x86: segmentation.h: fix C++ build error

[andrewboie]

Signed-off-by: Andrew Boie andrew.p.boie@intel.com

[pfalcon]

Maybe I'm dumb, but I didn't get what was wrong from the diff/commit message.

[andrewboie]

In C++ designated initializers have to be populated in the order they are specified in the struct definition, for reasons which are unknown to me

[pfalcon]

Thanks, that's what I thought (really). But please treat that as a random note re: quality of the commit messages: if there's something unclear, other people can't learn from it and will repeat the mistake. (Yeah, my messages should be better too. ;-).

[lpereira]

I suspect it's the same reason initializer lists in constructors have to specify fields in the same order they're in the definition. This wil work:

struct SomeStruct {
    int foo;
    int bar;

    explicit SomeStruct(int foo_, int bar_) : foo(foo_), bar(bar_) {}
};

But writing : bar(...), foo(...) won't. Given that initializer lists are not part of C++ (yet) and are a GCC extension, I suspect that GCC uses that as a syntax sugar to create a constructor (don't quote me on this). In any case, this gives an "official" answer why the order matters.

[andyross]

It's for exactly that reason, yeah. The C++ standard guarantees that members are initialized in the order they appear in the struct. Allowing the constructor initializer expressions to execute in an order other than the one they have in the file was considered to be certifiably insane by the standards committee (of course, the right answer would have been to guarantee to initialize them in the order specified by the initializer list! but they messed up in the original spec that predated constructor initializers).

What's interesting is that GCC applies the same rules to their own named-field struct initializer extension when compiling C++ but not when generating C. I certainly had no clue.