The following code fails in both pov and megapov (list too long) - but
megapov crashes. Sometimes (well, with varients of this - this version
always seems to crash immediately), the crash occurs straight away,
sometimes I get the standard error message, but them mp crashes on the next
attempt to render (even when I have corrected the fault by increasing the
increment of n to 0.1)

I'm using mp 6a

#declare n = 0;
#declare TestPigment =
pigment{
  bozo
  pigment_map{
    #while(n<=1)
      [n rgb 1]
      #declare n = n + 0.000001;
    #end
  }
}

Post a reply to this message

Tom Melly wrote:

(something)

It's because of the 256 map entries limitations....

Bouf.

Post a reply to this message

Tom Melly wrote:
> 
> The following code fails in both pov and megapov (list too long) - but
> megapov crashes.

You are not allowed more than 256 entries in a color map which explains
the warning message in the official version. You are correct however in
assuming that MP should not crash as a result.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Christophe Bouffartigue <Chr### [at] nanterremarellifr> wrote:
: It's because of the 256 map entries limitations....

  That's right, but crashing is still a bug.

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

Ken wrote:
> 
> You are not allowed more than 256 entries in a color map which explains
> the warning message in the official version. You are correct however in
> assuming that MP should not crash as a result.
> 

I think Chris Huff was working on removing that limitation, or was it
someone else?

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann wrote:
> 
> Ken wrote:
> >
> > You are not allowed more than 256 entries in a color map which explains
> > the warning message in the official version. You are correct however in
> > assuming that MP should not crash as a result.
> >
> 
> I think Chris Huff was working on removing that limitation, or was it
> someone else?

What would be gained by it ?

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

> > I think Chris Huff was working on removing that limitation, or was it
> > someone else?
> 
> What would be gained by it ?

	The delightful idea that no software should contain size limitations
of any kind. Especially since today's home computers may accept several Gbytes
of onboard memory. I personnaly don't think that (again nowadays) memory size,
as disk space, is a "good reason" compared to CPU time. But even the last becomes
smaller day after day for the same jobs. So why bother with limitations ?

	[Well, sorry for that, but I'm currently enjoying supercomputers for
my research calculations, and once I ran a "small" job using 96 processors in
parallel. Was just for fun since 8 are much more efficient in my case... the
device has something like 256 R12000 MIPS processors though]


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

In article <3A819B20.178355ED@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> I think Chris Huff was working on removing that limitation, or was it
> someone else?

I was, but haven't gotten it working right yet. If my code got stuck in 
0.7, that might explain the crash...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3A819F31.8892A310@pacbell.net>, lin### [at] povrayorg 
wrote:

> What would be gained by it ?

Simple: the ability to have more than 255 elements in blend maps.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

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.

  Of course this shouldn't matter in this case since the required size can
be calculated first, then a proper array allocated and initialized from the
input.

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

In article <3a829438@news.povray.org>, Warp <war### [at] tagpovrayorg> 
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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> 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

In article <3a840791@news.povray.org>, Warp <war### [at] tagpovrayorg> 
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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> 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

In article <3a87d2dd@news.povray.org> , Warp <war### [at] tagpovrayorg>  
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

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3a87e7c7$1@news.povray.org...
> In article <3a87d2dd@news.povray.org> , Warp <war### [at] tagpovrayorg>
> 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

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a87d2dd@news.povray.org...
> Chris Huff <chr### [at] maccom> 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

In article <3a8945a1@news.povray.org> , "Scott Hill" 
<sco### [at] ncgraphicsnet> 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] povrayorg

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

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3a894f89$1@news.povray.org...
> In article <3a8945a1@news.povray.org> , "Scott Hill"
> <sco### [at] ncgraphicsnet> 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

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

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> 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.
>


    Cool.

Actually....
    <rant on> Having thought on this a little - stuff like this really
annoys me - standards committees are meant to reach an agreement about what
the standard means, not keep changing there minds, dev tools developers
should stop arsing about (though as I said - it's hardly their fault with
moving targets an' all that jazz) and only release complete libraries that,
at the minimum, comply to _some sort of standard_ and we programmers should
all stop just taking all this shit lying down - we bitch and moan privately
about the shit standards, buggy dev tools, moving targets and the like but
bugger all get's done - it's about time we used some of the power we have -
without any programmers doing any actual development on a platform, that
platform will die - we have the ultimate power to decide what makes it and
what doesn't - we should exercise it and stop putting up with this shit -
after all, it's us that get's the blame in the end - Project behind schedule
? That'll be the lazy developers. Bloaty code ? That'll be the lazy
developers. Bug-ridden shit ? That'll be the lazy programmers. Trouble is
sometimes you only get shit to work with and no matter how well you sculpt
it, shit is shit. <rant off>

--
Scott Hill.
NC Graphics (Cambridge) Ltd.
http://www.ncgraphics.co.uk

Post a reply to this message

In article <3a895cd8@news.povray.org> , "Scott Hill" 
<sco### [at] ncgraphicsnet> wrote:

> STL support when the ISO/ANSI boards keep changing there minds on just what
> the standard is.

STL is stanard.  Part of the ISO/IEC 14882-1998 one (or ISO C++ for
short).  The problem is nobody seems to care too much for full
compliance - new features sell, not a good implementation of the old
ones :-(

>     BTW, why did you say "Only the iostreams should be used" ? As I
> understand it, they're the least supported part of the STL.

Yes and no.  However, they are the simplest to fix because the
implementation has hardly changed in the past five years (except for a
few hardly ever used functions).  For gcc it is just renaming a few
include files (well, creating a include file with the right name taht
includes the one with the wrong name).


      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

In article <3a896c71@news.povray.org> , "Scott Hill" 
<sco### [at] ncgraphicsnet> wrote:

>     <rant on> Having thought on this a little - stuff like this really
> annoys me - standards committees are meant to reach an agreement about what
> the standard means, not keep changing there minds, dev tools developers
> should stop arsing about (though as I said - it's hardly their fault with
> moving targets an' all that jazz) and only release complete libraries that,
> at the minimum, comply to _some sort of standard_ and we programmers should
> all stop just taking all this shit lying down - we bitch and moan privately
> about the shit standards, buggy dev tools, moving targets and the like but
> bugger all get's done - it's about time we used some of the power we have -
> without any programmers doing any actual development on a platform, that
> platform will die - we have the ultimate power to decide what makes it and
> what doesn't - we should exercise it and stop putting up with this shit -
> after all, it's us that get's the blame in the end - Project behind schedule
> ? That'll be the lazy developers. Bloaty code ? That'll be the lazy
> developers. Bug-ridden shit ? That'll be the lazy programmers. Trouble is
> sometimes you only get shit to work with and no matter how well you sculpt
> it, shit is shit. <rant off>

It is a standard, but nobody cares :-(


____________________________________________________
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

On 2001-02-13 14:39, Scott Hill <sco### [at] ncgraphicsnet> wrote:
>    The only benefit you get with a linked list is improved random access
>speeds.

Ah, no. You get better random access speed with a dynamic array (O(1)
vs. O(n)). You may get a faster time for an append operation with a
linked list, but that depends on how good your malloc implementation is.

	hp

-- 
   _  | Peter J. Holzer    | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR       | which is our implementation of Linux.
| |   | hjp### [at] wsracat      | 
__/   | http://www.hjp.at/ |	-- Scott McNealy, Dec. 2000

Post a reply to this message

You make it sound like most compilers (specially gcc) have extremely
poor support for STL; that it's almost impossible to make anything according
to the C++ standard because the standard-conforming STL implementation is
almost inexistent.

  I would like to note that this is not true.
  I have been coding for more than 2 years with gcc using STL (as my work,
not just as hobby). It is true that there are some things missing (like
string iterators), but mostly the STL implementation conforms to the standard
and is very usable.
  Among other "exotic" things in the STL, I have used stream iterators,
iterator traits, functors, predicates and several "exotic" utilities
(such as bind1st, bind2nd, etc), and they all work as the C++ standard states.

  And this is not all. The STL implementation used by gcc is (at least
partially) very efficient.
  For example once I tried to make my own sort()-function which would "kill"
std::sort() (with all the same functionality but a lot faster). I used every
possible trick I know to make it faster (eg. I used a hybrid between randomized
quicksort and insertion sort, which is about 25% faster than quicksort
alone), but I didn't succeed. My implementation of sort() was slower than
std::sort() in almost every case.

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

In article <3a8a6369@news.povray.org> , Warp <war### [at] tagpovrayorg>  
wrote:

>   You make it sound like most compilers (specially gcc) have extremely
> poor support for STL; that it's almost impossible to make anything according
> to the C++ standard because the standard-conforming STL implementation is
> almost inexistent.

Yes, and the support is really poor, but not in the teams you are
talking about - you missed my point completely.

I mentioned gcc as one _example_ (because I didn't want to write a too
long response), but many other compilers have the same problem (i.e.
Visual C, CodeWarrior, etc).  The point is _not_, I repeat is _not_,
that _one_ compiler is not fully standard compliant, but that hardly any
compiler gets at least the important (read: the stuff I want to use)
stuff right.  Now, in order to write anything portable you first have to
make sure you know about all the missing features in every
compiler/library combination you want to use, then you can hope to find
a usable subset of available functions and classes.  Add yet another
compiler/library combination later and you have to do it all over again.
This is hardly something I consider a useful _cross-platform_ library.

>   I would like to note that this is not true.
>   I have been coding for more than 2 years with gcc using STL (as my work,
> not just as hobby). It is true that there are some things missing (like
> string iterators), but mostly the STL implementation conforms to the standard
> and is very usable.

Yes, I use the STL frequently (for example in the POV-Ray 3.5 Mac
frontend), but I do not remember a case when I did not have to make
changes to code (taken straight from the ISO C++ standard document or
Stroustrup's book) when trying to compile other STL programs under
Visual C++, gcc and CodeWarrior (see below).  Let me note that these are
the three compilers the team is using for Windows, Linux and Mac OS
respectively.  The Visual C++ library is a mess when it comes to string
support (seems to have to do with making it compatible with MFC, I
guess), in gcc iostreams are more distant from the standard than
anything else (not to mention the template problems they even admit to
have on their website!) and CodeWarrior comes with a nice and nearly
complete library but every not-so-frequently-used function seems to have
bugs you have to fix first it or wait half a year for them to do it (and
did I complain that an average compile of a medium sized program can
take 100 MB of memory if it is using templates?).

Or, just look at the endless number of compiler specific ifdefs in the
SGI STL.  Ever wondered why they are needed?  Surly not because all
compilers even remotely support a common subset of "simple things" like
template support.

>   Among other "exotic" things in the STL, I have used stream iterators,
> iterator traits, functors, predicates and several "exotic" utilities
> (such as bind1st, bind2nd, etc), and they all work as the C++ standard states.

As said above, I never said you cannot use the STL with a single
compiler/library combination!

Take the "povdocgen" utility (in the Perforce depot) for example.  It
only uses string, vector, list and algorithm and is 1700 lines.  It took
several hours to find out just what is causing gcc to not like it.  And
still, this does not mean that it will work with Visual C++.  The code
is really primitive and uses only the simplest features of the STL in a
minimal manner.  And it takes hours to port to another compiler/library
combination.  Granted, we will develop POV-Ray 4 on the major platforms
simultaneously, but still consider this scenario:

Someone submits a change to the code.  You download it and try to
compile.  You get errors because some STL class member function does not
even exist.  Now you have to find a workaround using another member
function.  This takes you lets say two hours.  Then you submit your
change.  With a bit of luck it still works for the person who submitted
the original change.  A third person downloads it, has to make changes
for his compiler, and submits the change.  How likely is it now that it
still works for the first person or you?  How much time was spend to
sort this out that could have been used doing some real work?  How much
testing and team communication overhead do we introduce by this kind of
issues?  Or, how long will it delay a release?

>   And this is not all. The STL implementation used by gcc is (at least
> partially) very efficient.

Yes, my local STL is really fast, too, but what is all the speed good
for if it is still not portable? - Nothing, if you are talking about
cross-platform code...


      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

In article <3a8ab231@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Yes, and the support is really poor, but not in the teams you are
> talking about - you missed my point completely.

I hate my spell-checker.  This should read "not in the terms", of
course.


____________________________________________________
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

"Peter J. Holzer" <hjp### [at] hjpat> wrote in message
news:slr### [at] tealhhjpat...
> On 2001-02-13 14:39, Scott Hill <sco### [at] ncgraphicsnet> wrote:
> >    The only benefit you get with a linked list is improved random access
> >speeds.
>
> Ah, no. You get better random access speed with a dynamic array (O(1)
> vs. O(n)). You may get a faster time for an append operation with a
> linked list, but that depends on how good your malloc implementation is.
>


    What I said - only less correctly. That's what I meant anyway - poor
choice of words on my part.

--
Scott Hill.
NC Graphics (Cambridge) Ltd.
http://www.ncgraphics.co.uk

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Yes, my local STL is really fast, too, but what is all the speed good
: for if it is still not portable?

  It's an interesting question whether a 100% standard compliant code
can be considered portable or not.
  If the code is completely standard, it's not the code's fault that a
compiler can't compile it. I don't think that you can say that the code
is not portable, since the code is 100% standard.

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

On 2001-02-16 14:34, Warp <war### [at] tagpovrayorg> wrote:
>Thorsten Froehlich <tho### [at] trfde> wrote:
>: Yes, my local STL is really fast, too, but what is all the speed good
>: for if it is still not portable?
>
>  It's an interesting question whether a 100% standard compliant code
>can be considered portable or not.
>  If the code is completely standard, it's not the code's fault that a
>compiler can't compile it. I don't think that you can say that the code
>is not portable, since the code is 100% standard.

I do think so. "Portable" does not mean the same thing as "standard
compliant". It means "compiles and runs with the expected result on a
wide variety of platforms". Since I'm not familiar with C++, I'll use C
as an example:

The C standard was finalized in 1989, about 15 years after the language
was invented and about 10 years after K&R was published.

Does that mean that one could not write portable C programs until 1989,
because there was no standard? Absolutely not. There were a lot of
programs, which worked on PCs, Unixes, VMS, mainframes, etc. They were,
in every sense of the word, portable.

OTOH, If, in 1990, you wrote a program with the C standard as your only
reference, would that program be portable? Probably not. The C standard
did not only define a common subset of all existing C implementations
(although that was its primary goal), but it also standardized some
things which were only implemented by a few implementations or even
other languages, but seemed generally useful, and some things were even
invented out of the blue. So a program, which used for example,
prototypes, <stdarg.h>, locales, and some macro features would have a
very slim chance to compile on a randomly chosen platform. It was not
portable. OTOH, a lot of not standards-compliant programs (because they
used <varargs.h> or sockets, or relied on two's-complement arithmetic)
were very portable, because those features they relied upon were in
widespread use.

For C, which is a rather small standard IMHO, it took about 5 years
after the standard was published, before you could expect the large
majority of installed compilers to handle most of the C standard
correctly. Until that time a portable program had to work around the
flaws and deficiencies of various compilers.

You can debate whether this is the fault of the standard writers,
because they standardized things which didn't exist, or the compiler
writers, because they were not fast enough in providing
standard-compliant compilers, or of the customers, because they didn't
upgrade their compilers as soon as they were available, but that was the
situation with C in the early 1990s.

I expect the situation will be similar for C++.

	hp

-- 
   _  | Peter J. Holzer    | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR       | which is our implementation of Linux.
| |   | hjp### [at] wsracat      | 
__/   | http://www.hjp.at/ |	-- Scott McNealy, Dec. 2000

Post a reply to this message

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3A819F31.8892A310@pacbell.net...
>
> What would be gained by it ?
>

I don't know - maybe nothing. But while the limitation exists we will never
know.

Post a reply to this message