blocks|key|2750929|text|派生成员的内存布局没有的保证，强制转换是而不是安全的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2750930|因为你有继承，也可能有填充，这是而不是琐碎。|2750931|§9类|2750932|2750933|+1POD+struct109是既是普通类又是标准布局类联合的类，并且没有非POD结构类型、非POD联合类型(或此类类型的数组)的非静态数据成员。类似地，POD联合是既是普通类又是标准布局类的联合，并且没有非|blockquote|2750934|2750935|2750936|另外，std::is_pod<RGBA>也不是POD|CODE|2750937|std::cout+<<+std::boolalpha;
std::cout+<<+std::is_pod<RGBA>::value+<<+'\n';|code-block|syntax|javascript|2750938|结果为假。请参阅live+demo|2750939|entityMap|0|LINK|mutability|MUTABLE|url|https://ideone.com/PiZpNF^0|B|1|K|3|0|G|3|0|0|3|0|0|0|0|0|3|H|0|0|8|9|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@$9|18|A|19|B|C]|$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1C|8|@$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1F|8|@$9|1G|A|1H|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1I|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|1J|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1L|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1M|8|@$9|1N|A|1O|B|R]]|D|@]|E|$]]|$1|S|3|T|5|U|7|1P|8|@]|D|@]|E|$V|W]]|$1|X|3|Y|5|6|7|1Q|8|@]|D|@$9|1R|A|1S|1|1T]]|E|$]]|$1|Z|3|-4|5|6|7|1U|8|@]|D|@]|E|$]]]|10|$11|$5|12|13|14|E|$15|16]]]]

There is NO guarantees about the memory layout of derived members and the cast is NOT safe.

As you have inheritance, also there could be padding, this is NOT trivial.

§ 9 Classes

<blockquote>
 1 A POD struct109 is a class that is both a trivial class and a standard-layout class, and has no non-static data members of type non-POD struct, non-POD union (or array of such types). Similarly, a POD union is a union that is both a trivial class and a standard layout class, and has no non-
</blockquote>

Also <code>std::is_pod&lt;RGBA&gt;</code> is not a POD

<pre><code>std::cout &lt;&lt; std::boolalpha;
std::cout &lt;&lt; std::is_pod&lt;RGBA&gt;::value &lt;&lt; '\n';
</code></pre>

result is false. see <a href="https://ideone.com/PiZpNF" rel="noreferrer">live demo</a>

blocks|key|2750944|text|很容易检查填充:打印sizeof(RGB)和sizeof(RGBA)。如果它不是3个相应的4，那么结构是填充的，你需要删除它。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2750945|至于成员a是否在b之后，可以使用offsetof检查每个成员的偏移量。如果a的偏移量比b的偏移量大1，那么a紧跟在b之后。|2750946|entityMap|0|LINK|mutability|MUTABLE|url|http://en.cppreference.com/w/cpp/types/offsetof^0|A|B|M|C|0|4|1|8|1|G|8|11|1|17|1|1H|1|1L|1|G|8|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@$9|19|A|1A|1|1B]]|E|$]]|$1|H|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

It's easy to check for padding: Print <code>sizeof(RGB)</code> and <code>sizeof(RGBA)</code>. If it's not 3 respective 4 then the structures are padded, and you need to remove it.

As for if the member <code>a</code> comes after <code>b</code>, you can use <a href="http://en.cppreference.com/w/cpp/types/offsetof" rel="nofollow"><code>offsetof</code></a> to check each members offset. If the offset for <code>a</code> is one larger than the offset of <code>b</code> then <code>a</code> comes directly after <code>b</code>.

blocks|key|159566|text|不，布局不是保证的。唯一的保证是标准布局类；而此类的条件之一是它|type|unstyled|depth|inlineStyleRanges|entityRanges|data|159567|159568|或者在最多的派生类中没有非静态数据成员，并且最多有一个具有非静态数据成员的基类，或者没有具有非静态数据成员的基类|blockquote|159569|159570|159571|换句话说，所有数据成员必须在同一个类中，而不是在多个类中。|159572|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|N|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|K|$]]

No, the layout is not guaranteed. The only guarantees are for standard-layout classes; and one of the conditions of such a class is that it

<blockquote>
 either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base classes with non-static data members
</blockquote>

In other words, all data members must be in the same class, not in more than one.

blocks|key|162014|text|正如前面所有的答案所指出的:它不是标准所保证的。但是，如果您仍然需要这样的POD继承(派生类实际上不再是POD)，您至少可以通过使用static_assert来验证当前编译器的行为是否符合预期。如果您切换到另一个行为不同的编译器，那么您至少应该得到编译器错误。但是，如果您的代码应该易于移植，那么这可能是一种糟糕的做法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|162015|我还推荐使用编译器变量属性__attribute__((packed))来声明POD结构并使用<cstdint>。这是有效的，例如，GCC，但也可能是不同的编译器，你使用的。|offset|length|style|CODE|162016|#include+<cstdint>

struct+__attribute__((packed))+RGB+{
++++uint8_t+r;
++++uint8_t+g;
++++uint8_t+b;
};

struct+__attribute__((packed))+RGBA+:+RGB+{
++++uint8_t+a;
};

static_assert(+sizeof(RGB)+==+3u,+"Unexpected+size"+);
static_assert(+sizeof(RGBA)+==+4u,+"Unexpected+size"+);|code-block|syntax|javascript|162017|entityMap^0|0|D|N|1B|9|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@$D|Q|E|R|F|G]|$D|S|E|T|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|U|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

As all previous answers here already stated: it is not guaranteed by the standard. But if you still require such an inheritance of PODs (the derived class is actually no POD anymore), you can at least validate that the current compiler behaves as desired, by using static_assert. If you switch to another compiler that behaves different, then you should at least get compiler errors. Though, this may be bad practice if your code should be easily portable.
I also recommend to use compiler variable attribute <code>__attribute__((packed))</code> to declare your POD structures and to use <code>&lt;cstdint&gt;</code>. This is valid with e.g. GCC, but might also be different depending on the compiler you use.
<pre><code>#include &lt;cstdint&gt;

struct __attribute__((packed)) RGB {
 uint8_t r;
 uint8_t g;
 uint8_t b;
};

struct __attribute__((packed)) RGBA : RGB {
 uint8_t a;
};

static_assert( sizeof(RGB) == 3u, &quot;Unexpected size&quot; );
static_assert( sizeof(RGBA) == 4u, &quot;Unexpected size&quot; );
</code></pre>

blocks|key|2963569|text|我可能错了，但在我看来，你可以定义：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2963570|struct+RGBA+{
++++struct+RGB+base;
++++unsigned+char+g;
};|code-block|syntax|javascript|2963571|和(1)+RGBA将是POD，以及(2)您可以通过两种方式进行转换：|2963572|RRBA+x;
RGB*+x_rgb+=+reinterpret_cast<RGB*>(&x);
RGBA*+x_rgba+=+reinterpret_cast<RGBA*>(x_rgb);|2963573|我怀疑会有一些填充可能会被attribute((packed)).消除|offset|length|style|BOLD|2963574|entityMap^0|0|0|0|0|D|9|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I maybe wrong but seems to me that you can define:
<pre><code>struct RGBA {
 struct RGB base;
 unsigned char g;
};
</code></pre>
and (1) RGBA will be POD, and (2) you can cast both ways:
<pre><code>RRBA x;
RGB* x_rgb = reinterpret_cast&lt;RGB*&gt;(&amp;x);
RGBA* x_rgba = reinterpret_cast&lt;RGBA*&gt;(x_rgb);
</code></pre>
I suspect there will be some padding that may be eliminated by attribute((packed)).

Let's say, I have a <code>struct RGB</code> and I want to create <code>struct RGBA</code>, which inherits <code>RGB</code>:

<pre><code>struct RGB {
 unsigned char r;
 unsigned char g;
 unsigned char b;
};

struct RGBA: RGB {
 unsigned char a;
};
</code></pre>

Both will be used for reading uncompressed image data: 

<pre><code>RGBA *pixel=static_cast&lt;RGBA *&gt;(image-&gt;uncompressed_data);
</code></pre>

Question: Is this safe, regarding the memory layout of <code>struct RGBA</code>? Does anyone guarantee, that:

<ul>
<li><code>unsigned char a</code> comes after the <code>RGB struct</code> (not before)</li>
<li>There is no padding between <code>struct RGB</code> and the a parameter from <code>struct RGBA</code>?</li>
</ul>

will <code>#pragma pack</code> help here? It's all about memory layout during inheritance.

C++ POD struct inheritance? Are there any guarantees about the memory layout of derived members

编译器

比方说，我有一个struct RGB，我想创建继承RGB的struct RGBAstruct RGB {    unsigned char r;    unsigned char g;    unsigned char b;};struct RGBA: RGB {    unsigned char a;};两者都将用于...

问C++ POD结构继承？派生成员的内存布局有什么保证吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C++ POD结构继承？派生成员的内存布局有什么保证吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C++ POD结构继承？派生成员的内存布局有什么保证吗？
EN