Copying and moving are value-semantic operations. To define them, you first have to decide what properties of a class give its objects distinct values. This point was at first largely sidestepped for the iostreams library, and then C++11 took a different direction incompatible with such a copy constructor. The state of a stream object comprises … Read more
The syntax X a = b; where a and b are of type X has always meant copy construction. Whatever variants, such as: X a = X(); are used, there is no assignment going on, and never has been. Construct and assign would be something like: X a; a = X();
As pointed out by Nicol Bolas, the original version of this answer was incorrect: cppreference at the time of writing incorrectly documented the order in which constructors were considered in list-initialization. Below is an answer using the rules as they exist in the n4140 draft of the standard, which is very close to the official … Read more
The copy constructor doesn’t (can’t) really make a copy of the object because Derived::Derived(const Derived&) can’t access pdata to change it. Sure it can: Derived(const Derived& d) : Base(d) { cout << “Derived::Derived(const B&)” << endl; } If you don’t specify a base class constructor in the initializer list, its default constructor is called. If … Read more
This approach is the preferred way of copying polymorphic objects because it offloads the responsibility of determining how to copy an object of an arbitrary type to that object, rather than trying to determine it at compile-time. More generally, if you don’t know what the base class pointer points at at compile-time, you can’t possibly … Read more
This is a known bug and will hopefully be fixed in C++17 (not for C++14, see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1467). Your struct is an aggregate, so to initialize it with {someElement} there needs to be at least one data member, as you have discovered. Try providing an operator int(); and you will see it compiles.
The short answer is: Because the standard says you won’t. The C++ Standard 12.8/9 (Draft N3242) tells: The implicitly-declared copy constructor for a class X will have the form X::X(const X&) if each direct or virtual base class B of X has a copy constructor whose first parameter is of type const B& or const … Read more
To elaborate the two answers already given a bit: When you define variables to be “the same as” some other variable, you have basically two possibilities: ClassA aCopy = someOtherA; //copy ClassA& aRef = someOtherA; //reference Instead of non-const lvalue references, there are of course const references and rvalue references. The main thing I want … Read more
Yes, that’s a bad idea. All member variables of user-defined types will be initialized first, and then immediately overwritten. That swap trick is this: Foo& operator=(Foo rhs) // note the copying { rhs.swap(*this); //swap our internals with the copy of rhs return *this; } // rhs, now containing our old internals, will be deleted
The explicit copy constructor means that the copy constructor will not be called implicitly, which is what happens in the expression: CustomString s = CustomString(“test”); This expression literally means: create a temporary CustomString using the constructor that takes a const char*. Implicitly call the copy constructor of CustomString to copy from that temporary into s. … Read more