------=_Part_571_1849184376.1430156056913
Content-Type: multipart/alternative;
 boundary="----=_Part_572_858468048.1430156056913"

------=_Part_572_858468048.1430156056913
Content-Type: text/plain; charset=UTF-8

Hello,
I propose to find a solution to avoid typing many of: #include
<any-std-header>
The compiler could assume that all symbols in std are in the current
namespace
after parsing a keyword, i.e. #include <>

so that if I type the following code the compiler doesn't complain:

#include <>
using namespace std;
int main(void) {
  string instance;
  thread instance2;
  vector<unique_ptr<int> > instance3;
 ...
  return 0;
}

....so in the compilation process the compiler would notice that header for
std::string is required -or for any other std type explicitely mentioned-
so it includes them automagically, like if #include <string> and #include
<vector> and #include <thread>, etc would have bee written in the code.

Thank you.

Marcos MM Mayorga

--

---
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_572_858468048.1430156056913
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<br>I propose to find a solution to avoid typing man=
y of: #include &lt;any-std-header&gt; <br>The compiler could assume that al=
l symbols in std are in the current namespace<br>after parsing a keyword, i=
..e. #include &lt;&gt;<br><br>so that if I type the following code the compi=
ler doesn't complain:<br><br>#include &lt;&gt;<br>using namespace std;<br>i=
nt main(void) {<br>&nbsp; string instance;<br>&nbsp; thread instance2;<br>&=
nbsp; vector&lt;unique_ptr&lt;int&gt; &gt; instance3;<br>&nbsp;...<br>&nbsp=
; return 0;<br>}<br><br>...so in the compilation process the compiler would=
 notice that header for std::string  is required -or for any other std type=
 explicitely mentioned- so it includes them automagically, like if #include=
 &lt;string&gt; and #include &lt;vector&gt; and #include &lt;thread&gt;, et=
c would have bee written in the code.<br><br>Thank you.<br><br>Marcos MM Ma=
yorga<br><br></div>

<p></p>

-- <br />
<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 <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 />
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_572_858468048.1430156056913--
------=_Part_571_1849184376.1430156056913--

.

------=_Part_3216_1674846392.1430157203256
Content-Type: multipart/alternative;
 boundary="----=_Part_3217_2075149115.1430157203257"

------=_Part_3217_2075149115.1430157203257
Content-Type: text/plain; charset=UTF-8

No.

--

---
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_3217_2075149115.1430157203257
Content-Type: text/html; charset=UTF-8

No.

<p></p>

-- <br />
<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 <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<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_3217_2075149115.1430157203257--
------=_Part_3216_1674846392.1430157203256--

.

------=_Part_4447_941598983.1430157413055
Content-Type: multipart/alternative;
 boundary="----=_Part_4448_647112538.1430157413055"

------=_Part_4448_647112538.1430157413055
Content-Type: text/plain; charset=UTF-8

If you're comfortable with having one, write an own header and include all
standard library headers in it.
However, that's definitely not recommended, and would not warrant a
language change by any means.

--

---
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_4448_647112538.1430157413055
Content-Type: text/html; charset=UTF-8

<div dir="ltr">If you're comfortable with having one, write an own header and include all standard library headers in it.<div>However, that's definitely not recommended, and would not warrant a language change by any means.</div></div>

<p></p>

-- <br />
<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 <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<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_4448_647112538.1430157413055--
------=_Part_4447_941598983.1430157413055--

.

This is a multi-part message in MIME format.
--------------010003070604030907070502
Content-Type: text/plain; charset=UTF-8; format=flowed



On 28/04/15 03:53, tomalak@gmail.com wrote:
> No. --

I'll add my No to that, this is a bad idea if you really want that just
make a file allstd say and put it all in there
ie.
#include <string>
#include <iostream>
....
// then I suppose you want the c stuff too so:

#include <cassert>
....

// I would never use this as it would bring in every thing even the
stuff I wasn't using
#include <allstd>
using namespace std;
// we now have all of std in there whether we use it or not

>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

    .~.     In my life God comes first....
    /V\         but Linux is pretty high after that :-D
   /( )\    Francis (Grizzly) Smit
   ^^-^^    http://www.smit.id.au/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GM/CS/H/P/S/IT/L d- s+:+ a++ C++++ UL++++$ P++ L+++$ E--- W++
N W--- M-- V-- PE- PGP t+ 5-- X-- R- tv b++++ D-
G e++ h+ y?
------END GEEK CODE BLOCK------
http://www.geekcode.com/

--

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

--------------010003070604030907070502
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 28/04/15 03:53, <a class="moz-txt-link-abbreviated" href="mailto:tomalak@gmail.com">tomalak@gmail.com</a>
      wrote:<br>
    </div>
    <blockquote
      cite="mid:d9c73d07-81f9-430b-a343-50ec4277d6b4@isocpp.org"
      type="cite">No.
      -- <br>
    </blockquote>
    <br>
    I'll add my No to that, this is a bad idea if you really want that
    just make a file allstd say and put it all in there<br>
    ie.<br>
    #include &lt;string&gt;<br>
    #include &lt;iostream&gt;<br>
    ...<br>
    // then I suppose you want the c stuff too so:<br>
    <br>
    #include &lt;cassert&gt;<br>
    ...<br>
    <br>
    // I would never use this as it would bring in every thing even the
    stuff I wasn't using<br>
    #include &lt;allstd&gt;<br>
    using namespace std;<br>
    // we now have all of std in there whether we use it or not<br>
    <br>
    <blockquote
      cite="mid:d9c73d07-81f9-430b-a343-50ec4277d6b4@isocpp.org"
      type="cite">
      <br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send="true"
        href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send="true"
        href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
      Visit this group at <a moz-do-not-send="true"
        href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <pre>   .~.     In my life God comes first....
   /V\         but Linux is pretty high after that :-D
  /( )\    Francis (Grizzly) Smit
  ^^-^^    <a class="moz-txt-link-freetext" href="http://www.smit.id.au/">http://www.smit.id.au/</a>
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GM/CS/H/P/S/IT/L d- s+:+ a++ C++++ UL++++$ P++ L+++$ E--- W++
N W--- M-- V-- PE- PGP t+ 5-- X-- R- tv b++++ D-
G e++ h+ y?
------END GEEK CODE BLOCK------
<a class="moz-txt-link-freetext" href="http://www.geekcode.com/">http://www.geekcode.com/</a>
</pre>
    </div>
  </body>
</html>

<p></p>

-- <br />
<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 <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<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 />

--------------010003070604030907070502--

.

--047d7b5d5e12c170a60514c61bc7
Content-Type: text/plain; charset=UTF-8

I would like to add my thumbs down to the proposal.  As already mentioned,
if you *really did need* to import all standard headers, create a prelude
header.

I can see no advantage of getting the compiler to discern from the code
which headers are needed.  By the time the compiler has ascertained the
need, the optimal point of inclusion has elapsed.

--

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

--047d7b5d5e12c170a60514c61bc7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>I would like to add my thumbs down to the proposal.=C2=A0 As already m=
entioned, if you <em>really did need</em> to import all standard headers, c=
reate a prelude header.</div>
<div>=C2=A0</div>
<div>I can see no advantage of getting the compiler to discern from the cod=
e which headers are needed.=C2=A0 By the time the compiler has ascertained =
the need, the optimal point of inclusion has elapsed.</div>

<p></p>

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

--047d7b5d5e12c170a60514c61bc7--

.

On 28 April 2015 at 13:13, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> I would like to add my thumbs down to the proposal.  As already mentioned,
> if you really did need to import all standard headers, create a prelude
> header.

Also, standardized prelude headers have been proposed, but we can't agree on
what should go in them. Roll your own.

--

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

.

On Tue, Apr 28, 2015 at 1:30 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 28 April 2015 at 13:13, Douglas Boffey <douglas.boffey@gmail.com> wrote:
>> I would like to add my thumbs down to the proposal.  As already mentioned,
>> if you really did need to import all standard headers, create a prelude
>> header.
>
> Also, standardized prelude headers have been proposed, but we can't agree on
> what should go in them. Roll your own.

I'll add my -1 to the proposal. If anything, I would prefer standard
headers to be more fine grained.

--

---
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_351_1812425018.1430218669458
Content-Type: multipart/alternative;
 boundary="----=_Part_352_1519228478.1430218669458"

------=_Part_352_1519228478.1430218669458
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Also, the #include directives are being replaced by modules. So I think it=
=20
would be better to talk about how modules could implement that kind of=20
feature (even if I do not thinks modules will made it anytime soon).
BTW, I don't see how such a feature could be implemented in #include since=
=20
this directive is handled by the preprocessor, not the compiler.

Le lundi 27 avril 2015 19:34:17 UTC+2, mayorg...@gmail.com a =C3=A9crit :
>
> Hello,
> I propose to find a solution to avoid typing many of: #include=20
> <any-std-header>=20
> The compiler could assume that all symbols in std are in the current=20
> namespace
> after parsing a keyword, i.e. #include <>
>
> so that if I type the following code the compiler doesn't complain:
>
> #include <>
> using namespace std;
> int main(void) {
>   string instance;
>   thread instance2;
>   vector<unique_ptr<int> > instance3;
>  ...
>   return 0;
> }
>
> ...so in the compilation process the compiler would notice that header fo=
r=20
> std::string is required -or for any other std type explicitely mentioned-=
=20
> so it includes them automagically, like if #include <string> and #include=
=20
> <vector> and #include <thread>, etc would have bee written in the code.
>
> Thank you.
>
> Marcos MM Mayorga
>
>

--=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_352_1519228478.1430218669458
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Also, the #include directives are being replaced by module=
s. So I think it would be better to talk about how modules could implement =
that kind of feature (even if I do not thinks modules will made it anytime =
soon).<br>BTW, I don't see how such a feature could be implemented in #incl=
ude since this directive is handled by the preprocessor, not the compiler.<=
br><br>Le lundi 27 avril 2015 19:34:17 UTC+2, mayorg...@gmail.com a =C3=A9c=
rit&nbsp;:<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">Hel=
lo,<br>I propose to find a solution to avoid typing many of: #include &lt;a=
ny-std-header&gt; <br>The compiler could assume that all symbols in std are=
 in the current namespace<br>after parsing a keyword, i.e. #include &lt;&gt=
;<br><br>so that if I type the following code the compiler doesn't complain=
:<br><br>#include &lt;&gt;<br>using namespace std;<br>int main(void) {<br>&=
nbsp; string instance;<br>&nbsp; thread instance2;<br>&nbsp; vector&lt;uniq=
ue_ptr&lt;int&gt; &gt; instance3;<br>&nbsp;...<br>&nbsp; return 0;<br>}<br>=
<br>...so in the compilation process the compiler would notice that header =
for std::string  is required -or for any other std type explicitely mention=
ed- so it includes them automagically, like if #include &lt;string&gt; and =
#include &lt;vector&gt; and #include &lt;thread&gt;, etc would have bee wri=
tten in the code.<br><br>Thank you.<br><br>Marcos MM Mayorga<br><br></div><=
/blockquote></div>

<p></p>

-- <br />
<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 <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 />
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_352_1519228478.1430218669458--
------=_Part_351_1812425018.1430218669458--

.

Hi,
Thank you for the replies.
Let me please say something more in favour of the proposal.
I defend less work for the programmer, not less work for the compiler.
If the programmer specifies std::string in the code the compiler could
implicitly include <string>, instead of complaining and forcing the
programmer lose time and focus writing the mandatory header inclusion
line which does not add more value to the code.
Note that, in practice, this doesn't require to include all std
library on each compilation job, it just require for the compiler to
have an internal pre-calculated lookup table (std::symbol,header
file).

Best,
Marcos

PS: solutions like having a personal header file are out of the scope
of the proposal, the practical benefit would be real if this a
standard behavior in compilers.


2015-04-28 12:57 GMT+02:00, masse.nicolas@gmail.com <masse.nicolas@gmail.co=
m>:
> Also, the #include directives are being replaced by modules. So I think i=
t
> would be better to talk about how modules could implement that kind of
> feature (even if I do not thinks modules will made it anytime soon).
> BTW, I don't see how such a feature could be implemented in #include sinc=
e
> this directive is handled by the preprocessor, not the compiler.
>
> Le lundi 27 avril 2015 19:34:17 UTC+2, mayorg...@gmail.com a =C3=A9crit :
>>
>> Hello,
>> I propose to find a solution to avoid typing many of: #include
>> <any-std-header>
>> The compiler could assume that all symbols in std are in the current
>> namespace
>> after parsing a keyword, i.e. #include <>
>>
>> so that if I type the following code the compiler doesn't complain:
>>
>> #include <>
>> using namespace std;
>> int main(void) {
>>   string instance;
>>   thread instance2;
>>   vector<unique_ptr<int> > instance3;
>>  ...
>>   return 0;
>> }
>>
>> ...so in the compilation process the compiler would notice that header f=
or
>>
>> std::string is required -or for any other std type explicitely mentioned=
-
>>
>> so it includes them automagically, like if #include <string> and #includ=
e
>>
>> <vector> and #include <thread>, etc would have bee written in the code.
>>
>> Thank you.
>>
>> Marcos MM Mayorga
>>
>>


--=20
mm-studios.com
"un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
abonarlos."
follow my tweets at http://twitter.com/mayorga;
Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2

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

.

--f46d043892d75626bf0514c94212
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well, among the issues to solve if you want you proposal to have a chance
(I think):

1. #include is a preprocessor directive (which copy-paste the content of a
file into the currently processed),
    it'snot a keyword, and there is no way you will make it work
    with the language. Therefore instead of proposing #include <>, you
should propose an actual keyword.
   Maybe something like "import *;".
2. There is the Module TS work-in-progress which will introduce new ways to
"import" things.
   This should improve the ease to find the right library for the use.
   For example:  import std;
   Should make available every name from the standard library, which is
more or less what you are
   proposing. Therefore, there might not be a need for your proposal.
3. Most languages with module system don't provide the feature you are
proposing and I think I can easily guess why:
   a. the search for the name might be expensive on compilation time and
memory;
   b. this totally breaks encapsulation strategies. I mean that it seem
useful exclusively for very simple cases, not in big projects.
   c. For languages other than C++, using this proposal would force the
user to use only cannonical names, which are very long
       in these languages. In C++ using namespace directives would help
make the code shorter but might make it harder to read too,
       it depends.

In any way, I think you might want to check the details of the current
modules proposals see if they fit the need
and then reconsider if your proposal is actually needed in a world with
modules.




On Tue, Apr 28, 2015 at 3:22 PM, Marcos Mayorga <mayorga.geek@gmail.com>
wrote:

> Hi,
> Thank you for the replies.
> Let me please say something more in favour of the proposal.
> I defend less work for the programmer, not less work for the compiler.
> If the programmer specifies std::string in the code the compiler could
> implicitly include <string>, instead of complaining and forcing the
> programmer lose time and focus writing the mandatory header inclusion
> line which does not add more value to the code.
> Note that, in practice, this doesn't require to include all std
> library on each compilation job, it just require for the compiler to
> have an internal pre-calculated lookup table (std::symbol,header
> file).
>
> Best,
> Marcos
>
> PS: solutions like having a personal header file are out of the scope
> of the proposal, the practical benefit would be real if this a
> standard behavior in compilers.
>
>
> 2015-04-28 12:57 GMT+02:00, masse.nicolas@gmail.com <
> masse.nicolas@gmail.com>:
> > Also, the #include directives are being replaced by modules. So I think
> it
> > would be better to talk about how modules could implement that kind of
> > feature (even if I do not thinks modules will made it anytime soon).
> > BTW, I don't see how such a feature could be implemented in #include
> since
> > this directive is handled by the preprocessor, not the compiler.
> >
> > Le lundi 27 avril 2015 19:34:17 UTC+2, mayorg...@gmail.com a =C3=A9crit=
 :
> >>
> >> Hello,
> >> I propose to find a solution to avoid typing many of: #include
> >> <any-std-header>
> >> The compiler could assume that all symbols in std are in the current
> >> namespace
> >> after parsing a keyword, i.e. #include <>
> >>
> >> so that if I type the following code the compiler doesn't complain:
> >>
> >> #include <>
> >> using namespace std;
> >> int main(void) {
> >>   string instance;
> >>   thread instance2;
> >>   vector<unique_ptr<int> > instance3;
> >>  ...
> >>   return 0;
> >> }
> >>
> >> ...so in the compilation process the compiler would notice that header
> for
> >>
> >> std::string is required -or for any other std type explicitely
> mentioned-
> >>
> >> so it includes them automagically, like if #include <string> and
> #include
> >>
> >> <vector> and #include <thread>, etc would have bee written in the code=
..
> >>
> >> Thank you.
> >>
> >> Marcos MM Mayorga
> >>
> >>
>
>
> --
> mm-studios.com
> "un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
> abonarlos."
> follow my tweets at http://twitter.com/mayorga;
> Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2
>
> --
>
> ---
> 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/.
>

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

--f46d043892d75626bf0514c94212
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well, among the issues to solve if you want you proposal t=
o have a chance (I think):<div><br></div><div>1. #include is a preprocessor=
 directive (which copy-paste the content of a file into the currently proce=
ssed),=C2=A0</div><div>=C2=A0 =C2=A0 it&#39;snot a keyword, and there is no=
 way you will make it work=C2=A0</div><div>=C2=A0 =C2=A0 with the language.=
 Therefore instead of proposing #include &lt;&gt;, you should propose an ac=
tual keyword.</div><div>=C2=A0 =C2=A0Maybe something like &quot;import *;&q=
uot;.</div><div>2. There is the Module TS work-in-progress which will intro=
duce new ways to &quot;import&quot; things.</div><div>=C2=A0 =C2=A0This sho=
uld improve the ease to find the right library for the use.</div><div>=C2=
=A0 =C2=A0For example: =C2=A0import std;</div><div>=C2=A0 =C2=A0Should make=
 available every name from the standard library, which is more or less what=
 you are</div><div>=C2=A0 =C2=A0proposing. Therefore, there might not be a =
need for your proposal.</div><div>3. Most languages with module system don&=
#39;t provide the feature you are proposing and I think I can easily guess =
why:</div><div>=C2=A0 =C2=A0a. the search for the name might be expensive o=
n compilation time and memory;</div><div>=C2=A0 =C2=A0b. this totally break=
s encapsulation strategies. I mean that it seem useful exclusively for very=
 simple cases, not in big projects.</div><div>=C2=A0 =C2=A0c. For languages=
 other than C++, using this proposal would force the user to use only canno=
nical names, which are very long</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0in th=
ese languages. In C++ using namespace directives would help make the code s=
horter but might make it harder to read too,</div><div>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0it depends.</div><div><br></div><div>In any way, I think you might w=
ant to check the details of the current modules proposals see if they fit t=
he need</div><div>and then reconsider if your proposal is actually needed i=
n a world with modules.</div><div><br></div><div><br></div><div><br></div><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Apr =
28, 2015 at 3:22 PM, Marcos Mayorga <span dir=3D"ltr">&lt;<a href=3D"mailto=
:mayorga.geek@gmail.com" target=3D"_blank">mayorga.geek@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
Thank you for the replies.<br>
Let me please say something more in favour of the proposal.<br>
I defend less work for the programmer, not less work for the compiler.<br>
If the programmer specifies std::string in the code the compiler could<br>
implicitly include &lt;string&gt;, instead of complaining and forcing the<b=
r>
programmer lose time and focus writing the mandatory header inclusion<br>
line which does not add more value to the code.<br>
Note that, in practice, this doesn&#39;t require to include all std<br>
library on each compilation job, it just require for the compiler to<br>
have an internal pre-calculated lookup table (std::symbol,header<br>
file).<br>
<br>
Best,<br>
Marcos<br>
<br>
PS: solutions like having a personal header file are out of the scope<br>
of the proposal, the practical benefit would be real if this a<br>
standard behavior in compilers.<br>
<div><div class=3D"h5"><br>
<br>
2015-04-28 12:57 GMT+02:00, <a href=3D"mailto:masse.nicolas@gmail.com">mass=
e.nicolas@gmail.com</a> &lt;<a href=3D"mailto:masse.nicolas@gmail.com">mass=
e.nicolas@gmail.com</a>&gt;:<br>
&gt; Also, the #include directives are being replaced by modules. So I thin=
k it<br>
&gt; would be better to talk about how modules could implement that kind of=
<br>
&gt; feature (even if I do not thinks modules will made it anytime soon).<b=
r>
&gt; BTW, I don&#39;t see how such a feature could be implemented in #inclu=
de since<br>
&gt; this directive is handled by the preprocessor, not the compiler.<br>
&gt;<br>
&gt; Le lundi 27 avril 2015 19:34:17 UTC+2, <a href=3D"mailto:mayorg...@gma=
il.com">mayorg...@gmail.com</a> a =C3=A9crit :<br>
&gt;&gt;<br>
&gt;&gt; Hello,<br>
&gt;&gt; I propose to find a solution to avoid typing many of: #include<br>
&gt;&gt; &lt;any-std-header&gt;<br>
&gt;&gt; The compiler could assume that all symbols in std are in the curre=
nt<br>
&gt;&gt; namespace<br>
&gt;&gt; after parsing a keyword, i.e. #include &lt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; so that if I type the following code the compiler doesn&#39;t comp=
lain:<br>
&gt;&gt;<br>
&gt;&gt; #include &lt;&gt;<br>
&gt;&gt; using namespace std;<br>
&gt;&gt; int main(void) {<br>
&gt;&gt;=C2=A0 =C2=A0string instance;<br>
&gt;&gt;=C2=A0 =C2=A0thread instance2;<br>
&gt;&gt;=C2=A0 =C2=A0vector&lt;unique_ptr&lt;int&gt; &gt; instance3;<br>
&gt;&gt;=C2=A0 ...<br>
&gt;&gt;=C2=A0 =C2=A0return 0;<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; ...so in the compilation process the compiler would notice that he=
ader for<br>
&gt;&gt;<br>
&gt;&gt; std::string is required -or for any other std type explicitely men=
tioned-<br>
&gt;&gt;<br>
&gt;&gt; so it includes them automagically, like if #include &lt;string&gt;=
 and #include<br>
&gt;&gt;<br>
&gt;&gt; &lt;vector&gt; and #include &lt;thread&gt;, etc would have bee wri=
tten in the code.<br>
&gt;&gt;<br>
&gt;&gt; Thank you.<br>
&gt;&gt;<br>
&gt;&gt; Marcos MM Mayorga<br>
&gt;&gt;<br>
&gt;&gt;<br>
<br>
<br>
--<br>
</div></div><a href=3D"http://mm-studios.com" target=3D"_blank">mm-studios.=
com</a><br>
&quot;un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo pued=
o<br>
abonarlos.&quot;<br>
follow my tweets at <a href=3D"http://twitter.com/mayorga" target=3D"_blank=
">http://twitter.com/mayorga</a>;<br>
Marcos Mayorga. 9CEA 212C C9BC A7C1 D417=C2=A0 4B9A 859D FCA1 A159 49E2<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--f46d043892d75626bf0514c94212--

.

--Apple-Mail=_DD8B51F4-B95D-4415-8778-82D34D165D15
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9328, at 9:22 PM, Marcos Mayorga <mayorga.geek@g=
mail.com> wrote:
>=20
> I defend less work for the programmer, not less work for the compiler.

Longer coffee breaks :)

https://xkcd.com/303/ <https://xkcd.com/303/>

> Note that, in practice, this doesn't require to include all std
> library on each compilation job, it just require for the compiler to
> have an internal pre-calculated lookup table (std::symbol,header
> file).


Surely we=E2=80=99ll get there one day. It=E2=80=99s the natural result of =
evolution.

However, things with such difficult implementation can=E2=80=99t be legisla=
ted into existence.

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

--Apple-Mail=_DD8B51F4-B95D-4415-8778-82D34D165D15
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9328, at 9:22 PM, Marcos Mayorga &lt;<a href=3D"mailto:mayorga.geek@=
gmail.com" class=3D"">mayorga.geek@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; floa=
t: none; display: inline !important;" class=3D"">I defend less work for the=
 programmer, not less work for the compiler.</span><br style=3D"font-family=
: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fon=
t-weight: normal; letter-spacing: normal; line-height: normal; orphans: aut=
o; text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" c=
lass=3D""></div></blockquote></div><br class=3D""><div class=3D"">Longer co=
ffee breaks :)</div><div class=3D""><br class=3D""></div><div class=3D""><a=
 href=3D"https://xkcd.com/303/" class=3D"">https://xkcd.com/303/</a></div><=
div class=3D""><br class=3D""></div><div class=3D""><blockquote type=3D"cit=
e" class=3D""><div class=3D"">Note that, in practice, this doesn't require =
to include all std</div><div class=3D""><span class=3D"" style=3D"float: no=
ne; display: inline !important;">library on each compilation job, it just r=
equire for the compiler to</span><br class=3D""><span class=3D"" style=3D"f=
loat: none; display: inline !important;">have an internal pre-calculated lo=
okup table (std::symbol,header</span><br class=3D""><span class=3D"" style=
=3D"float: none; display: inline !important;">file).</span><br class=3D""><=
/div></blockquote></div><div class=3D""><div class=3D""><span class=3D"" st=
yle=3D"float: none; display: inline !important;"><br class=3D""></span></di=
v></div><div class=3D""><span class=3D"" style=3D"float: none; display: inl=
ine !important;">Surely we=E2=80=99ll get there one day. It=E2=80=99s the n=
atural result of evolution.</span></div><div class=3D""><span class=3D"" st=
yle=3D"float: none; display: inline !important;"><br class=3D""></span></di=
v><div class=3D""><span class=3D"" style=3D"float: none; display: inline !i=
mportant;">However, things with such difficult implementation can=E2=80=99t=
 be legislated into existence.</span></div></body></html>

<p></p>

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

--Apple-Mail=_DD8B51F4-B95D-4415-8778-82D34D165D15--

.

On Tue, Apr 28, 2015 at 4:22 PM, Marcos Mayorga <mayorga.geek@gmail.com> wrote:
> Hi,
> Thank you for the replies.
> Let me please say something more in favour of the proposal.
> I defend less work for the programmer, not less work for the compiler.
> If the programmer specifies std::string in the code the compiler could
> implicitly include <string>, instead of complaining and forcing the
> programmer lose time and focus writing the mandatory header inclusion
> line which does not add more value to the code.
> Note that, in practice, this doesn't require to include all std
> library on each compilation job, it just require for the compiler to
> have an internal pre-calculated lookup table (std::symbol,header
> file).

What would you do with name clashes and ADL?

Ex.1:

  using namespace std;
  const char* find(const char*, const char*, char);

  template< typename T >
  void foo(T begin, T end)
  {
    T p = find(begin, end, 'x'); // includes <algorithm>?
  }

Ex.2:

  #include <boost/shared_ptr.hpp>

  using namespace std;
  using namespace boost;

  typedef shared_ptr< int > ptr; // includes <memory>? ambiguous?

Ex.3:

  std::string a, b;
  swap(a, b); // includes <utility>? why?

--

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

.

--001a11c204fa12f6560514f02c4c
Content-Type: text/plain; charset=UTF-8

Assuming the std header <algorithm> contains the guard _ALGORITHM, how
would you expect the following to behave?

#include <>

void foo(const std::vector<int> &v) {
#ifndef _ALGORITHM
  std::for_each(v.begin(), v.end(), [](int i){std::cout << i; }
#endif
}

--

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

--001a11c204fa12f6560514f02c4c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>Assuming the std header &lt;algorithm&gt; contains the guard _ALGORITH=
M, how would you expect the following to behave?</div>
<div>=C2=A0</div>
<div><font face=3D"monospace,monospace">#include &lt;&gt;</font></div>
<div><font face=3D"monospace,monospace"></font>=C2=A0</div>
<div><font face=3D"monospace,monospace">void foo(const std::vector&lt;int&g=
t; &amp;v) {</font></div>
<div><font face=3D"monospace,monospace">#ifndef _ALGORITHM</font></div>
<div><font face=3D"monospace,monospace">=C2=A0 std::for_each(v.begin(), v.e=
nd(), [](int i){std::cout &lt;&lt; i; }</font></div>
<div><font face=3D"monospace,monospace">#endif</font></div>
<div><font face=3D"monospace,monospace">}</font></div>

<p></p>

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

--001a11c204fa12f6560514f02c4c--

.

before complaining and aborting compilation, the compiler would:
1.- lookup for preprocessor symbol _ALGORITHM in some optimized data
base, finding that it is defined in file algorithm
2.- include <algorithm>

I think that algorithm would solve all problems, providing std does
not define the same symbol in different files, which is conflictive.



2015-04-30 14:24 GMT+02:00, Douglas Boffey <douglas.boffey@gmail.com>:
> Assuming the std header <algorithm> contains the guard _ALGORITHM, how
> would you expect the following to behave?
>
> #include <>
>
> void foo(const std::vector<int> &v) {
> #ifndef _ALGORITHM
>   std::for_each(v.begin(), v.end(), [](int i){std::cout << i; }
> #endif
> }
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/mZN8_tvVOeg/=
unsubscribe.
> To unsubscribe from this group and all its topics, 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/.
>


--=20
mm-studios.com
"un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
abonarlos."
follow my tweets at http://twitter.com/mayorga;
Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2

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

.

--001a113f90364080f00514f1365b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

IMHO this is a dead end. Besides the negative feedback with their good
reasons (you didn't answer what about ADL), there is a very clean
separation between preprocessor and compiler, and people (specially the
creator of the language) want to see the former less and less evolved
("abolished" actually said). That's where the modules feature shows up. I
suggest you that if you are concerned about these sort of issues, read all
about moduled first and then ask to join the study group in order to help
there.

My 0.02$


El 30/4/2015 10:28, "Marcos Mayorga" <mayorga.geek@gmail.com> escribi=C3=B3=
:

> before complaining and aborting compilation, the compiler would:
> 1.- lookup for preprocessor symbol _ALGORITHM in some optimized data
> base, finding that it is defined in file algorithm
> 2.- include <algorithm>
>
> I think that algorithm would solve all problems, providing std does
> not define the same symbol in different files, which is conflictive.
>
>
>
> 2015-04-30 14:24 GMT+02:00, Douglas Boffey <douglas.boffey@gmail.com>:
> > Assuming the std header <algorithm> contains the guard _ALGORITHM, how
> > would you expect the following to behave?
> >
> > #include <>
> >
> > void foo(const std::vector<int> &v) {
> > #ifndef _ALGORITHM
> >   std::for_each(v.begin(), v.end(), [](int i){std::cout << i; }
> > #endif
> > }
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to a topic in the
> > Google Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/mZN8_tvVOeg/=
unsubscribe
> .
> > To unsubscribe from this group and all its topics, 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/.
> >
>
>
> --
> mm-studios.com
> "un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
> abonarlos."
> follow my tweets at http://twitter.com/mayorga;
> Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2
>
> --
>
> ---
> 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/.
>

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

--001a113f90364080f00514f1365b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">IMHO this is a dead end. Besides the negative feedback with =
their good reasons (you didn&#39;t answer what about ADL), there is a very =
clean separation between preprocessor and compiler, and people (specially t=
he creator of the language) want to see the former less and less evolved (&=
quot;abolished&quot; actually said). That&#39;s where the modules feature s=
hows up. I suggest you that if you are concerned about these sort of issues=
, read all about moduled first and then ask to join the study group in orde=
r to help there.</p>
<p dir=3D"ltr">My 0.02$</p>
<p dir=3D"ltr">=C2=A0 </p>
<div class=3D"gmail_quote">El 30/4/2015 10:28, &quot;Marcos Mayorga&quot; &=
lt;<a href=3D"mailto:mayorga.geek@gmail.com">mayorga.geek@gmail.com</a>&gt;=
 escribi=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">befo=
re complaining and aborting compilation, the compiler would:<br>
1.- lookup for preprocessor symbol _ALGORITHM in some optimized data<br>
base, finding that it is defined in file algorithm<br>
2.- include &lt;algorithm&gt;<br>
<br>
I think that algorithm would solve all problems, providing std does<br>
not define the same symbol in different files, which is conflictive.<br>
<br>
<br>
<br>
2015-04-30 14:24 GMT+02:00, Douglas Boffey &lt;<a href=3D"mailto:douglas.bo=
ffey@gmail.com">douglas.boffey@gmail.com</a>&gt;:<br>
&gt; Assuming the std header &lt;algorithm&gt; contains the guard _ALGORITH=
M, how<br>
&gt; would you expect the following to behave?<br>
&gt;<br>
&gt; #include &lt;&gt;<br>
&gt;<br>
&gt; void foo(const std::vector&lt;int&gt; &amp;v) {<br>
&gt; #ifndef _ALGORITHM<br>
&gt;=C2=A0 =C2=A0std::for_each(v.begin(), v.end(), [](int i){std::cout &lt;=
&lt; i; }<br>
&gt; #endif<br>
&gt; }<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to a topic in the=
<br>
&gt; Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<b=
r>
&gt; To unsubscribe from this topic, visit<br>
&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposal=
s/mZN8_tvVOeg/unsubscribe" target=3D"_blank">https://groups.google.com/a/is=
ocpp.org/d/topic/std-proposals/mZN8_tvVOeg/unsubscribe</a>.<br>
&gt; To unsubscribe from this group and all its topics, send an email to<br=
>
&gt; <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposal=
s+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-proposal=
s/</a>.<br>
&gt;<br>
<br>
<br>
--<br>
<a href=3D"http://mm-studios.com" target=3D"_blank">mm-studios.com</a><br>
&quot;un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo pued=
o<br>
abonarlos.&quot;<br>
follow my tweets at <a href=3D"http://twitter.com/mayorga" target=3D"_blank=
">http://twitter.com/mayorga</a>;<br>
Marcos Mayorga. 9CEA 212C C9BC A7C1 D417=C2=A0 4B9A 859D FCA1 A159 49E2<br>
<br>
--<br>
<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

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

--001a113f90364080f00514f1365b--

.

On 30 April 2015 at 15:24, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> Assuming the std header <algorithm> contains the guard _ALGORITHM, how wo=
uld
> you expect the following to behave?
>
> #include <>
>
> void foo(const std::vector<int> &v) {
> #ifndef _ALGORITHM
>   std::for_each(v.begin(), v.end(), [](int i){std::cout << i; }
> #endif
> }


Just FYI, that program is ill-formed because it violates [lex.name]/3:
"In addition, some identifiers are reserved for use by C ++
implementations and shall not be used otherwise; no diagnostic is
required.
=E2=80=94 Each identifier that contains a double underscore __ or begins wi=
th
an underscore followed by an
uppercase letter is reserved to the implementation for any use.
=E2=80=94 Each identifier that begins with an underscore is reserved to the
implementation for use as a name in the global namespace."

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

.

This is a multi-part message in MIME format.
--------------030308030705060207070102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 30/04/2015 14:40, Ville Voutilainen wrote:
> On 30 April 2015 at 15:24, Douglas Boffey <douglas.boffey@gmail.com> wrot=
e:
>> Assuming the std header <algorithm> contains the guard _ALGORITHM, how w=
ould
>> you expect the following to behave?
>>
>> #include <>
>>
>> void foo(const std::vector<int> &v) {
>> #ifndef _ALGORITHM
>>    std::for_each(v.begin(), v.end(), [](int i){std::cout << i; }
>> #endif
>> }
>
> Just FYI, that program is ill-formed because it violates [lex.name]/3:
> "In addition, some identifiers are reserved for use by C ++
> implementations and shall not be used otherwise; no diagnostic is
> required.
> =E2=80=94 Each identifier that contains a double underscore __ or begins =
with
> an underscore followed by an
> uppercase letter is reserved to the implementation for any use.
> =E2=80=94 Each identifier that begins with an underscore is reserved to t=
he
> implementation for use as a name in the global namespace."
>
How does that violate [lex.name]? The presupposition is that=20
the implementation /has/ used _ALGORITHM "for any use".=20
We're now checking for that use.

In short, I don't believe checking the value of an=20
implementation-defined macro counts as violating [lex.name];=20
surely the intent is that we shall not /define//mutate such=20
macros?

Tom

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

--------------030308030705060207070102
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 30/04/2015 14:40, Ville Voutilainen
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAFk2RUauXfDaWdkYquJJW2q-1drDXmRmkksPZATBswV15UrZag@mail.gmail.=
com"
      type=3D"cite">
      <pre wrap=3D"">On 30 April 2015 at 15:24, Douglas Boffey <a class=3D"=
moz-txt-link-rfc2396E" href=3D"mailto:douglas.boffey@gmail.com">&lt;douglas=
..boffey@gmail.com&gt;</a> wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Assuming the std header &lt;algorithm&gt; contains t=
he guard _ALGORITHM, how would
you expect the following to behave?

#include &lt;&gt;

void foo(const std::vector&lt;int&gt; &amp;v) {
#ifndef _ALGORITHM
  std::for_each(v.begin(), v.end(), [](int i){std::cout &lt;&lt; i; }
#endif
}
</pre>
      </blockquote>
      <pre wrap=3D"">

Just FYI, that program is ill-formed because it violates [lex.name]/3:
"In addition, some identifiers are reserved for use by C ++
implementations and shall not be used otherwise; no diagnostic is
required.
=E2=80=94 Each identifier that contains a double underscore __ or begins wi=
th
an underscore followed by an
uppercase letter is reserved to the implementation for any use.
=E2=80=94 Each identifier that begins with an underscore is reserved to the
implementation for use as a name in the global namespace."

</pre>
    </blockquote>
    How does that violate [lex.name]? The presupposition is that the
    implementation <i>has</i> used <tt>_ALGORITHM</tt> "for any use".
    We're now checking for that use.<br>
    <br>
    In short, I don't believe checking the value of an
    implementation-defined macro counts as violating [lex.name]; surely
    the intent is that we shall not <i>define</i>/mutate such macros?<br>
    <br>
    Tom<br>
  </body>
</html>

<p></p>

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

--------------030308030705060207070102--

.

On 30 April 2015 at 16:47, Tomalak Geret'kal <tom@kera.name> wrote:
> How does that violate [lex.name]? The presupposition is that the

Because it's using a name that is reserved for an implementation.

> implementation has used _ALGORITHM "for any use". We're now checking for
> that use.

Yes, and standard C++ doesn't allow us to do that.

> In short, I don't believe checking the value of an implementation-defined
> macro counts as violating [lex.name]; surely the intent is that we shall not
> define/mutate such macros?

Surely the intent is that such names are not used for anything in
programs, including
checking whether they are defined or not.

--

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

.

--Apple-Mail=_C8C91A46-5197-4F86-BAEF-C567E917AE29
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9330, at 9:47 PM, Tomalak Geret'kal <tom@kera.na=
me> wrote:
>=20
> How does that violate [lex.name]? The presupposition is that the implemen=
tation has used _ALGORITHM "for any use". We're now checking for that use.

Reservation for any use means not just preprocessor macros, but also as a k=
eyword or anything else. Not only does #ifdef _ALGORITHM not portably check=
 anything, the implementation is free to specify it to wipe your hard drive=
..

There are non-preprocessor ways of checking whether names from a particular=
 header have been defined in std, but the results are unspecified. Any C++ =
header is allowed to include any other C++ header ([res.on.headers] =C2=A71=
7.6.5.2). (C library headers, which work on the global namespace, are not e=
ligible.)

This is a good thing for the proposal. Eventually, since it=E2=80=99s a con=
forming feature, I think we=E2=80=99ll see databases as Marcos describes. E=
ventually the idea can be standardized. It would be better to spell it #inc=
lude <std>, though, and avoid extending the preprocessor.

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

--Apple-Mail=_C8C91A46-5197-4F86-BAEF-C567E917AE29
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9330, at 9:47 PM, Tomalak Geret'kal &lt;<a href=3D"mailto:tom@kera.n=
ame" class=3D"">tom@kera.name</a>&gt; wrote:</div><br class=3D"Apple-interc=
hange-newline"><div class=3D""><span style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rg=
b(255, 255, 255); float: none; display: inline !important;" class=3D"">How =
does that violate [lex.name]? The presupposition is that the implementation=
<span class=3D"Apple-converted-space">&nbsp;</span></span><i style=3D"font-=
family: Helvetica; font-size: 12px; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
 start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color=
: rgb(255, 255, 255);" class=3D"">has</i><span style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background=
-color: rgb(255, 255, 255); float: none; display: inline !important;" class=
=3D""><span class=3D"Apple-converted-space">&nbsp;</span>used<span class=3D=
"Apple-converted-space">&nbsp;</span></span><tt style=3D"font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; line-height: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 2=
55);" class=3D"">_ALGORITHM</tt><span style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
 letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: r=
gb(255, 255, 255); float: none; display: inline !important;" class=3D""><sp=
an class=3D"Apple-converted-space">&nbsp;</span>"for any use". We're now ch=
ecking for that use.</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255,=
 255, 255);" class=3D""></div></blockquote></div><br class=3D""><div class=
=3D"">Reservation for any use means not just preprocessor macros, but also =
as a keyword or anything else. Not only does <font face=3D"Courier" class=
=3D"">#ifdef _ALGORITHM</font>&nbsp;not portably check anything, the implem=
entation is free to specify it to wipe your hard drive.</div><div class=3D"=
"><br class=3D""></div><div class=3D"">There are non-preprocessor ways of c=
hecking whether names from a particular header have been defined in <font f=
ace=3D"Courier" class=3D"">std</font>, but the results are unspecified.&nbs=
p;Any C++ header is allowed to include any other C++ header ([res.on.header=
s] =C2=A717.6.5.2). (C library headers, which work on the global namespace,=
 are not eligible.)</div><div class=3D""><br class=3D""></div><div class=3D=
"">This is a good thing for the proposal. Eventually, since it=E2=80=99s a =
conforming feature, I think we=E2=80=99ll see databases as Marcos describes=
.. Eventually the idea can be standardized. It would be better to spell it <=
font face=3D"Courier" class=3D"">#include &lt;std&gt;</font>, though, and a=
void extending the preprocessor.</div></body></html>

<p></p>

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

--Apple-Mail=_C8C91A46-5197-4F86-BAEF-C567E917AE29--

.

On Monday 27 April 2015 10:34:16 mayorga.geek@gmail.com wrote:
> Hello,
> I propose to find a solution to avoid typing many of: #include
> <any-std-header>

To summarise: please bring this to the Modules discussion. There are more
powerful and more efficient alternatives being discussed there, without a huge
reverse dependency between compiler and preprocessor.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

On 30/04/2015 14:50, Ville Voutilainen wrote:
> On 30 April 2015 at 16:47, Tomalak Geret'kal <tom@kera.name> wrote:
>> implementation has used _ALGORITHM "for any use". We're now checking for
>> that use.
> Yes, and standard C++ doesn't allow us to do that.
> Surely the intent is that such names are not used for anything in
> programs, including
> checking whether they are defined or not.
Consensus on the particular gathering linked below does not
agree with you.

   - http://stackoverflow.com/q/29971760/560648

--

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

.

--Apple-Mail=_7D3BC95E-4964-454C-8238-E7781AD89337
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9301, at 12:24 AM, Tomalak Geret'kal <tom@kera.n=
ame> wrote:
>=20
>> Yes, and standard C++ doesn't allow us to do that.
>> Surely the intent is that such names are not used for anything in
>> programs, including
>> checking whether they are defined or not.
> Consensus on the particular gathering linked below does not agree with yo=
u.
>=20
>  - http://stackoverflow.com/q/29971760/560648

That consensus says, =E2=80=9Cundefined behavior,=E2=80=9D =E2=80=9Cimpleme=
ntation-specific,=E2=80=9D and just as I mentioned:

> The _ALGORITHM identifier could, under the standard, be used as part of a=
 pre-processing step to say "replace this source code with hard drive delet=
ing code". Its existence (prior to pre-processing, or after) could be suffi=
cient to completely change your program behavior.

In other words, observing a header guard within the implementation is not s=
ufficient to use it as in the example. Ville is correct that the example is=
 in error.

If an implementation did document the behavior of the example, future suppo=
rt of that extension would be their problem.

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

--Apple-Mail=_7D3BC95E-4964-454C-8238-E7781AD89337
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9301, at 12:24 AM, Tomalak Geret'kal &lt;<a href=3D"mailto:tom@kera.=
name" class=3D"">tom@kera.name</a>&gt; wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><blockquote type=3D"cite" class=3D"">Yes, a=
nd standard C++ doesn't allow us to do that.<br class=3D"">Surely the inten=
t is that such names are not used for anything in<br class=3D"">programs, i=
ncluding<br class=3D"">checking whether they are defined or not.<br class=
=3D""></blockquote>Consensus on the particular gathering linked below does =
not agree with you.<br class=3D""><br class=3D""> &nbsp;- <a href=3D"http:/=
/stackoverflow.com/q/29971760/560648" class=3D"">http://stackoverflow.com/q=
/29971760/560648</a><br class=3D""></div></blockquote></div><br class=3D"">=
<div class=3D"">That consensus says, =E2=80=9Cundefined behavior,=E2=80=9D =
=E2=80=9Cimplementation-specific,=E2=80=9D and just as I mentioned:</div><d=
iv class=3D""><br class=3D""></div><div class=3D""><blockquote type=3D"cite=
" class=3D"">The <code class=3D"">_ALGORITHM</code> identifier could, under=
 the standard, be=20
used as part of a pre-processing step to say "replace this source code=20
with hard drive deleting code".  Its existence (prior to pre-processing,
 or after) could be sufficient to completely change your program=20
behavior.</blockquote><br class=3D""></div><div class=3D"">In other words, =
observing a header guard within the implementation is not sufficient to use=
 it as in the example. Ville is correct that the example is in error.</div>=
<div class=3D""><br class=3D""></div><div class=3D"">If an implementation d=
id document the behavior of the example, future support of that extension w=
ould be their problem.</div></body></html>

<p></p>

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

--Apple-Mail=_7D3BC95E-4964-454C-8238-E7781AD89337--

.

This is a multi-part message in MIME format.
--------------090607030307010208000802
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 30/04/2015 17:29, David Krauss wrote:
>
>> On 2015=E2=80=9305=E2=80=9301, at 12:24 AM, Tomalak Geret'kal=20
>> <tom@kera.name <mailto:tom@kera.name>> wrote:
>>
>>> Yes, and standard C++ doesn't allow us to do that.
>>> Surely the intent is that such names are not used for=20
>>> anything in
>>> programs, including
>>> checking whether they are defined or not.
>> Consensus on the particular gathering linked below does=20
>> not agree with you.
>>
>>  - http://stackoverflow.com/q/29971760/560648
>
> That consensus says, =E2=80=9Cundefined behavior,=E2=80=9D=20
> =E2=80=9Cimplementation-specific,=E2=80=9D
Right, and neither of those things mean "ill-formed".

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

--------------090607030307010208000802
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 30/04/2015 17:29, David Krauss
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:058D2182-B5D4-456B-B983-71B24E769049@gmail.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
      <br class=3D"">
      <div>
        <blockquote type=3D"cite" class=3D"">
          <div class=3D"">On 2015=E2=80=9305=E2=80=9301, at 12:24 AM, Tomal=
ak Geret'kal
            &lt;<a moz-do-not-send=3D"true" href=3D"mailto:tom@kera.name"
              class=3D"">tom@kera.name</a>&gt; wrote:</div>
          <br class=3D"Apple-interchange-newline">
          <div class=3D"">
            <blockquote type=3D"cite" class=3D"">Yes, and standard C++
              doesn't allow us to do that.<br class=3D"">
              Surely the intent is that such names are not used for
              anything in<br class=3D"">
              programs, including<br class=3D"">
              checking whether they are defined or not.<br class=3D"">
            </blockquote>
            Consensus on the particular gathering linked below does not
            agree with you.<br class=3D"">
            <br class=3D"">
            =C2=A0- <a moz-do-not-send=3D"true"
              href=3D"http://stackoverflow.com/q/29971760/560648" class=3D"=
">http://stackoverflow.com/q/29971760/560648</a><br
              class=3D"">
          </div>
        </blockquote>
      </div>
      <br class=3D"">
      <div class=3D"">That consensus says, =E2=80=9Cundefined behavior,=E2=
=80=9D
        =E2=80=9Cimplementation-specific,=E2=80=9D</div>
    </blockquote>
    Right, and neither of those things mean "ill-formed".
  </body>
</html>

<p></p>

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

--------------090607030307010208000802--

.

--Apple-Mail=_BBAAC29D-E850-4275-B63C-881FCDB79C53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9301, at 12:30 AM, Tomalak Geret'kal <tom@kera.n=
ame> wrote:
>=20
> Right, and neither of those things mean "ill-formed=E2=80=9D.

Ville didn=E2=80=99t say ill-formed. He said the intent of the standard is =
to disallow users from using such an example, as a general rule.

Implementations can specifically define exceptions to the general rule, but=
 that wasn=E2=80=99t given as part of the example.

It=E2=80=99s irrelevant to the proposal, anyway, since as I noted header in=
terdependencies are implementation-specific. An implementation may load the=
 entire =E2=80=9Cdatabase=E2=80=9D at the first standard #include, and it m=
ay define #include <> to refer to a header including some standard header.

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

--Apple-Mail=_BBAAC29D-E850-4275-B63C-881FCDB79C53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9301, at 12:30 AM, Tomalak Geret'kal &lt;<a href=3D"mailto:tom@kera.=
name" class=3D"">tom@kera.name</a>&gt; wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D"">
 =20
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
" class=3D"">
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"">
    <div class=3D"moz-cite-prefix">Right, and neither of those things mean =
"ill-formed=E2=80=9D.</div></div></div></blockquote><br class=3D""></div><d=
iv>Ville didn=E2=80=99t say ill-formed. He said the intent of the standard =
is to disallow users from using such an example, as a general rule.</div><b=
r class=3D""><div class=3D"">Implementations can specifically define except=
ions to the general rule, but that wasn=E2=80=99t given as part of the exam=
ple.</div><div class=3D""><br class=3D""></div><div class=3D"">It=E2=80=99s=
 irrelevant to the proposal, anyway, since as I noted header interdependenc=
ies are implementation-specific. An implementation may load the entire =E2=
=80=9Cdatabase=E2=80=9D at the first standard <font face=3D"Courier" class=
=3D"">#include</font>, and it may define <font face=3D"Courier" class=3D"">=
#include &lt;&gt;</font>&nbsp;to refer to a header including some standard =
header.</div></body></html>

<p></p>

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

--Apple-Mail=_BBAAC29D-E850-4275-B63C-881FCDB79C53--

.

This is a multi-part message in MIME format.
--------------030305070800080007090407
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 30/04/2015 17:36, David Krauss wrote:
>
>> On 2015=E2=80=9305=E2=80=9301, at 12:30 AM, Tomalak Geret'kal=20
>> <tom@kera.name <mailto:tom@kera.name>> wrote:
>>
>> Right, and neither of those things mean "ill-formed=E2=80=9D.
>
> Ville didn=E2=80=99t say ill-formed. He said the intent of the=20
> standard is to disallow users from using such an example,=20
> as a general rule.
David the very first thing Ville said on this subject was:

Just FYI, that program is ill-formed because

That's a direct quote.

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

--------------030305070800080007090407
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 30/04/2015 17:36, David Krauss
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:7A296317-A3A7-427E-A810-86CB5B60D2A6@gmail.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
      <br class=3D"">
      <div>
        <blockquote type=3D"cite" class=3D"">
          <div class=3D"">On 2015=E2=80=9305=E2=80=9301, at 12:30 AM, Tomal=
ak Geret'kal
            &lt;<a moz-do-not-send=3D"true" href=3D"mailto:tom@kera.name"
              class=3D"">tom@kera.name</a>&gt; wrote:</div>
          <br class=3D"Apple-interchange-newline">
          <div class=3D"">
            <meta content=3D"text/html; charset=3Dutf-8"
              http-equiv=3D"Content-Type" class=3D"">
            <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"">
              <div class=3D"moz-cite-prefix">Right, and neither of those
                things mean "ill-formed=E2=80=9D.</div>
            </div>
          </div>
        </blockquote>
        <br class=3D"">
      </div>
      <div>Ville didn=E2=80=99t say ill-formed. He said the intent of the
        standard is to disallow users from using such an example, as a
        general rule.</div>
    </blockquote>
    David the very first thing Ville said on this subject was:<br>
    <pre wrap=3D"">Just FYI, that program is ill-formed because</pre>
    That's a direct quote.<br>
  </body>
</html>

<p></p>

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

--------------030305070800080007090407--

.

> On 2015=E2=80=9305=E2=80=9301, at 12:37 AM, Tomalak Geret'kal <tom@kera.n=
ame> wrote:
>=20
> David the very first thing Ville said on this subject was:
> Just FYI, that program is ill-formed because

Yeah, I scrolled further and noticed that just as the email was sending :P =
..

It=E2=80=99s a diagnosable error but it=E2=80=99s not ill-formed.

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

.

IMHO the discussion should not be cut just for touching the language
roots, i want to think there could be infinite conversation threads,
and can be used for allowing all kind of open discussions, in other
words, just let it die, no need to kill it.

Excuses.
B. R.
M.


2015-04-30 15:38 GMT+02:00, dgutson . <danielgutson@gmail.com>:
> IMHO this is a dead end. Besides the negative feedback with their good
> reasons (you didn't answer what about ADL), there is a very clean
> separation between preprocessor and compiler, and people (specially the
> creator of the language) want to see the former less and less evolved
> ("abolished" actually said). That's where the modules feature shows up. I
> suggest you that if you are concerned about these sort of issues, read al=
l
> about moduled first and then ask to join the study group in order to help
> there.
>
> My 0.02$
>
>
> El 30/4/2015 10:28, "Marcos Mayorga" <mayorga.geek@gmail.com> escribi=C3=
=B3:
>
>> before complaining and aborting compilation, the compiler would:
>> 1.- lookup for preprocessor symbol _ALGORITHM in some optimized data
>> base, finding that it is defined in file algorithm
>> 2.- include <algorithm>
>>
>> I think that algorithm would solve all problems, providing std does
>> not define the same symbol in different files, which is conflictive.
>>
>>
>>
>> 2015-04-30 14:24 GMT+02:00, Douglas Boffey <douglas.boffey@gmail.com>:
>> > Assuming the std header <algorithm> contains the guard _ALGORITHM, how
>> > would you expect the following to behave?
>> >
>> > #include <>
>> >
>> > void foo(const std::vector<int> &v) {
>> > #ifndef _ALGORITHM
>> >   std::for_each(v.begin(), v.end(), [](int i){std::cout << i; }
>> > #endif
>> > }
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this topic, visit
>> >
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/mZN8_tvVOeg=
/unsubscribe
>> .
>> > To unsubscribe from this group and all its topics, 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/.
>> >
>>
>>
>> --
>> mm-studios.com
>> "un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
>> abonarlos."
>> follow my tweets at http://twitter.com/mayorga;
>> Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/mZN8_tvVOeg/=
unsubscribe.
> To unsubscribe from this group and all its topics, 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/.
>


--=20
mm-studios.com
"un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
abonarlos."
follow my tweets at http://twitter.com/mayorga;
Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2

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

.

On Thu, Apr 30, 2015 at 4:34 PM, Marcos Mayorga <mayorga.geek@gmail.com> wr=
ote:
> IMHO the discussion should not be cut just for touching the language
> roots, i want to think there could be infinite conversation threads,

Don't get me wrong. I don't dare to question and propose to change the
"language roots"
whenever an attractive and modern idea arises.
It happens that your idea is (in my opinion) an anachronism in nowadays tre=
nds.
That's why I gave you an advise about modules where (again, in my opinion) =
your
effort will be better used: did you check it?

I stop following this thread. Ran out of time budget for this.

> and can be used for allowing all kind of open discussions, in other
> words, just let it die, no need to kill it.
>
> Excuses.
> B. R.
> M.
>
>
> 2015-04-30 15:38 GMT+02:00, dgutson . <danielgutson@gmail.com>:
>> IMHO this is a dead end. Besides the negative feedback with their good
>> reasons (you didn't answer what about ADL), there is a very clean
>> separation between preprocessor and compiler, and people (specially the
>> creator of the language) want to see the former less and less evolved
>> ("abolished" actually said). That's where the modules feature shows up. =
I
>> suggest you that if you are concerned about these sort of issues, read a=
ll
>> about moduled first and then ask to join the study group in order to hel=
p
>> there.
>>
>> My 0.02$
>>
>>
>> El 30/4/2015 10:28, "Marcos Mayorga" <mayorga.geek@gmail.com> escribi=C3=
=B3:
>>
>>> before complaining and aborting compilation, the compiler would:
>>> 1.- lookup for preprocessor symbol _ALGORITHM in some optimized data
>>> base, finding that it is defined in file algorithm
>>> 2.- include <algorithm>
>>>
>>> I think that algorithm would solve all problems, providing std does
>>> not define the same symbol in different files, which is conflictive.
>>>
>>>
>>>
>>> 2015-04-30 14:24 GMT+02:00, Douglas Boffey <douglas.boffey@gmail.com>:
>>> > Assuming the std header <algorithm> contains the guard _ALGORITHM, ho=
w
>>> > would you expect the following to behave?
>>> >
>>> > #include <>
>>> >
>>> > void foo(const std::vector<int> &v) {
>>> > #ifndef _ALGORITHM
>>> >   std::for_each(v.begin(), v.end(), [](int i){std::cout << i; }
>>> > #endif
>>> > }
>>> >
>>> > --
>>> >
>>> > ---
>>> > You received this message because you are subscribed to a topic in th=
e
>>> > Google Groups "ISO C++ Standard - Future Proposals" group.
>>> > To unsubscribe from this topic, visit
>>> >
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/mZN8_tvVOe=
g/unsubscribe
>>> .
>>> > To unsubscribe from this group and all its topics, 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/.
>>> >
>>>
>>>
>>> --
>>> mm-studios.com
>>> "un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
>>> abonarlos."
>>> follow my tweets at http://twitter.com/mayorga;
>>> Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google Grou=
ps
>>> "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/.
>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/mZN8_tvVOeg=
/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/.
>>
>
>
> --
> mm-studios.com
> "un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
> abonarlos."
> follow my tweets at http://twitter.com/mayorga;
> Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2
>
> --
>
> ---
> 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-propo=
sals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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_682_213009298.1430467318589
Content-Type: multipart/alternative;
 boundary="----=_Part_683_192031937.1430467318589"

------=_Part_683_192031937.1430467318589
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi, sorry for the delay in the answer,
ADL is handled by the compiler by a process named mangling (at least in=20
1998) which generates a unique symbol id. The lookup table would be indexed=
=20
by the mangled name.

I accept there may be hard resolving symbols that require a higher level of=
=20
enginnering to discover which header is required, it could be even=20
impossible, in those cases i am happy the compiler resolve complaining,=20
the optimization I propose would cover the majority of std symbols or a=20
high percentage of cases.

I might be touching a language root, but I valorate that the compiler dont=
=20
require me to type redundant instructions in my sources, like stating=20
std::string and having to include <string>, that's reduntant.

I also want to answer to the claim of cpu consumption, yes, it might=20
consume more cpu but only processing sources with keyword 'import std', or=
=20
whatever it could be.=20

B.R.
Marcos






El martes, 28 de abril de 2015, 16:46:32 (UTC+2), Andrey Semashev escribi=
=C3=B3:
>
> On Tue, Apr 28, 2015 at 4:22 PM, Marcos Mayorga <mayorg...@gmail.com=20
> <javascript:>> wrote:=20
> > Hi,=20
> > Thank you for the replies.=20
> > Let me please say something more in favour of the proposal.=20
> > I defend less work for the programmer, not less work for the compiler.=
=20
> > If the programmer specifies std::string in the code the compiler could=
=20
> > implicitly include <string>, instead of complaining and forcing the=20
> > programmer lose time and focus writing the mandatory header inclusion=
=20
> > line which does not add more value to the code.=20
> > Note that, in practice, this doesn't require to include all std=20
> > library on each compilation job, it just require for the compiler to=20
> > have an internal pre-calculated lookup table (std::symbol,header=20
> > file).=20
>
> What would you do with name clashes and ADL?=20
>
> Ex.1:=20
>
>   using namespace std;=20
>   const char* find(const char*, const char*, char);=20
>
>   template< typename T >=20
>   void foo(T begin, T end)=20
>   {=20
>     T p =3D find(begin, end, 'x'); // includes <algorithm>?=20
>   }=20
>
> Ex.2:=20
>
>   #include <boost/shared_ptr.hpp>=20
>
>   using namespace std;=20
>   using namespace boost;=20
>
>   typedef shared_ptr< int > ptr; // includes <memory>? ambiguous?=20
>
> Ex.3:=20
>
>   std::string a, b;=20
>   swap(a, b); // includes <utility>? why?=20
>

--=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_683_192031937.1430467318589
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi, sorry for the delay in the answer,<br>ADL is handled b=
y the compiler by a process named mangling (at least in 1998) which generat=
es a unique symbol id. The lookup table would be indexed by the mangled nam=
e.<br><br>I accept there may be hard resolving symbols that require a highe=
r level of enginnering to discover which header is required, it could be ev=
en impossible, in those cases i am happy the compiler resolve complaining, =
<br>the optimization I propose would cover the majority of std symbols or a=
 high percentage of cases.<br><br>I might be touching a language root, but =
I valorate that the compiler dont require me to type redundant instructions=
 in my sources, like stating std::string and having to include &lt;string&g=
t;, that's reduntant.<br><br>I also want to answer to the claim of cpu cons=
umption, yes, it might consume more cpu but only processing sources with ke=
yword 'import std', or whatever it could be. <br><br>B.R.<br>Marcos<br><br>=
<br><br><br><br><br>El martes, 28 de abril de 2015, 16:46:32 (UTC+2), Andre=
y Semashev  escribi=C3=B3:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On T=
ue, Apr 28, 2015 at 4:22 PM, Marcos Mayorga &lt;<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"wcJmqoAtyHgJ" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">mayorg...@gmail.com</a>&gt; wrote:
<br>&gt; Hi,
<br>&gt; Thank you for the replies.
<br>&gt; Let me please say something more in favour of the proposal.
<br>&gt; I defend less work for the programmer, not less work for the compi=
ler.
<br>&gt; If the programmer specifies std::string in the code the compiler c=
ould
<br>&gt; implicitly include &lt;string&gt;, instead of complaining and forc=
ing the
<br>&gt; programmer lose time and focus writing the mandatory header inclus=
ion
<br>&gt; line which does not add more value to the code.
<br>&gt; Note that, in practice, this doesn't require to include all std
<br>&gt; library on each compilation job, it just require for the compiler =
to
<br>&gt; have an internal pre-calculated lookup table (std::symbol,header
<br>&gt; file).
<br>
<br>What would you do with name clashes and ADL?
<br>
<br>Ex.1:
<br>
<br>&nbsp; using namespace std;
<br>&nbsp; const char* find(const char*, const char*, char);
<br>
<br>&nbsp; template&lt; typename T &gt;
<br>&nbsp; void foo(T begin, T end)
<br>&nbsp; {
<br>&nbsp; &nbsp; T p =3D find(begin, end, 'x'); // includes &lt;algorithm&=
gt;?
<br>&nbsp; }
<br>
<br>Ex.2:
<br>
<br>&nbsp; #include &lt;boost/shared_ptr.hpp&gt;
<br>
<br>&nbsp; using namespace std;
<br>&nbsp; using namespace boost;
<br>
<br>&nbsp; typedef shared_ptr&lt; int &gt; ptr; // includes &lt;memory&gt;?=
 ambiguous?
<br>
<br>Ex.3:
<br>
<br>&nbsp; std::string a, b;
<br>&nbsp; swap(a, b); // includes &lt;utility&gt;? why?
<br></blockquote></div>

<p></p>

-- <br />
<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 <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 />
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_683_192031937.1430467318589--
------=_Part_682_213009298.1430467318589--

.

------=_Part_760_1014082986.1430467384134
Content-Type: multipart/alternative;
 boundary="----=_Part_761_1262523110.1430467384134"

------=_Part_761_1262523110.1430467384134
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'll read about modules, thank you

El jueves, 30 de abril de 2015, 16:41:15 (UTC+2), Thiago Macieira escribi=
=C3=B3:
>
> On Monday 27 April 2015 10:34:16 mayorg...@gmail.com <javascript:> wrote:=
=20
> > Hello,=20
> > I propose to find a solution to avoid typing many of: #include=20
> > <any-std-header>=20
>
> To summarise: please bring this to the Modules discussion. There are more=
=20
> powerful and more efficient alternatives being discussed there, without a=
=20
> huge=20
> reverse dependency between compiler and preprocessor.=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
>

--=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_761_1262523110.1430467384134
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'll read about modules, thank you<br><br>El jueves, 30 de=
 abril de 2015, 16:41:15 (UTC+2), Thiago Macieira  escribi=C3=B3:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On Monday 27 April 2015 10:34:16 <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"wY33LIRF-1kJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" oncl=
ick=3D"this.href=3D'javascript:';return true;">mayorg...@gmail.com</a> wrot=
e:
<br>&gt; Hello,
<br>&gt; I propose to find a solution to avoid typing many of: #include
<br>&gt; &lt;any-std-header&gt;
<br>
<br>To summarise: please bring this to the Modules discussion. There are mo=
re=20
<br>powerful and more efficient alternatives being discussed there, without=
 a huge=20
<br>reverse dependency between compiler and preprocessor.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div>

<p></p>

-- <br />
<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 <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 />
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_761_1262523110.1430467384134--
------=_Part_760_1014082986.1430467384134--

.

--Apple-Mail=_05B5ACCC-9BFB-43E3-8491-CDEA1D3929C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9301, at 4:01 PM, mayorga.geek@gmail.com wrote:
>=20
> ADL is handled by the compiler by a process named mangling (at least in 1=
998) which generates a unique symbol id. The lookup table would be indexed =
by the mangled name.

You can=E2=80=99t look up a mangled name, and mangling has little to do wit=
h ADL. First ADL finds overloads of a (non-mangled) name, then overload res=
olution picks one, then the ABI maps the overload signature to a string cal=
led a mangled name.


> On 2015=E2=80=9304=E2=80=9328, at 10:46 PM, Andrey Semashev <andrey.semas=
hev@gmail.com> wrote:

>=20

> Ex.1:=20

>=20
>   using namespace std;=20

If you get this far, namespace std already exists, so a standard header has=
 been included, so std::find may (or may not) have been declared.

A program that depends on std::find not existing at this point is unportabl=
e.

>   const char* find(const char*, const char*, char);=20
>=20
>   template< typename T >=20
>   void foo(T begin, T end)=20
>   {=20
>     T p =3D find(begin, end, 'x'); // includes <algorithm>?=20
>   }=20


The using directive is still in effect, so this will call <algorithm> or yo=
ur own function, depending on overloading and unspecified header interdepen=
dencies.

If you don=E2=80=99t want that, don=E2=80=99t do using namespace std!

> Ex.2:=20
>=20
>   #include <boost/shared_ptr.hpp>=20
>=20
>   using namespace std;=20
>   using namespace boost;=20

Seriously??

> Ex.3:=20
>=20
>   std::string a, b;=20
>   swap(a, b); // includes <utility>? why?=20

If you have included <string>, you likely already have all of <utility>.

For the umpteenth time, this is a non-proposal. The functionality can alrea=
dy be provided at implementations=E2=80=99 convenience by =E2=80=9Cpessimiz=
ing=E2=80=9D header dependencies, even without introducing a special header=
, spelled #include <> or otherwise.

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

--Apple-Mail=_05B5ACCC-9BFB-43E3-8491-CDEA1D3929C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9301, at 4:01 PM, <a href=3D"mailto:mayorga.geek@gmail.com" class=3D=
"">mayorga.geek@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-ne=
wline"><div class=3D""><span style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; line-height: normal; orphans: auto; text-align: start; text=
-indent: 0px; text-transform: none; white-space: normal; widows: auto; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline=
 !important;" class=3D"">ADL is handled by the compiler by a process named =
mangling (at least in 1998) which generates a unique symbol id. The lookup =
table would be indexed by the mangled name.</span><br style=3D"font-family:=
 Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" cl=
ass=3D""></div></blockquote></div><br class=3D""><div class=3D"">You can=E2=
=80=99t look up a mangled name, and mangling has little to do with ADL. Fir=
st ADL finds overloads of a (non-mangled) name, then overload resolution pi=
cks one, then the ABI maps the overload signature to a string called a mang=
led name.</div><div class=3D""><br class=3D""></div><div class=3D""><br cla=
ss=3D""></div><div class=3D""><blockquote type=3D"cite" class=3D"">On 2015=
=E2=80=9304=E2=80=9328, at 10:46 PM, Andrey Semashev &lt;<a href=3D"mailto:=
andrey.semashev@gmail.com" class=3D"">andrey.semashev@gmail.com</a>&gt; wro=
te:</blockquote></div><div class=3D""><blockquote type=3D"cite" class=3D"">=
<br class=3D""></blockquote></div><div class=3D""><blockquote type=3D"cite"=
 class=3D"">Ex.1:&nbsp;</blockquote></div><div class=3D""><blockquote type=
=3D"cite" class=3D""><br class=3D"">&nbsp; using namespace std;&nbsp;<br cl=
ass=3D""></blockquote><div class=3D""><br class=3D""></div><div class=3D"">=
If you get this far, <font face=3D"Courier" class=3D"">namespace std</font>=
 already exists, so a standard header has been included, so <font face=3D"C=
ourier" class=3D"">std::find</font> may (or may not) have been declared.</d=
iv><div class=3D""><br class=3D""></div><div class=3D"">A program that depe=
nds on <font face=3D"Courier" class=3D"">std::find</font> not existing at t=
his point is unportable.</div><br class=3D""><blockquote type=3D"cite" clas=
s=3D"">&nbsp; const char* find(const char*, const char*, char);&nbsp;<br cl=
ass=3D""><br class=3D"">&nbsp; template&lt; typename T &gt;&nbsp;<br class=
=3D"">&nbsp; void foo(T begin, T end)&nbsp;<br class=3D"">&nbsp; {&nbsp;<br=
 class=3D"">&nbsp; &nbsp; T p =3D find(begin, end, 'x'); // includes &lt;al=
gorithm&gt;?&nbsp;<br class=3D"">&nbsp; }&nbsp;<br class=3D""></blockquote>=
</div><div class=3D""><br class=3D""></div><div class=3D"">The using direct=
ive is still in effect, so this will call <font face=3D"Courier" class=3D""=
>&lt;algorithm&gt;</font> or your own function, depending on overloading an=
d unspecified header interdependencies.</div><div class=3D""><br class=3D""=
></div><div class=3D"">If you don=E2=80=99t want that, don=E2=80=99t do <fo=
nt face=3D"Courier" class=3D"">using namespace std</font>!</div><div class=
=3D""><br class=3D""></div><div class=3D""><div class=3D""><blockquote type=
=3D"cite" class=3D"">Ex.2:&nbsp;<br class=3D""><br class=3D"">&nbsp; #inclu=
de &lt;boost/shared_ptr.hpp&gt;&nbsp;<br class=3D""><br class=3D"">&nbsp; u=
sing namespace std;&nbsp;<br class=3D"">&nbsp; using namespace boost;&nbsp;=
<br class=3D""></blockquote><div class=3D""><br class=3D""></div><div class=
=3D"">Seriously??</div><br class=3D""><blockquote type=3D"cite" class=3D"">=
Ex.3:&nbsp;<br class=3D""><br class=3D"">&nbsp; std::string a, b;&nbsp;<br =
class=3D"">&nbsp; swap(a, b); // includes &lt;utility&gt;? why?&nbsp;<br cl=
ass=3D""></blockquote><br class=3D""></div><div class=3D"">If you have incl=
uded <font face=3D"Courier" class=3D"">&lt;string&gt;</font>, you likely al=
ready have all of&nbsp;<font face=3D"Courier" class=3D"">&lt;utility&gt;</f=
ont>.</div><div class=3D""><br class=3D""></div><div class=3D"">For the ump=
teenth time, this is a non-proposal. The functionality can already be provi=
ded at implementations=E2=80=99 convenience by =E2=80=9Cpessimizing=E2=80=
=9D header dependencies, even without introducing a special header, spelled=
 <font face=3D"Courier" class=3D"">#include &lt;&gt;</font> or otherwise.</=
div><div class=3D""></div></div></body></html>

<p></p>

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

--Apple-Mail=_05B5ACCC-9BFB-43E3-8491-CDEA1D3929C1--

.

On Friday 01 May 2015 16:17:05 David Krauss wrote:
> > On 2015=E2=80=9304=E2=80=9328, at 10:46 PM, Andrey Semashev <andrey.sem=
ashev@gmail.com>
> > wrote:>=20
> > Ex.1:
> >   using namespace std;
>=20
> If you get this far, namespace std already exists, so a standard header h=
as
> been included, so std::find may (or may not) have been declared.
>=20
> A program that depends on std::find not existing at this point is
> unportable.
> >   const char* find(const char*, const char*, char);
> >  =20
> >   template< typename T >
> >   void foo(T begin, T end)
> >   {
> >  =20
> >     T p =3D find(begin, end, 'x'); // includes <algorithm>?
> >  =20
> >   }
>=20
> The using directive is still in effect, so this will call <algorithm> or
> your own function, depending on overloading and unspecified header
> interdependencies.
>=20
> If you don=E2=80=99t want that, don=E2=80=99t do using namespace std!

That does not answer my question, which is "does this line cause <algorithm=
>=20
inclusion?" Whether or not the code is sane is irrelevant.

> > Ex.2:
> >   #include <boost/shared_ptr.hpp>
> >  =20
> >   using namespace std;
> >   using namespace boost;
>=20
> Seriously??

Yep. You'd be surprised but I've seen real code like that. Admittedly, it w=
as=20
written before std::shared_ptr was introduced.

> > Ex.3:
> >   std::string a, b;
> >   swap(a, b); // includes <utility>? why?
>=20
> If you have included <string>, you likely already have all of <utility>.

Who said that? And again, this does not answer my question.

> For the umpteenth time, this is a non-proposal.

Here we agree.

> The functionality can
> already be provided at implementations=E2=80=99 convenience by =E2=80=9Cp=
essimizing=E2=80=9D header
> dependencies, even without introducing a special header, spelled #include
> <> or otherwise.

No, that's not right. The user cannot rely on the premise that any STL head=
er=20
includes everything. On the contrary, the user must assume that the header=
=20
does not include anything else and only introduces symbols which are descri=
bed=20
in the Standard, in the synopsis section for that header. Personally, I=20
consider it a shortcoming if an implementation declares undocumented (by th=
e=20
Standard) public symbols as a result of including a header.

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

.

On 01/05/2015 09:01, mayorga.geek@gmail.com wrote:
> Hi, sorry for the delay in the answer,
> ADL is handled by the compiler by a process named mangling
Ehm no, I'm afraid not!

--

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

.

--Apple-Mail=_55309123-1630-43AD-95A4-2D17B07DB6B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9301, at 5:06 PM, Andrey Semashev <andrey.semash=
ev@gmail.com> wrote:
>=20
> That does not answer my question, which is "does this line cause <algorit=
hm>=20
> inclusion?" Whether or not the code is sane is irrelevant.

The answer is that it=E2=80=99s unspecified whether <algorithm> was already=
 included earlier.

Lazily reading a standard library database is an implementation model, but =
it says little about behavior. It=E2=80=99s compatible with the current sta=
ndard, so the answer to all these questions is just to refer to C++14.

> Yep. You'd be surprised but I've seen real code like that. Admittedly, it=
 was=20
> written before std::shared_ptr was introduced.

Sure, there=E2=80=99s plenty of code like that, but it=E2=80=99s already br=
oken. Do you want to design a proposal to guarantee when std::shared_ptr is=
 not defined?

>>> Ex.3:
>>>  std::string a, b;
>>>  swap(a, b); // includes <utility>? why?
>>=20
>> If you have included <string>, you likely already have all of <utility>.
>=20
> Who said that? And again, this does not answer my question.

Clang (libc++) includes <utility> from <string>. GCC (libstdc++) does not. =
It=E2=80=99s ambiguous and usually undocumented.

>> The functionality can
>> already be provided at implementations=E2=80=99 convenience by =E2=80=9C=
pessimizing=E2=80=9D header
>> dependencies, even without introducing a special header, spelled #includ=
e
>> <> or otherwise.
>=20
> No, that's not right. The user cannot rely on the premise that any STL he=
ader=20
> includes everything. On the contrary, the user must assume that the heade=
r=20
> does not include anything else and only introduces symbols which are desc=
ribed=20
> in the Standard, in the synopsis section for that header.

I only said the implementation is free to do things either way.

The user cannot rely on the premise that any standard header has *or has no=
t* been included.

> Personally, I=20
> consider it a shortcoming if an implementation declares undocumented (by =
the=20
> Standard) public symbols as a result of including a header.

Yes, for a monolithic standard library, it would improve QOI to track which=
 headers have been included and warn when a missing one is used. Implementi=
ng this as a dedicated feature would improve on the scattershot start of th=
e art.

One day in the distant future, when every implementation has implemented su=
ch a low-overhead monolithic precompiled library and there=E2=80=99s absolu=
tely no advantage to individual headers, we can deprecate all of them. Unti=
l then, no proposal is needed.

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

--Apple-Mail=_55309123-1630-43AD-95A4-2D17B07DB6B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9301, at 5:06 PM, Andrey Semashev &lt;<a href=3D"mailto:andrey.semas=
hev@gmail.com" class=3D"">andrey.semashev@gmail.com</a>&gt; wrote:</div><br=
 class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; float: none; display: inline !important;" class=3D"">That does not answer=
 my question, which is "does this line cause &lt;algorithm&gt;<span class=
=3D"Apple-converted-space">&nbsp;</span></span><br style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px; float: none; display: inline !important;" cla=
ss=3D"">inclusion?" Whether or not the code is sane is irrelevant.</span><b=
r style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px;" class=3D""></div></blockquote><div><br class=3D""></di=
v><div>The answer is that it=E2=80=99s unspecified whether <font face=3D"Co=
urier" class=3D"">&lt;algorithm&gt;</font> was already included earlier.</d=
iv><div><br class=3D""></div><div>Lazily reading a standard library databas=
e is an implementation model, but it says little about behavior. It=E2=80=
=99s compatible with the current standard, so the answer to all these quest=
ions is just to refer to C++14.</div><br class=3D""><blockquote type=3D"cit=
e" class=3D""><div class=3D""><span style=3D"font-family: Helvetica; font-s=
ize: 12px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; line-height: normal; orphans: auto; text-align: star=
t; text-indent: 0px; text-transform: none; white-space: normal; widows: aut=
o; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display:=
 inline !important;" class=3D"">Yep. You'd be surprised but I've seen real =
code like that. Admittedly, it was<span class=3D"Apple-converted-space">&nb=
sp;</span></span><br style=3D"font-family: Helvetica; font-size: 12px; font=
-style: normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; text-indent:=
 0px; text-transform: none; white-space: normal; widows: auto; word-spacing=
: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
float: none; display: inline !important;" class=3D"">written before std::sh=
ared_ptr was introduced.</span><br style=3D"font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant: normal; font-weight: normal; le=
tter-spacing: normal; line-height: normal; orphans: auto; text-align: start=
; text-indent: 0px; text-transform: none; white-space: normal; widows: auto=
; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></bl=
ockquote><div><br class=3D""></div><div>Sure, there=E2=80=99s plenty of cod=
e like that, but it=E2=80=99s already broken. Do you want to design a propo=
sal to guarantee when <font face=3D"Courier" class=3D"">std::shared_ptr</fo=
nt> is not defined?</div><br class=3D""><blockquote type=3D"cite" class=3D"=
"><div class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><=
blockquote type=3D"cite" class=3D"">Ex.3:<br class=3D"">&nbsp;std::string a=
, b;<br class=3D"">&nbsp;swap(a, b); // includes &lt;utility&gt;? why?<br c=
lass=3D""></blockquote><br class=3D"">If you have included &lt;string&gt;, =
you likely already have all of &lt;utility&gt;.<br class=3D""></blockquote>=
<br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; line-heig=
ht: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
 auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; disp=
lay: inline !important;" class=3D"">Who said that? And again, this does not=
 answer my question.</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></blockq=
uote><div><br class=3D""></div><div>Clang (libc++) includes <font face=3D"C=
ourier" class=3D"">&lt;utility&gt;</font> from <font face=3D"Courier" class=
=3D"">&lt;string&gt;</font>. GCC (libstdc++) does not. It=E2=80=99s ambiguo=
us and usually undocumented.</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><blockquote type=3D"cite" style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" cla=
ss=3D"">The functionality can</blockquote><blockquote type=3D"cite" style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D"">already be provided at implementations=E2=80=99 co=
nvenience by =E2=80=9Cpessimizing=E2=80=9D header<br class=3D"">dependencie=
s, even without introducing a special header, spelled #include<br class=3D"=
">&lt;&gt; or otherwise.<br class=3D""></blockquote><br style=3D"font-famil=
y: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fo=
nt-weight: normal; letter-spacing: normal; line-height: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
 normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px; float: none; display: inline !important;=
" class=3D"">No, that's not right. The user cannot rely on the premise that=
 any STL header<span class=3D"Apple-converted-space">&nbsp;</span></span><b=
r style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
 letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; displa=
y: inline !important;" class=3D"">includes everything. On the contrary, the=
 user must assume that the header<span class=3D"Apple-converted-space">&nbs=
p;</span></span><br style=3D"font-family: Helvetica; font-size: 12px; font-=
style: normal; font-variant: normal; font-weight: normal; letter-spacing: n=
ormal; line-height: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; word-spacing:=
 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-famil=
y: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fo=
nt-weight: normal; letter-spacing: normal; line-height: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
 normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; f=
loat: none; display: inline !important;" class=3D"">does not include anythi=
ng else and only introduces symbols which are described<span class=3D"Apple=
-converted-space">&nbsp;</span></span><br style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; line-height: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><sp=
an style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px; float: none; display: inline !important;" class=3D"">i=
n the Standard, in the synopsis section for that header. </span></div></blo=
ckquote><div><br class=3D""></div><div>I only said the implementation is fr=
ee to do things either way.</div><div><br class=3D""></div><div>The user ca=
nnot rely on the premise that any standard header has *<i class=3D"">or has=
 not</i>* been included.</div><br class=3D""><blockquote type=3D"cite" clas=
s=3D""><div class=3D""><span style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; line-height: normal; orphans: auto; text-align: start; text=
-indent: 0px; text-transform: none; white-space: normal; widows: auto; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline=
 !important;" class=3D"">Personally, I<span class=3D"Apple-converted-space"=
>&nbsp;</span></span><br style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; line-height: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; line-height: normal; orphan=
s: auto; text-align: start; text-indent: 0px; text-transform: none; white-s=
pace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px; float: none; display: inline !important;" class=3D"">consider it a shor=
tcoming if an implementation declares undocumented (by the<span class=3D"Ap=
ple-converted-space">&nbsp;</span></span><br style=3D"font-family: Helvetic=
a; font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-al=
ign: start; text-indent: 0px; text-transform: none; white-space: normal; wi=
dows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">=
<span style=3D"font-family: Helvetica; font-size: 12px; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px; float: none; display: inline !important;" class=3D"=
">Standard) public symbols as a result of including a header.</span><br sty=
le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; line-height: nor=
mal; orphans: auto; text-align: start; text-indent: 0px; text-transform: no=
ne; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stro=
ke-width: 0px;" class=3D""></div></blockquote></div><br class=3D""><div cla=
ss=3D"">Yes, for a monolithic standard library, it would improve QOI to tra=
ck which headers have been included and warn when a missing one is used. Im=
plementing this as a dedicated feature would improve on the scattershot sta=
rt of the art.</div><div class=3D""><br class=3D""></div><div class=3D"">On=
e day in the distant future, when every implementation has implemented such=
 a low-overhead monolithic precompiled library and there=E2=80=99s absolute=
ly no advantage to individual headers, we can deprecate all of them. Until =
then, no proposal is needed.</div></body></html>

<p></p>

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

--Apple-Mail=_55309123-1630-43AD-95A4-2D17B07DB6B9--

.

that supports my idea, the std should not require the user to know in
which file a symbol is defined. If it does it is doing wrong from the
very beginning, at that time when the file was more meaningful, i
think new trends are more scoped based, like std:: is. No need to know
the file. I affirm.

2015-05-01 15:11 GMT+02:00, David Krauss <potswa@gmail.com>:
>
>> On 2015=E2=80=9305=E2=80=9301, at 5:06 PM, Andrey Semashev <andrey.semas=
hev@gmail.com>
>> wrote:
>>
>> That does not answer my question, which is "does this line cause
>> <algorithm>
>> inclusion?" Whether or not the code is sane is irrelevant.
>
> The answer is that it=E2=80=99s unspecified whether <algorithm> was alrea=
dy included
> earlier.
>
> Lazily reading a standard library database is an implementation model, bu=
t
> it says little about behavior. It=E2=80=99s compatible with the current s=
tandard, so
> the answer to all these questions is just to refer to C++14.
>
>> Yep. You'd be surprised but I've seen real code like that. Admittedly, i=
t
>> was
>> written before std::shared_ptr was introduced.
>
> Sure, there=E2=80=99s plenty of code like that, but it=E2=80=99s already =
broken. Do you want
> to design a proposal to guarantee when std::shared_ptr is not defined?
>
>>>> Ex.3:
>>>>  std::string a, b;
>>>>  swap(a, b); // includes <utility>? why?
>>>
>>> If you have included <string>, you likely already have all of <utility>=
..
>>
>> Who said that? And again, this does not answer my question.
>
> Clang (libc++) includes <utility> from <string>. GCC (libstdc++) does not=
..
> It=E2=80=99s ambiguous and usually undocumented.
>
>>> The functionality can
>>> already be provided at implementations=E2=80=99 convenience by =E2=80=
=9Cpessimizing=E2=80=9D
>>> header
>>> dependencies, even without introducing a special header, spelled
>>> #include
>>> <> or otherwise.
>>
>> No, that's not right. The user cannot rely on the premise that any STL
>> header
>> includes everything. On the contrary, the user must assume that the head=
er
>>
>> does not include anything else and only introduces symbols which are
>> described
>> in the Standard, in the synopsis section for that header.
>
> I only said the implementation is free to do things either way.
>
> The user cannot rely on the premise that any standard header has *or has
> not* been included.
>
>> Personally, I
>> consider it a shortcoming if an implementation declares undocumented (by
>> the
>> Standard) public symbols as a result of including a header.
>
> Yes, for a monolithic standard library, it would improve QOI to track whi=
ch
> headers have been included and warn when a missing one is used. Implement=
ing
> this as a dedicated feature would improve on the scattershot start of the
> art.
>
> One day in the distant future, when every implementation has implemented
> such a low-overhead monolithic precompiled library and there=E2=80=99s ab=
solutely no
> advantage to individual headers, we can deprecate all of them. Until then=
,
> no proposal is needed.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/mZN8_tvVOeg/=
unsubscribe.
> To unsubscribe from this group and all its topics, 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/.
>


--=20
mm-studios.com
"un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
abonarlos."
follow my tweets at http://twitter.com/mayorga;
Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2

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

.

On Friday 01 May 2015 17:08:23 Marcos Mayorga wrote:
> that supports my idea, the std should not require the user to know in
> which file a symbol is defined. If it does it is doing wrong from the
> very beginning, at that time when the file was more meaningful, i
> think new trends are more scoped based, like std:: is. No need to know
> the file. I affirm.

The premise is right: we should not have required people to know which
#include a given class or function is declared in.

However, that boat sailed a long time ago.

The correct solution is to get rid of #includes as much as possible, and
that's the Modules proposal.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

> On 2015=E2=80=9305=E2=80=9302, at 5:56 AM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>=20
> The premise is right: we should not have required people to know which=20
> #include a given class or function is declared in.
>=20
> However, that boat sailed a long time ago.

That=E2=80=99s backwards. The header-based implementation was the only way =
to do it in the past (up to the present), there=E2=80=99s no sense of =E2=
=80=9Cshould have.=E2=80=9D However, the boat never sailed and there=E2=80=
=99s still room to implement a monolithic library.

One example implementation, not far-out by current methods:

1. Implement a daemon process holding shared memory with a representation o=
f the standard library.
2. If a standard header is #included when a precompiled header would be acc=
eptable, load the library from the daemon as a PCH.
3. Any structures that need to be modified need to be copied into process-l=
ocal memory as compilation proceeds.

This isn=E2=80=99t complete or ideal, but it would be a significant step in=
 the right direction.

> The correct solution is to get rid of #includes as much as possible, and=
=20
> that's the Modules proposal.

There=E2=80=99s a lot of hand-waving around modules and it=E2=80=99s often =
not clear what problem it really solves or how.

As mentioned, any solution requires rearchitecting name lookup. If modules =
requires that the entire standard library be brought into scope at once, th=
en it=E2=80=99s going to be unusably slow until implementations make some m=
ajor evolution.

=E2=80=9CThings with such difficult implementation can=E2=80=99t be legisla=
ted into existence.=E2=80=9D

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

.

On Saturday 02 May 2015 09:30:53 David Krauss wrote:
> > On 2015=E2=80=9305=E2=80=9302, at 5:56 AM, Thiago Macieira <thiago@maci=
eira.org> wrote:
> >=20
> > The premise is right: we should not have required people to know which
> > #include a given class or function is declared in.
> >=20
> > However, that boat sailed a long time ago.
>=20
> That=E2=80=99s backwards. The header-based implementation was the only wa=
y to do it
> in the past (up to the present), there=E2=80=99s no sense of =E2=80=9Csho=
uld have.=E2=80=9D
> However, the boat never sailed and there=E2=80=99s still room to implemen=
t a
> monolithic library.

My point is that, with benefit of hindsight and better understanding of=20
technology, there could have been something different in place of #includes=
..

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

.

--Apple-Mail=_02086184-ABFA-48A6-8A0F-13430D7985FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9302, at 11:15 AM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> My point is that, with benefit of hindsight and better understanding of=
=20
> technology, there could have been something different in place of #includ=
es.

The problems with #include, which are tackled by modules so as to allow the=
 equivalent of multiple precompiled headers, are dependencies on macros and=
 order of inclusion. A header may inspect macros, and macros have unlimited=
 power to change the meaning of subsequent headers. A header may be brittle=
 vis-a-vis the ODR by presuming a name have to have been defined (or not de=
fined) by a preceding inclusion.

These issues are the entire motivation for modules, AFAIK, and without them=
 headers could already be cached. However,

1. The issues don=E2=80=99t apply to the standard library. Any macro interf=
erence leads to UB, aside from NDEBUG. The spec also precludes dependency o=
n order of inclusion. Given modules, the implementation should be free to t=
ranslate standard headers into module importations. Hence, we don=E2=80=99t=
 need module syntax or any normative change.

2. I=E2=80=99ve still yet to see a description of what replaces configurati=
on macros, i.e. how the build environment (or client program) may configure=
 or select a module binary. So I=E2=80=99m not convinced the problem is sol=
ved at all. Is the implementation supposed to hard-code the debug- vs. rele=
ase-mode distinction?

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

--Apple-Mail=_02086184-ABFA-48A6-8A0F-13430D7985FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9302, at 11:15 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago@maci=
eira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D"">My point is that, with benefit of=
 hindsight and better understanding of <br class=3D"">technology, there cou=
ld have been something different in place of #includes.<br class=3D""></div=
></blockquote></div><br class=3D""><div class=3D"">The problems with <font =
face=3D"Courier" class=3D"">#include</font>, which are tackled by modules s=
o as to allow the equivalent of multiple precompiled headers, are dependenc=
ies on macros and order of inclusion. A header may inspect macros, and macr=
os have unlimited power to change the meaning of subsequent headers. A head=
er may be brittle vis-a-vis the ODR by presuming a name have to have been d=
efined (or not defined) by a preceding inclusion.</div><div class=3D""><br =
class=3D""></div><div class=3D"">These issues are the entire motivation for=
 modules, AFAIK, and without them headers could already be cached. However,=
</div><div class=3D""><br class=3D""></div><div class=3D"">1. The issues do=
n=E2=80=99t apply to the standard library. Any macro interference leads to =
UB, aside from <font face=3D"Courier" class=3D"">NDEBUG</font>. The spec al=
so precludes dependency on order of inclusion. Given modules, the implement=
ation should be free to translate standard headers into module importations=
.. Hence, we don=E2=80=99t need module syntax or any normative change.</div>=
<div class=3D""><br class=3D""></div><div class=3D"">2. I=E2=80=99ve still =
yet to see a description of what replaces configuration macros, i.e. how th=
e build environment (or client program) may configure or select a module bi=
nary. So I=E2=80=99m not convinced the problem is solved at all. Is the imp=
lementation supposed to hard-code the debug- vs. release-mode distinction?<=
/div></body></html>

<p></p>

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

--Apple-Mail=_02086184-ABFA-48A6-8A0F-13430D7985FE--

.

------=_Part_861_82627022.1430542198064
Content-Type: multipart/alternative;
 boundary="----=_Part_862_1437922792.1430542198064"

------=_Part_862_1437922792.1430542198064
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, May 1, 2015 at 11:51:14 PM UTC-4, David Krauss wrote:
>
>
> On 2015=E2=80=9305=E2=80=9302, at 11:15 AM, Thiago Macieira <thi...@macie=
ira.org=20
> <javascript:>> wrote:
>
> My point is that, with benefit of hindsight and better understanding of=
=20
> technology, there could have been something different in place of=20
> #includes.
>
>
> The problems with #include, which are tackled by modules so as to allow=
=20
> the equivalent of multiple precompiled headers, are dependencies on macro=
s=20
> and order of inclusion. A header may inspect macros, and macros have=20
> unlimited power to change the meaning of subsequent headers. A header may=
=20
> be brittle vis-a-vis the ODR by presuming a name have to have been define=
d=20
> (or not defined) by a preceding inclusion.
>
> These issues are the entire motivation for modules, AFAIK, and without=20
> them headers could already be cached.
>

Modules to me are first and foremost about improving build times. Oh sure,=
=20
it certainly fixes those issues. But it fixes them as a consequence of=20
fixing the problem of having to compile too much stuff.

When you #include something, you're telling the compiler to copy-and-paste=
=20
a bunch of text into your .cpp file. Which means that a simple, 4-line=20
Hello World program that #includes <iostream> is really several thousand=20
lines long.

Modules fix that by being able to import symbols, fully compiled, directly=
=20
into the system. So the compiler can just load a binary blob into memory,=
=20
do some pointer fixup, and have working <iostream> stuff. It's much faster=
=20
than parsing through thousands of lines of C++, just to get to the 4 lines=
=20
that actually matter.

Every other advantage of modules is based on the elimination of this=20
needless parsing step. ODR is fixed, since the previous compilation of a=20
header/source is available, not as text, but as a fully-formed set of=20
symbols, which can only be modified by the second phase of two-phase-lookup=
=20
template instantiation. Order of inclusion is fixed for the same reason.

But to me, the foundation of the modules feature is gaining compile time=20
performance by not compiling thousands of lines of C++ text just to get to=
=20
your real code. The rest is a natural outgrowth of that.

Oh, and FYI: the current modules proposal doesn't solve macro issues.=20
Modules can't really handle macros, since they happen at a different phase=
=20
of text processing. So, if you want to write a macro library, you still=20
will need to "export" the macro interface of it as one or more headers that=
=20
have to be included.

What modules do resolve is the possibility of macro *conflicts* between=20
separate modules (that don't have macros as part of their interface). Which=
=20
is wonderful.
=20

> However,
>
> 1. The issues don=E2=80=99t apply to the standard library. Any macro inte=
rference=20
> leads to UB, aside from NDEBUG. The spec also precludes dependency on=20
> order of inclusion. Given modules, the implementation should be free to=
=20
> translate standard headers into module importations. Hence, we don=E2=80=
=99t need=20
> module syntax or any normative change.
>

Let's assume this is true for the moment.

What good is that, exactly? OK, so you solve the various problems for the=
=20
standard library. Boost is by far huger than any standard library=20
implementation. But since it doesn't use magic internal macro stuff, Boost=
=20
gains absolutely nothing by doing this. So you have all of the positive=20
effects of modules, but only for the standard library.

Why would you prefer the special-case solution to one that gives you the=20
exact same advantages, yet works everywhere, for all libraries equally? We=
=20
are talking about a feature that will immediately become redundant once=20
modules come out.

Do you think you'll get it sooner than modules?

Also, it should be noted that, with modules... you can still have headers.=
=20
And the standard library certainly will; the standards committee does not=
=20
expect everyone to instantly replace `#include <vector>` with `import=20
std.vector`. For compilers that implement modules, the <vector> header file=
=20
will likely be a single `import std.vector` statement.

2. I=E2=80=99ve still yet to see a description of what replaces configurati=
on=20
> macros, i.e. how the build environment (or client program) may configure =
or=20
> select a module binary. So I=E2=80=99m not convinced the problem is solve=
d at all.=20
> Is the implementation supposed to hard-code the debug- vs. release-mode=
=20
> distinction?
>

If you're talking about with modules, nothing changes with regard to=20
configuration macros.

The way module-based builds work with configurations is basically the way=
=20
builds worked without them. At least, for configuration macros that can=20
break ODR.

Module files are a lot like object files. You rebuild them when either the=
=20
source they're dependent on changes or when the build configuration=20
settings change. This happens automatically due to your build tool. Module=
=20
files, like object files, are built from source code.

You can pass module files around like .lib/.a files. However, just as with=
=20
any form of static linking, it's up to the user to make sure that the=20
project linking to the static library uses the same build settings that the=
=20
modules/.lib/.a files were built with. Otherwise, bad things can happen.

Again, this is just as true pre-modules. You'll get ODR breakages if you=20
build your library using debugging STL, while you link it to code compiled=
=20
with release STL. Modules don't affect this one way or the other.

--=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_862_1437922792.1430542198064
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, May 1, 2015 at 11:51:14 PM UTC-4, David Krauss =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:=
break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9305=E2=
=80=9302, at 11:15 AM, Thiago Macieira &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"Bzjf8mxxHpQJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">thi...@macieira.org</a>&gt; wrote:</div><br><div>My=
 point is that, with benefit of hindsight and better understanding of <br>t=
echnology, there could have been something different in place of #includes.=
<br></div></blockquote></div><br><div>The problems with <font face=3D"Couri=
er">#include</font>, which are tackled by modules so as to allow the equiva=
lent of multiple precompiled headers, are dependencies on macros and order =
of inclusion. A header may inspect macros, and macros have unlimited power =
to change the meaning of subsequent headers. A header may be brittle vis-a-=
vis the ODR by presuming a name have to have been defined (or not defined) =
by a preceding inclusion.</div><div><br></div><div>These issues are the ent=
ire motivation for modules, AFAIK, and without them headers could already b=
e cached.</div></div></blockquote><div><br>Modules to me are first and fore=
most about improving build times. Oh sure, it certainly fixes those issues.=
 But it fixes them as a consequence of fixing the problem of having to comp=
ile too much stuff.<br><br>When you #include something, you're telling the =
compiler to copy-and-paste a bunch of text into your .cpp file. Which means=
 that a simple, 4-line Hello World program that #includes &lt;iostream&gt; =
is really several thousand lines long.<br><br>Modules fix that by being abl=
e to import symbols, fully compiled, directly into the system. So the compi=
ler can just load a binary blob into memory, do some pointer fixup, and hav=
e working &lt;iostream&gt; stuff. It's much faster than parsing through tho=
usands of lines of C++, just to get to the 4 lines that actually matter.<br=
><br>Every other advantage of modules is based on the elimination of this n=
eedless parsing step. ODR is fixed, since the previous compilation of a hea=
der/source is available, not as text, but as a fully-formed set of symbols,=
 which can only be modified by the second phase of two-phase-lookup templat=
e instantiation. Order of inclusion is fixed for the same reason.<br><br>Bu=
t to me, the foundation of the modules feature is gaining compile time perf=
ormance by not compiling thousands of lines of C++ text just to get to your=
 real code. The rest is a natural outgrowth of that.<br><br>Oh, and FYI: th=
e current modules proposal doesn't solve macro issues. Modules can't really=
 handle macros, since they happen at a different phase of text processing. =
So, if you want to write a macro library, you still will need to "export" t=
he macro interface of it as one or more headers that have to be included.<b=
r><br>What modules do resolve is the possibility of macro <i>conflicts</i> =
between separate modules (that don't have macros as part of their interface=
). Which is wonderful.<br>&nbsp;</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><div> However,</div><div><br></=
div><div>1. The issues don=E2=80=99t apply to the standard library. Any mac=
ro interference leads to UB, aside from <font face=3D"Courier">NDEBUG</font=
>. The spec also precludes dependency on order of inclusion. Given modules,=
 the implementation should be free to translate standard headers into modul=
e importations. Hence, we don=E2=80=99t need module syntax or any normative=
 change.</div></div></blockquote><div><br>Let's assume this is true for the=
 moment.<br><br>What good is that, exactly? OK, so you solve the various pr=
oblems for the standard library. Boost is by far huger than any standard li=
brary implementation. But since it doesn't use magic internal macro stuff, =
Boost gains absolutely nothing by doing this. So you have all of the positi=
ve effects of modules, but only for the standard library.<br><br>Why would =
you prefer the special-case solution to one that gives you the exact same a=
dvantages, yet works everywhere, for all libraries equally? We are talking =
about a feature that will immediately become redundant once modules come ou=
t.<br><br>Do you think you'll get it sooner than modules?<br><br>Also, it s=
hould be noted that, with modules... you can still have headers. And the st=
andard library certainly will; the standards committee does not expect ever=
yone to instantly replace `#include &lt;vector&gt;` with `import std.vector=
`. For compilers that implement modules, the &lt;vector&gt; header file wil=
l likely be a single `import std.vector` statement.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div=
></div><div>2. I=E2=80=99ve still yet to see a description of what replaces=
 configuration macros, i.e. how the build environment (or client program) m=
ay configure or select a module binary. So I=E2=80=99m not convinced the pr=
oblem is solved at all. Is the implementation supposed to hard-code the deb=
ug- vs. release-mode distinction?</div></div></blockquote><div><br>If you'r=
e talking about with modules, nothing changes with regard to configuration =
macros.<br><br>The way module-based builds work with configurations is basi=
cally the way builds worked without them. At least, for configuration macro=
s that can break ODR.<br><br>Module files are a lot like object files. You =
rebuild them when either the source they're dependent on changes or when th=
e build configuration settings change. This happens automatically due to yo=
ur build tool. Module files, like object files, are built from source code.=
<br><br>You can pass module files around like .lib/.a files. However, just =
as with any form of static linking, it's up to the user to make sure that t=
he project linking to the static library uses the same build settings that =
the modules/.lib/.a files were built with. Otherwise, bad things can happen=
..<br><br>Again, this is just as true pre-modules. You'll get ODR breakages =
if you build your library using debugging STL, while you link it to code co=
mpiled with release STL. Modules don't affect this one way or the other.<br=
></div></div>

<p></p>

-- <br />
<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 <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 />
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_862_1437922792.1430542198064--
------=_Part_861_82627022.1430542198064--

.

--Apple-Mail=_065195FF-336F-4541-8A55-18C97DCDC148
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9302, at 12:49 PM, Nicol Bolas <jmckesson@gmail.=
com> wrote:
>=20
> On Friday, May 1, 2015 at 11:51:14 PM UTC-4, David Krauss wrote:
>=20
> These issues are the entire motivation for modules, AFAIK, and without th=
em headers could already be cached.
>=20
> Modules to me are first and foremost about improving build times. Oh sure=
, it certainly fixes those issues. But it fixes them as a consequence of fi=
xing the problem of having to compile too much stuff.

Yes, this is what I meant by =E2=80=9Ccaching headers.=E2=80=9D

> When you #include something, you're telling the compiler to copy-and-past=
e a bunch of text into your .cpp file. Which means that a simple, 4-line He=
llo World program that #includes <iostream> is really several thousand line=
s long.

The compiler can do anything with the same ultimate effect. The only hitche=
s are the several things I mentioned.

> Modules fix that by being able to import symbols, fully compiled, directl=
y into the system. So the compiler can just load a binary blob into memory,=
 do some pointer fixup, and have working <iostream> stuff. It's much faster=
 than parsing through thousands of lines of C++, just to get to the 4 lines=
 that actually matter.

As I said, loading a module would be a valid implementation of #include <io=
stream>, so we don=E2=80=99t actually need standard modules to deliver this=
 to users today. (I=E2=80=99ve never debated this point before, so it would=
 be interesting to hear any agreement or counterargument.)

> Every other advantage of modules is based on the elimination of this need=
less parsing step. ODR is fixed, since the previous compilation of a header=
/source is available, not as text, but as a fully-formed set of symbols, wh=
ich can only be modified by the second phase of two-phase-lookup template i=
nstantiation. Order of inclusion is fixed for the same reason.

The ODR isn=E2=80=99t defective and the modules proposal only contains mino=
r tweaks. What you mean is that it gets harder to violate the ODR.

However, ODR violations are effectively UB. Headers that violate the ODR, d=
ue to ordering dependencies or otherwise, could already be safely cached un=
der the guise of UB.

The problem with caching classic headers is that one program can generate t=
he cache in one context, and the ODR doesn=E2=80=99t apply when a second pr=
ogram uses it in a different context. The context in which a module file is=
 built is definitive. Most libraries don=E2=80=99t intend to depend on such=
 context, though, and certainly not the standard library.

> What modules do resolve is the possibility of macro conflicts between sep=
arate modules (that don't have macros as part of their interface). Which is=
 wonderful.

Right. It would just be nice to have it both ways, and see the likes of NDE=
BUG supported without implementation-specific magic.

> 1. The issues don=E2=80=99t apply to the standard library. Any macro inte=
rference leads to UB, aside from NDEBUG. The spec also precludes dependency=
 on order of inclusion. Given modules, the implementation should be free to=
 translate standard headers into module importations. Hence, we don=E2=80=
=99t need module syntax or any normative change.
>=20
> Let's assume this is true for the moment.
>=20
> What good is that, exactly? OK, so you solve the various problems for the=
 standard library. Boost is by far huger than any standard library implemen=
tation. But since it doesn't use magic internal macro stuff, Boost gains ab=
solutely nothing by doing this. So you have all of the positive effects of =
modules, but only for the standard library.

This discussion thread is about the standard library. My points here are li=
mited to that scope.

Yes, the whole problem including third-party libraries is more general. I=
=E2=80=99m not arguing against modules.

> Why would you prefer the special-case solution to one that gives you the =
exact same advantages, yet works everywhere, for all libraries equally? We =
are talking about a feature that will immediately become redundant once mod=
ules come out.

Not really, the above paragraph is talking about something that can be depl=
oyed in standard-conforming implementations when the modules TS isn=E2=80=
=99t enabled =E2=80=94 when modules exist in the toolchain but module and i=
mport keywords are disabled by default.

> Also, it should be noted that, with modules... you can still have headers=
.. And the standard library certainly will; the standards committee does not=
 expect everyone to instantly replace `#include <vector>` with `import std.=
vector`. For compilers that implement modules, the <vector> header file wil=
l likely be a single `import std.vector` statement.

Yep, that=E2=80=99s my point. Except it will probably look more literally l=
ike =E2=80=9C__import std.vector;.=E2=80=9D

> If you're talking about with modules, nothing changes with regard to conf=
iguration macros.
>=20
> The way module-based builds work with configurations is basically the way=
 builds worked without them. At least, for configuration macros that can br=
eak ODR.
>=20
> Module files are a lot like object files. You rebuild them when either th=
e source they're dependent on changes or when the build configuration setti=
ngs change. This happens automatically due to your build tool. Module files=
, like object files, are built from source code.

Right. It=E2=80=99s not exactly zero change because a build system using mo=
dules needs to define where it will put the module files. =E2=80=9CAutomati=
cally=E2=80=9D applies per project, once the build system has provided a ma=
pping of configurations to filesystem locations.

This is still short of the Platonic ideal, which would have a system-wide c=
ache across all projects and transparent optimization of builds. Personally=
, I get the sense that modules leave something on the table because librari=
es can=E2=80=99t explicitly declare what aspects of the build environment a=
re relevant, which could then be used as cache keys. Given such a list of s=
ensitivities, the system could internalize all module files. Letting any de=
pendency outside the list be NDR (UB), we could have pure classic header ca=
ching without modules. Given automatic detection of sensitivities, we could=
 have everything at no user effort. The purpose of modules is to sidestep t=
hat very difficult approach, but I still wonder if it will happen eventuall=
y anyway. The future does contain a lot of time, and there are other advant=
ages to a database-like approach.

Closer to the present, it will be inconvenient to have module files for the=
 standard library or Boost in every project, so I think we=E2=80=99ll see s=
ome evolution of library-distribution and build-mastering practice.

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

--Apple-Mail=_065195FF-336F-4541-8A55-18C97DCDC148
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9302, at 12:49 PM, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail=
..com" class=3D"">jmckesson@gmail.com</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Friday=
, May 1, 2015 at 11:51:14 PM UTC-4, David Krauss wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div style=3D"word-wrap:break-word" class=3D""><br=
 class=3D""><div class=3D"">These issues are the entire motivation for modu=
les, AFAIK, and without them headers could already be cached.</div></div></=
blockquote><div class=3D""><br class=3D"">Modules to me are first and forem=
ost about improving build times. Oh sure, it certainly fixes those issues. =
But it fixes them as a consequence of fixing the problem of having to compi=
le too much stuff.<br class=3D""></div></div></div></blockquote><div><br cl=
ass=3D""></div><div>Yes, this is what I meant by =E2=80=9Ccaching headers.=
=E2=80=9D</div><br class=3D""><blockquote type=3D"cite" class=3D""><div cla=
ss=3D""><div dir=3D"ltr" class=3D""><div class=3D"">When you #include somet=
hing, you're telling the compiler to copy-and-paste a bunch of text into yo=
ur .cpp file. Which means that a simple, 4-line Hello World program that #i=
ncludes &lt;iostream&gt; is really several thousand lines long.<br class=3D=
""></div></div></div></blockquote><div><br class=3D""></div><div>The compil=
er can do anything with the same ultimate effect. The only hitches are the =
several things I mentioned.</div><div><br class=3D""></div><blockquote type=
=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=
=3D"">Modules fix that by being able to import symbols, fully compiled, dir=
ectly into the system. So the compiler can just load a binary blob into mem=
ory, do some pointer fixup, and have working &lt;iostream&gt; stuff. It's m=
uch faster than parsing through thousands of lines of C++, just to get to t=
he 4 lines that actually matter.<br class=3D""></div></div></div></blockquo=
te><div><br class=3D""></div><div>As I said, loading a module would be a va=
lid implementation of <font face=3D"Courier" class=3D"">#include &lt;iostre=
am&gt;</font>, so we don=E2=80=99t actually need standard modules to delive=
r this to users today. (I=E2=80=99ve never debated this point before, so it=
 would be interesting to hear any agreement or counterargument.)</div><br c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"=
ltr" class=3D""><div class=3D"">Every other advantage of modules is based o=
n the elimination of this needless parsing step. ODR is fixed, since the pr=
evious compilation of a header/source is available, not as text, but as a f=
ully-formed set of symbols, which can only be modified by the second phase =
of two-phase-lookup template instantiation. Order of inclusion is fixed for=
 the same reason.<br class=3D""></div></div></div></blockquote><div><br cla=
ss=3D""></div><div>The ODR isn=E2=80=99t defective and the modules proposal=
 only contains minor tweaks. What you mean is that it gets harder to violat=
e the ODR.</div><div><br class=3D""></div><div>However, ODR violations are =
effectively UB. Headers that violate the ODR, due to ordering dependencies =
or otherwise, could already be safely cached under the guise of UB.</div><d=
iv><br class=3D""></div><div>The problem with caching classic headers is th=
at one program can generate the cache in one context, and the ODR doesn=E2=
=80=99t apply when a second program uses it in a different context. The con=
text in which a module file is built is definitive. Most libraries don=E2=
=80=99t intend to depend on such context, though, and certainly not the sta=
ndard library.</div><br class=3D""><blockquote type=3D"cite" class=3D""><di=
v class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">What modules do re=
solve is the possibility of macro <i class=3D"">conflicts</i> between separ=
ate modules (that don't have macros as part of their interface). Which is w=
onderful.<br class=3D""></div></div></div></blockquote><div><br class=3D"">=
</div>Right. It would just be nice to have it both ways, and see the likes =
of <font face=3D"Courier" class=3D"">NDEBUG</font> supported without implem=
entation-specific magic.<br class=3D""><br class=3D""><blockquote type=3D"c=
ite" class=3D""><div dir=3D"ltr" class=3D""><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div style=3D"word-wrap:break-word" class=3D""><div class=3D"=
">1. The issues don=E2=80=99t apply to the standard library. Any macro inte=
rference leads to UB, aside from <font face=3D"Courier" class=3D"">NDEBUG</=
font>. The spec also precludes dependency on order of inclusion. Given modu=
les, the implementation should be free to translate standard headers into m=
odule importations. Hence, we don=E2=80=99t need module syntax or any norma=
tive change.</div></div></blockquote><div class=3D""><br class=3D"">Let's a=
ssume this is true for the moment.<br class=3D""><br class=3D"">What good i=
s that, exactly? OK, so you solve the various problems for the standard lib=
rary. Boost is by far huger than any standard library implementation. But s=
ince it doesn't use magic internal macro stuff, Boost gains absolutely noth=
ing by doing this. So you have all of the positive effects of modules, but =
only for the standard library.<br class=3D""></div></div></blockquote><div>=
<br class=3D""></div><div>This discussion thread is about the standard libr=
ary. My points here are limited to that scope.</div><div><br class=3D""></d=
iv><div>Yes, the whole problem including third-party libraries is more gene=
ral. I=E2=80=99m not arguing against modules.</div><br class=3D""><blockquo=
te type=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Why=
 would you prefer the special-case solution to one that gives you the exact=
 same advantages, yet works everywhere, for all libraries equally? We are t=
alking about a feature that will immediately become redundant once modules =
come out.<br class=3D""></div></div></blockquote><div><br class=3D""></div>=
<div>Not really, the above paragraph is talking about something that can be=
 deployed in standard-conforming implementations when the modules TS isn=E2=
=80=99t enabled =E2=80=94 when modules exist in the toolchain but <font fac=
e=3D"Courier" class=3D"">module</font> and <font face=3D"Courier" class=3D"=
">import</font> keywords are disabled by default.</div><br class=3D""><bloc=
kquote type=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div class=3D""=
>Also, it should be noted that, with modules... you can still have headers.=
 And the standard library certainly will; the standards committee does not =
expect everyone to instantly replace `#include &lt;vector&gt;` with `import=
 std.vector`. For compilers that implement modules, the &lt;vector&gt; head=
er file will likely be a single `import std.vector` statement.<br class=3D"=
"></div></div></blockquote><div><br class=3D""></div><div>Yep, that=E2=80=
=99s my point. Except it will probably look more literally like =E2=80=9C<f=
ont face=3D"Courier" class=3D"">__import std.vector;</font>.=E2=80=9D</div>=
<div><br class=3D""></div><blockquote type=3D"cite" class=3D""><div dir=3D"=
ltr" class=3D""><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"=
word-wrap:break-word" class=3D""><div class=3D""></div></div></blockquote><=
div class=3D"">If you're talking about with modules, nothing changes with r=
egard to configuration macros.<br class=3D""><br class=3D"">The way module-=
based builds work with configurations is basically the way builds worked wi=
thout them. At least, for configuration macros that can break ODR.<br class=
=3D""><br class=3D"">Module files are a lot like object files. You rebuild =
them when either the source they're dependent on changes or when the build =
configuration settings change. This happens automatically due to your build=
 tool. Module files, like object files, are built from source code.<br clas=
s=3D""></div></div></blockquote><div><br class=3D""></div><div>Right. It=E2=
=80=99s not exactly zero change because a build system using modules needs =
to define where it will put the module files. =E2=80=9CAutomatically=E2=80=
=9D applies per project, once the build system has provided a mapping of co=
nfigurations to filesystem locations.</div><div><br class=3D""></div><div>T=
his is still short of the Platonic ideal, which would have a system-wide ca=
che across all projects and transparent optimization of builds. Personally,=
 I get the sense that modules leave something on the table because librarie=
s can=E2=80=99t explicitly declare what aspects of the build environment ar=
e relevant, which could then be used as cache keys. Given such a list of se=
nsitivities, the system could internalize all module files. Letting any dep=
endency outside the list be NDR (UB), we could have pure classic header cac=
hing without modules. Given automatic detection of sensitivities, we could =
have everything at no user effort. The purpose of modules is to sidestep th=
at very difficult approach, but I still wonder if it will happen eventually=
 anyway. The future does contain a lot of time, and there are other advanta=
ges to a database-like approach.</div><div><br class=3D""></div><div>Closer=
 to the present, it will be inconvenient to have module files for the stand=
ard library or Boost in every project, so I think we=E2=80=99ll see some ev=
olution of library-distribution and build-mastering practice.</div></div></=
body></html>

<p></p>

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

--Apple-Mail=_065195FF-336F-4541-8A55-18C97DCDC148--

.

--001a1133c77477f5100515478a7f
Content-Type: text/plain; charset=UTF-8

"Those who study history believe we are condemned to repeat it."

Back in the day, Ada programming systems were assumed to come with a
"program library", some form of binary representation of modules, so that
when you said "with Name;" the system could look up the already-compiled
Name package and import its symbols, or perhaps cause "Name" to be compiled
in order to do so.  This resulted in notoriety for "recompile the world"
problems, not to mention slow and buggy program library implementations.
Along came Dewar and GNAT, and they dispensed with the notion of compiled
program libraries, choosing to read the source of the package
specifications whenever they encountered a "with" package inclusion.  This
resulted in much faster and more reliable Ada compilation.

Knowing this, I'm afraid C++ modules will head down the same path.

--

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

--001a1133c77477f5100515478a7f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>&quot;Those who study history believe we are condemned=
 to repeat it.&quot;<br><br>Back in the day, Ada programming systems were a=
ssumed to come with a &quot;program library&quot;, some form of binary repr=
esentation of modules, so that when you said &quot;with Name;&quot; the sys=
tem could look up the already-compiled Name package and import its symbols,=
 or perhaps cause &quot;Name&quot; to be compiled in order to do so.=C2=A0 =
This resulted in notoriety for &quot;recompile the world&quot; problems, no=
t to mention slow and buggy program library implementations.=C2=A0 Along ca=
me Dewar and GNAT, and they dispensed with the notion of compiled program l=
ibraries, choosing to read the source of the package specifications wheneve=
r they encountered a &quot;with&quot; package inclusion.=C2=A0 This resulte=
d in much faster and more reliable Ada compilation.<div><br></div><div>Know=
ing this, I&#39;m afraid C++ modules will head down the same path.</div></d=
iv>

<p></p>

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

--001a1133c77477f5100515478a7f--

.

------=_Part_4035_1189284399.1430773435474
Content-Type: multipart/alternative;
 boundary="----=_Part_4036_1672591364.1430773435475"

------=_Part_4036_1672591364.1430773435475
Content-Type: text/plain; charset=UTF-8

IIRC modules of Pascal language use to be lot of faster (in compilation)
than C/C++ code. I don't know if this is still true but I could be good use
case to look at.

On Monday, May 4, 2015 at 10:38:15 PM UTC+2, Hyman Rosen wrote:
>
>
> "Those who study history believe we are condemned to repeat it."
>
> Back in the day, Ada programming systems were assumed to come with a
> "program library", some form of binary representation of modules, so that
> when you said "with Name;" the system could look up the already-compiled
> Name package and import its symbols, or perhaps cause "Name" to be compiled
> in order to do so.  This resulted in notoriety for "recompile the world"
> problems, not to mention slow and buggy program library implementations.
> Along came Dewar and GNAT, and they dispensed with the notion of compiled
> program libraries, choosing to read the source of the package
> specifications whenever they encountered a "with" package inclusion.  This
> resulted in much faster and more reliable Ada compilation.
>
> Knowing this, I'm afraid C++ modules will head down the same path.
>

--

---
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_4036_1672591364.1430773435475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">IIRC modules of Pascal language use to be lot of faster (i=
n compilation) than C/C++ code. I don't know if this is still true but I co=
uld be good use case to look at.<br><br>On Monday, May 4, 2015 at 10:38:15 =
PM UTC+2, Hyman Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><br>"Those who study history believe we are condemned to rep=
eat it."<br><br>Back in the day, Ada programming systems were assumed to co=
me with a "program library", some form of binary representation of modules,=
 so that when you said "with Name;" the system could look up the already-co=
mpiled Name package and import its symbols, or perhaps cause "Name" to be c=
ompiled in order to do so.&nbsp; This resulted in notoriety for "recompile =
the world" problems, not to mention slow and buggy program library implemen=
tations.&nbsp; Along came Dewar and GNAT, and they dispensed with the notio=
n of compiled program libraries, choosing to read the source of the package=
 specifications whenever they encountered a "with" package inclusion.&nbsp;=
 This resulted in much faster and more reliable Ada compilation.<div><br></=
div><div>Knowing this, I'm afraid C++ modules will head down the same path.=
</div></div>
</blockquote></div>

<p></p>

-- <br />
<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 <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 />
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_4036_1672591364.1430773435475--
------=_Part_4035_1189284399.1430773435474--

.

------=_Part_4184_2109868633.1430787745276
Content-Type: multipart/alternative;
 boundary="----=_Part_4185_1312135567.1430787745276"

------=_Part_4185_1312135567.1430787745276
Content-Type: text/plain; charset=UTF-8



On Monday, May 4, 2015 at 4:38:15 PM UTC-4, Hyman Rosen wrote:
>
>
> "Those who study history believe we are condemned to repeat it."
>
> Back in the day, Ada programming systems were assumed to come with a
> "program library", some form of binary representation of modules, so that
> when you said "with Name;" the system could look up the already-compiled
> Name package and import its symbols, or perhaps cause "Name" to be compiled
> in order to do so.  This resulted in notoriety for "recompile the world"
> problems, not to mention slow and buggy program library implementations.
>

I'm not sure how either of those is a necessary result of C++ modules
(granted, I'm not sure how that would be a necessary result of ADA modules
either, but I know nothing about that language or its build environment).
After all, at its core, modules are little more than generalized PCHs with
a bit of syntax to decide which other PCHs they require and which symbols
are added to the PCH.

And it would be hard to claim that a well-defined PCH doesn't improve
compile times.

I'd say the principle outstanding questions with regard to module compile
times are these: can compilers build C++ module files quickly? Can
compilers build C++ module files that they can quickly load and then apply
to a module currently being compiled? And can build systems be able to
quickly determine the set of needed modules for a particular cpp, locate
them, and compile them where necessary, all while being able to take
advantage of multi-core CPUs?

If all of those are true, I don't see any practical reason why modules
would be slower than the current build system.

Also, C++ must have the absolute worst "recompile the world" problems in
all of programming. Anything else would be, at worst, a lateral move.


>   Along came Dewar and GNAT, and they dispensed with the notion of
> compiled program libraries, choosing to read the source of the package
> specifications whenever they encountered a "with" package inclusion.  This
> resulted in much faster and more reliable Ada compilation.
>
> Knowing this, I'm afraid C++ modules will head down the same path.
>

I cannot imagine a circumstance in which compiling <vector> 10,000 times
for the 10,000 files in a project is faster than compiling <vector> once
for the entire project and loading a vector module file for the 10,000
files. Again, PCH files seem to demonstrate this.

--

---
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_4185_1312135567.1430787745276
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, May 4, 2015 at 4:38:15 PM UTC-4, Hyman =
Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br>"Those who study history believe we are condemned to repeat it."<br><br>=
Back in the day, Ada programming systems were assumed to come with a "progr=
am library", some form of binary representation of modules, so that when yo=
u said "with Name;" the system could look up the already-compiled Name pack=
age and import its symbols, or perhaps cause "Name" to be compiled in order=
 to do so.&nbsp; This resulted in notoriety for "recompile the world" probl=
ems, not to mention slow and buggy program library implementations.</div></=
blockquote><div><br>I'm not sure how either of those is a necessary result =
of C++ modules (granted, I'm not sure how that would be a necessary result =
of ADA modules either, but I know nothing about that language or its build =
environment). After all, at its core, modules are little more than generali=
zed PCHs with a bit of syntax to decide which other PCHs they require and w=
hich symbols are added to the PCH.<br><br>And it would be hard to claim tha=
t a well-defined PCH doesn't improve compile times.<br><br>I'd say the prin=
ciple outstanding questions with regard to module compile times are these: =
can compilers build C++ module files quickly? Can compilers build C++ modul=
e files that they can quickly load and then apply to a module currently bei=
ng compiled? And can build systems be able to quickly determine the set of =
needed modules for a particular cpp, locate them, and compile them where ne=
cessary, all while being able to take advantage of multi-core CPUs?<br><br>=
If all of those are true, I don't see any practical reason why modules woul=
d be slower than the current build system.<br><br>Also, C++ must have the a=
bsolute worst "recompile the world" problems in all of programming. Anythin=
g else would be, at worst, a lateral move.<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">&nbsp; Along came Dewar and GN=
AT, and they dispensed with the notion of compiled program libraries, choos=
ing to read the source of the package specifications whenever they encounte=
red a "with" package inclusion.&nbsp; This resulted in much faster and more=
 reliable Ada compilation.<div><br></div><div>Knowing this, I'm afraid C++ =
modules will head down the same path.</div></div></blockquote><div><br>I ca=
nnot imagine a circumstance in which compiling &lt;vector&gt; 10,000 times =
for the 10,000 files in a project is faster than compiling &lt;vector&gt; o=
nce for the entire project and loading a vector module file for the 10,000 =
files. Again, PCH files seem to demonstrate this.<br></div></div>

<p></p>

-- <br />
<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 <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 />
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_4185_1312135567.1430787745276--
------=_Part_4184_2109868633.1430787745276--

.

--001a1133c774ea3ff5051557d514
Content-Type: text/plain; charset=UTF-8

In addition to the Ada example, I recall having lots of trouble with Sun
C++ trying to cache template instantiations across compilations.  And of
course the "export" mechanism failed totally.  Whenever you have two things
which are supposed to be alternate views of the same thing, you introduce
the opportunity for error and inefficiency - the two things may not in fact
provide the same view, or the system that manages them may spend too much
time insuring that they do.  I'm not saying that modules will fail, I'm
just saying that past experience warrants caution.

On Mon, May 4, 2015 at 9:02 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Monday, May 4, 2015 at 4:38:15 PM UTC-4, Hyman Rosen wrote:
>>
>>
>> "Those who study history believe we are condemned to repeat it."
>>
>> Back in the day, Ada programming systems were assumed to come with a
>> "program library", some form of binary representation of modules, so that
>> when you said "with Name;" the system could look up the already-compiled
>> Name package and import its symbols, or perhaps cause "Name" to be compiled
>> in order to do so.  This resulted in notoriety for "recompile the world"
>> problems, not to mention slow and buggy program library implementations.
>>
>
> I'm not sure how either of those is a necessary result of C++ modules
> (granted, I'm not sure how that would be a necessary result of ADA modules
> either, but I know nothing about that language or its build environment).
> After all, at its core, modules are little more than generalized PCHs with
> a bit of syntax to decide which other PCHs they require and which symbols
> are added to the PCH.
>
> And it would be hard to claim that a well-defined PCH doesn't improve
> compile times.
>
> I'd say the principle outstanding questions with regard to module compile
> times are these: can compilers build C++ module files quickly? Can
> compilers build C++ module files that they can quickly load and then apply
> to a module currently being compiled? And can build systems be able to
> quickly determine the set of needed modules for a particular cpp, locate
> them, and compile them where necessary, all while being able to take
> advantage of multi-core CPUs?
>
> If all of those are true, I don't see any practical reason why modules
> would be slower than the current build system.
>
> Also, C++ must have the absolute worst "recompile the world" problems in
> all of programming. Anything else would be, at worst, a lateral move.
>
>
>>   Along came Dewar and GNAT, and they dispensed with the notion of
>> compiled program libraries, choosing to read the source of the package
>> specifications whenever they encountered a "with" package inclusion.  This
>> resulted in much faster and more reliable Ada compilation.
>>
>> Knowing this, I'm afraid C++ modules will head down the same path.
>>
>
> I cannot imagine a circumstance in which compiling <vector> 10,000 times
> for the 10,000 files in a project is faster than compiling <vector> once
> for the entire project and loading a vector module file for the 10,000
> files. Again, PCH files seem to demonstrate this.
>
> --
>
> ---
> 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/.
>

--

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

--001a1133c774ea3ff5051557d514
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In addition to the Ada example, I recall having lots of tr=
ouble with Sun C++ trying to cache template instantiations across compilati=
ons.=C2=A0=C2=A0And of course the &quot;export&quot; mechanism failed total=
ly.=C2=A0=C2=A0Whenever you have two things which are supposed to be altern=
ate views of the same thing, you introduce the opportunity for error and in=
efficiency - the two things may not in fact provide the same view, or the s=
ystem that manages them may spend too much time insuring that they do.=C2=
=A0 I&#39;m not saying that modules will fail, I&#39;m just saying that pas=
t experience warrants caution.</div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Mon, May 4, 2015 at 9:02 PM, Nicol Bolas <span dir=3D=
"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesso=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><span class=3D""><br><br>On Monday, May 4, 2015 at 4:38:15 PM UTC=
-4, Hyman Rosen 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"l=
tr"><br>&quot;Those who study history believe we are condemned to repeat it=
..&quot;<br><br>Back in the day, Ada programming systems were assumed to com=
e with a &quot;program library&quot;, some form of binary representation of=
 modules, so that when you said &quot;with Name;&quot; the system could loo=
k up the already-compiled Name package and import its symbols, or perhaps c=
ause &quot;Name&quot; to be compiled in order to do so.=C2=A0 This resulted=
 in notoriety for &quot;recompile the world&quot; problems, not to mention =
slow and buggy program library implementations.</div></blockquote></span><d=
iv><br>I&#39;m not sure how either of those is a necessary result of C++ mo=
dules (granted, I&#39;m not sure how that would be a necessary result of AD=
A modules either, but I know nothing about that language or its build envir=
onment). After all, at its core, modules are little more than generalized P=
CHs with a bit of syntax to decide which other PCHs they require and which =
symbols are added to the PCH.<br><br>And it would be hard to claim that a w=
ell-defined PCH doesn&#39;t improve compile times.<br><br>I&#39;d say the p=
rinciple outstanding questions with regard to module compile times are thes=
e: can compilers build C++ module files quickly? Can compilers build C++ mo=
dule files that they can quickly load and then apply to a module currently =
being compiled? And can build systems be able to quickly determine the set =
of needed modules for a particular cpp, locate them, and compile them where=
 necessary, all while being able to take advantage of multi-core CPUs?<br><=
br>If all of those are true, I don&#39;t see any practical reason why modul=
es would be slower than the current build system.<br><br>Also, C++ must hav=
e the absolute worst &quot;recompile the world&quot; problems in all of pro=
gramming. Anything else would be, at worst, a lateral move.<br>=C2=A0</div>=
<span class=3D""><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">=
=C2=A0 Along came Dewar and GNAT, and they dispensed with the notion of com=
piled program libraries, choosing to read the source of the package specifi=
cations whenever they encountered a &quot;with&quot; package inclusion.=C2=
=A0 This resulted in much faster and more reliable Ada compilation.<div><br=
></div><div>Knowing this, I&#39;m afraid C++ modules will head down the sam=
e path.</div></div></blockquote></span><div><br>I cannot imagine a circumst=
ance in which compiling &lt;vector&gt; 10,000 times for the 10,000 files in=
 a project is faster than compiling &lt;vector&gt; once for the entire proj=
ect and loading a vector module file for the 10,000 files. Again, PCH files=
 seem to demonstrate this.<br></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a1133c774ea3ff5051557d514--

.

--001a11c34a3cdeaa1f0515582a2a
Content-Type: text/plain; charset=UTF-8

Is this not already the case between a bunch of .cpp files and the .a or
..lib (probably more the latter)?

How are modules inherently different than a generated binary?

    David


On Tue, May 5, 2015 at 5:04 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> In addition to the Ada example, I recall having lots of trouble with Sun
> C++ trying to cache template instantiations across compilations.  And of
> course the "export" mechanism failed totally.  Whenever you have two things
> which are supposed to be alternate views of the same thing, you introduce
> the opportunity for error and inefficiency - the two things may not in fact
> provide the same view, or the system that manages them may spend too much
> time insuring that they do.  I'm not saying that modules will fail, I'm
> just saying that past experience warrants caution.
>
> On Mon, May 4, 2015 at 9:02 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> On Monday, May 4, 2015 at 4:38:15 PM UTC-4, Hyman Rosen wrote:
>>>
>>>
>>> "Those who study history believe we are condemned to repeat it."
>>>
>>> Back in the day, Ada programming systems were assumed to come with a
>>> "program library", some form of binary representation of modules, so that
>>> when you said "with Name;" the system could look up the already-compiled
>>> Name package and import its symbols, or perhaps cause "Name" to be compiled
>>> in order to do so.  This resulted in notoriety for "recompile the world"
>>> problems, not to mention slow and buggy program library implementations.
>>>
>>
>> I'm not sure how either of those is a necessary result of C++ modules
>> (granted, I'm not sure how that would be a necessary result of ADA modules
>> either, but I know nothing about that language or its build environment).
>> After all, at its core, modules are little more than generalized PCHs with
>> a bit of syntax to decide which other PCHs they require and which symbols
>> are added to the PCH.
>>
>> And it would be hard to claim that a well-defined PCH doesn't improve
>> compile times.
>>
>> I'd say the principle outstanding questions with regard to module compile
>> times are these: can compilers build C++ module files quickly? Can
>> compilers build C++ module files that they can quickly load and then apply
>> to a module currently being compiled? And can build systems be able to
>> quickly determine the set of needed modules for a particular cpp, locate
>> them, and compile them where necessary, all while being able to take
>> advantage of multi-core CPUs?
>>
>> If all of those are true, I don't see any practical reason why modules
>> would be slower than the current build system.
>>
>> Also, C++ must have the absolute worst "recompile the world" problems in
>> all of programming. Anything else would be, at worst, a lateral move.
>>
>>
>>>   Along came Dewar and GNAT, and they dispensed with the notion of
>>> compiled program libraries, choosing to read the source of the package
>>> specifications whenever they encountered a "with" package inclusion.  This
>>> resulted in much faster and more reliable Ada compilation.
>>>
>>> Knowing this, I'm afraid C++ modules will head down the same path.
>>>
>>
>> I cannot imagine a circumstance in which compiling <vector> 10,000 times
>> for the 10,000 files in a project is faster than compiling <vector> once
>> for the entire project and loading a vector module file for the 10,000
>> files. Again, PCH files seem to demonstrate this.
>>
>> --
>>
>> ---
>> 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/.
>>
>
>  --
>
> ---
> 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/.
>

--

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

--001a11c34a3cdeaa1f0515582a2a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is this not already the case between a bunch of .cpp files=
 and the .a or .lib (probably more the latter)?<br><br>How are modules inhe=
rently different than a generated binary?<br><br>=C2=A0 =C2=A0 David<div><b=
r></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Tue, May 5, 2015 at 5:04 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">In addit=
ion to the Ada example, I recall having lots of trouble with Sun C++ trying=
 to cache template instantiations across compilations.=C2=A0=C2=A0And of co=
urse the &quot;export&quot; mechanism failed totally.=C2=A0=C2=A0Whenever y=
ou have two things which are supposed to be alternate views of the same thi=
ng, you introduce the opportunity for error and inefficiency - the two thin=
gs may not in fact provide the same view, or the system that manages them m=
ay spend too much time insuring that they do.=C2=A0 I&#39;m not saying that=
 modules will fail, I&#39;m just saying that past experience warrants cauti=
on.</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Mon, May 4, 2015 at 9:02 PM, Nicol Bolas=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_bl=
ank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><span><br><br>On Monday, May 4, 2015 at 4:38:15 PM U=
TC-4, Hyman Rosen wrote:<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"><br>&quot;Those who study history believe we are condemned to repeat =
it.&quot;<br><br>Back in the day, Ada programming systems were assumed to c=
ome with a &quot;program library&quot;, some form of binary representation =
of modules, so that when you said &quot;with Name;&quot; the system could l=
ook up the already-compiled Name package and import its symbols, or perhaps=
 cause &quot;Name&quot; to be compiled in order to do so.=C2=A0 This result=
ed in notoriety for &quot;recompile the world&quot; problems, not to mentio=
n slow and buggy program library implementations.</div></blockquote></span>=
<div><br>I&#39;m not sure how either of those is a necessary result of C++ =
modules (granted, I&#39;m not sure how that would be a necessary result of =
ADA modules either, but I know nothing about that language or its build env=
ironment). After all, at its core, modules are little more than generalized=
 PCHs with a bit of syntax to decide which other PCHs they require and whic=
h symbols are added to the PCH.<br><br>And it would be hard to claim that a=
 well-defined PCH doesn&#39;t improve compile times.<br><br>I&#39;d say the=
 principle outstanding questions with regard to module compile times are th=
ese: can compilers build C++ module files quickly? Can compilers build C++ =
module files that they can quickly load and then apply to a module currentl=
y being compiled? And can build systems be able to quickly determine the se=
t of needed modules for a particular cpp, locate them, and compile them whe=
re necessary, all while being able to take advantage of multi-core CPUs?<br=
><br>If all of those are true, I don&#39;t see any practical reason why mod=
ules would be slower than the current build system.<br><br>Also, C++ must h=
ave the absolute worst &quot;recompile the world&quot; problems in all of p=
rogramming. Anything else would be, at worst, a lateral move.<br>=C2=A0</di=
v><span><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">=C2=A0 Alo=
ng came Dewar and GNAT, and they dispensed with the notion of compiled prog=
ram libraries, choosing to read the source of the package specifications wh=
enever they encountered a &quot;with&quot; package inclusion.=C2=A0 This re=
sulted in much faster and more reliable Ada compilation.<div><br></div><div=
>Knowing this, I&#39;m afraid C++ modules will head down the same path.</di=
v></div></blockquote></span><div><br>I cannot imagine a circumstance in whi=
ch compiling &lt;vector&gt; 10,000 times for the 10,000 files in a project =
is faster than compiling &lt;vector&gt; once for the entire project and loa=
ding a vector module file for the 10,000 files. Again, PCH files seem to de=
monstrate this.<br></div></div><div><div>

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c34a3cdeaa1f0515582a2a--

.

------=_Part_352_2072030705.1430846288729
Content-Type: multipart/alternative;
 boundary="----=_Part_353_1025239183.1430846288729"

------=_Part_353_1025239183.1430846288729
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 5, 2015 at 12:28:27 PM UTC-4, David Rodr=C3=ADguez Ibeas wr=
ote:
>
> Is this not already the case between a bunch of .cpp files and the .a or=
=20
> .lib (probably more the latter)?
>
> How are modules inherently different than a generated binary?
>
>     David
>

I'd say the biggest difference is not the results of compilation (where, as=
=20
you pointed out, .o/.obj files are effectively views of .cpp files, and=20
already have to be kept in-sync), but the compiler dependency graph.

Pre-modules, the build system has to, for each destination object file=20
you're building, know exactly what source and header files it depends on.=
=20
If any of these files on disk change, the object file must be rebuilt. With=
=20
modules, the ability to compile module X relies on actually *compiling*=20
module Y (to [re]generate its module file), not merely having changed a=20
source/header file.

So the build system would need to determine an ordering for compiling the=
=20
various destination objects. Before modules, such order was irrelevant.

I'm no expert on the details of C++ build systems. But I do know that most=
=20
of them can detect changes in headers, even if that header isn't=20
necessarily listed in the build system. From such changes, they can=20
generate a list of which .cpp files include (directly or indirectly) that=
=20
header and thus issue compilation orders.

Whatever mechanisms are currently being used to build the header dependency=
=20
graph can almost certainly be extended for tracking module dependencies.=20
They'd simply need to perform an ordering sort on module compilation (and=
=20
if no order is possible, then the user screwed up).

So I don't see anything about even this process that is generally=20
untenable; it's simply something that the various build systems have to=20
figure out.
=20

>
>
> On Tue, May 5, 2015 at 5:04 PM, Hyman Rosen <hyman...@gmail.com=20
> <javascript:>> wrote:
>
>> In addition to the Ada example, I recall having lots of trouble with Sun=
=20
>> C++ trying to cache template instantiations across compilations.  And of=
=20
>> course the "export" mechanism failed totally.  Whenever you have two thi=
ngs=20
>> which are supposed to be alternate views of the same thing, you introduc=
e=20
>> the opportunity for error and inefficiency - the two things may not in f=
act=20
>> provide the same view, or the system that manages them may spend too muc=
h=20
>> time insuring that they do.  I'm not saying that modules will fail, I'm=
=20
>> just saying that past experience warrants caution.
>>
>> On Mon, May 4, 2015 at 9:02 PM, Nicol Bolas <jmck...@gmail.com=20
>> <javascript:>> wrote:
>>
>>>
>>>
>>> On Monday, May 4, 2015 at 4:38:15 PM UTC-4, Hyman Rosen wrote:
>>>>
>>>>
>>>> "Those who study history believe we are condemned to repeat it."
>>>>
>>>> Back in the day, Ada programming systems were assumed to come with a=
=20
>>>> "program library", some form of binary representation of modules, so t=
hat=20
>>>> when you said "with Name;" the system could look up the already-compil=
ed=20
>>>> Name package and import its symbols, or perhaps cause "Name" to be com=
piled=20
>>>> in order to do so.  This resulted in notoriety for "recompile the worl=
d"=20
>>>> problems, not to mention slow and buggy program library implementation=
s.
>>>>
>>>
>>> I'm not sure how either of those is a necessary result of C++ modules=
=20
>>> (granted, I'm not sure how that would be a necessary result of ADA modu=
les=20
>>> either, but I know nothing about that language or its build environment=
).=20
>>> After all, at its core, modules are little more than generalized PCHs w=
ith=20
>>> a bit of syntax to decide which other PCHs they require and which symbo=
ls=20
>>> are added to the PCH.
>>>
>>> And it would be hard to claim that a well-defined PCH doesn't improve=
=20
>>> compile times.
>>>
>>> I'd say the principle outstanding questions with regard to module=20
>>> compile times are these: can compilers build C++ module files quickly? =
Can=20
>>> compilers build C++ module files that they can quickly load and then ap=
ply=20
>>> to a module currently being compiled? And can build systems be able to=
=20
>>> quickly determine the set of needed modules for a particular cpp, locat=
e=20
>>> them, and compile them where necessary, all while being able to take=20
>>> advantage of multi-core CPUs?
>>>
>>> If all of those are true, I don't see any practical reason why modules=
=20
>>> would be slower than the current build system.
>>>
>>> Also, C++ must have the absolute worst "recompile the world" problems i=
n=20
>>> all of programming. Anything else would be, at worst, a lateral move.
>>> =20
>>>
>>>>   Along came Dewar and GNAT, and they dispensed with the notion of=20
>>>> compiled program libraries, choosing to read the source of the package=
=20
>>>> specifications whenever they encountered a "with" package inclusion.  =
This=20
>>>> resulted in much faster and more reliable Ada compilation.
>>>>
>>>> Knowing this, I'm afraid C++ modules will head down the same path.
>>>>
>>>
>>> I cannot imagine a circumstance in which compiling <vector> 10,000 time=
s=20
>>> for the 10,000 files in a project is faster than compiling <vector> onc=
e=20
>>> for the entire project and loading a vector module file for the 10,000=
=20
>>> files. Again, PCH files seem to demonstrate this.
>>>
>>> --=20
>>>
>>> ---=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
>>> Visit this group at=20
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>  --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=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_353_1025239183.1430846288729
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 5, 2015 at 12:28:27 PM UTC-4, David Rodr=
=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">Is this not already the case between a bunch of .cpp files and th=
e .a or .lib (probably more the latter)?<br><br>How are modules inherently =
different than a generated binary?<br><br>&nbsp; &nbsp; David</div></blockq=
uote><div><br>I'd say the biggest difference is not the results of compilat=
ion (where, as you pointed out, .o/.obj files are effectively views of .cpp=
 files, and already have to be kept in-sync), but the compiler dependency g=
raph.<br><br>Pre-modules, the build system has to, for each destination obj=
ect file you're building, know exactly what source and header files it depe=
nds on. If any of these files on disk change, the object file must be rebui=
lt. With modules, the ability to compile module X relies on actually <i>com=
piling</i> module Y (to [re]generate its module file), not merely having ch=
anged a source/header file.<br><br>So the build system would need to determ=
ine an ordering for compiling the various destination objects. Before modul=
es, such order was irrelevant.<br><br>I'm no expert on the details of C++ b=
uild systems. But I do know that most of them can detect changes in headers=
, even if that header isn't necessarily listed in the build system. From su=
ch changes, they can generate a list of which .cpp files include (directly =
or indirectly) that header and thus issue compilation orders.<br><br>Whatev=
er mechanisms are currently being used to build the header dependency graph=
 can almost certainly be extended for tracking module dependencies. They'd =
simply need to perform an ordering sort on module compilation (and if no or=
der is possible, then the user screwed up).<br><br>So I don't see anything =
about even this process that is generally untenable; it's simply something =
that the various build systems have to figure out.<br>&nbsp;</div><blockquo=
te 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><br></div></div><=
div><br><div class=3D"gmail_quote">On Tue, May 5, 2015 at 5:04 PM, Hyman Ro=
sen <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"uO6D4P8b-zEJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">hyman...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">In addition to the Ada example, I recall having lot=
s of trouble with Sun C++ trying to cache template instantiations across co=
mpilations.&nbsp;&nbsp;And of course the "export" mechanism failed totally.=
&nbsp;&nbsp;Whenever you have two things which are supposed to be alternate=
 views of the same thing, you introduce the opportunity for error and ineff=
iciency - the two things may not in fact provide the same view, or the syst=
em that manages them may spend too much time insuring that they do.&nbsp; I=
'm not saying that modules will fail, I'm just saying that past experience =
warrants caution.</div><div><div><div><br><div class=3D"gmail_quote">On Mon=
, May 4, 2015 at 9:02 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"uO6D4P8b-zEJ" rel=3D"no=
follow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"t=
his.href=3D'javascript:';return true;">jmck...@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><br><br>On Mon=
day, May 4, 2015 at 4:38:15 PM UTC-4, Hyman Rosen wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><br>"Those who study history believ=
e we are condemned to repeat it."<br><br>Back in the day, Ada programming s=
ystems were assumed to come with a "program library", some form of binary r=
epresentation of modules, so that when you said "with Name;" the system cou=
ld look up the already-compiled Name package and import its symbols, or per=
haps cause "Name" to be compiled in order to do so.&nbsp; This resulted in =
notoriety for "recompile the world" problems, not to mention slow and buggy=
 program library implementations.</div></blockquote></span><div><br>I'm not=
 sure how either of those is a necessary result of C++ modules (granted, I'=
m not sure how that would be a necessary result of ADA modules either, but =
I know nothing about that language or its build environment). After all, at=
 its core, modules are little more than generalized PCHs with a bit of synt=
ax to decide which other PCHs they require and which symbols are added to t=
he PCH.<br><br>And it would be hard to claim that a well-defined PCH doesn'=
t improve compile times.<br><br>I'd say the principle outstanding questions=
 with regard to module compile times are these: can compilers build C++ mod=
ule files quickly? Can compilers build C++ module files that they can quick=
ly load and then apply to a module currently being compiled? And can build =
systems be able to quickly determine the set of needed modules for a partic=
ular cpp, locate them, and compile them where necessary, all while being ab=
le to take advantage of multi-core CPUs?<br><br>If all of those are true, I=
 don't see any practical reason why modules would be slower than the curren=
t build system.<br><br>Also, C++ must have the absolute worst "recompile th=
e world" problems in all of programming. Anything else would be, at worst, =
a lateral move.<br>&nbsp;</div><span><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">&nbsp; Along came Dewar and GNAT, and they dispensed wit=
h the notion of compiled program libraries, choosing to read the source of =
the package specifications whenever they encountered a "with" package inclu=
sion.&nbsp; This resulted in much faster and more reliable Ada compilation.=
<div><br></div><div>Knowing this, I'm afraid C++ modules will head down the=
 same path.</div></div></blockquote></span><div><br>I cannot imagine a circ=
umstance in which compiling &lt;vector&gt; 10,000 times for the 10,000 file=
s in a project is faster than compiling &lt;vector&gt; once for the entire =
project and loading a vector module file for the 10,000 files. Again, PCH f=
iles seem to demonstrate this.<br></div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
uO6D4P8b-zEJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"uO6D4P8b-zEJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
uO6D4P8b-zEJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"uO6D4P8b-zEJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
<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 <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 />
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_353_1025239183.1430846288729--
------=_Part_352_2072030705.1430846288729--

.