I am trying to reference an out argument of the mocked method getData. My problem is that "ControlData" has no copy constructor because it got deleted. As far as I understand, "SetArgReferee" does create an intermediate object before passing it by reference.
MOCK_METHOD1(getData, void(ControlData& par_rcl_ControlData));
ControlData loc_data;
EXPECT_CALL(loc_cl_control, getData(_)).WillOnce(SetArgReferee<0>(loc_data));
I have tried to create an custom action such as:
ACTION_P(SetArgRef, obj) { arg0 = &obj; }
But unfortunately this does not compile either. How can I pass an object directly on the mocked method?
Quoting form GoogleMock Cook Book:
SetArgPointee() conveniently makes an internal copy of the value you pass to it, removing the need to keep the value in scope and alive. The implication however is that the value must have a copy constructor and assignment operator.
Presumably the same applies to SetArgReferee. This means you need a custom action to move the object into that reference (without using copy constructor at any place).
Fortunately, later on there is a suggestion:
but how do we work with methods accepting move-only arguments? The answer is that they work normally, although some actions will not compile when any of method's arguments are move-only. You can always use Return, or a lambda or functor:
What you need is a lambda (or any function object) that will pass argument by move:
ControlData loc_data;
auto SetArgByMove = [&loc_data](auto& arg){arg = std::move(loc_data);};
EXPECT_CALL(loc_cl_control, getData(_)).WillOnce(Invoke(SetArgByMove));
This should compile and run without issues.
You could probably make a custom action as well, but not via ACTION_P macro - it also creates a copy of the object. You would have to write fully fledged action by creating a class that inherits from ActionInterface
Related
I noticed that when passing reference parameters to boost bind, those parameters won't act like references. Instead boost creates another copy of the member and the original passed in variable remains unchanged.
When I change the references to pointers, everything works ok.
My question is:
Is it possible to get references to work, or at least give a compiling error when it tries to use reference parameters?
The boost documentation for bind suggests that you can use boost::ref and boost::cref for this.
I ran into similar issue expecting a bind parameter to be passed by reference whenever the method used in the bind was declared to take a reference parameter. However this is NOT the case! You will need to explicitly wrap the bind parameter (that is to be passed by reference) in a boost::ref() or boost::cref() regardless of how the method is declared.
Example:
ClassA myClassAParameter
void Method(ClassA ¶m);
now, the following binding:
callback = boost::bind(&Method, myClassAParameter);
will actually make a COPY of the ClassA object (which i understand it is a temporary allocation and the called method should not keep a reference to it since this is not the reference of the actual object but to a copy of the object).
however, the following binding:
callback = boost::bind(&Method, boost::ref(myClassAParameter));
will not make a copy, but use a reference to create the bind object.
I want to ask one simple question which is making me confuse.
for example if I write in argument there is no reference &. but in the second case I have used & with rectangleType&, I am having confusion why we use this & when we can do it without this &. Where is this necessary and why we use it. My question is not about copy constructor.
rectangleType rectangleType::operator+
(const rectangleType rectangle)
Case 2:
rectangleType rectangleType::operator+
(const rectangleType& rectangle)
When you pass an object like rectangleType (or any other type) by value, you're making a copy of that object. This means:
Any changes made to the object by the function are not seen by the caller, since the changes are made on a copy, not the original object.
The act of copying the object incurs a performance cost.
Copying the object may not even be possible for some types.
So, pass by reference whenever:
You want the function to be able to modify the original object.
You want the code to run faster by not having to make a copy.
The object you're passing doesn't have a public copy constructor.
Pass by const reference whenever you don't need the function to be able to modify the original object.
For user-defined types, this essentially boils down to "pass by reference wherever possible."
How can you state that your question is not about copy construction if the answere is about it?
With a const reference no copy is made, this can be crucial for very large objects
There are classes wich explicitely dont provide a copy constructor, this way you can still pass them around.
So to conclude: You get benefits without disadvantages.
In the first method, it will receive a (complete) instance of rectangleType, that will be created using the copy constructor just to be passed as a parameter.
In the second method, it will receive a reference to an already existing instance; no copy will be made.
Can some body tell me the reason why we usually put const and & with some object which is passed in the constructor for example.
Book::Book(const Date &date);
The confusion that i have here is that usually & sign is used in the some function because the value is passed by reference and whatever changes happen to that variable in the function should reflect afterwards. But on the other hand const says that no assignment can be done to that variable.
If some body have some good idea about that please let me know the reason for that.
This is done to avoid an unnecessary copy. Take, for example, the following code:
Book::Book(Date date):
date_(date)
{
}
When you call this constructor it will copy date twice, once when you call the constructor, and once when you copy it into your member variable.
If you do this:
Book::Book(const Date &date):
date_(date)
{
}
date is only copied once. It is essentially just an optimisation.
The most common alternative is to pass by value:
Book::Book(Date date);
Passing by const reference prevents the parameter date from being copied when the parameter you pass is already a Date. Copying objects can be unnecessary, can be costly to perform, or it could result in a sliced object (and the incorrect results).
'Slicing' is basically demotion of an object's type via copy to its base. For a polymorphic type, this can actually change its behavior because the parameter would be copied as its base (Date), and then calls to its polymorphic interfaces would be different because the implementation has changed (e.g. its virtual methods would use the base's implementation instead).
It means that you pass the object via refrence (as you noted), but the object itself cannot be changed from the function (ctor in this case).
The reason for this could be:
you do not want to copy the full object, to make your code more efficient
you do not want to accidentially change the passed-in object
you want to be able to use the function with unnamed temporaries
you want to be able to pass objects that derive from the noted type (Date in this case)
For the third point, consider:
Book b(Date());
It's typically a performance optimization for input parameters. If you omit the '&' the parameter is accepted by value and the input object will have to be copied before being passed to the function. Passing by reference bypasses the copy.
In c++, when you have a parameter type of a function be something like const Type&, what you are doing is allowing a user to pass some value in by reference - A pointer to the value is implicitly passed in, but for ease of use, the compiler allows you to treat it as if it was a value.
In some cases, the compiler can also optimize it so that no pointer is used at all, and the function can refer directly to the memory of the value.
The reason that const is used is to safeguard yourself from altering memory that the user doesn't expect you to alter, and also to have it still work if the user passes in a const variable.
A const reference is a way of passing the data to the class without copying the data to a local copy, and still guaranteeing that the original object won't be modified by the function.
Why can we not the different build steps within the constructor itself.
if the build steps take arguments why can't they be provided as arguments to constructor and utilized within constructor to create the object.
AFAIK, in Builder pattern, the client which specific object to create; then what is the advantage in using a builder instead of a Constructor with arguments in the Class's object being created?
Oh! I get it. I was looking at the Wikipedia example and realized why Builder is helpful. It is helpful, when the client does not know which arguments to pass to the constructor as it is very complicated and hence cannot call the constructor directly and get the object. Consequently, he asks for help from the Concrete Builders who know what arguments to pass to constructors and hence get the object created.
Basically, if the client is the one who is mostly going to be passing the arguments to the constructor of the Class whose object is created, then Builder is not that helpful. It is perhaps better to use the prototype. On the other hand, if there is a small finite set of specific objects that can be created from the class by passing arguments to the constructor (or calling setters) to that class and if they are the ones that are frequently used, then it better to encapsulate this argument passing thingy in the Builder class and use them to create the objects for you.
Consider the following code snippet:
list<someClass>& method();
....
list<someClass> test = method();
What will the behavior of this be? Will this code:
Return a reference to the someClass instance returned by return value optimization from method(), and then perform someClass's copy constructor on the reference?
Avoid calling the copy constructor somehow?
Specifically, I have methods that are returning very large lists, and I want to avoid calling copy constructors on each return value.
EDIT: Erm, sorry, code compiles now...
The copy constructor will have to be called, because this code must make a copy: the method() function returns a reference to some object, a copy of which must be stored in the variable test.
Since you are returning a reference and not an object, there is no need for return value optimization.
If you do not want to make a copy of the list, you can make test a reference:
list<someClass>& test = method();
However, test will then refer to the original list, so any modifications made to test will also be made to the original list, and whenever the original list is destroyed, test will become invalid (which means you have to be more careful with object lifetimes).
There exists RVO. I am not sure if it applies here. Anyways it's one way to minimize copying.
http://en.wikipedia.org/wiki/Return_value_optimization
Well, you can't assign a list to someClass (unless you overloaded the assignment operator or copy constructor, and use the returned list to copy construct). If you didn't this shouldn't compile.
Looking at your code it is difficult to hazard a guess as to what you are trying to achieve here by returning the reference to a list and then making a copy of it.
Do consider the idea of returning an iterator to the list (or reference to the iterator) if possible (assuming that the list is not something local to a function etc).