4 ms·
Sigh, I knew someone was going to just complain that this is using the preprocessor and I'd have to waste more time on this... (a) It's a fundamental (but comm
by wfunction 9y ago
Sigh, I knew someone was going to just complain that this is using the preprocessor and I'd have to waste more time on this...
(a) It's a fundamental (but common) mistake to view processing as a logically "separate" stage from compiling C++ code. The two are semantically intertwined for all intents and purposes. Trivial example: the value of std::numeric_limits<int>::max() MUST match that of INT_MAX. Another trivial example: #pragmas (like omp parallel or vectorize) are "preprocessor" directives that can't really be "preprocessed"; they're often tightly coupled to the actual code. You cannot preprocess a program with a compiler that differs in any semantically visivle way from the actual compiler and expect the program to behave as the C++ standard specifies. The correct way to see a preprocessed file is as a convenient text-format snapshot/dump of the compiler's memory in the overall compilation process, nothing more.
(b) I don't want to spend more time on this but I'm pretty sure you could find a counterexample that doesn't depend on the preprocessor if you try hard enough. Just pretend I'm claiming the opposite and you're arguing with me about that, trying to prove me wrong. I'm sure you'll find a counterexample. Look at >> vs. > > and the like if you have no idea where to start.
- lorenzhs 9y agoI don't think we're disagreeing. All I meant was that if a critical error arises at a certain stage of compilation, errors that would only be detectable in a subsequent stage won't be emitted. This is in no way limited to this particular use case. Expecting it to continue isn't very realistic.