On Thu, 12 Sep 2019 at 14:17, Rene Rivera via SG14 <sg14_at_[hidden]>
wrote:

> On Thu, Sep 12, 2019 at 7:05 AM Klaim - Joël Lamotte <mjklaim_at_[hidden]>
> wrote:
>
>>
>> 1. If I understand correctly, as soon as you add `layout:` in a class
>> definition, you _must_ list all non-static member objects. Correct?
>>
>
> No..
>
> * Members listed would come first in the class member layout.
> * Members not listed would follow with the existing layout rules.
>
>
>>
I see, makes sense.


> 2. I infer that two classes with the same name in the same namespace with
>> the same members but different layouts leads to a compilation error.
>> Am I correct?
>>
>
> Ah.. Wouldn't you get duplicate definition error currently? Or at least
> link errors if they happen to be compiled in different TUs?
>
>

If the layout part is part of the definition, then I believe that would be
like that but it was not clear from the proposal.
For example:

struct X
{
public:
    int a;
    int b;
};

struct X
{
    int a;
    int b;
};

struct X
{
private:
public:
    int a;
private:
public:
    int b;
};

My current understanding is that these 3 definitions do not break ODR if
defined once in 3 separate cpp files of the same program (no link error,
defined behavior).
If I am correct, then it is not clear to me if `layout:` participate to the
definition or not.
I do expect it to do participate to the definition and different layout
breaks ODR, as expected, it's just not stated as such.


> 5. How would that impact classes with virtual function members? Should the
>> implementation of the virtual calls (through v-table usually)_ be ignored
>> and be implementation-defined? Or should it be visible in the layout
>> section?
>>
>
> This is for layout of the data members only. I.e. it would be an error to
> specify functions in the layout section. Not sure how it applies to the
> vtable. Can you elaborate?
>
>
Sure:
I am basically asking for a clarification in the paper that the feature
only affects order of data members (and alignment if it's ok) and does not
affect other unspecified implementation details like how virtual functions
are implemented (where the v-table pointer is placed, if the implementation
uses the v-table technique).

A. Joël Lamotte