A couple questions about modules spec

[Rich Eakin]

Hi all, I've been following the progress of modules for C++17 and it is a very exciting addition. I have a couple questions that I haven't been able to resolve after skimming the spec and watching the latest cppcon talk:

• To avoid namespace clashes, are module aliases, like pythons 'import math as m' for example, planned or supported in some way?

• I see that we are advised to move away from using the preprocessor to take full advantage of modules. However, how are we expected to do this while writing compile-time, cross-platform code? For example, take this header that exposes an interface to boost::filesystem, while also using the std::tr2::sys on Windows if available.  Will this code just be broken when switching to modules? Another case is where we define the type of application (here) depending on what preprocessor macro has been set, so that the user has available to them platform-specific functionality at compile time. Will we be needing to redesign this as well, and if so is there any advice for how to make our library play well with modules?

Thanks,

Rich

[Gabriel Dos Reis]

Rich,

Modules are orthogonal to namespaces.  Namespaces in C++ span translation units, and therefore module units.

Do you have concrete examples of the kind of name clashes you have in mind to illustrate the question?

 

You can use header files to expose third party header files.  Conditional inclusion is valid (as ever) within any translation unit, including module units.

Letting macros from the outside into a module unit via import declaration is not the route to go.  That sort of things should be pushed back to the build system level where it belongs.

As implementations are rolling module support, I expect to see more and more affordable tooling around how we expose interfaces.  Like with any new technology, there is a learning period and we will all be sharing experience and knowledge – remember mid ‘90s with the STL? J

 

-- Gaby

 

--
You received this message because you are subscribed to the Google Groups "SG2 - Modules" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modules+u...@isocpp.org.
To post to this group, send email to mod...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/modules/.

[Rich Eakin]

Thanks for the thoughtful response.

On Fri, Dec 4, 2015 at 9:44 AM, Gabriel Dos Reis <g...@microsoft.com> wrote:

Rich,

Modules are orthogonal to namespaces.  Namespaces in C++ span translation units, and therefore module units.

Do you have concrete examples of the kind of name clashes you have in mind to illustrate the question?

Ah, so we will be declaring the module name and namespace separately?  I was thinking that modules would take the place of namespaces (similar to java in some respect) once they were introduced, but I see that is not the case.

 

 

You can use header files to expose third party header files.  Conditional inclusion is valid (as ever) within any translation unit, including module units.

Letting macros from the outside into a module unit via import declaration is not the route to go.  That sort of things should be pushed back to the build system level where it belongs.

As implementations are rolling module support, I expect to see more and more affordable tooling around how we expose interfaces.  Like with any new technology, there is a learning period and we will all be sharing experience and knowledge – remember mid ‘90s with the STL? J

To make sure I understand you correctly, would the following work within a module export:

module app;

export {

#if defined( __clang__ )

  typedef AppMac App;

#elif defined( __WIN32__ )

  typedef AppMsw App;

#endif

}

I hear you on the on using a build system to detect and use platform specific code, but in reality this is very often much more involved than using a preprocessor conditional, quick hacks with approaching deadlines included. So I am also trying to think through what we'll do about our various macros CINDER_MSW, CINDER_MAC, etc., whether we'll just have to stick with an #include for that.  Nonetheless, the advice is much appreciated during these times when we're planning how to arrange things in the future.

Best,

Rich