[Scummvm-devel] Header files.
Max Horn
max at quendi.de
Sun Dec 21 10:49:01 CET 2003
Am Sonntag, 21.12.03 um 19:00 Uhr schrieb LavosSpawn:
>
>> "J.Brown (Ender)" <ender at scummvm.org> writes:
>>
>>> From memory, it must be the very first include.
>>
>>
>> Just out of curiosity, what will happen if it isn't?
>>
>
> It simply won't compile.
> Why do we even have these overloaded news and deletes?
Historically, we had them because people relied on newly created
class/struct instances to be zeroed out. However on many operating
systems this was not true. In order to at least get stuff running,
new/delete were added which explicitly zeroed the memory (of course
this didn't help for anything allocated on the stack). Then over time,
we worked hard to remove all traces of the "memory is zeroed out
initially" assumption. (Valgrind was very valuable for this). Nowadays,
nothing in ScummVM should rely on this anymore (anything which does is
broken and must be fixed).
So now we are in a position were we could remove those. However we
chose to keep them for the time being, but changed to poison the data
(i.e. setting it to 0xE7, not 0). Of course that harms Valgrind (and
apparently, this MSVC7 feature you mention). But for anybody who's not
using those, it means they get crashes if they are lazy and don't init
their member vars. Which is a good thing. We tried leaving the
poisoning out, and quickly some code crept in which wasn't portable...
That said, it'd be OK by me if we "#if 0" them now (but not fully
remove them, I'd like to keep them around, though, because they can be
quite useful for debugging).
> e.g. M$VC++7 automatically checks for reads of unintialized
> variables...
> which don't work this way, as all variables seem to be initialized.
Fine. Then you can change common/scummsys.h and base/main.cpp not to
overload them for MSVC7. Should be trivial to do, eh? :-)
> And I remember that these overloads caused a funny crash in BASS as
> well,
> when the overloads were changed to setting everything to zero for a
> release.
That indicates a bug in the BASS engine then. There is no other reason
I can imagine at this point...
Max
More information about the Scummvm-devel
mailing list