Re: [Plib-devel] PLIB developers needed.

[<Va...@t-...>]

Steve Baker wrote:
> 
> Christian Mayer wrote:
> 
> > > ...and then remove them anyway!
> >
> > I doubt that there is a need to remove it. There is a need for the other
> > code to be made const consistent.
> 
> BUT IT DOESN'T COMPILE ON AT LEAST ONE C++ IMPLEMENTATION.

Chill down. Nobody says that you should brake (or mustn't fix) a
compilation, just because it's correct that way.

I just wanted to say that we should cure the source of the problem and
not the symptoms.

When it comes to consts everyone is tempted to do that.

> > It's *very* important for a library to be const correct!
> 
> It's **MUCH** more important that it **COMPILE**!

I was assuming that it compiles. Otherwise it shouldn't be published...
(I know the limitations of that when it comes to protable code, etc.)

> > But as soon as a const correct program wants to use non const correct
> > functions it's very likely that the compilation brakes.
> > The other way round usually works.
> 
> It didn't even get through the ul.h header.  There was no other code
> involved apart from standard UNIX headers prior to that point. Also,
> the program compiles just fine under Linux - so there isn't
> anything wrong with my code.

Just that it compiles under one system doesn't say that there's nothing
wrong with it.

I don't know what causes it (I don't know any of the affected code). So
it might be your code or it might be the code in the ul.h or perhaps
even something totally different. I don't know it. So I'm not saying
who's guilty.

> We are looking at a use of 'const' that is in a more recent C++ spec
> than IRIX supports (this is just like the declaration-inside-a-for-loop
> issue for MSVC).
> 
> If we want our code to be portable, we have to forgo some of the
> fancier features of C++ in order to get through the lowest-common-denominator
> of all C++ compilers.

I allways thought that const was one of the most basic C++ features.

But anyway, do SG and SSG brake with that compiler? If the answer is no,
that is compiler supporting costs. SG *is* const correct and at least
half of SSG (IIRC).

> > PS: const correctness is quite easy to understand once you tried. (Steve
> > it shouldn't take you more than 10 minutes). After you've used it a few
> > times (with paying full attention) it comes automatically.
> 
> OK - I understand - that's not the point.  A program that compiles
> just fine under Linux/g++ doesn't compile under IRIX/C++ - and that's
> utterly intolerable.

No matter where it compiles. As soon as it doesn't compile on one
(reasonable) system make it intolerable.

> Am I supposed to be somehow consoled that although my program is
> completely unusable, it's wonderfully const-correct.  NO!  Const
> is a very small part of making programs that work - I've managed
> to write and debug millions of lines of code without it.

Of course.

But you can't cry and say 'ban all consts' just because you trip over
one that doesn't work - w/o really knowing if it's the const that causes
the problem or if its breaking the compiler just because the real
problem (probably a forgotten const) stays unnoticed.

> Programming is a practical skill - it's all about getting a job done.
> A feature that prevents me from compiling is infinitely worse than
> the teeny-tiny *theoretical* bug it's trying to correct.

It's not only about bugs. It's also about structure, performance and
probably other thing, too.

> Portability is more important to PLIB than const-correctness.

Definitely. But why shouldn't we try to get both?

CU,
Christian