3 ms·

what's wrong with #define(s)?

by a-dub 5y ago

einpoklum 5y ago
The compiler is blind to them, so they can't be reasoned about / carried forward anywhere / allowed for in one way or another. Moreover, because of `#define`s, the effect of including a file can be entirely different, so a compiler can never say "Oh, I know what's in this include file already, I don't need to include it again in other translation units". Of course #define's have many uses, and at present cannot be avoided entirely, but C++ has been making an effort to have other mechanisms put in place so as to obviate the use of #define's In particular, look for CppCon talks about Modules.
- a-dub 5y ago
  interesting. so traditionally the preprocessor has been used to work around incompatibilities across various compilers/platforms and to completely enable/disable features at compile time. what's the new thinking there? can you build big projects across clang/g++/intel without preprocessor workarounds now? has the number of viable compilers in use dropped and compatibility amongst those that live on increased? how about stuff like debugging/instrumentation? or is the current thinking on all that stuff to always build with all of it and enable/disable via runtime branch? (along with some argument that configuration at build time was more trouble than it's worth on modern spacious/fast machines)?
  - einpoklum 5y ago
    > what's the new thinking there? In a nutshell: Using compile-time facilities which are within the language itself. Compilers will expose information about the platform, about themselves, etc. A couple of examples: * https://en.cppreference.com/w/cpp/utility/source_location https://en.cppreference.com/w/cpp/utility/source_location * https://en.cppreference.com/w/cpp/types/endian https://en.cppreference.com/w/cpp/types/endian > can you build big projects across clang/g++/intel without preprocessor workarounds now? Well, first of all, s/now/when C++20 is fully and widely adopted. Still, a good question. Possibly not? I'm not sure. But you would need a lot less of them than previously. > has the number of viable compilers in use dropped Not really. > and compatibility amongst those that live on increased? Well, if they're compatible with the standard, that says more than it used to. > how about stuff like debugging/instrumentation? Maybe if constexpr(in_debug_mode) ? Not sure. I'm not on the committee...

what's wrong with #define(s)?

by a-dub 5y ago

what's wrong with #define(s)?

The compiler is blind to them, so they can't be reasoned about / carried forward anywhere / allowed for in one way or another. Moreover, because of `#define`s, the effect of including a file can be entirely different, so a compiler can never say "Oh, I know what's in this include file already, I don't need to include it again in other translation units". Of course #define's have many uses, and at present cannot be avoided entirely, but C++ has been making an effort to have other mechanisms put in place so as to obviate the use of #define's In particular, look for CppCon talks about Modules.

a-dub 5y ago
interesting. so traditionally the preprocessor has been used to work around incompatibilities across various compilers/platforms and to completely enable/disable features at compile time. what's the new thinking there? can you build big projects across clang/g++/intel without preprocessor workarounds now? has the number of viable compilers in use dropped and compatibility amongst those that live on increased? how about stuff like debugging/instrumentation? or is the current thinking on all that stuff to always build with all of it and enable/disable via runtime branch? (along with some argument that configuration at build time was more trouble than it's worth on modern spacious/fast machines)?
- einpoklum 5y ago
  > what's the new thinking there? In a nutshell: Using compile-time facilities which are within the language itself. Compilers will expose information about the platform, about themselves, etc. A couple of examples: * https://en.cppreference.com/w/cpp/utility/source_location https://en.cppreference.com/w/cpp/utility/source_location * https://en.cppreference.com/w/cpp/types/endian https://en.cppreference.com/w/cpp/types/endian > can you build big projects across clang/g++/intel without preprocessor workarounds now? Well, first of all, s/now/when C++20 is fully and widely adopted. Still, a good question. Possibly not? I'm not sure. But you would need a lot less of them than previously. > has the number of viable compilers in use dropped Not really. > and compatibility amongst those that live on increased? Well, if they're compatible with the standard, that says more than it used to. > how about stuff like debugging/instrumentation? Maybe if constexpr(in_debug_mode) ? Not sure. I'm not on the committee...