How to calculate offset of a class member at compile time?

Question

Given a class definition in C++

class A
{
  public:
    //methods definition
    ....

  private:
    int i;
    char *str;
    ....
}

Is it possible to calculate the offset of a class member at compile time using C++ template meta-programming? The class is not POD, and can have virtual methods, primitive and object data member.

What exactly do you mean by the "offset of a class member"? Do you mean how many bytes you'd have to add to a pointer to an instance of the class (after, say, `reinterpret_cast`'ing it to `char *`) to get to the member? If so, wouldn't simple subtraction tell you? — David Schwartz, Nov 01 '12 at 16:02
You could use `offsetof(A, i)` if that were defined for such types. Check your compiler documentation to see if it is. — Robᵩ, Nov 01 '12 at 16:05
Here is the [link](http://www.cplusplus.com/reference/clibrary/cstddef/offsetof/) to example code that uses offsetof(). — Hindol, Nov 01 '12 at 16:08
@Robᵩ and Hindol: Because of the extended functionality of structs in C++, in this language, the use of offsetof is restricted to "POD types", which for classes, more or less corresponds to the C concept of struct (although non-derived classes with only public non-virtual member functions and with no constructor and/or destructor would also qualify as POD). — Murilo Vasconcelos, Nov 01 '12 at 16:11
@MuriloVasconcelos - Agreed, thus the [subjunctive mood](http://en.wikipedia.org/wiki/English_subjunctive) in my sentence, "if that **were** defined." — Robᵩ, Nov 01 '12 at 16:34
I remember that the offsetof is not part of the standard, but still that's what you seem to look for. — Dean Seo, Jun 18 '15 at 04:12

Glen Low · Answer 1 · 2015-06-18T04:08:19.153

18

Based on Matthieu M.'s answer but shorter and with no macros:

template<typename T, typename U> constexpr size_t offsetOf(U T::*member)
{
    return (char*)&((T*)nullptr->*member) - (char*)nullptr;
}

And it's called like this:

struct X { int a, b, c, d; }

std::cout << "offset of c in X == " << offsetOf(&X::c);

Edit:

Jason Rice is correct. This will not produce an actual constant expression in C++11. It doesn't look possible given the restrictions in http://en.cppreference.com/w/cpp/language/constant_expression -- in particular no pointer difference and reinterpret_castcan be in a constant expression.

edited Jun 18 '15 at 04:08

answered Nov 22 '13 at 09:20

Glen Low

4,379
1
30
36

Just to spell it out, U is the member's type and T is the struct's type. I fudged those the first time. – Jason Rice Jan 10 '15 at 22:37
@Glen Low: Do we really need the `- (char*)nullptr` part? Aren't we just subtracting zero? I guess we can make it shorter :) – nav Feb 09 '15 at 20:14
1

@nav That seems to work on gcc but not llvm: error: cannot initialize return object of type 'size_t' (aka 'unsigned int') with an rvalue of type 'char *' – Jason Rice Feb 26 '15 at 17:26
If fact, if i use the above to initialize a constexpr it does not compile with clang/llvm. – Jason Rice Feb 26 '15 at 17:39
4

This causes undefined behaviour by dereferencing null pointer, and also by subtracting pointers when both pointers do not point to the same object – M.M Mar 22 '16 at 21:40
I don't recommend this solution. On Clang, when used with struct with multiple base classes it will give offset of member with respect to beginning of class where member is declared - this is wrong and unexpected. https://godbolt.org/z/qzExEd I suggest the use of dummy static object if possible – S. Kaczor Mar 10 '21 at 04:54

score 7 · Answer 2 · answered Nov 01 '12 at 17:23

Well... in C++11, you actually can compute such offsets right with regular C++ facilities (ie, without delegating to a particular compiler intrinsic).

In action at liveworkspace:

template <typename T, typename U>
constexpr int func(T const& t, U T::* a) {
     return (char const*)&t - (char const*)&(t.*a);
}

However this relies on t being a reference to a constexpr instance here, which might not be applicable to all classes. It does not forbid T from having a virtual method though, nor even a constructor, as long as it is a constexpr constructor.

Still, this is quite a hindrance. In unevaluated contexts we could actually use std::declval<T>() to simulate having an object; while having none. This poses no specific requirements on the constructor of an object, therefore. On the other hand, the values we can extract from such context are few... and they do pose issues with current compilers, too... Well, let's fake it!

In action at liveworkspace:

template <typename T, typename U>
constexpr size_t offsetof_impl(T const* t, U T::* a) {
    return (char const*)t - (char const*)&(t->*a) >= 0 ?
           (char const*)t - (char const*)&(t->*a)      :
           (char const*)&(t->*a) - (char const*)t;
}

#define offsetof(Type_, Attr_)                          \
    offsetof_impl((Type_ const*)nullptr, &Type_::Attr_)

The only issue I foresee is with virtual inheritance, because of its runtime placement of the base object. I would be glad to be presented with other defects, if there are.

@markd: [Beware](http://en.cppreference.com/w/cpp/types/offsetof) => If type is not a standard layout type or if the member is a static data member or a function member, then the behavior is undefined of using the `offsetof` macro as specified by the C standard is undefined. In other words, the `offsetof` macro of C works only with C-like types. — Matthieu M., Feb 20 '15 at 16:14
Why are you using `T const*` and `char const*` instead of just `T*` and `char*`? — ens, Nov 05 '15 at 21:15
@ens: to make it explicit that the function does not modify its input (it does not through the macro, but it may be used without). — Matthieu M., Nov 06 '15 at 07:16
@MatthieuM. Just bitten by new compiler here :) I guess the intentioin of the standards people is to make the offsets of base classes within a class non-constant but if a field is in a base class, even if that base class in non-virtual it does not work. I can understand why virtual base classes would be all over the place but for simple bases ? I had an old template where you would put in as a base class the "node" for a list ( a intrusive node on the object ) And the generic list code only needed the offset to the node. Alas can't do that :| — peterk, Dec 31 '18 at 21:28

score 3 · Answer 3 · answered Nov 01 '12 at 16:42

No, not in general.

The offsetof macro exists for POD (plain old data) structs, and it may be extended slightly with C++0x to standard layout structs (or other similar slight extensions). So for those restricted cases, you have a solution.

C++ offers a lot of freedom to compiler writers. I don't know of any clause that would prevent some classes from having variable offsets to members of the class -- however, I'm not sure why a compiler would do that either. ;)

Now, one approach to keep your code standards compliant, yet still have offsets, would be to stick your data into a POD (or some C++0x extension) sub-struct, on which offsetof will work, then work on that sub-struct instead of on the entire class. Or you could surrender standards compliance. The offset of your struct within your class wouldn't be known, but the offset of the member within the struct would be.

An important question to ask is "why do I want this, and do I really have a good reason"?

It may not be a really good reason, but some database interactions require compile-time constant offsets into data structures in order to construct indexes. It's possible to hard-code these, but letting the compiler calculate them instead can avoid some errors. — Austin Mullins, Apr 28 '16 at 20:15
@austin That is a case foe plain old data: putting a non-standard layout class into a database that way will be a bad idea. — Yakk - Adam Nevraumont, Apr 28 '16 at 22:43

score 0 · Answer 4 · edited Mar 27 '23 at 22:43

In the 1996 book "Inside the C++ Object Model", written by Stanley B. Lippman, one of the original C++ designer's, makes reference to Pointer-to-Member Functions in Chapter 4.4

the value returned from taking the address of a nonstatic data member is the byte value of the member's position in the class layout (plus 1). One can think of it as an incomplete value. It needs to be bound to the address of a class object before an actual instance of the member can be accessed.

While I vaguely recall that +1 from somewhere in some previous life, I've never seen or made use of this syntax before.

class t
{
public:
    int i;
    int j;
};
int (t::*pmf)() = &t::i;

At least according to the description, this seems to be a cool way to get "almost" the offset.

But it doesn't seem to work anymore, at least in GCC. I get an error:

Cannot initialize a variable of type 'int (t::*) with an rvalue of type "int t:: *'

Does anybody have any history behind what is going on here? Is something like this still possible?

Problem with the web -- obsolete books never die...

How to calculate offset of a class member at compile time?

4 Answers4

Linked