In article <3aaa02c0@news.povray.org> , "Alessandro Coppo" 
<a.c### [at] iolit> wrote:

> P.S.: if "The Team" starts rewriting collections and so from scratch, my

No, we are not doing this.  See the September announcement!

    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

On Sat, 10 Mar 2001 11:24:36 +0100, "Alessandro Coppo"
<a.c### [at] iolit> wrote:


>SGI STL compiles and works correctly even with that pile of brown stuff (tm)

^^^^^^^^^^^

I call it "biodegradeable bovine waste material"

follow-ups to o-t


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Tue, 6 Mar 2001 17:20:34 -0000, Scott Hill wrote:
> >"Wlodzimierz ABX Skiba" <abx### [at] abxartpl> wrote in message
> >news:3aa50f00@news.povray.org...
> >> > Supported compilers (taken from website) :
> >>
> >> any free for dos ?
> >
> >    Free no, but MSVC, and probably Borland and Watcom, will target DOS.
>
> Not MSVC in any recent version.  I think v. 1.52 was the last version to
target
> anything that isn't 32-bit.
>

    Sorry, yeah, should've clarified that a bit - as standard, no, MSVC does
not target DOS, but you can get an add-in for it (or at least could - I lost
my copy a while back in a H/D crash and, despite an extensive i'net search
(going on what little info I can recall about it), I can't find hide nor
hair of it any more }:-/ ).

> >> any one for amiga ?
> >
> >    Are there any C++ compilers _at all_ for the Amiga ?
>
> Well, there's GCC.  That works for DOS, too, in the form of DJGPP.
>

    Should be fine then.

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3aa55da0$1@news.povray.org...
> In article <3aa508f0@news.povray.org> , "Scott Hill"
> <sco### [at] ncgraphicsnet> wrote:
>
> I apologize in advance for my very clear words.  They are not personal.
> Please don't be offended.
>

    Don't worry - no offence taken. And like wise, please don't be offended
by my replies.

> >     So, why not use a cross-platform STL implementation ?
> >
> >     See : http://www.stlport.org
>
> You are missing the point.  The point is not having to _deal_ with the
> hassle of incompatible STLs.  Limiting to a specific implementation that
> works on a subset of compilers is by no means a solution to the problem.
> The goal is not writing a program using STL but writing a ray-tracer,
> thus we need tools that work _flawlessly_ not not those one first has to
> fight with for days to know their limitations.
>

    Well, I don't know the POV source code, but, my guess would be that it
uses various containers in all sorts of places and, even if it doesn't,
they're very usefull to patch writers. The STL implements a _standard_ set
of such containers - if you know the STL (and, IMPO[1], all C++ programmers
of any merit should know at least a little of the STL) you can develop code
for any project that uses the STL. Or to put that from another perspective,
if POV used STL any C++ programmer that knows the STL would avoid the
learning curve associated with learning POVs container implementation and
limitations.

< snipped list of compilers supported by the STL port>
> ...Some of them don't support templates (like gcc 2.7.2 or MrC 3.x or
> VC 4.x or Symantec C++, which has not been updated for more than four
> years at least on the Mac) in any way even close to any pre-standard.

    Yeah I thought a couple of them were a little suspect, but the web site
says it's been tested on these platforms and under these compilers and,
considering it's free, why would they lie ?

> The very fact that this STL had to be "ported" shows that it is a single
> big hack, no a usable piece of software.  Being able to compile code
> does not imply that it is fit for any purpose...
>

    It's only 'ported' because of the poor standards compliance at the
moment - it implements, as best it can for each platform, a standard set of
interfaces and it's really only the exotic stuff that may not work - program
to the standard (and avoid some of it more exotic features (shouldn't be
difficult)) and you can expect your code to work on any platform that
supports the STL.

> > basically the message was that, due to the inconsistency
> > in the various compiler providers STL implementations, one would not be
able
> > to use the STL within the POV 4.0 source code.
>
> No, you misunderstood.
>

    No I don't.

    If a platform does not support the STL then that's a problem for
compiler writers, not app developers - in any cross-platform project you
_have_ to make compromises and, sometimes, sacrifices to produce the optimum
solution. If, after analysis, that means the STL's out, then fine, but that
decision should be made after careful consideration of all the pros and
cons - that decision can not be made without the relevant information - I
was merely supplying that information.

>
> Last but not least, do not worry about this issue.

    Don't worry, I won't be losing any sleep over it.

> The team will find a
> working compromise, but as pointed out in previous posts about 4.0:
> There is no point discussing 4.0 features because nothing has been
> decided yet. Do don't spend your time on things that are not needed.

    Right, I really don't get this attitude - how is discussion bad ?
Without it the POV team can not get any perspective what-so-ever about what
the end users and other developers would like to see in POV - in the end the
POV team are going to make the final decision any way, so just what harm is
such discussion going to do ? IMPO[1], it can only help.

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

[1] - IMPO : In My Professional Opinion.

Post a reply to this message

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

> in the end the
> POV team are going to make the final decision any way, so just what harm is
> such discussion going to do ? IMPO[1], it can only help.

There is no harm, but as it has been stated frequently (i.e. in the
September announcement), we will just ignore such discussion.  The point
is that any such discussion is purely theoretical until we actually have
a design.  You first have to have a basic design, then you decide which
tools to use.  It is just a waste of time without knowing what we are
actually going to need.  That's all.


     Thorsten


> The STL implements a _standard_ set of such containers  <snip>

I know what the STL does.  I use the STL frequently.

>     Yeah I thought a couple of them were a little suspect, but the web site
> says it's been tested on these platforms and under these compilers and,
> considering it's free, why would they lie ?

No a lie.  Just a "don't care" or "don't know better" attitude.  There
is a big difference in software that "works somehow" and that "works
well".
Take a look at some of the many free image file format libraries.  They
clearly fall in the category "works somehow":  Apparently non of the
programmers writing them know how to use "typedef".  Instead, you find
something a conditional compile statement like "we have a brain-damaged
compiler that emits warnings (or worse, errors) for structure
definitions that are never filled in".  This one is taken from the
independent JPEG lib, similar comments are in ZLib.  Now, the funny
thing is that they claim somewhere this would be compiler specific,
including some compilers used for the development of POV-Ray yet we
don't have the problem ... my point is that frequently these free
libraries get ported in a "has to work yesterday or earlier" manner
instead of finding the true problem (lack of proper use of "typedef" in
this case).

And, you can observe exactly the same in some (not all!) of the patches
for POV-Ray when it comes to features (not compiler issues).  Someone
adds a feature that "works somehow".  Now guess who has to clean this up
later?  Considering the delay of 3.5, you can make a good guess (also
this is not the only reason for all the delays).  So, how much time
would we spend fixing this particular STL implementation?

>     It's only 'ported' because of the poor standards compliance at the
> moment - it implements, as best it can for each platform, a standard set of
> interfaces and it's really only the exotic stuff that may not work - program
> to the standard (and avoid some of it more exotic features (shouldn't be
> difficult)) and you can expect your code to work on any platform that
> supports the STL.

Yes, "more exotic", but what is "more exotic" for which compiler?  And,
how can a good library work around compilers such as gcc 2.72 (of
course, never versions work better) that claim in a warning (shown
whenever used) that templates are broken?!?  Obviously it has to be
doing some "dirty tricks".  Now, how can one be sure the code of such a
library is of really high quality?

>     If a platform does not support the STL then that's a problem for
> compiler writers, not app developers - in any cross-platform project you
> _have_ to make compromises and, sometimes, sacrifices to produce the optimum
> solution. If, after analysis, that means the STL's out, then fine, but that
> decision should be made after careful consideration of all the pros and
> cons - that decision can not be made without the relevant information - I
> was merely supplying that information.

But this is not my point!  My point is that having to bother with each
implementations limitation is not worth it.  Is there a point to write a
program that uses STL at any cost only because STL should be used, even
if this means you are struggling more with STL compiler problems than
with the actual program's bugs?  If a company can afford hiring more
people to compensate for the lost efficiency is one thing, if one has to
compensate for this by using more personal spare time (if possible) is
another!

>> The team will find a
>> working compromise, but as pointed out in previous posts about 4.0:
>> There is no point discussing 4.0 features because nothing has been
>> decided yet. Do don't spend your time on things that are not needed.
>
>     Right, I really don't get this attitude - how is discussion bad ?

Because it is premature?

> Without it the POV team can not get any perspective what-so-ever about what
> the end users and other developers would like to see in POV -

I could say "who cares", but it would be incorrect.  Of course users
suggest features all the time, and the useful ones will make it into
POV-Ray sooner or later.

However, as for developers, who cares?  If you you don't like the source
code structure, commenting, style or anything it does not matter.  As
long as we can get along with it, it stays the way we are used to.  The
only time we consider other developers is when it comes to portability.
In fact, his is clearly stated in the source code:  "This source code
file is provided so that users may experiment with enhancements to
POV-Ray and to port the software to platforms other than those supported
by the POV-Ray Team."



NOTE: Opinions expressed are my own and do not necessarily reflect those
of the POV-Team.


____________________________________________________
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

Thorsten Froehlich wrote in message <3aaced70$1@news.povray.org>...
>Yes, "more exotic", but what is "more exotic" for which compiler?  And,
>how can a good library work around compilers such as gcc 2.72 (of
>course, never versions work better) that claim in a warning (shown
>whenever used) that templates are broken?!?  Obviously it has to be
>doing some "dirty tricks".  Now, how can one be sure the code of such a
>library is of really high quality?


Where did you manage to get gcc 2.72 ? Next to a T.Rex skeleton in a
paleonthology museum? I have nothing but 2.95.x on my Linux CDs (got in the
last 12 months). If you want to hurt yourself, you can even get 2.96 from
RedHat 7! In my experience, 2.95.2 if MUCH better than MSVC6 SP3 w.r.t.
language conformance (not in optimization, sadly there MS still rules).

Alessandro Coppo
a.c### [at] iolit

Post a reply to this message

In article <3aad57ab$1@news.povray.org> , "Alessandro Coppo" 
<a.c### [at] iolit> wrote:

> Where did you manage to get gcc 2.72 ? Next to a T.Rex skeleton in a
> paleonthology museum? I have nothing but 2.95.x on my Linux CDs (got in the
> last 12 months). If you want to hurt yourself, you can even get 2.96 from
> RedHat 7! In my experience, 2.95.2 if MUCH better than MSVC6 SP3 w.r.t.
> language conformance (not in optimization, sadly there MS still rules).

Some systems are setup once and then let alone.  Besides it compiles all
C programs without problems.  I can access it on a close to
decommissioning cluster of SGI workstations at university.  The nice
thing is to have a account on the cluster which is rarely used by anyone
else, the downside is that it had been replaced two years ago and not
upgraded for another two before that.  Another system (not at
university) I use from time to time also had 2.72 until about half a
year ago.


     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

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3aaced70$1@news.povray.org...
<snippage>

    You made a lot of good points about the STL, none of which I disagree
with, but, I still don't get it:

    1. Why, if you use the STL all the time, are you so anti-STL ?
    2. This ivory tower mentality confuses me :
        Firstly, there are a large number of very talented programmers
putting a lot of their own spare time into POV patches, patches which are
now being used to enrich POVs official feature list, surely tapping some of
this talent could only be of benefit to POV ?
        Secondly, how can you design POV 4.0 without first considering
factors such as these and wouldn't public discussion of said factors
actually aid the POV-team - by providing you with pointers to the
information relevent to that consideration - how can any discussion ever be
'premature' ?

>
> NOTE: Opinions expressed are my own and do not necessarily reflect those
> of the POV-Team.
>

    Is this a standard .sig style include ? If not, I'm curious as to why
you wrote it, considering the number of times you used "we", in the post.

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

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

> 1. Why, if you use the STL all the time, are you so anti-STL ?

I am not anti-STL*.  It is just that I have seen so many problems when I
used straight-forward simple features of it with more than one compiler.
I think in its current state it is a perfect solution if you have a good
compiler with nearly complete STL support and you don't need
cross-platform code.  But I also think that it is not up to the task of
massive platform independent development yet.  Wait five years, and it
will hopefully no longer be a problem.

>     2. This ivory tower mentality confuses me :
>         Firstly, there are a large number of very talented programmers
> putting a lot of their own spare time into POV patches, patches which are
> now being used to enrich POVs official feature list, surely tapping some of
> this talent could only be of benefit to POV ?

Yes, it could.  I have to admit that my statement portrays an "ivory
tower mentality", but I simply want to avoid certain (in my opinion well
justified) statements that would offend too many people.  In short, some
of the patches, even some bigger ones are incomplete, quick hacks and
nothing more.  Lets leave it at this, please.

>         Secondly, how can you design POV 4.0 without first considering
> factors such as these and wouldn't public discussion of said factors
> actually aid the POV-team - by providing you with pointers to the
> information relevent to that consideration - how can any discussion ever be
> 'premature' ?

Well, you don't plan a house by designing its basement and then consider
the other floors' layout, do you?  Once there is a design of the high
level classes it is easy to decide which containers are actually
needed.  Then one can take a look at STL and see if the needed
containers can be used.  If not, then another solution will be found.

>> NOTE: Opinions expressed are my own and do not necessarily reflect those
>> of the POV-Team.
>
>     Is this a standard .sig style include ? If not, I'm curious as to why
> you wrote it, considering the number of times you used "we", in the post.

No, it is not a standard signature.  The "we" is used only when I refer
to public statements of the team.  Also, when talking about fixing code,
saying "I" does not really make sense.  All other use is unintentional
and that is why I add the disclaimer.


    Thorsten


NOTE: Opinions expressed are my own and do not necessarily reflect those
of the POV-Team.


* The rewritten Mac frontend for 3.5, for example, is based on a lot of
STL containers.  Right now the code is under 40K lines / 470KB compiled,
which is small compared to the about 25K lines / 150KB compiled of the
old frontend considering the many new features it offers.  Such compact
source code would not be possible without the STL, and the compiled size
gives a good idea exactly how much the complexity the STL hides (these
stats count only the size of compiled code, excluding libraries and
data).


____________________________________________________
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 Tue, 13 Mar 2001 00:03:40 +0100, "Alessandro Coppo"
<a.c### [at] iolit> wrote:

>Where did you manage to get gcc 2.72 ? Next to a T.Rex skeleton in a
>paleonthology museum? I have nothing but 2.95.x on my Linux CDs (got in the
>last 12 months). If you want to hurt yourself, you can even get 2.96 from
>RedHat 7! In my experience, 2.95.2 if MUCH better than MSVC6 SP3 w.r.t.
>language conformance (not in optimization, sadly there MS still rules).

Maybe it does for Intel platforms. On a K6III, gcc with -O9 does a
much better job than MSVC 6 in terms of speed.

Admittedly, the program used for speed comparisons was a mem hog (ate
up about 150 megs, granted -- without any swapping as I have 192 RAM)
and the speed increase might be due to the better memory management in
Linux. Still, 5-10% is quite good.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message