>> Heh, really? Most languages I work with can allocate new objects in O(1)
>> time and using O(1) memory for bookkeeping. I'm not used to dynamic
>> allocation being anything to worry about.
>
>    Last time I checked, 16 bytes is O(1) memory.

You seem to suggest that there's 16 bytes of overhead /per object/. I'm 
saying I'm used to there being a fixed number of bytes of overhead, 
regardless of the number of objects. That's O(N) vs O(1).

>>>> Mmm, I hadn't even thought of using an /array/. I suppose the upper
>>>> bound on the tree size is statically known, so why not?
>>>
>>>     The array doesn't necessarily have to be fixed in size.
>
>> It does if it's static. Either that or the source I'm reading is
>> incorrect...
>
>    You don't have to use a static array.

Sure. But then you're dynamically allocating again.

>> Well, sure. If I was going to allocate, I don't know, one object for
>> every pixel on the screen, then sure
>
>    But that's exactly what object-oriented design would have you do.

Sure. And I'm saying, if I wanted to do something like that, then yes, I 
might go out of my way to try to make it efficient. (E.g., by not using 
elaborate inheritance hierarchies and such.)

>    Anyways, the major issue with dynamic allocation is memory management.
> If by avoiding allocating individual objects manually you save yourself
> the trouble of having to manage the memory, it's a win-win situation.
> Why would you not want to do that?

Sure, avoiding manual memory management is always a good idea. It seems 
the cost is that you have less flexibility in designing your classes. 
(Then again, how many different kinds of pixel can there possibly be?)

>>>     Since TreeNode there is managing dynamically allocated memory, you'll
>>> have to write a proper copy constructor and assignment operator or else
>>> you have a leak and/or accesses to deleted memory. (And as I said in my
>>> previous post, that's not trivial because of all the options you have.)
>
>> How about if I never actually need to duplicate the tree? Does that make
>> things any simpler?
>
>    You are copying TreeNode objects in the above code.

*facepalm*

Right. I think I know how to redesign to avoid that. Should make things 
a bit more coherent...

Post a reply to this message