"Warp" <war### [at] tagpovrayorg> wrote:
>
>   Do you know what is the problem with the code?
>   It does not explain *how* it does it. A clear explanation of how it is
> done and the possible advantages and disadvantages would be good. It may
> be done in such a way that it's not suitable for the original application
> (eg. because of memory usage inefficiency).

As I said, I was not the author of the code, and yet it appeared to me
pretty self-explanatory. In short, it makes *very* cleaver use of
pointers... Upon ititialization, part of the allocated memory pool is filled
with pointers to other parts of the pool where actual data are stored. So
you may later de-reference the pool pointer as, say, pp[ K ][ I ][ J ] and
get exactly what one would expect... A *very* clever solution. As to its
efficiency: it is definitely the most efficient *general* solution to the
problem being discussed. While there may exist solutions that treat some
specific cases more efficiently, IMHO nothing campares well to amalloc()
when it comes to allocating truly arbitrary variable-size arrays. And,
definitely, it is more memory-efficient than a vector of vectors (since it
allocates just one block; the absolute minimum).

>   As for translating it to C++, I would certainly not use malloc()
> (you certainly know what's the main difference between the new operator
> and the malloc() function, besides syntax, don't you?)

Interesting. Besides *MUCH* harder heap debugging with 'new' operators, I
know no significant differences (it did not seem like meat calling ctors).
Or did you mean set_new_handler() and respective functionality? I works with
malloc() for ages, so here malloc() is on par.

Post a reply to this message