[OT] unbelievable: #ifdef _OTHER_LIB_H

[H. S. Teoh via Digitalmars-d]

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 at 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!