Re: [Plib-devel] PLIB developers needed.

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

Steve Baker wrote:
> 
>  I tried to compile PLIB on an SGI machine at work - and your 'const-ification' of the clock
> routine stopped it from compiling on the IRIX compiler.
> 
> You had:
> 
>   class ulClock
>   {
>     ...
>     public:
>       ...
>       int getSomething () const { return something ; }
>       ...
>    } ;
> 
> The 'const' seemed to do *bad* things to the SGI compiler.
> 
> Could you remind me what exactly a 'const' right there actually *does*?

Others have already answered that, but I think one point is missing:

This const tells the compiler that ulClock won't be changed by calling
getSomething().

That can cause performance benefits as the compiler can optimize better.
It could e.g. inline that function.
It's also very good for the structure of the code as it prevents any
unwanted access to the data. 
So you can get the excessive type checking at compile time and no subtle
bugs during run time. This gets extremely important when you are using
pointers.
 
> ...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.

It's *very* important for a library to be const correct! There might be
const correct programs that want to use the library.
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.

As I was writing a const correct FGFS extension (BalloonSim IIRC) it
wouldn't compile as I was heavily using SG. I had the choice to cast all
the consts away or make SG const correct. I did the later (and thus had
to fix half of SSG) as there's no point i casting the consts away. Why
should I use them otherwise?

CU,
Christian

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.