On Thu, Sep 12, 2019 at 7:05 AM Klaim - Joël Lamotte <mjklaim_at_[hidden]>
wrote:

>
>
> On Mon, 9 Sep 2019 at 21:00, Rene Rivera via SG14 <sg14_at_[hidden]>
> wrote:
>
>> My entry for the agenda at the CppCon meeting is...
>>
>> "Member Layout Control"
>> <
>> https://raw.githack.com/grafikrobot/papers/master/wg21/member_layout/member_layout_D1605R0.html
>> >
>>
>> It's "rough" first attempt at this. But it's good enough for discussion.
>>
>>
> Hi, nice idea.
>

Thanks.


> Some questions/remarks I had while reading:
>
> 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.


> 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?


> 3. In my humble opinion, the alignment should be part of the layout as it
> is directly related.
>

Same sentiment was expressed at the meeting yesterday :-) And I agree.


> 4. Could you add examples of ABI maintenance while evolving a class? I can
> see how but I think it would be useful in the paper.
>

Sure.


> 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?

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net