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

Reposting this here as originally posted in wrong group:
https://groups.google.com/a/isocpp.org/forum/m/?pli=3D1#!topic/std-discussi=
on/2KNNorMv6Is

--- Start of OP ----

Not sure if anything like this has been discussed before.
I have been having a dark time with a recent project where one of my requir=
ements is about reduction of dependencies. I also think this idea might ena=
ble simple and more declarative code for most use cases.

Ok, so, most of you have probably had the need for a class that does one th=
ing and internally requires the use of other external libraries. While also=
 following the rule of KISS and DRY, this requires private functions that h=
ave parameters of external types.

Example:
{{
class thing {
public:
   thing(....);
   string DoSomething(....);
private:
   string PrivateFromExternal(externalType a, ....);
   externalType PrivateToExternal(string b, ....);
};
}}
Someone who inherits this class automatically now has a dependency on exter=
nalType and thus would require linking against the library binaries.

However, with the development of meta-classes and other mechanisms, I am wo=
ndering if now is the time to allow something that has been in other langua=
ges for a while.

The ability of partial classes.

The way I see this working is that only when a compile sees the partial key=
word (could be different if "partial" is not acceptable), then the definiti=
on should be open for expansion later in the translation unit.

This way in one header file I can expose the minimal public definition of t=
he class, and then later define the private internal methods. This would al=
so allow me to chain header files to allow multiple levels of definition.
The actual implementation could do this by making each subsequent partial c=
lass a class that inherits from the previous type and then define an inline=
 using for the partial type to the name required for the class.

For example:

first.h
{{
#include <string>;

partial class Thing {
public:
   Thing(....);
   void DoSomething(....);
   string GetSomething(....);

// compiler would add =3D>
//private:    baseThing _internal;
// where baseThing is the next partial/final class definition
// compiler would then copy public and protected methods into this class an=
d make them forward to the internal type
};

// compiler would define a using definition here from the mashed function n=
ame to Thing for use by other classes
}}

second.h
{{
#include "first.h"
#include <map>;

partial class Thing {
protected:
   Thing(std::map<string,string> a, ....);
   string ToJson(void) const;
   void FromJson(string);

// compiler would add =3D>
//private:    baseThing _internal;
// where baseThing is the next partial/final class definition
// compiler would then copy public and protected methods into this class an=
d make them forward to the internal type
};

// compiler would re-define using definition here from the mashed function =
name to Thing for use by other classes
}}

thing.cpp
{{
#include "second.h";
#include <external_lib>;

final class Thing {
private:
   externalType ToET(....);
   string FromET(....);
   string CallServiceUsingET(externalType, ....);
}

/* All Implementation Details Here */
}}

Something like this would allow me to use Thing in various ways depending o=
n my requirements and locality to the type. Thing, is a single entity to re=
ason about regardless of what level of access I require. Also by only inclu=
ding first.h in another class I can use Thing without having to have my cod=
e depend and link with external_lib.

This facility could also use the meta-classes proposal so that each partial=
 definition could be a meta-class to further reduce verbosity in its defini=
tion, but would also ensure that we have the cleanest code possible, that i=
s easy to reason about.

This I think would be handy, but wanted to see if there was anything I had =
forgotten before I try and write a proposal.
All feedback welcome (even if it is to point out how stupid this idea is). =
I know this may be difficult to actually implement, because it requires for=
ward/future definition dependency. But, I think this could be solved using =
reflection somehow. I am not an expert, so I expect Simone to say "oh, that=
 could be done like this ....)" or "can't do that because of ....".

Hope this idea sparks some interest as I think this could be a useful featu=
re of the language (or library if that is where it is better suited).

---- End of OP ----

Summary of previous response:
Could be solved by:
- Template functions and then provide specialisation in cpp
- Actual Pimpl boilerplate library code using smart_ptrs
- Modules

My reply to these:
Yes these could solve the direct problem of hiding the initial problem of l=
eaking dependencies. Also using free functions in the cpp file could do the=
 same hiding.
However, I don't believe any of these options are particularly clear or eas=
y to understand at a glance.
One of the main aims is to provide a simple way to enable automatic pimpl a=
nd also when used with meta-classes could provide a lot of flexibility and =
streamline boilerplate code.
I have not really created many examples here as this was quickly thrown tog=
ether to get some initial feedback. I may try to write this up in full and =
provide a lot more useful points to this other than just the auto-pimpl ide=
a. I would be interested in any other opinions and ideas.

--=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/0e49ee2a-2ead-431d-83ae-54587c1b8c8e%40isocpp.or=
g.

------=_Part_3201_2033864267.1502555400173--

.

On s=C3=A1bado, 12 de agosto de 2017 09:30:00 PDT Izzy Coding wrote:
> #include "first.h"
> #include <map>;
>=20
> partial class Thing {
> protected:
>    Thing(std::map<string,string> a, ....);
>    string ToJson(void) const;
>    void FromJson(string);
>=20
> // compiler would add =3D>
> //private:    baseThing _internal;
> // where baseThing is the next partial/final class definition
> // compiler would then copy public and protected methods into this class =
and
> make them forward to the internal type };

baseThing isn't defined here. Did you intend it to be a forward declaration=
,=20
meaning that sizeof(Thing) is also unknown?

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

--=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/150258677.cqT3gqeyh5%40tjmaciei-mobl1.

.

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

What I meant by baseThing is:
If you numbered the things (giving them unique names), then each Thing woul=
d have an internal unique_ptr<Thing..> where .. would be the id of the next=
 "partial" in the "stack". This can be done as if partial is specified on a=
 class then there would have to be at least a final class. Therefore one co=
uld forward declare Thing(n+1) and then just keep a pointer to it.

Whether that is right or not I don't know. But it would be nice to have som=
e clear and easy syntax to allow me to both define pimpl-classes and also a=
llow me flexibility to share the pimpl definition with multiple classes tha=
t maybe only differ on a few methods and their implementation.

I know this is partially covered by meta-classes, but that does not allow m=
e to extend definitions across multiple files without boilerplate code that=
 looks ugly and is sometime difficult to reason about unless your an evange=
list. Also I would prefer to be able to keep my public interface clean and =
have my source code readable by even a newbie cpper.=20

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

------=_Part_3224_368089946.1502560067242--

.

On s=C3=A1bado, 12 de agosto de 2017 10:47:47 PDT Izzy Coding wrote:
> What I meant by baseThing is:
> If you numbered the things (giving them unique names), then each Thing wo=
uld
> have an internal unique_ptr<Thing..> where .. would be the id of the next
> "partial" in the "stack". This can be done as if partial is specified on =
a
> class then there would have to be at least a final class. Therefore one
> could forward declare Thing(n+1) and then just keep a pointer to it.

Ok, understood, though unique_ptr isn't necessary. A plain pointer suffices=
..

But that's not what I understand a partial class to be. You're chaining=20
pointers and introducing overhead. The incomplete definition solution achie=
ves=20
the same without that overhead, but at the expense of making it impossible =
to=20
instantiate the type until it's complete.

I can see advantages and disadvantages for both cases.

> Whether that is right or not I don't know. But it would be nice to have s=
ome
> clear and easy syntax to allow me to both define pimpl-classes and also
> allow me flexibility to share the pimpl definition with multiple classes
> that maybe only differ on a few methods and their implementation.

Sorry, I didn't understand this part. How do you want to share the second=
=20
(private) part of different first (public) parts?

> I know this is partially covered by meta-classes, but that does not allow=
 me
> to extend definitions across multiple files without boilerplate code that
> looks ugly and is sometime difficult to reason about unless your an
> evangelist. Also I would prefer to be able to keep my public interface
> clean and have my source code readable by even a newbie cpper.


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

--=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/2837900.vx9fRd0nJE%40tjmaciei-mobl1.

.

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

What I meant about referencing from multiple classes is that,

Given an object of type Thing,
And I include first.h,
When I use the instance in my code,
Then I expect to have access to the methods defined in first.h on the insta=
nce of Thing,

Given an object of type Thing,
And I include second.h (that could have public methods and data members def=
ined),
When I use the instance in my code,
Then I expect to have access to the methods defined by first.h,
And I expect to have access to the methods defined by second.h

This may look just like interfaces and inheritance, but is more about havin=
g to avoid the ugliness and extra code (that is very easy to get wrong) req=
uired to manually do pimpl or method implementation hiding.

Ultimately both cases would point to a fully defined and constructed instan=
ce of Thing, but would act similar to a class hierarchy where the user has =
static_cast<RelevantThingLevel>. The memory layout could be implemented muc=
h the same as a multi-layer class hierarchy, but as a single object. The "p=
ointer" to Thing(n+1) could be removed during compilation and maybe have st=
ructs defined for each high level partial which would use explicit conversi=
on functions that just forward method and data calls to the fully fledged o=
bject. So, I don't believe there would be any real overhead as it would jus=
t be a "view" into the full object at run-time.

Also there could be an optimiser opportunity to "merge" multiple partial de=
finitions if nothing depends directly on the higher level partial class?

If it was possible to delay naming the partial class type, then it could po=
ssibly enable the compiler.n() calls used in meta-classes proposal to enabl=
e one high level definition to be used by 2 differing classes. This would n=
ot mean they are related in any way, but would just reduce the number of ti=
me I would have to specify the same things on multiple classes.

--=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/b239fb78-d23b-47c4-9a00-2d4df798cff0%40isocpp.or=
g.

------=_Part_3483_167964591.1502571317199--

.

On s=C3=A1bado, 12 de agosto de 2017 13:55:17 PDT Izzy Coding wrote:
> What I meant about referencing from multiple classes is that,
>=20
> Given an object of type Thing,
> And I include first.h,
> When I use the instance in my code,
> Then I expect to have access to the methods defined in first.h on the
> instance of Thing,

As a pointer or do you instantiate such an object in the stack or as a memb=
er=20
of another structure?

> This may look just like interfaces and inheritance, but is more about hav=
ing
> to avoid the ugliness and extra code (that is very easy to get wrong)
> required to manually do pimpl or method implementation hiding.

It doesn't look any different from inheritance. Please explain how it is=20
different.

The biggest challenge with pimpl is that the secondary object needs to be=
=20
allocated in the heap. You haven't explained if this is part of your design=
=20
and, if so, how it gets allocated and deallocated.

> Ultimately both cases would point to a fully defined and constructed
> instance of Thing, but would act similar to a class hierarchy where the
> user has static_cast<RelevantThingLevel>. The memory layout could be
> implemented much the same as a multi-layer class hierarchy, but as a sing=
le
> object. The "pointer" to Thing(n+1) could be removed during compilation a=
nd
> maybe have structs defined for each high level partial which would use
> explicit conversion functions that just forward method and data calls to
> the fully fledged object. So, I don't believe there would be any real
> overhead as it would just be a "view" into the full object at run-time.

You're still describing inheritance.

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

--=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/1853356.WW4VBYSKBC%40tjmaciei-mobl1.

.

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

I'm not sure exactly how the implementation would work as I have not sat do=
wn to fully flesh it out yet. But, I would hope and strive to ensure zero o=
verhead where possible.

Inheritance would require multiple class definitions spread across multiple=
 sets of .h and .cpp files (or if you like to dump multiple things in a sin=
gle file you could do it as 2 files, but I doubt many people do this). Also=
 This allows creation of FirstThing independent of FullThing.

Partial just tells the compiler that I don't care what the full size of Thi=
ng is, I just want access to the view I do have a definition for. These can=
 only be created in full (requiring include of full definition chain so all=
ocation can happen as normal), but seen and used as a partial view of that =
full type as required. A FirstThing is a FullThing, but where I only care a=
bout the size of memory that is defined in first.h. I hope this makes sense=
..

This allows me to spread the definition of a single type across multiple fi=
les so that I can keep my includes as minimal as possible and means the usi=
ng class/function only has to know about what it is going to use.

Also when used with meta-classes each partial could be defined as a differe=
nt meta-class which would include only the required compiler transforms ava=
ilable to each level of partial. Which would allow the separation of concer=
ns for each set of functionality in a Thing.

--=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/2e940bb4-f8d4-4a02-9802-0036af7efc09%40isocpp.or=
g.

------=_Part_3756_1410752398.1502614309860--

.

On Sunday, 13 August 2017 01:51:49 PDT Izzy Coding wrote:
> I'm not sure exactly how the implementation would work as I have not sat
> down to fully flesh it out yet. But, I would hope and strive to ensure zero
> overhead where possible.

That imples no heap allocation, which means the full object size must be known
at any point in the instantiation.

That means your feature request is no different than inheritance, with the
possible exception of making the partial types non-instantiable without
requiring a pure virtual method inside. Of course, you could achieve the same
by way of a protected, default constructor (or private if you want to ensure
only you can derive from it).

The only visible difference I can think of would be the typeid() and reflection
of the objects.

> Inheritance would require multiple class definitions spread across multiple
> sets of .h and .cpp files (or if you like to dump multiple things in a
> single file you could do it as 2 files, but I doubt many people do this).

Which your proposal also asks for.

> Also This allows creation of FirstThing independent of FullThing.

No, it doesn't. See above.

> Partial just tells the compiler that I don't care what the full size of
> Thing is, I just want access to the view I do have a definition for. These
> can only be created in full (requiring include of full definition chain so
> allocation can happen as normal), but seen and used as a partial view of
> that full type as required. A FirstThing is a FullThing, but where I only
> care about the size of memory that is defined in first.h. I hope this makes
> sense.
>
> This allows me to spread the definition of a single type across multiple
> files so that I can keep my includes as minimal as possible and means the
> using class/function only has to know about what it is going to use.

I don't see how that is any different from simple inheritance.

> Also when used with meta-classes each partial could be defined as a
> different meta-class which would include only the required compiler
> transforms available to each level of partial. Which would allow the
> separation of concerns for each set of functionality in a Thing.

Right.

--
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/2546050.sL0pCq2xIu%40tjmaciei-mobl1.

.

On 2017-08-12 12:30, Izzy Coding wrote:
> Example:
> {{
> class thing {
> public:
>    thing(....);
>    string DoSomething(....);
> private:
>    string PrivateFromExternal(externalType a, ....);
>    externalType PrivateToExternal(string b, ....);
> };
> }}
>
> Someone who inherits this class automatically now has a dependency on
> externalType and thus would require linking against the library
> binaries.
Uh... no? Only if they are actually using those types. (They only need
the headers, and only if you were unable to forward declare the types.)

--
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/a069666d-922f-53dd-5d95-5bbe322bb794%40gmail.com.

.

------=_Part_6546_1388632174.1502830993769
Content-Type: multipart/alternative;
 boundary="----=_Part_6547_287832769.1502830993769"

------=_Part_6547_287832769.1502830993769
Content-Type: text/plain; charset="UTF-8"

What would make a bigger impact is if we could figure out a way to actually
be able to add non-static data members in a class extension in a cpp file.
This would allow the impl pattern (without the p). The obstacles to this
are huge, of course, as it would more or less demand link time code
generation, with the actual size being stored as a constant in the object
file resulting from compiling the class extension. While linkers do do some
offset modifications this takes those problems to a whole new level.

Without this ability I don't think this proposal has much talking for it
though. I'd much rather have the indirect inheritance already proposed,
which seems to solve the problem more elegantly.

After modules is widely in use class extensions with non-static data
members may not seem so hard as it does now... and anything that reduces
the number of allocations a program needs to do is a good thing!

Getting some incarnation of the C VLA idea into C++ is probably one of the
things that would help reduce allocations the most. Maybe this should be
given some more thought again.

Den tisdag 15 augusti 2017 kl. 16:21:41 UTC+2 skrev Matthew Woehlke:
>
> On 2017-08-12 12:30, Izzy Coding wrote:
> > Example:
> > {{
> > class thing {
> > public:
> >    thing(....);
> >    string DoSomething(....);
> > private:
> >    string PrivateFromExternal(externalType a, ....);
> >    externalType PrivateToExternal(string b, ....);
> > };
> > }}
> >
> > Someone who inherits this class automatically now has a dependency on
> > externalType and thus would require linking against the library
> > binaries.
> Uh... no? Only if they are actually using those types. (They only need
> the headers, and only if you were unable to forward declare the types.)
>
> --
> 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/fcd6995e-ffe5-442f-8da6-d24bee4c1d13%40isocpp.org.

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

<div dir=3D"ltr">What would make a bigger impact is if we could figure out =
a way to actually be able to add non-static data members in a class extensi=
on in a cpp file. This would allow the impl pattern (without the p). The ob=
stacles to this are huge, of course, as it would more or less demand link t=
ime code generation, with the actual size being stored as a constant in the=
 object file resulting from compiling the class extension. While linkers do=
 do some offset modifications this takes those problems to a whole new leve=
l.<div><br></div><div>Without this ability I don&#39;t think this proposal =
has much talking for it though. I&#39;d much rather have the indirect inher=
itance already proposed, which seems to solve the problem more elegantly.</=
div><div><br></div><div>After modules is widely in use class extensions wit=
h non-static data members may not seem so hard as it does now... and anythi=
ng that reduces the number of allocations a program needs to do is a good t=
hing!</div><div><br></div><div>Getting some incarnation of the C VLA idea i=
nto C++ is probably one of the things that would help reduce allocations th=
e most. Maybe this should be given some more thought again.<br><br>Den tisd=
ag 15 augusti 2017 kl. 16:21:41 UTC+2 skrev Matthew Woehlke:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">On 2017-08-12 12:30, Izzy Coding wrote:
<br>&gt; Example:
<br>&gt; {{
<br>&gt; class thing {
<br>&gt; public:
<br>&gt; =C2=A0 =C2=A0thing(....);
<br>&gt; =C2=A0 =C2=A0string DoSomething(....);
<br>&gt; private:
<br>&gt; =C2=A0 =C2=A0string PrivateFromExternal(<wbr>externalType a, ....)=
;
<br>&gt; =C2=A0 =C2=A0externalType PrivateToExternal(string b, ....);
<br>&gt; };
<br>&gt; }}
<br>&gt;
<br>&gt; Someone who inherits this class automatically now has a dependency=
 on
<br>&gt; externalType and thus would require linking against the library
<br>&gt; binaries.
<br>Uh... no? Only if they are actually using those types. (They only need
<br>the headers, and only if you were unable to forward declare the types.)
<br>
<br>--=20
<br>Matthew
<br></blockquote></div></div>

<p></p>

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

------=_Part_6547_287832769.1502830993769--

------=_Part_6546_1388632174.1502830993769--

.

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

> Uh... no? Only if they are actually using those types. (They only need=20
> the headers, and only if you were unable to forward declare the types.)=
=20

How do you manage that then?
Every time I have used a class that defines the usage of an external type I=
 have had to "include" that libraries includes directory and "link" to its =
binary witching my build tool and compiler config.

What this is trying to do is reduce the requirement of having to know the f=
ull size of a Thing when using it. I should only need to care about the siz=
e of the partial Thing that I care about. If "constructing" a new Thing the=
n that would require knowledge of the full type (hence the idea of "final" =
to mark the end of the chain).

--=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/cf31f504-4e54-4550-884a-55a9a437c7e9%40isocpp.or=
g.

------=_Part_7146_1914238946.1502862535817--

.

On 2017-08-16 01:48, Izzy Coding wrote:
>> Uh... no? Only if they are actually using those types. (They only need
>> the headers, and only if you were unable to forward declare the types.)
>
> How do you manage that then?

  class undef;

  struct foo
  {
    void x(undef);
    undef y();
  };

  struct bar : foo
  {
  };

  int main()
  {
    bar x;
    return 0;
  }

The implementations of `foo::x`/`foo::y` need the full definition of
`undef`, but derived classes (e.g. `bar`) don't. The above compiles and
links just fine, at least on GCC. (Yes, even though the methods are
public, because nothing in the above actually *calls* them. Since in
your case they were private, obviously nothing outside of `thing` or
friends will call them.)

--
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/f3c01536-525f-208c-a180-94a42dd3c75c%40gmail.com.

.