Prev: what happen when Compile this code?
Next: Combining Two Buffers - How To?
From: Daniel Krügler on 25 Mar 2010 02:11
On 25 Mrz., 13:27, Tonni Tielens <tonnitiel...(a)gmail.com> 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.

It is very easy to run into that problem in Java (and
we did that in one or the other occasion), but because
of the existence of this problem in Java, you use
several idioms to minimize that risk:

- Make classes immutable, e.g. String, Integer.

- Provide read-only sub-interfaces to parts of
the class that you want to "publish".

The latter is still possible to break class invariants
unintentionally, if careless downcasting to mutable
interfaces is practiced.

Greetings from Bremen,

Daniel Kr�gler



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

From: Ike Waters on 25 Mar 2010 04:05
mattb schrieb:
> I have recently heard the above, along with a further statement along
> the lines of -
>
> 'const is there to stop amateur slip ups. Professionals should know
> what a function is expecting and should use that.'
>
> Could I please have some comments on these statements.

1. const is a technical advantage.

Without const, you cannot trivially implement copy-on-write or simply
use the information that your object state did not change.

Without const, there is no reference to const. You cannot call

template<typename T>
T function(const T& a); // assume T can be fat, f.e. an IPv6 address

by using

int t = function(1);

any longer.

Compilers should be able optimize more with const, in particular when
using compile time constant values.

2. const is for free (IDEs should autocomplete it) and prevents lots
of errors

void work(const Container& a, Container& b)
{
assert(a.size() > b.size());

Container::const_iterator j(a.begin());
for(Container::iterator i(b.begin()); i != b.end(); ++i, ++j)
if(compareStuff(*i, *j))
j = b.erase(j); // oops, mistook j for i
}

Remove the const and replace the const_iterator and you will have a
hard time finding the bug. The buggy line works at least with vectors
in g++.

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

From: GMan on 25 Mar 2010 04:07
On Mar 25, 10:10 am, Goran <goran.pu...(a)gmail.com> wrote:
>
> I don't know if you're being ironic. If no, then I say: and yet,
> professional drivers (e.g. in a Formula 1 car) are heavily strapped.
>
> Goran.

Exactly.


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

From: Nick Hounsome on 25 Mar 2010 19:53
On 25 Mar, 23:27, Aaron Creed <b...(a)computermail.net> wrote:
> What are your opinions of const function arguments, with respect to
> value semantics? e.g.:
>
> In the .h:
> void foo(int x);
>
> In the .cpp:
> int foo(int const x)
> {
> return x*2;
>
> }

In the declaration it has no value where parameters are passed by
value anyway because it has no effect on the caller.
All it acheives is to clutter the interface.

>
> In the body (function definition), it might be nice to include the
> const because many of the reasons people have mentioned so far
> (preventing erroneous changes to something you meant to have constant,
> etc).

The interface is not the place to put implementation details and a
const int parameter is purely implementation detail and not an
important detail at that.

There is another way to do this - just create a local const and use
that or even a const reference to the parameter.

>
> However it doesn't seem like I see this practice happen often in code
> I read. One downside I can see is that from a eye-ball point of view,
> the functions might look like they are signatures to two different
> functions and cause some confusion (even though I believe most
> compilers will treat them as the same).

No foo(int) and foo(const int) are always two different functions
even though there is no useful difference.


{ mod factoid: T foo(int) and T foo(const int) are the same function by the
language rules, C++98 �8.3.5/3 "Such cv-qualifiers affect only the definition of
the parameter within the body of the function; they do not affect the function
type". Similarly, a storage class specifier such as 'register' is not part of
the type. However, an IDE may not necessarily recognize this rule. -mod }



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

From: Nick Hounsome on 29 Mar 2010 04:00
On 28 Mar, 22:05, "Peter C. Chapin" <pcc482...(a)gmail.com> wrote:
> Nick Hounsome wrote:

>
> There have been times when I've modified a function only to have the compiler
> tell me that I'm changing a const. This forced me to review my change a
> little more closely than I would have otherwise... before removing const from
> the declaration. That extra bit of review was probably a good thing, right?
> There may have even been cases where I noticed a problem during that extra
> review, but I don't remember.

This is just wrong.

You should never change a declaration to suit the implementation
(Unless is required to allow any sort of implementation - which isn't
the case here) Declarations are supposed to be about what a function
is going to do not how it is going to do it.

In a big project you realy don't want to trigger a massive recompile
for something that has no semantic effect on callers.

--
[ 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: what happen when Compile this code?
Next: Combining Two Buffers - How To?