------=_Part_710_1962489432.1421415244203
Content-Type: multipart/alternative;
 boundary="----=_Part_711_358549351.1421415244203"

------=_Part_711_358549351.1421415244203
Content-Type: text/plain; charset=UTF-8

I've read through the module proposal and one thing that is a bit unclear
to me is what thoughts there currently are on how the whole thing is
supposed to work wrt. multiple implementation files for the same module.:

At the moment, if we have interface.h and interface.cpp, the using code
will do `#include<interface.h>` and to actually translate the resulting
program, we have to "feed/include" the cpp file of the interface in the
project system / make file so that it is compiled (and linked) too. (and
the interface.cpp file will just include the header too.)

Section 3.2 shows m.itf.cpp and m.impl1.cpp, m.impl2.cpp -- all three
contain the `module M;` declaration; only m.itf.cpp conatins the export
section wit the actual interface.

It is likely that m.itf.cpp would contain some class declaration in its
export section and that the implementation of the class member functions
would be moved to the m.implx.cpp file - is this a valid assumption?

How would then (the compiler of) m.implx.cpp know about the declarations in
the module interface, as it cannot #include m.itf.cpp?

cheers,
Martin

--

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

<div dir=3D"ltr">I've read through the module proposal and one thing that i=
s a bit unclear to me is what thoughts there currently are on how the whole=
 thing is supposed to work wrt. multiple implementation files for the same =
module.:<br><br>At the moment, if we have interface.h and interface.cpp, th=
e using code will do `#include&lt;interface.h&gt;` and to actually translat=
e the resulting program, we have to "feed/include" the cpp file of the inte=
rface in the project system / make file so that it is compiled (and linked)=
 too. (and the interface.cpp file will just include the header too.)<br><br=
>Section 3.2 shows m.itf.cpp and m.impl1.cpp, m.impl2.cpp -- all three cont=
ain the `module M;` declaration; only m.itf.cpp conatins the export section=
 wit the actual interface.<br><br>It is likely that m.itf.cpp would contain=
 some class declaration in its export section and that the implementation o=
f the class member functions would be moved to the m.implx.cpp file - is th=
is a valid assumption?<br><br>How would then (the compiler of) m.implx.cpp =
know about the declarations in the module interface, as it cannot #include =
m.itf.cpp?<br><br>cheers,<br>Martin<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_711_358549351.1421415244203--
------=_Part_710_1962489432.1421415244203--

.

Martin Ba <0xcdcdcdcd@gmx.at> writes:

| I've read through the module proposal and one thing that is a bit
| unclear to me is what thoughts there currently are on how the whole
| thing is supposed to work wrt. multiple implementation files for the
| same module.:
|
| At the moment, if we have interface.h and interface.cpp, the using
| code will do `#include<interface.h>` and to actually translate the
| resulting program, we have to "feed/include" the cpp file of the
| interface in the project system / make file so that it is compiled
| (and linked) too. (and the interface.cpp file will just include the
| header too.)

In the real world C++, there is no one-to-one correspondance between a
header file that provides the declarations for a component, and the
implementation file that implements all of the API.  A C++ world with
module must support that.  I.e. we can't afford the simplistic
assumptions of say Java.

We ought to have the ability to separate the interface declaration from
the module implementation, since there can be several module
implementations -- e.g. consider bootstrapping.

| Section 3.2 shows m.itf.cpp and m.impl1.cpp, m.impl2.cpp -- all three
| contain the `module M;` declaration; only m.itf.cpp conatins the
| export section wit the actual interface.
|
| It is likely that m.itf.cpp would contain some class declaration in
| its export section and that the implementation of the class member
| functions would be moved to the m.implx.cpp file - is this a valid
| assumption?

Correct.

| How would then (the compiler of) m.implx.cpp know about the
| declarations in the module interface, as it cannot #include m.itf.cpp?

That is what the 'module declaration' identifying a translation unit is for.
It tells the compiler (with appropriate swicth, as always) that the
translation unit is part of the nominated module.

-- Gaby

--

---
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_1129_933276557.1421434456055
Content-Type: multipart/alternative;
 boundary="----=_Part_1130_358535811.1421434456056"

------=_Part_1130_358535811.1421434456056
Content-Type: text/plain; charset=UTF-8

On Friday, January 16, 2015 at 6:58:25 PM UTC+1, Gabriel Dos Reis wrote:
>
> Martin Ba <0xcdc...@gmx.at <javascript:>> writes:
>
> | I've read through the module proposal ...
> |
> | At the moment, if we have interface.h and interface.cpp...
>
> In the real world C++, there is no one-to-one correspondance between a
> header file that provides the declarations for a component, and the
> implementation file that implements all of the API.  A C++ world with
> module must support that.  I.e. we can't afford the simplistic
> assumptions of say Java.
>
>
Indeed. We can't afford the simplistic view of Java that prescribes a
directory/file layout, and I wasn't hinting that we should.

However, there is a thing that Java, Perl, Python (...) have in common for
all packagemodules, that I find very compelling:

When the search paths are set up correctly, the to use a "module" *all* you
have to is `import using name;` - you do *not* have to tell the
compiler/linker/interpreter where the specific files of the "module" reside.

Contrast this with the C++ (and also C#) world today: To use another
translation unit, you *must* tell the "project system" explicitly that it
also should compile (and link) specific source file(s) and these files all
must be enumerated explicitly in a make file or VS project.

This *is* probably part of the implementation, but it sure would be nice if
the Modules Proposal would allow (or even suggest in a note)
implementations how to pick up module definitions from an `import M;` only,
without the user having to tell the "build system" explicitly that it
should compile m.itf.cpp m.impl1.cpp and m.impl2.cpp


> We ought to have the ability to separate the interface declaration from
> the module implementation, since there can be several module
> implementations -- e.g. consider bootstrapping.
>
>
Sorry. I don't quite follow here what you mean by boostrapping wrt.
"several module impl."?

| Section 3.2 shows m.itf.cpp and m.impl1.cpp, m.impl2.cpp -- all three
> | contain the `module M;` declaration; only m.itf.cpp conatins the
> | export section wit the actual interface.
> |
> | It is likely that m.itf.cpp would contain some class declaration in
> | its export section and that the implementation of the class member
> | functions would be moved to the m.implx.cpp file - is this a valid
> | assumption?
>
> Correct.
>
> | How would then (the compiler of) m.implx.cpp know about the
> | declarations in the module interface, as it cannot #include m.itf.cpp?
>
> That is what the 'module declaration' identifying a translation unit is
> for.
> It tells the compiler (with appropriate switch, as always) that the
> translation unit is part of the nominated module.
>
>
Could you give an envisioned sample invocation of a compiler that would
produce object file(s?) for such a module?
Today, you do
* `compile itf.cpp` (where impl.cpp #includes itf.h)
* `compile main.cpp` (and main.cpp also #includes itf.h)
* `link impl.obj main.obj`

The two compilations are 100% independent, but this could no longer be the
case given how I understand the example from 3.2

I do not understand how this is supposed to work with the envisioned
modules.

thanks,
Martin

--

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

<div dir=3D"ltr">On Friday, January 16, 2015 at 6:58:25 PM UTC+1, Gabriel D=
os Reis wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Martin Ba &lt;<a=
 href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"STIaSz6LX7=
4J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;"=
 onclick=3D"this.href=3D'javascript:';return true;">0xcdc...@gmx.at</a>&gt;=
 writes:
<br>
<br>| I've read through the module proposal ...<br>|=20
<br>| At the moment, if we have interface.h and interface.cpp...<br>
<br>In the real world C++, there is no one-to-one correspondance between a
<br>header file that provides the declarations for a component, and the
<br>implementation file that implements all of the API. &nbsp;A C++ world w=
ith
<br>module must support that. &nbsp;I.e. we can't afford the simplistic
<br>assumptions of say Java.=20
<br>
<br></blockquote><div><br>Indeed. We can't afford the simplistic view of Ja=
va that prescribes a directory/file layout, and I wasn't hinting that we sh=
ould.<br><br>However, there is a thing that Java, Perl, Python (...) have i=
n common for all packagemodules, that I find very compelling:<br><br>When t=
he search paths are set up correctly, the to use a "module" *all* you have =
to is `import using name;` - you do *not* have to tell the compiler/linker/=
interpreter where the specific files of the "module" reside.<br><br>Contras=
t this with the C++ (and also C#) world today: To use another translation u=
nit, you *must* tell the "project system" explicitly that it also should co=
mpile (and link) specific source file(s) and these files all must be enumer=
ated explicitly in a make file or VS project.<br><br>This *is* probably par=
t of the implementation, but it sure would be nice if the Modules Proposal =
would allow (or even suggest in a note) implementations how to pick up modu=
le definitions from an `import M;` only, without the user having to tell th=
e "build system" explicitly that it should compile m.itf.cpp m.impl1.cpp an=
d m.impl2.cpp<br>&nbsp; <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">We ought to have the ability to separate the interface declaration fr=
om
<br>the module implementation, since there can be several module
<br>implementations -- e.g. consider bootstrapping.
<br>
<br></blockquote><div><br>Sorry. I don't quite follow here what you mean by=
 boostrapping wrt. "several module impl."? <br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">| Section 3.2 shows m.itf.cpp and m.impl1.cpp, =
m.impl2.cpp -- all three
<br>| contain the `module M;` declaration; only m.itf.cpp conatins the
<br>| export section wit the actual interface.
<br>|=20
<br>| It is likely that m.itf.cpp would contain some class declaration in
<br>| its export section and that the implementation of the class member
<br>| functions would be moved to the m.implx.cpp file - is this a valid
<br>| assumption?
<br>
<br>Correct.
<br>
<br>| How would then (the compiler of) m.implx.cpp know about the
<br>| declarations in the module interface, as it cannot #include m.itf.cpp=
?
<br>
<br>That is what the 'module declaration' identifying a translation unit is=
 for.
<br>It tells the compiler (with appropriate switch, as always) that the
<br>translation unit is part of the nominated module.
<br>
<br></blockquote><div><br>Could you give an envisioned sample invocation of=
 a compiler that would produce object file(s?) for such a module?<br>Today,=
 you do <br>* `compile itf.cpp` (where impl.cpp #includes itf.h)<br>* `comp=
ile main.cpp` (and main.cpp also #includes itf.h)<br>* `link impl.obj main.=
obj`<br><br>The two compilations are 100% independent, but this could no lo=
nger be the case given how I understand the example from 3.2<br><br>I do no=
t understand how this is supposed to work with the envisioned modules.<br><=
br>thanks,<br>Martin<br><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_1130_358535811.1421434456056--
------=_Part_1129_933276557.1421434456055--

.

On 2015-01-16 13:54, Martin Ba wrote:
> On Friday, January 16, 2015 at 6:58:25 PM UTC+1, Gabriel Dos Reis wrote:
>> We ought to have the ability to separate the interface declaration from=
=20
>> the module implementation, since there can be several module=20
>> implementations -- e.g. consider bootstrapping.=20
>
> Sorry. I don't quite follow here what you mean by boostrapping wrt.=20
> "several module impl."?=20

For example:

- Utility.h (gives declaration of Utility class)
- UtilityBootstrap.cpp (implements Utility class)
- UtilityFull.cpp (also implements Utility class)

Bootstrapping would be e.g. building a tool that needs a minimal version
of itself to build the fully featured version of itself. The bootstrap
version would use UtilityBootstrap.cpp, while the full version would use
UtilityFull.cpp. Both would use Utility.h.

This also happens in abstraction layers (e.g. network =E2=86=92 SSL vs. Gnu=
TLS,
rendering =E2=86=92 GL vs. D3D, input handling =E2=86=92 X vs. SDL, etc.). =
An
implementation is selected at compile time, but many implementations are
available in the repository, but the interface is common/shared.

--=20
Matthew

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

.