------=_Part_108_2142842500.1538634444050
Content-Type: multipart/alternative;
 boundary="----=_Part_109_1644153745.1538634444051"

------=_Part_109_1644153745.1538634444051
Content-Type: text/plain; charset="UTF-8"

One of the biggest spooks among C++ developers is *ABI Compatibility*. How
can we ensure that we aren't combining translation units with mismatching
ABIs?

Some ABI issues (e.g. name-mangling, vtable placement, member layout and
padding, and calling convention) have been fairly stable for many years.
The Itanium ABI allows Clang and GCC code to link together with pretty high
success rates. Not to say that it is perfect, but it's a great start.

There are other important ABI considerations. The prime example is that of
a library which may update the layout of its classes. This may be for a
version change, or perhaps because it changes its behavior based on being
compiled in "debug" mode (e.g. debug iterators).

I'd like to propose a new standard attribute: [[abi(<key>, <value>,
<message>)]], allowing user code to annotate translation units with ABI
compatibility information.

It appears in an *attribute-declaration*, an attribute appearing at
namespace scope with no other language construct:

#ifndef MY_HEADER_INCLUDED
#define MY_HEADER_INCLUDED

#include <other_things.hpp>

namespace my_library {

#ifdef NDEBUG
#  define MYLIB_BT Release
#else
#  define MYLIB_BT Debug
#endif

// Tag if we are built with debug/release mode
[[abi("MyLibrary.BuildType",
      MYLIB_STR(MYLIB_BT),
      "Linking incompatible configurations of MyLibrary together is not
allowed")]];

// Tag the exact ABI revision of the container
[[abi("my_library::my_container/abi",
      "1.3.x",
      "Incompatible versions of my_library::my_container")]];

template <typename T>
class my_container {

#ifdef NDEBUG
  using iterator = detail::debug_container_iterator<T>;
#else
  using iterator = detail::container_iterator<T>;
#endif

};


}

#endif // MY_HEADER_INCLUDED

(Apologies for the macros)

All [[abi()]] attributes that appear in a translation unit will cause that
TU to be tagged with the given key=value pair (along with the <message>).
When translation units are combined (by a linker), if any of the
constituent translation units contain conflicting <value>s for any given
<key>, the program is ill formed with the <message> given as associated
with the mismatching <key>. (If multiple TUs have mismatching <message>s
for an errant <key>=<value>, it is unspecified which message is chosen).

This concept isn't new: MSVC implements a similar feature using #pragma
detect_mismatch, which enforces compatible linking between different
configurations of its standard library.

Of course, other names for the attribute might be better than the simple
(simplistic?) "abi", including:


   - [[compatibility()]]
   - [[detect_mismatch()]]
   - [[enforce_matching()]]

Let's see what the world thinks before I write a formal paper for mailing.

--
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 email 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/1ad13933-bc24-441e-9f0d-ee34a6911aea%40isocpp.org.

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

<div dir=3D"ltr"><div>One of the biggest spooks among C++ developers is <i>=
ABI Compatibility</i>. How can we ensure that we aren&#39;t combining trans=
lation units with mismatching ABIs?</div><div><br></div><div>Some ABI issue=
s (e.g. name-mangling, vtable placement, member layout and padding, and cal=
ling convention) have been fairly stable for many years. The Itanium ABI al=
lows Clang and GCC code to link together with pretty high success rates. No=
t to say that it is perfect, but it&#39;s a great start.</div><div><br></di=
v><div>There are other important ABI considerations. The prime example is t=
hat of a library which may update the layout of its classes. This may be fo=
r a version change, or perhaps because it changes its behavior based on bei=
ng compiled in &quot;debug&quot; mode (e.g. debug iterators).</div><div><br=
></div><div>I&#39;d like to propose a new standard attribute: <font face=3D=
"courier new,monospace">[[abi(&lt;key&gt;, &lt;value&gt;, &lt;message&gt;)]=
]<font face=3D"arial,sans-serif">, allowing user code to annotate translati=
on units with ABI compatibility information.</font></font><br></div><div><b=
r></div><div>It appears in an <i>attribute-declaration</i>, an attribute ap=
pearing at namespace scope with no other language construct:</div><div><br>=
</div><div><div style=3D"background-color: rgb(250, 250, 250); border-color=
: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap=
: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">#ifndef</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 MY_HEADER_INCLUDED</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"></span><br><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><code class=3D"prettyprint"><span style=3D"color: #800;" class=3D"styled=
-by-prettify">#define</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> MY_HEADER_INCLUDED</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br><br>#include &lt;other_things.hpp&gt;<br><br>namesp=
ace my_library {<br><br>#ifdef NDEBUG<br>#=C2=A0 define MYLIB_BT Release<br=
>#else<br>#=C2=A0 define MYLIB_BT Debug<br>#endif<br><br>// Tag if we are b=
uilt with debug/release mode<br>[[abi(&quot;MyLibrary.BuildType&quot;,</spa=
n></code></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MYLIB_STR(MYLIB_BT),<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 &quot;Linking incompatible configurations of MyLib=
rary together is not allowed&quot;)]];<br><br>// Tag the exact ABI revision=
 of the container<br>[[abi(&quot;my_library::my_container/abi&quot;,<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quot;1.3.x&quot;,<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 &quot;Incompatible versions of my_library::my_container&quot;)]];<br=
></span></code></span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>template &lt;typename T&gt;<br>class my_container {<br>=
<br>#ifdef NDEBUG<br>=C2=A0 using iterator =3D detail::debug_container_iter=
ator&lt;T&gt;;<br>#else<br>=C2=A0 using iterator =3D detail::container_iter=
ator&lt;T&gt;;<br>#endif<br><br>};<br><br><br>}<br><br>#endif // </span></c=
ode></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><code =
class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">MY_HEADER_INCLUDED</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></code></span></code></span></div></code=
></div><br>(Apologies for the macros)</div><div><br></div><div>All <span st=
yle=3D"font-family: courier new, monospace;">[[abi()]]</span> attributes th=
at appear in a translation unit will cause that TU to be tagged with the gi=
ven key=3Dvalue pair (along with the &lt;message&gt;). When translation uni=
ts are combined (by a linker), if any of the constituent translation units =
contain conflicting &lt;value&gt;s for any given &lt;key&gt;, the program i=
s ill formed with the &lt;message&gt; given as associated with the mismatch=
ing &lt;key&gt;. (If multiple TUs have mismatching &lt;message&gt;s for an =
errant &lt;key&gt;=3D&lt;value&gt;, it is unspecified which message is chos=
en).</div><div><br></div><div>This concept isn&#39;t new: MSVC implements a=
 similar feature using <span style=3D"font-family: courier new, monospace;"=
>#pragma detect_mismatch</span>, which enforces compatible linking between =
different configurations of its standard library.</div><div><br></div><div>=
Of course, other names for the attribute might be better than the simple (s=
implistic?) &quot;abi&quot;, including:</div><div><br></div><div><ul><li><s=
pan style=3D"font-family: courier new, monospace;">[[compatibility()]]</spa=
n></li><li><span style=3D"font-family: courier new, monospace;">[[detect_mi=
smatch()]]</span></li><li><span style=3D"font-family: courier new, monospac=
e;">[[enforce_matching()]]</span></li></ul></div><div>Let&#39;s see what th=
e world thinks before I write a formal paper for mailing.<br></div></div>

<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/1ad13933-bc24-441e-9f0d-ee34a6911aea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1ad13933-bc24-441e-9f0d-ee34a6911aea=
%40isocpp.org</a>.<br />

------=_Part_109_1644153745.1538634444051--

------=_Part_108_2142842500.1538634444050--

.

On Thu, 4 Oct 2018 at 09:27, Colby Pike (vector-of-bool)
<vectorofbool@gmail.com> wrote:

> Let's see what the world thinks before I write a formal paper for mailing.

Have you read http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4028.pdf ?

--
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 email 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/CAFk2RUbLpTXzWhx%2B4uM_SuxEXUAn%2Brj81LPU37LP8Kj8oDP6GA%40mail.gmail.com.

.

------=_Part_387_1925821908.1538676356497
Content-Type: multipart/alternative;
 boundary="----=_Part_388_1037904946.1538676356497"

------=_Part_388_1037904946.1538676356497
Content-Type: text/plain; charset="UTF-8"

Yes, I have read this paper. The issues it addresses are orthogonal to
mine. Where the linked paper moves toward promoting a way to maintain ABI
stability, my proposal offers the facility to explicitly call out ABI
incompatibility.

On Thursday, October 4, 2018 at 3:04:05 AM UTC-6, Ville Voutilainen wrote:
>
> On Thu, 4 Oct 2018 at 09:27, Colby Pike (vector-of-bool)
> <vector...@gmail.com <javascript:>> wrote:
>
> > Let's see what the world thinks before I write a formal paper for
> mailing.
>
> Have you read
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4028.pdf ?
>

--
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 email 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/52e562ff-49fa-4e8f-b662-bab4be117100%40isocpp.org.

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

<div dir=3D"ltr">Yes, I have read this paper. The issues it addresses are o=
rthogonal to mine. Where the linked paper moves toward promoting a way to m=
aintain ABI stability, my proposal offers the facility to explicitly call o=
ut ABI incompatibility.<div><br>On Thursday, October 4, 2018 at 3:04:05 AM =
UTC-6, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>On Thu, 4 Oct 2018 at 09:27, Colby Pike (vector-of-bool)
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
PoDQguTHAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">vector...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Let&#39;s see what the world thinks before I write a formal paper =
for mailing.
<br>
<br>Have you read <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers=
/2014/n4028.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2F=
SC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4028.pdf\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNF8dAkT-D4Sjd4ti3nzb_vk0d_K5g&#39;;return true;" onclick=3D"this=
..href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC=
1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4028.pdf\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNF8dAkT-D4Sjd4ti3nzb_vk0d_K5g&#39;;return true;">http://open=
-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n4028.<wbr>pdf</a> ?
<br></blockquote></div></div>

<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/52e562ff-49fa-4e8f-b662-bab4be117100%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/52e562ff-49fa-4e8f-b662-bab4be117100=
%40isocpp.org</a>.<br />

------=_Part_388_1037904946.1538676356497--

------=_Part_387_1925821908.1538676356497--

.