Native C++ vs. Managed languages (C#)

[julz]

Hello there,

There's a question that keeps running in my head, which I wanted to share with you.
I've always loved C, C++ and low level languages, like Assembly. I like to think that I stay
close to the processor and other devices. This is usually faster, and in my mind, easier to
understand.

But nowadays, languages such as C# and the .NET Framework are becoming more and more
popular, I've even heard about new processors which would run natively with .NET (need to confirm that). The problem with this kind of languages, is that you don't control everything
like you used to with C++. Of course, it might be easier not to bother about when allocating
and deallocating memory and things like that, but still... it feels like losing some control over
the machine.

So what do you think. Will C++ and low level languages "disappear" ? By that I mean,
become less and less popular and only be used for embedded devices, drivers, etc.
Or will C++ stay in the run with, for example, C++0x/1x ?

 

[Filip Larsen]

Both managed and unmanaged languages has their usage. However, to me it surely seems that a progressively larger mass of software developers end up being far more productive and with a higher quality when using a managed language. This is probably not just because it is managed but also due to many other benefits a managed language like C# and Java offers when used in a modern IDE.

While there no doubt are some people on the planet that are able to produce high-quality code in C++ it is by far the language in which I have witness the most nasty and hard to find bugs, most related to memory overflow or "loose pointers". As late as today I've witnessed the presence of a strcmp between type char * and type long being compiled just fine and released into production code with a resulting core dump that took many man hours to find and disrupted production service for a day. And I've seen similar environments that without as much as a warning compiles functions with a declared return type but without an actual return in the function body and classes with un-initialized member fields, both resulting in crash or, even worse, just "strange behavior". This is of course more of a compiler environment problem than strictly a language problem, but to me it indicate that perhaps C++ allows too much freedom for people to hurt themselves.

 

[Hurkyl]

As late as today I've witnessed the presence of a strcmp between type char * and type long being compiled just fine

That's not a compiler environment problem; that's an honest-go-goodness broken compiler. (Unless, of course, someone working on your project had the bright idea to write a strcmp function that took such arguments...)


Addendum: since C++ is supposed to work with C system headers, the C++ standard cannot make all the guarantees it may like. e.g. I don't have it handy to see if it insists that strcmp is a function rather than a macro. In the latter case, I don't think the standard can make any guarantees at all regarding type safety. So it's possible you have a working compiler, but it wasn't psychic enough to know that you weren't intentionally using a strange feature of a silly version of the C library.

 

[mgb_phys]

This is usually faster, and in my mind, easier to
understand.

And easier to understand what the computer is doing.

So what do you think. Will C++ and low level languages "disappear" ? By that I mean,
become less and less popular and only be used for embedded devices, drivers, etc.

We were asking the same question 10years ago about java, and 30years ago about lisp.

You can make C++ essentially managed, using object RAII design and smart pointers you never need to write another new/malloc/delete.

The problem with a lot of managed languages isn't the language so much as the framework behind it. In C and C++ you have a good idea what a strcmp() call is doing and there are no real side effects, in .Net or J2EE it could do absolutely anything.

We had one case where a programmer was trying to profile some code in Java, the code to subtract two timestamps was taking much longer than the function they were measuring. The Java time/date library was doing all sorts of locale and timezone conversion stuff we didn't know/care about simply to subtract two integers

It's called a leaky abstraction - see http://www.joelonsoftware.com/articles/LeakyAbstractions.html

 

[Mark44]

It's called a leaky abstraction - see http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Interesting article!