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