------=_Part_2091_18155277.1367853826012
Content-Type: text/plain; charset=ISO-8859-1



On Monday, May 6, 2013 8:03:43 AM UTC-7, unituni...@gmail.com wrote:
>
> First of all, I think it won't hurt almost every existing compilers.
> Actually it won't asking for any change of each one of them:
> Say,
> *1.
> - If each of all the base classes of a class has only one base class, and
> each of all these classes neither contains any Virtual function nor
> Virtually inherited from the other class, The most inheritance will share
> the same address of each bases.
> *2.
> - If a class has no virtual functions, the first defined data member of
> will share the same address of the class.
>

The problem with this is *defining* what "the first defined data member"
means. Do base classes come first or last? Different compilers do it
differently. That's why the current standard layout rules only work with
base classes if at most one class in the hierarchy has non-static data
members.

There are compilers that put derived classes first. And there are compilers
that put derived classes last. So *someone* is going to have to change
their compilers to comply with whatever rule you eventually come up with.

And that's no good.

*3(Optional).
> - If a classe inherited from only one class, the two class will share the
> same address.
>

What do you mean by "share the same address"? What does this have to do
with standard layout or layout compatibility?


> I think the rule about the Standard-Layout is not much help for C++ itself
> because if we need to extend a class by inheriting rather than defind a
> data member to use its original protected member functions. If we need to
> apply the memory layout then it's a realy big lose if the data member
> definition is the only option: The access controls won't be easy, even the
> function can be mapped it is also slow for both compiling and
> running(canceled inlines) even with inline keyword.
>

I'm sorry, but I don't understand your reasoning for this. Can you give an
example of code where you're significantly using protected and inheritance,
but *not* polymorphism (ie: virtual function calls)? *And* that this code
needs to use low-level layout-compatibility rules.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2091_18155277.1367853826012
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, May 6, 2013 8:03:43 AM UTC-7, unituni...@gmail.com wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div>First of all, I think it=
 won't hurt almost every existing compilers. Actually it won't asking for a=
ny change of each one of them:</div><div>Say,</div><div>*1.</div><div>- If =
each of all the base classes of a class has only one base class, and each o=
f all these classes neither contains any Virtual function nor Virtually inh=
erited from the other class, The most inheritance will share the same addre=
ss of each bases.</div><div>*2.</div><div>- If a class has no virtual funct=
ions, the first defined data member of will share the same address of the c=
lass.</div></blockquote><div><br>The problem with this is <i>defining</i> w=
hat "the first defined data member" means. Do base classes come first or la=
st? Different compilers do it differently. That's why the current standard =
layout rules only work with base classes if at most one class in the hierar=
chy has non-static data members.<br><br>There are compilers that put derive=
d classes first. And there are compilers that put derived classes last. So =
<i>someone</i> is going to have to change their compilers to comply with wh=
atever rule you eventually come up with.<br><br>And that's no good.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>*3(Optional).</div>=
<div>- If a classe inherited from only one class, the two class will share =
the same address.</div></blockquote><div><br>What do you mean by "share the=
 same address"? What does this have to do with standard layout or layout co=
mpatibility?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
><br></div><div>I think the rule about the Standard-Layout is not much help=
 for C++ itself because if we need to extend a class by inheriting rather t=
han defind a data member to use its original protected member functions. If=
 we need to apply the memory layout then it's a realy big lose if the data =
member definition is the only option: The access controls won't be easy, ev=
en the function can be mapped it is also slow for both compiling and runnin=
g(canceled inlines) even with inline keyword.</div></blockquote><div><br>I'=
m sorry, but I don't understand your reasoning for this. Can you give an ex=
ample of code where you're significantly using protected and inheritance, b=
ut <i>not</i> polymorphism (ie: virtual function calls)? <i>And</i> that th=
is code needs to use low-level layout-compatibility rules.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2091_18155277.1367853826012--

.

------=_Part_948_12370551.1367859947901
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC-4=
=E4=B8=8A=E5=8D=8811=E6=97=B623=E5=88=8645=E7=A7=92=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Monday, May 6, 2013 8:03:43 AM UTC-7, unituni...@gmail.com wrote:
>>
>> First of all, I think it won't hurt almost every existing compilers.=20
>> Actually it won't asking for any change of each one of them:
>> Say,
>> *1.
>> - If each of all the base classes of a class has only one base class, an=
d=20
>> each of all these classes neither contains any Virtual function nor=20
>> Virtually inherited from the other class, The most inheritance will shar=
e=20
>> the same address of each bases.
>> *2.
>> - If a class has no virtual functions, the first defined data member of=
=20
>> will share the same address of the class.
>>
>
> The problem with this is *defining* what "the first defined data member"=
=20
> means. Do base classes come first or last? Different compilers do it=20
> differently. That's why the current standard layout rules only work with=
=20
> base classes if at most one class in the hierarchy has non-static data=20
> members.
>
> There are compilers that put derived classes first. And there are=20
> compilers that put derived classes last. So *someone* is going to have to=
=20
> change their compilers to comply with whatever rule you eventually come u=
p=20
> with.
>
> And that's no good.
>
> *3(Optional).
>> - If a classe inherited from only one class, the two class will share th=
e=20
>> same address.
>>
>
> What do you mean by "share the same address"? What does this have to do=
=20
> with standard layout or layout compatibility?
>
>
>> I think the rule about the Standard-Layout is not much help for C++=20
>> itself because if we need to extend a class by inheriting rather than=20
>> defind a data member to use its original protected member functions. If =
we=20
>> need to apply the memory layout then it's a realy big lose if the data=
=20
>> member definition is the only option: The access controls won't be easy,=
=20
>> even the function can be mapped it is also slow for both compiling and=
=20
>> running(canceled inlines) even with inline keyword.
>>
>
> I'm sorry, but I don't understand your reasoning for this. Can you give a=
n=20
> example of code where you're significantly using protected and inheritanc=
e,=20
> but *not* polymorphism (ie: virtual function calls)? *And* that this code=
=20
> needs to use low-level layout-compatibility rules.
>

Here is the code for your last question only, the other code will follow=20
later.

// These structures are only for testing purpose.
struct Base // Assuming it and BinaryDumperHost are provided by a library=
=20
maker [NO.1]. Should not be available to clients.
{
friend class BinaryDumperHost; // This class is another class that use Base=
=20
to store a serials of data.

private:
int val; // TODO: Should only be modified by BinaryDumperHost and the=20
inherited classes/structures from Base.

public:
int get_val(void) const { return(val); };

protected:
void set_val(int newVal) // Assuming it should only be called by either=20
inherited classes/structures or BinaryDumperHost.
{
val =3D min(newVal, 10); // Assuming we restrict the input, so the Extended=
=20
structures can't give val as they want.
};

Base(void): val() {}; // Private constructor. So the Base can only created=
=20
by either BinaryDumperHost or the extension.

private:
static void * operator new (size_t);
static void * operator new [] (size_t);
static void operator delete (void *);    // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
static void operator delete [] (void *); // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
};

// Assuming it and BinaryDumperHost are provided by another library maker=
=20
[NO.2], which not just have to follow
// the regulations defined by [No.1] but also have made extra regulations=
=20
itself. Finally it and Base will be
// proceed by BinaryDumperHost.
struct Pseudo_STD_Extended: Base // Should not be available to clients.
{
friend class BinaryDumperHost;

private:
int valExt1; // val1
int valExt2; // val2

public:
// int get_val1(void) const { return(valExt1); };
// int get_val2(void) const { return(valExt2); };

private:
void set_val(int newVal) // Assuming it should only be called by=20
BinaryDumperHost.
{
int _Fixed_Val;

// Generate _Fixed_Val here, which is based on the newVal and valExt1 and=
=20
valExt1.

Base::set_val(_Fixed_Val);
}

//void set_val1(int newVal); // Assuming it should only be called by=20
BinaryDumperHost.
//void set_val2(int newVal); // Assuming it should only be called by=20
BinaryDumperHost.

private:
Pseudo_STD_Extended(void) {}; // Call Base::Base(). Should only available=
=20
to BinaryDumperHost but not clients.

private:
static void * operator new (size_t);
static void * operator new [] (size_t);
static void operator delete (void *);    // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
static void operator delete [] (void *); // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
};

struct STD_LY_Extended // Available for current C++ STD.
{
Base _base_vals; // Entry.

private:
int valExt1; // val1
int valExt2; // val2

public:
// int get_val1(void) const { return(valExt1); };
// int get_val2(void) const { return(valExt2); };

private:
//void set_val(int newVal);// I don't know how to make this simply.
void set_val(int newVal)// It shouldn't have been opened to clients.
{
//_base_vals.set_val(_Fixed_Val); // NO way to go.
};

private:
STD_Extended(void) {}; // Call Base::Base(). Should only available to=20
BinaryDumperHost but not clients.

private:
static void * operator new (size_t);
static void * operator new [] (size_t);
static void operator delete (void *);    // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
static void operator delete [] (void *); // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
};
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_948_12370551.1367859947901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=80UTC-4=E4=B8=8A=E5=8D=8811=E6=97=B623=E5=88=8645=E7=A7=92=EF=BC=8CNicol B=
olas=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><br><br>On Monday, May 6, 2013 8:03:43 AM UTC-7, <a>unituni...@gmail.com</=
a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>First of all, I think=
 it won't hurt almost every existing compilers. Actually it won't asking fo=
r any change of each one of them:</div><div>Say,</div><div>*1.</div><div>- =
If each of all the base classes of a class has only one base class, and eac=
h of all these classes neither contains any Virtual function nor Virtually =
inherited from the other class, The most inheritance will share the same ad=
dress of each bases.</div><div>*2.</div><div>- If a class has no virtual fu=
nctions, the first defined data member of will share the same address of th=
e class.</div></blockquote><div><br>The problem with this is <i>defining</i=
> what "the first defined data member" means. Do base classes come first or=
 last? Different compilers do it differently. That's why the current standa=
rd layout rules only work with base classes if at most one class in the hie=
rarchy has non-static data members.<br><br>There are compilers that put der=
ived classes first. And there are compilers that put derived classes last. =
So <i>someone</i> is going to have to change their compilers to comply with=
 whatever rule you eventually come up with.<br><br>And that's no good.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>*3(Optional).</div><d=
iv>- If a classe inherited from only one class, the two class will share th=
e same address.</div></blockquote><div><br>What do you mean by "share the s=
ame address"? What does this have to do with standard layout or layout comp=
atibility?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></=
div><div>I think the rule about the Standard-Layout is not much help for C+=
+ itself because if we need to extend a class by inheriting rather than def=
ind a data member to use its original protected member functions. If we nee=
d to apply the memory layout then it's a realy big lose if the data member =
definition is the only option: The access controls won't be easy, even the =
function can be mapped it is also slow for both compiling and running(cance=
led inlines) even with inline keyword.</div></blockquote><div><br>I'm sorry=
, but I don't understand your reasoning for this. Can you give an example o=
f code where you're significantly using protected and inheritance, but <i>n=
ot</i> polymorphism (ie: virtual function calls)? <i>And</i> that this code=
 needs to use low-level layout-compatibility rules.<br></div></blockquote><=
div><br></div><div>Here is the code for your last question only, the other =
code will follow later.<br></div><div><br></div><div>// These structures ar=
e only for testing purpose.</div><div>struct Base // Assuming it and Binary=
DumperHost are provided by a library maker [NO.1]. Should not be available =
to clients.</div><div>{</div><div><span class=3D"Apple-tab-span" style=3D"w=
hite-space:pre"> </span>friend class BinaryDumperHost; // This class is ano=
ther class that use Base to store a serials of data.</div><div><br></div><d=
iv>private:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:p=
re"> </span>int val; // TODO: Should only be modified by BinaryDumperHost a=
nd the inherited classes/structures from Base.</div><div><br></div><div>pub=
lic:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </=
span>int get_val(void) const { return(val); };</div><div><br></div><div>pro=
tected:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">=
 </span>void set_val(int newVal) // Assuming it should only be called by ei=
ther inherited classes/structures or BinaryDumperHost.</div><div><span clas=
s=3D"Apple-tab-span" style=3D"white-space:pre"> </span>{</div><div><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre">  </span>val =3D min(newVa=
l, 10); // Assuming we restrict the input, so the Extended structures can't=
 give val as they want.</div><div><span class=3D"Apple-tab-span" style=3D"w=
hite-space:pre"> </span>};</div><div><br></div><div><span class=3D"Apple-ta=
b-span" style=3D"white-space:pre"> </span>Base(void): val() {}; // Private =
constructor. So the Base can only created by either BinaryDumperHost or the=
 extension.</div><div><br></div><div>private:</div><div><span class=3D"Appl=
e-tab-span" style=3D"white-space:pre"> </span>static void * operator new (s=
ize_t);</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">=
 </span>static void * operator new [] (size_t);</div><div><span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre"> </span>static void operator delete=
 (void *); &nbsp; &nbsp;// Raise compiling error if the interitanced classe=
s being deleted with a Base * pointer.</div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre"> </span>static void operator delete [] (void=
 *); // Raise compiling error if the interitanced classes being deleted wit=
h a Base * pointer.</div><div>};</div><div><br></div><div>// Assuming it an=
d BinaryDumperHost are provided by another library maker [NO.2], which not =
just have to follow</div><div>// the regulations defined by [No.1] but also=
 have made extra regulations itself. Finally it and Base will be</div><div>=
// proceed by BinaryDumperHost.</div><div>struct Pseudo_STD_Extended: Base =
// Should not be available to clients.</div><div>{</div><div><span class=3D=
"Apple-tab-span" style=3D"white-space:pre"> </span>friend class BinaryDumpe=
rHost;</div><div><br></div><div>private:</div><div><span class=3D"Apple-tab=
-span" style=3D"white-space:pre"> </span>int valExt1; // val1</div><div><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int valExt2; =
// val2</div><div><br></div><div>public:</div><div>//<span class=3D"Apple-t=
ab-span" style=3D"white-space:pre"> </span>int get_val1(void) const { retur=
n(valExt1); };</div><div>//<span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre"> </span>int get_val2(void) const { return(valExt2); };</div><div><=
br></div><div>private:</div><div><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>void set_val(int newVal) // Assuming it should only =
be called by BinaryDumperHost.</div><div><span class=3D"Apple-tab-span" sty=
le=3D"white-space:pre"> </span>{</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre">  </span>int _Fixed_Val;</div><div><br></div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>// Genera=
te _Fixed_Val here, which is based on the newVal and valExt1 and valExt1.</=
div><div><br></div><div><span class=3D"Apple-tab-span" style=3D"white-space=
:pre">  </span>Base::set_val(_Fixed_Val);</div><div><span class=3D"Apple-ta=
b-span" style=3D"white-space:pre"> </span>}</div><div><br></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>//void set_val1(=
int newVal); // Assuming it should only be called by BinaryDumperHost.</div=
><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>//vo=
id set_val2(int newVal); // Assuming it should only be called by BinaryDump=
erHost.</div><div><br></div><div>private:</div><div><span class=3D"Apple-ta=
b-span" style=3D"white-space:pre"> </span>Pseudo_STD_Extended(void) {}; // =
Call Base::Base(). Should only available to BinaryDumperHost but not client=
s.</div><div><br></div><div>private:</div><div><span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre"> </span>static void * operator new (size_t);</=
div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>s=
tatic void * operator new [] (size_t);</div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre"> </span>static void operator delete (void *)=
; &nbsp; &nbsp;// Raise compiling error if the interitanced classes being d=
eleted with a Base * pointer.</div><div><span class=3D"Apple-tab-span" styl=
e=3D"white-space:pre"> </span>static void operator delete [] (void *); // R=
aise compiling error if the interitanced classes being deleted with a Base =
* pointer.</div><div>};</div><div><br></div><div>struct STD_LY_Extended // =
Available for current C++ STD.</div><div>{</div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre"> </span>Base _base_vals; // Entry.</div>=
<div><br></div><div>private:</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>int valExt1; // val1</div><div><span class=3D"=
Apple-tab-span" style=3D"white-space:pre"> </span>int valExt2; // val2</div=
><div><br></div><div>public:</div><div>//<span class=3D"Apple-tab-span" sty=
le=3D"white-space:pre"> </span>int get_val1(void) const { return(valExt1); =
};</div><div>//<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </=
span>int get_val2(void) const { return(valExt2); };</div><div><br></div><di=
v>private:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pr=
e"> </span>//void set_val(int newVal);// I don't know how to make this simp=
ly.</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </s=
pan>void set_val(int newVal)// It shouldn't have been opened to clients.</d=
iv><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>{<=
/div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span=
>//_base_vals.set_val(_Fixed_Val); // NO way to go.</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>};</div><div><br></di=
v><div>private:</div><div><span class=3D"Apple-tab-span" style=3D"white-spa=
ce:pre"> </span>STD_Extended(void) {}; // Call Base::Base(). Should only av=
ailable to BinaryDumperHost but not clients.</div><div><br></div><div>priva=
te:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </s=
pan>static void * operator new (size_t);</div><div><span class=3D"Apple-tab=
-span" style=3D"white-space:pre"> </span>static void * operator new [] (siz=
e_t);</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> <=
/span>static void operator delete (void *); &nbsp; &nbsp;// Raise compiling=
 error if the interitanced classes being deleted with a Base * pointer.</di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>sta=
tic void operator delete [] (void *); // Raise compiling error if the inter=
itanced classes being deleted with a Base * pointer.</div><div>};</div><div=
>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_948_12370551.1367859947901--

.

------=_Part_130_10573621.1367860978064
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC-4=
=E4=B8=8B=E5=8D=881=E6=97=B605=E5=88=8647=E7=A7=92=EF=BC=8Cunituni...@gmail=
..com=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> =E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC=
-4=E4=B8=8A=E5=8D=8811=E6=97=B623=E5=88=8645=E7=A7=92=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A
>>
>>
>> The problem with this is *defining* what "the first defined data member"=
=20
>> means. Do base classes come first or last? Different compilers do it=20
>> differently. That's why the current standard layout rules only work with=
=20
>> base classes if at most one class in the hierarchy has non-static data=
=20
>> members.
>>
>> The second line i should have posted:
2.
- If a class has neither virtual functions nor base classes, the first=20
defined data member of will share the same address of the class, no matter=
=20
that member is or isn't Standard-Layouted.
struct Sealer // Without take virtual functions / base classes itself.
{
   SomeClass header_val;
   int val1;
   char val2;
   Sealer(void);
};
Let us always get
 reinterpret_cast<void *>(&Sealer) =3D=3D reinterpret_cast<void *>(&header_=
val)
being true.
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_130_10573621.1367860978064
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br>=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80U=
TC-4=E4=B8=8B=E5=8D=881=E6=97=B605=E5=88=8647=E7=A7=92=EF=BC=8Cunituni...@g=
mail.com=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><br><br>=
=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC-4=
=E4=B8=8A=E5=8D=8811=E6=97=B623=E5=88=8645=E7=A7=92=EF=BC=8C<wbr>Nicol Bola=
s=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;"><div><br>The probl=
em with this is <i>defining</i> what "the first defined data member" means.=
 Do base classes come first or last? Different compilers do it differently.=
 That's why the current standard layout rules only work with base classes i=
f at most one class in the hierarchy has non-static data members.<br><br></=
div></blockquote></blockquote><div>The second line i should have posted:<br=
>2.<br>- If a class has neither virtual functions nor base classes, the fir=
st defined data member of will share the same address of the class, no matt=
er that member is or isn't Standard-Layouted.</div><div>struct Sealer // Wi=
thout take virtual functions / base classes itself.<br>{<br>&nbsp;&nbsp; So=
meClass header_val;<br>&nbsp;&nbsp; int val1;<br>&nbsp;&nbsp; char val2;</d=
iv><div>&nbsp;&nbsp; Sealer(void);<br>};</div><div>Let us always get<br>&nb=
sp;reinterpret_cast&lt;void *&gt;(&amp;Sealer) =3D=3D reinterpret_cast&lt;v=
oid *&gt;(&amp;header_val)<br>being true.</div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_130_10573621.1367860978064--

.

------=_Part_630_31336792.1367862113202
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC-4=
=E4=B8=8A=E5=8D=8811=E6=97=B623=E5=88=8645=E7=A7=92=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Monday, May 6, 2013 8:03:43 AM UTC-7, unituni...@gmail.com wrote:
>>
>> First of all, I think it won't hurt almost every existing compilers.=20
>> Actually it won't asking for any change of each one of them:
>> Say,
>> *1.
>> - If each of all the base classes of a class has only one base class, an=
d=20
>> each of all these classes neither contains any Virtual function nor=20
>> Virtually inherited from the other class, The most inheritance will shar=
e=20
>> the same address of each bases.
>> *2.
>> - If a class has no virtual functions, the first defined data member of=
=20
>> will share the same address of the class.
>>
>
> The problem with this is *defining* what "the first defined data member"=
=20
> means. Do base classes come first or last? Different compilers do it=20
> differently. That's why the current standard layout rules only work with=
=20
> base classes if at most one class in the hierarchy has non-static data=20
> members.
>
> There are compilers that put derived classes first. And there are=20
> compilers that put derived classes last. So *someone* is going to have to=
=20
> change their compilers to comply with whatever rule you eventually come u=
p=20
> with.
>
> And that's no good.
>
> *3(Optional).
>> - If a classe inherited from only one class, the two class will share th=
e=20
>> same address.
>>
>
> What do you mean by "share the same address"? What does this have to do=
=20
> with standard layout or layout compatibility?
>
>
>> I think the rule about the Standard-Layout is not much help for C++=20
>> itself because if we need to extend a class by inheriting rather than=20
>> defind a data member to use its original protected member functions. If =
we=20
>> need to apply the memory layout then it's a realy big lose if the data=
=20
>> member definition is the only option: The access controls won't be easy,=
=20
>> even the function can be mapped it is also slow for both compiling and=
=20
>> running(canceled inlines) even with inline keyword.
>>
>
> I'm sorry, but I don't understand your reasoning for this. Can you give a=
n=20
> example of code where you're significantly using protected and inheritanc=
e,=20
> but *not* polymorphism (ie: virtual function calls)? *And* that this code=
=20
> needs to use low-level layout-compatibility rules.
>

Here is the code for your last question only, the other code will follow=20
later.

// These structures are only for testing purpose.
struct Base // Assuming it and BinaryDumperHost are provided by a library=
=20
maker [NO.1]. Should not be available to clients.
{
friend class BinaryDumperHost; // This class is another class that use Base=
=20
to store a serials of data.

private:
int val; // TODO: Should only be modified by BinaryDumperHost and the=20
inherited classes/structures from Base.

public:
int get_val(void) const { return(val); };

protected:
void set_val(int newVal) // Assuming it should only be called by either=20
inherited classes/structures or BinaryDumperHost.
{
val =3D min(newVal, 10); // Assuming we restrict the input, so the Extended=
=20
structures can't give val as they want.
};

Base(void): val() {}; // Private constructor. So the Base can only created=
=20
by either BinaryDumperHost or the extension.

private:
static void * operator new (size_t);
static void * operator new [] (size_t);
static void operator delete (void *);    // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
static void operator delete [] (void *); // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
};

// Assuming it is provided by another library maker [NO.2], which not just=
=20
have to follow
// the regulations defined by [No.1] but also have made extra regulations=
=20
itself. Finally it and Base will be
// proceed by BinaryDumperHost.
struct Pseudo_STD_Extended: Base // Should not be available to clients.
{
friend class BinaryDumperHost;

private:
int valExt1; // val1
int valExt2; // val2

public:
// int get_val1(void) const { return(valExt1); };
// int get_val2(void) const { return(valExt2); };

private:
void set_val(int newVal) // Assuming it should only be called by=20
BinaryDumperHost.
{
int _Fixed_Val;

// Generate _Fixed_Val here, which is based on the newVal and valExt1 and=
=20
valExt1.

Base::set_val(_Fixed_Val);
}

//void set_val1(int newVal); // Assuming it should only be called by=20
BinaryDumperHost.
//void set_val2(int newVal); // Assuming it should only be called by=20
BinaryDumperHost.

private:
Pseudo_STD_Extended(void) {}; // Call Base::Base(). Should only available=
=20
to BinaryDumperHost but not clients.

private:
static void * operator new (size_t);
static void * operator new [] (size_t);
static void operator delete (void *);    // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
static void operator delete [] (void *); // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
};

struct STD_LY_Extended // Available for current C++ STD.
{
Base _base_vals; // Entry.

private:
int valExt1; // val1
int valExt2; // val2

public:
// int get_val1(void) const { return(valExt1); };
// int get_val2(void) const { return(valExt2); };

private:
//void set_val(int newVal);// I don't know how to make this simply.
void set_val(int newVal)// It shouldn't have been opened to clients.
{
//_base_vals.set_val(_Fixed_Val); // NO way to go.
};

private:
STD_Extended(void) {}; // Call Base::Base(). Should only available to=20
BinaryDumperHost but not clients.

private:
static void * operator new (size_t);
static void * operator new [] (size_t);
static void operator delete (void *);    // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
static void operator delete [] (void *); // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
};

As a result the clients' code can only access BinaryDumperHost, and these=
=20
structures won't be usable to them(although they can access those which are=
=20
handled by BinaryDumperHost).
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_630_31336792.1367862113202
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=80UTC-4=E4=B8=8A=E5=8D=8811=E6=97=B623=E5=88=8645=E7=A7=92=EF=BC=8CNicol B=
olas=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><br><br>On Monday, May 6, 2013 8:03:43 AM UTC-7, <a>unituni...@gmail.com</=
a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>First of all, I think=
 it won't hurt almost every existing compilers. Actually it won't asking fo=
r any change of each one of them:</div><div>Say,</div><div>*1.</div><div>- =
If each of all the base classes of a class has only one base class, and eac=
h of all these classes neither contains any Virtual function nor Virtually =
inherited from the other class, The most inheritance will share the same ad=
dress of each bases.</div><div>*2.</div><div>- If a class has no virtual fu=
nctions, the first defined data member of will share the same address of th=
e class.</div></blockquote><div><br>The problem with this is <i>defining</i=
> what "the first defined data member" means. Do base classes come first or=
 last? Different compilers do it differently. That's why the current standa=
rd layout rules only work with base classes if at most one class in the hie=
rarchy has non-static data members.<br><br>There are compilers that put der=
ived classes first. And there are compilers that put derived classes last. =
So <i>someone</i> is going to have to change their compilers to comply with=
 whatever rule you eventually come up with.<br><br>And that's no good.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>*3(Optional).</div><d=
iv>- If a classe inherited from only one class, the two class will share th=
e same address.</div></blockquote><div><br>What do you mean by "share the s=
ame address"? What does this have to do with standard layout or layout comp=
atibility?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></=
div><div>I think the rule about the Standard-Layout is not much help for C+=
+ itself because if we need to extend a class by inheriting rather than def=
ind a data member to use its original protected member functions. If we nee=
d to apply the memory layout then it's a realy big lose if the data member =
definition is the only option: The access controls won't be easy, even the =
function can be mapped it is also slow for both compiling and running(cance=
led inlines) even with inline keyword.</div></blockquote><div><br>I'm sorry=
, but I don't understand your reasoning for this. Can you give an example o=
f code where you're significantly using protected and inheritance, but <i>n=
ot</i> polymorphism (ie: virtual function calls)? <i>And</i> that this code=
 needs to use low-level layout-compatibility rules.<br></div></blockquote><=
div><br></div><div>Here is the code for your last question only, the other =
code will follow later.</div><div><br></div><div>// These structures are on=
ly for testing purpose.</div><div>struct Base // Assuming it and BinaryDump=
erHost are provided by a library maker [NO.1]. Should not be available to c=
lients.</div><div>{</div><div><span class=3D"Apple-tab-span" style=3D"white=
-space:pre"> </span>friend class BinaryDumperHost; // This class is another=
 class that use Base to store a serials of data.</div><div><br></div><div>p=
rivate:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">=
 </span>int val; // TODO: Should only be modified by BinaryDumperHost and t=
he inherited classes/structures from Base.</div><div><br></div><div>public:=
</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span=
>int get_val(void) const { return(val); };</div><div><br></div><div>protect=
ed:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </s=
pan>void set_val(int newVal) // Assuming it should only be called by either=
 inherited classes/structures or BinaryDumperHost.</div><div><span class=3D=
"Apple-tab-span" style=3D"white-space:pre"> </span>{</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">  </span>val =3D min(newVal, =
10); // Assuming we restrict the input, so the Extended structures can't gi=
ve val as they want.</div><div><span class=3D"Apple-tab-span" style=3D"whit=
e-space:pre"> </span>};</div><div><br></div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre"> </span>Base(void): val() {}; // Private con=
structor. So the Base can only created by either BinaryDumperHost or the ex=
tension.</div><div><br></div><div>private:</div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre"> </span>static void * operator new (size=
_t);</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </=
span>static void * operator new [] (size_t);</div><div><span class=3D"Apple=
-tab-span" style=3D"white-space:pre"> </span>static void operator delete (v=
oid *); &nbsp; &nbsp;// Raise compiling error if the interitanced classes b=
eing deleted with a Base * pointer.</div><div><span class=3D"Apple-tab-span=
" style=3D"white-space:pre"> </span>static void operator delete [] (void *)=
; // Raise compiling error if the interitanced classes being deleted with a=
 Base * pointer.</div><div>};</div><div><br></div><div>// Assuming it is pr=
ovided by another library maker [NO.2], which not just have to follow</div>=
<div>// the regulations defined by [No.1] but also have made extra regulati=
ons itself. Finally it and Base will be</div><div>// proceed by BinaryDumpe=
rHost.</div><div>struct Pseudo_STD_Extended: Base // Should not be availabl=
e to clients.</div><div>{</div><div><span class=3D"Apple-tab-span" style=3D=
"white-space:pre"> </span>friend class BinaryDumperHost;</div><div><br></di=
v><div>private:</div><div><span class=3D"Apple-tab-span" style=3D"white-spa=
ce:pre"> </span>int valExt1; // val1</div><div><span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre"> </span>int valExt2; // val2</div><div><br></d=
iv><div>public:</div><div>//<span class=3D"Apple-tab-span" style=3D"white-s=
pace:pre"> </span>int get_val1(void) const { return(valExt1); };</div><div>=
//<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int get_=
val2(void) const { return(valExt2); };</div><div><br></div><div>private:</d=
iv><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>vo=
id set_val(int newVal) // Assuming it should only be called by BinaryDumper=
Host.</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> <=
/span>{</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">=
  </span>int _Fixed_Val;</div><div><br></div><div><span class=3D"Apple-tab-=
span" style=3D"white-space:pre">  </span>// Generate _Fixed_Val here, which=
 is based on the newVal and valExt1 and valExt1.</div><div><br></div><div><=
span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>Base::set_=
val(_Fixed_Val);</div><div><span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre"> </span>}</div><div><br></div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span>//void set_val1(int newVal); // Assuming =
it should only be called by BinaryDumperHost.</div><div><span class=3D"Appl=
e-tab-span" style=3D"white-space:pre"> </span>//void set_val2(int newVal); =
// Assuming it should only be called by BinaryDumperHost.</div><div><br></d=
iv><div>private:</div><div><span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre"> </span>Pseudo_STD_Extended(void) {}; // Call Base::Base(). Should=
 only available to BinaryDumperHost but not clients.</div><div><br></div><d=
iv>private:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:p=
re"> </span>static void * operator new (size_t);</div><div><span class=3D"A=
pple-tab-span" style=3D"white-space:pre"> </span>static void * operator new=
 [] (size_t);</div><div><span class=3D"Apple-tab-span" style=3D"white-space=
:pre"> </span>static void operator delete (void *); &nbsp; &nbsp;// Raise c=
ompiling error if the interitanced classes being deleted with a Base * poin=
ter.</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </=
span>static void operator delete [] (void *); // Raise compiling error if t=
he interitanced classes being deleted with a Base * pointer.</div><div>};</=
div><div><br></div><div>struct STD_LY_Extended // Available for current C++=
 STD.</div><div>{</div><div><span class=3D"Apple-tab-span" style=3D"white-s=
pace:pre"> </span>Base _base_vals; // Entry.</div><div><br></div><div>priva=
te:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </s=
pan>int valExt1; // val1</div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre"> </span>int valExt2; // val2</div><div><br></div><div>publ=
ic:</div><div>//<span class=3D"Apple-tab-span" style=3D"white-space:pre"> <=
/span>int get_val1(void) const { return(valExt1); };</div><div>//<span clas=
s=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int get_val2(void) c=
onst { return(valExt2); };</div><div><br></div><div>private:</div><div><spa=
n class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>//void set_val=
(int newVal);// I don't know how to make this simply.</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>void set_val(int newV=
al)// It shouldn't have been opened to clients.</div><div><span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre"> </span>{</div><div><span class=3D"=
Apple-tab-span" style=3D"white-space:pre">  </span>//_base_vals.set_val(_Fi=
xed_Val); // NO way to go.</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>};</div><div><br></div><div>private:</div><div=
><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>STD_Exten=
ded(void) {}; // Call Base::Base(). Should only available to BinaryDumperHo=
st but not clients.</div><div><br></div><div>private:</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>static void * operato=
r new (size_t);</div><div><span class=3D"Apple-tab-span" style=3D"white-spa=
ce:pre"> </span>static void * operator new [] (size_t);</div><div><span cla=
ss=3D"Apple-tab-span" style=3D"white-space:pre"> </span>static void operato=
r delete (void *); &nbsp; &nbsp;// Raise compiling error if the interitance=
d classes being deleted with a Base * pointer.</div><div><span class=3D"App=
le-tab-span" style=3D"white-space:pre"> </span>static void operator delete =
[] (void *); // Raise compiling error if the interitanced classes being del=
eted with a Base * pointer.</div><div>};</div><div><br></div><div>As a resu=
lt the clients' code can only access BinaryDumperHost, and these structures=
 won't be usable to them(although they can access those which are handled b=
y BinaryDumperHost).</div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_630_31336792.1367862113202--

.

------=_Part_2232_11958932.1367871739079
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC-4=
=E4=B8=8A=E5=8D=8811=E6=97=B623=E5=88=8645=E7=A7=92=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Monday, May 6, 2013 8:03:43 AM UTC-7, unituni...@gmail.com wrote:
>>
>> First of all, I think it won't hurt almost every existing compilers.=20
>> Actually it won't asking for any change of each one of them:
>> Say,
>> *1.
>> - If each of all the base classes of a class has only one base class, an=
d=20
>> each of all these classes neither contains any Virtual function nor=20
>> Virtually inherited from the other class, The most inheritance will shar=
e=20
>> the same address of each bases.
>> *2.
>> - If a class has no virtual functions, the first defined data member of=
=20
>> will share the same address of the class.
>>
>
> The problem with this is *defining* what "the first defined data member"=
=20
> means. Do base classes come first or last? Different compilers do it=20
> differently. That's why the current standard layout rules only work with=
=20
> base classes if at most one class in the hierarchy has non-static data=20
> members.
>
> There are compilers that put derived classes first. And there are=20
> compilers that put derived classes last. So *someone* is going to have to=
=20
> change their compilers to comply with whatever rule you eventually come u=
p=20
> with.
>
> And that's no good.
>
> *3(Optional).
>> - If a classe inherited from only one class, the two class will share th=
e=20
>> same address.
>>
>
> What do you mean by "share the same address"? What does this have to do=
=20
> with standard layout or layout compatibility?
>
>
>> I think the rule about the Standard-Layout is not much help for C++=20
>> itself because if we need to extend a class by inheriting rather than=20
>> defind a data member to use its original protected member functions. If =
we=20
>> need to apply the memory layout then it's a realy big lose if the data=
=20
>> member definition is the only option: The access controls won't be easy,=
=20
>> even the function can be mapped it is also slow for both compiling and=
=20
>> running(canceled inlines) even with inline keyword.
>>
>
> I'm sorry, but I don't understand your reasoning for this. Can you give a=
n=20
> example of code where you're significantly using protected and inheritanc=
e,=20
> but *not* polymorphism (ie: virtual function calls)? *And* that this code=
=20
> needs to use low-level layout-compatibility rules.
>

Here is the code for your last question only.

// These structures are only for testing purpose.
struct Base // Assuming it and BinaryDumperHost are both provided by a=20
library maker [NO.1]. Should not be available to clients.
{
friend class BinaryDumperHost; // This class is one that use Base to store=
=20
a serials of data, which is definded at else where.

private:
int val; // TODO: Should only be modified by BinaryDumperHost and the=20
inherited classes/structures from Base.

public:
int get_val(void) const { return(val); };

protected:
void set_val(int newVal) // Assuming it should only be called by either=20
inherited classes/structures or BinaryDumperHost.
{
val =3D min(newVal, 10); // Assuming we restrict the input, so the Extended=
=20
structures can't give val as they want.
};

Base(void): val() {}; // Private constructor. So the Base can only created=
=20
by either BinaryDumperHost or the extension.

private:
static void * operator new (size_t);
static void * operator new [] (size_t);
static void operator delete (void *);    // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
static void operator delete [] (void *); // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
};

// Assuming it is provided by another library maker [NO.2], which not just=
=20
have to follow
// the regulations defined by [No.1] but also have made extra regulations=
=20
itself. Finally it and Base will be
// proceed by BinaryDumperHost.
struct Pseudo_STD_Extended: Base // Should not be available to clients.
{
friend class BinaryDumperHost;

private:
int valExt1; // val1
int valExt2; // val2

public:
// int get_val1(void) const { return(valExt1); };
// int get_val2(void) const { return(valExt2); };

private:
void set_val(int newVal) // Assuming it should only be called by=20
BinaryDumperHost.
{
int _Fixed_Val;

// Generate _Fixed_Val here, which is based on the newVal and valExt1 and=
=20
valExt1.

Base::set_val(_Fixed_Val);
}

//void set_val1(int newVal); // Assuming it should only be called by=20
BinaryDumperHost.
//void set_val2(int newVal); // Assuming it should only be called by=20
BinaryDumperHost.

private:
Pseudo_STD_Extended(void) {}; // Call Base::Base(). Should only be=20
available to BinaryDumperHost but not clients.

private:
static void * operator new (size_t);
static void * operator new [] (size_t);
static void operator delete (void *);    // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
static void operator delete [] (void *); // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
};

struct STD_LY_Extended // Available for current C++ STD.
{
Base _base_vals; // Entry.

private:
int valExt1; // val1
int valExt2; // val2

public:
// int get_val1(void) const { return(valExt1); };
// int get_val2(void) const { return(valExt2); };

private:
//void set_val(int newVal);// I don't know how to make this simply.
void set_val(int newVal)// It shouldn't have been opened to clients.
{
//_base_vals.set_val(_Fixed_Val); // NO way to go.
};

private:
STD_Extended(void) {}; // Call Base::Base(). Should only be available to=20
BinaryDumperHost but not clients.

private:
static void * operator new (size_t);
static void * operator new [] (size_t);
static void operator delete (void *);    // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
static void operator delete [] (void *); // Raise compiling error if the=20
interitanced classes being deleted with a Base * pointer.
};

As a result the clients' code can only get access to BinaryDumperHost, and=
=20
these structures won't be usable to them(although they can still get access=
=20
to those which are handled by BinaryDumperHost).=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_2232_11958932.1367871739079
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=80UTC-4=E4=B8=8A=E5=8D=8811=E6=97=B623=E5=88=8645=E7=A7=92=EF=BC=8CNicol B=
olas=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><br><br>On Monday, May 6, 2013 8:03:43 AM UTC-7, <a>unituni...@gmail.com</=
a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>First of all, I think=
 it won't hurt almost every existing compilers. Actually it won't asking fo=
r any change of each one of them:</div><div>Say,</div><div>*1.</div><div>- =
If each of all the base classes of a class has only one base class, and eac=
h of all these classes neither contains any Virtual function nor Virtually =
inherited from the other class, The most inheritance will share the same ad=
dress of each bases.</div><div>*2.</div><div>- If a class has no virtual fu=
nctions, the first defined data member of will share the same address of th=
e class.</div></blockquote><div><br>The problem with this is <i>defining</i=
> what "the first defined data member" means. Do base classes come first or=
 last? Different compilers do it differently. That's why the current standa=
rd layout rules only work with base classes if at most one class in the hie=
rarchy has non-static data members.<br><br>There are compilers that put der=
ived classes first. And there are compilers that put derived classes last. =
So <i>someone</i> is going to have to change their compilers to comply with=
 whatever rule you eventually come up with.<br><br>And that's no good.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>*3(Optional).</div><d=
iv>- If a classe inherited from only one class, the two class will share th=
e same address.</div></blockquote><div><br>What do you mean by "share the s=
ame address"? What does this have to do with standard layout or layout comp=
atibility?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></=
div><div>I think the rule about the Standard-Layout is not much help for C+=
+ itself because if we need to extend a class by inheriting rather than def=
ind a data member to use its original protected member functions. If we nee=
d to apply the memory layout then it's a realy big lose if the data member =
definition is the only option: The access controls won't be easy, even the =
function can be mapped it is also slow for both compiling and running(cance=
led inlines) even with inline keyword.</div></blockquote><div><br>I'm sorry=
, but I don't understand your reasoning for this. Can you give an example o=
f code where you're significantly using protected and inheritance, but <i>n=
ot</i> polymorphism (ie: virtual function calls)? <i>And</i> that this code=
 needs to use low-level layout-compatibility rules.<br></div></blockquote><=
div><br></div><div>Here is the code for your last question only.</div><div>=
<br></div><div>// These structures are only for testing purpose.</div><div>=
struct Base // Assuming it and BinaryDumperHost are both provided by a libr=
ary maker [NO.1]. Should not be available to clients.</div><div>{</div><div=
><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>friend cl=
ass BinaryDumperHost; // This class is one that use Base to store a serials=
 of data, which is definded at else where.</div><div><br></div><div>private=
:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </spa=
n>int val; // TODO: Should only be modified by BinaryDumperHost and the inh=
erited classes/structures from Base.</div><div><br></div><div>public:</div>=
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int g=
et_val(void) const { return(val); };</div><div><br></div><div>protected:</d=
iv><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>vo=
id set_val(int newVal) // Assuming it should only be called by either inher=
ited classes/structures or BinaryDumperHost.</div><div><span class=3D"Apple=
-tab-span" style=3D"white-space:pre"> </span>{</div><div><span class=3D"App=
le-tab-span" style=3D"white-space:pre">  </span>val =3D min(newVal, 10); //=
 Assuming we restrict the input, so the Extended structures can't give val =
as they want.</div><div><span class=3D"Apple-tab-span" style=3D"white-space=
:pre"> </span>};</div><div><br></div><div><span class=3D"Apple-tab-span" st=
yle=3D"white-space:pre"> </span>Base(void): val() {}; // Private constructo=
r. So the Base can only created by either BinaryDumperHost or the extension=
..</div><div><br></div><div>private:</div><div><span class=3D"Apple-tab-span=
" style=3D"white-space:pre"> </span>static void * operator new (size_t);</d=
iv><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>st=
atic void * operator new [] (size_t);</div><div><span class=3D"Apple-tab-sp=
an" style=3D"white-space:pre"> </span>static void operator delete (void *);=
 &nbsp; &nbsp;// Raise compiling error if the interitanced classes being de=
leted with a Base * pointer.</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>static void operator delete [] (void *); // Ra=
ise compiling error if the interitanced classes being deleted with a Base *=
 pointer.</div><div>};</div><div><br></div><div>// Assuming it is provided =
by another library maker [NO.2], which not just have to follow</div><div>//=
 the regulations defined by [No.1] but also have made extra regulations its=
elf. Finally it and Base will be</div><div>// proceed by BinaryDumperHost.<=
/div><div>struct Pseudo_STD_Extended: Base // Should not be available to cl=
ients.</div><div>{</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre"> </span>friend class BinaryDumperHost;</div><div><br></div><div>=
private:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"=
> </span>int valExt1; // val1</div><div><span class=3D"Apple-tab-span" styl=
e=3D"white-space:pre"> </span>int valExt2; // val2</div><div><br></div><div=
>public:</div><div>//<span class=3D"Apple-tab-span" style=3D"white-space:pr=
e"> </span>int get_val1(void) const { return(valExt1); };</div><div>//<span=
 class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int get_val2(vo=
id) const { return(valExt2); };</div><div><br></div><div>private:</div><div=
><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>void set_=
val(int newVal) // Assuming it should only be called by BinaryDumperHost.</=
div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>{=
</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">  </spa=
n>int _Fixed_Val;</div><div><br></div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre">  </span>// Generate _Fixed_Val here, which is bas=
ed on the newVal and valExt1 and valExt1.</div><div><br></div><div><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre">  </span>Base::set_val(_Fi=
xed_Val);</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre=
"> </span>}</div><div><br></div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>//void set_val1(int newVal); // Assuming it sh=
ould only be called by BinaryDumperHost.</div><div><span class=3D"Apple-tab=
-span" style=3D"white-space:pre"> </span>//void set_val2(int newVal); // As=
suming it should only be called by BinaryDumperHost.</div><div><br></div><d=
iv>private:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:p=
re"> </span>Pseudo_STD_Extended(void) {}; // Call Base::Base(). Should only=
 be available to BinaryDumperHost but not clients.</div><div><br></div><div=
>private:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre=
"> </span>static void * operator new (size_t);</div><div><span class=3D"App=
le-tab-span" style=3D"white-space:pre"> </span>static void * operator new [=
] (size_t);</div><div><span class=3D"Apple-tab-span" style=3D"white-space:p=
re"> </span>static void operator delete (void *); &nbsp; &nbsp;// Raise com=
piling error if the interitanced classes being deleted with a Base * pointe=
r.</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>static void operator delete [] (void *); // Raise compiling error if the=
 interitanced classes being deleted with a Base * pointer.</div><div>};</di=
v><div><br></div><div>struct STD_LY_Extended // Available for current C++ S=
TD.</div><div>{</div><div><span class=3D"Apple-tab-span" style=3D"white-spa=
ce:pre"> </span>Base _base_vals; // Entry.</div><div><br></div><div>private=
:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </spa=
n>int valExt1; // val1</div><div><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>int valExt2; // val2</div><div><br></div><div>public=
:</div><div>//<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </s=
pan>int get_val1(void) const { return(valExt1); };</div><div>//<span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int get_val2(void) co=
nst { return(valExt2); };</div><div><br></div><div>private:</div><div><span=
 class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>//void set_val(=
int newVal);// I don't know how to make this simply.</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>void set_val(int newV=
al)// It shouldn't have been opened to clients.</div><div><span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre"> </span>{</div><div><span class=3D"=
Apple-tab-span" style=3D"white-space:pre">  </span>//_base_vals.set_val(_Fi=
xed_Val); // NO way to go.</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>};</div><div><br></div><div>private:</div><div=
><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>STD_Exten=
ded(void) {}; // Call Base::Base(). Should only be available to BinaryDumpe=
rHost but not clients.</div><div><br></div><div>private:</div><div><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>static void * oper=
ator new (size_t);</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre"> </span>static void * operator new [] (size_t);</div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>static void oper=
ator delete (void *); &nbsp; &nbsp;// Raise compiling error if the interita=
nced classes being deleted with a Base * pointer.</div><div><span class=3D"=
Apple-tab-span" style=3D"white-space:pre"> </span>static void operator dele=
te [] (void *); // Raise compiling error if the interitanced classes being =
deleted with a Base * pointer.</div><div>};</div><div><br></div><div>As a r=
esult the clients' code can only get access to BinaryDumperHost, and these =
structures won't be usable to them(although they can still get access to th=
ose which are handled by BinaryDumperHost).&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2232_11958932.1367871739079--

.

------=_Part_2312_31679333.1367873756206
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC-4=
=E4=B8=8B=E5=8D=881=E6=97=B622=E5=88=8658=E7=A7=92=EF=BC=8Cunituni...@gmail=
..com=E5=86=99=E9=81=93=EF=BC=9A
>
> The second line i should have posted:
> 2.
> - If a class has neither virtual functions nor base classes, the first=20
> defined data member of will share the same address of the class, no matte=
r=20
> that member is or isn't Standard-Layouted.
> struct Sealer // Without take virtual functions / base classes itself.
> {
>    SomeClass header_val;
>    int val1;
>    char val2;
>    Sealer(void);
> };
> Let us always get
>  reinterpret_cast<void *>(&Sealer) =3D=3D reinterpret_cast<void *>(&heade=
r_val)
> being true.
> =20
>
Revised again:
2.
- If a class has neither virtual functions nor base classes, the first=20
defined data member of will share the same address of the class, no matter=
=20
if that member is or isn't Standard-Layouted, as long as that class have=20
the same access control for all its data-members.

=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_2312_31679333.1367873756206
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=80UTC-4=E4=B8=8B=E5=8D=881=E6=97=B622=E5=88=8658=E7=A7=92=EF=BC=8Cunituni.=
...@gmail.com=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div>The second line i should have posted:<br>2.<br>- If a class h=
as neither virtual functions nor base classes, the first defined data membe=
r of will share the same address of the class, no matter that member is or =
isn't Standard-Layouted.</div><div>struct Sealer // Without take virtual fu=
nctions / base classes itself.<br>{<br>&nbsp;&nbsp; SomeClass header_val;<b=
r>&nbsp;&nbsp; int val1;<br>&nbsp;&nbsp; char val2;</div><div>&nbsp;&nbsp; =
Sealer(void);<br>};</div><div>Let us always get<br>&nbsp;reinterpret_cast&l=
t;void *&gt;(&amp;Sealer) =3D=3D reinterpret_cast&lt;void *&gt;(&amp;header=
_val)<br>being true.</div><div>&nbsp;</div></blockquote><div>Revised again:=
</div><div>2.<br>- If a class has neither virtual functions nor base classe=
s, the first defined data member of will share the same address of the clas=
s, no matter if that member is or isn't Standard-Layouted, as long as&nbsp;=
that class have the same access control for&nbsp;all its data-members.</div=
><div><br></div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2312_31679333.1367873756206--

.

------=_Part_2283_4416760.1367873766350
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC-4=
=E4=B8=8B=E5=8D=881=E6=97=B622=E5=88=8658=E7=A7=92=EF=BC=8Cunituni...@gmail=
..com=E5=86=99=E9=81=93=EF=BC=9A
>
> The second line i should have posted:
> 2.
> - If a class has neither virtual functions nor base classes, the first=20
> defined data member of will share the same address of the class, no matte=
r=20
> that member is or isn't Standard-Layouted.
> struct Sealer // Without take virtual functions / base classes itself.
> {
>    SomeClass header_val;
>    int val1;
>    char val2;
>    Sealer(void);
> };
> Let us always get
>  reinterpret_cast<void *>(&Sealer) =3D=3D reinterpret_cast<void *>(&heade=
r_val)
> being true.
> =20
>
Revised again:
2.
- If a class has neither virtual functions nor base classes, the first=20
defined data member of will share the same address of the class, no matter=
=20
if that member is or isn't Standard-Layouted, as long as that class have=20
the same access control for all its data-members.

=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_2283_4416760.1367873766350
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=80UTC-4=E4=B8=8B=E5=8D=881=E6=97=B622=E5=88=8658=E7=A7=92=EF=BC=8Cunituni.=
...@gmail.com=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div>The second line i should have posted:<br>2.<br>- If a class h=
as neither virtual functions nor base classes, the first defined data membe=
r of will share the same address of the class, no matter that member is or =
isn't Standard-Layouted.</div><div>struct Sealer // Without take virtual fu=
nctions / base classes itself.<br>{<br>&nbsp;&nbsp; SomeClass header_val;<b=
r>&nbsp;&nbsp; int val1;<br>&nbsp;&nbsp; char val2;</div><div>&nbsp;&nbsp; =
Sealer(void);<br>};</div><div>Let us always get<br>&nbsp;reinterpret_cast&l=
t;void *&gt;(&amp;Sealer) =3D=3D reinterpret_cast&lt;void *&gt;(&amp;header=
_val)<br>being true.</div><div>&nbsp;</div></blockquote><div>Revised again:=
</div><div>2.<br>- If a class has neither virtual functions nor base classe=
s, the first defined data member of will share the same address of the clas=
s, no matter if that member is or isn't Standard-Layouted, as long as&nbsp;=
that class have the same access control for&nbsp;all its data-members.</div=
><div><br></div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2283_4416760.1367873766350--

.

------=_Part_2549_24464166.1367899050478
Content-Type: text/plain; charset=ISO-8859-1

It sounds to me like your problem is that you're not using a proper
serialization library, and are instead relying on binary compatibility
between, well, whatever it is you're communicating across.

The point of standard layout was to standardize *existing* practice, to
relax the rules so that the implicit rules every compiler already used
would be standardized for any future compilers. There is no standard
existing practice for whether base class members come before a class's
members or after. So there can be no existing practice to standardize.

The point was *not* to enforce a specific layout on every type that doesn't
use virtual functions.

Also, it's not clear why you need to *enforce* that nobody can create a
`Base` object directly. Is there something wrong with creating a `Base` as
a standalone object? It's not like it has pure virtual functions or
something. So why do you need to syntactically forbid users from
constructing one?

Your class design is suspect, not the language.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2549_24464166.1367899050478
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It sounds to me like your problem is that you're not using a proper seriali=
zation library, and are instead relying on binary compatibility between, we=
ll, whatever it is you're communicating across.<br><br>The point of standar=
d layout was to standardize <i>existing</i> practice, to relax the rules so=
 that the implicit rules every compiler already used would be standardized =
for any future compilers. There is no standard existing practice for whethe=
r base class members=20
come before a class's members or after. So there can be no existing=20
practice to standardize.<br><br>The point was <i>not</i> to enforce a speci=
fic layout on every type that doesn't use virtual functions.<br><br>Also, i=
t's not clear why you need to <i>enforce</i> that nobody can create a `Base=
` object directly. Is there something wrong with creating a `Base` as a sta=
ndalone object? It's not like it has pure virtual functions or something. S=
o why do you need to syntactically forbid users from constructing one?<br><=
br>Your class design is suspect, not the language.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2549_24464166.1367899050478--

.

------=_Part_238_31487672.1367934079945
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC-4=
=E4=B8=8B=E5=8D=8811=E6=97=B657=E5=88=8630=E7=A7=92=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A
>
> It sounds to me like your problem is that you're not using a proper=20
> serialization library, and are instead relying on binary compatibility=20
> between, well, whatever it is you're communicating across.
>
> The point of standard layout was to standardize *existing* practice, to=
=20
> relax the rules so that the implicit rules every compiler already used=20
> would be standardized for any future compilers. There is no standard=20
> existing practice for whether base class members come before a class's=20
> members or after. So there can be no existing practice to standardize.
>
> The point was *not* to enforce a specific layout on every type that=20
> doesn't use virtual functions.
>
> Also, it's not clear why you need to *enforce* that nobody can create a=
=20
> `Base` object directly. Is there something wrong with creating a `Base` a=
s=20
> a standalone object? It's not like it has pure virtual functions or=20
> something. So why do you need to syntactically forbid users from=20
> constructing one?
>
> Your class design is suspect, not the language.
>

 what i have to remind is that
1. The inheritance and access control can be designed NOT JUST for=20
polymorphism usage.
2. In the real word there are still many things logically interrelated but=
=20
can't be as only one object. It can be several objects but can work only if=
=20
they are working together. You may ask 'why don't use a kind of aggregate=
=20
to build an object...'. Yes, they are logically interrelated but they are=
=20
also can't be just bind together with only one object. They are just parts=
=20
of missions, not for an object. The truth is that it is meaningless to let=
=20
one of them being used alone. Another fact is that something should be a=20
private used by a class but can't be defined within yet for some reason.=20
Say, for increasing the speed of compiling time and make the executing file=
=20
much smaller(which is no sense to a normal class but generally will be so=
=20
effective for template functions and classes). Another reason is=20
multithread programing. Generally a C++ class is for OOP designs which=20
means it should be comfortable to be put anywhere and behaves at any time=
=20
you like it to do, which should handle the resource of itself individual=20
and not rely on the current circumstance. But in the multi-thread=20
environment something should happen at special time and act as the designer=
=20
asked. In other time they can't be placed as clients pleases. You can't=20
seal all stuffs together. You can't ask your client too much about=20
autonomy, or why they use C++? The solution is disable anything you don't=
=20
want them to freely use.
  There is not necessary that if several things is related together then=20
they must be put together. If something is designed in the negative way it=
=20
won't mean to be bad. What a good design is is not decided by tradition but=
=20
the logical to match purpose.
  I think that's why it's so hard and complicated to handle multi-thread=20
programs in C++ (like the old time that simulating lambda with macros and=
=20
functor templates before the C++11 being out). The C++11 provided several=
=20
simple stuffs for that but they are still too simple and crude.
  I also think that it has been good things(and finally! thank god) the=20
C++11 accept lambda expression and variadic templates, but it's still not=
=20
good enough so far.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_238_31487672.1367934079945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=80UTC-4=E4=B8=8B=E5=8D=8811=E6=97=B657=E5=88=8630=E7=A7=92=EF=BC=8CNicol B=
olas=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>It sounds to me like your problem is that you're not using a proper serial=
ization library, and are instead relying on binary compatibility between, w=
ell, whatever it is you're communicating across.<br><br>The point of standa=
rd layout was to standardize <i>existing</i> practice, to relax the rules s=
o that the implicit rules every compiler already used would be standardized=
 for any future compilers. There is no standard existing practice for wheth=
er base class members=20
come before a class's members or after. So there can be no existing=20
practice to standardize.<br><br>The point was <i>not</i> to enforce a speci=
fic layout on every type that doesn't use virtual functions.<br><br>Also, i=
t's not clear why you need to <i>enforce</i> that nobody can create a `Base=
` object directly. Is there something wrong with creating a `Base` as a sta=
ndalone object? It's not like it has pure virtual functions or something. S=
o why do you need to syntactically forbid users from constructing one?<br><=
br>Your class design is suspect, not the language.<br></blockquote><div><br=
></div><div>&nbsp;what i have to remind is that</div><div>1. The inheritanc=
e and access control can be designed NOT JUST for polymorphism usage.</div>=
<div>2. In the real word there are still many things logically interrelated=
 but can't be as only one object. It can be several objects but can work on=
ly if they are working together. You may ask 'why don't use a kind of aggre=
gate to build an object...'. Yes, they are logically interrelated but they =
are also can't be just bind together with only one object. They are just pa=
rts of missions, not for an object. The truth is that it is meaningless to =
let one of them being used alone. Another fact is that something should be =
a private used by a class but can't be defined within yet for some reason. =
Say, for increasing the speed of compiling time and make the executing file=
 much smaller(which is no sense to a normal class but generally will be so =
effective for template functions and classes). Another reason is multithrea=
d programing. Generally a C++ class is for OOP designs which means it shoul=
d be comfortable to be put anywhere and behaves at any time you like it to =
do, which should handle the resource of itself individual and not rely on t=
he current circumstance. But in the multi-thread environment something shou=
ld happen at special time and act as the designer asked. In other time they=
 can't be placed as clients pleases. You can't seal all stuffs together. Yo=
u can't ask your client too much about autonomy, or why they use C++? The s=
olution is disable anything you don't want them to freely use.</div><div>&n=
bsp; There is not necessary that if several things is related together then=
 they must be put together. If something is designed in the negative way it=
 won't mean to be bad. What a good design is is not decided by tradition bu=
t the logical to match purpose.</div><div>&nbsp; I think that's why it's so=
 hard and complicated to handle multi-thread programs in C++ (like the old =
time that simulating lambda with macros and functor templates before the C+=
+11 being out). The C++11 provided several simple stuffs for that but they =
are still too simple and crude.</div><div>&nbsp; I also think that it has b=
een good things(and finally! thank god) the C++11 accept lambda expression =
and variadic templates, but it's still not good enough so far.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_238_31487672.1367934079945--

.

------=_Part_18_7302836.1367934706836
Content-Type: text/plain; charset=ISO-8859-1

3. Why ask for *1*2*3 ? The performance will keep high. To *1*3: If the
inherited classes does not start from the address of the whole object what
will happen -- when conversion happened the pointer to object will do
increasing or decreasing if the base classes not share the same address to
the whole object. Even if it's no big deal with you then you still need to
concern about this: If it's necessary to check the pointer to object to see
being nullptr or not, but the pointer is provided by a
pointer-to-base-class, you have to do check only with the type of the
initial pointer, then implement a serials of conversions even in singleton
inheritance design. It's much wrose than good...
The multi-inheritances and virtual-inheritances always moves the pointers
is only because the compiler makers have no other choice. To *2: I don't
think any additional magic is need so that you have to break it. More, If
the address of the bases are not the same to the inherited, to make sure
the certain memory image the only choice is to use the standard-layouted
structures, one nested in another. the access through member functions
won't be efficient, to both pointer shifts and function calls(rather than
call the member functions with the this pointer directly, we have to call
functions one nested another and shift object pointer step by step). It's
not good, no matter the compiling time, the runtime efficiency, the size of
executable binaries.

  You talked about the problem of design. As the demo i provided before If
a structure is designed for data storage then why i have to use a virtual
things? I don't needed, even i shouldn't. Why i have to go the way back of
what i plan to do? If the C-Style is the only better choice then the C++
access control is useless here.

  You said that "to relax the rules so that the implicit rules every
compiler already used would be standardized for any future compilers. There
is no standard existing practice for whether base class members come before
a class's members or after. So there can be no existing practice to
standardize."
First: As i know at leaset the Clang\MSVC\gcc all doesn't need extra
modification to support these 3 points of mine.
Second: 'no' doesn't realy means No but that no one can take that risk to
rely on something not being sure. And no one seems noticed about that it
may become a real problem someday.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_18_7302836.1367934706836
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>3. Why ask for *1*2*3 ? The performance will keep high. To *1*3: If th=
e inherited classes does not start from the address of the whole object wha=
t will happen -- when conversion happened the pointer to object will do inc=
reasing or decreasing if the base classes not share the same address to the=
 whole object. Even if it's no big deal with you then you still need to con=
cern about this: If it's necessary to check the pointer to object to see be=
ing nullptr or not, but the pointer is provided by a pointer-to-base-class,=
 you have to do check only with the type of the initial pointer, then imple=
ment a serials of conversions even in singleton inheritance design. It's mu=
ch wrose than good...</div><div>The multi-inheritances and virtual-inherita=
nces always moves the pointers is only because the compiler makers have no =
other choice. To *2: I don't think any additional magic is need so that you=
 have to break it. More, If the address of the bases are not the same to th=
e inherited, to make sure the certain memory image the only choice is to us=
e the standard-layouted structures, one nested in another. the access throu=
gh member functions won't be efficient, to both pointer shifts and function=
 calls(rather than call the member functions with the this pointer directly=
, we have to call functions one nested another and shift object pointer ste=
p by step). It's not good, no matter the compiling time, the runtime effici=
ency, the size of executable binaries.</div><div><br></div><div>&nbsp; You =
talked about the problem of design. As the demo i provided before If a stru=
cture is designed for data storage then why i have to use a virtual things?=
 I don't needed, even i shouldn't. Why i have to go the way back of what i =
plan to do? If the C-Style is the only better choice then the C++ access co=
ntrol is useless here.</div><div><br></div><div>&nbsp; You said that "to re=
lax the rules so that the implicit rules every compiler already used would =
be standardized for any future compilers. There is no standard existing pra=
ctice for whether base class members come before a class's members or after=
.. So there can be no existing practice to standardize."</div><div>First: As=
 i know at leaset the Clang\MSVC\gcc all doesn't need extra modification to=
 support these 3 points of mine.</div><div>Second: 'no' doesn't realy means=
 No but that no one can take that risk to rely on something not being sure.=
 And no one seems noticed about that it may become a real problem someday.<=
/div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_18_7302836.1367934706836--

.

------=_Part_46_27822518.1367943426247
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 7, 2013 6:41:19 AM UTC-7, unituni...@gmail.com wrote:
>
> =E5=9C=A8 2013=E5=B9=B45=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC=
-4=E4=B8=8B=E5=8D=8811=E6=97=B657=E5=88=8630=E7=A7=92=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A
>>
>> It sounds to me like your problem is that you're not using a proper=20
>> serialization library, and are instead relying on binary compatibility=
=20
>> between, well, whatever it is you're communicating across.
>>
>> The point of standard layout was to standardize *existing* practice, to=
=20
>> relax the rules so that the implicit rules every compiler already used=
=20
>> would be standardized for any future compilers. There is no standard=20
>> existing practice for whether base class members come before a class's=
=20
>> members or after. So there can be no existing practice to standardize.
>>
>> The point was *not* to enforce a specific layout on every type that=20
>> doesn't use virtual functions.
>>
>> Also, it's not clear why you need to *enforce* that nobody can create a=
=20
>> `Base` object directly. Is there something wrong with creating a `Base` =
as=20
>> a standalone object? It's not like it has pure virtual functions or=20
>> something. So why do you need to syntactically forbid users from=20
>> constructing one?
>>
>> Your class design is suspect, not the language.
>>
>
>  what i have to remind is that
> 1. The inheritance and access control can be designed NOT JUST for=20
> polymorphism usage.
>

Access controls, yes. Public inheritance? No.

Besides the convenience feature of being able to use the same public or=20
protected interfaces in derived classes, what *good* does inheritance get=
=20
you over aggregation?

2. In the real word there are still many things logically interrelated but=
=20
> can't be as only one object. It can be several objects but can work only =
if=20
> they are working together. You may ask 'why don't use a kind of aggregate=
=20
> to build an object...'. Yes, they are logically interrelated but they are=
=20
> also can't be just bind together with only one object. They are just part=
s=20
> of missions, not for an object. The truth is that it is meaningless to le=
t=20
> one of them being used alone.
>

You seem to be stating a contradiction. If you have two objects that can=20
only be used with each other, then you do not have two objects. What you=20
really have is *one* object, which contains other objects. The existence of=
=20
those other objects is not something that the outside world needs to know=
=20
about. It's an implementation detail, not a part of the interface.

Another fact is that something should be a private used by a class but=20
> can't be defined within yet for some reason. Say, for increasing the spee=
d=20
> of compiling time and make the executing file much smaller(which is no=20
> sense to a normal class but generally will be so effective for template=
=20
> functions and classes).
>

That's a solved problem: Pimpl. It involves creating an internal object=20
that the outside world neither knows nor cares about.

On Tuesday, May 7, 2013 6:51:46 AM UTC-7, unituni...@gmail.com wrote:
>
> 3. Why ask for *1*2*3 ? The performance will keep high. To *1*3: If the=
=20
> inherited classes does not start from the address of the whole object wha=
t=20
> will happen -- when conversion happened the pointer to object will do=20
> increasing or decreasing if the base classes not share the same address t=
o=20
> the whole object.
>
Even if it's no big deal with you then you still need to concern about=20
> this: If it's necessary to check the pointer to object to see being nullp=
tr=20
> or not, but the pointer is provided by a pointer-to-base-class, you have =
to=20
> do check only with the type of the initial pointer, then implement a=20
> serials of conversions even in singleton inheritance design. It's much=20
> wrose than good...
>

That's for compiler writers to decide, not for the standard. The standard=
=20
should allow compiler makers to implement it as they see fit.

The multi-inheritances and virtual-inheritances always moves the pointers=
=20
> is only because the compiler makers have no other choice. To *2: I don't=
=20
> think any additional magic is need so that you have to break it. More, If=
=20
> the address of the bases are not the same to the inherited, to make sure=
=20
> the certain memory image the only choice is to use the standard-layouted=
=20
> structures, one nested in another. the access through member functions=20
> won't be efficient, to both pointer shifts and function calls(rather than=
=20
> call the member functions with the this pointer directly, we have to call=
=20
> functions one nested another and shift object pointer step by step). It's=
=20
> not good, no matter the compiling time, the runtime efficiency, the size =
of=20
> executable binaries.
>

Are you an expert in writing compilers for various CPUs?

One reason to put base classes last instead of first is because of=20
offsetting. If you're in a member function of a type, you will generally do=
=20
two things with `this`: access a direct member variable, or access a=20
base-class member variable/function. Accessing a direct member variable=20
requires offsetting the `this` pointer and then dereferencing that memory.=
=20
Accessing the base class member/function requires offsetting `this` as well=
..

The problem is this. Some CPUs have special opcodes that can offset a=20
register by a constant that's built into the opcode itself. However, the=20
size of those offsets can be quite limited in some cases, so you can only=
=20
do it for, let's say, a 6-bit value. 6 bits being at most 64 bytes. So if=
=20
the offset you use is going to be less than 64, then you only need one=20
opcode to offset it. But if it's more, then you need two: load a constant=
=20
into a register (this opcode allows larger offsets), followed by adding two=
=20
registers together.

If the base class(es) is 128 bytes in size, and the base class comes first,=
=20
then every access to direct data members will require two opcodes. But if=
=20
the base class comes last, then all direct data members can be accessed=20
with just one opcode. And, generally speaking, a member function is more=20
likely to access the direct members of a class than any base class members.

So putting the base class first is more efficient in common cases.

This is why the standard allows the compiler leeway on how things are=20
implemented. For *you* and your needs, the "compiling time, the runtime=20
efficiency, the size of executable binaries" may not matter. But for=20
someone else it will. Why are your needs more important than theirs?

  You talked about the problem of design. As the demo i provided before If=
=20
> a structure is designed for data storage then why i have to use a virtual=
=20
> things? I don't needed, even i shouldn't. Why i have to go the way back o=
f=20
> what i plan to do? If the C-Style is the only better choice then the C++=
=20
> access control is useless here.
>

A "better choice" would be to use a decent design; what you did was not=20
good design. And a "better choice" would also be to use a *real*serializati=
on library, not relying on object layout to serialize data.=20
Going to "C-Style" is not the only option here; simply using a design that=
=20
isn't terrible would be an improvement.

The demo you provided is code that should *fail* code review. We should not=
=20
add stuff to the language for the sole purpose of supporting terrible code.

  You said that "to relax the rules so that the implicit rules every=20
> compiler already used would be standardized for any future compilers. The=
re=20
> is no standard existing practice for whether base class members come befo=
re=20
> a class's members or after. So there can be no existing practice to=20
> standardize."
> First: As i know at leaset the Clang\MSVC\gcc all doesn't need extra=20
> modification to support these 3 points of mine.
>

That's wonderful. But there are other compilers besides Clang/MSVC/gcc. Who=
=20
are you to force these compilers into making *breaking* changes?

Also, this is generally dictated by the ABI that the compiler is compiling=
=20
to, so GCC can compile to other ABIs that use a different arrangement.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_46_27822518.1367943426247
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 7, 2013 6:41:19 AM UTC-7, unituni...@gmail.com wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">=E5=9C=A8 2013=E5=B9=B45=E6=9C=886=
=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80UTC-4=E4=B8=8B=E5=8D=8811=E6=97=B657=E5=
=88=8630=E7=A7=92=EF=BC=8C<wbr>Nicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">It sounds to me like your problem is that=
 you're not using a proper serialization library, and are instead relying o=
n binary compatibility between, well, whatever it is you're communicating a=
cross.<br><br>The point of standard layout was to standardize <i>existing</=
i> practice, to relax the rules so that the implicit rules every compiler a=
lready used would be standardized for any future compilers. There is no sta=
ndard existing practice for whether base class members=20
come before a class's members or after. So there can be no existing=20
practice to standardize.<br><br>The point was <i>not</i> to enforce a speci=
fic layout on every type that doesn't use virtual functions.<br><br>Also, i=
t's not clear why you need to <i>enforce</i> that nobody can create a `Base=
` object directly. Is there something wrong with creating a `Base` as a sta=
ndalone object? It's not like it has pure virtual functions or something. S=
o why do you need to syntactically forbid users from constructing one?<br><=
br>Your class design is suspect, not the language.<br></blockquote><div><br=
></div><div>&nbsp;what i have to remind is that</div><div>1. The inheritanc=
e and access control can be designed NOT JUST for polymorphism usage.</div>=
</blockquote><div><br>Access controls, yes. Public inheritance? No.<br><br>=
Besides the convenience feature of being able to use the same public or pro=
tected interfaces in derived classes, what <i>good</i> does inheritance get=
 you over aggregation?<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div>2. In the real word there are still many things logically interr=
elated but can't be as only one object. It can be several objects but can w=
ork only if they are working together. You may ask 'why don't use a kind of=
 aggregate to build an object...'. Yes, they are logically interrelated but=
 they are also can't be just bind together with only one object. They are j=
ust parts of missions, not for an object. The truth is that it is meaningle=
ss to let one of them being used alone.</div></blockquote><div><br>You seem=
 to be stating a contradiction. If you have two objects that can only be us=
ed with each other, then you do not have two objects. What you really have =
is <i>one</i> object, which contains other objects. The existence of those =
other objects is not something that the outside world needs to know about. =
It's an implementation detail, not a part of the interface.<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div>Another fact is that someth=
ing should be a private used by a class but can't be defined within yet for=
 some reason. Say, for increasing the speed of compiling time and make the =
executing file much smaller(which is no sense to a normal class but general=
ly will be so effective for template functions and classes).</div></blockqu=
ote><div><br>That's a solved problem: Pimpl. It involves creating an intern=
al object that the outside world neither knows nor cares about.<br><br>On T=
uesday, May 7, 2013 6:51:46 AM UTC-7, unituni...@gmail.com wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div>3.
 Why ask for *1*2*3 ? The performance will keep high. To *1*3: If the=20
inherited classes does not start from the address of the whole object=20
what will happen -- when conversion happened the pointer to object will=20
do increasing or decreasing if the base classes not share the same=20
address to the whole object.</div></blockquote><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div>Even if it's no big deal with you then you=20
still need to concern about this: If it's necessary to check the pointer
 to object to see being nullptr or not, but the pointer is provided by a
 pointer-to-base-class, you have to do check only with the type of the=20
initial pointer, then implement a serials of conversions even in=20
singleton inheritance design. It's much wrose than good...</div></blockquot=
e><div><br>That's for compiler writers to decide, not for the standard. The=
 standard should allow compiler makers to implement it as they see fit.<br>=
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div>The
 multi-inheritances and virtual-inheritances always moves the pointers=20
is only because the compiler makers have no other choice. To *2: I don't
 think any additional magic is need so that you have to break it. More,=20
If the address of the bases are not the same to the inherited, to make=20
sure the certain memory image the only choice is to use the=20
standard-layouted structures, one nested in another. the access through=20
member functions won't be efficient, to both pointer shifts and function
 calls(rather than call the member functions with the this pointer=20
directly, we have to call functions one nested another and shift object=20
pointer step by step). It's not good, no matter the compiling time, the=20
runtime efficiency, the size of executable binaries.</div></blockquote><div=
><br>Are you an expert in writing compilers for various CPUs?<br><br>One re=
ason to put base classes last instead of first is because of offsetting. If=
 you're in a member function of a type, you will generally do two things wi=
th `this`: access a direct member variable, or access a base-class member v=
ariable/function. Accessing a direct member variable requires offsetting th=
e `this` pointer and then dereferencing that memory. Accessing the base cla=
ss member/function requires offsetting `this` as well.<br><br>The problem i=
s this. Some CPUs have special opcodes that can offset a register by a cons=
tant that's built into the opcode itself. However, the size of those offset=
s can be quite limited in some cases, so you can only do it for, let's say,=
 a 6-bit value. 6 bits being at most 64 bytes. So if the offset you use is =
going to be less than 64, then you only need one opcode to offset it. But i=
f it's more, then you need two: load a constant into a register (this opcod=
e allows larger offsets), followed by adding two registers together.<br><br=
>If the base class(es) is 128 bytes in size, and the base class comes first=
, then every access to direct data members will require two opcodes. But if=
 the base class comes last, then all direct data members can be accessed wi=
th just one opcode. And, generally speaking, a member function is more like=
ly to access the direct members of a class than any base class members.<br>=
<br>So putting the base class first is more efficient in common cases.<br><=
br>This is why the standard allows the compiler leeway on how things are im=
plemented. For <i>you</i> and your needs, the "compiling time, the=20
runtime efficiency, the size of executable binaries" may not matter. But fo=
r someone else it will. Why are your needs more important than theirs?<br><=
/div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>&nbsp;
 You talked about the problem of design. As the demo i provided before=20
If a structure is designed for data storage then why i have to use a=20
virtual things? I don't needed, even i shouldn't. Why i have to go the=20
way back of what i plan to do? If the C-Style is the only better choice=20
then the C++ access control is useless here.</div></blockquote><div><br>A "=
better choice" would be to use a decent design; what you did was not good d=
esign. And a "better choice" would also be to use a <i>real</i> serializati=
on library, not relying on object layout to serialize data. Going to "C-Sty=
le" is not the only option here; simply using a design that isn't terrible =
would be an improvement.<br><br>The demo you provided is code that should <=
i>fail</i> code review. We should not add stuff to the language for the sol=
e purpose of supporting terrible code.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div>&nbsp;=20
You said that "to relax the rules so that the implicit rules every=20
compiler already used would be standardized for any future compilers.=20
There is no standard existing practice for whether base class members=20
come before a class's members or after. So there can be no existing=20
practice to standardize."</div><div>First: As i know at leaset the Clang\MS=
VC\gcc all doesn't need extra modification to support these 3 points of min=
e.</div></blockquote><div><br>That's wonderful. But there are other compile=
rs besides Clang/MSVC/gcc. Who are you to force these compilers into making=
 <i>breaking</i> changes?<br><br>Also, this is generally dictated by the AB=
I that the compiler is compiling to, so GCC can compile to other ABIs that =
use a different arrangement.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_46_27822518.1367943426247--

.