CODEWITHSUNDEEP
c++macros
Abdul Rahman
Abdul Rahman

Reputation: 1384

What is this c++ macro doing?

I dont see what the following macro is doing? If anyone can help me see it it would be appreciated. 

#define BASE_OFFSET(ClassName,BaseName)\
(DWORD(static_cast < BaseName* >( reinterpret_cast\
< ClassName* >(Ox10000000)))-Ox10000000)

If anyone is curious to know where it is coming from, it comes out of the 3rd chapter of Don Box Book Essential COM where he is building a QueryInterface function using interface tables and the above macro is somehow used to find the pointer to the interface vtable of the class, where class is the ClassName implementing the BaseName, although I dont know how it is doing that.

Upvotes: 1

Views: 314

Answers (2)

mdllc
mdllc

Reputation: 11

Remark about magic 0x10000000 constant.

If that constant will be 0, GCC will show warning -Winvalid-offset-of (if it is enabled, of course). Maybe other compilers do something like that.

Upvotes: 1

Seva Alekseyev
Seva Alekseyev

Reputation: 61331

It tells to the compiler: "imagine there a ClassName object at 0x10000000. Where would the BaseName data begin in that object, relative to 0x10000000"?

Think of a memory layout of a class object with multiple bases:

class A: B, C{};

In the memory block that constitutes an A object, there's the chunk of data that belong to B, also a chunk of data that belongs to C, and the data that are specific to A. Since the address of at least one base's data cannot be the same as the address of the class instance as a whole, the numeric value of the this pointer that you pass to different methods needs to vary. The macro retrieves the value of the difference.

EDIT: The pointer to the vtable is, by convention, the first data member in any class with virtual functions. So by finding the address of the base data, one finds the address of its vtable pointer.

Now, about the type conversion. Normally, when you typecast pointers, the operation is internally trivial - the numeric value of the address does not depend on what type does it point to; the very notion of datatype only exists on the C level. There's one important exception though - when you cast object pointers with multiple inheritance. As we've just discussed, the this pointer that you need to pass to a base class method might be numerically different from the one of the derived object's.

So the distinction between static_cast and reinterpret_cast captures this difference neatly. When you use reinterpret_cast, you're telling the compiler: "I know better. Take this numeric value and interpret it as a pointer to what I say". This is a deliberate subversion of the type system, dangerous, but occasionally necessary. This kind of cast is by definition trivial - cause you say so.

By "trivial" I mean - the numeric value of the pointer does not change.

The static_cast is a more high level construct. In this particular case, you're casting between an object and its base. That's a reasonable, safe cast under C++ class rules - BUT it might be numerically nontrivial. That's why the macro uses two different typecasts. static_cast does NOT violate the type system.

To recap:

reinterpret_cast<ClassName* >(OxlOOOOOOO)

is an unsafe operation. It returns a bogus pointer to a bogus object, but it's OK because we never dereference it.

static_cast<BaseName*>(...)

is a safe operation (with an unsafe pointer, the irony). It's the part where the nontrivial pointer typecast happens.

(DWORD(...)-OxlOOOOOOO)

is pure arithmetic. That's where the unsafety doubles back on itself: rather than use the pointer as a pointer, we cast it back to an integer and forget that it ever was a pointer.

The last stage could be equivalently rephrased as:

((char*)(...)-(char*)OxlOOOOOOO)

if that makes more sense.

Upvotes: 7

Related Questions