Typecasting from bare data to C++ wrapper

Question

Say I have some data allocated somewhere in my program, like:

some_type a;

and I want to wrap this data in a class for access. Is it valid to say,

class Foo {
private:
    some_type _val;
public:
    inline void doSomething() { c_doSomething(&_val); }
}

Foo *x = reinterpret_cast<Foo *>(&a);
x->double();

The class has no virtual functions, and only includes a single data item of the type I'm trying to wrap. Does the C++ standard specify that this reinterpret_cast is safe and valid? sizeof(Foo) == sizeof(some_type), no address alignment issues, or anything? (In my case, I'd be ensuring that some_type is either a primitive type like int, or a POD structure, but I'm curious what happens if we don't enforce that restriction, too - for example, a derived class of a UIWidget like a UIMenuItem, or something.)

Thanks!

Answer 1

Is it valid to say...

No, this is not valid. There are only a small number of types that a can be treated as; the complete list can be found in an answer I gave to another question.

Does the C++ standard specify that this reinterpret_cast is safe and valid?

The C++ Standards says very little about reinterpret_cast. Its behavior is almost entirely implementation-defined, so use of it is usually non-portable.

The correct way to do this would be to either

• have a Foo constructor that takes a some_type argument and makes a copy of it or stores a reference or pointer to it, or

• implement your "wrapper" interface as a set of non-member functions that take a some_type object by reference as an argument.

Answer 2

14882/1998/9.2.17:

"A pointer to a PODstruct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bitfield, then to the unit in which it resides) and vice versa. [Note: There might therefore be unnamed padding within a PODstruct object, but not at its beginning, as necessary to achieve appropriate alignment. ]"

So, it would be valid if your wrapper was strictly a POD in itself. However, access specifiers mean that it is not a strictly a POD. That said, I would be interested in knowing whether any current implementation changes object layout due to access specifiers. I think that for all practical purposes, you are good to go.

And for the case when the element is not a POD, it follows that the container is not a POD, and hence all bets are off.

Answer 3

Since your Foo object is already only valid as long as the existing a is valid:

struct Foo {
  some_type &base;

  Foo(some_type &base) : base (base) {}

  void doSomething() { c_doSomething(&base); }
}

//...
Foo x = a;
x.doSomething();

Answer 4

You want to look up the rules governing POD (plain old data) types. If the C++ class is a POD type, then yes, you can cast it.

The details of what actually happens and how aliasing is handled are implementation defined, but are usually reasonable and should match what would happen with a similar C type or struct.

I happen to use this a lot in a project of mine that implements B+ trees in shared memory maps. It has worked in GCC across multiple types of Linux and BSDs including Mac OS X. It also works fine in Windows with MSVC.

Answer 5

Yes, this is valid as long as the wrapper type you are creating (Foo in your example) is a POD-type.