scott wrote:
>> You don't want to initialize things twice, but you also don't get told 
>> if/where it is the system does it for you.

And it turns out that if you add the component before you initialize the 
game, then the component manager thing initializes all those added 
components. If you add the component after you initialize the game, the 
component gets initialized as you add it.  *But* if you add the component in 
the game's Initialize() function, the component never gets initialized. It 
does, however, get deinitialized, so I'm pretty sure that's a bug and not 
just something I'm doing wrong.

> Back when I was doing C++/DirectX stuff I remember things like this.  
> The documentation didn't mention whether objects were getting released 
> by functions or not.  If you used one object to create another, could 
> you then release the first object?  Or when you finally released the 
> second one, did it release the first one for you?

And that is the joy of GC. That's exactly the kind of example I use to 
explain why Alan Kay says that GC is required for an OO system. Otherwise 
you have to know the internals of the classes, and in particular whether 
they copy or reference the instances you pass to them.

> In the end trial and error using the debug libraries sorted out most 
> leaks. It had a cool feature where each object was given a number and 
> then when your program exited it gave a list of numbers that weren't 
> released.  You could then set the debug library to break when an object 
> with that number was created - it was then obvious (most of the time) 
> what you had forgotten/not realised to release.

Yeah, stuff like that is cool.  It can work OK when you have good tools. 
When your destination platform is too small to hold a debugger, you can be 
rather screwed.

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message