Can copy constructors of containers be defined as deleted for non-copyable value types?

  • A+
Category:Languages

If we have a container with non-copyable value type, such a container class still defines the copy constructor, just it may not be invoked.

using T = std::vector<std::unique_ptr<int>>; std::cout << std::is_copy_constructible_v<T>; // prints out "1" (libstdc++) 

This may cause "hidden" problems such as the one discussed here: Does Visual Studio 2017 need an explicit move constructor declaration?.

My question is if Standard library implementations may define such copy constructor as conditionally deleted, namely deleted in case of non-copyable value types. It would make perfect sense to me (at least until there are C++ concepts). Would such implementation be Standard-compliant?

 


This is not possible ever since vector got incomplete type support:

struct E {     std::vector<E> e; }; 

E is copyable iff std::vector<E> is copyable, and std::vector<E> is copyable iff E is copyable. Turtles all the way down.

Even before that, because the allocator's construct can mutilate the constructor arguments as it sees fit, and there's no way for the container to tell if something is "allocator-constructible", conditionally deleting the copy constructor would require some serious design work. The incomplete type support just put the nail in the coffin.

Comment

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: