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