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