On Wed, Nov 26, 2014 at 10:46:08PM +0100, Andrej Mitrovic via Digitalmars-d wrote: > On 11/26/14, Adam D. Ruppe via Digitalmars-d > <digitalmars-d@puremagic.com> wrote: > > That's in the xterm source code. Yes, it depends on the presence > > of a particular include guard. > > Oh you should know how much trouble I went through when I was building > my C++ wrapping tool (initially just a wxWidgets wrapping tool). The > include stuff was 90% of the mess. So much frustration with *order of > inclusions*. It's probably *the* reason why I completely burnt-out on > continuing working on tool after several months.
Wow. I've only had the misfortune of having to deal with order-dependent #include's a few times in my life. I must live a sheltered life indeed! :-P I do agree that they are utterly evil, though. Even more evil is header files that compile successfully even if the #include's are wrongly ordered, but behaves differently (yes, I have actually seen this before): // some evil .h file: ... #ifndef someSillyStdLibMacro #define someSillyStdLibMacro myOwnBrokenImpl #endif So if you #include the system header that defines someSillyStdLibMacro, then you get the right behaviour, otherwise, the code still compiles but you end up using myOwnBrokenImpl instead, which inevitably does NOT work properly on your system 'cos, unsurprisingly, it was written for the author's own peculiar environment. Worse yet, the broken implementation only gets used in .c files that have the wrong ordering of #include's. Good luck debugging this nightmare! > I can't believe there are brand-new programming languages being > developed where the author(s) still insist(s) on textual inclusion. Wow. Textual inclusion is so 80's! Where've they *been* all this time?! > I'm sorry, but the detour you took with that simple decision causes an > insane mess for both the tools and the end-user, don't repeat the > mistake of C and C++ anymore, please! D's modules are a **massive > blessing**. Yeah, D's module system saves a LOT of headache, even in spite of its flaws. (Private imported module symbols conflicting with public symbols, anyone? Global scoped imports always being public? Local unscoped imports shadowing local variables (aka local variable hijacking)? Yeah, D modules could be better... but compared with #ifdef hell in C/C++, it's still orders of magnitude better.) T -- Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!