On Mon, 07 Jan 2002, sjbaker1@... (Steve Baker) wrote:
> Date: Mon, 07 Jan 2002 22:40:46 -0600
> To: Bernie Bright <bbright@...>
> From: sjbaker1@... (Steve Baker)
> CC: plib-devel@...
> Reply-To: sjbaker1@...
> Subject: Re: [Plib-devel] Const member functions
[...]
> Huh! You're right. I'm utterly amazed.
>
> Stripping this to the bare bones:
>
> #include <stdio.h>
>
> class A
> {
> public:
> char *getStringValue ( void ) { printf ( "no-const\n" ) ; }
> char *getStringValue ( void ) const { printf ( "const\n" ) ; }
> } ;
>
> int main ()
> {
> A b ;
>
> b.getStringValue() ;
> }
>
> ....this prints "no-const". But how does the compiler know what to do?
Stop !
You guys are confusing const member functions and const *pointers* again !
The getValue () kind of routines can't be made const since they *do* modify
their object when they sync the widget's value with the valuator.
The code above is perfectly valid and g++ is smart enough to auto-decide
whether to use the const version or not -
((const A*)&b) -> getStringValue () ;
prints "const" - but I am still somewhat unsure about why the non-const one
is used by default, but again, this is not what we were talking about !
The suggestion by Bernie was to do:
char *getStringValue ( void ) ;
const char *getStringValue ( void ) ;
Which does not compile since overloading by return values does not work in
C++ like Steve explained.
The point is that a member function declared 'const' has a different
prototype than a non-const one, that's why it is valid to have two class
member functions with the same name taking the same kind of parameters,
even with different return types, if you declare one const and the other
one non-const - however, this is very inellegant and I am not sure how
other compilers than g++ behave.
> If I leave off
> the 'const' on the second definition, it doesn't compile (well, Duh!).
Yes.
> Why does the compiler choose the version of the function that potentially
> changes the underlying structure over the one that doesn't?
I don't know. It might be intresting how windows compilers behave or what
the ANSI standard says on this.
> So under what circumstances does the compiler call the second function?
See above - for example:
((const A*)&b) -> getStringValue () ;
But in order to direct the discussion to what it initially was about again:
The question was whether to *return* a const *pointer* - please forget
about making the getStringValue () const again. It does not work unless we
change that valuator handling code.
Since overloading by return types is not possible, Julian suggested to do:
const char * puValue::getStringValue ( void ) ;
char * puValue::getWriteableStringValue ( void ) ;
However, I really can't see any advantage by doing so.
Again, I don't think it is a good idea to break applications that are not
const-correct. We should not force people to write const-correct code,
although it is generally a good idea.
Secondly, I can't see any advantage by this at all. We decided that we *do*
want to give the programmer direct access to the widet's string buffer for
various reasons, and there is nothing you can do with a const pointer that
you can't with a non-const one, so why have two getter functions ?
- Sebastian
|