13

The existing question on Why can't I initialise an array of objects if they have private copy constructors? specifically refers to C++03. I know from that question that what I am trying to do is not allowed in C++03 but I thought that it should be possible in C++11

I have a non-movable class (call it Child) and I need to initialize an array of Child in the constructor of another class (call it Parent). By "non-movable" I mean that the address of a Child object has to remain the same during that object's lifetime. What is the correct way to do this?

With C++11 I've tried the following:

class Child
{
public:
    Child (int x) {}
    ~Child () {}

    Child (const Child &) = delete;
};

class Parent
{
public:
    Parent () : children {{5}, {7}} {}

private:
    Child children[2];
};

This code compiles fine with Clang 3.5.0, but GCC 4.9.1 complains that I am trying to use the deleted copy constructor:

test.cc: In constructor ‘Parent::Parent()’:
test.cc:13:35: error: use of deleted function ‘Child::Child(const Child&)’
     Parent () : children {{5}, {7}} {}
                                   ^
test.cc:7:5: note: declared here
     Child (const Child &) = delete;
     ^

I've read about the difference between copy-initialization and direct-initialization (here and here, for example), and I want to avoid calling the copy constructor by using direct-initialization. Am I getting the syntax wrong? Is this a bug in GCC? Or is what I am trying to do just not possible?

Community
  • 1
  • 1
John Lindgren
  • 777
  • 5
  • 14
  • 1
    Seems to me this is a clang bug, and not a gcc bug. clang fails to compile the code if you change it to `children {Child{5}, Child{7}}`, which should behave identically to what you've posted. A workaround would be to use a `vector` and emplace the `Child` objects. – Praetorian Nov 01 '14 at 02:23
  • g++ succeeds with `Child children[2] { {5}, {7} };` which should be identical to the version where the same initializer occurs in the ctor initializer list; both are covered by [dcl.init.list]/3 – M.M Nov 01 '14 at 03:04
  • 1
    Reading through the sections on initialization this code seems correct; `children[2] = { {5}, {7} }` says that `children[0]` is copy-initializaed from `{5}`, i.e. it's the same as `Child c = { 5 };`, and that is covered by [dcl.init.list] again which invokes the constructor for `c` that takes `int` (without involving a copy). – M.M Nov 01 '14 at 03:11
  • 2
    @Praetorian: `children {Child {5}, Child {7}}` is different, I think. Putting `Child {5}` inside the braces forces the compiler to (nominally) create a temporary object which is then copied to initialize the array. – John Lindgren Nov 01 '14 at 04:21
  • @MattMcNabb: Strange to me is that if I comment out the _destructor_ in Child, then GCC accepts the code. I believe the absence of a (non-default) destructor means that Child is then a [literal type](http://en.cppreference.com/w/cpp/concept/LiteralType). Do you know if there are different initialization rules for literal types? – John Lindgren Nov 01 '14 at 04:25
  • @JohnLindgren *Stack Overflow flagged this answer as related* ... I initially flagged it (StackOverflow doesn't do all that much on its own) but given the comments I retracted my vote, in part because emplacement offers an answer fitting your specific phrased requirements...and also because it seems there's some nuances here worth looking at in the compilers...even if it's finding a bug. – HostileFork says dont trust SE Nov 01 '14 at 07:46
  • 5
    Created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707. We'll see what the GCC developers have to say. – John Lindgren Nov 01 '14 at 18:53

2 Answers2

4

I agree with the comments that this seems to be a GCC bug (reported as 63707).

It only fails to compile when the type in the array has a user-defined destructor, which doesn't make sense to me.

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
  • Sometimes it also fails without destructor: http://stackoverflow.com/questions/31906483/class-member-array-of-objects-without-default-constructor-and-deleted-copy-cont – peku33 Aug 09 '15 at 17:34
  • @peku33, yes, I gave a similar example in the GCC bug report. The problem happens with non-trivial destructors, not only user-defined ones. – Jonathan Wakely Aug 11 '15 at 14:19
-1

I came through a similar issue, namely that this code

#include <iostream>

class Widget {
public:
    Widget(int i) { std::cout << "Ctor " << i << std::endl; }

    Widget(const Widget&); // = delete;
};

int main() {
    Widget w = 123;
}

compiled and gave the expected result, but after uncommenting the = delete it failed to compile with gcc-4.9.

After reading the standard I believe the answer lies in the second item of highest indentation in 8.5/16, which is cited below.

What basically seems to happen is that the compiler conceptually wants to create a temporary of type Widget and direct-initialize the actual object w from that temporary through the copy constructor. Since the copy constructor is deleted, compilation stops. If the copy constructor was not deleted, the compiler would later realize that it may elide the copy, but it does not get that far.

Here is the relevant part:

[...] for the [...] copy-initialization cases [...] user-defined conversion sequences that can convert from the source type to the destination type [...] are enumerated as described in 13.3.1.4, and the best one is chosen through overload resolution (13.3). [...] The function selected is called with the initializer expression as its argument; if the function is a constructor, the call initializes a temporary of the cv-unqualified version of the destination type. [...] The result of the call (which is the temporary for the constructor case) is then used to direct-initialize, according to the rules above, the object that is the destination of the copy-initialization. In certain cases, an implementation is permitted to eliminate the copying inherent in this direct-initialization by constructing the intermediate result directly into the object being initialized; see 12.2, 12.8.

But I may be wrong since there is a lot in the [...] parts that I did not understand.

levzettelin
  • 2,600
  • 19
  • 32
  • 3
    I don't think this is really related. `Widget w = 123;` uses the copy constructor, `Widget w{123};` is direct initialization. – Tavian Barnes Nov 17 '14 at 00:46
  • 1
    This is definitely a different situation. Creating a `Widget` on the stack requires an accessible destructor, because it gets called automatically for stack objects. If you have a deleted destructor you can't create it on the stack. That's nothing to do with the question. – Jonathan Wakely Jan 28 '15 at 11:40
  • @JonathanWakely It is not the destructor that is deleted in my example. – levzettelin Jan 28 '15 at 15:22
  • 1
    You're right, sorry. Still a different situation though. `Widget w = 123;` means `Widget w = Widget(123)` which requires a copy constructor. That's a well-known feature of C++, nothing to do with C++11, and unrelated to this question. – Jonathan Wakely Jan 28 '15 at 15:24
  • @JonathanWakely I understood the quoted part of the standard (at the time when I wrote this) to also talk about the situation in the OP. I am suggesting that the failing line is equivalent to `Parent () : children { Child{5}, Child{7}} {}` and then the actual array elements are initialized from the temporaries. But maybe I got something wrong. – levzettelin Jan 28 '15 at 15:50