![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a829438@news.povray.org>, Warp <war### [at] tag povray org>
wrote:
> The problem with dynamic data containers is that they usually take
> extra memory (at least temporarily) and are sometimes slower than
> fixed-sized data containers.
Well, the unlimited version will parse a little slower, since it will
have to resize the array every so often, but unless you have some really
huge blend maps it won't be noticeable, and it will only affect parse
time. I took the approach of resizing the array when needed for
simplicity.
I think color_maps will reallocate to an array of exactly the right size
after parsing, but I'm not certain about the other blend_map types...but
the memory waste for each bland_map won't be very bad even if there are
unused entries.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
: Well, the unlimited version will parse a little slower, since it will
: have to resize the array every so often, but unless you have some really
: huge blend maps it won't be noticeable, and it will only affect parse
: time. I took the approach of resizing the array when needed for
: simplicity.
Wouldn't a better and faster approach be to read all the entries into
a temporary list and then allocate an proper-sized array, copy the entries
in there and then free the list?
I think that a temporary list would take less memory than a temporary
dynamic array.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a840791@news.povray.org>, Warp <war### [at] tag povray org>
wrote:
> Wouldn't a better and faster approach be to read all the entries into
> a temporary list and then allocate an proper-sized array, copy the
> entries in there and then free the list?
> I think that a temporary list would take less memory than a temporary
> dynamic array.
Maybe slightly faster at parse time, but would require one of these:
1: Changing the blend map data structure to a linked list. Pro: faster
parsing. Cons: slower rendering, slightly more memory, more coding.
2: Adding a pointer to each element of the blend map structure, so you
can use them in a linked list, but store them in an array for final
usage. Pros: faster parsing, and render speed not directly affected.
Cons: much more memory wastage, and even more coding.
3: Making a separate data type for elements of lists and of arrays, use
the list type for the temporary list and copy to an array of the array
type. Pros: Fast parsing speed, same rendering speed, and only
temporarily uses more memory. Cons: Much more coding than either of the
above, and seems like a generally clumsy solution.
If I use the resizeable array approach, it fits into the existing code
very well (in fact, it's almost like this was planned from the start,
but never implemented), doesn't take a lot of work to implement, and is
only noticeably slower every once in a while, when it has to resize the
array (for example, every 64 items). It wastes some memory temporarily,
but that can be removed, and it doesn't amount to much anyway. (I think
the color_map code does remove unused entries, but I'm not sure about
the other types.)
You could even include a little optional parameter to specify the number
of items, so the array would be allocated once. If someone really needs
to worry about blend map memory and parse speed, they could then specify
the number of entries in their map and the array would never have to be
resized.
I really don't think the speed advantage of using a temporary list would
be noticeable except in extreme cases of several hundred entries, when
the array has to be resized multiple times...and then you would probably
have to do a benchmark to notice it.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
: 1: Changing the blend map data structure to a linked list. Pro: faster
: parsing. Cons: slower rendering, slightly more memory, more coding.
I was talking about a TEMPORARY list. First you read the data into the
temporary list, then you allocate a proper-sized array, copy the data from
the list into the array and then destroy the list.
: 3: Making a separate data type for elements of lists and of arrays, use
: the list type for the temporary list and copy to an array of the array
: type. Pros: Fast parsing speed, same rendering speed, and only
: temporarily uses more memory. Cons: Much more coding than either of the
: above, and seems like a generally clumsy solution.
Coding a list is very easy and fast to code. And with the upcoming pov3.5
you'll be able to use STL lists so you don't have to code at all.
And it's not a clumsy solution. It's a clean and smart solution. Using
a (hand-coded) dynamic array is the clumsy solution.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a87d2dd@news.povray.org> , Warp <war### [at] tag povray org>
wrote:
> Coding a list is very easy and fast to code. And with the upcoming pov3.5
> you'll be able to use STL lists so you don't have to code at all.
You won't. Only the iostreams should be used (with a lot of care).
Thorsten
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Thorsten Froehlich" <tho### [at] trf de> wrote in message
news:3a87e7c7$1@news.povray.org...
> In article <3a87d2dd@news.povray.org> , Warp <war### [at] tag povray org>
> wrote:
>
> > Coding a list is very easy and fast to code. And with the upcoming
pov3.5
> > you'll be able to use STL lists so you don't have to code at all.
>
> You won't. Only the iostreams should be used (with a lot of care).
>
Why not ? The point of the STL is that it is generic, i.e. designed to
work with _any_ data classes - you really have to work hard to make your
classes incompatible with the STL, so, what's up with the C++ code in 3.5
that makes it so ?
--
Scott Hill.
NC Graphics (Cambridge) Ltd.
http://www.ncgraphics.co.uk
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Warp" <war### [at] tag povray org> wrote in message
news:3a87d2dd@news.povray.org...
> Chris Huff <chr### [at] mac com> wrote:
>
<sniped stuff about dynamically allocated arrays and linked lists>
>
> And it's not a clumsy solution. It's a clean and smart solution. Using
> a (hand-coded) dynamic array is the clumsy solution.
>
JPDA[1] - How is hand-coding a list any more clumsy and any less clean
and smart that hand coding a dynamic array, exactly ?
All a linked list is is a fancy dynamic array (in fact there's probably
more work (and, therefore, more chance of screwing something up) in hand
writing a linked list - the dynamic array just needs to keep track of the
current used and max sizes, a linked list requires maintaining previous
and/or next node pointers).
The only benefit you get with a linked list is improved random access
speeds.
--
Scott Hill.
NC Graphics (Cambridge) Ltd.
http://www.ncgraphics.co.uk
[1] JPDA - Just Playing Devils Advocate.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a8945a1@news.povray.org> , "Scott Hill"
<sco### [at] ncgraphics net> wrote:
> Why not ? The point of the STL is that it is generic, i.e. designed to
> work with _any_ data classes - you really have to work hard to make your
> classes incompatible with the STL, so, what's up with the C++ code in 3.5
> that makes it so ?
You missed the point. It is not that we are not compatible with the STL
(I never said that, did I?), but that there is no compatible STL. Most
platforms are far behind when it comes to an ISO C++ STL implementation.
It starts with different, non-standard include file names, add continues
with missing or different names for classes and methods, not to mention
bugs. For example, using standard STL would make compiling with the
currently available gcc plus libraries impossible (we spend a few days
sorting out just iostreams). Other problems include template support in
many compilers, and so on, and so on. Besides, we would be using two
memory models, one based on malloc/free, another on new/delete. Not all
compilers can (or want) to map new/delete to malloc/free so you also
could get increase memory fragmentation. Overloading new/delete is a
nice idea, but again requires so may platform specific changes (because
nobody really supports this part of the standard in the same way). Some
compilers don't even support block-level variable scope!
So, in summary, no STL in 3.5. We just hope the situation improves in
the next 12 - 24 month (especially gcc 3.0), but initial 4.0 development
(if we can use the STL at all by then) might still be a pain...
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povray org
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Thorsten Froehlich" <tho### [at] trf de> wrote in message
news:3a894f89$1@news.povray.org...
> In article <3a8945a1@news.povray.org> , "Scott Hill"
> <sco### [at] ncgraphics net> wrote:
>
> > Why not ? The point of the STL is that it is generic, i.e. designed
to
> > work with _any_ data classes - you really have to work hard to make your
> > classes incompatible with the STL, so, what's up with the C++ code in
3.5
> > that makes it so ?
>
> You missed the point. It is not that we are not compatible with the STL
> (I never said that, did I?)
No, you never, not in so many words anyway - your statement was a little
ambiguous so it could have been read that way.
> but that there is no compatible STL.
Tell me about it ! I was forgetting POV's cross-platform and therefore
cross-compiler too (note to self : just 'cos you code windows apps all day
and read windows programming books and eat windows code and sleep in a world
of windows, it don't mean windows is all there is....(Hmm, maybe I should
get out more....))
As you say, hopefully they'll fix a standard for the STL and then people
could actually work towards a target that isn't moving about all the time -
as it is currently you can't really blame compiler writers for the lack of
STL support when the ISO/ANSI boards keep changing there minds on just what
the standard is.
BTW, why did you say "Only the iostreams should be used" ? As I
understand it, they're the least supported part of the STL.
--
Scott Hill.
NC Graphics (Cambridge) Ltd.
http://www.ncgraphics.co.uk
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 13 Feb 2001 16:11:18 -0000, Scott Hill wrote:
> BTW, why did you say "Only the iostreams should be used" ? As I
>understand it, they're the least supported part of the STL.
Because they've been successfully encapsulated in a suitably cross-platform
way in the current source.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |