------=_Part_759_985625534.1456247587987
Content-Type: multipart/alternative;
 boundary="----=_Part_760_1181297829.1456247587988"

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

Seriously? A *zip file*? It's annoying enough to have to download a PDF,=20
but at least that's viewable. Why can't people just use a text file for=20
these sorts of preliminary things? You don't need to provide header files=
=20
for us to be able to understand the proposal.

As for the proposal itself, I have to take issue with the very first=20
sentence:

The main purpose of the public and the private parts of a C++ class is to=
=20
> separate the interface of that class from its
> implementation
>

No. The main purpose of the public/private distinction is to have a=20
language mechanism for *encapsulation*, who's main purpose is to be able to=
=20
establish invariants in the class which could only be broken by a very=20
limited set of code. Separating interface from implementation is *not* the=
=20
point at all.

If that were the purpose, we wouldn't have to put the interface and=20
implementation in the same place.

As for the general motivation for the proposal, modules will already=20
mitigate the recompilation costs reasonably effectively. You will only need=
=20
to recompile code that imports your module if you change the actual=20
declarations within the class (public and private). Merely modifying the=20
code in a member function should *not* cause a recompilation cascade unless=
=20
that function is defined inline.

Plus, modules will generally make recompilation cascades *far* less severe.=
=20
Recompiling an `import std.vector` will be cheap, while recompiling=20
`#include <vector>` is far more expensive. So even if you have to recompile=
=20
a file, you're just recompiling that file, not the tens of thousands of=20
lines of code that the file `#include`s.

So your proposal is primarily to solve a problem which is already being=20
solved.

Also, I'm not too sure about this particular idea:

All the users instantiating instances of the class would still need to=20
> include both; instead, all the users that do not instantiate objects of=
=20
> that class but just use the public interface of the class through=20
> references or pointers would need to include only the =E2=80=9Cinterface =
header=E2=80=9D,=20
> and would not need to be recompiled when the implementation of the class =
is=20
> changed.
>

What does "instantiating instances of the class" mean? Do you mean=20
constructing/destructing values of that type? If so, then I would say that=
=20
this fails to actually accomplish the goal in *many* cases. Oh sure, if you=
=20
have some code that only accesses the type by pointer/reference, then you=
=20
may not need to recompile it. But frequently, code that uses a type also=20
needs to be able to create new copies of it and/or destroy it. So this is=
=20
only helpful to you if you're dealing with code that has a lot of pointers=
=20
to things that it does not own.

And not *smart* pointers either, since those have to be able to destroy it.

Lastly, I can't say I much like your particular means of specifying this=20
functionality. Take the example you provided in the proposal. You introduce=
=20
a name for this "contract": `StackInterface`. But you never really do=20
anything with that name. The public interface's class name is still=20
`Stack`; users will refer to it exclusively by that name. And the private=
=20
implementation's name is still `Stack`; users will refer to it exclusively=
=20
by that name. And the private implementation must include any public=20
interfaces before defining the private interface.

So... what's the point of `StackInstance`? Why not just `partial class=20
Stack` for defining the public interface, and `class Stack` for defining=20
the private implementation?

I do not find your reasoning for this new name convincing either:

Saving declarations: the =E2=80=9Cinternal class=E2=80=9D specifies that it=
 has =E2=80=9Cmoved=E2=80=9D the=20
> declaration of its public methods in the named =E2=80=9Cpartial class=E2=
=80=9D and=20
> therefore does not need to declare those public methods again.
>

This can be implicitly determined simply by knowing that a `partial class`=
=20
for that class-name has already been defined. After all, the non-partial=20
class definition will need all partial class definitions available in order=
=20
to make the class definition whole. So there's no need for it to declare=20
partial class members again.

Preventing hijacking: as the =E2=80=9Cpartial class=E2=80=9D also must have=
 a name and at=20
> the same time must specify that it is exporting methods belonging to the=
=20
> named =E2=80=9Cinternal class=E2=80=9D, the =E2=80=9Cinternal class=E2=80=
=9D has the ability to control=20
> which contracts it wants to implement; this prevents =E2=80=9Chijacking=
=E2=80=9D by third=20
> parties who otherwise would be able to declare another, unwanted =E2=80=
=9Cpartial=20
> class=E2=80=9D without having to name the =E2=80=9Cinternal class=E2=80=
=9D and thus gaining access=20
> to the private members without touching the declaration of the =E2=80=9Ci=
nternal=20
> class=E2=80=9D itself.
>

Let's examine how one would go about this hijacking without the=20
"protection" of your contract name idea.

Presumably, in order to *define* those "hijacking" members that access=20
class privates, you would need the definition of the main class you are=20
hijacking. And that main class *must* include any partial classes it uses,=
=20
correct?

So using your example, `Stack.cpp` #includes the original partial class and=
=20
the main class definition. A prospective `Hijack.cpp` defines its own new=
=20
partial class for `Stack`, after which it does `#include Stack.h` to get=20
the main class's definition (so that it can access the private members).

But this means that your `Hijack.cpp` has a class `Stack` that includes two=
=20
partial classes, while `Stack.cpp` only includes one partial class for=20
`Stack`. That violates ODR; two definitions of the same type, but those=20
definitions aren't the same.

Since you've broken ODR, you're in undefined behavior land. So your attempt=
=20
to hijack the class fails, since your code is no longer well-defined C++.

Oh sure, it'd be nice if the compiler gave you a quick error to prevent=20
such hijacking attempts, rather than being a link-time failure or runtime=
=20
undefined behavior.

But it's not like your proposed solution is immune to such perfidy either.=
=20
Consider this:

partial class Stack export StackInterface
{
  //My hijack methods
};

//Or whatever include-guards `StackInterface.h` uses
#define STACK_INTERFACE_H

#include "Stack.h"

By defining the include guard, I prevent `StackInterface.h` from being=20
included, which allows my hijack class to "work."

Of course, it doesn't actually work because it still *violates ODR*. Your=
=20
`Stack.cpp` will still define a class of the same name with a different=20
definition from `Hijack.cpp`.

So either way, you're relying on ODR to save you from hijacking. At least=
=20
my way, you don't introduce the illusion of security.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2c87118a-178b-491c-984f-12cf7023ba78%40isocpp.or=
g.

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

<div dir=3D"ltr">Seriously? A <i>zip file</i>? It&#39;s annoying enough to =
have to download a PDF, but at least that&#39;s viewable. Why can&#39;t peo=
ple just use a text file for these sorts of preliminary things? You don&#39=
;t need to provide header files for us to be able to understand the proposa=
l.<br><br>As for the proposal itself, I have to take issue with the very fi=
rst sentence:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quo=
te">The main purpose of the public and the private parts of a C++ class is =
to separate the interface of that class from its<br>implementation<br></blo=
ckquote><div><br>No. The main purpose of the public/private distinction is =
to have a language mechanism for <i>encapsulation</i>, who&#39;s main purpo=
se is to be able to establish invariants in the class which could only be b=
roken by a very limited set of code. Separating interface from implementati=
on is <i>not</i> the point at all.<br><br>If that were the purpose, we woul=
dn&#39;t have to put the interface and implementation in the same place.<br=
><br>As for the general motivation for the proposal, modules will already m=
itigate the recompilation costs reasonably effectively. You will only need =
to recompile code that imports your module if you change the actual declara=
tions within the class (public and private). Merely modifying the code in a=
 member function should *not* cause a recompilation cascade unless that fun=
ction is defined inline.<br><br>Plus, modules will generally make recompila=
tion cascades <i>far</i> less severe. Recompiling an `import std.vector` wi=
ll be cheap, while recompiling `#include &lt;vector&gt;` is far more expens=
ive. So even if you have to recompile a file, you&#39;re just recompiling t=
hat file, not the tens of thousands of lines of code that the file `#includ=
e`s.<br><br>So your proposal is primarily to solve a problem which is alrea=
dy being solved.<br><br>Also, I&#39;m not too sure about this particular id=
ea:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px=
 solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">All th=
e users instantiating instances of the class would still need to include bo=
th; instead, all the users that do not instantiate objects of that class bu=
t just use the public interface of the class through references or pointers=
 would need to include only the =E2=80=9Cinterface header=E2=80=9D, and wou=
ld not need to be recompiled when the implementation of the class is change=
d.<br></blockquote><br>What does &quot;instantiating instances of the class=
&quot; mean? Do you mean constructing/destructing values of that type? If s=
o, then I would say that this fails to actually accomplish the goal in <i>m=
any</i> cases. Oh sure, if you have some code that only accesses the type b=
y pointer/reference, then you may not need to recompile it. But frequently,=
 code that uses a type also needs to be able to create new copies of it and=
/or destroy it. So this is only helpful to you if you&#39;re dealing with c=
ode that has a lot of pointers to things that it does not own.<br><br>And n=
ot <i>smart</i> pointers either, since those have to be able to destroy it.=
<br><br>Lastly, I can&#39;t say I much like your particular means of specif=
ying this functionality. Take the example you provided in the proposal. You=
 introduce a name for this &quot;contract&quot;: `StackInterface`. But you =
never really do anything with that name. The public interface&#39;s class n=
ame is still `Stack`; users will refer to it exclusively by that name. And =
the private implementation&#39;s name is still `Stack`; users will refer to=
 it exclusively by that name. And the private implementation must include a=
ny public interfaces before defining the private interface.<br><br>So... wh=
at&#39;s the point of `StackInstance`? Why not just `partial class Stack` f=
or defining the public interface, and `class Stack` for defining the privat=
e implementation?<br><br>I do not find your reasoning for this new name con=
vincing either:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_q=
uote">Saving declarations: the =E2=80=9Cinternal class=E2=80=9D specifies t=
hat it has =E2=80=9Cmoved=E2=80=9D the declaration of its public methods in=
 the named =E2=80=9Cpartial class=E2=80=9D and therefore does not need to d=
eclare those public methods again.<br></blockquote><div><br>This can be imp=
licitly determined simply by knowing that a `partial class` for that class-=
name has already been defined. After all, the non-partial class definition =
will need all partial class definitions available in order to make the clas=
s definition whole. So there&#39;s no need for it to declare partial class =
members again.<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_qu=
ote">Preventing hijacking: as the =E2=80=9Cpartial class=E2=80=9D also must=
 have a name and at the same time must specify that it is exporting methods=
 belonging to the named =E2=80=9Cinternal class=E2=80=9D, the =E2=80=9Cinte=
rnal class=E2=80=9D has the ability to control which contracts it wants to =
implement; this prevents =E2=80=9Chijacking=E2=80=9D by third parties who o=
therwise would be able to declare another, unwanted =E2=80=9Cpartial class=
=E2=80=9D without having to name the =E2=80=9Cinternal class=E2=80=9D and t=
hus gaining access to the private members without touching the declaration =
of the =E2=80=9Cinternal class=E2=80=9D itself.<br></blockquote><div><br>Le=
t&#39;s examine how one would go about this hijacking without the &quot;pro=
tection&quot; of your contract name idea.<br><br>Presumably, in order to <i=
>define</i> those &quot;hijacking&quot; members that access class privates,=
 you would need the definition of the main class you are hijacking. And tha=
t main class <i>must</i> include any partial classes it uses, correct?<br><=
br>So using your example, `Stack.cpp` #includes the original partial class =
and the main class definition. A prospective `Hijack.cpp` defines its own n=
ew partial class for `Stack`, after which it does `#include Stack.h` to get=
 the main class&#39;s definition (so that it can access the private members=
).<br><br>But this means that your `Hijack.cpp` has a class `Stack` that in=
cludes two partial classes, while `Stack.cpp` only includes one partial cla=
ss for `Stack`. That violates ODR; two definitions of the same type, but th=
ose definitions aren&#39;t the same.<br><br>Since you&#39;ve broken ODR, yo=
u&#39;re in undefined behavior land. So your attempt to hijack the class fa=
ils, since your code is no longer well-defined C++.<br><br>Oh sure, it&#39;=
d be nice if the compiler gave you a quick error to prevent such hijacking =
attempts, rather than being a link-time failure or runtime undefined behavi=
or.<br><br>But it&#39;s not like your proposed solution is immune to such p=
erfidy either. Consider this:<br><br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">partial</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Stack</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">export</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">StackInterface</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"styled-by-prettify"><br>=C2=A0 </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">//My hijack methods</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">//Or whatever include-guards `StackInterfac=
e.h` uses</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">#define=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> STACK_INT=
ERFACE_H<br><br></span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">#include</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&quot=
;Stack.h&quot;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span></div></code></div><br>By defining the include guard, I prev=
ent `StackInterface.h` from being included, which allows my hijack class to=
 &quot;work.&quot;<br><br>Of course, it doesn&#39;t actually work because i=
t still <i>violates ODR</i>. Your `Stack.cpp` will still define a class of =
the same name with a different definition from `Hijack.cpp`.<br><br>So eith=
er way, you&#39;re relying on ODR to save you from hijacking. At least my w=
ay, you don&#39;t introduce the illusion of security.<br></div></div></div>=
</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2c87118a-178b-491c-984f-12cf7023ba78%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2c87118a-178b-491c-984f-12cf7023ba78=
%40isocpp.org</a>.<br />

------=_Part_760_1181297829.1456247587988--
------=_Part_759_985625534.1456247587987--

.

------=_Part_403_233945056.1456250809833
Content-Type: multipart/alternative;
 boundary="----=_Part_404_819765611.1456250809834"

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

"You will only need to recompile code that imports your module if you=20
change the actual declarations within the class (public and private)."

That is *exactly *what my proposal avoids: recompile code if *only the=20
private part* of the used class is changed. If modules require to recompile=
=20
their users when the private part is changed, they *do not *resolve the=20
recompilation problem.=20

Il giorno marted=C3=AC 23 febbraio 2016 18:13:08 UTC+1, Nicol Bolas ha scri=
tto:
>
> Seriously? A *zip file*? It's annoying enough to have to download a PDF,=
=20
> but at least that's viewable. Why can't people just use a text file for=
=20
> these sorts of preliminary things? You don't need to provide header files=
=20
> for us to be able to understand the proposal.
>
> As for the proposal itself, I have to take issue with the very first=20
> sentence:
>
> The main purpose of the public and the private parts of a C++ class is to=
=20
>> separate the interface of that class from its
>> implementation
>>
>
> No. The main purpose of the public/private distinction is to have a=20
> language mechanism for *encapsulation*, who's main purpose is to be able=
=20
> to establish invariants in the class which could only be broken by a very=
=20
> limited set of code. Separating interface from implementation is *not*=20
> the point at all.
>
> If that were the purpose, we wouldn't have to put the interface and=20
> implementation in the same place.
>
> As for the general motivation for the proposal, modules will already=20
> mitigate the recompilation costs reasonably effectively. You will only ne=
ed=20
> to recompile code that imports your module if you change the actual=20
> declarations within the class (public and private). Merely modifying the=
=20
> code in a member function should *not* cause a recompilation cascade unle=
ss=20
> that function is defined inline.
>
> Plus, modules will generally make recompilation cascades *far* less=20
> severe. Recompiling an `import std.vector` will be cheap, while recompili=
ng=20
> `#include <vector>` is far more expensive. So even if you have to recompi=
le=20
> a file, you're just recompiling that file, not the tens of thousands of=
=20
> lines of code that the file `#include`s.
>
> So your proposal is primarily to solve a problem which is already being=
=20
> solved.
>
> Also, I'm not too sure about this particular idea:
>
> All the users instantiating instances of the class would still need to=20
>> include both; instead, all the users that do not instantiate objects of=
=20
>> that class but just use the public interface of the class through=20
>> references or pointers would need to include only the =E2=80=9Cinterface=
 header=E2=80=9D,=20
>> and would not need to be recompiled when the implementation of the class=
 is=20
>> changed.
>>
>
> What does "instantiating instances of the class" mean? Do you mean=20
> constructing/destructing values of that type? If so, then I would say tha=
t=20
> this fails to actually accomplish the goal in *many* cases. Oh sure, if=
=20
> you have some code that only accesses the type by pointer/reference, then=
=20
> you may not need to recompile it. But frequently, code that uses a type=
=20
> also needs to be able to create new copies of it and/or destroy it. So th=
is=20
> is only helpful to you if you're dealing with code that has a lot of=20
> pointers to things that it does not own.
>
> And not *smart* pointers either, since those have to be able to destroy=
=20
> it.
>
> Lastly, I can't say I much like your particular means of specifying this=
=20
> functionality. Take the example you provided in the proposal. You introdu=
ce=20
> a name for this "contract": `StackInterface`. But you never really do=20
> anything with that name. The public interface's class name is still=20
> `Stack`; users will refer to it exclusively by that name. And the private=
=20
> implementation's name is still `Stack`; users will refer to it exclusivel=
y=20
> by that name. And the private implementation must include any public=20
> interfaces before defining the private interface.
>
> So... what's the point of `StackInstance`? Why not just `partial class=20
> Stack` for defining the public interface, and `class Stack` for defining=
=20
> the private implementation?
>
> I do not find your reasoning for this new name convincing either:
>
> Saving declarations: the =E2=80=9Cinternal class=E2=80=9D specifies that =
it has =E2=80=9Cmoved=E2=80=9D=20
>> the declaration of its public methods in the named =E2=80=9Cpartial clas=
s=E2=80=9D and=20
>> therefore does not need to declare those public methods again.
>>
>
> This can be implicitly determined simply by knowing that a `partial class=
`=20
> for that class-name has already been defined. After all, the non-partial=
=20
> class definition will need all partial class definitions available in ord=
er=20
> to make the class definition whole. So there's no need for it to declare=
=20
> partial class members again.
>
> Preventing hijacking: as the =E2=80=9Cpartial class=E2=80=9D also must ha=
ve a name and at=20
>> the same time must specify that it is exporting methods belonging to the=
=20
>> named =E2=80=9Cinternal class=E2=80=9D, the =E2=80=9Cinternal class=E2=
=80=9D has the ability to control=20
>> which contracts it wants to implement; this prevents =E2=80=9Chijacking=
=E2=80=9D by third=20
>> parties who otherwise would be able to declare another, unwanted =E2=80=
=9Cpartial=20
>> class=E2=80=9D without having to name the =E2=80=9Cinternal class=E2=80=
=9D and thus gaining access=20
>> to the private members without touching the declaration of the =E2=80=9C=
internal=20
>> class=E2=80=9D itself.
>>
>
> Let's examine how one would go about this hijacking without the=20
> "protection" of your contract name idea.
>
> Presumably, in order to *define* those "hijacking" members that access=20
> class privates, you would need the definition of the main class you are=
=20
> hijacking. And that main class *must* include any partial classes it=20
> uses, correct?
>
> So using your example, `Stack.cpp` #includes the original partial class=
=20
> and the main class definition. A prospective `Hijack.cpp` defines its own=
=20
> new partial class for `Stack`, after which it does `#include Stack.h` to=
=20
> get the main class's definition (so that it can access the private member=
s).
>
> But this means that your `Hijack.cpp` has a class `Stack` that includes=
=20
> two partial classes, while `Stack.cpp` only includes one partial class fo=
r=20
> `Stack`. That violates ODR; two definitions of the same type, but those=
=20
> definitions aren't the same.
>
> Since you've broken ODR, you're in undefined behavior land. So your=20
> attempt to hijack the class fails, since your code is no longer=20
> well-defined C++.
>
> Oh sure, it'd be nice if the compiler gave you a quick error to prevent=
=20
> such hijacking attempts, rather than being a link-time failure or runtime=
=20
> undefined behavior.
>
> But it's not like your proposed solution is immune to such perfidy either=
..=20
> Consider this:
>
> partial class Stack export StackInterface
> {
>   //My hijack methods
> };
>
> //Or whatever include-guards `StackInterface.h` uses
> #define STACK_INTERFACE_H
>
> #include "Stack.h"
>
> By defining the include guard, I prevent `StackInterface.h` from being=20
> included, which allows my hijack class to "work."
>
> Of course, it doesn't actually work because it still *violates ODR*. Your=
=20
> `Stack.cpp` will still define a class of the same name with a different=
=20
> definition from `Hijack.cpp`.
>
> So either way, you're relying on ODR to save you from hijacking. At least=
=20
> my way, you don't introduce the illusion of security.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/47161298-ff63-4a4a-a5fc-036afbb37baf%40isocpp.or=
g.

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

<div dir=3D"ltr">&quot;You will only need to recompile code that imports yo=
ur module if you=20
change the actual declarations within the class (public and private).&quot;=
<br><br>That is <b>exactly </b>what my proposal avoids: recompile code if <=
b>only the private part</b> of the used class is changed. If modules requir=
e to recompile their users when the private part is changed, they <b>do not=
 </b>resolve the recompilation problem. <br><br>Il giorno marted=C3=AC 23 f=
ebbraio 2016 18:13:08 UTC+1, Nicol Bolas ha scritto:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr">Seriously? A <i>zip file</i>? It&#39=
;s annoying enough to have to download a PDF, but at least that&#39;s viewa=
ble. Why can&#39;t people just use a text file for these sorts of prelimina=
ry things? You don&#39;t need to provide header files for us to be able to =
understand the proposal.<br><br>As for the proposal itself, I have to take =
issue with the very first sentence:<br><br><blockquote style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" clas=
s=3D"gmail_quote">The main purpose of the public and the private parts of a=
 C++ class is to separate the interface of that class from its<br>implement=
ation<br></blockquote><div><br>No. The main purpose of the public/private d=
istinction is to have a language mechanism for <i>encapsulation</i>, who&#3=
9;s main purpose is to be able to establish invariants in the class which c=
ould only be broken by a very limited set of code. Separating interface fro=
m implementation is <i>not</i> the point at all.<br><br>If that were the pu=
rpose, we wouldn&#39;t have to put the interface and implementation in the =
same place.<br><br>As for the general motivation for the proposal, modules =
will already mitigate the recompilation costs reasonably effectively. You w=
ill only need to recompile code that imports your module if you change the =
actual declarations within the class (public and private). Merely modifying=
 the code in a member function should *not* cause a recompilation cascade u=
nless that function is defined inline.<br><br>Plus, modules will generally =
make recompilation cascades <i>far</i> less severe. Recompiling an `import =
std.vector` will be cheap, while recompiling `#include &lt;vector&gt;` is f=
ar more expensive. So even if you have to recompile a file, you&#39;re just=
 recompiling that file, not the tens of thousands of lines of code that the=
 file `#include`s.<br><br>So your proposal is primarily to solve a problem =
which is already being solved.<br><br>Also, I&#39;m not too sure about this=
 particular idea:<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">=
All the users instantiating instances of the class would still need to incl=
ude both; instead, all the users that do not instantiate objects of that cl=
ass but just use the public interface of the class through references or po=
inters would need to include only the =E2=80=9Cinterface header=E2=80=9D, a=
nd would not need to be recompiled when the implementation of the class is =
changed.<br></blockquote><br>What does &quot;instantiating instances of the=
 class&quot; mean? Do you mean constructing/destructing values of that type=
? If so, then I would say that this fails to actually accomplish the goal i=
n <i>many</i> cases. Oh sure, if you have some code that only accesses the =
type by pointer/reference, then you may not need to recompile it. But frequ=
ently, code that uses a type also needs to be able to create new copies of =
it and/or destroy it. So this is only helpful to you if you&#39;re dealing =
with code that has a lot of pointers to things that it does not own.<br><br=
>And not <i>smart</i> pointers either, since those have to be able to destr=
oy it.<br><br>Lastly, I can&#39;t say I much like your particular means of =
specifying this functionality. Take the example you provided in the proposa=
l. You introduce a name for this &quot;contract&quot;: `StackInterface`. Bu=
t you never really do anything with that name. The public interface&#39;s c=
lass name is still `Stack`; users will refer to it exclusively by that name=
.. And the private implementation&#39;s name is still `Stack`; users will re=
fer to it exclusively by that name. And the private implementation must inc=
lude any public interfaces before defining the private interface.<br><br>So=
.... what&#39;s the point of `StackInstance`? Why not just `partial class St=
ack` for defining the public interface, and `class Stack` for defining the =
private implementation?<br><br>I do not find your reasoning for this new na=
me convincing either:<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quo=
te">Saving declarations: the =E2=80=9Cinternal class=E2=80=9D specifies tha=
t it has =E2=80=9Cmoved=E2=80=9D the declaration of its public methods in t=
he named =E2=80=9Cpartial class=E2=80=9D and therefore does not need to dec=
lare those public methods again.<br></blockquote><div><br>This can be impli=
citly determined simply by knowing that a `partial class` for that class-na=
me has already been defined. After all, the non-partial class definition wi=
ll need all partial class definitions available in order to make the class =
definition whole. So there&#39;s no need for it to declare partial class me=
mbers again.<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Preve=
nting hijacking: as the =E2=80=9Cpartial class=E2=80=9D also must have a na=
me and at the same time must specify that it is exporting methods belonging=
 to the named =E2=80=9Cinternal class=E2=80=9D, the =E2=80=9Cinternal class=
=E2=80=9D has the ability to control which contracts it wants to implement;=
 this prevents =E2=80=9Chijacking=E2=80=9D by third parties who otherwise w=
ould be able to declare another, unwanted =E2=80=9Cpartial class=E2=80=9D w=
ithout having to name the =E2=80=9Cinternal class=E2=80=9D and thus gaining=
 access to the private members without touching the declaration of the =E2=
=80=9Cinternal class=E2=80=9D itself.<br></blockquote><div><br>Let&#39;s ex=
amine how one would go about this hijacking without the &quot;protection&qu=
ot; of your contract name idea.<br><br>Presumably, in order to <i>define</i=
> those &quot;hijacking&quot; members that access class privates, you would=
 need the definition of the main class you are hijacking. And that main cla=
ss <i>must</i> include any partial classes it uses, correct?<br><br>So usin=
g your example, `Stack.cpp` #includes the original partial class and the ma=
in class definition. A prospective `Hijack.cpp` defines its own new partial=
 class for `Stack`, after which it does `#include Stack.h` to get the main =
class&#39;s definition (so that it can access the private members).<br><br>=
But this means that your `Hijack.cpp` has a class `Stack` that includes two=
 partial classes, while `Stack.cpp` only includes one partial class for `St=
ack`. That violates ODR; two definitions of the same type, but those defini=
tions aren&#39;t the same.<br><br>Since you&#39;ve broken ODR, you&#39;re i=
n undefined behavior land. So your attempt to hijack the class fails, since=
 your code is no longer well-defined C++.<br><br>Oh sure, it&#39;d be nice =
if the compiler gave you a quick error to prevent such hijacking attempts, =
rather than being a link-time failure or runtime undefined behavior.<br><br=
>But it&#39;s not like your proposed solution is immune to such perfidy eit=
her. Consider this:<br><br><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap=
:break-word"><code><div><span style=3D"color:#008">partial</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">class</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Stack</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">export</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">StackInterface</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span=
 style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">//My hij=
ack methods</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#660">};</span><span style=3D"color:#000"><br><br></span><span style=3D"c=
olor:#800">//Or whatever include-guards `StackInterface.h` uses</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#800">#define</span><=
span style=3D"color:#000"> STACK_INTERFACE_H<br><br></span><span style=3D"c=
olor:#800">#include</span><span style=3D"color:#000"> </span><span style=3D=
"color:#080">&quot;Stack.h&quot;</span><span style=3D"color:#000"><br></spa=
n></div></code></div><br>By defining the include guard, I prevent `StackInt=
erface.h` from being included, which allows my hijack class to &quot;work.&=
quot;<br><br>Of course, it doesn&#39;t actually work because it still <i>vi=
olates ODR</i>. Your `Stack.cpp` will still define a class of the same name=
 with a different definition from `Hijack.cpp`.<br><br>So either way, you&#=
39;re relying on ODR to save you from hijacking. At least my way, you don&#=
39;t introduce the illusion of security.<br></div></div></div></div></block=
quote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/47161298-ff63-4a4a-a5fc-036afbb37baf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/47161298-ff63-4a4a-a5fc-036afbb37baf=
%40isocpp.org</a>.<br />

------=_Part_404_819765611.1456250809834--
------=_Part_403_233945056.1456250809833--

.

------=_Part_787_1273093763.1456251372513
Content-Type: multipart/alternative;
 boundary="----=_Part_788_231242605.1456251372513"

------=_Part_788_231242605.1456251372513
Content-Type: text/plain; charset=UTF-8

"What does "instantiating instances of the class" mean? Do you mean
constructing/destructing values of that type? If so, then I would say that
this fails to actually accomplish the goal in *many* cases. Oh sure, if you
have some code that only accesses the type by pointer/reference, then you
may not need to recompile it. But frequently, code that uses a type also
needs to be able to create new copies of it and/or destroy it. So this is
only helpful to you if you're dealing with code that has a lot of pointers
to things that it does not own."

Yes, this is the typical case in embedded software. Objects are statically
created once, and used somewhere else with pointer/references for instance
after dependency injections.
No new copies are created nor destroyed (dynamic memory is typically
prohibited in embedded software).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/406d5ed9-8beb-4cfa-85c4-238d31c02d8a%40isocpp.org.

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

<div dir=3D"ltr">&quot;What does &quot;instantiating instances of the class=
&quot; mean? Do you mean=20
constructing/destructing values of that type? If so, then I would say=20
that this fails to actually accomplish the goal in <i>many</i> cases. Oh
 sure, if you have some code that only accesses the type by=20
pointer/reference, then you may not need to recompile it. But=20
frequently, code that uses a type also needs to be able to create new=20
copies of it and/or destroy it. So this is only helpful to you if you&#39;r=
e
 dealing with code that has a lot of pointers to things that it does not
 own.&quot;<br><br>Yes, this is the typical case in embedded software. Obje=
cts are statically created once, and used somewhere else with pointer/refer=
ences for instance after dependency injections. <br>No new copies are creat=
ed nor destroyed (dynamic memory is typically prohibited in embedded softwa=
re).<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/406d5ed9-8beb-4cfa-85c4-238d31c02d8a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/406d5ed9-8beb-4cfa-85c4-238d31c02d8a=
%40isocpp.org</a>.<br />

------=_Part_788_231242605.1456251372513--
------=_Part_787_1273093763.1456251372513--

.

------=_Part_805_77192769.1456252917984
Content-Type: multipart/alternative;
 boundary="----=_Part_806_930884945.1456252917984"

------=_Part_806_930884945.1456252917984
Content-Type: text/plain; charset=UTF-8



On Tuesday, February 23, 2016 at 1:06:50 PM UTC-5, daniele...@gmail.com
wrote:
>
> "You will only need to recompile code that imports your module if you
> change the actual declarations within the class (public and private)."
>
> That is *exactly *what my proposal avoids: recompile code if *only the
> private part* of the used class is changed. If modules require to
> recompile their users when the private part is changed, they *do not *resolve
> the recompilation problem.
>

So what? How often do you change the declarations in a class? How often do
you add new members to a class? Compare that to how often you modify the
actual contents of member functions.

It's not nearly as often.

Also, as I pointed out, modules makes recompilation much cheaper on the
whole. So even if you still need a recompilation, that recompilation will
be significantly *faster* than if you didn't.

Yes, the problem didn't go away. But it's far less of an issue.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27f03075-2c48-4b50-b91f-a5f2eb2f6021%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, February 23, 2016 at 1:06:50 PM UTC-5,=
 daniele...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">&quot;You will only need to recompile code that imports your=
 module if you=20
change the actual declarations within the class (public and private).&quot;=
<br><br>That is <b>exactly </b>what my proposal avoids: recompile code if <=
b>only the private part</b> of the used class is changed. If modules requir=
e to recompile their users when the private part is changed, they <b>do not=
 </b>resolve the recompilation problem.</div></blockquote><div><br>So what?=
 How often do you change the declarations in a class? How often do you add =
new members to a class? Compare that to how often you modify the actual con=
tents of member functions.<br><br>It&#39;s not nearly as often.<br><br>Also=
, as I pointed out, modules makes recompilation much cheaper on the whole. =
So even if you still need a recompilation, that recompilation will be signi=
ficantly <i>faster</i> than if you didn&#39;t.<br><br>Yes, the problem didn=
&#39;t go away. But it&#39;s far less of an issue.</div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/27f03075-2c48-4b50-b91f-a5f2eb2f6021%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/27f03075-2c48-4b50-b91f-a5f2eb2f6021=
%40isocpp.org</a>.<br />

------=_Part_806_930884945.1456252917984--
------=_Part_805_77192769.1456252917984--

.

------=_Part_11113_47441159.1456256813959
Content-Type: multipart/alternative;
 boundary="----=_Part_11114_1837045919.1456256813959"

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

"So what?"

in large embedded system projects with frequent integrations and testing,=
=20
the changes to the private part of a class are really frequent.
Private part does not mean only data members, but also private helper=20
methods, tipically added to simplify the implementation of public methods.
Anyhow, another annoying issue that causes the need to recompile is=20
represented by the other header files included by the header of a class=20
because needed only by its private part. Changes in those header files=20
drives also to recompile the users of the class, even if they do not need=
=20
at all those other header files. And so on.

As stated in the .pdf explaining my proposal, the introduction of=20
polymorphism in the Stroustroup book and the Handle/Body pattern introduced=
=20
by Coplien addresses exactly this recompile-need issue, evidently because=
=20
it *is *an issue!
Unfortunately both solutions need additional memory, which does not fit=20
embedded systems.
Anyhow, nice to know that modules *do not* solve the recompilation problem=
=20
addressed by my proposal: at least, I did not think in vain.

Il giorno marted=C3=AC 23 febbraio 2016 19:41:58 UTC+1, Nicol Bolas ha scri=
tto:
>
>
>
> On Tuesday, February 23, 2016 at 1:06:50 PM UTC-5, daniele...@gmail.com=
=20
> wrote:
>>
>> "You will only need to recompile code that imports your module if you=20
>> change the actual declarations within the class (public and private)."
>>
>> That is *exactly *what my proposal avoids: recompile code if *only the=
=20
>> private part* of the used class is changed. If modules require to=20
>> recompile their users when the private part is changed, they *do not *re=
solve=20
>> the recompilation problem.
>>
>
> So what? How often do you change the declarations in a class? How often d=
o=20
> you add new members to a class? Compare that to how often you modify the=
=20
> actual contents of member functions.
>
> It's not nearly as often.
>
> Also, as I pointed out, modules makes recompilation much cheaper on the=
=20
> whole. So even if you still need a recompilation, that recompilation will=
=20
> be significantly *faster* than if you didn't.
>
> Yes, the problem didn't go away. But it's far less of an issue.
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/53e05fd6-0dc6-4b89-8313-de6528b77004%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>&quot;So what?&quot;</div><div><br></div><div>in larg=
e embedded system projects with frequent integrations and testing, the chan=
ges to the private part of a class are really frequent.</div><div>Private p=
art does not mean only data members, but also private helper methods, tipic=
ally added to simplify the implementation of public methods.</div><div>Anyh=
ow, another annoying issue that causes the need to recompile is represented=
 by the other header files included by the header of a class because needed=
 only by its private part. Changes in those header files drives also to rec=
ompile the users of the class, even if they do not need at all those other =
header files. And so on.</div><div><br></div><div>As stated in the .pdf exp=
laining my proposal, the introduction of polymorphism in the Stroustroup bo=
ok and the Handle/Body pattern introduced by Coplien addresses exactly this=
 recompile-need issue, evidently because it <b>is </b>an issue!</div><div>U=
nfortunately both solutions need additional memory, which does not fit embe=
dded systems.</div><div>Anyhow, nice to know that modules <b>do not</b> sol=
ve the recompilation problem addressed by my proposal: at least, I did not =
think in vain.</div><div><br>Il giorno marted=C3=AC 23 febbraio 2016 19:41:=
58 UTC+1, Nicol Bolas ha scritto:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><br><br>On Tuesday, February 23, 2016 at 1:06:50 PM UTC=
-5, <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">&quot;You will only need to recompile code that imports=
 your module if you=20
change the actual declarations within the class (public and private).&quot;=
<br><br>That is <b>exactly </b>what my proposal avoids: recompile code if <=
b>only the private part</b> of the used class is changed. If modules requir=
e to recompile their users when the private part is changed, they <b>do not=
 </b>resolve the recompilation problem.</div></blockquote><div><br>So what?=
 How often do you change the declarations in a class? How often do you add =
new members to a class? Compare that to how often you modify the actual con=
tents of member functions.<br><br>It&#39;s not nearly as often.<br><br>Also=
, as I pointed out, modules makes recompilation much cheaper on the whole. =
So even if you still need a recompilation, that recompilation will be signi=
ficantly <i>faster</i> than if you didn&#39;t.<br><br>Yes, the problem didn=
&#39;t go away. But it&#39;s far less of an issue.</div><br></div></blockqu=
ote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/53e05fd6-0dc6-4b89-8313-de6528b77004%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/53e05fd6-0dc6-4b89-8313-de6528b77004=
%40isocpp.org</a>.<br />

------=_Part_11114_1837045919.1456256813959--
------=_Part_11113_47441159.1456256813959--

.

------=_Part_10867_1738500323.1456279234711
Content-Type: multipart/alternative;
 boundary="----=_Part_10868_100495248.1456279234712"

------=_Part_10868_100495248.1456279234712
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 23, 2016 at 2:46:54 PM UTC-5, daniele...@gmail.com
wrote:
>
> "So what?"
>
> in large embedded system projects with frequent integrations and testing,
> the changes to the private part of a class are really frequent.
> Private part does not mean only data members, but also private helper
> methods, tipically added to simplify the implementation of public methods.
> Anyhow, another annoying issue that causes the need to recompile is
> represented by the other header files included by the header of a class
> because needed only by its private part. Changes in those header files
> drives also to recompile the users of the class, even if they do not need
> at all those other header files. And so on.
>
As stated in the .pdf explaining my proposal, the introduction of
> polymorphism in the Stroustroup book and the Handle/Body pattern introduced
> by Coplien addresses exactly this recompile-need issue, evidently because
> it *is *an issue!
> Unfortunately both solutions need additional memory, which does not fit
> embedded systems.
> Anyhow, nice to know that modules *do not* solve the recompilation
> problem addressed by my proposal: at least, I did not think in vain.
>

I think your focus on the "recompilation problem" is misdirected.

The "recompilation problem" is only a problem for one reason: recompilation
takes a long time. Recompilation takes a long time because the C++
inclusion mechanism is entirely textual. If you recompile a 500 line file,
what you're really doing is recompiling tens of thousands of lines of
included C++ code.

With modules, recompiling a 500 line file requires compiling 500 lines of
C++ code.

As such, with modules the "recompilation problem" is no longer a *problem*.
That is, yes, you will still have to recompile code. But since recompiling
your code will be *much faster*, you won't care.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0231918b-e788-48f5-b5ef-233b6dc40a13%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, February 23, 2016 at 2:46:54 PM UTC-5, daniele=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>&quot;So what?&quot;</div><div><br></div><div>in large embedd=
ed system projects with frequent integrations and testing, the changes to t=
he private part of a class are really frequent.</div><div>Private part does=
 not mean only data members, but also private helper methods, tipically add=
ed to simplify the implementation of public methods.</div><div>Anyhow, anot=
her annoying issue that causes the need to recompile is represented by the =
other header files included by the header of a class because needed only by=
 its private part. Changes in those header files drives also to recompile t=
he users of the class, even if they do not need at all those other header f=
iles. And so on.</div></div></blockquote><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div></div><div>As stated in the .pdf explainin=
g my proposal, the introduction of polymorphism in the Stroustroup book and=
 the Handle/Body pattern introduced by Coplien addresses exactly this recom=
pile-need issue, evidently because it <b>is </b>an issue!</div><div>Unfortu=
nately both solutions need additional memory, which does not fit embedded s=
ystems.</div><div>Anyhow, nice to know that modules <b>do not</b> solve the=
 recompilation problem addressed by my proposal: at least, I did not think =
in vain.</div></div></blockquote><div><br>I think your focus on the &quot;r=
ecompilation problem&quot; is misdirected.<br><br>The &quot;recompilation p=
roblem&quot; is only a problem for one reason: recompilation takes a long t=
ime. Recompilation takes a long time because the C++ inclusion mechanism is=
 entirely textual. If you recompile a 500 line file, what you&#39;re really=
 doing is recompiling tens of thousands of lines of included C++ code.<br><=
br>With modules, recompiling a 500 line file requires compiling 500 lines o=
f C++ code.<br><br>As such, with modules the &quot;recompilation problem&qu=
ot; is no longer a <i>problem</i>. That is, yes, you will still have to rec=
ompile code. But since recompiling your code will be <i>much faster</i>, yo=
u won&#39;t care.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0231918b-e788-48f5-b5ef-233b6dc40a13%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0231918b-e788-48f5-b5ef-233b6dc40a13=
%40isocpp.org</a>.<br />

------=_Part_10868_100495248.1456279234712--
------=_Part_10867_1738500323.1456279234711--

.

------=_Part_7022_665487974.1456285639760
Content-Type: text/plain; charset=UTF-8

It depends; anyhow, not in general.
The typical case is when users are many and big and the header file of the used class is small: in that case the recompilation due to modules won't be faster at all.
Again, we are talking about two different things. I do not doubt that modules is a nice construct, but as you confirm, it does not address the problem solved by my proposal: remove completely useless compile dependencies.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a7a878a3-dd52-4a19-8aba-20eae32341f1%40isocpp.org.

------=_Part_7022_665487974.1456285639760--

.

------=_Part_237_1360589564.1456473948788
Content-Type: multipart/alternative;
 boundary="----=_Part_238_633154546.1456473948789"

------=_Part_238_633154546.1456473948789
Content-Type: text/plain; charset=UTF-8

Summary of comments up to now:
This "partial class" proposal remove compile dependencies with no
additional memory cost; no current C++ possible solution achieves both.
The "module" construct has some benefits but does *not* remove the compile
dependencies addressed by this "partial class" proposal: therefore both
proposals could coexist together with their orthogonal benefits.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/18a10a5c-ff3c-47da-ac10-f04d6898eb42%40isocpp.org.

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

<div dir=3D"ltr">Summary of comments up to now: <br>This &quot;partial clas=
s&quot; proposal remove compile dependencies with no additional memory cost=
; no current C++ possible solution achieves both.<br>The &quot;module&quot;=
 construct has some benefits but does *not* remove the compile dependencies=
 addressed by this &quot;partial class&quot; proposal: therefore both propo=
sals could coexist together with their orthogonal benefits.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/18a10a5c-ff3c-47da-ac10-f04d6898eb42%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/18a10a5c-ff3c-47da-ac10-f04d6898eb42=
%40isocpp.org</a>.<br />

------=_Part_238_633154546.1456473948789--
------=_Part_237_1360589564.1456473948788--

.

------=_Part_332_724632751.1456478695120
Content-Type: multipart/alternative;
 boundary="----=_Part_333_103471401.1456478695126"

------=_Part_333_103471401.1456478695126
Content-Type: text/plain; charset=UTF-8

To me, module proposal can actually handle this. A compiler smart enough
can extract "public layer" from module definition and recompile dependents
only when that public layer is changed. And please note that that public
layer will also include at least size of private part. Something like
`private: char _1234__[PRIVATE_PART_SIZE];`

On Friday, February 26, 2016 at 10:05:49 AM UTC+2, daniele...@gmail.com
wrote:
>
> Summary of comments up to now:
> This "partial class" proposal remove compile dependencies with no
> additional memory cost; no current C++ possible solution achieves both.
> The "module" construct has some benefits but does *not* remove the compile
> dependencies addressed by this "partial class" proposal: therefore both
> proposals could coexist together with their orthogonal benefits.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c5288672-6319-4af4-9457-30ce10ad580b%40isocpp.org.

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

<div dir=3D"ltr">To me, module proposal can actually handle this. A compile=
r smart enough can extract &quot;public layer&quot; from module definition =
and recompile dependents only when that public layer is changed. And please=
 note that that public layer will also include at least size of private par=
t. Something like `private: char _1234__[PRIVATE_PART_SIZE];`<br><br>On Fri=
day, February 26, 2016 at 10:05:49 AM UTC+2, daniele...@gmail.com wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Summary of comme=
nts up to now: <br>This &quot;partial class&quot; proposal remove compile d=
ependencies with no additional memory cost; no current C++ possible solutio=
n achieves both.<br>The &quot;module&quot; construct has some benefits but =
does *not* remove the compile dependencies addressed by this &quot;partial =
class&quot; proposal: therefore both proposals could coexist together with =
their orthogonal benefits.<br></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c5288672-6319-4af4-9457-30ce10ad580b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c5288672-6319-4af4-9457-30ce10ad580b=
%40isocpp.org</a>.<br />

------=_Part_333_103471401.1456478695126--
------=_Part_332_724632751.1456478695120--

.

------=_Part_5_511099.1456481002667
Content-Type: multipart/alternative;
 boundary="----=_Part_6_409261640.1456481002667"

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

If "*that public layer will also include at least size of private part*",=
=20
still the module construct
* does not remove compile dependencies.*Users of a class C having a=20
reference or pointer to class C* do not need to be recompiled* if the size=
=20
of class C changes because private members where added or modified.


Il giorno venerd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha scr=
itto:
>
> To me, module proposal can actually handle this. A compiler smart enough=
=20
> can extract "public layer" from module definition and recompile dependent=
s=20
> only when that public layer is changed. And please note that that public=
=20
> layer will also include at least size of private part. Something like=20
> `private: char _1234__[PRIVATE_PART_SIZE];`
>
> On Friday, February 26, 2016 at 10:05:49 AM UTC+2, daniele...@gmail.com=
=20
> wrote:
>>
>> Summary of comments up to now:=20
>> This "partial class" proposal remove compile dependencies with no=20
>> additional memory cost; no current C++ possible solution achieves both.
>> The "module" construct has some benefits but does *not* remove the=20
>> compile dependencies addressed by this "partial class" proposal: therefo=
re=20
>> both proposals could coexist together with their orthogonal benefits.
>>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e242d554-2332-46ae-9f7d-a6a50956a7a5%40isocpp.or=
g.

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

<div dir=3D"ltr">If &quot;<i>that public layer will also include at least s=
ize of=20
private part</i>&quot;, still the module construct<b> does not remove compi=
le dependencies.<br></b>Users of a class C having a reference or pointer to=
 class C<b> do not need to be recompiled</b> if the size of class C changes=
 because private members where added or modified.<br><br><br>Il giorno vene=
rd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha scritto:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">To me, module proposal=
 can actually handle this. A compiler smart enough can extract &quot;public=
 layer&quot; from module definition and recompile dependents only when that=
 public layer is changed. And please note that that public layer will also =
include at least size of private part. Something like `private: char _1234_=
_[PRIVATE_PART_SIZE];`<br><br>On Friday, February 26, 2016 at 10:05:49 AM U=
TC+2, <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">Summary of comments up to now: <br>This &quot;partial=
 class&quot; proposal remove compile dependencies with no additional memory=
 cost; no current C++ possible solution achieves both.<br>The &quot;module&=
quot; construct has some benefits but does *not* remove the compile depende=
ncies addressed by this &quot;partial class&quot; proposal: therefore both =
proposals could coexist together with their orthogonal benefits.<br></div><=
/blockquote></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e242d554-2332-46ae-9f7d-a6a50956a7a5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e242d554-2332-46ae-9f7d-a6a50956a7a5=
%40isocpp.org</a>.<br />

------=_Part_6_409261640.1456481002667--
------=_Part_5_511099.1456481002667--

.

------=_Part_146_1286353816.1456484798708
Content-Type: multipart/alternative;
 boundary="----=_Part_147_250460176.1456484798708"

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

I still don't see why you want to enforce such responsibility onto=20
programmers. Let's have another header type?
IMO compiler can perfectly deduce even such cases. It's compiler=20
responsibility to track dependencies and not mine.

On Friday, February 26, 2016 at 12:03:23 PM UTC+2, daniele...@gmail.com=20
wrote:
>
> If "*that public layer will also include at least size of private part*",=
=20
> still the module construct
> * does not remove compile dependencies.*Users of a class C having a=20
> reference or pointer to class C* do not need to be recompiled* if the=20
> size of class C changes because private members where added or modified.
>
>
> Il giorno venerd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha s=
critto:
>>
>> To me, module proposal can actually handle this. A compiler smart enough=
=20
>> can extract "public layer" from module definition and recompile dependen=
ts=20
>> only when that public layer is changed. And please note that that public=
=20
>> layer will also include at least size of private part. Something like=20
>> `private: char _1234__[PRIVATE_PART_SIZE];`
>>
>> On Friday, February 26, 2016 at 10:05:49 AM UTC+2, daniele...@gmail.com=
=20
>> wrote:
>>>
>>> Summary of comments up to now:=20
>>> This "partial class" proposal remove compile dependencies with no=20
>>> additional memory cost; no current C++ possible solution achieves both.
>>> The "module" construct has some benefits but does *not* remove the=20
>>> compile dependencies addressed by this "partial class" proposal: theref=
ore=20
>>> both proposals could coexist together with their orthogonal benefits.
>>>
>>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fd756d79-aa99-4727-9217-75bf757160d5%40isocpp.or=
g.

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

<div dir=3D"ltr">I still don&#39;t see why you want to enforce such respons=
ibility onto programmers. Let&#39;s have another header type?<br>IMO compil=
er can perfectly deduce even such cases. It&#39;s compiler responsibility t=
o track dependencies and not mine.<br><br>On Friday, February 26, 2016 at 1=
2:03:23 PM UTC+2, daniele...@gmail.com wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr">If &quot;<i>that public layer will also inc=
lude at least size of=20
private part</i>&quot;, still the module construct<b> does not remove compi=
le dependencies.<br></b>Users of a class C having a reference or pointer to=
 class C<b> do not need to be recompiled</b> if the size of class C changes=
 because private members where added or modified.<br><br><br>Il giorno vene=
rd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha scritto:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">To me, module proposal can =
actually handle this. A compiler smart enough can extract &quot;public laye=
r&quot; from module definition and recompile dependents only when that publ=
ic layer is changed. And please note that that public layer will also inclu=
de at least size of private part. Something like `private: char _1234__[PRI=
VATE_PART_SIZE];`<br><br>On Friday, February 26, 2016 at 10:05:49 AM UTC+2,=
 <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Summary of comments up to now: <br>This &quot;partial cla=
ss&quot; proposal remove compile dependencies with no additional memory cos=
t; no current C++ possible solution achieves both.<br>The &quot;module&quot=
; construct has some benefits but does *not* remove the compile dependencie=
s addressed by this &quot;partial class&quot; proposal: therefore both prop=
osals could coexist together with their orthogonal benefits.<br></div></blo=
ckquote></div></blockquote></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fd756d79-aa99-4727-9217-75bf757160d5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fd756d79-aa99-4727-9217-75bf757160d5=
%40isocpp.org</a>.<br />

------=_Part_147_250460176.1456484798708--
------=_Part_146_1286353816.1456484798708--

.

------=_Part_327_1715824285.1456488227435
Content-Type: multipart/alternative;
 boundary="----=_Part_328_1503770437.1456488227436"

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

Programmers have up to now already this responsibility, when they choose to=
=20
use polymorphism or handle/body pattern to separate better the interface=20
from the implementation removing compile dependencies.
Both solutions are good C++ programming style and have an additional=20
headers (no problem with that), unfortunately they require additional=20
memory, which does not fit embedded systems, which is the ultimate target=
=20
addressed by my proposal.

Il giorno venerd=C3=AC 26 febbraio 2016 12:06:39 UTC+1, Igor Baidiuk ha scr=
itto:
>
> I still don't see why you want to enforce such responsibility onto=20
> programmers. Let's have another header type?
> IMO compiler can perfectly deduce even such cases. It's compiler=20
> responsibility to track dependencies and not mine.
>
> On Friday, February 26, 2016 at 12:03:23 PM UTC+2, daniele...@gmail.com=
=20
> wrote:
>>
>> If "*that public layer will also include at least size of private part*"=
,=20
>> still the module construct
>> * does not remove compile dependencies.*Users of a class C having a=20
>> reference or pointer to class C* do not need to be recompiled* if the=20
>> size of class C changes because private members where added or modified.
>>
>>
>> Il giorno venerd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha=
=20
>> scritto:
>>>
>>> To me, module proposal can actually handle this. A compiler smart enoug=
h=20
>>> can extract "public layer" from module definition and recompile depende=
nts=20
>>> only when that public layer is changed. And please note that that publi=
c=20
>>> layer will also include at least size of private part. Something like=
=20
>>> `private: char _1234__[PRIVATE_PART_SIZE];`
>>>
>>> On Friday, February 26, 2016 at 10:05:49 AM UTC+2, daniele...@gmail.com=
=20
>>> wrote:
>>>>
>>>> Summary of comments up to now:=20
>>>> This "partial class" proposal remove compile dependencies with no=20
>>>> additional memory cost; no current C++ possible solution achieves both=
..
>>>> The "module" construct has some benefits but does *not* remove the=20
>>>> compile dependencies addressed by this "partial class" proposal: there=
fore=20
>>>> both proposals could coexist together with their orthogonal benefits.
>>>>
>>>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/615fbe84-2733-4d78-879f-01ea15f3e267%40isocpp.or=
g.

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

<div dir=3D"ltr">Programmers have up to now already this responsibility, wh=
en they choose to use polymorphism or handle/body pattern to separate bette=
r the interface from the implementation removing compile dependencies.<br>B=
oth solutions are good C++ programming style and have an additional headers=
 (no problem with that), unfortunately they require additional memory, whic=
h does not fit embedded systems, which is the ultimate target addressed by =
my proposal.<br><br>Il giorno venerd=C3=AC 26 febbraio 2016 12:06:39 UTC+1,=
 Igor Baidiuk ha scritto:<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">I still don&#39;t see why you want to enforce such responsibili=
ty onto programmers. Let&#39;s have another header type?<br>IMO compiler ca=
n perfectly deduce even such cases. It&#39;s compiler responsibility to tra=
ck dependencies and not mine.<br><br>On Friday, February 26, 2016 at 12:03:=
23 PM UTC+2, <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">If &quot;<i>that public layer will also includ=
e at least size of=20
private part</i>&quot;, still the module construct<b> does not remove compi=
le dependencies.<br></b>Users of a class C having a reference or pointer to=
 class C<b> do not need to be recompiled</b> if the size of class C changes=
 because private members where added or modified.<br><br><br>Il giorno vene=
rd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha scritto:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">To me, module proposal can =
actually handle this. A compiler smart enough can extract &quot;public laye=
r&quot; from module definition and recompile dependents only when that publ=
ic layer is changed. And please note that that public layer will also inclu=
de at least size of private part. Something like `private: char _1234__[PRI=
VATE_PART_SIZE];`<br><br>On Friday, February 26, 2016 at 10:05:49 AM UTC+2,=
 <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Summary of comments up to now: <br>This &quot;partial cla=
ss&quot; proposal remove compile dependencies with no additional memory cos=
t; no current C++ possible solution achieves both.<br>The &quot;module&quot=
; construct has some benefits but does *not* remove the compile dependencie=
s addressed by this &quot;partial class&quot; proposal: therefore both prop=
osals could coexist together with their orthogonal benefits.<br></div></blo=
ckquote></div></blockquote></div></blockquote></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/615fbe84-2733-4d78-879f-01ea15f3e267%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/615fbe84-2733-4d78-879f-01ea15f3e267=
%40isocpp.org</a>.<br />

------=_Part_328_1503770437.1456488227436--
------=_Part_327_1715824285.1456488227435--

.

------=_Part_144_1684537965.1456488971917
Content-Type: multipart/alternative;
 boundary="----=_Part_145_2106729418.1456488971918"

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

I still don't get why this can't be handled by compiler with modules=20
support.
Next, you claim that this is a boon to embedded systems. This basically=20
drops to either in-native compilation (which is AFAIK almost nonexistent=20
for embeds), where you usually can't expect modern compiler (so no luck=20
with your proposal anyway) or cross-compilation. For the latter, you=20
compile with modern compiler on a modern PC. I wonder what the amount of=20
code should be so that you'll see difference from your proposal. Given you=
=20
have modules at your side, so rebuild happens on public layer change only.

So my conclusion is. You basically want feature which is mostly covered by=
=20
modules proposal, requires additional bookkeeping/typing and gives some=20
diminishing outcomes in corner cases.

On Friday, February 26, 2016 at 2:03:47 PM UTC+2, daniele...@gmail.com=20
wrote:
>
> Programmers have up to now already this responsibility, when they choose=
=20
> to use polymorphism or handle/body pattern to separate better the interfa=
ce=20
> from the implementation removing compile dependencies.
> Both solutions are good C++ programming style and have an additional=20
> headers (no problem with that), unfortunately they require additional=20
> memory, which does not fit embedded systems, which is the ultimate target=
=20
> addressed by my proposal.
>
> Il giorno venerd=C3=AC 26 febbraio 2016 12:06:39 UTC+1, Igor Baidiuk ha s=
critto:
>>
>> I still don't see why you want to enforce such responsibility onto=20
>> programmers. Let's have another header type?
>> IMO compiler can perfectly deduce even such cases. It's compiler=20
>> responsibility to track dependencies and not mine.
>>
>> On Friday, February 26, 2016 at 12:03:23 PM UTC+2, daniele...@gmail.com=
=20
>> wrote:
>>>
>>> If "*that public layer will also include at least size of private part*=
",=20
>>> still the module construct
>>> * does not remove compile dependencies.*Users of a class C having a=20
>>> reference or pointer to class C* do not need to be recompiled* if the=
=20
>>> size of class C changes because private members where added or modified=
..
>>>
>>>
>>> Il giorno venerd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha=
=20
>>> scritto:
>>>>
>>>> To me, module proposal can actually handle this. A compiler smart=20
>>>> enough can extract "public layer" from module definition and recompile=
=20
>>>> dependents only when that public layer is changed. And please note tha=
t=20
>>>> that public layer will also include at least size of private part.=20
>>>> Something like `private: char _1234__[PRIVATE_PART_SIZE];`
>>>>
>>>> On Friday, February 26, 2016 at 10:05:49 AM UTC+2, daniele...@gmail.co=
m=20
>>>> wrote:
>>>>>
>>>>> Summary of comments up to now:=20
>>>>> This "partial class" proposal remove compile dependencies with no=20
>>>>> additional memory cost; no current C++ possible solution achieves bot=
h.
>>>>> The "module" construct has some benefits but does *not* remove the=20
>>>>> compile dependencies addressed by this "partial class" proposal: ther=
efore=20
>>>>> both proposals could coexist together with their orthogonal benefits.
>>>>>
>>>>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b2e39c36-e9e1-4ff0-836a-724780c1953c%40isocpp.or=
g.

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

<div dir=3D"ltr">I still don&#39;t get why this can&#39;t be handled by com=
piler with modules support.<br>Next, you claim that this is a boon to embed=
ded systems. This basically drops to either in-native compilation (which is=
 AFAIK almost nonexistent for embeds), where you usually can&#39;t expect m=
odern compiler (so no luck with your proposal anyway) or cross-compilation.=
 For the latter, you compile with modern compiler on a modern PC. I wonder =
what the amount of code should be so that you&#39;ll see difference from yo=
ur proposal. Given you have modules at your side, so rebuild happens on pub=
lic layer change only.<br><br>So my conclusion is. You basically want featu=
re which is mostly covered by modules proposal, requires additional bookkee=
ping/typing and gives some diminishing outcomes in corner cases.<br><br>On =
Friday, February 26, 2016 at 2:03:47 PM UTC+2, daniele...@gmail.com wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Programmers ha=
ve up to now already this responsibility, when they choose to use polymorph=
ism or handle/body pattern to separate better the interface from the implem=
entation removing compile dependencies.<br>Both solutions are good C++ prog=
ramming style and have an additional headers (no problem with that), unfort=
unately they require additional memory, which does not fit embedded systems=
, which is the ultimate target addressed by my proposal.<br><br>Il giorno v=
enerd=C3=AC 26 febbraio 2016 12:06:39 UTC+1, Igor Baidiuk ha scritto:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I still don&#39;t see wh=
y you want to enforce such responsibility onto programmers. Let&#39;s have =
another header type?<br>IMO compiler can perfectly deduce even such cases. =
It&#39;s compiler responsibility to track dependencies and not mine.<br><br=
>On Friday, February 26, 2016 at 12:03:23 PM UTC+2, <a>daniele...@gmail.com=
</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">If &quo=
t;<i>that public layer will also include at least size of=20
private part</i>&quot;, still the module construct<b> does not remove compi=
le dependencies.<br></b>Users of a class C having a reference or pointer to=
 class C<b> do not need to be recompiled</b> if the size of class C changes=
 because private members where added or modified.<br><br><br>Il giorno vene=
rd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha scritto:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">To me, module proposal can =
actually handle this. A compiler smart enough can extract &quot;public laye=
r&quot; from module definition and recompile dependents only when that publ=
ic layer is changed. And please note that that public layer will also inclu=
de at least size of private part. Something like `private: char _1234__[PRI=
VATE_PART_SIZE];`<br><br>On Friday, February 26, 2016 at 10:05:49 AM UTC+2,=
 <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Summary of comments up to now: <br>This &quot;partial cla=
ss&quot; proposal remove compile dependencies with no additional memory cos=
t; no current C++ possible solution achieves both.<br>The &quot;module&quot=
; construct has some benefits but does *not* remove the compile dependencie=
s addressed by this &quot;partial class&quot; proposal: therefore both prop=
osals could coexist together with their orthogonal benefits.<br></div></blo=
ckquote></div></blockquote></div></blockquote></div></blockquote></div></bl=
ockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b2e39c36-e9e1-4ff0-836a-724780c1953c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2e39c36-e9e1-4ff0-836a-724780c1953c=
%40isocpp.org</a>.<br />

------=_Part_145_2106729418.1456488971918--
------=_Part_144_1684537965.1456488971917--

.

------=_Part_468_1640483564.1456489226019
Content-Type: multipart/alternative;
 boundary="----=_Part_469_144267091.1456489226019"

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

I still do not get how the benefits of my proposals can be handed by the=20
modules, if every statement I read in this thread about this module=20
constructs reveals exactly the contrary.

Il giorno venerd=C3=AC 26 febbraio 2016 13:16:12 UTC+1, Igor Baidiuk ha scr=
itto:
>
> I still don't get why this can't be handled by compiler with modules=20
> support.
> Next, you claim that this is a boon to embedded systems. This basically=
=20
> drops to either in-native compilation (which is AFAIK almost nonexistent=
=20
> for embeds), where you usually can't expect modern compiler (so no luck=
=20
> with your proposal anyway) or cross-compilation. For the latter, you=20
> compile with modern compiler on a modern PC. I wonder what the amount of=
=20
> code should be so that you'll see difference from your proposal. Given yo=
u=20
> have modules at your side, so rebuild happens on public layer change only=
..
>
> So my conclusion is. You basically want feature which is mostly covered b=
y=20
> modules proposal, requires additional bookkeeping/typing and gives some=
=20
> diminishing outcomes in corner cases.
>
> On Friday, February 26, 2016 at 2:03:47 PM UTC+2, daniele...@gmail.com=20
> wrote:
>>
>> Programmers have up to now already this responsibility, when they choose=
=20
>> to use polymorphism or handle/body pattern to separate better the interf=
ace=20
>> from the implementation removing compile dependencies.
>> Both solutions are good C++ programming style and have an additional=20
>> headers (no problem with that), unfortunately they require additional=20
>> memory, which does not fit embedded systems, which is the ultimate targe=
t=20
>> addressed by my proposal.
>>
>> Il giorno venerd=C3=AC 26 febbraio 2016 12:06:39 UTC+1, Igor Baidiuk ha=
=20
>> scritto:
>>>
>>> I still don't see why you want to enforce such responsibility onto=20
>>> programmers. Let's have another header type?
>>> IMO compiler can perfectly deduce even such cases. It's compiler=20
>>> responsibility to track dependencies and not mine.
>>>
>>> On Friday, February 26, 2016 at 12:03:23 PM UTC+2, daniele...@gmail.com=
=20
>>> wrote:
>>>>
>>>> If "*that public layer will also include at least size of private part=
*",=20
>>>> still the module construct
>>>> * does not remove compile dependencies.*Users of a class C having a=20
>>>> reference or pointer to class C* do not need to be recompiled* if the=
=20
>>>> size of class C changes because private members where added or modifie=
d.
>>>>
>>>>
>>>> Il giorno venerd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk h=
a=20
>>>> scritto:
>>>>>
>>>>> To me, module proposal can actually handle this. A compiler smart=20
>>>>> enough can extract "public layer" from module definition and recompil=
e=20
>>>>> dependents only when that public layer is changed. And please note th=
at=20
>>>>> that public layer will also include at least size of private part.=20
>>>>> Something like `private: char _1234__[PRIVATE_PART_SIZE];`
>>>>>
>>>>> On Friday, February 26, 2016 at 10:05:49 AM UTC+2,=20
>>>>> daniele...@gmail.com wrote:
>>>>>>
>>>>>> Summary of comments up to now:=20
>>>>>> This "partial class" proposal remove compile dependencies with no=20
>>>>>> additional memory cost; no current C++ possible solution achieves bo=
th.
>>>>>> The "module" construct has some benefits but does *not* remove the=
=20
>>>>>> compile dependencies addressed by this "partial class" proposal: the=
refore=20
>>>>>> both proposals could coexist together with their orthogonal benefits=
..
>>>>>>
>>>>>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5f31f800-1221-47a8-be6c-e1128e686450%40isocpp.or=
g.

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

<div dir=3D"ltr">I still do not get how the benefits of my proposals can be=
 handed by the modules, if every statement I read in this thread about this=
 module constructs reveals exactly the contrary.<br><br>Il giorno venerd=C3=
=AC 26 febbraio 2016 13:16:12 UTC+1, Igor Baidiuk ha scritto:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I still don&#39;t get why t=
his can&#39;t be handled by compiler with modules support.<br>Next, you cla=
im that this is a boon to embedded systems. This basically drops to either =
in-native compilation (which is AFAIK almost nonexistent for embeds), where=
 you usually can&#39;t expect modern compiler (so no luck with your proposa=
l anyway) or cross-compilation. For the latter, you compile with modern com=
piler on a modern PC. I wonder what the amount of code should be so that yo=
u&#39;ll see difference from your proposal. Given you have modules at your =
side, so rebuild happens on public layer change only.<br><br>So my conclusi=
on is. You basically want feature which is mostly covered by modules propos=
al, requires additional bookkeeping/typing and gives some diminishing outco=
mes in corner cases.<br><br>On Friday, February 26, 2016 at 2:03:47 PM UTC+=
2, <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">Programmers have up to now already this responsibility, =
when they choose to use polymorphism or handle/body pattern to separate bet=
ter the interface from the implementation removing compile dependencies.<br=
>Both solutions are good C++ programming style and have an additional heade=
rs (no problem with that), unfortunately they require additional memory, wh=
ich does not fit embedded systems, which is the ultimate target addressed b=
y my proposal.<br><br>Il giorno venerd=C3=AC 26 febbraio 2016 12:06:39 UTC+=
1, Igor Baidiuk ha scritto:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">I still don&#39;t see why you want to enforce such responsibility =
onto programmers. Let&#39;s have another header type?<br>IMO compiler can p=
erfectly deduce even such cases. It&#39;s compiler responsibility to track =
dependencies and not mine.<br><br>On Friday, February 26, 2016 at 12:03:23 =
PM UTC+2, <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">If &quot;<i>that public layer will also include a=
t least size of=20
private part</i>&quot;, still the module construct<b> does not remove compi=
le dependencies.<br></b>Users of a class C having a reference or pointer to=
 class C<b> do not need to be recompiled</b> if the size of class C changes=
 because private members where added or modified.<br><br><br>Il giorno vene=
rd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha scritto:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">To me, module proposal can =
actually handle this. A compiler smart enough can extract &quot;public laye=
r&quot; from module definition and recompile dependents only when that publ=
ic layer is changed. And please note that that public layer will also inclu=
de at least size of private part. Something like `private: char _1234__[PRI=
VATE_PART_SIZE];`<br><br>On Friday, February 26, 2016 at 10:05:49 AM UTC+2,=
 <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Summary of comments up to now: <br>This &quot;partial cla=
ss&quot; proposal remove compile dependencies with no additional memory cos=
t; no current C++ possible solution achieves both.<br>The &quot;module&quot=
; construct has some benefits but does *not* remove the compile dependencie=
s addressed by this &quot;partial class&quot; proposal: therefore both prop=
osals could coexist together with their orthogonal benefits.<br></div></blo=
ckquote></div></blockquote></div></blockquote></div></blockquote></div></bl=
ockquote></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5f31f800-1221-47a8-be6c-e1128e686450%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5f31f800-1221-47a8-be6c-e1128e686450=
%40isocpp.org</a>.<br />

------=_Part_469_144267091.1456489226019--
------=_Part_468_1640483564.1456489226019--

.

------=_Part_267_1970167662.1456490045661
Content-Type: multipart/alternative;
 boundary="----=_Part_268_434432449.1456490045662"

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

Very simple. First, compiler is able to generate some kind of header from=
=20
module, which contains only public layer (including struct sizes, but not=
=20
exact layout of private parts). Having this, no one prohibits compiler from=
=20
shrinking this info to "pointer-only" public layer, if needed. As a result,=
=20
no need for yet another language construct.

I, on my side, can't see benefits from your proposal. Compared to modules,=
=20
you propose compile time improvement at the expense of language complexity=
=20
and additional typing and bookkeeping. Where, this compile time improvement=
=20
would happen only full static interface vs pointer-only interface. So,=20
would _this_ _additional_ improvement be _that_ big to counter language=20
complexity it introduces? Please note that pointer-dependent interface will=
=20
have high chances to change anyway whenever any modification happens inside=
=20
module - because of inlining, functions layout, etc.

On Friday, February 26, 2016 at 2:20:26 PM UTC+2, daniele...@gmail.com=20
wrote:
>
> I still do not get how the benefits of my proposals can be handed by the=
=20
> modules, if every statement I read in this thread about this module=20
> constructs reveals exactly the contrary.
>
> Il giorno venerd=C3=AC 26 febbraio 2016 13:16:12 UTC+1, Igor Baidiuk ha s=
critto:
>>
>> I still don't get why this can't be handled by compiler with modules=20
>> support.
>> Next, you claim that this is a boon to embedded systems. This basically=
=20
>> drops to either in-native compilation (which is AFAIK almost nonexistent=
=20
>> for embeds), where you usually can't expect modern compiler (so no luck=
=20
>> with your proposal anyway) or cross-compilation. For the latter, you=20
>> compile with modern compiler on a modern PC. I wonder what the amount of=
=20
>> code should be so that you'll see difference from your proposal. Given y=
ou=20
>> have modules at your side, so rebuild happens on public layer change onl=
y.
>>
>> So my conclusion is. You basically want feature which is mostly covered=
=20
>> by modules proposal, requires additional bookkeeping/typing and gives so=
me=20
>> diminishing outcomes in corner cases.
>>
>> On Friday, February 26, 2016 at 2:03:47 PM UTC+2, daniele...@gmail.com=
=20
>> wrote:
>>>
>>> Programmers have up to now already this responsibility, when they choos=
e=20
>>> to use polymorphism or handle/body pattern to separate better the inter=
face=20
>>> from the implementation removing compile dependencies.
>>> Both solutions are good C++ programming style and have an additional=20
>>> headers (no problem with that), unfortunately they require additional=
=20
>>> memory, which does not fit embedded systems, which is the ultimate targ=
et=20
>>> addressed by my proposal.
>>>
>>> Il giorno venerd=C3=AC 26 febbraio 2016 12:06:39 UTC+1, Igor Baidiuk ha=
=20
>>> scritto:
>>>>
>>>> I still don't see why you want to enforce such responsibility onto=20
>>>> programmers. Let's have another header type?
>>>> IMO compiler can perfectly deduce even such cases. It's compiler=20
>>>> responsibility to track dependencies and not mine.
>>>>
>>>> On Friday, February 26, 2016 at 12:03:23 PM UTC+2, daniele...@gmail.co=
m=20
>>>> wrote:
>>>>>
>>>>> If "*that public layer will also include at least size of private=20
>>>>> part*", still the module construct
>>>>> * does not remove compile dependencies.*Users of a class C having a=
=20
>>>>> reference or pointer to class C* do not need to be recompiled* if the=
=20
>>>>> size of class C changes because private members where added or modifi=
ed.
>>>>>
>>>>>
>>>>> Il giorno venerd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk =
ha=20
>>>>> scritto:
>>>>>>
>>>>>> To me, module proposal can actually handle this. A compiler smart=20
>>>>>> enough can extract "public layer" from module definition and recompi=
le=20
>>>>>> dependents only when that public layer is changed. And please note t=
hat=20
>>>>>> that public layer will also include at least size of private part.=
=20
>>>>>> Something like `private: char _1234__[PRIVATE_PART_SIZE];`
>>>>>>
>>>>>> On Friday, February 26, 2016 at 10:05:49 AM UTC+2,=20
>>>>>> daniele...@gmail.com wrote:
>>>>>>>
>>>>>>> Summary of comments up to now:=20
>>>>>>> This "partial class" proposal remove compile dependencies with no=
=20
>>>>>>> additional memory cost; no current C++ possible solution achieves b=
oth.
>>>>>>> The "module" construct has some benefits but does *not* remove the=
=20
>>>>>>> compile dependencies addressed by this "partial class" proposal: th=
erefore=20
>>>>>>> both proposals could coexist together with their orthogonal benefit=
s.
>>>>>>>
>>>>>>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2917bf07-c677-4b47-ad4f-a99b7a3f528b%40isocpp.or=
g.

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

<div dir=3D"ltr">Very simple. First, compiler is able to generate some kind=
 of header from module, which contains only public layer (including struct =
sizes, but not exact layout of private parts). Having this, no one prohibit=
s compiler from shrinking this info to &quot;pointer-only&quot; public laye=
r, if needed. As a result, no need for yet another language construct.<br><=
br>I, on my side, can&#39;t see benefits from your proposal. Compared to mo=
dules, you propose compile time improvement at the expense of language comp=
lexity and additional typing and bookkeeping. Where, this compile time impr=
ovement would happen only full static interface vs pointer-only interface. =
So, would _this_ _additional_ improvement be _that_ big to counter language=
 complexity it introduces? Please note that pointer-dependent interface wil=
l have high chances to change anyway whenever any modification happens insi=
de module - because of inlining, functions layout, etc.<br><br>On Friday, F=
ebruary 26, 2016 at 2:20:26 PM UTC+2, daniele...@gmail.com wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I still do not get how =
the benefits of my proposals can be handed by the modules, if every stateme=
nt I read in this thread about this module constructs reveals exactly the c=
ontrary.<br><br>Il giorno venerd=C3=AC 26 febbraio 2016 13:16:12 UTC+1, Igo=
r Baidiuk ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">I still don&#39;t get why this can&#39;t be handled by compiler with mod=
ules support.<br>Next, you claim that this is a boon to embedded systems. T=
his basically drops to either in-native compilation (which is AFAIK almost =
nonexistent for embeds), where you usually can&#39;t expect modern compiler=
 (so no luck with your proposal anyway) or cross-compilation. For the latte=
r, you compile with modern compiler on a modern PC. I wonder what the amoun=
t of code should be so that you&#39;ll see difference from your proposal. G=
iven you have modules at your side, so rebuild happens on public layer chan=
ge only.<br><br>So my conclusion is. You basically want feature which is mo=
stly covered by modules proposal, requires additional bookkeeping/typing an=
d gives some diminishing outcomes in corner cases.<br><br>On Friday, Februa=
ry 26, 2016 at 2:03:47 PM UTC+2, <a>daniele...@gmail.com</a> wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Programmers have up to now=
 already this responsibility, when they choose to use polymorphism or handl=
e/body pattern to separate better the interface from the implementation rem=
oving compile dependencies.<br>Both solutions are good C++ programming styl=
e and have an additional headers (no problem with that), unfortunately they=
 require additional memory, which does not fit embedded systems, which is t=
he ultimate target addressed by my proposal.<br><br>Il giorno venerd=C3=AC =
26 febbraio 2016 12:06:39 UTC+1, Igor Baidiuk ha scritto:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">I still don&#39;t see why you want =
to enforce such responsibility onto programmers. Let&#39;s have another hea=
der type?<br>IMO compiler can perfectly deduce even such cases. It&#39;s co=
mpiler responsibility to track dependencies and not mine.<br><br>On Friday,=
 February 26, 2016 at 12:03:23 PM UTC+2, <a>daniele...@gmail.com</a> wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">If &quot;<i>that p=
ublic layer will also include at least size of=20
private part</i>&quot;, still the module construct<b> does not remove compi=
le dependencies.<br></b>Users of a class C having a reference or pointer to=
 class C<b> do not need to be recompiled</b> if the size of class C changes=
 because private members where added or modified.<br><br><br>Il giorno vene=
rd=C3=AC 26 febbraio 2016 10:24:55 UTC+1, Igor Baidiuk ha scritto:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">To me, module proposal can =
actually handle this. A compiler smart enough can extract &quot;public laye=
r&quot; from module definition and recompile dependents only when that publ=
ic layer is changed. And please note that that public layer will also inclu=
de at least size of private part. Something like `private: char _1234__[PRI=
VATE_PART_SIZE];`<br><br>On Friday, February 26, 2016 at 10:05:49 AM UTC+2,=
 <a>daniele...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Summary of comments up to now: <br>This &quot;partial cla=
ss&quot; proposal remove compile dependencies with no additional memory cos=
t; no current C++ possible solution achieves both.<br>The &quot;module&quot=
; construct has some benefits but does *not* remove the compile dependencie=
s addressed by this &quot;partial class&quot; proposal: therefore both prop=
osals could coexist together with their orthogonal benefits.<br></div></blo=
ckquote></div></blockquote></div></blockquote></div></blockquote></div></bl=
ockquote></div></blockquote></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2917bf07-c677-4b47-ad4f-a99b7a3f528b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2917bf07-c677-4b47-ad4f-a99b7a3f528b=
%40isocpp.org</a>.<br />

------=_Part_268_434432449.1456490045662--
------=_Part_267_1970167662.1456490045661--

.

------=_Part_342_1994198222.1456490896815
Content-Type: multipart/alternative;
 boundary="----=_Part_343_1949335021.1456490896820"

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

You are comparing the two proposals as a challenge, but I have nothing=20
against the module construct, it sounds powerful.
I am only saying that is does not remove all useless compile dependencies:=
=20
if you argue the the size belongs to the public layer, all the users that=
=20
do not need the size will still suffer from this useless compile dependency=
..
Actually the users of a class can be split in two groups: those that do not=
=20
create instances of the class and those who do. Only the second need the=20
size, but not the first, which therefore do not need to be recompiled when=
=20
the private part of the used class (and as consequence, the size) is=20
modified.

Il giorno venerd=C3=AC 26 febbraio 2016 13:34:06 UTC+1, Igor Baidiuk ha scr=
itto:
>
> Very simple. First, compiler is able to generate some kind of header from=
=20
> module, which contains only public layer (including struct sizes, but not=
=20
> exact layout of private parts). Having this, no one prohibits compiler fr=
om=20
> shrinking this info to "pointer-only" public layer, if needed. As a resul=
t,=20
> no need for yet another language construct.
>
> I, on my side, can't see benefits from your proposal. Compared to modules=
,=20
> you propose compile time improvement at the expense of language complexit=
y=20
> and additional typing and bookkeeping. Where, this compile time improveme=
nt=20
> would happen only full static interface vs pointer-only interface. So,=20
> would _this_ _additional_ improvement be _that_ big to counter language=
=20
> complexity it introduces? Please note that pointer-dependent interface wi=
ll=20
> have high chances to change anyway whenever any modification happens insi=
de=20
> module - because of inlining, functions layout, etc.
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e5930acf-29f3-4a46-b135-e5f5a99eb89e%40isocpp.or=
g.

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

<div dir=3D"ltr">You are comparing the two proposals as a challenge, but I =
have nothing against the module construct, it sounds powerful.<br>I am only=
 saying that is does not remove all useless compile dependencies: if you ar=
gue the the size belongs to the public layer, all the users that do not nee=
d the size will still suffer from this useless compile dependency.<br>Actua=
lly the users of a class can be split in two groups: those that do not crea=
te instances of the class and those who do. Only the second need the size, =
but not the first, which therefore do not need to be recompiled when the pr=
ivate part of the used class (and as consequence, the size) is modified.<br=
><br>Il giorno venerd=C3=AC 26 febbraio 2016 13:34:06 UTC+1, Igor Baidiuk h=
a scritto:<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">Ver=
y simple. First, compiler is able to generate some kind of header from modu=
le, which contains only public layer (including struct sizes, but not exact=
 layout of private parts). Having this, no one prohibits compiler from shri=
nking this info to &quot;pointer-only&quot; public layer, if needed. As a r=
esult, no need for yet another language construct.<br><br>I, on my side, ca=
n&#39;t see benefits from your proposal. Compared to modules, you propose c=
ompile time improvement at the expense of language complexity and additiona=
l typing and bookkeeping. Where, this compile time improvement would happen=
 only full static interface vs pointer-only interface. So, would _this_ _ad=
ditional_ improvement be _that_ big to counter language complexity it intro=
duces? Please note that pointer-dependent interface will have high chances =
to change anyway whenever any modification happens inside module - because =
of inlining, functions layout, etc.<br><br></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e5930acf-29f3-4a46-b135-e5f5a99eb89e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e5930acf-29f3-4a46-b135-e5f5a99eb89e=
%40isocpp.org</a>.<br />

------=_Part_343_1949335021.1456490896820--
------=_Part_342_1994198222.1456490896815--

.

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

On Tue, Feb 23, 2016 at 2:55 PM, <daniele.bordes@gmail.com> wrote:

> The private part of a class must be declared in the same header file where
> the public part is also declared and therefore included by all the users of
> that class.
> This means that whenever the private part of a class (a part of its
> implementation) is changed, as a consequence all the users of that class
> need to be recompiled.
> Currently only two solutions exist to avoid this problem:
>
> 1) inheritance
> 2) patterns like handle/body (also know as Pimpl Idiom)
>
> Both solutions requires additional memory costs, because each object would
> have an additional pointer. These additional memory costs could represent a
> severe penalty in Embedded Software.
>
> A new "*partial class*" construct can avoid both the recompilation
> problem and these additional memory costs: for a complete description of
> this new proposal, see attachments.
>

What does your proposal have that the following cannot achieve?

In a header file, define a public interface:

struct iface
{
    void foo();
protected:
    iface() {}
    ~iface() {}
}

In another header, define the real class:

struct impl: iface
{
    friend struct iface;
private:
    void bar();
}

Somewhere else define the public methods:

void iface::foo()
{
    static_cast<impl*>(this)->bar();
}

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3MdwT2yEMuDmrkQPyOuUaPC6LeY%2B8zvvWJfYvkAejxbA%40mail.gmail.com.

--001a11c24f06c9db2f052cac7060
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 T=
ue, Feb 23, 2016 at 2:55 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:danie=
le.bordes@gmail.com" target=3D"_blank">daniele.bordes@gmail.com</a>&gt;</sp=
an> 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 dir=3D"ltr"><div>The private part of a =
class must be declared in the same header file where the public part is als=
o declared and therefore included by all the users of that class.<br>This m=
eans that whenever the private part of a class (a part of its implementatio=
n) is changed, as a consequence all the users of that class need to be reco=
mpiled.<br>Currently only two solutions exist to avoid this problem:</div><=
div><br></div><div>1) inheritance<br>2) patterns like handle/body (also kno=
w as Pimpl Idiom)</div><div><br></div><div>Both solutions requires addition=
al memory costs, because each object would have an additional pointer. Thes=
e additional memory costs could represent a severe penalty in Embedded Soft=
ware.</div><div><br></div><p>A new &quot;<strong>partial class</strong>&quo=
t; construct can avoid both the recompilation problem and these additional =
memory costs: for a complete description of this new proposal, see attachme=
nts.</p></div></blockquote><div><br></div><div>What does your proposal have=
 that the following cannot achieve?</div><div><br></div><div>In a header fi=
le, define a public interface:</div><div><br></div><div>struct iface</div><=
div>{</div><div>=C2=A0 =C2=A0 void foo();</div><div>protected:</div><div>=
=C2=A0 =C2=A0 iface() {}</div><div>=C2=A0 =C2=A0 ~iface() {}<br></div><div>=
}</div><div><br></div><div>In another header, define the real class:</div><=
div><br></div><div>struct impl: iface</div><div>{</div><div>=C2=A0 =C2=A0 f=
riend struct iface;</div><div>private:</div><div>=C2=A0 =C2=A0 void bar();<=
/div><div>}<br></div><div><br></div><div>Somewhere else define the public m=
ethods:</div><div><br></div><div>void iface::foo()</div><div>{</div><div>=
=C2=A0 =C2=A0 static_cast&lt;impl*&gt;(this)-&gt;bar();</div><div>}</div><d=
iv><br></div><div>Cheers,</div><div>V.</div><div><br></div></div></div></di=
v>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3MdwT2yEMuDmrkQPyOuUaPC6LeY%2B=
8zvvWJfYvkAejxbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3MdwT2yE=
MuDmrkQPyOuUaPC6LeY%2B8zvvWJfYvkAejxbA%40mail.gmail.com</a>.<br />

--001a11c24f06c9db2f052cac7060--

.

------=_Part_435_1878222728.1456498089796
Content-Type: multipart/alternative;
 boundary="----=_Part_436_859974020.1456498089796"

------=_Part_436_859974020.1456498089796
Content-Type: text/plain; charset=UTF-8

On Friday, February 26, 2016 at 4:24:55 AM UTC-5, Igor Baidiuk wrote:
>
> To me, module proposal can actually handle this. A compiler smart enough
> can extract "public layer" from module definition and recompile dependents
> only when that public layer is changed. And please note that that public
> layer will also include at least size of private part. Something like
> `private: char _1234__[PRIVATE_PART_SIZE];`
>

Sure... right up until you start giving reflection the ability to access
privates. Which pretty much every reflection proposal that allows you to
access constructs on a type does.

Then your module files need to actually store all private data.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fce6da66-2510-4a09-bc71-0046fc48a64a%40isocpp.org.

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

<div dir=3D"ltr">On Friday, February 26, 2016 at 4:24:55 AM UTC-5, Igor Bai=
diuk 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">To=
 me, module proposal can actually handle this. A compiler smart enough can =
extract &quot;public layer&quot; from module definition and recompile depen=
dents only when that public layer is changed. And please note that that pub=
lic layer will also include at least size of private part. Something like `=
private: char _1234__[PRIVATE_PART_SIZE];`<br></div></blockquote><div><br>S=
ure... right up until you start giving reflection the ability to access pri=
vates. Which pretty much every reflection proposal that allows you to acces=
s constructs on a type does.<br><br>Then your module files need to actually=
 store all private data.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fce6da66-2510-4a09-bc71-0046fc48a64a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fce6da66-2510-4a09-bc71-0046fc48a64a=
%40isocpp.org</a>.<br />

------=_Part_436_859974020.1456498089796--
------=_Part_435_1878222728.1456498089796--

.

------=_Part_13_1149445701.1456498356378
Content-Type: multipart/alternative;
 boundary="----=_Part_14_734086383.1456498356378"

------=_Part_14_734086383.1456498356378
Content-Type: text/plain; charset=UTF-8

On Friday, February 26, 2016 at 8:40:24 AM UTC-5, Viacheslav Usov wrote:
>
> On Tue, Feb 23, 2016 at 2:55 PM, <daniele...@gmail.com <javascript:>>
> wrote:
>
>> The private part of a class must be declared in the same header file
>> where the public part is also declared and therefore included by all the
>> users of that class.
>> This means that whenever the private part of a class (a part of its
>> implementation) is changed, as a consequence all the users of that class
>> need to be recompiled.
>> Currently only two solutions exist to avoid this problem:
>>
>> 1) inheritance
>> 2) patterns like handle/body (also know as Pimpl Idiom)
>>
>> Both solutions requires additional memory costs, because each object
>> would have an additional pointer. These additional memory costs could
>> represent a severe penalty in Embedded Software.
>>
>> A new "*partial class*" construct can avoid both the recompilation
>> problem and these additional memory costs: for a complete description of
>> this new proposal, see attachments.
>>
>
> What does your proposal have that the following cannot achieve?
>

You mean besides basic usability, like not having to manually static_cast
to your actual type every time you do something like access a private
member?

Yes, we do that in the CRTP too, but at least then we're doing that for
customizability, not some compilation thing.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9bea41f6-47e0-43c4-8f68-5a70fb20208f%40isocpp.org.

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

<div dir=3D"ltr">On Friday, February 26, 2016 at 8:40:24 AM UTC-5, Viachesl=
av Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On Tue, Feb 23, 2016 at 2:55 PM,  <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"GTlL_sTmAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">daniele...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>The private part of a class must be declared in the same=
 header file where the public part is also declared and therefore included =
by all the users of that class.<br>This means that whenever the private par=
t of a class (a part of its implementation) is changed, as a consequence al=
l the users of that class need to be recompiled.<br>Currently only two solu=
tions exist to avoid this problem:</div><div><br></div><div>1) inheritance<=
br>2) patterns like handle/body (also know as Pimpl Idiom)</div><div><br></=
div><div>Both solutions requires additional memory costs, because each obje=
ct would have an additional pointer. These additional memory costs could re=
present a severe penalty in Embedded Software.</div><div><br></div><p>A new=
 &quot;<b>partial class</b>&quot; construct can avoid both the recompilatio=
n problem and these additional memory costs: for a complete description of =
this new proposal, see attachments.</p></div></blockquote><div><br></div><d=
iv>What does your proposal have that the following cannot achieve?</div></d=
iv></div></div></blockquote><div><br>You mean besides basic usability, like=
 not having to manually static_cast to your actual type every time you do s=
omething like access a private member?<br><br>Yes, we do that in the CRTP t=
oo, but at least then we&#39;re doing that for customizability, not some co=
mpilation thing.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9bea41f6-47e0-43c4-8f68-5a70fb20208f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9bea41f6-47e0-43c4-8f68-5a70fb20208f=
%40isocpp.org</a>.<br />

------=_Part_14_734086383.1456498356378--
------=_Part_13_1149445701.1456498356378--

.

------=_Part_264_2087037061.1456498488409
Content-Type: multipart/alternative;
 boundary="----=_Part_265_500166917.1456498488410"

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

I'm not comparing them as a challenge. I'm saying that your proposal is a=
=20
mere tiny subset of modules proposal
Modules:
+ Public layer isolation. No pollution of importer's namespace with what he=
=20
doesn't need.
+ Compile time reduction, because of shrinking dependencies down to public=
=20
layers.
+ One file per module
- 'module' and 'import' syntax instead of #include
- all dependents would be still recompiled on public layer change
Partials:
+ Pointer-only dependencies recompiled faster
- two headers instead of one
- two includes instead of one
- compile time is reduced upon amount of parsing private section of class,=
=20
and only where only pointer is used
- need to keep track on where you need only pointers
- yet another keyword

On Friday, February 26, 2016 at 2:48:17 PM UTC+2, daniele...@gmail.com=20
wrote:
>
> You are comparing the two proposals as a challenge, but I have nothing=20
> against the module construct, it sounds powerful.
> I am only saying that is does not remove all useless compile dependencies=
:=20
> if you argue the the size belongs to the public layer, all the users that=
=20
> do not need the size will still suffer from this useless compile dependen=
cy.
> Actually the users of a class can be split in two groups: those that do=
=20
> not create instances of the class and those who do. Only the second need=
=20
> the size, but not the first, which therefore do not need to be recompiled=
=20
> when the private part of the used class (and as consequence, the size) is=
=20
> modified.
>
> Il giorno venerd=C3=AC 26 febbraio 2016 13:34:06 UTC+1, Igor Baidiuk ha s=
critto:
>>
>> Very simple. First, compiler is able to generate some kind of header fro=
m=20
>> module, which contains only public layer (including struct sizes, but no=
t=20
>> exact layout of private parts). Having this, no one prohibits compiler f=
rom=20
>> shrinking this info to "pointer-only" public layer, if needed. As a resu=
lt,=20
>> no need for yet another language construct.
>>
>> I, on my side, can't see benefits from your proposal. Compared to=20
>> modules, you propose compile time improvement at the expense of language=
=20
>> complexity and additional typing and bookkeeping. Where, this compile ti=
me=20
>> improvement would happen only full static interface vs pointer-only=20
>> interface. So, would _this_ _additional_ improvement be _that_ big to=20
>> counter language complexity it introduces? Please note that=20
>> pointer-dependent interface will have high chances to change anyway=20
>> whenever any modification happens inside module - because of inlining,=
=20
>> functions layout, etc.
>>
>>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e8079d91-db89-4d84-bc22-cbcde3a06936%40isocpp.or=
g.

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

<div dir=3D"ltr">I&#39;m not comparing them as a challenge. I&#39;m saying =
that your proposal is a mere tiny subset of modules proposal<br>Modules:<br=
>+ Public layer isolation. No pollution of importer&#39;s namespace with wh=
at he doesn&#39;t need.<br>+ Compile time reduction, because of shrinking d=
ependencies down to public layers.<br>+ One file per module<br>- &#39;modul=
e&#39; and &#39;import&#39; syntax instead of #include<br>- all dependents =
would be still recompiled on public layer change<br>Partials:<br>+ Pointer-=
only dependencies recompiled faster<br>- two headers instead of one<br>- tw=
o includes instead of one<br>- compile time is reduced upon amount of parsi=
ng private section of class, and only where only pointer is used<br>- need =
to keep track on where you need only pointers<br>- yet another keyword<br><=
br>On Friday, February 26, 2016 at 2:48:17 PM UTC+2, daniele...@gmail.com w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">You are =
comparing the two proposals as a challenge, but I have nothing against the =
module construct, it sounds powerful.<br>I am only saying that is does not =
remove all useless compile dependencies: if you argue the the size belongs =
to the public layer, all the users that do not need the size will still suf=
fer from this useless compile dependency.<br>Actually the users of a class =
can be split in two groups: those that do not create instances of the class=
 and those who do. Only the second need the size, but not the first, which =
therefore do not need to be recompiled when the private part of the used cl=
ass (and as consequence, the size) is modified.<br><br>Il giorno venerd=C3=
=AC 26 febbraio 2016 13:34:06 UTC+1, Igor Baidiuk ha scritto:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">Very simple. First, compiler is =
able to generate some kind of header from module, which contains only publi=
c layer (including struct sizes, but not exact layout of private parts). Ha=
ving this, no one prohibits compiler from shrinking this info to &quot;poin=
ter-only&quot; public layer, if needed. As a result, no need for yet anothe=
r language construct.<br><br>I, on my side, can&#39;t see benefits from you=
r proposal. Compared to modules, you propose compile time improvement at th=
e expense of language complexity and additional typing and bookkeeping. Whe=
re, this compile time improvement would happen only full static interface v=
s pointer-only interface. So, would _this_ _additional_ improvement be _tha=
t_ big to counter language complexity it introduces? Please note that point=
er-dependent interface will have high chances to change anyway whenever any=
 modification happens inside module - because of inlining, functions layout=
, etc.<br><br></div></blockquote></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8079d91-db89-4d84-bc22-cbcde3a06936%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e8079d91-db89-4d84-bc22-cbcde3a06936=
%40isocpp.org</a>.<br />

------=_Part_265_500166917.1456498488410--
------=_Part_264_2087037061.1456498488409--

.

------=_Part_634_1635501378.1456498809440
Content-Type: multipart/alternative;
 boundary="----=_Part_635_1619425412.1456498809440"

------=_Part_635_1619425412.1456498809440
Content-Type: text/plain; charset=UTF-8

To me, it would be pretty obvious that compile-time reflection won't be
able to see private or internal class members from outside of the module.

On Friday, February 26, 2016 at 4:48:10 PM UTC+2, Nicol Bolas wrote:
>
> On Friday, February 26, 2016 at 4:24:55 AM UTC-5, Igor Baidiuk wrote:
>>
>> To me, module proposal can actually handle this. A compiler smart enough
>> can extract "public layer" from module definition and recompile dependents
>> only when that public layer is changed. And please note that that public
>> layer will also include at least size of private part. Something like
>> `private: char _1234__[PRIVATE_PART_SIZE];`
>>
>
> Sure... right up until you start giving reflection the ability to access
> privates. Which pretty much every reflection proposal that allows you to
> access constructs on a type does.
>
> Then your module files need to actually store all private data.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8edcbf63-80a3-4bb6-9b00-207d65b9934e%40isocpp.org.

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

<div dir=3D"ltr">To me, it would be pretty obvious that compile-time reflec=
tion won&#39;t be able to see private or internal class members from outsid=
e of the module.<br><br>On Friday, February 26, 2016 at 4:48:10 PM UTC+2, N=
icol Bolas wrote:<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">On Friday, February 26, 2016 at 4:24:55 AM UTC-5, Igor Baidiuk wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">To me, module propos=
al can actually handle this. A compiler smart enough can extract &quot;publ=
ic layer&quot; from module definition and recompile dependents only when th=
at public layer is changed. And please note that that public layer will als=
o include at least size of private part. Something like `private: char _123=
4__[PRIVATE_PART_SIZE];`<br></div></blockquote><div><br>Sure... right up un=
til you start giving reflection the ability to access privates. Which prett=
y much every reflection proposal that allows you to access constructs on a =
type does.<br><br>Then your module files need to actually store all private=
 data.</div></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8edcbf63-80a3-4bb6-9b00-207d65b9934e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8edcbf63-80a3-4bb6-9b00-207d65b9934e=
%40isocpp.org</a>.<br />

------=_Part_635_1619425412.1456498809440--
------=_Part_634_1635501378.1456498809440--

.

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

On Fri, Feb 26, 2016 at 3:52 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> You mean besides basic usability, like not having to manually static_cast
to your actual type every time you do something like access a private
member?

Usability is yet to be mentioned by the OP, whose initial motivation was
solely "additional memory cost" which then somehow became "recompilation".

It is fairly obvious to me that the proposal is hardly anything but
syntactic sugar. Is that obvious to the OP?

Just for the record, having syntactic sugar is not bad per se.

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0w4dvYy1QDH%2BD6p6TebtvmeVZJZjYEabaF-63THhHczQ%40mail.gmail.com.

--001a113d2f8a1cf8a7052cada4e9
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 26, 2016 at 3:52 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">&gt; You mean besides basic usability, like not having to manually st=
atic_cast to your actual type every time you do something like access a pri=
vate member?</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_=
quote">Usability is yet to be mentioned by the OP, whose initial motivation=
 was solely &quot;additional memory cost&quot; which then somehow became &q=
uot;recompilation&quot;.</div><div class=3D"gmail_quote"><br></div><div cla=
ss=3D"gmail_quote">It is fairly obvious to me that the proposal is hardly a=
nything but syntactic sugar. Is that obvious to the OP?</div><div class=3D"=
gmail_quote"><br></div><div class=3D"gmail_quote">Just for the record, havi=
ng syntactic sugar is not bad per se.</div><div class=3D"gmail_quote"><br><=
/div><div class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">V.<=
/div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0w4dvYy1QDH%2BD6p6TebtvmeVZJZj=
YEabaF-63THhHczQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0w4dvYy1=
QDH%2BD6p6TebtvmeVZJZjYEabaF-63THhHczQ%40mail.gmail.com</a>.<br />

--001a113d2f8a1cf8a7052cada4e9--

.

------=_Part_388_1553980770.1456499397479
Content-Type: multipart/alternative;
 boundary="----=_Part_389_959723523.1456499397479"

------=_Part_389_959723523.1456499397479
Content-Type: text/plain; charset=UTF-8

On Friday, February 26, 2016 at 10:00:09 AM UTC-5, Igor Baidiuk wrote:
>
> To me, it would be pretty obvious that compile-time reflection won't be
> able to see private or internal class members from outside of the module.
>

So serialization, and any other form of reflection, has to be intrusive?
Nonsense.

As I understand it, modules are only defined in one place. So you can't add
something to a module from outside of it, so under that paradigm, it would
be impossible to make non-intrusive reflection work.

That's not a good thing.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/92dbf625-ba3b-4398-a31f-7705f2efc7db%40isocpp.org.

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

<div dir=3D"ltr">On Friday, February 26, 2016 at 10:00:09 AM UTC-5, Igor Ba=
idiuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">T=
o me, it would be pretty obvious that compile-time reflection won&#39;t be =
able to see private or internal class members from outside of the module.<b=
r></div></blockquote><div><br>So serialization, and any other form of refle=
ction, has to be intrusive? Nonsense.<br><br>As I understand it, modules ar=
e only defined in one place. So you can&#39;t add something to a module fro=
m outside of it, so under that paradigm, it would be impossible to make non=
-intrusive reflection work.<br><br>That&#39;s not a good thing.<br></div></=
div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/92dbf625-ba3b-4398-a31f-7705f2efc7db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/92dbf625-ba3b-4398-a31f-7705f2efc7db=
%40isocpp.org</a>.<br />

------=_Part_389_959723523.1456499397479--
------=_Part_388_1553980770.1456499397479--

.

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

Your proposal looks like a workaround, and as such would have the following=
 drawbacks:

- the cast of pointers is in general unsafe and could be a source of subtle=
 runtime errors; in your case, you could have many classes deriving from if=
ace, but iface::foo would call statically only one "implementation" method.=
 A little bit confusing and error prone.
- "foo" is like an additional declaration to expose "bar": it means, for ea=
ch method of the public interface you want to declare, you need to declare =
it twice. Pretty tedious.
- "friend" is a feature that leads to code that is both difficult to unders=
tand and maintain; it actually breaks the encapsulation. Even the C++ origi=
nal book strongly suggests to avoid it.
- there would be possibly a small runtime penalty (two function calls inste=
ad of a single one).

I think using "friend" just to specify an interface is a bad programming st=
yle, more "C-like", not good C++.
In my proposal, the interface is explicitly declared as such; no other dang=
erous workaround are needed.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a01958c0-8cfe-457a-a34a-e9a280b8600a%40isocpp.or=
g.

------=_Part_86_1906141080.1456499502020--

.

On 2016-02-26 09:48, Nicol Bolas wrote:
> On Friday, February 26, 2016 at 4:24:55 AM UTC-5, Igor Baidiuk wrote:
>> To me, module proposal can actually handle this. A compiler smart enough
>> can extract "public layer" from module definition and recompile dependents
>> only when that public layer is changed. And please note that that public
>> layer will also include at least size of private part. Something like
>> `private: char _1234__[PRIVATE_PART_SIZE];`
>
> Sure... right up until you start giving reflection the ability to access
> privates. Which pretty much every reflection proposal that allows you to
> access constructs on a type does.

Uh... encapsulation violation?

Well, okay, I could imagine some form of friending to allow this, but I
would rather hope that reflection isn't carte blanche to ignore access
protection.

On 2016-02-26 10:09, Nicol Bolas wrote:
> So serialization [...] has to be intrusive?

Yes. For the same reasons that copy ctors are intrusive. How on earth is
a generic mechanism supposed to know how to serialize and deserialize an
arbitrary class? These operations may have requirements that are not
readily deduced from just the class layout.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/napqsh%24nmm%241%40ger.gmane.org.

.

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

On Fri, Feb 26, 2016 at 4:11 PM, <daniele.bordes@gmail.com> wrote:

> Your proposal looks like a workaround

Well, it is an attempt to achieve the goals you stated expressly (no
additional memory; no recompilation) using only current C++.

> - the cast of pointers is in general unsafe and could be a source of
subtle runtime errors; in your case, you could have many classes deriving
from iface, but iface::foo would call statically only one "implementation"
method. A little bit confusing and error prone.

That could be remedied by making their constructors private, with the only
friend being the implementation class.

> - "foo" is like an additional declaration to expose "bar": it means, for
each method of the public interface you want to declare, you need to
declare it twice. Pretty tedious.

No; perhaps I did not express my intent clearly. bar() was merely an
indication of "something private to the implementation". One need not
define a private method for each public one.

> - "friend" is a feature that leads to code that is both difficult to
understand and maintain; it actually breaks the encapsulation. Even the C++
original book strongly suggests to avoid it.

In C++, friend means "tightly coupled with". This is exactly what you want.
Your proposal, even though not using the keyword friend, makes two classes
tightly coupled, to the point that they reference each other in their
definitions; that is also why no encapsulation is being broken as compared
to your proposal.

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3vRFHA0sPtoJgXEOSMXxfSOBD6Ac-ZLT2Xb5vUUspHVQ%40mail.gmail.com.

--047d7b6725dc80ab33052cae1d96
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 26, 2016 at 4:11 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:danie=
le.bordes@gmail.com" target=3D"_blank">daniele.bordes@gmail.com</a>&gt;</sp=
an> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote">&gt; Your proposal looks like a workaround<div><br></div><div>Well, it=
 is an attempt to achieve the goals you stated expressly (no additional mem=
ory; no recompilation) using only current C++.</div><div><br></div><div>&gt=
; - the cast of pointers is in general unsafe and could be a source of subt=
le runtime errors; in your case, you could have many classes deriving from =
iface, but iface::foo would call statically only one &quot;implementation&q=
uot; method. A little bit confusing and error prone.</div><div><br></div><d=
iv>That could be remedied by making their constructors private, with the on=
ly friend being the implementation class.</div><div><br></div><div>&gt; - &=
quot;foo&quot; is like an additional declaration to expose &quot;bar&quot;:=
 it means, for each method of the public interface you want to declare, you=
 need to declare it twice. Pretty tedious.</div><div><br></div><div>No; per=
haps I did not express my intent clearly. bar() was merely an indication of=
 &quot;something private to the implementation&quot;. One need not define a=
 private method for each public one.</div><div><br></div><div>&gt; - &quot;=
friend&quot; is a feature that leads to code that is both difficult to unde=
rstand and maintain; it actually breaks the encapsulation. Even the C++ ori=
ginal book strongly suggests to avoid it.</div><div><br></div><div>In C++, =
friend means &quot;tightly coupled with&quot;. This is exactly what you wan=
t. Your proposal, even though not using the keyword friend, makes two class=
es tightly coupled, to the point that they reference each other in their de=
finitions; that is also why no encapsulation is being broken as compared to=
 your proposal.</div><div><br></div><div>Cheers,</div><div>V.</div></div></=
div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3vRFHA0sPtoJgXEOSMXxfSOBD6Ac-Z=
LT2Xb5vUUspHVQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3vRFHA0sPt=
oJgXEOSMXxfSOBD6Ac-ZLT2Xb5vUUspHVQ%40mail.gmail.com</a>.<br />

--047d7b6725dc80ab33052cae1d96--

.

------=_Part_727_920258256.1456502687782
Content-Type: multipart/alternative;
 boundary="----=_Part_728_1031952388.1456502687783"

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

The text of my proposal says explicitly "without recurring to bad C-like=20
programming". I think your example (by the way, a one that we already=20
thought) falls in that category.
A concept should be expressed and realized in a simple and clear way, not=
=20
with a serie of workarounds likes:

- friend
- pointer conversion
- private constructor (?)

Some other considerations:
- many coding guidelines would be break by such an attempt.
- a class could be friend with many other classes; it does not specify that=
=20
it is an interface. Besides, If I write "iface", I have no control about=20
other possible derivation from iface: this is matter of other programmers:=
=20
they can do what they want with their constructors.
- finally, I think your example breaks the Liskov principle too.



Il giorno venerd=C3=AC 26 febbraio 2016 16:40:16 UTC+1, Viacheslav Usov ha=
=20
scritto:
>
> On Fri, Feb 26, 2016 at 4:11 PM, <daniele...@gmail.com <javascript:>>=20
> wrote:
>
> > Your proposal looks like a workaround
>
> Well, it is an attempt to achieve the goals you stated expressly (no=20
> additional memory; no recompilation) using only current C++.
>
> > - the cast of pointers is in general unsafe and could be a source of=20
> subtle runtime errors; in your case, you could have many classes deriving=
=20
> from iface, but iface::foo would call statically only one "implementation=
"=20
> method. A little bit confusing and error prone.
>
> That could be remedied by making their constructors private, with the onl=
y=20
> friend being the implementation class.
>
> > - "foo" is like an additional declaration to expose "bar": it means, fo=
r=20
> each method of the public interface you want to declare, you need to=20
> declare it twice. Pretty tedious.
>
> No; perhaps I did not express my intent clearly. bar() was merely an=20
> indication of "something private to the implementation". One need not=20
> define a private method for each public one.
>
> > - "friend" is a feature that leads to code that is both difficult to=20
> understand and maintain; it actually breaks the encapsulation. Even the C=
++=20
> original book strongly suggests to avoid it.
>
> In C++, friend means "tightly coupled with". This is exactly what you=20
> want. Your proposal, even though not using the keyword friend, makes two=
=20
> classes tightly coupled, to the point that they reference each other in=
=20
> their definitions; that is also why no encapsulation is being broken as=
=20
> compared to your proposal.
>
> Cheers,
> V.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/59566830-e0fd-4730-9416-bc427c249c48%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>The text of my proposal says explicitly &quot;without=
 recurring to bad C-like programming&quot;. I think your example (by the wa=
y, a one that we already thought) falls in that category.</div><div>A conce=
pt should be expressed and realized in a simple and clear way, not with a s=
erie of workarounds likes:</div><div><br></div><div>- friend</div><div>- po=
inter conversion</div><div>- private constructor (?)</div><div><br></div><d=
iv>Some other considerations:</div><div>- many coding guidelines would be b=
reak by such an attempt.</div><div>- a class could be friend with many othe=
r classes; it does not specify that it is an interface. Besides, If I write=
 &quot;iface&quot;, I have no control about other possible derivation from =
iface: this is matter of other programmers: they can do what they want with=
 their constructors.</div><div>- finally, I think your example breaks the L=
iskov principle too.</div><div><div><div><br></div><div><br></div><div><br>=
</div><div>Il giorno venerd=C3=AC 26 febbraio 2016 16:40:16 UTC+1, Viachesl=
av Usov ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote">On Fri, Feb 26, 2016 at 4:11 PM,  <sp=
an dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"j8h4hE_tAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">daniele...@gmail.com</a>&gt;</span> wrote:</div><div class=3D=
"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; Your proposal looks=
 like a workaround<div><br></div><div>Well, it is an attempt to achieve the=
 goals you stated expressly (no additional memory; no recompilation) using =
only current C++.</div><div><br></div><div>&gt; - the cast of pointers is i=
n general unsafe and could be a source of subtle runtime errors; in your ca=
se, you could have many classes deriving from iface, but iface::foo would c=
all statically only one &quot;implementation&quot; method. A little bit con=
fusing and error prone.</div><div><br></div><div>That could be remedied by =
making their constructors private, with the only friend being the implement=
ation class.</div><div><br></div><div>&gt; - &quot;foo&quot; is like an add=
itional declaration to expose &quot;bar&quot;: it means, for each method of=
 the public interface you want to declare, you need to declare it twice. Pr=
etty tedious.</div><div><br></div><div>No; perhaps I did not express my int=
ent clearly. bar() was merely an indication of &quot;something private to t=
he implementation&quot;. One need not define a private method for each publ=
ic one.</div><div><br></div><div>&gt; - &quot;friend&quot; is a feature tha=
t leads to code that is both difficult to understand and maintain; it actua=
lly breaks the encapsulation. Even the C++ original book strongly suggests =
to avoid it.</div><div><br></div><div>In C++, friend means &quot;tightly co=
upled with&quot;. This is exactly what you want. Your proposal, even though=
 not using the keyword friend, makes two classes tightly coupled, to the po=
int that they reference each other in their definitions; that is also why n=
o encapsulation is being broken as compared to your proposal.</div><div><br=
></div><div>Cheers,</div><div>V.</div></div></div></div>
</blockquote></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/59566830-e0fd-4730-9416-bc427c249c48%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/59566830-e0fd-4730-9416-bc427c249c48=
%40isocpp.org</a>.<br />

------=_Part_728_1031952388.1456502687783--
------=_Part_727_920258256.1456502687782--

.

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

Something more to the comparison between my proposal and the "modules": act=
ually I did not want nor need a "revolution" of the language as the one rep=
resented by the "module" construct: I just needed a solution as simple as p=
ossible to solve a remarkable, tedious problem, but keeping the language al=
most as it already is.
As for the keywords, probably the syntax could be simplified removing "part=
ial" at all, since "export" by the "partial class" would be enough. So my p=
roposals would not need additional keywords at all.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/35690250-23d7-478b-aa3a-625c2c590fe7%40isocpp.or=
g.

------=_Part_799_608584277.1456502903929--

.

------=_Part_311_1042528137.1456506347529
Content-Type: multipart/alternative;
 boundary="----=_Part_312_1503444930.1456506347529"

------=_Part_312_1503444930.1456506347529
Content-Type: text/plain; charset=UTF-8

On Friday, February 26, 2016 at 10:27:22 AM UTC-5, Matthew Woehlke wrote:
>
> On 2016-02-26 09:48, Nicol Bolas wrote:
> > On Friday, February 26, 2016 at 4:24:55 AM UTC-5, Igor Baidiuk wrote:
> >> To me, module proposal can actually handle this. A compiler smart
> enough
> >> can extract "public layer" from module definition and recompile
> dependents
> >> only when that public layer is changed. And please note that that
> public
> >> layer will also include at least size of private part. Something like
> >> `private: char _1234__[PRIVATE_PART_SIZE];`
> >
> > Sure... right up until you start giving reflection the ability to access
> > privates. Which pretty much every reflection proposal that allows you to
> > access constructs on a type does.
>
> Uh... encapsulation violation?
>

Yes. And?

I never said that I *liked* the idea of being able to reflect into
someone's privates. But like I said, C++ reflection proposals that allow
class introspection have always included the ability to violate
encapsulation. Just take a look at P0194; there is *nothing* to stop
outside code from using `get_all_data_members` to get all the members.

Clearly, people who want static reflection feel that this is important. So
if modules is going to make privates completely hidden, that will clash
with reflecting over privates.

*Personally*, I dislike the idea of reflecting over private members, and
I'd be in favor of modules hiding privates.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94af8408-56e7-4f3e-a02f-8f08f3f7607c%40isocpp.org.

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

<div dir=3D"ltr">On Friday, February 26, 2016 at 10:27:22 AM UTC-5, Matthew=
 Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-02-26 0=
9:48, Nicol Bolas wrote:
<br>&gt; On Friday, February 26, 2016 at 4:24:55 AM UTC-5, Igor Baidiuk wro=
te:
<br>&gt;&gt; To me, module proposal can actually handle this. A compiler sm=
art enough=20
<br>&gt;&gt; can extract &quot;public layer&quot; from module definition an=
d recompile dependents=20
<br>&gt;&gt; only when that public layer is changed. And please note that t=
hat public=20
<br>&gt;&gt; layer will also include at least size of private part. Somethi=
ng like=20
<br>&gt;&gt; `private: char _1234__[PRIVATE_PART_SIZE];`
<br>&gt;=20
<br>&gt; Sure... right up until you start giving reflection the ability to =
access=20
<br>&gt; privates. Which pretty much every reflection proposal that allows =
you to=20
<br>&gt; access constructs on a type does.
<br>
<br>Uh... encapsulation violation?
<br></blockquote><div><br>Yes. And?<br><br>I never said that I <i>liked</i>=
 the idea of being able to reflect into someone&#39;s privates. But like I =
said, C++ reflection proposals that allow class introspection have always i=
ncluded the ability to violate encapsulation. Just take a look at P0194; th=
ere is <i>nothing</i> to stop outside code from using `get_all_data_members=
` to get all the members.<br><br>Clearly, people who want static reflection=
 feel that this is important. So if modules is going to make privates compl=
etely hidden, that will clash with reflecting over privates.<br><br><i>Pers=
onally</i>, I dislike the idea of reflecting over private members, and I&#3=
9;d be in favor of modules hiding privates.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94af8408-56e7-4f3e-a02f-8f08f3f7607c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/94af8408-56e7-4f3e-a02f-8f08f3f7607c=
%40isocpp.org</a>.<br />

------=_Part_312_1503444930.1456506347529--
------=_Part_311_1042528137.1456506347529--

.

------=_Part_707_578520240.1456506360885
Content-Type: multipart/alternative;
 boundary="----=_Part_708_155678860.1456506360885"

------=_Part_708_155678860.1456506360885
Content-Type: text/plain; charset=UTF-8

On Friday, February 26, 2016 at 11:08:24 AM UTC-5, daniele...@gmail.com
wrote:
>
> Something more to the comparison between my proposal and the "modules":
> actually I did not want nor need a "revolution" of the language as the one
> represented by the "module" construct: I just needed a solution as simple
> as possible to solve a remarkable, tedious problem, but keeping the
> language almost as it already is.
> As for the keywords, probably the syntax could be simplified removing
> "partial" at all, since "export" by the "partial class" would be enough. So
> my proposals would not need additional keywords at all.


Except that `export` has a relationship to modules now. It's not your
keyword to use for your pet feature.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f7dc696c-0fbb-4bbc-9127-8c8b9fc9eebf%40isocpp.org.

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

<div dir=3D"ltr">On Friday, February 26, 2016 at 11:08:24 AM UTC-5, daniele=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Something =
more to the comparison between my proposal and the &quot;modules&quot;: act=
ually I did not want nor need a &quot;revolution&quot; of the language as t=
he one represented by the &quot;module&quot; construct: I just needed a sol=
ution as simple as possible to solve a remarkable, tedious problem, but kee=
ping the language almost as it already is.<br>As for the keywords, probably=
 the syntax could be simplified removing &quot;partial&quot; at all, since =
&quot;export&quot; by the &quot;partial class&quot; would be enough. So my =
proposals would not need additional keywords at all.</blockquote><div><br>E=
xcept that `export` has a relationship to modules now. It&#39;s not your ke=
yword to use for your pet feature.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f7dc696c-0fbb-4bbc-9127-8c8b9fc9eebf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f7dc696c-0fbb-4bbc-9127-8c8b9fc9eebf=
%40isocpp.org</a>.<br />

------=_Part_708_155678860.1456506360885--
------=_Part_707_578520240.1456506360885--

.

On Tue, Feb 23, 2016 at 05:55:57AM -0800, daniele.bordes@gmail.com wrote:
> The private part of a class must be declared in the same header file where
> the public part is also declared and therefore included by all the users of
> that class.
> This means that whenever the private part of a class (a part of its
> implementation) is changed, as a consequence all the users of that class
> need to be recompiled.
> Currently only two solutions exist to avoid this problem:
>
> 1) inheritance
> 2) patterns like handle/body (also know as Pimpl Idiom)
>
> Both solutions requires additional memory costs, because each object would
> have an additional pointer. These additional memory costs could represent a
> severe penalty in Embedded Software.
>
> A new "*partial class*" construct can avoid both the recompilation problem
> and these additional memory costs: for a complete description of this new
> proposal, see attachments.

When I read this proposal my first thoughts went in the direction of the
"declare private members outside of the declaration" proposal.

I think this proposal is way to limiting if it should be done.

Why should partial classes not be allowed to declare that they inherit from
other classes and why should they not be allowed to declare virtual functions?

So, I think that if it happens then it should be as follows:

partial class Foo : public Fum {
public:
 void foo();
 virtual void bar();
};

// At this point is the type Foo incomplete but it is known to have the
// operations foo() and bar(). This is the functionality the original poster
// was after.
// Note that we don't know it there are any automatically generated members,
// They have to be declared to exist in partial classes.

partial class Foo size(64) align(16) {
public:
 Foo(int, int);
};

// At this point is it known that sizeof(Foo) is 64 bytes and that it have a
// constructor taking two ints but all that was known in the first partial
// declaration is also known. The align directive tells how the oobject should
// be aligned.

// If there are two size or align directives with different values for the
// same class then that trigger undefined behaviour

class Foo {
public:
 Foo(Foo&& foo);
private:
 char buf[32];
};

// At this point is all of Foo declared. Note that sizeof(Foo) is 64 and
// alignof(Foo) is 16 due to the earlier declaratinos.
// If the data inside Foo gets bigger than the size directive allows, or if
// it forces stricter alignment than the align directive then that is
// an error with a required diagnostic.

It should probably be noted that I doubt anything will come from this.

/MF

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160226230126.GA22559%40noemi.

.

------=_Part_1137_424911262.1456530427948
Content-Type: multipart/alternative;
 boundary="----=_Part_1138_137145090.1456530427949"

------=_Part_1138_137145090.1456530427949
Content-Type: text/plain; charset=UTF-8

Isn't what you are proposing (in the pdf) just an attempt to reimplement
abstract base classes?
Functions relying only on the abstract base interface, need not be
recompiled when the implementation of concrete types change.
Example:

//StackInterface.h

struct StackInterface {
virtual void public_func() = 0;
};

//StackInterfaceFuncs.cpp //This file need not be recompiled when StackImp
 changes

#include "StackInterface.h"
void func(StackInterface& stack){
 stack.public_func();
}


//StackImp.h
#include "StackInterface.h"
struct StackImp: public StackInterface
{
 void public_func() {}
private:
 void private_func() {}
 int priv_var;
};


//main.cpp
#include "StackImp.h"
main() {
 StackImp s;
 func(s);
}



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ffef6ccc-3a11-4497-ac9f-edea23852cff%40isocpp.org.

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

<div dir=3D"ltr"><div><div>Isn&#39;t what you are proposing (in the pdf) ju=
st an attempt to reimplement abstract base classes?=C2=A0</div><div>Functio=
ns relying only on the abstract base interface, need not be recompiled when=
 the implementation of concrete types change.=C2=A0</div><div>Example:<br><=
/div><div><br><div><div class=3D"prettyprint" style=3D"border: 1px solid rg=
b(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 25=
0);"><code class=3D"prettyprint"><div style=3D"font-family: Arial, Helvetic=
a, sans-serif; background-color: rgb(255, 255, 255);">//StackInterface.h<br=
><br></div><div style=3D"font-family: Arial, Helvetica, sans-serif; backgro=
und-color: rgb(255, 255, 255);">struct StackInterface {</div><div style=3D"=
font-family: Arial, Helvetica, sans-serif; background-color: rgb(255, 255, =
255);"><span class=3D"Apple-tab-span" style=3D"white-space: pre;"> </span>v=
irtual void public_func() =3D 0;</div><div style=3D"font-family: Arial, Hel=
vetica, sans-serif; background-color: rgb(255, 255, 255);">};<br></div><div=
 class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div><div><div class=3D"prettyprint" styl=
e=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgroun=
d-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: rgb(136, 0, 0); font-family: Arial, Helv=
etica, sans-serif;"><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">//StackInterfaceFuncs.cpp //This file need not be recompiled when=C2=A0<=
/span></span><span style=3D"color: rgb(102, 0, 102); font-family: Arial, He=
lvetica, sans-serif;">StackImp</span><span style=3D"color: rgb(136, 0, 0); =
font-family: Arial, Helvetica, sans-serif;">=C2=A0changes</span></div><div =
class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">#include</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&quot;Sta=
ckInterface.h&quot;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fu=
nc</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">StackInterface</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> stack</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">){</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> <br>=C2=A0stack</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">public_func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span></div></code></div><div><br></div=
><div><br></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(1=
87, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #800;" class=3D"styled-by-prettify">//<span style=3D"color: rgb(102,=
 0, 102);">StackImp</span>.h</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">#include</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
>&quot;StackInterface.h&quot;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">=C2=A0</span><span style=3D"color: rgb(102, 0, 102); font-family: =
Arial, Helvetica, sans-serif;">StackImp</span><span class=3D"styled-by-pret=
tify" style=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(102, 1=
02, 0);">:</span><span class=3D"styled-by-prettify" style=3D"font-family: A=
rial, Helvetica, sans-serif; color: rgb(0, 0, 0);"> </span><span class=3D"s=
tyled-by-prettify" style=3D"font-family: Arial, Helvetica, sans-serif; colo=
r: rgb(0, 0, 136);">public</span><span class=3D"styled-by-prettify" style=
=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);"> </spa=
n><span class=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica=
, sans-serif; color: rgb(102, 0, 102);">StackInterface</span></div><div cla=
ss=3D"subprettyprint"><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettify">void=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> public_fu=
nc</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: #660;" class=3D"styled-by-prettify">{}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">private</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> private_func</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-pretti=
fy">{}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> priv_var</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></div=
><div><br></div></div></div></div></div><div><br></div><div class=3D"pretty=
print" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word=
; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">//main.cpp</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>#include</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&quot;<spa=
n style=3D"color: rgb(102, 0, 102); font-family: Arial, Helvetica, sans-ser=
if;">StackImp</span>.h&quot;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>main</span><span style=3D"color: #660;" class=3D"styl=
ed-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>=C2=A0=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><span styl=
e=3D"color: rgb(102, 0, 102); font-family: Arial, Helvetica, sans-serif;">S=
tackImp</span>=C2=A0s</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0func</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br></span></div></code></div><=
div><br><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ffef6ccc-3a11-4497-ac9f-edea23852cff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ffef6ccc-3a11-4497-ac9f-edea23852cff=
%40isocpp.org</a>.<br />

------=_Part_1138_137145090.1456530427949--
------=_Part_1137_424911262.1456530427948--

.

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

@perle

No, on the contrary: my proposal is to allow to split the header of a "conc=
rete type".
Using abstract base classes as in your example falls in the category "polym=
orphism/inheritance" described in the .pdf as one of the two current possib=
le solutions to remove compile dependencies, which would have unfortunately=
 the drawback of an additional pointer for each object (pointer to the virt=
ual table), that is, a "memory penalty" which my proposal wants also to avo=
id.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/66caa005-7b15-4352-9b17-d81a6ad0e485%40isocpp.or=
g.

------=_Part_1268_108656756.1456533195822--

.

------=_Part_1095_320577002.1456533441296
Content-Type: text/plain; charset=UTF-8

@Magnus

If I understand well, I think you could be right: in my proposal a "partial class" should not be a polymorphic type, this would affect the "memory layout" of each instances and this should be prohibited.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/268f1083-4b74-46e6-b2d9-7fd92f51e757%40isocpp.org.

------=_Part_1095_320577002.1456533441296--

.

------=_Part_1273_1786594649.1456533621439
Content-Type: text/plain; charset=UTF-8

@petke

Sorry, tip error: @perle above was meant to be for you.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6b13edaa-4f73-4412-8adb-04fea07c0765%40isocpp.org.

------=_Part_1273_1786594649.1456533621439--

.

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

Le 23/02/2016 14:55, daniele.bordes@gmail.com a =C3=A9crit :
> The private part of a class must be declared in the same header file=20
> where the public part is also declared and therefore included by all=20
> the users of that class.
> This means that whenever the private part of a class (a part of its=20
> implementation) is changed, as a consequence all the users of that=20
> class need to be recompiled.
> Currently only two solutions exist to avoid this problem:
>
> 1) inheritance
> 2) patterns like handle/body (also know as Pimpl Idiom)
>
> Both solutions requires additional memory costs, because each object=20
> would have an additional pointer. These additional memory costs could=20
> represent a severe penalty in Embedded Software.
>
> A new "*partial class*" construct can avoid both the recompilation=20
> problem and these additional memory costs: for a complete description=20
> of this new proposal, see attachments.
>
>
Hi,

I agree that this is something all the people coming from the C-world=20
are looking for.

I believe that C provides already the solution, but maybe the solution=20
is only partial, no pun intended.

Without any change sin the language, you need to forward declare the=20
class and add non-member functions taking a reference.

For example, in order to achieve your example

partial class Stack export StackInterface
{
public:

     // ordinary public methods:
     void push(int c);
     int pop();
     bool isFull();
     bool isEmpty();
};

In a StackRef.h file you can declare the reference interface as follows

//StackRef.h
class Stack;

// ordinary public methods:
void push(Stack& s, int c);
int pop(Stack& s);
bool isFull(Stack& s);
bool isEmpty(Stack& s);

In the Stack.h you declare your class as now.

//Stack.h

In Stack.cc you define the non-free member functions

void push(Stack& s, int c) { s.push(c));}
int pop(Stack& s) { return s.pop());}
bool isFull(Stack& s) { return s.isFull());}
bool isEmpty(Stack& s) { return s.isEmpty());}

I agree that this need some extra work from the developer side, but it=20
should cover what you are looking for.

If we had the uniform call syntax (that has been postponed) that=20
interpret s.f(a) as f(s,a), the user of the StackRef interface could use=20
also the member syntax.

I recognize that it is cumbersome to add the forwarding functions, and=20
your proposal has the merit to address this point.
Note that this technique doesn't provides access to the public members.

Whether it is worth to define an additional feature in the language to=20
cover this case is subject to discussion.

Vicente


P.S. I have not read your proposal yet :(

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/56D2C0C0.3020605%40wanadoo.fr.

--------------050405090200060607030300
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 23/02/2016 14:55,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:daniele.bordes@g=
mail.com">daniele.bordes@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:374600f5-0397-4243-91bc-d01afd145e6c@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>The private part of a class must be declared in the same
          header file where the public part is also declared and
          therefore included by all the users of that class.<br>
          This means that whenever the private part of a class (a part
          of its implementation) is changed, as a consequence all the
          users of that class need to be recompiled.<br>
          Currently only two solutions exist to avoid this problem:</div>
        <div><br>
        </div>
        <div>1) inheritance<br>
          2) patterns like handle/body (also know as Pimpl Idiom)</div>
        <div><br>
        </div>
        <div>Both solutions requires additional memory costs, because
          each object would have an additional pointer. These additional
          memory costs could represent a severe penalty in Embedded
          Software.</div>
        <div><br>
        </div>
        <p>A new "<strong>partial class</strong>" construct can avoid
          both the recompilation problem and these additional memory
          costs: for a complete description of this new proposal, see
          attachments.</p>
      </div>
      <br>
    </blockquote>
    Hi,<br>
    <br>
    I agree that this is something all the people coming from the
    C-world are looking for.<br>
    <br>
    I believe that C provides already the solution, but maybe the
    solution is only partial, no pun intended. <br>
    <br>
    Without any change sin the language, you need to forward declare the
    class and add non-member functions taking a reference.<br>
    <br>
    For example, in order to achieve your example<br>
    <br>
    partial class Stack export StackInterface<br>
    {<br>
    public: <br>
    <br>
    =C2=A0=C2=A0=C2=A0 // ordinary public methods:<br>
    =C2=A0=C2=A0=C2=A0 void push(int c);<br>
    =C2=A0=C2=A0=C2=A0 int pop();<br>
    =C2=A0=C2=A0=C2=A0 bool isFull();<br>
    =C2=A0=C2=A0=C2=A0 bool isEmpty();<br>
    };<br>
    <br>
    In a StackRef.h file you can declare the reference interface as
    follows<br>
    <br>
    //StackRef.h<br>
    class Stack;<br>
    <br>
    // ordinary public methods:<br>
    void push(Stack&amp; s, int c);<br>
    int pop(Stack&amp; s);<br>
    bool isFull(Stack&amp; s);<br>
    bool isEmpty(Stack&amp; s);<br>
    <br>
    In the Stack.h you declare your class as now.<br>
    =C2=A0<br>
    //Stack.h<br>
    <br>
    In Stack.cc you define the non-free member functions<br>
    <br>
    void push(Stack&amp; s, int c) { s.push(c));}<br>
    int pop(Stack&amp; s) { return s.pop());}<br>
    bool isFull(Stack&amp; s) { return s.isFull());}<br>
    bool isEmpty(Stack&amp; s) { return s.isEmpty());}<br>
    <br>
    I agree that this need some extra work from the developer side, but
    it should cover what you are looking for.<br>
    <br>
    If we had the uniform call syntax (that has been postponed) that
    interpret s.f(a) as f(s,a), the user of the StackRef interface could
    use also the member syntax.<br>
    <br>
    I recognize that it is cumbersome to add the forwarding functions,
    and your proposal has the merit to address this point. <br>
    Note that this technique doesn't provides access to the public
    members.<br>
    =C2=A0<br>
    Whether it is worth to define an additional feature in the language
    to cover this case is subject to discussion.<br>
    <br>
    Vicente<br>
    <br>
    <br>
    P.S. I have not read your proposal yet :(<br>
    <br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/56D2C0C0.3020605%40wanadoo.fr?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/56D2C0C0.3020605%40wanadoo.fr</a>.<br />

--------------050405090200060607030300--

.

------=_Part_330_1042530846.1456656141596
Content-Type: text/plain; charset=UTF-8

@Vicente

Hi Vicente,
thank you for your comment and your detailed example.
The point is that my proposal wants to avoid also the need of bad "C-like" programming: such a need would be a defeat of C++ against C. Otherwise, we could argue that everything can be done also in C, also polymorphism and so on.
In your C-like example the code of the interface must be replicated just because of a lack of the C++ language; I think this is tedious, not elegant, prone to error and probably need to pass pointers twice, with a small performance drawback.
Also, the syntax is C-like, with no evidence of invoking methods on an object.
My proposal would not suffer of any of such drawbacks; I also think that it  would by trivial to bring this proposal in the new C++.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b%40isocpp.org.

------=_Part_330_1042530846.1456656141596--

.

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

Le 28/02/2016 11:42, daniele.bordes@gmail.com a =C3=A9crit :
> @Vicente
>
> Hi Vicente,
> thank you for your comment and your detailed example.
Now I have read your proposal.
> The point is that my proposal wants to avoid also the need of bad "C-like=
" programming: such a need would be a defeat of C++ against C. Otherwise, w=
e could argue that everything can be done also in C, also polymorphism and =
so on.
Why do you say bad C-like programming. What is bad with it? I like=20
functional programming and a non-member function is a good interface to=20
my taste.
> In your C-like example the code of the interface must be replicated just =
because of a lack of the C++ language;
Note that you need to declare the functions and define them and you=20
repeat the interface also.

You can refine the C-like solution with more C++ features. Instead of=20
forwarding you can declare the non-member functions friend, which allows=20
to define the function without  needing to forward to a member function.

class Stack {

friend void push(Stack& s, int c) { ... }
friend int pop(Stack& s) { ...}
friend bool isFull(Stack& s) { ... }
friend bool isEmpty(Stack& s) { ... }

};

> I think this is tedious,
The previous solution is no more tedious that separating the declaration=20
and the definition.
> not elegant,
I could agree here, but IMO is the more elegant solution to the problem=20
I believe you want to solve with the current language.
> prone to error
I could agree with you with the forward solution, but I don't agree with=20
the friend alternative presented above.
> and probably need to pass pointers twice, with a small performance drawba=
ck.
I don't understand what you mean here.
> Also, the syntax is C-like, with no evidence of invoking methods on an ob=
ject.
This can be a plus for some of us. I don't know why a Method is better=20
than a function, because it is OO?
C++ is a multi-paradigm language. The user could need whatever is more=20
appropriated to his problem.
> My proposal would not suffer of any of such drawbacks; I also think that =
it  would by trivial to bring this proposal in the new C++.
>
I'm not saying that there is not a problem to solve, and I'm not against=20
a better solution to the problem and maybe your proposal is the better=20
solution. All will depend on the limitations the solution imposes and=20
the impact on other features of the language.


I believe however that you must compare what is comparable. BTW, I will=20
suggest to change your proposal and add a 0) C-like solution, that as I=20
have explained is better than the others you describe as current=20
alternatives without changing the language.

I don't know nothing that can be of trivial in the context of C++ and=20
less yet at this level. First, if you consider that this is trivial,=20
I'll suggest you invest sometime in implementing it.

Next follows some from the proposal

  *

    - cannot specify any derivations from other classes (only the
    =E2=80=9Cinternal class=E2=80=9D may do it)

  *

    - cannot declare data members

  *

    - cannot have virtual methods

  *

    - cannot declare constructors nor the destructor

All these constraints seems to be in line with my C++14/17 solution=20
forward declaring the class.

  *

    - may contain declaration of classes or enums

Without been to obtuse, I suspect that these are public declaration.=20
With the current language you could define them on an auxiliary class,=20
e.g. in StackInterface. Maybe not elegant, but possible.

  *

    - may declare static const plain data types

The same here.

  *

    - may declare operators


What do you mean by declare operators?

  *

    - may declare template methods

Do you mean template member functions that use only the interface of the=20
partial class? If yes, the template member function can be a non-member=20
as well.

The intent of my comments is not to break your proposal, but to state=20
clearly what I consider is the best way to solve the problem at hand=20
today without language changes. I consider the alternatives 1)=20
polymorphic types and 2) pimpl clearly as no solution to the problem at=20
hand.

Having in addition Uniform Call Syntax (x.f(a) and be used where f(x,a))=20
that we have not, I believe your proposal will not solve any major=20
issue. I'm not saying it couldn't solve minor issues.

Best,
Vicente

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/56D2E312.1010201%40wanadoo.fr.

--------------080803030906060802010802
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 28/02/2016 11:42,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:daniele.bordes@g=
mail.com">daniele.bordes@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">@Vicente

Hi Vicente,=20
thank you for your comment and your detailed example.</pre>
    </blockquote>
    Now I have read your proposal.<br>
    <blockquote
      cite=3D"mid:d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">
The point is that my proposal wants to avoid also the need of bad "C-like" =
programming: such a need would be a defeat of C++ against C. Otherwise, we =
could argue that everything can be done also in C, also polymorphism and so=
 on.</pre>
    </blockquote>
    Why do you say bad C-like programming. What is bad with it? I like
    functional programming and a non-member function is a good interface
    to my taste.<br>
    <blockquote
      cite=3D"mid:d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">
In your C-like example the code of the interface must be replicated just be=
cause of a lack of the C++ language; </pre>
    </blockquote>
    Note that you need to declare the functions and define them and you
    repeat the interface also.<br>
    <br>
    You can refine the C-like solution with more C++ features. Instead
    of forwarding you can declare the non-member functions friend, which
    allows to define the function without=C2=A0 needing to forward to a
    member function.<br>
    <br>
    class Stack {<br>
    <br>
    friend void push(Stack&amp; s, int c) { ... }<br>
    friend int pop(Stack&amp; s) { ...}<br>
    friend bool isFull(Stack&amp; s) { ... }<br>
    friend bool isEmpty(Stack&amp; s) { ... }<br>
    <br>
    };<br>
    <br>
    <blockquote
      cite=3D"mid:d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">I think this is tedious, </pre>
    </blockquote>
    The previous solution is no more tedious that separating the
    declaration and the definition.<br>
    <blockquote
      cite=3D"mid:d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">not elegant, </pre>
    </blockquote>
    I could agree here, but IMO is the more elegant solution to the
    problem I believe you want to solve with the current language.<br>
    <blockquote
      cite=3D"mid:d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">prone to error </pre>
    </blockquote>
    I could agree with you with the forward solution, but I don't agree
    with the friend alternative presented above.<br>
    <blockquote
      cite=3D"mid:d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">and probably need to pass pointers twice, with a small=
 performance drawback.</pre>
    </blockquote>
    I don't understand what you mean here.<br>
    <blockquote
      cite=3D"mid:d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">
Also, the syntax is C-like, with no evidence of invoking methods on an obje=
ct.</pre>
    </blockquote>
    This can be a plus for some of us. I don't know why a Method is
    better than a function, because it is OO?<br>
    C++ is a multi-paradigm language. The user could need whatever is
    more appropriated to his problem.<br>
    <blockquote
      cite=3D"mid:d37fd2b7-0355-4c8a-8f5e-dc17d9dfe69b@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">
My proposal would not suffer of any of such drawbacks; I also think that it=
  would by trivial to bring this proposal in the new C++.=20

</pre>
    </blockquote>
    I'm not saying that there is not a problem to solve, and I'm not
    against a better solution to the problem and maybe your proposal is
    the better solution. All will depend on the limitations the solution
    imposes and the impact on other features of the language.<br>
    <br>
    <br>
    I believe however that you must compare what is comparable. BTW, I
    will suggest to change your proposal and add a 0) C-like solution,
    that as I have explained is better than the others you describe as
    current alternatives without changing the language.<br>
    <br>
    I don't know nothing that can be of trivial in the context of C++
    and less yet at this level. First, if you consider that this is
    trivial, I'll suggest you invest sometime in implementing it.<br>
    <br>
    Next follows some from the proposal<br>
    <br>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
    <div class=3D"page" title=3D"Page 4">
      <div class=3D"layoutArea">
        <div class=3D"column">
          <ul style=3D"list-style-type: none">
            <li>
              <p><span style=3D"font-size: 6.000000pt; font-family:
                  'Calibri'">- =C2=A0</span><span style=3D"font-size:
                  10.000000pt; font-family: 'Calibri'">cannot specify
                  any derivations from other classes (only the </span><span
                  style=3D"font-size: 10.000000pt; font-family: 'Calibri'">=
=E2=80=9C</span><span
                  style=3D"font-size: 10.000000pt; font-family: 'Calibri'">=
internal
                  class</span><span style=3D"font-size: 10.000000pt;
                  font-family: 'Calibri'">=E2=80=9D </span><span
                  style=3D"font-size: 10.000000pt; font-family: 'Calibri'">=
may
                  do it)
                </span></p>
            </li>
            <li>
              <p><span style=3D"font-size: 6.000000pt; font-family:
                  'Calibri'">- =C2=A0</span><span style=3D"font-size:
                  10.000000pt; font-family: 'Calibri'">cannot declare
                  data members
                </span></p>
            </li>
            <li>
              <p><span style=3D"font-size: 6.000000pt; font-family:
                  'Calibri'">- =C2=A0</span><span style=3D"font-size:
                  10.000000pt; font-family: 'Calibri'">cannot have
                  virtual methods
                </span></p>
            </li>
            <li>
              <p><span style=3D"font-size: 6.000000pt; font-family:
                  'Calibri'">- =C2=A0</span><span style=3D"font-size:
                  10.000000pt; font-family: 'Calibri'">cannot declare
                  constructors nor the destructor
                </span></p>
            </li>
          </ul>
          <span style=3D"font-size: 10.000000pt; font-family: 'Calibri'">Al=
l
            these constraints seems to be in line with my C++14/17
            solution forward declaring the class.<br>
          </span>
          <ul style=3D"list-style-type: none">
            <li>
              <p><span style=3D"font-size: 6.000000pt; font-family:
                  'Calibri'">- =C2=A0</span><span style=3D"font-size:
                  10.000000pt; font-family: 'Calibri'">may contain
                  declaration of classes or enums
                </span></p>
            </li>
          </ul>
          <span style=3D"font-size: 10.000000pt; font-family: 'Calibri'">Wi=
thout
            been to obtuse, I suspect that these are public declaration.
            With the current language you could define them on an
            auxiliary class, e.g. in StackInterface. Maybe not elegant,
            but possible.<br>
          </span>
          <ul style=3D"list-style-type: none">
            <li>
              <p><span style=3D"font-size: 6.000000pt; font-family:
                  'Calibri'">- =C2=A0</span><span style=3D"font-size:
                  10.000000pt; font-family: 'Calibri'">may declare
                  static const plain data types
                </span></p>
            </li>
          </ul>
          <span style=3D"font-size: 10.000000pt; font-family: 'Calibri'">Th=
e
            same here.<br>
          </span>
          <ul style=3D"list-style-type: none">
            <li>
              <p><span style=3D"font-size: 6.000000pt; font-family:
                  'Calibri'">- =C2=A0</span><span style=3D"font-size:
                  10.000000pt; font-family: 'Calibri'">may declare
                  operators
                </span></p>
            </li>
          </ul>
          <br>
          What do you mean by declare operators? <br>
          <ul style=3D"list-style-type: none">
            <li>
              <p><span style=3D"font-size: 6.000000pt; font-family:
                  'Calibri'">- =C2=A0</span><span style=3D"font-size:
                  10.000000pt; font-family: 'Calibri'">may declare
                  template methods
                </span></p>
            </li>
          </ul>
        </div>
      </div>
    </div>
    Do you mean template member functions that use only the interface of
    the partial class? If yes, the template member function can be a
    non-member as well.<br>
    <br>
    The intent of my comments is not to break your proposal, but to
    state clearly what I consider is the best way to solve the problem
    at hand today without language changes. I consider the alternatives
    1) polymorphic types and 2) pimpl clearly as no solution to the
    problem at hand.<br>
    <title></title>
    <br>
    Having in addition Uniform Call Syntax (x.f(a) and be used where
    f(x,a)) that we have not, I believe your proposal will not solve any
    major issue. I'm not saying it couldn't solve minor issues.<br>
    <br>
    Best,<br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/56D2E312.1010201%40wanadoo.fr?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/56D2E312.1010201%40wanadoo.fr</a>.<br />

--------------080803030906060802010802--

.

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

@Vicente

Thank you very much for your deep discussion.
I still believe that a concept should be expressed in a natural and clear w=
ay, with no additional unneeded resource consumption and without need of wo=
rkarounds.
I have nothing against functional programming, when it is adequate for the =
situation; but I think firmly that in our topic this would be just a workar=
ound to express object oriented programming where the language fails to off=
er both compile independency and no additional memory.
One would program that way in C, not in C++. For the same reason, we could =
criticise the class construct itself in favor of old C struct, or the virtu=
al methods and say that pointers to functions solve already the problem!
What we want to express is an interface of a concrete-type class: your exam=
ple with "friends" and forward declararion does not express this in a clear=
 way, in my opinion. Besides, it should be the class itself to implement th=
ose methods,not demanding to friends their implementation.
Finally, many industrial coding-standards forbid "friend" usage because it =
can lead to a broken encapsulation and makes the code difficult to mantain =
and understand.
To summarise, I am convinced the C++ offers curiously only workarounds dang=
erous or breaking encapsulation to the problem addressed by my proposal.


--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0530dfc5-c74a-4177-af46-51660e668885%40isocpp.or=
g.

------=_Part_2266_1496322053.1456665878477--

.

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

On 28 February 2016 at 08:24, <daniele.bordes@gmail.com> wrote:

> Finally, many industrial coding-standards forbid "friend" usage because it
> can lead to a broken encapsulation and makes the code difficult to mantain
> and understand.
>

It is not the responsibility of the C++ standard to get around broken
coding standards.  There is no guarantee that they would even adopt your
"fix", even if it were to pass the committee.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPcg88n9cRQZXqVaWOJ%3Do%2BaEdxETyj-ter9QG1AvB-%3DPQ%40mail.gmail.com.

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

<div dir=3D"ltr">On 28 February 2016 at 08:24,  <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:daniele.bordes@gmail.com" target=3D"_blank">daniele.bordes@gma=
il.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">Finally, many industrial coding-s=
tandards forbid &quot;friend&quot; usage because it can lead to a broken en=
capsulation and makes the code difficult to mantain and understand.<br></bl=
ockquote><div><br></div><div>It is not the responsibility of the C++ standa=
rd to get around broken coding standards.=C2=A0 There is no guarantee that =
they would even adopt your &quot;fix&quot;, even if it were to pass the com=
mittee.</div></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><=
div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailt=
o:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPcg88n9cRQZXqVaWOJ%3Do%2BaEd=
xETyj-ter9QG1AvB-%3DPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
Pcg88n9cRQZXqVaWOJ%3Do%2BaEdxETyj-ter9QG1AvB-%3DPQ%40mail.gmail.com</a>.<br=
 />

--e89a8f23438152cea2052cd53f72--

.

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

That is not the main reason for my proposal, just an additional considerati=
on.
"Friend" is not a way to specify the interface of a class. All oppositions =
that I read here sound similar to oppositions to classes, constructors and =
virtual methods when C++ was firstly introduced in place of C: structs, glo=
bal functions, functions named "init" and pointers to function should have =
been already enough!

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/04574d52-3de5-44e8-97a0-736b3bbec1dc%40isocpp.or=
g.

------=_Part_2223_1178282483.1456671943397--

.

Le 28/02/2016 14:24, daniele.bordes@gmail.com a =C3=A9crit :
> @Vicente
>
> Thank you very much for your deep discussion.
> I still believe that a concept should be expressed in a natural and clear=
 way, with no additional unneeded resource consumption and without need of =
workarounds.
> I have nothing against functional programming, when it is adequate for th=
e situation; but I think firmly that in our topic this would be just a work=
around to express object oriented programming where the language fails to o=
ffer both compile independency and no additional memory.
Your functions cannot be virtual so I don't see why OO will be better.
> One would program that way in C, not in C++. For the same reason, we coul=
d criticise the class construct itself in favor of old C struct, or the vir=
tual methods and say that pointers to functions solve already the problem!
Please, not that struct are part of C++. The solution I presented is C++=20
not old C.
> What we want to express is an interface of a concrete-type class: your ex=
ample with "friends" and forward declararion does not express this in a cle=
ar way, in my opinion.
Here we disagree. It is you that want to reduce compilation=20
dependencies. This is a valid technique today.
> Besides, it should be the class itself to implement those methods,not dem=
anding to friends their implementation.
Friend are part of the a class interface.
> Finally, many industrial coding-standards forbid "friend" usage because i=
t can lead to a broken encapsulation and makes the code difficult to mantai=
n and understand.
Ugh. See Nevin's comment.
> To summarise, I am convinced the C++ offers curiously only workarounds da=
ngerous or breaking encapsulation to the problem addressed by my proposal.
>
>
The use cases your proposal solves are quite limited. The solution I've=20
presented is not a workaround neither dangerous and it doesn't breaks=20
encapsulation. The single thing that could disturb some people that are=20
used to use member functions. And I believe your proposal must be based=20
on this fact. This is the added value of your proposal.

Note that I could be for a language solution if the benefit is clear and=20
the language solution is elegant.

I was wondering why the user can not use the name of the interface, it=20
whatever the use can use is a reference or pointer to the interface.

Vicente

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/56D319B3.2090208%40wanadoo.fr.

.

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

I just wanted to solve a precise problem with a simple solution with a mini=
mal impact on the current language. I am still convinced that my proposal d=
oes it, maybe even elegantly. You says that struct and friend are part C++:=
 my answer is that also "goto" is part of C++!
"friend" is "technically" a part of the interface, but I would judge as "po=
or" a design using "friend" to specify the entire public interface of class=
: I remember well that Stroustroup itself in his C++ book suggested strongl=
y to avoid its usage. "friend" is good for overriding operators, otherwise =
is in my opinion a patch or a backdoor for bad designed software.

About the restrictions:
- I am not 100% sure that virtual methods must be forbidden; anyhow the pre=
sence of them would require an additional pointer to the virtual table, mak=
ing the use of partial class not more relevant
- you are probably right with StackInterface: it could be used also like a =
typedef, that is a synonym of Stack=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9cb74ef9-f041-4a8a-878c-550ad85f89e9%40isocpp.or=
g.

------=_Part_2529_425764711.1456677224030--

.

------=_Part_2415_290446455.1456677624689
Content-Type: text/plain; charset=UTF-8

Another important drawback of the workaround with "friend" classes or methods is that it is not self-evident by looking at them that they are actually an interface of another class.
A construct should express clearly and elegantly its purpose without obscurity or ambiguity.
Looking at the code of StackInterface it is immediately evident by construct that this is the interface of Stack.
You do not have at all this expressivity with "friend", just because this is not its purpose.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79875053-cefa-467f-a9c7-ddc169116335%40isocpp.org.

------=_Part_2415_290446455.1456677624689--

.

Le 28/02/2016 17:33, daniele.bordes@gmail.com a =C3=A9crit :

Please add some context while replaying.
> I just wanted to solve a precise problem with a simple solution with a mi=
nimal impact on the current language. I am still convinced that my proposal=
 does it, maybe even elegantly.
I'm not against your proposal. I just wanted that your proposal compares=20
what is comparable.
> You says that struct and friend are part C++: my answer is that also "got=
o" is part of C++!
Her we agree ;-) I suspect that you are against "goto".
> "friend" is "technically" a part of the interface, but I would judge as "=
poor" a design using "friend" to specify the entire public interface of cla=
ss: I remember well that Stroustroup itself in his C++ book suggested stron=
gly to avoid its usage. "friend" is good for overriding operators, otherwis=
e is in my opinion a patch or a backdoor for bad designed software.
Thanks for the qualifications for my design :)
>
> About the restrictions:
> - I am not 100% sure that virtual methods must be forbidden; anyhow the p=
resence of them would require an additional pointer to the virtual table, m=
aking the use of partial class not more relevant
IMHO, this is out of the scope. If your class is polymorphic, there is=20
no need for partial classes. Abstract classes will be enough.
> - you are probably right with StackInterface: it could be used also like =
a typedef, that is a synonym of Stack
>
We can see your partial classes as subject interfaces of a global object=20
limiting the interface. There is no inheritance relationship between the=20
object and its subjects.

Note that some consider a good design to don't define public virtual=20
functions.

Vicente

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/56D3281C.2040305%40wanadoo.fr.

.

Le 28/02/2016 17:40, daniele.bordes@gmail.com a =C3=A9crit :
> Another important drawback of the workaround with "friend" classes or met=
hods is that it is not self-evident by looking at them that they are actual=
ly an interface of another class.
> A construct should express clearly and elegantly its purpose without obsc=
urity or ambiguity.
Are you looking for something like std::string?
I don't see why a lot of people consider that non-member functions are=20
obscure. If the function has as parameter a class the user should=20
consider it as part of the vocabulary of the class.

> Looking at the code of StackInterface it is immediately evident by constr=
uct that this is the interface of Stack.
> You do not have at all this expressivity with "friend", just because this=
 is not its purpose.
>
Aren't begin()/end()/swap()/hash()/ ... part of the interface of a class?
What is the purpose of declaring a function friend?

Vicente
Vicente

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/56D32B3C.5070906%40wanadoo.fr.

.

------=_Part_2541_1047776138.1456699488428
Content-Type: multipart/alternative;
 boundary="----=_Part_2542_1090760349.1456699488429"

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

@Vicente
Hi Vicente, thank you very much for the discussion.
Some other commentators argued that an important part to be discussed about=
=20
a proposal concerns how it can be actually implemented and how difficult it=
=20
could be; I think your example with using static methods of a friend class=
=20
would perfect to show how a compiler could translate the construct of my=20
proposal; this should also suggest that the impact of the proposal on the=
=20
language would be trivial.
I am still convinced that your example is a workaround, for the reasons=20
expressed above; to add some additional motivations, we should not forget=
=20
that many concepts expressed in a clear, concise and elegant way in C++=20
could have been also expressed in C for instance:

- a concrete-type C++ class with public member functions could have been=20
expressed in C with a struct and global methods taking as first parameter a=
=20
pointer to the struct
- C++ polymporphism could be expressed with a type-field and a switch-case,=
=20
or with pointer to functions
- a kind of generic programming could be realised with pointers to void or=
=20
heavy usage of macros.

C++ introduced clean constructs to express directly those concepts, without=
=20
need of expressed them using obscure alternatives or confusing workarounds=
=20
to be used in C; the workarounds described above did not stop those new=20
constructs to become part of the new language!

I think my proposal goes in the same direction.
About the fact that my proposal is quite simple and limited: it is simple,=
=20
but not limited: every concrete-type class could exploit the partial class=
=20
construct and therefore eliminate many compile dependencies.
For the simplicity and the possibility to be expressed with workarounds=20
through already existing constructs, my proposal could be maybe compared=20
with the "enum class" construct. I think this feature is "very little" but=
=20
really useful, in particular for embedded system, because it gives the=20
possibility to express how large exactly is a value of that enum; besides=
=20
it adds more type safety. I felt a lack of this feature in the old C++,=20
where it could have been expressed using an enum and a class (or even a=20
template), but it would have been not so elegant and concise, so this=20
possibility has not stopped the "enum cass" construct to become part of the=
=20
new C++.=20
I think for the same reason, my proposal could be part of the future=20
standard as well.

Il giorno domenica 28 febbraio 2016 18:02:22 UTC+1, Vicente J. Botet=20
Escriba ha scritto:
>
> Le 28/02/2016 17:33, daniele...@gmail.com <javascript:> a =C3=A9crit :=20
>
> Please add some context while replaying.=20
> > I just wanted to solve a precise problem with a simple solution with a=
=20
> minimal impact on the current language. I am still convinced that my=20
> proposal does it, maybe even elegantly.=20
> I'm not against your proposal. I just wanted that your proposal compares=
=20
> what is comparable.=20
> > You says that struct and friend are part C++: my answer is that also=20
> "goto" is part of C++!=20
> Her we agree ;-) I suspect that you are against "goto".=20
> > "friend" is "technically" a part of the interface, but I would judge as=
=20
> "poor" a design using "friend" to specify the entire public interface of=
=20
> class: I remember well that Stroustroup itself in his C++ book suggested=
=20
> strongly to avoid its usage. "friend" is good for overriding operators,=
=20
> otherwise is in my opinion a patch or a backdoor for bad designed softwar=
e.=20
> Thanks for the qualifications for my design :)=20
> >=20
> > About the restrictions:=20
> > - I am not 100% sure that virtual methods must be forbidden; anyhow the=
=20
> presence of them would require an additional pointer to the virtual table=
,=20
> making the use of partial class not more relevant=20
> IMHO, this is out of the scope. If your class is polymorphic, there is=20
> no need for partial classes. Abstract classes will be enough.=20
> > - you are probably right with StackInterface: it could be used also lik=
e=20
> a typedef, that is a synonym of Stack=20
> >=20
> We can see your partial classes as subject interfaces of a global object=
=20
> limiting the interface. There is no inheritance relationship between the=
=20
> object and its subjects.=20
>
> Note that some consider a good design to don't define public virtual=20
> functions.=20
>
> 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/77ca4d20-76ed-440d-afc4-ce12a5d4c5d9%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>@Vicente</div><div>Hi Vicente, thank you very much fo=
r the discussion.</div><div>Some other commentators argued that an importan=
t part to be discussed about a proposal concerns how it can be actually imp=
lemented and how difficult it could be; I think your example with using sta=
tic methods of a friend class would perfect to show how a compiler could tr=
anslate the construct of my proposal; this should also suggest that the imp=
act of the proposal on the language would be trivial.</div><div>I am still =
convinced that your example is a workaround, for the reasons expressed abov=
e; to add some additional motivations, we should not forget that many conce=
pts expressed in a clear, concise and elegant way in C++ could have been al=
so expressed in C for instance:</div><div><br></div><div>- a concrete-type =
C++ class with public member functions could have been expressed in C with =
a struct and global methods taking as first parameter a pointer to the stru=
ct</div><div>- C++ polymporphism could be expressed with a type-field and a=
 switch-case, or with pointer to functions</div><div>- a kind of generic pr=
ogramming could be realised with pointers to void or heavy usage of macros.=
</div><div><br></div><div>C++ introduced clean constructs to express direct=
ly those concepts, without need of expressed them using obscure alternative=
s or confusing workarounds to be used in C; the workarounds described above=
 did not stop those new constructs to become part of the new language!</div=
><div><br></div><div>I think my proposal goes in the same direction.</div><=
div>About the fact that my proposal is quite simple and limited: it is simp=
le, but not limited: every concrete-type class could exploit the partial cl=
ass construct and therefore eliminate many compile dependencies.</div><div>=
For the simplicity and the possibility to be expressed with workarounds thr=
ough already existing constructs, my proposal could be maybe compared with =
the &quot;enum class&quot; construct. I think this feature is &quot;very li=
ttle&quot; but really useful, in particular for embedded system, because it=
 gives the possibility to express how large exactly is a value of that enum=
; besides it adds more type safety. I felt a lack of this feature in the ol=
d C++, where it could have been expressed using an enum and a class (or eve=
n a template), but it would have been not so elegant and concise, so this p=
ossibility has not stopped the &quot;enum cass&quot; construct to become pa=
rt of the new C++.=C2=A0</div><div>I think for the same reason, my proposal=
 could be part of the future standard as well.</div><br>Il giorno domenica =
28 febbraio 2016 18:02:22 UTC+1, Vicente J. Botet Escriba ha scritto:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">Le 28/02/2016 17:33, <a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"iKsCtfOOAwAJ" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;javascript:&#39;;return true;">daniele...@gmail.com=
</a> a =C3=A9crit :
<br>
<br>Please add some context while replaying.
<br>&gt; I just wanted to solve a precise problem with a simple solution wi=
th a minimal impact on the current language. I am still convinced that my p=
roposal does it, maybe even elegantly.
<br>I&#39;m not against your proposal. I just wanted that your proposal com=
pares=20
<br>what is comparable.
<br>&gt; You says that struct and friend are part C++: my answer is that al=
so &quot;goto&quot; is part of C++!
<br>Her we agree ;-) I suspect that you are against &quot;goto&quot;.
<br>&gt; &quot;friend&quot; is &quot;technically&quot; a part of the interf=
ace, but I would judge as &quot;poor&quot; a design using &quot;friend&quot=
; to specify the entire public interface of class: I remember well that Str=
oustroup itself in his C++ book suggested strongly to avoid its usage. &quo=
t;friend&quot; is good for overriding operators, otherwise is in my opinion=
 a patch or a backdoor for bad designed software.
<br>Thanks for the qualifications for my design :)
<br>&gt;
<br>&gt; About the restrictions:
<br>&gt; - I am not 100% sure that virtual methods must be forbidden; anyho=
w the presence of them would require an additional pointer to the virtual t=
able, making the use of partial class not more relevant
<br>IMHO, this is out of the scope. If your class is polymorphic, there is=
=20
<br>no need for partial classes. Abstract classes will be enough.
<br>&gt; - you are probably right with StackInterface: it could be used als=
o like a typedef, that is a synonym of Stack
<br>&gt;
<br>We can see your partial classes as subject interfaces of a global objec=
t=20
<br>limiting the interface. There is no inheritance relationship between th=
e=20
<br>object and its subjects.
<br>
<br>Note that some consider a good design to don&#39;t define public virtua=
l=20
<br>functions.
<br>
<br>Vicente
<br></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/77ca4d20-76ed-440d-afc4-ce12a5d4c5d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77ca4d20-76ed-440d-afc4-ce12a5d4c5d9=
%40isocpp.org</a>.<br />

------=_Part_2542_1090760349.1456699488429--
------=_Part_2541_1047776138.1456699488428--

.

>=C2=A0


class Foo {
public:
 Foo(Foo&& foo);
private:
 char buf[32];
};



I think the 'full' class declaration would need to mention that it knows ab=
out t he existence of the partial declaration, otherwise you may have just =
changed the size of my class without telling me.=C2=A0


Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Magnus Fromreide
Sent: Friday, February 26, 2016 5:01 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Partial class: a separation of a class interfa=
ce from its implementation with no memory costs

On Tue, Feb 23, 2016 at 05:55:57AM -0800, daniele.bordes@gmail.com wrote:
> The private part of a class must be declared in the same header file wher=
e=20
> the public part is also declared and therefore included by all the users =
of=20
> that class.
> This means that whenever the private part of a class (a part of its=20
> implementation) is changed, as a consequence all the users of that class=
=20
> need to be recompiled.
> Currently only two solutions exist to avoid this problem:
>=20
> 1) inheritance
> 2) patterns like handle/body (also know as Pimpl Idiom)
>=20
> Both solutions requires additional memory costs, because each object woul=
d=20
> have an additional pointer. These additional memory costs could represent=
 a=20
> severe penalty in Embedded Software.
>=20
> A new "*partial class*" construct can avoid both the recompilation proble=
m=20
> and these additional memory costs: for a complete description of this new
> proposal, see attachments.

When I read this proposal my first thoughts went in the direction of the
"declare private members outside of the declaration" proposal.

I think this proposal is way to limiting if it should be done.

Why should partial classes not be allowed to declare that they inherit from
other classes and why should they not be allowed to declare virtual functio=
ns?

So, I think that if it happens then it should be as follows:

partial class Foo : public Fum {
public:
void foo();
virtual void bar();
};

// At this point is the type Foo incomplete but it is known to have the
// operations foo() and bar(). This is the functionality the original poste=
r
// was after.
// Note that we don't know it there are any automatically generated members=
,
// They have to be declared to exist in partial classes.

partial class Foo size(64) align(16) {
public:
Foo(int, int);
};

// At this point is it known that sizeof(Foo) is 64 bytes and that it have =
a
// constructor taking two ints but all that was known in the first partial
// declaration is also known. The align directive tells how the oobject sho=
uld
// be aligned.

// If there are two size or align directives with different values for the
// same class then that trigger undefined behaviour

class Foo {
public:
Foo(Foo&& foo);
private:
char buf[32];
};

// At this point is all of Foo declared. Note that sizeof(Foo) is 64 and=20
// alignof(Foo) is 16 due to the earlier declaratinos.
// If the data inside Foo gets bigger than the size directive allows, or if
// it forces stricter alignment than the align directive then that is
// an error with a required diagnostic.

It should probably be noted that I doubt anything will come from this.

/MF

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160226230126.GA22559%40noemi.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160228232905.4898897.92634.6149%40gmail.com.

.

I think we all understand your problem and your solution.=C2=A0

Now convince us, even if it is easy, that it is worth doing.=C2=A0

It may be the most elegant solution to *your* problem, and every other solu=
tion is inelegant. But why is your problem more important than other proble=
ms faced by developers?

How common is this problem? Do you have data/numbers to back it up?
Even if it is common, how painful is it? How inelegant are the solutions? (=
of course this is subjective, I don't know what kind of numbers you could s=
how here - compile speeds maybe?)

Stroustrup usually asks "is it one of the top 20 problems we should be solv=
ing?"


Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: daniele.bordes@gmail.com
Sent: Sunday, February 28, 2016 7:24 AM
To: ISO C++ Standard - Future Proposals
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Partial class: a separation of a class interfa=
ce from its implementation with no memory costs

@Vicente

Thank you very much for your deep discussion.
I still believe that a concept should be expressed in a natural and clear w=
ay, with no additional unneeded resource consumption and without need of wo=
rkarounds.
I have nothing against functional programming, when it is adequate for the =
situation; but I think firmly that in our topic this would be just a workar=
ound to express object oriented programming where the language fails to off=
er both compile independency and no additional memory.
One would program that way in C, not in C++. For the same reason, we could =
criticise the class construct itself in favor of old C struct, or the virtu=
al methods and say that pointers to functions solve already the problem!
What we want to express is an interface of a concrete-type class: your exam=
ple with "friends" and forward declararion does not express this in a clear=
 way, in my opinion. Besides, it should be the class itself to implement th=
ose methods,not demanding to friends their implementation.
Finally, many industrial coding-standards forbid "friend" usage because it =
can lead to a broken encapsulation and makes the code difficult to mantain =
and understand.
To summarise, I am convinced the C++ offers curiously only workarounds dang=
erous or breaking encapsulation to the problem addressed by my proposal.


--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0530dfc5-c74a-4177-af46-51660e668885%40isocpp.or=
g.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160228234329.4898897.51743.6154%40gmail.com.

.

On Sun, Feb 28, 2016 at 05:29:05PM -0600, Tony V E wrote:
> >=C2=A0
>=20
>=20
> class Foo {
> public:
>  Foo(Foo&& foo);
> private:
>  char buf[32];
> };
>=20
>=20
>=20
> I think the 'full' class declaration would need to mention that it knows =
about t he existence of the partial declaration, otherwise you may have jus=
t changed the size of my class without telling me.=C2=A0

Fair enough, but then I suppose that is true for any intemediate partial
declaration as well.

/MF

>=20
> Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0De=
vice
> =C2=A0 Original Message =C2=A0
> From: Magnus Fromreide
> Sent: Friday, February 26, 2016 5:01 PM
> To: std-proposals@isocpp.org
> Reply To: std-proposals@isocpp.org
> Subject: Re: [std-proposals] Partial class: a separation of a class inter=
face from its implementation with no memory costs
>=20
> On Tue, Feb 23, 2016 at 05:55:57AM -0800, daniele.bordes@gmail.com wrote:
> > The private part of a class must be declared in the same header file wh=
ere=20
> > the public part is also declared and therefore included by all the user=
s of=20
> > that class.
> > This means that whenever the private part of a class (a part of its=20
> > implementation) is changed, as a consequence all the users of that clas=
s=20
> > need to be recompiled.
> > Currently only two solutions exist to avoid this problem:
> >=20
> > 1) inheritance
> > 2) patterns like handle/body (also know as Pimpl Idiom)
> >=20
> > Both solutions requires additional memory costs, because each object wo=
uld=20
> > have an additional pointer. These additional memory costs could represe=
nt a=20
> > severe penalty in Embedded Software.
> >=20
> > A new "*partial class*" construct can avoid both the recompilation prob=
lem=20
> > and these additional memory costs: for a complete description of this n=
ew
> > proposal, see attachments.
>=20
> When I read this proposal my first thoughts went in the direction of the
> "declare private members outside of the declaration" proposal.
>=20
> I think this proposal is way to limiting if it should be done.
>=20
> Why should partial classes not be allowed to declare that they inherit fr=
om
> other classes and why should they not be allowed to declare virtual funct=
ions?
>=20
> So, I think that if it happens then it should be as follows:
>=20
> partial class Foo : public Fum {
> public:
> void foo();
> virtual void bar();
> };
>=20
> // At this point is the type Foo incomplete but it is known to have the
> // operations foo() and bar(). This is the functionality the original pos=
ter
> // was after.
> // Note that we don't know it there are any automatically generated membe=
rs,
> // They have to be declared to exist in partial classes.
>=20
> partial class Foo size(64) align(16) {
> public:
> Foo(int, int);
> };
>=20
> // At this point is it known that sizeof(Foo) is 64 bytes and that it hav=
e a
> // constructor taking two ints but all that was known in the first partia=
l
> // declaration is also known. The align directive tells how the oobject s=
hould
> // be aligned.
>=20
> // If there are two size or align directives with different values for th=
e
> // same class then that trigger undefined behaviour
>=20
> class Foo {
> public:
> Foo(Foo&& foo);
> private:
> char buf[32];
> };
>=20
> // At this point is all of Foo declared. Note that sizeof(Foo) is 64 and=
=20
> // alignof(Foo) is 16 due to the earlier declaratinos.
> // If the data inside Foo gets bigger than the size directive allows, or =
if
> // it forces stricter alignment than the align directive then that is
> // an error with a required diagnostic.
>=20
> It should probably be noted that I doubt anything will come from this.
>=20
> /MF
>=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=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/20160226230126.GA22559%40noemi.
>=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=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/20160228232905.4898897.92634.6149%40gmail.com.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160229062550.GA14865%40noemi.bahnhof.se.

.

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

I do not see the point here.
Users including the partial class header do not create instances of the cla=
ss, so they do not need the size of the class.
Partial class therefore does not provide any internal details, not even the=
 size.

Il giorno luned=C3=AC 29 febbraio 2016 07:25:55 UTC+1, Magnus Fromreide ha =
scritto:
> On Sun, Feb 28, 2016 at 05:29:05PM -0600, Tony V E wrote:
> > >=C2=A0
> >=20
> >=20
> > class Foo {
> > public:
> >  Foo(Foo&& foo);
> > private:
> >  char buf[32];
> > };
> >=20
> >=20
> >=20
> > I think the 'full' class declaration would need to mention that it know=
s about t he existence of the partial declaration, otherwise you may have j=
ust changed the size of my class without telling me.=C2=A0
>=20
> Fair enough, but then I suppose that is true for any intemediate partial
> declaration as well.
>=20
> /MF
>=20
> >=20
> > Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0=
Device
> > =C2=A0 Original Message =C2=A0
> > From: Magnus Fromreide
> > Sent: Friday, February 26, 2016 5:01 PM
> > To: std-proposals@isocpp.org
> > Reply To: std-proposals@isocpp.org
> > Subject: Re: [std-proposals] Partial class: a separation of a class int=
erface from its implementation with no memory costs
> >=20
> > On Tue, Feb 23, 2016 at 05:55:57AM -0800, daniele.bordes@gmail.com wrot=
e:
> > > The private part of a class must be declared in the same header file =
where=20
> > > the public part is also declared and therefore included by all the us=
ers of=20
> > > that class.
> > > This means that whenever the private part of a class (a part of its=
=20
> > > implementation) is changed, as a consequence all the users of that cl=
ass=20
> > > need to be recompiled.
> > > Currently only two solutions exist to avoid this problem:
> > >=20
> > > 1) inheritance
> > > 2) patterns like handle/body (also know as Pimpl Idiom)
> > >=20
> > > Both solutions requires additional memory costs, because each object =
would=20
> > > have an additional pointer. These additional memory costs could repre=
sent a=20
> > > severe penalty in Embedded Software.
> > >=20
> > > A new "*partial class*" construct can avoid both the recompilation pr=
oblem=20
> > > and these additional memory costs: for a complete description of this=
 new
> > > proposal, see attachments.
> >=20
> > When I read this proposal my first thoughts went in the direction of th=
e
> > "declare private members outside of the declaration" proposal.
> >=20
> > I think this proposal is way to limiting if it should be done.
> >=20
> > Why should partial classes not be allowed to declare that they inherit =
from
> > other classes and why should they not be allowed to declare virtual fun=
ctions?
> >=20
> > So, I think that if it happens then it should be as follows:
> >=20
> > partial class Foo : public Fum {
> > public:
> > void foo();
> > virtual void bar();
> > };
> >=20
> > // At this point is the type Foo incomplete but it is known to have the
> > // operations foo() and bar(). This is the functionality the original p=
oster
> > // was after.
> > // Note that we don't know it there are any automatically generated mem=
bers,
> > // They have to be declared to exist in partial classes.
> >=20
> > partial class Foo size(64) align(16) {
> > public:
> > Foo(int, int);
> > };
> >=20
> > // At this point is it known that sizeof(Foo) is 64 bytes and that it h=
ave a
> > // constructor taking two ints but all that was known in the first part=
ial
> > // declaration is also known. The align directive tells how the oobject=
 should
> > // be aligned.
> >=20
> > // If there are two size or align directives with different values for =
the
> > // same class then that trigger undefined behaviour
> >=20
> > class Foo {
> > public:
> > Foo(Foo&& foo);
> > private:
> > char buf[32];
> > };
> >=20
> > // At this point is all of Foo declared. Note that sizeof(Foo) is 64 an=
d=20
> > // alignof(Foo) is 16 due to the earlier declaratinos.
> > // If the data inside Foo gets bigger than the size directive allows, o=
r if
> > // it forces stricter alignment than the align directive then that is
> > // an error with a required diagnostic.
> >=20
> > It should probably be noted that I doubt anything will come from this.
> >=20
> > /MF
> >=20
> > --=20
> > You received this message because you are subscribed to the Google Grou=
ps "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.
> > To view this discussion on the web visit https://groups.google.com/a/is=
ocpp.org/d/msgid/std-proposals/20160226230126.GA22559%40noemi.
> >=20
> > --=20
> > You received this message because you are subscribed to the Google Grou=
ps "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.
> > To view this discussion on the web visit https://groups.google.com/a/is=
ocpp.org/d/msgid/std-proposals/20160228232905.4898897.92634.6149%40gmail.co=
m.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7b87aca6-ac06-4e2a-8555-ed7a238bfa19%40isocpp.or=
g.

------=_Part_2681_184019684.1456727655117--

.

On Sun, Feb 28, 2016 at 10:34:15PM -0800, daniele.bordes@gmail.com wrote:
> I do not see the point here.
> Users including the partial class header do not create instances of the c=
lass, so they do not need the size of the class.
> Partial class therefore does not provide any internal details, not even t=
he size.

This subthread is about my modified proposal that allows you to spcify the
size and alignment of the full class and put constructors in the partials.
Give this then it is possible to create instances of the class using only a
partial declaration if enough details are given.

/MF

>=20
> Il giorno luned=C3=AC 29 febbraio 2016 07:25:55 UTC+1, Magnus Fromreide h=
a scritto:
> > On Sun, Feb 28, 2016 at 05:29:05PM -0600, Tony V E wrote:
> > > >=C2=A0
> > >=20
> > >=20
> > > class Foo {
> > > public:
> > >  Foo(Foo&& foo);
> > > private:
> > >  char buf[32];
> > > };
> > >=20
> > >=20
> > >=20
> > > I think the 'full' class declaration would need to mention that it kn=
ows about t he existence of the partial declaration, otherwise you may have=
 just changed the size of my class without telling me.=C2=A0
> >=20
> > Fair enough, but then I suppose that is true for any intemediate partia=
l
> > declaration as well.
> >=20
> > /MF
> >=20
> > >=20
> > > Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=
=A0Device
> > > =C2=A0 Original Message =C2=A0
> > > From: Magnus Fromreide
> > > Sent: Friday, February 26, 2016 5:01 PM
> > > To: std-proposals@isocpp.org
> > > Reply To: std-proposals@isocpp.org
> > > Subject: Re: [std-proposals] Partial class: a separation of a class i=
nterface from its implementation with no memory costs
> > >=20
> > > On Tue, Feb 23, 2016 at 05:55:57AM -0800, daniele.bordes@gmail.com wr=
ote:
> > > > The private part of a class must be declared in the same header fil=
e where=20
> > > > the public part is also declared and therefore included by all the =
users of=20
> > > > that class.
> > > > This means that whenever the private part of a class (a part of its=
=20
> > > > implementation) is changed, as a consequence all the users of that =
class=20
> > > > need to be recompiled.
> > > > Currently only two solutions exist to avoid this problem:
> > > >=20
> > > > 1) inheritance
> > > > 2) patterns like handle/body (also know as Pimpl Idiom)
> > > >=20
> > > > Both solutions requires additional memory costs, because each objec=
t would=20
> > > > have an additional pointer. These additional memory costs could rep=
resent a=20
> > > > severe penalty in Embedded Software.
> > > >=20
> > > > A new "*partial class*" construct can avoid both the recompilation =
problem=20
> > > > and these additional memory costs: for a complete description of th=
is new
> > > > proposal, see attachments.
> > >=20
> > > When I read this proposal my first thoughts went in the direction of =
the
> > > "declare private members outside of the declaration" proposal.
> > >=20
> > > I think this proposal is way to limiting if it should be done.
> > >=20
> > > Why should partial classes not be allowed to declare that they inheri=
t from
> > > other classes and why should they not be allowed to declare virtual f=
unctions?
> > >=20
> > > So, I think that if it happens then it should be as follows:
> > >=20
> > > partial class Foo : public Fum {
> > > public:
> > > void foo();
> > > virtual void bar();
> > > };
> > >=20
> > > // At this point is the type Foo incomplete but it is known to have t=
he
> > > // operations foo() and bar(). This is the functionality the original=
 poster
> > > // was after.
> > > // Note that we don't know it there are any automatically generated m=
embers,
> > > // They have to be declared to exist in partial classes.
> > >=20
> > > partial class Foo size(64) align(16) {
> > > public:
> > > Foo(int, int);
> > > };
> > >=20
> > > // At this point is it known that sizeof(Foo) is 64 bytes and that it=
 have a
> > > // constructor taking two ints but all that was known in the first pa=
rtial
> > > // declaration is also known. The align directive tells how the oobje=
ct should
> > > // be aligned.
> > >=20
> > > // If there are two size or align directives with different values fo=
r the
> > > // same class then that trigger undefined behaviour
> > >=20
> > > class Foo {
> > > public:
> > > Foo(Foo&& foo);
> > > private:
> > > char buf[32];
> > > };
> > >=20
> > > // At this point is all of Foo declared. Note that sizeof(Foo) is 64 =
and=20
> > > // alignof(Foo) is 16 due to the earlier declaratinos.
> > > // If the data inside Foo gets bigger than the size directive allows,=
 or if
> > > // it forces stricter alignment than the align directive then that is
> > > // an error with a required diagnostic.
> > >=20
> > > It should probably be noted that I doubt anything will come from this=
..
> > >=20
> > > /MF
> > >=20
> > > --=20
> > > You received this message because you are subscribed to the Google Gr=
oups "ISO C++ Standard - Future Proposals" group.
> > > To unsubscribe from this group and stop receiving emails from it, sen=
d an email to std-proposals+unsubscribe@isocpp.org.
> > > To post to this group, send email to std-proposals@isocpp.org.
> > > To view this discussion on the web visit https://groups.google.com/a/=
isocpp.org/d/msgid/std-proposals/20160226230126.GA22559%40noemi.
> > >=20
> > > --=20
> > > You received this message because you are subscribed to the Google Gr=
oups "ISO C++ Standard - Future Proposals" group.
> > > To unsubscribe from this group and stop receiving emails from it, sen=
d an email to std-proposals+unsubscribe@isocpp.org.
> > > To post to this group, send email to std-proposals@isocpp.org.
> > > To view this discussion on the web visit https://groups.google.com/a/=
isocpp.org/d/msgid/std-proposals/20160228232905.4898897.92634.6149%40gmail.=
com.
>=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=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/7b87aca6-ac06-4e2a-8555-ed7a238bfa19%40isocpp.=
org.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160229065054.GB14865%40noemi.bahnhof.se.

.

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

On Fri, Feb 26, 2016 at 5:04 PM, <daniele.bordes@gmail.com> wrote:

> The text of my proposal says explicitly "without recurring to bad C-like
programming". I think your example (by the way, a one that we already
thought) falls in that category.

"Bad" is subjective. "C-like", given that clause 1.1.2 of the C++ standard
says "C++ is a general purpose programming language based on the C
programming language", means "C++-like" and is wholly tautological and thus
irrelevant. If you want your proposal to gain traction, you need a very
clear and unambiguous motivating part to it. As things stand now, the bold
text in your proposal is SIMPLY NOT what you really want to address with
your proposal, because those things are addressable with existing C++
means, however "C-like" they might seem to you. This confused message is
very likely the reason you are getting largely negative feedback here.

At the heart of your proposal, what you really want is the freedom as in
pure C to use essentially forward-declared structures combined with the
C++-like method calls, except that the methods in your proposal are never
virtual. If your methods are never virtual, there is no functional
difference whatsoever with using non-member functions ("C-like" in your
terminology). The difference is purely syntactical, so your proposal is
essentially about making your preferred function call syntax easier to use
in a particular case.

Is that an unreasonable thing to ask for? Not really. Is it so important
that it will grab the full attention of the C++ committee? This is an
interesting question, because the syntactical differences in function call
syntax are a pretty hot topic for the C++ committee [1], with some
decisions already made [2].

Cheers,
V.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf

[2] https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3AOmiDXtY58AosYG%3DQhq9K8J0q%2BjjdgLEi1P0Bph6r%2BQ%40mail.gmail.com.

--001a11c24f0624c06e052ce950be
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 Fri, Feb 26, 2016 at 5:04 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:d=
aniele.bordes@gmail.com" target=3D"_blank">daniele.bordes@gmail.com</a>&gt;=
</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">&gt; The text of my proposal says explicitly &quot;without recurri=
ng to bad C-like programming&quot;. I think your example (by the way, a one=
 that we already thought) falls in that category.</div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote">&quot;Bad&quot; is subjective. =
&quot;C-like&quot;, given that clause 1.1.2 of the C++ standard says &quot;=
C++ is a general purpose programming language based on the C programming la=
nguage&quot;, means &quot;C++-like&quot; and is wholly tautological and thu=
s irrelevant. If you want your proposal to gain traction, you need a very c=
lear and unambiguous motivating part to it. As things stand now, the bold t=
ext in your proposal is SIMPLY NOT what you really want to address with you=
r proposal, because those things are addressable with existing C++ means, h=
owever &quot;C-like&quot; they might seem to you. This confused message is =
very likely the reason you are getting largely negative feedback here.</div=
><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">At the hea=
rt of your proposal, what you really want is the freedom as in pure C to us=
e essentially forward-declared structures combined with the C++-like method=
 calls, except that the methods in your proposal are never virtual. If your=
 methods are never virtual, there is no functional difference whatsoever wi=
th using non-member functions (&quot;C-like&quot; in your terminology). The=
 difference is purely syntactical, so your proposal is essentially about ma=
king your preferred function call syntax easier to use in a particular case=
..</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Is t=
hat an unreasonable thing to ask for? Not really. Is it so important that i=
t will grab the full attention of the C++ committee? This is an interesting=
 question, because the syntactical differences in function call syntax are =
a pretty hot topic for the C++ committee [1], with some decisions already m=
ade [2].</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quot=
e">Cheers,<br></div><div class=3D"gmail_quote">V.</div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote"><div class=3D"gmail_quote">[1] =
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pd=
f" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
5/n4474.pdf</a></div><div class=3D"gmail_quote"><br></div><div class=3D"gma=
il_quote">[2] <a href=3D"https://isocpp.org/blog/2015/11/kona-standards-mee=
ting-trip-report" target=3D"_blank">https://isocpp.org/blog/2015/11/kona-st=
andards-meeting-trip-report</a></div><div><br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3AOmiDXtY58AosYG%3DQhq9K8J0q%2=
BjjdgLEi1P0Bph6r%2BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3AOm=
iDXtY58AosYG%3DQhq9K8J0q%2BjjdgLEi1P0Bph6r%2BQ%40mail.gmail.com</a>.<br />

--001a11c24f0624c06e052ce950be--

.

On segunda-feira, 29 de fevereiro de 2016 15:17:46 PST Viacheslav Usov wrote:
> At the heart of your proposal, what you really want is the freedom as in
> pure C to use essentially forward-declared structures combined with the
> C++-like method calls, except that the methods in your proposal are never
> virtual. If your methods are never virtual, there is no functional
> difference whatsoever with using non-member functions ("C-like" in your
> terminology). The difference is purely syntactical, so your proposal is
> essentially about making your preferred function call syntax easier to use
> in a particular case.

If you take the unified call syntax proposal, this changes too.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/26489669.qsiea8TUlO%40tjmaciei-mobl4.

.

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

Hi Viacheslav,

thank you very much for your precious considerations.
I changed slightly the points regarding "bad C-like programming" and added =
other stuff required by some other comments. I will post it as soon as poss=
ible.
Anyhow, I must honestly admit that I do not share completely the same opini=
on when you write:

"there is no functional difference whatsoever with using non-member functio=
ns"

The alternative to member function calls is using static methods of a frien=
d class and a procedural programming style; in my opinion, this is not a me=
re syntactic question because:

a) you must use the additional "friend" construct
b) it is not immediate that a static method of friend class is actually an =
interface of another class
c) the same friend class could be used as friend of many other classes, pos=
sibly leading to the break of the information hiding principles.

If I look into the code and see:

C c =3D ::method(a, b)

I expect that "method" uses the object a, b through their public interfaces=
 and produces c, not that method is a part of the interface provided by a o=
r by b.

Therefore, I think the point is not really the "no functional difference", =
but the fact that using non-member functions to ultimately realize an inter=
face obliges to use something that makes the code more obscure to understan=
d and difficult to test.
This is the opinion of Stroustroup about friend:

"All other things considered equal, choose a member. It is not possible to =
know if someone someday will define a conversion operator. It is not always=
 possible to predict if a future change may require changes to the state of=
 the object involved. The member function call syntax makes it clear to the=
 user that the object may be modified; a reference argument is far less obv=
ious. Furthermore, expressions in the body of a member can be noticeably sh=
orter than the equivalent expressions in a global function; a nonmember fun=
ction must use an explicit argument, whereas the member can use this implic=
itly. Also, because member names are local to the class they tend to be
shorter than the names of nonmember functions."

"Don=E2=80=99t use friends, except to avoid global data or public data memb=
ers"

I am 100% of the same opinion.
Il giorno luned=C3=AC 29 febbraio 2016 15:17:48 UTC+1, Viacheslav Usov ha s=
critto:
> On Fri, Feb 26, 2016 at 5:04 PM,  <daniele...@gmail.com> wrote:
>=20
>=20
> > The text of my proposal says explicitly "without recurring to bad C-lik=
e programming". I think your example (by the way, a one that we already tho=
ught) falls in that category.
>=20
>=20
> "Bad" is subjective. "C-like", given that clause 1.1.2 of the C++ standar=
d says "C++ is a general purpose programming language based on the C progra=
mming language", means "C++-like" and is wholly tautological and thus irrel=
evant. If you want your proposal to gain traction, you need a very clear an=
d unambiguous motivating part to it. As things stand now, the bold text in =
your proposal is SIMPLY NOT what you really want to address with your propo=
sal, because those things are addressable with existing C++ means, however =
"C-like" they might seem to you. This confused message is very likely the r=
eason you are getting largely negative feedback here.
>=20
>=20
> At the heart of your proposal, what you really want is the freedom as in =
pure C to use essentially forward-declared structures combined with the C++=
-like method calls, except that the methods in your proposal are never virt=
ual. If your methods are never virtual, there is no functional difference w=
hatsoever with using non-member functions ("C-like" in your terminology). T=
he difference is purely syntactical, so your proposal is essentially about =
making your preferred function call syntax easier to use in a particular ca=
se.
>=20
>=20
> Is that an unreasonable thing to ask for? Not really. Is it so important =
that it will grab the full attention of the C++ committee? This is an inter=
esting question, because the syntactical differences in function call synta=
x are a pretty hot topic for the C++ committee [1], with some decisions alr=
eady made [2].
>=20
>=20
> Cheers,
>=20
> V.
>=20
>=20
>=20
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf
>=20
>=20
> [2] https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/71766f85-7330-4387-8485-642e3f3ad003%40isocpp.or=
g.

------=_Part_673_20477013.1456768071671--

.

------=_Part_539_781984494.1456769593608
Content-Type: multipart/alternative;
 boundary="----=_Part_540_24197826.1456769593609"

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

Another fundamental (in my opinion) difference between member functions and=
=20
non-member functions of a friend class:

- a member function can realize only a relation 1:1 with the class it=20
belongs to (it is a member of that class, not of other classes)
- a non-member function of a friend class can realize potentially a=20
relation 1:n with all the classes it is friend to

I do not think this is mere syntax.

Il giorno luned=C3=AC 29 febbraio 2016 15:17:48 UTC+1, Viacheslav Usov ha=
=20
scritto:
>
>
> On Fri, Feb 26, 2016 at 5:04 PM, <daniele...@gmail.com <javascript:>>=20
> wrote:
>
> > The text of my proposal says explicitly "without recurring to bad C-lik=
e=20
> programming". I think your example (by the way, a one that we already=20
> thought) falls in that category.
>
> "Bad" is subjective. "C-like", given that clause 1.1.2 of the C++ standar=
d=20
> says "C++ is a general purpose programming language based on the C=20
> programming language", means "C++-like" and is wholly tautological and th=
us=20
> irrelevant. If you want your proposal to gain traction, you need a very=
=20
> clear and unambiguous motivating part to it. As things stand now, the bol=
d=20
> text in your proposal is SIMPLY NOT what you really want to address with=
=20
> your proposal, because those things are addressable with existing C++=20
> means, however "C-like" they might seem to you. This confused message is=
=20
> very likely the reason you are getting largely negative feedback here.
>
> At the heart of your proposal, what you really want is the freedom as in=
=20
> pure C to use essentially forward-declared structures combined with the=
=20
> C++-like method calls, except that the methods in your proposal are never=
=20
> virtual. If your methods are never virtual, there is no functional=20
> difference whatsoever with using non-member functions ("C-like" in your=
=20
> terminology). The difference is purely syntactical, so your proposal is=
=20
> essentially about making your preferred function call syntax easier to us=
e=20
> in a particular case.
>
> Is that an unreasonable thing to ask for? Not really. Is it so important=
=20
> that it will grab the full attention of the C++ committee? This is an=20
> interesting question, because the syntactical differences in function cal=
l=20
> syntax are a pretty hot topic for the C++ committee [1], with some=20
> decisions already made [2].
>
> Cheers,
> V.
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf
>
> [2] https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/702cd644-9973-4418-8374-0e815461720a%40isocpp.or=
g.

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

<div dir=3D"ltr">Another fundamental (in my opinion) difference between mem=
ber functions and non-member functions of a friend class:<div><br></div><di=
v>- a member function can realize only a relation 1:1=C2=A0with the class i=
t belongs to (it is a member of that class, not of other classes)</div><div=
>- a non-member function of a friend class can realize potentially a relati=
on 1:n with all the classes it is friend to</div><div><br></div><div>I do n=
ot think this is mere syntax.<br><div><br>Il giorno luned=C3=AC 29 febbraio=
 2016 15:17:48 UTC+1, Viacheslav Usov ha scritto:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><br><div class=3D"gmail_quote">On =
Fri, Feb 26, 2016 at 5:04 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"PkyHUY3UAwAJ" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">daniele...@gmail.com</a>&gt=
;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gma=
il_quote">&gt; The text of my proposal says explicitly &quot;without recurr=
ing to bad C-like programming&quot;. I think your example (by the way, a on=
e that we already thought) falls in that category.</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote">&quot;Bad&quot; is subjective.=
 &quot;C-like&quot;, given that clause 1.1.2 of the C++ standard says &quot=
;C++ is a general purpose programming language based on the C programming l=
anguage&quot;, means &quot;C++-like&quot; and is wholly tautological and th=
us irrelevant. If you want your proposal to gain traction, you need a very =
clear and unambiguous motivating part to it. As things stand now, the bold =
text in your proposal is SIMPLY NOT what you really want to address with yo=
ur proposal, because those things are addressable with existing C++ means, =
however &quot;C-like&quot; they might seem to you. This confused message is=
 very likely the reason you are getting largely negative feedback here.</di=
v><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">At the he=
art of your proposal, what you really want is the freedom as in pure C to u=
se essentially forward-declared structures combined with the C++-like metho=
d calls, except that the methods in your proposal are never virtual. If you=
r methods are never virtual, there is no functional difference whatsoever w=
ith using non-member functions (&quot;C-like&quot; in your terminology). Th=
e difference is purely syntactical, so your proposal is essentially about m=
aking your preferred function call syntax easier to use in a particular cas=
e.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Is =
that an unreasonable thing to ask for? Not really. Is it so important that =
it will grab the full attention of the C++ committee? This is an interestin=
g question, because the syntactical differences in function call syntax are=
 a pretty hot topic for the C++ committee [1], with some decisions already =
made [2].</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te">Cheers,<br></div><div class=3D"gmail_quote">V.</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote"><div class=3D"gmail_quote">[1]=
 <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.p=
df" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg2=
1%2Fdocs%2Fpapers%2F2015%2Fn4474.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNHFi=
gxJItStW1U7PDXJ6n-EiK3h_A&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fw=
g21%2Fdocs%2Fpapers%2F2015%2Fn4474.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
FigxJItStW1U7PDXJ6n-EiK3h_A&#39;;return true;">http://www.open-std.org/jtc1=
/<wbr>sc22/wg21/docs/papers/2015/<wbr>n4474.pdf</a></div><div class=3D"gmai=
l_quote"><br></div><div class=3D"gmail_quote">[2] <a href=3D"https://isocpp=
..org/blog/2015/11/kona-standards-meeting-trip-report" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\=
75https%3A%2F%2Fisocpp.org%2Fblog%2F2015%2F11%2Fkona-standards-meeting-trip=
-report\46sa\75D\46sntz\0751\46usg\75AFQjCNEqYLuQO11BCv_AYTNRcsyrE0KXnQ&#39=
;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75=
https%3A%2F%2Fisocpp.org%2Fblog%2F2015%2F11%2Fkona-standards-meeting-trip-r=
eport\46sa\75D\46sntz\0751\46usg\75AFQjCNEqYLuQO11BCv_AYTNRcsyrE0KXnQ&#39;;=
return true;">https://isocpp.org/blog/2015/<wbr>11/kona-standards-meeting-<=
wbr>trip-report</a></div><div><br></div></div></div></div>
</blockquote></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/702cd644-9973-4418-8374-0e815461720a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/702cd644-9973-4418-8374-0e815461720a=
%40isocpp.org</a>.<br />

------=_Part_540_24197826.1456769593609--
------=_Part_539_781984494.1456769593608--

.

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

On Mon, Feb 29, 2016 at 6:47 PM, <daniele.bordes@gmail.com> wrote:

> The alternative to member function calls is using static methods of a
friend class and a procedural programming style; in my opinion, this is not
a mere syntactic question because:

I do not think you understood what I wrote.

Your concrete types (no virtual members) are representable by plain C
structures and plain C functions. Your desire to make the private parts of
your concrete parts invisible to the compiler is trivially achieved in
plain C by omitting the full definition of the structure in the interface
file.

The only thing not achieved by the above is the method call syntax.

>This is the opinion of Stroustroup about friend:

That opinion is decades old. Many things have changed since then. Here is
his opinion is a recent relevant document [1]:

The perceived *benefits* [2] are

[...]

   - *Decreased coupling / better encapsulation*: a class implementer does
   not have to place every function manipulating and object into the class.
   Only the minimal set of functions needing access to the object
   representation needs to be members. This simplifies comprehension and
   maintenance.


(end quote)

Cheers,
V.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf

[2] My emphasis.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0wQ5Fc0MLP0no6tPip%2BpexrQvtsb0%2BUS_tRfFJ%2B9DQDg%40mail.gmail.com.

--001a113d38ceee6755052ced25a9
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 M=
on, Feb 29, 2016 at 6:47 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:danie=
le.bordes@gmail.com" target=3D"_blank">daniele.bordes@gmail.com</a>&gt;</sp=
an> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote"><div>&gt; The alternative to member function calls is using static met=
hods of a friend class and a procedural programming style; in my opinion, t=
his is not a mere syntactic question because:</div><div><br></div><div>I do=
 not think you understood what I wrote.<br></div><div><br></div><div>Your c=
oncrete types (no virtual members) are representable by plain C structures =
and plain C functions. Your desire to make the private parts of your concre=
te parts invisible to the compiler is trivially achieved in plain C by omit=
ting the full definition of the structure in the interface file.</div><div>=
<br></div><div>The only thing not achieved by the above is the method call =
syntax.</div><div><br></div><div>&gt;This is the opinion of Stroustroup abo=
ut friend:</div><div><br></div><div>That opinion is decades old. Many thing=
s have changed since then. Here is his opinion is a recent relevant documen=
t [1]:</div><div><br></div><div>The perceived <i><u><b>benefits</b></u></i>=
=C2=A0[2] are</div><div><br></div><div>[...]=C2=A0</div><div><ul><li><i>Dec=
reased coupling / better encapsulation</i>: a class implementer does not ha=
ve to place every
function manipulating and object into the class. Only the minimal set of fu=
nctions needing
access to the object representation needs to be members. This simplifies co=
mprehension and
maintenance.<br></li></ul></div><div><br></div><div>(end quote)</div><div><=
br></div><div>Cheers,</div><div>V.</div><div><br></div><div>[1]=C2=A0<a hre=
f=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf">h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf</a></div=
><div><br></div><div>[2] My emphasis.</div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0wQ5Fc0MLP0no6tPip%2BpexrQvtsb=
0%2BUS_tRfFJ%2B9DQDg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0wQ5=
Fc0MLP0no6tPip%2BpexrQvtsb0%2BUS_tRfFJ%2B9DQDg%40mail.gmail.com</a>.<br />

--001a113d38ceee6755052ced25a9--

.

------=_Part_3787_1155404764.1456773575789
Content-Type: multipart/alternative;
 boundary="----=_Part_3788_416809440.1456773575790"

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

No, I perfectly understood, but I just think the argumentation is weak: for=
=20
the same reason, the class construct itself with private and public parts=
=20
would be also useless.
And well, everything is representable in plain C somehow.
Polymorphism through type-fields or pointer to functions, generic=20
programming through macros and/or pointers to void and so on.
One could also program in Assembler, it is also possible to express somehow=
=20
the same things as in C and in C++.
So, with your argumentation, why spend a lot of effort to create languages=
=20
like C and C++?


Il giorno luned=C3=AC 29 febbraio 2016 19:52:20 UTC+1, Viacheslav Usov ha=
=20
scritto:
>
> On Mon, Feb 29, 2016 at 6:47 PM, <daniele...@gmail.com <javascript:>>=20
> wrote:
>
> > The alternative to member function calls is using static methods of a=
=20
> friend class and a procedural programming style; in my opinion, this is n=
ot=20
> a mere syntactic question because:
>
> I do not think you understood what I wrote.
>
> Your concrete types (no virtual members) are representable by plain C=20
> structures and plain C functions. Your desire to make the private parts o=
f=20
> your concrete parts invisible to the compiler is trivially achieved in=20
> plain C by omitting the full definition of the structure in the interface=
=20
> file.
>
> The only thing not achieved by the above is the method call syntax.
>
> >This is the opinion of Stroustroup about friend:
>
> That opinion is decades old. Many things have changed since then. Here is=
=20
> his opinion is a recent relevant document [1]:
>
> The perceived *benefits* [2] are
>
> [...]=20
>
>    - *Decreased coupling / better encapsulation*: a class implementer=20
>    does not have to place every function manipulating and object into the=
=20
>    class. Only the minimal set of functions needing access to the object=
=20
>    representation needs to be members. This simplifies comprehension and=
=20
>    maintenance.
>   =20
>
> (end quote)
>
> Cheers,
> V.
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf
>
> [2] My emphasis.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b0d88ef5-6c38-4aa5-8ec4-db7c12c5ddf8%40isocpp.or=
g.

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

<div dir=3D"ltr">No, I perfectly understood, but I just think the argumenta=
tion is weak: for the same reason, the class construct itself with private =
and public parts would be also useless.<div>And well, everything is=C2=A0re=
presentable=C2=A0in plain C somehow.<br></div><div><div>Polymorphism throug=
h type-fields or pointer to functions, generic programming through macros a=
nd/or pointers to void and so on.<br><div>One could also program in Assembl=
er, it is also possible to express somehow the same things as in C and in C=
++.</div><div>So, with your argumentation, why spend a lot of effort to cre=
ate languages like C and C++?<br><br></div><div><br>Il giorno luned=C3=AC 2=
9 febbraio 2016 19:52:20 UTC+1, Viacheslav Usov ha scritto:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e">On Mon, Feb 29, 2016 at 6:47 PM,  <span dir=3D"ltr">&lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fllmd4jjAwAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;javascript:&#39;;return true;">daniele...@gmail.com<=
/a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote"><div>&gt; The alternative to member function calls is usin=
g static methods of a friend class and a procedural programming style; in m=
y opinion, this is not a mere syntactic question because:</div><div><br></d=
iv><div>I do not think you understood what I wrote.<br></div><div><br></div=
><div>Your concrete types (no virtual members) are representable by plain C=
 structures and plain C functions. Your desire to make the private parts of=
 your concrete parts invisible to the compiler is trivially achieved in pla=
in C by omitting the full definition of the structure in the interface file=
..</div><div><br></div><div>The only thing not achieved by the above is the =
method call syntax.</div><div><br></div><div>&gt;This is the opinion of Str=
oustroup about friend:</div><div><br></div><div>That opinion is decades old=
.. Many things have changed since then. Here is his opinion is a recent rele=
vant document [1]:</div><div><br></div><div>The perceived <i><u><b>benefits=
</b></u></i>=C2=A0[2] are</div><div><br></div><div>[...]=C2=A0</div><div><u=
l><li><i>Decreased coupling / better encapsulation</i>: a class implementer=
 does not have to place every
function manipulating and object into the class. Only the minimal set of fu=
nctions needing
access to the object representation needs to be members. This simplifies co=
mprehension and
maintenance.<br></li></ul></div><div><br></div><div>(end quote)</div><div><=
br></div><div>Cheers,</div><div>V.</div><div><br></div><div>[1]=C2=A0<a hre=
f=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://ww=
w.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2015%2Fp0131r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFgArzP=
PqWPRJyeFIsqQqR6veJ1Ew&#39;;return true;" onclick=3D"this.href=3D&#39;http:=
//www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2015%2Fp0131r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFg=
ArzPPqWPRJyeFIsqQqR6veJ1Ew&#39;;return true;">http://www.open-std.org/<wbr>=
jtc1/sc22/wg21/docs/papers/<wbr>2015/p0131r0.pdf</a></div><div><br></div><d=
iv>[2] My emphasis.</div></div></div></div>
</blockquote></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b0d88ef5-6c38-4aa5-8ec4-db7c12c5ddf8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0d88ef5-6c38-4aa5-8ec4-db7c12c5ddf8=
%40isocpp.org</a>.<br />

------=_Part_3788_416809440.1456773575790--
------=_Part_3787_1155404764.1456773575789--

.

------=_Part_573_2000711503.1456773727752
Content-Type: multipart/alternative;
 boundary="----=_Part_574_1126329939.1456773727752"

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

Thank you for the link.
By the way, there is no "friend" word at all in it.

Il giorno luned=C3=AC 29 febbraio 2016 19:52:20 UTC+1, Viacheslav Usov ha=
=20
scritto:
>
> On Mon, Feb 29, 2016 at 6:47 PM, <daniele...@gmail.com <javascript:>>=20
> wrote:
>
> > The alternative to member function calls is using static methods of a=
=20
> friend class and a procedural programming style; in my opinion, this is n=
ot=20
> a mere syntactic question because:
>
> I do not think you understood what I wrote.
>
> Your concrete types (no virtual members) are representable by plain C=20
> structures and plain C functions. Your desire to make the private parts o=
f=20
> your concrete parts invisible to the compiler is trivially achieved in=20
> plain C by omitting the full definition of the structure in the interface=
=20
> file.
>
> The only thing not achieved by the above is the method call syntax.
>
> >This is the opinion of Stroustroup about friend:
>
> That opinion is decades old. Many things have changed since then. Here is=
=20
> his opinion is a recent relevant document [1]:
>
> The perceived *benefits* [2] are
>
> [...]=20
>
>    - *Decreased coupling / better encapsulation*: a class implementer=20
>    does not have to place every function manipulating and object into the=
=20
>    class. Only the minimal set of functions needing access to the object=
=20
>    representation needs to be members. This simplifies comprehension and=
=20
>    maintenance.
>   =20
>
> (end quote)
>
> Cheers,
> V.
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf
>
> [2] My emphasis.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ada1b5e1-2b14-4d06-8855-0172d85ad6ba%40isocpp.or=
g.

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

<div dir=3D"ltr">Thank you for the link.<div>By the way, there is no &quot;=
friend&quot; word at all in it.<br><br>Il giorno luned=C3=AC 29 febbraio 20=
16 19:52:20 UTC+1, Viacheslav Usov ha scritto:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Mon, Fe=
b 29, 2016 at 6:47 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"fllmd4jjAwAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">daniele...@gmail.com</a>&gt;</span=
> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quot=
e"><div>&gt; The alternative to member function calls is using static metho=
ds of a friend class and a procedural programming style; in my opinion, thi=
s is not a mere syntactic question because:</div><div><br></div><div>I do n=
ot think you understood what I wrote.<br></div><div><br></div><div>Your con=
crete types (no virtual members) are representable by plain C structures an=
d plain C functions. Your desire to make the private parts of your concrete=
 parts invisible to the compiler is trivially achieved in plain C by omitti=
ng the full definition of the structure in the interface file.</div><div><b=
r></div><div>The only thing not achieved by the above is the method call sy=
ntax.</div><div><br></div><div>&gt;This is the opinion of Stroustroup about=
 friend:</div><div><br></div><div>That opinion is decades old. Many things =
have changed since then. Here is his opinion is a recent relevant document =
[1]:</div><div><br></div><div>The perceived <i><u><b>benefits</b></u></i>=
=C2=A0[2] are</div><div><br></div><div>[...]=C2=A0</div><div><ul><li><i>Dec=
reased coupling / better encapsulation</i>: a class implementer does not ha=
ve to place every
function manipulating and object into the class. Only the minimal set of fu=
nctions needing
access to the object representation needs to be members. This simplifies co=
mprehension and
maintenance.<br></li></ul></div><div><br></div><div>(end quote)</div><div><=
br></div><div>Cheers,</div><div>V.</div><div><br></div><div>[1]=C2=A0<a hre=
f=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://ww=
w.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2015%2Fp0131r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFgArzP=
PqWPRJyeFIsqQqR6veJ1Ew&#39;;return true;" onclick=3D"this.href=3D&#39;http:=
//www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2015%2Fp0131r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFg=
ArzPPqWPRJyeFIsqQqR6veJ1Ew&#39;;return true;">http://www.open-std.org/<wbr>=
jtc1/sc22/wg21/docs/papers/<wbr>2015/p0131r0.pdf</a></div><div><br></div><d=
iv>[2] My emphasis.</div></div></div></div>
</blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ada1b5e1-2b14-4d06-8855-0172d85ad6ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ada1b5e1-2b14-4d06-8855-0172d85ad6ba=
%40isocpp.org</a>.<br />

------=_Part_574_1126329939.1456773727752--
------=_Part_573_2000711503.1456773727752--

.

------=_Part_3754_1790156586.1456774252049
Content-Type: multipart/alternative;
 boundary="----=_Part_3755_1880700368.1456774252049"

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

"The only thing not achieved by the above is the method call syntax."

No. In the above C-like method all data members of the struct (declared=20
somewhere alse) are public. Every other methods have access to the data=20
members of the struct.
My proposal keeps encapsulation, not only the call syntax.

Il giorno luned=C3=AC 29 febbraio 2016 19:52:20 UTC+1, Viacheslav Usov ha=
=20
scritto:
>
> On Mon, Feb 29, 2016 at 6:47 PM, <daniele...@gmail.com <javascript:>>=20
> wrote:
>
> > The alternative to member function calls is using static methods of a=
=20
> friend class and a procedural programming style; in my opinion, this is n=
ot=20
> a mere syntactic question because:
>
> I do not think you understood what I wrote.
>
> Your concrete types (no virtual members) are representable by plain C=20
> structures and plain C functions. Your desire to make the private parts o=
f=20
> your concrete parts invisible to the compiler is trivially achieved in=20
> plain C by omitting the full definition of the structure in the interface=
=20
> file.
>
> The only thing not achieved by the above is the method call syntax.
>
> >This is the opinion of Stroustroup about friend:
>
> That opinion is decades old. Many things have changed since then. Here is=
=20
> his opinion is a recent relevant document [1]:
>
> The perceived *benefits* [2] are
>
> [...]=20
>
>    - *Decreased coupling / better encapsulation*: a class implementer=20
>    does not have to place every function manipulating and object into the=
=20
>    class. Only the minimal set of functions needing access to the object=
=20
>    representation needs to be members. This simplifies comprehension and=
=20
>    maintenance.
>   =20
>
> (end quote)
>
> Cheers,
> V.
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf
>
> [2] My emphasis.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7b8d4b4b-2d2f-4dcf-87a6-daac5b94499d%40isocpp.or=
g.

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

<div dir=3D"ltr">&quot;The only thing not achieved by the above is the meth=
od call syntax.&quot;<div><br></div><div>No. In the above C-like method all=
 data members of the struct (declared somewhere alse) are public. Every oth=
er methods have access to the data members of the struct.</div><div>My prop=
osal keeps encapsulation, not only the call syntax.<br><br>Il giorno luned=
=C3=AC 29 febbraio 2016 19:52:20 UTC+1, Viacheslav Usov ha scritto:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote">On Mon, Feb 29, 2016 at 6:47 PM,  <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fllmd4jjAwAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">daniele...@g=
mail.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote"><div>&gt; The alternative to member function calls=
 is using static methods of a friend class and a procedural programming sty=
le; in my opinion, this is not a mere syntactic question because:</div><div=
><br></div><div>I do not think you understood what I wrote.<br></div><div><=
br></div><div>Your concrete types (no virtual members) are representable by=
 plain C structures and plain C functions. Your desire to make the private =
parts of your concrete parts invisible to the compiler is trivially achieve=
d in plain C by omitting the full definition of the structure in the interf=
ace file.</div><div><br></div><div>The only thing not achieved by the above=
 is the method call syntax.</div><div><br></div><div>&gt;This is the opinio=
n of Stroustroup about friend:</div><div><br></div><div>That opinion is dec=
ades old. Many things have changed since then. Here is his opinion is a rec=
ent relevant document [1]:</div><div><br></div><div>The perceived <i><u><b>=
benefits</b></u></i>=C2=A0[2] are</div><div><br></div><div>[...]=C2=A0</div=
><div><ul><li><i>Decreased coupling / better encapsulation</i>: a class imp=
lementer does not have to place every
function manipulating and object into the class. Only the minimal set of fu=
nctions needing
access to the object representation needs to be members. This simplifies co=
mprehension and
maintenance.<br></li></ul></div><div><br></div><div>(end quote)</div><div><=
br></div><div>Cheers,</div><div>V.</div><div><br></div><div>[1]=C2=A0<a hre=
f=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://ww=
w.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2015%2Fp0131r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFgArzP=
PqWPRJyeFIsqQqR6veJ1Ew&#39;;return true;" onclick=3D"this.href=3D&#39;http:=
//www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2015%2Fp0131r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFg=
ArzPPqWPRJyeFIsqQqR6veJ1Ew&#39;;return true;">http://www.open-std.org/<wbr>=
jtc1/sc22/wg21/docs/papers/<wbr>2015/p0131r0.pdf</a></div><div><br></div><d=
iv>[2] My emphasis.</div></div></div></div>
</blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7b8d4b4b-2d2f-4dcf-87a6-daac5b94499d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b8d4b4b-2d2f-4dcf-87a6-daac5b94499d=
%40isocpp.org</a>.<br />

------=_Part_3755_1880700368.1456774252049--
------=_Part_3754_1790156586.1456774252049--

.

------=_Part_3869_2138970026.1456784799620
Content-Type: multipart/alternative;
 boundary="----=_Part_3870_969502041.1456784799621"

------=_Part_3870_969502041.1456784799621
Content-Type: text/plain; charset=UTF-8

Please do not comment here anymore.
The proposal has been refined at this link:

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/VThp-UMck7k

The following paragraphs has been added:

- abstract
- interaction with other proposals
- compile-time improvement
- compiler issue and miscellanea
- eventual syntax simplification

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/839c2469-51d9-4e13-97c6-6d377c5bc34c%40isocpp.org.

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

<div dir=3D"ltr"><div>Please do not comment here anymore.</div><div>The pro=
posal has been refined at this link:</div><div><br></div><div>https://group=
s.google.com/a/isocpp.org/forum/#!topic/std-proposals/VThp-UMck7k</div><div=
><br></div><div>The following paragraphs has been added:</div><div><br></di=
v><div>- abstract</div><div>- interaction with other proposals</div><div>- =
compile-time improvement</div><div>- compiler issue and miscellanea</div><d=
iv>- eventual syntax simplification</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/839c2469-51d9-4e13-97c6-6d377c5bc34c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/839c2469-51d9-4e13-97c6-6d377c5bc34c=
%40isocpp.org</a>.<br />

------=_Part_3870_969502041.1456784799621--
------=_Part_3869_2138970026.1456784799620--

.

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

On Mon, Feb 29, 2016 at 8:30 PM, <daniele.bordes@gmail.com> wrote:

> "The only thing not achieved by the above is the method call syntax."
>
> No. In the above C-like method all data members of the struct (declared
> somewhere alse) are public.
>

"Declared somewhere else" means "not declared for interface users", which
makes its entire content private. A forward-only plain C structure
declaration has a lot more privacy than a C++ class with private parts; you
know this, because this is what you want to achieve with your proposal.

> Every other methods have access to the data members of the struct. My
proposal keeps encapsulation, not only the call syntax.

As stated above, a forward-only structure declaration is a lot more
encapsulation than a full C++ class definition with private parts. It is
still more encapsulation than your proposal. You were given a link to a
document by Stroustrup, whose opinion seems so important for you, which
stated quite plainly that *not placing* functions in a class achieves *better
encapsulation*.

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg33-bsQU6rW%3DW%2Bv3hEemF-0hYny6Pv7jfwFMHjHSPDqow%40mail.gmail.com.

--047d7b6725dc80fcc4052cf977db
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 M=
on, Feb 29, 2016 at 8:30 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:danie=
le.bordes@gmail.com" target=3D"_blank">daniele.bordes@gmail.com</a>&gt;</sp=
an> 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 dir=3D"ltr">&quot;The only thing not ac=
hieved by the above is the method call syntax.&quot;<div><br></div><div>No.=
 In the above C-like method all data members of the struct (declared somewh=
ere alse) are public.</div></div></blockquote><div><br></div><div>&quot;Dec=
lared somewhere else&quot; means &quot;not declared for interface users&quo=
t;, which makes its entire content private. A forward-only=C2=A0plain C str=
ucture declaration has a lot more privacy than a C++ class with private par=
ts; you know this, because this is what you want to achieve with your propo=
sal.</div><div><br></div><div>&gt; Every other methods have access to the d=
ata members of the struct. My proposal keeps encapsulation, not only the ca=
ll syntax.</div><div><br></div><div>As stated above, a forward-only structu=
re declaration is a lot more encapsulation than a full C++ class definition=
 with private parts. It is still more encapsulation than your proposal. You=
 were given a link to a document by Stroustrup, whose opinion seems so impo=
rtant for you, which stated quite plainly that <i>not placing</i>=C2=A0func=
tions in a class achieves <i>better encapsulation</i>.<br></div><div><br></=
div><div>Cheers,</div><div>V.</div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg33-bsQU6rW%3DW%2Bv3hEemF-0hYny=
6Pv7jfwFMHjHSPDqow%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg33-bsQ=
U6rW%3DW%2Bv3hEemF-0hYny6Pv7jfwFMHjHSPDqow%40mail.gmail.com</a>.<br />

--047d7b6725dc80fcc4052cf977db--

.

------=_Part_4256_1558937357.1456827531643
Content-Type: multipart/alternative;
 boundary="----=_Part_4257_1472370525.1456827531643"

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

Please do not comment here anymore.
The proposal has been refined at this link:

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/VThp-UMc=
k7k


Il giorno marted=C3=AC 1 marzo 2016 10:34:08 UTC+1, Viacheslav Usov ha scri=
tto:
>
> On Mon, Feb 29, 2016 at 8:30 PM, <daniele...@gmail.com <javascript:>>=20
> wrote:
>
>> "The only thing not achieved by the above is the method call syntax."
>>
>> No. In the above C-like method all data members of the struct (declared=
=20
>> somewhere alse) are public.
>>
>
> "Declared somewhere else" means "not declared for interface users", which=
=20
> makes its entire content private. A forward-only plain C structure=20
> declaration has a lot more privacy than a C++ class with private parts; y=
ou=20
> know this, because this is what you want to achieve with your proposal.
>
> > Every other methods have access to the data members of the struct. My=
=20
> proposal keeps encapsulation, not only the call syntax.
>
> As stated above, a forward-only structure declaration is a lot more=20
> encapsulation than a full C++ class definition with private parts. It is=
=20
> still more encapsulation than your proposal. You were given a link to a=
=20
> document by Stroustrup, whose opinion seems so important for you, which=
=20
> stated quite plainly that *not placing* functions in a class achieves *be=
tter=20
> encapsulation*.
>
> Cheers,
> V.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f3cf4449-075f-48b0-a4b9-f89519765374%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>Please do not comment here anymore.</div><div>The pro=
posal has been refined at this link:</div><div><br></div><div><a href=3D"ht=
tps://groups.google.com/a/isocpp.org/forum/#%21topic/std-proposals/VThp-UMc=
k7k" target=3D"_blank" rel=3D"nofollow">https://groups.google.com/a/<wbr>is=
ocpp.org/forum/#!topic/std-<wbr>proposals/VThp-UMck7k</a></div><br><br>Il g=
iorno marted=C3=AC 1 marzo 2016 10:34:08 UTC+1, Viacheslav Usov ha scritto:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote">On Mon, Feb 29, 2016 at 8:30 PM,  <span dir=3D"ltr">&lt;=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"jfUeL6cT=
BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">danie=
le...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">=
&quot;The only thing not achieved by the above is the method call syntax.&q=
uot;<div><br></div><div>No. In the above C-like method all data members of =
the struct (declared somewhere alse) are public.</div></div></blockquote><d=
iv><br></div><div>&quot;Declared somewhere else&quot; means &quot;not decla=
red for interface users&quot;, which makes its entire content private. A fo=
rward-only=C2=A0plain C structure declaration has a lot more privacy than a=
 C++ class with private parts; you know this, because this is what you want=
 to achieve with your proposal.</div><div><br></div><div>&gt; Every other m=
ethods have access to the data members of the struct. My proposal keeps enc=
apsulation, not only the call syntax.</div><div><br></div><div>As stated ab=
ove, a forward-only structure declaration is a lot more encapsulation than =
a full C++ class definition with private parts. It is still more encapsulat=
ion than your proposal. You were given a link to a document by Stroustrup, =
whose opinion seems so important for you, which stated quite plainly that <=
i>not placing</i>=C2=A0functions in a class achieves <i>better encapsulatio=
n</i>.<br></div><div><br></div><div>Cheers,</div><div>V.</div></div></div><=
/div>
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f3cf4449-075f-48b0-a4b9-f89519765374%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f3cf4449-075f-48b0-a4b9-f89519765374=
%40isocpp.org</a>.<br />

------=_Part_4257_1472370525.1456827531643--
------=_Part_4256_1558937357.1456827531643--

.

2016-03-01 11:18 GMT+01:00  <daniele.bordes@gmail.com>:
> Please do not comment here anymore.

One of the main objectives of this forum is to discuss proposals that
are presented here. And the Standard ISO C++ page,

https://isocpp.org/std/submit-a-proposal

strongly recommends potential authors of proposals to float their
ideas in public to get early feedback from such readers of this forum.

I think it is important to welcome constructive criticism.

- Daniel

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGNvRgAU43Tbf0h9046E_utMRuR2CimPV9CquSGowan5SBSZaA%40mail.gmail.com.

.

------=_Part_5063_2037086233.1456844348128
Content-Type: multipart/alternative;
 boundary="----=_Part_5064_578328731.1456844348129"

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



On Tuesday, March 1, 2016 at 5:40:04 AM UTC-5, Daniel Kr=C3=BCgler wrote:
>
> 2016-03-01 11:18 GMT+01:00  <daniele...@gmail.com <javascript:>>:=20
> > Please do not comment here anymore.=20
>
> One of the main objectives of this forum is to discuss proposals that=20
> are presented here. And the Standard ISO C++ page,=20
>
> https://isocpp.org/std/submit-a-proposal=20
>
> strongly recommends potential authors of proposals to float their=20
> ideas in public to get early feedback from such readers of this forum.=20
>
> I think it is important to welcome constructive criticism.
>

He is. He's just saying that he started a new thread, so he'd rather the=20
discussion continue there.

I have no idea why he felt that he needed to start a new thread just for an=
=20
update to the proposal.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a32ded6e-d556-4c6b-9a3a-d995bc77c83c%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Tuesday, March 1, 2016 at 5:40:04 AM UTC-5, Dan=
iel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-03=
-01 11:18 GMT+01:00 =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"43bUZ0AXBAAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">daniele...@gmail.com</a>&gt;:
<br>&gt; Please do not comment here anymore.
<br>
<br>One of the main objectives of this forum is to discuss proposals that
<br>are presented here. And the Standard ISO C++ page,
<br>
<br><a href=3D"https://isocpp.org/std/submit-a-proposal" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url=
?q\75https%3A%2F%2Fisocpp.org%2Fstd%2Fsubmit-a-proposal\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGlLyCIYYQUZNTTJdUEpCYxvwG8Ig&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fisocpp.org%2F=
std%2Fsubmit-a-proposal\46sa\75D\46sntz\0751\46usg\75AFQjCNGlLyCIYYQUZNTTJd=
UEpCYxvwG8Ig&#39;;return true;">https://isocpp.org/std/submit-<wbr>a-propos=
al</a>
<br>
<br>strongly recommends potential authors of proposals to float their
<br>ideas in public to get early feedback from such readers of this forum.
<br>
<br>I think it is important to welcome constructive criticism.<br></blockqu=
ote><div><br>He is. He&#39;s just saying that he started a new thread, so h=
e&#39;d rather the discussion continue there.<br><br>I have no idea why he =
felt that he needed to start a new thread just for an update to the proposa=
l.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a32ded6e-d556-4c6b-9a3a-d995bc77c83c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a32ded6e-d556-4c6b-9a3a-d995bc77c83c=
%40isocpp.org</a>.<br />

------=_Part_5064_578328731.1456844348129--
------=_Part_5063_2037086233.1456844348128--

.

2016-03-01 15:59 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
>
>
> On Tuesday, March 1, 2016 at 5:40:04 AM UTC-5, Daniel Kr=C3=BCgler wrote:
>>
>> 2016-03-01 11:18 GMT+01:00  <daniele...@gmail.com>:
>> > Please do not comment here anymore.
>>
>> One of the main objectives of this forum is to discuss proposals that
>> are presented here. And the Standard ISO C++ page,
>>
>> https://isocpp.org/std/submit-a-proposal
>>
>> strongly recommends potential authors of proposals to float their
>> ideas in public to get early feedback from such readers of this forum.
>>
>> I think it is important to welcome constructive criticism.
>
> He is. He's just saying that he started a new thread, so he'd rather the
> discussion continue there.

Indeed, I got informed about that by himself (it might have been
better, if that had been a public response).

- Daniel

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGNvRgCTkkJ7B-KUprp2dyTu1qA0hXaU1arUtB48OAX82QF=
u2g%40mail.gmail.com.

.

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

This is what is described in the process:
"Update the draft proposal with a new revision to incorporate the feedback =
you=E2=80=99ve received, and post a new link."
=20
I thought "post a new link" means create another thread, otherwise understa=
nd which revision is referred by the comments is a mess.

The process sounds so "fuzzy" here....


Il giorno marted=C3=AC 1 marzo 2016 15:59:08 UTC+1, Nicol Bolas ha scritto:
> On Tuesday, March 1, 2016 at 5:40:04 AM UTC-5, Daniel Kr=C3=BCgler wrote:=
2016-03-01 11:18 GMT+01:00 =C2=A0<daniele...@gmail.com>:
>=20
> > Please do not comment here anymore.
>=20
>=20
>=20
> One of the main objectives of this forum is to discuss proposals that
>=20
> are presented here. And the Standard ISO C++ page,
>=20
>=20
>=20
> https://isocpp.org/std/submit-a-proposal
>=20
>=20
>=20
> strongly recommends potential authors of proposals to float their
>=20
> ideas in public to get early feedback from such readers of this forum.
>=20
>=20
>=20
> I think it is important to welcome constructive criticism.
>=20
>=20
> He is. He's just saying that he started a new thread, so he'd rather the =
discussion continue there.
>=20
> I have no idea why he felt that he needed to start a new thread just for =
an update to the proposal.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3b8f4d7a-5074-482f-8bfb-223705e5371b%40isocpp.or=
g.

------=_Part_3627_1251598767.1456896105476--

.

2016-03-02 6:21 GMT+01:00  <daniele.bordes@gmail.com>:
> This is what is described in the process:
> "Update the draft proposal with a new revision to incorporate the feedbac=
k you=E2=80=99ve received, and post a new link."
>
> I thought "post a new link" means create another thread, otherwise unders=
tand which revision is referred by the comments is a mess.
>
> The process sounds so "fuzzy" here....

I agree that the description is somewhat confusing, but the only thing
what is suggested here informally is make iterations of your still
drafting document based on the input you receive. The is no intention
behind that to require *how* you do that. Some people use a public
repository to generate new versions and just inform people about
changes of the document still available at the same (or another,
depending how you prefer that) external link, some others do just send
attachments. This part is only a recommendation - but a useful one! -
from the committees point of view.

At some point of these iterations the author should decide whether
he/she believes that the document is ripe to submit or not. Assuming
the decision was positive and when you notices that a new mailing
deadline is published on http://www.open-std.org/jtc1/sc22/wg21/, you
should contact the lwgchair address requesting to submit your
proposal. I'm recommending to that at least some days before that
deadline, because you presumably will get further guidance regarding
more fine-grained formal requirements and because this is basically a
two-step mechanism: The first step is the allocation of the document
number and the second one is you final submit including that number.

If you have any further questions, please contact the lwgchair address.

Thanks,

- Daniel

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGNvRgBhgEKTB6QdtE57j4MqXLGOCNi86zP2uT7h%2BoSoC=
qpn8A%40mail.gmail.com.

.

------=_Part_6287_1375222723.1456926468292
Content-Type: multipart/alternative;
 boundary="----=_Part_6288_1221360551.1456926468292"

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



On Wednesday, March 2, 2016 at 1:24:08 AM UTC-5, Daniel Kr=C3=BCgler wrote:
>
> 2016-03-02 6:21 GMT+01:00  <daniele...@gmail.com <javascript:>>:=20
> > This is what is described in the process:=20
> > "Update the draft proposal with a new revision to incorporate the=20
> feedback you=E2=80=99ve received, and post a new link."=20
> >=20
> > I thought "post a new link" means create another thread, otherwise=20
> understand which revision is referred by the comments is a mess.=20
> >=20
> > The process sounds so "fuzzy" here....=20
>
> I agree that the description is somewhat confusing, but the only thing=20
> what is suggested here informally is make iterations of your still=20
> drafting document based on the input you receive. The is no intention=20
> behind that to require *how* you do that. Some people use a public=20
> repository to generate new versions and just inform people about=20
> changes of the document still available at the same (or another,=20
> depending how you prefer that) external link, some others do just send=20
> attachments. This part is only a recommendation - but a useful one! -=20
> from the committees point of view.=20
>
> At some point of these iterations the author should decide whether=20
> he/she believes that the document is ripe to submit or not. Assuming=20
> the decision was positive and when you notices that a new mailing=20
> deadline is published on http://www.open-std.org/jtc1/sc22/wg21/, you=20
> should contact the lwgchair address requesting to submit your=20
> proposal.


As a language feature, should it not go to the EWG chair?

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0bf0832e-0f00-404f-8298-8d7a86484106%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Wednesday, March 2, 2016 at 1:24:08 AM UTC-5, D=
aniel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-=
03-02 6:21 GMT+01:00 =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"qz4XVN1XBAAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;">daniele...@gmail.com</a>&gt;:
<br>&gt; This is what is described in the process:
<br>&gt; &quot;Update the draft proposal with a new revision to incorporate=
 the feedback you=E2=80=99ve received, and post a new link.&quot;
<br>&gt;
<br>&gt; I thought &quot;post a new link&quot; means create another thread,=
 otherwise understand which revision is referred by the comments is a mess.
<br>&gt;
<br>&gt; The process sounds so &quot;fuzzy&quot; here....
<br>
<br>I agree that the description is somewhat confusing, but the only thing
<br>what is suggested here informally is make iterations of your still
<br>drafting document based on the input you receive. The is no intention
<br>behind that to require *how* you do that. Some people use a public
<br>repository to generate new versions and just inform people about
<br>changes of the document still available at the same (or another,
<br>depending how you prefer that) external link, some others do just send
<br>attachments. This part is only a recommendation - but a useful one! -
<br>from the committees point of view.
<br>
<br>At some point of these iterations the author should decide whether
<br>he/she believes that the document is ripe to submit or not. Assuming
<br>the decision was positive and when you notices that a new mailing
<br>deadline is published on <a href=3D"http://www.open-std.org/jtc1/sc22/w=
g21/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fw=
g21%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEDzTC8Ry9aTHT3x4t5uwkCZP6E8A&#39;=
;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75ht=
tp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2F\46sa\75D\46sntz\0751\46=
usg\75AFQjCNEDzTC8Ry9aTHT3x4t5uwkCZP6E8A&#39;;return true;">http://www.open=
-std.org/jtc1/<wbr>sc22/wg21/</a>, you
<br>should contact the lwgchair address requesting to submit your
<br>proposal.</blockquote><div><br>As a language feature, should it not go =
to the EWG chair?</div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0bf0832e-0f00-404f-8298-8d7a86484106%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0bf0832e-0f00-404f-8298-8d7a86484106=
%40isocpp.org</a>.<br />

------=_Part_6288_1221360551.1456926468292--
------=_Part_6287_1375222723.1456926468292--

.

2016-03-02 14:47 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
>> At some point of these iterations the author should decide whether
>> he/she believes that the document is ripe to submit or not. Assuming
>> the decision was positive and when you notices that a new mailing
>> deadline is published on http://www.open-std.org/jtc1/sc22/wg21/, you
>> should contact the lwgchair address requesting to submit your
>> proposal.
>
> As a language feature, should it not go to the EWG chair?

This might work, you have to contact the EWG chair for this. Currently
the lwgchair address collects all proposals.

I will request a clarification of this and some other details after
the Jacksonville meeting.

Thanks,

- Daniel

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGNvRgCvXAEhxT5FNzQsSgEm7AE%2B3DNqd9B333DPqHWjrSJVBg%40mail.gmail.com.

.

------=_Part_385_1670790494.1457301473928
Content-Type: multipart/alternative;
 boundary="----=_Part_386_1980555508.1457301473928"

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

I am costantly looking here:

http://www.open-std.org/jtc1/sc22/wg21/

but still no new deadline appears; it seems even to be updated only up to=
=20
18 Februar.
Is this normal?

Thanks,
Daniele Bordes

Il giorno mercoled=C3=AC 2 marzo 2016 14:52:40 UTC+1, Daniel Kr=C3=BCgler h=
a scritto:
>
> 2016-03-02 14:47 GMT+01:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:=
=20
> >> At some point of these iterations the author should decide whether=20
> >> he/she believes that the document is ripe to submit or not. Assuming=
=20
> >> the decision was positive and when you notices that a new mailing=20
> >> deadline is published on http://www.open-std.org/jtc1/sc22/wg21/, you=
=20
> >> should contact the lwgchair address requesting to submit your=20
> >> proposal.=20
> >=20
> > As a language feature, should it not go to the EWG chair?=20
>
> This might work, you have to contact the EWG chair for this. Currently=20
> the lwgchair address collects all proposals.=20
>
> I will request a clarification of this and some other details after=20
> the Jacksonville meeting.=20
>
> Thanks,=20
>
> - Daniel=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d5d77231-9e71-4573-b15e-ad24c8551a27%40isocpp.or=
g.

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

<div dir=3D"ltr">I am costantly looking here:<div><br></div><div>http://www=
..open-std.org/jtc1/sc22/wg21/</div><div><br></div><div>but still no new dea=
dline appears; it seems even to be updated only up to 18 Februar.</div><div=
>Is this normal?</div><div><br></div><div>Thanks,</div><div>Daniele Bordes<=
br><br>Il giorno mercoled=C3=AC 2 marzo 2016 14:52:40 UTC+1, Daniel Kr=C3=
=BCgler ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-03-02 =
14:47 GMT+01:00 Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"j0PtRVdwBAAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;java=
script:&#39;;return true;">jmck...@gmail.com</a>&gt;:
<br>&gt;&gt; At some point of these iterations the author should decide whe=
ther
<br>&gt;&gt; he/she believes that the document is ripe to submit or not. As=
suming
<br>&gt;&gt; the decision was positive and when you notices that a new mail=
ing
<br>&gt;&gt; deadline is published on <a href=3D"http://www.open-std.org/jt=
c1/sc22/wg21/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%=
2Fsc22%2Fwg21%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEDzTC8Ry9aTHT3x4t5uwkCZ=
P6E8A&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/=
url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2F\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNEDzTC8Ry9aTHT3x4t5uwkCZP6E8A&#39;;return true;">http:=
//www.open-std.org/jtc1/<wbr>sc22/wg21/</a>, you
<br>&gt;&gt; should contact the lwgchair address requesting to submit your
<br>&gt;&gt; proposal.
<br>&gt;
<br>&gt; As a language feature, should it not go to the EWG chair?
<br>
<br>This might work, you have to contact the EWG chair for this. Currently
<br>the lwgchair address collects all proposals.
<br>
<br>I will request a clarification of this and some other details after
<br>the Jacksonville meeting.
<br>
<br>Thanks,
<br>
<br>- Daniel
<br></blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d5d77231-9e71-4573-b15e-ad24c8551a27%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d5d77231-9e71-4573-b15e-ad24c8551a27=
%40isocpp.org</a>.<br />

------=_Part_386_1980555508.1457301473928--
------=_Part_385_1670790494.1457301473928--

.

2016-03-06 22:57 GMT+01:00  <daniele.bordes@gmail.com>:
> I am costantly looking here:
>
> http://www.open-std.org/jtc1/sc22/wg21/
>
> but still no new deadline appears; it seems even to be updated only up to 18
> Februar.
> Is this normal?

That is absolutely normal, because the Jacksonville has just ended at
this weekend.

- Daniel

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGNvRgB-hjzqLMBLxu1h6F7q0z-LRWbhFxEfAqP5gk0hs6qhAg%40mail.gmail.com.

.

On 2016-02-28 18:27, Tony V E wrote:
>> Clearly, people who want static reflection feel that [reflection
>> exposing private members] is important.
>=20
> Clearly *some* of the people who want static reflection feel that this is=
=20
> important.
>=20
> Some other people who want reflection think it is a bad idea=E2=80=8E. Bu=
t they have (so=20
> far) been outnumbered.

I can't say I got that impression from the SG evening session last week
(although it didn't come up specifically). At least one of the three
papers we considered only provided access to those members that are
visible at the point where reflection is invoked.

FWIW, I strongly prefer this model: access protection works as in other
contexts, and users that are friends can see private members.

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/nbk3v5%242r2%241%40ger.gmane.org.

.