why does const not work on pointed objects?

[Jeff Schwab]

Re: why does const not work on pointed objects?

Corno wrote:[color=blue][color=green]
>>I assume the OP is referring to something like the following:
>>
>>#include <string>
>>
>>struct foo
>>{
>> void bar() const
>> {
>> data = "hello"; // not allowed
>> }
>> std::string data;
>>};
>>
>>struct foo2
>>{
>> void bar() const
>> {
>> *data = "hello"; // allowed
>> }
>> std::string* data;
>>};
>>
>>In which case, I assume the OP's point is that the fact that 'data' is
>>held via a pointer makes it no less part of the object's data, so why
>>should you get non-const access to it from a const member function?[/color]
>
>
> so the value of using const in a public member function of a class (it's
> interface) is changed for me.[/color]

Then you had it wrong all along. The language never guaranteed that
const objects wouldn't change. The "const" keyword is mostly a hint
from one programmer to another that an object may be treated as though
it will not change. The language does not enforce const-ness.
[color=blue]
> It's no guarantee to the user that nothing will change; it imposes a IMHO
> strange restriction on the implementation; a part of the related data of an
> instance, eg, only the direct member data is not allowed to change. But as
> the example above shows, the same behaviour of the class can be implemented
> in another way (which is not a hack to me) that is not hindered by const.
> The only thing it does is that it creates 2 interfaces to the same class,[/color]

They're not the same class.
[color=blue]
> it
> makes a distinction between all users into 2 groups; users that have full
> access to all the member functions and users that can only use the const
> functions (either or not really const).[/color]

Nonsense. The functionality you want is easily implemented per Dylan's
excellent suggestion.

If it didn't sound so stupid, I'd pull out one of those platitudes about
"the spirit of the language." ;)

[Corno]

Re: why does const not work on pointed objects?

>[color=blue]
> Then you had it wrong all along. The language never guaranteed that
> const objects wouldn't change. The "const" keyword is mostly a hint
> from one programmer to another that an object may be treated as though
> it will not change. The language does not enforce const-ness.[/color]

Thank you for this information, that makes things a bit more clear!

Corno

[Carl Muller]

Re: why does const not work on pointed objects?

"Corno" <corno@%spam%.d ds.nl> wrote in message news:<c0a60l$bd d$1@reader08.wx s.nl>...[color=blue][color=green]
> >
> > I think the point is that any relationship that exists between two classes
> > is imposed by you. Since you are writing the code it is your[/color]
> responsibility[color=green]
> > to get the relationship right, not the language's. In the case you quote[/color]
> its[color=green]
> > not difficult.
> >[/color]
> In that case you could throw out the whole const keyword;
> "it's your responsibility to write correct code" ;)[/color]

Some of us don't have vast quantities of RAM like PC coders have
though... tables are customarily declared const so they can go into
ROM instead of chewing up precious RAM. Of course this also makes
"mutable" a sore point at runtime :-)

[tom_usenet]

Re: why does const not work on pointed objects?

On Tue, 10 Feb 2004 07:22:25 -0500, Jeff Schwab <jeffplus@comca st.net>
wrote:
[color=blue][color=green]
>> so the value of using const in a public member function of a class (it's
>> interface) is changed for me.[/color]
>
>Then you had it wrong all along. The language never guaranteed that
>const objects wouldn't change. The "const" keyword is mostly a hint
>from one programmer to another that an object may be treated as though
>it will not change. The language does not enforce const-ness.[/color]

The language enforces const-correctness for a reasonably logical
definition of that concept (ignoring const_cast and mutable for now).

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[John Harrison]

Re: why does const not work on pointed objects?


"Corno" <corno@%spam%.d ds.nl> wrote in message
news:c0aadt$g9n $1@reader08.wxs .nl...[color=blue]
>[color=green]
> >
> > I see mutable as being used for cached values and the like, not for
> > expressing the relationship between classes, which is far too complex to[/color]
> be[color=green]
> > captured in a single concept like mutable. Just attend some OO design
> > classes if you don't believe me!
> >[/color]
> You are correct, 'mutable' is not an elegant 'keyword' for such a[/color]
situation[color=blue]
> However, backtracking on your previous example about the Block not being
> mutated when moved;
> I would have to disagree. To me, moving the block mutates it as well so[/color]
the[color=blue]
> function should not be const.
> For me, it would be more logical if 'const' would guarantee that it would
> not change the state of the 'model'.
>
> Corno
>[/color]

So you see const as pertaining to the entire world being modelled not to the
individual object? Its a point of view, but I don't think you're going to
find much agreement.

You're seeing object relationships entirely in terms of what is called
aggregation (by some people, the terminology varies). The fact that one
object has a pointer to another object is just an implementation detail
(like your pimpl example). The pointer and the pointee are really one
conceptual object, living and dieing and being const together.

Nothing wrong with aggregation but object relationships can be more complex
and more subtle.

john

[Jeff Schwab]

Re: why does const not work on pointed objects?

tom_usenet wrote:[color=blue]
> On Tue, 10 Feb 2004 07:22:25 -0500, Jeff Schwab <jeffplus@comca st.net>
> wrote:
>
>[color=green][color=darkred]
>>>so the value of using const in a public member function of a class (it's
>>>interface) is changed for me.[/color]
>>
>>Then you had it wrong all along. The language never guaranteed that
>>const objects wouldn't change. The "const" keyword is mostly a hint[/color]
>[color=green]
>>from one programmer to another that an object may be treated as though[/color]
>[color=green]
>>it will not change. The language does not enforce const-ness.[/color]
>
>
> The language enforces const-correctness for a reasonably logical
> definition of that concept (ignoring const_cast and mutable for now).[/color]

Agreed. Changing the definition of that concept, e.g. to provide "deep
constness" by default (as the OP suggested), would risk the loss of the
"reasonably logical" property. I won't say that other definitions would
be "wrong," just different in a potentially misleading way.