0

I was just playing around with g++, and I found that

#include <type_traits>

class Foo {
public: int x;
public: char y;
public: double z;
};

static_assert(std::is_standard_layout<Foo>::value, "Foo is not standard layout");

int main() {}

Compiles just fine.

According to this answer, data members across access specifiers may be reordered in memory. So there's no gaurantee that x has to actually be the first member of Foo when actually laid out in memory. The way I've defined Foo, y could actually be the first element right?

I thought standard layout meant that you could more or less understand how the bytes are laid out for the given type. Allowing fields in a standard layout type to be reordered in an arbitrary manner seems counterintuitive to me. Why is this allowed?

Community
  • 1
  • 1
math4tots
  • 8,540
  • 14
  • 58
  • 95
  • `Foo` may not be standard layout doesn't means `Foo` _must not_ be standard layout. i.e. different version of the compiler may choose to fail on the static assert. But if it compiles, you know it must be standard layout. – Bryan Chen Dec 07 '16 at 03:56

1 Answers1

3

All members of your structure have the same access specifier: public. The fact that the keyword appears before every class member is immaterial. This is equivalent to the public access specifier appearing once, before all class members.

Sam Varshavchik
  • 114,536
  • 5
  • 94
  • 148
  • So is the answer I linked incorrect? Because that answer suggests that having a `public` access specifier appearing more than once does have some semantic difference – math4tots Dec 07 '16 at 03:52
  • By "answer I linked" I mean this one: http://stackoverflow.com/questions/11362543/using-same-c-access-specifiers-mulitple-times/11364029#11364029 – math4tots Dec 07 '16 at 03:52
  • @math4tots It looks to me like the answer is wrong. from draft n3797 9.2 p13: *Nonstatic data members of a (non-union) class with the same access control (Clause 11) are allocated so that later members have higher addresses within a class object* So even though private, protected and public have no order to each other all objects of one type have and absolute order to each other. – NathanOliver Dec 07 '16 at 03:57
  • Ah, that's embarrassing ^_^; I told someone at work today that they were different... I'll learn to refer to the standard before pretending I know things next time – math4tots Dec 07 '16 at 04:04
  • That quote from the standard mentions ordering, but doesn't mention whether those fields must be contiguous (e.g. a private field could still potentially be inserted between two public fields), do you happen to know if there's any language about when that can and can't happen? – math4tots Dec 07 '16 at 04:20
  • I searched http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf for the term "contiguous" and couldn't find anything, but I thought maybe they used different terminology to express the idea of "two fields being next to each other with nothing between them" – math4tots Dec 07 '16 at 04:24