<div dir="ltr">Just to throw in my 2 cents, it may be partly due to the games I've worked on and/or my own personal style, but I always try to code all initialization in the constructors, except in rare cases like the TsAGE globals classes, where I need to be able reset the entire class contents back to a predefined state without recreating it. As such, the types of errors Coverity generate would be extremely relevant for me, since it would indicate a variable that I hadn't initialized, and likely should have, and would have a tendency to cause problems. Whilst I understand the argument about it possibly being an advantage to see problems in Valgrind, I personally wouldn't see that as a big enough reason not to have the classes properly initialized. <div>
<div class="gmail_extra"><br></div><div class="gmail_extra">But in any case, I concur with what was set earlier, in that I have no problem handling such changes on a case by case basis.</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">Paul.<br><br><div class="gmail_quote">On Sat, Nov 9, 2013 at 5:19 PM, Johannes Schickel <span dir="ltr"><<a href="mailto:lordhoto@gmail.com" target="_blank">lordhoto@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">Isn't the unstable behavior you talk about a clearly visible indicator</span><br>
</div>
for an actual regression from the refactoring whereas with the simple<br>
variable initialization it might be hidden (but not fixed) and thus make<br>
it harder to figure out the problem?<br>
<div class="HOEnZb"><div class="h5"><br>
// Johannes<br></div></div></blockquote></div></div></div></div>