------=_Part_1940_28303952.1353623242207
Content-Type: text/plain; charset=ISO-8859-1

Conceptually, there is no reason why this could not be permitted. A class
with an incomplete data member could be considered to simply be incomplete
itself, even if there are defined member functions. This could, however, be
tricky when dealing with inheritance and other things. It would also raise
problems with ODR, as you would be effectively re-defining the class. In
addition, I'm not too sure what you would gain, because you could not do
much with this class which cannot be done now- only call member functions
on references and pointers, and possibly even only call non-virtual ones.
Plus, of course, template methods would have to only use the complete data
members... mess.

However, I believe the real solution to the problem of PIMPL generally
being a disgusting hack is to implement real modules instead of headers.

--




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

Conceptually, there is no reason why this could not be permitted. A class w=
ith an incomplete data member could be considered to simply be incomplete i=
tself, even if there are defined member functions. This could, however, be =
tricky when dealing with inheritance and other things. It would also raise =
problems with ODR, as you would be effectively re-defining the class. In ad=
dition, I'm not too sure what you would gain, because you could not do much=
 with this class which cannot be done now- only call member functions on re=
ferences and pointers, and possibly even only call non-virtual ones. Plus, =
of course, template methods would have to only use the complete data member=
s... mess.<div><br></div><div>However, I believe the real solution to the p=
roblem of PIMPL generally being a disgusting hack is to implement real modu=
les instead of headers.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1940_28303952.1353623242207--

.

------=_Part_452_32174669.1353665544861
Content-Type: text/plain; charset=ISO-8859-1

Op donderdag 22 november 2012 23:27:22 UTC+1 schreef DeadMG het volgende:

> Conceptually, there is no reason why this could not be permitted. A class
> with an incomplete data member could be considered to simply be incomplete
> itself, even if there are defined member functions. This could, however, be
> tricky when dealing with inheritance and other things. It would also raise
> problems with ODR, as you would be effectively re-defining the class.


ODR is always an issue, isn't it?


> In addition, I'm not too sure what you would gain, because you could not
> do much with this class which cannot be done now- only call member
> functions on references and pointers, and possibly even only call
> non-virtual ones.


Why would you not be able to call virtual ones?
The gain would be implementation simplicity (and performance), as you'd no
longer have the pointer indirection.


> Plus, of course, template methods would have to only use the complete data
> members... mess.
>
> However, I believe the real solution to the problem of PIMPL generally
> being a disgusting hack is to implement real modules instead of headers.
>

Would it? I thought modules would be far larger than a single class.

--




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

Op donderdag 22 november 2012 23:27:22 UTC+1 schreef DeadMG het volgende:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Conceptually, there is no re=
ason why this could not be permitted. A class with an incomplete data membe=
r could be considered to simply be incomplete itself, even if there are def=
ined member functions. This could, however, be tricky when dealing with inh=
eritance and other things. It would also raise problems with ODR, as you wo=
uld be effectively re-defining the class. </blockquote><div><br></div><div>=
ODR is always an issue, isn't it?</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">In addition, I'm not too sure what you would ga=
in, because you could not do much with this class which cannot be done now-=
 only call member functions on references and pointers, and possibly even o=
nly call non-virtual ones. </blockquote><div><br></div><div>Why would you n=
ot be able to call virtual ones?</div><div>The gain would be implementation=
 simplicity (and performance), as you'd no longer have the pointer indirect=
ion.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Plu=
s, of course, template methods would have to only use the complete data mem=
bers... mess.<div><br></div><div>However, I believe the real solution to th=
e problem of PIMPL generally being a disgusting hack is to implement real m=
odules instead of headers.</div></blockquote><div><br></div><div>Would it? =
I thought modules would be far larger than a single class.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_452_32174669.1353665544861--

.

------=_Part_366_10948708.1353665754367
Content-Type: text/plain; charset=ISO-8859-1

The size of a module is immaterial. The point is that it removes the
current problem of header files- the problem that PIMPL is intended to
partially resolve.

As for virtual functions, this would imply that the compiler can lay out
virtual table pointers without knowing the data members, no?

--




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

The size of a module is immaterial. The point is that it removes the curren=
t problem of header files- the problem that PIMPL is intended to partially =
resolve.<div><br></div><div>As for virtual functions, this would imply that=
 the compiler can lay out virtual table pointers without knowing the data m=
embers, no?</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_366_10948708.1353665754367--

.

On Fri, Nov 23, 2012 at 11:15 AM, DeadMG <wolfeinstein@gmail.com> wrote:
> As for virtual functions, this would imply that the compiler can lay out
> virtual table pointers without knowing the data members, no?

Yes. Maybe that's problematic with multiple and/or virtual inheritance.

--
Olaf

--




.

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

Le vendredi 23 novembre 2012 11:15:54 UTC+1, DeadMG a =E9crit :
>
> The size of a module is immaterial. The point is that it removes the=20
> current problem of header files- the problem that PIMPL is intended to=20
> partially resolve.


I'm starting to fear that modules will share with export the fact that some=
=20
are expecting a lot more from them that what those working on it are aiming=
=20
to do. My current understanding is that modules will offer little more than=
=20
autogenerated headers from the implementation file would excepted in the=20
area of name lookup, and there the visible effect will be essentially=20
allowing more efficient implementation.

On the positive side, they probably are a better framework to solve the=20
additional issues than export was -- in fact export wasn't a framework in=
=20
which integrate more things at all -- and there is implementation work=20
going on.

--=20
Jean-Marc

--=20




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

Le vendredi 23 novembre 2012 11:15:54 UTC+1, DeadMG a =E9crit&nbsp;:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">The size of a module is immaterial. T=
he point is that it removes the current problem of header files- the proble=
m that PIMPL is intended to partially resolve.</blockquote><br>I'm starting=
 to fear that modules will share with export the fact that some are expecti=
ng a lot more from them that what those working on it are aiming to do. My =
current understanding is that modules will offer little more than autogener=
ated headers from the implementation file would excepted in the area of nam=
e lookup, and there the visible effect will be essentially allowing more ef=
ficient implementation.<br><br>On the positive side, they probably are a be=
tter framework to solve the additional issues than export was -- in fact ex=
port wasn't a framework in which integrate more things at all -- and there =
is implementation work going on.<br><br>-- <br>Jean-Marc<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1840_5624025.1353666899969--

.

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



On Friday, November 23, 2012 2:35:00 AM UTC-8, Jean-Marc Bourguet wrote:
>
> Le vendredi 23 novembre 2012 11:15:54 UTC+1, DeadMG a =E9crit :
>>
>> The size of a module is immaterial. The point is that it removes the=20
>> current problem of header files- the problem that PIMPL is intended to=
=20
>> partially resolve.
>
>
> I'm starting to fear that modules will share with export the fact that=20
> some are expecting a lot more from them that what those working on it are=
=20
> aiming to do. My current understanding is that modules will offer little=
=20
> more than autogenerated headers from the implementation file would except=
ed=20
> in the area of name lookup, and there the visible effect will be=20
> essentially allowing more efficient implementation.
>

Yes and no. Modules is not intended to necessarily prevent recompilation=20
when you change internal details (at least, internal to the class. Though=
=20
even then, simply adding private member functions probably won't change the=
=20
module). The main thing you get is that each "header" only needs to be=20
compiled *once*.

The #include model requires that every #include <vector> in different=20
translation units include and compile the text of that header. Why? They're=
=20
going to come up with the same definitions as every other compilation of=20
that header, right?

Modules allow those symbols to be pre-parsed and pre-processed, like an=20
automated form of precompiled headers. Which means that you don't need to=
=20
run a full C++ compiler with error checking and so forth. Every C++ object=
=20
only has to be compiled once. That's the big deal with modules. Well, the=
=20
biggest deal.

As an example, consider this experiment<http://www.open-std.org/JTC1/SC22/W=
G21/docs/papers/2012/n3426.html>,=20
which represents a crude version of modules. It had benefits and tradeoffs,=
=20
based primarily on the fact that it was intended to be a=20
backwards-compatible, automated solution. Rather than the full modules=20
proposal. Information gleemed from this experiment is feeding into the=20
modules proposal.

So while some changes of a class's implementation may cause recompilation,=
=20
the modules that have to be recompiled are *only* those that change (and=20
those that use them). You don't have to recompile the entire standard=20
library for every source file, which is where a lot of the compile time for=
=20
a source file goes.

Nowadays, you have to care way too much about making such a change, just to=
=20
prevent long recompilations. The goal is to make recompilations fast enough=
=20
that you won't have to care.

On the positive side, they probably are a better framework to solve the=20
> additional issues than export was -- in fact export wasn't a framework in=
=20
> which integrate more things at all -- and there is implementation work=20
> going on.
>
> --=20
> Jean-Marc
>

--=20




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

<br><br>On Friday, November 23, 2012 2:35:00 AM UTC-8, Jean-Marc Bourguet w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Le vendredi 23 novembre 2=
012 11:15:54 UTC+1, DeadMG a =E9crit&nbsp;:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">The size of a module is immaterial. The point is that it removes th=
e current problem of header files- the problem that PIMPL is intended to pa=
rtially resolve.</blockquote><br>I'm starting to fear that modules will sha=
re with export the fact that some are expecting a lot more from them that w=
hat those working on it are aiming to do. My current understanding is that =
modules will offer little more than autogenerated headers from the implemen=
tation file would excepted in the area of name lookup, and there the visibl=
e effect will be essentially allowing more efficient implementation.<br></b=
lockquote><div><br>Yes and no. Modules is not intended to necessarily preve=
nt recompilation when you change internal details (at least, internal to th=
e class. Though even then, simply adding private member functions probably =
won't change the module). The main thing you get is that each "header" only=
 needs to be compiled <i>once</i>.<br><br>The #include model requires that =
every #include &lt;vector&gt; in different translation units include and co=
mpile the text of that header. Why? They're going to come up with the same =
definitions as every other compilation of that header, right?<br><br>Module=
s allow those symbols to be pre-parsed and pre-processed, like an automated=
 form of precompiled headers. Which means that you don't need to run a full=
 C++ compiler with error checking and so forth. Every C++ object only has t=
o be compiled once. That's the big deal with modules. Well, the biggest dea=
l.<br><br>As an example, <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/=
docs/papers/2012/n3426.html">consider this experiment</a>, which represents=
 a crude version of modules. It had benefits and tradeoffs, based primarily=
 on the fact that it was intended to be a backwards-compatible, automated s=
olution. Rather than the full modules proposal. Information gleemed from th=
is experiment is feeding into the modules proposal.<br><br>So while some ch=
anges of a class's implementation may cause recompilation, the modules that=
 have to be recompiled are <i>only</i> those that change (and those that us=
e them). You don't have to recompile the entire standard library for every =
source file, which is where a lot of the compile time for a source file goe=
s.<br><br>Nowadays, you have to care way too much about making such a chang=
e, just to prevent long recompilations. The goal is to make recompilations =
fast enough that you won't have to care.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">On the positive side, they probably are a better fr=
amework to solve the additional issues than export was -- in fact export wa=
sn't a framework in which integrate more things at all -- and there is impl=
ementation work going on.<br><br>-- <br>Jean-Marc<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_375_15546328.1353668278830--

.

On Mon, Jun 18, 2012 at 9:30 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 18 June 2012 15:58, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> Have you tried using a buffer for the implementation, and placement-new:ing the
>>> actual implementation object into it? No indirection in the implementation,
>>> and no leakage of implementation details to the user. The size of the buffer
>>> is, of course, less flexible than in a perfect world, but...
>> No, I haven't. But that's even more complexity. The proposal is meant
>> to improve the pimpl pattern.
>
> I understand the need. I have felt that need myself many times. I haven't
> felt it hard enough to actually go with the placement-new since in most
> cases I have been able to afford the indirection/allocation cost. Even so,
> I'd imagine that complexity needs to be suffered only once, and then you
> can reuse it.

I have written a generic "fast-pimpl" (name comes from Herb Sutter's
http://www.gotw.ca/gotw/028.htm) template in the past.  One that
hopefully covered most of Herb's legitimate qualms about a fast-pimpl.
 (ie have the cpp file check that the size estimated in the header was
actually correct, forward ctor args, etc).

It would be much easier to write in C++11 with variadics and perfect forwarding.

Tony

--




.