------=_Part_2469_26358736.1367077117580
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I read N3347 (Modules in C++),

--------- IMPORT AS ----------

The one thing I was most interested in wasn't mentioned at all (unless I
didn't read it properly).

One of the neat things you can do in the Javascript world is write an
"anonymous" module of code, and import that bundle into a namespace of your
choosing.

That neatly eliminates much of the namespace collision issues (because the
consumer of the library determines the local namespace of the symbols), and
follows what the Python world has been doing.  Seems to be a successful
approach from where I'm standing (as a JS/Python dabbler).

I understand that there are likely many problems with adding this into C++,
but I was hoping for a bit of discussion on the topic.


------- .mpp files and header-only libraries -------

How are .mpp files going to work in the context of header-only libraries?
 eg most of boost.

As I understand it, .mpp files are generated from .cpp files, and the .mpp
files contain not just the interface, but also additional information
depending on the way the .cpp file was compiled.

So boost's code would consist mostly of .cpp files that were not yet
compiled, as the build environment is not yet known.

And if I wanted to use eg boost::msm (meta-state-machine) in two of my own
project's .cpp files with different build settings (eg template depth for
fusion<> vectors), I would have to somehow compile the msm.cpp files in the
two different files independently.

Another example is a header file library with #defines for switching
features on and off.

I guess that sort of thing could not (yet) be moved across to a module
world?   Or, do you somehow cache the results of the various configurations
that the msm.cpp is eventually compiled with ?    A bit like ccache, each
time you compile a header, it figures out what the preprocessor did to it
and then gives you the previously-compiled result.

cheers,
Paul

--

---
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/?hl=en.



------=_Part_2469_26358736.1367077117580
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>I read N3347 (Modules in C++),<br></div><div><br></d=
iv><div>--------- IMPORT AS ----------</div><div><br></div><div>The one thi=
ng I was most interested in wasn't mentioned at all (unless I didn't read i=
t properly).</div><div><br></div><div>One of the neat things you can do in =
the Javascript world is write an "anonymous" module of code, and import tha=
t bundle into a namespace of your choosing.</div><div><br></div><div>That n=
eatly eliminates much of the namespace collision issues (because the consum=
er of the library determines the local namespace of the symbols), and follo=
ws what the Python world has been doing. &nbsp;Seems to be a successful app=
roach from where I'm standing (as a JS/Python dabbler).</div><div><br></div=
><div>I understand that there are likely many problems with adding this int=
o C++, but I was hoping for a bit of discussion on the topic.</div><div><br=
></div><div><br></div><div>------- .mpp files and header-only libraries ---=
----</div><div><br></div><div>How are .mpp files going to work in the conte=
xt of header-only libraries? &nbsp;eg most of boost.</div><div><br></div><d=
iv>As I understand it, .mpp files are generated from .cpp files, and the .m=
pp files contain not just the interface, but also additional information de=
pending on the way the .cpp file was compiled.</div><div><br></div><div>So =
boost's code would consist mostly of .cpp files that were not yet compiled,=
 as the build environment is not yet known.</div><div><br></div><div>And if=
 I wanted to use eg boost::msm (meta-state-machine) in two of my own projec=
t's .cpp files with different build settings (eg template depth for fusion&=
lt;&gt; vectors), I would have to somehow compile the msm.cpp files in the =
two different files independently.</div><div><br></div><div>Another example=
 is a header file library with #defines for switching features on and off.<=
/div><div><br></div><div>I guess that sort of thing could not (yet) be move=
d across to a module world? &nbsp; Or, do you somehow cache the results of =
the various configurations that the msm.cpp is eventually compiled with ? &=
nbsp; &nbsp;A bit like ccache, each time you compile a header, it figures o=
ut what the preprocessor did to it and then gives you the previously-compil=
ed result.</div><div><br></div><div>cheers,</div><div>Paul</div><div><br></=
div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2469_26358736.1367077117580--

.