------=_Part_2154_1820834383.1449439223836
Content-Type: multipart/alternative;
 boundary="----=_Part_2155_939899347.1449439223837"

------=_Part_2155_939899347.1449439223837
Content-Type: text/plain; charset=UTF-8

I've read N4465: A Module System For C++, Rev 3
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdf> and
skimmed P0143R0: Wording for Modules
<https://isocpp.org/files/papers/p0143r0.pdf>, and I would like some
understanding on how we might expect build systems and compilers to
interact with *module-names* as defined by these documents in comparison to
how they currently interact with *header-names*.

Current implementations have opted to strongly assosicate a *header-name*
with the host file system in *very *useful way: header-names are
interpreted as a file path that is *relative *to a partially-configurable,
ordered set of directories. As a convenience, this set automatically
includes the parent directory of the file containing the #include
directive. This allows a developer to construct an arbitrarily-complex
directory tree of source files in which each directory or subdirectory
represents a component that *doesn't need to know* (specify) its own
location within the directory tree and need only specify *relative *paths
for its own subcomponents.

In contrast, modules (as I understand them) have names that are *global *to
the entire program, are always "looked up" in the same way everywhere in
the program, and submodules cannot be imported without explicitly naming
their parent modules, *even if the importer is a parent*. In other words,
the module "name space" is like the C++ namespace system except that you
always have to use *fully*-qualified names.

For example, a file in some large codebase that doesn't use modules might
look like this:

// --- Deathstar/Power/Reactor/Cooling/Controller.cc ---
//private headers in same directory
#include "ControllerInit.h"
#include "TransferWafers.h"
#include "ExhaustPort.h"
#include "FaultCodes.h"
....

But with modules it would have to "fully qualify" its own submodules:

// --- Deathstar/Power/Reactor/Cooling/Controller.cc ---
//private submodules
import Deathstar.Power.Reactor.Cooling.ControllerInit;
import Deathstar.Power.Reactor.Cooling.TransferWafers;
import Deathstar.Power.Reactor.Cooling.ExhaustPort;
import Deathstar.Power.Reactor.Cooling.FaultCodes;
....

Are we okay with this?

Also, I'm disturbed by the initial direction Visual C++ has taken with its recent
experimental support for modules
<http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx>:
it requires the developer to specify on the command line the location of
every "module interface file" (a compiler-generated, binary description of
the module interface) or parent directory thereof in cases where that file
does not reside in the same directory as the file importing it. This seems
like a *pointless burden* when all module names are program-global and
fully-qualified anyway. You might think that I could mitigate this
boilerplate by just shove them all into a single directory... except that
by doing so, I have traded one burden for another: now I have to ensure
that all of those files are named with their *fully-qualified* module name
in order to avoid name clashes. This severly violates the DRY
<https://en.wikipedia.org/wiki/Don't_repeat_yourself> principle because my
source directory hierarchy *already *describes the hierarchy of its modules
and submodules thereof.

So, what are the long-term expectations with regard to any build system
configuration/command line options in order to use modules? With include
files, we have to specify include directories, but doing so *actually makes
a difference*. With modules... what is there really to configure?

--

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

<div dir=3D"ltr">I&#39;ve read <a href=3D"http://www.open-std.org/JTC1/SC22=
/WG21/docs/papers/2015/n4465.pdf">N4465: A Module System For C++, Rev 3</a>=
 and skimmed <a href=3D"https://isocpp.org/files/papers/p0143r0.pdf">P0143R=
0: Wording for Modules</a>, and I would like some understanding on how we m=
ight expect build systems and compilers to interact with <i>module-names</i=
> as defined by these documents in comparison to how they currently interac=
t with <i>header-names</i>.<br><br>Current implementations have opted to st=
rongly assosicate a <i>header-name</i> with the host file system in <b>very=
 </b>useful way: header-names are interpreted as a file path that is <b>rel=
ative </b>to a partially-configurable, ordered set of directories. As a con=
venience, this set automatically includes the parent directory of the file =
containing the #include directive. This allows a developer to construct an =
arbitrarily-complex directory tree of source files in which each directory =
or subdirectory represents a component that <b>doesn&#39;t need to know</b>=
 (specify) its own location within the directory tree and need only specify=
 <b>relative </b>paths for its own subcomponents.<br><br>In contrast, modul=
es (as I understand them) have names that are <b>global </b>to the entire p=
rogram, are always &quot;looked up&quot; in the same way everywhere in the =
program, and submodules cannot be imported without explicitly naming their =
parent modules, <b>even if the importer is a parent</b>. In other words, th=
e module &quot;name space&quot; is like the C++ namespace system except tha=
t you always have to use <i>fully</i>-qualified names.<br><br>For example, =
a file in some large codebase that doesn&#39;t use modules might look like =
this:<br><br><span style=3D"font-family: courier new,monospace;">// --- Dea=
thstar/Power/Reactor/Cooling/Controller.cc ---<br>//private headers in same=
 directory<br>#include &quot;ControllerInit.h&quot;<br>#include &quot;Trans=
ferWafers.h&quot;<br>#include &quot;ExhaustPort.h&quot;<br>#include &quot;F=
aultCodes.h&quot;<br>...</span><br><br>But with modules it would have to &q=
uot;fully qualify&quot; its own submodules:<br><br><span style=3D"font-fami=
ly: courier new,monospace;">// --- Deathstar/Power/Reactor/Cooling/Controll=
er.cc ---<br>//private submodules<br>import Deathstar.Power.Reactor.Cooling=
..ControllerInit;<br>import Deathstar.Power.Reactor.Cooling.TransferWafers;<=
br>import Deathstar.Power.Reactor.Cooling.ExhaustPort;<br>import Deathstar.=
Power.Reactor.Cooling.FaultCodes;<br>...</span><br><br>Are we okay with thi=
s?<br><br>Also, I&#39;m disturbed by the initial direction Visual C++ has t=
aken with its <a href=3D"http://blogs.msdn.com/b/vcblog/archive/2015/12/03/=
c-modules-in-vs-2015-update-1.aspx">recent experimental support for modules=
</a>: it requires the developer to specify on the command line the location=
 of every &quot;module interface file&quot; (a compiler-generated, binary d=
escription of the module interface) or parent directory thereof in cases wh=
ere that file does not reside in the same directory as the file importing i=
t. This seems like a <b>pointless burden</b> when all module names are prog=
ram-global and fully-qualified anyway. You might think that I could mitigat=
e this boilerplate by just shove them all into a single directory... except=
 that by doing so, I have traded one burden for another: now I have to ensu=
re that all of those files are named with their <b>fully-qualified</b> modu=
le name in order to avoid name clashes. This severly violates the <a href=
=3D"https://en.wikipedia.org/wiki/Don&#39;t_repeat_yourself">DRY</a> princi=
ple because my source directory hierarchy <b>already </b>describes the hier=
archy of its modules and submodules thereof.<br><br>So, what are the long-t=
erm expectations with regard to any build system configuration/command line=
 options in order to use modules? With include files, we have to specify in=
clude directories, but doing so <b>actually makes a difference</b>. With mo=
dules... what is there really to configure?<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_2155_939899347.1449439223837--
------=_Part_2154_1820834383.1449439223836--

.

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

Am 06.12.2015 um 23:00 schrieb Chris Hallock:
> I've read N4465: A Module System For C++, Rev 3
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdf>
> and skimmed P0143R0: Wording for Modules
> <https://isocpp.org/files/papers/p0143r0.pdf>, and I would like some
> understanding on how we might expect build systems and compilers to
> interact with /module-names/ as defined by these documents in
> comparison to how they currently interact with /header-names/.
>
> Current implementations have opted to strongly assosicate a
> /header-name/ with the host file system in *very *useful way:
> header-names are interpreted as a file path that is *relative *to a
> partially-configurable, ordered set of directories. As a convenience,
> this set automatically includes the parent directory of the file
> containing the #include directive. This allows a developer to
> construct an arbitrarily-complex directory tree of source files in
> which each directory or subdirectory represents a component that
> *doesn't need to know* (specify) its own location within the directory
> tree and need only specify *relative *paths for its own subcomponents.
As useful as this association may be, not all file systems have file
paths, or use different punctuations for file hierarchies. So
technically #include directives aren't 100% portable. Granted, most
people will bever be exposed to such platforms directly in this day and
age, but if you're writing a library you never know who's going to use
it. Since modules lift referencing of external code to a
filesystem-agnostic abstraction the source code becomes 100% portable.
It is then a matter of the build system to locate modules.
>
> In contrast, modules (as I understand them) have names that are
> *global *to the entire program, are always "looked up" in the same way
> everywhere in the program, and submodules cannot be imported without
> explicitly naming their parent modules, *even if the importer is a
> parent*. In other words, the module "name space" is like the C++
> namespace system except that you always have to use /fully/-qualified
> names.
>
> For example, a file in some large codebase that doesn't use modules
> might look like this:
>
> // --- Deathstar/Power/Reactor/Cooling/Controller.cc ---
> //private headers in same directory
> #include "ControllerInit.h"
> #include "TransferWafers.h"
> #include "ExhaustPort.h"
> #include "FaultCodes.h"
> ...
I find this practice very dangerous. Where exactly the #include
directive searches for files is implementation-defined and depends on
the build environment settings. So there is potential for finding the
wrong file, especially when people configure include paths to be
recursive (also a very dangerous practice). Furthermore it is
susceptible to breakage if the source file is moved to a different
location. If you're unlucky it suddenly includes the wrong header,
compiles successfully, violates the ODR or whatnot, and demons start
flying out your nose. If you're less unlucky the build fails and you're
about to waste a lot of time figuring out why it doesn't include the
header you expect it to. That's why I always try to enforce the policy
of specifying the full include path starting from a certain base directory.
>
> But with modules it would have to "fully qualify" its own submodules:
>
> // --- Deathstar/Power/Reactor/Cooling/Controller.cc ---
> //private submodules
> import Deathstar.Power.Reactor.Cooling.ControllerInit;
> import Deathstar.Power.Reactor.Cooling.TransferWafers;
> import Deathstar.Power.Reactor.Cooling.ExhaustPort;
> import Deathstar.Power.Reactor.Cooling.FaultCodes;
> ...
>
> Are we okay with this?
I am. Considering this is common practice in Java, C# and other
languages with packages (where imports are absolute and declared before
specifying the namespace/package of the current file) people don't seem
to complain all that much. It's just safer to do so. Less chance of
hitting ambiguities.

Plus, one can go over-the-top with submodules. It's up to you to decide
whether a submodule is really warranted.
>
> Also, I'm disturbed by the initial direction Visual C++ has taken with
> its recent experimental support for modules
> <http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx>:
> it requires the developer to specify on the command line the location
> of every "module interface file" (a compiler-generated, binary
> description of the module interface) or parent directory thereof in
> cases where that file does not reside in the same directory as the
> file importing it. This seems like a *pointless burden* when all
> module names are program-global and fully-qualified anyway. You might
> think that I could mitigate this boilerplate by just shove them all
> into a single directory... except that by doing so, I have traded one
> burden for another: now I have to ensure that all of those files are
> named with their *fully-qualified* module name in order to avoid name
> clashes. This severly violates the DRY
> <https://en.wikipedia.org/wiki/Don%27t_repeat_yourself> principle
> because my source directory hierarchy *already *describes the
> hierarchy of its modules and submodules thereof.
You are aware that the VS implementation is preliminery, a proof of
concept, and very likely to change/improve as the standardization
progresses, right?
>
> So, what are the long-term expectations with regard to any build
> system configuration/command line options in order to use modules?
> With include files, we have to specify include directories, but doing
> so *actually makes a difference*. With modules... what is there really
> to configure?
As Gabriel Dos Reis explained in his CppCon 2015 talk the compiler has
to generate metadata for every module so it can be consumed by other
TUs. You still have to tell the compiler where these metadata files are,
especially when dealing with third party libraries.
> --
>
> ---
> 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/.

--

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

--------------030605070202080902020000
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">
    Am 06.12.2015 um 23:00 schrieb Chris Hallock:<br>
    <blockquote
      cite="mid:379589cb-4b7d-4f8f-9233-485379154cc8@isocpp.org"
      type="cite">
      <div dir="ltr">I've read <a moz-do-not-send="true"
          href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdf">N4465:
          A Module System For C++, Rev 3</a> and skimmed <a
          moz-do-not-send="true"
          href="https://isocpp.org/files/papers/p0143r0.pdf">P0143R0:
          Wording for Modules</a>, and I would like some understanding
        on how we might expect build systems and compilers to interact
        with <i>module-names</i> as defined by these documents in
        comparison to how they currently interact with <i>header-names</i>.<br>
        <br>
        Current implementations have opted to strongly assosicate a <i>header-name</i>
        with the host file system in <b>very </b>useful way:
        header-names are interpreted as a file path that is <b>relative
        </b>to a partially-configurable, ordered set of directories. As
        a convenience, this set automatically includes the parent
        directory of the file containing the #include directive. This
        allows a developer to construct an arbitrarily-complex directory
        tree of source files in which each directory or subdirectory
        represents a component that <b>doesn't need to know</b>
        (specify) its own location within the directory tree and need
        only specify <b>relative </b>paths for its own subcomponents.<br>
      </div>
    </blockquote>
    As useful as this association may be, not all file systems have file
    paths, or use different punctuations for file hierarchies. So
    technically #include directives aren't 100% portable. Granted, most
    people will bever be exposed to such platforms directly in this day
    and age, but if you're writing a library you never know who's going
    to use it. Since modules lift referencing of external code to a
    filesystem-agnostic abstraction the source code becomes 100%
    portable. It is then a matter of the build system to locate modules.<br>
    <blockquote
      cite="mid:379589cb-4b7d-4f8f-9233-485379154cc8@isocpp.org"
      type="cite">
      <div dir="ltr"><br>
        In contrast, modules (as I understand them) have names that are
        <b>global </b>to the entire program, are always "looked up" in
        the same way everywhere in the program, and submodules cannot be
        imported without explicitly naming their parent modules, <b>even
          if the importer is a parent</b>. In other words, the module
        "name space" is like the C++ namespace system except that you
        always have to use <i>fully</i>-qualified names.<br>
        <br>
        For example, a file in some large codebase that doesn't use
        modules might look like this:<br>
        <br>
        <span style="font-family: courier new,monospace;">// ---
          Deathstar/Power/Reactor/Cooling/Controller.cc ---<br>
          //private headers in same directory<br>
          #include "ControllerInit.h"<br>
          #include "TransferWafers.h"<br>
          #include "ExhaustPort.h"<br>
          #include "FaultCodes.h"<br>
          ...</span><br>
      </div>
    </blockquote>
    I find this practice very dangerous. Where exactly the #include
    directive searches for files is implementation-defined and depends
    on the build environment settings. So there is potential for finding
    the wrong file, especially when people configure include paths to be
    recursive (also a very dangerous practice). Furthermore it is
    susceptible to breakage if the source file is moved to a different
    location. If you're unlucky it suddenly includes the wrong header,
    compiles successfully, violates the ODR or whatnot, and demons start
    flying out your nose. If you're less unlucky the build fails and
    you're about to waste a lot of time figuring out why it doesn't
    include the header you expect it to. That's why I always try to
    enforce the policy of specifying the full include path starting from
    a certain base directory.<br>
    <blockquote
      cite="mid:379589cb-4b7d-4f8f-9233-485379154cc8@isocpp.org"
      type="cite">
      <div dir="ltr"><br>
        But with modules it would have to "fully qualify" its own
        submodules:<br>
        <br>
        <span style="font-family: courier new,monospace;">// ---
          Deathstar/Power/Reactor/Cooling/Controller.cc ---<br>
          //private submodules<br>
          import Deathstar.Power.Reactor.Cooling.ControllerInit;<br>
          import Deathstar.Power.Reactor.Cooling.TransferWafers;<br>
          import Deathstar.Power.Reactor.Cooling.ExhaustPort;<br>
          import Deathstar.Power.Reactor.Cooling.FaultCodes;<br>
          ...</span><br>
        <br>
        Are we okay with this?<br>
      </div>
    </blockquote>
    I am. Considering this is common practice in Java, C# and other
    languages with packages (where imports are absolute and declared
    before specifying the namespace/package of the current file) people
    don't seem to complain all that much. It's just safer to do so. Less
    chance of hitting ambiguities.<br>
    <br>
    Plus, one can go over-the-top with submodules. It's up to you to
    decide whether a submodule is really warranted.<br>
    <blockquote
      cite="mid:379589cb-4b7d-4f8f-9233-485379154cc8@isocpp.org"
      type="cite">
      <div dir="ltr"><br>
        Also, I'm disturbed by the initial direction Visual C++ has
        taken with its <a moz-do-not-send="true"
href="http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx">recent
          experimental support for modules</a>: it requires the
        developer to specify on the command line the location of every
        "module interface file" (a compiler-generated, binary
        description of the module interface) or parent directory thereof
        in cases where that file does not reside in the same directory
        as the file importing it. This seems like a <b>pointless burden</b>
        when all module names are program-global and fully-qualified
        anyway. You might think that I could mitigate this boilerplate
        by just shove them all into a single directory... except that by
        doing so, I have traded one burden for another: now I have to
        ensure that all of those files are named with their <b>fully-qualified</b>
        module name in order to avoid name clashes. This severly
        violates the <a moz-do-not-send="true"
          href="https://en.wikipedia.org/wiki/Don%27t_repeat_yourself">DRY</a>
        principle because my source directory hierarchy <b>already </b>describes
        the hierarchy of its modules and submodules thereof.<br>
      </div>
    </blockquote>
    You are aware that the VS implementation is preliminery, a proof of
    concept, and very likely to change/improve as the standardization
    progresses, right?<br>
    <blockquote
      cite="mid:379589cb-4b7d-4f8f-9233-485379154cc8@isocpp.org"
      type="cite">
      <div dir="ltr"><br>
        So, what are the long-term expectations with regard to any build
        system configuration/command line options in order to use
        modules? With include files, we have to specify include
        directories, but doing so <b>actually makes a difference</b>.
        With modules... what is there really to configure?<br>
      </div>
    </blockquote>
    As Gabriel Dos Reis explained in his CppCon 2015 talk the compiler
    has to generate metadata for every module so it can be consumed by
    other TUs. You still have to tell the compiler where these metadata
    files are, especially when dealing with third party libraries.<br>
    <blockquote
      cite="mid:379589cb-4b7d-4f8f-9233-485379154cc8@isocpp.org"
      type="cite">
      -- <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 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>
  </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 />

--------------030605070202080902020000--

.

------=_Part_2120_2087015131.1449460174084
Content-Type: multipart/alternative;
 boundary="----=_Part_2121_501426756.1449460174085"

------=_Part_2121_501426756.1449460174085
Content-Type: text/plain; charset=UTF-8

On Sunday, December 6, 2015 at 6:01:30 PM UTC-5, Miro Knejp wrote:
>
> Am 06.12.2015 um 23:00 schrieb Chris Hallock:
>
> I've read N4465: A Module System For C++, Rev 3
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdf> and
> skimmed P0143R0: Wording for Modules
> <https://isocpp.org/files/papers/p0143r0.pdf>, and I would like some
> understanding on how we might expect build systems and compilers to
> interact with *module-names* as defined by these documents in comparison
> to how they currently interact with *header-names*.
>
> Current implementations have opted to strongly assosicate a *header-name*
> with the host file system in *very *useful way: header-names are
> interpreted as a file path that is *relative *to a
> partially-configurable, ordered set of directories. As a convenience, this
> set automatically includes the parent directory of the file containing the
> #include directive. This allows a developer to construct an
> arbitrarily-complex directory tree of source files in which each directory
> or subdirectory represents a component that *doesn't need to know*
> (specify) its own location within the directory tree and need only specify *relative
> *paths for its own subcomponents.
>
> As useful as this association may be, not all file systems have file
> paths, or use different punctuations for file hierarchies. So technically
> #include directives aren't 100% portable. Granted, most people will bever
> be exposed to such platforms directly in this day and age, but if you're
> writing a library you never know who's going to use it. Since modules lift
> referencing of external code to a filesystem-agnostic abstraction the
> source code becomes 100% portable. It is then a matter of the build system
> to locate modules.
>

I fully agree.



> In contrast, modules (as I understand them) have names that are *global *to
> the entire program, are always "looked up" in the same way everywhere in
> the program, and submodules cannot be imported without explicitly naming
> their parent modules, *even if the importer is a parent*. In other words,
> the module "name space" is like the C++ namespace system except that you
> always have to use *fully*-qualified names.
>
> For example, a file in some large codebase that doesn't use modules might
> look like this:
>
> // --- Deathstar/Power/Reactor/Cooling/Controller.cc ---
> //private headers in same directory
> #include "ControllerInit.h"
> #include "TransferWafers.h"
> #include "ExhaustPort.h"
> #include "FaultCodes.h"
> ...
>
> I find this practice very dangerous. Where exactly the #include directive
> searches for files is implementation-defined and depends on the build
> environment settings. So there is potential for finding the wrong file,
> especially when people configure include paths to be recursive (also a very
> dangerous practice). Furthermore it is susceptible to breakage if the
> source file is moved to a different location. If you're unlucky it suddenly
> includes the wrong header, compiles successfully, violates the ODR or
> whatnot, and demons start flying out your nose. If you're less unlucky the
> build fails and you're about to waste a lot of time figuring out why it
> doesn't include the header you expect it to. That's why I always try to
> enforce the policy of specifying the full include path starting from a
> certain base directory.
>

Well, it's not that much more dangerous than using unqualified names in
deeply nested C++ code because the parent directory always gets first
priority for matches (if using the quoted form), regardless of specified
include directories. That is merely a convention at the mercy of
implementations, but it is a strong convention that is heavily relied upon,
so I'm too worried about it. However, if it wasn't for this priority
detail, then you'd be absolutely right: unqualified header names would be
horribly unreliable (it'd be analagous to *using-directives* overriding
local scope during name lookup).



> But with modules it would have to "fully qualify" its own submodules:
>
> // --- Deathstar/Power/Reactor/Cooling/Controller.cc ---
> //private submodules
> import Deathstar.Power.Reactor.Cooling.ControllerInit;
> import Deathstar.Power.Reactor.Cooling.TransferWafers;
> import Deathstar.Power.Reactor.Cooling.ExhaustPort;
> import Deathstar.Power.Reactor.Cooling.FaultCodes;
> ...
>
> Are we okay with this?
>
> I am.
>

Fair enough.


Also, I'm disturbed by the initial direction Visual C++ has taken with its recent
> experimental support for modules
> <http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx>:
> it requires the developer to specify on the command line the location of
> every "module interface file" (a compiler-generated, binary description of
> the module interface) or parent directory thereof in cases where that file
> does not reside in the same directory as the file importing it. This seems
> like a *pointless burden* when all module names are program-global and
> fully-qualified anyway. You might think that I could mitigate this
> boilerplate by just shove them all into a single directory... except that
> by doing so, I have traded one burden for another: now I have to ensure
> that all of those files are named with their *fully-qualified* module
> name in order to avoid name clashes. This severly violates the DRY
> <https://en.wikipedia.org/wiki/Don%27t_repeat_yourself> principle because
> my source directory hierarchy *already *describes the hierarchy of its
> modules and submodules thereof.
>
> You are aware that the VS implementation is preliminery, a proof of
> concept, and very likely to change/improve as the standardization
> progresses, right?
>

Absolutely. It is expected that a preliminary effort will have rough spots,
and we should also point them out and think of ways to polish them.



> So, what are the long-term expectations with regard to any build system
> configuration/command line options in order to use modules? With include
> files, we have to specify include directories, but doing so *actually
> makes a difference*. With modules... what is there really to configure?
>
> As Gabriel Dos Reis explained in his CppCon 2015 talk the compiler has to
> generate metadata for every module so it can be consumed by other TUs. You
> still have to tell the compiler where these metadata files are, especially
> when dealing with third party libraries.
>

I just would like to see the build system and/or compiler automatically
generate and consume whatever metadata it needs without hand-holding by the
developer, by default. The source files are already described in the build
system and they are sufficient to describe all module interfaces consumed
by that program. Interface files are merely a cached form of this
information, like a kind of object file. Being able to override locations
of interface files and their file names and where to search for them is all
well and good, but there should be sensible defaults at the build system
level.

--

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

On Sunday, December 6, 2015 at 6:01:30 PM UTC-5, Miro Knejp wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    Am 06.12.2015 um 23:00 schrieb Chris Hallock:<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">I&#39;ve read <a href=3D"http://www.open-std.org/JTC=
1/SC22/WG21/docs/papers/2015/n4465.pdf" target=3D"_blank" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2F=
www.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2015%2Fn4465.pdf\46=
sa\75D\46sntz\0751\46usg\75AFQjCNEU1T2l4Vi9T4f1fK4FQTO8WyV6GA&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%=
2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2015%2Fn4465.pdf\=
46sa\75D\46sntz\0751\46usg\75AFQjCNEU1T2l4Vi9T4f1fK4FQTO8WyV6GA&#39;;return=
 true;">N4465:
          A Module System For C++, Rev 3</a> and skimmed <a href=3D"https:/=
/isocpp.org/files/papers/p0143r0.pdf" target=3D"_blank" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2F=
isocpp.org%2Ffiles%2Fpapers%2Fp0143r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQj=
CNGjm5OLBlIaeiG7-MXh9hoHN9i3Rg&#39;;return true;" onclick=3D"this.href=3D&#=
39;https://www.google.com/url?q\75https%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers=
%2Fp0143r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGjm5OLBlIaeiG7-MXh9hoHN9i=
3Rg&#39;;return true;">P0143R0:
          Wording for Modules</a>, and I would like some understanding
        on how we might expect build systems and compilers to interact
        with <i>module-names</i> as defined by these documents in
        comparison to how they currently interact with <i>header-names</i>.=
<br>
        <br>
        Current implementations have opted to strongly assosicate a <i>head=
er-name</i>
        with the host file system in <b>very </b>useful way:
        header-names are interpreted as a file path that is <b>relative
        </b>to a partially-configurable, ordered set of directories. As
        a convenience, this set automatically includes the parent
        directory of the file containing the #include directive. This
        allows a developer to construct an arbitrarily-complex directory
        tree of source files in which each directory or subdirectory
        represents a component that <b>doesn&#39;t need to know</b>
        (specify) its own location within the directory tree and need
        only specify <b>relative </b>paths for its own subcomponents.<br>
      </div>
    </blockquote>
    As useful as this association may be, not all file systems have file
    paths, or use different punctuations for file hierarchies. So
    technically #include directives aren&#39;t 100% portable. Granted, most
    people will bever be exposed to such platforms directly in this day
    and age, but if you&#39;re writing a library you never know who&#39;s g=
oing
    to use it. Since modules lift referencing of external code to a
    filesystem-agnostic abstraction the source code becomes 100%
    portable. It is then a matter of the build system to locate modules.<br=
></div></blockquote><div><br>I fully agree.<br><br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        In contrast, modules (as I understand them) have names that are
        <b>global </b>to the entire program, are always &quot;looked up&quo=
t; in
        the same way everywhere in the program, and submodules cannot be
        imported without explicitly naming their parent modules, <b>even
          if the importer is a parent</b>. In other words, the module
        &quot;name space&quot; is like the C++ namespace system except that=
 you
        always have to use <i>fully</i>-qualified names.<br>
        <br>
        For example, a file in some large codebase that doesn&#39;t use
        modules might look like this:<br>
        <br>
        <span style=3D"font-family:courier new,monospace">// ---
          Deathstar/Power/Reactor/<wbr>Cooling/Controller.cc ---<br>
          //private headers in same directory<br>
          #include &quot;ControllerInit.h&quot;<br>
          #include &quot;TransferWafers.h&quot;<br>
          #include &quot;ExhaustPort.h&quot;<br>
          #include &quot;FaultCodes.h&quot;<br>
          ...</span><br>
      </div>
    </blockquote>
    I find this practice very dangerous. Where exactly the #include
    directive searches for files is implementation-defined and depends
    on the build environment settings. So there is potential for finding
    the wrong file, especially when people configure include paths to be
    recursive (also a very dangerous practice). Furthermore it is
    susceptible to breakage if the source file is moved to a different
    location. If you&#39;re unlucky it suddenly includes the wrong header,
    compiles successfully, violates the ODR or whatnot, and demons start
    flying out your nose. If you&#39;re less unlucky the build fails and
    you&#39;re about to waste a lot of time figuring out why it doesn&#39;t
    include the header you expect it to. That&#39;s why I always try to
    enforce the policy of specifying the full include path starting from
    a certain base directory.<br></div></blockquote><div><br>Well, it&#39;s=
 not that much more dangerous than using unqualified names in deeply nested=
 C++ code because the parent directory always gets first priority for match=
es (if using the quoted form), regardless of specified include directories.=
 That is merely a convention at the mercy of implementations, but it is a s=
trong convention that is heavily relied upon, so I&#39;m too worried about =
it. However, if it wasn&#39;t for this priority detail, then you&#39;d be a=
bsolutely right: unqualified header names would be horribly unreliable (it&=
#39;d be analagous to <i>using-directives</i> overriding local scope during=
 name lookup).<br>=C2=A0<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        But with modules it would have to &quot;fully qualify&quot; its own
        submodules:<br>
        <br>
        <span style=3D"font-family:courier new,monospace">// ---
          Deathstar/Power/Reactor/<wbr>Cooling/Controller.cc ---<br>
          //private submodules<br>
          import Deathstar.Power.Reactor.<wbr>Cooling.ControllerInit;<br>
          import Deathstar.Power.Reactor.<wbr>Cooling.TransferWafers;<br>
          import Deathstar.Power.Reactor.<wbr>Cooling.ExhaustPort;<br>
          import Deathstar.Power.Reactor.<wbr>Cooling.FaultCodes;<br>
          ...</span><br>
        <br>
        Are we okay with this?<br>
      </div>
    </blockquote>
    I am.<br></div></blockquote><div><br>Fair enough.<br><br><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#=
000000">
   =20
    <blockquote type=3D"cite">Also, I&#39;m disturbed by the initial direct=
ion Visual C++ has
        taken with its <a href=3D"http://blogs.msdn.com/b/vcblog/archive/20=
15/12/03/c-modules-in-vs-2015-update-1.aspx" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%=
2F%2Fblogs.msdn.com%2Fb%2Fvcblog%2Farchive%2F2015%2F12%2F03%2Fc-modules-in-=
vs-2015-update-1.aspx\46sa\75D\46sntz\0751\46usg\75AFQjCNH-MNQbBpJjG7C_raWU=
ZW7Sf8KE8A&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google=
..com/url?q\75http%3A%2F%2Fblogs.msdn.com%2Fb%2Fvcblog%2Farchive%2F2015%2F12=
%2F03%2Fc-modules-in-vs-2015-update-1.aspx\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNH-MNQbBpJjG7C_raWUZW7Sf8KE8A&#39;;return true;">recent
          experimental support for modules</a>: it requires the
        developer to specify on the command line the location of every
        &quot;module interface file&quot; (a compiler-generated, binary
        description of the module interface) or parent directory thereof
        in cases where that file does not reside in the same directory
        as the file importing it. This seems like a <b>pointless burden</b>
        when all module names are program-global and fully-qualified
        anyway. You might think that I could mitigate this boilerplate
        by just shove them all into a single directory... except that by
        doing so, I have traded one burden for another: now I have to
        ensure that all of those files are named with their <b>fully-qualif=
ied</b>
        module name in order to avoid name clashes. This severly
        violates the <a href=3D"https://en.wikipedia.org/wiki/Don%27t_repea=
t_yourself" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2F=
Don%2527t_repeat_yourself\46sa\75D\46sntz\0751\46usg\75AFQjCNGNSofze2ZUb7fX=
2AIR19oHZ70ZXw&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.g=
oogle.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDon%2527t_repeat_=
yourself\46sa\75D\46sntz\0751\46usg\75AFQjCNGNSofze2ZUb7fX2AIR19oHZ70ZXw&#3=
9;;return true;">DRY</a>
        principle because my source directory hierarchy <b>already </b>desc=
ribes
        the hierarchy of its modules and submodules thereof.<br>
     =20
    </blockquote>
    You are aware that the VS implementation is preliminery, a proof of
    concept, and very likely to change/improve as the standardization
    progresses, right?<br></div></blockquote><div><br>Absolutely. It is exp=
ected that a preliminary effort will have rough spots, and we should also p=
oint them out and think of ways to polish them.<br><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 bgcolor=3D"#FFFFFF" text=3D"#000000=
">
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        So, what are the long-term expectations with regard to any build
        system configuration/command line options in order to use
        modules? With include files, we have to specify include
        directories, but doing so <b>actually makes a difference</b>.
        With modules... what is there really to configure?<br>
      </div>
    </blockquote>
    As Gabriel Dos Reis explained in his CppCon 2015 talk the compiler
    has to generate metadata for every module so it can be consumed by
    other TUs. You still have to tell the compiler where these metadata
    files are, especially when dealing with third party libraries.<br></div=
></blockquote><div><br>I just would like to see the build system and/or com=
piler automatically generate and consume whatever metadata it needs without=
 hand-holding by the developer, by default. The source files are already de=
scribed in the build system and they are sufficient to describe all module =
interfaces consumed by that program. Interface files are merely a cached fo=
rm of this information, like a kind of object file. Being able to override =
locations of interface files and their file names and where to search for t=
hem is all well and good, but there should be sensible defaults at the buil=
d system level.<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_2121_501426756.1449460174085--
------=_Part_2120_2087015131.1449460174084--

.