Mono Developers Regret Doing Moonlight In C++

[pepper_chico]

FUD

IMHO, this post if just FUD. Let's say regarding "better performance", "memory usage", ... it's comparing C++ with C. Off course, one won't expect to gain much if anything adopting one over the other. C++ is a language to that aims to allow *NO OVERHEAD* over C, but not *LESS OVERHEAD*. So... showing off that to diminish C++ has no point.

Let's say regarding "better performance", "memory usage", ... it's comparing C++/C over C#/Java/AnyCurrent-GC-VM-PL and that it's a bad choice in that regard. As of now, I don't see anyone in its right mind chosing the last when it's really necessary to have memory control and performance at hand. I mean, for cases when that's really necessary.

Just a few days ago didn't a microsoft employ talk about a new c# based language that gains in performance over plain c# because of tactics of precise memory management etc, generally found in C++, Rust, C etc, but generally missed in C#, Java, etc?

Also, currently C++ allows one do adopt many kinds of programming interfaces, one can abuse templates (some think of using that to gain runtime performance and slow compilation times... which I find suspicios), one can have functional style interfaces, expecting lambda arguments and the like, one can have C interfaces, whatever. So, talking a language is bad solely because a given library in that language doesn't particularly fulfill your expectations doesn't have any merit.

I'm not saying C++ is good or bad, I'm just saying I only see FUD in that post, and I'm generally convinced by better argumentation.

[AJSB]

Traditionally 2 types of bullshit(ters) have to follow after such an article: that C++ sucks or that it is better than C. In the Unix world the 1st type of bullshitters prevails, in the window$ world - the 2nd.

There's a 3rd kind....the ones that prefer BASIC-like language

They were born in the Dark Ages of C=64 and Sinclair ZX Spectrum


....yeah....i'm one of them

[lano1106]

one of C++ design principle is that you do not pay for features that you do not use. You can do C with C++ if you want.

Most C++ features can be implemented in a C program but most of the time, I'm willing to trade dev time, complexity and performance for builtin feature that are easy to use. Maybe C dynamic array management code are faster than STL vector but why would someone prefer to pepper boilerplate code all around the code when STL vector usage is clean and the performance edge that C would give isn't needed?

That is the theory. In practice, I have seen very ugly C++ code around. Like an hell of indirection across meaningless abstract interfaces, design patterns. I also hate a deep layers of shitty classes hierarchy but when the code is ugly, you can usually blame the programmer not the language. You know what, I have seen really really bad C code as well. C++ doesn't have monopoly in bad code department.

The other annoying part of C++ is that the C++ language can be so complex that there exist people tagged as language 'lawyers'. To my knowledge, only C++ has these annoying people that know everything.

At the end of the day, using C++ make my job fun and easier. I just avoid to overuse senselessly all the language possibilities and all is fine.

If a program performance sucks. Blame the programmer not the language.

[mrugiero]

I'm willing to trade dev time, complexity and performance for builtin feature that are easy to use

There is a single point that I find strange here, which is trading dev time for easy to use builtin features. Isn't the idea of using these to reduce dev time?
Also, complexity, but it's more that the term is ambiguous than something that sounds weird: I don't know if you mean the actual computational complexity (which may be increased by these features) or complexity as in how hard to read is the code, in which case I think it's pretty much the same thing, using easier constructs leads to simpler (in readability) code.

[wargames]

I would rather use Java with a bit of C for the critical parts (if any). C++ is probably the most hated programming language besides Perl, but that does not count as a programming language

[log0]

LOL. As the saying goes, a bad workman always blames his tools.

PS:
Another successful troll bait article. Yeah, you've got to feed your trolls Michael.

[bulletxt]

Oh my god, Paris Hilton's gossip is more interesting than this bullshit.

[GreatEmerald]

one of C++ design principle is that you do not pay for features that you do not use. You can do C with C++ if you want.

Not without it complaining very loudly.

That is the theory. In practice, I have seen very ugly C++ code around. Like an hell of indirection across meaningless abstract interfaces, design patterns. I also hate a deep layers of shitty classes hierarchy but when the code is ugly, you can usually blame the programmer not the language. You know what, I have seen really really bad C code as well. C++ doesn't have monopoly in bad code department.

I have worked on two C projects that I took over from previous developers. In both cases the C code was pretty horrible. The second case was even more horrible than the first case (at least in the first case they didn't do extremely unsafe pointer arithmetic all over the place, or store different type of data in an array than the one declared). Of course, that's not to say that C code is inherently horrible ? I have seen quite a bit of nice C code as well (just haven't worked with it a whole lot, unfortunately).

I prefer D, and I am yet to see a program in D that doesn't look beautiful (that's kind of the point of the language, actually). Of course, again, you can do much of the things you can do in C (except the exceptionally horrible and unsafe things), so I guess ugly D code does exist, but the language goes out of its way to provide all means to write clever and easy to understand code, which is rewarding in and of itself.

If a program performance sucks. Blame the programmer not the language.

Agreed. A lot of people argue that the GC in D is making it very slow, but then D is also used in performance-critical applications (advertisement bidding while pages load), so it's just a matter of knowing which functions are costly and which are not.

[lano1106]

There is a single point that I find strange here, which is trading dev time for easy to use builtin features. Isn't the idea of using these to reduce dev time?
Also, complexity, but it's more that the term is ambiguous than something that sounds weird: I don't know if you mean the actual computational complexity (which may be increased by these features) or complexity as in how hard to read is the code, in which case I think it's pretty much the same thing, using easier constructs leads to simpler (in readability) code.

thanks for the comment. Yes complexity in my post was ambigious. What I had in mind is with C++ features, it gets out of the way a lot of boilerplate code that the language takes care for you. Yes you can emulate RTTI, polymorphism and constructor/destructor with C but the cost will be a lot of lines of code. So let say this unnecessary boilerplate code represents 25% of the C code, this is adding 'complexity' to the task figuring what the other 75% does.

One of my favorite C++ idiom is RAII. This idom alone usually simplify a lot the code of a function and removes a lot of potential for future leaks.

Again, I understand where C++ bad reputation comes from. I have seen really bad code that made me swear. Writting readable C++ with good OO design is quite rare.

[DanL]

As the saying goes, a bad workman always blames his tools. Another successful troll bait article.

A "my language is better than yours" flamefest generates clicks and ad revenue! Throwing in the term 'Miguel de Icaza' is like throwing gasoline on the fire.