Em sábado, 15 de outubro de 2016, às 03:49:22 PDT, Ivan G. escreveu:
> 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
implementation-defined.
> 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.
How is #2 useful, if the internal representation implementation-defined? If one
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.
>
> 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.
--
Thiago Macieira - thiago (AT)
macieira.info - thiago (AT)
kde.org
Software Architect - Intel Open Source Technology Center