------=_Part_1236_1685990624.1476528562746
Content-Type: multipart/alternative;
 boundary="----=_Part_1237_1050929564.1476528562746"

------=_Part_1237_1050929564.1476528562746
Content-Type: text/plain; charset=UTF-8

From my point of view, this is very simple.
1) For standard layout types, always allow static_cast to size_t type.
2) For other types, make it implementation-defined. In fact, just expose
compiler's data representation internals without any requirements to change
it. If it's appropriately simple, allow conversion. If it's not, it must be
compilation error.

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.

Is there some very specific reason why this is impossible or undesirable?

--
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/3b0a16d3-18d2-40a3-bade-bf9fabcf307a%40isocpp.org.

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

<div dir=3D"ltr"><div>From my point of view, this is very simple.</div><div=
>1) For standard layout types, always allow static_cast to size_t type.</di=
v><div>2) For other types, make it implementation-defined. In fact, just ex=
pose compiler&#39;s data representation internals without any requirements =
to change it. If it&#39;s appropriately simple, allow conversion. If it&#39=
;s not, it must be compilation error.</div><div><br></div><div>One possible=
 use of this is to expose member offsets to embedded JIT compilers. Since o=
ffsetof() allows only POD types and very inconvenient, I&#39;d like to enab=
le it for classes with simple inheritance too. Which may be less portable, =
of course, but still useful.</div><div><br></div><div>Is there some very sp=
ecific reason why this is impossible or undesirable?</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/3b0a16d3-18d2-40a3-bade-bf9fabcf307a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3b0a16d3-18d2-40a3-bade-bf9fabcf307a=
%40isocpp.org</a>.<br />

------=_Part_1237_1050929564.1476528562746--

------=_Part_1236_1685990624.1476528562746--

.