Re: [Plib-devel] PLIB developers needed.
Brought to you by:
sjbaker
Menu
▾
▴
Re: [Plib-devel] PLIB developers needed.
|
From: Steve B. <sjb...@ai...> - 2000-08-12 19:11:16
|
Christian Mayer wrote:
> > 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.
You misunderstand - none of my code has entered the compiler at that point.
The source file says something like:
#include <stdio.h>
#include <plib/ul.h>
...more stuff...
..and the compiler barfs inside plib/ul.h when I remove the const from
within the function definitions....
int getWhatever () const { return whatever ; }
^^^^^
here
...it compiles and runs just fine.
> 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.
It's not a matter of guilt. Putting a 'const' right there is OK in
sufficiently modern C++ compilers - it fails in older ones though - so
we can't use that construct and remain 'sufficiently' portable.
> > 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.
It is - but not *there*.
const float pi = 3.14159 ; -- OK
int func ( const int &x ) ; -- OK
int getWhatever () const { return whatever; } -- NOT OK
> But anyway, do SG and SSG brake with that compiler?
This program only happened to use UL...but SG and SSG don't (AFAIK)
use const in *that* context.
> If the answer is no,
> that is compiler supporting costs. SG *is* const correct and at least
> half of SSG (IIRC).
Well - not exactly. The number of places where the keyword 'const' can
be stuck has grown steadily over the life of C++ - and some of the later
ones simply aren't universally supported.
> No matter where it compiles. As soon as it doesn't compile on one
> (reasonable) system make it intolerable.
Exactly...unfortunately.
> 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.
I don't really want to ban them all - just that particular usage (and
any others that we might find will break compilation on important
platforms).
One might argue about what platforms are important enough to warrent
dumping language features that are useful. However, IRIX is defined as
'important' because (selfishly) "PLIB is mine and I use IRIX"
:-)
If a similar question came up about compiling for (say) AmigaOS - the
answer *might* be different!
Personally, I think a minimal supportable OS set for PLIB is:
Windoze (all versions NT/95 and later (except possibly, Wince) - using
at least MSVC++, Borland and Cygwin)
Linux (2.0.0 and later)
BeOS (?? versions)
BSD (Including NetBSD, FreeBSD, etc)
MacOS (?? versions)
IRIX (6.0 and later)
Solaris (?? versions)
...I'd consider supporting SCO Unix and HPUX also...but if we had to make
significant language restrictions to make that work, I'd want to think twice
about *that* decision.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
