3 ms·

It's possible I don't understand the proposal and I'm probably going to get egg on my face and but I'm not sure I really want this. If I wanted Objective C or C

It's possible I don't understand the proposal and I'm probably going to get egg on my face and but I'm not sure I really want this. If I wanted Objective C or C# or Java or Python I'd use Objective C or C# or Java or Python. I actually like the preprocessor. I like that I can write code like this #ifdef DEBUG #define DEBUG_BLOCK(code) code #else #define DEBUG_BLOCK(code) #endif void SomeFunction(int a, float b) { DEBUG_BLOCK({ LOG_IF_ENABLED("Called SomeFunction(%d, %f)\n", a, b); }); ... do whatever it was SomeFunction does .. } In other languages that I'm used to there's no way to selectively compile stuff in/out. I like that I can change the behavior of a file for a single include unit -- foo.cc -- #include "mylib.h" -- bar.cc -- #include "mylib.h" -- baz.cc -- #define MYLIB_ENABLED_EXPENSIVE_DEBUGGING_STUFF 1 #include "mylib.h" because enabling it globally would run too slow I like that I can code generate // --command.h-- #define COMMAND_LIST \ COMMAND_OP(Stand) \ COMMAND_OP(Walk) \ COMMAND_OP(Run) \ COMMAND_OP(Hide) \ COMMAND_OP(Jump) \ // make enum for commands #define COMMAND_OP(id) k##id, enum CommandId { COMMAND_LIST kLastCommandId, }; #undef COMMAND_OP // --command.cc-- // Make command strings #define COMMAND_OP(id) #id const char* GetCommandString(CommandId id) { static const char* command_names[] = { #define COMMAND_OP(id) #id, COMMAND_LIST #undef COMMAND_OP }; return command_names[id]; } // make a jump table for the commands typedef bool (*CommandFunc)(Context*); bool FunctionDispatch(CommandID id, Context* ctx) { static CommandFunc s_command_table[] = { #define COMMAND_OP(id) id##Proc, COMMAND_LIST, #undef COMMAND_OP } return s_command_table[id](ctx); }; Or this class Thing { public: void DoSomething(); private: #ifdef USE_SLOW_LEGACY_FEATURE // needs access to Thing's internals. void EmulateOldSlowLegacyFeature(); #endif }; Yes, I can try to hide the implementation but again, the reason I'm using C++ is because I want the optimal code. Not a double indirected pimpl. If I wanted the indirection I'd be using another language. I love C/C++ and it's quirks. I use it's quirks to make my life easier in ways other some other languages don't. Modules seems like is ignoring some of what makes C/C++ unique and trying to turn it into Java/C# People saying the preprocessor has issues are ignoring the benefits. I miss the preprocessor in languages that don't have one because I miss those benefits. You could say, "well, just don't use this feature then" but I can easily see once a project goes down this path, all those benefits of the preprocessor will be lost. You can't easily switch your code between module and include, especially if it's a large project like WebKit, Chrome, Linux, etc. Leave my C++ alone! Get off my lawn!

shadowmint 14y ago
On a closer read of this proposal, I believe the key is in these lines: A module is a package describing a library • Interface of the library (API) • Implementation of the library That is, this will never replace the way you write applications. All it means is that there is an alternative way to depend on 3rd party libraries that improves compile time if that library supports it. If you're writing a library, you may choose to support it. I agree, if this was a proposal to remove #include, #define and #if, it would be doomed as a non-starter; that's simply not practical. I don't believe that it is though. Edit: Yes, I am saying that I believe this proposal is only practical for getting rid of public header files, the sort you'd find in /include/, and will have no impact on header files inside a single code base.
dietrichepp 14y ago
They're not ditching the processor, they're just making it so the preprocessor state is isolated for modules. You can still #define all you want, but it won't cross the boundary between your code and a module.
- fleitz 14y ago
  Which is pretty much how linking to a shared library works, your #defines and #includes have no effect.
  - dietrichepp 14y ago
    Well, no. If you make a #define it will affect code in the #include. This is why you sees puts defined as extern int puts(__const char *__s); The reason for the double underscore is so the definitions won't be affected if 's' is a macro.
msbarnett 14y ago
> You could say, "well, just don't use this feature then" but I can easily see once a project goes down this path, all those benefits of the preprocessor will be lost. You can't easily switch your code between module and include, especially if it's a large project like WebKit, Chrome, Linux, etc. It seems to me that that's the genius of this proposal: You can continue to use #include and the preprocessor where you feel it best serves you, because you can freely mix the two in the same compilation unit. It's fairly obvious when you're building things like your hypothetical command.h that you're going to base them on the preprocessor from the start, so the cost of moving from modules to pre-processor based solutions is irrelevant. And note that this proposal is not about removing macros, or removing the preprocessor, so your other two examples will continue to work in either scenario. Liking macros and the preprocessor is fine and dandy, but there's no need to force template-heavy code to continue to pay insanely high re-re-re-re-re-parsing costs ad infinitum simply to retain those features.

shadowmint 14y ago

On a closer read of this proposal, I believe the key is in these lines: A module is a package describing a library • Interface of the library (API) • Implementation of the library That is, this will never replace the way you write applications. All it means is that there is an alternative way to depend on 3rd party libraries that improves compile time if that library supports it. If you're writing a library, you may choose to support it. I agree, if this was a proposal to remove #include, #define and #if, it would be doomed as a non-starter; that's simply not practical. I don't believe that it is though. Edit: Yes, I am saying that I believe this proposal is only practical for getting rid of public header files, the sort you'd find in /include/, and will have no impact on header files inside a single code base.

dietrichepp 14y ago

They're not ditching the processor, they're just making it so the preprocessor state is isolated for modules. You can still #define all you want, but it won't cross the boundary between your code and a module.

fleitz 14y ago
Which is pretty much how linking to a shared library works, your #defines and #includes have no effect.
- dietrichepp 14y ago
  Well, no. If you make a #define it will affect code in the #include. This is why you sees puts defined as extern int puts(__const char *__s); The reason for the double underscore is so the definitions won't be affected if 's' is a macro.

msbarnett 14y ago

> You could say, "well, just don't use this feature then" but I can easily see once a project goes down this path, all those benefits of the preprocessor will be lost. You can't easily switch your code between module and include, especially if it's a large project like WebKit, Chrome, Linux, etc. It seems to me that that's the genius of this proposal: You can continue to use #include and the preprocessor where you feel it best serves you, because you can freely mix the two in the same compilation unit. It's fairly obvious when you're building things like your hypothetical command.h that you're going to base them on the preprocessor from the start, so the cost of moving from modules to pre-processor based solutions is irrelevant. And note that this proposal is not about removing macros, or removing the preprocessor, so your other two examples will continue to work in either scenario. Liking macros and the preprocessor is fine and dandy, but there's no need to force template-heavy code to continue to pay insanely high re-re-re-re-re-parsing costs ad infinitum simply to retain those features.