Conditional compilation inside asm and enum declarations

Walter Bright newshound1 at digitalmars.com
Tue Jul 14 17:13:18 PDT 2009


Rainer Deyke wrote:
> Walter Bright wrote:
>> It's not about protecting idiots. It's about making the better way to do
>> things the easier and more natural way, and making the worse more
>> difficult.
> 
> Making the better way easy is a worthwhile goal.  Making the worse way
> more difficult is not.  A programming language should never set out to
> intentionally make things difficult for the programmer.

Why do C and C++ (and D) make it difficult to do:

    char *p;
    p |= 1;

? There's no implementation difficulty in accepting such and generating 
correct code for it. It's purely a matter of making what is generally 
considered to be bad practice harder to do. I've never heard anyone 
argue that this was a bad decision.


> A feature that
> is used in bad code now may eventually find use in new idioms that
> improve the overall quality of code in the future.

#ifdef's have been around for 30 years now. I think that's long enough 
for them to prove themselves.

May I remind everyone that D still does have conditional compilation. It 
isn't going away.


>> I have long, long experience with #ifdef's. I know how convenient it is
>> to just plop those things in, like your first hit of heroin. I know how
>> justifiable just that one little old #ifdef is. Then you add in another,
>> and another, and another, and another, and eventually wonder how you
>> wound up with such an impenetrable thicket of awfulness. My own code
>> gets like that (despite my knowing better) and just about every long
>> lived piece of C/C++/asm code I've run across.
> 
> When I encounter bad code, I often try to refactor it.  The overall
> trend is that the quality of my code improves over time.

We all make promises to ourselves to lose weight, too <g>.



More information about the Digitalmars-d mailing list