C++ Defence

[wysota]

I am not against what you wrote. I just say to ignore people who try to prove you something by stating they like something over something else. The fact that they like something doesn't yet mean it is better, regardless what reputation they have. If one likes C#, it's fine, as long as his software can integrate with mine and the project doesn't experience delays or limitations because of choosing one technology over another. The fact that C/C++ can integrate with practically anything lets me hope nobody will have problems when using code I write.

[krsmichael]

I am not against what you wrote. I just say to ignore people who try to prove you something by stating they like something over something else. The fact that they like something doesn't yet mean it is better, regardless what reputation they have. If one likes C#, it's fine, as long as his software can integrate with mine and the project doesn't experience delays or limitations because of choosing one technology over another. The fact that C/C++ can integrate with practically anything lets me hope nobody will have problems when using code I write.

So, I know Java, C# and C++. C++ IS my language of choice. If I want to script something, I use Python. I always find articles denouncing C++ interesting. Years ago, Visual Basic programmers used to do it. Then Java programmers used to do it. Now it is the C# guys spewing off about it. Quite simply C# suckeths in many ways and prevents programmers from doing things that make design sense. This is especially true when you add wpf to the mix. In C++, I can ALWAYS achieve what I set out to achieve. People say that C++ leads to messy code. I've seen equally messy code in Java and C#. Add a UI to Java and/or C# and you don't get best of breed. Swing looks like crap. The Eclipse UI looks better but doesn't look native on any machine. C# only runs on Windows...if you want a decent forms or wpf ui.

Flash has come out with Flex, which is cross platform, but again the widgets don't look native. I could go on...

The bottom line is if you want a fast, native looking app, there is only one game in town. QT and C++. (Yes I know about QTJambi)

In the end, the people whining about C++ are usually people who lack programming discipline. They aren't consistent in their programming methods so they need things like Garbage collection to clean up after them. They get tired of the crashes due to null or invalid pointers....but I can make C+# crash like that too. The will often choose operator overloading as proof of a bad language. I find it liberating. It is just all in how you go about attacking the problem.

I'd take the advice of not starting new programs with C+= with a grain of salt. I've rewritten Perl servers that could only address 2000 simulteneous connections with a C++ version that could handle 20000. I've rewrote a VB app that took two minutes to startup, in C++ and ATL that took less than 2 seconds to start up doing the same functions. Keep in mind that the originals were writtten by experts in those languages. People will tell you that machines are getting faster so why bother. The answer is because everyone loves a crisp responsive app.

[caduel]

I'd like to comment the often heard argument "if you write ugly programs in <insert any language> here, it is just lack of discipline...".
In my experience, lack of discipline is a very common character trait. And as I (and I assume all of us) must often work with (maintain, improvce, replace) code written by others, it is of no great help that *we* of course are as disciplined as one can only imagine, right? If the guy who originally commited the sin (s)he called a program just happened to have been way back in the looong queue when god handed out discipline to programmers, the code will suffer all kinds of (avoidable) problems.
Therefore languages used for "every day coding" should try hard to not to rely too heavily on things like "it is ok, you just need discipline", "this feature might be dangerous, so you should know what you do", or "here's a shotgun, try not to shoot yourself in the foot". Just like the famous red button with the sign "do not press"...
So, it boils down to: choose the right language for the task andthe personnel.
I am not saying C++ is bad, by the way. I quite like it. (Stil, there are lots of things I'd rather see changed.)
Still, I for my part have the shotgun rather locked away than in the kitchen. For those rare tasks that need the shotgun, I can deal with having to unlock the gun cabinet. (Again, this is not to say C++ is bad, and Java, C# or whatever to final solution. Any language has weaknesses and strengths. Just some have more of the former...)

just my 2ct

[wysota]

On the other hand if you throw out the shotgun, you might unlock as many cabinets as you want and still you won't find it there. I think this is the right place and moment to say, that often (not always, so don't take it personal) people who complain about C++ and potential risks it brings are (or are good candidates for becoming) "enlightened end users". People who were at DevDays know what I'm talking about There are no perfect tools - Java is potentially dangerous as well especially that it allows you to call arbitrary C code. C# uses libraries which are wrappers over non-managed code, so it can be considered dangerous as well. Eventually all code, managed or not, comes down to real compiled code which can be buggy, thus dangerous. Qt is not perfect as well (regardless of the language you use with it) and as we praise upon it, we have to be aware of its weaknesses.

The problem is not as simple as "language X is better than language Y". There are cases where X is better and others where you can't implement some functionality in it regardless how much you try. I'm sure you wouldn't implement an operating system in javascript, right? Does it mean C is better than javascript just because there are operating systems written in it?

[chaoticbob]

Hi,

Wanted to chime in on this interesting thread. Do you guys think that C++ just has a bad rep because it just has a bad rep? By this, I mean something along the lines of the misinformation about C++ floating around and gets spread around - sometimes through coworkers or sometimes through professors - or sometimes through ESR.

I remember talking to a friend some years back and he was complaining about std::string being slow. Now, I'm certainly not advocating that std::string is lightning fast - but for most practical purposes, it's probably fast enough. Anyway, I asked him why he thought it was slow. He said, "Well, because it's too big". This friend had been out of college for about 2+ years and had been coding at some company for that amount of time....using MFC. To make a long story less long - his understanding of how a C++ program was loaded into memory was based on his understanding of how Java does it - because Java was what he had learned in college. I don't know how Java does it, my point here is that based of some previous knowledge - he had made some assumptions about C++ that may or may not be correct. In some parts, I think it's just human nature and that a large portion of the population does this.

That being said, I've ran into guys and girls that have been coding for some number of years that have had similar explanations for various other aspects of C++. I also run into the really hardcore C guys that hate C++ because they just hate it. Reasons vary. Then there is the ObjC guys. Then the dudes that you guys mentioned already that new language XXXX will replace C++.

From my perspective, C++ is a complex language. But that's what I enjoy about it and I dont' think I'm alone. I've been getting into a lot of template meta programming lately and the doors that it has open is simply amazing. I remember a few years back discovering Boost, boost::shared_ptr changed the way I designed objects. I don't think a whole lot of people really look forward to this kind of stuff - they feel like it's an unnecessary burden. Good C++ coders seem to be a different breed from the rest.

There are also some stupid parts about C++ one of which is std::string does not have replace operations that is string based and not index + size based. Boost saves the day on this one. I can sort of see where some programmers frustration with C++ comes from, but it's hard to sympathize with them when the solution to their problem is a Google away.

[wysota]

I remember talking to a friend some years back and he was complaining about std::string being slow. Now, I'm certainly not advocating that std::string is lightning fast - but for most practical purposes, it's probably fast enough.

STL has many implementations and has been probably reimplemented a couple of times on a number of platforms during years, so its quality has greatly increased. At the beginning it was indeed slow, especially std::string. You have some ropes there and probably other classes that work faster for particular purposes so there is a way to overcome that. But your friend's opinion could have been based on the state of the art that was two years back.

I don't know how Java does it, my point here is that based of some previous knowledge - he had made some assumptions about C++ that may or may not be correct. In some parts, I think it's just human nature and that a large portion of the population does this.

Yes, but on the other hand it works both ways. People simply tend to project things they know onto planes they don't know assuming it has to be the same. This works exactly like that in case of Windows/Linux/name_your_OS_here problem.

There are also some stupid parts about C++ one of which is std::string does not have replace operations that is string based and not index + size based. Boost saves the day on this one.

In some situation Qt does it even better and QString indeed is fast compared to std::string.

Let's face it though - there are plenty of things that are easier to do in Java than in C++ Probably not because of the language itself (though that's probably true as well) but because of the whole code library that is available "out there".

[chaoticbob]

STL has many implementations and has been probably reimplemented a couple of times on a number of platforms during years, so its quality has greatly increased. At the beginning it was indeed slow, especially std::string. You have some ropes there and probably other classes that work faster for particular purposes so there is a way to overcome that. But your friend's opinion could have been based on the state of the art that was two years back.

True. I can't remember what specifically in his application he was complaining about - but I remember be a bit confused at how it could possibly be slow. I think it was a mail sorting application (as in snail mail). They used a lot of MFC, so it could be that he was comparing std::string against MFC's string class. Which to be fair - was probably faster than std::string at the time.

Let's face it though - there are plenty of things that are easier to do in Java than in C++ Probably not because of the language itself (though that's probably true as well) but because of the whole code library that is available "out there".

Right, but to echo some sentiments from the "discipline" argument, it seems to depend on how used to it you are. I find every time I have to do Java, I always end up making a "C++ mistake" in it. I don't think I'm alone in that.

[Brandybuck]

The old-school Unix hackers (like Eric) are biased, because there were no decent C++ compilers for Unix for a long period. It was considered a "Windows" language, and many hackers refused to use it.

C++ is a common, general purpose, mid-level, native code, object oriented language. There is no other language to replace it. All others are either obscure, specific, high level, require runtime environments, or aren't object oriented. This doesn't mean other languages are bad, it means that they cannot fill the role of C++.

[Brandybuck]

I've finally read through the comments at ESR's site. Once I got past the language bigots, the pontificators, and the trolls, the complaints against C++ seemed to be that it's complicated.

Yes, C++ is complicated. It may be the world's most complicated language (even beyond Ada in some respects). It doesn't help that many C++ "purists' advocate the complexity. That's why I like Qt, it keeps the C++ simple. Nearly everything has an ordinary OO structure. Templates are only used where necesssary, and only in a straightforward way. Compare Qt's signals/slots with Boost Signals, for example, and it's night and day. Or consider that Qt does not throw exceptions to the user. The purists will decry this, but while being easy to learn they can be very difficult to use in practice.

The only real contender for C++'s niche is Python. (I won't risk a flamewar by saying why I don't think Java qualifies). That's why Python is on my list of things to learn when I get the time. But just last Monday I was listening to a Python developer rant on about how his language was too high-level to give him the level of control he needed.

Combined with Qt, I can think of no other language I would rather use for desktop application development than C++.

[wysota]

Yes, C++ is complicated. It may be the world's most complicated language (even beyond Ada in some respects).

More than Lisp? Yeah, I know the language itself is easy, but parenthesis might kill you...

That's why I like Qt, it keeps the C++ simple. Nearly everything has an ordinary OO structure. Templates are only used where necesssary, and only in a straightforward way.

Good point. A nice follow-up to this statement is the article in Qt Quartely by Matthias Ettrich: http://doc.trolltech.com/qq/qq13-apis.html

Combined with Qt, I can think of no other language I would rather use for desktop application development than C++.

Python+Qt is a nice combination as well