Christopher James Huff wrote:
> 
> This version fixes some bugs with evaluating expressions mixing scalars
> and vectors, and plugs a fairly big memory leak. I've also added a lot
> of other goodies...new functions, more operators, a random number
> generator using the Mersene Twister algorithm, graphing tools, several
> particle simulation demos...
> Still need a Unix makefile, any volunteers?
> 
> Feedback, please! Questions, comments, suggestions, flames, anything...
> 

After having the previously mentioned troubles downloading the files i had
errors compiling 'csdl_engine.cpp',  'csdl_streams.cpp' and
'csdl_stdlib.cpp':

g++ -c -Wall -o csdl_engine.o csdl_engine.cpp
csdl_engine.cpp: In method `class istream *
csdl::CSDL_Engine::OpenFile(const string &)':
csdl_engine.cpp:82: no matching function for call to
`vector<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
>,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
> > >::at (int &)'

g++ -c -Wall -o csdl_streams.o csdl_streams.cpp
csdl_streams.cpp: In method `class csdl::Data *
csdl::Stream_Read_Fn::Run()':
csdl_streams.cpp:31: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int &)'
csdl_streams.cpp: In method `class csdl::Data *
csdl::Stream_Write_Fn::Run()':
csdl_streams.cpp:38: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int &)'
csdl_streams.cpp: In method `class csdl::Data *
csdl::Stream_Open_Fn::Run()':
csdl_streams.cpp:45: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_streams.cpp:46: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'

g++ -c -Wall -o csdl_stdlib.o csdl_stdlib.cpp
csdl_stdlib.cpp: In method `class csdl::Data * csdl::SystemFn::Run()':
csdl_stdlib.cpp:31: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp: In method `class csdl::Data * csdl::MinFn::Run()':
csdl_stdlib.cpp:39: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp:41: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int &)'
csdl_stdlib.cpp:41: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int &)'
csdl_stdlib.cpp: In method `class csdl::Data * csdl::MaxFn::Run()':
csdl_stdlib.cpp:49: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp:51: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int &)'
csdl_stdlib.cpp:51: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int &)'
csdl_stdlib.cpp: In method `class csdl::Data * csdl::VLengthFn::Run()':
csdl_stdlib.cpp:59: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp: In method `class csdl::Data * csdl::VLengthSqrFn::Run()':
csdl_stdlib.cpp:66: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp: In method `class csdl::Data * csdl::VNormalizeFn::Run()':
csdl_stdlib.cpp:73: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp: In method `class csdl::Data * csdl::VDotFn::Run()':
csdl_stdlib.cpp:80: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp:80: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp: In method `class csdl::Data * csdl::VCrossFn::Run()':
csdl_stdlib.cpp:87: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp:87: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.cpp: In method `class csdl::Data *
csdl::FnRNGObjectSeed::Run()':
csdl_stdlib.cpp:156: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.h: In method `class csdl::Data *
csdl::Fn2ScalarRtScalar<double>::Run()':
csdl_function.h:88:   instantiated from here
csdl_stdlib.h:129: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.h:129: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'
csdl_stdlib.h: In method `class csdl::Data *
csdl::Fn1ScalarRtScalar<double>::Run()':
csdl_function.h:88:   instantiated from here
csdl_stdlib.h:114: no matching function for call to `vector<csdl::Data
*,allocator<csdl::Data *> >::at (int)'


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

In article <3CB015E3.65C0F697@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> After having the previously mentioned troubles downloading the files i had
> errors compiling 'csdl_engine.cpp',  'csdl_streams.cpp' and
> 'csdl_stdlib.cpp':

Ah, don't you just love template errors? :-/
It seems to be choking on the STL vector "at()" method...I have no idea 
why, it is standard. What version compiler and libraries are you using?
Anyone else have any ideas?
Try replacing "libPaths.at(j)" with "libPaths[j]" in csdl_engine.cpp, 
and "parameters->at(j)" with "(*parameters)[j]" in the others.

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

In article <3CB015E3.65C0F697@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> After having the previously mentioned troubles downloading the files
...snip...

Still having problems? :-(
What exactly were the problems? The line endings didn't give you any 
trouble, did they?
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...

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

Christopher James Huff <chr### [at] maccom> wrote:
> It seems to be choking on the STL vector "at()" method...I have no idea 
> why, it is standard. What version compiler and libraries are you using?

  At least gcc 2.x does not support the standard in this case (I haven't
the slightest idea why).
  I don't know about gcc 3.x (I haven't tried).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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

>   At least gcc 2.x does not support the standard in this case (I haven't
> the slightest idea why).
>   I don't know about gcc 3.x (I haven't tried).

I'm developing it using Apple's modified version of gcc 2.95.2.
Obviously, vector::at() works here...maybe Apple fixed that part.

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. In 
the next version I'll use the [] operator instead...

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

Christopher James Huff wrote:
> 
> Ah, don't you just love template errors? :-/
> It seems to be choking on the STL vector "at()" method...I have no idea
> why, it is standard. What version compiler and libraries are you using?

gcc 2.95.3-5

> Try replacing "libPaths.at(j)" with "libPaths[j]" in csdl_engine.cpp,
> and "parameters->at(j)" with "(*parameters)[j]" in the others.

It compiled correctly with that modifications.

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