-1

Possible Duplicate:
Const correctness for value parameters

I consider a good coding practice the following. When a parameter is passed to a function by value, it should only be read, but not modified (or reused) in the function body. But is it actually a good practice?

Example (of what I avoid doing):

int foo(int x){
    //do lots of cool stuff
    x = 69;
    //do even cooler stuff
}

From here on we get to const correctness. Provided that my practice is good follows that nearly every argument to every function should be preceded by a "const". Actually "a" is optimistic:

class A{
    const int gnoo(const int *const, const double) const;
};
Community
  • 1
  • 1
Vorac
  • 8,726
  • 11
  • 58
  • 101
  • Do not return a const copy. It serves no purpose other then making other peoples lives miserable. If its a reference or a pointer then ok but not a copy. – RedX May 30 '12 at 14:31

2 Answers2

1

There are two sides to the problem, the declaration and the definition. At the declaration point, the top level qualifiers of the function arguments are dropped, so the const is removed by the compiler. At the definition on the other hand, the compiler ensures that if the parameter is const it will not be modified internally.

The return type is another story, where the const is not dropped from the declaration, but in this case you most probably don't want to make the returned object (if it is by value) const, as that will possibly limit the chances of optimizing of your compiler in a couple of different ways. The first one, brand new in C++11 is that you cannot move out of a const object, which means that by returning a const object you inhibit moving from it. In C++03 the cases where this affect are fewer and more of a corner case, but there is limited advantage on returning const objects.

Some people suggests adding const everywhere. I don't, and most code I have read does not either.

David Rodríguez - dribeas
  • 204,818
  • 23
  • 294
  • 489
  • Just an example of when the return type SHOULD be const even if by value: suppose I create a view to a chunk of an array that is stored in my class and I return it. In order to prevent people to modify my class through the view (even with a move semantic), I can add the const to the return type. – bartgol Oct 30 '13 at 06:56
0

Your point is well taken. And depending on the language, the compiler/interpreter may throw an error or warning when it sees code like your first example.

However, at some point you have to choose whether or not you are going to try and protect "the developers" from doing something stupid or just assume that they are and catch this sort of thing during a code review.

Utilizing syntactic mechanisms to make the code safer is a good thing, IMHO. It can sort of impede development flow, unfortunately.

bluevector
  • 3,485
  • 1
  • 15
  • 18
  • Mine is kind of two-questions-in-one-post. So you are with me, not modifying passed by value arguments. Ever. However the second thing that troubles me is how to "put "const" everywhere that I can". This would mean consting almost all parameters of all functions. – Vorac May 30 '12 at 15:37
  • What you propose is a syntactic expression a solution to a philosophical problem. The functional guys say that it is good when functions (or methods) have zero side-effects. I agree with that. They're even better when idempotent (they return the same value for the same parameter set). How much that syntactic enforcement restricts a programmer is a different matter. Think of Java's requirement of advertising the exceptions a method might throw... all modern tools factored that away from the programmers, thereby nullifying the point of the syntactic requirement. – bluevector May 30 '12 at 16:20