Source code related: Question about DObject

[Grubber]

There are some things related to DObject class, that are unclear for me.

For example, why is the DArgs class (command line arguments parser) inherited from DObject? And why is FTexture (and other classes that could benefit from the embedded type information) not inherited from DObject? Is it because it would slow down things? If this is the case, would it be a problem to make DObject and FTexture and others inherit from a single base class, containing only the type information and maybe some additional basic stuff?

Thanks for clarification.

[Graf Zahl]

DArgs: no idea. It probably served a purpose once but not anymore.
FTexture: Because it would create too much overhead. The pointer cleanup code has to scan each and every instance of DObject and there's a lot of textures in the game. But yes, it would definitely help if the textures had type information.

[Grubber]

What about keeping the pointer substitution/cleanup code only inside the DObject class (if it's inherited from some other class)? Or, what about making some sort of class flag that will prevent instances of classes flagged with it to be added to the active object list (DObject::Objects) so that they'll be excluded from the pointer cleanup?

[randi]

DArgs subclasses DObject because I've been planning on (eventually) doing scripting for a long time, and I wanted the class to be easily accessible by scripts.

FTexture does not subclass DObject because by the time I wrote it, every object was getting scanned when an object was destroyed, and I didn't want to add another few thousand objects to that scan.

I am considering limiting the scanning to just DThinker and its descendants, since it really only needs to be done for objects that can live on a level.

[Graf Zahl]

If you change it please create an intermediate class. I am using non-thinkers that require pointer cleanup in GZDoom do limiting it to DThinker would mean that I'd have to rewrite it afterward.

[randi]

Using another object flag is one possibility; there are certainly plenty of those unused. It would default to off for DObject and on for DThinker. So anything that subclasses DThinker would get it set and anything higher up in the hierarchy would have it cleared by default.