On 2016-02-26 11:56, Nicol Bolas wrote:
> On Friday, February 26, 2016 at 10:17:06 AM UTC-5, Matthew Woehlke wrote:
>> How do modules work from a build system perspective, anyway?
>
> Microsoft has an implementation of Modules, which shows how they
> implemented it from a build system perspective
> <https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules-in-vs-2015-update-1/>
> .

Contrary to your later statement, this impression I get from that
article is that the only change is a new output object type.

What happens when the implementation of Foo and Bar both depend on each
other's modules?

>> Do you expect the compiler to be sufficiently clever as to not overwrite
>> an existing compiled module file if the one it just produced has the
>> same contents?
>
> Um, yes. There's no reason for a compiler not to do a basic bit of hashing
> on the compiled module file to check to see if it has genuinely changed.

I'd make muttering noises about memory use (to make this work, you have
to either write the file twice, or keep the whole thing in memory), but
seeing as I've watched gcc slurp up a few GiB to compile a file, keeping
the entire output temporarily in memory may be tolerable. (Besides, the
compiler may do that already, anyway.)

>> Or is the compiler expected to replace build tools entirely, i.e. to
>> build a library, you invoke the compiler once, passing it *every source
>> file used*, and expect the compiler to sort out what needs to be done?
>
> ... why not?

That seems like a significant change to both build systems and
compilers. As long as compiler vendors are okay with that, I guess it's
acceptable. (There's probably not much we can do about needing to
radically change how people build software once modules come into play.
That's likely to be the case regardless of the design.)

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/naq19i%24fhr%241%40ger.gmane.org.

.

------=_Part_649_2039268439.1456508553109
Content-Type: text/plain; charset=UTF-8

My "pet" feature does not change completely the language as the "modules".
Maybe you should call it "++C".

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62371ee0-b237-45d6-9baf-76f82573e177%40isocpp.org.

------=_Part_649_2039268439.1456508553109--

.

------=_Part_965_2030590843.1456508742566
Content-Type: text/plain; charset=UTF-8

Anyhow there are already some keywords with a different meaning in a different context.
"static" for example.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0d23ef00-2805-4577-a719-9f923d921345%40isocpp.org.

------=_Part_965_2030590843.1456508742566--

.

------=_Part_525_560232075.1456520611527
Content-Type: multipart/alternative;
 boundary="----=_Part_526_1505789708.1456520611527"

------=_Part_526_1505789708.1456520611527
Content-Type: text/plain; charset=UTF-8

On Friday, February 26, 2016 at 12:45:42 PM UTC-5, daniele...@gmail.com
wrote:
>
> Anyhow there are already some keywords with a different meaning in a
> different context.
> "static" for example.


Perhaps, but `export class X` will have a very specific meaning under
modules.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d39a2255-f5b2-4a69-8654-9bd2725014c8%40isocpp.org.

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

<div dir=3D"ltr">On Friday, February 26, 2016 at 12:45:42 PM UTC-5, daniele=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Anyhow the=
re are already some keywords with a different meaning in a different contex=
t.<br>&quot;static&quot; for example.</blockquote><div><br>Perhaps, but `ex=
port class X` will have a very specific meaning under modules. <br></div></=
div>

<p></p>

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

------=_Part_526_1505789708.1456520611527--
------=_Part_525_560232075.1456520611527--

.

------=_Part_905_1635993586.1456521036485
Content-Type: multipart/alternative;
 boundary="----=_Part_906_1785290335.1456521036485"

------=_Part_906_1785290335.1456521036485
Content-Type: text/plain; charset=UTF-8

On Friday, February 26, 2016 at 12:16:46 PM UTC-5, Matthew Woehlke wrote:
>
> On 2016-02-26 11:56, Nicol Bolas wrote:
> > On Friday, February 26, 2016 at 10:17:06 AM UTC-5, Matthew Woehlke
> wrote:
> >> How do modules work from a build system perspective, anyway?
> >
> > Microsoft has an implementation of Modules, which shows how they
> > implemented it from a build system perspective
> > <
> https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules-in-vs-2015-update-1/>
>
> > .
>
> Contrary to your later statement, this impression I get from that
> article is that the only change is a new output object type.
>

Right. Because that's all that's needed from their build system
perspective. Visual studio understand that if file X depends on file Y, and
file Y depends on file Z, it needs to compile file Z so that Y can be
current, then compile Y so that X can be current.

Functionally, the only thing modules adds is that you get two files from
building a .cpp file: an object file and a module file. That and the fact
that building later .cpp files can rely on the results of previous .cpp
operations, but any decent build system should be able to handle
dependencies like that.

What happens when the implementation of Foo and Bar both depend on each
> other's modules?
>

Pretty much every C++ modules proposal has made it quite clear that module
inclusion must form a directed, acyclic graph. And the current one is no
exception. So when that happens, you need to extract the conflicting parts
into a module file.

>> Do you expect the compiler to be sufficiently clever as to not overwrite
> >> an existing compiled module file if the one it just produced has the
> >> same contents?
> >
> > Um, yes. There's no reason for a compiler not to do a basic bit of
> hashing
> > on the compiled module file to check to see if it has genuinely changed.
>
> I'd make muttering noises about memory use (to make this work, you have
> to either write the file twice, or keep the whole thing in memory), but
> seeing as I've watched gcc slurp up a few GiB to compile a file, keeping
> the entire output temporarily in memory may be tolerable. (Besides, the
> compiler may do that already, anyway.)
>

The entire output... of a single module. That's really not that much. I've
had large, Boost-laden PCH files, but even those have only been on the
order of hundreds of kilobytes in size.

I would expect the far more granular modules to be smaller in size.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e87c7956-35fe-4cc7-8a1c-175011e9fc62%40isocpp.org.

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

<div dir=3D"ltr">On Friday, February 26, 2016 at 12:16:46 PM UTC-5, Matthew=
 Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-02-26 1=
1:56, Nicol Bolas wrote:
<br>&gt; On Friday, February 26, 2016 at 10:17:06 AM UTC-5, Matthew Woehlke=
 wrote:
<br>&gt;&gt; How do modules work from a build system perspective, anyway?
<br>&gt;=20
<br>&gt; Microsoft has an implementation of Modules, which shows how they=
=20
<br>&gt; implemented it from a build system perspective=20
<br>&gt; &lt;<a href=3D"https://blogs.msdn.microsoft.com/vcblog/2015/12/03/=
c-modules-in-vs-2015-update-1/" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fblogs.=
msdn.microsoft.com%2Fvcblog%2F2015%2F12%2F03%2Fc-modules-in-vs-2015-update-=
1%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNF0t9zgu-uwhQYlnKEpJMsoc2lGZQ&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75htt=
ps%3A%2F%2Fblogs.msdn.microsoft.com%2Fvcblog%2F2015%2F12%2F03%2Fc-modules-i=
n-vs-2015-update-1%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNF0t9zgu-uwhQYlnKEp=
JMsoc2lGZQ&#39;;return true;">https://blogs.msdn.microsoft.<wbr>com/vcblog/=
2015/12/03/c-<wbr>modules-in-vs-2015-update-1/</a>&gt;
<br>&gt; .
<br>
<br>Contrary to your later statement, this impression I get from that
<br>article is that the only change is a new output object type.
<br></blockquote><div><br>Right. Because that&#39;s all that&#39;s needed f=
rom their build system perspective. Visual studio understand that if file X=
 depends on file Y, and file Y depends on file Z, it needs to compile file =
Z so that Y can be current, then compile Y so that X can be current.<br><br=
>Functionally, the only thing modules adds is that you get two files from b=
uilding a .cpp file: an object file and a module file. That and the fact th=
at building later .cpp files can rely on the results of previous .cpp opera=
tions, but any decent build system should be able to handle dependencies li=
ke that.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
What happens when the implementation of Foo and Bar both depend on each
<br>other&#39;s modules?<br></blockquote><div><br>Pretty much every C++ mod=
ules proposal has made it quite clear that module inclusion must form a dir=
ected, acyclic graph. And the current one is no exception. So when that hap=
pens, you need to extract the conflicting parts into a module file.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt;&gt; Do you expect the compiler to be sufficiently clever as to not ove=
rwrite=20
<br>&gt;&gt; an existing compiled module file if the one it just produced h=
as the=20
<br>&gt;&gt; same contents?
<br>&gt;=20
<br>&gt; Um, yes. There&#39;s no reason for a compiler not to do a basic bi=
t of hashing=20
<br>&gt; on the compiled module file to check to see if it has genuinely ch=
anged.
<br>
<br>I&#39;d make muttering noises about memory use (to make this work, you =
have
<br>to either write the file twice, or keep the whole thing in memory), but
<br>seeing as I&#39;ve watched gcc slurp up a few GiB to compile a file, ke=
eping
<br>the entire output temporarily in memory may be tolerable. (Besides, the
<br>compiler may do that already, anyway.)<br></blockquote><div><br>The ent=
ire output... of a single module. That&#39;s really not that much. I&#39;ve=
 had large, Boost-laden PCH files, but even those have only been on the ord=
er of hundreds of kilobytes in size.<br><br>I would expect the far more gra=
nular modules to be smaller in size.<br></div></div>

<p></p>

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

------=_Part_906_1785290335.1456521036485--
------=_Part_905_1635993586.1456521036485--

.

------=_Part_606_1598750049.1456521298384
Content-Type: text/plain; charset=UTF-8

I thought quickly to something different, for instance:

// "partial class":
class Stack : export StackInterface

// "internal class"
class Stack : public StackInterface

It should not interfere with the things you mention.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8a224f6a-80f2-410a-96da-915eb9b79960%40isocpp.org.

------=_Part_606_1598750049.1456521298384--

.