To bother or not to bother... "const" as function argument
Quote:Original post by Genjix
and a compiler also optimizes when it sees const, btw
Not very often does optimization occur from the use of const. See GOTW for reasons why.
Quote:Original post by Unwise owl
Let's say you have a very simple function like this:
*** Source Snippet Removed ***
I know the latter example is more correct by definition, yet I never tend to use consts for function arguments. Why? Because they're just one more thing to think of. If I pass something by reference, I may suddenly realize I need to modify it, and then I must go back to the prototype. Either that, or typing "const " involves pressing 6 extra buttons on the keyboard for no immediate gain. Multiply this by the number of function arguments that should be constant in your program and you get into huge numbers quite quickly (then again, so is programming all other code already).
I've seen professional code that ignores consts completely. I've seen posters at GameDev advoating why you shouldn't ignore them. Discuss!
Use const when you should not when you can.
if the function doesn't change the object i also prefer to use this like:
//or like this:
void f(const SSomeStruct& obj) const
{
std::cout << obj.x << std::endl;
}
for 2 reason:
1- const parameter ensure that the object never change through this function
and it acts as a read-only argument so you can give access to critical objects
to friends using this style ( i mean friend accessor not boddies).
2- the second const optimise your function if you have a good compiler.
non of c++ elements are redundant ,all are good!
cheers
Quote:Original post by Nitage
If const_cast isn't uses, foo1 and foo2 provide a guarentee the the original object passed in remains the same. foo3 doesn't.
foo1 and foo3 both pass by value. The original object will not be modified.
Whether the local copy can be modified or not is irrelevant. Whether the object contains pointers or not is equally irrelevant.
I think using const here is important for future readability. When I see void f(Whatever& w) in an interface, I assume that w will be modified by the function, so I take the necessary precautions in the caller. When I see void f(const Whatever& w), I can be sure the pass-by-reference is just for performance.
I'm sometimes lax on comments, and consting arguments helps me remember/work out what a function does.
Here's an example of a possibly hard to find bug when passing by value
If foo had been const, this wouldn't compile (and the compiler would tell you where the problem is), but it compiled for me without warnings on g++ and outputs:
true
true
when you probably meant it to output:
true
false
Newbies tend to write code like this and it can happen pretty easily when you're really tired (or have been in front of the keyboard for more than 6 hours straight - more or less depending on the person). I usually think of the extra 6 keypresses as worthwile.
[Edited by - Will F on June 11, 2005 5:43:47 PM]
#include <iostream>using namespace std;void a(bool foo){ if (foo == true) cout << "true" << endl; else cout << "false" << endl;}void b(bool foo){ if (foo = true) cout << "true" << endl; else cout << "false" << endl;}int main(){ a(true); b(false); return 0;}
If foo had been const, this wouldn't compile (and the compiler would tell you where the problem is), but it compiled for me without warnings on g++ and outputs:
true
true
when you probably meant it to output:
true
false
Newbies tend to write code like this and it can happen pretty easily when you're really tired (or have been in front of the keyboard for more than 6 hours straight - more or less depending on the person). I usually think of the extra 6 keypresses as worthwile.
[Edited by - Will F on June 11, 2005 5:43:47 PM]
Quote:Original post by Unwise owl
I've seen professional code that ignores consts completely.
The Doom 3 SDK apparently doesn't use the standard library, this doesn't necessarily mean you shouldn't.
While it seems like the extra 6 key presses add up, as your projects get larger and larger those key presses become less and less significant, and it can help you prevent some stupid bugs, especially when you're passing by reference.
Here's another Guru of the Week article you might like.
My general experience is that I've been forced to go through and change pointer arguments to const too often, so it's a good habit that may save you from headaches later.
I haven't yet made a pointer argument const and then later needed to make it non-const.
I haven't yet made a pointer argument const and then later needed to make it non-const.
const correctness helps make our code 'more' type safe. this is part of the beauty of c++. the compiler can check for more then just fat fingered syntax errors. it can tell us when our design makes no sense. for example:
let's say my algorithms in Y's other functions are under the assumption that no one else (other them Y itself) can mess with m_x. under this assumption i can make my code go faster (maybe i don't have to check the value of X::i as much, who knows). in the above code the compiler is going to tell me i'm breaking my own rule.
_ugly
class X { int i; public: void mutate() { ++i; }};class Y { X m_x; public: const X & get_x () const { return m_x; } // more code here};void foo ( X & x ) { x.mutate(); }int main () { Y y; foo( y.get_x() ); // OOPS! return 0;}
let's say my algorithms in Y's other functions are under the assumption that no one else (other them Y itself) can mess with m_x. under this assumption i can make my code go faster (maybe i don't have to check the value of X::i as much, who knows). in the above code the compiler is going to tell me i'm breaking my own rule.
_ugly
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement