Conditional compilation inside asm and enum declarations

Leandro Lucarella llucax at gmail.com
Tue Jul 14 19:28:44 PDT 2009


Walter Bright, el 14 de julio a las 14:52 me escribiste:
> Leandro Lucarella wrote:
> >The same goes for version (!X) ..., I think it should be available, there
> >are cases when the use is valid and you have to do artificial hacks like
> >version (X) else .... It's like Java not having functions or global
> >variable. You're just annoying people that know what they're doing to
> >"protect" the idiots (which can go and use static methods and variables
> >anyways; or version (X) else ...).
> 
> 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.
> 
> In C++,
> 
>    int a[5];
> 
> is the wrong way, and:
> 
>    std::vector<int>(5) a;
> 
> is the right way. C++ makes the right way ugly and hard. I'd like to
> reverse that.
> 
> All languages have some characteristics of "you shouldn't be allowed to
> do that", the problem is where the line is drawn.
> 
> 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.

I think you can always use it right when you have only one "#ifdef", and
when you see that it's getting messy, you can refactor your code to go the
way of "module personalities". If you can do that, the language can scale
up *and* down. Otherwise the language is only suitable for big systems.
Again, compare it to Java: for big systems is usually a good thing to use
an architecture with several layers and OO with very "hard" interfaces. In
Java you can only use that, you can't hack a quick script because it
doesn't scale down.

I think D should handle both worlds gracefully.

> I do the same as you, running the preprocessor independently on C code
> to figure out what's happening. That, however, would be problematic with
> D as it doesn't have a preprocessor. You'd have to build a separate tool
> to do it.

Again, people can make bad code in D anyways, you just make it a little
harder, at the expense of making a little harder to use version more
flexibly when it's right to do so (as Java make it harder to make a free
function or a global variable).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Wenn ist das nunstück git und slotermeyer? Ja!
Beiherhund das oder die Flipperwaldt gersput!
	-- Monty Python (no leer si sabés alemán)



More information about the Digitalmars-d mailing list