POV-Ray : Newsgroups : povray.programming : Array pointers Server Time
26 Sep 2024 23:52:35 EDT (-0400)
  Array pointers (Message 11 to 17 of 17)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Vadim Sytnikov
Subject: Re: amalloc() (long post)
Date: 18 Jan 2003 06:36:14
Message: <3e293c2e$1@news.povray.org>
"Thorsten Froehlich" <tho### [at] trfde> wrote:
>
> It depends on the topic - for example I would judge a book on MS-DOS as
> outdated, yes.  And even a few chapters in a book on algorithm analysis
> might be considered outdated.  The only written works that can never be
> outdated are fictional ones.

I see. Makes some sense, but I have to admit that I'm tempted to ask how
many knights' novels have you read recently. But I guess I should not ask,
since that would only lead to one more disagreement, right? :-)

Well, as to the code... it works for me perfectly. IMHO, nothing in it makes
it outdated. Nothing. If one programs in C, the code is perfectly usable
right away. If one is a C++ adept, writing a wrapper class is trivial.

In fact, I have my own "polished" version of that procedure, the one that I
use heavily in my projects. But since I were not the original author, I
though that it would be more fair to post the original version, with the
original comments etc. (especially given that the author was so generous to
release the code to the public domain).


Post a reply to this message

From: Warp
Subject: Re: amalloc() (long post)
Date: 18 Jan 2003 07:37:45
Message: <3e294a99@news.povray.org>
Vadim Sytnikov <syt### [at] rucom> wrote:
> Well, as to the code... it works for me perfectly.

  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 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?)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -


Post a reply to this message

From: Vadim Sytnikov
Subject: Re: amalloc() (long post)
Date: 18 Jan 2003 08:32:50
Message: <3e295782@news.povray.org>
"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

From: Warp
Subject: Re: amalloc() (long post)
Date: 18 Jan 2003 11:00:53
Message: <3e297a35@news.povray.org>
Vadim Sytnikov <syt### [at] rucom> wrote:
> Interesting. Besides *MUCH* harder heap debugging with 'new' operators, I
> know no significant differences (it did not seem like meat calling ctors).

  If you allocate an array of objects with malloc(), they will not be
constructed. When you free() the array, the objects will not be destructed.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -


Post a reply to this message

From: Vadim Sytnikov
Subject: Re: amalloc() (long post)
Date: 18 Jan 2003 11:09:56
Message: <3e297c54@news.povray.org>
> > Interesting. Besides *MUCH* harder heap debugging with 'new' operators,
I
> > know no significant differences (it did not seem like meat calling
ctors).
>
>   If you allocate an array of objects with malloc(), they will not be
> constructed. When you free() the array, the objects will not be
destructed.

Sorry for my numerous typos, but that was supposed to be "it did not seem
like you meant calling cator". So it did. OK.


Post a reply to this message

From: Vadim Sytnikov
Subject: Re: amalloc() (long post)
Date: 18 Jan 2003 11:34:47
Message: <3e298227@news.povray.org>
"Vadim Sytnikov" wrote:

> Sorry for my numerous typos, but that was supposed to be "it did not seem
> like you meant calling cator". So it did. OK.

WOW! I can't believe it! "cator" instead of "ctors" even in the erratum! I
should really have some rest... Where exactly is that "Island near the
Carribean" that Bill mentioned?...


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: amalloc() (long post)
Date: 19 Jan 2003 14:47:56
Message: <3e2b00ec$1@news.povray.org>
In article <3e293c2e$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> "Thorsten Froehlich" <tho### [at] trfde> wrote:
>>
>> It depends on the topic - for example I would judge a book on MS-DOS as
>> outdated, yes.  And even a few chapters in a book on algorithm analysis
>> might be considered outdated.  The only written works that can never be
>> outdated are fictional ones.
>
> I see. Makes some sense, but I have to admit that I'm tempted to ask how
> many knights' novels have you read recently. But I guess I should not ask,
> since that would only lead to one more disagreement, right? :-)
>
> Well, as to the code... it works for me perfectly. IMHO, nothing in it makes
> it outdated. Nothing. If one programs in C, the code is perfectly usable
> right away. If one is a C++ adept, writing a wrapper class is trivial.
>
> In fact, I have my own "polished" version of that procedure, the one that I
> use heavily in my projects. But since I were not the original author, I
> though that it would be more fair to post the original version, with the
> original comments etc. (especially given that the author was so generous to
> release the code to the public domain).

Completely unrelated, but here is an example of supposedly well-working code
that is only five years old:

<http://groups.google.de/groups?threadm=f5c52e87.0301190433.269fb975%40posti
ng.google.com>

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.