ほぼPODデータのためのREINTERPRET_CAST（レイアウト互換性が十分です）

Question

static_castとreinterpret_castについて学びようとしています。

標準（9.2.18）が正しい場合は、PODデータのreinterpret_castが安全であると述べています：

pod-structオブジェクトへのポインタ Aを使用して適切に変換された reinterpret_cast、ITSを指します 初期メンバー（またはそのメンバーがAの場合 ビットフィールド、その後ユニットへ それは存在し、その逆もあります。 [注：それゆえ、したがって任意のものがあるかもしれません 必要に応じて、ポッド構造オブジェクト内でのパディングが開始されるように 適切な整列。 - 終わり 注

私の質問はこれをどのように解釈するべきかです。は、例えばレイアウト互換性が十分ですか？そうでなければ、なぜ？

私にとって、次の例は、厳格な「PODだけが有効である」解釈が間違っているようです。

class complex_base  // a POD-class (I believe)
{
public:  
  double m_data[2];
};

class complex : public complex_base
{  //Not a POD-class (due to constructor and inheritance)
public:
  complex(const double real, const double imag); 
}

double* d = new double[4];
//I believe the following are valid because complex_base is POD
complex_base& cb1 = reinterpret_cast<complex_base&>(d[0]);  
complex_base& cb2 = reinterpret_cast<complex_base&>(d[2]);
//Does the following complete a valid cast to complex even though complex is NOT POD?
complex& c1 = static_cast<complex&>(cb1);
complex& c2 = static_cast<complex&>(cb2);

.

また、complex_base::m_dataが保護されている場合は壊れる可能性があります（complex_baseがPODではないことを意味します）。 [編集：そしてどうやって自分自身を守る/そのような破損を検出する]

レイアウト互換性が十分であるべきだと思われる - しかしこれは標準が言うことではないようです。

編集： 答えをありがとう。彼らはまた私がこれを見つけるのを助けました、 >>> http://www.open-std.org. /jtc1/sc22/wg21/docs/papers/2007/n2342.htm

Answer 1

I believe the following are valid because complex_base is POD

You are wrong. d[0] does not refer to the first member of a complex_base object. Its alignment may therefor not be good enough for a complex_base object, therefor such a cast is not safe (and not allowed by the text you quote).

Does the following complete a valid cast to complex even though complex is NOT POD?

cb1 and cb2 do not point to subobjects of an object of type complex, therefor the static_cast produces undefined behavior. Refer to 5.2.9p5 of C++03

If the lvalue of type "cv1 B" is actually a sub-object of an object of type D, the lvalue refers to the enclosing object of type D. Otherwise, the result of the cast is undefined.

It's not enough if merely the types involved fit together. The text talks about a pointer pointing to a POD-struct object and about an lvalue referring to a certain subobject. oth complex and complex_base are standard-layout objects. The C++0x spec says, instead of the text you quoted:

Is POD-ness requirement too strict?

This is a different question, not regarding your example code. Yes, requiring POD-ness is too strict. In C++0x this was recognized, and a new requirement which is more loose, "standard-layout" is given. I do think that both complex and complex_base are standard-layout classes, by the C++0x definition. The C++0x spec says, instead of the text you quoted:

A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa.

I interpret that as allowing to cast a pointer to a double, which actually points to a complex member (member by inheritance), to be casted to a complex*. A Standard-layout class is one that either has no base classes containing non-static data, or has only one base-class containing non-static data. Thus there is an unique "initial member".

Answer 2

What can break is that non-POD class instances may have vtable pointers, in order to implement virtual dispatch, if they have any virtual functions, including the virtual dtor. The vtbl pointer will typicaly be the first member of the non-POD class.

(Technically, virtual dispatch doesn't have to implemented this way; practically it is. That's why the Standard has to be so strict about what qualifies as a POD type.)

I'm honestly not sure why just having a ctor ("8.5.1(1): "An aggregate is an array or class (clause 9) with no user-declared constructors (12.1)") disqualifies something from being a POD. But, it does.

In the particular case you have here, of course, there's no need for a reinterpret cast. Instead, just add a conversion operator to the base class:

class complex_base  // a POD-class (I believe)
{
public:  
  double m_data[2];
  operator double*() {
    return m_data;
  }
};


complex_base b; // create a complex_base
double* p = b; 

Since a complex_base isn't a double*, the C++ compiler will apply one (and only one) user-defined conversion operator in order to assign b to p. That means that p = b invokes the conversion operator, yielding p = b.operator double*() (and note that that's actually legal syntax -- you can directly call conversion operators, not that you should), which of course does whatever it does, in this case return m_data.

Note that this is questionable, as we now have direct access to b's internals. In practice, we might return a const double*, or a copy, or a smart copy-on-write "pointer" or ....

Of course, in this case, m_data is public anyway, so we're not worse off than if we just wrote:

 double* p = b.m_data;

We are a bit better off, actually, because clients of complex_base don't need to know how to convert it to a double.