------=_Part_2962_1109125796.1521130356339
Content-Type: multipart/alternative;
 boundary="----=_Part_2963_2000995723.1521130356340"

------=_Part_2963_2000995723.1521130356340
Content-Type: text/plain; charset="UTF-8"

The C standard library defines a large number of things that are macros. In
the vast majority of cases, these are constants or functions, which can in
C++ code be converted into `constexpr` variables or actual functions. For
all intents and purposes, such constructs can be drop-in replacements for
the C macros, which allows us to still work with them in a modular standard
library that doesn't allow macros.

`offsetof` is a special case because it's not a function. Or at least, it's
not a function that C++ at present allows you to write. Without reflection,
there is no way to pass a typename or member variable as a function
parameter. And while there are ways we can work around it, none of those
ways would be drop-in replacements for `offsetof`; the user would have to
change their code.

And even ignoring the non-drop-in part, there is currently no C++
replacement for `offsetof`. As modules moves forward, are there plans to
resolve this issue and similar ones (beside the "let's get modules to
export macros" plan)?

--
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/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40isocpp.org.

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

<div dir=3D"ltr">The C standard library defines a large number of things th=
at are macros. In the vast majority of cases, these are constants or functi=
ons, which can in C++ code be converted into `constexpr` variables or actua=
l functions. For all intents and purposes, such constructs can be drop-in r=
eplacements for the C macros, which allows us to still work with them in a =
modular standard library that doesn&#39;t allow macros.<br><br>`offsetof` i=
s a special case because it&#39;s not a function. Or at least, it&#39;s not=
 a function that C++ at present allows you to write. Without reflection, th=
ere is no way to pass a typename or member variable as a function parameter=
.. And while there are ways we can work around it, none of those ways would =
be drop-in replacements for `offsetof`; the user would have to change their=
 code.<br><br>And even ignoring the non-drop-in part, there is currently no=
 C++ replacement for `offsetof`. As modules moves forward, are there plans =
to resolve this issue and similar ones (beside the &quot;let&#39;s get modu=
les to export macros&quot; plan)?<br></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/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e=
%40isocpp.org</a>.<br />

------=_Part_2963_2000995723.1521130356340--

------=_Part_2962_1109125796.1521130356339--

.

--f4f5e80aede42a0db10567768908
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 15, 2018 at 12:12 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> The C standard library defines a large number of things that are macros.
> In the vast majority of cases, these are constants or functions, which can
> in C++ code be converted into `constexpr` variables or actual functions.
> For all intents and purposes, such constructs can be drop-in replacements
> for the C macros, which allows us to still work with them in a modular
> standard library that doesn't allow macros.
>
> `offsetof` is a special case because it's not a function. Or at least,
> it's not a function that C++ at present allows you to write. Without
> reflection, there is no way to pass a typename or member variable as a
> function parameter. And while there are ways we can work around it, none of
> those ways would be drop-in replacements for `offsetof`; the user would
> have to change their code.
>
> And even ignoring the non-drop-in part, there is currently no C++
> replacement for `offsetof`. As modules moves forward, are there plans to
> resolve this issue and similar ones (beside the "let's get modules to
> export macros" plan)?
>

The Standard requires (in *[headers]*) that offsetof be a macro, so a
library that bans macros perforce cannot use offsetof (or assert, setjmp,
va_arg, va_end, and va_start).  If you want to change that, then make
offsetof a built-in keyword, just like decltype and sizeof.

Also, what does it mean, "a modular standard library that doesn't use
macros"?  A module can (or must, I suppose, for now) have an exported
interface that does not provide macros to its users, but that does not
prevent the code in the module from including header files and using macros
as part of its implementation.

--
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/CAHSYqdbx5W6zu%2B0SuOFU7OhiYD7jAcRY-mrw%2BNY%3Dm%2BAAAh5_qw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 15, 2018 at 12:12 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">The C standard library defines a large number of things that are m=
acros. In the vast majority of cases, these are constants or functions, whi=
ch can in C++ code be converted into `constexpr` variables or actual functi=
ons. For all intents and purposes, such constructs can be drop-in replaceme=
nts for the C macros, which allows us to still work with them in a modular =
standard library that doesn&#39;t allow macros.<br><br>`offsetof` is a spec=
ial case because it&#39;s not a function. Or at least, it&#39;s not a funct=
ion that C++ at present allows you to write. Without reflection, there is n=
o way to pass a typename or member variable as a function parameter. And wh=
ile there are ways we can work around it, none of those ways would be drop-=
in replacements for `offsetof`; the user would have to change their code.<b=
r><br>And even ignoring the non-drop-in part, there is currently no C++ rep=
lacement for `offsetof`. As modules moves forward, are there plans to resol=
ve this issue and similar ones (beside the &quot;let&#39;s get modules to e=
xport macros&quot; plan)?</div></blockquote><div><br>The Standard requires =
(in <b>[headers]</b>) that <font face=3D"monospace, monospace">offsetof</fo=
nt> be a macro, so a library that bans macros perforce cannot use <font fac=
e=3D"monospace, monospace">offsetof=C2=A0</font>(or <font face=3D"monospace=
, monospace">assert</font>, <font face=3D"monospace, monospace">setjmp</fon=
t>, <font face=3D"monospace, monospace">va_arg</font>, <font face=3D"monosp=
ace, monospace">va_end</font>, and <font face=3D"monospace, monospace">va_s=
tart</font>).=C2=A0 If you want to change that, then make <font face=3D"mon=
ospace, monospace">offsetof</font> a built-in keyword, just like <font face=
=3D"monospace, monospace">decltype</font> and <font face=3D"monospace, mono=
space">sizeof</font>.<br><br>Also, what does it mean, &quot;a modular stand=
ard library that doesn&#39;t use macros&quot;?=C2=A0 A module can (or must,=
 I suppose, for now) have an exported interface that does not provide macro=
s to its users, but that does not prevent the code in the module from inclu=
ding header files and using macros as part of its implementation.</div></di=
v></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/CAHSYqdbx5W6zu%2B0SuOFU7OhiYD7jAcRY-m=
rw%2BNY%3Dm%2BAAAh5_qw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbx=
5W6zu%2B0SuOFU7OhiYD7jAcRY-mrw%2BNY%3Dm%2BAAAh5_qw%40mail.gmail.com</a>.<br=
 />

--f4f5e80aede42a0db10567768908--

.

--001a1136e056204cc3056776b895
Content-Type: text/plain; charset="UTF-8"

Not that I know of. This was mentioned in passing while discussing P0908,
where it was suggested to make it an operator.

EWG then went back and forth a bit, as making offsetof an operator would
mean incompatibilities with POSIX headers but better for modules.

You might want to write a proposal for this.

There is the Atom proposal which proposes to have a "module header" which
can also solve this issue in a relatively clean way (P0947).

On Thu, Mar 15, 2018, 12:12 PM Nicol Bolas <jmckesson@gmail.com> wrote:

> The C standard library defines a large number of things that are macros.
> In the vast majority of cases, these are constants or functions, which can
> in C++ code be converted into `constexpr` variables or actual functions.
> For all intents and purposes, such constructs can be drop-in replacements
> for the C macros, which allows us to still work with them in a modular
> standard library that doesn't allow macros.
>
> `offsetof` is a special case because it's not a function. Or at least,
> it's not a function that C++ at present allows you to write. Without
> reflection, there is no way to pass a typename or member variable as a
> function parameter. And while there are ways we can work around it, none of
> those ways would be drop-in replacements for `offsetof`; the user would
> have to change their code.
>
> And even ignoring the non-drop-in part, there is currently no C++
> replacement for `offsetof`. As modules moves forward, are there plans to
> resolve this issue and similar ones (beside the "let's get modules to
> export macros" plan)?
>
> --
> 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/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CALmDwq38-kBPK2QnEPLkzM9z7r_jXif7oBoO%2BA7CMm9XBUC96g%40mail.gmail.com.

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

<div dir=3D"auto">Not that I know of. This was mentioned in passing while d=
iscussing P0908, where it was suggested to make it an operator.<div dir=3D"=
auto"><br></div><div dir=3D"auto">EWG then went back and forth a bit, as ma=
king offsetof an operator would mean incompatibilities with POSIX headers b=
ut better for modules.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Y=
ou might want to write a proposal for this.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">There is the Atom proposal which proposes to have a &qu=
ot;module header&quot; which can also solve this issue in a relatively clea=
n way (P0947).</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">O=
n Thu, Mar 15, 2018, 12:12 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@g=
mail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">jmckesson@gmail.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
The C standard library defines a large number of things that are macros. In=
 the vast majority of cases, these are constants or functions, which can in=
 C++ code be converted into `constexpr` variables or actual functions. For =
all intents and purposes, such constructs can be drop-in replacements for t=
he C macros, which allows us to still work with them in a modular standard =
library that doesn&#39;t allow macros.<br><br>`offsetof` is a special case =
because it&#39;s not a function. Or at least, it&#39;s not a function that =
C++ at present allows you to write. Without reflection, there is no way to =
pass a typename or member variable as a function parameter. And while there=
 are ways we can work around it, none of those ways would be drop-in replac=
ements for `offsetof`; the user would have to change their code.<br><br>And=
 even ignoring the non-drop-in part, there is currently no C++ replacement =
for `offsetof`. As modules moves forward, are there plans to resolve this i=
ssue and similar ones (beside the &quot;let&#39;s get modules to export mac=
ros&quot; plan)?<br></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" rel=3D"nore=
ferrer noreferrer noreferrer" target=3D"_blank">std-proposals+unsubscribe@i=
socpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">std-propos=
als@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/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer =
noreferrer noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40isocpp.or=
g</a>.<br>
</blockquote></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/CALmDwq38-kBPK2QnEPLkzM9z7r_jXif7oBoO=
%2BA7CMm9XBUC96g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq38-kBPK2=
QnEPLkzM9z7r_jXif7oBoO%2BA7CMm9XBUC96g%40mail.gmail.com</a>.<br />

--001a1136e056204cc3056776b895--

.

------=_Part_3905_956883210.1521137384218
Content-Type: multipart/alternative;
 boundary="----=_Part_3906_1789220076.1521137384218"

------=_Part_3906_1789220076.1521137384218
Content-Type: text/plain; charset="UTF-8"

I think we should leave this macro alone and add new operator with
different name that will be available everywhere.
And then optionally define `offsetof ` with use this new operator.

On Thursday, March 15, 2018 at 6:21:19 PM UTC+1, Nicolas Lesser wrote:
>
> Not that I know of. This was mentioned in passing while discussing P0908,
> where it was suggested to make it an operator.
>
> EWG then went back and forth a bit, as making offsetof an operator would
> mean incompatibilities with POSIX headers but better for modules.
>
> You might want to write a proposal for this.
>
> There is the Atom proposal which proposes to have a "module header" which
> can also solve this issue in a relatively clean way (P0947).
>
> On Thu, Mar 15, 2018, 12:12 PM Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> The C standard library defines a large number of things that are macros.
>> In the vast majority of cases, these are constants or functions, which can
>> in C++ code be converted into `constexpr` variables or actual functions.
>> For all intents and purposes, such constructs can be drop-in replacements
>> for the C macros, which allows us to still work with them in a modular
>> standard library that doesn't allow macros.
>>
>> `offsetof` is a special case because it's not a function. Or at least,
>> it's not a function that C++ at present allows you to write. Without
>> reflection, there is no way to pass a typename or member variable as a
>> function parameter. And while there are ways we can work around it, none of
>> those ways would be drop-in replacements for `offsetof`; the user would
>> have to change their code.
>>
>> And even ignoring the non-drop-in part, there is currently no C++
>> replacement for `offsetof`. As modules moves forward, are there plans to
>> resolve this issue and similar ones (beside the "let's get modules to
>> export macros" plan)?
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>

--
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/e7a864e9-a866-40d6-9688-95219dc34d92%40isocpp.org.

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

<div dir=3D"ltr">I think we should leave this macro alone and add new opera=
tor with different name that will be available everywhere.<br>And then opti=
onally define `offsetof ` with use this new operator.<br><br>On Thursday, M=
arch 15, 2018 at 6:21:19 PM UTC+1, Nicolas Lesser wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"auto">Not that I know of. This was =
mentioned in passing while discussing P0908, where it was suggested to make=
 it an operator.<div dir=3D"auto"><br></div><div dir=3D"auto">EWG then went=
 back and forth a bit, as making offsetof an operator would mean incompatib=
ilities with POSIX headers but better for modules.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">You might want to write a proposal for this.</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">There is the Atom proposal =
which proposes to have a &quot;module header&quot; which can also solve thi=
s issue in a relatively clean way (P0947).</div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr">On Thu, Mar 15, 2018, 12:12 PM Nicol Bolas &lt;<=
a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"ghWJOl6pAgAJ" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck..=
..@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">The C standard library defines a large number of things that are m=
acros. In the vast majority of cases, these are constants or functions, whi=
ch can in C++ code be converted into `constexpr` variables or actual functi=
ons. For all intents and purposes, such constructs can be drop-in replaceme=
nts for the C macros, which allows us to still work with them in a modular =
standard library that doesn&#39;t allow macros.<br><br>`offsetof` is a spec=
ial case because it&#39;s not a function. Or at least, it&#39;s not a funct=
ion that C++ at present allows you to write. Without reflection, there is n=
o way to pass a typename or member variable as a function parameter. And wh=
ile there are ways we can work around it, none of those ways would be drop-=
in replacements for `offsetof`; the user would have to change their code.<b=
r><br>And even ignoring the non-drop-in part, there is currently no C++ rep=
lacement for `offsetof`. As modules moves forward, are there plans to resol=
ve this issue and similar ones (beside the &quot;let&#39;s get modules to e=
xport macros&quot; plan)?<br></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"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"ghWJOl6pAgAJ" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" rel=3D"nofollo=
w" target=3D"_blank" gdf-obfuscated-mailto=3D"ghWJOl6pAgAJ" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c5f5ccc4-3267-442d-<wbr>8cb2-=
de1ae103a38e%40isocpp.org</a><wbr>.<br>
</blockquote></div>
</blockquote></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/e7a864e9-a866-40d6-9688-95219dc34d92%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e7a864e9-a866-40d6-9688-95219dc34d92=
%40isocpp.org</a>.<br />

------=_Part_3906_1789220076.1521137384218--

------=_Part_3905_956883210.1521137384218--

.

--000000000000efb9fa0567776971
Content-Type: text/plain; charset="UTF-8"

ooo offsetof that works on members of virtual base classes :)

On Thu, Mar 15, 2018 at 6:09 PM, <inkwizytoryankes@gmail.com> wrote:

> I think we should leave this macro alone and add new operator with
> different name that will be available everywhere.
> And then optionally define `offsetof ` with use this new operator.
>
> On Thursday, March 15, 2018 at 6:21:19 PM UTC+1, Nicolas Lesser wrote:
>>
>> Not that I know of. This was mentioned in passing while discussing P0908,
>> where it was suggested to make it an operator.
>>
>> EWG then went back and forth a bit, as making offsetof an operator would
>> mean incompatibilities with POSIX headers but better for modules.
>>
>> You might want to write a proposal for this.
>>
>> There is the Atom proposal which proposes to have a "module header" which
>> can also solve this issue in a relatively clean way (P0947).
>>
>> On Thu, Mar 15, 2018, 12:12 PM Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> The C standard library defines a large number of things that are macros.
>>> In the vast majority of cases, these are constants or functions, which can
>>> in C++ code be converted into `constexpr` variables or actual functions.
>>> For all intents and purposes, such constructs can be drop-in replacements
>>> for the C macros, which allows us to still work with them in a modular
>>> standard library that doesn't allow macros.
>>>
>>> `offsetof` is a special case because it's not a function. Or at least,
>>> it's not a function that C++ at present allows you to write. Without
>>> reflection, there is no way to pass a typename or member variable as a
>>> function parameter. And while there are ways we can work around it, none of
>>> those ways would be drop-in replacements for `offsetof`; the user would
>>> have to change their code.
>>>
>>> And even ignoring the non-drop-in part, there is currently no C++
>>> replacement for `offsetof`. As modules moves forward, are there plans to
>>> resolve this issue and similar ones (beside the "let's get modules to
>>> export macros" plan)?
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-
>>> de1ae103a38e%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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/e7a864e9-a866-40d6-
> 9688-95219dc34d92%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e7a864e9-a866-40d6-9688-95219dc34d92%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAANG%3DkUKSnNQ%3DdcKB-oeDdap7ydGNUy4dM9p4LOBZCrLdGL%3DUw%40mail.gmail.com.

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

<div dir=3D"ltr">ooo offsetof that works on members of virtual base classes=
 :)</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, =
Mar 15, 2018 at 6:09 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwizyto=
ryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think we sh=
ould leave this macro alone and add new operator with different name that w=
ill be available everywhere.<br>And then optionally define `offsetof ` with=
 use this new operator.<span class=3D""><br><br>On Thursday, March 15, 2018=
 at 6:21:19 PM UTC+1, Nicolas Lesser wrote:</span><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><span class=3D""><div dir=3D"auto">Not that I know of. This =
was mentioned in passing while discussing P0908, where it was suggested to =
make it an operator.<div dir=3D"auto"><br></div><div dir=3D"auto">EWG then =
went back and forth a bit, as making offsetof an operator would mean incomp=
atibilities with POSIX headers but better for modules.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">You might want to write a proposal for this.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">There is the Atom propo=
sal which proposes to have a &quot;module header&quot; which can also solve=
 this issue in a relatively clean way (P0947).</div></div><br></span><div c=
lass=3D"gmail_quote"><span class=3D""><div dir=3D"ltr">On Thu, Mar 15, 2018=
, 12:12 PM Nicol Bolas &lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt; wr=
ote:<br></div></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div d=
ir=3D"ltr">The C standard library defines a large number of things that are=
 macros. In the vast majority of cases, these are constants or functions, w=
hich can in C++ code be converted into `constexpr` variables or actual func=
tions. For all intents and purposes, such constructs can be drop-in replace=
ments for the C macros, which allows us to still work with them in a modula=
r standard library that doesn&#39;t allow macros.<br><br>`offsetof` is a sp=
ecial case because it&#39;s not a function. Or at least, it&#39;s not a fun=
ction that C++ at present allows you to write. Without reflection, there is=
 no way to pass a typename or member variable as a function parameter. And =
while there are ways we can work around it, none of those ways would be dro=
p-in replacements for `offsetof`; the user would have to change their code.=
<br><br>And even ignoring the non-drop-in part, there is currently no C++ r=
eplacement for `offsetof`. As modules moves forward, are there plans to res=
olve this issue and similar ones (beside the &quot;let&#39;s get modules to=
 export macros&quot; plan)?<br></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></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/c5f5ccc4-3267-442d-8cb2-<wbr>de1ae103a38e%40isocpp.org</a>.<br=
>
</span></blockquote></div>
</blockquote></div><span class=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7a864e9-a866-40d6-9688-95219dc34d92%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e7a8=
64e9-a866-40d6-<wbr>9688-95219dc34d92%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></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/CAANG%3DkUKSnNQ%3DdcKB-oeDdap7ydGNUy4=
dM9p4LOBZCrLdGL%3DUw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUK=
SnNQ%3DdcKB-oeDdap7ydGNUy4dM9p4LOBZCrLdGL%3DUw%40mail.gmail.com</a>.<br />

--000000000000efb9fa0567776971--

.

--94eb2c0d24e877ec7b056777cb07
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 15, 2018 at 2:09 PM, <inkwizytoryankes@gmail.com> wrote:

> I think we should leave this macro alone and add new operator with
> different name that will be available everywhere.
> And then optionally define `offsetof ` with use this new operator.
>

Some compilers do that already.
gcc and clang turn offsetof(a,b) into __builtin_offsetof(a, b).
IBM's xlC turns it into __offsetof(a,b).

--
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/CAHSYqdZjybBTSsXczYTzdWi2jFKCNA5NKwYbbZu4%2B4TkvcZEPA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 15, 2018 at 2:09 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwi=
zytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr">I think we should leave this macro alone and add new operator wit=
h different name that will be available everywhere.<br>And then optionally =
define `offsetof ` with use this new operator.</div></blockquote><div><br>S=
ome compilers do that already.<br>gcc and clang turn <font face=3D"monospac=
e, monospace">offsetof(a,b)</font> into <font face=3D"monospace, monospace"=
>__builtin_offsetof(a, b)</font>.<br>IBM&#39;s xlC turns it into <font face=
=3D"monospace, monospace">__offsetof(a,b)</font>.</div></div></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/CAHSYqdZjybBTSsXczYTzdWi2jFKCNA5NKwYb=
bZu4%2B4TkvcZEPA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZjybBTSs=
XczYTzdWi2jFKCNA5NKwYbbZu4%2B4TkvcZEPA%40mail.gmail.com</a>.<br />

--94eb2c0d24e877ec7b056777cb07--

.

--001a1140a99a93ce0d056778770e
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 15, 2018 at 2:37 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Thu, Mar 15, 2018 at 2:09 PM, <inkwizytoryankes@gmail.com> wrote:
>
>> I think we should leave this macro alone and add new operator with
>> different name that will be available everywhere.
>> And then optionally define `offsetof ` with use this new operator.
>>
>
> Some compilers do that already.
> gcc and clang turn offsetof(a,b) into __builtin_offsetof(a, b).
> IBM's xlC turns it into __offsetof(a,b).
>

So does MSVC -- although it seems to protect the __builtin_offsetof(a, b)
version behind another
macro of the form  _CRT_USE_BUILTIN_OFFSETOF that is disabled by default.
Doesn't the regular offsetof do something weird if the passed in type
implements operator&
and returns something evil?

--
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/CALEPxfuvJioe0St%3D3LBFVTDT_1_1xiciRduuqYeSy0koJpT4_A%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 15, 2018 at 2:37 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span clas=
s=3D"gmail-">On Thu, Mar 15, 2018 at 2:09 PM,  <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:inkwizytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">I think we should leave this macro alone and ad=
d new operator with different name that will be available everywhere.<br>An=
d then optionally define `offsetof ` with use this new operator.</div></blo=
ckquote></span><div><br>Some compilers do that already.<br>gcc and clang tu=
rn <font face=3D"monospace, monospace">offsetof(a,b)</font> into <font face=
=3D"monospace, monospace">__builtin_offsetof(a, b)</font>.<br>IBM&#39;s xlC=
 turns it into <font face=3D"monospace, monospace">__offsetof(a,b)</font>.<=
/div></div></div></div></blockquote><div><br></div><div>So does MSVC -- alt=
hough it seems to protect the __builtin_offsetof(a, b) version behind anoth=
er=C2=A0</div><div>macro of the form=C2=A0=C2=A0_CRT_USE_BUILTIN_OFFSETOF t=
hat is disabled by default.</div><div>Doesn&#39;t the regular offsetof do s=
omething weird if the passed in type implements operator&amp;</div><div>and=
 returns something evil?</div><div><br></div></div><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/CALEPxfuvJioe0St%3D3LBFVTDT_1_1xiciRd=
uuqYeSy0koJpT4_A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfuvJioe0S=
t%3D3LBFVTDT_1_1xiciRduuqYeSy0koJpT4_A%40mail.gmail.com</a>.<br />

--001a1140a99a93ce0d056778770e--

.

On Thursday, 15 March 2018 10:21:05 PDT Nicolas Lesser wrote:
> Not that I know of. This was mentioned in passing while discussing P0908,
> where it was suggested to make it an operator.

I'd bring back the idea of using pointers to members as a complete replacement
for offsetof.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/8745898.m7JMjNCkYK%40tjmaciei-mobl1.

.

--f403045c38a292153f056778d359
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 15, 2018 at 3:26 PM, Dilip Ranganathan <misc.usage@gmail.com>
wrote:
>
> Doesn't the regular offsetof do something weird if the passed in type
> implements operator&
> and returns something evil?
>

A naive definition of offsetof(Class, Member) is
((std::size_t)(&((Class*)0)->Member)),
which won't work if Member has an operator&.

--
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/CAHSYqdYNHqtEVJDGF32BkhHEidZV1noMsBte1mS%2BYEi02_zQ7A%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 15, 2018 at 3:26 PM, Dilip Ranganathan <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:misc.usage@gmail.com" target=3D"_blank">misc.usage@gmail.com</a=
>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div>Doesn&#39;t the regular =
offsetof do something weird if the passed in type implements operator&amp;<=
/div><div>and returns something evil?</div></div></div></div></blockquote><=
div><br>A naive definition of <font face=3D"monospace, monospace">offsetof(=
Class, Member)</font> is <font face=3D"monospace, monospace">((std::size_t)=
(&amp;((Class*)0)-&gt;Member))</font><font face=3D"arial, helvetica, sans-s=
erif">,<br>which won&#39;t work if Member has an operator&amp;.</font></div=
></div></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/CAHSYqdYNHqtEVJDGF32BkhHEidZV1noMsBte=
1mS%2BYEi02_zQ7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYNHqtEVJ=
DGF32BkhHEidZV1noMsBte1mS%2BYEi02_zQ7A%40mail.gmail.com</a>.<br />

--f403045c38a292153f056778d359--

.

On 03/15/18 22:41, Thiago Macieira wrote:
> On Thursday, 15 March 2018 10:21:05 PDT Nicolas Lesser wrote:
>> Not that I know of. This was mentioned in passing while discussing P0908,
>> where it was suggested to make it an operator.
>
> I'd bring back the idea of using pointers to members as a complete replacement
> for offsetof.

P0908 suggested something along these lines and it was rejected.

--
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/08d4fa62-ab7d-f257-5a50-fc77f4d35a24%40gmail.com.

.

On Thursday, 15 March 2018 13:53:54 PDT Andrey Semashev wrote:
> On 03/15/18 22:41, Thiago Macieira wrote:
> > On Thursday, 15 March 2018 10:21:05 PDT Nicolas Lesser wrote:
> >> Not that I know of. This was mentioned in passing while discussing P0908,
> >> where it was suggested to make it an operator.
> >
> > I'd bring back the idea of using pointers to members as a complete
> > replacement for offsetof.
>
> P0908 suggested something along these lines and it was rejected.

That's not what I meant.

I meant not using offsetof at all. All uses of offsetof can be replaced with a
pointer to member or pointer to container.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/2034613.rN3AoRdNao%40tjmaciei-mobl1.

.

On 03/16/18 02:12, Thiago Macieira wrote:
> On Thursday, 15 March 2018 13:53:54 PDT Andrey Semashev wrote:
>> On 03/15/18 22:41, Thiago Macieira wrote:
>>> On Thursday, 15 March 2018 10:21:05 PDT Nicolas Lesser wrote:
>>>> Not that I know of. This was mentioned in passing while discussing P0908,
>>>> where it was suggested to make it an operator.
>>>
>>> I'd bring back the idea of using pointers to members as a complete
>>> replacement for offsetof.
>>
>> P0908 suggested something along these lines and it was rejected.
>
> That's not what I meant.
>
> I meant not using offsetof at all. All uses of offsetof can be replaced with a
> pointer to member or pointer to container.

Not sure what you mean by pointer to container.

You cannot emulate this use case with a pointer to member:

   struct A
   {
     int x[10];
   };

   offsetof(A, x[5]);

Also, it is much more difficult to obtain an offset to a nested member
without offsetof:

   struct B
   {
     A a;
   };

   offsetof(B, a.x[5]);

Don't get me wrong, being able to extract offset information from a
pointer to member would be useful, but it wouldn't be an equivalent
replacement of offsetof.

--
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/d4126e87-47a3-2693-e731-5a0f7f1d6732%40gmail.com.

.

On Thursday, 15 March 2018 16:37:04 PDT Andrey Semashev wrote:
> > I meant not using offsetof at all. All uses of offsetof can be replaced
> > with a pointer to member or pointer to container.
>
> Not sure what you mean by pointer to container.

The inverse/dual of a pointer to member. Instead of pointing from the top of
the structure to a member, it reverses and points to the top of the structure.

> You cannot emulate this use case with a pointer to member:
>
>    struct A
>    {
>      int x[10];
>    };
>
>    offsetof(A, x[5]);

Why not? We can if we give ourselves the syntax for it.

> Also, it is much more difficult to obtain an offset to a nested member
> without offsetof:
>
>    struct B
>    {
>      A a;
>    };
>
>    offsetof(B, a.x[5]);

No, it isn't.

 int A:: *int_in_A = &A::y; // just so we don't discuss arrays just now
 A B:: *A_in_B = &B::a;
 int B:: *int_in_B = int_in_A + A_in_B; // syntax TBD

> Don't get me wrong, being able to extract offset information from a
> pointer to member would be useful, but it wouldn't be an equivalent
> replacement of offsetof.

It would be if we make it.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/2319008.6H3YVR8kxN%40tjmaciei-mobl1.

.

On 03/16/18 03:05, Thiago Macieira wrote:
> On Thursday, 15 March 2018 16:37:04 PDT Andrey Semashev wrote:
>>> I meant not using offsetof at all. All uses of offsetof can be replaced
>>> with a pointer to member or pointer to container.
>>
>> Not sure what you mean by pointer to container.
>
> The inverse/dual of a pointer to member. Instead of pointing from the top of
> the structure to a member, it reverses and points to the top of the structure.
>
>> You cannot emulate this use case with a pointer to member:
>>
>>     struct A
>>     {
>>       int x[10];
>>     };
>>
>>     offsetof(A, x[5]);
>
> Why not? We can if we give ourselves the syntax for it.

Well, we don't have one now, that's why you can't do that. We need at
least a proposal for this new syntax to have a meaningful comparison
with offsetof.

>> Also, it is much more difficult to obtain an offset to a nested member
>> without offsetof:
>>
>>     struct B
>>     {
>>       A a;
>>     };
>>
>>     offsetof(B, a.x[5]);
>
> No, it isn't.
>
>  int A:: *int_in_A = &A::y; // just so we don't discuss arrays just now
>  A B:: *A_in_B = &B::a;
>  int B:: *int_in_B = int_in_A + A_in_B; // syntax TBD

Right, that illustrates what I called "much more difficult". offsetof is
pretty difficult to beat in code conciseness and clarity.

--
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/f8eb7785-19fb-d220-d06b-b973f051f283%40gmail.com.

.

On Thursday, 15 March 2018 18:05:52 PDT Andrey Semashev wrote:
> > Why not? We can if we give ourselves the syntax for it.
>
> Well, we don't have one now, that's why you can't do that. We need at
> least a proposal for this new syntax to have a meaningful comparison
> with offsetof.

Right. I'm just saying that we should use pointer-to-members instead, since
they would also give us type safety, something that offsetof can't do.

> >  int A:: *int_in_A = &A::y; // just so we don't discuss arrays just now
> >  A B:: *A_in_B = &B::a;
> >  int B:: *int_in_B = int_in_A + A_in_B; // syntax TBD
>
> Right, that illustrates what I called "much more difficult". offsetof is
> pretty difficult to beat in code conciseness and clarity.

But you get an offset, which breaks a lot of assumptions in the type system.
It's not really easy to use.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/2555999.PcE7Su909f%40tjmaciei-mobl1.

.

------=_Part_305_480958435.1521172549316
Content-Type: multipart/alternative;
 boundary="----=_Part_306_1034161659.1521172549316"

------=_Part_306_1034161659.1521172549316
Content-Type: text/plain; charset="UTF-8"

On Thursday, March 15, 2018 at 2:09:44 PM UTC-4, Marcin Jaczewski wrote:
>
> I think we should leave this macro alone and add new operator with
> different name that will be available everywhere.
> And then optionally define `offsetof ` with use this new operator.
>

The problem I'm talking about here is that if you have a `std.cstddef`
module, without the ability to export macros, it cannot export anything
which is compatible with `offsetof` usage. So even if we make an operator
for this or empower member pointers or whatever, the existence of such a
feature won't allow you to switch from `#include <cstddef>` to `import
std.cstddef` without changing your code.

--
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/71ed1718-d272-4920-92fe-3b59750e6fb8%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, March 15, 2018 at 2:09:44 PM UTC-4, Marcin Ja=
czewski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>I think we should leave this macro alone and add new operator with differe=
nt name that will be available everywhere.<br>And then optionally define `o=
ffsetof ` with use this new operator.<br></div></blockquote><div><br>The pr=
oblem I&#39;m talking about here is that if you have a `std.cstddef` module=
, without the ability to export macros, it cannot export anything which is =
compatible with `offsetof` usage. So even if we make an operator for this o=
r empower member pointers or whatever, the existence of such a feature won&=
#39;t allow you to switch from `#include &lt;cstddef&gt;` to `import std.cs=
tddef` without changing your code.</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/71ed1718-d272-4920-92fe-3b59750e6fb8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/71ed1718-d272-4920-92fe-3b59750e6fb8=
%40isocpp.org</a>.<br />

------=_Part_306_1034161659.1521172549316--

------=_Part_305_480958435.1521172549316--

.

--001a114975742fea86056788c9c2
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 15, 2018 at 11:55 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> The problem I'm talking about here is that if you have a `std.cstddef`
> module, without the ability to export macros, it cannot export anything
> which is compatible with `offsetof` usage. So even if we make an operator
> for this or empower member pointers or whatever, the existence of such a
> feature won't allow you to switch from `#include <cstddef>` to `import
> std.cstddef` without changing your code.
>

You just need to simultaneously modify C++ so that there is a built-in
equivalent
to offsetof, and make offsetof a pre-defined macro that expands to that.
Why is
that difficult?

Are you imagining that modular C++ isn't going to have a preprocessor at
all?
Users of __FILE__, __LINE__, __PRETTY_FUNCTION__, and __COUNTER__
may want to have a word with you.

--
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/CAHSYqdaG06U9DwCW57%3DUM5GrUHkXWV9Ah5u%2B1wDrisBSo_nQig%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 15, 2018 at 11:55 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The proble=
m I&#39;m talking about here is that if you have a `std.cstddef` module, wi=
thout the ability to export macros, it cannot export anything which is comp=
atible with `offsetof` usage. So even if we make an operator for this or em=
power member pointers or whatever, the existence of such a feature won&#39;=
t allow you to switch from `#include &lt;cstddef&gt;` to `import std.cstdde=
f` without changing your code.</div></div></blockquote><div><br>You just ne=
ed to simultaneously modify C++ so that there is a built-in equivalent<br>t=
o offsetof, and make offsetof a pre-defined macro that expands to that.=C2=
=A0 Why is<br>that difficult?<br><br>Are you imagining that modular C++ isn=
&#39;t going to have a preprocessor at all?<br>Users of __FILE__, __LINE__,=
 __PRETTY_FUNCTION__, and __COUNTER__<br>may want to have a word with you.<=
/div></div></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/CAHSYqdaG06U9DwCW57%3DUM5GrUHkXWV9Ah5=
u%2B1wDrisBSo_nQig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaG06U9=
DwCW57%3DUM5GrUHkXWV9Ah5u%2B1wDrisBSo_nQig%40mail.gmail.com</a>.<br />

--001a114975742fea86056788c9c2--

.

--001a1143dd1ebbef420567890d80
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 15, 2018 at 8:05 PM, Thiago Macieira <thiago@macieira.org>
wrote:
>
>         int A:: *int_in_A = &A::y;      // just so we don't discuss arrays
> just now
>         A B:: *A_in_B = &B::a;
>         int B:: *int_in_B = int_in_A + A_in_B;  // syntax TBD


Rather than inventing a new syntax, the obvious solution is to allow the
creation of
member pointers using a syntax that allows C designators to be used,
instead of
just *qualified-id*s.  The code above would then just be

    struct A { int x[10]; };
    struct B { A a; };
    int B::*number_5 = &B::a.x[5];

--
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/CAHSYqdbvMA-gv%2BeP1iu53J6pnLTmr9KjR4_0XJBnEsy5qth%3D%2BA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 15, 2018 at 8:05 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int A:: *int_in_A =3D &amp;A::y;=C2=A0 =C2=A0 =
=C2=A0 // just so we don&#39;t discuss arrays just now<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A B:: *A_in_B =3D &amp;B::a;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int B:: *int_in_B =3D int_in_A + A_in_B;=C2=A0 =
// syntax TBD</blockquote><div><br>Rather than inventing a new syntax, the =
obvious solution is to allow the creation of<br>member pointers using a syn=
tax that allows C designators to be used, instead of<br>just <i>qualified-i=
d</i>s.=C2=A0 The code above would then just be<br><br><font face=3D"monosp=
ace, monospace">=C2=A0 =C2=A0 struct A { int x[10]; };<br>=C2=A0 =C2=A0 str=
uct B { A a; };<br>=C2=A0 =C2=A0 int B::*number_5 =3D &amp;B::a.x[5];</font=
></div></div></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/CAHSYqdbvMA-gv%2BeP1iu53J6pnLTmr9KjR4=
_0XJBnEsy5qth%3D%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbvMA=
-gv%2BeP1iu53J6pnLTmr9KjR4_0XJBnEsy5qth%3D%2BA%40mail.gmail.com</a>.<br />

--001a1143dd1ebbef420567890d80--

.

------=_Part_1144_1649908020.1521213405837
Content-Type: multipart/alternative;
 boundary="----=_Part_1145_1684924087.1521213405838"

------=_Part_1145_1684924087.1521213405838
Content-Type: text/plain; charset="UTF-8"



On Friday, March 16, 2018 at 10:54:35 AM UTC-4, Hyman Rosen wrote:
>
> On Thu, Mar 15, 2018 at 11:55 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>>
>> The problem I'm talking about here is that if you have a `std.cstddef`
>> module, without the ability to export macros, it cannot export anything
>> which is compatible with `offsetof` usage. So even if we make an operator
>> for this or empower member pointers or whatever, the existence of such a
>> feature won't allow you to switch from `#include <cstddef>` to `import
>> std.cstddef` without changing your code.
>>
>
> You just need to simultaneously modify C++ so that there is a built-in
> equivalent
> to offsetof, and make offsetof a pre-defined macro that expands to that.
>

And if modules can't export macros, how will `import std.cstddef` give me
access to that module?

--
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/22ef47e6-e957-4519-820f-1decb09a116d%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, March 16, 2018 at 10:54:35 AM UTC-4, Hy=
man Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote">On Thu, Mar 15, 2018 at 11:55 PM, Nicol =
Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"Yu6D6PDvAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>The problem I&#39;m talking about h=
ere is that if you have a `std.cstddef` module, without the ability to expo=
rt macros, it cannot export anything which is compatible with `offsetof` us=
age. So even if we make an operator for this or empower member pointers or =
whatever, the existence of such a feature won&#39;t allow you to switch fro=
m `#include &lt;cstddef&gt;` to `import std.cstddef` without changing your =
code.</div></div></blockquote><div><br>You just need to simultaneously modi=
fy C++ so that there is a built-in equivalent<br>to offsetof, and make offs=
etof a pre-defined macro that expands to that.</div></div></div></div></blo=
ckquote><div><br>And if modules can&#39;t export macros, how will `import s=
td.cstddef` give me access to that module?</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/22ef47e6-e957-4519-820f-1decb09a116d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/22ef47e6-e957-4519-820f-1decb09a116d=
%40isocpp.org</a>.<br />

------=_Part_1145_1684924087.1521213405838--

------=_Part_1144_1649908020.1521213405837--

.

--001a1149231856feab05678956dd
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 16, 2018 at 11:16 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> You just need to simultaneously modify C++ so that there is a built-in
>> equivalent
>> to offsetof, and make offsetof a pre-defined macro that expands to that.
>>
>
> And if modules can't export macros, how will `import std.cstddef` give me
> access to that module?
>

What module?  I don't understand.

Let me try again:

   - Change C++ so that there is a built-in version of offsetof under a
   different name, say __offsetof.
   - __offsetof is available for use in all C++ code without any header or
   module needed, just as sizeof is.
   - Also change C++ so that offsetof is a pre-defined macro that expands
   to __offsetof.
   - As a pre-defined macro, offsetof is available without any header or
   module needed, just as __LINE__ is.

OK?

--
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/CAHSYqdZA9zarj3qL0otGwaQQU-g2Tkk7jEmWziFBWz%3DiYR2ANg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 16, 2018 at 11:16 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div>You just need to simultaneously modify C++ so that th=
ere is a built-in equivalent<br>to offsetof, and make offsetof a pre-define=
d macro that expands to that.</div></div></div></div></blockquote></span><d=
iv><br>And if modules can&#39;t export macros, how will `import std.cstddef=
` give me access to that module?</div></div></blockquote><div><br>What modu=
le?=C2=A0 I don&#39;t understand.<br><br>Let me try again:<br><ul><li>Chang=
e C++ so that there is a built-in version of <font face=3D"monospace, monos=
pace">offsetof</font> under a different name, say <font face=3D"monospace, =
monospace">__offsetof</font>.</li><li><font face=3D"monospace, monospace">

<span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-siz=
e:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:n=
ormal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px;background-color:r=
gb(255,255,255);text-decoration-style:initial;text-decoration-color:initial=
;float:none;display:inline">__offsetof</span>=C2=A0</font>is available for =
use in all C++ code without any header or module needed, just as <font face=
=3D"monospace, monospace">sizeof</font> is.</li><li>Also change C++ so that=
 <font face=3D"monospace, monospace">offsetof</font>=C2=A0is a pre-defined =
macro that expands to <font face=3D"monospace, monospace">

<span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-siz=
e:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:n=
ormal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px;background-color:r=
gb(255,255,255);text-decoration-style:initial;text-decoration-color:initial=
;float:none;display:inline">__offsetof</span></font>.</li><li>As a pre-defi=
ned macro, <font face=3D"monospace, monospace">offsetof</font> is available=
 without any header or module needed, just as __LINE__ is.<br></li></ul><di=
v>OK?</div></div></div></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/CAHSYqdZA9zarj3qL0otGwaQQU-g2Tkk7jEmW=
ziFBWz%3DiYR2ANg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZA9zarj3=
qL0otGwaQQU-g2Tkk7jEmWziFBWz%3DiYR2ANg%40mail.gmail.com</a>.<br />

--001a1149231856feab05678956dd--

.

On Friday, 16 March 2018 08:13:21 PDT Hyman Rosen wrote:
> Rather than inventing a new syntax, the obvious solution is to allow the
> creation of
> member pointers using a syntax that allows C designators to be used,
> instead of
> just *qualified-id*s.  The code above would then just be
>
>     struct A { int x[10]; };
>     struct B { A a; };
>     int B::*number_5 = &B::a.x[5];

I think I still want the syntax for adding, subtracting and negating pointer
to members.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/1521219213.aWm8xxBS2X%40tjmaciei-mobl1.

.

--f403045c16be393f3a056789a260
Content-Type: text/plain; charset="UTF-8"

Yeah, me too :).

There's all kinds of caveats with that though, so I'm anticipating some
resistance.

G

On Fri, Mar 16, 2018 at 3:51 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Friday, 16 March 2018 08:13:21 PDT Hyman Rosen wrote:
> > Rather than inventing a new syntax, the obvious solution is to allow the
> > creation of
> > member pointers using a syntax that allows C designators to be used,
> > instead of
> > just *qualified-id*s.  The code above would then just be
> >
> >     struct A { int x[10]; };
> >     struct B { A a; };
> >     int B::*number_5 = &B::a.x[5];
>
> I think I still want the syntax for adding, subtracting and negating
> pointer
> to members.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> 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/1521219213.aWm8xxBS2X%40tjmaciei-mobl1.
>

--
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/CAANG%3DkUjdhf5q7wF-UF98pazAQ_iX70ffa50E11jzXB6Bbb2LQ%40mail.gmail.com.

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

<div dir=3D"ltr">Yeah, me too :).<div><br></div><div>There&#39;s all kinds =
of caveats with that though, so I&#39;m anticipating some resistance.</div>=
<div><br></div><div>G</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Mar 16, 2018 at 3:51 PM, Thiago Macieira <span dir=
=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><spa=
n class=3D"">On Friday, 16 March 2018 08:13:21 PDT Hyman Rosen wrote:<br>
&gt; Rather than inventing a new syntax, the obvious solution is to allow t=
he<br>
&gt; creation of<br>
&gt; member pointers using a syntax that allows C designators to be used,<b=
r>
&gt; instead of<br>
</span>&gt; just *qualified-id*s.=C2=A0 The code above would then just be<b=
r>
<span class=3D"">&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0struct A { int x[10]; };<br>
&gt;=C2=A0 =C2=A0 =C2=A0struct B { A a; };<br>
&gt;=C2=A0 =C2=A0 =C2=A0int B::*number_5 =3D &amp;B::a.x[5];<br>
<br>
</span>I think I still want the syntax for adding, subtracting and negating=
 pointer<br>
to members.<br>
<span class=3D""><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
</span><span class=3D"">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/1521219213.aWm8xxBS2X%40tjmaci=
ei-mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/=
<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1521219213.<wbr>aWm8xxBS2X%40tjm=
aciei-mobl1</a>.<br>
</blockquote></div><br></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/CAANG%3DkUjdhf5q7wF-UF98pazAQ_iX70ffa=
50E11jzXB6Bbb2LQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUjdhf5=
q7wF-UF98pazAQ_iX70ffa50E11jzXB6Bbb2LQ%40mail.gmail.com</a>.<br />

--f403045c16be393f3a056789a260--

.

------=_Part_1850_1285662006.1521220991948
Content-Type: multipart/alternative;
 boundary="----=_Part_1851_1871515636.1521220991948"

------=_Part_1851_1871515636.1521220991948
Content-Type: text/plain; charset="UTF-8"

On Friday, March 16, 2018 at 11:34:02 AM UTC-4, Hyman Rosen wrote:
>
> On Fri, Mar 16, 2018 at 11:16 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>>
>> You just need to simultaneously modify C++ so that there is a built-in
>>> equivalent
>>> to offsetof, and make offsetof a pre-defined macro that expands to that.
>>>
>>
>> And if modules can't export macros, how will `import std.cstddef` give me
>> access to that module?
>>
>
> What module?  I don't understand.
>
> Let me try again:
>
>    - Change C++ so that there is a built-in version of offsetof under a
>    different name, say __offsetof.
>    - __offsetof is available for use in all C++ code without any header
>    or module needed, just as sizeof is.
>    - Also change C++ so that offsetof is a pre-defined macro that expands
>    to __offsetof.
>
>
Oh, when you said "built-in" you meant like "supplied by the compiler".

So... what happens with people's code that *don't* include <cstddef> or
<stddef> that happens to use the `offsetof` identifier? Admittedly this is
a minor issue, as I rather doubt someone's going to make a class or
function that conflicts with a fairly widely known C macro that gets
included by quite a few things (even if only because of other useful
things).

--
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/64578641-a89f-4b60-82ce-5183a54a3630%40isocpp.org.

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

<div dir=3D"ltr">On Friday, March 16, 2018 at 11:34:02 AM UTC-4, Hyman Rose=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote">On Fri, Mar 16, 2018 at 11:16 AM, Nicol Bolas <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"BhLMGhjyAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote"><div>You just need to simult=
aneously modify C++ so that there is a built-in equivalent<br>to offsetof, =
and make offsetof a pre-defined macro that expands to that.</div></div></di=
v></div></blockquote></span><div><br>And if modules can&#39;t export macros=
, how will `import std.cstddef` give me access to that module?</div></div><=
/blockquote><div><br>What module?=C2=A0 I don&#39;t understand.<br><br></di=
v></div></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Let me try again:<=
br><ul><li>Change C++ so that there is a built-in version of <font face=3D"=
monospace, monospace">offsetof</font> under a different name, say <font fac=
e=3D"monospace, monospace">__offsetof</font>.</li><li><font face=3D"monospa=
ce, monospace">

<span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-siz=
e:small;font-style:normal;font-weight:400;letter-spacing:normal;text-align:=
left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x;background-color:rgb(255,255,255);float:none;display:inline">__offsetof</=
span>=C2=A0</font>is available for use in all C++ code without any header o=
r module needed, just as <font face=3D"monospace, monospace">sizeof</font> =
is.</li><li>Also change C++ so that <font face=3D"monospace, monospace">off=
setof</font>=C2=A0is a pre-defined macro that expands to <font face=3D"mono=
space, monospace">

<span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-siz=
e:small;font-style:normal;font-weight:400;letter-spacing:normal;text-align:=
left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x;background-color:rgb(255,255,255);float:none;display:inline">__offsetof</=
span></font>.</li></ul></div></div></div></div></blockquote><div><br>Oh, wh=
en you said &quot;built-in&quot; you meant like &quot;supplied by the compi=
ler&quot;.<br><br>So... what happens with people&#39;s code that <i>don&#39=
;t</i> include &lt;cstddef&gt; or &lt;stddef&gt; that happens to use the `o=
ffsetof` identifier? Admittedly this is a minor issue, as I rather doubt so=
meone&#39;s going to make a class or function that conflicts with a fairly =
widely known C macro that gets included by quite a few things (even if only=
 because of other useful things).<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/64578641-a89f-4b60-82ce-5183a54a3630%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/64578641-a89f-4b60-82ce-5183a54a3630=
%40isocpp.org</a>.<br />

------=_Part_1851_1871515636.1521220991948--

------=_Part_1850_1285662006.1521220991948--

.

--94eb2c0d24e85cace505678b46e7
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 16, 2018 at 1:23 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> So... what happens with people's code that *don't* include <cstddef> or
> <stddef> that happens to use the `offsetof` identifier?
>

It stops working, just like code that uses concept and requires.

--
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/CAHSYqdbXmmEgWEPE-dZT8yzP8WN4aZK9o-9nOYCykDZDTGNO5Q%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 16, 2018 at 1:23 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>So... what =
happens with people&#39;s code that <i>don&#39;t</i> include &lt;cstddef&gt=
; or &lt;stddef&gt; that happens to use the `offsetof` identifier?</div></d=
iv></blockquote><div><br>It stops working, just like code that uses <font f=
ace=3D"monospace, monospace">concept</font> and <font face=3D"monospace, mo=
nospace">requires</font>.</div></div></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/CAHSYqdbXmmEgWEPE-dZT8yzP8WN4aZK9o-9n=
OYCykDZDTGNO5Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbXmmEgWEPE=
-dZT8yzP8WN4aZK9o-9nOYCykDZDTGNO5Q%40mail.gmail.com</a>.<br />

--94eb2c0d24e85cace505678b46e7--

.

------=_Part_2119_1204606126.1521226589362
Content-Type: multipart/alternative;
 boundary="----=_Part_2120_2045095458.1521226589362"

------=_Part_2120_2045095458.1521226589362
Content-Type: text/plain; charset="UTF-8"

On Friday, March 16, 2018 at 8:13:44 AM UTC-7, Hyman Rosen wrote:
>
>
>     struct A { int x[10]; };
>     struct B { A a; };
>     int B::*number_5 = &B::a.x[5];
>

Careful here: this is a breaking change.  Consider this currently-legal
code:

struct W { int x[10]; };
struct X { W w; };
struct Y { W w; };
struct Z : X, Y
{
    void f();
};

void Z::f()
{
    int *p = &Y::w.x[5];
    *p = 4;
}

You'd need to use parentheses and define operators . and [] on member
operators in order to solve this:

(&B::a).x[5]

I really like Thiago's proposal regarding data member pointers, but it has
a major problem: it's an ABI break.  Some proposed constructions would
allow data member pointers with a negative offset (pointing to the
containing class's members), and both the Microsoft and Itanium ABIs encode
null member pointers as -1.

Melissa

--
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/dcd5b3da-0018-4eca-b7a6-b94e950de2de%40isocpp.org.

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

<div dir=3D"ltr">On Friday, March 16, 2018 at 8:13:44 AM UTC-7, Hyman Rosen=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote"><br><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 struct A { int x[10]; };<br>=C2=A0 =C2=A0 struct B { A a; };<br>=
=C2=A0 =C2=A0 int B::*number_5 =3D &amp;B::a.x[5];</font></div></div></div>=
</div></blockquote><div><br>Careful here: this is a breaking change.=C2=A0 =
Consider this currently-legal code:<br><br><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: #=
008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> W </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">10</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">];</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> X </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> W=
 w</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> Y </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> W w</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> Z </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> X</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> Y<br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> Z</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">f</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">p </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">Y</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">w</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">];</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">p </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></=
code></div><br>You&#39;d need to use parentheses and define operators . and=
 [] on member operators in order to solve this:<br><br>(&amp;B::a).x[5]<br>=
<br>I really like Thiago&#39;s proposal regarding data member pointers, but=
 it has a major problem: it&#39;s an ABI break.=C2=A0 Some proposed constru=
ctions would allow data member pointers with a negative offset (pointing to=
 the containing class&#39;s members), and both the Microsoft and Itanium AB=
Is encode null member pointers as -1.<br><br>Melissa<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/dcd5b3da-0018-4eca-b7a6-b94e950de2de%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dcd5b3da-0018-4eca-b7a6-b94e950de2de=
%40isocpp.org</a>.<br />

------=_Part_2120_2045095458.1521226589362--

------=_Part_2119_1204606126.1521226589362--

.

--001a1143dd1e614aac05678c9348
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 16, 2018 at 2:56 PM, Myriachan <myriachan@gmail.com> wrote:

> On Friday, March 16, 2018 at 8:13:44 AM UTC-7, Hyman Rosen wrote:
>>
>>
>>     struct A { int x[10]; };
>>     struct B { A a; };
>>     int B::*number_5 = &B::a.x[5];
>>
>
> Careful here: this is a breaking change.  Consider this currently-legal
> code:
>
> struct W { int x[10]; };
> struct X { W w; };
> struct Y { W w; };
> struct Z : X, Y
> {
>     void f();
> };
>
> void Z::f()
> {
>     int *p = &Y::w.x[5];
>     *p = 4;
> }
>
>
I swear, C++ drives me more crazy every time I look at it.  Notice the
obvious corollary to your code:

    void Z::f()
    {
        int *p = &(Y::w.x[5]);  // OK
        int *q = & Y::w.x[5] ;  // OK
        W   *r = &(Y::w)     ;  // OK
        W   *s = & Y::w      ;  // Error
    }

C++ syntax is a horrible hodgepodge mess caused by too much "it would be
nice if *this* meant *that*"
without any consideration of making everything globally consistent.

--
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/CAHSYqda43Vo0%2BvhY3i39JT1%2BcBaumAwynsJ%3D-NjGu7Nm3Yd9-A%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 16, 2018 at 2:56 PM, Myriachan <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
"">On Friday, March 16, 2018 at 8:13:44 AM UTC-7, Hyman Rosen wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><br><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 struct A =
{ int x[10]; };<br>=C2=A0 =C2=A0 struct B { A a; };<br>=C2=A0 =C2=A0 int B:=
:*number_5 =3D &amp;B::a.x[5];</font></div></div></div></div></blockquote><=
/span><div><br>Careful here: this is a breaking change.=C2=A0 Consider this=
 currently-legal code:<br><br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px" class=
=3D"m_6940945667384060895prettyprint"><code class=3D"m_6940945667384060895p=
rettyprint"><div class=3D"m_6940945667384060895subprettyprint"><span style=
=3D"color:#008" class=3D"m_6940945667384060895styled-by-prettify">struct</s=
pan><span style=3D"color:#000" class=3D"m_6940945667384060895styled-by-pret=
tify"> W </span><span style=3D"color:#660" class=3D"m_6940945667384060895st=
yled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_69409456673=
84060895styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_6=
940945667384060895styled-by-prettify">int</span><span style=3D"color:#000" =
class=3D"m_6940945667384060895styled-by-prettify"> x</span><span style=3D"c=
olor:#660" class=3D"m_6940945667384060895styled-by-prettify">[</span><span =
style=3D"color:#066" class=3D"m_6940945667384060895styled-by-prettify">10</=
span><span style=3D"color:#660" class=3D"m_6940945667384060895styled-by-pre=
ttify">];</span><span style=3D"color:#000" class=3D"m_6940945667384060895st=
yled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_69409456673=
84060895styled-by-prettify">};</span><span style=3D"color:#000" class=3D"m_=
6940945667384060895styled-by-prettify"><br></span><span style=3D"color:#008=
" class=3D"m_6940945667384060895styled-by-prettify">struct</span><span styl=
e=3D"color:#000" class=3D"m_6940945667384060895styled-by-prettify"> X </spa=
n><span style=3D"color:#660" class=3D"m_6940945667384060895styled-by-pretti=
fy">{</span><span style=3D"color:#000" class=3D"m_6940945667384060895styled=
-by-prettify"> W w</span><span style=3D"color:#660" class=3D"m_694094566738=
4060895styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_69=
40945667384060895styled-by-prettify"> </span><span style=3D"color:#660" cla=
ss=3D"m_6940945667384060895styled-by-prettify">};</span><span style=3D"colo=
r:#000" class=3D"m_6940945667384060895styled-by-prettify"><br></span><span =
style=3D"color:#008" class=3D"m_6940945667384060895styled-by-prettify">stru=
ct</span><span style=3D"color:#000" class=3D"m_6940945667384060895styled-by=
-prettify"> Y </span><span style=3D"color:#660" class=3D"m_6940945667384060=
895styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_694094=
5667384060895styled-by-prettify"> W w</span><span style=3D"color:#660" clas=
s=3D"m_6940945667384060895styled-by-prettify">;</span><span style=3D"color:=
#000" class=3D"m_6940945667384060895styled-by-prettify"> </span><span style=
=3D"color:#660" class=3D"m_6940945667384060895styled-by-prettify">};</span>=
<span style=3D"color:#000" class=3D"m_6940945667384060895styled-by-prettify=
"><br></span><span style=3D"color:#008" class=3D"m_6940945667384060895style=
d-by-prettify">struct</span><span style=3D"color:#000" class=3D"m_694094566=
7384060895styled-by-prettify"> Z </span><span style=3D"color:#660" class=3D=
"m_6940945667384060895styled-by-prettify">:</span><span style=3D"color:#000=
" class=3D"m_6940945667384060895styled-by-prettify"> X</span><span style=3D=
"color:#660" class=3D"m_6940945667384060895styled-by-prettify">,</span><spa=
n style=3D"color:#000" class=3D"m_6940945667384060895styled-by-prettify"> Y=
<br></span><span style=3D"color:#660" class=3D"m_6940945667384060895styled-=
by-prettify">{</span><span style=3D"color:#000" class=3D"m_6940945667384060=
895styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008" =
class=3D"m_6940945667384060895styled-by-prettify">void</span><span style=3D=
"color:#000" class=3D"m_6940945667384060895styled-by-prettify"> f</span><sp=
an style=3D"color:#660" class=3D"m_6940945667384060895styled-by-prettify">(=
);</span><span style=3D"color:#000" class=3D"m_6940945667384060895styled-by=
-prettify"><br></span><span style=3D"color:#660" class=3D"m_694094566738406=
0895styled-by-prettify">};</span><span style=3D"color:#000" class=3D"m_6940=
945667384060895styled-by-prettify"><br><br></span><span style=3D"color:#008=
" class=3D"m_6940945667384060895styled-by-prettify">void</span><span style=
=3D"color:#000" class=3D"m_6940945667384060895styled-by-prettify"> Z</span>=
<span style=3D"color:#660" class=3D"m_6940945667384060895styled-by-prettify=
">::</span><span style=3D"color:#000" class=3D"m_6940945667384060895styled-=
by-prettify">f</span><span style=3D"color:#660" class=3D"m_6940945667384060=
895styled-by-prettify">()</span><span style=3D"color:#000" class=3D"m_69409=
45667384060895styled-by-prettify"><br></span><span style=3D"color:#660" cla=
ss=3D"m_6940945667384060895styled-by-prettify">{</span><span style=3D"color=
:#000" class=3D"m_6940945667384060895styled-by-prettify"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color:#008" class=3D"m_6940945667384060895styled-by-p=
rettify">int</span><span style=3D"color:#000" class=3D"m_694094566738406089=
5styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_69409456=
67384060895styled-by-prettify">*</span><span style=3D"color:#000" class=3D"=
m_6940945667384060895styled-by-prettify">p </span><span style=3D"color:#660=
" class=3D"m_6940945667384060895styled-by-prettify">=3D</span><span style=
=3D"color:#000" class=3D"m_6940945667384060895styled-by-prettify"> </span><=
span style=3D"color:#660" class=3D"m_6940945667384060895styled-by-prettify"=
>&amp;</span><span style=3D"color:#000" class=3D"m_6940945667384060895style=
d-by-prettify">Y</span><span style=3D"color:#660" class=3D"m_69409456673840=
60895styled-by-prettify">::</span><span style=3D"color:#000" class=3D"m_694=
0945667384060895styled-by-prettify">w</span><span style=3D"color:#660" clas=
s=3D"m_6940945667384060895styled-by-prettify">.</span><span style=3D"color:=
#000" class=3D"m_6940945667384060895styled-by-prettify">x</span><span style=
=3D"color:#660" class=3D"m_6940945667384060895styled-by-prettify">[</span><=
span style=3D"color:#066" class=3D"m_6940945667384060895styled-by-prettify"=
>5</span><span style=3D"color:#660" class=3D"m_6940945667384060895styled-by=
-prettify">];</span><span style=3D"color:#000" class=3D"m_69409456673840608=
95styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660" c=
lass=3D"m_6940945667384060895styled-by-prettify">*</span><span style=3D"col=
or:#000" class=3D"m_6940945667384060895styled-by-prettify">p </span><span s=
tyle=3D"color:#660" class=3D"m_6940945667384060895styled-by-prettify">=3D</=
span><span style=3D"color:#000" class=3D"m_6940945667384060895styled-by-pre=
ttify"> </span><span style=3D"color:#066" class=3D"m_6940945667384060895sty=
led-by-prettify">4</span><span style=3D"color:#660" class=3D"m_694094566738=
4060895styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_69=
40945667384060895styled-by-prettify"><br></span><span style=3D"color:#660" =
class=3D"m_6940945667384060895styled-by-prettify">}</span></div></code></di=
v><br></div></div></blockquote><div><br>I swear, C++ drives me more crazy e=
very time I look at it.=C2=A0 Notice the obvious corollary to your code:<br=
><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 void Z::f()</font><b=
r><font face=3D"monospace, monospace">=C2=A0 =C2=A0 {</font><br><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int *p =3D &amp;(Y</f=
ont><span style=3D"font-family:monospace,monospace;color:rgb(34,34,34);font=
-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-ca=
ps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px;background-co=
lor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:in=
itial;float:none;display:inline">::w.x[5]);=C2=A0 // OK

<br style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-size:=
small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:nor=
mal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;background-color:rg=
b(255,255,255);text-decoration-style:initial;text-decoration-color:initial"=
><span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-si=
ze:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:=
normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px;background-color=
:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initi=
al;float:none;display:inline">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int *q =3D &amp; =
Y::w.x[5] ;=C2=A0 // OK</span></span><br><font face=3D"monospace, monospace=
">=C2=A0 =C2=A0 =C2=A0 =C2=A0 W=C2=A0 =C2=A0*r =3D &amp;(Y::w)=C2=A0 =C2=A0=
 =C2=A0;=C2=A0 // OK</font><br><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 W=C2=A0 =C2=A0*s =3D &amp; Y::w=C2=A0 =C2=A0 =C2=A0 ;=
=C2=A0 // Error</font><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0=
 }</font><br><br><font face=3D"arial, helvetica, sans-serif">C++ syntax is =
a horrible hodgepodge mess caused by too much &quot;it would be nice if <i>=
this</i> meant <i>that</i>&quot;<br>without any consideration of making eve=
rything globally consistent.</font></div></div></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/CAHSYqda43Vo0%2BvhY3i39JT1%2BcBaumAwy=
nsJ%3D-NjGu7Nm3Yd9-A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda43V=
o0%2BvhY3i39JT1%2BcBaumAwynsJ%3D-NjGu7Nm3Yd9-A%40mail.gmail.com</a>.<br />

--001a1143dd1e614aac05678c9348--

.

------=_Part_2390_1155485501.1521230529541
Content-Type: multipart/alternative;
 boundary="----=_Part_2391_1763402201.1521230529542"

------=_Part_2391_1763402201.1521230529542
Content-Type: text/plain; charset="UTF-8"

On Friday, March 16, 2018 at 12:25:51 PM UTC-7, Hyman Rosen wrote:
>
> On Fri, Mar 16, 2018 at 2:56 PM, Myriachan <myri...@gmail.com
> <javascript:>> wrote:
>
>> On Friday, March 16, 2018 at 8:13:44 AM UTC-7, Hyman Rosen wrote:
>>>
>>>
>>>     struct A { int x[10]; };
>>>     struct B { A a; };
>>>     int B::*number_5 = &B::a.x[5];
>>>
>>
>> Careful here: this is a breaking change.  Consider this currently-legal
>> code:
>>
>> struct W { int x[10]; };
>> struct X { W w; };
>> struct Y { W w; };
>> struct Z : X, Y
>> {
>>     void f();
>> };
>>
>> void Z::f()
>> {
>>     int *p = &Y::w.x[5];
>>     *p = 4;
>> }
>>
>>
> I swear, C++ drives me more crazy every time I look at it.  Notice the
> obvious corollary to your code:
>
>     void Z::f()
>     {
>         int *p = &(Y::w.x[5]);  // OK
>         int *q = & Y::w.x[5] ;  // OK
>         W   *r = &(Y::w)     ;  // OK
>         W   *s = & Y::w      ;  // Error
>     }
>
>
Yes.  It's explicitly stated as such in [expr.unary.op]/4: "A pointer to
member is only formed when an explicit & is used and its operand is a
qualified-id not enclosed in parentheses."


> C++ syntax is a horrible hodgepodge mess caused by too much "it would be
> nice if *this* meant *that*"
> without any consideration of making everything globally consistent.
>

Regarding the grammar of member pointers, I agree >.<

--
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/c0141b25-70e4-4b89-b03f-6c102d8ee35a%40isocpp.org.

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

<div dir=3D"ltr">On Friday, March 16, 2018 at 12:25:51 PM UTC-7, Hyman Rose=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote">On Fri, Mar 16, 2018 at 2:56 PM, Myriachan <span=
 dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"a4wtn77-AgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">myri...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><span>On Friday, March 16, 2018 at 8:13:44 AM U=
TC-7, Hyman Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><br><div><font face=3D"monospace, mon=
ospace">=C2=A0 =C2=A0 struct A { int x[10]; };<br>=C2=A0 =C2=A0 struct B { =
A a; };<br>=C2=A0 =C2=A0 int B::*number_5 =3D &amp;B::a.x[5];</font></div><=
/div></div></div></blockquote></span><div><br>Careful here: this is a break=
ing change.=C2=A0 Consider this currently-legal code:<br><br><div style=3D"=
background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-styl=
e:solid;border-width:1px"><code><div><span style=3D"color:#008">struct</spa=
n><span style=3D"color:#000"> W </span><span style=3D"color:#660">{</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">int</span><spa=
n style=3D"color:#000"> x</span><span style=3D"color:#660">[</span><span st=
yle=3D"color:#066">10</span><span style=3D"color:#660">];</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">};</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#008">struct</span><span style=
=3D"color:#000"> X </span><span style=3D"color:#660">{</span><span style=3D=
"color:#000"> W w</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">};</span><span style=3D"color=
:#000"><br></span><span style=3D"color:#008">struct</span><span style=3D"co=
lor:#000"> Y </span><span style=3D"color:#660">{</span><span style=3D"color=
:#000"> W w</span><span style=3D"color:#660">;</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">};</span><span style=3D"color:#000"=
><br></span><span style=3D"color:#008">struct</span><span style=3D"color:#0=
00"> Z </span><span style=3D"color:#660">:</span><span style=3D"color:#000"=
> X</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> Y<=
br></span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"=
color:#000"> f</span><span style=3D"color:#660">();</span><span style=3D"co=
lor:#000"><br></span><span style=3D"color:#660">};</span><span style=3D"col=
or:#000"><br><br></span><span style=3D"color:#008">void</span><span style=
=3D"color:#000"> Z</span><span style=3D"color:#660">::</span><span style=3D=
"color:#000">f</span><span style=3D"color:#660">()</span><span style=3D"col=
or:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"color=
:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">int</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">*</span><span style=
=3D"color:#000">p </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">&amp;</span><span style=
=3D"color:#000">Y</span><span style=3D"color:#660">::</span><span style=3D"=
color:#000">w</span><span style=3D"color:#660">.</span><span style=3D"color=
:#000">x</span><span style=3D"color:#660">[</span><span style=3D"color:#066=
">5</span><span style=3D"color:#660">];</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:#660">*</span><span style=3D"co=
lor:#000">p </span><span style=3D"color:#660">=3D</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#066">4</span><span style=3D"color:#66=
0">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>}</span></div></code></div><br></div></div></blockquote><div><br>I swear, =
C++ drives me more crazy every time I look at it.=C2=A0 Notice the obvious =
corollary to your code:<br><br><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 void Z::f()</font><br><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 {</font><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 int *p =3D &amp;(Y</font><span style=3D"font-family:monospace,monosp=
ace;color:rgb(34,34,34);font-size:small;font-style:normal;font-weight:400;l=
etter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;w=
hite-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:=
none;display:inline">::w.x[5]);=C2=A0 // OK

<br style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-size:=
small;font-style:normal;font-weight:400;letter-spacing:normal;text-align:st=
art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px=
;background-color:rgb(255,255,255)"><span style=3D"color:rgb(34,34,34);font=
-family:monospace,monospace;font-size:small;font-style:normal;font-weight:4=
00;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:no=
ne;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);fl=
oat:none;display:inline">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int *q =3D &amp; Y::w.=
x[5] ;=C2=A0 // OK</span></span><br><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 W=C2=A0 =C2=A0*r =3D &amp;(Y::w)=C2=A0 =C2=A0 =C2=
=A0;=C2=A0 // OK</font><br><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 W=C2=A0 =C2=A0*s =3D &amp; Y::w=C2=A0 =C2=A0 =C2=A0 ;=C2=
=A0 // Error</font><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 }<=
/font><br><br></div></div></div></div></blockquote><div><br>Yes.=C2=A0 It&#=
39;s explicitly stated as such in [expr.unary.op]/4: &quot;A pointer to mem=
ber is only formed when an explicit &amp; is used and its operand is a qual=
ified-id not enclosed in parentheses.&quot;<br>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div><font face=3D"arial, helvetica, sans-serif">C++ syntax is a horribl=
e hodgepodge mess caused by too much &quot;it would be nice if <i>this</i> =
meant <i>that</i>&quot;<br>without any consideration of making everything g=
lobally consistent.</font></div></div></div></div></blockquote><div><br>Reg=
arding the grammar of member pointers, I agree &gt;.&lt; <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/c0141b25-70e4-4b89-b03f-6c102d8ee35a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c0141b25-70e4-4b89-b03f-6c102d8ee35a=
%40isocpp.org</a>.<br />

------=_Part_2391_1763402201.1521230529542--

------=_Part_2390_1155485501.1521230529541--

.

On Friday, 16 March 2018 11:56:29 PDT Myriachan wrote:
> I really like Thiago's proposal regarding data member pointers, but it has
> a major problem: it's an ABI break.  Some proposed constructions would
> allow data member pointers with a negative offset (pointing to the
> containing class's members), and both the Microsoft and Itanium ABIs encode
> null member pointers as -1.

Not really. Negative offsets are already possible in some pathological
pointer-to-members (don't ask me which ones). The ABI has to have a way to
represent them in a way that is different from a null pointer.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/1576846.pGoWqklWjJ%40tjmaciei-mobl1.

.

------=_Part_2696_401175840.1521237736111
Content-Type: multipart/alternative;
 boundary="----=_Part_2697_1190768618.1521237736112"

------=_Part_2697_1190768618.1521237736112
Content-Type: text/plain; charset="UTF-8"



On Friday, March 16, 2018 at 6:23:12 PM UTC+1, Nicol Bolas wrote:
>
> On Friday, March 16, 2018 at 11:34:02 AM UTC-4, Hyman Rosen wrote:
>>
>> On Fri, Mar 16, 2018 at 11:16 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>> You just need to simultaneously modify C++ so that there is a built-in
>>>> equivalent
>>>> to offsetof, and make offsetof a pre-defined macro that expands to that.
>>>>
>>>
>>> And if modules can't export macros, how will `import std.cstddef` give
>>> me access to that module?
>>>
>>
>> What module?  I don't understand.
>>
>> Let me try again:
>>
>>    - Change C++ so that there is a built-in version of offsetof under a
>>    different name, say __offsetof.
>>    - __offsetof is available for use in all C++ code without any header
>>    or module needed, just as sizeof is.
>>    - Also change C++ so that offsetof is a pre-defined macro that
>>    expands to __offsetof.
>>
>>
> Oh, when you said "built-in" you meant like "supplied by the compiler".
>
> So... what happens with people's code that *don't* include <cstddef> or
> <stddef> that happens to use the `offsetof` identifier? Admittedly this is
> a minor issue, as I rather doubt someone's going to make a class or
> function that conflicts with a fairly widely known C macro that gets
> included by quite a few things (even if only because of other useful
> things).
>

People who use  `<cstddef>` will still use `<cstddef>` we don not change
antything (this why I suggest leaving it alone).
We add new keyword `real_super_offsetof` that will be available everywhere.
Only problem would be migration of heder to modules usage but because
offsetof is macro we can safely use text replace to change it to new
keyword.

--
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/d9e85fb4-6296-44ee-81f8-7b8fdbc8822e%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, March 16, 2018 at 6:23:12 PM UTC+1, Nic=
ol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Friday, March 16, 2018 at 11:34:02 AM UTC-4, Hyman Rosen wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote">On Fri, Mar 16, 2018 at 11:16 AM, Nicol Bolas <span dir=3D"ltr">&lt;=
<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>You just need to s=
imultaneously modify C++ so that there is a built-in equivalent<br>to offse=
tof, and make offsetof a pre-defined macro that expands to that.</div></div=
></div></div></blockquote></span><div><br>And if modules can&#39;t export m=
acros, how will `import std.cstddef` give me access to that module?</div></=
div></blockquote><div><br>What module?=C2=A0 I don&#39;t understand.<br><br=
></div></div></div></div></blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Let me try again:<=
br><ul><li>Change C++ so that there is a built-in version of <font face=3D"=
monospace, monospace">offsetof</font> under a different name, say <font fac=
e=3D"monospace, monospace">__offsetof</font>.</li><li><font face=3D"monospa=
ce, monospace">

<span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-siz=
e:small;font-style:normal;font-weight:400;letter-spacing:normal;text-align:=
left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x;background-color:rgb(255,255,255);float:none;display:inline">__offsetof</=
span>=C2=A0</font>is available for use in all C++ code without any header o=
r module needed, just as <font face=3D"monospace, monospace">sizeof</font> =
is.</li><li>Also change C++ so that <font face=3D"monospace, monospace">off=
setof</font>=C2=A0is a pre-defined macro that expands to <font face=3D"mono=
space, monospace">

<span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-siz=
e:small;font-style:normal;font-weight:400;letter-spacing:normal;text-align:=
left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x;background-color:rgb(255,255,255);float:none;display:inline">__offsetof</=
span></font>.</li></ul></div></div></div></div></blockquote><div><br>Oh, wh=
en you said &quot;built-in&quot; you meant like &quot;supplied by the compi=
ler&quot;.<br><br>So... what happens with people&#39;s code that <i>don&#39=
;t</i> include &lt;cstddef&gt; or &lt;stddef&gt; that happens to use the `o=
ffsetof` identifier? Admittedly this is a minor issue, as I rather doubt so=
meone&#39;s going to make a class or function that conflicts with a fairly =
widely known C macro that gets included by quite a few things (even if only=
 because of other useful things).<br></div></div></blockquote><div><br>Peop=
le who use=C2=A0 `&lt;cstddef&gt;` will still use `&lt;cstddef&gt;` we don =
not change antything (this why I suggest leaving it alone).<br>We add new k=
eyword `real_super_offsetof` that will be available everywhere.<br>Only pro=
blem would be migration of heder to modules usage but because offsetof is m=
acro we can safely use text replace to change it to new keyword.<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/d9e85fb4-6296-44ee-81f8-7b8fdbc8822e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d9e85fb4-6296-44ee-81f8-7b8fdbc8822e=
%40isocpp.org</a>.<br />

------=_Part_2697_1190768618.1521237736112--

------=_Part_2696_401175840.1521237736111--

.

------=_Part_2699_671267481.1521238344610
Content-Type: multipart/alternative;
 boundary="----=_Part_2700_1124475017.1521238344610"

------=_Part_2700_1124475017.1521238344610
Content-Type: text/plain; charset="UTF-8"

On Friday, March 16, 2018 at 6:02:16 PM UTC-4, Marcin Jaczewski wrote:
>
>
>
> On Friday, March 16, 2018 at 6:23:12 PM UTC+1, Nicol Bolas wrote:
>>
>> On Friday, March 16, 2018 at 11:34:02 AM UTC-4, Hyman Rosen wrote:
>>>
>>> On Fri, Mar 16, 2018 at 11:16 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>>
>>>> You just need to simultaneously modify C++ so that there is a built-in
>>>>> equivalent
>>>>> to offsetof, and make offsetof a pre-defined macro that expands to
>>>>> that.
>>>>>
>>>>
>>>> And if modules can't export macros, how will `import std.cstddef` give
>>>> me access to that module?
>>>>
>>>
>>> What module?  I don't understand.
>>>
>>> Let me try again:
>>>
>>>    - Change C++ so that there is a built-in version of offsetof under a
>>>    different name, say __offsetof.
>>>    - __offsetof is available for use in all C++ code without any header
>>>    or module needed, just as sizeof is.
>>>    - Also change C++ so that offsetof is a pre-defined macro that
>>>    expands to __offsetof.
>>>
>>>
>> Oh, when you said "built-in" you meant like "supplied by the compiler".
>>
>> So... what happens with people's code that *don't* include <cstddef> or
>> <stddef> that happens to use the `offsetof` identifier? Admittedly this is
>> a minor issue, as I rather doubt someone's going to make a class or
>> function that conflicts with a fairly widely known C macro that gets
>> included by quite a few things (even if only because of other useful
>> things).
>>
>
> People who use  `<cstddef>` will still use `<cstddef>` we don not change
> antything (this why I suggest leaving it alone).
> We add new keyword `real_super_offsetof` that will be available everywhere.
> Only problem would be migration of heder to modules usage but because
> offsetof is macro we can safely use text replace to change it to new
> keyword.
>

If it's going to be a direct, drop-in replacement, such that code which
uses `offsetof` can be changed to use `new_offsetof` with no other
changes... why make it a new identifier at all? Just have `offsetof` become
a C++ keyword, and have the C++ versions of `<cstddef>` and `stddef.h`
simply not define them.

I thought the whole point of using a new keyword was to give them a
(presumably) better interface.

--
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/6725bbc8-a8db-40e1-a3f4-98ac05e23862%40isocpp.org.

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

<div dir=3D"ltr">On Friday, March 16, 2018 at 6:02:16 PM UTC-4, Marcin Jacz=
ewski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br><br>On Friday, March 16, 2018 at 6:23:12 PM UTC+1, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, March 16, =
2018 at 11:34:02 AM UTC-4, Hyman Rosen wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Mar 16, =
2018 at 11:16 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmc=
k...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote"><div>You just need to simultaneously modify C+=
+ so that there is a built-in equivalent<br>to offsetof, and make offsetof =
a pre-defined macro that expands to that.</div></div></div></div></blockquo=
te></span><div><br>And if modules can&#39;t export macros, how will `import=
 std.cstddef` give me access to that module?</div></div></blockquote><div><=
br>What module?=C2=A0 I don&#39;t understand.<br><br></div></div></div></di=
v></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote"><div>Let me try again:<br><ul><li>Change C++ s=
o that there is a built-in version of <font face=3D"monospace, monospace">o=
ffsetof</font> under a different name, say <font face=3D"monospace, monospa=
ce">__offsetof</font>.</li><li><font face=3D"monospace, monospace">

<span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-siz=
e:small;font-style:normal;font-weight:400;letter-spacing:normal;text-align:=
left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x;background-color:rgb(255,255,255);float:none;display:inline">__offsetof</=
span>=C2=A0</font>is available for use in all C++ code without any header o=
r module needed, just as <font face=3D"monospace, monospace">sizeof</font> =
is.</li><li>Also change C++ so that <font face=3D"monospace, monospace">off=
setof</font>=C2=A0is a pre-defined macro that expands to <font face=3D"mono=
space, monospace">

<span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-siz=
e:small;font-style:normal;font-weight:400;letter-spacing:normal;text-align:=
left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x;background-color:rgb(255,255,255);float:none;display:inline">__offsetof</=
span></font>.</li></ul></div></div></div></div></blockquote><div><br>Oh, wh=
en you said &quot;built-in&quot; you meant like &quot;supplied by the compi=
ler&quot;.<br><br>So... what happens with people&#39;s code that <i>don&#39=
;t</i> include &lt;cstddef&gt; or &lt;stddef&gt; that happens to use the `o=
ffsetof` identifier? Admittedly this is a minor issue, as I rather doubt so=
meone&#39;s going to make a class or function that conflicts with a fairly =
widely known C macro that gets included by quite a few things (even if only=
 because of other useful things).<br></div></div></blockquote><div><br>Peop=
le who use=C2=A0 `&lt;cstddef&gt;` will still use `&lt;cstddef&gt;` we don =
not change antything (this why I suggest leaving it alone).<br>We add new k=
eyword `real_super_offsetof` that will be available everywhere.<br>Only pro=
blem would be migration of heder to modules usage but because offsetof is m=
acro we can safely use text replace to change it to new keyword.<br></div><=
/div></blockquote><div><br>If it&#39;s going to be a direct, drop-in replac=
ement, such that code which uses `offsetof` can be changed to use `new_offs=
etof` with no other changes... why make it a new identifier at all? Just ha=
ve `offsetof` become a C++ keyword, and have the C++ versions of `&lt;cstdd=
ef&gt;` and `stddef.h` simply not define them.<br><br>I thought the whole p=
oint of using a new keyword was to give them a (presumably) better interfac=
e.<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/6725bbc8-a8db-40e1-a3f4-98ac05e23862%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6725bbc8-a8db-40e1-a3f4-98ac05e23862=
%40isocpp.org</a>.<br />

------=_Part_2700_1124475017.1521238344610--

------=_Part_2699_671267481.1521238344610--

.

On Friday, 16 March 2018 15:12:24 PDT Nicol Bolas wrote:
> If it's going to be a direct, drop-in replacement, such that code which
> uses `offsetof` can be changed to use `new_offsetof` with no other
> changes... why make it a new identifier at all? Just have `offsetof` become
> a C++ keyword, and have the C++ versions of `<cstddef>` and `stddef.h`
> simply not define them.
>
> I thought the whole point of using a new keyword was to give them a
> (presumably) better interface.

Agreed, if we're going to go to the trouble of creating a new keyword, then we
ought to make sure it is better than offsetof. You know I dislike the type-
unsafe aspect of that. Another is the fact that its use could be UB, as it
adds pointers that shouldn't really be added.

The first step would be to make a (quick) survey of C++ uses of offsetof --
that is, things that aren't just regular C code in C++ mode (think of Linux
kernel's struct list[1]).

[1] https://code.woboq.org/linux/linux/tools/firewire/list.h.html

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/3998341.rfsqbO5A2U%40tjmaciei-mobl1.

.

------=_Part_4263_1238526659.1521281471848
Content-Type: multipart/alternative;
 boundary="----=_Part_4264_1670575124.1521281471848"

------=_Part_4264_1670575124.1521281471848
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Am Samstag, 17. M=C3=A4rz 2018 05:32:36 UTC+1 schrieb Thiago Macieira:
>
> The first step would be to make a (quick) survey of C++ uses of offsetof=
=20
> --=20
> that is, things that aren't just regular C code in C++ mode (think of=20
> Linux=20
> kernel's struct list[1]).=20
>

Hi Thiago,

as a first contribution to this survey :-), I recently used it to=20
determine, whether two attributes (used in two different memory layout=20
modes of a class) shaddow each other.
Here is the link to the spot (Line 667):
https://github.com/DuffsDevice/tinyutf8/blob/master/include/tinyutf8.h

I found this macro very useful in this spot and I'd be fine to have it=20
replaced by a built-in feature.

Hope this helps,
Jakob

--=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/8fdfc016-2eb8-4888-9531-66310c80b457%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>Am Samstag, 17. M=C3=A4rz 2018 05:32:36 UTC+1 schr=
ieb Thiago Macieira:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The first =
step would be to make a (quick) survey of C++ uses of offsetof --=20
<br>that is, things that aren&#39;t just regular C code in C++ mode (think =
of Linux=20
<br>kernel&#39;s struct list[1]).
<br></blockquote><div><br></div><div>Hi Thiago,</div><div><br></div><div>as=
 a first contribution to this survey :-), I recently used it to determine, =
whether two attributes (used in two different memory layout modes of a clas=
s) shaddow each other.</div><div>Here is the link to the spot (Line 667):</=
div><div><a href=3D"https://github.com/DuffsDevice/tinyutf8/blob/master/inc=
lude/tinyutf8.h">https://github.com/DuffsDevice/tinyutf8/blob/master/includ=
e/tinyutf8.h</a></div><div><br></div><div>I found this macro very useful in=
 this spot and I&#39;d be fine to have it replaced by a built-in feature.</=
div><div><br></div><div>Hope this helps,</div><div>Jakob</div><div><br></di=
v></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/8fdfc016-2eb8-4888-9531-66310c80b457%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8fdfc016-2eb8-4888-9531-66310c80b457=
%40isocpp.org</a>.<br />

------=_Part_4264_1670575124.1521281471848--

------=_Part_4263_1238526659.1521281471848--

.

On Saturday, 17 March 2018 03:11:11 PDT Jakob Riedle wrote:
> as a first contribution to this survey :-), I recently used it to
> determine, whether two attributes (used in two different memory layout
> modes of a class) shaddow each other.
> Here is the link to the spot (Line 667):
> https://github.com/DuffsDevice/tinyutf8/blob/master/include/tinyutf8.h

I think I understand what your optimisation is trying to do here: support the
case where struct NON_SSO has tail padding, in which case the last byte in
struct SSO aliases no members in NON_SSO. Is that it?

If so, the code is dead in all modern platforms, since sizeof(size_t) ==
sizeof(void *) and ditto for alignof. So NON_SSO will never have tail padding
and it will be very hard for you to test this anywhere. Is this an
optimisation you really want to keep in your code?

Though I don't see any other way to test for padding at a specific position
aside from offsetof. That seems to be a legitimate use, though fragile and
dangerous.

I also think that your code in that condition is UB. You can't use t_sso and
t_non_sso at the same time -- only one member of a union can be active at a
time. Since this function is supposed to disable SSO, you must leave the
t_non_sso member of the union active at the end of your function, but the last
one it would have used is t_sso.

Your last_byte<T> type may be suffering from the same problem.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/3371255.CqAHtthudB%40tjmaciei-mobl1.

.

--0000000000004e89700567b14fd7
Content-Type: text/plain; charset="UTF-8"

Looks like people in this thread have discussed pointers-to-members, but I
didn't see anyone bring up what I think is the best option to replace
offsetof (apologies if I missed it): a stdlib function that converts a
pointer-to-data-member into an offset.

(We'd need two other things for this to work well: the pointer-to-member
composition syntax and/or Hyman's generalized memptr formation syntax, plus
fixing the bug that &B::x can be of type "pointer to A member" where A is a
base class of B. But both of those seem good in their own right.)

On 15 Mar 2018 12:12, "Nicol Bolas" <jmckesson@gmail.com> wrote:

The C standard library defines a large number of things that are macros. In
the vast majority of cases, these are constants or functions, which can in
C++ code be converted into `constexpr` variables or actual functions. For
all intents and purposes, such constructs can be drop-in replacements for
the C macros, which allows us to still work with them in a modular standard
library that doesn't allow macros.

`offsetof` is a special case because it's not a function. Or at least, it's
not a function that C++ at present allows you to write. Without reflection,
there is no way to pass a typename or member variable as a function
parameter. And while there are ways we can work around it, none of those
ways would be drop-in replacements for `offsetof`; the user would have to
change their code.

And even ignoring the non-drop-in part, there is currently no C++
replacement for `offsetof`. As modules moves forward, are there plans to
resolve this issue and similar ones (beside the "let's get modules to
export macros" plan)?

--
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/c5f5ccc4-3267-442d-
8cb2-de1ae103a38e%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%40isocpp.org?utm_medium=email&utm_source=footer>
..

--
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/CAOfiQqm5MZA%2BZtpOvzAewVF%2BwrYLg219JuQgbpbePOmrZkmWuA%40mail.gmail.com.

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

<div dir=3D"auto">Looks like people in this thread have discussed pointers-=
to-members, but I didn&#39;t see anyone bring up what I think is the best o=
ption to replace offsetof (apologies if I missed it): a stdlib function tha=
t converts a pointer-to-data-member into an offset.<div dir=3D"auto"><br></=
div><div dir=3D"auto">(We&#39;d need two other things for this to work well=
: the pointer-to-member composition syntax and/or Hyman&#39;s generalized m=
emptr formation syntax, plus fixing the bug that &amp;B::x can be of type &=
quot;pointer to A member&quot; where A is a base class of B. But both of th=
ose seem good in their own right.)</div><div class=3D"gmail_extra" dir=3D"a=
uto"><br><div class=3D"gmail_quote">On 15 Mar 2018 12:12, &quot;Nicol Bolas=
&quot; &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>The C standard library defines a large number of things that are macros. I=
n the vast majority of cases, these are constants or functions, which can i=
n C++ code be converted into `constexpr` variables or actual functions. For=
 all intents and purposes, such constructs can be drop-in replacements for =
the C macros, which allows us to still work with them in a modular standard=
 library that doesn&#39;t allow macros.<br><br>`offsetof` is a special case=
 because it&#39;s not a function. Or at least, it&#39;s not a function that=
 C++ at present allows you to write. Without reflection, there is no way to=
 pass a typename or member variable as a function parameter. And while ther=
e are ways we can work around it, none of those ways would be drop-in repla=
cements for `offsetof`; the user would have to change their code.<br><br>An=
d even ignoring the non-drop-in part, there is currently no C++ replacement=
 for `offsetof`. As modules moves forward, are there plans to resolve this =
issue and similar ones (beside the &quot;let&#39;s get modules to export ma=
cros&quot; plan)?<font color=3D"#888888"><br></font></div><font color=3D"#8=
88888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/c5f5ccc4-3267-442d-8cb2-de1ae103a38e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c5f5=
ccc4-3267-442d-<wbr>8cb2-de1ae103a38e%40isocpp.org</a><wbr>.<br>
</font></blockquote></div><br><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/CAOfiQqm5MZA%2BZtpOvzAewVF%2BwrYLg219=
JuQgbpbePOmrZkmWuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm5MZA%=
2BZtpOvzAewVF%2BwrYLg219JuQgbpbePOmrZkmWuA%40mail.gmail.com</a>.<br />

--0000000000004e89700567b14fd7--

.

On Sunday, 18 March 2018 08:15:20 PDT Richard Smith wrote:
> Looks like people in this thread have discussed pointers-to-members, but I
> didn't see anyone bring up what I think is the best option to replace
> offsetof (apologies if I missed it): a stdlib function that converts a
> pointer-to-data-member into an offset.

That's a good idea, but it would lead to no better code than what we have
right now.

I'd still like to see more use-cases supported by the pointer to members,
composing them, inverting them (pointer to container), etc., so that we retain
type safety.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/304283527.crm4FIpuuk%40tjmaciei-mobl1.

.

On Thu, Mar 15, 2018 at 5:12 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> `offsetof` is a special case because it's not a function. Or at least, it's
> not a function that C++ at present allows you to write. Without reflection,

container_of() would be very nice to get as well.

Cheers,
Miguel

--
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/CANiq72kGF_F%2BJ-yNuEZt%3DgtJoQ7OfyRpDN0VONb-C7orfNtapA%40mail.gmail.com.

.

--000000000000671a5b0567b9e79a
Content-Type: text/plain; charset="UTF-8"

On 18 Mar 2018 09:19, "Thiago Macieira" <thiago@macieira.org> wrote:

On Sunday, 18 March 2018 08:15:20 PDT Richard Smith wrote:
> Looks like people in this thread have discussed pointers-to-members, but I
> didn't see anyone bring up what I think is the best option to replace
> offsetof (apologies if I missed it): a stdlib function that converts a
> pointer-to-data-member into an offset.

That's a good idea, but it would lead to no better code than what we have
right now.

I'd still like to see more use-cases supported by the pointer to members,
composing them, inverting them (pointer to container), etc., so that we
retain
type safety.


I agree, and I think that's a better place to focus our efforts. But if we
need it, I think we do have good solutions for offsetof without macros.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/304283527.crm4FIpuuk%40tjmaciei-mobl1.

--
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/CAOfiQq%3DF11f_adnre7BLQ7kCG7dqj2y_uOr%3Dua8uuZwekHS%3DCQ%40mail.gmail.com.

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

<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 18 Mar 2018 09:19, &quot;Thiago Macieira&quot; &lt;<a href=3D"mailto:t=
hiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br type=3D"attributi=
on"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div class=3D"quoted-text">On Sunday, 18 March=
 2018 08:15:20 PDT Richard Smith wrote:<br>
&gt; Looks like people in this thread have discussed pointers-to-members, b=
ut I<br>
&gt; didn&#39;t see anyone bring up what I think is the best option to repl=
ace<br>
&gt; offsetof (apologies if I missed it): a stdlib function that converts a=
<br>
&gt; pointer-to-data-member into an offset.<br>
<br>
</div>That&#39;s a good idea, but it would lead to no better code than what=
 we have<br>
right now.<br>
<br>
I&#39;d still like to see more use-cases supported by the pointer to member=
s,<br>
composing them, inverting them (pointer to container), etc., so that we ret=
ain<br>
type safety.</blockquote></div></div></div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">I agree, and I think that&#39;s a better place to focus our e=
fforts. But if we need it, I think we do have good solutions for offsetof w=
ithout macros.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
class=3D"quoted-text">
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
</div><div class=3D"quoted-text">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/304283527.crm4FIpuuk%40tjmaciei=
-mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<w=
br>isocpp.org/d/msgid/std-<wbr>proposals/304283527.<wbr>crm4FIpuuk%40tjmaci=
ei-mobl1</a>.<br>
</blockquote></div><br></div></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/CAOfiQq%3DF11f_adnre7BLQ7kCG7dqj2y_uO=
r%3Dua8uuZwekHS%3DCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DF=
11f_adnre7BLQ7kCG7dqj2y_uOr%3Dua8uuZwekHS%3DCQ%40mail.gmail.com</a>.<br />

--000000000000671a5b0567b9e79a--

.

------=_Part_13446_1514121501.1521497470641
Content-Type: multipart/alternative;
 boundary="----=_Part_13447_567332988.1521497470641"

------=_Part_13447_567332988.1521497470641
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Thiago,

Am Samstag, 17. M=C3=A4rz 2018 18:34:07 UTC+1 schrieb Thiago Macieira:
>
> I think I understand what your optimisation is trying to do here: support=
=20
> the=20
> case where struct NON_SSO has tail padding, in which case the last byte i=
n=20
> struct SSO aliases no members in NON_SSO. Is that it?=20
>
Yes, exactly.
=20

> If so, the code is dead in all modern platforms, since sizeof(size_t) =3D=
=3D=20
> sizeof(void *) and ditto for alignof. So NON_SSO will never have tail=20
> padding=20
> and it will be very hard for you to test this anywhere. Is this an=20
> optimisation you really want to keep in your code?
>
I haven't thought about it this way. And you're right, that it is in most=
=20
cases dead code.
Concerning testing: I've already tested it by inserting a 'char' field in=
=20
between members.

Though I don't see any other way to test for padding at a specific position=
=20
> aside from offsetof. That seems to be a legitimate use, though fragile an=
d=20
> dangerous.
>
I don't even consider it fragile. It's robust and platform independent. Do=
=20
I misunderstand something?
=20

> I also think that your code in that condition is UB. You can't use t_sso=
=20
> and=20
> t_non_sso at the same time -- only one member of a union can be active at=
=20
> a=20
> time. Since this function is supposed to disable SSO, you must leave the=
=20
> t_non_sso member of the union active at the end of your function, but the=
=20
> last=20
> one it would have used is t_sso.=20
>
You're right. However, my assumption is that accessing t_non_sso and t_sso=
=20
is no different than invoking reinterpret_cast<NON_SSO|SSO*>(this),
which I assume to work on every compiler and every platform, even though it=
=20
is UB as well.
The memory model of C++ is just not (yet) able to *guarantee* this very=20
obvious behaviour.
=20

> Your last_byte<T> type may be suffering from the same problem.
>
Right :)

Cheers,
Jakob
=20

--=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/5e4d466e-27d5-4278-aa6f-95879175f8be%40isocpp.or=
g.

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

<div dir=3D"ltr">Hi Thiago,<div><br></div><div>Am Samstag, 17. M=C3=A4rz 20=
18 18:34:07 UTC+1 schrieb Thiago Macieira:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">I think I understand what your optimisation is trying to do her=
e: support the=20
<br>case where struct NON_SSO has tail padding, in which case the last byte=
 in=20
<br>struct SSO aliases no members in NON_SSO. Is that it?
<br></blockquote><div>Yes, exactly.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">If so, the code is dead in all modern platforms=
, since sizeof(size_t) =3D=3D=20
<br>sizeof(void *) and ditto for alignof. So NON_SSO will never have tail p=
adding=20
<br>and it will be very hard for you to test this anywhere. Is this an=20
<br>optimisation you really want to keep in your code?<br></blockquote><div=
>I haven&#39;t thought about it this way. And you&#39;re right, that it is =
in most cases dead code.</div><div>Concerning testing: I&#39;ve already tes=
ted it by inserting a &#39;char&#39; field in between members.</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Though I don&#39;t see=
 any other way to test for padding at a specific position=20
<br>aside from offsetof. That seems to be a legitimate use, though fragile =
and=20
<br>dangerous.<br></blockquote><div>I don&#39;t even consider it fragile. I=
t&#39;s robust and platform independent. Do I misunderstand something?</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I also think=
 that your code in that condition is UB. You can&#39;t use t_sso and=20
<br>t_non_sso at the same time -- only one member of a union can be active =
at a=20
<br>time. Since this function is supposed to disable SSO, you must leave th=
e=20
<br>t_non_sso member of the union active at the end of your function, but t=
he last=20
<br>one it would have used is t_sso.
<br></blockquote><div>You&#39;re right. However, my assumption is that acce=
ssing t_non_sso and t_sso is no different than invoking reinterpret_cast&lt=
;NON_SSO|SSO*&gt;(this),</div><div>which I assume to work on every compiler=
 and every platform, even though it is UB as well.</div><div>The memory mod=
el of C++ is just not (yet) able to <i>guarantee</i> this very obvious beha=
viour.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Y=
our last_byte&lt;T&gt; type may be suffering from the same problem.<br></bl=
ockquote><div>Right :)</div><div><br></div><div>Cheers,</div><div>Jakob</di=
v><div>=C2=A0</div></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/5e4d466e-27d5-4278-aa6f-95879175f8be%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e4d466e-27d5-4278-aa6f-95879175f8be=
%40isocpp.org</a>.<br />

------=_Part_13447_567332988.1521497470641--

------=_Part_13446_1514121501.1521497470641--

.