I have a class AP
template<typename T>
class AP : public std::auto_ptr<T>
{
typedef std::auto_ptr<T> Super;
public:
AP() : Super() { }
AP(T* t) : Super(t) { }
AP(AP<T>& o) : Super(o) { }
};
And a function to return it.
namespace AIR {
namespace Tests {
namespace
{
AP<A> CreateGraph()
{
AP<A> top(A::Create("xyz").release());
...
return top;
}
AP<A> top;
top = CreateGraph();
When I compile the code
AP<A> top;
top = CreateGraph();
I got this error message
no match for ‘operator=’ in ‘top = AIR::Tests::<unnamed>::CreateGraph()()’
I added this operator to the AP class, but it doesn't work.
AP<T>& operator=(AP<T>& o) { (*(Super*)this) = o; return *this; }
What's wrong with the class?
EDIT
top.reset(CreateGraph().release()) solved this issue.
CreateGraph() returns by value, thus a CreateGraph() function call is an rvalue.
Because the std::auto_ptr copy assignment operator takes its argument by non-const reference, the implicitly declared AP copy assignment operator takes its argument by non-const reference.
A non-const reference can only bind to an lvalue, hence the error.
As I explained in an answer to one of your previous questions, if you want to have std::auto_ptr-like copying (where the actual copy constructor takes its argument by non-const reference), you also need to implement something similar to std::auto_ptr_ref.
I explain how std::auto_ptr uses this helper class to allow copying of rvalues in the accepted answer to How could one implement std::auto_ptr's copy constructor?
Shouldn't it be?
AP<T>& operator=(const AP<T>& o)
What if you replace
AP<A> top;
top = CreateGraph();
to
AP<A> top(CreateGraph());
Related
I met this code and i dont know what is this, can someone explain to me?
template<class T> base{
protected:
T data;
public:
...
T&& unwrap() && { return std::move(data); }
operator T&&() && { return std::move(data); }
}
I know operator T&&() is a cast operator but i cant figure out what is the meaning of the bold && in:
operator T&&() &&
or
T&& unwrap() &&
The && and & qualifiers on a member function like that indicates the following:
The & qualified function will be called on lvalue instances of the object
The && qualified function will be called on rvalue instances of the object
Example:
#include <iostream>
class Example
{
private:
int whatever = 0;
public:
Example() = default;
// Lvalue ref qualifier
void getWhatever() & { std::cout << "This is called on lvalue instances of Example\n"; }
// Rvalue ref qualifier
void getWhatever() && { std::cout << "This is called on rvalue instances of Example\n"; }
};
int main()
{
// Create example
Example a;
// Calls the lvalue version of the function since it's called on an lvalue
a.getWhatever();
// Calls rvalue version by making temporary
Example().getWhatever();
return 0;
}
The output of this is:
This is called on lvalue instances of Example
This is called on rvalue instances of Example
Since in the first function call we are calling it on an lvalue instance of Example, but in the second call we are making it a temporary on which we call the function, invoking the rvalue qualified function.
I followed this tutorial to start to understand the move semantics and rvalue references in C++11.
At some point, he implements these two classes with the std::move in the move constructors explaining that
we pass the temporary to a move constructor, and it takes on new life
in the new scope. In the context where the rvalue expression was
evaluated, the temporary object really is over and done with. But in
our constructor, the object has a name; it will be alive for the
entire duration of our function. In other words, we might use the
variable other more than once in the function, and the temporary
object has a defined location that truly persists for the entire
function. It's an lvalue in the true sense of the term locator value
class MetaData
{
public:
MetaData(int size, const string& name)
: _name(name)
, _size(size)
{}
MetaData(const MetaData& other)
: _name(other._name)
, _size(other._size)
{
cout << "MetaData -- Copy Constructor" << endl;
}
MetaData(MetaData&& other)
: _name(move(other._name))
, _size(other._size)
{
cout << "MetaData -- Move Constructor" << endl;
}
~MetaData()
{
_name.clear();
}
string getName() const { return _name; }
int getSize() const { return _size; }
private:
string _name;
int _size;
};
class ArrayWrapper
{
public:
ArrayWrapper()
: _p_vals(new int[64])
, _metadata(64, "ArrayWrapper")
{}
ArrayWrapper(int n)
: _p_vals(new int[n])
, _metadata(n, "ArrayWrapper")
{}
ArrayWrapper(ArrayWrapper&& other)
: _p_vals(other._p_vals)
, _metadata(move(other._metadata))
{
cout << "ArrayWrapper -- Move Constructor" << endl;
other._p_vals = nullptr;
}
ArrayWrapper(const ArrayWrapper& other)
: _p_vals(new int[other._metadata.getSize()])
, _metadata(other._metadata)
{
cout << "ArrayWrapper -- Copy Constructor" << endl;
for (int i = 0; i < _metadata.getSize(); ++i)
_p_vals[i] = other._p_vals[i];
}
~ArrayWrapper()
{
delete[] _p_vals;
}
int* getVals() const { return _p_vals; }
MetaData getMeta() const { return _metadata; }
private:
int* _p_vals;
MetaData _metadata;
};
In the ArrayWrapper move constructor I tried to change std::move with std::forward<MetaData> and the code shows that if I call the ArrayWrapper move constructor this will call the MetaData move constructor, like the example with the std::move.
Of course if I don't use either std::move or std::forward the MetaData copy costructor will be called.
The question is, in this case, is there a difference between using std::move and std::forward? Why should I use one instead of the other?
is there a difference between using std::move and std::forward? Why should I use one instead of the other?
Yes, std::move returns an rvalue reference of its parameter, while std::forward just forwards the parameter preserving its value category.
Use move when you clearly want to convert something to an rvalue. Use forward when you don't know what you've (may be an lvalue or an rvalue) and want to perfectly forward it (preserving its l or r valueness) to something. Can I typically/always use std::forward instead of std::move? is a question you might be interested in here.
In the below snippet, bar would get exactly what the caller of foo had passed, including its value category preserved:
template <class T>
void foo(T&& t) {
bar(std::forward<T>(t));
}
Don't let T&& fool you here - t is not an rvalue reference. When it appears in a type-deducing context, T&& acquires a special meaning. When foo is instantiated, T depends on whether the argument passed is an lvalue or an rvalue. If it's an lvalue of type U, T is deduced to U&. If it's an rvalue, T is deduced to U. See this excellent article for details. You need to understand about value categories and reference collapsing to understand things better in this front.
The relevant std::forward and std::move declarations are:
template< class T >
T&& forward( typename std::remove_reference<T>::type& t );
template< class T >
typename std::remove_reference<T>::type&& move( T&& t );
For the former:
std::forward<MetaData>(other._metadata);
std::forward<MetaData> returns MetaData&&.
For the latter:
std::move(other._metadata);
//argument derived as lvalue reference due to forwarding reference
std::move<MetaData&>(other._name);
std::move<MetaData&> returns typename std::remove_reference<MetaData&>::type&&, which is MetaData&&.
So the two forms are identical for your example. However, std::move is the right choice here, as it shows our intent to unconditionally move the argument. std::forward can be used to unconditionally move, but the purpose of it is to perfect-forward its argument.
In the following example, I have two classes which are the same, except that the first uses a template.
template <typename T>
class Container {
const T t;
public:
Container(const T _t): t(_t) { }
const T get() {
return t;
}
};
class PersonContainer {
const Person& p;
public:
PersonContainer(const Person& _p): p(_p) { }
const Person& get() {
return p;
}
};
Here's the Person class referred to:
struct Person {
int age;
Person(int _age): age(_age) {};
};
When I pass an rValue to a function expecting a lValue, it works fine in the non-template class's constructor (since it's a constant param). However, for the templated classes it fails:
int main() {
PersonContainer personContainer(Person(50)); // works fine
Container<Person&> container(Person(50)); // error
cout << personContainer.get().age;
cout << container.get().age;
return 0;
}
The error message I get is:
no matching function for call to ‘Container<Person&>::Container(Person)’
I'm curious to find out why the templated class does not behave the same way as the regular class.
The problem is how the const binds to T.
What it ends up with is a const reference to T. References are const by default so that makes no difference. Meaning that your constructor expects a T& to which the temporary can't bind(see your other question).
What you were expecting is a reference to a const T.
T = Person&
(const T == Person& const == Person&) != const Person&
I hope this makes sense.
As a reply to your comment on the other answer, you should simply take Person as a template parameter and make your get function return const T&.
In addition, storing references might be dangerous as your "container" might outlive the actual object to which the reference points.
Container<Person&> container(Person(50));
You should remove & from type you are passing to template as it's irrelevant in this context.
Container<Person> container(Person(50));
Inside a templated class, I found the expression, *this = NULL What does such an expression mean ?
The following is its definition:
TYPE** getPtr()
{
*this = NULL;
return &m_pPtr;
}
where m_pPtr is type TYPE* in the template class.
Assignment operator:
// Assignment operator.
TYPE* operator =(TYPE *pPtr) {
if (pPtr == m_pPtr)
return pPtr;
m_pPtr = pPtr;
return m_pPtr;
}
Vishnu.
It's difficult to say what the point of such a statement is without seeing the actual code.
But it will probably be invoking an overloaded assignment operator. e.g.:
#include <iostream>
class X {
public:
void operator=(void *) {
std::cout << "Here!\n";
}
void foo() {
*this = NULL;
}
};
int main() {
X x;
x.foo();
}
It's attempting to assign 0 to the current object. It will call something like
operator=(void *);
Another possibility (as far as I know) is that there is a constructor in the object which takes a void* or similar type. Then it would construct an object and then copy-assign that.
T :: T(void *); // construct with the void *
T :: T(const T &); // copy assignment
Recently I have read that it makes sense when returning by value from a function to qualify the return type const for non-builtin types, e.g.:
const Result operation() {
//..do something..
return Result(..);
}
I am struggling to understand the benefits of this, once the object has been returned surely it's the callers choice to decide if the returned object should be const?
Basically, there's a slight language problem here.
std::string func() {
return "hai";
}
func().push_back('c'); // Perfectly valid, yet non-sensical
Returning const rvalues is an attempt to prevent such behaviour. However, in reality, it does way more harm than good, because now that rvalue references are here, you're just going to prevent move semantics, which sucks, and the above behaviour will probably be prevented by the judicious use of rvalue and lvalue *this overloading. Plus, you'd have to be a bit of a moron to do this anyway.
It is occasionally useful. See this example:
class I
{
public:
I(int i) : value(i) {}
void set(int i) { value = i; }
I operator+(const I& rhs) { return I(value + rhs.value); }
I& operator=(const I& rhs) { value = rhs.value; return *this; }
private:
int value;
};
int main()
{
I a(2), b(3);
(a + b) = 2; // ???
return 0;
}
Note that the value returned by operator+ would normally be considered a temporary. But it's clearly being modified. That's not exactly desired.
If you declare the return type of operator+ as const I, this will fail to compile.
There is no benefit when returning by value. It doesn't make sense.
The only difference is that it prevents people from using it as an lvalue:
class Foo
{
void bar();
};
const Foo foo();
int main()
{
foo().bar(); // Invalid
}
Last year I've discovered another surprising usecase while working on a two-way C++-to-JavaScript bindings.
It requires a combination of following conditions:
You have a copyable and movable class Base.
You have a non-copyable non-movable class Derived deriving from Base.
You really, really do not want an instance of Base inside Derived to be movable as well.
You, however, really want slicing to work for whatever reason.
All classes are actually templates and you want to use template type deduction, so you cannot really use Derived::operator const Base&() or similar tricks instead of public inheritance.
#include <cassert>
#include <iostream>
#include <string>
#include <utility>
// Simple class which can be copied and moved.
template<typename T>
struct Base {
std::string data;
};
template<typename T>
struct Derived : Base<T> {
// Complex class which derives from Base<T> so that type deduction works
// in function calls below. This class also wants to be non-copyable
// and non-movable, so we disable copy and move.
Derived() : Base<T>{"Hello World"} {}
~Derived() {
// As no move is permitted, `data` should be left untouched, right?
assert(this->data == "Hello World");
}
Derived(const Derived&) = delete;
Derived(Derived&&) = delete;
Derived& operator=(const Derived&) = delete;
Derived& operator=(Derived&&) = delete;
};
// assertion fails when the `const` below is commented, wow!
/*const*/ auto create_derived() { return Derived<int>{}; }
// Next two functions hold reference to Base<T>/Derived<T>, so there
// are definitely no copies or moves when they get `create_derived()`
// as a parameter. Temporary materializations only.
template<typename T>
void good_use_1(const Base<T> &) { std::cout << "good_use_1 runs" << std::endl; }
template<typename T>
void good_use_2(const Derived<T> &) { std::cout << "good_use_2 runs" << std::endl; }
// This function actually takes ownership of its argument. If the argument
// was a temporary Derived<T>(), move-slicing happens: Base<T>(Base<T>&&) is invoked,
// modifying Derived<T>::data.
template<typename T>
void oops_use(Base<T>) { std::cout << "bad_use runs" << std::endl; }
int main() {
good_use_1(create_derived());
good_use_2(create_derived());
oops_use(create_derived());
}
The fact that I did not specify the type argument for oops_use<> means that the compiler should be able to deduce it from argument's type, hence the requirement that Base<T> is actually a real base of Derived<T>.
An implicit conversion should happen when calling oops_use(Base<T>). For that, create_derived()'s result is materialized into a temporary Derived<T> value, which is then moved into oops_use's argument by Base<T>(Base<T>&&) move constructor. Hence, the materialized temporary is now moved-from, and the assertion fails.
We cannot delete that move constructor, because it will make Base<T> non-movable. And we cannot really prevent Base<T>&& from binding to Derived<T>&& (unless we explicitly delete Base<T>(Derived<T>&&), which should be done for all derived classes).
So, the only resolution without Base modification here is to make create_derived() return const Derived<T>, so that oops_use's argument's constructor cannot move from the materialized temporary.
I like this example because not only it compiles both with and without const without any undefined behaviour, it behaves differently with and without const, and the correct behavior actually happens with const only.