<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<br><div><span class="Apple-tab-span" style="white-space:pre">        </span>Thank you for bringing this up, Stuart! &nbsp;I've been meaning to mention this but it slipped my mind...</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>The&nbsp;Theora project (and I think all the Ogg projects in general) generates a lot of warnings when compiled. &nbsp;Obviously all these warnings turn out to describe harmless things but it's better to have a project with no warnings so that when a change is made and a warning for a real problem gets reported, it's not lost in a sea of irrelevant warnings...</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>The problem I had to solve was actually a little more serious than a mere warning. &nbsp;In the code, there are a lot of local variable declarations like so:</div><div><br></div><div><br></div><div>int func() {</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>int local_var = local_var;</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>// do stuff</div><div>}</div><div><br></div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>I'm guessing that this self initialization trick is supposed to trick the compiler into not reporting an uninitialized variable for variables that are only conditionally used. &nbsp;However, when compiled for MS Windows using VC 2005 in debug mode, these initializations fail runtime checks and consequently throw exceptions. &nbsp;This is really irritating when trying to debug code using Theora. &nbsp;I actually had to run through all the code changing these initializations to something the compiler preferred like simply zeroing them out. &nbsp;It would be nice if the official code base simply did this to begin with...</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Again, it would be nice if the various Ogg projects didn't report any warnings when compiled. &nbsp;You could almost do this just by throwing some brackets and explicit casts in the code...</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Finally, and a little off topic, but considering the lack of comprehensive documentation and tutorials for the various Ogg APIs, it would be a good idea for the example code, which frankly act like reference implementations, to be a little more verbose. &nbsp;Variable names like "vi," "vt," "vc" etc... help to confuse the reader and obfuscate the code. &nbsp;They have no place in an example program...</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Thank you...</div>                                               <br /><hr />Stay in touch. <a href='http://go.microsoft.com/?linkid=9712959' target='_new'>Get Messenger on your phone now.</a></body>
</html>