11
///////////////////////////////////////
class A {
    ...
    const double funA(void)
    {...}
};

A a;
double x = a.funA(); 
// although the intention is to
// enforce the return value to be const and cannot be
// modified, it has little effect in the real world.

class A2 {
    ...
    double funB(void)
    {...}
};

///////////////////////////////////////
class A {
    void setA(const double d)
    { // now you cannot change the value of d, so what?
      // From my point of view, it is NOT a good practice to change the pass-in parameter
      // in this case, unless you want the caller to receive that change
      // instead, you can do 
      // const double dPassIn = d;
      / /then use dPassIn instead.
      ...
    }
};

class A2 {
    void setB(double d)
    {...}
};

//////////////////////////////////////

From my understanding, we should prefer to using A2::funB and A2::setB because the const used in both A::funA and A::setA has little meaning.

// Update //

    FMOD_RESULT F_API EventSystem::getReverbPresetByIndex(const int index, 
                                FMOD_REVERB_PROPERTIES *props, char **name = 0);

I consider FMOD is a well-designed package and it does use const int inside function parameter list. Now, I agree that the A::setA(const double d) has its edge.

q0987
  • 34,938
  • 69
  • 242
  • 387
  • You say that it is better to keep the parameter constant "...unless you want the caller to receive that change...". The caller would not receive the change in this particular case as the parameter is passed by value. You would need to pass a reference / pointer. – Petr Dec 06 '11 at 21:41
  • possible duplicate of [Constants and compiler optimization in C++](http://stackoverflow.com/questions/212237/constants-and-compiler-optimization-in-c) – Kyle Trauberman Jul 21 '12 at 03:23

4 Answers4

9

When returning by value the constant has no effect as it cannot be enforced anyway. Some compilers issue a warning. However it DOES make sense to return a pointer/reference to constant data.

When passing an argument into a function it is preferable (safer, allows for compiler optimizations) to pass it as a constant unless you absolutely need to change the data.

Petr
  • 1,128
  • 2
  • 14
  • 23
  • 1
    It does however limit the algorithms you can use in the function - without making unnecessary copies of the input. You don't want to have to change the definition of the function because of a later algorithm change in side the function. – Martin Beckett Dec 06 '11 at 21:19
  • @Martin Beckett Some people prefer to make copies as it keeps the input (initial values) intact... – Petr Dec 06 '11 at 21:22
  • 3
    I would have a very, very small amendement to make to your answer. If you return an object by value, making it const would prevent the user from calling a non-const method on that value. Obviously, the user can always assign the returned value to a non-const value and call the method there. ;) That's pretty much what I can think of. I thought making if const would prevent you from doing "if( foo() = 42 )", but turns out the compiler actually catches that error, since the return is not an l-value. – fronsacqc Dec 06 '11 at 21:30
  • 1
    @fronsacqc : Returning a const object by value also inhibits move semantics, which is never a good thing. Also, allowing non-const member functions to be called on temporaries can be a good thing, and even idiomatic -- see e.g. the C++03 `std::vector<>` shrink-to-fit idiom. – ildjarn Dec 06 '11 at 21:36
  • 1
    @MartinBeckett: Adding or removing top-level const-qualifier does not mean changing the declaration of the function. Don't put those consts in headers (they are meaningless to the caller), do as you like in the implementation files. – UncleBens Dec 06 '11 at 21:51
3

the const-keyword tells the Compiler "In my function setB i Wont change the Argument. If you want to Optimize for Multithreading you can use this Variable the same Time in another context, because my Work wont change it."

So i would say, in Progamming-logic, the second variant is better, like you said it has "little meaning", but in wider logic if you see what really happens, you should declare const, what is const, and dont declare const what isnt const. It is kind of a documentation the compiler understands and maybe will use to optimize your code!

EGOrecords
  • 1,959
  • 2
  • 19
  • 33
  • I updated my OP. I still think it is Not a good practice in this case to modify the passed-in double parameter and also this should not be enforced by redundantly using `const double` in the function parameter list. – q0987 Dec 06 '11 at 21:21
  • Not true. Ever heard of const_cast? const is meant to prevent you from making a mistake and modifying something that you shouldn't, period. – fronsacqc Dec 06 '11 at 21:22
  • 1
    @q0987 : If it's bad practice, then how is enforcing prevention of that bad practice redundant? – ildjarn Dec 06 '11 at 21:22
  • 1
    @q0987 Some people recommend this practice, but of course, you pay for the copy... – Petr Dec 06 '11 at 21:24
  • In case of more complex functions it may be better to keep the initial values intact just in case they are needed later. In case of really simple functions (hot-spots) it may be acceptable to use the argument data. – Petr Dec 06 '11 at 21:28
1

From my point of view, it is NOT a good practice to change the pass-in parameter

Then it makes sense to declare that by using the const on the argument in the definition of the function. Not everybody follows the practice, so having the const on the argument is better for future readers of your code than having to scan the whole function body for modifications to the argument.

And even if you follow the practice it's easy to modify a variable by mistake (the classic typo of = instead of == or passing the arg via non-const ref or pointer). The const argument in the implementation prevents this.

On the other hand const int argument in the declaration (if separate from definition) does not make sense.

Rafał Dowgird
  • 43,216
  • 11
  • 77
  • 90
0

In practice, there is no real benefits for scalars.

However, in theory it could help a compiler to perform additional optimizations, such as passing a reference to the constant instead of copying the double value.

Gabriel Cuvillier
  • 3,617
  • 1
  • 28
  • 35
  • I don't think it would save anything to pass by reference in this particular case. It is certainly preferable in case of more expansive objects such as strings etc... – Petr Dec 06 '11 at 21:35
  • 2
    Sure, but don't forget that double precision floating points are using FPU registers instead of traditional registers used for pointers and references. A compiler may use that trick to reduce the FPU load. – Gabriel Cuvillier Dec 06 '11 at 22:14