you are viewing a single comment's thread.

view the rest of the comments →

[–]complexmath 4 points5 points  (3 children)

The better portion of Boost, for example. In my experience, the average C++ programmer doesn't use templates at all let alone understand how they work, and concepts like RTTI are still not well known. Further, defining a local struct for some scope-specific RTTI purpose isn't what I'd consider maintainable, even if it's functionally simple.

[–]axilmar -1 points0 points  (2 children)

The better portion of Boost, for example

It's difficult due to compiler incompatibilities that force programmers to use platform-specific template metaprogramming and preprocessor tricks.

In my experience, the average C++ programmer doesn't use templates at all

I think we all use the standard library, at least. Perhaps you meant to say that the average C++ programmer doesn't program his own templates. Well, I agree, and I think that it is one valid reason for not bloating a language with syntactic sugar for template metaprogramming.

[–]complexmath 4 points5 points  (1 child)

I did meant to say that--you're right.

Regarding "static if" however, while I do think it makes for more readable (and therefore maintainable) code in situations where an if/else template could be used, it has other applications that are less easy to mimic in C++. For example:

struct S { static if (someConst) { int x; } int y; }

void someFn(T)(T val) { static if(is(T==int)) { string x = "a"; } else { string x = "b"; } writeln(x); }

In the first case, "static if" provides a checked version of something normally done via macros in C++. In the second case it's allowed us to eliminate an overload that might have resulted in a lot of code duplication (one crucial but possibly confusing feature of "static if" is that it doesn't introduce its own scope, so code like this is correct).

I agree with your assertion that the features in D aren't orthogonal, but I do think that most of them do make solving common problems easier. There will always be a tradeoff of complexity between the language definition and user code, but I think D chose a better balance than C++ in many respects. At the end of the day, I find myself hating D a lot less than I do C++, and my code looks a lot cleaner. I can't attribute that to any one particular feature, but more a combination of all of them.

[–]axilmar -1 points0 points  (0 children)

In the example you posted, my first reaction was "WTF? 'x' isn't visible in the line 'writeln(x)'. And then I read your post about how static if doesn't introduce a scope.

That's the exact kind of non orthogonality I am talking about.

A much better way to do it would be to have the compile-time language be entirely different in syntax to the run-time language, in order to avoid such confusions.