On 2017-08-12 10:25, Nicol Bolas wrote:
> That being said, it should be noted that much of the reason for pimpl will
> be made obsolete once we get modules.

Does "much of the reason" include binary compatibility?

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/776a479a-7154-4c7e-1a6f-8f2e2f36f1a7%40gmail.com.

.

------=_Part_6665_1402979493.1502824193328
Content-Type: multipart/alternative;
 boundary="----=_Part_6666_258955521.1502824193329"

------=_Part_6666_258955521.1502824193329
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 15, 2017 at 2:38:06 PM UTC-4, Matthew Woehlke wrote:
>
> On 2017-08-12 10:25, Nicol Bolas wrote:
> > That being said, it should be noted that much of the reason for pimpl
> will
> > be made obsolete once we get modules.
>
> Does "much of the reason" include binary compatibility?
>

If you mean that one library can change aspects of a class's implementation
which are not reflected in its class definition without the consuming code
having to be recompiled? The answer is yes.

If you mean that one library can change private definitions of an interface
class without the consuming code having to be recompiled? The answer is no.

If you mean that the inevitable recompile from item 2 will be *far faster*
due to not having to recompile the standard library, Boost, and every other
thing that *wasn't* changed just because they're being included in a .cpp
file that has to be recompiled? The answer is yes.

So it all really depends on why you used Pimpl in the first place.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/edb223ba-d184-4bb4-8f2c-5025d9e884f7%40isocpp.org.

------=_Part_6666_258955521.1502824193329
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 15, 2017 at 2:38:06 PM UTC-4, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-08-12 10:=
25, Nicol Bolas wrote:
<br>&gt; That being said, it should be noted that much of the reason for pi=
mpl will=20
<br>&gt; be made obsolete once we get modules.
<br>
<br>Does &quot;much of the reason&quot; include binary compatibility?
<br></blockquote><div><br>If you mean that one library can change aspects o=
f a class&#39;s implementation which are not reflected in its class definit=
ion without the consuming code having to be recompiled? The answer is yes.<=
br><br>If you mean that one library can change private definitions of an in=
terface class without the consuming code having to be recompiled? The answe=
r is no.<br><br>If you mean that the inevitable recompile from item 2 will =
be <i>far faster</i> due to not having to recompile the standard library, B=
oost, and every other thing that <i>wasn&#39;t</i> changed just because the=
y&#39;re being included in a .cpp file that has to be recompiled? The answe=
r is yes.<br><br>So it all really depends on why you used Pimpl in the firs=
t place.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/edb223ba-d184-4bb4-8f2c-5025d9e884f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/edb223ba-d184-4bb4-8f2c-5025d9e884f7=
%40isocpp.org</a>.<br />

------=_Part_6666_258955521.1502824193329--

------=_Part_6665_1402979493.1502824193328--

.

On 2017-08-15 15:09, Nicol Bolas wrote:
> On Tuesday, August 15, 2017 at 2:38:06 PM UTC-4, Matthew Woehlke wrote:
>> On 2017-08-12 10:25, Nicol Bolas wrote:=20
>>> That being said, it should be noted that much of the reason for pimpl=
=20
>>> will be made obsolete once we get modules.=20
>>
>> Does "much of the reason" include binary compatibility?=20
>=20
> If you mean that one library can change aspects of a class's implementati=
on=20
> which are not reflected in its class definition without the consuming cod=
e=20
> having to be recompiled? The answer is yes.
>=20
> If you mean that one library can change private definitions of an interfa=
ce=20
> class without the consuming code having to be recompiled? The answer is n=
o.
>=20
> If you mean that the inevitable recompile from item 2 will be *far faster=
*=20
> due to not having to recompile the standard library, Boost, and every oth=
er=20
> thing that *wasn't* changed just because they're being included in a .cpp=
=20
> file that has to be recompiled? The answer is yes.

So... that would be a "no".

Why?

Let's take Qt, for example. Widely used; lots of consumers. Uses PIMPL
to ensure BC. This means that Qt is updated... I can just update Qt, and
(hopefully) nothing breaks.

If Qt wasn't using PIMPL, then I would need to recompile *my entire
desktop environment* (that's on the order of 50-100 libraries and
applications). Actually, it's worse, because *I* am not recompiling
them. The recompile (which may in fact be much faster) happens on some
build farm. The cost *I* pay =E2=80=94 which *everyone* pays =E2=80=94 is i=
n downloading
and installing all those updates. Modules won't affect those costs.

....which is why Qt uses PIMPL, and will continue to use PIMPL even
post-modules.

I'm not even convinced that modules are a reason to stop using PIMPL, or
other dependency-reducing techniques. Recompiling "much faster" still
doesn't beat "not needed", even in the quantitative sense, never mind
the qualitative difference (especially in the case of libraries with
external consumers)...

All that said, I don't see where the OP's proposal offers significant
any benefit over traditional PIMPL. At best it reduces boilerplate.

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e40503eb-6c2c-eebc-2fde-40866e8629dd%40gmail.com=
..

.

------=_Part_6835_1195827043.1502828765225
Content-Type: multipart/alternative;
 boundary="----=_Part_6836_1793254240.1502828765225"

------=_Part_6836_1793254240.1502828765225
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, August 15, 2017 at 4:09:27 PM UTC-4, Matthew Woehlke wrote:
>
> On 2017-08-15 15:09, Nicol Bolas wrote:=20
> > On Tuesday, August 15, 2017 at 2:38:06 PM UTC-4, Matthew Woehlke wrote:=
=20
> >> On 2017-08-12 10:25, Nicol Bolas wrote:=20
> >>> That being said, it should be noted that much of the reason for pimpl=
=20
> >>> will be made obsolete once we get modules.=20
> >>=20
> >> Does "much of the reason" include binary compatibility?=20
> >=20
> > If you mean that one library can change aspects of a class's=20
> implementation=20
> > which are not reflected in its class definition without the consuming=
=20
> code=20
> > having to be recompiled? The answer is yes.=20
> >=20
> > If you mean that one library can change private definitions of an=20
> interface=20
> > class without the consuming code having to be recompiled? The answer is=
=20
> no.=20
> >=20
> > If you mean that the inevitable recompile from item 2 will be *far=20
> faster*=20
> > due to not having to recompile the standard library, Boost, and every=
=20
> other=20
> > thing that *wasn't* changed just because they're being included in a=20
> .cpp=20
> > file that has to be recompiled? The answer is yes.=20
>
> So... that would be a "no".=20
>
> Why?
>

Because C++ doesn't allow that sort of thing.

C++ is a statically typed language. If you have a class, that class has a=
=20
certain size. It has a certain set of member variables. And you can't=20
change them without recompiling every piece of code that uses it.

And let's not forget: just because a class has private stuff in it doesn't=
=20
mean that the private stuff has no bearing on the class's interface.=20
Especially with reflection allowing you to reflect into privates easily.=20
Privates are not accessible, but they're not invisible or irrelevant.

The goal of modules is not to change the nature of how your code can=20
interact with an external library. It's to make it so that you don't have=
=20
to keep recompiling stuff that doesn't change.

Let's take Qt, for example. Widely used; lots of consumers. Uses PIMPL=20
> to ensure BC. This means that Qt is updated... I can just update Qt, and=
=20
> (hopefully) nothing breaks.=20
>
> If Qt wasn't using PIMPL, then I would need to recompile *my entire=20
> desktop environment* (that's on the order of 50-100 libraries and=20
> applications). Actually, it's worse, because *I* am not recompiling=20
> them. The recompile (which may in fact be much faster) happens on some=20
> build farm. The cost *I* pay =E2=80=94 which *everyone* pays =E2=80=94 is=
 in downloading=20
> and installing all those updates. Modules won't affect those costs.=20
>
> ...which is why Qt uses PIMPL, and will continue to use PIMPL even=20
> post-modules.
>

Pimpl only provides protection from changes to the private interface of a=
=20
class. You still need a recompile whenever new API functions are added.

I'm not even convinced that modules are a reason to stop using PIMPL, or=20
> other dependency-reducing techniques. Recompiling "much faster" still=20
> doesn't beat "not needed", even in the quantitative sense, never mind=20
> the qualitative difference (especially in the case of libraries with=20
> external consumers)...
>

Sure. But "much faster" is good enough in many cases; bothering to remove=
=20
that last 5% of your full-build recompile time may not be worth it. After=
=20
all, Pimpl isn't exactly free or anything; it has costs. If those costs are=
=20
not worth getting slightly better compile time, then why do it?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/704bcb01-316b-4fb3-bd80-23108f693359%40isocpp.or=
g.

------=_Part_6836_1793254240.1502828765225
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 15, 2017 at 4:09:27 PM UTC-4, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-08-15 15:=
09, Nicol Bolas wrote:
<br>&gt; On Tuesday, August 15, 2017 at 2:38:06 PM UTC-4, Matthew Woehlke w=
rote:
<br>&gt;&gt; On 2017-08-12 10:25, Nicol Bolas wrote:=20
<br>&gt;&gt;&gt; That being said, it should be noted that much of the reaso=
n for pimpl=20
<br>&gt;&gt;&gt; will be made obsolete once we get modules.=20
<br>&gt;&gt;
<br>&gt;&gt; Does &quot;much of the reason&quot; include binary compatibili=
ty?=20
<br>&gt;=20
<br>&gt; If you mean that one library can change aspects of a class&#39;s i=
mplementation=20
<br>&gt; which are not reflected in its class definition without the consum=
ing code=20
<br>&gt; having to be recompiled? The answer is yes.
<br>&gt;=20
<br>&gt; If you mean that one library can change private definitions of an =
interface=20
<br>&gt; class without the consuming code having to be recompiled? The answ=
er is no.
<br>&gt;=20
<br>&gt; If you mean that the inevitable recompile from item 2 will be *far=
 faster*=20
<br>&gt; due to not having to recompile the standard library, Boost, and ev=
ery other=20
<br>&gt; thing that *wasn&#39;t* changed just because they&#39;re being inc=
luded in a .cpp=20
<br>&gt; file that has to be recompiled? The answer is yes.
<br>
<br>So... that would be a &quot;no&quot;.
<br>
<br>Why?<br></blockquote><div><br>Because C++ doesn&#39;t allow that sort o=
f thing.<br><br>C++ is a statically typed language. If you have a class, th=
at class has a certain size. It has a certain set of member variables. And =
you can&#39;t change them without recompiling every piece of code that uses=
 it.<br><br>And let&#39;s not forget: just because a class has private stuf=
f in it doesn&#39;t mean that the private stuff has no bearing on the class=
&#39;s interface. Especially with reflection allowing you to reflect into p=
rivates easily. Privates are not accessible, but they&#39;re not invisible =
or irrelevant.<br><br>The goal of modules is not to change the nature of ho=
w your code can interact with an external library. It&#39;s to make it so t=
hat you don&#39;t have to keep recompiling stuff that doesn&#39;t change.<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Let&#39;s take Qt, for example. Widely used; lots of consumers. Uses PIMPL
<br>to ensure BC. This means that Qt is updated... I can just update Qt, an=
d
<br>(hopefully) nothing breaks.
<br>
<br>If Qt wasn&#39;t using PIMPL, then I would need to recompile *my entire
<br>desktop environment* (that&#39;s on the order of 50-100 libraries and
<br>applications). Actually, it&#39;s worse, because *I* am not recompiling
<br>them. The recompile (which may in fact be much faster) happens on some
<br>build farm. The cost *I* pay =E2=80=94 which *everyone* pays =E2=80=94 =
is in downloading
<br>and installing all those updates. Modules won&#39;t affect those costs.
<br>
<br>...which is why Qt uses PIMPL, and will continue to use PIMPL even
<br>post-modules.<br></blockquote><div><br>Pimpl only provides protection f=
rom changes to the private interface of a class. You still need a recompile=
 whenever new API functions are added.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
I&#39;m not even convinced that modules are a reason to stop using PIMPL, o=
r
<br>other dependency-reducing techniques. Recompiling &quot;much faster&quo=
t; still
<br>doesn&#39;t beat &quot;not needed&quot;, even in the quantitative sense=
, never mind
<br>the qualitative difference (especially in the case of libraries with
<br>external consumers)...<br></blockquote><div><br>Sure. But &quot;much fa=
ster&quot; is good enough in many cases; bothering to remove that last 5% o=
f your full-build recompile time may not be worth it. After all, Pimpl isn&=
#39;t exactly free or anything; it has costs. If those costs are not worth =
getting slightly better compile time, then why do it?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/704bcb01-316b-4fb3-bd80-23108f693359%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/704bcb01-316b-4fb3-bd80-23108f693359=
%40isocpp.org</a>.<br />

------=_Part_6836_1793254240.1502828765225--

------=_Part_6835_1195827043.1502828765225--

.

On Tuesday, 15 August 2017 13:09:23 PDT Matthew Woehlke wrote:
> ...which is why Qt uses PIMPL, and will continue to use PIMPL even
> post-modules.

Even if modules did solve the problem, we would continue using d pointers
until at least 2025, probably a little more (Qt 7.0).

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

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2375233.kqf2j2mDIg%40tjmaciei-mobl1.

.

On 2017-08-15 16:26, Nicol Bolas wrote:
> On Tuesday, August 15, 2017 at 4:09:27 PM UTC-4, Matthew Woehlke wrote:
>> On 2017-08-15 15:09, Nicol Bolas wrote:
>>> On Tuesday, August 15, 2017 at 2:38:06 PM UTC-4, Matthew Woehlke wrote:
>>>> On 2017-08-12 10:25, Nicol Bolas wrote:
>>>>> That being said, it should be noted that much of the reason for pimpl
>>>>> will be made obsolete once we get modules.
>>>>
>>>> Does "much of the reason" include binary compatibility?
>>>
>>> [...]
>>
>> So... that would be a "no".
>>
>> Why?
>
> Because C++ doesn't allow that sort of thing.

This seems like a somewhat pedantic use of "allow". With PIMPL, the
class keeps its private stuff in a separate, opaque class, and keeps
only a pointer to that "private class" as its visible definition. That's
certainly "allowed" in the sense that there is lots of C++ code using
this idiom that can be compiled.

> Pimpl only provides protection from changes to the private interface of a
> class. You still need a recompile whenever new API functions are added.

Uh... no? Adding (non-member or non-virtual member) functions does not
change ABI; it is both SC and BC. In fact, there are lost of ways an API
can mutate without breaking BC; see
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
for a fairly extensive list.

Yes, many of these things may be *detectable* by consumers that are
specifically attempting to do so, but then, most (decent) libraries also
supply version information somehow.

You are perhaps applying a very pedantic meaning to "need". I (and
pretty much everyone that talks about BC/BIC) define "need" as whether
or not code built against an old version will continue to *function as
intended*.

>> I'm not even convinced that modules are a reason to stop using PIMPL, or
>> other dependency-reducing techniques. Recompiling "much faster" still
>> doesn't beat "not needed", even in the quantitative sense, never mind
>> the qualitative difference (especially in the case of libraries with
>> external consumers)...
>
> Sure. But "much faster" is good enough in many cases; bothering to remove
> that last 5% of your full-build recompile time may not be worth it.

I think we have a different definition of "many".

For stuff that's local to your project? Sure. (Were you really using
PIMPL for that before?) For stuff that's visible to external consumers?
Just the aggravation that you need to rebuild those *at all* may be
reason enough, even if it is really, really fast to rebuild them.

Not all of us are using Google's One True Repository that contains all
software in our "universe" managed under a single build tree.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2c1a20b8-3b26-1d6c-8ce8-b98ddb179a81%40gmail.com.

.

On Tuesday, 15 August 2017 14:03:17 PDT Matthew Woehlke wrote:
> > Pimpl only provides protection from changes to the private interface of a
> > class. You still need a recompile whenever new API functions are added.
>
> Uh... no? Adding (non-member or non-virtual member) functions does not
> change ABI; it is both SC and BC. In fact, there are lost of ways an API
> can mutate without breaking BC; see
> https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
> for a fairly extensive list.

Strictly speaking, the standard recognises no such thing as Binary
Compatibility for changed sources. It's ODR violation and your code is ill-
formed no diagnostic required.

Binary compatibility depends on the ABI of each platform and compiler. Knowing
the ABI allows us to violate the ODR still run.

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

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1607829.lb9YDU3Nyo%40tjmaciei-mobl1.

.

------=_Part_6961_1403491489.1502861785565
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> All that said, I don't see where the OP's proposal offers significant=20
> any benefit over traditional PIMPL. At best it reduces boilerplate.

That was my main intent. To reduce boilerplate code as depending on how com=
plicated your class is, using pimpl is even more complicated and easy to ge=
t wrong and introduce bugs/leaks.

I did/do not wish to extend this idea further as there are still quite a fe=
w other papers in flight that could affect this both for the good and the b=
ad. So for now this was just to post and get feedback to help me design and=
 write a proposal that covers everyone's points here where possible.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/81ef96ef-338e-4c67-9863-24532e154281%40isocpp.or=
g.

------=_Part_6961_1403491489.1502861785565--

.

On Tuesday, 15 August 2017 22:36:25 PDT Izzy Coding wrote:
> > All that said, I don't see where the OP's proposal offers significant
> > any benefit over traditional PIMPL. At best it reduces boilerplate.
>
> That was my main intent. To reduce boilerplate code as depending on how
> complicated your class is, using pimpl is even more complicated and easy to
> get wrong and introduce bugs/leaks.

Actually, no, it's not difficult to use.

The difficult part is keeping BC while updating the public API. Your proposal
does not make that easier, but depending on how it gets into the standard and
the ABIs, it could actually make things harder.

Besides, pimpl has one other advantage: you can derive from the public type.

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

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1886114.MqD7tOu2me%40tjmaciei-mobl1.

.