<div dir="ltr">Currently there is no "dotted path" (e.g. import std.algorithm, or whatever) import in C++; #include's are translated into it: try looking at -E with modules enabled.<div><br></div><div>You currently have to do everything through module maps; listing your header in a module map basically tells clang "I promise you this header meets certain assumptions of modularity" (which are really fairly reasonable assumptions; e.g. you aren't expecting a certain macro to be defined somewhere else in the code). Module maps also describe a "dotted import path", but that probably isn't going to be relevant for C++ for a long time. Currently Clang's diagnostics in the case where your header fails to meet those assumptions are not very good (by that I mean: really quite poor), but it is something that was recently discussed at the social and is recognized as an issue; you will primarily have to face this when actually writing your module map for the first time; after that, it should just transparently speed up your build.</div><div><br></div><div>I've attached a "minimal example" that should illustrate how it works.<br><div><br></div><div>And really, what is the difference between "#include <foo.h>" and "import mymodule.foo"? The real difference is that one can be used in your existing codebase (in conjunction with a module map) and give you real build performance wins for your real production C++ code right now (even if you have to support other compilers), and the other one a) isn't enabled now b) will probably not be what is actually standardized, and so will never work. How to organize the "dotted import paths" is a big bikeshed to paint (e.g. is std.string <string.h> or <string>? is it <a href="http://std.c.io" target="_blank">std.c.io</a> or std.c.stdio?) and ultimately the standard committee will be the one to decide for the standard library; in your own module maps for C++, I recommend focusing on making sure your headers are hygienic.</div><div><br></div><div>Right now, it is important to make sure your headers are "hygienic" so that they down the road, they can be composed into modules with nice "dotted import paths". Btw, you can get the build time improvements as soon as your headers are "hygienic".</div><div><br></div><div>-- Sean Silva</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 3, 2014 at 4:23 AM, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hello,<br>
<br>
SVN revision 218614 documented that C++ modules works in clang.<br>
<br>
Using the llvm apt repo on Ubuntu 14.04, I get this result:<br>
<br>
$ clang++-3.6 --version<br>
Ubuntu clang version 3.6.0-svn218873-1~exp1 (trunk) (based on LLVM 3.6.0)<br>
Target: x86_64-pc-linux-gnu<br>
Thread model: posix<br>
<br>
$ cat modules.cpp<br>
<br>
@import std;<br>
<br>
$ clang++-3.6 -std=c++1z -fmodules modules.cpp<br>
modules.cpp:2:1: error: expected unqualified-id<br>
@import std;<br>
^<br>
1 error generated.<br>
<br>
<br>
<br>
How do I try out clang modules support?<br>
<br>
Thanks,<br>
<br>
Steve.<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>