'Sirisian' said:

Oh and one of my big gripes is malloc and free are annoying as hell to use with all their casting clutter.

If you need to cast, then you're trying to compile a C program as C++. My favorite idiom is:

touche. That's what I get for coding in C++ so much. I'm curious why my professor never questioned that.

I use C a fair bit to write libraries that get called from python code. (At times it can drift into the dreaded c/c++ bastardization mess, but I try to keep things to C for most parts. Some of the C++ standard library stuff is just too tempting. I really don't want to know just how badly a few of these libraries break if I try to port them.)

Right now, the current project I'm finishing up is about 60% C by Lines of Code, which seems to translate to something around 20-30% functionality as I look back at some of my documentation.

Lets add some fuel to the flames:

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

The list of plain indisputable pareto improvements over either is nearly endless. The list of drawbacks? The only significant one I can think of is foregoing an existing C++ codebase; but you can compile it into a DLL if you need to (or rewrite it in a fraction of the number of lines).

C code compiles virtually without modifications, but if you want you can for instance seemlessly integrate as much functional jazz in there as you want, in clean syntax, and all of it compiling to the same machine code as hand-rolled C loops. Or do full blown metaprogramming with the same power as C++, plus extras, minus the agonizing pain.

Im not saying boost::bind or boost::range are impossible to use; its just that you have to learn the whole template jungle by yourself anyway if you want to have any clue whatsoever how to debug your programs, or gain any insight as to why abstractions that are supposed to inline without overhead cripple your performance anyway. It makes a mockery of the encapsulation libraries are supposed to provide. That is, if you didnt give up in dismay right when your 100 line program took more than a minute to compile.

So there you have it: use D

Lets add some fuel to the flames:

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

The list of plain indisputable pareto improvements over either is nearly endless. The list of drawbacks? The only significant one I can think of is foregoing an existing C++ codebase; but you can compile it into a DLL if you need to (or rewrite it in a fraction of the number of lines).

C code compiles virtually without modifications, but if you want you can for instance seemlessly integrate as much functional jazz in there as you want, in clean syntax, and all of it compiling to the same machine code as hand-rolled C loops. Or do full blown metaprogramming with the same power as C++, plus extras, minus the agonizing pain.

Im not saying boost::bind or boost::range are impossible to use; its just that you have to learn the whole template jungle by yourself anyway if you want to have any clue whatsoever how to debug your programs, or gain any insight as to why abstractions that are supposed to inline without overhead cripple your performance anyway. It makes a mockery of the encapsulation libraries are supposed to provide. That is, if you didnt give up in dismay right when your 100 line program took more than a minute to compile.

So there you have it: use D

Decent toolchain? Maybe on *nix, but on Windows, AFAIK there are no really working IDEs with full debugging support, neither there are any user-friendly debuggers. Also, there are like five different build tools, because rather than trying to find a compromise, the already scattered opensource community is making a lot of forks. Just look how many dead projects are there on dsource.org.


I like D, but without a decent, open IDE, it won't gain any momentum.

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

Not enough.

In order for a major shift to occur, there needs to be a killer feature.

Tapes won over vinyl because they were robust.
DVD won over tape because they didn't need to be rewinded.
USB won over DVD because it's not mechanical.

Java won over C++ because of garbage collection.
Dynamic languages won over the web because they removed the need for compilation step.

Note that in all of the above cases there are plenty of examples of incremental improvement. Zip drive did not win since it merely improved on size of disk. Blu-ray or AudioDVD did not win because they do similar.

To improve, one must change some fundamental aspect, not just iterate on existing parameters.

The killer feature of C++ over C? Namespaces, either real ones or struct/class encapsulation. And little else.

But merely fixing what is broken or improving on individual parameters simply isn't enough.

C code compiles virtually without modifications,Virtually without? Or completely without?

What about C-with-classes, which represents huge portion of production code. And if that code compiles already, why would I now start with a new language that might or might not work?

A C++ which compiles virtually all code is fine. It takes no effort, one just switches the compiler parameter in build.
D code first needs to be rewritten, build needs to be rewritten, application must then be tested and finally, in addition to all the usual bugs, a whole new class of bugs appears from "almost compatible" code.

None of this adds anything at all to final product, it takes *years* away from time that could be spent on that. Even if that problem were solved, there is still the lack of the killer feature.

without a decent, open IDEThere is no IDE for PHP. Well, there are many, but most one can hope is some trivial syntax highlighting. It certainly hasn't hindered the adoption, in many ways it made language accessible since all one needed was notepad.

Decent toolchain? Maybe on *nix, but on Windows, AFAIK there are no really working IDEs with full debugging support, neither there are any user-friendly debuggers. Also, there are like five different build tools, because rather than trying to find a compromise, the already scattered opensource community is making a lot of forks. Just look how many dead projects are there on dsource.org.


I like D, but without a decent, open IDE, it won't gain any momentum.

Visual Studio integration works pretty damned smooth for me. Autocomplete could be better, but id rather get an imperfect cue instantly than a better one after waiting for ten seconds.

No complainst about the debugger. Its not perfect, but it beats trying to parse a boost template error any day of the week.

Not to say there is no room for improvement here, but its improved a lot recently.

'Eelco' said:

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

Not enough.

In order for a major shift to occur, there needs to be a killer feature.

Tapes won over vinyl because they were robust.
DVD won over tape because they didn't need to be rewinded.
USB won over DVD because it's not mechanical.

Java won over C++ because of garbage collection.
Dynamic languages won over the web because they removed the need for compilation step.

Note that in all of the above cases there are plenty of examples of incremental improvement. Zip drive did not win since it merely improved on size of disk. Blu-ray or AudioDVD did not win because they do similar.

To improve, one must change some fundamental aspect, not just iterate on existing parameters.

The killer feature of C++ over C? Namespaces, either real ones or struct/class encapsulation. And little else.

But merely fixing what is broken or improving on individual parameters simply isn't enough.

Considering the vast expanses of incremental improvement C++ leaves for the taking, id say it adds up.

That said, there are a few fundamental things D offers; such as a memory model geared towards mullticore processing, and somewhat related: support for immutable data and transitive const. Its going to win out against C++ in that regard bigtime as parralelism continues to increase in importance.

Most importantly, in my opinion, is that it manages to combine a wide spectrum of features, not yet found within the same box. That matters; a lot. Want to do to the metal programming? Stuck with C++ and friends. Want to do functional programming or otherwise not be driven insane by syntax that makes ASM look easy on the eyes in comparison? Crap, got to give up on the latter or split my project over several programming languages. Want to write safe managed code and be productive? Shit; yet another programming language in the mix.

That, or you use D, which allows you to take the best form these paradigms as it suits you, without trying to force some religion on you.

There is one feature I think it should envy, which is the fluid static/dynamic interfacing the .NET platform offers. Other than that, im really happy with it.

Java won over C++ because of garbage collection.

As a general statement that is just plain not true. In some industries, sure, but as a blanket statement, no way. I spent two years working in a Java shop, on large server software, and event here an integral task had to be delegated to C++[1] (nevermind maintenance tasks which were generally scripted in bash). Outside of the enterprise-bloatware world, there are still a lot of people using C++. In game development, C++ is still very much winning over Java.

[1] Ok, admitedly, we were doing some pretty specialized stuff, so most developers won't need to.

Java won over C++ because of garbage collection.

In in the areas where Java did win over C++, whether or not it was because of garbage collection is debatable at best.

Nice to see different opinions on C and C++. Thanks for all of the feedback!

I typically program in C, but mostly because I'm much more comfortable using it than C++ (I program in C at work, and I have a complete understanding of it). I have written some programs in C++, but it is usually slower since I'm trying to learn some new ways of doing things.

There are certainly advantages to using C++ when used right, but I don't always use it right, and often it will take me longer to do something in C++ I could've done much quicker in C.