--047d7b33d31c39d1a504dc131ff2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6 May 2013 23:56, <unituniverse.1@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=881=E6=97=B622=E5=88=8658=E7=A7=92=EF=BC=8Cunituni...@gma=
il.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
>> defined data member of will share the same address of the class, no matt=
er
>> 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.
>>
>>
> Revised again:
> 2.
>
> - If a class has neither virtual functions nor base classes, the first
> defined data member of will share the same address of the class, no matte=
r
> if that member is or isn't Standard-Layouted, as long as that class have
> the same access control for all its data-members.
>
>
>
>
Perhaps you should take a look at
http://open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1425

--=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.



--047d7b33d31c39d1a504dc131ff2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 6 May 2013 23:56,  <span dir=3D"ltr">&lt;<a href=3D"mailto:unitu=
niverse.1@gmail.com" target=3D"_blank">unituniverse.1@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><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=8C<a href=3D"mailto:unituni...@gm=
ail.com" target=3D"_blank">unituni...@gmail.com</a>=E5=86=99=E9=81=93=EF=BC=
=9A<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div>The second line i sh=
ould have posted:<br>2.<br>- If a class has neither virtual functions nor b=
ase classes, the first defined data member of will share the same address o=
f the class, no matter that member is or isn&#39;t Standard-Layouted.</div>
<div>struct Sealer // Without take virtual functions / base classes itself.=
<br>{<br>=C2=A0=C2=A0 SomeClass header_val;<br>=C2=A0=C2=A0 int val1;<br>=
=C2=A0=C2=A0 char val2;</div><div>=C2=A0=C2=A0 Sealer(void);<br>};</div><di=
v>Let us always get<br>=C2=A0reinterpret_cast&lt;void *&gt;(&amp;Sealer) =
=3D=3D reinterpret_cast&lt;void *&gt;(&amp;header_val)<br>
being true.</div><div>=C2=A0</div></blockquote></div><div>Revised again:</d=
iv><div>2.<div class=3D"im"><br>- If a class has neither virtual functions =
nor base classes, the first defined data member of will share the same addr=
ess of the class, no matter if that member is or isn&#39;t Standard-Layoute=
d, as long as=C2=A0that class have the same access control for=C2=A0all its=
 data-members.</div>
</div><div><br></div><div><br><br></div></blockquote><div><br></div><div>Pe=
rhaps you should take a look at <a href=3D"http://open-std.org/JTC1/SC22/WG=
21/docs/cwg_active.html#1425">http://open-std.org/JTC1/SC22/WG21/docs/cwg_a=
ctive.html#1425</a> <br>
</div></div><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 />

--047d7b33d31c39d1a504dc131ff2--

.

------=_Part_2386_17489051.1367878347425
Content-Type: text/plain; charset=ISO-8859-1

Perhaps you should take a look at
http://open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1425

Thanks,  Ville Voutilainen :)

--

---
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_2386_17489051.1367878347425
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Perhaps you should take a look at <a href=3D"http://open-std.org/JTC1/SC22/=
WG21/docs/cwg_active.html#1425" target=3D"_blank">http://open-std.org/JTC1/=
SC22/<wbr>WG21/docs/cwg_active.html#1425</a>&nbsp;<div><br></div><div>Thank=
s,&nbsp;<span style=3D"color: rgb(136, 136, 136); line-height: 19.5px;">&nb=
sp;</span><span role=3D"gridcell" style=3D"color: rgb(136, 136, 136); line-=
height: 19.5px;"><span class=3D"_username"><span class=3D"GHSP2CYBOHB" styl=
e=3D"color: rgb(34, 34, 34);">Ville Voutilainen :)</span></span></span></di=
v>

<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_2386_17489051.1367878347425--

.

--047d7b2e0887d7582d04dc240bda
Content-Type: text/plain; charset=ISO-8859-1

On 7 May 2013 19:17, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>  what i have to remind is that
>> 1. The inheritance and access control can be designed NOT JUST for
>> polymorphism usage.
>>
>
> Access controls, yes. Public inheritance? No.
>

What? Public inheritance doesn't strictly equal polymorphism, never has,
never will.


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

Effortless conversion to the base type, which is highly useful with
construction veneers and other things that
exist solely to initialize a wrapped base type and then convert to it.

Regarding the pointer-shift-step-by-step, I suggest unituniverse to check
how it's actually done.

When you have learned how implementations actually work, considered the
open core issue that I mentioned,
and learned about the actual considerations leading to the lax layout
rules, perhaps then it's time to write
a proposal. I don't think we're even close to that point yet.

--

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



--047d7b2e0887d7582d04dc240bda
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 May 2013 19:17, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div>=A0what i have to remind is that</div><div>1. The inheritance and acce=
ss control can be designed NOT JUST for polymorphism usage.</div></blockquo=
te></div><div><br>Access controls, yes. Public inheritance? No.<br></div>
</blockquote><div><br></div><div>What? Public inheritance doesn&#39;t stric=
tly equal polymorphism, never has, never will. <br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div><br>Besides the convenience feature of being able to use the same publ=
ic or protected interfaces in derived classes, what <i>good</i> does inheri=
tance get you over aggregation?<br></div></blockquote><div><br></div><div>
Effortless conversion to the base type, which is highly useful with constru=
ction veneers and other things that<br></div><div>exist solely to initializ=
e a wrapped base type and then convert to it.<br><br></div><div>Regarding t=
he pointer-shift-step-by-step, I suggest unituniverse to check how it&#39;s=
 actually done.<br>
<br></div><div>When you have learned how implementations actually work, con=
sidered the open core issue that I mentioned,<br>and learned about the actu=
al considerations leading to the lax layout rules, perhaps then it&#39;s ti=
me to write<br>
a proposal. I don&#39;t think we&#39;re even close to that point yet.<br></=
div><div><br></div></div><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 />

--047d7b2e0887d7582d04dc240bda--

.

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



=E5=9C=A8 2013=E5=B9=B45=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8CUTC-4=
=E4=B8=8B=E5=8D=881=E6=97=B621=E5=88=8622=E7=A7=92=EF=BC=8CVille Voutilaine=
n=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
>
> On 7 May 2013 19:17, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>>
>>  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.
>>
>
> What? Public inheritance doesn't strictly equal polymorphism, never has,=
=20
> never will.=20
>
>
>> Besides the convenience feature of being able to use the same public or=
=20
>> protected interfaces in derived classes, what *good* does inheritance=20
>> get you over aggregation?
>>
>
> Effortless conversion to the base type, which is highly useful with=20
> construction veneers and other things that
> exist solely to initialize a wrapped base type and then convert to it.
>
> Regarding the pointer-shift-step-by-step, I suggest unituniverse to check=
=20
> how it's actually done.
>
> When you have learned how implementations actually work, considered the=
=20
> open core issue that I mentioned,
> and learned about the actual considerations leading to the lax layout=20
> rules, perhaps then it's time to write
> a proposal. I don't think we're even close to that point yet.
>
>
>
yes it's complicated and i can't provide anything valuable for now.

--=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_1190_12984680.1367948471770
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>=E5=9C=A8 2013=E5=B9=B45=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=
=8CUTC-4=E4=B8=8B=E5=8D=881=E6=97=B621=E5=88=8622=E7=A7=92=EF=BC=8CVille Vo=
utilainen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 7 May=
 2013 19:17, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"PzMTe3-7SCMJ">jmck...@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div>&nbsp;what i have to remind is that</div><div>1. The inheritance and a=
ccess control can be designed NOT JUST for polymorphism usage.</div></block=
quote></div><div><br>Access controls, yes. Public inheritance? No.<br></div=
>
</blockquote><div><br></div><div>What? Public inheritance doesn't strictly =
equal polymorphism, never has, never will. <br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div><br>Besides the convenience feature of being able to use the same publ=
ic or protected interfaces in derived classes, what <i>good</i> does inheri=
tance get you over aggregation?<br></div></blockquote><div><br></div><div>
Effortless conversion to the base type, which is highly useful with constru=
ction veneers and other things that<br></div><div>exist solely to initializ=
e a wrapped base type and then convert to it.<br><br></div><div>Regarding t=
he pointer-shift-step-by-step, I suggest unituniverse to check how it's act=
ually done.<br>
<br></div><div>When you have learned how implementations actually work, con=
sidered the open core issue that I mentioned,<br>and learned about the actu=
al considerations leading to the lax layout rules, perhaps then it's time t=
o write<br>
a proposal. I don't think we're even close to that point yet.<br></div><div=
><br></div></div><br></div></div></blockquote><div><br></div><div>yes it's =
complicated and i can't provide anything valuable for now.</div><div><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_1190_12984680.1367948471770--

.

------=_Part_3309_23192687.1367951437187
Content-Type: text/plain; charset=ISO-8859-1

I don't think the serialization isn't fit for everywhere especially for
writing container or binary operatings(like encoders/decoders) in memory.
There are many extra operatings evolved in.

What's about the this pointer of the whole (not one in any base class(es))
object? The binary value of it may not be equal to the actual entry address
of the object??

--

---
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_3309_23192687.1367951437187
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I don't think the serialization isn't fit for everywhere especially fo=
r writing container or binary operatings(like encoders/decoders) in memory.=
 There are many extra operatings evolved in.</div><div><br></div><div>What'=
s about the this pointer of the whole (not one in any base class(es)) objec=
t? The binary value of it may not be equal to the actual entry address of t=
he object??</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_3309_23192687.1367951437187--

.

------=_Part_3004_12597791.1367951479741
Content-Type: text/plain; charset=ISO-8859-1

I don't think the serialization being fit for everywhere especially for
writing container or binary operatings(like encoders/decoders) in memory.
There are many extra operatings evolved in.

What's about the this pointer of the whole (not one in any base class(es))
object? The binary value of it may not be equal to the actual entry address
of the object??

--

---
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_3004_12597791.1367951479741
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I don't think the serialization being fit for everywhere especially fo=
r writing container or binary operatings(like encoders/decoders) in memory.=
 There are many extra operatings evolved in.</div><div><br></div><div>What'=
s about the this pointer of the whole (not one in any base class(es)) objec=
t? The binary value of it may not be equal to the actual entry address of t=
he object??</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_3004_12597791.1367951479741--

.

------=_Part_3069_31412771.1367951660852
Content-Type: text/plain; charset=ISO-8859-1

I don't think the serialization being fit for everywhere especially for
writing container or binary operatings(like encoders/decoders) in memory.
There are many extra operatings evolved in.

What's about the this pointer of the whole (not one in any base class(es))
object? The binary value of it will always be equal to the actual entry
address of the object?? If so the second point may still make sense.

--

---
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_3069_31412771.1367951660852
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I don't think the serialization being fit for everywhere especially fo=
r writing container or binary operatings(like encoders/decoders) in memory.=
 There are many extra operatings evolved in.</div><div><br></div><div>What'=
s about the this pointer of the whole (not one in any base class(es)) objec=
t? The binary value of it will always be equal to the actual entry address =
of the object?? If so the second point may still make sense.</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_3069_31412771.1367951660852--

.

------=_Part_3677_29170277.1367984631224
Content-Type: text/plain; charset=ISO-8859-1

I don't think the serialization being fit for everywhere especially for
writing container or binary operatings(like encoders/decoders) in memory.
There are many extra operatings evolved in.

What's about the this pointer of the whole (not one in any base class(es))
object? The binary value of it will always be equal to the actual entry
address of the object?? If so the second point may still make sense:

"If a class has neither virtual member functions nor base classes, the
first defined data member of will share the same address of the class, no
matter 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's always get
 reinterpret_cast<void *>(&Sealer) == reinterpret_cast<void *>(&header_val)
as true.

--

---
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_3677_29170277.1367984631224
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I don't think the serialization being fit for everywhere especially fo=
r writing container or binary operatings(like encoders/decoders) in memory.=
 There are many extra operatings evolved in.</div><div><br></div><div>What'=
s about the this pointer of the whole (not one in any base class(es)) objec=
t? The binary value of it will always be equal to the actual entry address =
of the object?? If so the second point may still make sense:</div><div><br>=
</div><div>"If a class has neither virtual member functions&nbsp;<font colo=
r=3D"#cc0000">nor base classes</font>, the first defined data member of wil=
l share the same address of the class, no matter that member is or isn't St=
andard-Layouted."</div><div><br></div><div><div><font color=3D"#0000ff">str=
uct</font>&nbsp;<font color=3D"#3d85c6">Sealer</font>&nbsp;<font color=3D"#=
38761d">// Without take virtual functions / base classes itself.</font><br>=
{<br>&nbsp;&nbsp;&nbsp;<font color=3D"#3d85c6">SomeClass</font>&nbsp;<font =
color=3D"#000000">header_val</font>;<br>&nbsp;&nbsp;&nbsp;<font color=3D"#0=
000ff">int</font>&nbsp;val1;<br>&nbsp;&nbsp;&nbsp;<font color=3D"#0000ff">c=
har</font>&nbsp;val2;</div><div>&nbsp;&nbsp; Sealer(<font color=3D"#3d85c6"=
>void</font>);<br>};</div></div><div><br></div><div>Let's always get<br>&nb=
sp;reinterpret_cast&lt;void *&gt;(&amp;Sealer) =3D=3D reinterpret_cast&lt;v=
oid *&gt;(&amp;header_val)<br>as true.</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_3677_29170277.1367984631224--

.

------=_Part_2080_32918880.1367986424521
Content-Type: text/plain; charset=ISO-8859-1

First, please stop deleting posts. You're making it very confusing to read
the thread or respond to anything. If you're frequently having to correct
posts, then stop posting so fast. Slow down, proofread, wait a bit, and
then post.

If what you're trying to say is important, then it's important enough for
you to take time to say it. If you make a mistake, write a new post
explaining the error. Don't just delete it and start over.

On Tuesday, May 7, 2013 8:43:51 PM UTC-7, unituni...@gmail.com wrote:
>
> I don't think the serialization being fit for everywhere especially for
> writing container or binary operatings(like encoders/decoders) in memory.
> There are many extra operatings evolved in.
>

I've never seen an "encoder/decoder" that absolutely *needed* to use
inheritance instead of containment. Generally speaking, such low-level code
would work just fine with containment relationships.

Containment is not "C-Style" and inheritance is not "C++-Style". Both of
these are useful techniques in C++; they both have costs, and it's up to
you to weigh those costs when coming up with your design.

What's about the this pointer of the whole (not one in any base class(es))
> object? The binary value of it will always be equal to the actual entry
> address of the object?? If so the second point may still make sense:
>
> "If a class has neither virtual member functions nor base classes, the
> first defined data member of will share the same address of the class, no
> matter 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's always get
>  reinterpret_cast<void *>(&Sealer) == reinterpret_cast<void *>(&header_val)
> as true.
>

Why does this need to be a rule? That's the part you haven't explained.
What operations do you *need* to do that requires this equality?

--

---
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_2080_32918880.1367986424521
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

First, please stop deleting posts. You're making it very confusing to read =
the thread or respond to anything. If you're frequently having to correct p=
osts, then stop posting so fast. Slow down, proofread, wait a bit, and then=
 post.<br><br>If what you're trying to say is important, then it's importan=
t enough for you to take time to say it. If you make a mistake, write a new=
 post explaining the error. Don't just delete it and start over.<br><br>On =
Tuesday, May 7, 2013 8:43:51 PM UTC-7, unituni...@gmail.com wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div>I don't think the serialization be=
ing fit for everywhere especially for writing container or binary operating=
s(like encoders/decoders) in memory. There are many extra operatings evolve=
d in.</div></blockquote><div><br>I've never seen an "encoder/decoder" that =
absolutely <i>needed</i> to use inheritance instead of containment. General=
ly speaking, such low-level code would work just fine with containment rela=
tionships.<br><br>Containment is not "C-Style" and inheritance is not "C++-=
Style". Both of these are useful techniques in C++; they both have costs, a=
nd it's up to you to weigh those costs when coming up with your design.<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>What's about th=
e this pointer of the whole (not one in any base class(es)) object? The bin=
ary value of it will always be equal to the actual entry address of the obj=
ect?? If so the second point may still make sense:</div><div><br></div><div=
>"If a class has neither virtual member functions&nbsp;<font color=3D"#cc00=
00">nor base classes</font>, the first defined data member of will share th=
e same address of the class, no matter that member is or isn't Standard-Lay=
outed."</div><div><br></div><div><div><font color=3D"#0000ff">struct</font>=
&nbsp;<font color=3D"#3d85c6">Sealer</font>&nbsp;<font color=3D"#38761d">//=
 Without take virtual functions / base classes itself.</font><br>{<br>&nbsp=
;&nbsp;&nbsp;<font color=3D"#3d85c6">SomeClass</font>&nbsp;<font color=3D"#=
000000">header_val</font>;<br>&nbsp;&nbsp;&nbsp;<font color=3D"#0000ff">int=
</font>&nbsp;val1;<br>&nbsp;&nbsp;&nbsp;<font color=3D"#0000ff">char</font>=
&nbsp;val2;</div><div>&nbsp;&nbsp; Sealer(<font color=3D"#3d85c6">void</fon=
t>);<br>};</div></div><div><br></div><div>Let's always get<br>&nbsp;reinter=
pret_cast&lt;void *&gt;(&amp;Sealer) =3D=3D reinterpret_cast&lt;void *&gt;(=
&amp;header_val)<br>as true.</div></blockquote><div><br>Why does this need =
to be a rule? That's the part you haven't explained. What operations do you=
 <i>need</i> to do that requires this equality?<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_2080_32918880.1367986424521--

.

------=_Part_9_23740456.1368032644987
Content-Type: text/plain; charset=ISO-8859-1

Because it can be used at many places to enhance both the performance and
readability.

1.Assuming we have a class C1:
class C1
{
private:
    int a;

public:
    C1(void);
    C1(int var1, float var2);

private:
    C1(const C1 &);               // disabled copy-construct.
    C1 & operator = (const C1 &); // disabled copy-assignment.
    static void * operator new (size_t);
    static void operator delete (void *);// deleting C1 with pointer of C1
or the inheritance is not allowed.
    static void * operator new [] (size_t);
    static void operator delete [] (void *);// deleting C1 with pointer of
C1 or the inheritance is not allowed.
    template < typename _ty >
    operator _ty & (void) const;  // disabled generic (means without using
'reinterpret_case') convertions.
    C1 * operator & (void) const; // Get the address of C1 object is not
allowed.
};

Now we need a class to let it begin handled by a container and, however,
the container only allowed to provided at most one, at least none argument
to initialize the object. Finally let the object can be work in this way:


struct Packer // It should have been a template, for explanation i used a
non-template class instead.
{
    C1 mydata;

    Packer(void) {}; // Calling the default-constuctor of object mydata.

    Packer(ArgLists<int,float> args) // The container support at most one
argument. So we use ArgLists.
        : mydata(args.get<0>(), args.get<1>())
    {};
};

Here is the request: The Packer will be put as a inner class of that
container, which requires that the start address of it equals to the start
address of the mydata, as a result many things can be written in pithy
style. Without the standarized supporting it can still be applied but also
complicated with unnecessary performance losts, Something like:
 ptr_Packer = (Packer *)((byte *)Allocated_C1_ptr - offsetof(Packer,
mydata));
realy?? no, there is strong reason that the offsetof(Packer, mydata) be
zero. and much worse, once a compiler decided to use the hidden extended
bytes betweens the entry of Packer and address of mydata to do something,
that formal won't work correctly. But since the Packer itself is not a
polymorphism class: no base, no virtual function, and a class'
local-resources (not including static and global res.) shall never expand
outside of itself (or the sizeof operator would yield a ill result), It
seems no reason to do that by any compiler(the hidden bytes for alignment
both between two data members and after the last data member is still
allowed)? Or you can tell me more about if there is ...

Another sample:

class C2
{
private:
    SomeClass data;

public:
    C2(void);

    operator ExpandedInterf & (void);
    operator const ExpandedInterf & (void) const;

    // ... // some extended functions to handle data at here.

private:
    C2(const C2 &);               // disabled copy-construct.
    C2 & operator = (const C2 &); // disabled copy-assignment.
    static void * operator new (size_t);
    static void operator delete (void *);// deleting C1 with pointer of C1
or the inheritance is not allowed.
    static void * operator new [] (size_t);
    static void operator delete [] (void *);// deleting C1 with pointer of
C1 or the inheritance is not allowed.
    template < typename _ty >
    operator _ty & (void) const;  // disabled generic (means without using
'reinterpret_case') convertions.
    C2 * operator & (void) const; // Get the address of C1 object is not
allowed.
};

Here is the 'ExpandedInterf' looks like:

class ExpandedInterf
{
private:
    SomeClass mappeddata;

public:
    // ... // Constructors & destructors & some extended functions to
handle mappeddata at here.
};

You may tell 'you can use the pointer/pointer class in ExpandedInterf ...'.
First, it's slower than direct-mapping; Second, using those kind of way
will lead the lifetime of the ExpandedInterf and C2 being different. It's
also not pithy enough.

--

---
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_9_23740456.1368032644987
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Because it can be used at many places to enhance both the performance =
and readability.</div><div><br></div><div>1.Assuming we have a class C1:</d=
iv><div><font color=3D"#0000ff">class</font> <font color=3D"#3d85c6">C1</fo=
nt></div><div>{</div><div><font color=3D"#0000ff">private</font>:</div><div=
>&nbsp; &nbsp; <font color=3D"#0000ff">int</font> <font color=3D"#666666">a=
</font>;</div><div><br></div><div><font color=3D"#0000ff">public</font>:</d=
iv><div>&nbsp; &nbsp; C1(<font color=3D"#0000ff">void</font>);</div><div>&n=
bsp; &nbsp; C1(<font color=3D"#0000ff">int </font><font color=3D"#666666">v=
ar1</font>, <font color=3D"#0000ff">float </font><font color=3D"#666666">va=
r2</font>);</div><div><br></div><div><font color=3D"#0000ff">private</font>=
:</div><div>&nbsp; &nbsp; C1(<font color=3D"#0000ff">const </font><font col=
or=3D"#3d85c6">C1 </font>&amp;); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; <font color=3D"#6aa84f">// disabled copy-construct.</font></div><div=
>&nbsp; &nbsp; <font color=3D"#3d85c6">C1 </font>&amp; <font color=3D"#0000=
ff">operator </font>=3D (<font color=3D"#0000ff">const </font><font color=
=3D"#3d85c6">C1 </font>&amp;); <font color=3D"#6aa84f">// disabled copy-ass=
ignment.</font></div><div>&nbsp; &nbsp; <font color=3D"#0000ff">static void=
 </font><font color=3D"#000000">*</font><font color=3D"#0000ff"> operator n=
ew</font> (<font color=3D"#0000ff">size_t</font>);</div><div>&nbsp; &nbsp; =
<font color=3D"#0000ff">static void operator delete</font> (<font color=3D"=
#0000ff">void </font>*);<font color=3D"#6aa84f">// deleting C1 with pointer=
 of C1 or the inheritance is not allowed.</font></div><div>&nbsp; &nbsp; <f=
ont color=3D"#0000ff">static void</font> * <font color=3D"#0000ff">operator=
 new</font> [] (<font color=3D"#0000ff">size_t</font>);</div><div>&nbsp; &n=
bsp; <font color=3D"#0000ff">static void operator delete</font> [] (<font c=
olor=3D"#0000ff">void </font>*);<font color=3D"#6aa84f">// deleting C1 with=
 pointer of C1 or the inheritance is not allowed.</font></div><div>&nbsp; &=
nbsp; <font color=3D"#0000ff">template </font>&lt; <font color=3D"#0000ff">=
typename </font><font color=3D"#3d85c6">_ty </font>&gt;</div><div>&nbsp; &n=
bsp; <font color=3D"#0000ff">operator </font><font color=3D"#3d85c6">_ty </=
font>&amp; (<font color=3D"#0000ff">void</font>) <font color=3D"#0000ff">co=
nst</font>; &nbsp;<font color=3D"#6aa84f">// disabled generic (means withou=
t using 'reinterpret_case') convertions.</font></div><div>&nbsp; &nbsp; <fo=
nt color=3D"#3d85c6">C1 </font>* <font color=3D"#0000ff">operator </font>&a=
mp; (<font color=3D"#0000ff">void</font>) <font color=3D"#0000ff">const</fo=
nt>; <font color=3D"#6aa84f">// Get the address of C1 object is not allowed=
..</font></div><div>};</div><div><br></div><div>Now we need a class to let i=
t begin handled by a container and, however, the container only allowed to =
provided at most one, at least none argument to initialize the object. Fina=
lly let the object can be work in this way:</div><div><br></div><div><br></=
div><div><font color=3D"#0000ff">struct </font><font color=3D"#3d85c6">Pack=
er </font><font color=3D"#6aa84f">// It should have been a template, for ex=
planation i used a non-template class instead.</font></div><div>{</div><div=
>&nbsp; &nbsp; <font color=3D"#3d85c6">C1 </font><font color=3D"#666666">my=
data</font>;</div><div><br></div><div>&nbsp; &nbsp; Packer(<span style=3D"b=
ackground-color: rgb(255, 255, 255);"><font color=3D"#0000ff">void</font></=
span>) {}; <font color=3D"#6aa84f">// Calling the default-constuctor of obj=
ect mydata.</font></div><div><br></div><div>&nbsp; &nbsp; Packer(<font colo=
r=3D"#3d85c6">ArgLists</font>&lt;<font color=3D"#0000ff">int</font>,<font c=
olor=3D"#0000ff">float</font>&gt; <font color=3D"#666666">args</font>) <fon=
t color=3D"#6aa84f">// The container support at most one argument. So we us=
e ArgLists.</font></div><div>&nbsp; &nbsp; &nbsp; &nbsp; : <font color=3D"#=
666666">mydata</font>(<font color=3D"#666666">args</font>.get&lt;<font colo=
r=3D"#666666">0</font>&gt;(), <font color=3D"#666666">args</font>.get&lt;<f=
ont color=3D"#666666">1</font>&gt;())</div><div>&nbsp; &nbsp; {};</div><div=
>};</div><div><br></div><div>Here is the request: The Packer will be put as=
 a inner class of that container, which requires that the start address of =
it equals to the start address of the mydata, as a result many things can b=
e written in pithy style. Without the standarized supporting it can still b=
e applied but also complicated with unnecessary performance losts, Somethin=
g like:</div><div>&nbsp;ptr_Packer =3D (Packer *)((byte *)Allocated_C1_ptr =
- offsetof(Packer, mydata));</div><div>realy?? no, there is strong reason t=
hat the offsetof(Packer, mydata) be zero. and much worse, once a compiler d=
ecided to use the hidden extended bytes betweens the entry of Packer and ad=
dress of mydata to do something, that formal won't work correctly. But sinc=
e the Packer itself is not a polymorphism class: no base, no virtual functi=
on, and a class' local-resources (not including static and global res.) sha=
ll never expand outside of itself (or the sizeof operator would yield a ill=
 result), It seems no reason to do that by any compiler(the hidden bytes fo=
r alignment both between two data members and after the last data member is=
 still allowed)? Or you can tell me more about if there is ...</div><div><b=
r></div><div>Another sample:</div><div><br></div><div><font color=3D"#0000f=
f">class </font><font color=3D"#3d85c6">C2</font></div><div>{</div><div><fo=
nt color=3D"#0000ff">private</font>:</div><div>&nbsp; &nbsp; <font color=3D=
"#3d85c6">SomeClass </font><font color=3D"#666666">data</font>;</div><div><=
br></div><div><font color=3D"#0000ff">public</font>:</div><div>&nbsp; &nbsp=
; C2(<font color=3D"#0000ff">void</font>);</div><div><br></div><div>&nbsp; =
&nbsp; <font color=3D"#0000ff">operator </font><font color=3D"#3d85c6">Expa=
ndedInterf </font>&amp; (<font color=3D"#0000ff">void</font>);</div><div>&n=
bsp; &nbsp; <font color=3D"#0000ff">operator const</font> <font color=3D"#3=
d85c6">ExpandedInterf </font>&amp; (<font color=3D"#0000ff">void</font>) <f=
ont color=3D"#0000ff">const</font>;</div><div><br></div><div><span style=3D=
"color: rgb(106, 168, 79);">&nbsp; &nbsp; // ... // some extended functions=
 to handle data at here.</span><br></div><div><br></div><div><font color=3D=
"#0000ff">private</font>:</div><div>&nbsp; &nbsp; C2(<font color=3D"#0000ff=
">const </font><font color=3D"#3d85c6">C2 </font>&amp;); &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; <font color=3D"#6aa84f">// disabled copy-con=
struct.</font></div><div>&nbsp; &nbsp; <font color=3D"#3d85c6">C2 </font>&a=
mp; <font color=3D"#0000ff">operator </font>=3D (<font color=3D"#0000ff">co=
nst </font><font color=3D"#3d85c6">C2 </font>&amp;); <font color=3D"#6aa84f=
">// disabled copy-assignment.</font></div><div>&nbsp; &nbsp; <font color=
=3D"#0000ff">static void </font><font color=3D"#000000">* </font><font colo=
r=3D"#0000ff">operator new</font> (<font color=3D"#0000ff">size_t</font>);<=
/div><div>&nbsp; &nbsp; <font color=3D"#0000ff">static void operator delete=
</font> (<font color=3D"#0000ff">void </font>*);<font color=3D"#6aa84f">// =
deleting C1 with pointer of C1 or the inheritance is not allowed.</font></d=
iv><div>&nbsp; &nbsp; <font color=3D"#0000ff">static void </font><font colo=
r=3D"#000000">* </font><font color=3D"#0000ff">operator new</font> [] (<fon=
t color=3D"#0000ff">size_t</font>);</div><div>&nbsp; &nbsp; <font color=3D"=
#0000ff">static void operator delete</font> [] (<font color=3D"#0000ff">voi=
d </font>*);<font color=3D"#6aa84f">// deleting C1 with pointer of C1 or th=
e inheritance is not allowed.</font></div><div>&nbsp; &nbsp; <font color=3D=
"#0000ff">template </font>&lt; <font color=3D"#0000ff">typename </font><fon=
t color=3D"#3d85c6">_ty </font>&gt;</div><div>&nbsp; &nbsp; <font color=3D"=
#0000ff">operator </font><font color=3D"#3d85c6">_ty </font>&amp; (<font co=
lor=3D"#0000ff">void</font>) <font color=3D"#0000ff">const</font>; <font co=
lor=3D"#6aa84f">&nbsp;// disabled generic (means without using 'reinterpret=
_case') convertions.</font></div><div>&nbsp; &nbsp; <font color=3D"#3d85c6"=
>C2 </font>* <font color=3D"#0000ff">operator </font>&amp; (<font color=3D"=
#0000ff">void</font>) <font color=3D"#0000ff">const</font>; <font color=3D"=
#6aa84f">// Get the address of C1 object is not allowed.</font></div><div>}=
;</div><div><br></div><div>Here is the 'ExpandedInterf' looks like:</div><d=
iv><br></div><div><font color=3D"#0000ff">class </font><font color=3D"#3d85=
c6">ExpandedInterf</font></div><div>{</div><div><span style=3D"background-c=
olor: rgb(255, 255, 255);"><font color=3D"#0000ff">private</font></span>:</=
div><div>&nbsp; &nbsp; <font color=3D"#3d85c6">SomeClass </font><font color=
=3D"#666666">mappeddata</font>;</div><div><br></div><div><font color=3D"#00=
00ff">public</font>:</div><div>&nbsp; &nbsp; <font color=3D"#6aa84f">// ...=
 // Constructors &amp; destructors &amp; some extended functions to handle =
mappeddata at here.</font></div><div>};</div><div><br></div><div>You may te=
ll 'you can use the pointer/pointer class in ExpandedInterf ...'. First, it=
's slower than direct-mapping; Second, using those kind of way will lead th=
e lifetime of the ExpandedInterf and C2 being different. It's also not pith=
y enough.</div><div><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_9_23740456.1368032644987--

.

------=_Part_4353_29143114.1368064902805
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, May 8, 2013 10:04:04 AM UTC-7, unituni...@gmail.com wrote:
>
> Because it can be used at many places to enhance both the performance and
> readability.
>
> 1.Assuming we have a class C1:
> class C1
> {
> private:
>     int a;
>
> public:
>     C1(void);
>     C1(int var1, float var2);
>
> private:
>     C1(const C1 &);               // disabled copy-construct.
>     C1 & operator = (const C1 &); // disabled copy-assignment.
>     static void * operator new (size_t);
>     static void operator delete (void *);// deleting C1 with pointer of
> C1 or the inheritance is not allowed.
>     static void * operator new [] (size_t);
>     static void operator delete [] (void *);// deleting C1 with pointer
> of C1 or the inheritance is not allowed.
>     template < typename _ty >
>     operator _ty & (void) const;  // disabled generic (means without
> using 'reinterpret_case') convertions.
>     C1 * operator & (void) const; // Get the address of C1 object is not
> allowed.
> };
>

This is some of the worst C++ code I've ever seen. That's an impressive
feat, since it's just a class declaration.

I could imagine that there's a reason why you need to forbid heap
allocation for some type. I can't think of one off the top of my head, but
I'm sure there's a reason. But there is *absolutely no reason* to forbid
implicit conversions. Unless you specify a specific implicit conversion...
you can't do any implicit conversions. They're already forbidden; *double*forbidding them is just silly.

And there is *absolutely no reason* to forbid getting the address of the
object. If I want to get the address of a type, that's my business, not
yours. Not to mention, I can undo all of this effort just by using
`std::address_of`.

It seems to me that your problem is not with C++. It's that you're writing
garbage C++ code and want it to work.


> Now we need a class to let it begin handled by a container and, however,
> the container only allowed to provided at most one, at least none argument
> to initialize the object. Finally let the object can be work in this way:
>
>
> struct Packer // It should have been a template, for explanation i used a
> non-template class instead.
> {
>     C1 mydata;
>
>     Packer(void) {}; // Calling the default-constuctor of object mydata.
>
>     Packer(ArgLists<int,float> args) // The container support at most one
> argument. So we use ArgLists.
>         : mydata(args.get<0>(), args.get<1>())
>     {};
> };
>
> Here is the request: The Packer will be put as a inner class of that
> container, which requires that the start address of it equals to the start
> address of the mydata, as a result many things can be written in pithy
> style.
>

That doesn't explain why the container needs to have `mydata` and `Packer`
be at the same address. Indeed, I don't understand why the container *cares
at all* about the binary layout of this object. But even if it did, you
said it yourself: `Packer` is an inner class of the container. It's an
implementation detail of the container. So it knows good and well what it
contains.

If you have some "Allocated_C1_ptr" and you want a pointer to `mydata`, you
should use the obvious:

C1 *ptr_mydata = &Allocated_C1_ptr->mydata;

Oh right, you expressly forbid getting a pointer to the object in the *normal
C++ way*. So:

C1 *ptr_mydata = std::address_of(Allocated_C1_ptr->mydata);

Wasn't forbidding the use of `operator&` so useful? It kept me from getting
an address for *the entire second* that it took me to type
`std::address_of`. That was time well spent. </sarcasm>

My point is that your pointer fiddling here seems to serve no purpose. Your
example is exceedingly contrived. It relies on pointlessly forbidding me
from getting a pointer to an object. It also falls apart the moment someone
remembers that `std::address_of` exists.

Please find an example that looks like reasonable C++ code.

Without the standarized supporting it can still be applied but also
> complicated with unnecessary performance losts, Something like:
>  ptr_Packer = (Packer *)((byte *)Allocated_C1_ptr - offsetof(Packer,
> mydata));
>
realy?? no, there is strong reason that the offsetof(Packer, mydata) be
> zero. and much worse, once a compiler decided to use the hidden extended
> bytes betweens the entry of Packer and address of mydata to do something,
> that formal won't work correctly. But since the Packer itself is not a
> polymorphism class: no base, no virtual function, and a class'
> local-resources (not including static and global res.) shall never expand
> outside of itself (or the sizeof operator would yield a ill result), It
> seems no reason to do that by any compiler(the hidden bytes for alignment
> both between two data members and after the last data member is still
> allowed)? Or you can tell me more about if there is ...
>
> Another sample:
>
> class C2
> {
> private:
>     SomeClass data;
>
> public:
>     C2(void);
>
>     operator ExpandedInterf & (void);
>     operator const ExpandedInterf & (void) const;
>
>     // ... // some extended functions to handle data at here.
>
> private:
>     C2(const C2 &);               // disabled copy-construct.
>     C2 & operator = (const C2 &); // disabled copy-assignment.
>     static void * operator new (size_t);
>     static void operator delete (void *);// deleting C1 with pointer of
> C1 or the inheritance is not allowed.
>     static void * operator new [] (size_t);
>     static void operator delete [] (void *);// deleting C1 with pointer
> of C1 or the inheritance is not allowed.
>     template < typename _ty >
>     operator _ty & (void) const;  // disabled generic (means without
> using 'reinterpret_case') convertions.
>     C2 * operator & (void) const; // Get the address of C1 object is not
> allowed.
> };
>
> Here is the 'ExpandedInterf' looks like:
>
> class ExpandedInterf
> {
> private:
>     SomeClass mappeddata;
>
> public:
>     // ... // Constructors & destructors & some extended functions to
> handle mappeddata at here.
> };
>
> You may tell 'you can use the pointer/pointer class in ExpandedInterf
> ...'. First, it's slower than direct-mapping; Second, using those kind of
> way will lead the lifetime of the ExpandedInterf and C2 being different.
> It's also not pithy enough.
>

It's not clear at all what the relationship between these two classes are,
besides the fact that you have this incredibly dubious notion of returning
a *reference* from a conversion operator rather than a value. What exactly
are these conversion operators doing? And how does it make sense to return
a reference rather than a value? Are you trying to do some nonsense like
this:

operator ExpandedInterf & (void)
{
  return *reinterpret_cast<ExpandedInterf*>(std::address_of(this->data));
}

Because that's seriously horrible code. If you want `ExpandedInterf` to
share ownership of `SomeClass`, you use a *pointer*, not a horrible
`reinterpret_cast`. At least there, the ownership semantics and
relationships are explicit rather than implicit (and terribly broken, mind
you).

Give me an example of using this functionality that *isn't* laden with
`reinterpret_cast` usage. Remember: `reinterpret_cast` is something you,
generally, speaking, *shouldn't be using*. Indeed, it seems to me that
everything you want this for are things you shouldn't be doing in the first
place. Low-level, horrible, and fundamentally bad ideas.

Also, this is the second time you've used the word "pithy". I don't know
what you mean by this, and Google isn't helping.

--

---
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_4353_29143114.1368064902805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, May 8, 2013 10:04:04 AM UTC-7, unituni...@gmail.com wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div>Because it can be used at ma=
ny places to enhance both the performance and readability.</div><div><br></=
div><div>1.Assuming we have a class C1:</div><div><font color=3D"#0000ff">c=
lass</font> <font color=3D"#3d85c6">C1</font></div><div>{</div><div><font c=
olor=3D"#0000ff">private</font>:</div><div>&nbsp; &nbsp; <font color=3D"#00=
00ff">int</font> <font color=3D"#666666">a</font>;</div><div><br></div><div=
><font color=3D"#0000ff">public</font>:</div><div>&nbsp; &nbsp; C1(<font co=
lor=3D"#0000ff">void</font>);</div><div>&nbsp; &nbsp; C1(<font color=3D"#00=
00ff">int </font><font color=3D"#666666">var1</font>, <font color=3D"#0000f=
f">float </font><font color=3D"#666666">var2</font>);</div><div><br></div><=
div><font color=3D"#0000ff">private</font>:</div><div>&nbsp; &nbsp; C1(<fon=
t color=3D"#0000ff">const </font><font color=3D"#3d85c6">C1 </font>&amp;); =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <font color=3D"#6aa84f">//=
 disabled copy-construct.</font></div><div>&nbsp; &nbsp; <font color=3D"#3d=
85c6">C1 </font>&amp; <font color=3D"#0000ff">operator </font>=3D (<font co=
lor=3D"#0000ff">const </font><font color=3D"#3d85c6">C1 </font>&amp;); <fon=
t color=3D"#6aa84f">// disabled copy-assignment.</font></div><div>&nbsp; &n=
bsp; <font color=3D"#0000ff">static void </font><font color=3D"#000000">*</=
font><font color=3D"#0000ff"> operator new</font> (<font color=3D"#0000ff">=
size_t</font>);</div><div>&nbsp; &nbsp; <font color=3D"#0000ff">static void=
 operator delete</font> (<font color=3D"#0000ff">void </font>*);<font color=
=3D"#6aa84f">// deleting C1 with pointer of C1 or the inheritance is not al=
lowed.</font></div><div>&nbsp; &nbsp; <font color=3D"#0000ff">static void</=
font> * <font color=3D"#0000ff">operator new</font> [] (<font color=3D"#000=
0ff">size_t</font>);</div><div>&nbsp; &nbsp; <font color=3D"#0000ff">static=
 void operator delete</font> [] (<font color=3D"#0000ff">void </font>*);<fo=
nt color=3D"#6aa84f">// deleting C1 with pointer of C1 or the inheritance i=
s not allowed.</font></div><div>&nbsp; &nbsp; <font color=3D"#0000ff">templ=
ate </font>&lt; <font color=3D"#0000ff">typename </font><font color=3D"#3d8=
5c6">_ty </font>&gt;</div><div>&nbsp; &nbsp; <font color=3D"#0000ff">operat=
or </font><font color=3D"#3d85c6">_ty </font>&amp; (<font color=3D"#0000ff"=
>void</font>) <font color=3D"#0000ff">const</font>; &nbsp;<font color=3D"#6=
aa84f">// disabled generic (means without using 'reinterpret_case') convert=
ions.</font></div><div>&nbsp; &nbsp; <font color=3D"#3d85c6">C1 </font>* <f=
ont color=3D"#0000ff">operator </font>&amp; (<font color=3D"#0000ff">void</=
font>) <font color=3D"#0000ff">const</font>; <font color=3D"#6aa84f">// Get=
 the address of C1 object is not allowed.</font></div><div>};<br></div></bl=
ockquote><div><br>This is some of the worst C++ code I've ever seen. That's=
 an impressive feat, since it's just a class declaration.<br><br>I could im=
agine that there's a reason why you need to forbid heap allocation for some=
 type. I can't think of one off the top of my head, but I'm sure there's a =
reason. But there is <i>absolutely no reason</i> to forbid implicit convers=
ions. Unless you specify a specific implicit conversion... you can't do any=
 implicit conversions. They're already forbidden; <i>double</i> forbidding =
them is just silly.<br><br>And there is <i>absolutely no reason</i> to forb=
id getting the address of the object. If I want to get the address of a typ=
e, that's my business, not yours. Not to mention, I can undo all of this ef=
fort just by using `std::address_of`.<br><br>It seems to me that your probl=
em is not with C++. It's that you're writing garbage C++ code and want it t=
o work.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></=
div><div>Now we need a class to let it begin handled by a container and, ho=
wever, the container only allowed to provided at most one, at least none ar=
gument to initialize the object. Finally let the object can be work in this=
 way:</div><div><br></div><div><br></div><div><font color=3D"#0000ff">struc=
t </font><font color=3D"#3d85c6">Packer </font><font color=3D"#6aa84f">// I=
t should have been a template, for explanation i used a non-template class =
instead.</font></div><div>{</div><div>&nbsp; &nbsp; <font color=3D"#3d85c6"=
>C1 </font><font color=3D"#666666">mydata</font>;</div><div><br></div><div>=
&nbsp; &nbsp; Packer(<span style=3D"background-color:rgb(255,255,255)"><fon=
t color=3D"#0000ff">void</font></span>) {}; <font color=3D"#6aa84f">// Call=
ing the default-constuctor of object mydata.</font></div><div><br></div><di=
v>&nbsp; &nbsp; Packer(<font color=3D"#3d85c6">ArgLists</font>&lt;<font col=
or=3D"#0000ff">int</font>,<font color=3D"#0000ff">float</font>&gt; <font co=
lor=3D"#666666">args</font>) <font color=3D"#6aa84f">// The container suppo=
rt at most one argument. So we use ArgLists.</font></div><div>&nbsp; &nbsp;=
 &nbsp; &nbsp; : <font color=3D"#666666">mydata</font>(<font color=3D"#6666=
66">args</font>.get&lt;<font color=3D"#666666">0</font>&gt;(), <font color=
=3D"#666666">args</font>.get&lt;<font color=3D"#666666">1</font>&gt;())</di=
v><div>&nbsp; &nbsp; {};</div><div>};</div><div><br></div><div>Here is the =
request: The Packer will be put as a inner class of that container, which r=
equires that the start address of it equals to the start address of the myd=
ata, as a result many things can be written in pithy style.</div></blockquo=
te><div><br>That doesn't explain why the container needs to have `mydata` a=
nd `Packer` be at the same address. Indeed, I don't understand why the cont=
ainer <i>cares at all</i> about the binary layout of this object. But even =
if it did, you said it yourself: `Packer` is an inner class of the containe=
r. It's an implementation detail of the container. So it knows good and wel=
l what it contains.<br><br>If you have some "Allocated_C1_ptr" and you want=
 a pointer to `mydata`, you should use the obvious:<br><br><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">C1 </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">ptr_mydata </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&amp;</span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Allocated_C1_ptr</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">mydata</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span></div></code></div><br>Oh right, you expressly forbid getting a p=
ointer to the object in the <b><i>normal C++ way</i></b>. So:<br><br><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #000;" class=3D"styled-by-prettify">C1 </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">ptr_mydata </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">address_of</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Allocated_C1_ptr</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">mydata</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span></div></code></div><br>Wasn't forbidding the use of `oper=
ator&amp;` so useful? It kept me from getting an address for <i>the entire =
second</i> that it took me to type `std::address_of`. That was time well sp=
ent. &lt;/sarcasm&gt;<br><br>My point is that your pointer fiddling here se=
ems to serve no purpose. Your example is exceedingly contrived. It relies o=
n pointlessly forbidding me from getting a pointer to an object. It also fa=
lls apart the moment someone remembers that `std::address_of` exists.<br><b=
r>Please find an example that looks like reasonable C++ code.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div> Without the standarized =
supporting it can still be applied but also complicated with unnecessary pe=
rformance losts, Something like:</div><div>&nbsp;ptr_Packer =3D (Packer *)(=
(byte *)Allocated_C1_ptr - offsetof(Packer, mydata));&nbsp;</div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div>realy?? no, there is s=
trong reason that the offsetof(Packer, mydata) be zero. and much worse, onc=
e a compiler decided to use the hidden extended bytes betweens the entry of=
 Packer and address of mydata to do something, that formal won't work corre=
ctly. But since the Packer itself is not a polymorphism class: no base, no =
virtual function, and a class' local-resources (not including static and gl=
obal res.) shall never expand outside of itself (or the sizeof operator wou=
ld yield a ill result), It seems no reason to do that by any compiler(the h=
idden bytes for alignment both between two data members and after the last =
data member is still allowed)? Or you can tell me more about if there is ..=
..</div><div><br></div><div>Another sample:</div><div><br></div><div><font c=
olor=3D"#0000ff">class </font><font color=3D"#3d85c6">C2</font></div><div>{=
</div><div><font color=3D"#0000ff">private</font>:</div><div>&nbsp; &nbsp; =
<font color=3D"#3d85c6">SomeClass </font><font color=3D"#666666">data</font=
>;</div><div><br></div><div><font color=3D"#0000ff">public</font>:</div><di=
v>&nbsp; &nbsp; C2(<font color=3D"#0000ff">void</font>);</div><div><br></di=
v><div>&nbsp; &nbsp; <font color=3D"#0000ff">operator </font><font color=3D=
"#3d85c6">ExpandedInterf </font>&amp; (<font color=3D"#0000ff">void</font>)=
;</div><div>&nbsp; &nbsp; <font color=3D"#0000ff">operator const</font> <fo=
nt color=3D"#3d85c6">ExpandedInterf </font>&amp; (<font color=3D"#0000ff">v=
oid</font>) <font color=3D"#0000ff">const</font>;</div><div><br></div><div>=
<span style=3D"color:rgb(106,168,79)">&nbsp; &nbsp; // ... // some extended=
 functions to handle data at here.</span><br></div><div><br></div><div><fon=
t color=3D"#0000ff">private</font>:</div><div>&nbsp; &nbsp; C2(<font color=
=3D"#0000ff">const </font><font color=3D"#3d85c6">C2 </font>&amp;); &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <font color=3D"#6aa84f">// disabl=
ed copy-construct.</font></div><div>&nbsp; &nbsp; <font color=3D"#3d85c6">C=
2 </font>&amp; <font color=3D"#0000ff">operator </font>=3D (<font color=3D"=
#0000ff">const </font><font color=3D"#3d85c6">C2 </font>&amp;); <font color=
=3D"#6aa84f">// disabled copy-assignment.</font></div><div>&nbsp; &nbsp; <f=
ont color=3D"#0000ff">static void </font><font color=3D"#000000">* </font><=
font color=3D"#0000ff">operator new</font> (<font color=3D"#0000ff">size_t<=
/font>);</div><div>&nbsp; &nbsp; <font color=3D"#0000ff">static void operat=
or delete</font> (<font color=3D"#0000ff">void </font>*);<font color=3D"#6a=
a84f">// deleting C1 with pointer of C1 or the inheritance is not allowed.<=
/font></div><div>&nbsp; &nbsp; <font color=3D"#0000ff">static void </font><=
font color=3D"#000000">* </font><font color=3D"#0000ff">operator new</font>=
 [] (<font color=3D"#0000ff">size_t</font>);</div><div>&nbsp; &nbsp; <font =
color=3D"#0000ff">static void operator delete</font> [] (<font color=3D"#00=
00ff">void </font>*);<font color=3D"#6aa84f">// deleting C1 with pointer of=
 C1 or the inheritance is not allowed.</font></div><div>&nbsp; &nbsp; <font=
 color=3D"#0000ff">template </font>&lt; <font color=3D"#0000ff">typename </=
font><font color=3D"#3d85c6">_ty </font>&gt;</div><div>&nbsp; &nbsp; <font =
color=3D"#0000ff">operator </font><font color=3D"#3d85c6">_ty </font>&amp; =
(<font color=3D"#0000ff">void</font>) <font color=3D"#0000ff">const</font>;=
 <font color=3D"#6aa84f">&nbsp;// disabled generic (means without using 're=
interpret_case') convertions.</font></div><div>&nbsp; &nbsp; <font color=3D=
"#3d85c6">C2 </font>* <font color=3D"#0000ff">operator </font>&amp; (<font =
color=3D"#0000ff">void</font>) <font color=3D"#0000ff">const</font>; <font =
color=3D"#6aa84f">// Get the address of C1 object is not allowed.</font></d=
iv><div>};</div><div><br></div><div>Here is the 'ExpandedInterf' looks like=
:</div><div><br></div><div><font color=3D"#0000ff">class </font><font color=
=3D"#3d85c6">ExpandedInterf</font></div><div>{</div><div><span style=3D"bac=
kground-color:rgb(255,255,255)"><font color=3D"#0000ff">private</font></spa=
n>:</div><div>&nbsp; &nbsp; <font color=3D"#3d85c6">SomeClass </font><font =
color=3D"#666666">mappeddata</font>;</div><div><br></div><div><font color=
=3D"#0000ff">public</font>:</div><div>&nbsp; &nbsp; <font color=3D"#6aa84f"=
>// ... // Constructors &amp; destructors &amp; some extended functions to =
handle mappeddata at here.</font></div><div>};</div><div><br></div><div>You=
 may tell 'you can use the pointer/pointer class in ExpandedInterf ...'. Fi=
rst, it's slower than direct-mapping; Second, using those kind of way will =
lead the lifetime of the ExpandedInterf and C2 being different. It's also n=
ot pithy enough.</div></blockquote><div><br>It's not clear at all what the =
relationship between these two classes are, besides the fact that you have =
this incredibly dubious notion of returning a <i>reference</i> from a conve=
rsion operator rather than a value. What exactly are these conversion opera=
tors doing? And how does it make sense to return a reference rather than a =
value? Are you trying to do some nonsense like this:<br><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">ExpandedInterf</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">reinterpret_cast</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">ExpandedInterf</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">*&gt;(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">address_of</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">this</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">d=
ata</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br>Because that's seriously horrible code. If you want `ExpandedInterf` =
to share ownership of `SomeClass`, you use a <i>pointer</i>, not a horrible=
 `reinterpret_cast`. At least there, the ownership semantics and relationsh=
ips are explicit rather than implicit (and terribly broken, mind you).<br><=
br>Give me an example of using this functionality that <i>isn't</i> laden w=
ith `reinterpret_cast` usage. Remember: `reinterpret_cast` is something you=
, generally, speaking, <i>shouldn't be using</i>. Indeed, it seems to me th=
at everything you want this for are things you shouldn't be doing in the fi=
rst place. Low-level, horrible, and fundamentally bad ideas.<br><br>Also, t=
his is the second time you've used the word "pithy". I don't know what you =
mean by this, and Google isn't helping.<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_4353_29143114.1368064902805--

.

------=_Part_1_29773192.1368097326037
Content-Type: text/plain; charset=ISO-8859-1

What your point, obviously is, that anything 'worst' is something you are
limited or prevented? The code i put before is a sort of locker(or just a
kind of warning signs to tell the clients something they'd better not to
do) to special access ways. using the reinterpret_cast and addressof(which
internally use reinterpret_cast<char&>) is just like a way to broken the
door, which doesn't mean to be bad or lack of the locker itself.
The conversion operator overloading in the C1 is not for forbiding implicit
conversions but explicit ones(except any reinterpret_cast<>). The implicit
conversions have been disabled before the conversion operator overloading
has been placed.
The private declaration(or another formal which with '= delete;') of new
and delete operators is not for disabling the heap allocating what you
talked about. It's just for disabling the allocating requests in direct
allocating way, as i said before, with the pointer to C1 or the inherited
class from C1. You can still do allocating with other formal, like class
Placement { C1 val; }; with 'new Placement'.
It seems that the 'normal C++ way' you said meaning 'Use C++ just for
making the code Looked Like the Coding and running In C++ way, but not
compling in C++ way'? Or it must and will be garbage hur? I feel you are
being so angry about my code Not because the crap it was so but just
something making you feeling restricted, then anything on your way should
have been killed and why don't just get the hell out of the front of you --
is that what you mean?
You don't want to solve anything. You don't want to think. You don't even
care. All you did were just or even prefer to stand on where you are and
tell others 'No'. There must be a reason that the C++11 implement more
rules for POD/trivil/Standard-Layout. As your understand, they are all
useless and even shouldn't be exist if there was no such rules yet. The
allocator the stl internally used manage objects as binary way, but with
the type of object-pointer. finally the most of such codes they introduced
work like the following formal:

data_type * pBinary = (data_type *)new byte [number *
sizeof(data_type)];//Pseudo code. which is as the formal of
'alloc.allocate(size_type)' generally.
for(size_type i(); i < number; ++i)
{
    new(pBinary + i) data_type(init_arg); //Pseudo code. which is as the
formal of alloc.construct(pBinary + i, init_arg); generally.
}
// ... // Save the pointer and length here.

Anything have a reason. The 'normal C++ way' still have nothing to do to
stop the realy bad formal code. In most of cases it won't be necessary to
ask standard to change for that not because the client should take this job
but the interfaces maker should handle that verification in code but not
language standard. The 'normal way' is too crude and even worse. The
decision that reject to implement a rule shouldn't rely on whether it 'has
to' but it 'shall not'. There is a view that a good C++ code should do as
possible as it could to let the verification be done at the compiling time
rather than runtime unless it's realy hard or logically not fit for. The
'normal C++ way' is not good for that.

--

---
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_1_29773192.1368097326037
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>What your point, obviously is, that anything 'worst' is something you =
are limited or prevented? The code i put before is a sort of locker(or just=
 a kind of warning signs to tell the clients something they'd better not to=
 do) to special access ways. using the reinterpret_cast and addressof(which=
 internally use reinterpret_cast&lt;char&amp;&gt;) is just like a way to br=
oken the door, which doesn't mean to be bad or lack of the locker itself.</=
div><div>The conversion operator overloading in the C1 is not for forbiding=
 implicit conversions but explicit ones(except any reinterpret_cast&lt;&gt;=
). The implicit conversions have been disabled before the conversion operat=
or overloading has been placed.</div><div>The private declaration(or anothe=
r formal which with '=3D delete;') of new and delete operators is not for d=
isabling the heap allocating what you talked about. It's just for disabling=
 the allocating requests in direct allocating way, as i said before, with t=
he pointer to C1 or the inherited class from C1. You can still do allocatin=
g with other formal, like class Placement { C1 val; }; with 'new Placement'=
..</div><div>It seems that the 'normal C++ way' you said meaning 'Use C++ ju=
st for making the code Looked Like the Coding and running In C++ way, but n=
ot compling in C++ way'? Or it must and will be garbage hur? I feel you are=
 being so angry about my code Not because the crap it was so but just somet=
hing making you feeling restricted, then anything on your way should have b=
een killed and why don't just get the hell out of the front of you -- is th=
at what you mean?</div><div>You don't want to solve anything. You don't wan=
t to think. You don't even care. All you did were just or even prefer to st=
and on where you are and tell others 'No'. There must be a reason that the =
C++11 implement more rules for POD/trivil/Standard-Layout. As your understa=
nd, they are all useless and even shouldn't be exist if there was no such r=
ules yet. The allocator the stl internally used manage objects as binary wa=
y, but with the type of object-pointer. finally the most of such codes they=
 introduced work like the following formal:</div><div><br></div><div>data_t=
ype * pBinary =3D (data_type *)new byte [number * sizeof(data_type)];//Pseu=
do code. which is as the formal of 'alloc.allocate(size_type)' generally.</=
div><div>for(size_type i(); i &lt; number; ++i)</div><div>{</div><div>&nbsp=
; &nbsp; new(pBinary + i) data_type(init_arg); //Pseudo code. which is as t=
he formal of alloc.construct(pBinary + i, init_arg); generally.</div><div>}=
</div><div>// ... // Save the pointer and length here.</div><div><br></div>=
<div>Anything have a reason. The 'normal C++ way' still have nothing to do =
to stop the realy bad formal code. In most of cases it won't be necessary t=
o ask standard to change for that not because the client should take this j=
ob but the interfaces maker should handle that verification in code but not=
 language standard. The 'normal way' is too crude and even worse. The decis=
ion that reject to implement a rule shouldn't rely on <font color=3D"#0000f=
f">whether it 'has to'</font> but <font color=3D"#0000ff">it 'shall not'</f=
ont>. There is a view that a good C++ code should do as possible as it coul=
d to let the verification be done at the compiling time rather than runtime=
 unless it's realy hard or logically not fit for. The 'normal C++ way' is n=
ot good for that.</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_1_29773192.1368097326037--

.

------=_Part_4650_32123335.1368099478125
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, May 9, 2013 4:02:06 AM UTC-7, unituni...@gmail.com wrote:
>
> What your point, obviously is, that anything 'worst' is something you are
> limited or prevented?
>

Preventing the user from doing things that the class is not intended to do
is fine. Preventing a class from being copied is fine. Preventing a class
from being default constructed is fine. And so forth.

Getting a pointer to an object is the *right* of every C++ programmer. It
is a basic language feature, regardless of the object's type. For you to
deny a programmer that *right* is a violation of the contract between class
designer and class user. I'm not the only C++ programmer who thought it was
a mistake to allow users to overload the unary `operator&` on classes. And
I have no love for code that would deny me that right.

I don't really understand what the point of forbidding "explicit"
conversion of references is. Particularly when such explicit conversions
don't make sense and aren't protected by the rules of C++ anyway. It's
forbidding something that people don't do.

The private declaration(or another formal which with '= delete;') of new
> and delete operators is not for disabling the heap allocating what you
> talked about. It's just for disabling the allocating requests in direct
> allocating way, as i said before, with the pointer to C1 or the inherited
> class from C1. You can still do allocating with other formal, like class
> Placement { C1 val; }; with 'new Placement'.
>

So... what's the point? Why are you making normal usage of your class (like
heap allocation) *inconvenient*? People do not write C++ this way. And we
should not add features to the language that only a select few people who
use this coding style will use.

It seems that the 'normal C++ way' you said meaning 'Use C++ just for
> making the code Looked Like the Coding and running In C++ way, but not
> compling in C++ way'? Or it must and will be garbage hur? I feel you are
> being so angry about my code Not because the crap it was so but just
> something making you feeling restricted, then anything on your way should
> have been killed and why don't just get the hell out of the front of you --
> is that what you mean?
>

.... I don't understand what you're saying. Your use of language is becoming
an issue.

I would consider the "normal C++ way" to be what you see in real, live C++
programs. What you see in actual C++ libraries.

I don't see a lot of objects that you can't call `new` or `delete` on in
Boost. I don't see a lot of objects you can't get pointers to with
`operator&` in Microsoft or Google's C++ code. The standard library did not
forbid reference casting of `std::thread`.

That is what is "normal".

Your code is not following established C++ coding practices. And we
shouldn't add features to the *language* if it would only ever be useful to
people who are doing things that just don't make sense.

You don't want to solve anything. You don't want to think. You don't even
> care. All you did were just or even prefer to stand on where you are and
> tell others 'No'. There must be a reason that the C++11 implement more
> rules for POD/trivil/Standard-Layout.
>

I explained those reasons: it standardized existing practice. Also, it's
sometimes very useful to be layout-compatible with C types, while still
availing one's self of certain C++ features.

The difference between that and this is that I could explain how standard
layout is important just by referencing an existing C API<http://www.opengl.org/wiki/GLAPI/glDrawArraysIndirect>.
I want to interface with that via a class, and I want that class to have
member functions, constructors, destructors, and the like. The only thing
it can't have are base classes that have members, and I don't *need* that
to interface with a C API.

Your attempts to explain why you need the functionality you outline all
involve writing terrible code. *Needlessly* terrible code. They're
artificial problems that arise because you keep wanting to derive classes
from things or to stop people from using `operator&`, or other things that
have nothing to do with low-level coding.

Everything you have posted can be achieved another way, and in most cases
with only minor inconvenience. And those that can't are things you have no
business doing to begin with (like reference casting). They have nothing to
do with interfacing with C APIs or other low-level binary tasks.

As your understand, they are all useless and even shouldn't be exist if
> there was no such rules yet. The allocator the stl internally used manage
> objects as binary way, but with the type of object-pointer. finally the
> most of such codes they introduced work like the following formal:
>
> data_type * pBinary = (data_type *)new byte [number *
> sizeof(data_type)];//Pseudo code. which is as the formal of
> 'alloc.allocate(size_type)' generally.
> for(size_type i(); i < number; ++i)
> {
>     new(pBinary + i) data_type(init_arg); //Pseudo code. which is as the
> formal of alloc.construct(pBinary + i, init_arg); generally.
> }
> // ... // Save the pointer and length here.
>
> Anything have a reason. The 'normal C++ way' still have nothing to do to
> stop the realy bad formal code. In most of cases it won't be necessary to
> ask standard to change for that not because the client should take this job
> but the interfaces maker should handle that verification in code but not
> language standard. The 'normal way' is too crude and even worse. The
> decision that reject to implement a rule shouldn't rely on whether it
> 'has to' but it 'shall not'. There is a view that a good C++ code should
> do as possible as it could to let the verification be done at the compiling
> time rather than runtime unless it's realy hard or logically not fit for.
> The 'normal C++ way' is not good for that.
>

Again, I don't really understand what you're trying to say here.

--

---
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_4650_32123335.1368099478125
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 9, 2013 4:02:06 AM UTC-7, unituni...@gmail.com wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div>What your point, obviously is,=
 that anything 'worst' is something you are limited or prevented?</div></bl=
ockquote><div><br>Preventing the user from doing things that the class is n=
ot intended to do is fine. Preventing a class from being copied is fine. Pr=
eventing a class from being default constructed is fine. And so forth.<br><=
br>Getting a pointer to an object is the <i>right</i> of every C++ programm=
er. It is a basic language feature, regardless of the object's type. For yo=
u to deny a programmer that <i>right</i> is a violation of the contract bet=
ween class designer and class user. I'm not the only C++ programmer who tho=
ught it was a mistake to allow users to overload the unary `operator&amp;` =
on classes. And I have no love for code that would deny me that right.<br><=
br>I don't really understand what the point of forbidding "explicit" conver=
sion of references is. Particularly when such explicit conversions don't ma=
ke sense and aren't protected by the rules of C++ anyway. It's forbidding s=
omething that people don't do.<br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div>The private declaration(or another formal which with '=
=3D delete;') of new and delete operators is not for disabling the heap all=
ocating what you talked about. It's just for disabling the allocating reque=
sts in direct allocating way, as i said before, with the pointer to C1 or t=
he inherited class from C1. You can still do allocating with other formal, =
like class Placement { C1 val; }; with 'new Placement'.</div></blockquote><=
div><br>So... what's the point? Why are you making normal usage of your cla=
ss (like heap allocation) <i>inconvenient</i>? People do not write C++ this=
 way. And we should not add features to the language that only a select few=
 people who use this coding style will use.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>It seems that the 'normal C++ way' you sai=
d meaning 'Use C++ just for making the code Looked Like the Coding and runn=
ing In C++ way, but not compling in C++ way'? Or it must and will be garbag=
e hur? I feel you are being so angry about my code Not because the crap it =
was so but just something making you feeling restricted, then anything on y=
our way should have been killed and why don't just get the hell out of the =
front of you -- is that what you mean?</div></blockquote><div><br>... I don=
't understand what you're saying. Your use of language is becoming an issue=
..<br><br>I would consider the "normal C++ way" to be what you see in real, =
live C++ programs. What you see in actual C++ libraries.<br><br>I don't see=
 a lot of objects that you can't call `new` or `delete` on in Boost. I don'=
t see a lot of objects you can't get pointers to with `operator&amp;` in Mi=
crosoft or Google's C++ code. The standard library did not forbid reference=
 casting of `std::thread`.<br><br>That is what is "normal".<br><br>Your cod=
e is not following established C++ coding practices. And we shouldn't add f=
eatures to the <i>language</i> if it would only ever be useful to people wh=
o are doing things that just don't make sense.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div>You don't want to solve anything. You do=
n't want to think. You don't even care. All you did were just or even prefe=
r to stand on where you are and tell others 'No'. There must be a reason th=
at the C++11 implement more rules for POD/trivil/Standard-Layout.</div></bl=
ockquote><div><br>I explained those reasons: it standardized existing pract=
ice. Also, it's sometimes very useful to be layout-compatible with C types,=
 while still availing one's self of certain C++ features.<br><br>The differ=
ence between that and this is that I could explain how standard layout is i=
mportant just by <a href=3D"http://www.opengl.org/wiki/GLAPI/glDrawArraysIn=
direct">referencing an existing C API</a>. I want to interface with that vi=
a a class, and I want that class to have member functions, constructors, de=
structors, and the like. The only thing it can't have are base classes that=
 have members, and I don't <i>need</i> that to interface with a C API.<br><=
br>Your attempts to explain why you need the functionality you outline all =
involve writing terrible code. <i>Needlessly</i> terrible code. They're art=
ificial problems that arise because you keep wanting to derive classes from=
 things or to stop people from using `operator&amp;`, or other things that =
have nothing to do with low-level coding.<br><br>Everything you have posted=
 can be achieved another way, and in most cases with only minor inconvenien=
ce. And those that can't are things you have no business doing to begin wit=
h (like reference casting). They have nothing to do with interfacing with C=
 APIs or other low-level binary tasks.<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>As your understand, they are all useless and eve=
n shouldn't be exist if there was no such rules yet. The allocator the stl =
internally used manage objects as binary way, but with the type of object-p=
ointer. finally the most of such codes they introduced work like the follow=
ing formal:</div><div><br></div><div>data_type * pBinary =3D (data_type *)n=
ew byte [number * sizeof(data_type)];//Pseudo code. which is as the formal =
of 'alloc.allocate(size_type)' generally.</div><div>for(size_type i(); i &l=
t; number; ++i)</div><div>{</div><div>&nbsp; &nbsp; new(pBinary + i) data_t=
ype(init_arg); //Pseudo code. which is as the formal of alloc.construct(pBi=
nary + i, init_arg); generally.</div><div>}</div><div>// ... // Save the po=
inter and length here.</div><div><br></div><div>Anything have a reason. The=
 'normal C++ way' still have nothing to do to stop the realy bad formal cod=
e. In most of cases it won't be necessary to ask standard to change for tha=
t not because the client should take this job but the interfaces maker shou=
ld handle that verification in code but not language standard. The 'normal =
way' is too crude and even worse. The decision that reject to implement a r=
ule shouldn't rely on <font color=3D"#0000ff">whether it 'has to'</font> bu=
t <font color=3D"#0000ff">it 'shall not'</font>. There is a view that a goo=
d C++ code should do as possible as it could to let the verification be don=
e at the compiling time rather than runtime unless it's realy hard or logic=
ally not fit for. The 'normal C++ way' is not good for that.</div></blockqu=
ote><div><br>Again, I don't really understand what you're trying to say her=
e. <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_4650_32123335.1368099478125--

.