Topic: Allowing non-static data members of forward declared types


Author: Avi Kivity <avi@scylladb.com>
Date: Sun, 6 Jan 2019 13:32:45 +0200
Raw View
This is a multi-part message in MIME format.
--------------CFC20D417AB56C06005CCCF8
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

C++ forbids a NSDM from having a non-pointer, non-reference=20
forward-declared type, presumably because it makes it impossible to know=20
the size, alignment, and member offsets of the class:


    class foo;

    class bar {
     =C2=A0=C2=A0 foo f; // error
    };



A common work around is to use indirection, trading run-time performance=20
for compile time:


    class foo;

    class bar {
     =C2=A0=C2=A0=C2=A0 std::unique_ptr<foo> f;
     =C2=A0=C2=A0=C2=A0 bar(); // if we aren't satisfied with null f
     =C2=A0=C2=A0=C2=A0 ~bar(); // so we don't need foo's destructor here
    };



I think it would be useful for large code bases battling compile time to=20
relax this restriction. It would make any inline (generated or user=20
provided) function that requires offsets, alignment, or sizes be=20
ill-formed, but we are already used to moving these functions=20
out-of-line, or defining them in places where the full types are known.


I think this is a relatively simple change for compilers. The main=20
drawback is that errors become less clear, but the situation is so=20
common that I think it's worth it.




--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6d495e8a-8187-c88b-a5d3-e7e6060f10e5%40scylladb.=
com.

--------------CFC20D417AB56C06005CCCF8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>

    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    C++ forbids a NSDM from having a non-pointer, non-reference
    forward-declared type, presumably because it makes it impossible to
    know the size, alignment, and member offsets of the class:<br>
    <br>
    <br>
    <blockquote>class foo;<br>
      <br>
      class bar {<br>
      =C2=A0=C2=A0 foo f; // error<br>
      };<br>
    </blockquote>
    <br>
    <br>
    A common work around is to use indirection, trading run-time
    performance for compile time:<br>
    <br>
    <br>
    <blockquote>class foo;<br>
      <br>
      class bar {<br>
      =C2=A0=C2=A0=C2=A0 std::unique_ptr&lt;foo&gt; f;<br>
      =C2=A0=C2=A0=C2=A0 bar(); // if we aren't satisfied with null f<br>
      =C2=A0=C2=A0=C2=A0 ~bar(); // so we don't need foo's destructor here<=
br>
      };<br>
    </blockquote>
    <br>
    <br>
    I think it would be useful for large code bases battling compile
    time to relax this restriction. It would make any inline (generated
    or user provided) function that requires offsets, alignment, or
    sizes be ill-formed, but we are already used to moving these
    functions out-of-line, or defining them in places where the full
    types are known.<br>
    <br>
    <br>
    I think this is a relatively simple change for compilers. The main
    drawback is that errors become less clear, but the situation is so
    common that I think it's worth it.<br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6d495e8a-8187-c88b-a5d3-e7e6060f10e5%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/6d495e8a-8187-c88b-a5d3-e7e6060f10=
e5%40scylladb.com</a>.<br />

--------------CFC20D417AB56C06005CCCF8--

.