Prev: Combining Two Buffers - How To?
Next: [ANN] Miscellaneous Container Templates 0.9.1
From: Andrei Alexandrescu on 25 Mar 2010 04:07
On 03/25/2010 07:27 AM, Tonni Tielens wrote:
> Interesting topic. I was thinking about this a while ago. Why does
> Java for instance not have a const mechanism. E.g. in Java you can say
> a reference itself cannot change, but you cannot prevent someone from
> modifying an objects state if he has a reference to it. Why is const
> correctness never introduced in a language like Java and more
> important: why do people not seem to miss it?
>
> We are working on two applications in my team. One is a const correct C
> ++ application and one is a Java application. Although I understand
> the idea behind const and I urge others to make const correct code, we
> have never had a situation in the Java application where we thought:
> "Oh, if we only had const now, this wouldn't have happened." Of course
> this also goes for the construction worker who has never had a brick
> falling on his head.

I think there's some evidence that some people deem immutability as
desirable for Java. Searching Google Scholar for <<java immutability>>
reveals quite a few recent papers, such as:

Javari: Adding reference immutability to Java

http://groups.csail.mit.edu/pag/pubs/ref-immutability-oopsla2005-abstract.html

Object and Reference Immutability using Java Generics

http://www.zibin.net/publications/FSE07-igj.pdf

This one won ACM SIGSOFT Distinguished Paper Award, which may indirectly
tell that the subject is of interest.

Concurrency is the place where the necessity of a formalism for
immutability, and the perils of lacking one, become painfully obvious.


Andrei


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on 28 Mar 2010 09:34
Peter C. Chapin wrote:
> void f(const int x)
> {
> const int y = 2*x + 1;
> // Here x and y are local constants.
> }
>
> But... is my code better for this?

I think so, it's a style I've been slowly adopting.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on 29 Mar 2010 06:20
Jeffrey Schwab wrote:
> On 3/28/10 8:34 PM, Walter Bright wrote:
>> Peter C. Chapin wrote:
>>> const int y = 2*x + 1;
>> I think so, it's a style I've been slowly adopting.
> I've been doing that for about two years now, and my eyes have completely adjusted to it. The code is much easier to read than the older style, because a missing const doesn't just tell me that a variable is technically mutable, but that its value actually is modified by some statement in scope, or by some function with implicit access to the variable; else, the variable would have been declared const. The only thing I find jarring in Peter's code is that the const comes before the type it modifies, whereas my eyes have been trained to look after the type. If type names are short, as in this case, that's not a huge deal.

It's a bit easier in D because the type can be inferred from the initializer, so it becomes:

const y = 2*x + 1;

which is easy on the eyes and easy to type. I should also give credit to Andrei
Alexandrescu for introducing me to this style.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Seungbeom Kim on 29 Mar 2010 07:55
On 2010-03-29 14:18, Peter C. Chapin wrote:
> Daniel T. wrote:
>
>> It doesn't even really communicate intent if you are putting the const in
> after the fact because you happened to notice (or a tool told you) that the
> value didn't happen to get modified.
>
> I understand what you mean and I've thought about that too. I think there is
> still value in adding const even if after the fact. The tool says, "by the
> way... this value is never modified." In response I add something that will
> trigger a compile error later on if I modify the value without review. That
> seems like a good thing. If my existing code takes advantage of the object's
> constantness without the const actually being present, I run the risk of
> silently invalidating my existing code when I make future modifications.

Then how do you distinguish something that "is meant to" be const from
something that "happens to" be const?

I can imagine that adding const for the latter leads to the developer
later scratching his/her head mumbling, "Why did I/they put const here?
Did I/they really mean it or was it just accidental? Can I remove it
safely? I don't know..."

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Seungbeom Kim on 29 Mar 2010 19:59
On 2010-03-28 14:05, Peter C. Chapin wrote:
>
> It all depends on what you are used to seeing. I use things like
>
> void f(const int x)
> {
> // Here x is a constant.
> }
>
> quite often. This is because I declare everything const that can logically be
> declared as such.

On the other hand, I seldom (almost never) see things like:

ssize_t read(const int fd, void *const buf, const size_t count);

instead of

ssize_t read(int fd, void *buf, size_t count);

even though the parameters (fd, buf, and count) are all logically const,
and even though adding const would not break the interface compatibility.

In addition, adding const to buf and count would disallow the style of
implementation that increments buf and decrements count internally,
which is a perfectly valid way.

Doesn't const also prevent some kind of optimization?

void foo0(std::string s);
void foo1(const std::string s);

I remember hearing that a certain optimization that would have been
possible in foo0 is not possible in foo1.

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 |  Next  |  Last
Pages: 1 2
Prev: Combining Two Buffers - How To?
Next: [ANN] Miscellaneous Container Templates 0.9.1