is const correctness a dogma ?

77 просмотров
Перейти к первому непрочитанному сообщению

Andrea Griffini

не прочитано,
5 дек. 2002 г., 15:53:5105.12.2002
Hello...

I found myself in a quite blaspheme position of
wondering how much in my personal experience
const-correctness really helped me, and how much
did it cost me.

I'm not questioning if the const-correctness concept is
consistent or correctly captured by the C++ syntax (that
could be another interesting discussion), but only if
on the field it actually pays off.
IMO a software shouldn't represent all aspects of a
problem, but only aspects for which the description and
handling cost is justified by a return.

In this very moment I try to think to a single case
in which const-correctness helped me, saving me
from writing a logically inconsistent statement (of
course saving from a logically inconsistent statement
in which the logical error only is inherent
const-correctness doesn't count as a case).

Oddly enough my selective memory doesn't bring a single
case... I'm not telling it's rare... I can't actually
remember just one very single case in which a
const-correctness-related error message was useful
to anything else than const-correctness itself.

Other than me there's the compiler... after all const
correctness add details to the specifications of what
is being implemented. However const correctness of
references and pointers is never an help to a compiler
in C++, as only binds the reference and the pointer,
not the object, and it's perfectly legal to force that
aspect (and compilers are required to be paranoid on
this possibility). Note that I'm talking about const
correctness, not constness of objects that surely
help a lot both compilers and programmers.
I know many thinks the opposite on this point... for
a description of this aspect from a more recognized
voice see http://www.gotw.ca/gotw/081.htm

Hence so far in my experience the return value is a
desolate zero. No help for me, no help for the code
generator.

On the other side IMO the cost of const-correctness is
high... actully I would say very high.
Description gets more complex, with more cases.
In a few areas you get into serious trouble (iterators).
You get added freedom (calling a method with a reference
may open a window, calling it with a const reference
can save a file), but i'm not sure this is good.
Makes the language harder to teach (that's also because
of powerful but complex C declaration syntax, I know,
but a justification doesn't make it easier).
In my experience since the introduction of STL is probably
the source of most substantially useless (remember I'm
not counting useful a message about const-correctness
itself) and cryptic error messages.
I suppose its cost is relatively high in compilers too
(just a gut suspect, however; I never wrote a compiler
supporting the const correctness concept) and in libraries.

Do people here more expert than me (I seriously approached
C++ only a few years ago) have a very different view on
this ? May be const correctness has been found helping
in very large software projects with a large number of
programers ? That's a world I don't have any experience in.

I'm not looking for a description of why in theory it's
an help, but on when it actually helped in developing
complex software. Here we're going to start with a kind
of big C++ software project, and I'm not sure if insiting
on const correctness is a good thing or if we should just try
to learn how to get our code compiled by annoying compilers.
Just going for const correctness is of course the easy
choice (and no one could probably blame me for proposing
that); but is it really a *proven* good choice ?

A somewhat confused Andrea

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

Emily Winch

не прочитано,
5 дек. 2002 г., 19:10:3405.12.2002
Andrea Griffini wrote:

> Do people here more expert than me (I seriously approached
> C++ only a few years ago) have a very different view on
> this ? May be const correctness has been found helping
> in very large software projects with a large number of
> programers ? That's a world I don't have any experience in.

"More expert than you" is unlikely, but yes, I find const-correctness
helpful. The most obvious way it is helpful is simply in communication
of intent.

If I'm reading a piece of unfamiliar code and trying to work out what it

does, a lot of my effort is concentrated on working out, for each
variable I see, what things affect the value of that variable. If the
variable is global, I'm screwed. If the variable is local, and declared
half-way down the function instead of the top, I have to inspect half a
function. But if it's const, that cuts out all the code but one line.

Thus, the more variables I can make const the better, which is why I
swear at code involving member functions I want to use that could be
const but aren't.

Emily.

Tom Plunket

не прочитано,
6 дек. 2002 г., 12:58:0206.12.2002
Andrea Griffini wrote:

> Other than me there's the compiler... after all const
> correctness add details to the specifications of what
> is being implemented.

Details details details. The more details the better, because
then intent is clearer.

Making methods const means that one can call a method on the
object and know[1] that the object's state isn't going to change.
Functions taking const references are nice because then you can
call a function and know that your object isn't going to change.
This also necessitates the constness of member functions.

So I don't know that constness helps me program correctly, but it
helps me know what to expect when working with other people,
passing my objects to them or calling their methods.

> Hence so far in my experience the return value is a
> desolate zero. No help for me, no help for the code
> generator.

Are you working with others? Do they attempt to code with const-
correctness in mind? Just curious, but I am a dogmatic in this
one; I make everything const that I can and cry when I need to
make things non-const. It just feels nice to have a const object
that you can know isn't going to change.

> I'm not looking for a description of why in theory it's
> an help, but on when it actually helped in developing
> complex software.

Yeah I couldn't say that it's necessarily made the code any
better, but it does help the piece-of-mind. :)


[1] - Except in the case of mutable members, but those changes
shouldn't be visible from the outside.
-tom!

James Kanze

не прочитано,
6 дек. 2002 г., 13:12:2406.12.2002
agr...@tin.it (Andrea Griffini) wrote in message
news:<3deee55...@news.tin.it>...

> I found myself in a quite blaspheme position of wondering how much in
> my personal experience const-correctness really helped me, and how
> much did it cost me.

The question is somewhat ambiguous. Given the language specification,
you are almost required to be const correct in a number of situations; a
temporary will only bind to a const reference, not to a non-const one.
So if you write T& as the type of a parameter, the client code cannot
pass a temporary to the function. Given that, coherency then argues for
being const correct everywhere. So you don't have a choice.

If the question is rather, why is the language so defined to require
this, the answer is that it the alternative was tried, and found to be
error prone. My intuitive feeling (read: I really don't know what I'm
talking about, but I'm going to say it anyway) is that this (the error
prone-ness) is really only true when implicit conversions are involved.
If your code only uses user defined types with no implicit conversions
(which is the case for most of my code), the restriction that you cannt
bind a temporary to a non-const reference is more a problem than a
solution. The experience which led to the contrary conclusion was from
the earlier days of C++. I suspect that use of built-in types was much
more frequent then, and they certainly didn't have explicit to prevent
implicit conversions to user defined types. Times change, and what was
(probably correctly) felt to be necessary then may be more of a problem
now.

In my own code, I insist on 100% const correctness for value objects;
anything less, and I consider the code incorrect. For entity objects
(where I'm only passing pointers or references to explicitly created
objects), I'm much less careful. I generally strive for const
correctness on the grounds of orthogonality, but I don't worry about it
if I miss a function or two, and anytime I'm unsure of the long term
evolution of the function, I'll drop the const, even if the function
could currently use it.

And of course, I do what is necessary when working with an existing code
base. In the project I'm currently working on, const was pretty much
ignored in the entity objects. I do likewise, because making just one
part of the program const correct is a pain, and doesn't work. If I
declare my function to take a const reference to an object, because it
doesn't change the value of the object, I'm suddenly stuck that I cannot
call logically const functions on the object in my function, because
logically const or not, they weren't declared const in the existing
code. So the code is not const correct. I don't let it bother me.

--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung

Ken Hagan

не прочитано,
6 дек. 2002 г., 14:41:3506.12.2002
"Andrea Griffini" <agr...@tin.it> wrote...

>
> Hence so far in my experience the return value is a
> desolate zero. No help for me, no help for the code
> generator.
>
> On the other side IMO the cost of const-correctness is
> high... actully I would say very high.

Surely these statements are inconsistent. The cost can only be high if
we are faced with a lot of code that isn't const-correct. Since the
standard library is already correct, and operating system headers are
mostly correct, and after so many years of const in the language I
presume that even legacy code is mostly correct, that implies that
someone is churning out non-correct source code.

It's probably me. I'm a lousy typist. Fortunately, const lets the
compiler correct most instances of that particular kind of typo. Perhaps
you have lived with const for so long that you can no longer even think
the kind of mistake that it saves the rest of us from making. I'm sure
people have argued that modern compilers no longer benefit from
structured control and so we should all go back to using "goto". Perfect
programmers probably could.

Randy Maddox

не прочитано,
7 дек. 2002 г., 00:22:4507.12.2002
agr...@tin.it (Andrea Griffini) wrote in message
news:<3deee55...@news.tin.it>...
> Hello...
>
> I found myself in a quite blaspheme position of
> wondering how much in my personal experience
> const-correctness really helped me, and how much
> did it cost me.
>
> A somewhat confused Andrea
>

What about the case where you are passing something by reference to
avoid copy costs? In this situation it is very helpful to be able to
differentiate code which may change that something from code which may
not. The cost is only to type const in the parameter list. The
benefit is that both the caller and the compiler know the intent, and
the compiler can help enforce that intent. Any time you can express
your intent in a way that the compiler can enforce it is more likely
that your intent will not be violated. Not impossible, of course, but
definitely less likely.

Simple example: You have a sequence of records read from a database.
You can grant multiple threads read-only, i.e., const, access to this
sequence, but only const will tell you if this is safe or not.

Another simple example: You have a class that returns a pointer or
reference to some internal data. Without const that class cannot know
whether the caller who obtains the pointer or reference will modify
that data or not. It can be both safe and appropriate to allow
external read access to internal data, but allowing external write
access to internal data can be much messier and harder to justify.
Without const how would you deal with this situation?

Finally, const allows the compiler to make assumptions that it
otherwise could not. If you pass a pointer or reference to const to
some function, the compiler, and the optimizer, may assume that
function does not change the object referred to.

Don't blaspheme. const is a very Good Thing! :-)

Randy.

David B. Held

не прочитано,
7 дек. 2002 г., 05:16:4707.12.2002
"Andrea Griffini" <agr...@tin.it> wrote in message
news:3deee55...@news.tin.it...
> [...]

> I found myself in a quite blaspheme position of wondering
> how much in my personal experience const-correctness really
> helped me, and how much did it cost me.

Stone him!

> [...]


> In this very moment I try to think to a single case in which const-
> correctness helped me, saving me from writing a logically
> inconsistent statement (of course saving from a logically
> inconsistent statement in which the logical error only is inherent
> const-correctness doesn't count as a case).

The question is, *do you think about const-correctness when
writing code*? If so, it may simply be that your awareness of
constness is automatic, and so const-correctness is encouraging
a good style of coding to begin with. The compiler warns me if
there is unreachable code. I almost never see this warning. Does
that mean that the effort spent by the compiler vendors to
implement this diagnostic is wasted? No, it just means that I
already write my code in such a way that does not trigger the
diagnostic.

As others have noted, the true test of const-correctness is A)
when you have to use someone else's code, or B) someone else
has to use yours. If you asked other people to use your code,
and it lacked const correctness, you might find them using it in
incorrect ways. Another area where I find const correctness
invaluable is in migrating legacy C code (which often lacks
const correctness in a big way). Since many things are much
less encapsulated in old C code, it is often difficult to tell where
things get changed, and how. I find that it's much easier to
abuse such code unwittingly, because it's too much of a hassle
to find all the places where data can get changed.

Also, if I see a function that I think ought to be const, or have
const params, and it doesn't, I am suprised, and take a closer
look. This is often a warning that the function does not do
what I think it does, or has side effects that I wouldn't expect.
Again, with code you write entirely yourself, this is probably
not an issue. But with library code, or working with someone
else's project, these are very common issues, I think.

> [...]


> In my experience since the introduction of STL is probably
> the source of most substantially useless (remember I'm not
> counting useful a message about const-correctness itself)
> and cryptic error messages.

I think the problem of error messages is independent of const
correctness. And I agree that it's a big and growing problem.
I've seen code that literally generates 5-10 screen fulls of text
for just one error message. I'm aware that there are tools to
cope with that, but it would be nice if compilers integrated
such features directly.

> [...]


> May be const correctness has been found helping in very
> large software projects with a large number of programers ?
> That's a world I don't have any experience in.

> [...]

Even if it's not a large project, if it's a strange project, the
const correctness helps use the code properly. I don't see it
as being any different from data hiding. They are both
compiler-enforced restrictions on how you access data. When
was the last time you got a warning that you were trying to
access private data? Again, that's something that tends to
come automatically, and so if you use it, you don't think about
it. Try writing code that is *not* const-correct, and come back
to it in 6 months and see how you use it. ;)

Dave

Mark Smith

не прочитано,
7 дек. 2002 г., 05:22:4807.12.2002
Reply below...

"Andrea Griffini" <agr...@tin.it> wrote in message
news:3deee55...@news.tin.it...
>

> In this very moment I try to think to a single case
> in which const-correctness helped me, saving me
> from writing a logically inconsistent statement (of
> course saving from a logically inconsistent statement
> in which the logical error only is inherent
> const-correctness doesn't count as a case).
>
> Oddly enough my selective memory doesn't bring a single
> case... I'm not telling it's rare... I can't actually
> remember just one very single case in which a
> const-correctness-related error message was useful
> to anything else than const-correctness itself.

Hello Andrea,
Yes I've had the same experience. Const correctness has added
nothing but hassle to my C++ programs without any visible benefit,
although I guess the compiler might be making use of it for
optimisation purposes?

Programs evolve and change constantly, and the const correctness
handicaps this process by it's insistent ripple-through behaviour.

Another thing that really bothers me is const member functions!
I want to be able to change a classes implementation without altering
its interface, so if a member function that was const, now becomes
non-const, (eg if I add caching) why should clients care? It just breaks
the interface!

So I don't use const member functions, not only are they a hassle to
maintain, they are logically flawed!

I don't suppose anyone agrees do they? :-)

Kind Regards,
Mark Jordan.

llewelly

не прочитано,
7 дек. 2002 г., 10:46:5707.12.2002
agr...@tin.it (Andrea Griffini) writes:

> Hello...
>
> I found myself in a quite blaspheme position of
> wondering how much in my personal experience
> const-correctness really helped me, and how much
> did it cost me.

[snip]

I think it was coding in Java that taught me the value of const Foo*,
const Foo&, etc. While programming in Java I have occasionally
found myself tracking down some bug or other that occured becase I
passed a reference to a function, and that function modified
the referenced object when I didn't expect it.

In 2 different medium-sized C projects that I helped convert to C++, I
saw C++'s stricter const reveal the cause of several long-standing
bugs.

const-correctness also supports design idioms such as COW.

> Do people here more expert than me

[snip]

I think I'm less expert than you are.

> but is it really a *proven* good choice ?

[snip]

I think there is lots of anecdotal evidence. What we don't have is
measuremnts from carefully designed experiments. (So far as I
know, that is.)

Andrea Griffini

не прочитано,
7 дек. 2002 г., 15:10:0807.12.2002
On 6 Dec 2002 14:41:35 -0500, "Ken Hagan" <K.H...@thermoteknix.co.uk>
wrote:

>> On the other side IMO the cost of const-correctness is
>> high... actully I would say very high.
>
>Surely these statements are inconsistent. The cost can only be high if
>we are faced with a lot of code that isn't const-correct.

With more cost I mean that enforcing const-correctness
implies more typing, more thinking, and even duplication
of methods (just to provide a const version that does
basically the same but returns a const-something).
Also const-correctness on things like iterators has
other drawbacks (a const_iterator of course is not a
const iterator, like a pointer to a const is not a const
pointer, but conversion between iterators is way harder
than between pointers, and in some case iterators
- and not const_iterators - are required even when
logically a const_iterator should have been sufficent).

>Perhaps you have lived with const for so long that you
>can no longer even think the kind of mistake that it
>saves the rest of us from making.

Really compiler enforcement of const correctness saved
you from making logical errors ? That never happened
to me... but I can take your word.

I find more reasonable Tom Plunket position that is
that the *reading* of const-correctness related keywords
help humans and make things easier to understand.
Good naming and commenting should do the same, however.

>I'm sure people have argued that modern compilers no
>longer benefit from structured control and so we should
>all go back to using "goto".
>Perfect programmers probably could.

I don't think that structured programming was ever thought
as helping compilers. Actually one of the first things
many optimizing compilers do on your nice structured source
is chopping it in a lot of pieces and drawing a spaghetti
bowl of goto arrows between them.

Stuctured programming and its enforcement by the compiler
is an help for humans.

My doubt about const correctness is that I never found
compiler enforcement being really an help. I'm glad the
compiler informs me I forgot a closed brace or that
the "else" I typed is nonsense ... but when it tells
me that I can't call that method because i've only a
const reference as far as I can remember the error always
was just in const-ness of the parameter or of the method
declaration (and never that I was calling the wrong method
or i was calling it on the wrong object).
In other words I always found const-correctness only
helping const-correctness.

Andrea

Andrea Griffini

не прочитано,
7 дек. 2002 г., 15:15:3007.12.2002
On 6 Dec 2002 12:58:02 -0500, Tom Plunket <to...@fancy.org> wrote:

>So I don't know that constness helps me program correctly, but it
>helps me know what to expect when working with other people,
>passing my objects to them or calling their methods.

That's a good point. Probably discipline with names and
comments should suffice, but I may agree that having
that enforced may help.
In other words const-correctness enforcement helps only
because you're forced to type const-correct comments,
and those are the real value. They help you *before*
you start typing in statements...

> > Hence so far in my experience the return value is a
> > desolate zero. No help for me, no help for the code
> > generator.
>
>Are you working with others? Do they attempt to code with const-
>correctness in mind? Just curious, but I am a dogmatic in this
>one; I make everything const that I can and cry when I need to
>make things non-const.

We're a quite small group, and rarely anyone has to interact
with other people's code, except for a quite specific an
narrow interface. We're also so few that we directly decide
interfaces discussing them and we never discover them
just reading a doc or an header file.
And ... ahem... (blush) no. Most code isn't currently
const-correct at all. The background is C, where you
can just ignore almost completely the issue.

Andrea

Andrea Griffini

не прочитано,
7 дек. 2002 г., 15:20:4607.12.2002
On 7 Dec 2002 00:22:45 -0500, rma...@isicns.com (Randy Maddox) wrote:

>The cost is only to type const in the parameter list. The
>benefit is that both the caller and the compiler know the intent, and
>the compiler can help enforce that intent. Any time you can express
>your intent in a way that the compiler can enforce it is more likely
>that your intent will not be violated. Not impossible, of course, but
>definitely less likely.

This is exactly what I was not sure about.
Communicating or decyphering the intent with
just the part of the .h file that a compiler
understands has never happened to me, as
always there were man pages, comments, a
document or even a talking person describing
me the intent.

After some thought I think that I was missing
this value of const correctness ... and the
compiler enforcing it is in that no different
than a window requiring a dscription of changes
after checking in a module, or requiring
justification after discovering a naming
style violation.

>Without const how would you deal with this situation?

With comments and description ... if I want to.
Or I may have the choice of not doing it if I
don't want to invest that money.

I was also forgetting that ignoring the issue can be
really dangerous if you've conversion constructors
or implicit conversion operators, because copies can
be obtained and passed to functions without intention.
May be const-correctness would have not been so important
for C++ with foresight of implicit conversion problems
and having "explicit" keyword from the beginning.

>Finally, const allows the compiler to make assumptions that it
>otherwise could not. If you pass a pointer or reference to const to
>some function, the compiler, and the optimizer, may assume that
>function does not change the object referred to.

I don't agree... I don't think the optimizer can assume
anything. Remember that a const reference doesn't
tell *anything* about const-ness of the referenced object,
but only about operations allowed using *that* reference:
there may be total or partial aliasing and even const-casting.
So:

- Calling a const method doesn't imply the
object won't change.

- Passing a const reference doesn't mean the
object won't be changed (even if the object
is local and no-one else knows its address...
const-casting is legal and must work if the
referenced object is not a constant object).

- Receiving a const reference doesn't mean
that during the funcion others won't change
the referenced object.

It's perfectly legal receiving in the same function
a const reference A and a non-const pointer B where
B points to a sub-object of A... so after any change
made using B the compiler must consider that A may
have been changed.
Every time any unknown code is executed all objects
referenced by const references you received may
potentially change state... so after every constructor
call for which the definition is not known, even
every call to builtin operators line new or delete
means that all no assumption about referenced object
state is possible.

Andrea

Alf P. Steinbach

не прочитано,
7 дек. 2002 г., 15:21:5807.12.2002
On 5 Dec 2002 15:53:51 -0500, agr...@tin.it (Andrea Griffini) wrote:

>...


>In this very moment I try to think to a single case
>in which const-correctness helped me, saving me
>from writing a logically inconsistent statement (of
>course saving from a logically inconsistent statement
>in which the logical error only is inherent
>const-correctness doesn't count as a case).
>
>Oddly enough my selective memory doesn't bring a single
>case... I'm not telling it's rare... I can't actually
>remember just one very single case in which a
>const-correctness-related error message was useful
>to anything else than const-correctness itself.

>...

It's difficult to be very precise since you do not define
what you mean by "const correctness".

Assuming you're talking about applying the keyword "const",
here are some thoughts:


1) Const variables of simple type.
Always helpful to the programmer and/or the compiler,
and furthermore, failure to apply const (e.g., a "char*"
where there should be "char const*") makes for a very
difficult life. Should be adhered to religiously.
If there *can* be a "const", there *should* be.

2) Const return value for a function.
Generally an abomination (the new wisdom after Mojo).

3) Const methods to support client using const on object.
Sometimes helpful, sometimes not, a bit of a nuisance to
have a const duplicate of all relevant methods. In my
experience it's best to be very pragmatic about this. It
is a language defect at a higher level than mere syntax.

4) Const object that gives access to non-const object.
I've never figured out what's "right" or even "practical"
here. Talking about "const correctness" in this context
is probably futile. Talking about this situation in
general, instead of a single concrete example, is probably
futile at the current time.

5) Object with const non-static data member.
An abomination unless assignment is disallowed, and should
be avoided anyway.


Well, okay, fire up the discussion engines... ;-)

Cheers,

- Alf

Francis Glassborow

не прочитано,
7 дек. 2002 г., 16:36:3407.12.2002
In message <rb6I9.838$qg4.39531@wards>, Mark Smith <nob...@nowhere.com>
writes

>Reply below...
>
>"Andrea Griffini" <agr...@tin.it> wrote in message
>news:3deee55...@news.tin.it...
>>
>> In this very moment I try to think to a single case
>> in which const-correctness helped me, saving me
>> from writing a logically inconsistent statement (of
>> course saving from a logically inconsistent statement
>> in which the logical error only is inherent
>> const-correctness doesn't count as a case).
>>
>> Oddly enough my selective memory doesn't bring a single
>> case... I'm not telling it's rare... I can't actually
>> remember just one very single case in which a
>> const-correctness-related error message was useful
>> to anything else than const-correctness itself.
>
>Hello Andrea,
>Yes I've had the same experience. Const correctness has added
>nothing but hassle to my C++ programs without any visible benefit,
>although I guess the compiler might be making use of it for
>optimisation purposes?

Almost certainly you are still using a C mindset. It is actually almost
impossible to write C++ using the full range of tools provided by the
Standard Library without taking note of const correctness.

The ripple through effect is poison in C because of its lack of function

overloading (functions such as strtok() cannot be implemented in a const

correct form in C) However in C++ the ripple through is exactly what we
want to ensure that we do not abuse data.


>
>Programs evolve and change constantly, and the const correctness
>handicaps this process by it's insistent ripple-through behaviour.

If your code evolves in ways that cause unexpected ripple through of
const then I suspect that there is a problem in the design that the
evolution is addressing.

>
>Another thing that really bothers me is const member functions!
>I want to be able to change a classes implementation without altering
>its interface, so if a member function that was const, now becomes
>non-const, (eg if I add caching) why should clients care? It just
breaks
>the interface!

We have to use the language correctly. A function should not be declared

const simply on the basis that it does not change the object, but on the

basis that it would be conceptually wrong for it to change the logical
state of the object.

Sometimes certain aspects of an object's physical state (such as cached
results) need changing even when the object is being used in a logically

const context. That is what mutable is for.

>
>So I don't use const member functions, not only are they a hassle to
>maintain, they are logically flawed!

No they are not but a misunderstanding of the design concepts may make
it look that way.

>
>I don't suppose anyone agrees do they? :-)

Oh, you will have some agree but I would be amazed if any of those are
among those who are considered to be experts on C++ programming. If you
wish to argue with the likes of Scott Meyers, Herb Sutter, Andy Koenig,
Bjarne Stroustrup etc. you will have to marshall your arguments very
carefully.


--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

Niklas Matthies

не прочитано,
7 дек. 2002 г., 20:30:0507.12.2002
On 2002-12-07 10:22, Mark Smith <nob...@nowhere.com> wrote:
[...]

> Another thing that really bothers me is const member functions!
> I want to be able to change a classes implementation without altering
> its interface, so if a member function that was const, now becomes
> non-const, (eg if I add caching) why should clients care? It just
breaks
> the interface!

That's what 'mutable' is for. If you add caching, the member function is
conceptually still const, i.e. it doesn't change the observable state of
the object.

> So I don't use const member functions, not only are they a hassle to
> maintain, they are logically flawed!

So how do you call member functions on const references?

-- Niklas Matthies

Andrea Griffini

не прочитано,
8 дек. 2002 г., 08:57:3308.12.2002
On 7 Dec 2002 05:16:47 -0500, "David B. Held"
<dh...@codelogicconsulting.com> wrote:

>The question is, *do you think about const-correctness when
>writing code*? If so, it may simply be that your awareness of
>constness is automatic, and so const-correctness is encouraging
>a good style of coding to begin with.

This is a good point on the lines of what Tom Plunket said.

>The compiler warns me if there is unreachable code. I almost
>never see this warning. Does that mean that the effort spent
>by the compiler vendors to implement this diagnostic is wasted?
>No, it just means that I already write my code in such a way
>that does not trigger the diagnostic.

I'm not sure that warning is active with C++ ... a lot
of template trickery ends up in unreachable code.
Another warning on that level is the "not all paths return
a value" ... and actually I'm dubious about that.
The compiler isn't smart enough to understand that in some
cases the missing "path" can never be taken and this
generates spurious warnings on my builds (and they're in
<algorithm>... so I'm a bit reluctant in modifying code
coming with the compiler to fix that). On the other side
I can remember that warning saving me may be only a couple
of times in my life.

Of course may be things are of course different with who
is learning the language or even programming (and was crazy
enough to choose a monster like C++ to learn programming).

>As others have noted, the true test of const-correctness is A)
>when you have to use someone else's code, or B) someone else
>has to use yours. If you asked other people to use your code,
>and it lacked const correctness, you might find them using it in
>incorrect ways.

Yeah. As I said in my experience I was lucky enough of
never having just an uncommented ".h" to guide me.

>Another area where I find const correctness invaluable is in
>migrating legacy C code (which often lacks const correctness
>in a big way).

In C you can simply ignore the issue and all your code
will probably compile fine. Things with C++ are different
because of temporaries.

>Since many things are much less encapsulated in old C code,
>it is often difficult to tell where things get changed, and how.
>I find that it's much easier to abuse such code unwittingly,
>because it's too much of a hassle to find all the places where
>data can get changed.

True... but is this really related to const-correctness ?
I would say no.

>Also, if I see a function that I think ought to be const, or have
>const params, and it doesn't, I am suprised, and take a closer
>look. This is often a warning that the function does not do
>what I think it does, or has side effects that I wouldn't expect.

Or that the prototype was simply wrong about that
issue. No const correctness and it would have been
correct and you wouldn't have spent time on that.
In my experience this is the most frequent case.

>I think the problem of error messages is independent of const
>correctness. And I agree that it's a big and growing problem.

STL error messages are a known problem... and a few
solutions are facing. I was trying to say that most often
when I make such an error it's something related to
const-correctness. Things get tricky with const-correctness
and iterators.

Note that there are parts of STL I really don't use... so
may be that the fact that most errors are const-correctness
related in my experience is skewed by the fact that I'm
not fighting with binders and their friends.

>Even if it's not a large project, if it's a strange project, the
>const correctness helps use the code properly. I don't see it
>as being any different from data hiding.

Ok... you brought this out. My very first C++ real project
was a 50+Klines module for our CAD/CAM system. It uses just
a subset of C++ that I found later described as "C with classes"
and (please don't scream) everything is public! Moreover,
honestly, I didn't find the need for making things private.
I wrote it myself alone... so probably this doesn't count.

>They are both
>compiler-enforced restrictions on how you access data. When
>was the last time you got a warning that you were trying to
>access private data? Again, that's something that tends to
>come automatically, and so if you use it, you don't think about
>it. Try writing code that is *not* const-correct, and come back
>to it in 6 months and see how you use it. ;)

Hmmm. I think you're right on this. Adding data hiding to
that project now is probably a suicide.
In the begining everything is clean ad nice even without
compiler enforcement... but as you get near the result
and deadlines are approaching the temptation is high,
especially (this is what I've read) if you're working alone.

I think I'll try making what should be private actually
private on that project... just to have some laugh on
the number of errors the build will generate :)

Andrea

Andrea Griffini

не прочитано,
8 дек. 2002 г., 09:00:2708.12.2002
On 7 Dec 2002 05:22:48 -0500, "Mark Smith" <nob...@nowhere.com> wrote:

>although I guess the compiler might be making use of it for
>optimisation purposes?

No. Const-correctness can never help the optimizer.
The reasons are the presence of aliasing (and no
available method to inform the compiler that
aliasing should not be considered) and the fact
that casting away const-ness from a reference is
perfectly legal and must be supported.

>Programs evolve and change constantly, and the const correctness
>handicaps this process by it's insistent ripple-through behaviour.

This is something I've heard and on which I agree...
trying to add const-correctness late is terribly costly.
Our projects now don't consider const correctness beyond
what you're forced to by the language... I was wondering
if would be better for us to steer on what is in current
literature The Right Thing for *next* project.

I'm quite positive it's not a good idea to invest in fixing
const-correctness on current ones.

>Another thing that really bothers me is const member functions!
>I want to be able to change a classes implementation without altering
>its interface, so if a member function that was const, now becomes
>non-const, (eg if I add caching) why should clients care? It just breaks
>the interface!

This is the same that James Kanze said... sometimes updating
a method changes it from being const to being non-const
and this breaks a lot of existing code.
This never happened to me, but I can imagine such a situation.

I wonder if anyone used with C++ the approach described in
Object Oriented Software Construction of having only queries
(not changing the state and returning a value) and commands
(not returning a value but changing the state). That approach
looks even more stringent than const or non-const and is
more a directive on how to build interfaces (like structure
programming forces you in the way you can use jumps)...

C++ const-correctness doesn't gives you a direction... looks
like just an exercise in attention. Other parts of C++ give me
the same impression... like when I've to type

for(std::map<std::string,int>::const_iterator i=m.begin(),e=m.end();
i!=e; ++i)
...

instead of

for(m::const_iterator i=m.begin(),e=m.end(); i!=e; ++i)
...

This IMO is a typical case in which no real thinking is required,
and just a possibility of an annoying meaningless error is added.

Redudancy isn't always bad, of course. For example requiring
you to fill in your account number AND your name AND your
address when making a deposit is a security... without that
redudancy making an error when reading the account number
would automatically mean redirecting the money on a different
account and that's bad (ok... just for a moment imagine this
is not what indeed happens ;) ).

I just do not happen to remember a single case in which
compiler enforcement of const-correctness or the
necessity of re-entering the whole type actually helped
me in discovering a true logical error.

On the contrary I remember a deposit of mines that took
three weeks to get on my bank account even if cheque
was indeed resulting deposited because probably there
was something wrong either in what I wrote or in what
they read... and all that redundancy (that I thought
being good) was simply ignored.

>So I don't use const member functions, not only are they a hassle to
>maintain, they are logically flawed!
>
>I don't suppose anyone agrees do they? :-)

hey :) ... my position wasn't "const-correctness is a bad joke!",
but "what do you guys really think of const-correctness ?".
It's just a point on which my personal (little) experience
doesn't seem to agree with what I found in the literature.

Don't count me on your side (for now) ;)

Andrea

Hannes Häyrinen

не прочитано,
8 дек. 2002 г., 09:01:0708.12.2002
"Mark Smith" <nob...@nowhere.com> wrote in message news:<rb6I9.838$qg4.39531@wards>...

> Another thing that really bothers me is const member functions!
> I want to be able to change a classes implementation without altering
> its interface, so if a member function that was const, now becomes
> non-const, (eg if I add caching) why should clients care? It just breaks
> the interface!

A const member function can't just suddenly change to a non-const one.
Clients indeed should care if a member function is const or not.
Const assures that the function doesn't change the object (at least as
far as the clients can see it). Adding a cache system to a const function
doesn't really change the object (only speeds it up) so the function
should still be const.

There's a mutable keyword for this purpose. Stick a mutable to your
cache variables and you can then change them inside a const function.

Matthew Collett

не прочитано,
8 дек. 2002 г., 09:03:3308.12.2002
In article <rb6I9.838$qg4.39531@wards>,
"Mark Smith" <nob...@nowhere.com> wrote:

> I want to be able to change a classes implementation without altering
> its interface, so if a member function that was const, now becomes
> non-const, (eg if I add caching) why should clients care?
>

> Mark Jordan.

They shouldn't, which is why the language provides 'mutable' for exactly
this situation.

Best wishes,
Matthew Collett

Bo-Staffan Lankinen

не прочитано,
8 дек. 2002 г., 09:05:5108.12.2002
> And ... ahem... (blush) no. Most code isn't currently
> const-correct at all. The background is C, where you
> can just ignore almost completely the issue.

In your original post you wrote that you couldn't remember a single case in
which const-correctness has helped you. Why do you expect to experience any
benefits from const-correctness if you don't enforce it?

Bo-Staffan

Bo-Staffan Lankinen

не прочитано,
8 дек. 2002 г., 09:06:0908.12.2002
> I don't agree... I don't think the optimizer can assume
> anything. Remember that a const reference doesn't
> tell *anything* about const-ness of the referenced object,
> but only about operations allowed using *that* reference:
> there may be total or partial aliasing and even const-casting.
> So:

I agree with you that the compiler can't assume anything in this case. But
without enforcing const-correctness, it would severely limit the
opportunities to perform optimizations inherent to const objects.

Bo-Staffan

Andy Sawyer

не прочитано,
8 дек. 2002 г., 09:08:1308.12.2002
In article <kBwoGOCW...@robinton.demon.co.uk>,
on 7 Dec 2002 16:36:34 -0500,
Francis Glassborow <francis.g...@ntlworld.com> wrote:

> The ripple through effect is poison in C because of its lack of function
> overloading (functions such as strtok() cannot be implemented in a const
> correct form in C)

Since everything else you say is true, it's a shame you chose strtok
as your example here. 'strtok' is a really, really bad example, since
it CAN (and is) implemented in a const correct form in C. The _only_
const-correct form of strtok is:

char *strtok( char *s1, const char *s2 );

A much better example is strchr, where the additional overload is
necessary for const-correctness.

char *strchr( char *, int );
const char *strchr( const char *, int );

(There are plenty of Other examples - 21.4p4 et. seq. lists a bunch of
them).

Regards,
Andy S.
For the benefit of IST5/-/21 members, I will now scream "stop it,
stop it - you're agreeing with me" :-)
--
"Light thinks it travels faster than anything but it is wrong. No matter
how fast light travels it finds the darkness has always got there first,
and is waiting for it." -- Terry Pratchett, Reaper Man

"Rob Stewart" <robert<dot>stewart<at>bigfoot

не прочитано,
8 дек. 2002 г., 09:09:1608.12.2002
"Andrea Griffini" <agr...@tin.it> wrote in message
news:3df14040...@news.tin.it...

>
> My doubt about const correctness is that I never found
> compiler enforcement being really an help. I'm glad the
> compiler informs me I forgot a closed brace or that
> the "else" I typed is nonsense ... but when it tells
> me that I can't call that method because i've only a
> const reference as far as I can remember the error always
> was just in const-ness of the parameter or of the method
> declaration (and never that I was calling the wrong method
> or i was calling it on the wrong object).
> In other words I always found const-correctness only
> helping const-correctness.

But you're ignoring that const-correctness is a contractual
thing. You declare that a const mf doesn't change the underlying
object -- at least in the logical sense, if not the bitwise
sense. A const formal parameter or variable cannot be changed, by
definition -- unless you choose to cast away constness, of
course. Therefore, you can only use const mfs on const objects in
order to maintain the contract. If you want the option to modify
an object, then it must not be const, in which case you can use
const and non-const mfs on it.

If you don't want to deal with specifying those contracts, for
the compiler to automatically check for you, and instead rely on
the good will and behavior of yourself and other programmers,
then const-correctness will be a hindrance. Personally, I prefer
to have the compiler find my problems rather than wait until the
program misbehaves.

Rob

Andrei Alexandrescu

не прочитано,
8 дек. 2002 г., 09:15:5508.12.2002
"Andrea Griffini" <agr...@tin.it> wrote in message
news:3df14040...@news.tin.it...
> I find more reasonable Tom Plunket position that is
> that the *reading* of const-correctness related keywords
> help humans and make things easier to understand.
> Good naming and commenting should do the same, however.

As a rule, comments that are not enforced by the compiler will rot over
time.

> My doubt about const correctness is that I never found
> compiler enforcement being really an help. I'm glad the
> compiler informs me I forgot a closed brace or that
> the "else" I typed is nonsense ... but when it tells
> me that I can't call that method because i've only a
> const reference as far as I can remember the error always
> was just in const-ness of the parameter or of the method
> declaration (and never that I was calling the wrong method
> or i was calling it on the wrong object).
> In other words I always found const-correctness only
> helping const-correctness.

I have quite an opposite viewpoint. I don't appreciate it when the compiler
nags me about minor obvious syntactic details such as those you mention.
They are so trivial, that even the compiler itself might add suggestions for
fixes to the error message. (I predict this is going to happen in the near
future; many compilers already advise about missing ";" at the end of a
class etc.)

Why would I be thankful or, as you say, "glad" that the compiler informs me
of the little fish? That's like saying, I'm glad that my stove can heat.
Duh! Even the darn *editor* could signal such problems by making those lines
red while editing!

What I'm glad about, is when design or programming errors are revealed as
type errors. (The stove has a mechanism that prevents it from overheating or
causing fire.) This is all what a type system is about.

Talking about 'const' in particular: it has been proven (and applied to
enable the entire field of functional programming) that immutable data
enables better reasoning for both humans and machines. Data that is not
modified after being initialized is much easier to track and reason about.
Even compilers often transform programs into "static single assignment" form
which does not really make all data constant, but enables reasoning about
the flow.

Your observation that const-correctness only helps const-correctness might
derive from the fact that the const qualifier forms cliques. Whenever you
find that the problem is actually something that is const shouldn't, you
move an entity away from the const-clique. Such a move is important and has
many implications; you shouldn't feel very easy about it. The bigger the
const clique is, the better grip you have on your program's state. And it is
of help that the compiler traces these cliques for you.

On a very practical vein, when examining code, it is of great help to see
exactly what data a function changes and what data it does not. (By the way,
there's no conceptual difference between a const method and a function
taking some const argument). This information is invaluable in figuring out
how the state of the program is affected by various function executions.

Also, const is useful for stack data because it simplifies code reading and
understanding. If you see:

const size_t sz = v.size();

you understand at a glance that sz is meant to be a snapshot of v's size for
the rest of the function. If const is not there, sz might change later - and
you need to trace the whole function to figure out what sz is meant to be.

IMHO, not appreciating const is a common error of a design beginner, in the
same way that not appreciating types/indentation/good names/decomposition
are common errors of a programming beginner.


Andrei

Adam Hupp

не прочитано,
8 дек. 2002 г., 11:40:0808.12.2002
On Sat, 07 Dec 2002 05:22:48 +0000, Mark Smith wrote:
>
> Another thing that really bothers me is const member functions!
> I want to be able to change a classes implementation without altering
> its interface, so if a member function that was const, now becomes
> non-const, (eg if I add caching) why should clients care? It just
breaks
> the interface!

That is what the "mutable" modifier is for. Declare your cache variable
mutable and you can modify it in const member functions.

> So I don't use const member functions, not only are they a hassle to
> maintain, they are logically flawed!

> I don't suppose anyone agrees do they? :-)

Nope.

-Adam

Carlos Moreno

не прочитано,
8 дек. 2002 г., 11:40:2608.12.2002

David B. Held wrote:
>

> When
> was the last time you got a warning that you were trying to
> access private data?


<nitpicking>

I don't think anyone has ever seen a compiler warning when
trying to access private data -- in every single compiler
that I've worked with (ever since the days of Borland C++ 3),
that would produce a compiler error.

</nitpicking>

Carlos
--

Dave Harris

не прочитано,
8 дек. 2002 г., 11:41:2008.12.2002
agr...@tin.it (Andrea Griffini) wrote (abridged):

> I wonder if anyone used with C++ the approach described in
> Object Oriented Software Construction of having only queries
> (not changing the state and returning a value) and commands
> (not returning a value but changing the state).

I use it for most things. The exception is commands which need to return

some kind of status to say whether they worked. OOSC seems to recommend
storing the status in an instance variable and using another query to
get
it. Eg:
os.create_file( "filename" );
if (os.created_succeeded())
// ...

I dislike this because it adds more mutable state and I abhor mutable
state.


> I just do not happen to remember a single case in which

> compiler enforcement of const-correctness [...] actually helped


> me in discovering a true logical error.

I have known a few cases like that. They are rare because "const"
reflects
the way I think so there aren't many errors in code the compiler sees.

If I didn't have "const" I would often need to invent it. You will
often see discussion of this in Java groups (Java doesn't have "const").

Consider code like:

Point *p = circle.centre();
p->x += 1;

In Java there is no language-supported way to tell whether changing p
moves the circle it came from. Hence people either perform extra copies
to
ensure there are no side effects, or else they create read-only classes
by
hand.

That said, "const" adds enormous complication to the language, and makes
a
great deal of work for programmers. If I were designing a language I
don't
think I'd bother with it. As far as I know, C++ is the only language
which
does bother.

Much the same could be said of compile-time type-checking in general.
Most
errors which are caught by the static type-checker would be caught
during
testing anyway. I have used BCPL, an untyped language, and I think type
errors there only took around 10% of my debugging time.

Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."

Andrea Griffini

не прочитано,
8 дек. 2002 г., 14:57:5908.12.2002
On 8 Dec 2002 09:05:51 -0500, "Bo-Staffan Lankinen"
<spambo_steffan...@hotmail.com> wrote:

>In your original post you wrote that you couldn't remember a single
case in
>which const-correctness has helped you. Why do you expect to experience
any
>benefits from const-correctness if you don't enforce it?

I tried it with experiments. One experiment I'm working
on is a gui library and a toy image manipluation and video
compression program. No big stuff (less than ten thousands
lines of code) but enough to make me spend some time coding
free from "current practice" chains.

When I say I don't have experience in enforcing const
correctness it I was talking of work projects, where I'm
working with other programmers.
Introducing a new tecnique is a difficult issue... as the
first reaction is often "but we never did that way! and
our way sure works". That's why before spending my face
on something I must be sure there will be a good return.

A few weeks ago I proposed something that's so obvious
that shouldn't require even a discussion: modularization.
Believe it or not even that was hardly accepted... but
now that wonderful approach is really appreciated as
the programmer I discussed with was impressed by how
things gets simpler and easier to maintain if your
project is not just a big bowl of wires connecting
everything with everything else.

That was a really easy bet, of course.

Now I'm looking on where to spend the face I gained ;)

Andrea

Francis Glassborow

не прочитано,
8 дек. 2002 г., 17:14:1808.12.2002
In message <astn4f$ujvpl$1...@ID-47792.news.dfncis.de>, Bo-Staffan Lankinen
<spambo_steffan...@hotmail.com> writes

> > And ... ahem... (blush) no. Most code isn't currently
> > const-correct at all. The background is C, where you
> > can just ignore almost completely the issue.
>
>In your original post you wrote that you couldn't remember a single case in
>which const-correctness has helped you. Why do you expect to experience any
>benefits from const-correctness if you don't enforce it?

OTOH if you always enforce it how would you notice that you were gaining
any benefits? All that you would see is the tedium of always doing what
is necessary to maintain const correctness while being unaware of the
problems that it was insulating you from.


--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Francis Glassborow

не прочитано,
8 дек. 2002 г., 17:17:3508.12.2002
In message <3df240f1...@news.tin.it>, Andrea Griffini
<agr...@tin.it> writes

>Of course may be things are of course different with who
>is learning the language or even programming (and was crazy
>enough to choose a monster like C++ to learn programming).

You should distinguish between 'learning to program and using C++' from
'learning C++ without knowing how to program'.

I think that C++ is an excellent language to use while teaching a
newcomer how to program, but I would not teach them all of C++ in the
process of teaching them to Program.

I wonder what language you think would be a good one for a newcomer
learning to program. IMO, languages such as Java, Smalltalk, Prolog etc.
are two restrictive to teach general programming.

To teach I want a good general purpose language where I can select what
is useful for constructive teaching. IOWs the teacher, not the language
should determine what is taught.

--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Francis Glassborow

не прочитано,
8 дек. 2002 г., 17:18:3708.12.2002
In message <7kelh0...@ender.evo6.com>, Andy Sawyer <ne...@evo6.com>
writes

>Since everything else you say is true, it's a shame you chose strtok
>as your example here. 'strtok' is a really, really bad example, since
>it CAN (and is) implemented in a const correct form in C. The _only_
>const-correct form of strtok is:
>
>char *strtok( char *s1, const char *s2 );

True, I was forgetting that strtok has this signature which still allows
it to be called with a string literal with consequential undefined
behaviour.

>
>A much better example is strchr, where the additional overload is
>necessary for const-correctness.
>
> char *strchr( char *, int );
>const char *strchr( const char *, int );

Yes.


--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Baugereau

не прочитано,
8 дек. 2002 г., 17:21:1008.12.2002
> That said, "const" adds enormous complication to the language, and makes
> a
> great deal of work for programmers. If I were designing a language I
> don't
> think I'd bother with it. As far as I know, C++ is the only language
> which
> does bother.

Ada does in its way with "in", "out" and "in out" function parameters.
So it must not be such a bad idea :)

Andrea Griffini

не прочитано,
9 дек. 2002 г., 08:22:5609.12.2002
On 8 Dec 2002 17:17:35 -0500, Francis Glassborow
<francis.g...@ntlworld.com> wrote:

>I wonder what language you think would be a good one for a newcomer
>learning to program. IMO, languages such as Java, Smalltalk, Prolog
etc.
>are two restrictive to teach general programming.

That's a very good question. My answer is a simple assembler.

I'm assuming you're instead for the "top-down" approach,
and I'm assuming that on a statistical base ... because
that's what I've seen suggested mostly in the literature.

I learned programming starting from low level and going up.
The first programs I wrote were in RPN on an HP calculator
(that we got for almost free, because the owner thought
it was not working ... typing 1+1 it was getting a flashing
E at the +), next in SOA on a TI-57, then I had my hands on
an Apple ][ and started programming in assembler 6502.
Yeah... it took a *lot* of time, but you should consider I
was a kid reading manuals written in a foreign language and
typing on a keyboard. I suppose that having a teacher should
make things much faster.

Where did you start from ? Where did others that are proposing
the top-down approach start from ?

What about starting from UML ?

My idea is that learning is much easier from concrete to
abstract. We don't start with abelian groups with kids,
first we teach the integers.
That's why I think that someone learning programming shouldn't
start with containers iterators and const_iterators without
understanding memory issues, pointers and concrete data
structures first.

So my absurd position is that to learn C++ one should before
be quite comfortable with the C language that C++ was based on.
It's true that there's a risk that a programmer may get
used to bad idioms for which C++ has a better solution (I see
that on myself) ... but the risk of programming by coincidence
without a clear understanding of why a program works looks to
me no smaller. That fragility in my experience will translate
in panic and compiler blaming (or, no kidding, even accusing
bad-luck) when it will stop working (and it's when, not if).
I've seen this a jillion times, and I think you did too.

Also doesn't the top-down approach look a bit like a
dead-end street ?

Andrea

Bo-Staffan Lankinen

не прочитано,
9 дек. 2002 г., 13:30:2609.12.2002
> OTOH if you always enforce it how would you notice that you were
gaining
> any benefits? All that you would see is the tedium of always doing
what
> is necessary to maintain const correctness while being unaware of the
> problems that it was insulating you from.

That's not my experince of enforcing const correctness. It think that
any
programmer that is enforcing const correctness, on atleast a moderately
large project, occasionally makes the mistake of invoking a function
what
would accidently alter the state of an object, in a context, in which it
should be constant. In that case, it's quite evident that the enforcing
of
const correctness prevented you from making a programmatic error.

Bo-Staffan

Andrea Griffini

не прочитано,
9 дек. 2002 г., 13:31:0509.12.2002
On 8 Dec 2002 09:15:55 -0500, "Andrei Alexandrescu"
<andre...@hotmail.com> wrote:

>As a rule, comments that are not enforced by the compiler will rot over
>time.

I can only agree on this. I've seen this in many other
areas. I've read somewhere that there are psychologial
reasons for which programming in pairs and doing peer
reviews can help in keeping things cleaner... but not
being able to build if a rule has been violated seems
a bit more reassuring.

>What I'm glad about, is when design or programming errors are revealed
as
>type errors. (The stove has a mechanism that prevents it from
overheating or
>causing fire.) This is all what a type system is about.

This is exactly what I don't remember ever happening
to me... the const-correctness type error was never
an indication of a programming error if we exclude
const-correctness. In other words starting from the
program with the const-correctness related error and
removing all const correctness machinery would give
me a correct program. Try to do that with a missing
brace or a misplaced else.

Of course if using C++ const-correctness machinery
can't be ignored (temporaries can't be passed as
non-const references) and I can believe for sure that
without it implicit conversions can be a plague
(I didn't thought about this problem at first).

>IMHO, not appreciating const is a common error of a design beginner, in
the
>same way that not appreciating types/indentation/good
names/decomposition
>are common errors of a programming beginner.

Good to hear that :) ... at least shows I'm not a fool.

Andrea

Carlos Moreno

не прочитано,
9 дек. 2002 г., 15:18:0009.12.2002

Francis Glassborow wrote:

>
> OTOH if you always enforce it how would you notice that you were
gaining
> any benefits? All that you would see is the tedium of always doing
what
> is necessary to maintain const correctness while being unaware of the
> problems that it was insulating you from.


Actually, a fraction of the benefits is observable -- typos and similar
mistakes that are flagged by the compiler because const qualification
is violated.

Things so simple as using copy while thinking about strcpy (the order
of the parameters is the opposite); if the parameter you're copying
from is const-qualified (as it should be in 99% of properly written
code), then the compiler will tell you, and you just saved a few hours
or maybe a few months of chasing a bug.

About half of the bugs that I have in my day-to-day tasks are stopped
before they exist, because they are flagged by the compiler claiming
that the code violates some const-qualification. When I follow-up
those compiler error messages, in most cases I find out that the
expression would have been otherwise legal if it weren't for the
const-qualification.

I think that's evidence that, either const-qualification is a good
thing, or that I'm a very bad programmer (well, or both -- there is
no short-circuit evaluation in this type of situation ;-))

Carlos
--

Kevin Cline

не прочитано,
9 дек. 2002 г., 15:36:3709.12.2002
agr...@tin.it (Andrea Griffini) wrote in message news:<3df2346...@news.tin.it>...


> I'm quite positive it's not a good idea to invest in fixing
> const-correctness on current ones.

I wouldn't "invest" in it, but I might gradually fix it one class
at a time, from the bottom up. It will save wear and tear on any
new programmers who join the project. Even a fairly large code base
can be made const-correct in a few man-days of work. You just change
one class at a time starting from the lowest layer. What? You have no
layers, just a big ball of mud? Then I would start trying to tease
that mess apart first.

Andy Sawyer

не прочитано,
9 дек. 2002 г., 15:38:4109.12.2002
In article <WaVUQfEBJ389Ew$Y...@robinton.demon.co.uk>,
on 8 Dec 2002 17:18:37 -0500,
Francis Glassborow <francis.g...@ntlworld.com> wrote:

> In message <7kelh0...@ender.evo6.com>, Andy Sawyer <ne...@evo6.com>
> writes
> >Since everything else you say is true, it's a shame you chose strtok
> >as your example here. 'strtok' is a really, really bad example, since
> >it CAN (and is) implemented in a const correct form in C. The _only_
> >const-correct form of strtok is:
> >
> >char *strtok( char *s1, const char *s2 );
>
> True, I was forgetting that strtok has this signature which still
> allows it to be called with a string literal with consequential
> undefined behaviour.

strtok has that signature because it's the only correct signature for
strtok's behaviour. The fact is can be called with a string literal
with consequential undefined behaviour applies to plenty of other
standard library functions, and is - of course - due to inheriting C's
questionableน behaviour regarding the type of string literals. Here's
an example using strcpy:

strcpy( "undefined", "behaviour" );

Once again, char *strcpy( char *, const char *) is exactly the right
signature for the behaviour.

Regards,
Andy S.

น It's questionable because we know have the benefit of 20/20
hindsight


--
"Light thinks it travels faster than anything but it is wrong. No matter
how fast light travels it finds the darkness has always got there first,
and is waiting for it." -- Terry Pratchett, Reaper Man

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

apm

не прочитано,
9 дек. 2002 г., 15:39:2809.12.2002
agr...@tin.it (Andrea Griffini) wrote in message news:<3deee55...@news.tin.it>...
> Hello...
>
> I found myself in a quite blaspheme position of
> wondering how much in my personal experience
> const-correctness really helped me, and how much
> did it cost me.

You're right, that is blasphemous but perhaps for a different reason
than you think. IMAO const-correctness is a tool to assist in
self-documenting code and is therefore primarily of help to people
other than the original author. So it is mainly other people that will
be helped. It may indeed be a pain the neck for you but it does pay
dividends in the long run for the maintainers that come after you.

-apm

Carlos Moreno

не прочитано,
9 дек. 2002 г., 15:52:5109.12.2002

Andrea Griffini wrote:

>
> My idea is that learning is much easier from concrete to
> abstract.


So, would you propose that one has to learn about Chemistry,
Physics, Quantum Physiscs, then Mechanical engineering before
learning to drive? I mean, after all, you'd think it's
important to understand the concrete, and not be happy with
pressing the accelerator pedal without really understaning
how and why the car goes faster when one does that??

No, this is not a sarcastic example -- the analogy is valid,
IMO.

> We don't start with abelian groups with kids,
> first we teach the integers.


Well, sorry, but I see this as an example *against* your
case! Precisely, you start by sheltering kids from the
complexities of mathematics! You start by teaching them
what they can handle as newcomers to the world of mathematics!

That's why you should start teaching programming sheltering
them from the atrocities that happen inside a computer!!!!
And doing the simplest thing in C -- because you require
pointers for everything -- practically requires that you
understand Hardware and Computer Architecture! You can't
start by teaching printf; they have to understand the
very notion of what it means sending the contents of a
variable to the screen -- their brains are busy enough
to have to deal with the additional problem of remembering
the right format specifier, or figuring out why the
computer "is not doing what I asked it to" when accidentally
using the wrong format specifier.

It is a breakthrough for a beginner that you check if the
user entered an empty string by using an if and comparing
the entered string against "" ...

if (data == "")

Now, the poor guy has to understand that that is wrong
because data is a char *? And now, all of a sudden they
have to understand statically allocated memory? They
have to understand OS theory just to do something as
simple as if (num == 1) ... Because if you do it
that way with numbers, why on earth wouldn't it be the
same with a string??

> That's why I think that someone learning programming shouldn't
> start with containers iterators and const_iterators without
> understanding memory issues, pointers


How can you possibly suggest that memory issues and pointers
is the concrete part?? An array is something concrete;
pointers is the horrendously abstract and complex way in
which things happen inside a computer -- who cares about that
when what you want is to learn to program?!

Pointers and memory issues is the most advanced topic in
programming, and should be taught last!


I also learned the way you did -- my background is in
Electronics Engineering; my "mother language" is assmebler
too; then PL/M; then C, and then C++. But that doesn't
mean that I can't understand that is the worst possible
approach to teach programming...

The thing is, given that you are already an Electrical
Engineer who knows how to program in assembler, then maybe
learning C first might be ok (even if not best)... But
in any other case, it sounds like you're making them be
first an Electrical Engineer to then learn programming.
(yes, that was an exaggerated view -- just to make the
point clear)

> It's true that there's a risk that a programmer may get
> used to bad idioms for which C++ has a better solution (I see
> that on myself) ... but the risk of programming by coincidence
> without a clear understanding of why a program works looks to
> me no smaller.


And what do you call "programming by coincidence"?? If
I do a = 15; and it works, would you accuse me that it was
just by chance that that worked, only because I don't
understand how four lines of the data bus were driven
to 5 volts (or 3.3) while the write signal went through
a falling edge, possibly subject to wait states that
the chipset will produce?? Or maybe even worse: I'm
missing the processor cache! Would you tell me "There
are no wait states, you ignorant -- of course that thing
worked by pure luck! You don't even understand how the
cache memory works!" ?? I would say... "ohhh, what a
coincidence! I assigned 15 to the variable a, and that
magic box they call computer assigned 15 to just that
variable"

> That fragility in my experience will translate
> in panic and compiler blaming (or, no kidding, even accusing
> bad-luck) when it will stop working (and it's when, not if).
> I've seen this a jillion times, and I think you did too.


No, what I've seen a million times is people blaming it
to "black magic", Murphy, God's breaking the laws of the
Universe, etc., when you do this in C and it doesn't
work, even when you know for sure that the contents of
the string a is "hello"

if (a == "hello")
{
// .....

Carlos
--

Francis Glassborow

не прочитано,
9 дек. 2002 г., 16:02:4109.12.2002
In message <3df3d08d...@news.tin.it>, Andrea Griffini
<agr...@tin.it> writes

>Where did you start from ? Where did others that are proposing
>the top-down approach start from ?

This is an example of a common fallacy, that the way a teacher/expert
etc. learnt is the right way to learn. To decide on a good teaching
methodology (or more precisely to eliminate bad ones) we have to look at
the failure and why they failed.

From my experience, C++ is a perfectly suitable language to use for
teaching programming skills.

BTW, why teach assembler when working with a hex keypad brings you so
much closer to the hardware. After all it is only be examining the
binary codes for various ops (in my case for a Z80) that you get some
idea as to how the hardware manages these codes.

Personally I want to teach newcomers to program, if I am successful they
will be able to move to other languages fairly easily. In the long
distant past I used BASIC (and then had to explain to a set of examiners
why a thirty line program was superior to a 400 line one that did the
same thing -- to any competent programmer the 30 line one was easy to
understand, which is why some markers wanted to mark it down). At a
latter stage I used Forth as the language with which I taught 15-year
olds to program. That they all succeeded in producing original and
creative work and that people who did not understand Forth could
understand shows that they had grasped some important elements of
programming.

Some computer languages make teaching programming harder than necessary,
some do not. IMHO C++ is one of the latter.

--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Mark Charsley

не прочитано,
9 дек. 2002 г., 16:05:1209.12.2002
In article <rb6I9.838$qg4.39531@wards>, nob...@nowhere.com (Mark Smith)
wrote:

> Another thing that really bothers me is const member functions!
> I want to be able to change a classes implementation without altering
> its interface, so if a member function that was const, now becomes
> non-const, (eg if I add caching) why should clients care? It just
> breaks the interface!

If the change is an implementation details that clients shouldn't care
about, then use mutable - that's what the keyword's there for. If the
change does change the behaviour in ways important to the client, then
const allows you to quickly find which bits of code have been broken by
the change.

Mark

Jim Melton

не прочитано,
9 дек. 2002 г., 16:21:0809.12.2002
"Andrea Griffini" <agr...@tin.it> wrote in message
news:3df3edd8...@news.tin.it...

> On 8 Dec 2002 09:15:55 -0500, "Andrei Alexandrescu"
> <andre...@hotmail.com> wrote:
> >What I'm glad about, is when design or programming errors are revealed
> as
> >type errors. (The stove has a mechanism that prevents it from
> overheating or
> >causing fire.) This is all what a type system is about.
>
> This is exactly what I don't remember ever happening
> to me... the const-correctness type error was never
> an indication of a programming error if we exclude
> const-correctness. In other words starting from the
> program with the const-correctness related error and
> removing all const correctness machinery would give
> me a correct program. Try to do that with a missing
> brace or a misplaced else.


Consider:

void UpperCase(char* arg) // arg is modified by this function!
{
while (*arg)
{
*arg = to_upper(*arg);
++arg;
}
}

void foo()
{
UpperCase("a test string");
}

Now, since the standard defines string literals as "char const*", the above
call violates the C++ type system. Some compilers will only generate a
warning, allowing you to do evil things. If you don't enforce const
correctness in your code, such warnings are routinely ignored.

Now, remove the const correctness machinery (as you suggest above). There is
now no longer any such thing as "char const*" and the above code is
completely legal. Houston, we have a problem. If constants aren't, your code
may prove difficult to debug.
--
<disclaimer>
Opinions posted are those of the author.
My company doesn't pay me enough to speak for them.
</disclaimer>
--
Jim Melton
Software Architect, Fusion Programs
Lockheed Martin Astronautics
(303) 971-3846

Mark Smith

не прочитано,
9 дек. 2002 г., 16:22:5209.12.2002
"Matthew Collett" <m_co...@ihug.co.nz> wrote in message
news:m_collett-B5572...@lust.ihug.co.nz...

> In article <rb6I9.838$qg4.39531@wards>,
> "Mark Smith" <nob...@nowhere.com> wrote:
>
> > I want to be able to change a classes implementation without altering
> > its interface, so if a member function that was const, now becomes
> > non-const, (eg if I add caching) why should clients care?
> >
> They shouldn't, which is why the language provides 'mutable' for exactly
> this situation.

Yet more 2nd-level ripple-through effects! Great! :-)

Kind Regards,
Mark.

Mark Smith

не прочитано,
9 дек. 2002 г., 16:23:1509.12.2002
"Hannes Häyrinen" <hanz...@yahoo.com.au> wrote in message
news:d07b54da.02120...@posting.google.com...
> "Mark Smith" <nob...@nowhere.com> wrote in message
news:<rb6I9.838$qg4.39531@wards>...

> > Another thing that really bothers me is const member functions!
> > I want to be able to change a classes implementation without altering
> > its interface, so if a member function that was const, now becomes
> > non-const, (eg if I add caching) why should clients care? It just
breaks
> > the interface!
>
> A const member function can't just suddenly change to a non-const one.
> Clients indeed should care if a member function is const or not.
> Const assures that the function doesn't change the object (at least as
> far as the clients can see it). Adding a cache system to a const function
> doesn't really change the object (only speeds it up) so the function
> should still be const.

Hello Hannes,
Well, you've stated that clients should care if a member function
is const or not, but you haven't told me why? Why do clients
care if the method changes the object internally?

Mark Smith

не прочитано,
9 дек. 2002 г., 16:23:3609.12.2002
"Andrea Griffini" <agr...@tin.it> wrote in message
news:3df2346...@news.tin.it...
> On 7 Dec 2002 05:22:48 -0500, "Mark Smith" <nob...@nowhere.com> wrote:
>
> >although I guess the compiler might be making use of it for
> >optimisation purposes?
>
> No. Const-correctness can never help the optimizer.
> The reasons are the presence of aliasing (and no
> available method to inform the compiler that
> aliasing should not be considered) and the fact
> that casting away const-ness from a reference is
> perfectly legal and must be supported.

Hi Andrea,
That's a shame, it removes the only concrete reason as far as I'm
concerned for having it :-(

Mark Smith

не прочитано,
9 дек. 2002 г., 16:24:3109.12.2002
"Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
>
> Almost certainly you are still using a C mindset. It is actually almost
> impossible to write C++ using the full range of tools provided by the
> Standard Library without taking note of const correctness.

Hello Francis :-)
Bzzz, no sorry I don't have a C mindset, I'm just lazy, I don't
like doing things that have no benefits.

> >Another thing that really bothers me is const member functions!
> >I want to be able to change a classes implementation without altering
> >its interface, so if a member function that was const, now becomes
> >non-const, (eg if I add caching) why should clients care? It just
> breaks
> >the interface!
>

> We have to use the language correctly. A function should not be declared
> const simply on the basis that it does not change the object, but on the
> basis that it would be conceptually wrong for it to change the logical
> state of the object.

Yes, that's a good point. But who relies on the contract?

> Sometimes certain aspects of an object's physical state (such as cached
> results) need changing even when the object is being used in a logically
>
> const context. That is what mutable is for.

Ah you see, now your advocating yet another pointless exercise,
more needless ripple-through effects for something clients should
not care about anyway!

Clients should not assume or care whether the object is modified
internally by a method, it's none of their business. Can you provide
an example when it would be?

Mark Smith

не прочитано,
9 дек. 2002 г., 16:24:5309.12.2002
"Niklas Matthies" <comp.lang.c++.mod...@nmhq.net> wrote in
message news:slrnav41k4.jo.comp.lang....@nmhq.net...
> On 2002-12-07 10:22, Mark Smith <nob...@nowhere.com> wrote:
> [...]

> > Another thing that really bothers me is const member functions!
> > I want to be able to change a classes implementation without altering
> > its interface, so if a member function that was const, now becomes
> > non-const, (eg if I add caching) why should clients care? It just
> breaks
> > the interface!
>
> That's what 'mutable' is for. If you add caching, the member function is
> conceptually still const, i.e. it doesn't change the observable state of
> the object.

Yet more ripple-through! Great just what we need!

> So how do you call member functions on const references?

You don't need const references. You have an interface which
you call, who cares if the object is modified internally? It's
none of your business anyway!

llewelly

не прочитано,
9 дек. 2002 г., 16:26:2309.12.2002
Carlos Moreno <moreno_at_mo...@xx.xxx> writes:

[snip]


> <nitpicking>
>
> I don't think anyone has ever seen a compiler warning when
> trying to access private data -- in every single compiler
> that I've worked with (ever since the days of Borland C++ 3),
> that would produce a compiler error.
>
> </nitpicking>

[snip]

I have used compilers which provide a command line option to report
warnings instead of errors for access violations.

David B. Held

не прочитано,
9 дек. 2002 г., 16:29:4609.12.2002