When running the following code:
struct Copy
{
Copy() {std::cerr << __PRETTY_FUNCTION__ << std::endl;}
Copy(const Copy & other) {std::cerr << __PRETTY_FUNCTION__ << std::endl;}
Copy & operator=(const Copy & other) {std::cerr << __PRETTY_FUNCTION__ << std::endl; return *this;}
Copy(Copy && other) {std::cerr << __PRETTY_FUNCTION__ << std::endl;}
Copy & operator=(Copy && other) {std::cerr << __PRETTY_FUNCTION__ << std::endl; return *this;}
~Copy() {std::cerr << __PRETTY_FUNCTION__ << std::endl;}
};
char buffer[1024];
template <typename Type>
Type * push(Type value)
{
return new(buffer) Type(std::move(value));
};
int main()
{
push(Copy());
return 0;
}
I get the following output:
Copy::Copy()
Copy::Copy(Copy &&)
Copy::~Copy()
Is there anyway to elide the move constructor?
I was hoping that with -O3, it would be constructed in place, but by my testing, that doesn't seem to be the case.
Is there anyway to elide the move constructor? [...] I was hoping that with -O3, it would be constructed in place,
Well, you're explicitly calling the move constructor... and the object is being constructed in-place in buffer. Why do you expect the move constructor call to be elided?
template <typename Type>
Type * push(Type value)
{
// invokes `Type::Type(Type&&)`
// vvvvvvvvvvvvvvvvvvvvvv
return new(buffer) Type(std::move(value));
// ^^^^^^^^^^^^^^^^
// casts `value` to `Type&&`
};
Your question would make more sense if you were trying to construct Copy with a value of some other type. E.g.:
struct Copy
{
Copy(int) { std::cout << "INT\n"; }
// ... other ctors ...
};
template <typename Type, typename Arg>
Type * push(Arg x)
{
return new(buffer) Type(std::move(x));
};
int main()
{
push<Copy>(1);
}
The code above prints:
INT
No move/copy constructor is invoked.
live example on wandbox
I do not think you can do this. Because elision requires the compiler to have an intrinsic knowledge of where the objects are being constructed. And with that information, it can just avoid moves and copies and simply place the object where it needs to go. For example when you return something from the stack of one function back to another, the compiler can elide the move/copy.
But in your case placement new allows you to construct an object into any arbitrary buffer. And that buffer can really be anywhere, for example it can be on the stack (like in your case) or it can be allocated on the heap with new. So the compiler does not elide the move/copy here.
Strictly speaking, this can happen through some analysis of the code since the compiler already knows where the buffer is, but I doubt most compilers implement this.
Note note that you have declared an array of character pointers and not characters, so the buffer is more than 1024 bytes in length if that is what you were expecting
Note Also note that calling std::move explicitly can prevent elision
The best you can do in this case is make an in place constructor or a move constructor (as you have above) to construct that object into the buffer. An in place constructor would look something like this
template <typename... args>
void construct(std::in_place_t, Args&&... args) {
new (buffer) Type{std::forward<Args>(args)...};
}
Use an emplace function with perfect argument forwarding. There are a few more things to say since you're about to embark on an adventure in placement new:
Use std::aligned_storage_t<> for the storage. It guarantees that your objects will be properly aligned.
Do read and use the return value of placement new. In simple cases it won't be different from the address you provide. However the standard allows it to be, and in complex class hierarchies it might be.
updated example:
#include <iostream>
struct Copy
{
Copy() {std::cerr << __PRETTY_FUNCTION__ << std::endl;}
Copy(const Copy & other) {std::cerr << __PRETTY_FUNCTION__ << std::endl;}
Copy & operator=(const Copy & other) {std::cerr << __PRETTY_FUNCTION__ << std::endl; return *this;}
Copy(Copy && other) {std::cerr << __PRETTY_FUNCTION__ << std::endl;}
Copy & operator=(Copy && other) {std::cerr << __PRETTY_FUNCTION__ << std::endl; return *this;}
~Copy() {std::cerr << __PRETTY_FUNCTION__ << std::endl;}
};
std::aligned_storage_t<sizeof(Copy), alignof(Copy)> buffer[4];
template <typename Type, typename LegalStorage, typename...Args>
auto emplace(LegalStorage* buffer, Args&&...args) -> Type*
{
return new(buffer) Type(std::forward<Args>(args)...);
};
int main()
{
auto p1 = emplace<Copy>(buffer /* constructor arguments go here*/);
auto p2 = emplace<Copy>(&buffer[1]/* constructor arguments go here*/);
auto p3 = emplace<Copy>(buffer + 2/* constructor arguments go here*/);
auto p4 = emplace<Copy>(buffer + 3/* constructor arguments go here*/);
return 0;
}
Related
Currently, I'm storing a collection of std::unique_ptrs to heap allocated objects of a polymorphic type:
struct Foo {
virtual ~Foo() = default;
};
Collection<std::unique_ptr<Foo>> foos;
The basic interface I need is putting / taking owners of Foo to / from foos. The objects stored in foos are never supposed to be nullptr so I'd like to replace runtime assert(owner_taken) with compile-time checks. Moreover, I would like to be capable of using non-null owners in the context where a nullable one may be expected.
Probably, I need to store something like unique_ref but how would I extract one from foos? I don't want a copy, I want the stored object itself, so owner->clone() isn't a solution. Neither I can std::move(owner) because the state of a "unique reference" would be invalid afterwards.
Is there a clean design decision?
Is there a never-null unique owner of heap allocated objects?
There is no such type in the standard library.
It is possible to implement such type. Simply define a type with unique_ptr member and mark the default constructor deleted. You can mark constructor from std::nullptr_t deleted also so that construction from nullptr will be prevented at compile time.
Whether you construct from an external pointer, or allocate in the constructor, there is no alternative for checking for null at runtime.
Reading your question, I interpret the following requirements:
You don't want to copy or move the object itself (Foo)
You don't want a wrapper which has some sort of empty state which excludes move semantics
The object itself (Foo) should be stored on the heap such that its lifetime is independent of the control flow
The object itself (Foo) should be deleted once it is not used any more
As construction / destruction, copy and move are the only ways to get objects into / out of a container, the only thing left is a wrapper object which is copied when moved into / out of the container.
You can create such an object yourself as follows:
// LICENSE: MIT
#include <memory>
#include <utility>
template<typename T>
class shared_ref {
public:
template<typename ...Args>
shared_ref(Args&&... args)
: data{new T(std::forward<Args>(args)...)}
{}
shared_ref(shared_ref&&) = delete;
shared_ref& operator=(shared_ref&&) = delete;
T& get() noexcept {
return *data;
}
const T& get() const noexcept {
return *data;
}
operator T&() noexcept {
return get();
}
operator const T&() const noexcept {
return get();
}
void swap(shared_ref& other) noexcept {
return data.swap(other);
}
private:
std::shared_ptr<T> data;
};
template<class T>
void swap(shared_ref<T>& lhs, shared_ref<T>& rhs) noexcept {
return lhs.swap(rhs);
}
I leave it as an exercise to the reader to add support for Allocator, Deleter, operator[], implicit conversion contructor to base classes.
This can then be used as follows:
#include <iostream>
int main() {
shared_ref<int> r; // default initialized
std::cout << "r=" << r << std::endl;
r = 5; // type conversion operator to reference
std::cout << "r=" << r << std::endl;
shared_ref<int> s{7}; // initialized with forwarded arguments
std::cout << "s=" << s << std::endl;
std::swap(r, s);
std::cout << "r=" << r << ", " << "s=" << s << std::endl;
s = r; // copy assignment operator
std::cout << "s=" << s << std::endl;
const shared_ref<int> t{s}; // copy constructor
std::cout << "t=" << t << std::endl;
//t = 8; // const ref from a const object is immutable
return 0;
}
let's say I'm working with an idiomatic Cpp library (e.g. Intel's TBB) and have an in-place member in some class (e.g. TsCountersType _ts_counters;). Such member is automatically initialized by its default constructor (if it exists, otherwise compile error) unless my own KMeans's constructor initialize it explicitely by calling its constructor directly.
Then if I assign a new (created by calling constructor) value to the member field in a normal non-constructor method (e.g. init), what exactly is safe to assume?
I know that in that case the right side of the assignment is rvalue and thus move assignment operator will be called.
I think it is safe to assume that well behaving idiomatic Cpp code should call the original objects's (e.g. _ts_counters) destructor before moving the new object to the memory location. But is such assumption sound?
What about default move assignment operator? Does it call destructor on the original object before moving in? Is that even relevant question or is default move assignment operator created by the compiler only if (among other conditions) no explicit destructor is defined?
If that's the case what happens if I have a scenario similar to the TBB one where instead of TsCountersType I have simple custom tipe with a single unique_ptr and default everything else (constructors, destructors, move assignments, …). When will the unique_ptr get out of scope then?
Specifically in TBB's case, can I assume it happens given their documentation: Supported since C++11. Moves the content of other to *this intact. other is left in an unspecified state, but can be safely destroyed.
Example code:
class KMeans
{
private:
//...
// thread specific counters
typedef std::pair<std::vector<point_t>, std::vector<std::size_t>> TSCounterType;
typedef tbb::enumerable_thread_specific<TSCounterType> TsCountersType;
TsCountersType _ts_counters;
public:
//...
KMeans() : _tbbInit(tbb::task_scheduler_init::automatic) {}
virtual void init(std::size_t points, std::size_t k, std::size_t iters)
{
// When _ts_counters is replaced by a new object the destructor is automatically called on the original object
_ts_counters = TsCountersType(std::make_pair(std::vector<point_t>(k), std::vector<std::size_t>(k)));
}
};
Consider this code:
#include<iostream>
struct S
{
S() { std::cout << __PRETTY_FUNCTION__ << std::endl;}
S(S const &) { std::cout << __PRETTY_FUNCTION__ << std::endl;}
S(S&&) { std::cout << __PRETTY_FUNCTION__ << std::endl;}
S& operator=(S const &) { std::cout << __PRETTY_FUNCTION__ << std::endl; return *this;}
S& operator=(S&&) { std::cout << __PRETTY_FUNCTION__ << std::endl; return *this;}
~S() { std::cout << __PRETTY_FUNCTION__ << std::endl; }
};
struct W
{
W() : s{} {}
void init() { s = S{}; }
private:
S s;
};
int main()
{
W w{};
w.init();
}
The output this produces (clang and gcc tested):
S::S()
S::S()
S &S::operator=(S &&)
S::~S()
S::~S()
So, what happens exactly:
W's constcructor is called, which default initializes S
A temporary S is default constructed and immediately moved from into W::s member
Temporary object is now destructed (just before init exits)
W::s is destructed on main exit.
Mechanism for this is well explained here: Template "copy constructor" does not prevent compiler-generated move constructor, but I would like to better undestand why it is made this way. I understand that move constructor is not generated even if any other constructor is written by the programmer, because it is an indication that construction of object is non trivial and auto generated constructor will probably be wrong. Then why templated constructors that have the same signature as copy constructors are not simply named copy constructors?
Example:
class Person {
public:
template<typename T>
Person(T&& t) : s(std::forward<T>(t)) {
std::cout << __PRETTY_FUNCTION__ << "\n";
}
Person(int n) {
std::cout << __PRETTY_FUNCTION__ << "\n";
}
// No need to declare copy/move constructors as compiler will do this implicitly
// Templated constructor does not inhibit it.
//Person(const Person&) = default;
//Person(Person&&) = default;
private:
std::string s;
};
and then:
Person p("asd"); // OK!
//Person p4(p); // error as Person(T&&) is a better match
if I make p const:
const Person p("asd");
Person p4(p); // thats ok, generator constructor is a better match
but if I explicitly delete even a move constructor with:
Person(Person&&) = delete;
then auto generation of constructors is inhibited.
You understand wrong.
struct noisy {
noisy() { std::cout << "ctor()\n"; }
noisy(noisy&&) { std::cout << "ctor(&&)\n"; }
noisy(noisy const&) { std::cout << "ctor(const&)\n"; }
noisy& operator=(noisy&&) { std::cout << "asgn(&&)\n"; return *this; }
noisy& operator=(noisy const&) { std::cout << "asgn(const&)\n"; return *this; }
};
struct test {
noisy n;
test(int x) { (void)x; }
};
test has generated move/copy construct/assignment.
Live example.
A copy/move construct/assignment written by a programmer results in the other ones being suppressed.
Now, writing a constructor suppresses the zero-argument constructor. That may be why you are confused.
Templated constructors with the same signature as copy constructors are not copy constructors because the standard says so.
As it happens, templated code is rarely the correct code for a copy or move constructor/assignment.
The fact that forwarding references often grab self& and self const&& copy/move over the actual copy/move operations is a problem. C++ isn't perfect.
Usually the way to avoid this is:
template<class T,
class=std::enable_if_t<
!std::is_same<std::decay_t<T>, Person>::value
>
>
Person(T&& t) : s(std::forward<T>(t)) {
std::cout << __PRETTY_FUNCTION__ << "\n";
}
or !std::is_base_of<Person, std::decay_t<T>>::value which covers some other situations (like inheriting constructors).
I'm currently writing a logging class (just for practice) and ran into an issue. I have two classes: The class Buffer acts as a temporary buffer and flushes itself in it's destructor. And the class Proxy that returns a Buffer instance, so I don't have to write Buffer() all the time.
Anyways, here is the code:
#include <iomanip>
#include <iostream>
#include <sstream>
#include <string>
class Buffer
{
private:
std::stringstream buf;
public:
Buffer(){};
template <typename T>
Buffer(const T& v)
{
buf << v;
std::cout << "Constructor called\n";
};
~Buffer()
{
std::cout << "HEADER: " << buf.str() << "\n";
}
Buffer(const Buffer& b)
{
std::cout << "Copy-constructor called\n";
// How to get rid of this?
};
Buffer(Buffer&&) = default;
Buffer& operator=(const Buffer&) & = delete;
Buffer& operator=(Buffer&&) & = delete;
template <typename T>
Buffer& operator<<(const T& v)
{
buf << v;
return *this;
}
};
class Proxy
{
public:
Proxy(){};
~Proxy(){};
Proxy(const Proxy&) = delete;
Proxy(Proxy&&) = delete;
Proxy& operator=(const Proxy&) & = delete;
Proxy& operator=(Proxy&&) & = delete;
template <typename T>
Buffer operator<<(const T& v) const
{
if(v < 0)
return Buffer();
else
return Buffer(v);
}
};
int main () {
Buffer(Buffer() << "Test") << "what";
Buffer() << "This " << "works " << "fine";
const Proxy pr;
pr << "This " << "doesn't " << "use the copy-constructor";
pr << "This is a " << std::setw(10) << " test";
return 0;
}
Here is the output:
Copy-constructor called
HEADER: what
HEADER: Test
HEADER: This works fine
Constructor called
HEADER: This doesn't use the copy-constructor
Constructor called
HEADER: This is a test
The code does exactly what I want but it depends on RVO. I read multiple times that you should not rely on RVO so I wanted to ask how I can:
Avoid RVO completely so that the copy constructor is called every time
Avoid the copy constructor
I already tried to avoid the copy constructor by returning a reference or moving but that segfaults. I guess thats because the temporary in Proxy::operator<< is deleted during return.
I'd also be interested in completely different approaches that do roughly the same.
This seems like a contrived problem: Firstly, the code works whether RVO is enabled or disabled (you can test it by using G++ with the no-elide-constructors flag). Secondly, the way you are designing the return of a Buffer object for use with the << operator can only be done by copying†: The Proxy::operator<<(const T& v) function creates a new Buffer instance on the stack, which is then deleted when you leave the function call (i.e. between each concatenation in pr << "This " << "doesn't " << "use the copy-constructor";); This is why you get a segmentation fault when trying to reference this object from outside the function.
Alternatively, you could define a << operator to use dynamic memory by e.g. returning a unique_ptr<Buffer>:
#include <memory>
...
std::unique_ptr<Buffer> operator<<(const T& v) const
{
if(v < 0)
return std::unique_ptr<Buffer>(new Buffer());
else
return std::unique_ptr<Buffer>(new Buffer(v));
}
However, your original concatenation statements won't be compilable, then, because Proxy::operator<<(const T& v) now returns an object of type std::unique_ptr<Buffer> rather than Buffer, meaning that this returned object doesn't have its own Proxy::operator<<(const T& v) function defined and so multiple concatenations won't work without first explicitly de-referencing the returned pointer:
const Proxy pr;
std::unique_ptr<Buffer> pb = pr << "This ";
// pb << "doesn't " << "use the copy-constructor"; // This line doesn't work
*pb << "doesn't " << "use the copy-constructor";
In other words, your classes rely inherently on copying and so, if you really want to avoid copying, you should throw them away and completely re-design your logging functionalities.
† I'm sure there's some black-magic voodoo which can be invoked to make this possible --- albeit at the cost of one's sanity.
I read that template copy-con is never default copy onstructor, and template assignment-op is never a copy assignment operator.
I couldn't understand why this restriction is needed and straight away went online to ideone and return a test program but here copy constructor never gets called on further googling I came across templatized constructor and tried that but still it never calls copy constructor.
#include <iostream>
using namespace std;
template <typename T> class tt
{
public :
tt()
{
std::cout << std::endl << " CONSTRUCTOR" << std::endl;
}
template <typename U> const tt<T>& operator=(const tt<U>& that){std::cout << std::endl << " OPERATOR" << std::endl;}
template <typename U> tt(const tt<U>& that)
{
std::cout << std::endl << " COPY CONSTRUCTOR" << std::endl;
}
};
tt<int> test(void)
{
std::cout << std::endl << " INSIDE " << std::endl; tt<int> a; return a;
}
int main() {
// your code goes here
tt<int> a ; a = test();
return 0;
}
Can someone explain me the whole reason behind putting this restriction and also how to write a copy constructor of template class.
Thanks
I can't comment on why this is how it is, but here's how you write a copy constructor and assignment operator for a class template:
template <class T>
class A
{
public:
A(const A &){}
A & operator=(const A& a){return *this;}
};
and that's it.
The trick here is that even though A is a template, when you refer to it inside the class as A (such as in the function signatures) it is treated as the full type A<T>.
There are strict rules what constitutes a copy constructor (cf. C++11, 12.8):
It is not a template.
For a class T, its first argument must have type T & or T const & or T volatile & or T const volatile &.
If it has more than one argument, the further arguments must have default values.
If you do not declare a copy constructor, a copy constructor of the form T::T(T const &) is implicitly declared for you. (It may or may not actually be defined, and if it is defined it may be defined as deleted.)
(The usual overload resolution rules imply that you can have at most four copy constructors, one for each CV-qualification.)
There are analogous rules for move constructors, with && in place of &.