An alternative to C offsetof(): conditionally allow static_cast from a pointer to data member

208 views
Skip to first unread message

Ivan G.

unread,
Oct 15, 2016, 6:49:23 AM10/15/16
to ISO C++ Standard - Future Proposals
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?

Thiago Macieira

unread,
Oct 16, 2016, 1:02:58 PM10/16/16
to std-pr...@isocpp.org
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

Ivan G.

unread,
Oct 26, 2016, 1:43:54 PM10/26/16
to ISO C++ Standard - Future Proposals
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.

Thiago Macieira

unread,
Oct 27, 2016, 5:34:21 PM10/27/16
to std-pr...@isocpp.org
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.

T. C.

unread,
Oct 27, 2016, 9:13:24 PM10/27/16
to ISO C++ Standard - Future Proposals


On Thursday, October 27, 2016 at 5:34:21 PM UTC-4, Thiago Macieira wrote:

typedef S:: int *pmd;

int S::*.
Reply all
Reply to author
Forward
0 new messages