Basically there are three classes I defined: paralelogram, point and line classes, and paralelogram has some vectors of points and lines, and in the paralelogram class I am defining a compute_area function as
double Paralelogram::compute_area() const
{
assert( !points.empty() );
double h = points[3].distance_to_line( lines[0] ); // point[3] is the last point in
// the vector however it is not a
// const object, and this gives a
// compile time error
double base = points[0].distance_to_point( points[1] );
return base*h;
}
Edit distance_to_line function is non-const
double Point::distance_to_line(Line& l)
{
return l.distance_to_point(*this);
}
deleting the const from the function definition and declaration solves the problem, however my reasoning, while coding, was compute_area does not modify the object so it can be const, however this is right as long as it operates on const objects and calls functions of const objects, right?
If the point objects are not const also, this is not valid anymore. And since they are not const that is the reason why it works after the const removal.
This is a puzzling point for me where I do not modify the object however the objects it uses gives the problem and moreover what I am thinking I am still not changing those objects as well, but apparently there is a confusion in my const understanding. One more thing, is this somehow related to the this pointer of the Paralelogram class if yes can you clarify?
In a const function, types of every member becomes const in such a way that you cannot modify them (unless they're declared mutable), nor can you call any non-const function using them.
It seems that in your code, distance_to_line is non-const function, but you're calling it from a const function, that means inside const function points[3] and points[0] becomes const object, so you cannot call non-const function (which I believe distance_to_line is) on const object.
--
EDIT:
You need to make distance_to_line a const function, and since this function calls distance_to_point, you've to make even distance_to_point const function.
To make a member function const, you don't need to make the member variables const as well. You just need to ensure that your const function does not modify any of the member variables of the class.
Have you tried making the distance_to_line() function const on the point class? If that works, you'll also probably need to make distance_to_point() const as well. If these aren't const, the compiler can't ensure that the calling function is also const.
Make distance_to_line() and distance_to_point() const and your error will go away.
By declaring the function const, you're also restricting your access to any members - they'll be treated as if they were const as well. Since you can't call a non-const member function on a const object, those calls will fail.
Related
I have a ClassA that has a private: vector<ClassB> vec. I'm filling the vector up in ClassA::fillVec().
Now i'd like to return the vector(by reference? so no copying) and i'd also like forbid any further changes using const.
What still confuses me is the syntax. What i have so far is
const std::vector<ClassB> &ClassA::fillVec(...) const {}
But I don't know if that is right. And even if it's right, I found this solution on the internet, so if anyone could explain why the two const
The first const means that the return type is const reference i.e. the vector may not be modified through the reference.
The const at the end means that the member function is not allowed to modify the (ClassA) object. It is therefore allowed to call that method on a const ClassA instance. This of course contradicts with the purpose of the function assuming it's supposed to modify the member; it should therefore not be const.
You want to return a const reference to prevent the user changing it; but the function itself can't be const, since it modifies a class member.
const std::vector<ClassB> &fillVec(<parameters>);
^ ^
const return value no const here
You would use the second const on member functions that aren't supposed to modify the object they're called on.
If I have the class member function:
bar* foo::get_value() const
{
return &_value;
}
the compiler will complain
cannot initialize a variable of type bar * with an rvalue of type const bar *
_value is not const in the class.
If I have the function:
bar* foo::get_value() const
{
return const_cast<bar *>(&_value);
}
It works just fine.
I thought that declaring a member function constant meant that you promise to not modify the internal contents of the class, but the operation & seems to return a constant pointer in const member functions. Why is this?
When you declare a function const, you are saying that this is a function that is permitted on both a non-const and const instance of the object. Because it can be invoked on a const instance, the function should not mutate the object. When you return a non-const reference to an internal object, you are providing the caller with a way of mutating the object's internal state indirectly. To fix this, return a constant object, instead.
In other words, instead of:
Bar* Foo::GetBar() const
Do:
const Bar* Foo::GetBar() const
Or, better yet:
const Bar& Foo::GetBar() const
As you've observed, const_cast allows you to undermine the const-ness of the object. In general, you should avoid using const_cast; using it is a code smell, and it undermines the intended const gurantees.
When an object instance is declared const, it's treated as if all its member variables were also const -- that is, except members which have been declared with the keyword mutable.
So, theoretically, you could declare _value as mutable, which would at least be slightly preferable to const_cast<>-ing your way round it. But it's still not ideal. The right way to do this is to provide two overloads:
const bar* foo::get_value() const
{
return _value;
}
bar* foo::get_value()
{
return _value;
}
(and better yet would be to use references or smart pointers rather than raw pointers).
The problem is the return type of the getter function. You are returning bar* instead of const bar*. The former would allow the caller of the get_value function to modify the object. But that's explicitly forbidden by your declaration of _value as const.
You can bypass that with const_cast, but it's incorrect. It's like telling the compiler "trust me, I know what I'm doing", but in this case, you don't. You have no control over what the calling code will do with the object. And if they try to modify it—bam, undefined behavior.
Make life simple on yourself, just make the getter return const bar*:
const bar* foo::get_value() const
{
return &_value;
}
Do note that the compiler error message essentially told you the change you need to make to your code.
A const member function works only on a const object. With a const object you cannot change its member variables. That is why the compiler does not allow you to make a non const pointer to a member variable of a const object.
String::~String() {
std::cout<<"String()" <<std::endl;
}
I wonder if this implementation of destructor is valid?
And another question about const member function qualifier, I know the const function can not change the variables in this class, it just read-only. If there is no other weird questions about it, I think I can understand it, but I saw some questions as following:
It allows the invocation of a non-const member function for the object pointed to by this
It guarantees that only mutable member variables of the object pointed to by this can be changed
It ensures that all constants remain invariable
It prevents inheritance
It allows changes to the state of the object pointed to by this
Based on my understanding, it is very hard to check which one is right, so I guess all of them are wrong?
The destructor is technically just another function, there doesn't seem anything wrong syntactically with this destructor to me, so it seems valid
That is all there is to const member functions, you cannot modify the data. These functions are automatically invoked by a const instance of the class. So if you have two functions with the same signature except for const-ness, it will chose the const version for const instances, and for non-const instances, it will depend on how you use it that determines which version is invoked
a) you cannot invoke non-const member functions within a const member function
b)Correct
c) correct
d) i'm unsure what you mean by preventing inheritance. IF you declare a function as virtual, const or not, it is inherited and can be overridden by subclasses
e) in const member functions, all data is considered const, unless declared a mutable.
Yes, that is a valid destructor.
const does not prevent inheritance. Nor does it bring about invariant behavior in the class's methods.
This question is actually multiple questions, though.
I recommend reading C++ FAQS.
I wonder if this implementation of destructor is valid?
There is nothing wrong with the destructor. But the question is: is that all you want to do in the destructor? Destructor is usually used to free the resources object holds when its alive; so it should free them when its going to die, so that others can use them. If it doesn't free them, then those resources will not be used by others as long as the program runs. Such a situation is usually referred to as Resource Leak, and if the resource is memory, its called Memory Leak.
Regarding question 2.
A nice way to think of member function cv qualifiers is to think of them as qualifiers on the 'this' pointer.
For example, if we wrote some C++ code in C:
class A
{
public:
void f1 ();
void f2 () const;
private:
int i;
};
This is the same as the following C code:
struct A
{
int i;
};
void f1 (A * const this); // Non const member
void f2 (A const * const this); // Const member
Another important thing to understand is that when you refer to a non static data member of a class, (*this). is implicitly added to it:
void A::f1 ()
{
i = 0; // This and the next line have the same meaning
(*this).i = 0;
}
When the member function is const, the this pointer is declared as pointing to a const object:
void A::f2 () const
{
(*this).i = 0; // Error '*this' is const, so cannot modify (*this).i
}
One of the conclusions from this, and something that people sometimes find is surprising, is that a const member function can still modify data pointed to by a member pointer. For example:
class A
{
public:
void f () const
{
*i = 0;
}
private:
int * i;
};
This looks wrong, but it's actually fine. (*this).i is const and so you would not be able to change what i points to, but i is still a pointer to a non const int and so we can modify the value pointed to by i.
I have a program and many of its classes have some operators and methods with the keyword const like the followings:
operator const char* () const;
operator char* ();
void Save(const char *name) const;
void Load(const char *name);
First: what does it mean const at the end of the method declaration?, is it the same like putting it at the beginning?
Second: Why would be a const version and a no const version of operator() needed?
Thanks in advance.
First: what does it mean const at the end of the method declaration?, is it the same like putting it at the beginning?
No. A const at the end means that the method may be called on objects that are declared const. A const at the beginning means that the returned value is const.
Second: Why would be a const version and a no const version of operator() needed?
The non-const version returns a char* which is not const. By modifying this char* you could then in fact modify the object (assuming the char* is a member of the object).
Since this is not allowed for const objects, there's an overload of operator() for const objects, so that a const char* is returned, so the object can't be modified through it.
'const' at the end tells the compiler that this method does not change any member variables - that it is safe to call this method on const instances. So, Save could be called on a const instance, since it won't change that instance. Load on the other hand, will change the instance so can't be used on const instances.
The const version of operator() passes back a const pointer, guaranteeing the buffer passed back won't change. Presumably that's a pointer into a instance variable of the class. For non-const instances, the other operator() passes back a non-const pointer. It would have to be a pointer to some memory that even if written to, wouldn't change the contents of the instance.
Also, look up the 'mutable' keyword sometime. Understanding that will help you understand this idea of const-correctness.
Member function constness. It means the function can not(*) modify any of your member variables. It's like putting a const in front of all your member variables for this one function call. It's a good guarantee for the clients of your class and may also aid in compiler optimisations.
(*) - see also the keyword mutable.
Putting const at the end of a method declaration is stating that the object itself, or this, is const instead of the return type.
C++ allows methods to be overloaded on const for complicated reasons. Not enough space to go into full detail here. But here are a couple of short ones.
Ocassionally there is value, or flat necessity, in having a method behave differently when it is called from a const type. The most straight forward example is when you want to return a const value from a const method and a non-const value from a normal method.
Whether or not this is const dramatically changes the binding of the internal method. To the point that it would essentially become two different method bodies. Hence it makes sense to break it up into 2 different methods.
One note in addition to the other answers: there is no operator() in your example.
operator const char* () const;
operator char* ();
are conversion operators, which mean that objects of the class can be implicitly converted to C-style strings, like
void f(const MyClass& x, MyClass& y) {
const char* x_str = x;
char* y_str = y;
}
A declaration and usage of operator(), which means you can use an object of the class type sort of like a function, would look like:
class MyClass {
public:
const char* operator() (int x, int y) const;
// ...
};
void g(const MyClass& obj) {
const char* result = obj(3, 4);
}
If you're looking for a great resource on C++ (including tips on using const correctly) try "Effective C++".
A useful site about this: JRiddel.org
In C++ when you declare a method const by putting it AFTER the method signature you are asserting that "This method will not change any non-mutable instance variables in the object it is being called on."
The const before the return value (e.g. the const in: operator const char*...") is declaring that it only returns a variable pointer to a const char*. (You may not change the contents of the char* but you can re-assign the pointer.) If you wrote "const char* const ..." it would be a constant pointer to constant characters. (The const comes after the star).
The multiple versions are useful so the compiler can understand this:
const char* my_const_var = <object_name>();
char* my_var = <object_name>();
Chris
You should refer to the "HIGH·INTEGRITY C++ CODING STANDARD MANUAL" for knowing when it is recommended to use the const modifier for class members:
High Integrity CPP Rule 3.1.8: Declare 'const' any class member function that does not modify the externally visible state of the object. (QACPP 4211, 4214)
Justification: Although the language enforces bitwise const correctness, const correctness should be thought of as logical, not bitwise. A member function should be declared const if it is impossible for a client to determine whether the object has changed as a result of calling that function. The 'mutable' keyword can be used to declare member data which can be modified in const functions, this should only be used where the member data does not affect the externally visible state of the object.
class C
{
public:
const C& foo() { return * this; } // should be declared const
const int& getData() { return m_i; } // should be declared const
int bar() const { return m_mi; } // ok to declare const
private:
int m_i;
mutable int m_mi;
};
Reference Effective C++ Item 21;Industrial Strength C++ 7.13;
Const at the beginning applies to the return value. Const at the end applies to the method itself. When you declare a method as "const" you are saying that you have no intention of modifying any of the member variables of the class in the method. The compiler will even do some basic checks to make sure that the method doesn't modify member variables. The const in the return value prevents the caller from modifying the value that is returned. This can be useful when you return pointers or references to data managed by the class. This is often done to avoid returning copies of complex data which could be expensive at run time.
The reason you have two different operators is that the "const" version returns a const pointer to what is probably data internal to the class. If the instance of the class is const, then chances are you want the data being return should also be const. The "non-const" version just provides a method that returns a modifiable return value when the caller has a non-const instance of the class.
I understand that the function is not allowed to change the state of the object, but I thought I read somewhere that the compiler was allowed to assume that if the function was called with the same arguments, it would return the same value and thus could reuse a cached value if it was available. e.g.
class object
{
int get_value(int n) const
{
...
}
...
object x;
int a = x.get_value(1);
...
int b = x.get_value(1);
then the compiler could optimize the second call away and either use the value in a register or simply do b = a;
Is this true?
const is about program semantics and not about implementation details. You should mark a member function const when it does not change the visible state of the object, and should be callable on an object that is itself const. Within a const member function on a class X, the type of this is X const *: pointer to constant X object. Thus all member variables are effectively const within that member function (except mutable ones). If you have a const object, you can only call const member functions on it.
You can use mutable to indicate that a member variable may change even within a const member function. This is typically used to identify variables used for caching results, or for variables that don't affect the actual observable state such as mutexes (you still need to lock the mutex in the const member functions) or use counters.
class X
{
int data;
mutable boost::mutex m;
public:
void set_data(int i)
{
boost::lock_guard<boost::mutex> lk(m);
data=i;
}
int get_data() const // we want to be able to get the data on a const object
{
boost::lock_guard<boost::mutex> lk(m); // this requires m to be non-const
return data;
}
};
If you hold the data by pointer rather than directly (including smart pointers such as std::auto_ptr or boost::shared_ptr) then the pointer becomes const in a const member function, but not the pointed-to data, so you can modify the pointed-to data.
As for caching: in general the compiler cannot do this because the state might change between calls (especially in my multi-threaded example with the mutex). However, if the definition is inline then the compiler can pull the code into the calling function and optimize what it can see there. This might result in the function effectively only being called once.
The next version of the C++ Standard (C++0x) will have a new keyword constexpr. Functions tagged constexpr return a constant value, so the results can be cached. There are limits on what you can do in such a function (in order that the compiler can verify this fact).
The keyword mutable on member variables allows for const functions to alter the state of the object at hand.
And no, it doesn't cache data (at least not all calls) since the following code is a valid const function that changes over time:
int something() const { return m_pSomeObject->NextValue(); }
Note that the pointer can be const, though the object pointed to is not const, therefore the call to NextValue on SomeObject may or may not alter it's own internal state. This causes the function something to return different values each time it's called.
However, I can't answer how the compiler works with const methods. I have heard that it can optimize certain things, though I'd have to look it up to be certain.
No.
A const method is a method that doesn't change the state of the object (i.e. its fields), but you can't assume that given the same input, return value of a const method is determined. In other words, const keyword does NOT imply that the function is one-to-one. For instance a method that returns the current time is a const method but its return value changes between calls.
The const keyword on a member function marks the this parameter as constant. The function can still mute global data (so can't be cached), but not object data (allowing for calls on const objects).
In this context, a const member function means that this is treated as a const pointer also. In practical terms, it means you aren't allowed to modify the state of this inside a const member function.
For no-side-effect functions (i.e., what you're trying to achieve), GCC has a "function attribute" called pure (you use it by saying __attribute__((pure))): http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
I doubt it, the function could still call a global function that altered the state of the world and not violate const.
On top of the fact that the member function can modify global data, it is possible for the member function to modify explicitly declared mutable members of the object in question.
Corey is correct, but bear in mind that any member variables that are marked as mutable can be modified in const member functions.
It also means that these functions can be called from other const functions, or via other const references.
Edit: Damn, was beaten by 9 seconds.... 9!!! :)
const methods are also allowed to modify static locals. For example, the following is perfectly legal (and repeated calls to bar() will return increasing values - not a cached 0):
class Foo
{
public:
int bar() const
{
static int x = 0;
return x++;
}
};