Oppinion on 'least priviledge', 'const correctness', etc.

[Alexander]

Wherever I find something on the topic, these are considered positive.
Why? I only find it time-consuming. Could you respond (preferably on
comp.programming) why it can be considered as such, but motivated,
that is without responses like "it's good software engineering
practice", "it's just better", etc... I'm a learner, and I think now
is the best time to shape out practices and priorities.

 

[Jorgen Grahn]

["Followup-To:" header set to comp.lang.c++. Neither the Java nor the
comp.programming people want to read about const correctness, I'm sure.]

Wherever I find something on the topic, these are considered positive.

Only these two, or do you include a number of other things under
"etc", unknown to us?

Why? I only find it time-consuming. Could you respond (preferably on
comp.programming) why it can be considered as such, but motivated,
that is without responses like "it's good software engineering
practice", "it's just better", etc...

Const specifically: a language feature I really like.

I guess you can say that it adds another dimension to the type system.
It's good for the same reasons that the rest of the static typing is
good. E.g. that we can have have Foo* and Bar*, not just void*.

You make more information about your intentions explicit, in the code,
for the benefit for the reader. And the compiler can check it.

I'm a learner, and I think now
is the best time to shape out practices and priorities.

Yes. For const, you don't really have a choice -- if you refuse to use
it, you'll be in constant conflict with other programmers working on
the code.

There are still, I think, old C programmers who reject const, but I
never heard of a C++ programmer who did.

/Jorgen

 

[Juha Nieminen]

Const specifically: a language feature I really like.

I guess you can say that it adds another dimension to the type system.
It's good for the same reasons that the rest of the static typing is
good. E.g. that we can have have Foo* and Bar*, not just void*.

You make more information about your intentions explicit, in the code,
for the benefit for the reader. And the compiler can check it.

Sometimes constness can be used for efficiency.

It is possible for a class to have two member functions with an otherwise
identical signature (ie. name, parameters amount and types) except that one
is const and the other isn't. When the member function is called, the
compiler will choose which one of those two will be called depending on the
constness of the object, reference or pointer.

There are situations where this feature is taken advantage of for
efficiency: Sometimes the const version of the member function can be
made significantly more efficient because it can be made simpler due to
the fact that it doesn't change the object or, more usually, it can assume
that whatever it's returning will not be changed by the calling code.

(As an example, if eg. std::string implemented copy-on-write, then its
const version of operator[] can be significantly more efficient than its
non-const version because the const version doesn't need to deep-copy the
string even if it's currently being shared, while the non-const version
always has to deep-copy a shared string.)

 

[Öö Tiib]

Wherever I find something on the topic, these are considered positive.
Why? I only find it time-consuming.

I have heard them named as "principle of minimal privilege" and "const
correctness".

Illustrative example: Imagine that you play classical click-around,
find-items, combine-and-use-them-to-proceed adventure game. You need
to use 5 items for winning it but the game throws at you 80 red
herring items too. Some of the items may lead you to wrong, useless
places or into inescapable situations (that game does not indicate any
way). Fun to click and try to combine them all and to use everywhere
and then to reload earlier saves and to retry? No. Most like it be
better if game does not give red herrings to them at all or gave lot
less than possible. So "more" is not always "better".

Same is with access restrictions in computer science. Anyone writing
module or class interfaces should take good care about it being
sufficient and complete for its purpose. It is done for protecting the
users of interface from need to know about various red herrings and
wrong places. Best is to give to user *only* such information and
resources and access that they need for legitimate usage purposes.
Also it is important to give them *everything* that they need for
legitimate usage purposes, otherwise they start to ask questions like
"is this game winnable at all".

Of course it is initially time consuming for interface designer to
carefully arrange that access but it saves lot of time of the innocent
users of the interface. Also it gets easier when you have habit to do
it. If you write it all by yourself you may initially think that you
are the user yourself (and so not innocent) and so it does not apply
and habit is not needed. Wrong. Let me display why you are wrong there
too.

Why you write it at all? Usually it is done for fame and/or big bucks.
What is goal-reaching indicator? Popularity and/or commercial success.
Have you faced (however limited) popularity or commercial success? It
is terrible thing. The list of bugs and feature requests may grow to
hundreds or thousands despite how good effort you put up. You will see
it is hard, when you are lucky enough.

Lets say you manage alone? During maintenance your product grows over
100 000 lines of code easily in less than 5 years heroic maintenance.
100 000 lines is about the spot where you start to forget things why
you wrote that or that. Finally you are player yourself with full of
red herrings puzzle. You need to maintain it and hate it at same time.
You can not possibly manage alone.

Now comes last point. Writing interfaces lousily is bad habit. Others
do not like it. It is very hard to find allies. Very precious few can
navigate in 100 000 lines of one-man spaghetti. None of these precious
few lacks better offers or opportunities than to join you. Also it is
very hard for you to get rid of your bad habits (you have worked by
them for 5 years say).

Could you respond (preferably on
comp.programming) why it can be considered as such, but motivated,
that is without responses like "it's good software engineering
practice", "it's just better", etc... I'm a learner, and I think now
is the best time to shape out practices and priorities.

Why you cross posted to several groups? Post into every group
individually if you need different opinions. There are lot more
languages. Each is different. For example java does not have language
elements dedicated for const correctness at all i think. However ...
general reasons why principle of minimal privileges is good to follow
are lot older than C++ or java. I think most good developers have
habit to limit access to their modules internals in one way or other.

 

[Lew]

Why you cross posted to several groups? Post into every group
individually if you need different opinions. There are lot more

Wrong. You describe multi-posting, one of the cardinal sins of
Usenet. Cross-posting is much better.

Do not multi-post. Ever.

Cross-post only when you must, to the least number of relevant groups.

languages. Each is different. For example java [sic] does not have language
elements dedicated for const correctness at all i [sic] think. However ....

Wrong again, sort of. Java has 'final' which is sort of similar to
'const'.

 

[Lew]

["Followup-To:" header set to comp.lang.c++.  Neither the Java nor the
comp.programming people want to read about const correctness, I'm sure.]

Don't be so sure. Java has 'final', which isn't exactly the same as
'const' but is similar and applies similarly to the "principle of
least privilege" and the safety thereof.

Both 'const' and 'final' express the intention to prevent change to a
variable's value.

 

[Öö Tiib]

Wrong.  You describe multi-posting, one of the cardinal sins of
Usenet.  Cross-posting is much better.

Do not multi-post.  Ever.

Cross-post only when you must, to the least number of relevant groups.

OK. Thanks for correcting. I do neither anyway unless replying.
comp.lang.c++ and comp.lang.c++.moderated keep me usually entertained
enough.

languages. Each is different. For example java [sic] does not have language
elements dedicated for const correctness at all i [sic] think. However ....

Wrong again, sort of.  Java has 'final' which is sort of similar to
'const'.

I have not seen much usage of it nor heard much talk about 'final-
correctness' in friendly java teams. C devs talk about const a lot
more. Perhaps that 'final' sort of misses some useful perks of
'const'.

 

[Joshua Maurice]

I'm a big fan of language constructs that constrain the code in certain
ways, from data/implementation hiding/encapsulation to things like
"const", "final", "readonly" (C#), etc. that help convey and,
especially, enforce intent.  But these kinds of things really need to be
done in a way that doesn't allow the programmer to just wish the
restrictions away any time they like.  Otherwise, it's too tempting to
do just that when the alternative is to spend hours or days updating the
code to use the restriction properly.

Unfortunately (or fortunately ?), this is C++, and the motto is we'll
give you tools to help you not shoot yourself in the foot, perhaps
even make them the default, but if you're dead set on shooting
yourself in the foot, C++ will allow you to do so.

 

[Jonathan Lee]

I have not seen much usage of it nor heard much talk about 'final-
correctness' in friendly java teams. C devs talk about const a lot
more. Perhaps that 'final' sort of misses some useful perks of
'const'.

I've never heard of an equivalent of "const correctness" in Java,
but I also don't use it very much. Though, a quick Google search
seems to support the idea that "final" is really nothing like
const-correctness:

http://en.wikipedia.org/wiki/Final_(Java)
http://stackoverflow.com/questions/1370042/why-is-const-correctness-specific-to-c
http://mannu.livejournal.com/131085.html
http://en.wikipedia.org/wiki/Const-correctness

--Jonathan

 

[Öö Tiib]

Lew wrote:

I'm a big fan of language constructs that constrain the code in certain
ways, from data/implementation hiding/encapsulation to things like
"const", "final", "readonly" (C#), etc. that help convey and,
especially, enforce intent.  But these kinds of things really need to be
done in a way that doesn't allow the programmer to just wish the
restrictions away any time they like.  Otherwise, it's too tempting to
do just that when the alternative is to spend hours or days updating the
code to use the restriction properly.

C++ is yes, relatively anarchistic language so teams usually agree
upon policies that they follow and do not expect software (compiler)
to tell to human how to program it. There are always ways to
circumvent the language protection mechanics. If i remember correctly
then calling private member functions in C# is even easier than in C+
+. If something evil gets too annoyingly tempting then build
gallons ... few public executions later it is less tempting.

 

[Daniel Pitts]

["Followup-To:" header set to comp.lang.c++. Neither the Java nor the
comp.programming people want to read about const correctness, I'm sure.]

Don't be so sure. Java has 'final', which isn't exactly the same as
'const' but is similar and applies similarly to the "principle of
least privilege" and the safety thereof.

Both 'const' and 'final' express the intention to prevent change to a
variable's value.

Almost. const expresses that a specific object should be unchanged, but
final (unfortunately) only refers to primitive/reference immutability.
It is definitely a feature I miss in Java. Especially since immutable
objects are guaranteed to be thread-safe.

 

[Alan Gutierrez]

I've never heard of an equivalent of "const correctness" in Java,
but I also don't use it very much. Though, a quick Google search
seems to support the idea that "final" is really nothing like
const-correctness:

The equivalent in Java to "const-Correctness", culturally, is "Favor
Immutability". The same sort of conversation taking place here is one
that follows a request to explain the benefits of "Favor Immutability".

I'm new here, and I humbly submit the above observation.

 

[Lew]

I have not seen much usage of it nor heard much talk about 'final-
correctness' in friendly java [sic] teams. C devs talk about const a lot

That's because that's not what we call it. Alan gives you the correct term.

Or perhaps Java's 'final' doesn't need those "perks" because of the other
differences between the languages.


Therefore it doesn't exist? Anyway, the claim isn't that there's an exact
equivalent to "const correctness" but that Java's 'final' has similarities to
C++'s 'const', and relative to the Java language fills the same ecological niche.

Again, that's not the claim. The claim is that 'final' is similar for Java to
what 'const' is in C++, in certain ways.

The equivalent in Java to "const-Correctness", culturally, is "Favor
Immutability". The same sort of conversation taking place here is one
that follows a request to explain the benefits of "Favor Immutability".

I'm new here, and I humbly submit the above observation.

Everyone here seems to think that Java 'final' is just nothing a-'tall like
C[++] 'const'. They are, of course, mistaken.

Both keywords signal to the compiler that the item so marked cannot be altered.

Since Java supports only pointers and primitives and not value-object
variables, the semantics of its 'final' are bound to differ from those of
C++'s 'const'. C++ and Java are different languages. But in terms of
enforcing "least privilege" (this conversation's avowed topic) and
immutability, the two constructs serve cognate purposes.

 

[Jonathan Lee]

Therefore it doesn't exist?

Er.. no. In fact, I even went out of my way to say that I wasn't
experienced in Java so people wouldn't draw that conclusion.

 Anyway, the claim isn't that there's an exact equivalent to
"const correctness" but that Java's 'final' has similarities to
C++'s 'const', and relative to the Java language fills the same
ecological niche.

The OP was asking about const correctness, not the const keyword.
As for the "final" and "const" keywords being similar... that's
interesting, but a distinct topic.

Everyone here seems to think that Java 'final' is just nothing a-'tall like
C[++] 'const'.  They are, of course, mistaken.

We don't think that.

--Jonathan

 

[Daniel]

Sometimes the const version of the member function can be
made significantly more efficient because it can be made simpler due to
the fact that it doesn't change the object or, more usually, it can assume
that whatever it's returning will not be changed by the calling code.

On the contrary, whatever const on a member function is supposed to
mean, it doesn't mean "pure". The body of the method can still mutate
any variable that is embedded within a data member, and it can mutate
any data that is accessible through a pointer member. There is no
guarantee that two calls to a const method with the same arguments
will give the same result.

-- Daniel

 

[Daniel]

I've never heard of an equivalent of "const correctness" in Java,
but I also don't use it very much.

Neither Java or C++ has any way of marking a function as "pure". In
Java, the convention is more to use immutable interfaces, so the issue
doesn't arise as much. In C++, const restricts you to calling a
subset of member functions on the object, but there are no guarantees
that that subset doesn't also change state, there are restrictions,
but only to the first layer of the data.

-- Daniel

 

[Lew]

Neither Java or C++ has any way of marking a function as "pure". In
Java, the convention is more to use immutable interfaces, so the issue

Immutable class instances. Interfaces in Java can't enforce immutability.

 

[Öö Tiib]

I have not seen much usage of it nor heard much talk about 'final-
correctness' in friendly java [sic] teams. C devs talk about const a lot

That's because that's not what we call it.  Alan gives you the correct term.

Seems that "Favor Immutability" is not that popular idiom. Google for
"Const Correctness" 39,000 results, "Favor Immutability" 1,080. It is
more about how to create immutable classes, while in C++ you do not
need to (but may) make special classes for constant instances.

Or perhaps Java's 'final' doesn't need those "perks" because of the other
differences between the languages.

Huh? But these are tools, language features. Not mandatory to use
always but most like them since these really help. Perhaps that
'final' is simply considered enough by authors of java. There are fine
languages like Python with even less features supporting
immutability.

Again, that's not the claim.  The claim is that 'final' is similar for Java to
what 'const' is in C++, in certain ways.

Ok. Making primitive immutable with 'final' is yes in certain ways
same. It is mostly perhaps used for naming single constant values, not
write protection? You can also make a pointer immutable with 'final'.
That is sometimes done in C++ too but usually one uses a reference for
it ('const' is not needed at all).

There similarities end. 'final' about member function means that it
can not be further overridden and 'final' about class means that it
can not be derived from. These are entirely different purposes than
'const' has. It feels like 'final' is for some sort of global and meta-
immutability when 'const' is more for selectively write-protecting
(possibly mutable) data.

Everyone here seems to think that Java 'final' is just nothing a-'tall like
C[++] 'const'.  They are, of course, mistaken.

'const' yes, feels more oriented for not giving (and taking) unneeded
privileges locally. Major feature of 'const' is to declare that code
will not modify the object pointed to by a pointer through that
pointer. Other feature is to declare that function does not modify its
parameter and third is to show that member function does not modify
the object. How you do any of these with 'final'?

Both keywords signal to the compiler that the item so marked cannot be altered.

Since Java supports only pointers and primitives and not value-object
variables, the semantics of its 'final' are bound to differ from those of
C++'s 'const'.  C++ and Java are different languages.  But in terms of
enforcing "least privilege" (this conversation's avowed topic) and
immutability, the two constructs serve cognate purposes.

I am not saying that different feature set makes one language better
than other, just that 'final's purpose feels different and such
comparison feels stretched out, nothing to do. You can have immutable
view of mutable data by writing special interface in java, but the
cost is higher than with 'const' and what it all has to do with
'final'?

 

[Stuart Redmann]

Maybe I'm just lucky, but I cannot even remember the last time I
actually had to use const_cast because of some broken (or legacy) C++ or
C API. How often do you really encounter this problem?

Quite seldom. Most often these are in-house projects where the co-
workers offers a header for some wrapper Dll that has been written in
MatLab or IDL, and the generated headers file are not const-correct.
Since they don't know C++ I most often correct those headers by hand.

The Win32 API is not always const-correct (see VerQueryValue,
CreatePenIndirect, or TOOLTIPTEXT).

MS MFC uses some macros like RUNTIME_CLASS which contain const_casts.
If I cannot use such macros because my classes are inside a namespace
or are generated from a template, I have to replace the macro by hand,
which introduces const-casts in my code.

I generate some wrapper classes for COM components from the raw .idl
file, and import the type library that is generated from the .idl
file. Since type libraries "eat away" all const-modifiers, I'll have
to const-cast a lot in my wrapper classes (so that at least C++ users
have a const-correct API).

In some measurement and automation APIs you'll find non-const correct
functions (for example Roper Scientific's PVCAM API).

Those are only the examples that I found when I searched for
const_cast through all my projects. There may be a lot more cases
where I just used a plain C-cast.

Regards,
Stuart

 

[Juha Nieminen]

On the contrary, whatever const on a member function is supposed to
mean, it doesn't mean "pure". The body of the method can still mutate
any variable that is embedded within a data member, and it can mutate
any data that is accessible through a pointer member. There is no
guarantee that two calls to a const method with the same arguments
will give the same result.

I fail to see how what you wrote invalidates what I wrote.

Member function constness and be and is used for efficiency, the example
I gave being such a situation.