C++1z and Header Files

[A-Man]

So there's been rumors C++1z will get a module system in a plan to silently kill the header file mechanism. Some say it won't make it in C++1z, but that there are plans to get it sooner or later into the standard. I like header files personally, despite the problems they cause (maybe just because I got used to them). What I fear is the leap happening so suddenly, and I get left behind with my projects following the then-old header file mechanism.

From the looks of it, it seems people have somewhat began moving already; with how I see template generic types being implemented in .h(pp) files only. I still follow the trend of the .h(pp) .cpp pair since that feels "healthier" for the current standards, but I'm always burdened with having to declare the class for every (combination of) template argument(s).

I don't know, I'm confused. How should I be doing it, and where's all of this going? What are some best practices of using .h(pp) files nowadays, and have anyone here got an idea on how this module system will likely work?

[NightmareX1337]

So there's been rumors C++1z will get a module system in a plan to silently kill the header file mechanism. Some say it won't make it in C++1z, but that there are plans to get it sooner or later into the standard. I like header files personally, despite the problems they cause (maybe just because I got used to them). What I fear is the leap happening so suddenly, and I get left behind with my projects following the then-old header file mechanism.

I want to point out that header files are not going to die, module system will most likely coexist with it cuz you know they can't just throw whole C++ code base out of hand. Unless... someone creates a magically good tool for auto conversion (and it's nearly impossible).

I don't know, I'm confused. How should I be doing it, and where's all of this going? What are some best practices of using .h(pp) files nowadays, and have anyone here got an idea on how this module system will likely work?

Read everything.

Also... Take a look at Dlang. It has that thing called module system, almost identical to C++ equivalents. It should give you an idea about it.

[A-Man]

I want to point out that header files are not going to die, module system will most likely coexist with it cuz you know they can't just throw whole C++ code base out of hand.

I wouldn't be so sure. I mean C++11 for example is backward-compatable for the most part, but there were few things which actually changed from how they were (eg, std:wap was moved from <algorithm> to <utility>). And if we're going to be getting modules, the who standard library will probably be used with that too.

But I'm not very much concerned about code working as much as the ease of getting things upto date later in the future.

Read everything.

Also... Take a look at Dlang. It has that thing called module system, almost identical to C++ equivalents. It should give you an idea about it.

I'm not unfamiliar with modules (I use python very often), but what I was asking was the inner workings of those. So far, to me, C++ with modules I feel would just be embedding functions and variables into namespaces. But this has a lot of implications for classes for example, and things may get quite messy with current code where one may need to do things like forward declaration. Unless things drastically change and C++ won't become C++ anymore, I imagine one will have to deal with ordering and pointer referencing still. In which case, I would really just imagine modules to be fancied ifdef define endif locks with a bit of automation behind the scenes, with probably too much restrictive computer intervention.

I didn't know clang already has something of that as an experimental feature! I'll try that out (and check relevant D docs), and hopefully my doubts will become cleared. Thanks for your time.

[NightmareX1337]

I wouldn't be so sure. I mean C++11 for example is backward-compatable for the most part, but there were few things which actually changed from how they were (eg, std:wap was moved from <algorithm> to <utility>). And if we're going to be getting modules, the who standard library will probably be used with that too.

That's way too small change compared to replacing file inclusion with modules. The whole world would need to adapt this nontrivial gigantic migration which is impossible to automate. C++ would be doomed. Even though it's a step in the right direction, it's just too big of a migration to be done without a proper backwards compatible depreciation phase.

I'm not unfamiliar with modules (I use python very often), but what I was asking was the inner workings of those. So far, to me, C++ with modules I feel would just be embedding functions and variables into namespaces. But this has a lot of implications for classes for example, and things may get quite messy with current code where one may need to do things like forward declaration. Unless things drastically change and C++ won't become C++ anymore, I imagine one will have to deal with ordering and pointer referencing still. In which case, I would really just imagine modules to be fancied ifdef define endif locks with a bit of automation behind the scenes, with probably too much restrictive computer intervention.

I'm going to tell you how modules work. It's dead simple:
Compiler reads the whole source files omitting implementation (function bodies), and creates a symbol table. Then a second read phase occurs and this time it actually gets semantically validated. Finally, real compilation happens and linking bla bla... You know the rest.

I didn't know clang already has something of that as an experimental feature! I'll try that out (and check relevant D docs), and hopefully my doubts will become cleared. Thanks for your time.

You're welcome.