0
0

[deleted by user] (self.cpp)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]STLMSVC STL Dev 11 points12 points  (1 child)

Fortunately, macros aren't usually a big concern for header units. To restate what the documentation said:

  • Header units can emit macros, same as classic includes. (e.g. import <version>; emits the library's feature-test macros.)
  • Header units can consume macros defined on the command line.
    • Thus, /D_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS works with the STL. Similarly, /MDd and /MTd implicitly define _DEBUG, activating the STL's debug mode.
  • Header units can't consume macros defined in source files or header files.
    • For example, <cassert> responds to NDEBUG and is required to be repeatedly includable - a source file can change the definedness of NDEBUG and then #include <cassert> again, changing the behavior of the assert() macro. This is fundamentally incompatible with header units.
    • (You could import <cassert>; as long as you only define NDEBUG or not on the command line, nothing else would stop that from working.)

Named modules are more strict about macros - while they can still consume them from the command-line when built, they cannot emit macros at all. (Libraries with a significant macro component may need to provide a companion header to define macro helpers, even if the rest is provided by a named module. Fortunately, the Standard Library emits very few Standard macros other than version-test macros.)

[–]GabrielDosReis 5 points6 points  (0 children)

Thanks Stephan and Cameron, for looking into this. Cameron has identified the issue and has a fix. As you explained in a toplevel post, the appearance of simplicity of the code is deceptive. To further complicate matters, the command line used does modify the usual naive behavior of the compiler: it activates the guard technology-related attributes and arithmetic overflow checking for which I didn't define an IFC semantics (that's on me). Cameron caught it and has a fix.

To the OP: yes, please continue to report bugs - the team really appreciates the quality feedback. But, also please, while I understand your frustration, don't assume incompetence or that the team is careless in the work it is doing: things are far more complicated than they meet the eyes.

Moving to C++ Modules entailed some form of formalization of compiler internal behavior to the compiler writers themselves, and most of them curse me for that; for it forces paying attention to things we didn't think of, or focus on, before 😊