------=_Part_720_1567165.1362865662178
Content-Type: text/plain; charset=ISO-8859-1

The typical approach to implementing OO in C++ is to devolve it to it's C
counterpart in the compiler. Unfortunately, C-style object-orientation,
with free functions and opaque handles, has a number of advantages which
are denied to classes. So I propose the following additions to the core
language:

Firstly, when defining a class type, the members may be incomplete types.
This causes the defined class to be an incomplete type. In addition, if
defining a data member which is an instantiation of a template, that
template is not instantiated until the class is used in a context which
requires a complete type. This will enhance modularity in contexts where
the class defines data members which are private use only, or referred to
in many more TUs than instantiated. Then, only those TUs which need to
create the class need include the definitions of those data members. It
would also be necessary to require a complete type for the definition of
member functions.
Secondly, it would now be legal to call non-virtual member functions on a
class which has been defined, but is not complete. This mimics the ability
of C to call free functions, passing a pointer to an incomplete type as the
first argument.
Thirdly, it should be possible to not require a definition of static member
variables (with an implicit definition generated by the compiler in each TU
if the programmer did not put a definition in that TU), and where existing
static member variable definitions are concerned, to extend their linkage
to one per TU, requiring the linker to fold these redundant definitions.
Toolchains already have the ability to fold static variables in this
fashion, as is required by the Standard for static variables of inline
functions, or class templates. Not permitting class-level static variables
this same flexibility is unnecessary headache on the part of the user.

These changes would have a key impact of reducing the public headers to
those which are truly necessary, and reducing inclusion in all other cases.

--

---
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/?hl=en.



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

The typical approach to implementing OO in C++ is to devolve it to it's C c=
ounterpart in the compiler. Unfortunately, C-style object-orientation, with=
 free functions and opaque handles, has a number of advantages which are de=
nied to classes. So I propose the following additions to the core language:=
<div><br></div><div>Firstly, when defining a class type, the members may be=
 incomplete types. This causes the defined class to be an incomplete type. =
In addition, if defining a data member which is an instantiation of a templ=
ate, that template is not instantiated until the class is used in a context=
 which requires a complete type. This will enhance modularity in contexts w=
here the class defines data members which are private use only, or referred=
 to in many more TUs than instantiated. Then, only those TUs which need to =
create the class need include the definitions of those data members. It wou=
ld also be necessary to require a complete type for the definition of membe=
r functions.</div><div>Secondly, it would now be legal to call non-virtual =
member functions on a class which has been defined, but is not complete. Th=
is mimics the ability of C to call free functions, passing a pointer to an =
incomplete type as the first argument.<br></div><div>Thirdly, it should be =
possible to not require a definition of static member variables (with an im=
plicit definition generated by the compiler in each TU if the programmer di=
d not put a definition in that TU), and where existing static member variab=
le definitions are concerned, to extend their linkage to one per TU, requir=
ing the linker to fold these redundant definitions. Toolchains already have=
 the ability to fold static variables in this fashion, as is required by th=
e Standard for static variables of inline functions, or class templates. No=
t permitting class-level static variables this same flexibility is unnecess=
ary headache on the part of the user.</div><div><br></div><div>These change=
s would have a key impact of reducing the public headers to those which are=
 truly necessary, and reducing inclusion in all other cases.</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_720_1567165.1362865662178--

.

------=_Part_812_1517309.1362875077906
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, March 9, 2013 1:47:42 PM UTC-8, DeadMG wrote:
>
> The typical approach to implementing OO in C++ is to devolve it to it's C
> counterpart in the compiler. Unfortunately, C-style object-orientation,
> with free functions and opaque handles, has a number of advantages which
> are denied to classes. So I propose the following additions to the core
> language:
>
> Firstly, when defining a class type, the members may be incomplete types.
> This causes the defined class to be an incomplete type. In addition, if
> defining a data member which is an instantiation of a template, that
> template is not instantiated until the class is used in a context which
> requires a complete type. This will enhance modularity in contexts where
> the class defines data members which are private use only, or referred to
> in many more TUs than instantiated. Then, only those TUs which need to
> create the class need include the definitions of those data members. It
> would also be necessary to require a complete type for the definition of
> member functions.
> Secondly, it would now be legal to call non-virtual member functions on a
> class which has been defined, but is not complete. This mimics the ability
> of C to call free functions, passing a pointer to an incomplete type as the
> first argument.
> Thirdly, it should be possible to not require a definition of static
> member variables (with an implicit definition generated by the compiler in
> each TU if the programmer did not put a definition in that TU), and where
> existing static member variable definitions are concerned, to extend their
> linkage to one per TU, requiring the linker to fold these redundant
> definitions. Toolchains already have the ability to fold static variables
> in this fashion, as is required by the Standard for static variables of
> inline functions, or class templates. Not permitting class-level static
> variables this same flexibility is unnecessary headache on the part of the
> user.
>
> These changes would have a key impact of reducing the public headers to
> those which are truly necessary, and reducing inclusion in all other cases.
>

Or we could just let modules handle this. I don't really see the point of
adding a feature that reduces what needs to be in public headers when we're
talking about adding a feature that will make all of that irrelevant. Even
using module-map files, the recompilation for unimportant header changes
will be pretty minimal.

--

---
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/?hl=en.



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

On Saturday, March 9, 2013 1:47:42 PM UTC-8, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">The typical approach to implementing OO in C++ =
is to devolve it to it's C counterpart in the compiler. Unfortunately, C-st=
yle object-orientation, with free functions and opaque handles, has a numbe=
r of advantages which are denied to classes. So I propose the following add=
itions to the core language:<div><br></div><div>Firstly, when defining a cl=
ass type, the members may be incomplete types. This causes the defined clas=
s to be an incomplete type. In addition, if defining a data member which is=
 an instantiation of a template, that template is not instantiated until th=
e class is used in a context which requires a complete type. This will enha=
nce modularity in contexts where the class defines data members which are p=
rivate use only, or referred to in many more TUs than instantiated. Then, o=
nly those TUs which need to create the class need include the definitions o=
f those data members. It would also be necessary to require a complete type=
 for the definition of member functions.</div><div>Secondly, it would now b=
e legal to call non-virtual member functions on a class which has been defi=
ned, but is not complete. This mimics the ability of C to call free functio=
ns, passing a pointer to an incomplete type as the first argument.<br></div=
><div>Thirdly, it should be possible to not require a definition of static =
member variables (with an implicit definition generated by the compiler in =
each TU if the programmer did not put a definition in that TU), and where e=
xisting static member variable definitions are concerned, to extend their l=
inkage to one per TU, requiring the linker to fold these redundant definiti=
ons. Toolchains already have the ability to fold static variables in this f=
ashion, as is required by the Standard for static variables of inline funct=
ions, or class templates. Not permitting class-level static variables this =
same flexibility is unnecessary headache on the part of the user.</div><div=
><br></div><div>These changes would have a key impact of reducing the publi=
c headers to those which are truly necessary, and reducing inclusion in all=
 other cases.</div></blockquote><div><br>Or we could just let modules handl=
e this. I don't really see the point of adding a feature that reduces what =
needs to be in public headers when we're talking about adding a feature tha=
t will make all of that irrelevant. Even using module-map files, the recomp=
ilation for unimportant header changes will be pretty minimal.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_812_1517309.1362875077906--

.