Is D more cryptic than C++?

[Timon Gehr]

On 11/30/2011 12:57 PM, Abrahm wrote:
> "Peter Alexander"<peter.alexander.au at gmail.com>  wrote in message
> news:jb4sjp$1dnr$1 at digitalmars.com...
>> On 30/11/11 6:30 AM, Abrahm wrote:
>>> I get the feeling that it is from reading the threads in here. Is
>>> there
>>> somewhere that has non-trivial D and C++ code that does the same
>>> thing,
>>> side by side, so that I can evaluate D better? Links if you got 'em
>>> please. Maybe even a small entire application would be good to
>>> download
>>> and perusal. This request really calls for code that is not part of D,
>>> so
>>> the D front end compiler and the like is inappropriate.
>>
>> If you care about non-trivial programs and want to compare D with C++,
>> here's all you need to know:
>>
>> No header files
>
> OK, but I was considering the syntax-level rather than the process-level
> things. Hence my use of 'cryptic'. I wasn't looking for an overall
> assessment of developing software with D vs. with C++.
>
>> - Seriously, this makes all the difference. Several times I have quit D
>> to go back to C++, then I remember header files. I use C++ at my day
>> job, so I am used to having to maintain header files, but if you switch
>> from D to C++, you WILL feel the pain.
>
> Having syntax-folding editors these days has caused me to lately leave
> everything in the C++ header files and only move code in .cpp  files when
> there are circular references or when I want to hide something from
> library USERS. IOW, let the compiler figure out that most of the code
> can't be inlined.
>
> Care to comment on how the "only header files in C++"strategy compares to
> "no header files in D"? Seems similar to me.
>

You can use interface files that just contain the relevant declarations, 
there is no "no header files in D" policy. But it is currently 
completely up to the programmer to keep header and implementation in 
sync. I haven't needed to use those so far, because the compiler is so 
fast that usually just rebuilding the whole project is quicker than 
trying to engage in a separate compilation model. I am not sure how 
large a project needs to grow until using a few interface files actually 
gives you a performance benefit.

>>
>> Range-based foreach for integral types
>> - foreach (i; 0..n)
>>    vs.
>>    for (int i = 0; i<  n; ++i)
>>    It's a small thing, but makes all the difference.
>
> Even more minor than you show above for C++11 has improvements over the
> traditional 'for' loop and the 'auto' keyword allows building similar
> constructs (haven't used my 'foreach' lately so I forget if it was just
> for containers, but probably).
>

This is about the best you can get in C++11:
for(auto i : iota(0,n)) {}

It is certainly more cryptic than
foreach(i;0..n) {}

It is a little bit longer too. This one of the constructs that occur 
most often in procedural code, so the few additional key strokes add up.


>>
>> Sorting on some member or member function.
>> - sort!("a.weight<  b.weight")(things);
>>    vs.
>>    sort(things.begin(), things.end(), [](Thing const&  a, Thing const&  b)
>> { return a.weight<  b.weight; });
>>    And that's if you're using C++11. Huge amounts of pain if you're not.
>>
>
> I don't think I like that. D's 'sort' is some kind of construct instead
> of a function? Not intuitive at all. Seemingly incorrect from a design
> standpoint (but I'm not thinking about it heavily).
>

D's sort is a template function, just like C++'s sort.
It is just that D templates can take string arguments and it is possible 
to generate D code from strings. This makes the D version more concise 
and less cluttered.

This is an alternative that uses a delegate literal (it solves a similar 
problem as C++11 lambda functions)

sort!((a,b){return a.weight<b.weight;})(things);