>QvLib has no object deletion because deleting objects that are multiply
>instanced isn't straightforward. For example, consider this VRML scene:
>
>Separator {
> DEF SeparatorOne Separator {
> DEF SomeObject Separator {
> ... lots of stuff...
> }
> }
> DEF SeparatorTwo Separator {
> USE SomeObject
> }
>}
>
>What happens if you delete SeparatorOne? Is the SomeObject object deleted?
> If it is, it had better be removed from SeparatorTwo. If it isn't, some
>mechanism is needed to know whether or not objects are multiply instanced.
Simple reference counting will take care of this. By having _all_ QV objects
inherit from QVObject, which is reference counted, deletion becomes very
straight foward. Additionally, it becomes simple for someone to add their
own base behaviour. I didn't see your next paragraph, but I see that you
mention this. I think reference counting is fine for this sort of garbage
collection. For this stuff, I think a generational opportunistic scavenger
or something like it would be over-kill. IMHO, QV really needs, reference
counting, iostreams, and exceptions.
Robert