Christopher James Huff wrote:
> 
> Still having problems? :-(
> What exactly were the problems? The line endings didn't give you any
> trouble, did they?

No, but like previous versions it seems to be marked as text file and
therefore downloaded incorrectly, gzip refused to decompress.

> Well, at least you were still able to get them. Maybe I should get
> around to setting up my Earthlink account web site as a mirror...

Could be a good idea.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 18 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> I'm developing it using Apple's modified version of gcc 2.95.2.
> Obviously, vector::at() works here...maybe Apple fixed that part.

  Or maybe they are using another implementation of the STL library than
the one which comes by default with gcc (there are many implementations,
some of them in some ways better than the gcc implementation).

> It seems like such a simple and basic thing that it would be surprising 
> for even the least complete and compliant implementation to lack it.

  That's what surprises me as well.

> In the next version I'll use the [] operator instead...

  After all, if you are completely sure you will never index out of boundaries,
using the at() method is useless overhead.

  Besides, when you use the at() method, you should catch the exception it
might throw. Do you do that? If not, then using at() is pretty useless. :)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> and "parameters->at(j)" with "(*parameters)[j]" in the others.

  You could make also: parameters->operator[](j)

  Of course whether that is better is a matter of taste. :)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

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

>   Or maybe they are using another implementation of the STL library than
> the one which comes by default with gcc (there are many implementations,
> some of them in some ways better than the gcc implementation).

The header has comments from Hewlet Packard and Silicon Graphics, and I 
found this in the header file:

  // "at" will eventually have range checking, once we have the
  // infrastructure to be able to throw stl range errors.
  reference at(size_type n) { return (*this)[n]; }
  const_reference at(size_type n) const { return (*this)[n]; }

Looks like someone hacked it in temporarily. There are other comments 
about differences between the SGI version and the standard...that's 
probably why.
Apple's moving to gcc 3.1, they probably aren't going to put much effort 
into the old libraries.


>   After all, if you are completely sure you will never index out of 
> boundaries, using the at() method is useless overhead.

In one of the cases, it was just a leftover from a previous design. In 
the other cases, I don't know about the bounds...I'll have to do the 
checking myself.


>   Besides, when you use the at() method, you should catch the exception it
> might throw. Do you do that? If not, then using at() is pretty useless. :)

Not quite useless...the uncaught exception would terminate the program 
and the debugger would show where it came from. I'm still working on 
error checking, the next version will use exceptions.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message