[language troll] D vs C++ vs C# vs Objectve C

ITT we post our opinions on which language is better at (performance || being object oriented || portability || whatever) and is the proper successor to C.

Well, first of all, I know next to nothing about Objective C, so I'm not going to talk about it. But here are my opinions:

In terms of performance, I would think (no, I haven't done benchmarks), that C++ would be the fastest, followed by D, then by C#.

C++ retains complete compatability with C code, and, having been around longer, its implementations are much more mature and optimised.

D adds a whole lot of extra features which, in theory, should slow it down somewhat more than C++ at runtime.

C# runs inside a VM (yes, I realise it's JIT'd), thus I'd expect it to be out-performed most of the time by the first two.


I'm not sure what you mean by "being object oriented", as all of these languages seem to support OO. A few differences come to mind though.

The question of allowing multiple inheritance has always been a big point of argument. C++ goes with multiple inheritance, whereas C# and D both go with a single inheritance model.

I see C++ as being more flexible in this regard, as it doesn't tie you down to one way of programming. Nobody is forcing you to use multiple inheritance if you don't want to, but having the option there is nice.

C#'s concept of properties is a great idea, as it is a solution to the ugly get/set pattern that you end up with in Java (why isn't Java included in this debate anyway? It and C# are practically clones of each other). They allow you to access data on objects in a natural way, you can even drop them in instead of a variable and you won't notice.


Moving on to portability: it depends what you mean. Generally, I see this as being one of two things: runtime portability, and compile time portability.

In terms of runtime portability, C# wins (thank you project mono!), as it is compiled to byte code, and runs on a VM not unlike Java.

Both C++ and D currently compile to native code, so for each new platform you want to run it on, you need to recompile.

So, in terms of compile time portability, I think C++ wins. One of the goals of C++ has always been portability. This is why the C++ standard library doesn't have things for graphics, sockets, useful stuff - to keep it portable. Both D and C# seem to only run on the most common platforms.


Another difference in these languages is memory management. D and C# offer automatic memory management. Most of the time, this is a great thing, as you just don't want to care about it. That said, C++ is very flexible, in that you can use or implement your own garbage collection if you want to. And of course, managing your own memory is almost always more efficient.

D offers you explicit control of the memory management, you can turn it off and do your own thing as with C++.

C# provides some basic control over the garbage collector, but nowhere near the power that D or C++ provide.


I realise I've barely scratched the surface, there are many more differences between these languages that I haven't mentioned at all.

"Successor to C" is an interesting statement, as both D and C# (and Java :E) are considered to be potential successors to C++, not C.

I think I'm leaning towards D, as it's a nice blend of some higher level concepts found in Java and C#, with low-level power and flexibility found in C/C++. D's biggest problem at the moment, is gaining inertia: not many people use it, so people are less likely to use it. It has to gain some sort of critical mass to really take off.

I hear Objective C mixes the syntax of C with the semantics of Smalltalk. I gotta try that shit someday.

C++ is a lot slower than most people think, because it's so complex you generally succumb to Greenspun's 10th law.

C# does not seem to represent a sufficient advancement to be worth all the fuss MSFT fanboys make about it. A couple of "advanced" (read: invented in the 60s) features and people are cumming in their pants. Reminds me of the idiots talking about cross-platform portability and garbage collection when Java came out.

D looks like a statically typed Python. The author is apparently a leet compiler author, and he's keeping his compiler closed in the hope that someone will buy it off him someday. He doesn't realise that these days a language without an open implementation doesn't proliferate fast enough to be competitive. Well not without a corporate marketing team behind it to take advantage of fanboys.

A couple of "advanced" (read: invented in the 60s) features and people are cumming in their pants.

It's amusing how almost all language advances we see in mainstream languages today come from that era.

>>1
The proper successor of C is C99, it only needs a serious standard library with real functionality (but you can use free portable libraries if you need to).

Performance: There's nothing better. A good C compiler will even do a better job than an assembly guru half the times, since optimizing code and pairing instructions got so hard to do by hand.

Being OO: I disagree that OO is the panacea of programming. I'd rather go for a multi-paradigm language, like C++--. Every problem has a different orientation and is best resolved with a different paradigm.

Portability: There's little more portable than properly written C code using portable libraries. After recompilation, it's as portable as Java, only way faster.

Whatever: I want C2005 standard libraries as comprehensive as Java's, but 1% as overly, stupidly, OOly complicated.

D looks very interesting. It'll need more popularity though, and the only way to get that these days is to make it public domain or something similar.

A good C compiler will even do a better job than an assembly guru half the times
More liek 99% of the time.

>D looks like a statically typed Python.
I'm trying to figure out Python (lol n00b porgrammer am i) so that sounds appealing.

>The author is apparently a leet compiler author, and he's keeping his compiler closed in the hope that someone will buy it off him someday.

There's a front end for GCC, I'd assume it has to be open source.

Which version of D is this? Do you know how many D's there are?

The proper successor of C is C99, it only needs a serious standard library with real functionality

Amen to that. I love C, but I really, really wish they'd make a new standard library. The current one is crufty, inconsistent, and dare I say both inefficient and dangerous. Considering that libraries are usually shared now days, it'd also be nice if it did a bit more than it does now.

Of course it'll never happen, so sooner or later it'll be RIP C. Thanks a lot, standards committee. You guys really do suck.

http://www.opend.org/

Copyright (C) The OpenD Team 2002.

It's dead, Jim.

>>9
Perhaps you or somebody else can say "fuck the standards commitee", and put together a series of open source, portable libraries like SDL and a C interface for ICU so we can call that "Community C2005". That would make MANY people happy and I'm sure hundreds of projects would want to rely on it.

I'd be happy if they just got rid of the shitty string functions and replaced them with something better. Null termination is kinda dumb if you ask me.

They should add PCRE as standard in there too.

Add Boehm's garbage collector in there too. People who want to do it manually can, while the rest of us can use the gc and get on with our lives.

That damn committee is driving C to the grave. Complex data types? Fuck me, man, there are bigger problems to solve first.

>>13
I always thought the same. Perhaps SDL+ICU (with a C interface too)+PCRE (new version with better Unicode support)-C strings (they're stupid, yeah)+revamped stdlib+bundled, but optional use garbage collector could do it.

Regex in C aren't as productive as they are in other languages because the PCRE API is complicated and painful to use sometimes, and the pcreposix API is inefficient (every time you call regexec, it'll do strlen() on the subject!) and incomplete. A better interface to PCRE would be welcome.

strlen() would be cheap if we got rid of null termination.

Actually, we wouldn't even need strlen(). Something like mystring.size would be enough.

>>17
Exactly. I had an idea for a solution but never got to implement it. It offers the following features:

- Fully binary string (may contain 0x00)
- O(1) strlen and many O(1) operations
- O(n) operations are still O(n)
- Direct access to characters with []
- Wide characters (you can also make a regular char version if you want)
- Fully dynamic allocation
- All operations which do not alter the string length do not require reallocation
- All operations which shrink the string could be done without reallocation
- Operations which expand the string will not always need reallocation
- You may very easily tune them for speed or memory consumption
- Some degree of direct C strings compatibility

An lstring is an allocated block of memory handled by a pointer that's not actually pointing to its beginning. It has a memory reserve for a certain length, plus a few bytes.

How to create an lstring: something like:
typedef wchar_t *lstring;
void *tmp;
tmp = malloc(DEFAULT_MAX_LEN + 2 * sizeof(int) + sizeof(wchar_t));
*(int *) tmp = DEFAULT_MAX_LEN; //This is the allocated length
((int *) tmp)[1] = 0; //This is the current length
lstring = (lstring) & ((int *) tmp)[2]; //Here's where the string begins
//our lstring pointer actually points to the beginning of the data, so we can
//still access its characters with [] :)
*lstring = 0; //We reserve an extra characer for a final zero.
//Our operations will never rely on it, but this makes for some C library
//compatibility if you want to do stuff like wstrupr and you are certain your
//string doesn't contain binary zeros.

Last time I was badmouthing C I was told there were some good string libraries out there. Apparently IBM has one.

Coincidentally I started hacking on one last night. Mine focusses more on safety and ease of use than efficiency though. It's just a struct that wraps an int and a char* and a bunch of operations for writing to it while doing bounds checking and auto-expanding. Which I guess is the same as yours, except you use a clever trick so that it can still be accessed with array syntax. I might rip that off, heh.

Where they both fall down is needing to malloc/realloc, which for a string-heavy program is going to be slow. It might be necessary to write a custom memory manager specifically to try to reuse strings as much as possible to avoid allocating new memory for every single string. I have no fucking clue how to do that though, it might be necessary to sneak a peak inside Python or something to see how it does it.

I would recommend that you grow your arrays exponentially rather than linearly, for speed. If you double the size of your strings every time they get full, you will only need a logarithmic number of reallocs. On the memory side of things, your strings will never be less than half full - which is good compared to, say, linked lists which never use /more/ than half their memory for data.

Yes, IBM has a (supposedly) superb library named ICU (although I believe it's for C++) with full Unicode support, which may be used freely. Then there's BString, without Unicode support, which does something similar to what we're saying.

You're right about exponentially increasing the size.

As for speed, I don't think we'd need a custom memory manager; even though realloc sounds horrendously slow from a C perspective, it's still faster than what every other language would do, and it wouldn't happen too often. For example, consider Java. Every time you want to do anything, even modify a character without altering the string's length, it just throws it away and allocates a new string. That's terrible, plus it's O(n) (because of copy). I don't think even Python, Perl or PHP would be faster than eventual, logaritmic reallocs.

I don't know how's realloc() implemented, and if it's going to copy the original block all the times; if it doesn't, then fine; if it does, then we might want to do something like malloc(new size), copy only the part of the string that's actually in use, copy data fields, free(old block), which would still be linear but a considerable optimization.

>>20
Java has a StringBuffer class which doesn't do that.

>>21
But isn't that a buffer, as in ugly and uncomfortable to hack with?

Java's Strings, AFAIK, are heavily optimised using flyweight programming. Even though it seems like you're creating new strings all the time, most of the time you're reusing old ones. In fact Java is exactly what I was thinking of when I wrote >>19

I made some benchmarks with them and found concatenation is indeed O(n), which is terrible. Because of this, I just couldn't compare them to C, Perl, JavaScript, etc. Then I wrote a different version using buffers, which is less comfortable and not a real string frontend, but at least it worked. Only then it was faster than Perl, but 4 or 5 times slower than C's BString library.

>>23 is right, and C# implements strings similarly.  That's why it's a bad idea to lock on a string.  If any other program running on that same instance of the virtual machine happens to lock on the same string, you've got a shared resource that probably wasn't expected and are begging for a deadlock.

So, what you're saying is strings in Java and C# suck. You probably can use other classes but they'll have a worse interface. Yay. Looks like C/C++ is not the only language without a perfect string implementation.

>>26

Generalizations like "they suck" are inaccurate most of the time.  Strings in Java and C# can actually be quite efficient due to their immutable nature and the underlying flyweight pattern.  Strings are relatively inefficient if you're performing lots of string manipulations, but then you can use the StringBuilder (or whatever it's called) which implements mutable strings.

They don't suck, they're just different.

If it's Java, then by definition it sucks.

Let the flamewar begin.

>>27
Immutable anything is IMO one of the worst ideas you could ever have. And yes, even bash "strings" are good, only not to be used too much. What I'm saying is Java's regular string operations have a terrible algorithmic complexity and, while Java's, and anything else's for that matter, work for "Hello world!" and setting an object's caption, they are terribly slow whenever you're doing anything serious with them, like parsing data (before Java addicts reply: no, not XML data, zomg).

Please don't turn this semi-interesting thread into another JOIN US! PERSONS WHO HATE JAVA!

To return to the original question.

I'm not sure about performance but Objective C probably loses if C# is smart about JIT compiling. C++ should win, but you never know.

C++ wins at portability, hands down. Its compilers are everywhere. C# and Objective C need their runtime support, and D is, well, just not very widely spread.

On the other hand, compared to the others C++ loses at object orientation. But it really is a multi-paradigm language and not strictly an OO language anyway.

Finally, the highest Whatever rating goes to D.

I doubt it. A large chunk of OS X uses Objective C. The C# proggies on windows are something of a joke, performance-wise.

If you want the best OO language, you'll have to look at all those weird languages with weird compilers. Obective Caml is said to be as fast as C once it's compiled. C# is a good language to me but I don't know how it compares to Java or D. And Objective-C is awesome to program Mac OS X but it's very slow with all those messages sent everywhere, you can only write the GUI components of your application in this language, don't use it for the engine.

Obective Caml is said to be as fast as C once it's compiled.

Almost, not quite.

That said, I'd like the language a lot more if it didn't have all these strange quirks. Ocaml wasn't created from the ground up, and it shows.

real programmers use standard ml

>>32 I've found C# to out perform a C++ and Java version of the same library. The library was originally ported from C++ to Java and then to C#. We were surprised by the results.

I've also heard talk of Java out performing C++ in some cases. But I haven't encounted it myself.

Chances are if you ported the C# library back to C++, C++ would be a lot faster. This doesn't prove much of anything.

This is a library which we currently sell on all three platforms. The Java version goes slower than the C++. The builk of the port from Java to C# was done using automated tools and the resulting code has not been restructured in any way between the three platforms. If anything the code is structured to favour C++ instead of Java and C#.

The library is CPU and memory intensive.

If anything the code is structured to favour C++ instead of Java and C#.

Not having seen the code, I can't question your experience. However, suffice to say, it contradicts my experience.

Tell me a bit about the automated tools.

Just the generic java2c# tools which MS provides with .NET.

We were surprised by the results.

I imagine that results completely dependent on the code in question. Still a single data point with C# being faster than C++ adds some value do the discussion.

test
test
test
test

test > test > test

> test

> test

[code]> test[/code]

[#]> test[/#]

>test

>test

test
test
test

test
test
test

test
test
test
test

test
test
test
test

test
test
test
test
test

test
test
test
test

test
test
testtesttest

test
test
testtesttest

test
testtest

testtesttest

> > > testtesttest

test
testtesttest

test
testtesttest

test
test
test
test

test
test
test
test
test

test
test
test
test
test

test
testtest

test

test[/o]

EXPERT