Em s=C3=A1bado, 15 de outubro de 2016, =C3=A0s 03:49:22 PDT, Ivan G. escrev=
eu:
> From my point of view, this is very simple.
> 1) For standard layout types, always allow static_cast to size_t type.

Add a note: for non-null pointers. For null pointers, the result is=20
implementation-defined.

> 2) For other types, make it implementation-defined. In fact, just expose
> compiler's data representation internals without any requirements to chan=
ge
> it. If it's appropriately simple, allow conversion. If it's not, it must =
be
> compilation error.

How is #2 useful, if the internal representation implementation-defined? If=
 one=20
is to know the ABI of the compiler in question, they may already do type-
punning and read from the pointer-to-member directly.

> One possible use of this is to expose member offsets to embedded JIT
> compilers. Since offsetof() allows only POD types and very inconvenient,
> I'd like to enable it for classes with simple inheritance too. Which may =
be
> less portable, of course, but still useful.
>=20
> Is there some very specific reason why this is impossible or undesirable?

I like this idea, but I still think someone should write a paper on pointer=
-
to-member arithmethic, as discussed on this mailing list more than once.

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

--=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/77720404.eO4MklFt8c%40tjmaciei-mobl1.

.

------=_Part_1297_1089925262.1477503833903
Content-Type: multipart/alternative;
 boundary="----=_Part_1298_2084526958.1477503833903"

------=_Part_1298_2084526958.1477503833903
Content-Type: text/plain; charset=UTF-8

What is null pointer to data member?

I did some non-exhaustive examination of pointer to data member internal
representation for x86-64: MSVC uses 32-bit offsets for all types except
ones with virtual inheritance, but Clang seems using 64-bit offsets for all
types. If the static_cast to size_t is allowed, it stops matter whether
they are 32-bit or 64-bit, the compiler will always give the usable offset
just like the offsetof would. And it will theoretically work safely for
many compilers, if not all.

--
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/b2cec4e9-5bf4-476a-92b3-91e3362fbcc4%40isocpp.org.

------=_Part_1298_2084526958.1477503833903
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>What is null pointer to data member?</div><div><br></=
div><div>I did some non-exhaustive examination of pointer to data member in=
ternal representation for x86-64: MSVC uses 32-bit offsets for all types ex=
cept ones with virtual inheritance, but Clang seems using 64-bit offsets fo=
r all types. If the static_cast to size_t is allowed, it stops matter wheth=
er they are 32-bit or 64-bit, the compiler will always give the usable offs=
et just like the offsetof would. And it will theoretically work safely for =
many compilers, if not all.</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/b2cec4e9-5bf4-476a-92b3-91e3362fbcc4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2cec4e9-5bf4-476a-92b3-91e3362fbcc4=
%40isocpp.org</a>.<br />

------=_Part_1298_2084526958.1477503833903--

------=_Part_1297_1089925262.1477503833903--

.

On quarta-feira, 26 de outubro de 2016 10:43:53 PDT Ivan G. wrote:
> What is null pointer to data member?

typedef S:: int *pmd;
pmd x = nullptr;

In the Portable IA-64 C++ ABI, this is represented by a stored value of -1.

That presents an interesting case for when the PMD points to something before
the beginning of the type in question. Yes, those can happen too.

> I did some non-exhaustive examination of pointer to data member internal
> representation for x86-64: MSVC uses 32-bit offsets for all types except
> ones with virtual inheritance, but Clang seems using 64-bit offsets for all
> types. If the static_cast to size_t is allowed, it stops matter whether
> they are 32-bit or 64-bit, the compiler will always give the usable offset
> just like the offsetof would. And it will theoretically work safely for
> many compilers, if not all.

--
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/54733753.30eDXvGn7x%40tjmaciei-mobl1.

.

------=_Part_278_398571926.1477617204390
Content-Type: multipart/alternative;
 boundary="----=_Part_279_1448307996.1477617204391"

------=_Part_279_1448307996.1477617204391
Content-Type: text/plain; charset=UTF-8



On Thursday, October 27, 2016 at 5:34:21 PM UTC-4, Thiago Macieira wrote:
>
>
> typedef S:: int *pmd;
>

int S::*.

--
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/539d3982-4435-4f64-850d-ad9b1a07a882%40isocpp.org.

------=_Part_279_1448307996.1477617204391
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 27, 2016 at 5:34:21 PM UTC-4,=
 Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>typ=
edef S:: int *pmd;
<br></blockquote><div><br></div><div>int S::*.</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/539d3982-4435-4f64-850d-ad9b1a07a882%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/539d3982-4435-4f64-850d-ad9b1a07a882=
%40isocpp.org</a>.<br />

------=_Part_279_1448307996.1477617204391--

------=_Part_278_398571926.1477617204390--

.