<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! 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 Theora project (and I think all the Ogg projects in general) generates a lot of warnings when compiled. 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. 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. However, when compiled for MS Windows using VC 2005 in debug mode, these initializations fail runtime checks and consequently throw exceptions. This is really irritating when trying to debug code using Theora. I actually had to run through all the code changing these initializations to something the compiler preferred like simply zeroing them out. 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. 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. Variable names like "vi," "vt," "vc" etc... help to confuse the reader and obfuscate the code. 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>