D
D
Daniil Demidko2016-04-11 03:39:42
C++ / C#
Daniil Demidko, 2016-04-11 03:39:42

Modularity in C++, what might it look like?

Read about planned modularity in C++. Specifically, I didn't find anything.
Who can explain how it will be?
After all, in fact - all .cpp files that are compiled and then linked together are also modules (and even Stroustrup has a chapter called "Modularity").
So what is planned to change?
Will modules be linked to the file system as packages like in Java?
Or will there be assemblies like in C#?

Answer the question

In order to leave comments, you need to log in

1 answer(s)
S
Stanislav Makarov, 2016-04-11
@Daniro_San

Java packages and Dotnet builds are about modules in terms of a large application structure, they have nothing to do with it.
We are talking about modules at the level of program code.
If you want to roughly understand how it will look - look, for example, at units in Pascal. This is approximately what they want to get in the end - the ability to humanly, at the language level, declare module interfaces, connect them to each other, monitor dependencies between modules ( except that C ++ modules do not seem to be tied to a compilation unit, as opposed to Pascal's units ).
Now in C++ this is achieved by a big hack at the preprocessor level(rather than the language compiler) called include files. This mechanism, based on the "many declarations, one definition" rule, is inherited from C and is essentially a replacement for the missing ability to pass metadata from one compilation unit to another when building a project. With the help of includes, you cram EVERYTHING that the compiler may need into one file. In fact, it turns out that most of the compilation unit after processing by the preprocessor is the contents of include files. And all this is processed by the compiler every time anew (in each compilation unit). In C, this is still all right, but in the pros, where many libraries contain heavy boilerplate code, it becomes quite sad. In addition, working with inclusions itself is not an easy practice, and if followed incorrectly, especially for beginners, they can get the most amazing errors from the compiler. You don't have to go far for an example - try not to set protection against multiple inclusion in a large project.
All this preprocessor magic does not add beauty and transparency to the language. While other languages ​​write "package foobar" and "import foobar", we write "#pragma once" or even "#ifndef FOOBAR_H ...". It's getting kind of sad.
The above in one sentence: modules want to be made real, instead of being imitated by means of a preprocessor.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question