D programming

[Akkernight]

So a guy I know has started on D and tells me it's great, shows improvement to the old C language and I read that this is because C++ keeps backwards compatability, which has some costs, now I wanted to ask you peeps about this, and I really don't want people replying here who are ignorant and just say C/C++ is the best 'cause it is :P be pragmatic as the guy said...

Here are some links:

Comparison - D Programming Language 2.0 - Digital Mars
Overview - D Programming Language 2.0 - Digital Mars

The comparison page says that D doesn't support multi-inheritance which is true, but it uses some other techniques to do multi-heritance, so read up and don't only compare to the comparison page :P


Let's start positive; D is based on C++ and claims that it improves from C++ by not having the old C slow it down, which kinda makes sense. It claims to have a proven 10% better working efficiency, meaning that projects are by theory made 10% faster. And you can read more about it.

The negative part: D is new compared to C++ which is old and has been update to now and still will be, meaning it most likely has less flaws and more time to think about how the language should work/be implemented/whatever. There's more work for C++ programmers than there is for D, but without the programmers being open minded and not ignorant, this will never change :P There's more help to get with C++ and more resources to learn it.

These are some basics I know about.

Now start debating and be reasonable, I want open minded thinking, not ignorant thinking

[MK27]

Let's start positive; D is based on C++ and claims that it improves from C++ by not having the old C slow it down, which kinda makes sense.

Actually no it does not make sense. Ideally, C is faster than C++ and usually benchmarks that way, but ideally, C++ can be as fast as C. So C++ is not "slowed down" by it's C legacy; this is like say a language is "slowed down" because by legacy, it must at some point be translated into assembly. Possibly true, but not really, since there is no alternative. I suppose the question is how you turn it into assembly.

The difference between C and C++ is that C++ provides more tools to the programmer. That is all. It is does not improve performance, and NO ONE ever claimed it did. C++ is not, never has been, and never will be "faster" performance wise. It is just gives the programmer more choices about how to program. Write that out on the blackboard 100 times: "All C++ does is give the programmer more choices".

There's more work for C++ programmers than there is for D, but without the programmers being open minded and not ignorant, this will never change :P There's more help to get with C++ and more resources to learn it.

That's an excellent point (unless somebody does something, nothing changes); if you try and like and really believe in D, go with it. However, considering you just started school, etc, you may want to consider whether you can afford, at this point, to be pursing such (currently) obscure alternatives.

Now start debating and be reasonable, I want open minded thinking, not ignorant thinking

Okay, just keep in mind what I explained about the difference between C and C++. The slow part of C++ is the ++. All those features slow it down. If you are interested in a faster performing language, you would have to throw them both out (I suppose that is the D premise). HOWEVER, if all you want is fast, logic says you need less, not more; but at the same time, they seem to want a lot of new stuff (like garbage collection) in order to compete with newer languages like Java. Those are not "speed optimizations".

So, in fact, I say this is not really about speed at all. It is just another new language. It is about functionality. If you like the way the language works, it is good. Do not bother getting excited about it being "faster" -- if all people wanted was faster, new languages would not look like this (they are, in fact, getting slower but the hardware makes up for it, so we can afford more features, like resizable arrays* and various "safety features" for security, etc).

* of course, arrays have always been "resizable", it is a question of how much work that is for the programmer.

[anon]

I guess "slow" here measures programmer productivity: because C++ is designed to support (most) C code, it had to make compromises in language design that will slow down the programmer. As D did not set out to support C code directly, its language features could be such as to allow faster development.

That said, I haven't tried D myself.

[cpjust]

The difference between C and C++ is that C++ provides more tools to the programmer. That is all. It is does not improve performance, and NO ONE ever claimed it did. C++ is not, never has been, and never will be "faster" performance wise. It is just gives the programmer more choices about how to program. Write that out on the blackboard 100 times: "All C++ does is give the programmer more choices".

Well unless you start looking at things that make good use of templates like std::sort() vs qsort() in which case C++ is WAY faster than C.

[MK27]

I guess "slow" here measures programmer productivity: because C++ is designed to support (most) C code, it had to make compromises in language design that will slow down the programmer. As D did not set out to support C code directly, its language features could be such as to allow faster development.

As long as we don't confuse these two very different uses of the word "faster". In terms of development speed, there are already a ton of (mostly interpreted) languages that are way, way faster than either C or C++. But the cost of speed of development is bound to be speed of execution. Of course, today, in the professional world where real people must be paid to do real work, I think speed of development tends to be a much bigger factor.

I tend to work a lot in both C and perl and obviously, things like objects, hashes, dynamic typing, operator overloading, garbage collection, dynamic arrays, etc. are extremely labour saving but they are not necessary. Occasionally I will write something in perl, then once I have the general form of the thing finalized, rewrite it in C. I am pretty sure this actually saves time vs, if I started it in C in the first place, because of all the changes and playing around with form and function during "development". For example, regular expressions are very easy to use, but expensive. Once you know exactly what you want to do and where and to what, it is usually not hard to write a C routine without regexps to do that. Classes usually boil down to typedefs and functions. But writing a routine before you have done much testing and experimentation can mean having to spend hours reworking it over and over and possibly scrapping it, something that only takes minutes with perl. And who wants to admit that some function you spent all day on is now no longer going to be used?

I think the same could be said for some library functions, eg, you use them for convenience, but when you really want to optimize at the end, you can take the library right out and write some custom functions for exactly what you are doing.

Again, I think "evaluating D" will be a matter of functionality. One thing that just occurred to me is that there may be an advantage to not making everything built in, however...which I guess is a C++ approach.

Well unless you start looking at things that make good use of templates like std::sort() vs qsort() in which case C++ is WAY faster than C.

Yes, this is why it is called "quacksort" and is not really a standard function. Eg, with perl the standard sort was qsort for a while, then enough people demonstrated that it's speed is idealized and in reality often sub-optimal, so they went back to a merge sort algorithm which is a better general purpose method. "Sorting" is a great example of a generalized task that is bound to be done better if you DO IT YOURSELF. So when someone says "look at my library, it's faster" well, great, that's probably true, that's what libraries are for. It probably is not so much about the particular language as to being about a particular library. And if you know what you are doing, it might get done BEST without any library at all. This is why I am thinking too much built-in may be a bad thing for a compiled language that wants to be about execution speed.

[laserlight]

Yes, this is why it is called "quacksort" and is not really a standard function.

But it is, and interestingly, qsort() need not be implemented with quicksort, or at least it is not mandated by the C standard.

Eg, with perl the standard sort was qsort for a while, then enough people demonstrated that it's speed is idealized and in reality often sub-optimal, so they went back to a merge sort algorithm which is a better general purpose method.

That is interesting. Did they consider introsort?

"Sorting" is a great example of a generalized task that is bound to be done better if you DO IT YOURSELF.

That is true, but then it is generally true that many general algorithms can be optimised for specific situations better than a library can optimise than, if an expert implements it.

It probably is not so much about the particular language as to being about a particular library.

However, I think cpjust is really talking about a difference due to a difference in the core language. In particular, that compilers can optimise std::sort when it is passed a function object better than they can optimise std::sort when it is passed a function pointer, and likewise when qsort is passed a function pointer. Because of the lack of templates, it is less convenient to get the same kind of optimisation for a C library.

[MK27]

Here's an example of what I mean about the "built-in" drawback:

Why have strings built-in to the core language of D rather than entirely in a library as in C++ Strings? What's the point? Where's the improvement?

Concatenation Operator

C++ Strings are stuck with overloading existing operators. The obvious choice for concatenation is += and +. But someone just looking at the code will see + and think "addition". He'll have to look up the types (and types are frequently buried behind multiple typedef's) to see that it's a string type, and it's not adding strings but concatenating them.

Additionally, if one has an array of floats, is '+' overloaded to be the same as a vector addition, or an array concatenation?

In D, these problems are avoided by introducing a new binary operator ~ as the concatenation operator.

Well hurray! I guess you made things easier/more foolproof. Hopefully you did it well, because you're stuck with it now...and if you're not a fool, who cares? One pitfall in this is some languages use ".=" or just "." and some just "+", so now everything should be thoroughly confused unless all you ever do is program in D. Plus "~" is common with regexp in perl and elsewhere (=~).

But it is, and interestingly, qsort() need not be implemented with quicksort, or at least it is not mandated by the C standard.

That is interesting. Did they consider introsort?

I dunno. That is the whole story as I have heard it.

That is true, but then it is generally true that many general algorithms can be optimised for specific situations better than a library can optimise than, if an expert implements it.

Of course -- at least logically that should be true. How "expert" you need to be is context dependant, I think. What is most important is that you focus on a specific task, and skip unnecessary options and details.

C IMO is very very short on libraries and I would guess this is why (like, asm is probably "short on libraries" too). Perl has like 16000+ of them on CPAN. Hmmm....

However, I think cpjust is really talking about a difference due to a difference in the core language. In particular, that compilers can optimise std::sort when it is passed a function object better than they can optimise std::sort when it is passed a function pointer, and likewise when qsort is passed a function pointer. Because of the lack of templates, it is less convenient to get the same kind of optimisation for a C library.

Okay, I have heard of this, which only highlights the issue further: if you really want speed, write your own sort for the task. No function pointer, no templates, no unnecessary operations. I am pretty sure OOP also, by nature tends to involve unnecessary ops (altho no doubt this has been greatly addressed); as I said above, I'd rather play around with a class, but once the playing is finished and you are as chuffed as you can get with the elegance, etc, it is probably better done with plain ol' datatypes and functions...

[Akkernight]

I was talking about speed in productivity, that programmers can make projects faster, and I understood it so that it still keeps the speed of C++ :P
I was also told that collages or whatever are already starting D programming classes, so maybe D really has a chance

[cpjust]

If they had a Solaris compiler I might like to suggest it as an alternative to C++ at my company.

[Sebastiani]

Okay, I have heard of this, which only highlights the issue further: if you really want speed, write your own sort for the task. No function pointer, no templates, no unnecessary operations. I am pretty sure OOP also, by nature tends to involve unnecessary ops (altho no doubt this has been greatly addressed); as I said above, I'd rather play around with a class, but once the playing is finished and you are as chuffed as you can get with the elegance, etc, it is probably better done with plain ol' datatypes and functions...

Don't be too sure about that:

#include <iostream>
#include <algorithm>
#include <ctime>

using namespace std;

struct foo
{
    foo( int value = 0 )
    : value( value )
    {    }
    
    int 
        value;
};    

struct cpp_foo_compare
{
    cpp_foo_compare( foo const& lhs )
    : lhs( lhs )
    {    }

    inline bool operator ( ) ( foo const& rhs )
    {
        return lhs.value == rhs.value;
    }
    
    foo const&
        lhs;
};

int c_foo_compare( void const* lhs, void const* rhs )
{
    return ( ( foo const* )lhs )->value == ( ( foo const* )rhs )->value;
}

void* c_find( void const* data, size_t length, size_t span, int ( * compare )( void const*, void const* ), void const* value )
{
    unsigned char*
        ptr = ( unsigned char* )data;
    if( length % span != 0 )
        return 0;
    while( length-- )
    {
        if( compare( ptr, value ) )
            return ptr;
        ptr += span;    
    }
    return 0;
}

void cpp_test( foo const* data, size_t length, foo const* value )
{
    find_if( data, data + length, cpp_foo_compare( *value ) );
}

void c_test( foo const* data, size_t length, foo const* value )
{
    c_find( data, length, sizeof( foo ), c_foo_compare, value );
}

void hand_coded_test( foo const* data, size_t length, foo const* value )
{
    for( foo const* seq = data, * fin = data + length; seq != fin; ++seq )
        if( seq->value == value->value )
            break;
}

void test
( 
    char const* name,
    foo const* data, 
    size_t length, 
    size_t iterations, 
    void ( * function )( foo const*, size_t, foo const* ), 
    foo const* value 
)
{    
    clock_t
        start, 
        stop;
    start = clock( );
    size_t
        count = iterations;
    while( count-- )
        function( data, length, value );
    stop = clock( );
    cout << "Completed " << iterations << " iterations with function '" << name 
    << "' in " << ( double( stop - start ) / CLK_TCK ) << " seconds" << endl;
}
    
int main( void )
{
	size_t const 
		length = 1024, 
		iterations = 131072;
	foo 
		data[ length ];
	int
		target = 3114;
	data[ length - 1 ].value = target;	
	foo
		bar( target );
	test( "hand_coded_test", data, length, iterations, hand_coded_test, &bar );
	test( "c_test", data, length, iterations, c_test, &bar );
	test( "cpp_test", data, length, iterations, cpp_test, &bar );
	return 0;
}

On my machine the 'cpp_test' was fastest.

[MK27]

void* c_find( void const* data, size_t length, size_t span, 
         int ( * compare )( void const*, void const* ), void const* value )

Right so this is the exact same issue as discussed in the previous posts. By contrasting OOP to a more direct use "of datatypes and functions" I did not mean this or some generisized method of rendering class effects in C -- I did not even mean contrasting C to C++ to D or whatever -- I meant that given the time, a number of seperate possible functions works better here than one function that serves several possible roles. But this places more stress and labour in the hands of both the programmer who writes the routines and the one who uses them.

Which way do you want to write? I am not saying I'd prefer the later, but it is kind of a "I want my cake to eat it too" contest when you start discussing convience as performance advantage methinks. Maybe it will win! This seems to me a desire to avoid "subjective" discussions of "language design" and cower in an idealized world of dubious benchmarks and potentially over abstracted abstractions

I guess part of what got me going here was Akkernight's presentation of D being about "speed" and that

1) execution speed does not seem to be a particular goal of the project any more than any other PR work I have seen on a language.

2) by sticking to a C/C++ comparison, they effectively COMPLETELY DODGE the real issue of development "speed". AFAICT, this is like saying you get better gas mileage than a M1A tank.

Not that this writes anything off, I just think the most significant aspects of language design are avoided.

[Sebastiani]

I was just trying to prove that C++ doesn't inherently introduce "unnecessary operations" (and in fact can even be more efficient than a "hand-coded" implementation). The bottom line is that C simply doesn't have the proper facilities for writing generic, reusable software, and can never compete with C++ in that respect (nor D, for that matter). Not that you can't write decent software with C, but it's just much more difficult and a whole lot more work.

[MK27]

The bottom line is that C simply doesn't have the proper facilities for writing generic, reusable software, and can never compete with C++ in that respect (nor D, for that matter). Not that you can't write decent software with C, but it's just much more difficult and a whole lot more work.

Okay, we are on the same page there because I agree (more or less).