🔒 Locked
const
Advertisement
Original Post
Is there any reason writing const explicitly in case of this:
int Proc1(const int x) {
...
}
And this:
int Proc2(const TLARGE_STRUCTURE x) {
...
}
Or this:
const int Proc3() {
...
}
Any reasons (semantics or efficiency) should be considered.
Thx.
[edited by - xropi on October 28, 2002 6:00:20 AM]
Well, sometimes, but not really.
The only thing that it will do is to make sure that the implementor of the function do not think that the argument is passed by non-const-reference. The implementor will get a compiler error if he/she/it tries to alter the argument, but as it is a copy of the original variable that should not really matter. It also makes it impossible for the implementor to access non-const methods of the argument.
The only thing that it will do is to make sure that the implementor of the function do not think that the argument is passed by non-const-reference. The implementor will get a compiler error if he/she/it tries to alter the argument, but as it is a copy of the original variable that should not really matter. It also makes it impossible for the implementor to access non-const methods of the argument.
quote:
Original post by dMDI
You write const before a parameter when passing by reference to guarantee that the function does not alter the parameter, and simply uses references as an efficient mechanism for passing the parameter.
For example:
void Blah (const Foo& data) {
// Function that doesn''t modify data
}
It''s ok, I use that form. I just can''t imagine what are Proc1, Proc2, Proc3 for in my example.
Passing variables by reference are more efficient if the size of the variable are greater than the size of a pointer (4 bytes in 32-bit OS:es). Passing by reference for variables which size are less than the size of a pointer could be less efficient, depending on your OS and calling convension and other thingies.
dalleboy: that''s not the question.
what''s the point of ''const int''?
are compiler implementors allowed to optimise it away?
what''s the point of ''const int''?
are compiler implementors allowed to optimise it away?
Adding const to a value passed (or returned) by reference isn''t worth worrying about. The idea of const is to enforce that a parameter must not be changed as a side-effect of calling a function. If you pass the parameter by value, it shouldn''t matter, since the callee will construct a local copy and no change will be apparent from the caller code.
quote:
Original post by petewood
are compiler implementors allowed to optimise it away?
No. "const" is a compile-time feature - i.e. attempts to modify const qualified values are required to induce a diagnostic and render the program ill-formed. If the programmer states she wants const, the compiler must observe that requirement. Once the program is compiled there is no concept of const, so nothing will be present within the compiler output.
quote:
Original post by SabreMan
Adding const to a value passed (or returned) by reference isn''t worth worrying about. The idea of const is to enforce that a parameter must not be changed as a side-effect of calling a function. If you pass the parameter by value, it shouldn''t matter, since the callee will construct a local copy and no change will be apparent from the caller code.
So:
int Proc1(const int x) {
...
}
only restricts the programmer. (because x cannot be changed while it won''t cause any errors)
What about:
const int Proc3() {
...
}
What''s the point of this? (nothing -- I think)
But this:
const int &Proc4() {
...
}
has meaning for me.
quote:
Original post by xropi
What about:
const int Proc3() {
...
}
What''s the point of this? (nothing -- I think)
Again, it''s return by-value, so it''s of no real benefit. In fact, there are pathological cases where STL algorithms can assume various (member) functions return by non-const value. I can''t be any more specific without looking up the details, which I can''t be bothered to do right now. Hey, it''s Monday!
quote:
But this:
const int &Proc4() {
...
}
has meaning for me.
Yup. If you think in terms of member functions, doing this can bypass access control by allowing direct modification of private variables. Not nice!
quote:
Original post by Deyja
Const also allows the compiler to make some memory optimizations. For instance, if you pass something by value and const, the compiler doesn''t bother making a copy, because it knows it won''t be changing anyway.
It can''t be sure of that...
void foo(const int i)
{
int& non_const_i = const_cast<int&>(i);
non_const_i = 10;
}
int main()
{
int val = 0;
foo(val);
}
class C
{
public:
C()
: counter_(0)
{}
void foo() const
{
++counter_;
}
private:
mutable int counter_;
};
void foo(const C c)
{
c.foo();
}
int main()
{
const C c;
foo(c);
}
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement