------=_Part_30_1620637889.1421968756719
Content-Type: multipart/alternative;
 boundary="----=_Part_31_1525905522.1421968756720"

------=_Part_31_1525905522.1421968756720
Content-Type: text/plain; charset=UTF-8

Hi there,

maybe somebody can join and help with this following brainstorming, may
sound naive, but would love to hear opinions.

Two new keywords: (white and black), or (iface and impl) or anything else,
I will go for the moment with two rather neutral keywords black and white.
Black is for blackbox, white is for whitebox. Black is for what you hide,
white is what you show. Black is really private, white is really public. No
more pimpl, guaranteed fast compilation times, less recompilation and the
list does not stop here.

// content of A.h
class white A {
   /* here come all public virtuals and non virtuals */
   /* we could also allow public data members */
};


// content of A.cpp
class black A {
   /* here come all data members  */
   /* here come all the private methods */
};

/* how would I solve */
A * = new A();

what do we need for allocation? The size of the data members from white and
black? Compiler can either generate a classsize() function or with -fPIC
trick, put the size into data section, so that it can be available at
runtime. Advantage of a classize() function is that like this, classes can
have an easier life in shared libraries (plugin pattern for instance).
What about allocating on the stack? Do the same in alloca style.

What about subclassing? Well here are two problems: the size and the
offsets.

Subclass size: For the subclass the classize will be it's size plus the
data it defines additionally.

Offsets: we either force all the public data members into the blackbox (so
only private data members, thus defined in black), and outside world does
not have to know about offsets, everything will be accessed only through
getters/setters. Or one can use the normal offset calculation like for
normal classes, one can make the convention that "white" members are at the
beginning of the object. The problem would be a bit tricky with subclasses.
But also here the compiler can calculate offests as: offset in subclass +
size of baseclass.

thanks for your feedback



--

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

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

<div dir=3D"ltr"><div>Hi there,&nbsp;</div><div><br></div><div>maybe somebo=
dy can join and help with this following brainstorming, may sound naive, bu=
t would love to hear opinions.&nbsp;</div><div><br></div>Two new keywords: =
(white and black), or (iface and impl) or anything else, I will go for the =
moment with two rather neutral keywords black and white.&nbsp;<div>Black is=
 for blackbox, white is for whitebox. Black is for what you hide, white is =
what you show. Black is really private, white is really public. No more pim=
pl, guaranteed fast compilation times, less recompilation and the list does=
 not stop here.</div><div><br></div><div>// content of A.h</div><div>class =
white A {</div><div>&nbsp; &nbsp;/* here come all public virtuals and non v=
irtuals */</div><div>&nbsp; &nbsp;/* we could also allow public data member=
s */</div><div>};</div><div><br></div><div><br></div><div><div>// content o=
f A.cpp</div><div>class black A {</div><div>&nbsp; &nbsp;/* here come all d=
ata members &nbsp;*/</div><div>&nbsp; &nbsp;/* here come all the private me=
thods */<br></div><div>};</div></div><div><br></div><div>/* how would I sol=
ve */</div><div>A * =3D new A();</div><div><br></div><div>what do we need f=
or allocation? The size of the data members from white and black? Compiler =
can either generate a classsize() function or with -fPIC trick, put the siz=
e into data section, so that it can be available at runtime. Advantage of a=
 classize() function is that like this, classes can have an easier life in =
shared libraries (plugin pattern for instance).&nbsp;</div><div>What about =
allocating on the stack? Do the same in alloca style.&nbsp;<br><br>What abo=
ut subclassing? Well here are two problems: the size and the offsets.&nbsp;=
</div><div><br></div><div>Subclass size: For the subclass the classize will=
 be it's size plus the data it defines additionally.&nbsp;</div><div><br></=
div><div>Offsets: we either force all the public data members into the blac=
kbox (so only private data members, thus defined in black), and outside wor=
ld does not have to know about offsets, everything will be accessed only th=
rough getters/setters. Or one can use the normal offset calculation like fo=
r normal classes, one can make the convention that "white" members are at t=
he beginning of the object. The problem would be a bit tricky with subclass=
es. But also here the compiler can calculate offests as: offset in subclass=
 + size of baseclass.</div><div><br></div><div>thanks for your feedback</di=
v><div><br></div><div><br></div><div><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_31_1525905522.1421968756720--
------=_Part_30_1620637889.1421968756719--

.

While the concept sounds good on the surface, there seems an awful lot
of baggage associated with it.

On 1/22/15, mobiphil <mobi@mobiphil.com> wrote:
> Hi there,
>
> maybe somebody can join and help with this following brainstorming, may
> sound naive, but would love to hear opinions.
>
> Two new keywords: (white and black), or (iface and impl) or anything else,
> I will go for the moment with two rather neutral keywords black and white.
> Black is for blackbox, white is for whitebox. Black is for what you hide,
> white is what you show. Black is really private, white is really public. No
>
> more pimpl, guaranteed fast compilation times, less recompilation and the
> list does not stop here.
>
> // content of A.h
> class white A {
>    /* here come all public virtuals and non virtuals */
>    /* we could also allow public data members */
> };
>
>
> // content of A.cpp
> class black A {
>    /* here come all data members  */
>    /* here come all the private methods */
> };
>
> /* how would I solve */
> A * = new A();
>
> what do we need for allocation? The size of the data members from white and
>
> black? Compiler can either generate a classsize() function or with -fPIC
> trick, put the size into data section, so that it can be available at
> runtime. Advantage of a classize() function is that like this, classes can
> have an easier life in shared libraries (plugin pattern for instance).
> What about allocating on the stack? Do the same in alloca style.
>
> What about subclassing? Well here are two problems: the size and the
> offsets.
>
> Subclass size: For the subclass the classize will be it's size plus the
> data it defines additionally.
>
> Offsets: we either force all the public data members into the blackbox (so
> only private data members, thus defined in black), and outside world does
> not have to know about offsets, everything will be accessed only through
> getters/setters. Or one can use the normal offset calculation like for
> normal classes, one can make the convention that "white" members are at the
>
> beginning of the object. The problem would be a bit tricky with subclasses.
>
> But also here the compiler can calculate offests as: offset in subclass +
> size of baseclass.
>
> thanks for your feedback
>
>
>
> --
>
> ---
> 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/.
>

--

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

.

Have you had a look at the work done by the Modules SG?

On 1/23/15, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> While the concept sounds good on the surface, there seems an awful lot
> of baggage associated with it.
>
> On 1/22/15, mobiphil <mobi@mobiphil.com> wrote:
>> Hi there,
>>
>> maybe somebody can join and help with this following brainstorming, may
>> sound naive, but would love to hear opinions.
>>
>> Two new keywords: (white and black), or (iface and impl) or anything
>> else,
>> I will go for the moment with two rather neutral keywords black and
>> white.
>> Black is for blackbox, white is for whitebox. Black is for what you hide,
>> white is what you show. Black is really private, white is really public.
>> No
>>
>> more pimpl, guaranteed fast compilation times, less recompilation and the
>> list does not stop here.
>>
>> // content of A.h
>> class white A {
>>    /* here come all public virtuals and non virtuals */
>>    /* we could also allow public data members */
>> };
>>
>>
>> // content of A.cpp
>> class black A {
>>    /* here come all data members  */
>>    /* here come all the private methods */
>> };
>>
>> /* how would I solve */
>> A * = new A();
>>
>> what do we need for allocation? The size of the data members from white
>> and
>>
>> black? Compiler can either generate a classsize() function or with -fPIC
>> trick, put the size into data section, so that it can be available at
>> runtime. Advantage of a classize() function is that like this, classes
>> can
>> have an easier life in shared libraries (plugin pattern for instance).
>> What about allocating on the stack? Do the same in alloca style.
>>
>> What about subclassing? Well here are two problems: the size and the
>> offsets.
>>
>> Subclass size: For the subclass the classize will be it's size plus the
>> data it defines additionally.
>>
>> Offsets: we either force all the public data members into the blackbox
>> (so
>> only private data members, thus defined in black), and outside world does
>> not have to know about offsets, everything will be accessed only through
>> getters/setters. Or one can use the normal offset calculation like for
>> normal classes, one can make the convention that "white" members are at
>> the
>>
>> beginning of the object. The problem would be a bit tricky with
>> subclasses.
>>
>> But also here the compiler can calculate offests as: offset in subclass +
>> size of baseclass.
>>
>> thanks for your feedback
>>
>>
>>
>> --
>>
>> ---
>> 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/.
>>
>

--

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

.

------=_Part_109_76038278.1422011965479
Content-Type: multipart/alternative;
 boundary="----=_Part_110_222568381.1422011965479"

------=_Part_110_222568381.1422011965479
Content-Type: text/plain; charset=UTF-8



> While the concept sounds good on the surface, there seems an awful lot
> of baggage associated with it.
>
> I know... but that is the objective of this proposed brainstorming, to
name all the elements... What I forgot to mention is that obviously using
the keywords thus splitting the class would be obviously optional

--

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

------=_Part_110_222568381.1422011965479
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">While the concept sounds good on the surface, there seems an awful lot
<br>of baggage associated with it.
<br><br></blockquote><div>I know... but that is the objective of this proposed brainstorming, to name all the elements... What I forgot to mention is that obviously using the keywords thus splitting the class would be obviously optional&nbsp;</div></div>

<p></p>

-- <br />
<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_110_222568381.1422011965479--
------=_Part_109_76038278.1422011965479--

.

------=_Part_269_13740481.1422012127109
Content-Type: multipart/alternative;
 boundary="----=_Part_270_1407133159.1422012127118"

------=_Part_270_1407133159.1422012127118
Content-Type: text/plain; charset=UTF-8


>
> Have you had a look at the work done by the Modules SG?
>

Yes, but they are almost orthogonally different, though their effect may
overlap. I am hacking right now the modules implementation of clang.

--

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

------=_Part_270_1407133159.1422012127118
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Have you had a look at the work done by the Modules SG?
<br></blockquote><div><br></div><div>Yes, but they are almost orthogonally different, though their effect may overlap. I am hacking right now the modules implementation of clang.</div></div>

<p></p>

-- <br />
<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_270_1407133159.1422012127118--
------=_Part_269_13740481.1422012127109--

.

------=_Part_182_1872699039.1422015022219
Content-Type: multipart/alternative;
 boundary="----=_Part_183_961842928.1422015022223"

------=_Part_183_961842928.1422015022223
Content-Type: text/plain; charset=UTF-8

If you go that road, I suggest looking at Modula 3 and its "partial
revelations", ie the possibility for a component to provides different
interfaces to different customers.

Yours,

--
Jean-Marc

--

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

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

<div dir=3D"ltr">If you go that road, I suggest looking at Modula 3 and its=
 "partial revelations", ie the possibility for a component to provides diff=
erent interfaces to different customers.<div><br></div><div>Yours,</div><di=
v><br></div><div>--&nbsp;</div><div>Jean-Marc</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_183_961842928.1422015022223--
------=_Part_182_1872699039.1422015022219--

.

------=_Part_1562_225626841.1422026086617
Content-Type: multipart/alternative;
 boundary="----=_Part_1563_1801679732.1422026086617"

------=_Part_1563_1801679732.1422026086617
Content-Type: text/plain; charset=UTF-8


>
> If you go that road, I suggest looking at Modula 3 and its "partial
> revelations", ie the possibility for a component to provides different
> interfaces to different customers.
>

was not aware about this, skimmed the article (link below), will read it
more carefully at a later time, but it seems that it is a generalization of
what I just proposed.

What is ill in C++ is that one tried to push everything into one class
declaration. I was thinking also about including in the same proposal the
fact that non virtual functions declarations could be easily removed from
the class declaration and allow anywhere just Class::method() {}.. kind of
declarations/definitions. This would allow moving of different details of a
class into different header. Obviously This does not mean that one wants to
create a class that can do everything.

  The "black" I proposed, could be split into several blacks, the class
black idiom could be regarded as even superfluous, and just allow "int
Class::member ;" declaration anywhere. The linker could gather all the
parts of the classes and reason about it. But this later detail is a bit
extreme, I agree.



http://www.cs.tut.fi/lintula/manual/modula3/modula-3/html/partial-rev/index.html

--

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">If you go that road, I suggest looking at Modula 3 and its "partial rev=
elations", ie the possibility for a component to provides different interfa=
ces to different customers.</div></blockquote><div><br></div><div>was not a=
ware about this, skimmed the article (link below), will read it more carefu=
lly at a later time, but it seems that it is a generalization of what I jus=
t proposed.<br><br>What is ill in C++ is that one tried to push everything =
into one class declaration. I was thinking also about including in the same=
 proposal the fact that non virtual functions declarations could be easily =
removed from the class declaration and allow anywhere just Class::method() =
{}.. kind of declarations/definitions. This would allow moving of different=
 details of a class into different header. Obviously This does not mean tha=
t one wants to create a class that can do everything.</div><div><br></div><=
div>&nbsp;&nbsp;The "black" I proposed, could be split into several blacks,=
 the class black idiom could be regarded as even superfluous, and just allo=
w "int Class::member ;" declaration anywhere. The linker could gather all t=
he parts of the classes and reason about it. But this later detail is a bit=
 extreme, I agree.</div><div><br></div><div><br></div><div><br></div><div>h=
ttp://www.cs.tut.fi/lintula/manual/modula3/modula-3/html/partial-rev/index.=
html</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1563_1801679732.1422026086617--
------=_Part_1562_225626841.1422026086617--

.

On 01/22/2015 06:19 PM, mobiphil wrote:
> maybe somebody can join and help with this following brainstorming, may
> sound naive, but would love to hear opinions.

Are you familiar with Objective-C?  If not, I recommend researching
Objective-C interfaces, implementations, categories, and class
extensions to help flesh out your idea.

What would sizeof(A) produce in a translation unit that observes only
the interface (white) declaration?  Would this require a dynamic sizeof
similar to that required for C99 variable length arrays?  (I think the
need for a dynamic sizeof is one of the issues that have prevented
variable length arrays being added to C++).

Would class data members of these split class types be allowed when only
the interface (white) declaration is present in a translation unit?  If
so, what would be the result of sizeof(X) for such a class?

Tom.

--

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

.

------=_Part_509_258460392.1422029125694
Content-Type: multipart/alternative;
 boundary="----=_Part_510_1731874110.1422029125694"

------=_Part_510_1731874110.1422029125694
Content-Type: text/plain; charset=UTF-8

Thanks for joining

> maybe somebody can join and help with this following brainstorming, may
> > sound naive, but would love to hear opinions.
>
> Are you familiar with Objective-C?  If not, I recommend researching
> Objective-C interfaces, implementations, categories, and class
> extensions to help flesh out your idea.
>

Have some very basic notion. I would not spend too much time for further
study if there is zero acceptance for such ideas.


> What would sizeof(A) produce in a translation unit that observes only
> the interface (white) declaration?

 Would this require a dynamic sizeof
> similar to that required for C99 variable length arrays?  (I think the
> need for a dynamic sizeof is one of the issues that have prevented
> variable length arrays being added to C++).
>
> Compilation error for static sizeof. If really needed for runtime, then
replace with a pointer to some global text that would be solved by the
linker (like fpic). Or go for the function Class::sizeof() that would be
automatically generated by the compiler.


> Would class data members of these split class types be allowed when only
> the interface (white) declaration is present in a translation unit?  If
> so, what would be the result of sizeof(X) for such a class?
>

static sizeof(x), does not make sense, we both agree. I am not supposed to
want know the color, shape etc. of an object that does not exist.
If you do not provide the blackbox, you will have linker error, the same
way you would have for missing vtables. This linker error would be
"implemented" either by missing Class::size() function or Class::size
global variable.



--

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

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

<div dir=3D"ltr"><div>Thanks for joining&nbsp;</div><br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">&gt; maybe somebody can join and help with this=
 following brainstorming, may
<br>&gt; sound naive, but would love to hear opinions.
<br>
<br>Are you familiar with Objective-C? &nbsp;If not, I recommend researchin=
g=20
<br>Objective-C interfaces, implementations, categories, and class=20
<br>extensions to help flesh out your idea.
<br></blockquote><div><br></div><div>Have some very basic notion. I would n=
ot spend too much time for further study if there is zero acceptance for su=
ch ideas.&nbsp;</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>What would sizeof(A) produce in a translation unit that observes only=
=20
<br>the interface (white) declaration?</blockquote><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"> &nbsp;Would this require a dynamic sizeof=20
<br>similar to that required for C99 variable length arrays? &nbsp;(I think=
 the=20
<br>need for a dynamic sizeof is one of the issues that have prevented=20
<br>variable length arrays being added to C++).
<br>
<br></blockquote><div>Compilation error for static sizeof. If really needed=
 for runtime, then replace with a pointer to some global text that would be=
 solved by the linker (like fpic). Or go for the function Class::sizeof() t=
hat would be automatically generated by the compiler.<br></div><div>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Would class data members =
of these split class types be allowed when only=20
<br>the interface (white) declaration is present in a translation unit? &nb=
sp;If=20
<br>so, what would be the result of sizeof(X) for such a class?
<br></blockquote><div><br></div><div>static sizeof(x), does not make sense,=
 we both agree. I am not supposed to want know the color, shape etc. of an =
object that does not exist.</div><div>If you do not provide the blackbox, y=
ou will have linker error, the same way you would have for missing vtables.=
 This linker error would be "implemented" either by missing Class::size() f=
unction or Class::size global variable.</div><div><br></div><div>&nbsp;</di=
v></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_510_1731874110.1422029125694--
------=_Part_509_258460392.1422029125694--

.

On Friday 23 January 2015 08:05:25 mobiphil wrote:
> static sizeof(x), does not make sense, we both agree. I am not supposed to
> want know the color, shape etc. of an object that does not exist.
> If you do not provide the blackbox, you will have linker error, the same
> way you would have for missing vtables. This linker error would be
> "implemented" either by missing Class::size() function or Class::size
> global variable.

Without a static sizeof, you can't:

 - use operator new
 - use make_shared or make_unique
 - declare the object on the stack
 - use it as a member of another object

The only way you can create such an object is to call an allocator function.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_1754_138350334.1422038548417
Content-Type: multipart/alternative;
 boundary="----=_Part_1755_1676757484.1422038548417"

------=_Part_1755_1676757484.1422038548417
Content-Type: text/plain; charset=UTF-8

I thought I touch all the subjects, but I will comment once more


> Without a static sizeof, you can't:
>
>  - use operator new
>
Not if you do not separate the concepts. When does new happen? At runtime.
Do I know the size of the object at runtime yes. Proposed here either a
function that the compiler would generate, or a global that would hold the
size of the object deduced based on the size of "black" (+ size of white if
I want to allow data in the white)


>  - use make_shared or make_unique
>
Well, did not look into this one, but not all objects or classes fit into
all patterns. Non copiables do not fit into patterns that need copiable
etc...


>  - declare the object on the stack
>
Yes you could, as mentioned earlier, do alloca based on the dynamic size
mentioned above

>  - use it as a member of another object

Yes you could. The size and offset needed though would be calculated at
runtime with similare mechasism like -fpic


--

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

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

<div dir=3D"ltr"><div>I thought I touch all the subjects, but I will commen=
t once more<br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">Without a static sizeof, you can't:
<br>
<br>&nbsp;- use operator new
<br></blockquote><div>Not if you do not separate the concepts. When does ne=
w happen? At runtime. Do I know the size of the object at runtime yes. Prop=
osed here either a function that the compiler would generate, or a global t=
hat would hold the size of the object deduced based on the size of "black" =
(+ size of white if I want to allow data in the white)</div><div>&nbsp;</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">&nbsp;- use make_shared or m=
ake_unique
<br></blockquote><div>Well, did not look into this one, but not all objects=
 or classes fit into all patterns. Non copiables do not fit into patterns t=
hat need copiable etc...</div><div>&nbsp;</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">&nbsp;- declare the object on the stack
<br></blockquote><div>Yes you could, as mentioned earlier, do alloca based =
on the dynamic size mentioned above&nbsp;</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">&nbsp;- use it as a member of another object&nbsp;</blockq=
uote><div>Yes you could. The size and offset needed though would be calcula=
ted at runtime with similare mechasism like -fpic</div><div><br></div><div>=
<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1755_1676757484.1422038548417--
------=_Part_1754_138350334.1422038548417--

.

On Friday 23 January 2015 10:42:28 mobiphil wrote:
> >  - use it as a member of another object
>
> Yes you could. The size and offset needed though would be calculated at
> runtime with similare mechasism like -fpic

More like virtual inheritance instead of position-independent code.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_623_1990348239.1422039558815
Content-Type: multipart/alternative;
 boundary="----=_Part_624_430083554.1422039558815"

------=_Part_624_430083554.1422039558815
Content-Type: text/plain; charset=UTF-8


>
> > Yes you could. The size and offset needed though would be calculated at
> > runtime with similare mechasism like -fpic
>
> More like virtual inheritance instead of position-independent code.
>

What do you mean?

What I mean with "similar mechanism like -fPIC": offsets and size will be
known at runtime by pointing to a global location that will be resolved by
the linker

--

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

------=_Part_624_430083554.1422039558815
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Yes you could. The size and offset needed though would be calculated at
<br>&gt; runtime with similare mechasism like -fpic
<br>
<br>More like virtual inheritance instead of position-independent code.
<br></blockquote><div><br></div><div>What do you mean?<br><br>What I mean with "similar mechanism like -fPIC": offsets and size will be known at runtime by pointing to a global location that will be resolved by the linker</div></div>

<p></p>

-- <br />
<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_624_430083554.1422039558815--
------=_Part_623_1990348239.1422039558815--

.

On Friday 23 January 2015 10:59:18 mobiphil wrote:
> > > Yes you could. The size and offset needed though would be calculated at
> > > runtime with similare mechasism like -fpic
> >
> > More like virtual inheritance instead of position-independent code.
>
> What do you mean?
>
> What I mean with "similar mechanism like -fPIC": offsets and size will be
> known at runtime by pointing to a global location that will be resolved by
> the linker

Also possible, but just not the way I envisioned it. Loading it from a very
different page of memory may be slower than keeping it local and just
referencing each dynamic item by a pointer, like a virtual base.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_972_1893562912.1422057895163
Content-Type: multipart/alternative;
 boundary="----=_Part_973_1551697091.1422057895163"

------=_Part_973_1551697091.1422057895163
Content-Type: text/plain; charset=UTF-8


>
> Also possible, but just not the way I envisioned it. Loading it from a
> very
> different page of memory may be slower than keeping it local and just
> referencing each dynamic item by a pointer, like a virtual base.
>

I had this in mind. I am trying to think both in terms of dynamic and
static linking. Dynamic linking is probably bringing more complex, I was
rather thinking in terms of it. Without going into details dynamic linking
with current compilers/linkers can be mainly done in two ways: either
intrusive or non intrusive. The linker may go to the code and patch
function addresses, or use the function wrappers. (sorry if I do not use
the right terminology). All these are implementation details that have
their advantages/disadvantages. As most of shared libraries are implemented
with -fpic, for the sake of simplicity I mentioned this one. I am perfectly
aware of the expense. Patching references at dynamic linking time would be
another solution. Patching all the references has the disadvantage that you
may patch 99% of references that are not used, slowing down thus dynamic
linking. If it is static linking the linker could patch it at linking time.

Referencing each dynamic item by a pointer : you are proposing that dynamic
items shall be allocated separately and keep a pointer like in the case of
opaque pointers? Do not think this is a solution. These pointers equally
can fall outside of the page and have same cache issues you are touched or?
 For me it is important that the object itself stays compact. The question
is what is the best solution to access members of the "white". The most
straightforward would be for the sake of simplicity to forbid data members
in the white, and really keep it like an interface.

--

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Also possible=
, but just not the way I envisioned it. Loading it from a very=20
<br>different page of memory may be slower than keeping it local and just=
=20
<br>referencing each dynamic item by a pointer, like a virtual base.
<br></blockquote><div><br></div><div>I had this in mind. I am trying to thi=
nk both in terms of dynamic and static linking. Dynamic linking is probably=
 bringing more complex, I was rather thinking in terms of it. Without going=
 into details dynamic linking with current compilers/linkers can be mainly =
done in two ways: either intrusive or non intrusive. The linker may go to t=
he code and patch function addresses, or use the function wrappers. (sorry =
if I do not use the right terminology). All these are implementation detail=
s that have their advantages/disadvantages. As most of shared libraries are=
 implemented with -fpic, for the sake of simplicity I mentioned this one. I=
 am perfectly aware of the expense. Patching references at dynamic linking =
time would be another solution. Patching all the references has the disadva=
ntage that you may patch 99% of references that are not used, slowing down =
thus dynamic linking. If it is static linking the linker could patch it at =
linking time.<br><br>Referencing each dynamic item by a pointer : you are p=
roposing that dynamic items shall be allocated separately and keep a pointe=
r like in the case of opaque pointers? Do not think this is a solution. The=
se pointers equally can fall outside of the page and have same cache issues=
 you are touched or? &nbsp;For me it is important that the object itself st=
ays compact. The question is what is the best solution to access members of=
 the "white". The most straightforward would be for the sake of simplicity =
to forbid data members in the white, and really keep it like an interface.<=
/div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_973_1551697091.1422057895163--
------=_Part_972_1893562912.1422057895163--

.

On Friday 23 January 2015 16:04:55 mobiphil wrote:
> Referencing each dynamic item by a pointer : you are proposing that dynamic
> items shall be allocated separately and keep a pointer like in the case of
> opaque pointers?

No, I am not proposing that. First of all, I am not proposing anything. I
personally don't think your proposal will fly...

But if it were to be implemented, I'd expect it to be done like a class with
virtual bases: the allocator allocates a block of memory with sufficient size
for all of the dynamic objects inside, which it calculates at runtime by
adding up the sizes of each one, and initialises a helper pointer to those
objects. This extra pointer is an implementation detail and is hidden from the
user, just like a virtual base's pointer.

The other solution is to create a "dynamic table" of the class, which like the
virtual table, is associated one per class. This table would contain the size
of the full class and the offsets of each of the dynamic-sized members. The
problem here is initialising this table, since it can only be done at runtime,
it has to be done on program load.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

The other option would be for the compiler to produce an interface
file containing the necessary details.

On 1/24/15, Thiago Macieira <thiago@macieira.org> wrote:
> On Friday 23 January 2015 16:04:55 mobiphil wrote:
>> Referencing each dynamic item by a pointer : you are proposing that
>> dynamic
>> items shall be allocated separately and keep a pointer like in the case
>> of
>> opaque pointers?
>
> No, I am not proposing that. First of all, I am not proposing anything. I
> personally don't think your proposal will fly...
>
> But if it were to be implemented, I'd expect it to be done like a class with
>
> virtual bases: the allocator allocates a block of memory with sufficient
> size
> for all of the dynamic objects inside, which it calculates at runtime by
> adding up the sizes of each one, and initialises a helper pointer to those
> objects. This extra pointer is an implementation detail and is hidden from
> the
> user, just like a virtual base's pointer.
>
> The other solution is to create a "dynamic table" of the class, which like
> the
> virtual table, is associated one per class. This table would contain the
> size
> of the full class and the offsets of each of the dynamic-sized members. The
>
> problem here is initialising this table, since it can only be done at
> runtime,
> it has to be done on program load.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.
>

--

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

.

.... and references that when compiling the dependent TU.

On 1/24/15, Thiago Macieira <thiago@macieira.org> wrote:
> On Friday 23 January 2015 16:04:55 mobiphil wrote:
>> Referencing each dynamic item by a pointer : you are proposing that
>> dynamic
>> items shall be allocated separately and keep a pointer like in the case
>> of
>> opaque pointers?
>
> No, I am not proposing that. First of all, I am not proposing anything. I
> personally don't think your proposal will fly...
>
> But if it were to be implemented, I'd expect it to be done like a class with
>
> virtual bases: the allocator allocates a block of memory with sufficient
> size
> for all of the dynamic objects inside, which it calculates at runtime by
> adding up the sizes of each one, and initialises a helper pointer to those
> objects. This extra pointer is an implementation detail and is hidden from
> the
> user, just like a virtual base's pointer.
>
> The other solution is to create a "dynamic table" of the class, which like
> the
> virtual table, is associated one per class. This table would contain the
> size
> of the full class and the offsets of each of the dynamic-sized members. The
>
> problem here is initialising this table, since it can only be done at
> runtime,
> it has to be done on program load.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.
>

--

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

.

------=_Part_2549_1633221344.1422099459162
Content-Type: multipart/alternative;
 boundary="----=_Part_2550_415152654.1422099459162"

------=_Part_2550_415152654.1422099459162
Content-Type: text/plain; charset=UTF-8


>
> > Referencing each dynamic item by a pointer : you are proposing that
> dynamic
> > items shall be allocated separately and keep a pointer like in the case
> of
> > opaque pointers?
>
> No, I am not proposing that. First of all, I am not proposing anything.


Well, suggesting, writing, proposing, I think you get it...


> personally don't think your proposal will fly...
>

That is a bit negative. Seeing how slowly C++ developed, and how rigid it
is, that would not surprise me. Unfortunately most of industries failed to
influence the evolution of C++. Such a feature would have saved for most of
projects I worked lot of dollars. I see in your signature that you work in
kde area, thus probably you deal lot with QT. I wonder if having such
feature QT would have bothered with opaque pointers.


> But if it were to be implemented, I'd expect it to be done like a class
> with
> virtual bases: the allocator allocates a block of memory with sufficient
> size
> for all of the dynamic objects inside,

sufficient you mean allocated can exceed much the size of all dynamic
objects?


> which it calculates at runtime by
> adding up the sizes of each one, and initialises a helper pointer to those
> objects.

Sorry: one pointer to several objects, is that correct? Who would store
this pointer, how would it work?


> The other solution is to create a "dynamic table" of the class, which like
> the
> virtual table, is associated one per class. This table would contain the
> size
> of the full class and the offsets of each of the dynamic-sized members.
> The
> problem here is initialising this table, since it can only be done at
> runtime,
> it has to be done on program load.
>
You get it... This is exactly what I did mean with the -fpic like
mechanism, was bit lazy to describe.
But you made a good point and will link it with your previous observation
about having this information in a different memory page that will probably
cause cache miss. Well unfortunately virtual tables suffer of the same
problem. So we arrived to the point: this information could be part of the
virtual pointer table.

Another solution would be (at least for the beta :) ) to forbid data
members in the interface. The dynamic linker or the linker (I know, linkers
do not have such tasks) could go only through the code that knows about the
black, and patch it with right offset, as he would already know about the
blacks of superclases.




--

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Referenc=
ing each dynamic item by a pointer : you are proposing that dynamic=20
<br>&gt; items shall be allocated separately and keep a pointer like in the=
 case of
<br>&gt; opaque pointers?
<br>
<br>No, I am not proposing that. First of all, I am not proposing anything.=
 </blockquote><div><br></div><div>Well, suggesting, writing, proposing, I t=
hink you get it...&nbsp;</div><div>&nbsp;</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">personally don't think your proposal will fly...
<br></blockquote><div><br></div><div>That is a bit negative. Seeing how slo=
wly C++ developed, and how rigid it is, that would not surprise me. Unfortu=
nately most of industries failed to influence the evolution of C++. Such a =
feature would have saved for most of projects I worked lot of dollars. I se=
e in your signature that you work in kde area, thus probably you deal lot w=
ith QT. I wonder if having such feature QT would have bothered with opaque =
pointers.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">But if it were to be implemented, I'd expect it to be done like a class w=
ith=20
<br>virtual bases: the allocator allocates a block of memory with sufficien=
t size=20
<br>for all of the dynamic objects inside, </blockquote><div>sufficient you=
 mean allocated can exceed much the size of all dynamic objects?</div><div>=
&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">which it calcu=
lates at runtime by=20
<br>adding up the sizes of each one, and initialises a helper pointer to th=
ose=20
<br>objects. </blockquote><div>Sorry: one pointer to several objects, is th=
at correct? Who would store this pointer, how would it work?</div><div>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The other solution is =
to create a "dynamic table" of the class, which like the=20
<br>virtual table, is associated one per class. This table would contain th=
e size=20
<br>of the full class and the offsets of each of the dynamic-sized members.=
 The=20
<br>problem here is initialising this table, since it can only be done at r=
untime,=20
<br>it has to be done on program load.
<br></blockquote><div>You get it... This is exactly what I did mean with th=
e -fpic like mechanism, was bit lazy to describe.&nbsp;</div><div>But you m=
ade a good point and will link it with your previous observation about havi=
ng this information in a different memory page that will probably cause cac=
he miss. Well unfortunately virtual tables suffer of the same problem. So w=
e arrived to the point: this information could be part of the virtual point=
er table.</div><div><br></div><div>Another solution would be (at least for =
the beta :) ) to forbid data members in the interface. The dynamic linker o=
r the linker (I know, linkers do not have such tasks) could go only through=
 the code that knows about the black, and patch it with right offset, as he=
 would already know about the blacks of superclases.</div><div><br><br></di=
v><div><br></div><div><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2550_415152654.1422099459162--
------=_Part_2549_1633221344.1422099459162--

.

------=_Part_2112_327059416.1422099588007
Content-Type: multipart/alternative;
 boundary="----=_Part_2113_1476952039.1422099588007"

------=_Part_2113_1476952039.1422099588007
Content-Type: text/plain; charset=UTF-8


>
> The other option would be for the compiler to produce an interface
> file containing the necessary details.
>

I am afraid that would still introduce compile time dependencies. Once you
changed the content of the black, that would regenerate the interface thus
force the dependees to recompile.


--

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

------=_Part_2113_1476952039.1422099588007
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The other option would be for the compiler to produce an interface
<br>file containing the necessary details.
<br></blockquote><div><br></div><div>I am afraid that would still introduce compile time dependencies. Once you changed the content of the black, that would regenerate the interface thus force the dependees to recompile.</div><div>&nbsp;</div></div>

<p></p>

-- <br />
<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_2113_1476952039.1422099588007--
------=_Part_2112_327059416.1422099588007--

.

On Saturday 24 January 2015 03:37:39 mobiphil wrote:
> > But if it were to be implemented, I'd expect it to be done like a class
> > with
> > virtual bases: the allocator allocates a block of memory with sufficient
> > size
> > for all of the dynamic objects inside,
>
> sufficient you mean allocated can exceed much the size of all dynamic
> objects?

Exceeds yes. By the padding amount and the extra pointers.

>
> > which it calculates at runtime by
> > adding up the sizes of each one, and initialises a helper pointer to those
> > objects.
>
> Sorry: one pointer to several objects, is that correct? Who would store
> this pointer, how would it work?

Let's say Foo and Bar are dynamic in the object below:

class MyObject : public virtual SomeOther
{
 Foo foo;
 int i;
 int j;
 void *d;
 Bar bar;
 virtual ~MyObject();
};

If it's implemented as I described, the real object's ABI is:

struct MyObject_real
{
 MyObject_vtable *_vptr;
 SomeOther *_vbase;
 Foo *foo;
 Bar *bar;

 int i;
 int j;
 void *d;

 SomeOther _vbase_space;
 // plus space for Foo and Bar
};

The code that allocates MyObject needs to take sizeof(MyObject_real) and add
the dynamic sizes of Foo and Bar. The difference between that and the allocated
space for the virtual base is that the size of the former isn't known at
compile time.

If you do object.foo.x, it's implemented as real(object).foo->x.

> > The other solution is to create a "dynamic table" of the class, which like
> > the
> > virtual table, is associated one per class. This table would contain the
> > size
> > of the full class and the offsets of each of the dynamic-sized members.
> > The
> > problem here is initialising this table, since it can only be done at
> > runtime,
> > it has to be done on program load.
>
> You get it... This is exactly what I did mean with the -fpic like
> mechanism, was bit lazy to describe.
> But you made a good point and will link it with your previous observation
> about having this information in a different memory page that will probably
> cause cache miss. Well unfortunately virtual tables suffer of the same
> problem. So we arrived to the point: this information could be part of the
> virtual pointer table.

This requires careful research by the ABI developers to see which solution is
more efficient. My educated guess is that mine above is more cache- and
instruction-efficient, but I have not (and have no intention to) actually
benchmarked this.

Your solution requires loading a ptrdiff_t from a known, global location in
memory, then adding it to your class's base pointer. With -fPIC, this becomes
a double indirection: you need to load a pointer from the GOT and then load
the ptrdiff_t from the address the GOT contained, only then add it.

And then there's the initialisation of this table. For a single dynamic-sized
object, the value can be emitted by the compiler at compile time. For an
object that contains other dynamic-sized objects, the compiler can't do it, so
it has to emit load-time code to calculate this and save in the "dynamic
table". I don't want to imagine the problems caused by getting the
initialisation order wrong.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_231_226515242.1422122455521
Content-Type: multipart/alternative;
 boundary="----=_Part_232_1700649810.1422122455521"

------=_Part_232_1700649810.1422122455521
Content-Type: text/plain; charset=UTF-8


>
> struct MyObject_real
>
{
>         MyObject_vtable *_vptr;
>         SomeOther *_vbase;
>         Foo *foo;
>         Bar *bar;
>
>         int i;
>         int j;
>         void *d;
>
>         SomeOther _vbase_space;
>         // plus space for Foo and Bar
> };
>

I see, but personally I would not be happy seeing the space wasted for
pointers especially not 64 bit. I am thinking to make another proposal
about 64bit pointer compression. Eventually offsets would do it. Why should
I store the layout of each object in each object. And that is what I mean
by "this information could be part of the virtual pointer table".  It is
true that vtable is not present for all classes, but well, there will be
another reason for the existence of vtable.


> The code that allocates MyObject needs to take sizeof(MyObject_real) and
> add
> the dynamic sizes of Foo and Bar. The difference between that and the
> allocated
> space for the virtual base is that the size of the former isn't known at
> compile time.
>

Regarding layout I think the base should come first. Isn't it implemented
like that. Casting normally keeps the address, so base class data should be
at lower addresses.

Well, I think better not to mix -fpic anymore and mix dynamic and static
linking for the moment. When I wrote the first message, did not think about
virtual tables. Probably the cleanest is to say size and offset (layout)
 information will be available at runtime in vtable or vtable alike
structure.




--

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">struct MyObje=
ct_real&nbsp;<br></blockquote><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
{
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MyObject_vtable *_vptr;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SomeOther *_vbase;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Foo *foo;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bar *bar;
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int i;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int j;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;void *d;
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SomeOther _vbase_space;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// plus space for Foo a=
nd Bar
<br>};
<br></blockquote><div><br></div><div>I see, but personally I would not be h=
appy seeing the space wasted for pointers especially not 64 bit. I am think=
ing to make another proposal about 64bit pointer compression. Eventually of=
fsets would do it. Why should I store the layout of each object in each obj=
ect. And that is what I mean by "this information could be part of the virt=
ual pointer table". &nbsp;It is true that vtable is not present for all cla=
sses, but well, there will be another reason for the existence of vtable.</=
div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The code =
that allocates MyObject needs to take sizeof(MyObject_real) and add=20
<br>the dynamic sizes of Foo and Bar. The difference between that and the a=
llocated=20
<br>space for the virtual base is that the size of the former isn't known a=
t=20
<br>compile time.
<br></blockquote><div><br></div><div>Regarding layout I think the base shou=
ld come first. Isn't it implemented like that. Casting normally keeps the a=
ddress, so base class data should be at lower addresses.&nbsp;</div><div><b=
r></div><div>Well, I think better not to mix -fpic anymore and mix dynamic =
and static linking for the moment. When I wrote the first message, did not =
think about virtual tables. Probably the cleanest is to say size and offset=
 (layout) &nbsp;information will be available at runtime in vtable or vtabl=
e alike structure.<br><br><br><br><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_232_1700649810.1422122455521--
------=_Part_231_226515242.1422122455521--

.

On Saturday 24 January 2015 10:00:55 mobiphil wrote:
> Regarding layout I think the base should come first. Isn't it implemented
> like that. Casting normally keeps the address, so base class data should be
> at lower addresses.

Not for virtual bases. The virtual base is kept after the non-virtuals.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--001a113f3288a585fa050e6e8fbc
Content-Type: text/plain; charset=UTF-8

so, this topic can be forgotten, nobody bites? ;)

--

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

--001a113f3288a585fa050e6e8fbc
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div class="gmail_extra">so, this topic can be forgotten, nobody bites? ;)
</div></div>

<p></p>

-- <br />
<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--001a113f3288a585fa050e6e8fbc--

.

On Friday 06 February 2015 18:15:02 mobi phil wrote:
> so, this topic can be forgotten, nobody bites? ;)

You haven't written a proposal.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--20cf3040ebf45ed768050e743049
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 6, 2015 at 11:22 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Friday 06 February 2015 18:15:02 mobi phil wrote:
> > so, this topic can be forgotten, nobody bites? ;)
>
> You haven't written a proposal.


Sorry, do not understand this. How would you pretend there was no proposal
while you reacted to it yourself....

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 6, 2015 at 11:22 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><span class=3D"">On Friday 06 February=
 2015 18:15:02 mobi phil wrote:<br>
&gt; so, this topic can be forgotten, nobody bites? ;)<br>
<br>
</span>You haven&#39;t written a proposal.</blockquote><div><br></div><div>=
Sorry, do not understand this. How would you pretend there was no proposal =
while you reacted to it yourself....</div><div><br></div><div><br></div></d=
iv>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--20cf3040ebf45ed768050e743049--

.

On Saturday 07 February 2015 00:57:53 mobi phil wrote:
> On Fri, Feb 6, 2015 at 11:22 PM, Thiago Macieira <thiago@macieira.org>
>
> wrote:
> > On Friday 06 February 2015 18:15:02 mobi phil wrote:
> > > so, this topic can be forgotten, nobody bites? ;)
> >
> > You haven't written a proposal.
>
> Sorry, do not understand this. How would you pretend there was no proposal
> while you reacted to it yourself....

I meant that you did not write a paper and submit to the committee for
consideration.

I think your idea has merit. It makes sense to present it and talk to the
people doing Modules. Some aspects of it could be adopted there.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--089e0111b8fad938e5050e7c9ce3
Content-Type: text/plain; charset=UTF-8

>
> On Saturday 07 February 2015 00:57:53 mobi phil wrote:
> > On Fri, Feb 6, 2015 at 11:22 PM, Thiago Macieira <thiago@macieira.org>
> >
> > wrote:
> > > On Friday 06 February 2015 18:15:02 mobi phil wrote:
> > > > so, this topic can be forgotten, nobody bites? ;)
> > >
> > > You haven't written a proposal.
> >
> > Sorry, do not understand this. How would you pretend there was no
> proposal
> > while you reacted to it yourself....
>
> I meant that you did not write a paper and submit to the committee for
> consideration.
>
> I think your idea has merit. It makes sense to present it and talk to the
> people doing Modules. Some aspects of it could be adopted there.
>

While I do not know exactly the formal procedure, I do not think it is
worth the effort to write a formal paper unless some of the honorable
members of the honorable committee would show minimum interest to ever
consider it. The reason of the brainstorming is to find together weaknesses
of the model and solutions for them.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div><div>On Saturday 07 February 2015 00:57:53 =
mobi phil wrote:<br>
&gt; On Fri, Feb 6, 2015 at 11:22 PM, Thiago Macieira &lt;<a href=3D"mailto=
:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;<br>
&gt;<br>
&gt; wrote:<br>
&gt; &gt; On Friday 06 February 2015 18:15:02 mobi phil wrote:<br>
&gt; &gt; &gt; so, this topic can be forgotten, nobody bites? ;)<br>
&gt; &gt;<br>
&gt; &gt; You haven&#39;t written a proposal.<br>
&gt;<br>
&gt; Sorry, do not understand this. How would you pretend there was no prop=
osal<br>
&gt; while you reacted to it yourself....<br>
<br>
</div></div>I meant that you did not write a paper and submit to the commit=
tee for<br>
consideration.<br>
<br>
I think your idea has merit. It makes sense to present it and talk to the<b=
r>
people doing Modules. Some aspects of it could be adopted there.<br>
<div><div></div></div></blockquote></div><br>
</div><div class=3D"gmail_extra">While I do not know exactly the formal pro=
cedure, I do not think it is worth the effort to write a formal paper unles=
s some of the honorable members of the honorable committee would show minim=
um interest to ever consider it. The reason of the brainstorming is to find=
 together weaknesses of the model and solutions for them.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0111b8fad938e5050e7c9ce3--

.

------=_Part_1188_292565653.1423318011324
Content-Type: multipart/alternative;
 boundary="----=_Part_1189_1560861988.1423318011324"

------=_Part_1189_1560861988.1423318011324
Content-Type: text/plain; charset=UTF-8



On Saturday, February 7, 2015 at 11:00:56 PM UTC+13, mobiphil wrote:
>
> On Saturday 07 February 2015 00:57:53 mobi phil wrote:
>> > On Fri, Feb 6, 2015 at 11:22 PM, Thiago Macieira <thi...@macieira.org
>> <javascript:>>
>> >
>> > wrote:
>> > > On Friday 06 February 2015 18:15:02 mobi phil wrote:
>> > > > so, this topic can be forgotten, nobody bites? ;)
>> > >
>> > > You haven't written a proposal.
>> >
>> > Sorry, do not understand this. How would you pretend there was no
>> proposal
>> > while you reacted to it yourself....
>>
>> I meant that you did not write a paper and submit to the committee for
>> consideration.
>>
>> I think your idea has merit. It makes sense to present it and talk to the
>> people doing Modules. Some aspects of it could be adopted there.
>>
>
> While I do not know exactly the formal procedure, I do not think it is
> worth the effort to write a formal paper unless some of the honorable
> members of the honorable committee would show minimum interest to ever
> consider it. The reason of the brainstorming is to find together weaknesses
> of the model and solutions for them.
>
>
> I agree

--

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

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

<div dir=3D"ltr"><br><br>On Saturday, February 7, 2015 at 11:00:56 PM UTC+1=
3, mobiphil wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div><div>On Saturday 07 =
February 2015 00:57:53 mobi phil wrote:<br>
&gt; On Fri, Feb 6, 2015 at 11:22 PM, Thiago Macieira &lt;<a onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gd=
f-obfuscated-mailto=3D"BJQEkn4dDgQJ">thi...@macieira.org</a>&gt;<br>
&gt;<br>
&gt; wrote:<br>
&gt; &gt; On Friday 06 February 2015 18:15:02 mobi phil wrote:<br>
&gt; &gt; &gt; so, this topic can be forgotten, nobody bites? ;)<br>
&gt; &gt;<br>
&gt; &gt; You haven't written a proposal.<br>
&gt;<br>
&gt; Sorry, do not understand this. How would you pretend there was no prop=
osal<br>
&gt; while you reacted to it yourself....<br>
<br>
</div></div>I meant that you did not write a paper and submit to the commit=
tee for<br>
consideration.<br>
<br>
I think your idea has merit. It makes sense to present it and talk to the<b=
r>
people doing Modules. Some aspects of it could be adopted there.<br>
<div><div></div></div></blockquote></div><br>
</div><div>While I do not know exactly the formal procedure, I do not think=
 it is worth the effort to write a formal paper unless some of the honorabl=
e members of the honorable committee would show minimum interest to ever co=
nsider it. The reason of the brainstorming is to find together weaknesses o=
f the model and solutions for them.</div><div><br></div><div><br></div></di=
v></blockquote><div>I agree</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1189_1560861988.1423318011324--
------=_Part_1188_292565653.1423318011324--

.

On 7 February 2015 at 16:06,  <gmisocpp@gmail.com> wrote:
>> While I do not know exactly the formal procedure, I do not think it is
>> worth the effort to write a formal paper unless some of the honorable
>> members of the honorable committee would show minimum interest to ever
>> consider it. The reason of the brainstorming is to find together weaknesses
>> of the model and solutions for them.
> I agree


As far as I understand it, the idea deals with being able to express
interface-implementation splits in a way that doesn't incur size/abstraction
penalty. Some aspects of that are handled by modules, some probably
aren't. Overall, the "in size" "physical design" aspect of having to
state the types of members in a class definition can indeed be problematic
in the sense that you have to commit to the types in a class definition
regardless of whether the types are ever used by clients. There are
work-arounds(*) for that, so the question is whether language support
for such a facility is truly necessary and/or worth the cost of it.

(*) The work-arounds aren't necessarily easy - having a data buffer
in a class and having pimpl-side implementations know the actual
type of objects stored in such a buffer require proper alignment
and proper lifetime handling, which can be non-trivial.

--

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

.

--bcaec51969cd0f68bd050e80ad8d
Content-Type: text/plain; charset=UTF-8

>
> On 7 February 2015 at 16:06,  <gmisocpp@gmail.com> wrote:
> >> While I do not know exactly the formal procedure, I do not think it is
> >> worth the effort to write a formal paper unless some of the honorable
> >> members of the honorable committee would show minimum interest to ever
> >> consider it. The reason of the brainstorming is to find together
> weaknesses
> >> of the model and solutions for them.
> > I agree
>
>
> As far as I understand it, the idea deals with being able to express
> interface-implementation splits in a way that doesn't incur
> size/abstraction
> penalty. Some aspects of that are handled by modules, some probably
> aren't.

If you change the class definition, you need to recompile module +
everything depends on module.
If you split the stuff into to, you need to recompile only if you change
the real interface towards the rest of the world.
In my experience you spend 90% of time doing useless recompiles just
because you need to ad a damm' private method. If it is private why do I
need to recompile billions of lines of code in client code?

While this is not the only benefit the proposal would bring, it is the only
one that would have some way to deal with modules. Unfortunately though the
same benefit could not be achieved by modules.


> Overall, the "in size" "physical design" aspect of having to
> state the types of members in a class definition can indeed be problematic
> in the sense that you have to commit to the types in a class definition
> regardless of whether the types are ever used by clients. There are
> work-arounds(*) for that, so the question is whether language support
> for such a facility is truly necessary and/or worth the cost of it.
>
> (*) The work-arounds aren't necessarily easy - having a data buffer
> in a class and having pimpl-side implementations know the actual
> type of objects stored in such a buffer require proper alignment
> and proper lifetime handling, which can be non-trivial.


Of course there are work-arounds. Pimpl would be just an annoying hack that
would make inheritance difficult. Alignment and similar problems should be
the compilers problem.

"there is a workaround", pattern is often used, as most of the cases there
is a workaround. There is a workaround for any aspect for which C++ tries
to prove that it is inferior to C, including object oriented programming,
type safety, templates etc. You can implement dynamic type checking and you
will be on the safe side. You can implement constructs that mimic templates
at a very high cost, including some trivial text based templates etc. etc.
For everything there is a workaround. Unfortunately most of the cases it
turns out that work-arounds are ugly hacks with serious negative
consequences.

For me the equation is simple:
-> how many people/projects are using pimple?
-> why are they using pimple?
-> what is overhead to implement pimple for each class?
-> how much this overhead compromises the readibility of the code?
-> how many people/projects avoided pimple, just because pimple is ugly and
preferred to discard advantages concerning the binary interface

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><span>On 7 February 2015 at 16:06,=C2=A0 &lt;<a href=3D"mailto=
:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt; wrote:<br=
>
&gt;&gt; While I do not know exactly the formal procedure, I do not think i=
t is<br>
&gt;&gt; worth the effort to write a formal paper unless some of the honora=
ble<br>
&gt;&gt; members of the honorable committee would show minimum interest to =
ever<br>
&gt;&gt; consider it. The reason of the brainstorming is to find together w=
eaknesses<br>
&gt;&gt; of the model and solutions for them.<br>
&gt; I agree<br>
<br>
<br>
</span>As far as I understand it, the idea deals with being able to express=
<br>
interface-implementation splits in a way that doesn&#39;t incur size/abstra=
ction<br>
penalty. Some aspects of that are handled by modules, some probably<br>
aren&#39;t. </blockquote><div>If you change the class definition, you need =
to recompile module + everything depends on module.<br>If you split the stu=
ff into to, you need to recompile only if you change the real interface tow=
ards the rest of the world.</div><div>In my experience you spend 90% of tim=
e doing useless recompiles just because you need to ad a damm&#39; private =
method. If it is private why do I need to recompile billions of lines of co=
de in client code?</div><div><br></div><div>While this is not the only bene=
fit the proposal would bring, it is the only one that would have some way t=
o deal with modules. Unfortunately though the same benefit could not be ach=
ieved by modules.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">Overall, the &quot=
;in size&quot; &quot;physical design&quot; aspect of having to<br>
state the types of members in a class definition can indeed be problematic<=
br>
in the sense that you have to commit to the types in a class definition<br>
regardless of whether the types are ever used by clients. There are<br>
work-arounds(*) for that, so the question is whether language support<br>
for such a facility is truly necessary and/or worth the cost of it.<br>
<br>
(*) The work-arounds aren&#39;t necessarily easy - having a data buffer<br>
in a class and having pimpl-side implementations know the actual<br>
type of objects stored in such a buffer require proper alignment<br>
and proper lifetime handling, which can be non-trivial.</blockquote><div><b=
r></div><div>Of course there are work-arounds. Pimpl would be just an annoy=
ing hack that would make inheritance difficult. Alignment and similar probl=
ems should be the compilers problem.=C2=A0</div><div><br></div><div>&quot;t=
here is a workaround&quot;, pattern is often used, as most of the cases the=
re is a workaround. There is a workaround for any aspect for which C++ trie=
s to prove that it is inferior to C, including object oriented programming,=
 type safety, templates etc. You can implement dynamic type checking and yo=
u will be on the safe side. You can implement constructs that mimic templat=
es at a very high cost, including some trivial text based templates etc. et=
c. For everything there is a workaround. Unfortunately most of the cases it=
 turns out that work-arounds are ugly hacks with serious negative consequen=
ces.=C2=A0</div><div><br></div><div>For me the equation is simple:=C2=A0</d=
iv><div>-&gt; how many people/projects are using pimple?</div><div>-&gt; wh=
y are they using pimple?</div><div>-&gt; what is overhead to implement pimp=
le for each class?</div><div>-&gt; how much this overhead compromises the r=
eadibility of the code?</div><div>-&gt; how many people/projects avoided pi=
mple, just because pimple is ugly and preferred to discard advantages conce=
rning the binary interface=C2=A0</div><div><br></div><div><br></div><div><b=
r></div><div><br></div></div>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec51969cd0f68bd050e80ad8d--

.

This is a multi-part message in MIME format.
--------------030006020707090304080100
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 07/02/15 15:51, mobi phil a =C3=A9crit :
>
>     On 7 February 2015 at 16:06,  <gmisocpp@gmail.com
>     <mailto:gmisocpp@gmail.com>> wrote:
>     >> While I do not know exactly the formal procedure, I do not
>     think it is
>     >> worth the effort to write a formal paper unless some of the
>     honorable
>     >> members of the honorable committee would show minimum interest
>     to ever
>     >> consider it. The reason of the brainstorming is to find
>     together weaknesses
>     >> of the model and solutions for them.
>     > I agree
>
>
>     As far as I understand it, the idea deals with being able to express
>     interface-implementation splits in a way that doesn't incur
>     size/abstraction
>     penalty. Some aspects of that are handled by modules, some probably
>     aren't.=20
>
> If you change the class definition, you need to recompile module +=20
> everything depends on module.
I don't know well the module proposal, but I would expect that only=20
everything that depends on the public part of the module.
> If you split the stuff into to, you need to recompile only if you=20
> change the real interface towards the rest of the world.
I would expect modules would bring this.
> In my experience you spend 90% of time doing useless recompiles just=20
> because you need to ad a damm' private method. If it is private why do=20
> I need to recompile billions of lines of code in client code?
Agreed, there is no need.
>
> While this is not the only benefit the proposal would bring, it is the=20
> only one that would have some way to deal with modules. Unfortunately=20
> though the same benefit could not be achieved by modules.
Why? What is missing in modules so that we can achieve it?
>
>     Overall, the "in size" "physical design" aspect of having to
>     state the types of members in a class definition can indeed be
>     problematic
>     in the sense that you have to commit to the types in a class
>     definition
>     regardless of whether the types are ever used by clients. There are
>     work-arounds(*) for that, so the question is whether language support
>     for such a facility is truly necessary and/or worth the cost of it.
>
>     (*) The work-arounds aren't necessarily easy - having a data buffer
>     in a class and having pimpl-side implementations know the actual
>     type of objects stored in such a buffer require proper alignment
>     and proper lifetime handling, which can be non-trivial.
>
>
> Of course there are work-arounds. Pimpl would be just an annoying hack=20
> that would make inheritance difficult. Alignment and similar problems=20
> should be the compilers problem.
>
> "there is a workaround", pattern is often used, as most of the cases=20
> there is a workaround. There is a workaround for any aspect for which=20
> C++ tries to prove that it is inferior to C,
Don't forget that C++ includes C, so that anything you can do with C you=20
can do with C++.
> including object oriented programming, type safety, templates etc. You=20
> can implement dynamic type checking and you will be on the safe side.=20
> You can implement constructs that mimic templates at a very high cost,=20
> including some trivial text based templates etc. etc. For everything=20
> there is a workaround. Unfortunately most of the cases it turns out=20
> that work-arounds are ugly hacks with serious negative consequences.
>
> For me the equation is simple:
> -> how many people/projects are using pimple?
> -> why are they using pimple?
> -> what is overhead to implement pimple for each class?
> -> how much this overhead compromises the readibility of the code?
> -> how many people/projects avoided pimple, just because pimple is=20
> ugly and preferred to discard advantages concerning the binary interface
>
I don't think pimpl is the idiom needed to split the back and the white=20
parts of a class. IMHO, it is more the backdoor idiom that is needed.=20
The backdoor is the black part of your proposal.

C.hpp
-----
class C {
public:
     // public member functions declaration
protected:
     // protected member functions declaration
private:
     aligned_storage<N>storage;
     friend struct black;
};


C.cpp
-----

struct C::black {
   C& that_;
   black(C& that) : that_(that) {}
   struct private_ {... };
   static_assert(sizeof(private_) =3D=3D N, "Public and private sizes don't=
=20
match");
   private_& pdata() { return *reinterpret_cast<private_*>(that_.storage);}

   // Add here any private static or non static member
};

int C::f() {
   // use of the C::black(*this) for any private access, either for data=20
or private functions
   // use of C::black:: for any internal type or static member
}

My questions are:
* how many people/projects having compile time issues (millions of=20
lines) don't use this backdoor idiom?
* why?

I'm all for a future C++ in which we don't need this idiom, and I expect=20
that the Module proposal would provide it.

Vicente

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 07/02/15 15:51, mobi phil a =C3=A9cri=
t=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CAGMoNKv1gMCMs=3DbshkJQ23HqG=3DTvzpMOGJ8xv3N2KerRgU710w@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><span>On
                7 February 2015 at 16:06,=C2=A0 &lt;<a moz-do-not-send=3D"t=
rue"
                  href=3D"mailto:gmisocpp@gmail.com" target=3D"_blank">gmis=
ocpp@gmail.com</a>&gt;
                wrote:<br>
                &gt;&gt; While I do not know exactly the formal
                procedure, I do not think it is<br>
                &gt;&gt; worth the effort to write a formal paper unless
                some of the honorable<br>
                &gt;&gt; members of the honorable committee would show
                minimum interest to ever<br>
                &gt;&gt; consider it. The reason of the brainstorming is
                to find together weaknesses<br>
                &gt;&gt; of the model and solutions for them.<br>
                &gt; I agree<br>
                <br>
                <br>
              </span>As far as I understand it, the idea deals with
              being able to express<br>
              interface-implementation splits in a way that doesn't
              incur size/abstraction<br>
              penalty. Some aspects of that are handled by modules, some
              probably<br>
              aren't. </blockquote>
            <div>If you change the class definition, you need to
              recompile module + everything depends on module.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I don't know well the module proposal, but I would expect that only
    everything that depends on the public part of the module.<br>
    <blockquote
cite=3D"mid:CAGMoNKv1gMCMs=3DbshkJQ23HqG=3DTvzpMOGJ8xv3N2KerRgU710w@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>If you split the stuff into to, you need to recompile
              only if you change the real interface towards the rest of
              the world.</div>
          </div>
        </div>
      </div>
    </blockquote>
    I would expect modules would bring this.<br>
    <blockquote
cite=3D"mid:CAGMoNKv1gMCMs=3DbshkJQ23HqG=3DTvzpMOGJ8xv3N2KerRgU710w@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>In my experience you spend 90% of time doing useless
              recompiles just because you need to ad a damm' private
              method. If it is private why do I need to recompile
              billions of lines of code in client code?</div>
          </div>
        </div>
      </div>
    </blockquote>
    Agreed, there is no need.<br>
    <blockquote
cite=3D"mid:CAGMoNKv1gMCMs=3DbshkJQ23HqG=3DTvzpMOGJ8xv3N2KerRgU710w@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div><br>
            </div>
            <div>While this is not the only benefit the proposal would
              bring, it is the only one that would have some way to deal
              with modules. Unfortunately though the same benefit could
              not be achieved by modules.</div>
          </div>
        </div>
      </div>
    </blockquote>
    Why? What is missing in modules so that we can achieve it?<br>
    <blockquote
cite=3D"mid:CAGMoNKv1gMCMs=3DbshkJQ23HqG=3DTvzpMOGJ8xv3N2KerRgU710w@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">Overall,
              the "in size" "physical design" aspect of having to<br>
              state the types of members in a class definition can
              indeed be problematic<br>
              in the sense that you have to commit to the types in a
              class definition<br>
              regardless of whether the types are ever used by clients.
              There are<br>
              work-arounds(*) for that, so the question is whether
              language support<br>
              for such a facility is truly necessary and/or worth the
              cost of it.<br>
              <br>
              (*) The work-arounds aren't necessarily easy - having a
              data buffer<br>
              in a class and having pimpl-side implementations know the
              actual<br>
              type of objects stored in such a buffer require proper
              alignment<br>
              and proper lifetime handling, which can be non-trivial.</bloc=
kquote>
            <div><br>
            </div>
            <div>Of course there are work-arounds. Pimpl would be just
              an annoying hack that would make inheritance difficult.
              Alignment and similar problems should be the compilers
              problem.=C2=A0</div>
            <div><br>
            </div>
            <div>"there is a workaround", pattern is often used, as most
              of the cases there is a workaround. There is a workaround
              for any aspect for which C++ tries to prove that it is
              inferior to C, </div>
          </div>
        </div>
      </div>
    </blockquote>
    Don't forget that C++ includes C, so that anything you can do with C
    you can do with C++.<br>
    <blockquote
cite=3D"mid:CAGMoNKv1gMCMs=3DbshkJQ23HqG=3DTvzpMOGJ8xv3N2KerRgU710w@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>including object oriented programming, type safety,
              templates etc. You can implement dynamic type checking and
              you will be on the safe side. You can implement constructs
              that mimic templates at a very high cost, including some
              trivial text based templates etc. etc. For everything
              there is a workaround. Unfortunately most of the cases it
              turns out that work-arounds are ugly hacks with serious
              negative consequences.=C2=A0</div>
            <div><br>
            </div>
            <div>For me the equation is simple:=C2=A0</div>
            <div>-&gt; how many people/projects are using pimple?</div>
            <div>-&gt; why are they using pimple?</div>
            <div>-&gt; what is overhead to implement pimple for each
              class?</div>
            <div>-&gt; how much this overhead compromises the
              readibility of the code?</div>
            <div>-&gt; how many people/projects avoided pimple, just
              because pimple is ugly and preferred to discard advantages
              concerning the binary interface=C2=A0</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I don't think pimpl is the idiom needed to split the back and the
    white parts of a class. IMHO, it is more the backdoor idiom that is
    needed. The backdoor is the black part of your proposal.<br>
    <br>
    <font size=3D"+1">C.hpp<br>
      -----<br>
      class C {<br>
      public:<br>
      =C2=A0=C2=A0=C2=A0 // public member functions declaration<br>
      protected:<br>
      =C2=A0=C2=A0=C2=A0 // protected member functions declaration<br>
      private:<br>
      =C2=A0=C2=A0=C2=A0 aligned_storage&lt;N&gt;storage;<br>
      =C2=A0=C2=A0=C2=A0 friend struct black;<br>
    </font><font size=3D"+1">};<br>
      <br>
      <br>
      C.cpp<br>
      -----<br>
      <br>
      struct C::</font><font size=3D"+1"><font size=3D"+1">black</font> {</=
font><br>
    =C2=A0 C&amp; that_;<br>
    <font size=3D"+1"><font size=3D"+1">=C2=A0 black(C&amp; that) : that_(t=
hat)
        {}<br>
        =C2=A0 struct private_ {... };<br>
        =C2=A0 static_assert(sizeof(</font></font><font size=3D"+1"><font
        size=3D"+1">private_</font></font><font size=3D"+1"><font size=3D"+=
1"><font
          size=3D"+1"><font size=3D"+1">) =3D=3D N, "Public and private siz=
es
            don't match");=C2=A0 <br>
            =C2=A0 private_&amp; pdata() { return
            *reinterpret_cast&lt;private_*&gt;(that_.</font></font></font><=
/font><font
      size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><fo=
nt
              size=3D"+1">storage</font>);}<br>
            <br>
            =C2=A0 // Add here any private static or non static member<br>
          </font></font></font>};<br>
      <br>
      int C::f() {<br>
      =C2=A0 // use of the C::</font><font size=3D"+1"><font size=3D"+1">bl=
ack</font>(*this)
      for any private access, either for data or private functions<br>
      =C2=A0 // use of C::black:: for any internal type or static member<br=
>
      }</font><br>
    <br>
    My questions are:<br>
    * how many people/projects having compile time issues (millions of
    lines) don't use this backdoor idiom?<br>
    * why?<br>
    <br>
    I'm all for a future C++ in which we don't need this idiom, and I
    expect that the Module proposal would provide it.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------030006020707090304080100--

.

--089e011840384c0e54050e92b9f5
Content-Type: text/plain; charset=UTF-8

>
> If you split the stuff into to, you need to recompile only if you change
> the real interface towards the rest of the world.
>
> I would expect modules would bring this.
>

well, while I do not know in depth the modules proposal, I would rather
bet, that it will not be able to do the impossible. I have doubts that it
would be so clever, that will not force clients to recompile once you add
the declaration of a private method.


>   While this is not the only benefit the proposal would bring, it is the
> only one that would have some way to deal with modules. Unfortunately
> though the same benefit could not be achieved by modules.
>
> Why? What is missing in modules so that we can achieve it?
>

see above: IMHO modules will not be able to deal with
-> do not recompile client code if you add private method
-> do not recompile if you change class internal data
-> recompile only if the interface of a class changes, in best case if the
method definition that client code depends on changes.

Please note that this black-white proposal does not mean that all classes
have to behave this "dynamic" way.

>
> Of course there are work-arounds. Pimpl would be just an annoying hack
> that would make inheritance difficult. Alignment and similar problems
> should be the compilers problem.
>
>  "there is a workaround", pattern is often used, as most of the cases
> there is a workaround. There is a workaround for any aspect for which C++
> tries to prove that it is inferior to C,
>
> Don't forget that C++ includes C, so that anything you can do with C you
> can do with C++.
>

Thanks for telling me that... really forgot :) ... well trying to be a bit
sarcastic here ... Then please read it: "with the C core features"


>   including object oriented programming, type safety, templates etc. You
> can implement dynamic type checking and you will be on the safe side. You
> can implement constructs that mimic templates at a very high cost,
> including some trivial text based templates etc. etc. For everything there
> is a workaround. Unfortunately most of the cases it turns out that
> work-arounds are ugly hacks with serious negative consequences.
>
>  For me the equation is simple:
> -> how many people/projects are using pimple?
> -> why are they using pimple?
> -> what is overhead to implement pimple for each class?
> -> how much this overhead compromises the readibility of the code?
> -> how many people/projects avoided pimple, just because pimple is ugly
> and preferred to discard advantages concerning the binary interface
>
>    I don't think pimpl is the idiom needed to split the back and the
> white parts of a class. IMHO, it is more the backdoor idiom that is needed.
> The backdoor is the black part of your proposal.
>
> C.hpp
> -----
> class C {
> public:
>     // public member functions declaration
> protected:
>     // protected member functions declaration
> private:
>     aligned_storage<N>storage;
>     friend struct black;
> };
>
>
> C.cpp
> -----
>
> struct C::black {
>   C& that_;
>   black(C& that) : that_(that) {}
>   struct private_ {... };
>   static_assert(sizeof(private_) == N, "Public and private sizes don't
> match");
>   private_& pdata() { return *reinterpret_cast<private_*>(that_.storage);}
>
>   // Add here any private static or non static member
> };
>
> int C::f() {
>   // use of the C::black(*this) for any private access, either for data
> or private functions
>   // use of C::black:: for any internal type or static member
> }
>
> My questions are:
> * how many people/projects having compile time issues (millions of lines)
> don't use this backdoor idiom?
> * why?
>
> I'm all for a future C++ in which we don't need this idiom, and I expect
> that the Module proposal would provide it.
>

while you remove the problem of pimple, you introduce sthg. else, which my
proposal tries to solve. You are strongly depending on this N. Too loosen a
bit this dependency you could make at the beginning this N enough big, but
that would lead to waste of memory.

My proposal covers the fact that this "N" is  practically replaced at
runtime, with the real size.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><span =
class=3D""><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div>If you split the stuff into to, you n=
eed to recompile
              only if you change the real interface towards the rest of
              the world.</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    I would expect modules would bring this.</div></blockquote><div><br></d=
iv><div>well, while I do not know in depth the modules proposal, I would ra=
ther bet, that it will not be able to do the impossible. I have doubts that=
 it would be so clever, that will not force clients to recompile once you a=
dd the declaration of a private method.=C2=A0</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><span cla=
ss=3D"">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>While this is not the only benefit the proposal would
              bring, it is the only one that would have some way to deal
              with modules. Unfortunately though the same benefit could
              not be achieved by modules.<br></div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Why? What is missing in modules so that we can achieve it?</div></block=
quote><div><br></div><div>see above: IMHO modules will not be able to deal =
with</div><div>-&gt; do not recompile client code if you add private method=
</div><div>-&gt; do not recompile if you change class internal data</div><d=
iv>-&gt; recompile only if the interface of a class changes, in best case i=
f the method definition that client code depends on changes.</div><div>=C2=
=A0<br></div><div>Please note that this black-white proposal does not mean =
that all classes have to behave this &quot;dynamic&quot; way.</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><span clas=
s=3D""><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div><br></div>
            <div>Of course there are work-arounds. Pimpl would be just
              an annoying hack that would make inheritance difficult.
              Alignment and similar problems should be the compilers
              problem.=C2=A0</div>
            <div><br>
            </div>
            <div>&quot;there is a workaround&quot;, pattern is often used, =
as most
              of the cases there is a workaround. There is a workaround
              for any aspect for which C++ tries to prove that it is
              inferior to C, </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Don&#39;t forget that C++ includes C, so that anything you can do with =
C
    you can do with C++.</div></blockquote><div><br></div><div>Thanks for t=
elling me that... really forgot :) ... well trying to be a bit sarcastic he=
re ... Then please read it: &quot;with the C core features&quot;</div><div>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" tex=
t=3D"#000000"><span class=3D"">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>including object oriented programming, type safety,
              templates etc. You can implement dynamic type checking and
              you will be on the safe side. You can implement constructs
              that mimic templates at a very high cost, including some
              trivial text based templates etc. etc. For everything
              there is a workaround. Unfortunately most of the cases it
              turns out that work-arounds are ugly hacks with serious
              negative consequences.=C2=A0</div>
            <div><br>
            </div>
            <div>For me the equation is simple:=C2=A0</div>
            <div>-&gt; how many people/projects are using pimple?</div>
            <div>-&gt; why are they using pimple?</div>
            <div>-&gt; what is overhead to implement pimple for each
              class?</div>
            <div>-&gt; how much this overhead compromises the
              readibility of the code?</div>
            <div>-&gt; how many people/projects avoided pimple, just
              because pimple is ugly and preferred to discard advantages
              concerning the binary interface=C2=A0</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    I don&#39;t think pimpl is the idiom needed to split the back and the
    white parts of a class. IMHO, it is more the backdoor idiom that is
    needed. The backdoor is the black part of your proposal.<br>
    <br>
    <font size=3D"+1">C.hpp<br>
      -----<br>
      class C {<br>
      public:<br>
      =C2=A0=C2=A0=C2=A0 // public member functions declaration<br>
      protected:<br>
      =C2=A0=C2=A0=C2=A0 // protected member functions declaration<br>
      private:<br>
      =C2=A0=C2=A0=C2=A0 aligned_storage&lt;N&gt;storage;<br>
      =C2=A0=C2=A0=C2=A0 friend struct black;<br>
    </font><font size=3D"+1">};<br>
      <br>
      <br>
      C.cpp<br>
      -----<br>
      <br>
      struct C::</font><font size=3D"+1"><font size=3D"+1">black</font> {</=
font><br>
    =C2=A0 C&amp; that_;<br>
    <font size=3D"+1"><font size=3D"+1">=C2=A0 black(C&amp; that) : that_(t=
hat)
        {}<br>
        =C2=A0 struct private_ {... };<br>
        =C2=A0 static_assert(sizeof(</font></font><font size=3D"+1"><font s=
ize=3D"+1">private_</font></font><font size=3D"+1"><font size=3D"+1"><font =
size=3D"+1"><font size=3D"+1">) =3D=3D N, &quot;Public and private sizes
            don&#39;t match&quot;);=C2=A0 <br>
            =C2=A0 private_&amp; pdata() { return
            *reinterpret_cast&lt;private_*&gt;(that_.</font></font></font><=
/font><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+=
1"><font size=3D"+1">storage</font>);}<br>
            <br>
            =C2=A0 // Add here any private static or non static member<br>
          </font></font></font>};<br>
      <br>
      int C::f() {<br>
      =C2=A0 // use of the C::</font><font size=3D"+1"><font size=3D"+1">bl=
ack</font>(*this)
      for any private access, either for data or private functions<br>
      =C2=A0 // use of C::black:: for any internal type or static member<br=
>
      }</font><br>
    <br>
    My questions are:<br>
    * how many people/projects having compile time issues (millions of
    lines) don&#39;t use this backdoor idiom?<br>
    * why?<br>
    <br>
    I&#39;m all for a future C++ in which we don&#39;t need this idiom, and=
 I
    expect that the Module proposal would provide it.</div></blockquote><di=
v><br></div><div>while you remove the problem of pimple, you introduce sthg=
.. else, which my proposal tries to solve. You are strongly depending on thi=
s N. Too loosen a bit this dependency you could make at the beginning this =
N enough big, but that would lead to waste of memory.=C2=A0<br><br>My propo=
sal covers the fact that this &quot;N&quot; is =C2=A0practically replaced a=
t runtime, with the real size.</div><div><br></div></div>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e011840384c0e54050e92b9f5--

.

This is a multi-part message in MIME format.
--------------090601080407010305060407
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 08/02/15 13:23, mobi phil a =C3=A9crit :
>
>>     If you split the stuff into to, you need to recompile only if you
>>     change the real interface towards the rest of the world.
>     I would expect modules would bring this.
>
>
> well, while I do not know in depth the modules proposal, I would=20
> rather bet, that it will not be able to do the impossible. I have=20
> doubts that it would be so clever, that will not force clients to=20
> recompile once you add the declaration of a private method.
IMO, this should be possible and so it is a QOI. Only if the=20
implementers consider that this wouldn't be possible or too complex we=20
would need to adapt the proposal.
>
>>     While this is not the only benefit the proposal would bring, it
>>     is the only one that would have some way to deal with modules.
>>     Unfortunately though the same benefit could not be achieved by
>>     modules.
>     Why? What is missing in modules so that we can achieve it?
>
>
> see above: IMHO modules will not be able to deal with
> -> do not recompile client code if you add private method
> -> do not recompile if you change class internal data
> -> recompile only if the interface of a class changes, in best case if=20
> the method definition that client code depends on changes.
IMHO, it should be easier to ensure that the module proposal is able to=20
do it that adding your alternative approach.
>
> Please note that this black-white proposal does not mean that all=20
> classes have to behave this "dynamic" way.
I don't see anything dynamic in the behavior you have defined.
> <snip>
>
>>
>>     For me the equation is simple:
>>     -> how many people/projects are using pimple?
>>     -> why are they using pimple?
>>     -> what is overhead to implement pimple for each class?
>>     -> how much this overhead compromises the readibility of the code?
>>     -> how many people/projects avoided pimple, just because pimple
>>     is ugly and preferred to discard advantages concerning the binary
>>     interface
>>
>     I don't think pimpl is the idiom needed to split the back and the
>     white parts of a class. IMHO, it is more the backdoor idiom that
>     is needed. The backdoor is the black part of your proposal.
>
>     <snip>
>
>     I'm all for a future C++ in which we don't need this idiom, and I
>     expect that the Module proposal would provide it.
>
>
> while you remove the problem of pimple, you introduce sthg. else,=20
> which my proposal tries to solve. You are strongly depending on this=20
> N. Too loosen a bit this dependency you could make at the beginning=20
> this N enough big, but that would lead to waste of memory.
>
There is not big or small, just are equals or not. This N, should be=20
provided by the compiler from the module definition as well as all other=20
public and protected functions.
> My proposal covers the fact that this "N" is  practically replaced at=20
> runtime, with the real size.
>
>
We don't need it at run-time, but at compile time, and IMO, the Module=20
proposal should be such that such implementation is possible.

After reading the module proposal, it seams that, they are not=20
addressing this problem. I suggest you to join the Module ML and request=20
for the requirements you are looking for (not the solutions). Maybe your=20
white/black split could be the solution.

c++std-modules@accu.org

Vicente

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 08/02/15 13:23, mobi phil a =C3=A9cri=
t=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CAGMoNKs2LqVubLSrq4YEBHr5+1pU5Meqbdo--URf+PHDfSVGuw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr">
                      <div class=3D"gmail_extra">
                        <div class=3D"gmail_quote">
                          <div>If you split the stuff into to, you need
                            to recompile only if you change the real
                            interface towards the rest of the world.</div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span> I would expect modules would bring this.</div>
            </blockquote>
            <div><br>
            </div>
            <div>well, while I do not know in depth the modules
              proposal, I would rather bet, that it will not be able to
              do the impossible. I have doubts that it would be so
              clever, that will not force clients to recompile once you
              add the declaration of a private method. <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    IMO, this should be possible and so it is a QOI. Only if the
    implementers consider that this wouldn't be possible or too complex
    we would need to adapt the proposal.<br>
    <blockquote
cite=3D"mid:CAGMoNKs2LqVubLSrq4YEBHr5+1pU5Meqbdo--URf+PHDfSVGuw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr">
                      <div class=3D"gmail_extra">
                        <div class=3D"gmail_quote">
                          <div>While this is not the only benefit the
                            proposal would bring, it is the only one
                            that would have some way to deal with
                            modules. Unfortunately though the same
                            benefit could not be achieved by modules.<br>
                          </div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span> Why? What is missing in modules so that we can
                achieve it?</div>
            </blockquote>
            <div><br>
            </div>
            <div>see above: IMHO modules will not be able to deal with</div=
>
            <div>-&gt; do not recompile client code if you add private
              method</div>
            <div>-&gt; do not recompile if you change class internal
              data</div>
            <div>-&gt; recompile only if the interface of a class
              changes, in best case if the method definition that client
              code depends on changes.</div>
          </div>
        </div>
      </div>
    </blockquote>
    IMHO, it should be easier to ensure that the module proposal is able
    to do it that adding your alternative approach.<br>
    <blockquote
cite=3D"mid:CAGMoNKs2LqVubLSrq4YEBHr5+1pU5Meqbdo--URf+PHDfSVGuw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>=C2=A0<br>
            </div>
            <div>Please note that this black-white proposal does not
              mean that all classes have to behave this "dynamic" way.</div=
>
          </div>
        </div>
      </div>
    </blockquote>
    I don't see anything dynamic in the behavior you have defined.<br>
    <blockquote
cite=3D"mid:CAGMoNKs2LqVubLSrq4YEBHr5+1pU5Meqbdo--URf+PHDfSVGuw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">&lt;snip&gt; <br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr">
                      <div class=3D"gmail_extra">
                        <div class=3D"gmail_quote"><br>
                          <div>For me the equation is simple:=C2=A0</div>
                          <div>-&gt; how many people/projects are using
                            pimple?</div>
                          <div>-&gt; why are they using pimple?</div>
                          <div>-&gt; what is overhead to implement
                            pimple for each class?</div>
                          <div>-&gt; how much this overhead compromises
                            the readibility of the code?</div>
                          <div>-&gt; how many people/projects avoided
                            pimple, just because pimple is ugly and
                            preferred to discard advantages concerning
                            the binary interface=C2=A0</div>
                          <div><br>
                          </div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span> I don't think pimpl is the idiom needed to split
                the back and the white parts of a class. IMHO, it is
                more the backdoor idiom that is needed. The backdoor is
                the black part of your proposal.<br>
                <br>
                &lt;snip&gt;<br>
                <br>
                I'm all for a future C++ in which we don't need this
                idiom, and I expect that the Module proposal would
                provide it.</div>
            </blockquote>
            <div><br>
            </div>
            <div>while you remove the problem of pimple, you introduce
              sthg. else, which my proposal tries to solve. You are
              strongly depending on this N. Too loosen a bit this
              dependency you could make at the beginning this N enough
              big, but that would lead to waste of memory.=C2=A0<br>
              <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    There is not big or small, just are equals or not. This N, should be
    provided by the compiler from the module definition as well as all
    other public and protected functions.<br>
    <blockquote
cite=3D"mid:CAGMoNKs2LqVubLSrq4YEBHr5+1pU5Meqbdo--URf+PHDfSVGuw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>My proposal covers the fact that this "N" is
              =C2=A0practically replaced at runtime, with the real size.</d=
iv>
            <div><br>
            </div>
          </div>
        </div>
      </div>
      <br>
    </blockquote>
    We don't need it at run-time, but at compile time, and IMO, the
    Module proposal should be such that such implementation is possible.<br=
>
    <br>
    After reading the module proposal, it seams that, they are not
    addressing this problem. I suggest you to join the Module ML and
    request for the requirements you are looking for (not the
    solutions). Maybe your white/black split could be the solution.<br>
    <pre wrap=3D""><a class=3D"moz-txt-link-abbreviated" href=3D"mailto:c++=
std-modules@accu.org">c++std-modules@accu.org</a></pre>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------090601080407010305060407--

.

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

>
> Le 08/02/15 13:23, mobi phil a =C3=A9crit :
>
>      If you split the stuff into to, you need to recompile only if you
>> change the real interface towards the rest of the world.
>>
>>  I would expect modules would bring this.
>>
>
>  well, while I do not know in depth the modules proposal, I would rather
> bet, that it will not be able to do the impossible. I have doubts that it
> would be so clever, that will not force clients to recompile once you add
> the declaration of a private method.
>
> IMO, this should be possible and so it is a QOI. Only if the implementers
> consider that this wouldn't be possible or too complex we would need to
> adapt the proposal.
>

I do not pretend that I know the proposal, I have some basic idea of how
clang is doing it. Without going into the details I think there are two
things that needs to be looked at separated:
-> if the header changes, the module that depends on it needs to be rebuilt=
..
-> the way at least clang approached it, you still need to work with
makefile dependencies.

If you changed the header, the timestamp, checksum, or whatsoever way you
would implement dependencies, the source file that depends on the header in
question will have to be rebuilt. This must be true even in case where you
add a private method, unless a special file is generated for dependencies
that reflect only really "public" stuff from headers.



> While this is not the only benefit the proposal would bring, it is the
>> only one that would have some way to deal with modules. Unfortunately
>> though the same benefit could not be achieved by modules.
>>
>>  Why? What is missing in modules so that we can achieve it?
>>
>
>  see above: IMHO modules will not be able to deal with
> -> do not recompile client code if you add private method
> -> do not recompile if you change class internal data
> -> recompile only if the interface of a class changes, in best case if th=
e
> method definition that client code depends on changes.
>
> IMHO, it should be easier to ensure that the module proposal is able to d=
o
> it that adding your alternative approach.
>

While reducing dependencies is one of the goals of my approach/proposal I
really doubt that handling private data changes in headers will be delt
with modules. For simple reason that any source file that depends on the
definition of the class (due to sizeof()) will need to recompile once the
size of the class changes. In my proposal this dependency is postponed till
runtime.


> Please note that this black-white proposal does not mean that all classes
> have to behave this "dynamic" way.
>
> I don't see anything dynamic in the behavior you have defined.
>

Well, do not wonder, I have the impression that you did not understand the
main idea.
Did you carefully read the original post? Sorry, but I doubt

Let's rewrite the reasoning with different perspective
-> What do we want?
->>> to really hide private part of a class
--->>>> private methods
--->>>> private data
-> What is the main problem with this?
--->>>> private methods: not really.. they are forced to be declared in the
class declaration, without any reason, so no problem to remove
--->>>> private data: well... this is the problem, as "client" classes need
to know the size of the class

---> solution: make any local/global/heap allocation depending on a
"global" variable that will be known at dynamic linking

while this would open doors for other dynamic things, you already see a
little "dynamic" here.

while you remove the problem of pimple, you introduce sthg. else, which my
> proposal tries to solve. You are strongly depending on this N. Too loosen=
 a
> bit this dependency you could make at the beginning this N enough big, bu=
t
> that would lead to waste of memory.
>
>    There is not big or small, just are equals or not. This N, should be
> provided by the compiler from the module definition as well as all other
> public and protected functions.
>
>   My proposal covers the fact that this "N" is  practically replaced at
> runtime, with the real size.
>
>  We don't need it at run-time, but at compile time, and IMO, the Module
> proposal should be such that such implementation is possible.
>

Well, while do not know who are the "we" I need it and I see tha major
advantage. Whatsoever way you define N at compile time, you will force
everybody who depends on N to rebuild once you change the size of the
implementation which is exactly the thing I want to achieve among others.

Another point of this "dynamic" classes is that you could use C++ classes
from dynamic libraries without any pimpl overhead.


>
> After reading the module proposal, it seams that, they are not addressing
> this problem. I suggest you to join the Module ML and request for the
> requirements you are looking for (not the solutions). Maybe your
> white/black split could be the solution.
>
> c++std-modules@accu.org
>
> No problem to help there, but personally I fail to see that this could be
done with modules...

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><div>Le 08/02/15 13:=
23, mobi phil a =C3=A9crit=C2=A0:<br>
    </div><span class=3D"">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
              <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span>
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr">
                      <div class=3D"gmail_extra">
                        <div class=3D"gmail_quote">
                          <div>If you split the stuff into to, you need
                            to recompile only if you change the real
                            interface towards the rest of the world.</div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span> I would expect modules would bring this.</div>
            </blockquote>
            <div><br>
            </div>
            <div>well, while I do not know in depth the modules
              proposal, I would rather bet, that it will not be able to
              do the impossible. I have doubts that it would be so
              clever, that will not force clients to recompile once you
              add the declaration of a private method. <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    IMO, this should be possible and so it is a QOI. Only if the
    implementers consider that this wouldn&#39;t be possible or too complex
    we would need to adapt the proposal.</div></blockquote><div><br></div><=
div>I do not pretend that I know the proposal, I have some basic idea of ho=
w clang is doing it. Without going into the details I think there are two t=
hings that needs to be looked at separated:</div><div>-&gt; if the header c=
hanges, the module that depends on it needs to be rebuilt.<br></div><div>-&=
gt; the way at least clang approached it, you still need to work with makef=
ile dependencies.</div><div><br></div><div>If you changed the header, the t=
imestamp, checksum, or whatsoever way you would implement dependencies, the=
 source file that depends on the header in question will have to be rebuilt=
.. This must be true even in case where you add a private method, unless a s=
pecial file is generated for dependencies that reflect only really &quot;pu=
blic&quot; stuff from headers.</div><div><br></div><div>=C2=A0<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D""><b=
lockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#0000=
00"><span><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div>While this is not the only benefit the
                            proposal would bring, it is the only one
                            that would have some way to deal with
                            modules. Unfortunately though the same
                            benefit could not be achieved by modules.<br>
                          </div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span> Why? What is missing in modules so that we can
                achieve it?</div>
            </blockquote>
            <div><br>
            </div>
            <div>see above: IMHO modules will not be able to deal with</div=
>
            <div>-&gt; do not recompile client code if you add private
              method</div>
            <div>-&gt; do not recompile if you change class internal
              data</div>
            <div>-&gt; recompile only if the interface of a class
              changes, in best case if the method definition that client
              code depends on changes.</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    IMHO, it should be easier to ensure that the module proposal is able
    to do it that adding your alternative approach.</div></blockquote><div>=
<br></div><div>While reducing dependencies is one of the goals of my approa=
ch/proposal I really doubt that handling private data changes in headers wi=
ll be delt with modules. For simple reason that any source file that depend=
s on the definition of the class (due to sizeof()) will need to recompile o=
nce the size of the class changes. In my proposal this dependency is postpo=
ned till runtime.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000"><span class=3D""><blockquote type=3D"cite"><d=
iv dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>P=
lease note that this black-white proposal does not
              mean that all classes have to behave this &quot;dynamic&quot;=
 way.<br></div>
          </div>
        </div>
      </div>
    </blockquote></span>
    I don&#39;t see anything dynamic in the behavior you have defined.<br><=
/div></blockquote><div><br></div><div>Well, do not wonder, I have the impre=
ssion that you did not understand the main idea.=C2=A0</div><div>Did you ca=
refully read the original post? Sorry, but I doubt</div><div><br>Let&#39;s =
rewrite the reasoning with different perspective</div><div>-&gt; What do we=
 want?</div><div>-&gt;&gt;&gt; to really hide private part of a class=C2=A0=
</div><div>---&gt;&gt;&gt;&gt; private methods</div><div>---&gt;&gt;&gt;&gt=
; private data<br></div><div>-&gt; What is the main problem with this?</div=
><div>---&gt;&gt;&gt;&gt; private methods: not really.. they are forced to =
be declared in the class declaration, without any reason, so no problem to =
remove</div><div>---&gt;&gt;&gt;&gt; private data: well... this is the prob=
lem, as &quot;client&quot; classes need to know the size of the class</div>=
<div><br></div><div>---&gt; solution: make any local/global/heap allocation=
 depending on a &quot;global&quot; variable that will be known at dynamic l=
inking</div><div><br></div><div>while this would open doors for other dynam=
ic things, you already see a little &quot;dynamic&quot; here.</div><div><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><blockquo=
te type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><span class=3D""><div>while you remove the problem of pimple, =
you introduce
              sthg. else, which my proposal tries to solve. You are
              strongly depending on this N. Too loosen a bit this
              dependency you could make at the beginning this N enough
              big, but that would lead to waste of memory.=C2=A0<br>
              <br>
            </div>
          </span></div>
        </div>
      </div>
    </blockquote>
    There is not big or small, just are equals or not. This N, should be
    provided by the compiler from the module definition as well as all
    other public and protected functions.<span class=3D""><br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>My proposal covers the fact that this &quot;N&quot; is
              =C2=A0practically replaced at runtime, with the real size.</d=
iv>
            <div><br></div></div></div></div>
    </blockquote></span>
    We don&#39;t need it at run-time, but at compile time, and IMO, the
    Module proposal should be such that such implementation is possible.<br=
></div></blockquote><div><br></div><div>Well, while do not know who are the=
 &quot;we&quot; I need it and I see tha major advantage. Whatsoever way you=
 define N at compile time, you will force everybody who depends on N to reb=
uild once you change the size of the implementation which is exactly the th=
ing I want to achieve among others.=C2=A0</div><div><br></div><div>Another =
point of this &quot;dynamic&quot; classes is that you could use C++ classes=
 from dynamic libraries without any pimpl overhead.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    After reading the module proposal, it seams that, they are not
    addressing this problem. I suggest you to join the Module ML and
    request for the requirements you are looking for (not the
    solutions). Maybe your white/black split could be the solution.<br>
    <pre><a href=3D"mailto:c++std-modules@accu.org" target=3D"_blank">c++st=
d-modules@accu.org</a></pre></div></blockquote><div>No problem to help ther=
e, but personally I fail to see that this could be done with modules...</di=
v></div>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ec45a31fa83050e96c9f2--

.

On Sunday 08 February 2015 18:14:26 mobi phil wrote:
> If you changed the header, the timestamp, checksum, or whatsoever way you
> would implement dependencies, the source file that depends on the header in
> question will have to be rebuilt. This must be true even in case where you
> add a private method, unless a special file is generated for dependencies
> that reflect only really "public" stuff from headers.

Unless, of course, that class has friends. In which case, even private changes
will require rebuilding.

> While reducing dependencies is one of the goals of my approach/proposal I
> really doubt that handling private data changes in headers will be delt
> with modules. For simple reason that any source file that depends on the
> definition of the class (due to sizeof()) will need to recompile once the
> size of the class changes. In my proposal this dependency is postponed till
> runtime.

Your idea, not proposal. You need to do a little more work to make it a
proposal, including writing a paper and presenting it in a committee meeting.
Or convincing someone to do it for you.

> > After reading the module proposal, it seams that, they are not addressing
> > this problem. I suggest you to join the Module ML and request for the
> > requirements you are looking for (not the solutions). Maybe your
> > white/black split could be the solution.
> >
> > c++std-modules@accu.org
> >
> > No problem to help there, but personally I fail to see that this could be
>
> done with modules...

Are you saying that modules would make it impossible to implement your
suggestion?

Because if you aren't saying that, then you're missing the point. We're not
saying that modules is doing what you suggested. We are saying that you should
join the modules discussion so that your solution gets worked into the modules
proposal.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--bcaec51969cd2863ab050e97ab29
Content-Type: text/plain; charset=UTF-8

>
> On Sunday 08 February 2015 18:14:26 mobi phil wrote:
> > If you changed the header, the timestamp, checksum, or whatsoever way you
> > would implement dependencies, the source file that depends on the header
> in
> > question will have to be rebuilt. This must be true even in case where
> you
> > add a private method, unless a special file is generated for dependencies
> > that reflect only really "public" stuff from headers.
>
> Unless, of course, that class has friends. In which case, even private
> changes
> will require rebuilding.
>

Friendship as always should be sometimes reconsidered. If not really
necessary for performance reason, just use getters/setters.
But if really necessary and most of the time friends like to be together,
most of the time they are close to each other.
Such friendship would be declared in the black, and friends may/should know
about blacks, but they should not propagate this dependency.

inside A.h

white  A { /* white is the real iterface, could be called "class iface"

}

inside A.cpp

black A {


friend black F;
}

inside F.cpp
#include "A.cpp"
#include "F.h"

the black of A could also be factored into A.black.h, that would be
included by both A.cpp and F.cpp


> While reducing dependencies is one of the goals of my approach/proposal I
> > really doubt that handling private data changes in headers will be delt
> > with modules. For simple reason that any source file that depends on the
> > definition of the class (due to sizeof()) will need to recompile once the
> > size of the class changes. In my proposal this dependency is postponed
> till
> > runtime.
>
> Your idea, not proposal. You need to do a little more work to make it a
> proposal, including writing a paper and presenting it in a committee
> meeting.
> Or convincing someone to do it for you.
>

Let's not get lost in words. It is a proposal, though it is not a formal
one. It was not just an idea, I thought about at coffee time. Have it in my
mind for a while and though about certain aspects. While I wanted to
implement it in pure C with macros, gave up. Though could reformulate the
original post, do not feel at the moment it would be worth to go into a
deep analyzis if the added value is not recognized.


> > > After reading the module proposal, it seams that, they are not
> addressing
> > > this problem. I suggest you to join the Module ML and request for the
> > > requirements you are looking for (not the solutions). Maybe your
> > > white/black split could be the solution.
> > >
> > > c++std-modules@accu.org
> > >
> > > No problem to help there, but personally I fail to see that this could
> be
> >
> > done with modules...
>
> Are you saying that modules would make it impossible to implement your

suggestion?
>

Because if you aren't saying that, then you're missing the point. We're not
> saying that modules is doing what you suggested. We are saying that you
> should
> join the modules discussion so that your solution gets worked into the
> modules
> proposal.
>

To avoid further confusion: I am not saying anything else than that I have
strong doubts that this could be worked in some way into modules if you do
not add the necessary language extension. Once you added those extensions,
should be treated as a separate story as it involves mainly non-module
related changes.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">On Sunday 08 February 2015 18:1=
4:26 mobi phil wrote:<br>
&gt; If you changed the header, the timestamp, checksum, or whatsoever way =
you<br>
&gt; would implement dependencies, the source file that depends on the head=
er in<br>
&gt; question will have to be rebuilt. This must be true even in case where=
 you<br>
&gt; add a private method, unless a special file is generated for dependenc=
ies<br>
&gt; that reflect only really &quot;public&quot; stuff from headers.<br>
<br>
</span>Unless, of course, that class has friends. In which case, even priva=
te changes<br>
will require rebuilding.<br></blockquote><div><br></div><div>Friendship as =
always should be sometimes reconsidered. If not really necessary for perfor=
mance reason, just use getters/setters.</div><div>But if really necessary a=
nd most of the time friends like to be together, most of the time they are =
close to each other.</div><div>Such friendship would be declared in the bla=
ck, and friends may/should know about blacks, but they should not propagate=
 this dependency.=C2=A0</div><div><br></div><div>inside A.h</div><div><br><=
/div><div>white =C2=A0A { /* white is the real iterface, could be called &q=
uot;class iface&quot;=C2=A0</div><div><br></div><div>}</div><div><br></div>=
<div>inside A.cpp</div><div><br></div><div>black A {</div><div><br></div><d=
iv><br></div><div>friend black F;<br>}</div><div><br></div><div>inside F.cp=
p</div><div>#include &quot;A.cpp&quot;</div><div>#include &quot;F.h&quot;=
=C2=A0</div><div><br></div><div>the black of A could also be factored into =
A.black.h, that would be included by both A.cpp and F.cpp</div><div><br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt; Whil=
e reducing dependencies is one of the goals of my approach/proposal I<br>
&gt; really doubt that handling private data changes in headers will be del=
t<br>
&gt; with modules. For simple reason that any source file that depends on t=
he<br>
&gt; definition of the class (due to sizeof()) will need to recompile once =
the<br>
&gt; size of the class changes. In my proposal this dependency is postponed=
 till<br>
&gt; runtime.<br>
<br>
</span>Your idea, not proposal. You need to do a little more work to make i=
t a<br>
proposal, including writing a paper and presenting it in a committee meetin=
g.<br>
Or convincing someone to do it for you.<br></blockquote><div><br></div><div=
>Let&#39;s not get lost in words. It is a proposal, though it is not a form=
al one. It was not just an idea, I thought about at coffee time. Have it in=
 my mind for a while and though about certain aspects. While I wanted to im=
plement it in pure C with macros, gave up. Though could reformulate the ori=
ginal post, do not feel at the moment it would be worth to go into a deep a=
nalyzis if the added value is not recognized.=C2=A0</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><span class=3D"">&gt; &gt; After reading the =
module proposal, it seams that, they are not addressing<br>
&gt; &gt; this problem. I suggest you to join the Module ML and request for=
 the<br>
&gt; &gt; requirements you are looking for (not the solutions). Maybe your<=
br>
&gt; &gt; white/black split could be the solution.<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"mailto:c%2B%2Bstd-modules@accu.org">c++std-modules@acc=
u.org</a><br>
&gt; &gt;<br>
&gt; &gt; No problem to help there, but personally I fail to see that this =
could be<br>
&gt;<br>
&gt; done with modules...<br>
<br>
</span>Are you saying that modules would make it impossible to implement yo=
ur=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">suggestion?<br></blockq=
uote><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">Because if you aren&#39;=
t saying that, then you&#39;re missing the point. We&#39;re not<br>
saying that modules is doing what you suggested. We are saying that you sho=
uld<br>
join the modules discussion so that your solution gets worked into the modu=
les<br>
proposal.<br></blockquote><div><br></div><div>To avoid further confusion: I=
 am not saying anything else than that I have strong doubts that this could=
 be worked in some way into modules if you do not add the necessary languag=
e extension. Once you added those extensions, should be treated as a separa=
te story as it involves mainly non-module related changes.</div><div><br></=
div><div><br></div><div><br></div></div>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec51969cd2863ab050e97ab29--

.

On Sunday 08 February 2015 19:17:37 mobi phil wrote:
> > On Sunday 08 February 2015 18:14:26 mobi phil wrote:
> > Unless, of course, that class has friends. In which case, even private
> > changes
> > will require rebuilding.
>
> Friendship as always should be sometimes reconsidered. If not really
> necessary for performance reason, just use getters/setters.

That's advice. Unless forbid the practice, the advice can be ignored and you
have to deal with it.

It's irrelevant whether it's a bad practice or not.

> But if really necessary and most of the time friends like to be together,
> most of the time they are close to each other.
> Such friendship would be declared in the black, and friends may/should know
> about blacks, but they should not propagate this dependency.
>
> inside A.h
>
> white  A { /* white is the real iterface, could be called "class iface"
>
> }
>
> inside A.cpp
>
> black A {
>
>
> friend black F;
> }
>
> inside F.cpp
> #include "A.cpp"
> #include "F.h"
>
> the black of A could also be factored into A.black.h, that would be
> included by both A.cpp and F.cpp

Sounds like advice. Therefore, it can be ignored.

> Let's not get lost in words. It is a proposal, though it is not a formal
> one. It was not just an idea, I thought about at coffee time. Have it in my
> mind for a while and though about certain aspects. While I wanted to
> implement it in pure C with macros, gave up. Though could reformulate the
> original post, do not feel at the moment it would be worth to go into a
> deep analyzis if the added value is not recognized.

What recognition are you expecting before you go further?

> > Are you saying that modules would make it impossible to implement your
> > suggestion?
> > Because if you aren't saying that, then you're missing the point. We're
not
> > saying that modules is doing what you suggested. We are saying that you
> > should
> > join the modules discussion so that your solution gets worked into the
> > modules
> > proposal.
>
> To avoid further confusion: I am not saying anything else than that I have
> strong doubts that this could be worked in some way into modules if you do
> not add the necessary language extension. Once you added those extensions,
> should be treated as a separate story as it involves mainly non-module
> related changes.

Understood.

I still recommend talking to the people doing modules because they may have
other points to bring up and they're the right people to help you with your
suggestion.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--20cf3040ebf4738f21050e9816bd
Content-Type: text/plain; charset=UTF-8

>
> On Sunday 08 February 2015 19:17:37 mobi phil wrote:
> > > On Sunday 08 February 2015 18:14:26 mobi phil wrote:
> > > Unless, of course, that class has friends. In which case, even private
> > > changes
> > > will require rebuilding.
> >
> > Friendship as always should be sometimes reconsidered. If not really
> > necessary for performance reason, just use getters/setters.
>
> That's advice. Unless forbid the practice, the advice can be ignored and
> you
> have to deal with it.
>
> It's irrelevant whether it's a bad practice or not.
>

while this new construct has to have a different name than "class" or
another keyword attached to it, it is straightforward to turn the above
into a rule by forbidding friend keyword inside the body of with the white.


> Though could reformulate the
> > original post, do not feel at the moment it would be worth to go into a
> > deep analyzis if the added value is not recognized.
>
> What recognition are you expecting before you go further?
>

Well, so far you as QT "guy" (I understand), you did not seem to show any
sign that it would be valuable in a framework like QT (obviously without
thinking about rewriting parts of it, to make this used). Obviously this
does not mean that I do not see that value.



> Understood.
>
> I still recommend talking to the people doing modules because they may have
> other points to bring up and they're the right people to help you with your
> suggestion.
>

Will try to do so, just that it needs first go through those papers and not
too much time for it.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">On Sunday 08 February 2015 19:1=
7:37 mobi phil wrote:<br>
&gt; &gt; On Sunday 08 February 2015 18:14:26 mobi phil wrote:<br>
</span><span class=3D"">&gt; &gt; Unless, of course, that class has friends=
.. In which case, even private<br>
&gt; &gt; changes<br>
&gt; &gt; will require rebuilding.<br>
&gt;<br>
&gt; Friendship as always should be sometimes reconsidered. If not really<b=
r>
&gt; necessary for performance reason, just use getters/setters.<br>
<br>
</span>That&#39;s advice. Unless forbid the practice, the advice can be ign=
ored and you<br>
have to deal with it.<br>
<br>
It&#39;s irrelevant whether it&#39;s a bad practice or not.<br></blockquote=
><div><br></div><div>while this new construct has to have a different name =
than &quot;class&quot; or another keyword attached to it, it is straightfor=
ward to turn the above into a rule by forbidding friend keyword inside the =
body of with the white.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span class=3D"">Though could reformulate the<br>
&gt; original post, do not feel at the moment it would be worth to go into =
a<br>
&gt; deep analyzis if the added value is not recognized.<br>
<br>
</span>What recognition are you expecting before you go further?<br></block=
quote><div><br>Well, so far you as QT &quot;guy&quot; (I understand), you d=
id not seem to show any sign that it would be valuable in a framework like =
QT (obviously without thinking about rewriting parts of it, to make this us=
ed). Obviously this does not mean that I do not see that value.</div><div><=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Understood.<br>
<br>
I still recommend talking to the people doing modules because they may have=
<br>
other points to bring up and they&#39;re the right people to help you with =
your<br>
suggestion.<br></blockquote><div><br></div><div>Will try to do so, just tha=
t it needs first go through those papers and not too much time for it.</div=
><div><br></div></div>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--20cf3040ebf4738f21050e9816bd--

.

On Sunday 08 February 2015 19:47:37 mobi phil wrote:
> > What recognition are you expecting before you go further?
>
> Well, so far you as QT "guy" (I understand), you did not seem to show any
> sign that it would be valuable in a framework like QT (obviously without
> thinking about rewriting parts of it, to make this used). Obviously this
> does not mean that I do not see that value.

I have two qualms about the proposal: one, which we discussed, is the runtime
overhead which may be too great, greater than the use of d pointers (pimpl).
The other is that I can't use for a long time. Let me put it this way: if this
showed up for C++17, we might be able to start relying on it in Qt by 2025.

Other than that, the idea is interesting.

If you want more feedback, write a paper.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--089e0111b8fadc0f7e050e98e12b
Content-Type: text/plain; charset=UTF-8

>
> I have two qualms about the proposal: one, which we discussed, is the
> runtime
> overhead which may be too great, greater than the use of d pointers
> (pimpl).
>

I do not think this would be the case. For accessing data members that are
in the pimpl or back through getters/setters, the overhead would be equal,
that is a function call. For data members that are in the "white", indeed
there is an overhead compared to normal member access, but this overhead
would not be greater than accessing "black" members.
For both "black" and "white" members (well, both for real public ones from
white and the one's that are accessed through getters/setters from black)
one could think about another language extension I would call it runtime
inline-ing. Given a  pair of setter/getter or "white" public data member,
the compiler would generate placeholder code and the dynamic loader would
patch it with the correct de-referencing of the member based on the "final"
layout of the class. This mechanism will trade code space for this patching
versus efficiency of patching/replacement.

Overhead for creating objects would be in worst case equal with pimpl.


> The other is that I can't use for a long time. Let me put it this way: if
> this
> showed up for C++17, we might be able to start relying on it in Qt by 2025.
>
Well, tend to agree, but this sad law of reality applies to any other
proposals.

Other than that, the idea is interesting.
>
If you want more feedback, write a paper.
>

Will try to write then a first version of the paper. At the end of the day
it does not need to pretend it would cover all the details about the impact
on the future of the humanity :)

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">I have two qualms about the proposal: one, which=
 we discussed, is the runtime<br>
overhead which may be too great, greater than the use of d pointers (pimpl)=
..<br></blockquote><div><br></div><div>I do not think this would be the case=
.. For accessing data members that are in the pimpl or back through getters/=
setters, the overhead would be equal, that is a function call. For data mem=
bers that are in the &quot;white&quot;, indeed there is an overhead compare=
d to normal member access, but this overhead would not be greater than acce=
ssing &quot;black&quot; members.=C2=A0</div><div>For both &quot;black&quot;=
 and &quot;white&quot; members (well, both for real public ones from white =
and the one&#39;s that are accessed through getters/setters from black) one=
 could think about another language extension I would call it runtime inlin=
e-ing. Given a =C2=A0pair of setter/getter or &quot;white&quot; public data=
 member, the compiler would generate placeholder code and the dynamic loade=
r would patch it with the correct de-referencing of the member based on the=
 &quot;final&quot; layout of the class. This mechanism will trade code spac=
e for this patching versus efficiency of patching/replacement.</div><div><b=
r></div><div>Overhead for creating objects would be in worst case equal wit=
h pimpl.<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The other is that I can&#39;t use for a long time. Let me put it this way: =
if this<br>
showed up for C++17, we might be able to start relying on it in Qt by 2025.=
<br></blockquote><div>Well, tend to agree, but this sad law of reality appl=
ies to any other proposals.</div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">Other than that, the idea is interesting.<br></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">If you want more feedback, write a paper.<br></blockquote=
><div><br></div><div>Will try to write then a first version of the paper. A=
t the end of the day it does not need to pretend it would cover all the det=
ails about the impact on the future of the humanity :)=C2=A0<br><br><br></d=
iv><div>=C2=A0</div><div><br></div><div><br></div></div>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0111b8fadc0f7e050e98e12b--

.

--20cf3040ebf409100a050e99f099
Content-Type: text/plain; charset=UTF-8

is this the paper about modules?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2073.pdf

did skim it, but:
-> not too much thing is clearly proposed as standard in terms of templates
instantiation which in my opinion takes most of compilation times
-> does not say anything about recompilation dependencies when changing the
data members thus size of classes...

will go later to their mailing list, to form an idea where they are

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra">is this the paper about modules=
?<br><br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006=
/n2073.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2073.p=
df</a><br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">did s=
kim it, but:<br></div><div class=3D"gmail_extra">-&gt; not too much thing i=
s clearly proposed as standard in terms of templates instantiation which in=
 my opinion takes most of compilation times</div><div class=3D"gmail_extra"=
>-&gt; does not say anything about recompilation dependencies when changing=
 the data members thus size of classes...</div><div class=3D"gmail_extra"><=
br></div><div class=3D"gmail_extra">will go later to their mailing list, to=
 form an idea where they are<br></div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
/div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--20cf3040ebf409100a050e99f099--

.

--001a11c3a2c285c8f4050e9d8a07
Content-Type: text/plain; charset=UTF-8

On Sun, Feb 8, 2015 at 10:00 PM, mobi phil <mobi@mobiphil.com> wrote:

> is this the paper about modules?
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2073.pdf
>

There have been several proposals and updates since this one (see the year
in the url).

The last module proposal is from microsoft (they have a private
implementation apparently):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf

It's similar to the one implemented in clang, with a few differences. See
http://clang.llvm.org/docs/Modules.html

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sun, Feb 8, 2015 at 10:00 PM, mobi phil <span dir=3D"ltr">&lt;<a href=3D=
"mailto:mobi@mobiphil.com" target=3D"_blank">mobi@mobiphil.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div class=3D"gmail_extra">is this the paper =
about modules?<br><br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2006/n2073.pdf" target=3D"_blank">http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2006/n2073.pdf</a><br>
</div><div class=3D"gmail_extra"></div></blockquote></div><div class=3D"gma=
il_extra"><br></div>There have been several proposals and updates since thi=
s one (see the year in the url).<br><br></div><div class=3D"gmail_extra">Th=
e last module proposal is from microsoft (they have a private implementatio=
n apparently):=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2014/n4047.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
014/n4047.pdf</a></div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">It&#39;s similar to the one implemented in clang, with a few di=
fferences. See <a href=3D"http://clang.llvm.org/docs/Modules.html">http://c=
lang.llvm.org/docs/Modules.html</a></div><div class=3D"gmail_extra"><br></d=
iv></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3a2c285c8f4050e9d8a07--

.

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

thanks for the correct link.

-> I was investigating clang modules implementation few weeks ago.
Unfortunately did not gain anything in terms of compilation time
improvements for some source code that was heavily depending on heavy boost
templates. It does not support implicit template instantiations to be cache
in the compiled modules, which for me is the most important thing. Would
love to see instant compilation for a file that includes few headers that
contain heavy templates. Maybe I failed to grasp how to do it and raised
the question on clang dev-list, but did not get till today a clear answer.
Would love to see somebody showing me real compilation time gain when
building such. But this is not the topic of this thread.

-> went through the latest proposal:
->> The proposal luckily makes reference to implicit template instantiation
caching.
->> Do not like that they are convinced to throw away the preprocesor
without creating something in place
->> related to my current proposal (see also the quote from the paper
below), they touch the subject about "changes to private member" but the
seem not to want to adventure by coming up with any solution.

from the proposal
"An occasionally vexing rule of standard C++ is that protection controls
access,
not visibility. E.g. a private member of a class is visible to, but not
accessible to
non-member entities. In particular, any change to a private member of a
class is
likely to trigger re-processing of any translation unit that depends on
that class=E2=80=99s
definition even if the change does not affect the validity of dependent
units. It
is tempting to solve that problem with a module system. However, having two
distinct sets of rules (visibility and accessibility) for class members
strikes us as
undesirable and potentially fertile source of confusion. Furthermore, we
want to
support mass-migration of existing codes to modules without programmers
having
to worry about class member name lookup rules: if you understand those rule=
s
today, then you do not have to learn new rules when you move to modules and
you
do not have to worry about how the classes you consume are provided (via
modules
or non-modules).
That being said, we believe the visibility vs. accessibility issue is a
problem that
should be solved by an orthogonal language construct, irrespectively of
whether a
class is defined in a module interface declaration or in an ordinary
translation unit.

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

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

<div dir=3D"ltr"><div>thanks for the correct link.=C2=A0</div><div><br></di=
v><div>-&gt; I was investigating clang modules implementation few weeks ago=
.. Unfortunately did not gain anything in terms of compilation time improvem=
ents for some source code that was heavily depending on heavy boost templat=
es. It does not support implicit template instantiations to be cache in the=
 compiled modules, which for me is the most important thing. Would love to =
see instant compilation for a file that includes few headers that contain h=
eavy templates. Maybe I failed to grasp how to do it and raised the questio=
n on clang dev-list, but did not get till today a clear answer. Would love =
to see somebody showing me real compilation time gain when building such. B=
ut this is not the topic of this thread.</div><div><br></div><div>-&gt; wen=
t through the latest proposal:</div><div>-&gt;&gt; The proposal luckily mak=
es reference to implicit template instantiation caching.=C2=A0<br></div><di=
v>-&gt;&gt; Do not like that they are convinced to throw away the preproces=
or without creating something in place</div><div>-&gt;&gt; related to my cu=
rrent proposal (see also the quote from the paper below), they touch the su=
bject about &quot;changes to private member&quot; but the seem not to want =
to adventure by coming up with any solution.<br></div><div><br></div><div>f=
rom the proposal</div><div><div>&quot;An occasionally vexing rule of standa=
rd C++ is that protection controls access,</div><div>not visibility. E.g. a=
 private member of a class is visible to, but not accessible to</div><div>n=
on-member entities. In particular, any change to a private member of a clas=
s is</div><div>likely to trigger re-processing of any translation unit that=
 depends on that class=E2=80=99s</div><div>definition even if the change do=
es not affect the validity of dependent units. It</div><div>is tempting to =
solve that problem with a module system. However, having two</div><div>dist=
inct sets of rules (visibility and accessibility) for class members strikes=
 us as</div><div>undesirable and potentially fertile source of confusion. F=
urthermore, we want to</div><div>support mass-migration of existing codes t=
o modules without programmers having</div><div>to worry about class member =
name lookup rules: if you understand those rules</div><div>today, then you =
do not have to learn new rules when you move to modules and you</div><div>d=
o not have to worry about how the classes you consume are provided (via mod=
ules</div><div>or non-modules).</div><div>That being said, we believe the v=
isibility vs. accessibility issue is a problem that</div><div>should be sol=
ved by an orthogonal language construct, irrespectively of whether a</div><=
div>class is defined in a module interface declaration or in an ordinary tr=
anslation unit.</div></div><div><br></div><div><br></div><div class=3D"gmai=
l_extra">
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ec45ace731a050e9e1342--

.

Le 09/02/15 02:56, mobi phil a =C3=A9crit :
> thanks for the correct link.
>
> -> I was investigating clang modules implementation few weeks ago.=20
> Unfortunately did not gain anything in terms of compilation time=20
> improvements for some source code that was heavily depending on heavy=20
> boost templates. It does not support implicit template instantiations=20
> to be cache in the compiled modules, which for me is the most=20
> important thing. Would love to see instant compilation for a file that=20
> includes few headers that contain heavy templates. Maybe I failed to=20
> grasp how to do it and raised the question on clang dev-list, but did=20
> not get till today a clear answer. Would love to see somebody showing=20
> me real compilation time gain when building such. But this is not the=20
> topic of this thread.
>
Agreed. However the goal is the same: reduce compile time.
> -> went through the latest proposal:
> ->> The proposal luckily makes reference to implicit template=20
> instantiation caching.
> ->> Do not like that they are convinced to throw away the preprocesor=20
> without creating something in place
> ->> related to my current proposal (see also the quote from the paper=20
> below), they touch the subject about "changes to private member" but=20
> the seem not to want to adventure by coming up with any solution.
>
> from the proposal
> "An occasionally vexing rule of standard C++ is that protection=20
> controls access,
> not visibility. E.g. a private member of a class is visible to, but=20
> not accessible to
> non-member entities. In particular, any change to a private member of=20
> a class is
> likely to trigger re-processing of any translation unit that depends=20
> on that class=E2=80=99s
> definition even if the change does not affect the validity of=20
> dependent units. It
> is tempting to solve that problem with a module system. However,=20
> having two
> distinct sets of rules (visibility and accessibility) for class=20
> members strikes us as
> undesirable and potentially fertile source of confusion. Furthermore,=20
> we want to
> support mass-migration of existing codes to modules without=20
> programmers having
> to worry about class member name lookup rules: if you understand those=20
> rules
> today, then you do not have to learn new rules when you move to=20
> modules and you
> do not have to worry about how the classes you consume are provided=20
> (via modules
> or non-modules).
> That being said, we believe the visibility vs. accessibility issue is=20
> a problem that
> should be solved by an orthogonal language construct, irrespectively=20
> of whether a
> class is defined in a module interface declaration or in an ordinary=20
> translation unit.
>
>
Thanks for the quote. It seems I was wrong, and that the module proposal=20
would not take care of the visibility issues.

I believe that you have here the go from the honorable people you were=20
looking for, at least for the problem to be solved. I'm sure the same=20
people would be interested in discussing possible solutions.

I will add this quoting the proposal:
"Runtime Performance
Moving an existing code to a brave new module world, or writing new=20
codes with modules, should not in any way degrade its runtime=20
performance characteristics. In particular, we do not seek a module=20
system requiring a compiler to perform automatic =E2=80=9Cboxing=E2=80=9D o=
f object=20
representation (exposed in class private members) =E2=80=93in attempts to=
=20
reducing re-compilation=E2=80=93 via opaque data pointers a la ` pImpl idio=
m."


Respect to the visibility issue, I would like to preserve Runtime=20
Performance also: Moving an existing code to a brave new visibility=20
aware world, or writing new codes with visibility concerns, should not=20
in any way degrade its runtime performance characteristics."

I'm not saying that I'm against any visibility solution that doesn't=20
preserve runtime performance, just that the performance aspect must be=20
considered.

Vicente

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

.

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

>
> I will add this quoting the proposal:
> "Runtime Performance
> Moving an existing code to a brave new module world, or writing new codes
> with modules, should not in any way degrade its runtime performance
> characteristics. In particular, we do not seek a module system requiring =
a
> compiler to perform automatic =E2=80=9Cboxing=E2=80=9D of object represen=
tation (exposed in
> class private members) =E2=80=93in attempts to reducing re-compilation=E2=
=80=93 via opaque
> data pointers a la ` pImpl idiom."
>
>
> Respect to the visibility issue, I would like to preserve Runtime
> Performance also: Moving an existing code to a brave new visibility aware
> world, or writing new codes with visibility concerns, should not in any w=
ay
> degrade its runtime performance characteristics."
>
> I'm not saying that I'm against any visibility solution that doesn't
> preserve runtime performance, just that the performance aspect must be
> considered.


Well, while it would be annoying to have a general solution where private
data would be automatically moved to some pimpl one has to have the freedom
to do so. Some applications may suffer from this little performance penalty
of the black/white approach, but as described earlier this would be the
same overhead as a non-inlined pair of setter/getter. You are trading
something against something.

While non-inlined setters/getters would be a performance penalty for both
actual approach and black/white, maybe one could think of some link time or
dynamic link time inlining solution, where a certain code binary code
pattern could be replaced with the "real implementation".

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">I will add this quoting the proposal:<br>
&quot;Runtime Performance<br>
Moving an existing code to a brave new module world, or writing new codes w=
ith modules, should not in any way degrade its runtime performance characte=
ristics. In particular, we do not seek a module system requiring a compiler=
 to perform automatic =E2=80=9Cboxing=E2=80=9D of object representation (ex=
posed in class private members) =E2=80=93in attempts to reducing re-compila=
tion=E2=80=93 via opaque data pointers a la ` pImpl idiom.&quot;<br>
<br>
<br>
Respect to the visibility issue, I would like to preserve Runtime Performan=
ce also: Moving an existing code to a brave new visibility aware world, or =
writing new codes with visibility concerns, should not in any way degrade i=
ts runtime performance characteristics.&quot;<br>
<br>
I&#39;m not saying that I&#39;m against any visibility solution that doesn&=
#39;t preserve runtime performance, just that the performance aspect must b=
e considered.</blockquote><div><br></div><div>Well, while it would be annoy=
ing to have a general solution where private data would be automatically mo=
ved to some pimpl one has to have the freedom to do so. Some applications m=
ay suffer from this little performance penalty of the black/white approach,=
 but as described earlier this would be the same overhead as a non-inlined =
pair of setter/getter. You are trading something against something.</div><d=
iv><br></div><div>While non-inlined setters/getters would be a performance =
penalty for both actual approach and black/white, maybe one could think of =
some link time or dynamic link time inlining solution, where a certain code=
 binary code pattern could be replaced with the &quot;real implementation&q=
uot;.</div><div><br></div><div><br></div><div><br></div><div>=C2=A0</div></=
div>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec51969cdcd649b050ea53fcb--

.

--001a11332018a8ea17050f346e38
Content-Type: text/plain; charset=UTF-8

FYI: some of you for sure know about llvm-lto. It could solve the overhead
of getter/setters or with other words how offsets would be solved.

llvm/clang has llvm-lto and the gold plugin that can inline functions at
linking time. The setters/getters defined in the black and containing the
correct member offset information could be inlined at link time. It seems
that there would be no runtime access overhead for data members defined in
"black".

I assume that this trick with lto(=inline) could be used also for pimpl
related call overhead.

--

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

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

<div dir=3D"ltr">FYI: some of you for sure know about llvm-lto. It could so=
lve the overhead of getter/setters or with other words how offsets would be=
 solved.<div><br></div><div>llvm/clang has llvm-lto and the gold plugin tha=
t can inline functions at linking time. The setters/getters defined in the =
black and containing the correct member offset information could be inlined=
 at link time. It seems that there would be no runtime access overhead for =
data members defined in &quot;black&quot;.=C2=A0</div><div><br></div><div>I=
 assume that this trick with lto(=3Dinline) could be used also for pimpl re=
lated call overhead.=C2=A0</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11332018a8ea17050f346e38--

.

------=_Part_2302_476811868.1424155348387
Content-Type: multipart/alternative;
 boundary="----=_Part_2303_1515578519.1424155348387"

------=_Part_2303_1515578519.1424155348387
Content-Type: text/plain; charset=UTF-8

This is an attractive alternative to pointer-based PIMPL, though it would
require sweeping modifications to be made across every compliant
loader/toolset.

That said, I still like it.

However, it doesn't seem to address re-using the same interface for
multiple implementations simultaneously (exposing "new" through the
interface layer constrains it to a single implementation).

Another issue is version discrepancy: What metadata must be stored in
external module containing all the "black" in order to ensure that the
addition of new members to that layer do not cause undefined behavior when
linked against an older "white" that doesn't know about them? There needs
to be a way to verify a new "black" against an already compiled "white"
during compilation, which seems to indicate the need for a large amount of
metadata...

These concerns stem from a number of problems I've been facing lately:

Say we need to display the same dataset on a workstation monitor and
through a projector.

The monitor is connected through an Nvidia adapter, and the projector
through an old ATI.

We have to create one rendering context per adapter, as moving a window
from the workstation display to the projector will crash or result in
garbage (unless all rendering is done with GDI).

Both contexts have different feature sets resulting in different "black"
layers, however the "white" layer looks the same for both.

The obvious solution is PIMPL, though there is a lot of work involved in
maintaining the parallel sets of types required to realize this.
After a small change in the interface, resolving version discrepancies for
every affected module slows development to a crawl.

The biggest time-waster is a new "black" failing its tests after
compilation.

--

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

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

<div dir=3D"ltr">This is an attractive alternative to pointer-based PIMPL, =
though it=20
would require sweeping modifications to be made across every compliant=20
loader/toolset.<br><br>That said, I still like it.<br><br>However, it doesn=
't seem to address re-using the same interface for multiple implementations=
 simultaneously (exposing "new" through the interface layer constrains it t=
o a single implementation).<br><br>Another issue is version discrepancy: Wh=
at metadata must be stored in external module containing all the "black" in=
 order to ensure that the addition of new members to that layer do not caus=
e undefined behavior when linked against an older "white" that doesn't know=
 about them? There needs to be a way to verify a new "black" against an alr=
eady compiled "white" during compilation, which seems to indicate the need =
for a large amount of metadata...<br><br>These concerns stem from a number =
of problems I've been facing lately:<br><br>Say we need to display the same=
 dataset on a workstation monitor and through a projector.<br><br>The monit=
or is connected through an Nvidia adapter, and the projector through an old=
 ATI.<br><br>We have to create one rendering context per adapter, as moving=
 a window from the workstation display to the projector will crash or resul=
t in garbage (unless all rendering is done with GDI).<br><br>Both contexts =
have different feature sets resulting in different "black" layers, however =
the "white" layer looks the same for both.<br><br>The obvious solution is P=
IMPL, though there is a lot of work involved in maintaining the parallel se=
ts of types required to realize this.<br>After a small change in the interf=
ace, resolving version discrepancies for every affected module slows develo=
pment to a crawl.<br><br>The biggest time-waster is a new "black" failing i=
ts tests after compilation.<br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2303_1515578519.1424155348387--
------=_Part_2302_476811868.1424155348387--

.

------=_Part_269_560565842.1424156377381
Content-Type: multipart/alternative;
 boundary="----=_Part_270_419347105.1424156377381"

------=_Part_270_419347105.1424156377381
Content-Type: text/plain; charset=UTF-8

Answering my first question: Just have the "black" layer return a pointer,
which brings us back to PIMPL.

The real power of this proposal would be a standardized way to validate an
implementation against a compiled interface.


On Monday, February 16, 2015 at 11:42:28 PM UTC-7, Chris Gary wrote:
>
> This is an attractive alternative to pointer-based PIMPL, though it would
> require sweeping modifications to be made across every compliant
> loader/toolset.
>
> That said, I still like it.
>
> However, it doesn't seem to address re-using the same interface for
> multiple implementations simultaneously (exposing "new" through the
> interface layer constrains it to a single implementation).
>
> *snip*
>

--

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

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

<div dir=3D"ltr">Answering my first question: Just have the "black" layer r=
eturn a pointer, which brings us back to PIMPL.<br><br>The real power of th=
is proposal would be a standardized way to validate an implementation again=
st a compiled interface.<br><br><br>On Monday, February 16, 2015 at 11:42:2=
8 PM UTC-7, Chris Gary wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">This is an attractive alternative to pointer-based PIMPL, t=
hough it=20
would require sweeping modifications to be made across every compliant=20
loader/toolset.<br><br>That said, I still like it.<br><br>However, it doesn=
't seem to address re-using the same interface for multiple implementations=
 simultaneously (exposing "new" through the interface layer constrains it t=
o a single implementation).<br><br>*snip*<br></div></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_270_419347105.1424156377381--
------=_Part_269_560565842.1424156377381--

.

On 2015-02-17 12:02, Chris Gary wrote:
> To avoid introducing new CSK, you can re-use "virtual" and "override" for
> this purpose.

Hmm... not loving it. Anything wrong with:

public class Foo /* white */ { ... };
private class Foo /* black */ { ... };

....?

On 2015-02-17 12:16, Chris Gary wrote:
> I would also like to add that, unless there is a reasonable way to combine
> a "white" and "black" into the same definition, this actually *forces* the
> two to be separated.

How would such a combination be different from a regular class?

--
Matthew

--

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

.

On 2015-02-17 12:42, mobi phil wrote:
> Matthew Woehlke wrote:
>> On 2015-02-17 12:16, Chris Gary wrote:
>>> I would also like to add that, unless there is a reasonable way
>>> to combine a "white" and "black" into the same definition, this
>>> actually *forces* the two to be separated.
>>
>> How would such a combination be different from a regular class?
>
> sorry.. did you read the original post and the thread?

It's been a while, but I think I recall the general gist. I think one of
us is missing something, however. I get the black/white concept when you
separate the interface from the implementation (isn't that the point?).
What I *don't* get is what it means to use this feature when the two are
*not* separated. (In particular, as per my question, what would be the
use case for that and how would it differ from a "regular" class?)

--
Matthew

--

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

.

On 2015-02-17 12:41, mobi phil wrote:
> hi, as stated in the original post, personally do not care how the two
> constructs will be named, thus if majority of folks would love
> virtual/override do not care... However it is not really virtual and
> override in my original concept. I would not force all the data members to
> be virtual. I would allow part of data to be in white. The black would
> complement it.

Agreed, but note also I don't think we're suggesting that. (Overriding
(pardon the pun) those keywords for this is a bit abusive of what they
normally mean, and a source of potential confusion as you've just
demonstrated, which is one reason using public/private instead might be
better.)

--
Matthew

--

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

.

------=_Part_1776_1731295157.1424342707635
Content-Type: multipart/alternative;
 boundary="----=_Part_1777_1621770496.1424342707635"

------=_Part_1777_1621770496.1424342707635
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 17, 2015 at 10:38:24 AM UTC-7, Matthew Woehlke wrote:
>
> *snip*
>
> On 2015-02-17 12:16, Chris Gary wrote:
> > I would also like to add that, unless there is a reasonable way to
> combine
> > a "white" and "black" into the same definition, this actually *forces*
> the
> > two to be separated.
>
> How would such a combination be different from a regular class?
>
> --
> Matthew
>

The idea would be that it would simultaneously define an interface and
implementation, while allowing other implementations to be defined later.
This would reduce repetition, as a separate "black" would not have to be
defined right away.

Unless there is some way to add a "pure" specifier, the absence of which
would allow a "white" definition to double as "black".

I still have a problem with needing to resolve sizeof() at link time: Using
sizeof() is critical for templates that decide things like whether or not
an instance will fit in a small aligned buffer versus needing heap
allocation.

Obviously, alignment becomes a problem, as we might have some member with
larger than alignof(double) requirement (e.g. AVX tuple). I don't think
this can be dealt with efficiently at link time, as it would basically
require all template "algorithms" to be recorded as bytecode somehow. That,
or simply forbidding sizeof() or alignof() to be used on an interface in
the context of a template, which makes the idea incompatible with half the
language...

Concerning keywords: I don't really care what is chosen, just as long as
they don't turn nested definitions and the like into keyword soup or become
easily confused with other commonly-defined symbols (such as color enums).
My policy about keywords is that the result needs to be reasonably readable
as monochrome text...

--

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

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

<div dir=3D"ltr">On Tuesday, February 17, 2015 at 10:38:24 AM UTC-7, Matthe=
w Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">*snip*<br>
<br>On 2015-02-17 12:16, Chris Gary wrote:
<br>&gt; I would also like to add that, unless there is a reasonable way to=
 combine=20
<br>&gt; a "white" and "black" into the same definition, this actually *for=
ces* the=20
<br>&gt; two to be separated.
<br>
<br>How would such a combination be different from a regular class?
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br>The idea would be that it would simultaneously de=
fine an interface and implementation, while allowing other implementations =
to be defined later. This would reduce repetition, as a separate "black" wo=
uld not have to be defined right away.<br><br>Unless there is some way to a=
dd a "pure" specifier, the absence of which would allow a "white" definitio=
n to double as "black".<br><br>I still have a problem with needing to resol=
ve sizeof() at link time: Using sizeof() is critical for templates that dec=
ide things like whether or not an instance will fit in a small aligned buff=
er versus needing heap allocation.<br><br>Obviously, alignment becomes a pr=
oblem, as we might have some member with larger than alignof(double) requir=
ement (e.g. AVX tuple). I don't think this can be dealt with efficiently at=
 link time, as it would basically require all template "algorithms" to be r=
ecorded as bytecode somehow. That, or simply forbidding sizeof() or alignof=
() to be used on an interface in the context of a template, which makes the=
 idea incompatible with half the language...<br><br>Concerning keywords: I =
don't really care what is chosen, just as long as they don't turn nested de=
finitions and the like into keyword soup or become easily confused with oth=
er commonly-defined symbols (such as color enums). My policy about keywords=
 is that the result needs to be reasonably readable as monochrome text...<b=
r></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1777_1621770496.1424342707635--
------=_Part_1776_1731295157.1424342707635--

.

------=_Part_1392_629767698.1424346448869
Content-Type: multipart/alternative;
 boundary="----=_Part_1393_1706287870.1424346448869"

------=_Part_1393_1706287870.1424346448869
Content-Type: text/plain; charset=UTF-8

On Thursday, February 19, 2015 at 3:45:07 AM UTC-7, Chris Gary wrote:
>
> That, or simply forbidding sizeof() or alignof() to be used on an
> interface in the context of a template, which makes the idea incompatible
> with half the language...
>

I exaggerated a bit there... Let me clarify: If a "white" can double as a
"black" (or there is a compatible "black" in the TU), then sizeof() and
alignof() are well-defined, but it absolutely must be deduced at compile
time. The case where it can't be used in a template really isn't that
different than applying sizeof() to an incomplete type (pure "white" is
fundamentally incomplete)...

--

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

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

<div dir=3D"ltr">On Thursday, February 19, 2015 at 3:45:07 AM UTC-7, Chris =
Gary wrote:<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">Th=
at, or simply forbidding sizeof() or alignof() to be used on an interface i=
n the context of a template, which makes the idea incompatible with half th=
e language...<br></div></blockquote><div><br>I exaggerated a bit there... L=
et me clarify: If a "white" can double as a "black" (or there is a compatib=
le "black" in the TU), then sizeof() and alignof() are well-defined, but it=
 absolutely must be deduced at compile time. The case where it can't be use=
d in a template really isn't that different than applying sizeof() to an in=
complete type (pure "white" is fundamentally incomplete)...<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1393_1706287870.1424346448869--
------=_Part_1392_629767698.1424346448869--

.

------=_Part_1043_1096839691.1424729738540
Content-Type: multipart/alternative;
 boundary="----=_Part_1044_585060789.1424729738540"

------=_Part_1044_585060789.1424729738540
Content-Type: text/plain; charset=UTF-8

I'm sorry to involve in this way, but could you please state what is/are
the goals you want to achieve by this suggestion/proposal?
I haven't read all the posts under this topic, I'll just summarize the
goals I've noticed:
1) separate public interface from internal implementation details
2) enable change of internal implementation without the need of
recompilation code that only uses the public interface of the class/struct.
Please could you add other goals which I've missed? I'm sorry if I
completely misunderstood your ideas.

An old way to achieve goals 1&2: abstract interface with pure virtual
methods:
// white.h:
class IWidget {
public:
  virtual void set(int) = 0;
  virtual int get() const = 0;
};

// black.h:
class WidgetImpl : public IWidget {
public:
  virtual void set(int i) override { x = i; }
  virtual int get() const { return x; }

private:
  int x;
};
.... now if you decide to change the implementation of WidgetImpl, there's
no need to recompile code that uses only IWidget.




I can't imagine setup where this same behavior would be achieved by using
non-virtual methods. Let's consider code using the black/white keywords (I
might missed the proposed syntax, please correct me if I'm wrong):
// white.h:
class white Widget {
public:
  void set(int i) { setInternal(i); }
  int get() const { return getInternal(); }
};

// black.h:
class black Widget {
private:
  void setInternal(int i) { x = i; }
  int getInternal() const { return getInternal2(); }

private:
  int getInternal2() const { return getInternal3(); }
  int getInternal3() const { return x; }

private:
  int x;
};

Then let's assume a use of Widget:
// foo.cpp:
#include "white.h"
void foo() {
  Widget w;
  w.set(2);
  std::cout << w.get() << endl;
}
.... here I think any reasonable compiler would inline the call of
Widget::get to just reading directly the private member Widget::x (there is
no virtual call, no obstacles (if not the black/white keywords)).
But by inlining, the compiled object file of foo.cpp now holds information
about not only internal structure of black Widget but also about its
implementation. So whenever the implementation of black Widget changes,
foo.cpp has to be recompiled to refresh that information.
IMHO either:
a) foo can see the entrails of black Widget -> then foo.cpp must be
recompiled on every black Widget change. (we didn't achieve goal #2)
or:
b) foo can be optimized only up to the implementation of white Widget, not
further. -> then it seems to me similar to calling a virtual method. (Yes,
it might be more efficient then calling an explicitly virtual method. But
I'm not sure if all this brings enough value).

--

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

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

<div dir=3D"ltr">I'm sorry to involve in this way, but could you please sta=
te what is/are the goals you want to achieve by this suggestion/proposal?<d=
iv>I haven't read all the posts under this topic, I'll just summarize the g=
oals I've noticed:</div><div>1) separate public interface from internal imp=
lementation details</div><div>2) enable change of internal implementation w=
ithout the need of recompilation code that only uses the public interface o=
f the class/struct.</div><div>Please could you add other goals which I've m=
issed? I'm sorry if I completely misunderstood your ideas.</div><div><br></=
div><div>An old way to achieve goals 1&amp;2: abstract interface with pure =
virtual methods:</div><div><div class=3D"prettyprint" style=3D"border: 1px =
solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250,=
 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><fon=
t color=3D"#660066"><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// white.h:</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">cl=
ass</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">IWidget</span><s=
pan 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=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">public</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">set</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">vi=
rtual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">get</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span></font></div></code=
></div></div><div><br></div><div><div class=3D"prettyprint" style=3D"border=
: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rg=
b(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><font color=3D"#660066"><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">// black.h:</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></font><span style=3D"color: #008;" class=3D"styled-by=
-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Wid=
getImpl</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">public</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">IWidget</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: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">public</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">vir=
tual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">set</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ov=
erride</span><font color=3D"#666600"><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: #000;" class=3D"styled-by-prettify=
"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span></font><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">virtual</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">get</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><sp=
an 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=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">private</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span></div></code></div></div><div>... now if you dec=
ide to change the implementation of WidgetImpl, there's no need to recompil=
e code that uses only IWidget.</div><div><br></div><div><br></div><div><br>=
</div><div><br></div><div>I can't imagine setup where this same behavior wo=
uld be achieved by using non-virtual methods. Let's consider code using the=
 black/white keywords (I might missed the proposed syntax, please correct m=
e if I'm wrong):</div><div><div class=3D"prettyprint" style=3D"border: 1px =
solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250,=
 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// white.h:</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> white </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Widget</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">public</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">set</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> setInternal</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">get</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> getInternal</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div><br></div><div><div class=3D"prettyprint" s=
tyle=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgr=
ound-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/ black.h:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">class<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> black </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">Widget</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">private</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> setInternal</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><font=
 color=3D"#666600"><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">}</span></font><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> getInternal</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">const</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: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> getInternal2</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">private</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> getInternal2</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</s=
pan><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: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> getInternal3</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> getInternal3</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</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: #000;" class=3D"styled-by-prettify"><br><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">private</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><div><br></div><div>Then let=
's assume a use of Widget:</div><div><div class=3D"prettyprint" style=3D"bo=
rder: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color=
: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><font color=3D"#660066"><span style=3D"color: #800;" class=3D"styled-=
by-prettify">// foo.cpp:</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">#include</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"wh=
ite.h"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">()</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: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Widget</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> w</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; w</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">set</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> w</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">get</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> endl</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></font></div></code>=
</div></div><div>... here I think any reasonable compiler would inline the =
call of Widget::get to just reading directly the private member Widget::x (=
there is no virtual call, no obstacles (if not the black/white keywords)).<=
br></div></div><div>But by inlining, the compiled object file of foo.cpp no=
w holds information about not only internal structure of black Widget but a=
lso about its implementation. So whenever the implementation of black Widge=
t changes, foo.cpp has to be recompiled to refresh that information.</div><=
div>IMHO either:</div><div>a) foo can see the entrails of black Widget -&gt=
; then foo.cpp must be recompiled on every black Widget change. (we didn't =
achieve goal #2)</div><div>or:</div><div>b) foo can be optimized only up to=
 the implementation of white Widget, not further. -&gt; then it seems to me=
 similar to calling a virtual method. (Yes, it might be more efficient then=
 calling an explicitly virtual method. But I'm not sure if all this brings =
enough value).</div><div><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1044_585060789.1424729738540--
------=_Part_1043_1096839691.1424729738540--

.

--Apple-Mail=_67525FB7-EC8B-4287-B877-851A963D1DF9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9327, at 6:31 AM, mobi phil <mobi@mobiphil.com> =
wrote:
>=20
> May I kindly ask you to go through all emails. This problem was
> already addressed. The proposal does not intend to replace all the
> usage of all the classes in all the templates in all the world. There
> are classes that do not provide other kind of protocols that make them
> unusable in thousands of other templates. The proposal will not
> satisfy the interface for sizeof at compiltime and with that this part
> of topic is closed.

You can summarily stop a part of this discussion so easily now, but once th=
e committee realizes that you=E2=80=99re proposing sizeof expressions that =
aren=E2=80=99t compile-time constants, they=E2=80=99ll stop the entire prop=
osal equally swiftly. I=E2=80=99ve not been following this thread, but you =
might be better off saying that sizeof cannot be applied to certain types a=
t all, and introducing a new runtime function to take its place if necessar=
y.

By the way, the VLA/=E2=80=9Cclasses of runtime size=E2=80=9D proposal did =
not provide for varying object size at runtime, to my knowledge.

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

--Apple-Mail=_67525FB7-EC8B-4287-B877-851A963D1DF9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9327, at 6:31 AM, mobi phil &lt;<a href=3D"mailto:mobi@mobiphil.com"=
 class=3D"">mobi@mobiphil.com</a>&gt; wrote:</div><br class=3D"Apple-interc=
hange-newline"><div class=3D""><div style=3D"" class=3D""><span style=3D"fo=
nt-family: Helvetica; font-size: 12px; font-style: normal; font-variant: no=
rmal; font-weight: normal; letter-spacing: normal; line-height: normal; orp=
hans: auto; text-align: start; text-indent: 0px; text-transform: none; whit=
e-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width=
: 0px; float: none; display: inline !important;" class=3D"">May I kindly as=
k you to go through all emails. This problem was</span><br style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-=
style: normal; font-variant: normal; font-weight: normal; letter-spacing: n=
ormal; line-height: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; word-spacing:=
 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !importa=
nt;" class=3D"">already addressed. The proposal does not intend to replace =
all the</span><br style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family:=
 Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; flo=
at: none; display: inline !important;" class=3D"">usage of all the classes =
in all the templates in all the world. There</span><br style=3D"font-family=
: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fon=
t-weight: normal; letter-spacing: normal; line-height: normal; orphans: aut=
o; text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" c=
lass=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: norma=
l; line-height: normal; orphans: auto; text-align: start; text-indent: 0px;=
 text-transform: none; white-space: normal; widows: auto; word-spacing: 0px=
; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"=
 class=3D"">are classes that do not provide other kind of protocols that ma=
ke them</span><br style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family:=
 Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; flo=
at: none; display: inline !important;" class=3D"">unusable in thousands of =
other templates. The proposal will not</span><br style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px; float: none; display: inline !important;" cla=
ss=3D"">satisfy the interface for sizeof at compiltime and with that this p=
art</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style:=
 normal; font-variant: normal; font-weight: normal; letter-spacing: normal;=
 line-height: normal; orphans: auto; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Hel=
vetica; font-size: 12px; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; orphans: auto; te=
xt-align: start; text-indent: 0px; text-transform: none; white-space: norma=
l; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: =
none; display: inline !important;" class=3D"">of topic is closed.</span><br=
 style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height:=
 normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-=
stroke-width: 0px;" class=3D""></div></div></blockquote><div><br class=3D""=
></div>You can summarily stop a part of this discussion so easily now, but =
once the committee realizes that you=E2=80=99re proposing sizeof expression=
s that aren=E2=80=99t compile-time constants, they=E2=80=99ll stop the enti=
re proposal equally swiftly. I=E2=80=99ve not been following this thread, b=
ut you might be better off saying that sizeof cannot be applied to certain =
types at all, and introducing a new runtime function to take its place if n=
ecessary.</div><div><br class=3D""></div><div>By the way, the VLA/=E2=80=9C=
classes of runtime size=E2=80=9D proposal did not provide for varying objec=
t size at runtime, to my knowledge.</div></body></html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_67525FB7-EC8B-4287-B877-851A963D1DF9--

.

--Apple-Mail=_C9A27668-EC4E-4B05-A7A1-3B23A357992A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9327, at 7:44 AM, David Krauss <potswa@gmail.com=
> wrote:
>=20
> By the way, the VLA/=E2=80=9Cclasses of runtime size=E2=80=9D proposal di=
d not provide for varying object size at runtime, to my knowledge.

I mean, changing the size of an object already created, as suggested a coup=
le messages ago. Of course it allowed for deciding the size of an object up=
on construction.

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

--Apple-Mail=_C9A27668-EC4E-4B05-A7A1-3B23A357992A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9327, at 7:44 AM, David Krauss &lt;<a href=3D"mailto:potswa@gmail.co=
m" class=3D"">potswa@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><span style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
 letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; displa=
y: inline !important;" class=3D"">By the way, the VLA/=E2=80=9Cclasses of r=
untime size=E2=80=9D proposal did not provide for varying object size at ru=
ntime, to my knowledge.</span></div></blockquote></div><br class=3D""><div =
class=3D"">I mean, changing the size of an object already created, as sugge=
sted a couple messages ago. Of course it allowed for deciding the size of a=
n object upon construction.</div></body></html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_C9A27668-EC4E-4B05-A7A1-3B23A357992A--

.

> I mean, changing the size of an object already created, as suggested a
> couple messages ago. Of course it allowed for deciding the size of an object
> upon construction.

Jumping in and while landing grabbing a random apple from the tree,
would not bring too much added value, isn't it? ;)

Can you please read more carefully the thread and avoid statements
like "changing the size of an object already created, as suggested a
couple messages ago..". At least myself I did not make such
irresponsible statements. You confused with variations on the idea
about loading the full class from a dynamic library which means
together with sizeof() and equivalent functions and offset providing
functions that satisfy the white interface.

You make me repeating the same trivial statement yet the x'th time:
the runtime "sizeof" detail is an option. The main proposal is
focusing on link time inlining. Thus you missed the point, it wont be
compile time constant sizeof, it wont't be runtime, but it wants to be
link time constant. For the rest if you bother, just go through the
thread.

--

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

.

> On 2015=E2=80=9302=E2=80=9327, at 9:36 AM, mobi phil <mobi@mobiphil.com> =
wrote:
>=20
> Can you please read more carefully the thread and avoid statements
> like "changing the size of an object already created, as suggested a
> couple messages ago..". At least myself I did not make such
> irresponsible statements.

=E2=80=9CPlease do not confuse with some proposals that had as object dynam=
ically growing objects or anything in that direction.=E2=80=9D You said thi=
s in reference to N3875, and I just wanted to clarify that N3875 (and vario=
us related or similar papers) don=E2=80=99t have that either, yet they have=
 run into trouble.

I don=E2=80=99t think it makes much difference whether a size is determined=
 at link/load time or upon a function call.

> For the rest if you bother, just go through the thread.

This thread has become insanely long. Where am I supposed to start? Perhaps=
 now is a good time to start compiling your findings into a comprehensive p=
aper.

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

.

> I don=E2=80=99t think it makes much difference whether a size is determin=
ed at link/load time or upon a function call.

The statement is ambiguous. While it will obviously make difference
for the compiler, as the feature has to be implemented, it will also
make huge difference if a function call could be replaced by linker
with a "link time constant" that is link-time-inlined. For some
reasons LLVM guys are working hard on such optimizations. It is easy
to reject by blaming potential run-time performance degradation, but
if that is excluded then
If C++ committee thinks only in terms of technology of 20 years ago,
indeed there will be plenty of reasons to refuse anything.

Paper will be ready soon, please do not blame me for the thread
becoming long, could have ignored all replies but that was obviously
not my interest.

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

.