I wrote the following code:
class MyObjectHolder {
public:
std::vector<int> getMyObject() const {
return myObject;
}
private:
std::vector<int> myObject;
};
At some point of my program I attempt to use the getMyObject method and use only const methods on the retrieved object:
const std::vector<int> myObject = myObjectHolder.getMyObject();
myObject.size();
int a = myObject.front();
Now, is it possible that the compiler will optimize this code so that no copies of the std::vector<int> are done?
Is it somehow possible that the compiler determines that I'm only using the const methods on the retrieved object (and let's assume there is no mutable nonsense happening behind it) and it would not make any copies of the objects and perform these const operations on the private member of the MyObjectHolder instead?
If yes, would it be possible if I didn't explicitly declare the const std::vector<int> myObject as const?
If no, what are the reasons not to do this? In which cases this optimization would be to hard to implement / deduce that it's possible and correct here / etc... ?
Now, is it possible that the compiler will optimize this code so that no copies of the std::vector<int> are done?
No, the compiler doesn't know what callers will do with that object unless you are making use of global optimization over all code that uses the object (the compiler can't generally make assumptions about its use; moreover if object is exported from a dll it can't make any assumption at all).
If yes, would it be possible if I didn't explicitly declare the const std::vector myObject as const?
No, anyway the conversion from non-const to const could be implicit.
If no, what are the reasons not to do this? In which cases this optimization would be to hard to implement / deduce that it's possible and correct here / etc... ?
It's an optmiziation that should be done inside getMyObject() but the compiler can't be sure that callers won't cast away the const. Actually this is a very old debate about the use of const, usually I think it's more clear to always think about const as something for programmers and not for compilers.
I would suggest to use
const std::vector<int>& getMyObject() const {
return myObject;
}
It would return the constant reference of myObject without copy that.
And use the result with
const std::vector<int>& myObject = myObjectHolder.getMyObject();
It is possible Copy Elision and Return Value Optimization will kick in. If you use C++ compiler with C++11 support, then you may get it optimised by move semantics.
I'd recommend to read the excellent article Want Speed? Pass by Value by Dave Abrahams with discussion in the comments below it.
However, for details you should refer documentation of your C++ compiler.
Related
I'm working on some code in which a variable of type std::vector<double> is declared, before the value is specified. I can't define the value together with declaration, because it takes many lines of code to set the value. The thing is that this variable is a constant in essence, meaning it shouldn't be modified once it's set. However, it can't be declared const.
One way is to create another variable which is const and copy the value into it. const std::vector<double> a(b); would do, and use a instead of b in the program. However, my variable can be large and I wish to learn a way other than having to perform copying.
Any suggestions from you guys?
You may create a function to initialize it. In worst, you have a move. at best you have (N)RVO (return value optimization).
std::vector<Object> CreateBigVector();
And then
const std::vector<Object> myObject = CreateBigVector();
One way is to create a function
std::vector<Object> CreateYourVector();
and use it to initialise
const std::vector<Object> vec = CreateYourVector();
Another (technically a variation) is to create a helper class that contains your vector, and do all the work in a constructor
class Helper
{
std::vector<Object> vec;
public:
Helper()
{
// initialise your vector here
};
const std::vector<Object> &TheVec() const {return vec;};
};
const Helper helper;
The above techniques can be combined, for example change the constructor
Helper() : vec(CreateYourVector()) {};
These techniques can also be mixed with others, such as the singleton pattern.
I think the problem is about scoping. You have to separate your problem into two different scopes:
a scope where you build up your vector
a (or others) scope(s) where you use it
In the scope where you build up your vector, it logically isn't a const variable. Once you have built it, you want it not to be changed anymore. So you may want to refer to it through a const &.
I'd go this way:
define a function std::vector<double> build_up()
inside build_up, you define a non-const vector and you can build it
when you're done, you can return it by value (RVO will avoid any copy)
refer to the object returned by build_up() as a const object
I.e.
const std::vector<double> v = build_up();
In c++11, you can use the initial list to define a const vector. I think it is a easiest way. Try it: const vector<double> = {1.0, 2.0, 3.0};. It will not take many lines of code to set the value. I hope this can help you.
The traditional approach would be to only expose a handle that enforces constness and avoids making expensive copies outside the context where the vector is created and initialized. Such handle would be a const pointer or reference.
Since you are using std::vector you can benefit from modern c++ facilities, since std::vector supports features like move semantics off-the-shelf.
In particular, I suggest you to budget some time to have a look at:
move semantics
smart pointers
which upgrade the traditional way of passing around raw pointers. They enforce ownership semantics (which context owns the object) and allow you to express your intentions in a very precise way through the code.
As far as I know , making constant functions in a class is useful for read/write compiler optimizations.
A constant function within a class means that the class members will remain constant during the execution of the function.
However, you can bypass this by const casting the implicit parameter (ofc this is a very bad practice).
My questions is as follows :
What pitfalls can the following code cause (especially in terms of performance unrelated to thread synchronization) ?
int myClass::getSomething() const
{
myClass* writableThis = const_cast<myClass*>(this);
writableThis->m_nMemberInt++;
...
return m_nSomeOtherUnchangedMember;
}
Another related question :
Is the behavior compiler/platform/os specific ?
I would also very much appreciate if someone could explain the magic under the hood when such a code is compiled/executed (I'm speculating that the CPU is making out-of-order optimizations based on the fact that the function is const , and not respecting this during actual execution should have some side effects).
EDIT :
Thank you for clarifying this for me. After further research all the received answers are correct but I can accept only one :).
Regarding the const qualifier being used solely for syntax corectness , I believe this answer is both right and wrong, the correct way to state this (imho) would be that it is used mostly for syntax corectness (in a very limited number of scenarios it can produce different / better code ). References : SO Related question , related article
The const_cast<T>(this) trick is potentially unsafe, because the user of your member function may run into undefined behavior without doing anything wrong on their side.
The problem is that casting away const-ness is allowed only when you start with a non-const object. If your object is constant, the function that casts away its const-ness and uses the resultant pointer to change object's state triggers undefined behavior:
struct Test {
int n;
Test() : n(0) {}
void potentiallyUndefinedBehavior() const {
Test *wrong = const_cast<Test*>(this);
wrong->n++;
}
};
int main() {
Test t1;
// This call is OK, because t1 is non-const
t1.potentiallyUndefinedBehavior();
const Test t2;
// This triggers undefined behavior, because t2 is const
t2.potentiallyUndefinedBehavior();
return 0;
}
The trick with const_cast<T>(this) has been invented for caching values inside member functions with const qualifier. However, it is no longer useful, because C++ added a special keyword for this sort of things: by marking a member mutable you make that member writable inside const-qualified methods:
struct Test {
mutable int n;
Test() : n(0) {}
void wellDefinedBehavior() const {
n++;
}
};
Now the const member function will not trigger undefined behavior regardless of the context.
The CPU doesn't know anything about const, which is a C++ keyword. By the time the compiler has transformed the C++ code to assembly, there's not much left of that.
Of course, there's a real possibility that the generated code is entirely different because of the const keyword. For instance, the const version of some operator[] may return a T object by value whereas the non-const version must return a T&. A CPU doesn't even know what function it's in, or even assume the existence of functions.
My answer is to use the storage class mutable for any thing which need to be modified in const methods.
It's built into the language, so there are several benefits. It's a tighter control for how const methods modify data members. Other developers will know these data members will change in const methods. If there are any compiler optimizations, the compiler will know to do the right thing.
class myClass {
private:
int m_nSomeOtherUnchangedMember;
mutable int m_nMemberInt;
…
public:
int getSomething() const;
…
};
int myClass::getSomething() const
{
m_nMemberInt++;
…
return m_nSomeOtherUnchangedMember;
}
As far as I know , making constant functions in a class is useful for read/write compiler optimizations.
No. We use const methods to enforce semantic guarantees, not to allow optimizations (with the possible exception of avoiding copies).
What pitfalls can the following code cause
Firstly, it can break program semantics.
For example, std::map nodes store std::pair<const Key, T>, because the Key shouldn't mutate after it has been inserted. If the key changes value, the map sorting invariant is incorrect, and subsequent find/insert/rebalance operations will misbehave.
If you call a const-qualified method on this const key, and that method changes the Key in a way that affects how it compares, then you've cunningly broken the map.
Secondly, it can kill your program. If you have a const object overlaid on a genuinely read-only address range, or you have a statically-initialized const object in the read-only initialized data segment, then writing to it will cause some kind of protection error
As other stated the const-correctness was designed as a help for the programmers and not an help for the optimizer. You should remember 4 things:
1. const references and const methods are not faster
2. const references and const methods are not faster
3. const references and const methods are not faster
4. const references and const methods are not faster
More specifically the optimizer simply completely ignores const-ness of references or of methods because const doesn't really mean in that context what you are thinking.
A const reference to an object doesn't mean that for example during the execution of a method the object will remain constant. Consider for example:
struct MyObject {
int x;
void foo() const {
printf("%i\n", x);
char *p = new char[10];
printf("%i\n", x);
delete[] p;
}
};
the compiler cannot assume that x member didn't mutate between the two calls to printf. The reason is that std::operator new global allocator could have been overloaded and the code could have regular non-const pointer to the instance. Therefore it's perfectly legal for the global allocator to change x during the execution of foo. The compiler cannot know this is not going to happen (the global allocator could be overloaded in another
compilation unit).
Calling any unknown code (i.e. basically any non-inlined function) can mutate any part of an object, being in a const method or not. The const method simply means that you cannot use this to mutate the object, not that the object is constant.
If const correctness is really an help for the programmers is another question on which I personally have a quite heretic point of view, but that's another story...
sorry for such a long question but I try to be as clear as possible. This somehow follows my previous question about strings in C++. I'm trying to figure out how I could return std::string from a function without redundant memory allocations, without relying on NRVO. The reasons why I don't want to rely on NRVO are:
it is not supported by the compiler we currently use
even when it is supported it might not always be enabled in Debug mode
it might fail in some cases (example)
Please note that I need a C++03 compatible solution (no C++0x rvalue references thus, unfortunately...)
The simplest way do this is pass-by-reference and do std::swap, like this
void test(std::string& res)
{
std::string s;
//...
res.swap(s);
}
But it is more natural and often more convenient to return by value than pass by reference, so what I want to achieve is this:
std::string test()
{
std::string s;
//...
return SOMETHING(s);
}
Ideally it would just do a swap with the "return value", but I don't see how to do this in C++. There is auto_ptr already which does move instead of copy, and I could actually use auto_ptr<string>, but I'd like to avoid dynamically allocating the string object itself.
My idea is to somehow "tag" a string object that it is being returned from a function to permit moving its data when a copy constructor is called on return. So I ended up with this code, which does exactly what I want:
struct Str
{
struct Moveable
{
Str & ref;
explicit Moveable(Str & other): ref(other) {}
};
Str() {}
Str(const std::string& other) : data(other) {} // copy
Str(Moveable& other) { data.swap(other.ref.data); } // move
Moveable Move()
{
return Moveable(*this);
}
std::string data;
};
Str test()
{
Str s;
//...
return s.Move(); // no allocation, even without NRVO
}
So... Does all this make sense, or there are some serious issues that I'm missing? (I'm not sure if there is no lifetime issue for example). Maybe you have already seen such idea in a library (book, article...), and could give me a reference to it?
EDIT: As #rstevens noticed, this code is MSVC-specific and won't compile under g++ which does not like the non-const temporary. This is an issue, but let's just assume this implementation is MSVC-specific.
The implementation of boost uses move semantics emulation internally for libraries like Boost.Thread. You may want to look at the implementation and do something similar.
Edit: there is actually an active development of a library Boost.Move, so you can already start using it.
Did you check this code on g++?
Since you call Str(Movable &) with a temporary object (the one returned by s.Move())!
This is not standard's compliant and not supported by g++. It is supported by MSVC! (MS calls this a feature...).
Have you actually determined that returning by value is a performance problem in your application? That seems like the simplest/easiest way to go, and when you upgrade to a more modern compiler you can use rvalue references.
I can't answer the question regarding the destruction order of s vs the Movable's reference. You could, for your compiler, put code in the various constructors and destructors to see what the order is. Even if it looks ok I'd still consider using one of the normal patterns you outlined though just to prevent reader confusion and possibly breaking on an alternate compiler.
In RAII, resources are not initialized until they are accessed. However, many access methods are declared constant. I need to call a mutable (non-const) function to initialize a data member.
Example: Loading from a data base
struct MyClass
{
int get_value(void) const;
private:
void load_from_database(void); // Loads the data member from database.
int m_value;
};
int
MyClass ::
get_value(void) const
{
static bool value_initialized(false);
if (!value_initialized)
{
// The compiler complains about this call because
// the method is non-const and called from a const
// method.
load_from_database();
}
return m_value;
}
My primitive solution is to declare the data member as mutable. I would rather not do this, because it suggests that other methods can change the member.
How would I cast the load_from_database() statement to get rid of the compiler errors?
This is not RAII. In RAII you would initialize it in the constructor, which would solve your problems.
So, what you are using here is Lazy. Be it lazy initialization or lazy computation.
If you don't use mutable, you are in for a world of hurt.
Of course you could use a const_cast, but what if someone does:
static const MyClass Examplar;
And the compiler decides it is a good candidate for Read-Only memory ? Well, in this case the effects of the const_cast are undefined. At best, nothing happens.
If you still wish to pursue the const_cast route, do it as R Samuel Klatchko do.
If you thought over and think there is likely a better alternative, you can decide to wrap your variable. If it was in class of its own, with only 3 methods: get, set and load_from_database, then you would not worry about it being mutable.
You are basically implementing a caching mechanism. Personally I think it's OK to mark cached data as mutable.
As Matthieu already pointed out, what you're trying to do here has little (if anything) to do with RAII. Likewise, I doubt that any combination of const and mutable is really going to help. const and mutable modify the type, and apply equally to all access to an object of that type.
What you seem to want is for a small amount of code to have write access, and anything else only read access to the value. Given the basic design of C++ (and most similar languages), the right way to do that is to move the variable into a class of its own, with the small amount of code that needs write access as part of (or possibly a friend of) that class. The rest of the world is given its read-only access via the class' interface (i.e., a member function that retrieves the value).
The (presumably stripped down) MyClass you've posted is pretty close to right -- you just need to use that by itself, instead of as part of a larger class with lots of other members. The main things to change would be 1) the name from MyClass to something like lazy_int, and 2) (at least by my preference) get_value() should probably be renamed to operator int(). Yes, m_value will probably need to be mutable, but this doesn't allow other code to write the value, simply because other code doesn't have access to the value itself at all.
Then you embed an object of that type into your larger class. The code in that outer class can treat it as an int (on a read-only basis) thanks to its operator int(), but can't write it, simply because the class doesn't give any way to do so.
[ LOOK MA! NO CASTS! :)) ]
struct DBValue
{
int get_value();
private:
void load_from_database();
int value;
};
struct MyClass
{
MyClass(): db_value(new DBValue()) {}
~MyClass() { delete db_value; }
int get_value() const;
private:
DBValue * const db_value;
};
int MyClass::get_value() const
{
return db_value->get_value(); // calls void load_from_database() if needed
}
The idea is to have a politically correct MyClass with const methods not mutating anything but calling both const and non-const methods of aggregated objects via const pointers.
Don't use const_cast here, or you're asking for trouble. Using mutable in this case shouldn't be a problem, but if the profiler didn't suggest otherwise then I think users would be less surprised to see an object that is expensive to construct than an accessor method that is expensive to call the first time.
If your method changes the state of the object (e.g. by changing the state of the underlying database), then the method should not be const. In that case you should have a separate, non-const load-method, that has to be called before the const getter can be called.
This method would require neither const_cast not mutable, and would make the potentially expensive operation explicit.
I have a place in the code that used to say
const myType & myVar = someMethod();
The problem is that:
someMethod() returns const myType
I need to be able to change myVar later on, by assigning a default value if the object is in an invalid state. So I need to make myVar to be non-const.
I assume I need to make myVar be non-reference as well, right? E.g. myType myVar?
What is the C++ "correct" way of doing this const-to-nonconst? Static cast? Lexical cast? Something else?
I may have access to boost's lexical cast, so I don't mind that option, but I'd prefer the non-boost solution as well if it ends up i'm not allowed to use boost.
Thanks!
You probably don't need any cast. If you can copy a T, then you can also copy a T const, pathological cases excluded. The copy of the T const need not be a T const itself.
myType myVar = someMethod(); // Creates a non-const copy that you may change.
I wouldn't use the const_cast solutions, and copying the object might not work. Instead, why not conditionally assign to another const reference? If myVar is valid, assign that. If not, assign the default. Then the code below can use this new const reference. One way to do this is to use the conditional expression:
const myType& myOtherVar = (myVar.isValid() ? myVar : defaultVar);
Another way is to write a function that takes a const reference (myVar) and returns either myVar or defaultVar, depending on the validity of myVar, and assign the return value from that to myOtherVar.
A third way is to use a const pointer, pointing it at either the address of myVar or the address of the default object.
const_cast<type without const>()
But, does someMethod() really return const myType? If so, you are making a reference to a temporary -- it will be destroyed and your reference will be bad. Change myVar to non-ref (so it copies) -- no need to declare it const in that case. Or, if someMethod() returns a reference, use the const_cast if you must (but you are changing something that someMethod thought wouldn't change).
There's no "C++" way (not only to this, but to anything).
The bad way is to use a const_cast, but the behavior will then be undefined (read: don't do that).
What you should do is copy the object and then modify the copy. It's the only proper way to deal with immutable objects.
Try the following
myType& mutableMyVar = const_cast<myType&>(myVar);
In general removing const is a bad idea though. The caller method returned you a reference to a variable it believes will be treated as const. If you violate this assumption by removing the const and modifying the variable you could put either object into a valid state.
It may be legal in your particular case but in general this is something to be avoided
You can creat an object from the const object using copy constructor or something assignment operator and then modify it.
But I think you would be better off seeing why the function was returning const type in the first place. There would have been a reason why it was declared const. If you are very sure that that is what you wanted, you can always const_cast away the constness like this:
T obj1 = const_cast<T&> (obj);
What is the C++ "correct" way of doing this const-to-nonconst? Static cast? Lexical cast? Something else?
There is no C++ way. For one reason or another, the author of that class decided that you should not be able to modify the instance through this method.
If you were the author, you could make it return a non-const reference. But those are still suspicious, unless the class really has no business hiding it from you (e.g like vector doesn't hide what it holds for you, and just hides how it holds stuff for you).
A better way (depending on what this is all about) might also be not to expose members for external manipulation, but rather provide a method that does this manipulation for you. For example:
class BadPosition
{
int x, y;
public:
int& get_x() { return x; }
int& get_y() { return x; }
//...
};
BadPosition p;
p.get_x() += 1;
p.get_y() += -1;
class BetterPosition
{
int x, y;
public:
void move(int x_inc, int y_inc) { x += x_inc; y += y_inc; }
//...
};
BetterPosition p;
p.move(1, -1);
If you need this to put the class in a valid state later, then perhaps consider making its constructor do that. If you cannot do that, at least provide an Init() method, so as not to make such a complicated class rely entirely on being externally manipulated into something usable.
There may be of course other ways not requiring a cast, e.g you could create a copy, modify that, and then use the modified copy to replace the whole instance with another one (assuming this is enough to construct it):
X x;
...
Y y = x.get();
y.modify();
x = X(y);
Edit: So the class returns by value? In this case there should be no way to modify the instance in the class, since all you get is a copy in the first place. You can reference that with a const reference, but even if you cast away constness from that reference, you are still referencing a temporary.
My reply above assumed it returned a const reference, since that would seem a more sensible thing to do (I haven't seen people often return by const value, although probably there are those who strongly recommend it).