------=_Part_1232_28179534.1383104357774
Content-Type: text/plain; charset=ISO-8859-1

There is one major wart in C++ class design, and that is with private
member functions required to be in the class definition.

This has a number of problems:
1) Changing the private method's signature or adding/removing private
methods requires everyone including the header to recompile. This is a huge
problem for large projects with long recompilation times.
2) file static / anonymous namespace definitions in the .cc file cannot be
used in the private method's signature. Anything used in the signature must
be at least forward declared in the header, adding more symbol pollution.
3) For shared library interfaces, the private methods are extra unnecessary
symbols that have to be managed.
4) Private method signatures or even the existence of private methods can
depend on the underlying implementation. If the class has multiple
implementations (e.g. different platforms), #defines and other conditional
compilation mechanisms are required in the header file.
5) Its just bad encapsulation. Callers don't need to know anything about
the functions which implement the class behavior.

The only private declarations that should be required in the header are
declarations required by the compiler. I believe all of those are:
1) Private data members (sizeof())
2) Private virtual methods (for inheriting)
3) Private non-virtual methods called by inline functions.

One way to do this would be to extend the friend feature. We could define
friend functions within the body of member functions. It might look like
this:

//foo.hh

class Foo {
  public:
    void doWork();
  private:
    int _f;
}

//foo.cc
static void doWorkHelper(Foo* f) {
  doSomethingWith(f->_f);
};

void Foo::doWork() {
  friend void doWorkHelper(Foo*);

  doWorkHelper(this);
}

This has potential for abuse of course, but it would finally allow us to
limit the list of declarations in the class definition to the bare minimum
required by the compiler. When it comes to defining interfaces, less is
always more.
One other use of this feature could be to add a backdoor for unit tests.

Thoughts?

--

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

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

<div dir=3D"ltr">There is one major wart in C++ class design, and that is w=
ith private member functions required to be in the class definition.<div><b=
r></div><div>This has a number of problems:</div><div>1) Changing the priva=
te method's signature or adding/removing private methods requires everyone =
including the header to recompile. This is a huge problem for large project=
s with long recompilation times.</div><div>2) file static / anonymous names=
pace definitions in the .cc file cannot be used in the private method's sig=
nature. Anything used in the signature must be at least forward declared in=
 the header, adding more symbol pollution.</div><div>3) For shared library =
interfaces, the private methods are extra unnecessary symbols that have to =
be managed.</div><div>4) Private method signatures or even the existence of=
 private methods can depend on the underlying implementation. If the class =
has multiple implementations (e.g. different platforms), #defines and other=
 conditional compilation mechanisms are required in the header file.</div><=
div>5) Its just bad encapsulation. Callers don't need to know anything abou=
t the functions which implement the class behavior.</div><div><br></div><di=
v>The only private declarations that should be required in the header are d=
eclarations required by the compiler. I believe all of those are:</div><div=
>1) Private data members (sizeof())</div><div>2) Private virtual methods (f=
or inheriting)</div><div>3) Private non-virtual methods called by inline fu=
nctions.</div><div><br></div><div>One way to do this would be to extend the=
 friend feature. We could define friend functions within the body of member=
 functions. It might look like this:</div><div><br></div><div>//foo.hh</div=
><div><br></div><div>class Foo {<br>&nbsp; public:</div><div>&nbsp; &nbsp; =
void doWork();</div><div>&nbsp; private:</div><div>&nbsp; &nbsp; int _f;</d=
iv><div>}</div><div><br></div><div>//foo.cc</div><div>static void doWorkHel=
per(Foo* f) {</div><div>&nbsp; doSomethingWith(f-&gt;_f);<br>};</div><div><=
br></div><div>void Foo::doWork() {<br>&nbsp; friend void doWorkHelper(Foo*)=
;</div><div><br></div><div>&nbsp; doWorkHelper(this);</div><div>}</div><div=
><br></div><div>This has potential for abuse of course, but it would finall=
y allow us to limit the list of declarations in the class definition to the=
 bare minimum required by the compiler. When it comes to defining interface=
s, less is always more.</div><div>One other use of this feature could be to=
 add a backdoor for unit tests.</div><div><br></div><div>Thoughts?</div></d=
iv>

<p></p>

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

------=_Part_1232_28179534.1383104357774--

.

--089e0160c35ee1f99e04e9ed8bd5
Content-Type: text/plain; charset=ISO-8859-1

> One other use of this feature could be to add a backdoor for unit tests.

Unit tests that test non-public data are bad (brittle) unit tests. Break up
those classes! :)

For most cases where these bits matter you can define a static non-member
non-friend function in a file somewhere, and have your member function
implementations call these non-members.

Another mitigation is to put your "private member functions" into another
class, and declare that class a friend. You still leak the one symbol, but
that's comparatively minor:

http://ideone.com/K9m0Fz

#include <iostream>
class PublicClass
{
 friend class PublicClassImpl;
 int idx;
public:
 PublicClass() : idx (42) {}
 void DoWork();
};

// In the implementation file:
class PublicClassImpl
{
public:
    static void DoWorkImpl(PublicClass& target);
};

void PublicClass::DoWork()
{
 PublicClassImpl::DoWorkImpl(*this);
}

void PublicClassImpl::DoWorkImpl(PublicClass& target)
{
 std::cout << "Index is currently " << target.idx++ << std::endl;
}

// Example Use:
int main() {
 PublicClass pc;
 pc.DoWork();
 pc.DoWork();
 return 0;
}

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Oct 29, 2013 at 8:39 PM, <fmatthew5876@gmail.com> wrote:

> There is one major wart in C++ class design, and that is with private
> member functions required to be in the class definition.
>
> This has a number of problems:
> 1) Changing the private method's signature or adding/removing private
> methods requires everyone including the header to recompile. This is a huge
> problem for large projects with long recompilation times.
> 2) file static / anonymous namespace definitions in the .cc file cannot be
> used in the private method's signature. Anything used in the signature must
> be at least forward declared in the header, adding more symbol pollution.
> 3) For shared library interfaces, the private methods are extra
> unnecessary symbols that have to be managed.
> 4) Private method signatures or even the existence of private methods can
> depend on the underlying implementation. If the class has multiple
> implementations (e.g. different platforms), #defines and other conditional
> compilation mechanisms are required in the header file.
> 5) Its just bad encapsulation. Callers don't need to know anything about
> the functions which implement the class behavior.
>
> The only private declarations that should be required in the header are
> declarations required by the compiler. I believe all of those are:
> 1) Private data members (sizeof())
> 2) Private virtual methods (for inheriting)
> 3) Private non-virtual methods called by inline functions.
>
> One way to do this would be to extend the friend feature. We could define
> friend functions within the body of member functions. It might look like
> this:
>
> //foo.hh
>
> class Foo {
>   public:
>     void doWork();
>   private:
>     int _f;
> }
>
> //foo.cc
> static void doWorkHelper(Foo* f) {
>   doSomethingWith(f->_f);
> };
>
> void Foo::doWork() {
>   friend void doWorkHelper(Foo*);
>
>   doWorkHelper(this);
> }
>
> This has potential for abuse of course, but it would finally allow us to
> limit the list of declarations in the class definition to the bare minimum
> required by the compiler. When it comes to defining interfaces, less is
> always more.
> One other use of this feature could be to add a backdoor for unit tests.
>
> Thoughts?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><div>&gt; One other use of this feature could be to add a =
backdoor for unit tests.</div><div>=A0</div><div>Unit tests that test non-p=
ublic data are bad (brittle) unit tests. Break up those classes! :)</div><d=
iv>

=A0</div><div>For most cases where these bits matter you can define a stati=
c non-member non-friend function in a file somewhere, and have your member =
function implementations call these non-members.</div><div>=A0</div><div>An=
other mitigation is to put your &quot;private member functions&quot; into a=
nother class, and declare that class a friend. You still leak the one symbo=
l, but that&#39;s comparatively minor:</div>

<div>=A0</div><div><a href=3D"http://ideone.com/K9m0Fz">http://ideone.com/K=
9m0Fz</a></div><div>=A0</div><div><font face=3D"courier new,monospace">#inc=
lude &lt;iostream&gt;</font></div><div><font face=3D"courier new,monospace"=
>class PublicClass<br>

{<br>=A0friend class PublicClassImpl;<br>=A0int idx;<br>public:<br>=A0Publi=
cClass() : idx (42) {}<br>=A0void DoWork();<br>};</font></div><div>=A0</div=
><div><font face=3D"courier new,monospace">// In the implementation file:<b=
r>class PublicClassImpl<br>

{<br>public:<br>=A0=A0=A0 static void DoWorkImpl(PublicClass&amp; target);<=
br>};</font></div><div><font face=3D"Courier New"></font>=A0</div><div><fon=
t face=3D"courier new,monospace">void PublicClass::DoWork()<br>{<br>=A0Publ=
icClassImpl::DoWorkImpl(*this);<br>

}</font></div><div>=A0</div><div><font face=3D"courier new,monospace">void =
PublicClassImpl::DoWorkImpl(PublicClass&amp; target)<br>{<br>=A0std::cout &=
lt;&lt; &quot;Index is currently &quot; &lt;&lt; target.idx++ &lt;&lt; std:=
:endl;<br>

}</font></div><div>=A0</div><div><font face=3D"courier new,monospace">// Ex=
ample Use:</font></div><div><font face=3D"courier new,monospace">int main()=
 {<br>=A0PublicClass pc;<br>=A0pc.DoWork();<br>=A0pc.DoWork();<br>=A0return=
 0;<br>}</font></div>

<div><font face=3D"Courier New"></font>=A0</div><div>Billy O&#39;Neal</div>=
<div class=3D"gmail_extra"><div><div dir=3D"ltr"><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Oct 29, 2013 at 8:39 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank"=
>fmatthew5876@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-colo=
r:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

<div dir=3D"ltr">There is one major wart in C++ class design, and that is w=
ith private member functions required to be in the class definition.<div><b=
r></div><div>This has a number of problems:</div><div>1) Changing the priva=
te method&#39;s signature or adding/removing private methods requires every=
one including the header to recompile. This is a huge problem for large pro=
jects with long recompilation times.</div>

<div>2) file static / anonymous namespace definitions in the .cc file canno=
t be used in the private method&#39;s signature. Anything used in the signa=
ture must be at least forward declared in the header, adding more symbol po=
llution.</div>

<div>3) For shared library interfaces, the private methods are extra unnece=
ssary symbols that have to be managed.</div><div>4) Private method signatur=
es or even the existence of private methods can depend on the underlying im=
plementation. If the class has multiple implementations (e.g. different pla=
tforms), #defines and other conditional compilation mechanisms are required=
 in the header file.</div>

<div>5) Its just bad encapsulation. Callers don&#39;t need to know anything=
 about the functions which implement the class behavior.</div><div><br></di=
v><div>The only private declarations that should be required in the header =
are declarations required by the compiler. I believe all of those are:</div=
>

<div>1) Private data members (sizeof())</div><div>2) Private virtual method=
s (for inheriting)</div><div>3) Private non-virtual methods called by inlin=
e functions.</div><div><br></div><div>One way to do this would be to extend=
 the friend feature. We could define friend functions within the body of me=
mber functions. It might look like this:</div>

<div><br></div><div>//foo.hh</div><div><br></div><div>class Foo {<br>=A0 pu=
blic:</div><div>=A0 =A0 void doWork();</div><div>=A0 private:</div><div>=A0=
 =A0 int _f;</div><div>}</div><div><br></div><div>//foo.cc</div><div>static=
 void doWorkHelper(Foo* f) {</div>

<div>=A0 doSomethingWith(f-&gt;_f);<br>};</div><div><br></div><div>void Foo=
::doWork() {<br>=A0 friend void doWorkHelper(Foo*);</div><div><br></div><di=
v>=A0 doWorkHelper(this);</div><div>}</div><div><br></div><div>This has pot=
ential for abuse of course, but it would finally allow us to limit the list=
 of declarations in the class definition to the bare minimum required by th=
e compiler. When it comes to defining interfaces, less is always more.</div=
>

<div>One other use of this feature could be to add a backdoor for unit test=
s.</div><div><br></div><div>Thoughts?</div></div><span class=3D"HOEnZb"><fo=
nt color=3D"#888888">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

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

--089e0160c35ee1f99e04e9ed8bd5--

.

------=_Part_302_7913481.1383144825039
Content-Type: text/plain; charset=ISO-8859-1

Some suggestions similarly to Billy O'Neal's are given here:

https://groups.google.com/forum/?fromgroups#!searchin/comp.lang.c$2B$2B.moderated/Moving$20private$20functions$20to$20opaque$20inner/comp.lang.c++.moderated/GJyXgeEtAOA/PwXSG_ZGeGgJ

Cheers,
Cassio.

--

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

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

<div dir=3D"ltr">Some suggestions similarly to Billy O'Neal's are given her=
e:<br><br>https://groups.google.com/forum/?fromgroups#!searchin/comp.lang.c=
$2B$2B.moderated/Moving$20private$20functions$20to$20opaque$20inner/comp.la=
ng.c++.moderated/GJyXgeEtAOA/PwXSG_ZGeGgJ<br><br>Cheers,<br>Cassio.<br></di=
v>

<p></p>

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

------=_Part_302_7913481.1383144825039--

.

--001a11367c1c94be9504e9f69ddc
Content-Type: text/plain; charset=ISO-8859-1

On 30 October 2013 16:53, Cassio Neri <cassio.neri@gmail.com> wrote:

> Some suggestions similarly to Billy O'Neal's are given here:
>
>
> https://groups.google.com/forum/?fromgroups#!searchin/comp.lang.c$2B$2B.moderated/Moving$20private$20functions$20to$20opaque$20inner/comp.lang.c++.moderated/GJyXgeEtAOA/PwXSG_ZGeGgJ
>
> Cheers,
> Cassio.
>
>
>
>
I have also used a solution where I define a public struct for the members
of the class
and have the members in a private instance of that struct, and then pass a
reference
to that struct to implementation-file-scope 'private' functions. This way
the only
private member functions that need to be in the class definition are the
ones that
are virtual.

So,

1) Changing the private method's signature or adding/removing private
methods requires everyone including the header to recompile. This is a huge
problem for large projects with long recompilation times.

- not a problem anymore

2) file static / anonymous namespace definitions in the .cc file cannot be
used in the private method's signature. Anything used in the signature must
be at least forward declared in the header, adding more symbol pollution.

- ditto

3) For shared library interfaces, the private methods are extra unnecessary
symbols that have to be managed.

- I can use implementation-specific visibility settings for this, so not a
problem

4) Private method signatures or even the existence of private methods can
depend on the underlying implementation. If the class has multiple
implementations (e.g. different platforms), #defines and other conditional
compilation mechanisms are required in the header file.

- as for 1&2, not a problem

5) Its just bad encapsulation. Callers don't need to know anything about
the functions which implement the class behavior.

- ditto

The tediousness of such a solution is seemingly not big enough to really
want a language
change, according to my experience.

I haven't used an opaque array blob from which the implementation-functions
allocate space
to the real members. I have considered it a couple of times, but never
bothered using it. And it
doesn't help much for cases where the size of the blob must increase.

The Lakosbook (
http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620)
provides further insight for physical design and insulation.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 30 October 2013 16:53, Cassio Neri <span dir=3D"ltr">&lt;<a href=
=3D"mailto:cassio.neri@gmail.com" target=3D"_blank">cassio.neri@gmail.com</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Some sug=
gestions similarly to Billy O&#39;Neal&#39;s are given here:<br><br><a href=
=3D"https://groups.google.com/forum/?fromgroups#!searchin/comp.lang.c$2B$2B=
..moderated/Moving$20private$20functions$20to$20opaque$20inner/comp.lang.c++=
..moderated/GJyXgeEtAOA/PwXSG_ZGeGgJ" target=3D"_blank">https://groups.googl=
e.com/forum/?fromgroups#!searchin/comp.lang.c$2B$2B.moderated/Moving$20priv=
ate$20functions$20to$20opaque$20inner/comp.lang.c++.moderated/GJyXgeEtAOA/P=
wXSG_ZGeGgJ</a><br>
<br>Cheers,<br>Cassio.<br></div><div class=3D""><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>I have also used a sol=
ution where I define a public struct for the members of the class<br></div>=
<div>and have the members in a private instance of that struct, and then pa=
ss a reference<br>
to that struct to implementation-file-scope &#39;private&#39; functions. Th=
is way the only<br></div><div>private member functions that need to be in t=
he class definition are the ones that<br>are virtual.<br><br></div><div>
So,<br><br><div>1) Changing the private method&#39;s signature or adding/re=
moving=20
private methods requires everyone including the header to recompile.=20
This is a huge problem for large projects with long recompilation times.<br=
><br></div><div>- not a problem anymore<br><br></div><div>2)
 file static / anonymous namespace definitions in the .cc file cannot be
 used in the private method&#39;s signature. Anything used in the signature=
=20
must be at least forward declared in the header, adding more symbol=20
pollution.<br><br></div><div>- ditto<br><br></div><div>3) For shared librar=
y interfaces, the private methods are extra unnecessary symbols that have t=
o be managed.<br><br></div><div>- I can use implementation-specific visibil=
ity settings for this, so not a problem<br>
<br></div><div>4)
 Private method signatures or even the existence of private methods can=20
depend on the underlying implementation. If the class has multiple=20
implementations (e.g. different platforms), #defines and other=20
conditional compilation mechanisms are required in the header file.<br><br>=
</div><div>- as for 1&amp;2, not a problem<br><br></div><div>5) Its just ba=
d encapsulation. Callers don&#39;t need to know anything about the function=
s which implement the class behavior.</div>
<div><br></div><div>- ditto<br></div><br></div><div>The tediousness of such=
 a solution is seemingly not big enough to really want a language<br>change=
, according to my experience.<br><br></div><div>I haven&#39;t used an opaqu=
e array blob from which the implementation-functions allocate space<br>
to the real members. I have considered it a couple of times, but never both=
ered using it. And it<br></div><div>doesn&#39;t help much for cases where t=
he size of the blob must increase.<br><br></div><div>The Lakosbook (<a href=
=3D"http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633=
620">http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/020163=
3620</a>)<br>
</div><div>provides further insight for physical design and insulation.<br>=
</div></div><br></div></div>

<p></p>

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

--001a11367c1c94be9504e9f69ddc--

.

------=_Part_2149_29710459.1383498617420
Content-Type: text/plain; charset=ISO-8859-1

Hello,

   I've been thinking about a new proposal for a "class implementation
namespace", where I initially thought to only allow member function
implementations that were already declared, but reading this proposal I
realized that allowing new private member function declarations would solve
your problem. It would look something like this using your example:

//foo.hh

class Foo {
  public:
    void doWork();
  private:
    int _f;
}

//foo.cc:

class Foo namespace {

// optional forward declaraction:
  void doWrokHelper();  // implicitly private

// definition of doWorkHelper() private member function declared above:
  void doWorkHelper() {
     doSomethingWith(_f);
  }

// definition of doWork() public member function declared in Foo.hh:
  void doWork() {
     doWorkHelper();
  }
} // end class Foo namespace (the "implementation namespace")

In my opinion this "class implementation namespace" would be a cleaner
solution to your issue, and would also have additional benefits:
  - template class member function implementations could be separated from
the main class declaration without having to resort to ugly repetitions
  - member functions returning nested classes could be written the same way
as declared (this is a common problem for new learners according to my
experience)
  - in general, the "implementation" part would be syntactically similar to
the declaration part, without unnecessary repetition of the class name, etc

I'll try to write a detailed proposal next week (I first wanted to
implement this concept in clang, but I guess it's better to get out the
idea first...)

cheers,
mitch

On Wednesday, October 30, 2013 4:39:17 AM UTC+1, fmatth...@gmail.com wrote:
>
> There is one major wart in C++ class design, and that is with private
> member functions required to be in the class definition.
>
> This has a number of problems:
> 1) Changing the private method's signature or adding/removing private
> methods requires everyone including the header to recompile. This is a huge
> problem for large projects with long recompilation times.
> 2) file static / anonymous namespace definitions in the .cc file cannot be
> used in the private method's signature. Anything used in the signature must
> be at least forward declared in the header, adding more symbol pollution.
> 3) For shared library interfaces, the private methods are extra
> unnecessary symbols that have to be managed.
> 4) Private method signatures or even the existence of private methods can
> depend on the underlying implementation. If the class has multiple
> implementations (e.g. different platforms), #defines and other conditional
> compilation mechanisms are required in the header file.
> 5) Its just bad encapsulation. Callers don't need to know anything about
> the functions which implement the class behavior.
>
> The only private declarations that should be required in the header are
> declarations required by the compiler. I believe all of those are:
> 1) Private data members (sizeof())
> 2) Private virtual methods (for inheriting)
> 3) Private non-virtual methods called by inline functions.
>
> One way to do this would be to extend the friend feature. We could define
> friend functions within the body of member functions. It might look like
> this:
>
> //foo.hh
>
> class Foo {
>   public:
>     void doWork();
>   private:
>     int _f;
> }
>
> //foo.cc
> static void doWorkHelper(Foo* f) {
>   doSomethingWith(f->_f);
> };
>
> void Foo::doWork() {
>   friend void doWorkHelper(Foo*);
>
>   doWorkHelper(this);
> }
>
> This has potential for abuse of course, but it would finally allow us to
> limit the list of declarations in the class definition to the bare minimum
> required by the compiler. When it comes to defining interfaces, less is
> always more.
> One other use of this feature could be to add a backdoor for unit tests.
>
> Thoughts?
>

--

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

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

<div dir=3D"ltr">Hello,<div><br></div><div>&nbsp; &nbsp;I've been thinking =
about a new proposal for a "class implementation namespace", where I initia=
lly thought to only allow member function implementations that were already=
 declared, but reading this proposal I realized that allowing new private m=
ember function declarations would solve your problem. It would look somethi=
ng like this using your example:</div><div><br></div><div><div>//foo.hh</di=
v><div><br></div><div>class Foo {<br>&nbsp; public:</div><div>&nbsp; &nbsp;=
 void doWork();</div><div>&nbsp; private:</div><div>&nbsp; &nbsp; int _f;</=
div><div>}</div><div><br></div><div>//foo.cc:</div><div><br></div><div>clas=
s Foo namespace {</div><div><br></div><div>// optional forward declaraction=
:</div><div>&nbsp; void doWrokHelper(); &nbsp;// implicitly private</div><d=
iv><br></div><div>// definition of doWorkHelper() private member function d=
eclared above:</div><div>&nbsp; void doWorkHelper() {</div><div>&nbsp; &nbs=
p; &nbsp;doSomethingWith(_f);</div><div>&nbsp; }</div><div>&nbsp;&nbsp;</di=
v><div>// definition of doWork() public member function declared in Foo.hh:=
</div><div>&nbsp; void doWork() {</div><div>&nbsp; &nbsp; &nbsp;doWorkHelpe=
r();</div><div>&nbsp; }</div><div>} // end class Foo namespace (the "implem=
entation namespace")</div><div><br></div><div>In my opinion this "class imp=
lementation namespace" would be a cleaner solution to your issue, and would=
 also have additional benefits:</div></div><div>&nbsp; - template class mem=
ber function implementations could be separated from the main class declara=
tion without having to resort to ugly repetitions</div><div>&nbsp; - member=
 functions returning nested classes could be written the same way as declar=
ed (this is a common problem for new learners according to my experience)</=
div><div>&nbsp; - in general, the "implementation" part would be syntactica=
lly similar to the declaration part, without unnecessary repetition of the =
class name, etc</div><div><br></div><div>I'll try to write a detailed propo=
sal next week (I first wanted to implement this concept in clang, but I gue=
ss it's better to get out the idea first...)</div><div><br></div><div>cheer=
s,</div><div>mitch</div><div><br>On Wednesday, October 30, 2013 4:39:17 AM =
UTC+1, fmatth...@gmail.com 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">There is one major wart in C++ class design, and that i=
s with private member functions required to be in the class definition.<div=
><br></div><div>This has a number of problems:</div><div>1) Changing the pr=
ivate method's signature or adding/removing private methods requires everyo=
ne including the header to recompile. This is a huge problem for large proj=
ects with long recompilation times.</div><div>2) file static / anonymous na=
mespace definitions in the .cc file cannot be used in the private method's =
signature. Anything used in the signature must be at least forward declared=
 in the header, adding more symbol pollution.</div><div>3) For shared libra=
ry interfaces, the private methods are extra unnecessary symbols that have =
to be managed.</div><div>4) Private method signatures or even the existence=
 of private methods can depend on the underlying implementation. If the cla=
ss has multiple implementations (e.g. different platforms), #defines and ot=
her conditional compilation mechanisms are required in the header file.</di=
v><div>5) Its just bad encapsulation. Callers don't need to know anything a=
bout the functions which implement the class behavior.</div><div><br></div>=
<div>The only private declarations that should be required in the header ar=
e declarations required by the compiler. I believe all of those are:</div><=
div>1) Private data members (sizeof())</div><div>2) Private virtual methods=
 (for inheriting)</div><div>3) Private non-virtual methods called by inline=
 functions.</div><div><br></div><div>One way to do this would be to extend =
the friend feature. We could define friend functions within the body of mem=
ber functions. It might look like this:</div><div><br></div><div>//foo.hh</=
div><div><br></div><div>class Foo {<br>&nbsp; public:</div><div>&nbsp; &nbs=
p; void doWork();</div><div>&nbsp; private:</div><div>&nbsp; &nbsp; int _f;=
</div><div>}</div><div><br></div><div>//foo.cc</div><div>static void doWork=
Helper(Foo* f) {</div><div>&nbsp; doSomethingWith(f-&gt;_f);<br>};</div><di=
v><br></div><div>void Foo::doWork() {<br>&nbsp; friend void doWorkHelper(Fo=
o*);</div><div><br></div><div>&nbsp; doWorkHelper(this);</div><div>}</div><=
div><br></div><div>This has potential for abuse of course, but it would fin=
ally allow us to limit the list of declarations in the class definition to =
the bare minimum required by the compiler. When it comes to defining interf=
aces, less is always more.</div><div>One other use of this feature could be=
 to add a backdoor for unit tests.</div><div><br></div><div>Thoughts?</div>=
</div></blockquote></div></div>

<p></p>

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

------=_Part_2149_29710459.1383498617420--

.

------=_Part_2280_24424726.1383514769417
Content-Type: text/plain; charset=ISO-8859-1

Maybe not intuitive, but this is by design. For performance reasons, the
compiler needs to know the layout of a struct, and it can only do that if
the definition is visible. Any workarounds require an indirection AFAIK, as
does implementing this as standard behavior. If you want hiding and abi
compatibility use the PIMPL idiom for private data. But realize that it
adds an extra indirection.

-Tim

On Wednesday, October 30, 2013 4:39:17 AM UTC+1, fmatth...@gmail.com wrote:
>
> There is one major wart in C++ class design, and that is with private
> member functions required to be in the class definition.
>
> This has a number of problems:
> 1) Changing the private method's signature or adding/removing private
> methods requires everyone including the header to recompile. This is a huge
> problem for large projects with long recompilation times.
> 2) file static / anonymous namespace definitions in the .cc file cannot be
> used in the private method's signature. Anything used in the signature must
> be at least forward declared in the header, adding more symbol pollution.
> 3) For shared library interfaces, the private methods are extra
> unnecessary symbols that have to be managed.
> 4) Private method signatures or even the existence of private methods can
> depend on the underlying implementation. If the class has multiple
> implementations (e.g. different platforms), #defines and other conditional
> compilation mechanisms are required in the header file.
> 5) Its just bad encapsulation. Callers don't need to know anything about
> the functions which implement the class behavior.
>
> The only private declarations that should be required in the header are
> declarations required by the compiler. I believe all of those are:
> 1) Private data members (sizeof())
> 2) Private virtual methods (for inheriting)
> 3) Private non-virtual methods called by inline functions.
>
> One way to do this would be to extend the friend feature. We could define
> friend functions within the body of member functions. It might look like
> this:
>
> //foo.hh
>
> class Foo {
>   public:
>     void doWork();
>   private:
>     int _f;
> }
>
> //foo.cc
> static void doWorkHelper(Foo* f) {
>   doSomethingWith(f->_f);
> };
>
> void Foo::doWork() {
>   friend void doWorkHelper(Foo*);
>
>   doWorkHelper(this);
> }
>
> This has potential for abuse of course, but it would finally allow us to
> limit the list of declarations in the class definition to the bare minimum
> required by the compiler. When it comes to defining interfaces, less is
> always more.
> One other use of this feature could be to add a backdoor for unit tests.
>
> Thoughts?
>

--

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

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

<div dir=3D"ltr">Maybe not intuitive, but this is by design. For performanc=
e reasons, the compiler needs to know the layout of a struct, and it can on=
ly do that if the definition is visible. Any workarounds require an indirec=
tion AFAIK, as does implementing this as standard behavior. If you want hid=
ing and abi compatibility use the PIMPL idiom for private data. But realize=
 that it adds an extra indirection.<div><div><br></div><div>-Tim<br><br>On =
Wednesday, October 30, 2013 4:39:17 AM UTC+1, fmatth...@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">There is one maj=
or wart in C++ class design, and that is with private member functions requ=
ired to be in the class definition.<div><br></div><div>This has a number of=
 problems:</div><div>1) Changing the private method's signature or adding/r=
emoving private methods requires everyone including the header to recompile=
.. This is a huge problem for large projects with long recompilation times.<=
/div><div>2) file static / anonymous namespace definitions in the .cc file =
cannot be used in the private method's signature. Anything used in the sign=
ature must be at least forward declared in the header, adding more symbol p=
ollution.</div><div>3) For shared library interfaces, the private methods a=
re extra unnecessary symbols that have to be managed.</div><div>4) Private =
method signatures or even the existence of private methods can depend on th=
e underlying implementation. If the class has multiple implementations (e.g=
.. different platforms), #defines and other conditional compilation mechanis=
ms are required in the header file.</div><div>5) Its just bad encapsulation=
.. Callers don't need to know anything about the functions which implement t=
he class behavior.</div><div><br></div><div>The only private declarations t=
hat should be required in the header are declarations required by the compi=
ler. I believe all of those are:</div><div>1) Private data members (sizeof(=
))</div><div>2) Private virtual methods (for inheriting)</div><div>3) Priva=
te non-virtual methods called by inline functions.</div><div><br></div><div=
>One way to do this would be to extend the friend feature. We could define =
friend functions within the body of member functions. It might look like th=
is:</div><div><br></div><div>//foo.hh</div><div><br></div><div>class Foo {<=
br>&nbsp; public:</div><div>&nbsp; &nbsp; void doWork();</div><div>&nbsp; p=
rivate:</div><div>&nbsp; &nbsp; int _f;</div><div>}</div><div><br></div><di=
v>//foo.cc</div><div>static void doWorkHelper(Foo* f) {</div><div>&nbsp; do=
SomethingWith(f-&gt;_f);<br>};</div><div><br></div><div>void Foo::doWork() =
{<br>&nbsp; friend void doWorkHelper(Foo*);</div><div><br></div><div>&nbsp;=
 doWorkHelper(this);</div><div>}</div><div><br></div><div>This has potentia=
l for abuse of course, but it would finally allow us to limit the list of d=
eclarations in the class definition to the bare minimum required by the com=
piler. When it comes to defining interfaces, less is always more.</div><div=
>One other use of this feature could be to add a backdoor for unit tests.</=
div><div><br></div><div>Thoughts?</div></div></blockquote></div></div></div=
>

<p></p>

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

------=_Part_2280_24424726.1383514769417--

.

--001a11c33676a2f73804ea4f847d
Content-Type: text/plain; charset=ISO-8859-1

Private member *data* does need to be declared in the class definition so
that callers know what size to lay out for the object. Private member
*functions* do not.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sun, Nov 3, 2013 at 1:39 PM, <shadowdrak@gmail.com> wrote:

> Maybe not intuitive, but this is by design. For performance reasons, the
> compiler needs to know the layout of a struct, and it can only do that if
> the definition is visible. Any workarounds require an indirection AFAIK, as
> does implementing this as standard behavior. If you want hiding and abi
> compatibility use the PIMPL idiom for private data. But realize that it
> adds an extra indirection.
>
> -Tim
>
>
> On Wednesday, October 30, 2013 4:39:17 AM UTC+1, fmatth...@gmail.comwrote:
>>
>> There is one major wart in C++ class design, and that is with private
>> member functions required to be in the class definition.
>>
>> This has a number of problems:
>> 1) Changing the private method's signature or adding/removing private
>> methods requires everyone including the header to recompile. This is a huge
>> problem for large projects with long recompilation times.
>> 2) file static / anonymous namespace definitions in the .cc file cannot
>> be used in the private method's signature. Anything used in the signature
>> must be at least forward declared in the header, adding more symbol
>> pollution.
>> 3) For shared library interfaces, the private methods are extra
>> unnecessary symbols that have to be managed.
>> 4) Private method signatures or even the existence of private methods can
>> depend on the underlying implementation. If the class has multiple
>> implementations (e.g. different platforms), #defines and other conditional
>> compilation mechanisms are required in the header file.
>> 5) Its just bad encapsulation. Callers don't need to know anything about
>> the functions which implement the class behavior.
>>
>> The only private declarations that should be required in the header are
>> declarations required by the compiler. I believe all of those are:
>> 1) Private data members (sizeof())
>> 2) Private virtual methods (for inheriting)
>> 3) Private non-virtual methods called by inline functions.
>>
>> One way to do this would be to extend the friend feature. We could define
>> friend functions within the body of member functions. It might look like
>> this:
>>
>> //foo.hh
>>
>> class Foo {
>>   public:
>>     void doWork();
>>   private:
>>     int _f;
>> }
>>
>> //foo.cc
>> static void doWorkHelper(Foo* f) {
>>   doSomethingWith(f->_f);
>> };
>>
>> void Foo::doWork() {
>>   friend void doWorkHelper(Foo*);
>>
>>   doWorkHelper(this);
>> }
>>
>> This has potential for abuse of course, but it would finally allow us to
>> limit the list of declarations in the class definition to the bare minimum
>> required by the compiler. When it comes to defining interfaces, less is
>> always more.
>> One other use of this feature could be to add a backdoor for unit tests.
>>
>> Thoughts?
>>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">Private member *data* does need to be declared in the clas=
s definition so that callers know what size to lay out for the object. Priv=
ate member *functions* do not.</div><div class=3D"gmail_extra"><br clear=3D=
"all">

<div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 1:39 PM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:shadowdrak@gmail.com" target=3D"_blank">sh=
adowdrak@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Maybe not intuitive, but this is by design. For performanc=
e reasons, the compiler needs to know the layout of a struct, and it can on=
ly do that if the definition is visible. Any workarounds require an indirec=
tion AFAIK, as does implementing this as standard behavior. If you want hid=
ing and abi compatibility use the PIMPL idiom for private data. But realize=
 that it adds an extra indirection.<div>

<div><br></div><div>-Tim<div><div class=3D"h5"><br><br>On Wednesday, Octobe=
r 30, 2013 4:39:17 AM UTC+1, <a href=3D"mailto:fmatth...@gmail.com" target=
=3D"_blank">fmatth...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid">

<div dir=3D"ltr">There is one major wart in C++ class design, and that is w=
ith private member functions required to be in the class definition.<div><b=
r></div><div>This has a number of problems:</div><div>1) Changing the priva=
te method&#39;s signature or adding/removing private methods requires every=
one including the header to recompile. This is a huge problem for large pro=
jects with long recompilation times.</div>

<div>2) file static / anonymous namespace definitions in the .cc file canno=
t be used in the private method&#39;s signature. Anything used in the signa=
ture must be at least forward declared in the header, adding more symbol po=
llution.</div>

<div>3) For shared library interfaces, the private methods are extra unnece=
ssary symbols that have to be managed.</div><div>4) Private method signatur=
es or even the existence of private methods can depend on the underlying im=
plementation. If the class has multiple implementations (e.g. different pla=
tforms), #defines and other conditional compilation mechanisms are required=
 in the header file.</div>

<div>5) Its just bad encapsulation. Callers don&#39;t need to know anything=
 about the functions which implement the class behavior.</div><div><br></di=
v><div>The only private declarations that should be required in the header =
are declarations required by the compiler. I believe all of those are:</div=
>

<div>1) Private data members (sizeof())</div><div>2) Private virtual method=
s (for inheriting)</div><div>3) Private non-virtual methods called by inlin=
e functions.</div><div><br></div><div>One way to do this would be to extend=
 the friend feature. We could define friend functions within the body of me=
mber functions. It might look like this:</div>

<div><br></div><div>//foo.hh</div><div><br></div><div>class Foo {<br>=A0 pu=
blic:</div><div>=A0 =A0 void doWork();</div><div>=A0 private:</div><div>=A0=
 =A0 int _f;</div><div>}</div><div><br></div><div>//foo.cc</div><div>static=
 void doWorkHelper(Foo* f) {</div>

<div>=A0 doSomethingWith(f-&gt;_f);<br>};</div><div><br></div><div>void Foo=
::doWork() {<br>=A0 friend void doWorkHelper(Foo*);</div><div><br></div><di=
v>=A0 doWorkHelper(this);</div><div>}</div><div><br></div><div>This has pot=
ential for abuse of course, but it would finally allow us to limit the list=
 of declarations in the class definition to the bare minimum required by th=
e compiler. When it comes to defining interfaces, less is always more.</div=
>

<div>One other use of this feature could be to add a backdoor for unit test=
s.</div><div><br></div><div>Thoughts?</div></div></blockquote></div></div><=
/div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c33676a2f73804ea4f847d--

.

--001a11c23c8883a5ce04ea500f02
Content-Type: text/plain; charset=ISO-8859-1

Adding a virtual member functions to a class without other virtual member
functions does change the class layout. (I guess classes whose virtual
member functions are all private don't occur in practice though.)


2013/11/4 Billy O'Neal <billy.oneal@gmail.com>

> Private member *data* does need to be declared in the class definition so
> that callers know what size to lay out for the object. Private member
> *functions* do not.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Sun, Nov 3, 2013 at 1:39 PM, <shadowdrak@gmail.com> wrote:
>
>> Maybe not intuitive, but this is by design. For performance reasons, the
>> compiler needs to know the layout of a struct, and it can only do that if
>> the definition is visible. Any workarounds require an indirection AFAIK, as
>> does implementing this as standard behavior. If you want hiding and abi
>> compatibility use the PIMPL idiom for private data. But realize that it
>> adds an extra indirection.
>>
>> -Tim
>>
>>
>> On Wednesday, October 30, 2013 4:39:17 AM UTC+1, fmatth...@gmail.comwrote:
>>>
>>> There is one major wart in C++ class design, and that is with private
>>> member functions required to be in the class definition.
>>>
>>> This has a number of problems:
>>> 1) Changing the private method's signature or adding/removing private
>>> methods requires everyone including the header to recompile. This is a huge
>>> problem for large projects with long recompilation times.
>>> 2) file static / anonymous namespace definitions in the .cc file cannot
>>> be used in the private method's signature. Anything used in the signature
>>> must be at least forward declared in the header, adding more symbol
>>> pollution.
>>> 3) For shared library interfaces, the private methods are extra
>>> unnecessary symbols that have to be managed.
>>> 4) Private method signatures or even the existence of private methods
>>> can depend on the underlying implementation. If the class has multiple
>>> implementations (e.g. different platforms), #defines and other conditional
>>> compilation mechanisms are required in the header file.
>>> 5) Its just bad encapsulation. Callers don't need to know anything about
>>> the functions which implement the class behavior.
>>>
>>> The only private declarations that should be required in the header are
>>> declarations required by the compiler. I believe all of those are:
>>> 1) Private data members (sizeof())
>>> 2) Private virtual methods (for inheriting)
>>> 3) Private non-virtual methods called by inline functions.
>>>
>>> One way to do this would be to extend the friend feature. We could
>>> define friend functions within the body of member functions. It might look
>>> like this:
>>>
>>> //foo.hh
>>>
>>> class Foo {
>>>   public:
>>>     void doWork();
>>>   private:
>>>     int _f;
>>> }
>>>
>>> //foo.cc
>>> static void doWorkHelper(Foo* f) {
>>>   doSomethingWith(f->_f);
>>> };
>>>
>>> void Foo::doWork() {
>>>   friend void doWorkHelper(Foo*);
>>>
>>>   doWorkHelper(this);
>>> }
>>>
>>> This has potential for abuse of course, but it would finally allow us to
>>> limit the list of declarations in the class definition to the bare minimum
>>> required by the compiler. When it comes to defining interfaces, less is
>>> always more.
>>> One other use of this feature could be to add a backdoor for unit tests.
>>>
>>> Thoughts?
>>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">Adding a virtual member functions to a class without other=
 virtual member functions does change the class layout. (I guess classes wh=
ose virtual member functions are all private don&#39;t occur in practice th=
ough.)<br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/11/4 Bil=
ly O&#39;Neal <span dir=3D"ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com=
" target=3D"_blank">billy.oneal@gmail.com</a>&gt;</span><br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div dir=3D"ltr">Private member *data* does need to be declared in the clas=
s definition so that callers know what size to lay out for the object. Priv=
ate member *functions* do not.</div><div class=3D"gmail_extra"><div class=
=3D"im">
<br clear=3D"all">

<div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>


<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div><div class=3D"h5"><div class=3D"gmail_quote">On Sun, Nov=
 3, 2013 at 1:39 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:shadowdrak@gm=
ail.com" target=3D"_blank">shadowdrak@gmail.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">


<div dir=3D"ltr">Maybe not intuitive, but this is by design. For performanc=
e reasons, the compiler needs to know the layout of a struct, and it can on=
ly do that if the definition is visible. Any workarounds require an indirec=
tion AFAIK, as does implementing this as standard behavior. If you want hid=
ing and abi compatibility use the PIMPL idiom for private data. But realize=
 that it adds an extra indirection.<div>


<div><br></div><div>-Tim<div><div><br><br>On Wednesday, October 30, 2013 4:=
39:17 AM UTC+1, <a href=3D"mailto:fmatth...@gmail.com" target=3D"_blank">fm=
atth...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">


<div dir=3D"ltr">There is one major wart in C++ class design, and that is w=
ith private member functions required to be in the class definition.<div><b=
r></div><div>This has a number of problems:</div><div>1) Changing the priva=
te method&#39;s signature or adding/removing private methods requires every=
one including the header to recompile. This is a huge problem for large pro=
jects with long recompilation times.</div>


<div>2) file static / anonymous namespace definitions in the .cc file canno=
t be used in the private method&#39;s signature. Anything used in the signa=
ture must be at least forward declared in the header, adding more symbol po=
llution.</div>


<div>3) For shared library interfaces, the private methods are extra unnece=
ssary symbols that have to be managed.</div><div>4) Private method signatur=
es or even the existence of private methods can depend on the underlying im=
plementation. If the class has multiple implementations (e.g. different pla=
tforms), #defines and other conditional compilation mechanisms are required=
 in the header file.</div>


<div>5) Its just bad encapsulation. Callers don&#39;t need to know anything=
 about the functions which implement the class behavior.</div><div><br></di=
v><div>The only private declarations that should be required in the header =
are declarations required by the compiler. I believe all of those are:</div=
>


<div>1) Private data members (sizeof())</div><div>2) Private virtual method=
s (for inheriting)</div><div>3) Private non-virtual methods called by inlin=
e functions.</div><div><br></div><div>One way to do this would be to extend=
 the friend feature. We could define friend functions within the body of me=
mber functions. It might look like this:</div>


<div><br></div><div>//foo.hh</div><div><br></div><div>class Foo {<br>=A0 pu=
blic:</div><div>=A0 =A0 void doWork();</div><div>=A0 private:</div><div>=A0=
 =A0 int _f;</div><div>}</div><div><br></div><div>//foo.cc</div><div>static=
 void doWorkHelper(Foo* f) {</div>


<div>=A0 doSomethingWith(f-&gt;_f);<br>};</div><div><br></div><div>void Foo=
::doWork() {<br>=A0 friend void doWorkHelper(Foo*);</div><div><br></div><di=
v>=A0 doWorkHelper(this);</div><div>}</div><div><br></div><div>This has pot=
ential for abuse of course, but it would finally allow us to limit the list=
 of declarations in the class definition to the bare minimum required by th=
e compiler. When it comes to defining interfaces, less is always more.</div=
>


<div>One other use of this feature could be to add a backdoor for unit test=
s.</div><div><br></div><div>Thoughts?</div></div></blockquote></div></div><=
/div></div></div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div><div class=3D"HOEnZb">=
<div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--001a11c23c8883a5ce04ea500f02--

.

--089e015388488dccfc04ea503a8d
Content-Type: text/plain; charset=ISO-8859-1

Actually that's a good point -- most of the iostreams classes' virtual
functions are all private, for example. The functions added in a single
translation unit would have to be non-virtual.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sun, Nov 3, 2013 at 5:44 PM, Philipp Stephani <p.stephani2@gmail.com>wrote:

> Adding a virtual member functions to a class without other virtual member
> functions does change the class layout. (I guess classes whose virtual
> member functions are all private don't occur in practice though.)
>
>
>
> 2013/11/4 Billy O'Neal <billy.oneal@gmail.com>
>
>> Private member *data* does need to be declared in the class definition so
>> that callers know what size to lay out for the object. Private member
>> *functions* do not.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Sun, Nov 3, 2013 at 1:39 PM, <shadowdrak@gmail.com> wrote:
>>
>>> Maybe not intuitive, but this is by design. For performance reasons, the
>>> compiler needs to know the layout of a struct, and it can only do that if
>>> the definition is visible. Any workarounds require an indirection AFAIK, as
>>> does implementing this as standard behavior. If you want hiding and abi
>>> compatibility use the PIMPL idiom for private data. But realize that it
>>> adds an extra indirection.
>>>
>>> -Tim
>>>
>>>
>>> On Wednesday, October 30, 2013 4:39:17 AM UTC+1, fmatth...@gmail.comwrote:
>>>>
>>>> There is one major wart in C++ class design, and that is with private
>>>> member functions required to be in the class definition.
>>>>
>>>> This has a number of problems:
>>>> 1) Changing the private method's signature or adding/removing private
>>>> methods requires everyone including the header to recompile. This is a huge
>>>> problem for large projects with long recompilation times.
>>>> 2) file static / anonymous namespace definitions in the .cc file cannot
>>>> be used in the private method's signature. Anything used in the signature
>>>> must be at least forward declared in the header, adding more symbol
>>>> pollution.
>>>> 3) For shared library interfaces, the private methods are extra
>>>> unnecessary symbols that have to be managed.
>>>> 4) Private method signatures or even the existence of private methods
>>>> can depend on the underlying implementation. If the class has multiple
>>>> implementations (e.g. different platforms), #defines and other conditional
>>>> compilation mechanisms are required in the header file.
>>>> 5) Its just bad encapsulation. Callers don't need to know anything
>>>> about the functions which implement the class behavior.
>>>>
>>>> The only private declarations that should be required in the header are
>>>> declarations required by the compiler. I believe all of those are:
>>>> 1) Private data members (sizeof())
>>>> 2) Private virtual methods (for inheriting)
>>>> 3) Private non-virtual methods called by inline functions.
>>>>
>>>> One way to do this would be to extend the friend feature. We could
>>>> define friend functions within the body of member functions. It might look
>>>> like this:
>>>>
>>>> //foo.hh
>>>>
>>>> class Foo {
>>>>   public:
>>>>     void doWork();
>>>>   private:
>>>>     int _f;
>>>> }
>>>>
>>>> //foo.cc
>>>> static void doWorkHelper(Foo* f) {
>>>>   doSomethingWith(f->_f);
>>>> };
>>>>
>>>> void Foo::doWork() {
>>>>   friend void doWorkHelper(Foo*);
>>>>
>>>>   doWorkHelper(this);
>>>> }
>>>>
>>>> This has potential for abuse of course, but it would finally allow us
>>>> to limit the list of declarations in the class definition to the bare
>>>> minimum required by the compiler. When it comes to defining interfaces,
>>>> less is always more.
>>>> One other use of this feature could be to add a backdoor for unit tests.
>>>>
>>>> Thoughts?
>>>>
>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">Actually that&#39;s a good point -- most of the iostreams =
classes&#39; virtual functions are all private, for example. The functions =
added in a single translation unit would have to be non-virtual.</div><div =
class=3D"gmail_extra">

<br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a =
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github=
..com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 5:44 PM, Philipp =
Stephani <span dir=3D"ltr">&lt;<a href=3D"mailto:p.stephani2@gmail.com" tar=
get=3D"_blank">p.stephani2@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div dir=3D"ltr">Adding a virtual member functions to a class without other=
 virtual member functions does change the class layout. (I guess classes wh=
ose virtual member functions are all private don&#39;t occur in practice th=
ough.)<div>

<div class=3D"h5"><br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/11/4 Bil=
ly O&#39;Neal <span dir=3D"ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com=
" target=3D"_blank">billy.oneal@gmail.com</a>&gt;</span><br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;borde=
r-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid=
">


<div dir=3D"ltr">Private member *data* does need to be declared in the clas=
s definition so that callers know what size to lay out for the object. Priv=
ate member *functions* do not.</div><div class=3D"gmail_extra"><div>
<br clear=3D"all">

<div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>




<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div><div><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 1=
:39 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:shadowdrak@gmail.com" targ=
et=3D"_blank">shadowdrak@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;borde=
r-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid=
">




<div dir=3D"ltr">Maybe not intuitive, but this is by design. For performanc=
e reasons, the compiler needs to know the layout of a struct, and it can on=
ly do that if the definition is visible. Any workarounds require an indirec=
tion AFAIK, as does implementing this as standard behavior. If you want hid=
ing and abi compatibility use the PIMPL idiom for private data. But realize=
 that it adds an extra indirection.<div>




<div><br></div><div>-Tim<div><div><br><br>On Wednesday, October 30, 2013 4:=
39:17 AM UTC+1, <a href=3D"mailto:fmatth...@gmail.com" target=3D"_blank">fm=
atth...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">




<div dir=3D"ltr">There is one major wart in C++ class design, and that is w=
ith private member functions required to be in the class definition.<div><b=
r></div><div>This has a number of problems:</div><div>1) Changing the priva=
te method&#39;s signature or adding/removing private methods requires every=
one including the header to recompile. This is a huge problem for large pro=
jects with long recompilation times.</div>




<div>2) file static / anonymous namespace definitions in the .cc file canno=
t be used in the private method&#39;s signature. Anything used in the signa=
ture must be at least forward declared in the header, adding more symbol po=
llution.</div>




<div>3) For shared library interfaces, the private methods are extra unnece=
ssary symbols that have to be managed.</div><div>4) Private method signatur=
es or even the existence of private methods can depend on the underlying im=
plementation. If the class has multiple implementations (e.g. different pla=
tforms), #defines and other conditional compilation mechanisms are required=
 in the header file.</div>




<div>5) Its just bad encapsulation. Callers don&#39;t need to know anything=
 about the functions which implement the class behavior.</div><div><br></di=
v><div>The only private declarations that should be required in the header =
are declarations required by the compiler. I believe all of those are:</div=
>




<div>1) Private data members (sizeof())</div><div>2) Private virtual method=
s (for inheriting)</div><div>3) Private non-virtual methods called by inlin=
e functions.</div><div><br></div><div>One way to do this would be to extend=
 the friend feature. We could define friend functions within the body of me=
mber functions. It might look like this:</div>




<div><br></div><div>//foo.hh</div><div><br></div><div>class Foo {<br>=A0 pu=
blic:</div><div>=A0 =A0 void doWork();</div><div>=A0 private:</div><div>=A0=
 =A0 int _f;</div><div>}</div><div><br></div><div>//foo.cc</div><div>static=
 void doWorkHelper(Foo* f) {</div>




<div>=A0 doSomethingWith(f-&gt;_f);<br>};</div><div><br></div><div>void Foo=
::doWork() {<br>=A0 friend void doWorkHelper(Foo*);</div><div><br></div><di=
v>=A0 doWorkHelper(this);</div><div>}</div><div><br></div><div>This has pot=
ential for abuse of course, but it would finally allow us to limit the list=
 of declarations in the class definition to the bare minimum required by th=
e compiler. When it comes to defining interfaces, less is always more.</div=
>




<div>One other use of this feature could be to add a backdoor for unit test=
s.</div><div><br></div><div>Thoughts?</div></div></blockquote></div></div><=
/div></div></div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div></div><div class=3D"HO=
EnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e015388488dccfc04ea503a8d--

.

--001a1132f26ad2bfea04ea505d1a
Content-Type: text/plain; charset=ISO-8859-1

Their destructor is public. However, there can exist classes with protected
nonvirtual destructors (that allow dynamic dispatch for calling but not for
destruction).
I'm not sure whether a restriction should be made to only allow private
nonvirtual functions outside the class definition -- a rule could be added
that the class layout may not be different for any nonzero number of
virtual functions, and the compiler could signal an error if a virtual
function is to be added to a class whose definition doesn't contain any
virtual functions.
In general I guess modules can solve this problem in a more generic way.


2013/11/4 Billy O'Neal <billy.oneal@gmail.com>

> Actually that's a good point -- most of the iostreams classes' virtual
> functions are all private, for example. The functions added in a single
> translation unit would have to be non-virtual.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Sun, Nov 3, 2013 at 5:44 PM, Philipp Stephani <p.stephani2@gmail.com>wrote:
>
>> Adding a virtual member functions to a class without other virtual member
>> functions does change the class layout. (I guess classes whose virtual
>> member functions are all private don't occur in practice though.)
>>
>>
>>
>> 2013/11/4 Billy O'Neal <billy.oneal@gmail.com>
>>
>>> Private member *data* does need to be declared in the class definition
>>> so that callers know what size to lay out for the object. Private member
>>> *functions* do not.
>>>
>>> Billy O'Neal
>>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>>> http://stackoverflow.com/users/82320/billy-oneal
>>> Malware Response Instructor - BleepingComputer.com
>>>
>>>
>>> On Sun, Nov 3, 2013 at 1:39 PM, <shadowdrak@gmail.com> wrote:
>>>
>>>> Maybe not intuitive, but this is by design. For performance reasons,
>>>> the compiler needs to know the layout of a struct, and it can only do that
>>>> if the definition is visible. Any workarounds require an indirection AFAIK,
>>>> as does implementing this as standard behavior. If you want hiding and abi
>>>> compatibility use the PIMPL idiom for private data. But realize that it
>>>> adds an extra indirection.
>>>>
>>>> -Tim
>>>>
>>>>
>>>> On Wednesday, October 30, 2013 4:39:17 AM UTC+1, fmatth...@gmail.comwrote:
>>>>>
>>>>> There is one major wart in C++ class design, and that is with private
>>>>> member functions required to be in the class definition.
>>>>>
>>>>> This has a number of problems:
>>>>> 1) Changing the private method's signature or adding/removing private
>>>>> methods requires everyone including the header to recompile. This is a huge
>>>>> problem for large projects with long recompilation times.
>>>>> 2) file static / anonymous namespace definitions in the .cc file
>>>>> cannot be used in the private method's signature. Anything used in the
>>>>> signature must be at least forward declared in the header, adding more
>>>>> symbol pollution.
>>>>> 3) For shared library interfaces, the private methods are extra
>>>>> unnecessary symbols that have to be managed.
>>>>> 4) Private method signatures or even the existence of private methods
>>>>> can depend on the underlying implementation. If the class has multiple
>>>>> implementations (e.g. different platforms), #defines and other conditional
>>>>> compilation mechanisms are required in the header file.
>>>>> 5) Its just bad encapsulation. Callers don't need to know anything
>>>>> about the functions which implement the class behavior.
>>>>>
>>>>> The only private declarations that should be required in the header
>>>>> are declarations required by the compiler. I believe all of those are:
>>>>> 1) Private data members (sizeof())
>>>>> 2) Private virtual methods (for inheriting)
>>>>> 3) Private non-virtual methods called by inline functions.
>>>>>
>>>>> One way to do this would be to extend the friend feature. We could
>>>>> define friend functions within the body of member functions. It might look
>>>>> like this:
>>>>>
>>>>> //foo.hh
>>>>>
>>>>> class Foo {
>>>>>   public:
>>>>>     void doWork();
>>>>>   private:
>>>>>     int _f;
>>>>> }
>>>>>
>>>>> //foo.cc
>>>>> static void doWorkHelper(Foo* f) {
>>>>>   doSomethingWith(f->_f);
>>>>> };
>>>>>
>>>>> void Foo::doWork() {
>>>>>   friend void doWorkHelper(Foo*);
>>>>>
>>>>>   doWorkHelper(this);
>>>>> }
>>>>>
>>>>> This has potential for abuse of course, but it would finally allow us
>>>>> to limit the list of declarations in the class definition to the bare
>>>>> minimum required by the compiler. When it comes to defining interfaces,
>>>>> less is always more.
>>>>> One other use of this feature could be to add a backdoor for unit
>>>>> tests.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>  --
>>>>
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposals+unsubscribe@isocpp.org.
>>>> To post to this group, send email to std-proposals@isocpp.org.
>>>> Visit this group at
>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>
>>>
>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">Their destructor is public. However, there can exist class=
es with protected nonvirtual destructors (that allow dynamic dispatch for c=
alling but not for destruction).<div>I&#39;m not sure whether a restriction=
 should be made to only allow private nonvirtual functions outside the clas=
s definition -- a rule could be added that the class layout may not be diff=
erent for any nonzero number of virtual functions, and the compiler could s=
ignal an error if a virtual function is to be added to a class whose defini=
tion doesn&#39;t contain any virtual functions.</div>
<div>In general I guess modules can solve this problem in a more generic wa=
y.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"=
>2013/11/4 Billy O&#39;Neal <span dir=3D"ltr">&lt;<a href=3D"mailto:billy.o=
neal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Actually that&#39;s a good =
point -- most of the iostreams classes&#39; virtual functions are all priva=
te, for example. The functions added in a single translation unit would hav=
e to be non-virtual.</div>
<div class=3D"gmail_extra"><div class=3D"im">

<br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a =
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github=
..com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>


<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div><div class=3D"h5"><div class=3D"gmail_quote">On Sun, Nov=
 3, 2013 at 5:44 PM, Philipp Stephani <span dir=3D"ltr">&lt;<a href=3D"mail=
to:p.stephani2@gmail.com" target=3D"_blank">p.stephani2@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Adding a virtual member functions to a class without other=
 virtual member functions does change the class layout. (I guess classes wh=
ose virtual member functions are all private don&#39;t occur in practice th=
ough.)<div>


<div><br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/11/4 Bil=
ly O&#39;Neal <span dir=3D"ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com=
" target=3D"_blank">billy.oneal@gmail.com</a>&gt;</span><br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;borde=
r-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid=
">



<div dir=3D"ltr">Private member *data* does need to be declared in the clas=
s definition so that callers know what size to lay out for the object. Priv=
ate member *functions* do not.</div><div class=3D"gmail_extra"><div>
<br clear=3D"all">

<div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>





<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div><div><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 1=
:39 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:shadowdrak@gmail.com" targ=
et=3D"_blank">shadowdrak@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;borde=
r-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid=
">





<div dir=3D"ltr">Maybe not intuitive, but this is by design. For performanc=
e reasons, the compiler needs to know the layout of a struct, and it can on=
ly do that if the definition is visible. Any workarounds require an indirec=
tion AFAIK, as does implementing this as standard behavior. If you want hid=
ing and abi compatibility use the PIMPL idiom for private data. But realize=
 that it adds an extra indirection.<div>





<div><br></div><div>-Tim<div><div><br><br>On Wednesday, October 30, 2013 4:=
39:17 AM UTC+1, <a href=3D"mailto:fmatth...@gmail.com" target=3D"_blank">fm=
atth...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">





<div dir=3D"ltr">There is one major wart in C++ class design, and that is w=
ith private member functions required to be in the class definition.<div><b=
r></div><div>This has a number of problems:</div><div>1) Changing the priva=
te method&#39;s signature or adding/removing private methods requires every=
one including the header to recompile. This is a huge problem for large pro=
jects with long recompilation times.</div>





<div>2) file static / anonymous namespace definitions in the .cc file canno=
t be used in the private method&#39;s signature. Anything used in the signa=
ture must be at least forward declared in the header, adding more symbol po=
llution.</div>





<div>3) For shared library interfaces, the private methods are extra unnece=
ssary symbols that have to be managed.</div><div>4) Private method signatur=
es or even the existence of private methods can depend on the underlying im=
plementation. If the class has multiple implementations (e.g. different pla=
tforms), #defines and other conditional compilation mechanisms are required=
 in the header file.</div>





<div>5) Its just bad encapsulation. Callers don&#39;t need to know anything=
 about the functions which implement the class behavior.</div><div><br></di=
v><div>The only private declarations that should be required in the header =
are declarations required by the compiler. I believe all of those are:</div=
>





<div>1) Private data members (sizeof())</div><div>2) Private virtual method=
s (for inheriting)</div><div>3) Private non-virtual methods called by inlin=
e functions.</div><div><br></div><div>One way to do this would be to extend=
 the friend feature. We could define friend functions within the body of me=
mber functions. It might look like this:</div>





<div><br></div><div>//foo.hh</div><div><br></div><div>class Foo {<br>=A0 pu=
blic:</div><div>=A0 =A0 void doWork();</div><div>=A0 private:</div><div>=A0=
 =A0 int _f;</div><div>}</div><div><br></div><div>//foo.cc</div><div>static=
 void doWorkHelper(Foo* f) {</div>





<div>=A0 doSomethingWith(f-&gt;_f);<br>};</div><div><br></div><div>void Foo=
::doWork() {<br>=A0 friend void doWorkHelper(Foo*);</div><div><br></div><di=
v>=A0 doWorkHelper(this);</div><div>}</div><div><br></div><div>This has pot=
ential for abuse of course, but it would finally allow us to limit the list=
 of declarations in the class definition to the bare minimum required by th=
e compiler. When it comes to defining interfaces, less is always more.</div=
>





<div>One other use of this feature could be to add a backdoor for unit test=
s.</div><div><br></div><div>Thoughts?</div></div></blockquote></div></div><=
/div></div></div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div></div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div><div class=3D"HOEnZb">=
<div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a1132f26ad2bfea04ea505d1a--

.

--001a11c3675e387b0a04ea5066ed
Content-Type: text/plain; charset=ISO-8859-1

2013/11/4 Philipp Stephani <p.stephani2@gmail.com>

> I'm not sure whether a restriction should be made to only allow private
> nonvirtual functions outside the class definition -- a rule could be added
> that the class layout may not be different for any nonzero number of
> virtual functions, and the compiler could signal an error if a virtual
> function is to be added to a class whose definition doesn't contain any
> virtual functions.
>

This is wrong: As already pointed out by the OP, all virtual functions can
be overridden and are therefore part of the interface, regardless of their
visibility.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/11/4 Philipp Stephani <span dir=3D"ltr">&lt;<a href=3D"mailto:=
p.stephani2@gmail.com" target=3D"_blank">p.stephani2@gmail.com</a>&gt;</spa=
n><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>I&#39;m not sure whether a restriction should be made=
 to only allow private nonvirtual functions outside the class definition --=
 a rule could be added that the class layout may not be different for any n=
onzero number of virtual functions, and the compiler could signal an error =
if a virtual function is to be added to a class whose definition doesn&#39;=
t contain any virtual functions.</div>
</div></blockquote><div><br></div><div>This is wrong: As already pointed ou=
t by the OP, all virtual functions can be overridden and are therefore part=
 of the interface, regardless of their visibility.=A0</div></div></div></di=
v>

<p></p>

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

--001a11c3675e387b0a04ea5066ed--

.

On segunda-feira, 4 de novembro de 2013 03:09:00, Philipp Stephani wrote:
> 2013/11/4 Philipp Stephani <p.stephani2@gmail.com>
>
> > I'm not sure whether a restriction should be made to only allow private
> > nonvirtual functions outside the class definition -- a rule could be added
> > that the class layout may not be different for any nonzero number of
> > virtual functions, and the compiler could signal an error if a virtual
> > function is to be added to a class whose definition doesn't contain any
> > virtual functions.
>
> This is wrong: As already pointed out by the OP, all virtual functions can
> be overridden and are therefore part of the interface, regardless of their
> visibility.

No, they cannot.

Overriding a virtual function may change the ABI. *Any* virtual declaration
must be visible to all callers.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

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

On 4 November 2013 04:36, Thiago Macieira <thiago@macieira.org> wrote:

> On segunda-feira, 4 de novembro de 2013 03:09:00, Philipp Stephani wrote:
> > 2013/11/4 Philipp Stephani <p.stephani2@gmail.com>
> >
> > > I'm not sure whether a restriction should be made to only allow private
> > > nonvirtual functions outside the class definition -- a rule could be
> added
> > > that the class layout may not be different for any nonzero number of
> > > virtual functions, and the compiler could signal an error if a virtual
> > > function is to be added to a class whose definition doesn't contain any
> > > virtual functions.
> >
> > This is wrong: As already pointed out by the OP, all virtual functions
> can
> > be overridden and are therefore part of the interface, regardless of
> their
> > visibility.
>
> No, they cannot.
>

They cannot? As in, virtual functions cannot be overridden? Are you thinking
about final here?


>
> Overriding a virtual function may change the ABI. *Any* virtual declaration
> must be visible to all callers.
>
>
>
Same question, I guess.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 November 2013 04:36, Thiago Macieira <span dir=3D"ltr">&lt;<a =
href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On segunda-feira, 4 de nov=
embro de 2013 03:09:00, Philipp Stephani wrote:<br>
&gt; 2013/11/4 Philipp Stephani &lt;<a href=3D"mailto:p.stephani2@gmail.com=
">p.stephani2@gmail.com</a>&gt;<br>
&gt;<br>
&gt; &gt; I&#39;m not sure whether a restriction should be made to only all=
ow private<br>
&gt; &gt; nonvirtual functions outside the class definition -- a rule could=
 be added<br>
&gt; &gt; that the class layout may not be different for any nonzero number=
 of<br>
&gt; &gt; virtual functions, and the compiler could signal an error if a vi=
rtual<br>
&gt; &gt; function is to be added to a class whose definition doesn&#39;t c=
ontain any<br>
&gt; &gt; virtual functions.<br>
&gt;<br>
&gt; This is wrong: As already pointed out by the OP, all virtual functions=
 can<br>
&gt; be overridden and are therefore part of the interface, regardless of t=
heir<br>
&gt; visibility.<br>
<br>
</div>No, they cannot.<br></blockquote><div><br></div><div>They cannot? As =
in, virtual functions cannot be overridden? Are you thinking<br>about final=
 here?<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Overriding a virtual function may change the ABI. *Any* virtual declaration=
<br>
must be visible to all callers.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></bloc=
kquote><div><br></div><div>Same question, I guess. <br></div></div><br></di=
v></div>

<p></p>

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

--047d7bdc90beb3b4dc04ea51fcdc--

.

On segunda-feira, 4 de novembro de 2013 06:02:39, Ville Voutilainen wrote:
> They cannot? As in, virtual functions cannot be overridden? Are you thinking
> about final here?
>
>
> > Overriding a virtual function may change the ABI. *Any* virtual
> > declaration
> > must be visible to all callers.

> Same question, I guess.

Ok, after rereading what I posted, looks like I might not have answered the
right post. So let me start over:

This thread is about adding methods to a class without having it in the main
class { } body, which is visible to all users. I support that idea.

However, that must be entirely restricted to non-virtual methods.

Adding a virtual method, like everyone who has done any binary compatibility
work knows, is not possible. That includes overrides. Any and all virtual
methods present in a given class -- whether new or overrides -- must be
declared in the class body and visible to all users.

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

--

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

.

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

On 4 November 2013 06:15, Thiago Macieira <thiago@macieira.org> wrote:

> On segunda-feira, 4 de novembro de 2013 06:02:39, Ville Voutilainen wrote:
> > They cannot? As in, virtual functions cannot be overridden? Are you
> thinking
> > about final here?
> >
> >
> > > Overriding a virtual function may change the ABI. *Any* virtual
> > > declaration
> > > must be visible to all callers.
>
> > Same question, I guess.
>
> Ok, after rereading what I posted, looks like I might not have answered the
> right post. So let me start over:
>
> This thread is about adding methods to a class without having it in the
> main
> class { } body, which is visible to all users. I support that idea.
>
> However, that must be entirely restricted to non-virtual methods.
>
> Adding a virtual method, like everyone who has done any binary
> compatibility
> work knows, is not possible. That includes overrides. Any and all virtual
> methods present in a given class -- whether new or overrides -- must be
> declared in the class body and visible to all users.
>
>
>
I still have trouble grokking the "that includes overrides" part. How does
adding
an override change the ABI?

--

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

--047d7bdc8afe8837ad04ea5286c9
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 4 November 2013 06:15, Thiago Macieira <span dir="ltr">&lt;<a href="mailto:thiago@macieira.org" target="_blank">thiago@macieira.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On segunda-feira, 4 de novembro de 2013 06:02:39, Ville Voutilainen wrote:<br>
&gt; They cannot? As in, virtual functions cannot be overridden? Are you thinking<br>
&gt; about final here?<br>
&gt;<br>
&gt;<br>
&gt; &gt; Overriding a virtual function may change the ABI. *Any* virtual<br>
&gt; &gt; declaration<br>
&gt; &gt; must be visible to all callers.<br>
<br>
&gt; Same question, I guess.<br>
<br>
</div>Ok, after rereading what I posted, looks like I might not have answered the<br>
right post. So let me start over:<br>
<br>
This thread is about adding methods to a class without having it in the main<br>
class { } body, which is visible to all users. I support that idea.<br>
<br>
However, that must be entirely restricted to non-virtual methods.<br>
<br>
Adding a virtual method, like everyone who has done any binary compatibility<br>
work knows, is not possible. That includes overrides. Any and all virtual<br>
methods present in a given class -- whether new or overrides -- must be<br>
declared in the class body and visible to all users.<br>
<div class="HOEnZb"><div class="h5"><br><br></div></div></blockquote><div><br></div><div>I still have trouble grokking the &quot;that includes overrides&quot; part. How does adding<br>an override change the ABI? <br></div>
</div><br></div></div>

<p></p>

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

--047d7bdc8afe8837ad04ea5286c9--

.

--089e0149d0aea9c91a04ea531ba1
Content-Type: text/plain; charset=ISO-8859-1

It is overridden in one translation unit, but not in another translation
unit. That means the vtbl in each translation unit differs, which leads to
ODR violations. (This is assuming virtual functions are implemented in
terms of vtbls, but all implementations of which I am aware implement
things that way)

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sun, Nov 3, 2013 at 8:41 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 4 November 2013 06:15, Thiago Macieira <thiago@macieira.org> wrote:
>
>> On segunda-feira, 4 de novembro de 2013 06:02:39, Ville Voutilainen wrote:
>> > They cannot? As in, virtual functions cannot be overridden? Are you
>> thinking
>> > about final here?
>> >
>> >
>> > > Overriding a virtual function may change the ABI. *Any* virtual
>> > > declaration
>> > > must be visible to all callers.
>>
>> > Same question, I guess.
>>
>> Ok, after rereading what I posted, looks like I might not have answered
>> the
>> right post. So let me start over:
>>
>> This thread is about adding methods to a class without having it in the
>> main
>> class { } body, which is visible to all users. I support that idea.
>>
>> However, that must be entirely restricted to non-virtual methods.
>>
>> Adding a virtual method, like everyone who has done any binary
>> compatibility
>> work knows, is not possible. That includes overrides. Any and all virtual
>> methods present in a given class -- whether new or overrides -- must be
>> declared in the class body and visible to all users.
>>
>>
>>
> I still have trouble grokking the "that includes overrides" part. How does
> adding
> an override change the ABI?
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">It is overridden in one translation unit, but not in anoth=
er translation unit. That means the vtbl in each translation unit differs, =
which leads to ODR violations. (This is assuming virtual functions are impl=
emented in terms of vtbls, but all implementations of which I am aware impl=
ement things that way)</div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 8:41 PM, Ville Vo=
utilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.c=
om" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">On 4 November 2013 06:15, Thiago Macieira <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thi=
ago@macieira.org</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div>On segunda-feira, 4 de novembro de 2013 06:02:39, Vil=
le Voutilainen wrote:<br>


&gt; They cannot? As in, virtual functions cannot be overridden? Are you th=
inking<br>
&gt; about final here?<br>
&gt;<br>
&gt;<br>
&gt; &gt; Overriding a virtual function may change the ABI. *Any* virtual<b=
r>
&gt; &gt; declaration<br>
&gt; &gt; must be visible to all callers.<br>
<br>
&gt; Same question, I guess.<br>
<br>
</div>Ok, after rereading what I posted, looks like I might not have answer=
ed the<br>
right post. So let me start over:<br>
<br>
This thread is about adding methods to a class without having it in the mai=
n<br>
class { } body, which is visible to all users. I support that idea.<br>
<br>
However, that must be entirely restricted to non-virtual methods.<br>
<br>
Adding a virtual method, like everyone who has done any binary compatibilit=
y<br>
work knows, is not possible. That includes overrides. Any and all virtual<b=
r>
methods present in a given class -- whether new or overrides -- must be<br>
declared in the class body and visible to all users.<br>
<div><div><br><br></div></div></blockquote><div><br></div></div><div>I stil=
l have trouble grokking the &quot;that includes overrides&quot; part. How d=
oes adding<br>an override change the ABI? <br></div>
</div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e0149d0aea9c91a04ea531ba1--

.

On segunda-feira, 4 de novembro de 2013 06:41:12, Ville Voutilainen wrote:
> I still have trouble grokking the "that includes overrides" part. How does
> adding an override change the ABI?

See these two exceptions to overriding virtuals
http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a_virtual_with_a_covariant_return_with_different_top_address
http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a_virtual_that_doesn.27t_come_from_a_primary_base

These two overrides are actually new virtuals in disguise under the portable
IA-64 C++ ABI used by GCC and Clang. Since those two cases are possible, we
have to take into consideration the possibility that other overrides are
actually new virtuals under other ABIs.

That means we must treat all overrides as if they were new virtuals for the
purpose of defining the standard.

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

--

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

.

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

On 4 November 2013 07:28, Thiago Macieira <thiago@macieira.org> wrote:

> On segunda-feira, 4 de novembro de 2013 06:41:12, Ville Voutilainen wrote:
> > I still have trouble grokking the "that includes overrides" part. How
> does
> > adding an override change the ABI?
>
> See these two exceptions to overriding virtuals
>
> http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a_virtual_with_a_covariant_return_with_different_top_address
>
> http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a_virtual_that_doesn.27t_come_from_a_primary_base
>
> These two overrides are actually new virtuals in disguise under the
> portable
> IA-64 C++ ABI used by GCC and Clang. Since those two cases are possible, we
> have to take into consideration the possibility that other overrides are
> actually new virtuals under other ABIs.
>
> That means we must treat all overrides as if they were new virtuals for the
> purpose of defining the standard.
>

Thanks for the explanation. Also, as Billy pointed out, it would be rather
weird
to have any attempts to add "virtual extension methods" in one TU and not
have
them in another. It would be a step towards object inheritance from class
inheritance,
and I don't think we want to take such steps.

I still don't think the (specification/implementation/teaching/etc.) cost
of extension
methods is palatable. There are well-known solutions to the problem that
are good
enough that the benefit of adding extension methods to the language is
unconvincing
to me.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 November 2013 07:28, Thiago Macieira <span dir=3D"ltr">&lt;<a =
href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On segunda-feira, 4 de nov=
embro de 2013 06:41:12, Ville Voutilainen wrote:<br>
&gt; I still have trouble grokking the &quot;that includes overrides&quot; =
part. How does<br>
&gt; adding an override change the ABI?<br>
<br>
</div>See these two exceptions to overriding virtuals<br>
<a href=3D"http://techbase.kde.org/Policies/Binary_Compatibility_Examples#O=
verride_a_virtual_with_a_covariant_return_with_different_top_address" targe=
t=3D"_blank">http://techbase.kde.org/Policies/Binary_Compatibility_Examples=
#Override_a_virtual_with_a_covariant_return_with_different_top_address</a><=
br>

<a href=3D"http://techbase.kde.org/Policies/Binary_Compatibility_Examples#O=
verride_a_virtual_that_doesn.27t_come_from_a_primary_base" target=3D"_blank=
">http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a=
_virtual_that_doesn.27t_come_from_a_primary_base</a><br>

<br>
These two overrides are actually new virtuals in disguise under the portabl=
e<br>
IA-64 C++ ABI used by GCC and Clang. Since those two cases are possible, we=
<br>
have to take into consideration the possibility that other overrides are<br=
>
actually new virtuals under other ABIs.<br>
<br>
That means we must treat all overrides as if they were new virtuals for the=
<br>
purpose of defining the standard.<br></blockquote><div><br></div><div>Thank=
s for the explanation. Also, as Billy pointed out, it would be rather weird=
<br>to have any attempts to add &quot;virtual extension methods&quot; in on=
e TU and not have<br>
them in another. It would be a step towards object inheritance from class i=
nheritance,<br>and I don&#39;t think we want to take such steps.<br><br></d=
iv><div>I still don&#39;t think the (specification/implementation/teaching/=
etc.) cost of extension<br>
methods is palatable. There are well-known solutions to the problem that ar=
e good<br>enough that the benefit of adding extension methods to the langua=
ge is unconvincing<br>to me.<br></div></div></div></div>

<p></p>

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

--047d7bdc78cced96c904ea537045--

.

On segunda-feira, 4 de novembro de 2013 07:46:44, Ville Voutilainen wrote:
> I still don't think the (specification/implementation/teaching/etc.) cost of
> extension methods is palatable. There are well-known solutions to the
> problem that are good enough that the benefit of adding extension methods
> to the language is unconvincing to me.

Well, the one thing I'd want is to have a real static (as in file-local)
method, to control my exports.

I know all the techniques. But I am forced to use compiler extensions in order
to control the list of exports from my TUs and libraries, to degrading the
linkers' performances due to way too many symbols.

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

--

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

.

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

I'm not sure "extension methods" are related here -- at least, anywhere
else I've seen that concept they've not been able to access private details
of a class.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sun, Nov 3, 2013 at 9:46 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 4 November 2013 07:28, Thiago Macieira <thiago@macieira.org> wrote:
>
>> On segunda-feira, 4 de novembro de 2013 06:41:12, Ville Voutilainen wrote:
>> > I still have trouble grokking the "that includes overrides" part. How
>> does
>> > adding an override change the ABI?
>>
>> See these two exceptions to overriding virtuals
>>
>> http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a_virtual_with_a_covariant_return_with_different_top_address
>>
>> http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a_virtual_that_doesn.27t_come_from_a_primary_base
>>
>> These two overrides are actually new virtuals in disguise under the
>> portable
>> IA-64 C++ ABI used by GCC and Clang. Since those two cases are possible,
>> we
>> have to take into consideration the possibility that other overrides are
>> actually new virtuals under other ABIs.
>>
>> That means we must treat all overrides as if they were new virtuals for
>> the
>> purpose of defining the standard.
>>
>
> Thanks for the explanation. Also, as Billy pointed out, it would be rather
> weird
> to have any attempts to add "virtual extension methods" in one TU and not
> have
> them in another. It would be a step towards object inheritance from class
> inheritance,
> and I don't think we want to take such steps.
>
> I still don't think the (specification/implementation/teaching/etc.) cost
> of extension
> methods is palatable. There are well-known solutions to the problem that
> are good
> enough that the benefit of adding extension methods to the language is
> unconvincing
> to me.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra">I&#39;m not sure &quot;extensio=
n methods&quot; are related here -- at least, anywhere else I&#39;ve seen t=
hat concept they&#39;ve not been able to access private details of a class.=
<br clear=3D"all">

<div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>


<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 9:46 PM, Ville Vo=
utilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.c=
om" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">


<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div>On 4 November 2013 07:28, Thiago Macieira <span dir=3D"ltr">&l=
t;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.=
org</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div>On segunda-feira, 4 de novembro de 2013 06:41:12, Vil=
le Voutilainen wrote:<br>



&gt; I still have trouble grokking the &quot;that includes overrides&quot; =
part. How does<br>
&gt; adding an override change the ABI?<br>
<br>
</div>See these two exceptions to overriding virtuals<br>
<a href=3D"http://techbase.kde.org/Policies/Binary_Compatibility_Examples#O=
verride_a_virtual_with_a_covariant_return_with_different_top_address" targe=
t=3D"_blank">http://techbase.kde.org/Policies/Binary_Compatibility_Examples=
#Override_a_virtual_with_a_covariant_return_with_different_top_address</a><=
br>




<a href=3D"http://techbase.kde.org/Policies/Binary_Compatibility_Examples#O=
verride_a_virtual_that_doesn.27t_come_from_a_primary_base" target=3D"_blank=
">http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Override_a=
_virtual_that_doesn.27t_come_from_a_primary_base</a><br>




<br>
These two overrides are actually new virtuals in disguise under the portabl=
e<br>
IA-64 C++ ABI used by GCC and Clang. Since those two cases are possible, we=
<br>
have to take into consideration the possibility that other overrides are<br=
>
actually new virtuals under other ABIs.<br>
<br>
That means we must treat all overrides as if they were new virtuals for the=
<br>
purpose of defining the standard.<br></blockquote><div><br></div></div><div=
>Thanks for the explanation. Also, as Billy pointed out, it would be rather=
 weird<br>to have any attempts to add &quot;virtual extension methods&quot;=
 in one TU and not have<br>



them in another. It would be a step towards object inheritance from class i=
nheritance,<br>and I don&#39;t think we want to take such steps.<br><br></d=
iv><div>I still don&#39;t think the (specification/implementation/teaching/=
etc.) cost of extension<br>



methods is palatable. There are well-known solutions to the problem that ar=
e good<br>enough that the benefit of adding extension methods to the langua=
ge is unconvincing<br>to me.<br></div></div></div></div><div>
<div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--047d7b6740744ba8c104ea539baf--

.

------=_Part_3918_17438284.1383571102802
Content-Type: text/plain; charset=ISO-8859-1



On Monday, November 4, 2013 2:05:15 AM UTC+1, Billy O'Neal wrote:
>
> Private member *data* does need to be declared in the class definition so
> that callers know what size to lay out for the object. Private member
> *functions* do not.
>
> Not entirely true. In general, callers don't need to know the layout. The
layout is (only?) required when accessing data members, the size is only
required when creating an object on the stack.
Not requiring private data members in the header would be nice too IMO.

--

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

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

<div dir=3D"ltr"><br><br>On Monday, November 4, 2013 2:05:15 AM UTC+1, Bill=
y O'Neal 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=
">Private member *data* does need to be declared in the class definition so=
 that callers know what size to lay out for the object. Private member *fun=
ctions* do not.</div><div><br></div></blockquote><div>Not entirely true. In=
 general, callers don't need to know the layout. The layout is (only?) requ=
ired when accessing data members, the size is only required when creating a=
n object on the stack.</div><div>Not requiring private data members in the =
header would be nice too IMO.</div></div>

<p></p>

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

------=_Part_3918_17438284.1383571102802--

.

--Apple-Mail=_6EAAC587-C2CC-46E4-8DBF-28E71BCBA705
Content-Type: text/plain; charset=ISO-8859-1


On Nov 4, 2013, at 5:18 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:

>
>
> On Monday, November 4, 2013 2:05:15 AM UTC+1, Billy O'Neal wrote:
> Private member *data* does need to be declared in the class definition so that callers know what size to lay out for the object. Private member *functions* do not.
>
> Not entirely true. In general, callers don't need to know the layout. The layout is (only?) required when accessing data members, the size is only required when creating an object on the stack.

Counterexample:
 struct Foo;
 Foo * f = new Foo;

This calls operator new ( size_t ) to allocate memory.
How much memory should be allocated?


> Not requiring private data members in the header would be nice too IMO.

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

--

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

--Apple-Mail=_6EAAC587-C2CC-46E4-8DBF-28E71BCBA705
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 4,=
 2013, at 5:18 AM, Olaf van der Spek &lt;<a href=3D"mailto:olafvdspek@gmail=
..com">olafvdspek@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchan=
ge-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><br><br>On Monday, N=
ovember 4, 2013 2:05:15 AM UTC+1, Billy O'Neal wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr">Private member *data* does need to =
be declared in the class definition so that callers know what size to lay o=
ut for the object. Private member *functions* do not.</div><div><br></div><=
/blockquote><div>Not entirely true. In general, callers don't need to know =
the layout. The layout is (only?) required when accessing data members, the=
 size is only required when creating an object on the stack.</div></div></b=
lockquote><div><br></div>Counterexample:</div><div><span class=3D"Apple-tab=
-span" style=3D"white-space:pre"> </span>struct Foo;</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Foo * f =3D new Foo;<=
/div><div><br></div><div>This calls operator new ( size_t ) to allocate mem=
ory.</div><div>How much memory should be allocated?</div><div><br></div><di=
v><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr"><div>Not requir=
ing private data members in the header would be nice too IMO.</div></div>
</blockquote></div><br><div apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; color:=
 rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-=
spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decoration=
s-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-widt=
h: 0px; font-size: medium; ">-- Marshall<br><br>Marshall Clow &nbsp; &nbsp;=
 Idio Software &nbsp; &lt;<a href=3D"mailto:mclow.lists@gmail.com">mailto:m=
clow.lists@gmail.com</a>&gt;<br><br>A.D. 1517: Martin Luther nails his 95 T=
heses to the church door and is promptly moderated down to (-1, Flamebait).=
<br>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;-- Yu Suzuki</span>

</div>
<br></body></html>

<p></p>

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

--Apple-Mail=_6EAAC587-C2CC-46E4-8DBF-28E71BCBA705--

.

On Mon, Nov 4, 2013 at 3:01 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
> Not entirely true. In general, callers don't need to know the layout. The
> layout is (only?) required when accessing data members, the size is only
> required when creating an object on the stack.
>
>
> Counterexample:
> struct Foo;
> Foo * f = new Foo;
>
> This calls operator new ( size_t ) to allocate memory.
> How much memory should be allocated?

One could use a factory function
Or some (automatic) get_size() function could be generated

--

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

.

On segunda-feira, 4 de novembro de 2013 15:14:56, Olaf van der Spek wrote:
> One could use a factory function
> Or some (automatic) get_size() function could be generated

Let's not go there, please.

Instead, if this is a desired feature, let's just make it so the compiler
knows that it's a partial declaration. Until the declaration is full, the type
is incomplete and its size is not known.

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

--

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

.

On Mon, Nov 4, 2013 at 5:22 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On segunda-feira, 4 de novembro de 2013 15:14:56, Olaf van der Spek wrote:
>> One could use a factory function
>> Or some (automatic) get_size() function could be generated
>
> Let's not go there, please.
>
> Instead, if this is a desired feature, let's just make it so the compiler
> knows that it's a partial declaration. Until the declaration is full, the type
> is incomplete and its size is not known.

The idea is to move all private parts out of the header, avoiding
rebuilds on changes to private parts.


--
Olaf

--

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

.

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

Allowing the declaration of private member data outside of the header would
also make inheritance or composition with this class impossible, so any use
of this class would need to be through a pointer. In this case, what would
be the advantage of this with respect to using the pimpl idiom?


2013/11/4 Olaf van der Spek <olafvdspek@gmail.com>

> On Mon, Nov 4, 2013 at 5:22 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
> > On segunda-feira, 4 de novembro de 2013 15:14:56, Olaf van der Spek
> wrote:
> >> One could use a factory function
> >> Or some (automatic) get_size() function could be generated
> >
> > Let's not go there, please.
> >
> > Instead, if this is a desired feature, let's just make it so the compiler
> > knows that it's a partial declaration. Until the declaration is full,
> the type
> > is incomplete and its size is not known.
>
> The idea is to move all private parts out of the header, avoiding
> rebuilds on changes to private parts.
>
>
> --
> Olaf
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">Allowing the declaration of private member data outside of=
 the header would also make inheritance or composition with this class impo=
ssible, so any use of this class would need to be through a pointer. In thi=
s case, what would be the advantage of this with respect to using the pimpl=
 idiom?</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/11/4 Ola=
f van der Spek <span dir=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com=
" target=3D"_blank">olafvdspek@gmail.com</a>&gt;</span><br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<div class=3D"im">On Mon, Nov 4, 2013 at 5:22 PM, Thiago Macieira &lt;<a hr=
ef=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt; On segunda-feira, 4 de novembro de 2013 15:14:56, Olaf van der Spek wr=
ote:<br>
&gt;&gt; One could use a factory function<br>
&gt;&gt; Or some (automatic) get_size() function could be generated<br>
&gt;<br>
&gt; Let&#39;s not go there, please.<br>
&gt;<br>
&gt; Instead, if this is a desired feature, let&#39;s just make it so the c=
ompiler<br>
&gt; knows that it&#39;s a partial declaration. Until the declaration is fu=
ll, the type<br>
&gt; is incomplete and its size is not known.<br>
<br>
</div>The idea is to move all private parts out of the header, avoiding<br>
rebuilds on changes to private parts.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
Olaf<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--047d7bd7656216f5bb04ea5d00e8--

.

On segunda-feira, 4 de novembro de 2013 18:11:01, xavi wrote:
> Allowing the declaration of private member data outside of the header would
> also make inheritance or composition with this class impossible, so any use
> of this class would need to be through a pointer. In this case, what would
> be the advantage of this with respect to using the pimpl idiom?

It would simplify the code for the implementation. A good pimpl solution
requires all public functions to be mirrored in the private so that you don't
get a double indirection to the data (it also improves code generation because
the private class isn't exported).

This would be basically a way for C++ place member functions in opaque types.

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

--

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

.

--089e011830f47eef0c04ea5d6175
Content-Type: text/plain; charset=ISO-8859-1

>The idea is to move all private parts out of the header, avoiding rebuilds
on changes to private parts.

That isn't possible in a language with value semantics everywhere. Java and
C# allow this by forcing all interactions with a class to occur through
pointers / references, and by generating code at runtime for correct
inheritance behavior. Those aren't acceptable tradeoffs for a language like
C++.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Nov 4, 2013 at 8:28 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Mon, Nov 4, 2013 at 5:22 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
> > On segunda-feira, 4 de novembro de 2013 15:14:56, Olaf van der Spek
> wrote:
> >> One could use a factory function
> >> Or some (automatic) get_size() function could be generated
> >
> > Let's not go there, please.
> >
> > Instead, if this is a desired feature, let's just make it so the compiler
> > knows that it's a partial declaration. Until the declaration is full,
> the type
> > is incomplete and its size is not known.
>
> The idea is to move all private parts out of the header, avoiding
> rebuilds on changes to private parts.
>
>
> --
> Olaf
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><div>&gt;The idea is to move all private parts out of the =
header, avoiding rebuilds on changes to private parts.</div><div>=A0</div><=
div>That isn&#39;t possible in a language with value semantics everywhere. =
Java and C# allow this by forcing all interactions with a class to occur th=
rough pointers / references, and by generating code at runtime for correct =
inheritance behavior. Those aren&#39;t acceptable tradeoffs for a language =
like C++.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 4, 2013 at 8:28 AM, Olaf van=
 der Spek <span dir=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" tar=
get=3D"_blank">olafvdspek@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

<div class=3D"im">On Mon, Nov 4, 2013 at 5:22 PM, Thiago Macieira &lt;<a hr=
ef=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt; On segunda-feira, 4 de novembro de 2013 15:14:56, Olaf van der Spek wr=
ote:<br>
&gt;&gt; One could use a factory function<br>
&gt;&gt; Or some (automatic) get_size() function could be generated<br>
&gt;<br>
&gt; Let&#39;s not go there, please.<br>
&gt;<br>
&gt; Instead, if this is a desired feature, let&#39;s just make it so the c=
ompiler<br>
&gt; knows that it&#39;s a partial declaration. Until the declaration is fu=
ll, the type<br>
&gt; is incomplete and its size is not known.<br>
<br>
</div>The idea is to move all private parts out of the header, avoiding<br>
rebuilds on changes to private parts.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
Olaf<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e011830f47eef0c04ea5d6175--

.

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

On Sun, Nov 3, 2013 at 9:10 AM, <mitchnull@gmail.com> wrote:

> Hello,
>
>    I've been thinking about a new proposal for a "class implementation
> namespace", where I initially thought to only allow member function
> implementations that were already declared, but reading this proposal I
> realized that allowing new private member function declarations would solve
> your problem. It would look something like this using your example:
>
> //foo.hh
>
> class Foo {
>   public:
>     void doWork();
>   private:
>     int _f;
> }
>
> //foo.cc:
>
> class Foo namespace {
>

"class X namespace" looks a lot like "allow me to violate access control
here, please".

I think you should require the class to opt into this somehow (perhaps by
requiring a forward declaration of this inside the class body, or requiring
every such namespace to contain a member of the class).

But since we're brainstorming here, we can get most of the benefit here
with extension methods alone:

// foo.h
class Foo {
public:
  void doWork();
private:
  int _f;
  friend struct FooImpl;
};

// foo.cc
struct FooImpl {
  static void doWorkHelper(Foo *this) {
    doSomethingWith(_f);
  }
};

void Foo::doWork() {
  doWorkHelper();
}

// optional forward declaraction:
>   void doWrokHelper();  // implicitly private
>
> // definition of doWorkHelper() private member function declared above:
>   void doWorkHelper() {
>      doSomethingWith(_f);
>   }
>
> // definition of doWork() public member function declared in Foo.hh:
>   void doWork() {
>      doWorkHelper();
>   }
> } // end class Foo namespace (the "implementation namespace")
>
> In my opinion this "class implementation namespace" would be a cleaner
> solution to your issue, and would also have additional benefits:
>   - template class member function implementations could be separated from
> the main class declaration without having to resort to ugly repetitions
>   - member functions returning nested classes could be written the same
> way as declared (this is a common problem for new learners according to my
> experience)
>   - in general, the "implementation" part would be syntactically similar
> to the declaration part, without unnecessary repetition of the class name,
> etc
>
> I'll try to write a detailed proposal next week (I first wanted to
> implement this concept in clang, but I guess it's better to get out the
> idea first...)
>
> cheers,
> mitch
>
> On Wednesday, October 30, 2013 4:39:17 AM UTC+1, fmatth...@gmail.comwrote:
>>
>> There is one major wart in C++ class design, and that is with private
>> member functions required to be in the class definition.
>>
>> This has a number of problems:
>> 1) Changing the private method's signature or adding/removing private
>> methods requires everyone including the header to recompile. This is a huge
>> problem for large projects with long recompilation times.
>> 2) file static / anonymous namespace definitions in the .cc file cannot
>> be used in the private method's signature. Anything used in the signature
>> must be at least forward declared in the header, adding more symbol
>> pollution.
>> 3) For shared library interfaces, the private methods are extra
>> unnecessary symbols that have to be managed.
>> 4) Private method signatures or even the existence of private methods can
>> depend on the underlying implementation. If the class has multiple
>> implementations (e.g. different platforms), #defines and other conditional
>> compilation mechanisms are required in the header file.
>> 5) Its just bad encapsulation. Callers don't need to know anything about
>> the functions which implement the class behavior.
>>
>> The only private declarations that should be required in the header are
>> declarations required by the compiler. I believe all of those are:
>> 1) Private data members (sizeof())
>> 2) Private virtual methods (for inheriting)
>> 3) Private non-virtual methods called by inline functions.
>>
>> One way to do this would be to extend the friend feature. We could define
>> friend functions within the body of member functions. It might look like
>> this:
>>
>> //foo.hh
>>
>> class Foo {
>>   public:
>>     void doWork();
>>   private:
>>     int _f;
>> }
>>
>> //foo.cc
>> static void doWorkHelper(Foo* f) {
>>   doSomethingWith(f->_f);
>> };
>>
>> void Foo::doWork() {
>>   friend void doWorkHelper(Foo*);
>>
>>   doWorkHelper(this);
>> }
>>
>> This has potential for abuse of course, but it would finally allow us to
>> limit the list of declarations in the class definition to the bare minimum
>> required by the compiler. When it comes to defining interfaces, less is
>> always more.
>> One other use of this feature could be to add a backdoor for unit tests.
>>
>> Thoughts?
>>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">On Sun, Nov 3, 2013 at 9:10 AM,  <span dir=3D"ltr">&lt;<a =
href=3D"mailto:mitchnull@gmail.com" target=3D"_blank">mitchnull@gmail.com</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hello,<div><br></div><div>=A0 =A0I&#39;ve been thinking ab=
out a new proposal for a &quot;class implementation namespace&quot;, where =
I initially thought to only allow member function implementations that were=
 already declared, but reading this proposal I realized that allowing new p=
rivate member function declarations would solve your problem. It would look=
 something like this using your example:</div>
<div><br></div><div><div class=3D"im"><div>//foo.hh</div><div><br></div><di=
v>class Foo {<br>=A0 public:</div><div>=A0 =A0 void doWork();</div><div>=A0=
 private:</div><div>=A0 =A0 int _f;</div><div>}</div><div><br></div></div><=
div>//foo.cc:</div>
<div><br></div><div>class Foo namespace {</div></div></div></blockquote><di=
v><br></div><div>&quot;class X namespace&quot; looks a lot like &quot;allow=
 me to violate access control here, please&quot;.</div><div><br></div><div>
I think you should require the class to opt into this somehow (perhaps by r=
equiring a forward declaration of this inside the class body, or requiring =
every such namespace to contain a member of the class).</div><div><br></div=
>
<div>But since we&#39;re brainstorming here, we can get most of the benefit=
 here with extension methods alone:</div><div><br></div><div>// foo.h</div>=
<div>class Foo {</div><div>public:</div><div>=A0 void doWork();</div><div>
private:</div><div>=A0 int _f;</div><div>=A0 friend struct FooImpl;</div><d=
iv>};</div><div><br></div><div>// foo.cc</div><div>struct FooImpl {</div><d=
iv>=A0 static void doWorkHelper(Foo *this) {</div><div>=A0 =A0 doSomethingW=
ith(_f);</div>
<div>=A0 }</div><div>};</div><div><br></div><div>void Foo::doWork() {</div>=
<div>=A0 doWorkHelper();</div><div>}</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div><div>// optional forward declaraction:</div><div>=A0 =
void doWrokHelper(); =A0// implicitly private</div><div><br></div><div>// d=
efinition of doWorkHelper() private member function declared above:</div><d=
iv>
=A0 void doWorkHelper() {</div><div>=A0 =A0 =A0doSomethingWith(_f);</div><d=
iv>=A0 }</div><div>=A0=A0</div><div>// definition of doWork() public member=
 function declared in Foo.hh:</div><div>=A0 void doWork() {</div><div>=A0 =
=A0 =A0doWorkHelper();</div>
<div>=A0 }</div><div>} // end class Foo namespace (the &quot;implementation=
 namespace&quot;)</div><div><br></div><div>In my opinion this &quot;class i=
mplementation namespace&quot; would be a cleaner solution to your issue, an=
d would also have additional benefits:</div>
</div><div>=A0 - template class member function implementations could be se=
parated from the main class declaration without having to resort to ugly re=
petitions</div><div>=A0 - member functions returning nested classes could b=
e written the same way as declared (this is a common problem for new learne=
rs according to my experience)</div>
<div>=A0 - in general, the &quot;implementation&quot; part would be syntact=
ically similar to the declaration part, without unnecessary repetition of t=
he class name, etc</div><div><br></div><div>I&#39;ll try to write a detaile=
d proposal next week (I first wanted to implement this concept in clang, bu=
t I guess it&#39;s better to get out the idea first...)</div>
<div><br></div><div>cheers,</div><div>mitch</div><div><div class=3D"h5"><di=
v><br>On Wednesday, October 30, 2013 4:39:17 AM UTC+1, <a href=3D"mailto:fm=
atth...@gmail.com" target=3D"_blank">fmatth...@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">There is one major wart in C++ class design, and that is w=
ith private member functions required to be in the class definition.<div><b=
r></div><div>This has a number of problems:</div><div>1) Changing the priva=
te method&#39;s signature or adding/removing private methods requires every=
one including the header to recompile. This is a huge problem for large pro=
jects with long recompilation times.</div>
<div>2) file static / anonymous namespace definitions in the .cc file canno=
t be used in the private method&#39;s signature. Anything used in the signa=
ture must be at least forward declared in the header, adding more symbol po=
llution.</div>
<div>3) For shared library interfaces, the private methods are extra unnece=
ssary symbols that have to be managed.</div><div>4) Private method signatur=
es or even the existence of private methods can depend on the underlying im=
plementation. If the class has multiple implementations (e.g. different pla=
tforms), #defines and other conditional compilation mechanisms are required=
 in the header file.</div>
<div>5) Its just bad encapsulation. Callers don&#39;t need to know anything=
 about the functions which implement the class behavior.</div><div><br></di=
v><div>The only private declarations that should be required in the header =
are declarations required by the compiler. I believe all of those are:</div=
>
<div>1) Private data members (sizeof())</div><div>2) Private virtual method=
s (for inheriting)</div><div>3) Private non-virtual methods called by inlin=
e functions.</div><div><br></div><div>One way to do this would be to extend=
 the friend feature. We could define friend functions within the body of me=
mber functions. It might look like this:</div>
<div><br></div><div>//foo.hh</div><div><br></div><div>class Foo {<br>=A0 pu=
blic:</div><div>=A0 =A0 void doWork();</div><div>=A0 private:</div><div>=A0=
 =A0 int _f;</div><div>}</div><div><br></div><div>//foo.cc</div><div>static=
 void doWorkHelper(Foo* f) {</div>
<div>=A0 doSomethingWith(f-&gt;_f);<br>};</div><div><br></div><div>void Foo=
::doWork() {<br>=A0 friend void doWorkHelper(Foo*);</div><div><br></div><di=
v>=A0 doWorkHelper(this);</div><div>}</div><div><br></div><div>This has pot=
ential for abuse of course, but it would finally allow us to limit the list=
 of declarations in the class definition to the bare minimum required by th=
e compiler. When it comes to defining interfaces, less is always more.</div=
>
<div>One other use of this feature could be to add a backdoor for unit test=
s.</div><div><br></div><div>Thoughts?</div></div></blockquote></div></div><=
/div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--047d7bacba9a57e11604ea5db4eb--

.

--089e013cba283d00be04ea5de432
Content-Type: text/plain; charset=ISO-8859-1

As long as you store the pimpl pointer in a local variable (so that the
compiler knows that the pointer doesn't change no matter what you call),
the compiler can generate exactly the same code for accessing members of
pimpl as it would for accessing members of this (which is a pointer, after
all). As for the private class being exported, that's the kind of details
that the standard usually leaves to implementations, and a good compiler
with link-time optimization would be able to remove these symbols anyway.


2013/11/4 Thiago Macieira <thiago@macieira.org>

> On segunda-feira, 4 de novembro de 2013 18:11:01, xavi wrote:
> > Allowing the declaration of private member data outside of the header
> would
> > also make inheritance or composition with this class impossible, so any
> use
> > of this class would need to be through a pointer. In this case, what
> would
> > be the advantage of this with respect to using the pimpl idiom?
>
> It would simplify the code for the implementation. A good pimpl solution
> requires all public functions to be mirrored in the private so that you
> don't
> get a double indirection to the data (it also improves code generation
> because
> the private class isn't exported).
>
> This would be basically a way for C++ place member functions in opaque
> types.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">As long as you store the pimpl pointer in a local variable=
 (so that the compiler knows that the pointer doesn&#39;t change no matter =
what you call), the compiler can generate exactly the same code for accessi=
ng members of pimpl as it would for accessing members of this (which is a p=
ointer, after all). As for the private class being exported, that&#39;s the=
 kind of details that the standard usually leaves to implementations, and a=
 good compiler with link-time optimization would be able to remove these sy=
mbols anyway.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/11/4 Thi=
ago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" t=
arget=3D"_blank">thiago@macieira.org</a>&gt;</span><br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<div class=3D"im">On segunda-feira, 4 de novembro de 2013 18:11:01, xavi wr=
ote:<br>
&gt; Allowing the declaration of private member data outside of the header =
would<br>
&gt; also make inheritance or composition with this class impossible, so an=
y use<br>
&gt; of this class would need to be through a pointer. In this case, what w=
ould<br>
&gt; be the advantage of this with respect to using the pimpl idiom?<br>
<br>
</div>It would simplify the code for the implementation. A good pimpl solut=
ion<br>
requires all public functions to be mirrored in the private so that you don=
&#39;t<br>
get a double indirection to the data (it also improves code generation beca=
use<br>
the private class isn&#39;t exported).<br>
<br>
This would be basically a way for C++ place member functions in opaque type=
s.<br>
<div class=3D"im HOEnZb"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e013cba283d00be04ea5de432--

.

On segunda-feira, 4 de novembro de 2013 19:14:48, xavi wrote:
> As long as you store the pimpl pointer in a local variable (so that the
> compiler knows that the pointer doesn't change no matter what you call),
> the compiler can generate exactly the same code for accessing members of
> pimpl as it would for accessing members of this (which is a pointer, after
> all). As for the private class being exported, that's the kind of details
> that the standard usually leaves to implementations, and a good compiler
> with link-time optimization would be able to remove these symbols anyway.

It's the kind of detail that the standard can make easier for the compilers,
so the compilers can generate better code under more use-cases.

Link-time optimisation isn't enough in some cases, isn't possible in some
others, and isn't state-of-the-art yet.

Maybe the solution will come with modules, when we can finally have a
standardised syntax for "this method is called by other modules" versus "this
method is never called externally"

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

--

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

.

On Mon, Nov 4, 2013 at 1:01 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>> //foo.cc:
>>
>> class Foo namespace {
>
>
> "class X namespace" looks a lot like "allow me to violate access control
> here, please".

I don't think so.  This scope, afaics, is private, with contents safe
to be added without changing the ABI.

> But since we're brainstorming here, we can get most of the benefit here with
> extension methods alone:
>
> // foo.h
> class Foo {
> public:
>   void doWork();
> private:
>   int _f;
>   friend struct FooImpl;
> };
>
> // foo.cc
> struct FooImpl {
>   static void doWorkHelper(Foo *this) {
>     doSomethingWith(_f);
>   }
> };
>
> void Foo::doWork() {
>   doWorkHelper();
> }

I see two problems here:

 1. Program is written for human to read.  This approach, with
    functions taking pointer to objects, basically reverted C++ to C;

 2. Friend is flawed: what you need is to grant accessibility to
    a set of functions, but what you do is to grant accessibility to
    another class scope.  I read this as another "solution from
    implementation's view" like using private to make a class
    non-copyable.

There should be more simple, more obvious answer to the problem
raise in this thread.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

--001a11c1c4a6d713ee04ea61473f
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 4, 2013 at 12:36 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Mon, Nov 4, 2013 at 1:01 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
> >> //foo.cc:
> >>
> >> class Foo namespace {
> >
> >
> > "class X namespace" looks a lot like "allow me to violate access control
> > here, please".
>
> I don't think so.  This scope, afaics, is private, with contents safe
> to be added without changing the ABI.


If you can add friends to a 'class namespace', you can trivially use it to
violate access control (and get access to private members from some third
party TU). You can get the same effect even without allowing friends in a
'class namespace', but you need to work a little harder. For instance:

struct Launderer {
  virtual int get(Foo *p) = 0;
} *launderer;

class Foo namespace {
  struct FooLaunderer : Launderer {
    FooLaunderer() { launderer = this; }
    int get(Foo *p) { return p->_f; }
  } static theLaunderer;
}
Foo::FooLaunderer Foo::theLaunderer;

int evil_get_member(Foo *p) { return launderer->get(p); }

You can get the same effect without a static data member in the 'class
namespace', but again it takes a little more work. And you can do the same
thing without even using a member class (using a local class instead of a
member function instead). So: this subtly breaks access control.

> But since we're brainstorming here, we can get most of the benefit here
> with
> > extension methods alone:
> >
> > // foo.h
> > class Foo {
> > public:
> >   void doWork();
> > private:
> >   int _f;
> >   friend struct FooImpl;
> > };
> >
> > // foo.cc
> > struct FooImpl {
> >   static void doWorkHelper(Foo *this) {
> >     doSomethingWith(_f);
> >   }
> > };
> >
> > void Foo::doWork() {
> >   doWorkHelper();
> > }
>
> I see two problems here:
>
>  1. Program is written for human to read.  This approach, with
>     functions taking pointer to objects, basically reverted C++ to C;
>
>  2. Friend is flawed: what you need is to grant accessibility to
>     a set of functions, but what you do is to grant accessibility to
>     another class scope.  I read this as another "solution from
>     implementation's view" like using private to make a class
>     non-copyable.
>
> There should be more simple, more obvious answer to the problem
> raise in this thread.


*shrug* It doesn't seem like a big problem to me, especially not once we
have modules. I don't think it warrants a big heavy language feature of its
own.

--

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

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

<div dir=3D"ltr">On Mon, Nov 4, 2013 at 12:36 PM, Zhihao Yuan <span dir=3D"=
ltr">&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Mon, Nov 4, 2013 at 1:01 PM, Richard Smith &lt;<a href=
=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:<br>
&gt;&gt; //foo.cc:<br>
&gt;&gt;<br>
&gt;&gt; class Foo namespace {<br>
&gt;<br>
&gt;<br>
&gt; &quot;class X namespace&quot; looks a lot like &quot;allow me to viola=
te access control<br>
&gt; here, please&quot;.<br>
<br>
</div>I don&#39;t think so. =A0This scope, afaics, is private, with content=
s safe<br>
to be added without changing the ABI.</blockquote><div><br></div><div>If yo=
u can add friends to a &#39;class namespace&#39;, you can trivially use it =
to violate access control (and get access to private members from some thir=
d party TU). You can get the same effect even without allowing friends in a=
 &#39;class namespace&#39;, but you need to work a little harder. For insta=
nce:</div>
<div><br></div><div>struct Launderer {<br></div><div>=A0 virtual int get(Fo=
o *p) =3D 0;</div><div>} *launderer;<br></div><div><br></div><div>class Foo=
 namespace {<br></div><div>=A0 struct FooLaunderer : Launderer {</div><div>=
=A0 =A0 FooLaunderer() { launderer =3D this; }</div>
<div>=A0 =A0 int get(Foo *p) { return p-&gt;_f; }</div><div>=A0 } static th=
eLaunderer;</div><div>}</div><div>Foo::FooLaunderer Foo::theLaunderer;</div=
><div><br></div><div>int evil_get_member(Foo *p) { return launderer-&gt;get=
(p); }</div>
<div><br></div><div>You can get the same effect without a static data membe=
r in the &#39;class namespace&#39;, but again it takes a little more work. =
And you can do the same thing without even using a member class (using a lo=
cal class instead of a member function instead). So: this subtly breaks acc=
ess control.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
&gt; But since we&#39;re brainstorming here, we can get most of the benefit=
 here with<br>
&gt; extension methods alone:<br>
&gt;<br>
&gt; // foo.h<br>
&gt; class Foo {<br>
&gt; public:<br>
&gt; =A0 void doWork();<br>
&gt; private:<br>
&gt; =A0 int _f;<br>
&gt; =A0 friend struct FooImpl;<br>
&gt; };<br>
&gt;<br>
&gt; // foo.cc<br>
&gt; struct FooImpl {<br>
&gt; =A0 static void doWorkHelper(Foo *this) {<br>
&gt; =A0 =A0 doSomethingWith(_f);<br>
&gt; =A0 }<br>
&gt; };<br>
&gt;<br>
&gt; void Foo::doWork() {<br>
&gt; =A0 doWorkHelper();<br>
&gt; }<br>
<br>
</div>I see two problems here:<br>
<br>
=A01. Program is written for human to read. =A0This approach, with<br>
=A0 =A0 functions taking pointer to objects, basically reverted C++ to C;<b=
r>
<br>
=A02. Friend is flawed: what you need is to grant accessibility to<br>
=A0 =A0 a set of functions, but what you do is to grant accessibility to<br=
>
=A0 =A0 another class scope. =A0I read this as another &quot;solution from<=
br>
=A0 =A0 implementation&#39;s view&quot; like using private to make a class<=
br>
=A0 =A0 non-copyable.<br>
<br>
There should be more simple, more obvious answer to the problem<br>
raise in this thread.</blockquote><div><br></div><div>*shrug* It doesn&#39;=
t seem like a big problem to me, especially not once we have modules. I don=
&#39;t think it warrants a big heavy language feature of its own.</div>
</div></div></div>

<p></p>

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

--001a11c1c4a6d713ee04ea61473f--

.

On Mon, Nov 4, 2013 at 5:17 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>> I don't think so.  This scope, afaics, is private, with contents safe
>> to be added without changing the ABI.
>
> struct Launderer {
>   virtual int get(Foo *p) = 0;
> } *launderer;
>
> class Foo namespace {
>   struct FooLaunderer : Launderer {
>     FooLaunderer() { launderer = this; }
>     int get(Foo *p) { return p->_f; }
>   } static theLaunderer;

I see.  class namespace can be re-opened.

>>  1. Program is written for human to read.  This approach, with
>>     functions taking pointer to objects, basically reverted C++ to C;
>>
>>  2. Friend is flawed: what you need is to grant accessibility to
>>     a set of functions, but what you do is to grant accessibility to
>>     another class scope.  I read this as another "solution from
>>     implementation's view" like using private to make a class
>>     non-copyable.
>>
>> There should be more simple, more obvious answer to the problem
>> raise in this thread.
>
>
> *shrug* It doesn't seem like a big problem to me, especially not once we
> have modules. I don't think it warrants a big heavy language feature of its
> own.

I'm not +1 for class namespace the specific idea.  Can you elaborate
on how to use modules to solve this?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

------=_Part_35_12028995.1383726886030
Content-Type: text/plain; charset=ISO-8859-1



On Monday, November 4, 2013 11:17:24 PM UTC+1, Richard Smith wrote:
>
> On Mon, Nov 4, 2013 at 12:36 PM, Zhihao Yuan <z...@miator.net<javascript:>
> > wrote:
>
>> On Mon, Nov 4, 2013 at 1:01 PM, Richard Smith <ric...@metafoo.co.uk<javascript:>>
>> wrote:
>> >> //foo.cc:
>> >>
>> >> class Foo namespace {
>> >
>> >
>> > "class X namespace" looks a lot like "allow me to violate access control
>> > here, please".
>>
>> I don't think so.  This scope, afaics, is private, with contents safe
>> to be added without changing the ABI.
>
>
> If you can add friends to a 'class namespace', you can trivially use it to
> violate access control (and get access to private members from some third
> party TU). You can get the same effect even without allowing friends in a
> 'class namespace', but you need to work a little harder. For instance:
>
> struct Launderer {
>   virtual int get(Foo *p) = 0;
> } *launderer;
>
> class Foo namespace {
>   struct FooLaunderer : Launderer {
>     FooLaunderer() { launderer = this; }
>     int get(Foo *p) { return p->_f; }
>   } static theLaunderer;
> }
>

The above code would not be valid in "class namespace", there is no
"free-floating this pointer" just because you're in the "class namespace".
As I wrote in my original post, the primary motivation for class-namespace
is to allow the implementation of already declared members to be less
verbose / more uniform, the new idea sparkled by this thread is to allow
declaration / definition of yet undeclared _private_ member functions. I
don't think they could be used to circumvent access control in any way.

Basically, the following would be allowed in class-namespace:
- using declarations
- typedefs
- definition of previously declared members / member functions
- declaration / definition of new _private_ member functions or _private_
static member functions (these should probably be "special" regarding
linkage, they should be TU bound and not exported, but I'm not (yet)
well-versed with this area to express my ideas here correctly, sorry)
- nested class-namespaces for implementation of previously declared nested
classes

Does this make sense?


Foo::FooLaunderer Foo::theLaunderer;
>
> int evil_get_member(Foo *p) { return launderer->get(p); }
>
> You can get the same effect without a static data member in the 'class
> namespace', but again it takes a little more work. And you can do the same
> thing without even using a member class (using a local class instead of a
> member function instead). So: this subtly breaks access control.
>
> > But since we're brainstorming here, we can get most of the benefit here
>> with
>> > extension methods alone:
>> >
>> > // foo.h
>> > class Foo {
>> > public:
>> >   void doWork();
>> > private:
>> >   int _f;
>> >   friend struct FooImpl;
>> > };
>> >
>> > // foo.cc
>> > struct FooImpl {
>> >   static void doWorkHelper(Foo *this) {
>> >     doSomethingWith(_f);
>> >   }
>> > };
>> >
>> > void Foo::doWork() {
>> >   doWorkHelper();
>> > }
>>
>> I see two problems here:
>>
>>  1. Program is written for human to read.  This approach, with
>>     functions taking pointer to objects, basically reverted C++ to C;
>>
>>  2. Friend is flawed: what you need is to grant accessibility to
>>     a set of functions, but what you do is to grant accessibility to
>>     another class scope.  I read this as another "solution from
>>     implementation's view" like using private to make a class
>>     non-copyable.
>>
>> There should be more simple, more obvious answer to the problem
>> raise in this thread.
>
>
> *shrug* It doesn't seem like a big problem to me, especially not once we
> have modules. I don't think it warrants a big heavy language feature of its
> own.
>

--

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

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

<div dir=3D"ltr"><br><br>On Monday, November 4, 2013 11:17:24 PM UTC+1, Ric=
hard Smith 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 Mon, Nov 4, 2013 at 12:36 PM, Zhihao Yuan <span dir=3D"ltr">&lt;<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"_4Ke8j2DO7wJ=
">z...@miator.net</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>On Mon, Nov 4, 2013 at 1:01 PM, Richard Smith &lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"_4Ke8j2DO7wJ">ric...@metafoo=
..co.uk</a>&gt; wrote:<br>
&gt;&gt; //foo.cc:<br>
&gt;&gt;<br>
&gt;&gt; class Foo namespace {<br>
&gt;<br>
&gt;<br>
&gt; "class X namespace" looks a lot like "allow me to violate access contr=
ol<br>
&gt; here, please".<br>
<br>
</div>I don't think so. &nbsp;This scope, afaics, is private, with contents=
 safe<br>
to be added without changing the ABI.</blockquote><div><br></div><div>If yo=
u can add friends to a 'class namespace', you can trivially use it to viola=
te access control (and get access to private members from some third party =
TU). You can get the same effect even without allowing friends in a 'class =
namespace', but you need to work a little harder. For instance:</div>
<div><br></div><div>struct Launderer {<br></div><div>&nbsp; virtual int get=
(Foo *p) =3D 0;</div><div>} *launderer;<br></div><div><br></div><div>class =
Foo namespace {<br></div><div>&nbsp; struct FooLaunderer : Launderer {</div=
><div>&nbsp; &nbsp; FooLaunderer() { launderer =3D this; }</div>
<div>&nbsp; &nbsp; int get(Foo *p) { return p-&gt;_f; }</div><div>&nbsp; } =
static theLaunderer;</div><div>}</div></div></div></div></blockquote><div><=
br></div><div>The above code would not be valid in "class namespace", there=
 is no "free-floating this pointer" just because you're in the "class names=
pace". As I wrote in my original post, the primary motivation for class-nam=
espace is to allow the implementation of already declared members to be les=
s verbose / more uniform, the new idea sparkled by this thread is to allow =
declaration / definition of yet undeclared _private_ member functions. I do=
n't think they could be used to circumvent access control in any way.</div>=
<div><br></div><div>Basically, the following would be allowed in class-name=
space:</div><div>- using declarations</div><div>- typedefs</div><div>- defi=
nition of previously declared members / member functions</div><div>- declar=
ation / definition of new _private_ member functions or _private_ static me=
mber functions (these should probably be "special" regarding linkage, they =
should be TU bound and not exported, but I'm not (yet) well-versed with thi=
s area to express my ideas here correctly, sorry)</div><div>- nested class-=
namespaces for implementation of previously declared nested classes</div><d=
iv><br></div><div>Does this make sense?</div><div><span style=3D"font-size:=
 13px;">&nbsp;</span><br></div><div><br></div><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"><div>Foo::=
FooLaunderer Foo::theLaunderer;</div><div><br></div><div>int evil_get_membe=
r(Foo *p) { return launderer-&gt;get(p); }</div>
<div><br></div><div>You can get the same effect without a static data membe=
r in the 'class namespace', but again it takes a little more work. And you =
can do the same thing without even using a member class (using a local clas=
s instead of a member function instead). So: this subtly breaks access cont=
rol.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div>
&gt; But since we're brainstorming here, we can get most of the benefit her=
e with<br>
&gt; extension methods alone:<br>
&gt;<br>
&gt; // foo.h<br>
&gt; class Foo {<br>
&gt; public:<br>
&gt; &nbsp; void doWork();<br>
&gt; private:<br>
&gt; &nbsp; int _f;<br>
&gt; &nbsp; friend struct FooImpl;<br>
&gt; };<br>
&gt;<br>
&gt; // foo.cc<br>
&gt; struct FooImpl {<br>
&gt; &nbsp; static void doWorkHelper(Foo *this) {<br>
&gt; &nbsp; &nbsp; doSomethingWith(_f);<br>
&gt; &nbsp; }<br>
&gt; };<br>
&gt;<br>
&gt; void Foo::doWork() {<br>
&gt; &nbsp; doWorkHelper();<br>
&gt; }<br>
<br>
</div>I see two problems here:<br>
<br>
&nbsp;1. Program is written for human to read. &nbsp;This approach, with<br=
>
&nbsp; &nbsp; functions taking pointer to objects, basically reverted C++ t=
o C;<br>
<br>
&nbsp;2. Friend is flawed: what you need is to grant accessibility to<br>
&nbsp; &nbsp; a set of functions, but what you do is to grant accessibility=
 to<br>
&nbsp; &nbsp; another class scope. &nbsp;I read this as another "solution f=
rom<br>
&nbsp; &nbsp; implementation's view" like using private to make a class<br>
&nbsp; &nbsp; non-copyable.<br>
<br>
There should be more simple, more obvious answer to the problem<br>
raise in this thread.</blockquote><div><br></div><div>*shrug* It doesn't se=
em like a big problem to me, especially not once we have modules. I don't t=
hink it warrants a big heavy language feature of its own.</div>
</div></div></div>
</blockquote></div>

<p></p>

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

------=_Part_35_12028995.1383726886030--

.

------=_Part_112_33179426.1383740512646
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, October 30, 2013 12:12:10 AM UTC-4, Billy O'Neal wrote:
>
> Unit tests that test non-public data are bad (brittle) unit tests. Break
up those classes! :)


99% of the time I agree, however there are some cases where it is
unavoidable. One example is optimizations. For example, perhaps your
class is a template that is optimized for POD types. The effect may
not actually be visible from the public interface, in which case you
may need to dig into the private interface to ensure the optimization
triggers for all of the right cases and works as expected.

Right now this is impossible to do without doing horrible things like
adding extra public methods, friend declarations, or making everything
protected and inheriting. All of these are horrible.

On Wednesday, October 30, 2013 11:02:01 AM UTC-4, Ville Voutilainen wrote:
>
>
> I have also used a solution where I define a public struct for the
members of the class
> and have the members in a private instance of that struct, and then pass
a reference
> to that struct to implementation-file-scope 'private' functions. This way
the only
> private member functions that need to be in the class definition are the
ones that
> are virtual.


This works but I'm not sure I like it as it exposes another public symbol.

The other trick is the private nested class with static methods. No
symbols are exposed to the user but this is still a coupling of the
class definition with the private member implementations.
Whoever implements the private methods, regardless of how many C files
are used is restricted to using this one nested class.

On Sunday, November 3, 2013 8:44:45 PM UTC-5, Philipp Stephani wrote:
>
> Adding a virtual member functions to a class without other virtual member
functions does change the class layout. (I guess classes whose virtual
member functions are all private don't occur in practice though.)


Actually all virtual functions with the exception of the destructor
should almost always be private. This is the non-virtual idiom.
http://www.gotw.ca/publications/mill18.htm

On Sunday, November 3, 2013 12:10:17 PM UTC-5, mitc...@gmail.com wrote:
>
>    I've been thinking about a new proposal for a "class implementation
namespace",


This is pretty interesting. One potential abuse is that if anyone
wants to just avoid your public interface they can open the namespace
and hack in something. I could see horrible last minute bug fixes
being implemented this way. Still, access control is just a tool for
allowing us to write better interfaces, if people want to do stupid
things we don't need to be responsible for them.

The friend idea I proposed limits the access control to the
implementation of member functions. Only someone writing the actual
member functions can extend the access control out to another
function.

On Sunday, November 3, 2013 9:06:39 PM UTC-5, Philipp Stephani wrote:
>
> I'm not sure whether a restriction should be made to only allow private
nonvirtual functions outside the class definition -- a rule could be added
that the class layout may not be different for any nonzero number of
virtual functions, and the compiler could signal an error if a virtual
function is to be added to a class whose definition doesn't contain any
virtual functions.


As suggested by others, virtual functions must be in the class
definition. Every part of the interface which is exposed to users must
be in the class definition, it should not be spread out and makes
little sense to do so. More on that later.


On Monday, November 4, 2013 12:56:11 AM UTC-5, Thiago Macieira wrote:
>
> Well, the one thing I'd want is to have a real static (as in file-local)
> method, to control my exports.
>
> I know all the techniques. But I am forced to use compiler extensions in
order
> to control the list of exports from my TUs and libraries, to degrading the
> linkers' performances due to way too many symbols.


I was under the impression that static and anonymous namespace
functions don't export symbols even in single object files. In fact
the function may be removed entirely or even sliced up into callable
pieces if the compiler decides to inline it everywehre.

With regards to the general problem of symbol visibility, that's
probably something that would probably involve [attributes] and is
outside of this discussion entirely.

On Monday, November 4, 2013 8:18:22 AM UTC-5, Olaf van der Spek wrote:
>
> Not entirely true. In general, callers don't need to know the layout. The
layout is (only?) required when accessing data members, the size is only
required when creating an object on the stack.
> Not requiring private data members in the header would be nice too IMO.


But how would you compute the size without knowing the layout? You
need to know the layout for padding. Also, what real use is knowing
the size without knowing the layout. As soon as you change a data
member your callers will need to recompile anyway as the size will
change.

 On Monday, November 4, 2013 2:41:35 PM UTC-5, Thiago Macieira wrote:
>
> Maybe the solution will come with modules, when we can finally have a
> standardised syntax for "this method is called by other modules" versus
"this
> method is never called externally"


Maybe, maybe not. What are modules? When will they become available?
We have no idea. I'd like a workable solution to this problem now.


I'd like to focus the discussion a bit. Lets agree on some invariants.
The following must remain in the class definition.
* data members with any access control.
* virtual methods with any access control.
* public and protected non-virtual methods, they are part of the interface.
* private non-virtual methods called by inline functions, for obvious
reasons.

Maybe someone can come up with a good reason to break one of these but
I don't want to discuss it here. If you're passionate about that then
please start a new thread.

Not only are there hard implementation reasons for these, restricting
the external interface to a single point, namely the class interface
is an extremely powerful constraint in terms of usability and
readability. I don't need to chase down multiple header files, source
files, and documentation, I just need to see one class definition and
it has everything I need to know as a possible user of the class
(using directly or inheriting). The only thing I don't need to know
about is how many functions are used to implement its behavior, and
those are the non-virtual private methods we are discussing.

So far we have 2 suggestions, declaring friends in function bodies and
having a class namespace.

Here's another, simply define allow a syntax to define new private
methods outside of the class definition. These methods should *always*
be private and therefore only callable by other class methods. What we
don't want is to allow people to start writing public or protected
extension methods, making interfaces impossibly complicated. This
allows easy extensibility and also keeps the interface constrained to
whats in the definition.

class Foo {
  public:
  Foo(int i);
};

//explicitly define a new private method which is not in the class body
explicit void Foo::_foo() {
}

//explicitly define a new private constructor, callable by other
constructors
explicit Foo::Foo() {
}

//Define the public constructor which calls the explicit private one
using delegation
explicit Foo::Foo(int i) : Foo() {
}

I like this better than the namespace proposal, because with the
namespace, you have this problem:
class Foo namespace {

//Hundreds of lines of code

//Wait, is this an extension method or a normal function? I have to look
for the namespace tags.
void foo();

};
Also if the only thing that's going in your namespace is function
definitions, do you really need to create a scope for that? I always
prefer to use static for file local functions instead of anonymous
namespaces. I use anonymous namespaces for file local global variables
and class definitions.

The namespace idea however would allow you to define other things such as
private nested types and typedefs.

I also like it better than the friend proposal, because adding friend
to already cluttered function bodies is hard to read and rather
intelligent. Its also not obvious looking at a function knowing
whether or not something else has declared it as a friend.

--

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

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

<div dir=3D"ltr"><span style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;">On Wednesday, October 30, 2013 12:12:10 AM UTC-4, Bi=
lly O'Neal wrote:</span><br style=3D"font-family: arial, sans-serif; font-s=
ize: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;">&gt;</span><br style=3D"font-family: aria=
l, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family=
: arial, sans-serif; font-size: 12.499999046325684px;">&gt; Unit tests that=
 test non-public data are bad (brittle) unit tests. Break up those classes!=
 :)</span><br style=3D"font-family: arial, sans-serif; font-size: 12.499999=
046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 1=
2.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-s=
ize: 12.499999046325684px;">99% of the time I agree, however there are some=
 cases where it is</span><br style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif;=
 font-size: 12.499999046325684px;">unavoidable. One example is optimization=
s. For example, perhaps your</span><br style=3D"font-family: arial, sans-se=
rif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, s=
ans-serif; font-size: 12.499999046325684px;">class is a template that is op=
timized for POD types. The effect may</span><br style=3D"font-family: arial=
, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family:=
 arial, sans-serif; font-size: 12.499999046325684px;">not actually be visib=
le from the public interface, in which case you</span><br style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;">may need to=
 dig into the private interface to ensure the optimization</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>triggers for all of the right cases and works as expected.</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br s=
tyle=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><=
span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;">Right now this is impossible to do without doing horrible things like<=
/span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999990463=
25684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.4999=
99046325684px;">adding extra public methods, friend declarations, or making=
 everything</span><br style=3D"font-family: arial, sans-serif; font-size: 1=
2.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-s=
ize: 12.499999046325684px;">protected and inheriting. All of these are horr=
ible.</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999=
99046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.=
499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-siz=
e: 12.499999046325684px;">On Wednesday, October 30, 2013 11:02:01 AM UTC-4,=
 Ville Voutilainen wrote:</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans=
-serif; font-size: 12.499999046325684px;">&gt;</span><br style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fon=
t-family: arial, sans-serif; font-size: 12.499999046325684px;">&gt;</span><=
br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px=
;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49999904632=
5684px;">&gt; I have also used a solution where I define a public struct fo=
r the members of the class</span><br style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, san=
s-serif; font-size: 12.499999046325684px;">&gt; and have the members in a p=
rivate instance of that struct, and then pass a reference</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>&gt; to that struct to implementation-file-scope 'private' functions. This=
 way the only</span><br style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;">&gt; private member functions that need to be=
 in the class definition are the ones that</span><br style=3D"font-family: =
arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;">&gt; are virtual=
..</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904=
6325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.4999=
99046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.=
499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-siz=
e: 12.499999046325684px;">This works but I'm not sure I like it as it expos=
es another public symbol.</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, =
sans-serif; font-size: 12.499999046325684px;">The other trick is the privat=
e nested class with static methods. No</span><br style=3D"font-family: aria=
l, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family=
: arial, sans-serif; font-size: 12.499999046325684px;">symbols are exposed =
to the user but this is still a coupling of the</span><br style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;">class defin=
ition with the private member implementations.</span><br style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fon=
t-family: arial, sans-serif; font-size: 12.499999046325684px;">Whoever impl=
ements the private methods, regardless of how many C files</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>are used is restricted to using this one nested class.</span><br style=3D"=
font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>On Sunday, November 3, 2013 8:44:45 PM UTC-5, Philipp Stephani wrote:</spa=
n><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904632568=
4px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49999904=
6325684px;">&gt;</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">&gt; Adding a virtual member functions to =
a class without other virtual member functions does change the class layout=
.. (I guess classes whose virtual member functions are all private don't occ=
ur in practice though.)</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-ser=
if; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans=
-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial=
, sans-serif; font-size: 12.499999046325684px;">Actually all virtual functi=
ons with the exception of the destructor</span><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">should almost alwa=
ys be private. This is the non-virtual idiom.</span><br style=3D"font-famil=
y: arial, sans-serif; font-size: 12.499999046325684px;"><a href=3D"http://w=
ww.gotw.ca/publications/mill18.htm" target=3D"_blank" style=3D"color: rgb(1=
7, 85, 204); font-family: arial, sans-serif; font-size: 12.499999046325684p=
x;">http://www.gotw.ca/<wbr>publications/mill18.htm</a><br style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;"><div class=3D"im=
" style=3D"color: rgb(80, 0, 80); font-family: arial, sans-serif; font-size=
: 12.499999046325684px;"><br>On Sunday, November 3, 2013 12:10:17 PM UTC-5,=
&nbsp;<a href=3D"mailto:mitc...@gmail.com" style=3D"color: rgb(17, 85, 204)=
;">mitc...@gmail.com</a>&nbsp;wrote:<br>&gt;<br>&gt; &nbsp; &nbsp;I've been=
 thinking about a new proposal for a "class implementation namespace",<br><=
br><br></div><span style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;">This is pretty interesting. One potential abuse is that =
if anyone</span><br style=3D"font-family: arial, sans-serif; font-size: 12.=
499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-siz=
e: 12.499999046325684px;">wants to just avoid your public interface they ca=
n open the namespace</span><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;">and hack in something. I could see hor=
rible last minute bug fixes</span><br style=3D"font-family: arial, sans-ser=
if; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sa=
ns-serif; font-size: 12.499999046325684px;">being implemented this way. Sti=
ll, access control is just a tool for</span><br style=3D"font-family: arial=
, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family:=
 arial, sans-serif; font-size: 12.499999046325684px;">allowing us to write =
better interfaces, if people want to do stupid</span><br style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fon=
t-family: arial, sans-serif; font-size: 12.499999046325684px;">things we do=
n't need to be responsible for them.</span><br style=3D"font-family: arial,=
 sans-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">The friend idea I =
proposed limits the access control to the</span><br style=3D"font-family: a=
rial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;">implementation of=
 member functions. Only someone writing the actual</span><br style=3D"font-=
family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D=
"font-family: arial, sans-serif; font-size: 12.499999046325684px;">member f=
unctions can extend the access control out to another</span><br style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">funct=
ion.</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999=
9046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size=
: 12.499999046325684px;">On Sunday, November 3, 2013 9:06:39 PM UTC-5, Phil=
ipp Stephani wrote:</span><br style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;">&gt;</span><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">&gt; I'm not sure =
whether a restriction should be made to only allow private nonvirtual funct=
ions outside the class definition -- a rule could be added that the class l=
ayout may not be different for any nonzero number of virtual functions, and=
 the compiler could signal an error if a virtual function is to be added to=
 a class whose definition doesn't contain any virtual functions.</span><br =
style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">=
<br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684p=
x;"><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325=
684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499999=
046325684px;">As suggested by others, virtual functions must be in the clas=
s</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904=
6325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;">definition. Every part of the interface which is exposed =
to users must</span><br style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;">be in the class definition, it should not be =
spread out and makes</span><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;">little sense to do so. More on that la=
ter.</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999=
9046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;">On Monday, November 4, 2013 12:56:11 AM UTC-5,=
 Thiago Macieira wrote:</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;">&gt;</span><br style=3D"font-family=
: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-=
family: arial, sans-serif; font-size: 12.499999046325684px;">&gt; Well, the=
 one thing I'd want is to have a real static (as in file-local)</span><br s=
tyle=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><=
span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;">&gt; method, to control my exports.</span><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">&gt;</span><br sty=
le=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><sp=
an style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px=
;">&gt; I know all the techniques. But I am forced to use compiler extensio=
ns in order</span><br style=3D"font-family: arial, sans-serif; font-size: 1=
2.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-s=
ize: 12.499999046325684px;">&gt; to control the list of exports from my TUs=
 and libraries, to degrading the</span><br style=3D"font-family: arial, san=
s-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: aria=
l, sans-serif; font-size: 12.499999046325684px;">&gt; linkers' performances=
 due to way too many symbols.</span><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sa=
ns-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial=
, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family:=
 arial, sans-serif; font-size: 12.499999046325684px;">I was under the impre=
ssion that static and anonymous namespace</span><br style=3D"font-family: a=
rial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;">functions don't e=
xport symbols even in single object files. In fact</span><br style=3D"font-=
family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D=
"font-family: arial, sans-serif; font-size: 12.499999046325684px;">the func=
tion may be removed entirely or even sliced up into callable</span><br styl=
e=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><spa=
n style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;=
">pieces if the compiler decides to inline it everywehre.</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br s=
tyle=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><=
span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;">With regards to the general problem of symbol visibility, that's</span=
><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499999046=
325684px;">probably something that would probably involve [attributes] and =
is</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999990=
46325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;">outside of this discussion entirely.</span><br style=3D"=
font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>On Monday, November 4, 2013 8:18:22 AM UTC-5, Olaf van der Spek wrote:</sp=
an><br style=3D"font-family: arial, sans-serif; font-size: 12.4999990463256=
84px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.4999990=
46325684px;">&gt;</span><br style=3D"font-family: arial, sans-serif; font-s=
ize: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;">&gt; Not entirely true. In general, calle=
rs don't need to know the layout. The layout is (only?) required when acces=
sing data members, the size is only required when creating an object on the=
 stack.</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;">&gt; Not requiring private data members in the head=
er would be nice too IMO.</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sa=
ns-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: ari=
al, sans-serif; font-size: 12.499999046325684px;">But how would you compute=
 the size without knowing the layout? You</span><br style=3D"font-family: a=
rial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;">need to know the =
layout for padding. Also, what real use is knowing</span><br style=3D"font-=
family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D=
"font-family: arial, sans-serif; font-size: 12.499999046325684px;">the size=
 without knowing the layout. As soon as you change a data</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>member your callers will need to recompile anyway as the size will</span><=
br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px=
;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49999904632=
5684px;">change.</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;">&nbsp;On Monday, November 4, 2013 2:41=
:35 PM UTC-5, Thiago Macieira wrote:</span><br style=3D"font-family: arial,=
 sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: =
arial, sans-serif; font-size: 12.499999046325684px;">&gt;</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>&gt; Maybe the solution will come with modules, when we can finally have a=
</span><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046=
325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499=
999046325684px;">&gt; standardised syntax for "this method is called by oth=
er modules" versus "this</span><br style=3D"font-family: arial, sans-serif;=
 font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-=
serif; font-size: 12.499999046325684px;">&gt; method is never called extern=
ally"</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999=
99046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.=
499999046325684px;"><br style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;">Maybe, maybe not. What are modules? When will=
 they become available?</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;">We have no idea. I'd like a workabl=
e solution to this problem now.</span><br style=3D"font-family: arial, sans=
-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, =
sans-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: ari=
al, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-famil=
y: arial, sans-serif; font-size: 12.499999046325684px;">I'd like to focus t=
he discussion a bit. Lets agree on some invariants.</span><br style=3D"font=
-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">The f=
ollowing must remain in the class definition.</span><br style=3D"font-famil=
y: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font=
-family: arial, sans-serif; font-size: 12.499999046325684px;">* data member=
s with any access control.</span><br style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, san=
s-serif; font-size: 12.499999046325684px;">* virtual methods with any acces=
s control.</span><br style=3D"font-family: arial, sans-serif; font-size: 12=
..499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;">* public and protected non-virtual methods, they=
 are part of the interface.</span><br style=3D"font-family: arial, sans-ser=
if; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sa=
ns-serif; font-size: 12.499999046325684px;">* private non-virtual methods c=
alled by inline functions, for obvious reasons.</span><br style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;"><br style=3D"font=
-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">Maybe=
 someone can come up with a good reason to break one of these but</span><br=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
><span style=3D"font-family: arial, sans-serif; font-size: 12.4999990463256=
84px;">I don't want to discuss it here. If you're passionate about that the=
n</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904=
6325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;">please start a new thread.</span><br style=3D"font-family=
: arial, sans-serif; font-size: 12.499999046325684px;"><br style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"f=
ont-family: arial, sans-serif; font-size: 12.499999046325684px;">Not only a=
re there hard implementation reasons for these, restricting</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>the external interface to a single point, namely the class interface</span=
><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499999046=
325684px;">is an extremely powerful constraint in terms of usability and</s=
pan><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325=
684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499999=
046325684px;">readability. I don't need to chase down multiple header files=
, source</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size=
: 12.499999046325684px;">files, and documentation, I just need to see one c=
lass definition and</span><br style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;">it has everything I need to know as a p=
ossible user of the class</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans=
-serif; font-size: 12.499999046325684px;">(using directly or inheriting). T=
he only thing I don't need to know</span><br style=3D"font-family: arial, s=
ans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;">about is how many functi=
ons are used to implement its behavior, and</span><br style=3D"font-family:=
 arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-f=
amily: arial, sans-serif; font-size: 12.499999046325684px;">those are the n=
on-virtual private methods we are discussing.</span><br style=3D"font-famil=
y: arial, sans-serif; font-size: 12.499999046325684px;"><br style=3D"font-f=
amily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"=
font-family: arial, sans-serif; font-size: 12.499999046325684px;">So far we=
 have 2 suggestions, declaring friends in function bodies and</span><br sty=
le=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><sp=
an style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px=
;">having a class namespace.</span><br style=3D"font-family: arial, sans-se=
rif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, san=
s-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: aria=
l, sans-serif; font-size: 12.499999046325684px;">Here's another, simply def=
ine allow a syntax to define new private</span><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">methods outside of=
 the class definition. These methods should *always*</span><br style=3D"fon=
t-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">be pr=
ivate and therefore only callable by other class methods. What we</span><br=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
><span style=3D"font-family: arial, sans-serif; font-size: 12.4999990463256=
84px;">don't want is to allow people to start writing public or protected</=
span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904632=
5684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49999=
9046325684px;">extension methods, making interfaces impossibly complicated.=
 This</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999=
99046325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 1=
2.499999046325684px;">allows easy extensibility and also keeps the interfac=
e constrained to</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">whats in the definition.</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br s=
tyle=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><=
span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;">class Foo {</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">&nbsp; public:</span><br style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;">&nbsp; Foo(=
int i);</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;">};</span><br style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-=
serif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial,=
 sans-serif; font-size: 12.499999046325684px;">//explicitly define a new pr=
ivate method which is not in the class body</span><br style=3D"font-family:=
 arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-f=
amily: arial, sans-serif; font-size: 12.499999046325684px;">explicit void F=
oo::_foo() {</span><br style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;">}</span><br style=3D"font-family: arial, sans-=
serif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, s=
ans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;">//explicitly define a ne=
w private constructor, callable by other constructors</span><br style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">expli=
cit Foo::Foo() {</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">}</span><br style=3D"font-family: arial, s=
ans-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: aria=
l, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family=
: arial, sans-serif; font-size: 12.499999046325684px;">//Define the public =
constructor which calls the explicit private one</span><br style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"f=
ont-family: arial, sans-serif; font-size: 12.499999046325684px;">using dele=
gation</span><br style=3D"font-family: arial, sans-serif; font-size: 12.499=
999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;">explicit Foo::Foo(int i) : Foo() {</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>}</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999990=
46325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.499=
999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;">I like this better than the namespace proposal, beca=
use with the</span><br style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;">namespace, you have this problem:</span><br st=
yle=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><s=
pan style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684p=
x;">class Foo namespace {</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, =
sans-serif; font-size: 12.499999046325684px;">//Hundreds of lines of code</=
span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904632=
5684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.4999990=
46325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;">//Wait, is this an extension method or a normal function=
? I have to&nbsp;</span><span style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;">look for the namespace tags.</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>void foo();</span><br style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;"><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">};</span><br style=3D"font-family: arial, =
sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: a=
rial, sans-serif; font-size: 12.499999046325684px;">Also if the only thing =
that's going in your namespace is function</span><br style=3D"font-family: =
arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;">definitions, do =
you really need to create a scope for that? I always</span><br style=3D"fon=
t-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">prefe=
r to use static for file local functions instead of anonymous</span><br sty=
le=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><sp=
an style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px=
;">namespaces. I use anonymous namespaces for file local global variables</=
span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904632=
5684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49999=
9046325684px;">and class definitions.</span><br style=3D"font-family: arial=
, sans-serif; font-size: 12.499999046325684px;"><br>The namespace idea howe=
ver would allow you to define other things such as private nested types and=
 typedefs.<br style=3D"font-family: arial, sans-serif; font-size: 12.499999=
046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;">I also like it better than the friend proposal, bec=
ause adding friend</span><br style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif;=
 font-size: 12.499999046325684px;">to already cluttered function bodies is =
hard to read and rather</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;">intelligent. Its also not obvious l=
ooking at a function knowing</span><br style=3D"font-family: arial, sans-se=
rif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, s=
ans-serif; font-size: 12.499999046325684px;">whether or not something else =
has declared it as a friend.</span></div>

<p></p>

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

------=_Part_112_33179426.1383740512646--

.

------=_Part_6049_33057765.1383741199036
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, November 6, 2013 3:34:45 AM UTC-5, mitc...@gmail.com wrote:
>
> Basically, the following would be allowed in class-namespace:
> - using declarations
> - typedefs
> - definition of previously declared members / member functions
> - declaration / definition of new _private_ member functions or _private_
> static member functions (these should probably be "special" regarding
> linkage, they should be TU bound and not exported, but I'm not (yet)
> well-versed with this area to express my ideas here correctly, sorry)
> - nested class-namespaces for implementation of previously declared nested
> classes
>
> Does this make sense?
>

I'd recommend making everything in the class namespace private to the
class, and by that I mean nothing outside of the class can use any of its
 declarations. It would be as if they were declared directly in the classes
private section. This prevents anyone from actually modifying the external
class interface and avoids the "break access control here" anti-pattern
that surely some people would try to use. In this way the class namespace
is merely a tool for making the class implementation easier to write.

--

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

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

<div dir=3D"ltr"><br><br>On Wednesday, November 6, 2013 3:34:45 AM UTC-5, m=
itc...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>Basically, the following would be allowed in class-namespace=
:</div><div>- using declarations</div><div>- typedefs</div><div>- definitio=
n of previously declared members / member functions</div><div>- declaration=
 / definition of new _private_ member functions or _private_ static member =
functions (these should probably be "special" regarding linkage, they shoul=
d be TU bound and not exported, but I'm not (yet) well-versed with this are=
a to express my ideas here correctly, sorry)</div><div>- nested class-names=
paces for implementation of previously declared nested classes</div><div><b=
r></div><div>Does this make sense?</div></div></blockquote><div><br></div><=
div>I'd recommend making everything in the class namespace private to the c=
lass, and by that I mean nothing outside of the class can use any of its &n=
bsp;declarations. It would be as if they were declared directly in the clas=
ses private section. This prevents anyone from actually modifying the exter=
nal class interface and avoids the "break access control here" anti-pattern=
 that surely some people would try to use. In this way the class namespace =
is merely a tool for making the class implementation easier to write.</div>=
</div>

<p></p>

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

------=_Part_6049_33057765.1383741199036--

.

------=_Part_260_19702731.1383741810593
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, November 6, 2013 1:33:18 PM UTC+1, fmatth...@gmail.com wrote:
>
>
>
> On Wednesday, November 6, 2013 3:34:45 AM UTC-5, mitc...@gmail.com wrote:
>>
>> Basically, the following would be allowed in class-namespace:
>> - using declarations
>> - typedefs
>> - definition of previously declared members / member functions
>> - declaration / definition of new _private_ member functions or _private_
>> static member functions (these should probably be "special" regarding
>> linkage, they should be TU bound and not exported, but I'm not (yet)
>> well-versed with this area to express my ideas here correctly, sorry)
>> - nested class-namespaces for implementation of previously declared
>> nested classes
>>
>> Does this make sense?
>>
>
> I'd recommend making everything in the class namespace private to the
> class, and by that I mean nothing outside of the class can use any of its
>  declarations. It would be as if they were declared directly in the classes
> private section. This prevents anyone from actually modifying the external
> class interface and avoids the "break access control here" anti-pattern
> that surely some people would try to use. In this way the class namespace
> is merely a tool for making the class implementation easier to write.
>

That's exactly what I had in mind, but probably failed to communicate
clearly.  Everything in class-namespace is private to the class.

--

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

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

<div dir=3D"ltr"><br><br>On Wednesday, November 6, 2013 1:33:18 PM UTC+1, f=
matth...@gmail.com 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"><br><br>On Wednesday, November 6, 2013 3:34:45 AM UTC-5, <a>mit=
c...@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"><div>Basically, the following would be allowed in class-namespace:=
</div><div>- using declarations</div><div>- typedefs</div><div>- definition=
 of previously declared members / member functions</div><div>- declaration =
/ definition of new _private_ member functions or _private_ static member f=
unctions (these should probably be "special" regarding linkage, they should=
 be TU bound and not exported, but I'm not (yet) well-versed with this area=
 to express my ideas here correctly, sorry)</div><div>- nested class-namesp=
aces for implementation of previously declared nested classes</div><div><br=
></div><div>Does this make sense?</div></div></blockquote><div><br></div><d=
iv>I'd recommend making everything in the class namespace private to the cl=
ass, and by that I mean nothing outside of the class can use any of its &nb=
sp;declarations. It would be as if they were declared directly in the class=
es private section. This prevents anyone from actually modifying the extern=
al class interface and avoids the "break access control here" anti-pattern =
that surely some people would try to use. In this way the class namespace i=
s merely a tool for making the class implementation easier to write.</div><=
/div></blockquote><div><br></div><div>That's exactly what I had in mind, bu=
t probably failed to communicate clearly. &nbsp;Everything in class-namespa=
ce is private to the class.&nbsp;</div></div>

<p></p>

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

------=_Part_260_19702731.1383741810593--

.

On Wed, Nov 6, 2013 at 1:21 PM,  <fmatthew5876@gmail.com> wrote:
> On Monday, November 4, 2013 8:18:22 AM UTC-5, Olaf van der Spek wrote:
>>
>> Not entirely true. In general, callers don't need to know the layout. The
>> layout is (only?) required when accessing data members, the size is only
>> required when creating an object on the stack.
>> Not requiring private data members in the header would be nice too IMO.
>
>
> But how would you compute the size without knowing the layout? You
> need to know the layout for padding. Also, what real use is knowing
> the size without knowing the layout. As soon as you change a data
> member your callers will need to recompile anyway as the size will
> change.

If you pass by reference / pointer there's no need to know size, is there?

--

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

.

------=_Part_0_1383755132467
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline

If you pass by reference there's no need for the type to be complete either.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Olaf van der Spek" <olafvdspek@gmail.com>
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Re: Fixing the private method issue
Date: Wed, Nov 6, 2013 4:45 AM

On Wed, Nov 6, 2013 at 1:21 PM,  <fmatthew5876@gmail.com> wrote:
> On Monday, November 4, 2013 8:18:22 AM UTC-5, Olaf van der Spek wrote:
>>
>> Not entirely true. In general, callers don't need to know the layout. The
>> layout is (only?) required when accessing data members, the size is only
>> required when creating an object on the stack.
>> Not requiring private data members in the header would be nice too IMO.
>
>
> But how would you compute the size without knowing the layout? You
> need to know the layout for padding. Also, what real use is knowing
> the size without knowing the layout. As soon as you change a data
> member your callers will need to recompile anyway as the size will
> change.

If you pass by reference / pointer there's no need to know size, is there?

--

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

--

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

------=_Part_0_1383755132467
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html><head></head><body><div style=3D"font-size: 12pt; font-family: Calibr=
i,sans-serif;"><div>If you pass by reference there's no need for the type t=
o be complete either.</div><div><br></div><div>Sent from a touchscreen. Ple=
ase excuse the brevity and tpyos.</div><br><div id=3D"htc_header">----- Rep=
ly message -----<br>From: &quot;Olaf van der Spek&quot; &lt;olafvdspek@gmai=
l.com&gt;<br>To: &lt;std-proposals@isocpp.org&gt;<br>Subject: [std-proposal=
s] Re: Fixing the private method issue<br>Date: Wed, Nov 6, 2013 4:45 AM</d=
iv></div><br><pre style=3D"word-wrap: break-word; white-space: pre-wrap;">O=
n Wed, Nov 6, 2013 at 1:21 PM,  &lt;fmatthew5876@gmail.com&gt; wrote:
&gt; On Monday, November 4, 2013 8:18:22 AM UTC-5, Olaf van der Spek wrote:
&gt;&gt;
&gt;&gt; Not entirely true. In general, callers don't need to know the layo=
ut. The
&gt;&gt; layout is (only?) required when accessing data members, the size i=
s only
&gt;&gt; required when creating an object on the stack.
&gt;&gt; Not requiring private data members in the header would be nice too=
 IMO.
&gt;
&gt;
&gt; But how would you compute the size without knowing the layout? You
&gt; need to know the layout for padding. Also, what real use is knowing
&gt; the size without knowing the layout. As soon as you change a data
&gt; member your callers will need to recompile anyway as the size will
&gt; change.

If you pass by reference / pointer there's no need to know size, is there?

--=20

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

<p></p>

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

------=_Part_0_1383755132467--


.

------=_Part_0_1383755262287
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>One example is optimizations. For example, perhaps your
class is a template that is optimized for POD types

If you can't see any difference big enough to reliably unit test, the perfo=
rmance gains aren't worth the additional complexity.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: fmatthew5876@gmail.com
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Re: Fixing the private method issue
Date: Wed, Nov 6, 2013 4:21 AM

On Wednesday, October 30, 2013 12:12:10 AM UTC-4, Billy O'Neal wrote:>> Uni=
t tests that test non-public data are bad (brittle) unit tests. Break up th=
ose classes! :)99% of the time I agree, however there are some cases where =
it isunavoidable. One example is optimizations. For example, perhaps yourcl=
ass is a template that is optimized for POD types. The effect maynot actual=
ly be visible from the public interface, in which case youmay need to dig i=
nto the private interface to ensure the optimizationtriggers for all of the=
 right cases and works as expected.Right now this is impossible to do witho=
ut doing horrible things likeadding extra public methods, friend declaratio=
ns, or making everythingprotected and inheriting. All of these are horrible=
..On Wednesday, October 30, 2013 11:02:01 AM UTC-4, Ville Voutilainen wrote:=
>>> I have also used a solution where I define a public struct for the memb=
ers of the class> and have the members in a private instance of that struct=
, and then pass a reference> to that struct to implementation-file-scope 'p=
rivate' functions. This way the only> private member functions that need to=
 be in the class definition are the ones that> are virtual.This works but I=
'm not sure I like it as it exposes another public symbol.The other trick i=
s the private nested class with static methods. Nosymbols are exposed to th=
e user but this is still a coupling of theclass definition with the private=
 member implementations.Whoever implements the private methods, regardless =
of how many C filesare used is restricted to using this one nested class.On=
 Sunday, November 3, 2013 8:44:45 PM UTC-5, Philipp Stephani wrote:>> Addin=
g a virtual member functions to a class without other virtual member functi=
ons does change the class layout. (I guess classes whose virtual member fun=
ctions are all private don't occur in practice though.)Actually all virtual=
 functions with the exception of the destructorshould almost always be priv=
ate. This is the non-virtual idiom.http://www.gotw.ca/publications/mill18.h=
tm
On Sunday, November 3, 2013 12:10:17 PM UTC-5, mitc...@gmail.com wrote:
>
>    I've been thinking about a new proposal for a "class implementation na=
mespace",


This is pretty interesting. One potential abuse is that if anyonewants to j=
ust avoid your public interface they can open the namespaceand hack in some=
thing. I could see horrible last minute bug fixesbeing implemented this way=
.. Still, access control is just a tool forallowing us to write better inter=
faces, if people want to do stupidthings we don't need to be responsible fo=
r them.The friend idea I proposed limits the access control to theimplement=
ation of member functions. Only someone writing the actualmember functions =
can extend the access control out to anotherfunction.On Sunday, November 3,=
 2013 9:06:39 PM UTC-5, Philipp Stephani wrote:>> I'm not sure whether a re=
striction should be made to only allow private nonvirtual functions outside=
 the class definition -- a rule could be added that the class layout may no=
t be different for any nonzero number of virtual functions, and the compile=
r could signal an error if a virtual function is to be added to a class who=
se definition doesn't contain any virtual functions.As suggested by others,=
 virtual functions must be in the classdefinition. Every part of the interf=
ace which is exposed to users mustbe in the class definition, it should not=
 be spread out and makeslittle sense to do so. More on that later.On Monday=
, November 4, 2013 12:56:11 AM UTC-5, Thiago Macieira wrote:>> Well, the on=
e thing I'd want is to have a real static (as in file-local)> method, to co=
ntrol my exports.>> I know all the techniques. But I am forced to use compi=
ler extensions in order> to control the list of exports from my TUs and lib=
raries, to degrading the> linkers' performances due to way too many symbols=
..I was under the impression that static and anonymous namespacefunctions do=
n't export symbols even in single object files. In factthe function may be =
removed entirely or even sliced up into callablepieces if the compiler deci=
des to inline it everywehre.With regards to the general problem of symbol v=
isibility, that'sprobably something that would probably involve [attributes=
] and isoutside of this discussion entirely.On Monday, November 4, 2013 8:1=
8:22 AM UTC-5, Olaf van der Spek wrote:>> Not entirely true. In general, ca=
llers don't need to know the layout. The layout is (only?) required when ac=
cessing data members, the size is only required when creating an object on =
the stack.> Not requiring private data members in the header would be nice =
too IMO.But how would you compute the size without knowing the layout? Youn=
eed to know the layout for padding. Also, what real use is knowingthe size =
without knowing the layout. As soon as you change a datamember your callers=
 will need to recompile anyway as the size willchange. On Monday, November =
4, 2013 2:41:35 PM UTC-5, Thiago Macieira wrote:>> Maybe the solution will =
come with modules, when we can finally have a> standardised syntax for "thi=
s method is called by other modules" versus "this> method is never called e=
xternally"Maybe, maybe not. What are modules? When will they become availab=
le?We have no idea. I'd like a workable solution to this problem now.I'd li=
ke to focus the discussion a bit. Lets agree on some invariants.The followi=
ng must remain in the class definition.* data members with any access contr=
ol.* virtual methods with any access control.* public and protected non-vir=
tual methods, they are part of the interface.* private non-virtual methods =
called by inline functions, for obvious reasons.Maybe someone can come up w=
ith a good reason to break one of these butI don't want to discuss it here.=
 If you're passionate about that thenplease start a new thread.Not only are=
 there hard implementation reasons for these, restrictingthe external inter=
face to a single point, namely the class interfaceis an extremely powerful =
constraint in terms of usability andreadability. I don't need to chase down=
 multiple header files, sourcefiles, and documentation, I just need to see =
one class definition andit has everything I need to know as a possible user=
 of the class(using directly or inheriting). The only thing I don't need to=
 knowabout is how many functions are used to implement its behavior, andtho=
se are the non-virtual private methods we are discussing.So far we have 2 s=
uggestions, declaring friends in function bodies andhaving a class namespac=
e.Here's another, simply define allow a syntax to define new privatemethods=
 outside of the class definition. These methods should *always*be private a=
nd therefore only callable by other class methods. What wedon't want is to =
allow people to start writing public or protectedextension methods, making =
interfaces impossibly complicated. Thisallows easy extensibility and also k=
eeps the interface constrained towhats in the definition.class Foo {  publi=
c:  Foo(int i);};//explicitly define a new private method which is not in t=
he class bodyexplicit void Foo::_foo() {}//explicitly define a new private =
constructor, callable by other constructorsexplicit Foo::Foo() {}//Define t=
he public constructor which calls the explicit private oneusing delegatione=
xplicit Foo::Foo(int i) : Foo() {}I like this better than the namespace pro=
posal, because with thenamespace, you have this problem:class Foo namespace=
 {//Hundreds of lines of code//Wait, is this an extension method or a norma=
l function? I have to look for the namespace tags.void foo();};Also if the =
only thing that's going in your namespace is functiondefinitions, do you re=
ally need to create a scope for that? I alwaysprefer to use static for file=
 local functions instead of anonymousnamespaces. I use anonymous namespaces=
 for file local global variablesand class definitions.
The namespace idea however would allow you to define other things such as p=
rivate nested types and typedefs.I also like it better than the friend prop=
osal, because adding friendto already cluttered function bodies is hard to =
read and ratherintelligent. Its also not obvious looking at a function know=
ingwhether or not something else has declared it as a friend.




--=20

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

--=20

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

------=_Part_0_1383755262287
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>&gt;O=
ne example is optimizations. For example, perhaps your</div><div>class is a=
 template that is optimized for POD types</div><div><br></div><div>If you c=
an't see any difference big enough to reliably unit test, the performance g=
ains aren't worth the additional complexity.</div><div><br></div><div>Sent =
from a touchscreen. Please excuse the brevity and tpyos.</div><br><div id=
=3D"htc_header">----- Reply message -----<br>From: fmatthew5876@gmail.com<b=
r>To: &lt;std-proposals@isocpp.org&gt;<br>Subject: [std-proposals] Re: Fixi=
ng the private method issue<br>Date: Wed, Nov 6, 2013 4:21 AM</div></div><b=
r><div dir=3D"ltr"><span style=3D"font-family: arial, sans-serif; font-size=
: 12.499999046325684px;">On Wednesday, October 30, 2013 12:12:10 AM UTC-4, =
Billy O'Neal wrote:</span><br style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;">&gt;</span><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">&gt; Unit tests th=
at test non-public data are bad (brittle) unit tests. Break up those classe=
s! :)</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999=
99046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.=
499999046325684px;"><br style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;">99% of the time I agree, however there are so=
me cases where it is</span><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;">unavoidable. One example is optimizati=
ons. For example, perhaps your</span><br style=3D"font-family: arial, sans-=
serif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial,=
 sans-serif; font-size: 12.499999046325684px;">class is a template that is =
optimized for POD types. The effect may</span><br style=3D"font-family: ari=
al, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-famil=
y: arial, sans-serif; font-size: 12.499999046325684px;">not actually be vis=
ible from the public interface, in which case you</span><br style=3D"font-f=
amily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"=
font-family: arial, sans-serif; font-size: 12.499999046325684px;">may need =
to dig into the private interface to ensure the optimization</span><br styl=
e=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><spa=
n style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;=
">triggers for all of the right cases and works as expected.</span><br styl=
e=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br =
style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">=
<span style=3D"font-family: arial, sans-serif; font-size: 12.49999904632568=
4px;">Right now this is impossible to do without doing horrible things like=
</span><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046=
325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499=
999046325684px;">adding extra public methods, friend declarations, or makin=
g everything</span><br style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;">protected and inheriting. All of these are hor=
rible.</span><br style=3D"font-family: arial, sans-serif; font-size: 12.499=
999046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12=
..499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;">On Wednesday, October 30, 2013 11:02:01 AM UTC-4=
, Ville Voutilainen wrote:</span><br style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, san=
s-serif; font-size: 12.499999046325684px;">&gt;</span><br style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;">&gt;</span>=
<br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684p=
x;"><span style=3D"font-family: arial, sans-serif; font-size: 12.4999990463=
25684px;">&gt; I have also used a solution where I define a public struct f=
or the members of the class</span><br style=3D"font-family: arial, sans-ser=
if; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sa=
ns-serif; font-size: 12.499999046325684px;">&gt; and have the members in a =
private instance of that struct, and then pass a reference</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>&gt; to that struct to implementation-file-scope 'private' functions. This=
 way the only</span><br style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;">&gt; private member functions that need to be=
 in the class definition are the ones that</span><br style=3D"font-family: =
arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;">&gt; are virtual=
..</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904=
6325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.4999=
99046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.=
499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-siz=
e: 12.499999046325684px;">This works but I'm not sure I like it as it expos=
es another public symbol.</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, =
sans-serif; font-size: 12.499999046325684px;">The other trick is the privat=
e nested class with static methods. No</span><br style=3D"font-family: aria=
l, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family=
: arial, sans-serif; font-size: 12.499999046325684px;">symbols are exposed =
to the user but this is still a coupling of the</span><br style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;">class defin=
ition with the private member implementations.</span><br style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fon=
t-family: arial, sans-serif; font-size: 12.499999046325684px;">Whoever impl=
ements the private methods, regardless of how many C files</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>are used is restricted to using this one nested class.</span><br style=3D"=
font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>On Sunday, November 3, 2013 8:44:45 PM UTC-5, Philipp Stephani wrote:</spa=
n><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904632568=
4px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49999904=
6325684px;">&gt;</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">&gt; Adding a virtual member functions to =
a class without other virtual member functions does change the class layout=
.. (I guess classes whose virtual member functions are all private don't occ=
ur in practice though.)</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-ser=
if; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans=
-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial=
, sans-serif; font-size: 12.499999046325684px;">Actually all virtual functi=
ons with the exception of the destructor</span><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">should almost alwa=
ys be private. This is the non-virtual idiom.</span><br style=3D"font-famil=
y: arial, sans-serif; font-size: 12.499999046325684px;"><a href=3D"http://w=
ww.gotw.ca/publications/mill18.htm" target=3D"_blank" style=3D"color: rgb(1=
7, 85, 204); font-family: arial, sans-serif; font-size: 12.499999046325684p=
x;">http://www.gotw.ca/<wbr>publications/mill18.htm</a><br style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;"><div class=3D"im=
" style=3D"color: rgb(80, 0, 80); font-family: arial, sans-serif; font-size=
: 12.499999046325684px;"><br>On Sunday, November 3, 2013 12:10:17 PM UTC-5,=
&nbsp;<a href=3D"mailto:mitc...@gmail.com" style=3D"color: rgb(17, 85, 204)=
;">mitc...@gmail.com</a>&nbsp;wrote:<br>&gt;<br>&gt; &nbsp; &nbsp;I've been=
 thinking about a new proposal for a "class implementation namespace",<br><=
br><br></div><span style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;">This is pretty interesting. One potential abuse is that =
if anyone</span><br style=3D"font-family: arial, sans-serif; font-size: 12.=
499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-siz=
e: 12.499999046325684px;">wants to just avoid your public interface they ca=
n open the namespace</span><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;">and hack in something. I could see hor=
rible last minute bug fixes</span><br style=3D"font-family: arial, sans-ser=
if; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sa=
ns-serif; font-size: 12.499999046325684px;">being implemented this way. Sti=
ll, access control is just a tool for</span><br style=3D"font-family: arial=
, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family:=
 arial, sans-serif; font-size: 12.499999046325684px;">allowing us to write =
better interfaces, if people want to do stupid</span><br style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fon=
t-family: arial, sans-serif; font-size: 12.499999046325684px;">things we do=
n't need to be responsible for them.</span><br style=3D"font-family: arial,=
 sans-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">The friend idea I =
proposed limits the access control to the</span><br style=3D"font-family: a=
rial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;">implementation of=
 member functions. Only someone writing the actual</span><br style=3D"font-=
family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D=
"font-family: arial, sans-serif; font-size: 12.499999046325684px;">member f=
unctions can extend the access control out to another</span><br style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">funct=
ion.</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999=
9046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size=
: 12.499999046325684px;">On Sunday, November 3, 2013 9:06:39 PM UTC-5, Phil=
ipp Stephani wrote:</span><br style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;">&gt;</span><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">&gt; I'm not sure =
whether a restriction should be made to only allow private nonvirtual funct=
ions outside the class definition -- a rule could be added that the class l=
ayout may not be different for any nonzero number of virtual functions, and=
 the compiler could signal an error if a virtual function is to be added to=
 a class whose definition doesn't contain any virtual functions.</span><br =
style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">=
<br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684p=
x;"><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325=
684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499999=
046325684px;">As suggested by others, virtual functions must be in the clas=
s</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904=
6325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;">definition. Every part of the interface which is exposed =
to users must</span><br style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;">be in the class definition, it should not be =
spread out and makes</span><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;">little sense to do so. More on that la=
ter.</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999=
9046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;">On Monday, November 4, 2013 12:56:11 AM UTC-5,=
 Thiago Macieira wrote:</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;">&gt;</span><br style=3D"font-family=
: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-=
family: arial, sans-serif; font-size: 12.499999046325684px;">&gt; Well, the=
 one thing I'd want is to have a real static (as in file-local)</span><br s=
tyle=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><=
span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;">&gt; method, to control my exports.</span><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">&gt;</span><br sty=
le=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><sp=
an style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px=
;">&gt; I know all the techniques. But I am forced to use compiler extensio=
ns in order</span><br style=3D"font-family: arial, sans-serif; font-size: 1=
2.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-s=
ize: 12.499999046325684px;">&gt; to control the list of exports from my TUs=
 and libraries, to degrading the</span><br style=3D"font-family: arial, san=
s-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: aria=
l, sans-serif; font-size: 12.499999046325684px;">&gt; linkers' performances=
 due to way too many symbols.</span><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sa=
ns-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial=
, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family:=
 arial, sans-serif; font-size: 12.499999046325684px;">I was under the impre=
ssion that static and anonymous namespace</span><br style=3D"font-family: a=
rial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;">functions don't e=
xport symbols even in single object files. In fact</span><br style=3D"font-=
family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D=
"font-family: arial, sans-serif; font-size: 12.499999046325684px;">the func=
tion may be removed entirely or even sliced up into callable</span><br styl=
e=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><spa=
n style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;=
">pieces if the compiler decides to inline it everywehre.</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br s=
tyle=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><=
span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;">With regards to the general problem of symbol visibility, that's</span=
><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499999046=
325684px;">probably something that would probably involve [attributes] and =
is</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999990=
46325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;">outside of this discussion entirely.</span><br style=3D"=
font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>On Monday, November 4, 2013 8:18:22 AM UTC-5, Olaf van der Spek wrote:</sp=
an><br style=3D"font-family: arial, sans-serif; font-size: 12.4999990463256=
84px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.4999990=
46325684px;">&gt;</span><br style=3D"font-family: arial, sans-serif; font-s=
ize: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;">&gt; Not entirely true. In general, calle=
rs don't need to know the layout. The layout is (only?) required when acces=
sing data members, the size is only required when creating an object on the=
 stack.</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;">&gt; Not requiring private data members in the head=
er would be nice too IMO.</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sa=
ns-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: ari=
al, sans-serif; font-size: 12.499999046325684px;">But how would you compute=
 the size without knowing the layout? You</span><br style=3D"font-family: a=
rial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;">need to know the =
layout for padding. Also, what real use is knowing</span><br style=3D"font-=
family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D=
"font-family: arial, sans-serif; font-size: 12.499999046325684px;">the size=
 without knowing the layout. As soon as you change a data</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>member your callers will need to recompile anyway as the size will</span><=
br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px=
;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49999904632=
5684px;">change.</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;">&nbsp;On Monday, November 4, 2013 2:41=
:35 PM UTC-5, Thiago Macieira wrote:</span><br style=3D"font-family: arial,=
 sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: =
arial, sans-serif; font-size: 12.499999046325684px;">&gt;</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>&gt; Maybe the solution will come with modules, when we can finally have a=
</span><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046=
325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499=
999046325684px;">&gt; standardised syntax for "this method is called by oth=
er modules" versus "this</span><br style=3D"font-family: arial, sans-serif;=
 font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-=
serif; font-size: 12.499999046325684px;">&gt; method is never called extern=
ally"</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999=
99046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.=
499999046325684px;"><br style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;">Maybe, maybe not. What are modules? When will=
 they become available?</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;">We have no idea. I'd like a workabl=
e solution to this problem now.</span><br style=3D"font-family: arial, sans=
-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, =
sans-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: ari=
al, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-famil=
y: arial, sans-serif; font-size: 12.499999046325684px;">I'd like to focus t=
he discussion a bit. Lets agree on some invariants.</span><br style=3D"font=
-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">The f=
ollowing must remain in the class definition.</span><br style=3D"font-famil=
y: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font=
-family: arial, sans-serif; font-size: 12.499999046325684px;">* data member=
s with any access control.</span><br style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, san=
s-serif; font-size: 12.499999046325684px;">* virtual methods with any acces=
s control.</span><br style=3D"font-family: arial, sans-serif; font-size: 12=
..499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;">* public and protected non-virtual methods, they=
 are part of the interface.</span><br style=3D"font-family: arial, sans-ser=
if; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sa=
ns-serif; font-size: 12.499999046325684px;">* private non-virtual methods c=
alled by inline functions, for obvious reasons.</span><br style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;"><br style=3D"font=
-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">Maybe=
 someone can come up with a good reason to break one of these but</span><br=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
><span style=3D"font-family: arial, sans-serif; font-size: 12.4999990463256=
84px;">I don't want to discuss it here. If you're passionate about that the=
n</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904=
6325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;">please start a new thread.</span><br style=3D"font-family=
: arial, sans-serif; font-size: 12.499999046325684px;"><br style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"f=
ont-family: arial, sans-serif; font-size: 12.499999046325684px;">Not only a=
re there hard implementation reasons for these, restricting</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>the external interface to a single point, namely the class interface</span=
><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499999046=
325684px;">is an extremely powerful constraint in terms of usability and</s=
pan><br style=3D"font-family: arial, sans-serif; font-size: 12.499999046325=
684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.499999=
046325684px;">readability. I don't need to chase down multiple header files=
, source</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size=
: 12.499999046325684px;">files, and documentation, I just need to see one c=
lass definition and</span><br style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;">it has everything I need to know as a p=
ossible user of the class</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans=
-serif; font-size: 12.499999046325684px;">(using directly or inheriting). T=
he only thing I don't need to know</span><br style=3D"font-family: arial, s=
ans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;">about is how many functi=
ons are used to implement its behavior, and</span><br style=3D"font-family:=
 arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-f=
amily: arial, sans-serif; font-size: 12.499999046325684px;">those are the n=
on-virtual private methods we are discussing.</span><br style=3D"font-famil=
y: arial, sans-serif; font-size: 12.499999046325684px;"><br style=3D"font-f=
amily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"=
font-family: arial, sans-serif; font-size: 12.499999046325684px;">So far we=
 have 2 suggestions, declaring friends in function bodies and</span><br sty=
le=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><sp=
an style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px=
;">having a class namespace.</span><br style=3D"font-family: arial, sans-se=
rif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, san=
s-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: aria=
l, sans-serif; font-size: 12.499999046325684px;">Here's another, simply def=
ine allow a syntax to define new private</span><br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.499999046325684px;">methods outside of=
 the class definition. These methods should *always*</span><br style=3D"fon=
t-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">be pr=
ivate and therefore only callable by other class methods. What we</span><br=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
><span style=3D"font-family: arial, sans-serif; font-size: 12.4999990463256=
84px;">don't want is to allow people to start writing public or protected</=
span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904632=
5684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49999=
9046325684px;">extension methods, making interfaces impossibly complicated.=
 This</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999=
99046325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 1=
2.499999046325684px;">allows easy extensibility and also keeps the interfac=
e constrained to</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">whats in the definition.</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><br s=
tyle=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><=
span style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684=
px;">class Foo {</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">&nbsp; public:</span><br style=3D"font-fam=
ily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;">&nbsp; Foo(=
int i);</span><br style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;">};</span><br style=3D"font-family: arial, sans-seri=
f; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-=
serif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial,=
 sans-serif; font-size: 12.499999046325684px;">//explicitly define a new pr=
ivate method which is not in the class body</span><br style=3D"font-family:=
 arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-f=
amily: arial, sans-serif; font-size: 12.499999046325684px;">explicit void F=
oo::_foo() {</span><br style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;">}</span><br style=3D"font-family: arial, sans-=
serif; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, s=
ans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: ar=
ial, sans-serif; font-size: 12.499999046325684px;">//explicitly define a ne=
w private constructor, callable by other constructors</span><br style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">expli=
cit Foo::Foo() {</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">}</span><br style=3D"font-family: arial, s=
ans-serif; font-size: 12.499999046325684px;"><br style=3D"font-family: aria=
l, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family=
: arial, sans-serif; font-size: 12.499999046325684px;">//Define the public =
constructor which calls the explicit private one</span><br style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"f=
ont-family: arial, sans-serif; font-size: 12.499999046325684px;">using dele=
gation</span><br style=3D"font-family: arial, sans-serif; font-size: 12.499=
999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;">explicit Foo::Foo(int i) : Foo() {</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>}</span><br style=3D"font-family: arial, sans-serif; font-size: 12.4999990=
46325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.499=
999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;">I like this better than the namespace proposal, beca=
use with the</span><br style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;">namespace, you have this problem:</span><br st=
yle=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><s=
pan style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684p=
x;">class Foo namespace {</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.499999046325684px;"><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, =
sans-serif; font-size: 12.499999046325684px;">//Hundreds of lines of code</=
span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904632=
5684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.4999990=
46325684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.4=
99999046325684px;">//Wait, is this an extension method or a normal function=
? I have to&nbsp;</span><span style=3D"font-family: arial, sans-serif; font=
-size: 12.499999046325684px;">look for the namespace tags.</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><span=
 style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"=
>void foo();</span><br style=3D"font-family: arial, sans-serif; font-size: =
12.499999046325684px;"><br style=3D"font-family: arial, sans-serif; font-si=
ze: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.499999046325684px;">};</span><br style=3D"font-family: arial, =
sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-family: a=
rial, sans-serif; font-size: 12.499999046325684px;">Also if the only thing =
that's going in your namespace is function</span><br style=3D"font-family: =
arial, sans-serif; font-size: 12.499999046325684px;"><span style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.499999046325684px;">definitions, do =
you really need to create a scope for that? I always</span><br style=3D"fon=
t-family: arial, sans-serif; font-size: 12.499999046325684px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;">prefe=
r to use static for file local functions instead of anonymous</span><br sty=
le=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px;"><sp=
an style=3D"font-family: arial, sans-serif; font-size: 12.499999046325684px=
;">namespaces. I use anonymous namespaces for file local global variables</=
span><br style=3D"font-family: arial, sans-serif; font-size: 12.49999904632=
5684px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.49999=
9046325684px;">and class definitions.</span><br style=3D"font-family: arial=
, sans-serif; font-size: 12.499999046325684px;"><br>The namespace idea howe=
ver would allow you to define other things such as private nested types and=
 typedefs.<br style=3D"font-family: arial, sans-serif; font-size: 12.499999=
046325684px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.49=
9999046325684px;"><span style=3D"font-family: arial, sans-serif; font-size:=
 12.499999046325684px;">I also like it better than the friend proposal, bec=
ause adding friend</span><br style=3D"font-family: arial, sans-serif; font-=
size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-serif;=
 font-size: 12.499999046325684px;">to already cluttered function bodies is =
hard to read and rather</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.499999046325684px;"><span style=3D"font-family: arial, sans-s=
erif; font-size: 12.499999046325684px;">intelligent. Its also not obvious l=
ooking at a function knowing</span><br style=3D"font-family: arial, sans-se=
rif; font-size: 12.499999046325684px;"><span style=3D"font-family: arial, s=
ans-serif; font-size: 12.499999046325684px;">whether or not something else =
has declared it as a friend.</span></div>

<p></p>

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

<p></p>

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

------=_Part_0_1383755262287--


.

On Wed, Nov 6, 2013 at 5:25 PM, billy.oneal@gmail.com
<billy.oneal@gmail.com> wrote:
> If you pass by reference there's no need for the type to be complete either.

Member functions can't be called on an incomplete type

--

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

.

--089e010d96c43d80c304ea85f30f
Content-Type: text/plain; charset=ISO-8859-1

I'm confused -- first you want to be able to add private non-virtual member
functions to a class inside of a single translation unit, which seems
reasonable. Now you're proposing something else -- completely separating
the public interface of the class from its representation. I don't think
that'd be near as useful -- the number of translation units which mention
the type, call public member functions of the type, but don't try to copy
or otherwise interact with it are going to be extremely small. Plus, such a
feature would be far harder to specify given the way the language currently
works.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Wed, Nov 6, 2013 at 8:39 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Wed, Nov 6, 2013 at 5:25 PM, billy.oneal@gmail.com
> <billy.oneal@gmail.com> wrote:
> > If you pass by reference there's no need for the type to be complete
> either.
>
> Member functions can't be called on an incomplete type
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><div>I&#39;m confused -- first you want to be able to add =
private non-virtual member functions to a class inside of a single translat=
ion unit, which seems reasonable. Now you&#39;re proposing something else -=
- completely separating the public interface of the class from its represen=
tation. I don&#39;t think that&#39;d be near as useful -- the number of tra=
nslation units which mention the type, call public member functions of the =
type, but don&#39;t try to copy or otherwise interact with it are going to =
be extremely small. Plus, such a feature would be far harder to specify giv=
en the way the language currently works.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Nov 6, 2013 at 8:39 AM, Olaf van=
 der Spek <span dir=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" tar=
get=3D"_blank">olafvdspek@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

<div class=3D"im">On Wed, Nov 6, 2013 at 5:25 PM, <a href=3D"mailto:billy.o=
neal@gmail.com">billy.oneal@gmail.com</a><br>
&lt;<a href=3D"mailto:billy.oneal@gmail.com">billy.oneal@gmail.com</a>&gt; =
wrote:<br>
&gt; If you pass by reference there&#39;s no need for the type to be comple=
te either.<br>
<br>
</div>Member functions can&#39;t be called on an incomplete type<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e010d96c43d80c304ea85f30f--

.

On Wed, Nov 6, 2013 at 7:01 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
> I'm confused -- first you want to be able to add private non-virtual member
> functions to a class inside of a single translation unit, which seems
> reasonable. Now you're proposing something else -- completely separating the
> public interface of the class from its representation. I don't think that'd
> be near as useful -- the number of translation units which mention the type,
> call public member functions of the type, but don't try to copy or otherwise
> interact with it are going to be extremely small.

What do you mean by otherwise interacting?
Non-copyable classes like iostream et are used quite useful and are
used quite a lot, without any need for copying them.

--

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

.

--089e0116028c2bd5bf04ea89736b
Content-Type: text/plain; charset=ISO-8859-1

>Non-copyable classes [...] are used quite useful and are used quite a lot,
without any need for copying them.
Yes, they are. However, one always has to balance how often something is
used with the scope of the change in the language proposed. I don't think
this pattern is near common enough to merit having to define a completely
new class declaration syntax for people to learn. Of course, I'm not on the
committee or anything like that so it isn't like my opinion matters.

>iostream
The iostreams classes are templates, and as a result need even public
member definitions available in each translation unit, so that's not a
great example.



Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Wed, Nov 6, 2013 at 2:04 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Wed, Nov 6, 2013 at 7:01 PM, Billy O'Neal <billy.oneal@gmail.com>
> wrote:
> > I'm confused -- first you want to be able to add private non-virtual
> member
> > functions to a class inside of a single translation unit, which seems
> > reasonable. Now you're proposing something else -- completely separating
> the
> > public interface of the class from its representation. I don't think
> that'd
> > be near as useful -- the number of translation units which mention the
> type,
> > call public member functions of the type, but don't try to copy or
> otherwise
> > interact with it are going to be extremely small.
>
> What do you mean by otherwise interacting?
> Non-copyable classes like iostream et are used quite useful and are
> used quite a lot, without any need for copying them.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><div><div>&gt;Non-copyable classes [...] are used quite us=
eful and are=A0used quite a lot, without any need for copying them.</div><d=
iv>Yes, they are. However, one always has to balance how often something is=
 used with the scope of the change in the language proposed. I don&#39;t th=
ink this pattern is near common enough to merit having to define a complete=
ly new class declaration syntax for people to learn. Of course, I&#39;m not=
 on the committee or anything like that so it isn&#39;t like my opinion mat=
ters.</div>

<div>=A0</div><div>&gt;iostream</div></div><div>The iostreams classes are t=
emplates, and as a result need even public member definitions available in =
each translation unit, so that&#39;s not a great example.</div><div>=A0</di=
v>

<div>=A0</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div =
dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.or=
g/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></div><d=
iv><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_=
blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Nov 6, 2013 at 2:04 PM, Olaf van=
 der Spek <span dir=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" tar=
get=3D"_blank">olafvdspek@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

<div class=3D"im">On Wed, Nov 6, 2013 at 7:01 PM, Billy O&#39;Neal &lt;<a h=
ref=3D"mailto:billy.oneal@gmail.com">billy.oneal@gmail.com</a>&gt; wrote:<b=
r>
&gt; I&#39;m confused -- first you want to be able to add private non-virtu=
al member<br>
&gt; functions to a class inside of a single translation unit, which seems<=
br>
&gt; reasonable. Now you&#39;re proposing something else -- completely sepa=
rating the<br>
&gt; public interface of the class from its representation. I don&#39;t thi=
nk that&#39;d<br>
&gt; be near as useful -- the number of translation units which mention the=
 type,<br>
&gt; call public member functions of the type, but don&#39;t try to copy or=
 otherwise<br>
&gt; interact with it are going to be extremely small.<br>
<br>
</div>What do you mean by otherwise interacting?<br>
Non-copyable classes like iostream et are used quite useful and are<br>
used quite a lot, without any need for copying them.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e0116028c2bd5bf04ea89736b--

.

------=_Part_2832_23477592.1384228726952
Content-Type: text/plain; charset=ISO-8859-1

I think I prefer my idea of being able to just define private methods
outside of the class body, explicit keyword or not.

//foo.hh
class Foo {
public:
  int foo();
};

//private extension method declaration in the header file
explicit int Foo::_bar();

//inline private extension method
explicit inline int Foo::_baz() { return 5; }

//inline public method calls private extension method
inline int Foo::foo() { return _bar; }

//foo.cc
//private extension method which only appears in the file.
explicit int Foo::_bar_impl() {
  return 42;
}

//private extension method definition
explicit int Foo::_bar() {
  return _baz_impl();
}

With the namespace proposal, you get to define extra things like nested
classes and typedefs, but is there any reason you would actually ever need
to do this? The only time I find myself defining private nest classes or
typedefs is when I'm using them to define my private class data members. In
those situations, they would have to be in the class definition anyway.

If you want to define helper classes and typedefs, you can simply make them
file local which is even better, or if they need to be shared between
translation units, use a private header file.


--

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

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

<div dir=3D"ltr">I think I prefer my idea of being able to just define priv=
ate methods outside of the class body, explicit keyword or not.<div><br></d=
iv><div>//foo.hh</div><div>class Foo {</div><div>public:</div><div>&nbsp; i=
nt foo();<br>};</div><div><br></div><div>//private extension method declara=
tion in the header file</div><div>explicit int Foo::_bar();</div><div><br><=
/div><div>//inline private extension method</div><div>explicit inline int F=
oo::_baz() { return 5; }</div><div><br></div><div>//inline public method ca=
lls private extension method</div><div>inline int Foo::foo() { return _bar;=
 }</div><div><br></div><div>//foo.cc</div><div>//private extension method w=
hich only appears in the file.</div><div>explicit int Foo::_bar_impl() {</d=
iv><div>&nbsp; return 42;</div><div>}<br><div><br></div><div>//private exte=
nsion method definition</div><div>explicit int Foo::_bar() {</div><div>&nbs=
p; return _baz_impl();</div><div>}</div><div><br></div><div>With the namesp=
ace proposal, you get to define extra things like nested classes and typede=
fs, but is there any reason you would actually ever need to do this? The on=
ly time I find myself defining private nest classes or typedefs is when I'm=
 using them to define my private class data members. In those situations, t=
hey would have to be in the class definition anyway.</div><div><br></div><d=
iv>If you want to define helper classes and typedefs, you can simply make t=
hem file local which is even better, or if they need to be shared between t=
ranslation units, use a private header file.</div><div><br></div><div><br><=
/div></div></div>

<p></p>

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

------=_Part_2832_23477592.1384228726952--

.

------=_Part_4374_1094640.1384429517758
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 12, 2013 4:58:46 AM UTC+1, fmatth...@gmail.com wrote:
>
> I think I prefer my idea of being able to just define private methods
> outside of the class body, explicit keyword or not.
>

 I also came to the conclusion that mixing my class-namespace proposal with
this is probably not the best idea. There should be a way to define
"hidden" private member functions without class-namespace, too.  The only
common ground with the two proposals is that if the new "hidden" private
member declaration will turn out to be similar to a normal member
definition (with an extra keyword like 'explicit' or 'private'), then it
should be possible to define the same in class-namespace (without the extra
class scope specifiers and such).

One issue that crossed my mind when thinking about "breaking" an existing
class: it should not be possible to add a "hidden" private member that adds
an overload to an existing declared private member.  I don't know if
there's a similar constraint elsewhere in the standard, or if it'd be
completely new...

--

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

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

<div dir=3D"ltr"><br><br>On Tuesday, November 12, 2013 4:58:46 AM UTC+1, fm=
atth...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">I think I prefer my idea of being able to just define private me=
thods outside of the class body, explicit keyword or not.<div><span style=
=3D"font-size: 13px;"></span></div></div></blockquote><div><br></div><div>&=
nbsp;I also came to the conclusion that mixing my class-namespace proposal =
with this is probably not the best idea. There should be a way to define "h=
idden" private member functions without class-namespace, too. &nbsp;The onl=
y common ground with the two proposals is that if the new "hidden" private =
member declaration will turn out to be similar to a normal member definitio=
n (with an extra keyword like 'explicit' or 'private'), then it should be p=
ossible to define the same in class-namespace (without the extra class scop=
e specifiers and such).</div><div><br></div><div>One issue that crossed my =
mind when thinking about "breaking" an existing class: it should not be pos=
sible to add a "hidden" private member that adds an overload to an existing=
 declared private member. &nbsp;I don't know if there's a similar constrain=
t elsewhere in the standard, or if it'd be completely new...</div><div><br>=
</div></div>

<p></p>

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

------=_Part_4374_1094640.1384429517758--

.

------=_Part_73_26043117.1384435602754
Content-Type: text/plain; charset=ISO-8859-1

One additonal wrinkle is how to define static private extension methods:

//Is this file local or a static class method?
static explicit int Foo::sfoo() { /* ... */ }

Perhaps this syntax?

//File local private extension method
static explicit int Foo::f1() { /* ... */ }

//private extension static class method
explicit int Foo::f2() static { /* ... */ }

//File local private extension static class method
static explicit int Foo::f3() static { /* ... */ }

On Thursday, November 14, 2013 6:45:17 AM UTC-5, mitc...@gmail.com wrote:
>
>
>
> On Tuesday, November 12, 2013 4:58:46 AM UTC+1, fmatth...@gmail.com wrote:
>>
>> I think I prefer my idea of being able to just define private methods
>> outside of the class body, explicit keyword or not.
>>
>
>  I also came to the conclusion that mixing my class-namespace proposal
> with this is probably not the best idea. There should be a way to define
> "hidden" private member functions without class-namespace, too.  The only
> common ground with the two proposals is that if the new "hidden" private
> member declaration will turn out to be similar to a normal member
> definition (with an extra keyword like 'explicit' or 'private'), then it
> should be possible to define the same in class-namespace (without the extra
> class scope specifiers and such).
>

We can write 2 competing proposals. Either one I'd be happy with to improve
compile times and improve encapsulation by hiding more implementation
details from the user.


>
> One issue that crossed my mind when thinking about "breaking" an existing
> class: it should not be possible to add a "hidden" private member that adds
> an overload to an existing declared private member.  I don't know if
> there's a similar constraint elsewhere in the standard, or if it'd be
> completely new...
>

I think its probably ok to do this. You can define overloads for normal
functions anywhere. Why not private member functions. The only taboo in my
mind is breaking encapsulation, which is what would happen if we allowed
extension of public, protected, data members, and/or virtual.

--

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

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

<div dir=3D"ltr">One additonal wrinkle is how to define static private exte=
nsion methods:<div><br></div><div>//Is this file local or a static class me=
thod?</div><div>static explicit int Foo::sfoo() { /* ... */ }</div><div><br=
></div><div>Perhaps this syntax?</div><div><br></div><div>//File local priv=
ate extension method</div><div>static explicit int Foo::f1() { /* ... */ }<=
br></div><div><br></div><div>//private extension static class method</div><=
div>explicit int Foo::f2() static { /* ... */ }<br></div><div><br></div><di=
v>//File local private extension static class method</div><div>static expli=
cit int Foo::f3() static { /* ... */ }<br><br>On Thursday, November 14, 201=
3 6:45:17 AM UTC-5, mitc...@gmail.com wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><br><br>On Tuesday, November 12, 2013 4:58:4=
6 AM UTC+1, <a>fmatth...@gmail.com</a> wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">I think I prefer my idea of being able to just d=
efine private methods outside of the class body, explicit keyword or not.<d=
iv><span style=3D"font-size:13px"></span></div></div></blockquote><div><br>=
</div><div>&nbsp;I also came to the conclusion that mixing my class-namespa=
ce proposal with this is probably not the best idea. There should be a way =
to define "hidden" private member functions without class-namespace, too. &=
nbsp;The only common ground with the two proposals is that if the new "hidd=
en" private member declaration will turn out to be similar to a normal memb=
er definition (with an extra keyword like 'explicit' or 'private'), then it=
 should be possible to define the same in class-namespace (without the extr=
a class scope specifiers and such).</div></div></blockquote><div><br></div>=
<div>We can write 2 competing proposals. Either one I'd be happy with to im=
prove compile times and improve encapsulation by hiding more implementation=
 details from the user.</div><div>&nbsp;</div><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><br></div><div>One issue that crossed=
 my mind when thinking about "breaking" an existing class: it should not be=
 possible to add a "hidden" private member that adds an overload to an exis=
ting declared private member. &nbsp;I don't know if there's a similar const=
raint elsewhere in the standard, or if it'd be completely new...</div></div=
></blockquote><div><br></div><div>I think its probably ok to do this. You c=
an define overloads for normal functions anywhere. Why not private member f=
unctions. The only taboo in my mind is breaking encapsulation, which is wha=
t would happen if we allowed extension of public, protected, data members, =
and/or virtual.&nbsp;</div></div></div>

<p></p>

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

------=_Part_73_26043117.1384435602754--

.

------=_Part_256_16224438.1384437557089
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, November 14, 2013 2:26:42 PM UTC+1, fmatth...@gmail.com wrote:
[SNIP]

> We can write 2 competing proposals. Either one I'd be happy with to
> improve compile times and improve encapsulation by hiding more
> implementation details from the user.
>

The original goal  / scope of my (would be) class-namespace proposal is to
allow writing the implementation of class members with a less verbose /
more uniform (with regards to the declaration) syntax, shoehorning these
hidden-private members into it doesn't seem like a good idea to me any
more, so if anything solid comes out from this proposal, I'll address it in
the class-namespace proposal, too, if appropriate, but I won't introduce
this feature there.


>
>
>>
>> One issue that crossed my mind when thinking about "breaking" an existing
>> class: it should not be possible to add a "hidden" private member that adds
>> an overload to an existing declared private member.  I don't know if
>> there's a similar constraint elsewhere in the standard, or if it'd be
>> completely new...
>>
>
> I think its probably ok to do this. You can define overloads for normal
> functions anywhere. Why not private member functions. The only taboo in my
> mind is breaking encapsulation, which is what would happen if we allowed
> extension of public, protected, data members, and/or virtual.
>

But you _can_ break encapsulation by introducing private overloads,
consider this example:

class Foo {
   int bar_;
   // ...
   int getBarImpl() const;
public:
   int getBar() { return getBarImpl(); }
};

// evil.cc:

// non-const override of Foo::getBarImpl():
explicit int Foo::getBarImpl() { bar_ = 42;  /* direct access to private
member... */ }
Foo f;
f.getBar(); // calls our evil override getBarImpl()


--

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

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

<div dir=3D"ltr">On Thursday, November 14, 2013 2:26:42 PM UTC+1, fmatth...=
@gmail.com wrote:<div><span style=3D"font-size: 13px;">[SNIP]</span><br></d=
iv><div><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"><div>=
We can write 2 competing proposals. Either one I'd be happy with to improve=
 compile times and improve encapsulation by hiding more implementation deta=
ils from the user.</div><div></div></div></blockquote><div><br></div><div>T=
he original goal &nbsp;/ scope of my (would be) class-namespace proposal is=
 to allow writing the implementation of class members with a less verbose /=
 more uniform (with regards to the declaration) syntax, shoehorning these h=
idden-private members into it doesn't seem like a good idea to me any more,=
 so if anything solid comes out from this proposal, I'll address it in the =
class-namespace proposal, too, if appropriate, but I won't introduce this f=
eature there.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>&nbsp;</div><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"><div><br></div><div>One issue that crossed my mind wh=
en thinking about "breaking" an existing class: it should not be possible t=
o add a "hidden" private member that adds an overload to an existing declar=
ed private member. &nbsp;I don't know if there's a similar constraint elsew=
here in the standard, or if it'd be completely new...</div></div></blockquo=
te><div><br></div><div>I think its probably ok to do this. You can define o=
verloads for normal functions anywhere. Why not private member functions. T=
he only taboo in my mind is breaking encapsulation, which is what would hap=
pen if we allowed extension of public, protected, data members, and/or virt=
ual.&nbsp;</div></div></blockquote><div><br></div><div>But you _can_ break =
encapsulation by introducing private overloads, consider this example:</div=
><div><br></div><div>class Foo {</div><div>&nbsp; &nbsp;int bar_;</div><div=
>&nbsp; &nbsp;// ...</div><div>&nbsp; &nbsp;int getBarImpl() const;</div><d=
iv>public:</div><div>&nbsp; &nbsp;int getBar() { return getBarImpl(); }</di=
v><div>};</div><div><br></div><div>// evil.cc:</div><div><br></div><div>// =
non-const override of Foo::getBarImpl():</div><div>explicit int Foo::getBar=
Impl() { bar_ =3D 42; &nbsp;/* direct access to private member... */ }</div=
></div><div>Foo f;</div><div>f.getBar(); // calls our evil override getBarI=
mpl()</div><div><br></div><div><br></div></div>

<p></p>

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

------=_Part_256_16224438.1384437557089--

.

------=_Part_349_28818427.1384522247457
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thursday, November 14, 2013 8:59:16 AM UTC-5, mitc...@gmail.com wrote:
>
> On Thursday, November 14, 2013 2:26:42 PM UTC+1, fmatth...@gmail.comwrote=
:
> [SNIP]
>
>> We can write 2 competing proposals. Either one I'd be happy with to=20
>> improve compile times and improve encapsulation by hiding more=20
>> implementation details from the user.
>>
>
> The original goal  / scope of my (would be) class-namespace proposal is t=
o=20
> allow writing the implementation of class members with a less verbose /=
=20
> more uniform (with regards to the declaration) syntax, shoehorning these=
=20
> hidden-private members into it doesn't seem like a good idea to me any=20
> more, so if anything solid comes out from this proposal, I'll address it =
in=20
> the class-namespace proposal, too, if appropriate, but I won't introduce=
=20
> this feature there.
> =20
>
>> =20
>>
>>>
>>> One issue that crossed my mind when thinking about "breaking" an=20
>>> existing class: it should not be possible to add a "hidden" private mem=
ber=20
>>> that adds an overload to an existing declared private member.  I don't =
know=20
>>> if there's a similar constraint elsewhere in the standard, or if it'd b=
e=20
>>> completely new...
>>>
>>
>> I think its probably ok to do this. You can define overloads for normal=
=20
>> functions anywhere. Why not private member functions. The only taboo in =
my=20
>> mind is breaking encapsulation, which is what would happen if we allowed=
=20
>> extension of public, protected, data members, and/or virtual.=20
>>
>
> But you _can_ break encapsulation by introducing private overloads,=20
> consider this example:
>
> class Foo {
>    int bar_;
>    // ...
>    int getBarImpl() const;
> public:
>    int getBar() { return getBarImpl(); }
> };
>
> // evil.cc:
>
> // non-const override of Foo::getBarImpl():
> explicit int Foo::getBarImpl() { bar_ =3D 42;  /* direct access to privat=
e=20
> member... */ }
> Foo f;
> f.getBar(); // calls our evil override getBarImpl()
>
> Actually I don't even think this hole will work as intended. Consider thi=
s=20
example:

http://gcc.godbolt.org/#%7B%22version%22%3A3%2C%22filterAsm%22%3A%7B%22labe=
ls%22%3Atrue%2C%22directives%22%3Atrue%2C%22commentOnly%22%3Atrue%7D%2C%22c=
ompilers%22%3A%5B%7B%22source%22%3A%22%5Cn%5Cn%5Cnint%20foo(const%20int%26%=
20i)%20%7B%5Cn%20%20return%201%3B%5Cn%7D%5Cn%5Cninline%20int%20bar()%20%7B%=
5Cn%20%20int%20x%20%3D%202%3B%5Cn%20%20return%20foo(x)%3B%5Cn%7D%5Cn%5Cntem=
plate%20%3Ctypename%20T%3E%5Cninline%20int%20baz()%20%7B%5Cn%20%20T%20x%20%=
3D%202%3B%5Cn%20%20return%20foo(x)%3B%5Cn%7D%5Cn%5Cnint%20foo(int%26%20i)%2=
0%7B%5Cn%20%20return%203%3B%5Cn%7D%5Cn%5Cnint%20main()%20%7B%5Cn%20%20%2F%2=
Funcomment%20to%20see%20result%5Cn%20%20%2F%2Freturn%20bar()%3B%5Cn%20%20%2=
F%2Freturn%20baz%3Cint%3E()%3B%5Cn%20%20return%20baz%3Cconst%20int%3E()%3B%=
5Cn%7D%22%2C%22compiler%22%3A%22%2Fusr%2Fbin%2Fg%2B%2B-4.8%22%2C%22options%=
22%3A%22-O3%20-march%3Dnative%20-std%3Dc%2B%2B11%20%22%7D%5D%7D
=20

--=20

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

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

<div dir=3D"ltr"><br><br>On Thursday, November 14, 2013 8:59:16 AM UTC-5, m=
itc...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">On Thursday, November 14, 2013 2:26:42 PM UTC+1, <a>fmatth...@gma=
il.com</a> wrote:<div><span style=3D"font-size:13px">[SNIP]</span><br></div=
><div><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"><div>We can =
write 2 competing proposals. Either one I'd be happy with to improve compil=
e times and improve encapsulation by hiding more implementation details fro=
m the user.</div><div></div></div></blockquote><div><br></div><div>The orig=
inal goal &nbsp;/ scope of my (would be) class-namespace proposal is to all=
ow writing the implementation of class members with a less verbose / more u=
niform (with regards to the declaration) syntax, shoehorning these hidden-p=
rivate members into it doesn't seem like a good idea to me any more, so if =
anything solid comes out from this proposal, I'll address it in the class-n=
amespace proposal, too, if appropriate, but I won't introduce this feature =
there.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><br></div><div>One issue that crossed my mind when thinking =
about "breaking" an existing class: it should not be possible to add a "hid=
den" private member that adds an overload to an existing declared private m=
ember. &nbsp;I don't know if there's a similar constraint elsewhere in the =
standard, or if it'd be completely new...</div></div></blockquote><div><br>=
</div><div>I think its probably ok to do this. You can define overloads for=
 normal functions anywhere. Why not private member functions. The only tabo=
o in my mind is breaking encapsulation, which is what would happen if we al=
lowed extension of public, protected, data members, and/or virtual.&nbsp;</=
div></div></blockquote><div><br></div><div>But you _can_ break encapsulatio=
n by introducing private overloads, consider this example:</div><div><br></=
div><div>class Foo {</div><div>&nbsp; &nbsp;int bar_;</div><div>&nbsp; &nbs=
p;// ...</div><div>&nbsp; &nbsp;int getBarImpl() const;</div><div>public:</=
div><div>&nbsp; &nbsp;int getBar() { return getBarImpl(); }</div><div>};</d=
iv><div><br></div><div>// evil.cc:</div><div><br></div><div>// non-const ov=
erride of Foo::getBarImpl():</div><div>explicit int Foo::getBarImpl() { bar=
_ =3D 42; &nbsp;/* direct access to private member... */ }</div></div><div>=
Foo f;</div><div>f.getBar(); // calls our evil override getBarImpl()</div><=
div><br></div></div></blockquote><div>Actually I don't even think this hole=
 will work as intended. Consider this example:</div><div><br></div><div><a =
href=3D"http://gcc.godbolt.org/#%7B%22version%22%3A3%2C%22filterAsm%22%3A%7=
B%22labels%22%3Atrue%2C%22directives%22%3Atrue%2C%22commentOnly%22%3Atrue%7=
D%2C%22compilers%22%3A%5B%7B%22source%22%3A%22%5Cn%5Cn%5Cnint%20foo(const%2=
0int%26%20i)%20%7B%5Cn%20%20return%201%3B%5Cn%7D%5Cn%5Cninline%20int%20bar(=
)%20%7B%5Cn%20%20int%20x%20%3D%202%3B%5Cn%20%20return%20foo(x)%3B%5Cn%7D%5C=
n%5Cntemplate%20%3Ctypename%20T%3E%5Cninline%20int%20baz()%20%7B%5Cn%20%20T=
%20x%20%3D%202%3B%5Cn%20%20return%20foo(x)%3B%5Cn%7D%5Cn%5Cnint%20foo(int%2=
6%20i)%20%7B%5Cn%20%20return%203%3B%5Cn%7D%5Cn%5Cnint%20main()%20%7B%5Cn%20=
%20%2F%2Funcomment%20to%20see%20result%5Cn%20%20%2F%2Freturn%20bar()%3B%5Cn=
%20%20%2F%2Freturn%20baz%3Cint%3E()%3B%5Cn%20%20return%20baz%3Cconst%20int%=
3E()%3B%5Cn%7D%22%2C%22compiler%22%3A%22%2Fusr%2Fbin%2Fg%2B%2B-4.8%22%2C%22=
options%22%3A%22-O3%20-march%3Dnative%20-std%3Dc%2B%2B11%20%22%7D%5D%7D" st=
yle=3D"font-size: 13px;">http://gcc.godbolt.org/#%7B%22version%22%3A3%2C%22=
filterAsm%22%3A%7B%22labels%22%3Atrue%2C%22directives%22%3Atrue%2C%22commen=
tOnly%22%3Atrue%7D%2C%22compilers%22%3A%5B%7B%22source%22%3A%22%5Cn%5Cn%5Cn=
int%20foo(const%20int%26%20i)%20%7B%5Cn%20%20return%201%3B%5Cn%7D%5Cn%5Cnin=
line%20int%20bar()%20%7B%5Cn%20%20int%20x%20%3D%202%3B%5Cn%20%20return%20fo=
o(x)%3B%5Cn%7D%5Cn%5Cntemplate%20%3Ctypename%20T%3E%5Cninline%20int%20baz()=
%20%7B%5Cn%20%20T%20x%20%3D%202%3B%5Cn%20%20return%20foo(x)%3B%5Cn%7D%5Cn%5=
Cnint%20foo(int%26%20i)%20%7B%5Cn%20%20return%203%3B%5Cn%7D%5Cn%5Cnint%20ma=
in()%20%7B%5Cn%20%20%2F%2Funcomment%20to%20see%20result%5Cn%20%20%2F%2Fretu=
rn%20bar()%3B%5Cn%20%20%2F%2Freturn%20baz%3Cint%3E()%3B%5Cn%20%20return%20b=
az%3Cconst%20int%3E()%3B%5Cn%7D%22%2C%22compiler%22%3A%22%2Fusr%2Fbin%2Fg%2=
B%2B-4.8%22%2C%22options%22%3A%22-O3%20-march%3Dnative%20-std%3Dc%2B%2B11%2=
0%22%7D%5D%7D</a>&nbsp;</div></div>

<p></p>

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

------=_Part_349_28818427.1384522247457--

.

------=_Part_1032_9115913.1384626091663
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think it has been stated before in this thread that methods called by=20
inline methods declared in the class head must be in the class head. This=
=20
should mean that only overloads visible at the point of definition of the=
=20
calling inline method's body should be considered whenever that method is=
=20
instantiated or inlined. In the example this would mean that getBar() could=
=20
never call the non-const version of getBarImpl().

Maybe this was what you meant, "fmatth"?


When it comes to extension methods vs. opening a class scope to implement=
=20
methods I think these should be two orthogonal features. I also suggest to=
=20
use another syntax than "class namespaec Foo" to reopening a class. Like=20
this:

Foo:: {
    // Implement methods declared in class head:
    void Foo(int) {}    // A ctor
    int GetPi() { return 3; }   // Some other method

    // Combination of both features adds an extension method without=20
stating Foo::
    explicit void ExtraMethod() { cout << "Extra" << endl; }
}

// A "regular" extension method.
explicit void Foo::AdditionalExtra()
{
}


It could also be considered to replace the explicit keyword with "private"=
=20
as it makes it clear that the method is private. The drawback could be that=
=20
it becomes a bit hard to explain that if you put "private" in front of a=20
method declared in the class head it is an error while if you do it in=20
front of another method signature it is ok. Anyway, I think I would=20
personally prefer "private":

private void Foo::AnotherExtension()
{
}

Another drawback could be that some would ask why public and protected are=
=20
not allowed in the same way...


Den fredagen den 15:e november 2013 kl. 14:30:47 UTC+1 skrev=20
fmatth...@gmail.com:
>
>
>
> On Thursday, November 14, 2013 8:59:16 AM UTC-5, mitc...@gmail.com wrote:
>>
>> On Thursday, November 14, 2013 2:26:42 PM UTC+1, fmatth...@gmail.comwrot=
e:
>> [SNIP]
>>
>>> We can write 2 competing proposals. Either one I'd be happy with to=20
>>> improve compile times and improve encapsulation by hiding more=20
>>> implementation details from the user.
>>>
>>
>> The original goal  / scope of my (would be) class-namespace proposal is=
=20
>> to allow writing the implementation of class members with a less verbose=
 /=20
>> more uniform (with regards to the declaration) syntax, shoehorning these=
=20
>> hidden-private members into it doesn't seem like a good idea to me any=
=20
>> more, so if anything solid comes out from this proposal, I'll address it=
 in=20
>> the class-namespace proposal, too, if appropriate, but I won't introduce=
=20
>> this feature there.
>> =20
>>
>>> =20
>>>
>>>>
>>>> One issue that crossed my mind when thinking about "breaking" an=20
>>>> existing class: it should not be possible to add a "hidden" private me=
mber=20
>>>> that adds an overload to an existing declared private member.  I don't=
 know=20
>>>> if there's a similar constraint elsewhere in the standard, or if it'd =
be=20
>>>> completely new...
>>>>
>>>
>>> I think its probably ok to do this. You can define overloads for normal=
=20
>>> functions anywhere. Why not private member functions. The only taboo in=
 my=20
>>> mind is breaking encapsulation, which is what would happen if we allowe=
d=20
>>> extension of public, protected, data members, and/or virtual.=20
>>>
>>
>> But you _can_ break encapsulation by introducing private overloads,=20
>> consider this example:
>>
>> class Foo {
>>    int bar_;
>>    // ...
>>    int getBarImpl() const;
>> public:
>>    int getBar() { return getBarImpl(); }
>> };
>>
>> // evil.cc:
>>
>> // non-const override of Foo::getBarImpl():
>> explicit int Foo::getBarImpl() { bar_ =3D 42;  /* direct access to priva=
te=20
>> member... */ }
>> Foo f;
>> f.getBar(); // calls our evil override getBarImpl()
>>
>> Actually I don't even think this hole will work as intended. Consider=20
> this example:
>
>
> http://gcc.godbolt.org/#%7B%22version%22%3A3%2C%22filterAsm%22%3A%7B%22la=
bels%22%3Atrue%2C%22directives%22%3Atrue%2C%22commentOnly%22%3Atrue%7D%2C%2=
2compilers%22%3A%5B%7B%22source%22%3A%22%5Cn%5Cn%5Cnint%20foo(const%20int%2=
6%20i)%20%7B%5Cn%20%20return%201%3B%5Cn%7D%5Cn%5Cninline%20int%20bar()%20%7=
B%5Cn%20%20int%20x%20%3D%202%3B%5Cn%20%20return%20foo(x)%3B%5Cn%7D%5Cn%5Cnt=
emplate%20%3Ctypename%20T%3E%5Cninline%20int%20baz()%20%7B%5Cn%20%20T%20x%2=
0%3D%202%3B%5Cn%20%20return%20foo(x)%3B%5Cn%7D%5Cn%5Cnint%20foo(int%26%20i)=
%20%7B%5Cn%20%20return%203%3B%5Cn%7D%5Cn%5Cnint%20main()%20%7B%5Cn%20%20%2F=
%2Funcomment%20to%20see%20result%5Cn%20%20%2F%2Freturn%20bar()%3B%5Cn%20%20=
%2F%2Freturn%20baz%3Cint%3E()%3B%5Cn%20%20return%20baz%3Cconst%20int%3E()%3=
B%5Cn%7D%22%2C%22compiler%22%3A%22%2Fusr%2Fbin%2Fg%2B%2B-4.8%22%2C%22option=
s%22%3A%22-O3%20-march%3Dnative%20-std%3Dc%2B%2B11%20%22%7D%5D%7D
> =20
>

--=20

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

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

<div dir=3D"ltr">I think it has been stated before in this thread that meth=
ods called by inline methods declared in the class head must be in the clas=
s head. This should mean that only overloads visible at the point of defini=
tion of the calling inline method's body should be considered whenever that=
 method is instantiated or inlined. In the example this would mean that get=
Bar() could never call the non-const version of getBarImpl().<div><br></div=
><div>Maybe this was what you meant, "fmatth"?</div><div><br></div><div><br=
></div><div>When it comes to extension methods vs. opening a class scope to=
 implement methods I think these should be two orthogonal features. I also =
suggest to use another syntax than "class namespaec Foo" to reopening a cla=
ss. Like this:</div><div><br></div><div>Foo:: {</div><div>&nbsp; &nbsp; // =
Implement methods declared in class head:</div><div>&nbsp; &nbsp; void Foo(=
int) {} &nbsp; &nbsp;// A ctor</div><div>&nbsp; &nbsp; int GetPi() { return=
 3; } &nbsp; // Some other method</div><div><br></div><div>&nbsp; &nbsp; //=
 Combination of both features adds an extension method without stating Foo:=
:</div><div>&nbsp; &nbsp; explicit void ExtraMethod() { cout &lt;&lt; "Extr=
a" &lt;&lt; endl; }</div><div>}</div><div><br></div><div>// A "regular" ext=
ension method.</div><div>explicit void Foo::AdditionalExtra()</div><div>{</=
div><div>}</div><div><br></div><div><br></div><div>It could also be conside=
red to replace the explicit keyword with "private" as it makes it clear tha=
t the method is private. The drawback could be that it becomes a bit hard t=
o explain that if you put "private" in front of a method declared in the cl=
ass head it is an error while if you do it in front of another method signa=
ture it is ok. Anyway, I think I would personally prefer "private":</div><d=
iv><br></div><div>private void Foo::AnotherExtension()</div><div>{</div><di=
v>}<br><div><br></div><div>Another drawback could be that some would ask wh=
y public and protected are not allowed in the same way...</div><div><br><br=
>Den fredagen den 15:e november 2013 kl. 14:30:47 UTC+1 skrev fmatth...@gma=
il.com:<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><b=
r>On Thursday, November 14, 2013 8:59:16 AM UTC-5, <a>mitc...@gmail.com</a>=
 wrote:<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">On Thursday=
, November 14, 2013 2:26:42 PM UTC+1, <a>fmatth...@gmail.com</a> wrote:<div=
><span style=3D"font-size:13px">[SNIP]</span><br></div><div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div>We can write 2 competing pro=
posals. Either one I'd be happy with to improve compile times and improve e=
ncapsulation by hiding more implementation details from the user.</div><div=
></div></div></blockquote><div><br></div><div>The original goal &nbsp;/ sco=
pe of my (would be) class-namespace proposal is to allow writing the implem=
entation of class members with a less verbose / more uniform (with regards =
to the declaration) syntax, shoehorning these hidden-private members into i=
t doesn't seem like a good idea to me any more, so if anything solid comes =
out from this proposal, I'll address it in the class-namespace proposal, to=
o, if appropriate, but I won't introduce this feature there.</div><div>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>&nbsp=
;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></=
div><div>One issue that crossed my mind when thinking about "breaking" an e=
xisting class: it should not be possible to add a "hidden" private member t=
hat adds an overload to an existing declared private member. &nbsp;I don't =
know if there's a similar constraint elsewhere in the standard, or if it'd =
be completely new...</div></div></blockquote><div><br></div><div>I think it=
s probably ok to do this. You can define overloads for normal functions any=
where. Why not private member functions. The only taboo in my mind is break=
ing encapsulation, which is what would happen if we allowed extension of pu=
blic, protected, data members, and/or virtual.&nbsp;</div></div></blockquot=
e><div><br></div><div>But you _can_ break encapsulation by introducing priv=
ate overloads, consider this example:</div><div><br></div><div>class Foo {<=
/div><div>&nbsp; &nbsp;int bar_;</div><div>&nbsp; &nbsp;// ...</div><div>&n=
bsp; &nbsp;int getBarImpl() const;</div><div>public:</div><div>&nbsp; &nbsp=
;int getBar() { return getBarImpl(); }</div><div>};</div><div><br></div><di=
v>// evil.cc:</div><div><br></div><div>// non-const override of Foo::getBar=
Impl():</div><div>explicit int Foo::getBarImpl() { bar_ =3D 42; &nbsp;/* di=
rect access to private member... */ }</div></div><div>Foo f;</div><div>f.ge=
tBar(); // calls our evil override getBarImpl()</div><div><br></div></div><=
/blockquote><div>Actually I don't even think this hole will work as intende=
d. Consider this example:</div><div><br></div><div><a href=3D"http://gcc.go=
dbolt.org/#%7B%22version%22%3A3%2C%22filterAsm%22%3A%7B%22labels%22%3Atrue%=
2C%22directives%22%3Atrue%2C%22commentOnly%22%3Atrue%7D%2C%22compilers%22%3=
A%5B%7B%22source%22%3A%22%5Cn%5Cn%5Cnint%20foo(const%20int%26%20i)%20%7B%5C=
n%20%20return%201%3B%5Cn%7D%5Cn%5Cninline%20int%20bar()%20%7B%5Cn%20%20int%=
20x%20%3D%202%3B%5Cn%20%20return%20foo(x)%3B%5Cn%7D%5Cn%5Cntemplate%20%3Cty=
pename%20T%3E%5Cninline%20int%20baz()%20%7B%5Cn%20%20T%20x%20%3D%202%3B%5Cn=
%20%20return%20foo(x)%3B%5Cn%7D%5Cn%5Cnint%20foo(int%26%20i)%20%7B%5Cn%20%2=
0return%203%3B%5Cn%7D%5Cn%5Cnint%20main()%20%7B%5Cn%20%20%2F%2Funcomment%20=
to%20see%20result%5Cn%20%20%2F%2Freturn%20bar()%3B%5Cn%20%20%2F%2Freturn%20=
baz%3Cint%3E()%3B%5Cn%20%20return%20baz%3Cconst%20int%3E()%3B%5Cn%7D%22%2C%=
22compiler%22%3A%22%2Fusr%2Fbin%2Fg%2B%2B-4.8%22%2C%22options%22%3A%22-O3%2=
0-march%3Dnative%20-std%3Dc%2B%2B11%20%22%7D%5D%7D" style=3D"font-size:13px=
" target=3D"_blank">http://gcc.godbolt.org/#%7B%<wbr>22version%22%3A3%2C%<w=
br>22filterAsm%22%3A%7B%22labels%<wbr>22%3Atrue%2C%22directives%22%<wbr>3At=
rue%2C%22commentOnly%22%<wbr>3Atrue%7D%2C%22compilers%22%<wbr>3A%5B%7B%22so=
urce%22%3A%22%<wbr>5Cn%5Cn%5Cnint%20foo(const%<wbr>20int%26%20i)%20%7B%5Cn%=
20%<wbr>20return%201%3B%5Cn%7D%5Cn%<wbr>5Cninline%20int%20bar()%20%7B%<wbr>=
5Cn%20%20int%20x%20%3D%202%3B%<wbr>5Cn%20%20return%20foo(x)%3B%<wbr>5Cn%7D%=
5Cn%5Cntemplate%20%<wbr>3Ctypename%20T%3E%5Cninline%<wbr>20int%20baz()%20%7=
B%5Cn%20%<wbr>20T%20x%20%3D%202%3B%5Cn%20%<wbr>20return%20foo(x)%3B%5Cn%7D%=
<wbr>5Cn%5Cnint%20foo(int%26%20i)%<wbr>20%7B%5Cn%20%20return%203%3B%<wbr>5C=
n%7D%5Cn%5Cnint%20main()%20%<wbr>7B%5Cn%20%20%2F%2Funcomment%<wbr>20to%20se=
e%20result%5Cn%20%20%<wbr>2F%2Freturn%20bar()%3B%5Cn%20%<wbr>20%2F%2Freturn=
%20baz%3Cint%3E(<wbr>)%3B%5Cn%20%20return%20baz%<wbr>3Cconst%20int%3E()%3B%=
5Cn%7D%<wbr>22%2C%22compiler%22%3A%22%<wbr>2Fusr%2Fbin%2Fg%2B%2B-4.8%22%<wb=
r>2C%22options%22%3A%22-O3%20-<wbr>march%3Dnative%20-std%3Dc%2B%<wbr>2B11%2=
0%22%7D%5D%7D</a>&nbsp;</div></div></blockquote></div></div></div>

<p></p>

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

------=_Part_1032_9115913.1384626091663--

.