------=_Part_273_11944738.1380553629368
Content-Type: text/plain; charset=ISO-8859-1

Hi, I wanted to post this in the Concepts group but I never got a response
from my join request so I'm posting here. Something that I've been thinking
about on and off for a while but since the GoingNative 2013 videos I wanted
to put my thoughts out there and see what the community thinks.

I don't remember which video it was but Bjarne Stroustrup mentioned that
one of the issues of the old Concepts proposals was that compilation times
got worse with the prototype implementation.

I started to think that maybe the community is going about this the wrong
way, maybe the first step and the highest priority above everything else
should be to standardize a module system so we can get away from textual
inclusion we have now. Then come back to features, features which can have
an influence (and influenced by) compilation times and see how they perform.

To me it does not seem to make much sense to to accept/reject solutions
which are disadvantaged by an old/outdated system (textual includes) that
everyone knows the issues with it and we eventually be replaced.

I'm not trying to say that we should (or should not) bring back the old
Concepts proposal but rather we should fix the fundamental issues first
(the ones which affects the 99%) before coming up with solutions for new
features, ones that are influenced by them.

I'm also in the belief that regardless of Concepts, a module system should
be the highest priority above all else. I've been working with C++
commercially for almost 10 years (and longer prior to this). When working
with a team of programmers on a large project build times for C++ projects
can get pretty insane and most C++ programmers do not consistently use
features/techniques like forward declarations if ever. It's just too much
mental work and too mechnical for a team of programmers to get right
especially when programmers are rushed to meet deadlines.

The more extensions and/or features added to C++ that influence the build
times, the worse the build times are going to get.

--

---
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_273_11944738.1380553629368
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi, I wanted to post this in the Concepts group but I neve=
r got a response from my join request so I'm posting here. Something that I=
've been thinking about on and off for a while but since the GoingNative 20=
13 videos I wanted to put my thoughts out there and see what the community =
thinks.<br><br>I don't remember which video it was but Bjarne Stroustrup me=
ntioned that one of the issues of the old Concepts proposals was that compi=
lation times got worse with the prototype implementation.<br><br>I started =
to think that maybe the community is going about this the wrong way, maybe =
the first step and the highest priority above everything else should be to =
standardize a module system so we can get away from textual inclusion we ha=
ve now. Then come back to features, features which can have an influence (a=
nd influenced by) compilation times and see how they perform.<br><br>To me =
it does not seem to make much sense to to accept/reject solutions which are=
 disadvantaged by an old/outdated system (textual includes) that everyone k=
nows the issues with it and we eventually be replaced.<br><br>I'm not tryin=
g to say that we should (or should not) bring back the old Concepts proposa=
l but rather we should fix the fundamental issues first&nbsp; (the ones whi=
ch affects the 99%) before coming up with solutions for new features, ones =
that are influenced by them.<br><br>I'm also in the belief that regardless =
of Concepts, a module system should be the highest priority above all else.=
 I've been working with C++ commercially for almost 10 years (and longer pr=
ior to this). When working with a team of programmers on a large project bu=
ild times for C++ projects can get pretty insane and most C++ programmers d=
o not consistently use features/techniques like forward declarations if eve=
r. It's just too much mental work and too mechnical for a team of programme=
rs to get right especially when programmers are rushed to meet deadlines.<b=
r><br>The more extensions and/or features added to C++ that influence the b=
uild times, the worse the build times are going to get.<br><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 />

------=_Part_273_11944738.1380553629368--

.

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

On 30 September 2013 18:07, snk_kid <korcan.hussein@googlemail.com> wrote:

>
> I'm not trying to say that we should (or should not) bring back the old
> Concepts proposal but rather we should fix the fundamental issues first
> (the ones which affects the 99%) before coming up with solutions for new
> features, ones that are influenced by them.
>
>
Well, I guess I'm in the 1% then, because lack of modules is not a problem
for 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/.

--001a11c25b485a0f0f04e79b6a09
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 September 2013 18:07, snk_kid <span dir=3D"ltr">&lt;<a href=
=3D"mailto:korcan.hussein@googlemail.com" target=3D"_blank">korcan.hussein@=
googlemail.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>I&#39;m not trying to s=
ay that we should (or should not) bring back the old Concepts proposal but =
rather we should fix the fundamental issues first=A0 (the ones which affect=
s the 99%) before coming up with solutions for new features, ones that are =
influenced by them.<br>
<br></div></blockquote><div><br></div><div>Well, I guess I&#39;m in the 1% =
then, because lack of modules is not a problem for 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 />

--001a11c25b485a0f0f04e79b6a09--

.

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

On Mon, Sep 30, 2013 at 10:07 AM, snk_kid <korcan.hussein@googlemail.com>wrote:

> I started to think that maybe the community is going about this the wrong
> way, maybe the first step and the highest priority above everything else
> should be to standardize a module system so we can get away from textual
> inclusion we have now. Then come back to features, features which can have
> an influence (and influenced by) compilation times and see how they perform.
>
> To me it does not seem to make much sense to to accept/reject solutions
> which are disadvantaged by an old/outdated system (textual includes) that
> everyone knows the issues with it and we eventually be replaced.
>
>
>
I agree that the compile times for projects over 1 million lines of code
makes life difficult --- it has certainly made my life difficult.  Fixing
it is important, and it will most likely be fixed by modules.

However, I haven't been able to find a single priority queue for the
community :-)  The people working on modules are not fungible with the
people working on concepts for a lot of reasons, but keep in mind that they
they are also volunteers.  Volunteers work on what they want to work on.
 It is not as if all the other standardization work (sized dealloc,
filesystem, concurrency, etc) is being done at the expense of modules.

One thing you could do is to talk to the people working on modules and see
if there is anything that you could help with.

Robert

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te">On Mon, Sep 30, 2013 at 10:07 AM, snk_kid <span dir=3D"ltr">&lt;<a href=
=3D"mailto:korcan.hussein@googlemail.com" target=3D"_blank">korcan.hussein@=
googlemail.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">I started to think that may=
be the community is going about this the wrong way, maybe the first step an=
d the highest priority above everything else should be to standardize a mod=
ule system so we can get away from textual inclusion we have now. Then come=
 back to features, features which can have an influence (and influenced by)=
 compilation times and see how they perform.<br>
<br>To me it does not seem to make much sense to to accept/reject solutions=
 which are disadvantaged by an old/outdated system (textual includes) that =
everyone knows the issues with it and we eventually be replaced.<br><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div></bl=
ockquote><div><br></div><div style>I agree that the compile times for proje=
cts over 1 million lines of code makes life difficult --- it has certainly =
made my life difficult. =A0Fixing it is important, and it will most likely =
be fixed by modules.</div>
<div style><br></div><div style>However, I haven&#39;t been able to find a =
single priority queue for the community :-) =A0The people working on module=
s are not fungible with the people working on concepts for a lot of reasons=
, but keep in mind that they they are also volunteers. =A0Volunteers work o=
n what they want to work on. =A0It is not as if all the other standardizati=
on work (sized dealloc, filesystem, concurrency, etc) is being done at the =
expense of modules.</div>
<div style><br></div><div style>One thing you could do is to talk to the pe=
ople working on modules and see if there is anything that you could help wi=
th.</div><div style><br></div><div style>Robert</div><div style><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 />

--089e014942eea9b74e04e79be58f--

.

On 9/30/13 11:57 PM, Robert Zeh wrote:
> On Mon, Sep 30, 2013 at 10:07 AM, snk_kid <korcan.hussein@googlemail.com>=
wrote:
>
>> Then come back to features, features which can have
>> an influence (and influenced by) compilation times and see how they perf=
orm.
>>
> I agree that the compile times for projects over 1 million lines of code
> makes life difficult --- it has certainly made my life difficult.

Why don't precompiled headers work for you?

Adjusting the language to make compilers faster seems conceptually=20
backwards, or a red flag. I haven't looked into modules much, but I'd=20
assumed the motivation was elsewhere. I thought header repetition was a=20
solved problem.

Loading precompiled header files also takes significant time, but=20
modules wouldn't necessarily be any better. I'm sure that can be=20
improved, but it's a job for compiler vendors.

Standardizing an interoperable format equivalent to a precompiled header=20
would take forever. PCHes are just AST dumps. Standardizing a=20
compressed, serialized AST for every C++ construct? That's much harder=20
than standardizing an ABI. And when a compiler has to perform meaningful=20
conversion because the native AST differs, performance is lost and the=20
exercise becomes pointless.

So we already have a speedy binary format on every platform used for=20
serious work, and we're never going to unify these formats anyway=85 what=
=20
are modules supposed to fix? Just to remove the PCH build-system=20
boilerplate by letting the compiler cache things more easily? Seems minor.

--=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/.

.

--001a11c20a72f8d75704e7acdd8d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 1, 2013 at 7:00 AM, David Krauss <potswa@gmail.com> wrote:

>
> Why don't precompiled headers work for you?
>
>
I must say it don't work for me neither. Precompiled headers are not a
silver bullet, they also can have the reverse effect of adding compile time=
..
Anyway, it's better to manage your dependencies well, but it's also hard
with a language that can't figure out which part of the compiled file is a
dependency or not (because it can't tell you when you don't
need to include a file anymore, after a change).


> Adjusting the language to make compilers faster seems conceptually
> backwards, or a red flag.


Not if it's the design of the language that prevent build time to get
faster.


> I haven't looked into modules much, but I'd assumed the motivation was
> elsewhere.


My understanding is that the main motivation is reducing build time. You
can read the issues there:
http://clang.llvm.org/docs/Modules.html#problems-with-the-current-model
The first stated problem that Modules would solve is "Compile-time
scalability". Also see the Modules paper for more details on this.


> I thought header repetition was a solved problem.
>
>
It's not: not repeating opening the same file several time is indeed solved
problem, but the content of a header might be interpreted differently
depending on the code after and before it's inclusion,
which forces the compiler to at least re-parse the content of headers for
each compilation unit.

Loading precompiled header files also takes significant time, but modules
> wouldn't necessarily be any better. I'm sure that can be improved, but it=
's
> a job for compiler vendors.
>
>
The Modules documentation states that it can make "the API of each software
library is only parsed once, reducing the M x N compilation problem to an M
+ N problem."
Precompiled headers can't do that. They also can't automatically be
configured to scale with changes.


> Standardizing an interoperable format equivalent to a precompiled header
> would take forever. PCHes are just AST dumps. Standardizing a compressed,
> serialized AST for every C++ construct? That's much harder than
> standardizing an ABI. And when a compiler has to perform meaningful
> conversion because the native AST differs, performance is lost and the
> exercise becomes pointless.
>
>
I've seen no such format proposal. Did I miss something?


> So we already have a speedy binary format on every platform used for
> serious work, and we're never going to unify these formats anyway=85 what=
 are
> modules supposed to fix? Just to remove the PCH build-system boilerplate =
by
> letting the compiler cache things more easily? Seems minor.
>
>
It's not. First, there is no way PCH builds can be scaled.
Second, lack of quick feedback is killing productivity. It's a major
problem.
All the C++ projects I've worked on so  far have had this build time
project, even the smallest.
Even applying all the best dependencies technique (including unity builds,
which are no silver bullet either) can't scale.

--=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/.

--001a11c20a72f8d75704e7acdd8d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Oct 1, 2013 at 7:00 AM, David Krauss <span dir=3D"ltr">&lt;=
<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><br></div>
Why don&#39;t precompiled headers work for you?<br>
<br></blockquote><div><br></div><div>I must say it don&#39;t work for me ne=
ither. Precompiled headers are not a silver bullet, they also can have the =
reverse effect of adding compile time.</div><div>Anyway, it&#39;s better to=
 manage your dependencies well, but it&#39;s also hard with a language that=
 can&#39;t figure out which part of the compiled file is a dependency or no=
t (because it can&#39;t tell you when you don&#39;t<br>
need to include a file anymore, after a change).</div><div>=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex">

Adjusting the language to make compilers faster seems conceptually backward=
s, or a red flag. </blockquote><div><br></div><div>Not if it&#39;s the desi=
gn of the language that prevent build time to get faster.=A0</div><div>=A0<=
/div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">I haven&#39;t looked into modules much, but I&#39;d assume=
d the motivation was elsewhere. </blockquote>
<div><br></div><div>My understanding is that the main motivation is reducin=
g build time. You can read the issues there:=A0<a href=3D"http://clang.llvm=
..org/docs/Modules.html#problems-with-the-current-model">http://clang.llvm.o=
rg/docs/Modules.html#problems-with-the-current-model</a></div>
<div>The first stated problem that Modules would solve is &quot;Compile-tim=
e scalability&quot;. Also see the Modules paper for more details on this.</=
div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex">
I thought header repetition was a solved problem.<br>
<br></blockquote><div><br></div><div>It&#39;s not: not repeating opening th=
e same file several time is indeed solved problem, but the content of a hea=
der might be interpreted differently depending on the code after and before=
 it&#39;s inclusion,<br>
which forces the compiler to at least re-parse the content of headers for e=
ach compilation unit.</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Loading precompiled header files also takes significant time, but modules w=
ouldn&#39;t necessarily be any better. I&#39;m sure that can be improved, b=
ut it&#39;s a job for compiler vendors.<br>
<br></blockquote><div><br></div><div>The Modules documentation states that =
it can make &quot;the API of each software library is only parsed once, red=
ucing the M x N compilation problem to an M + N problem.&quot;<br>Precompil=
ed headers can&#39;t do that. They also can&#39;t automatically be configur=
ed to scale with changes.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
Standardizing an interoperable format equivalent to a precompiled header wo=
uld take forever. PCHes are just AST dumps. Standardizing a compressed, ser=
ialized AST for every C++ construct? That&#39;s much harder than standardiz=
ing an ABI. And when a compiler has to perform meaningful conversion becaus=
e the native AST differs, performance is lost and the exercise becomes poin=
tless.<br>

<br></blockquote><div><br></div><div>I&#39;ve seen no such format proposal.=
 Did I miss something?=A0<br></div><div>=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So we already have a speedy binary format on every platform used for seriou=
s work, and we&#39;re never going to unify these formats anyway=85 what are=
 modules supposed to fix? Just to remove the PCH build-system boilerplate b=
y letting the compiler cache things more easily? Seems minor.<div class=3D"=
">
<div class=3D"h5"><br></div></div></blockquote><div>=A0</div><div>It&#39;s =
not. First, there is no way PCH builds can be scaled.</div><div>Second, lac=
k of quick feedback is killing productivity. It&#39;s a major problem.</div=
>
<div>All the C++ projects I&#39;ve worked on so =A0far have had this build =
time project, even the smallest.</div><div>Even applying all the best depen=
dencies technique (including unity builds, which are no silver bullet eithe=
r) can&#39;t scale.</div>
<div><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 />

--001a11c20a72f8d75704e7acdd8d--

.

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

On Tue, Oct 1, 2013 at 2:12 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>w=
rote:

> All the C++ projects I've worked on so  far have had this build time
> project, even the smallest.


I meant "All the C++ projects I've worked on so  far had this build time
problem, even the smallest project."

--=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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Oct 1, 2013 at 2:12 PM, Klaim - Jo=EBl Lamotte <span dir=3D"ltr">&l=
t;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">All the C++ projects I&#39;ve worked on so =A0far have had=
 this build time project, even the smallest.</blockquote>
</div><br>I meant &quot;All the C++ projects I&#39;ve worked on so =A0far h=
ad this build time problem, even the smallest project.&quot;</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 />

--001a1134c4c2ff2c1804e7acf7f3--

.

------=_Part_2845_21686803.1380631412079
Content-Type: text/plain; charset=ISO-8859-1

So many ignorant people. Pathetic.

--

---
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_2845_21686803.1380631412079
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">So many ignorant people. Pathetic.<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 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 />

------=_Part_2845_21686803.1380631412079--

.

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

On Monday, September 30, 2013 10:00:07 PM UTC-7, David Krauss wrote:

> On 9/30/13 11:57 PM, Robert Zeh wrote:=20
> > On Mon, Sep 30, 2013 at 10:07 AM, snk_kid <korcan....@googlemail.com<ja=
vascript:>>wrote:=20
>
> >=20
> >> Then come back to features, features which can have=20
> >> an influence (and influenced by) compilation times and see how they=20
> perform.=20
> >>=20
> > I agree that the compile times for projects over 1 million lines of cod=
e=20
> > makes life difficult --- it has certainly made my life difficult.=20
>
> Why don't precompiled headers work for you?
>

They cause many problems.  They're often buggy.  They play very poorly with=
=20
the preprocessor but yet have to play with it where as modules just=20
side-step the preprocessor entirely.  Precompiled headers impose a large=20
number of limitations.  They're not universally available.  Setting them up=
=20
differs between compilers, IDEs, and build systems.  They can often=20
_increase_ build time if used naively and don't help nearly as much as=20
modules can when used intelligently.  Precompiled headers are a hackjob=20
stopgap to work around the severe limitations and problems of the C=20
preprocessor token-pasting dependency mechanism.
=20

>
> Adjusting the language to make compilers faster seems conceptually=20
> backwards, or a red flag. I haven't looked into modules much, but I'd=20


Not fixing a language that is often characterized by its atrocious compile=
=20
times when a clearly identified and widely known (to other similar=20
languages) solution is presented is a lot more backwards, as I see it.=20
 There is a very clear problem and a clear fix; why not do it?  :)
=20

>
> assumed the motivation was elsewhere. I thought header repetition was a=
=20
> solved problem.=20
>
> Loading precompiled header files also takes significant time, but=20
> modules wouldn't necessarily be any better. I'm sure that can be=20
> improved, but it's a job for compiler vendors.=20
>

Other languages have long laid all this to rest.  I'd suggest looking into=
=20
the module sytems - and build time improvements brought about by them - in=
=20
compiled languages like C#, Java, D, Go, etc.  The C include pattern is a=
=20
huge problem that simply does not scale at either a parsing or an I/O=20
level.  That's not surprising considering that the whole C preprocessor was=
=20
a hack to work around short-comings in the original C language itself (you=
=20
might be aware of what C coding was like before the preprocessor was tacked=
=20
on; lots of manual copying of prototypes and structure definitions from big=
=20
printed manuals).  The original C language had no way to include=20
dependencies without pasting things in.  The preprocessor is just a tool to=
=20
make that pasting automated.  Modules fundamentally changes and fixes the=
=20
entire problem rather than just hacking it to be barely tolerable.
=20

> Standardizing an interoperable format equivalent to a precompiled header=
=20
> would take forever. PCHes are just AST dumps. Standardizing a=20
> compressed, serialized AST for every C++ construct? That's much harder=20
> than standardizing an ABI. And when a compiler has to perform meaningful=
=20
> conversion because the native AST differs, performance is lost and the=20
> exercise becomes pointless.=20
>

<pedantry> Well, it's not a hard problem to solve at the basic level of=20
having such an interoperable format.  It's an impossible problem to solve=
=20
in a way that provides any significant benefit.  Simply changing things=20
from needing to parse C/C++ (a portable interchange of machine=20
instructions, if you will) into a compiler-specific in-memory format to=20
needing to parse a slightly more compact version into a compiler-specific=
=20
in-memory format is going to help on the I/O side a bit, but not the=20
parsing or template instantiation side.  The problem is not that it's=20
_hard_ to provide a portable format but that no such portable format can=20
actually do what PCHs do, making the entire exercise pointless. A portable=
=20
PCH would likely just be a big C++ header file run through the=20
preprocessor, maybe with a terser syntax. </pedantry>
=20

>
> So we already have a speedy binary format on every platform used for=20
> serious work, and we're never going to unify these formats anyway=EF=BF=
=BD what=20
> are modules supposed to fix? Just to remove the PCH build-system=20
> boilerplate by letting the compiler cache things more easily? Seems minor=
..
>

Modules simplify the entire coding process.  No other language designed=20
requires such an awkward split as header files.  They're sometimes touted=
=20
as a clean separation between implementation and interface, but that's=20
rarely true.  Templates make that untrue.  Class definitions usually make=
=20
that untrue (since you the header needs to declare public and private=20
members).  The needs of the linker - which on a related subject are in=20
general pretty terrible - mandates a lot in terms of putting private=20
symbols in headers to share things between translation units.  Look at the=
=20
pattern adopted by many/most libraries where they have to split headers=20
between internal and external headers simply because headers by themselves=
=20
don't actually solve any problems at all besides the awkward translation=20
unit semantics inherited from C.

Modules let C++ behave more like all the other modern C-like languages.=20
 They make the problems of header dependencies _disappear_.  They make the=
=20
issues with public and private symbols _explicit_ rather than poorly=20
abstracted.  They remove the code-duplication necessary between a header=20
file and a cpp file.  They remove the arbitrary (from the standpoint of a=
=20
newcomer) distinction between which code must be in a header and which code=
=20
can/should be in a cpp go away.  If fully embraced, they can make most of=
=20
the hairier problems of the linker and dynamic library generation go away,=
=20
too.  And yes, they (can) make the compilation and linking process=20
significantly shorter (if designed/implemented well) in cases where a PCH=
=20
is infeasible or counter-productive and without all the nasty side-effects=
=20
of a unity build.

--=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_578_26165696.1380651141359
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, September 30, 2013 10:00:07 PM UTC-7, David Kra=
uss wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 9/30/13 11:57=
 PM, Robert Zeh wrote:
<br>&gt; On Mon, Sep 30, 2013 at 10:07 AM, snk_kid &lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"o0cLjO_EYSQJ">korcan....@goo=
glemail.com</a><wbr>&gt;wrote:
<br>&gt;
<br>&gt;&gt; Then come back to features, features which can have
<br>&gt;&gt; an influence (and influenced by) compilation times and see how=
 they perform.
<br>&gt;&gt;
<br>&gt; I agree that the compile times for projects over 1 million lines o=
f code
<br>&gt; makes life difficult --- it has certainly made my life difficult.
<br>
<br>Why don't precompiled headers work for you?<br></blockquote><div><br></=
div><div>They cause many problems. &nbsp;They're often buggy. &nbsp;They pl=
ay very poorly with the preprocessor but yet have to play with it where as =
modules just side-step the preprocessor entirely. &nbsp;Precompiled headers=
 impose a large number of limitations. &nbsp;They're not universally availa=
ble. &nbsp;Setting them up differs between compilers, IDEs, and build syste=
ms. &nbsp;They can often _increase_ build time if used naively and don't he=
lp nearly as much as modules can when used intelligently. &nbsp;Precompiled=
 headers are a hackjob stopgap to work around the severe limitations and pr=
oblems of the C preprocessor token-pasting dependency mechanism.</div><div>=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Adjusting the language to make compilers faster seems conceptually=20
<br>backwards, or a red flag. I haven't looked into modules much, but I'd <=
/blockquote><div><br></div><div>Not fixing a language that is often charact=
erized by its atrocious compile times when a clearly identified and widely =
known (to other similar languages) solution is presented is a lot more back=
wards, as I see it. &nbsp;There is a very clear problem and a clear fix; wh=
y not do it? &nbsp;:)</div><div>&nbsp;</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
<br>assumed the motivation was elsewhere. I thought header repetition was a=
=20
<br>solved problem.
<br>
<br>Loading precompiled header files also takes significant time, but=20
<br>modules wouldn't necessarily be any better. I'm sure that can be=20
<br>improved, but it's a job for compiler vendors.
<br></blockquote><div><br></div><div>Other languages have long laid all thi=
s to rest. &nbsp;I'd suggest looking into the module sytems - and build tim=
e improvements brought about by them - in compiled languages like C#, Java,=
 D, Go, etc. &nbsp;The C include pattern is a huge problem that simply does=
 not scale at either a parsing or an I/O level. &nbsp;That's not surprising=
 considering that the whole C preprocessor was a hack to work around short-=
comings in the original C language itself (you might be aware of what C cod=
ing was like before the preprocessor was tacked on; lots of manual copying =
of prototypes and structure definitions from big printed manuals). &nbsp;Th=
e original C language had no way to include dependencies without pasting th=
ings in. &nbsp;The preprocessor is just a tool to make that pasting automat=
ed. &nbsp;Modules fundamentally changes and fixes the entire problem rather=
 than just hacking it to be barely tolerable.</div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">Standardizing an interoperable format=
 equivalent to a precompiled header=20
<br>would take forever. PCHes are just AST dumps. Standardizing a=20
<br>compressed, serialized AST for every C++ construct? That's much harder=
=20
<br>than standardizing an ABI. And when a compiler has to perform meaningfu=
l=20
<br>conversion because the native AST differs, performance is lost and the=
=20
<br>exercise becomes pointless.
<br></blockquote><div><br></div><div>&lt;pedantry&gt; Well, it's not a hard=
 problem to solve at the basic level of having such an interoperable format=
.. &nbsp;It's an impossible problem to solve in a way that provides any sign=
ificant benefit. &nbsp;Simply changing things from needing to parse C/C++ (=
a portable interchange of machine instructions, if you will) into a compile=
r-specific in-memory format to needing to parse a slightly more compact ver=
sion into a compiler-specific in-memory format is going to help on the I/O =
side a bit, but not the parsing or template instantiation side. &nbsp;The p=
roblem is not that it's _hard_ to provide a portable format but that no suc=
h portable format can actually do what PCHs do, making the entire exercise =
pointless. A portable PCH would likely just be a big C++ header file run th=
rough the preprocessor, maybe with a terser syntax. &lt;/pedantry&gt;</div>=
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>So we already have a speedy binary format on every platform used for=20
<br>serious work, and we're never going to unify these formats anyway=EF=BF=
=BD what=20
<br>are modules supposed to fix? Just to remove the PCH build-system=20
<br>boilerplate by letting the compiler cache things more easily? Seems min=
or.<br></blockquote><div><br></div><div>Modules simplify the entire coding =
process. &nbsp;No other language designed requires such an awkward split as=
 header files. &nbsp;They're sometimes touted as a clean separation between=
 implementation and interface, but that's rarely true. &nbsp;Templates make=
 that untrue. &nbsp;Class definitions usually make that untrue (since you t=
he header needs to declare public and private members). &nbsp;The needs of =
the linker - which on a related subject are in general pretty terrible - ma=
ndates a lot in terms of putting private symbols in headers to share things=
 between translation units. &nbsp;Look at the pattern adopted by many/most =
libraries where they have to split headers between internal and external he=
aders simply because headers by themselves don't actually solve any problem=
s at all besides the awkward translation unit semantics inherited from C.</=
div><div><br></div><div>Modules let C++ behave more like all the other mode=
rn C-like languages. &nbsp;They make the problems of header dependencies _d=
isappear_. &nbsp;They make the issues with public and private symbols _expl=
icit_ rather than poorly abstracted. &nbsp;They remove the code-duplication=
 necessary between a header file and a cpp file. &nbsp;They remove the arbi=
trary (from the standpoint of a newcomer) distinction between which code mu=
st be in a header and which code can/should be in a cpp go away. &nbsp;If f=
ully embraced, they can make most of the hairier problems of the linker and=
 dynamic library generation go away, too. &nbsp;And yes, they (can) make th=
e compilation and linking process significantly shorter (if designed/implem=
ented well) in cases where a PCH is infeasible or counter-productive and wi=
thout all the nasty side-effects of a unity build.</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_578_26165696.1380651141359--

.

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



On Wednesday, October 2, 2013 2:12:21 AM UTC+8, Sean Middleditch wrote:
>
> On Monday, September 30, 2013 10:00:07 PM UTC-7, David Krauss wrote:
>
>> On 9/30/13 11:57 PM, Robert Zeh wrote:=20
>> > On Mon, Sep 30, 2013 at 10:07 AM, snk_kid <korcan....@googlemail.com>w=
rote:=20
>>
>> >=20
>> >> Then come back to features, features which can have=20
>> >> an influence (and influenced by) compilation times and see how they=
=20
>> perform.=20
>> >>=20
>> > I agree that the compile times for projects over 1 million lines of=20
>> code=20
>> > makes life difficult --- it has certainly made my life difficult.=20
>>
>> Why don't precompiled headers work for you?
>>
>
> They cause many problems.  They're often buggy. =20
>

Vacuous argument.
=20

> They play very poorly with the preprocessor but yet have to play with it=
=20
> where as modules just side-step the preprocessor entirely.
>

A module sidesteps it by starting translation with no user-defined macros,=
=20
no? And a PCH inclusion must be the first thing in the TU, before any=20
macros are defined. It would seem that modules are merely multiple PCHes,=
=20
or conversely that the problem of using PCHes is exactly that of generating=
=20
a one-size-fits-all PCH-module (or a small set of few-sizes-fit-most=20
PCH-modules) from header components.

If modules are forbidden from defining macros entirely, that's not a good=
=20
thing. All I know is that there have been various proposals of different=20
scopes. It's hard to tell what you're referring to.
=20

>  Precompiled headers impose a large number of limitations.  They're not=
=20
> universally available.  Setting them up differs between compilers, IDEs,=
=20
> and build systems.
>

The same applies to headers, not because of preprocessor limitations but=20
because the language says little about file storage. (And projects really=
=20
do manage headers differently existence, so the vagueness has a purpose.)=
=20
Every "professional" platform I've seen has a facility to dump state to a=
=20
local file, and reload it as the first directive in a TU.

It would be nice to have a standard way of doing that. It could be just a=
=20
single pragma.

Modules, like PCHes, would need to be build targets. Big programs are=20
harder to build; that's just reality.
=20

>  They can often _increase_ build time if used naively
>

The necessary work consists of checking to see which headers are slow, and=
=20
only putting the PCH in sources that actually need those headers.
=20

> and don't help nearly as much as modules can when used intelligently.
>

PCH is a build optimization to be used in addition to headers, which are=20
semantic equivalent to other languages' modules. Indeed it's unhelpful to=
=20
need to work towards a faster build. As for helping the build times, you're=
=20
just speculating because C++ isn't other languages.
=20

>  Precompiled headers are a hackjob stopgap to work around the severe=20
> limitations and problems of the C preprocessor token-pasting dependency=
=20
> mechanism.
>

Some implementations are half-assed, but as for performance, the vendor is=
=20
just addressing customer needs. Modules aren't magic fast sauce as the=20
underlying problem is the same.
=20

> Adjusting the language to make compilers faster seems conceptually=20
>> backwards, or a red flag. I haven't looked into modules much, but I'd=20
>
>
> Not fixing a language that is often characterized by its atrocious compil=
e=20
> times when a clearly identified and widely known (to other similar=20
> languages) solution is presented is a lot more backwards, as I see it.=20
>  There is a very clear problem and a clear fix; why not do it?  :)
>

We're now talking about slow compile times due to excessive long-hand code.=
=20
Not templates or complicated overload resolution, because they need to be=
=20
done the same no matter what.

Wouldn't another fix be to cache redundant definitions, mapping token=20
streams to AST, and skip parsing them? The ODR rule specifically allows=20
this, but no implementations do it. (Disclaimer: I plan to implement this.)

Or, for the here-and-now, minimize the interface and combat bloat with=20
proper separation of concerns. Reusable, highly generic header libraries=20
like Eigen and Boost are slow, but amenable to PCH. They aren't bloat. But=
=20
if you have definitions living in a header which *aren't* getting reused=20
all the time, perhaps they don't belong to an interface.
=20

> Loading precompiled header files also takes significant time, but=20
>> modules wouldn't necessarily be any better. I'm sure that can be=20
>> improved, but it's a job for compiler vendors.=20
>>
>
> Other languages have long laid all this to rest.  I'd suggest looking int=
o=20
> the module sytems - and build time improvements brought about by them - i=
n=20
> compiled languages like C#, Java, D, Go, etc.
>

I'm also familiar with the quirks of Java viz module versioning and=20
identification (and source tree layout, yuck). You still get situations=20
where a "clean rebuild" fixes an issue. Aside from C# which I haven't used,=
=20
I haven't seen D or Go used in a "really big" project.
=20

>  The C include pattern is a huge problem that simply does not scale at=20
> either a parsing or an I/O level.  That's not surprising considering that=
=20
> the whole C preprocessor was a hack to work around short-comings in the=
=20
> original C language itself (you might be aware of what C coding was like=
=20
> before the preprocessor was tacked on; lots of manual copying of prototyp=
es=20
> and structure definitions from big printed manuals).  The original C=20
> language had no way to include dependencies without pasting things in.  T=
he=20
> preprocessor is just a tool to make that pasting automated.  Modules=20
> fundamentally changes and fixes the entire problem rather than just hacki=
ng=20
> it to be barely tolerable.
>

Impassioned, but a vacuous argument. I/O can be cached (and usually is),=20
and a module system only changes its quantity by a constant factor. The ODR=
=20
rule already gives us enough to skip unnecessary parsing. In theory, and=20
hopefully soon in practice, the preprocessor does not make anything else=20
slow. And preprocessing itself (given a file cache) is fast enough not to=
=20
be a problem.

No implementation to my knowledge has even bothered to internalize caching,=
=20
which would be a first step. This is ultimately what makes Java fast: the=
=20
modules are always loaded in the always-on VM.
=20

> <pedantry> Well, it's not a hard problem to solve at the basic level of=
=20
> having such an interoperable format.  It's an impossible problem to solve=
=20
> in a way that provides any significant benefit.
>

Just to keep apples to apples, note that Java does derive a benefit because=
=20
the task at hand isn't translation to native code.

You're mostly rephrasing what I had said.
=20

> A portable PCH would likely just be a big C++ header file run through the=
=20
> preprocessor, maybe with a terser syntax. </pedantry>
>

I was supposing it would already be run through the parser, hence AST. To=
=20
my knowledge that's what most PCHes do.=20

So we already have a speedy binary format on every platform used for=20
>> serious work, and we're never going to unify these formats anyway=EF=BF=
=BD what=20
>> are modules supposed to fix? Just to remove the PCH build-system=20
>> boilerplate by letting the compiler cache things more easily? Seems mino=
r.
>>
>
> Modules simplify the entire coding process.  No other language designed=
=20
> requires such an awkward split as header files.  They're sometimes touted=
=20
> as a clean separation between implementation and interface, but that's=20
> rarely true.  Templates make that untrue.
>

If you *want* template interface separation, you can have it by forward=20
declaration. Folks are just lazy to do so.

Function return type deduction is the first thing to my knowledge to really=
=20
lock out the possibility of interface separation.
=20

>  Class definitions usually make that untrue (since you the header needs t=
o=20
> declare public and private members).
>

This is a real issue, if you really want to hide the private members. But=
=20
I'm not aware of a proposed C++ solution. Modules would make them invisible=
=20
only by obfuscation of the binary format. If that format is unportable, the=
=20
module file still needs to be generated by a publicly distributed source=20
file.

Java doesn't solve it either, it just makes virtual dispatch and factory=20
functions more idiomatic. If you use C++ like Java, the problem already=20
goes away.
=20

>  The needs of the linker - which on a related subject are in general=20
> pretty terrible - mandates a lot in terms of putting private symbols in=
=20
> headers to share things between translation units.  Look at the pattern=
=20
> adopted by many/most libraries where they have to split headers between=
=20
> internal and external headers simply because headers by themselves don't=
=20
> actually solve any problems at all besides the awkward translation unit=
=20
> semantics inherited from C.
>

If you don't want to distribute internal headers, you either need separate=
=20
external headers, or comprehensive documentation in a non-source format,=20
which adds certain risks. I don't see how this relates to TUs. It's a=20
matter of JavaDoc vs Doxygen. Users who don't rely on a manual will see=20
private members when they look up the public ones.

The way to avoid this in Java is with an additional abstract base class,=20
and the same applies in C++. But of course this doesn't mean it applies to=
=20
templates. So really this is fairly new territory. It's not fair to say we=
=20
should copy a solution from a non-templated language.
=20

> Modules let C++ behave more like all the other modern C-like languages.=
=20
>  They make the problems of header dependencies _disappear_.  They make th=
e=20
> issues with public and private symbols _explicit_ rather than poorly=20
> abstracted.  They remove the code-duplication necessary between a header=
=20
> file and a cpp file.  They remove the arbitrary (from the standpoint of a=
=20
> newcomer) distinction between which code must be in a header and which co=
de=20
> can/should be in a cpp go away.  If fully embraced, they can make most of=
=20
> the hairier problems of the linker and dynamic library generation go away=
,=20
> too.  And yes, they (can) make the compilation and linking process=20
> significantly shorter (if designed/implemented well) in cases where a PCH=
=20
> is infeasible or counter-productive and without all the nasty side-effect=
s=20
> of a unity build.
>

 I do think that C++ needs to improve interface specification and=20
separation. Modules might help, but remember that C++ does more than other=
=20
C-like languages. It never foists a pointer upon you, even if it would=20
simplify the ABI or language implementation, and there are templates.

As for performance, implementations should continue to improve handling of=
=20
the current language. We shouldn't need a silver bullet. I still have=20
doubts about non-viability of PCHes, but I guess what matters is real user=
=20
experience, not theoretical user experience :v) .

--=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_1015_27026583.1380686419133
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 2, 2013 2:12:21 AM UTC+8, Se=
an Middleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Monday, September 30, 2013 10:00:07 PM UTC-7, David Krauss wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">On 9/30/13 11:57 PM, Robert Z=
eh wrote:
<br>&gt; On Mon, Sep 30, 2013 at 10:07 AM, snk_kid &lt;<a>korcan....@google=
mail.com</a>&gt;<wbr>wrote:
<br>&gt;
<br>&gt;&gt; Then come back to features, features which can have
<br>&gt;&gt; an influence (and influenced by) compilation times and see how=
 they perform.
<br>&gt;&gt;
<br>&gt; I agree that the compile times for projects over 1 million lines o=
f code
<br>&gt; makes life difficult --- it has certainly made my life difficult.
<br>
<br>Why don't precompiled headers work for you?<br></blockquote><div><br></=
div><div>They cause many problems. &nbsp;They're often buggy. &nbsp;</div><=
/div></blockquote><div><br>Vacuous argument.<br>&nbsp;</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>They play very poorly w=
ith the preprocessor but yet have to play with it where as modules just sid=
e-step the preprocessor entirely.</div></div></blockquote><div><br>A module=
 sidesteps it by starting translation with no user-defined macros, no? And =
a PCH inclusion must be the first thing in the TU, before any macros are de=
fined. It would seem that modules are merely multiple PCHes, or conversely =
that the problem of using PCHes is exactly that of generating a one-size-fi=
ts-all PCH-module (or a small set of few-sizes-fit-most PCH-modules) from h=
eader components.<br><br>If modules are forbidden from defining macros enti=
rely, that's not a good thing. All I know is that there have been various p=
roposals of different scopes. It's hard to tell what you're referring to.<b=
r>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div> &nbsp;Precompiled headers impose a large number of limitations. &nbs=
p;They're not universally available. &nbsp;Setting them up differs between =
compilers, IDEs, and build systems.</div></div></blockquote><div><br>The sa=
me applies to headers, not because of preprocessor limitations but because =
the language says little about file storage. (And projects really do manage=
 headers differently existence, so the vagueness has a purpose.) Every "pro=
fessional" platform I've seen has a facility to dump state to a local file,=
 and reload it as the first directive in a TU.<br><br>It would be nice to h=
ave a standard way of doing that. It could be just a single pragma.<br><br>=
Modules, like PCHes, would need to be build targets. Big programs are harde=
r to build; that's just reality.<br>&nbsp;</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div> &nbsp;They can often _increase_ bu=
ild time if used naively</div></div></blockquote><div><br>The necessary wor=
k consists of checking to see which headers are slow, and only putting the =
PCH in sources that actually need those headers.<br>&nbsp;</div><blockquote=
 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"><div> and don't help nea=
rly as much as modules can when used intelligently.</div></div></blockquote=
><div><br>PCH is a build optimization to be used in addition to headers, wh=
ich are semantic equivalent to other languages' modules. Indeed it's unhelp=
ful to need to work towards a faster build. As for helping the build times,=
 you're just speculating because C++ isn't other languages.<br>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div> &nbsp;P=
recompiled headers are a hackjob stopgap to work around the severe limitati=
ons and problems of the C preprocessor token-pasting dependency mechanism.<=
/div></div></blockquote><div><br>Some implementations are half-assed, but a=
s for performance, the vendor is just addressing customer needs. Modules ar=
en't magic fast sauce as the underlying problem is the same.<br>&nbsp;</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">
Adjusting the language to make compilers faster seems conceptually=20
<br>backwards, or a red flag. I haven't looked into modules much, but I'd <=
/blockquote><div><br></div><div>Not fixing a language that is often charact=
erized by its atrocious compile times when a clearly identified and widely =
known (to other similar languages) solution is presented is a lot more back=
wards, as I see it. &nbsp;There is a very clear problem and a clear fix; wh=
y not do it? &nbsp;:)</div></div></blockquote><div><br>We're now talking ab=
out slow compile times due to excessive long-hand code. Not templates or co=
mplicated overload resolution, because they need to be done the same no mat=
ter what.<br><br>Wouldn't another fix be to cache redundant definitions, ma=
pping token streams to AST, and skip parsing them? The ODR rule specificall=
y allows this, but no implementations do it. (Disclaimer: I plan to impleme=
nt this.)<br><br>Or, for the here-and-now, minimize the interface and comba=
t bloat with proper separation of concerns. Reusable, highly generic header=
 libraries like Eigen and Boost are slow, but amenable to PCH. They aren't =
bloat. But if you have definitions living in a header which *aren't* gettin=
g reused all the time, perhaps they don't belong to an interface.<br>&nbsp;=
</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"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">
Loading precompiled header files also takes significant time, but=20
<br>modules wouldn't necessarily be any better. I'm sure that can be=20
<br>improved, but it's a job for compiler vendors.
<br></blockquote><div><br></div><div>Other languages have long laid all thi=
s to rest. &nbsp;I'd suggest looking into the module sytems - and build tim=
e improvements brought about by them - in compiled languages like C#, Java,=
 D, Go, etc.</div></div></blockquote><div><br>I'm also familiar with the qu=
irks of Java viz module versioning and identification (and source tree layo=
ut, yuck). You still get situations where a "clean rebuild" fixes an issue.=
 Aside from C# which I haven't used, I haven't seen D or Go used in a "real=
ly big" project.<br>&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;The C include pattern is a huge problem that=
 simply does not scale at either a parsing or an I/O level. &nbsp;That's no=
t surprising considering that the whole C preprocessor was a hack to work a=
round short-comings in the original C language itself (you might be aware o=
f what C coding was like before the preprocessor was tacked on; lots of man=
ual copying of prototypes and structure definitions from big printed manual=
s). &nbsp;The original C language had no way to include dependencies withou=
t pasting things in. &nbsp;The preprocessor is just a tool to make that pas=
ting automated. &nbsp;Modules fundamentally changes and fixes the entire pr=
oblem rather than just hacking it to be barely tolerable.</div></div></bloc=
kquote><div><br>Impassioned, but a vacuous argument. I/O can be cached (and=
 usually is), and a module system only changes its quantity by a constant f=
actor. The ODR rule already gives us enough to skip unnecessary parsing. In=
 theory, and hopefully soon in practice, the preprocessor does not make any=
thing else slow. And preprocessing itself (given a file cache) is fast enou=
gh not to be a problem.<br><br>No implementation to my knowledge has even b=
othered to internalize caching, which would be a first step. This is ultima=
tely what makes Java fast: the modules are always loaded in the always-on V=
M.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">&lt;pedantry&gt; Well, it's not a hard problem to solve at the basic l=
evel of having such an interoperable format. &nbsp;It's an impossible probl=
em to solve in a way that provides any significant benefit.</div></blockquo=
te><div><br>Just to keep apples to apples, note that Java does derive a ben=
efit because the task at hand isn't translation to native code.<br><br>You'=
re mostly rephrasing what I had said.<br>&nbsp;</div><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"> A portable PCH would likely just b=
e a big C++ header file run through the preprocessor, maybe with a terser s=
yntax. &lt;/pedantry&gt;</div></blockquote><div><br>I was supposing it woul=
d already be run through the parser, hence AST. To my knowledge that's what=
 most PCHes do. <br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">So we already have=
 a speedy binary format on every platform used for=20
<br>serious work, and we're never going to unify these formats anyway=EF=BF=
=BD what=20
<br>are modules supposed to fix? Just to remove the PCH build-system=20
<br>boilerplate by letting the compiler cache things more easily? Seems min=
or.<br></blockquote><div><br></div><div>Modules simplify the entire coding =
process. &nbsp;No other language designed requires such an awkward split as=
 header files. &nbsp;They're sometimes touted as a clean separation between=
 implementation and interface, but that's rarely true. &nbsp;Templates make=
 that untrue.</div></div></blockquote><div><br>If you *want* template inter=
face separation, you can have it by forward declaration. Folks are just laz=
y to do so.<br><br>Function return type deduction is the first thing to my =
knowledge to really lock out the possibility of interface separation.<br>&n=
bsp;</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"><di=
v> &nbsp;Class definitions usually make that untrue (since you the header n=
eeds to declare public and private members).</div></div></blockquote><div><=
br>This is a real issue, if you really want to hide the private members. Bu=
t I'm not aware of a proposed C++ solution. Modules would make them invisib=
le only by obfuscation of the binary format. If that format is unportable, =
the module file still needs to be generated by a publicly distributed sourc=
e file.<br><br>Java doesn't solve it either, it just makes virtual dispatch=
 and factory functions more idiomatic. If you use C++ like Java, the proble=
m already goes away.<br>&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;The needs of the linker - which on a rel=
ated subject are in general pretty terrible - mandates a lot in terms of pu=
tting private symbols in headers to share things between translation units.=
&nbsp; Look at the pattern adopted by many/most libraries where they have t=
o split headers between internal and external headers simply because header=
s by themselves don't actually solve any problems at all besides the awkwar=
d translation unit semantics inherited from C.</div></div></blockquote><div=
><br>If you don't want to distribute internal headers, you either need sepa=
rate external headers, or comprehensive documentation in a non-source forma=
t, which adds certain risks. I don't see how this relates to TUs. It's a ma=
tter of JavaDoc vs Doxygen. Users who don't rely on a manual will see priva=
te members when they look up the public ones.<br><br>The way to avoid this =
in Java is with an additional abstract base class, and the same applies in =
C++. But of course this doesn't mean it applies to templates. So really thi=
s is fairly new territory. It's not fair to say we should copy a solution f=
rom a non-templated language.<br>&nbsp;</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div>Modules let C++ behave more like all t=
he other modern C-like languages. &nbsp;They make the problems of header de=
pendencies _disappear_. &nbsp;They make the issues with public and private =
symbols _explicit_ rather than poorly abstracted. &nbsp;They remove the cod=
e-duplication necessary between a header file and a cpp file. &nbsp;They re=
move the arbitrary (from the standpoint of a newcomer) distinction between =
which code must be in a header and which code can/should be in a cpp go awa=
y. &nbsp;If fully embraced, they can make most of the hairier problems of t=
he linker and dynamic library generation go away, too. &nbsp;And yes, they =
(can) make the compilation and linking process significantly shorter (if de=
signed/implemented well) in cases where a PCH is infeasible or counter-prod=
uctive and without all the nasty side-effects of a unity build.</div></div>=
</blockquote><div><br>&nbsp;I do think that C++ needs to improve interface =
specification and separation. Modules might help, but remember that C++ doe=
s more than other C-like languages. It never foists a pointer upon you, eve=
n if it would simplify the ABI or language implementation, and there are te=
mplates.<br><br>As for performance, implementations should continue to impr=
ove handling of the current language. We shouldn't need a silver bullet. I =
still have doubts about non-viability of PCHes, but I guess what matters is=
 real user experience, not theoretical user experience :v) .<br><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_1015_27026583.1380686419133--

.