Submitted by Eric Raymond is working on an essay, putatively titled “Why C++ Is Not My Favorite Programming Language”. In his announcement, he calls it “an overcomplexity generator”, “bloated, obfuscated, unwieldy, rigid, and brittle”, and alleges that these characteristics appear in C++ applications also. I contend that many of the complaints about C++ are petty or are aimed at specific libraries or poor documentation and that many of the features commonly regarded as unnecessary (and excluded from intended replacements) are, in fact, highly useful. C++: the Ugly Useful Programming Language
Despite it’s ugly syntax sometimes, I love C++.
Simple as that
Before you get rid of C++, how about developing a language (with appropriate libraries) to do everything C++ does, including the ability to code fast, tight, native applications that can run on multiple platforms, and which will allow you to code close to the metal if you would like.
And most importantly, must be 99% C-compatible.
My experience is, for a small application that doesn’t do anything the base class library doesn’t provide, C# is indeed much faster to code. But as the code complexity grows and you need access to some C API then C# really is a hassle.
Good C++ libraries (like boost, Qt, OpenSceneGraph, etc) does a lot to smooth out the development experience.
Edited 2008-10-11 17:26 UTC
Well D comes pretty close to what he’s looking for.
http://en.wikipedia.org/wiki/D_programming
Personally I have high hopes for Vala:
http://live.gnome.org/Vala
That’s the first project in years that has made me really excited.
I hope Vala goes somewhere myself as well. I like the tack they are taking with it.
Well, we have objective-c…
It is C, and then smalltalk came in and started influencing it to be object oriented.
“Come on kid, everyone’s doing it!”
Objective-C does not have too much common with C++ design goals.
Objective-C just adds a bit of smalltalk syntax over C. Whereas C++ extends C syntax while keeping low-level efficiency.
BTW, note that there is Objective-C++ too
The original request was to get something that you could do everything possible with C++ and still be C compatible.
I delivered
OK, but that applies to about any language
Anyway, if there is any feature that is really *unique* to C++, it is destructor.
It is extremely useful and not present in any other language (AFAIK).
I guess destructors are the real reason why I prefer C++
Particulary, there is nothing similar in Objective-C.
Edited 2008-10-11 23:24 UTC
C compatible? Since when can I take my c code and just run it through the perl interpreter? Python interpreter? Java compiler?
I can do that with my objective-c compiler.
You’re right there. I don’t rely on that often at all, though.
Edited 2008-10-11 23:34 UTC
Absolutely not. One of the core foundation of modern C++ programming is generic programming. And in C++ this is not implemented through type erasure, instantiation of templates actually lead to new types. Combined with specialization, this also offers metaprogramming, which can be used for doing everything from compile-time optimizations to creating domain-specific languages (e.g. see Boost Spirit).
The Standard Template Library (STL) is built on C++ templates. It provides generic containers and algorithms. Where many other languages add e.g. sort algorithms to list classes (which is not really a reusable approach), STL provides generic algorithms for every container that provides iterators.
So, two of the most important aspects of modern C++, templates and STL are missing in Objective. So, it’s not really a substitute. The only thing that probably comes close is D.
To be fair, you CANNOT use std::sort for every container that provides iterators – only for those that provide *random access* iterators.
In fact, I believe that the whole idea of ‘generic’ algorithms that apply to anything is somewhat moot – the only useful algorithms are those dealing with random access containers. And within those, only sorts and bounds are really important (about 5 total).
In fact, if you would just glue those as std::vector, std::deque methods, you would lose only a little…
While I really like C++, I am not huge believer into STL. IMO, Stepanov nearly killed the language…
STL and Templates are intentionally not part of Objective-C. That Dynamic Type/linking run-time is still missing from C++.
Well there are two different design principles. Objective-C followed the keep it simple principle while C++ followed the, lets take every feature there is on earth and press it into the language approach. The problem is, that the keep it simple approach always is superior. Java could have never taken off if not a huge number of projects simply failed on C++s inherent complexity! Java sort Next was able to pull of a decent component based system in time with ObjectiveC while most others had inherent delays (COM etc…) or failed entirely in their first incarnations (Project Pink from Apple and IBM) is a clear sign of the overcomplexity of the design. The funny thing is that the better C++ based systems basically follow the keep it simple principle and omit a huge load of the language to reduce themselves down to the sane core!
Yeah, right. I just fail to see what all of these “every feature in the world” are…
E.g. compared to Java, I only see that C++ supports operator overloading and multiple inheritance from regular classed (you can inherit from multiple interfaces in Java though).
Do not even start speaking about C#, it has many many more of “every feature in the world” in it.
Now considering Objective-C, C++ introduces class as extension to C based struct, while Objective-C introduces wholy new runtime concept. Now of course, Objective-C approach has its advantages, but if you are about to decide what approach is simpler, extending existing C feature has to win…
Objective-C may be simpler then C++, but it is also way more limited then C++. For example it is impossible to write a efficient vector class in Objective-C. In C++ you would to something like:
public class Vector
{
public:
Vector(double x, double y, double z);
Vector operator+(Vector v);
double operator*(Vector v);
…
}
In Objective-C it is just not possible to write light-wight classes. Every method invocation is a hashtable lookup. You can of course use C-structs but in my opinion this is also suboptimal.
Objective-C also does not offer operator overloading and templates which are quite useful for numeric stuff, just think about matrix multiplication.
In my opinion the scope of Objective-C is much more limited then C++, but for some things it might be the better language.
Objective-C may be simpler then C++, but it is also way more limited then C++. For example it is impossible to write a efficient vector class in Objective-C. In C++ you would to something like:
public class Vector
{
public:
Vector(double x, double y, double z);
Vector operator+(Vector v);
double operator*(Vector v);
…
}
In Objective-C it is just not possible to write light-wight classes. Every method invocation is a hashtable lookup. You can of course use C-structs but in my opinion this is also suboptimal.
Problem with this comparison is, to enable inheritance and polymorphism C++ translates every call into a virtual method table lookup….
Which is exactly the same a lookup map for methods!
Depending on the compiler you might get efficient code, but you cannot rely on it.
This is incorrect (or at least a little bit misleading, depends on what you mean by “inheritance and polymorphism”, emphasis mine). The virtual function table is only created for functions, that are declared virtual. Other, non-virtual class member functions are resolved statically [1], e.g. at compile time, so (apart from the – nowadays compareably small – abstraction penalties) there should be no loss of performance when calling non-virtual class member functions compared to procedural functions. There are situations, where the lookup process and/or the table introduce unacceptable overheads (esp. in numerical sensitive / scientific code, cf. [2] for a very good introduction to this problem set + examples how to avoid it ).
While the virtual function lookup is indeed the “default” way to introduce polymorphism to C++ class hirachies, there are first-class-citizen alternatives
available for situations where other approaches are more appropiate (static polymorphism via template engines, static polymorphism via Barton-and-Nackman type template voodoo, carefully designed class hirachies with helper-classes, etc.)
[1] http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20…
[2] http://ubiety.uwaterloo.ca/~tveldhui/papers/techniques/techniques01…
you mean like lisp? (most any lisp variant, even scheme)
hurray Lisp!
FPC:
http://www.freepascal.org/
Even java code runs native today. Is not interpreted so is misleading your “native” statement. The same about .net
I think you’re confused, kid. Java and .NET can run with some of their code compiled to native machine code at runtime, but that’s not the same thing as a language that compiles to native code. You still need the actual managed runtime environment (which is quite different than just linking a shared library) for Java/.NET to work.
Basically, with C/C++, you can write code that runs on a machine in which no existing runtime or standard library yet exists (assuming your compiler has a target for it), where-as with Java/.NET, you need to port millions of lines of code (which themselves are written in — wait for it — C and C++) over to the platform first.
No, you are the incorrect “kid”. You have obviously never hear of the GCJ implementation of Java, so perhaps you ought to do some more research. GCJ can be statically compiled to a single native binary with no runtime dependencies. I don’t know if there is a .NET equivalent, but Java certainly has this ability. It runs as fast as GCC (which, incidentally, is slower than the Sun implementation of Java).
I spent nearly a decade working with C++ but now use Java because:
1) it is (finally) fast enough (faster than C++ in many cases)
2) it is faster to develop
3) the (free!) tools are better
4) it runs everywhere (my customers have a variety of environments, from embedded systems to enterprise servers)
5) Memory isn’t that much of an issue (you can get cheap embedded platforms with 64 MB memory)
6) it has libraries that work on all platforms
and, most important of all
6) it is usually much easier to read Java code written by others than C++ (especially barely-skilled corporate programmers)
I’m guessing that most of the advocates of C++ are mostly reading code written by themselves and don’t have to read a lot of code written by other people. That is one area I’ve found Java usually beats C++. This is what I think the earlier poster saying C++ should be written like “Java” – alluding to a code style which can easily be followed by others.
Hear, hear! I have much more difficulty reading C++ code than C code (or C# code) because people define so much of their own stuff in C++ and you often have to jump around a lot to base classes, odd operator overloads, and template code (sometimes this is hard in a debugger).
that language already exists, it’s called Delphi…
http://www.codegear.com
Objective-C… as old as C++ but way superior!
Soundwave superior, constructicons inferior
.. over Java or .Net apps any day.
And I guess I am not alone
Whether it’s about CUPS or Fedora, all ESR does these days is spout ugly, venemous rants about what he hates, even when it’s rooted in nothing but some bad experience he had one day. No suprise he is doing it again.
I think you may be a bit unfair to him. Of course he must have been doing many other things lately too than only ranting…
I don’t know about the lasting worthiness of his earlier CUPS & Fedora rants, nor about his many and sometimes maybe a bit odd or at least uncoventional opinions on many other subjects ( http://catb.org/~esr/writings/ ) – but as for understanding the pros and cons of various programming languages, he seems quite a competent person indeed to talk about that subject.
In 2003 he wrote the book The Art of Unix Programming and he has written well-known and often quoted insigthful articles where he compares the pros and cons of various programming languages, based on his knowledge of at least two dozen programming languages:
– How To Become A Hacker http://www.catb.org/~esr/faqs/hacker-howto.html
– Why Python? http://www.linuxjournal.com/article/3882
You may, of course, disagree with him, but at least he has some good arguments and knowledge to support his opinions concerning the pros and cons of various programming languages, and to discredit his opinions concerning programming one should at least have better arguments than just to blame him for ranting.
Edited 2008-10-11 19:14 UTC
“The paper is developing primarily from a software-engineering perspective rather than out of formal language theory. I~Ac^AEUR^ATMm particularly looking for empirical studies on the importance of manual memory management as a defect attractor (I have the Prechelt paper from the year 2000). I~Ac^AEUR^ATMm also interested in any empirical studies comparing the productivity impact of nominative vs. structural vs. duck typing.” –ESR
It doesn’t sound like it’s going to be a rant. For the record, his rant on CUPS _was_ definitely a rant, but he was also right and CUPS got improved.
The bad thing about C++ is that it’s way too easy to program fugly code which no one can read now maintain. If – on the other hand – you have a bunch of good and experienced coders and software architects, you usually end up having code which looks very similar to Java (except that you can sum complex numbers with ‘+’ operator) but is fully native and can be fine-tuned for performance where it really matters. If you don’t believe this, just look at some Qt4 programs.
Saying good c++ code ends up looking like java is kind of offensive…I take strong offense to that.
About the only way I can see c++ code looking like java is if the project & code base gets grossly over engineered.
The biggest valid complaints I’ve seen about c++ is that it allows for far too many different dialects to exist, all based on what company you work for or who you work with (of course the dialect I used is the best :-p )
This is an extremely strong disadvantage in the context of what ESR is saying: open source programming. It is true that you can alleviate the over complexity of the language in a strongly controlled environment, with one coding style, the do and don’t. But in open source programming, this becomes an almost fatal flaw. Only really big projects can deal with C++ (KDE, mozilla).
Also, C++ does not tend well to code reuse; this is linked to the previous point , since it id difficult to reuse the code using one subset in a project using another one. It is difficult as hell to interface to other languages because of its complicated linking model, templates can’t be used either as a library without a lot of boilerplate. It is true that STL-like containers are useful, but it comes at such a high price that I am not so sure anymore a plain C library is not better in most cases.
This was even more the case when OO was all the rage, and developers went on designing deep class hierarchies just because they could.
This leading to the banana/gorilla problem.
For our embedded (bare metal) development, I have considered OCaml, Ada, Oberon, Pascal, then C++. In that order.
We ended up with C++, because the others failed us with big runtimes, complex cross compiling settings, and lack of host OS support (as in Linux, macosx, Windows etc) which was important since we don’t want to force an OS on the developers.
Control over memory allocation is hugely important too – our initial platform only has 32k of ram.
C++ did the job nicely, we have our own templated OS and drivers, and the result is small and efficient.
The only restriction is no RTTI and exceptions, because of the associated runtime.
If we get the opportunity, we’ll add the cxa_* funtions to our libraries so we can support exceptions.
So yes, C++ is a good workhorse. We just have to have very experienced developers who know how it works under the hood.
I just wish we had the time to participate in the OCaml or Ada efforts so that cross compiling is as easy as in C++.
Hm? What’s that supposed to mean?
If just want or need the banana, you will also get the whole banana tree complete with the gorilla that was inside.
Or: try to pull just the one or two classes you need. In the end, you’ll end up with the whole hierarchy linked into your program.
Idiosyncratic analogy IMO – but anyway, thanks for the explanation!
See the bolded text: this is true if you have developers that can’t wrap their heads around designing things for code reuse, and false for those that can. As to the linking model, it’s not so bad if you use C++ static functions and straight C interface wrappers (if needed) because C++ static functions use C style linkage, which is as close to universal as you’ll find overall. But, if you don’t know how to deal with that, then yes, it becomes a mess. Again, for code reuse, that’s very much a function (pardon the pun) of the design method (there’s another one!) of the developer and what attributes they use in their designs: if you try to use all the fancy features and make an overly complicated class hierarchy with multiple inheritance where each class in a hierarchy depends on other classes that depend on it (creating cyclic dependencies) then yes, that highly hinders code-reuse. Then again, there’s absolutely nothing in straight C that prevents you from screwing things up in the same manner, and for that matter, any language that allows you to use forward declarations is not immune to this (which most do as a practical matter): this is a limit of the developers using the language, and not the language itself. Spaghetti C++ code is just more obvious to see than spaghetti straight C code, but there’s more than enough snarled straight C code (as well as Java, Perl, etc.) to show it is hardly a C++ism that’s unique to the language.
That’s not the fault of the language, it’s the fault of the coder. Yes, I strongly believe that. F*cked up coders can generate unbelievably unreadable and unmaintanable code in whatever language.
Up to this day I code all my algorithm code in c++ (mostly computationally highly intensive image and video processing code, some heavily multithreaded) and if I can choose, then I choose it always before any other language, java and c# included.
Some say it’s bad, because it’s easy to make mistakes. Well, learn to avoid those mistakes then, fools, and believe me, those good practices will help you in the long term, and big time.
But He has a point here. C++ is the “Perl” of compiled languages… it’s huge and HORRIBLE… but It’s powerful and everybody uses it. It’s a fact.
I think they have to take a _small_ subset of the language and create a new one from that (100% compatible at compiler and binary level). Then name it C–, Cava or C* and profit.
The entire language itself is certainly huge, but I’d venture that the “working set” that most developers can use to be very productive* is really not so formidable, and that even with this subset of the language, resulting code is often smaller and with less “boilerplate” than the corresponding C. Self-discipline is obviously required, though; C++ gives you yards and yards of rope with which to hang yourself
* The LLVM guys, for instance, use what they call a “tasteful subset” of C++, and I’ve seen people who simply can’t understand why anyone would ever use C++ over C – a viewpoint very nearly diametrically opposed to mine, for the record – praise their approach and codebase.
Agreed. Most of the C++ in Syllable for example doesn’t use much more than basic classes, references and exceptions. You could do all of these things with nothing more than standard C, but doing it with C++ makes the code neater and more logical.
Best perl description I have ever heard was the rather famous blog post by steve yegge entitled “Tour de Babel”
He describes c++ thusly
I agree with pretty much his entire essay http://steve.yegge.googlepages.com/tour-de-babel
What would you strip out of C++ and what would you leave in?
If you avoid the really icky stuff like templates, use namespaces effectively and don’t make your classes stupidly complex, C++ is about as bad as any other language I.e. not bad at all.
Oh and streams also suck a bit, but that’s just my own personal thing.
Templates and streams (and the STL containers) are 2 of my favourite features. The fact that you don’t use them is fine with me and it also highlights just what is special about C++.
In C++ you get all the _options_ and you can code the way you prefer without having a paradigm shoved down your throat.
Edited 2008-10-11 22:15 UTC
Streams are horrific. Trying to handle internationalization of “grammar” concepts utterly breaks streams to hell, which is where they should go back to.
If anything STL’s iterators & algorithms are extremely powerful, amazingly so. c++0x takes this power a step further with lambdas and other things.
The collections…well they are okay but definitely show how utterly obfuscated hackers can make their code. At least they aren’t c macros.
Edited 2008-10-12 05:28 UTC
Templates are great, but template syntax is awful. I’ve also yet to see streams used effectively anywhere: after their first C++ “Hello world” most coders seem to just avoid them.
Personally, I find the << syntax for putting data into a stream really logical and intuitive. The text or data to the right looks like it’s being “sent to” the object on the left. The only problem is that a lot of teachers and books don’t explain properly how this works – my teacher just said, “oh, it’s an overloaded operator” and didn’t tell me what that meant.
Well, in theory stream are nice in practice for text handling they’re not so good: bnolsen is right, for internationalisation streams suck.
And I would add that they’re much too verbose.
Not that printf is ideal: in C it’s untyped (but this is fixed in D), and arguments are too far for the text so it’s too easy to make mistakes..
Ruby puts with printf format would be ideal.
(enough said)
– Gilboa
….as with everything else in life, it doesn’t have to be pretty in order to work well.
I do not like the “I-know-everything-about-everything-and-I-can-hate-it” tone in the texts ESR writes. He seems to be a software critic, and like almost all critics, he can bash on a picture with no knowledge about painting…
I love C++, it is IMHO one of the few languages that lets me program in the bare metal and provides me a higher abstraction level (OOP, template metaprogramming, etc.)…
I cannot do object programming or generic programming in C (~Af^A la GTK+ is not a much viable solution) and using a higher level language (Java, C#, etc.) is not doable (or is not the easiest solution) when you are developing systems or commercial applications (let’s be honest, there is no a software with the same quality, functionality and performance to Microsoft Office or to Adobe Photoshop written in Java or C# or Python… and because their huge dimensions, they are not written in C neither, they are C++ code).
I agree Stroupstroup comments when he says the problem is not in C++, but in the low-skilled programmers…
There are tons of big commercial applications written in Java. In fact, I prefer ThinkFree Office (100% Java/Swing) over Ms Office any day.
I wish that were the case but the problem is that there are still some JNI components involved in it. I was hopeing to be able to run it on my SGI Octane the moment I saw “Java” then I realised that it had Java, but it wasn’t written in 100% pure java and all of it stored nicely in a big fat *.jar file.
I’m afraid you’re an anomaly.
The reason that MS Office, Photoshop etc are written in C++ and not in C#, etc is because they predate C#, Java and Python by many years. These apps have been around since the early 90’s.
Take any large Java app and work on it solidly for 15 years with a team of hundreds and then you will have something that you can compare to MS Office and Photoshop.
If Microsoft was starting MS Office from scratch today, I’m sure they’d go with C#/.NET from the outset.
Really? Don’t forget that .Net is a JIT compiled system, which means that the first time any part of the software is used, it’s slow because it’s being interpreted and compiled at the same time, yet it never reaches the performance levels of a native-compiled program. Why would MS put their customers through that – something which would become very public when they are selling a large program for hundreds of pounds or dollars – when they can just use something they can compile, and ship it out ready to go?
Apart from ThinkFree, can anyone name any heavyweight software, open-source or proprietary, which is based on a non-native platform?
About your question:
– bloated C code: GNOME Desktop
– bloated C++ code: OpenOffice and KDE4 desktop
– slim Java code: Eclipse (the start is slow but after that is faster than Visual Studio written in C++)
– well written C code: Apache Http server, Linux kernel, a lot of other examples
– bad written, memory hungry code (C): GCC compiler tools and linker
C++ was not able to remove the legacy so the compiling of some C++ files may take hundred of megabytes, if they use multiple headers + templates on GCC (cause of including headers, expanding templates, etc.) still hard to match in a big sourcecode.
Java/.NET is useful in places where the speed matter (that is why they do benchmarks on Java) but mostly to simplify a complex business logic that C++ rarely can match. The C++ advantage remains still the huge codebase that is hard to be matched by any non C/C++/ObjectiveC language/environment.
Edited 2008-10-12 12:46 UTC
Well from a library standpoint Java probably nowadays surpasses C++ by miles. I am not talking about the huge classlib which comes with every JDK. C++ people alwyays talking about the STL really makes me laugh, this feels like being stuck in the early nineties. But there is a myriad of third party libs and literally thousands of really well written opensource extensions. Add to that the probably best coding tooling in the world, and you can see that sometimes it makes sense to look what others are doing in their domain!
It’s possible (and done with all libraries and many commercial .NET packages) to have the code precompiled into native images and stored in the .NET image cache using the NGEN system. This has a mixed effect because some of the dynamic parts of the code become slower (the native code has to have extra checks for cases which were not known at pre-compiling time). On the other hand, the code pages become shareable and you don’t pay the initial load time and runtime costs of JITting the code.
It’s possible to have C# compiled all the way to native code and have no JIT at all. The Bartok compiler from the Singularity group at MSR does this.
Is the Bartok compiler commercially available, or has anyone come up with an open-source native compiler? (I guess not, because we’d know about it.)
I think Bartok is available for research use (in binary form only) with the Singularity RDK on CodePlex. I have not verified this myself.
Yes, basically all java web containers, Eclipse, Netbeans, Intellij, Google Android, Limewire etc…
That’s nonsense that people in the Java/C#/Python camp keep on bringing up but it has no basis in reality. Nobody writes large scale applications in Python, so I’ll leave that out of this discussion.
Adobe is happy to rewrite Photoshop in Objective-C to target the Mac market. Why are they unwilling to rewrite it in Java or C# if it will guarantee “easy” portability?
Managed languages will always have additional overheads compared to compiled languages. For many end-user facing applications, these overheads are just unacceptable. Managed runtimes add tremendous memory overhead that makes them unpractical for things like office suites, photo editors, browsers, and most other pieces of software.
Note, this is not to say that managed languages have no place on the desktop. They’re widely used in in-house business applications as they allow for a shorter development cycle than traditional C++ applications. Also, business desktops tend to run less applications than home user ones so the increased memory usage is not so easily felt.
The move from assembler to C to C++ became practical as hardware improved. Perhaps in the near future when 64 bit machines and operating systems become ubiquitous, and everyone is running with hundreds of gigabytes of RAM, we’ll start to see more applications targetting managed runtimes. Perhaps not, as some would argue that the there aren’t any long term productivity benefits in moving to managed runtimes.
Adobe probably has no problems linking in arbitrary C++ code into a program that contains a smaller Objective-C ‘View’ component. That’s a lot harder to do with Java (which doesn’t have great support on the Mac anyway.. so that wouldn’t be an option).
Microsoft’s equivalent set of tools, the Expression Suite, is actually partially written in C#. It’s entrenched like Adobe’s stuff, but I’m sure they would refrain from C# entirely if it were incapable. Media Center is also written in Managed Code and seems to perform quickly enough (at the very least it doesn’t seem to be CPU-bound).
Does anyone care? Listening to Eric used to be entertaining. But today I feel that we should be more concerned about the associated greenhouse gas emissions.
I think the biggest problem with C++ is whether you’re writing your own program, or trying to maintain/modify someone else’s. I’ve not seen many C programs that would give anyone trouble maintaining, but the majority of C++ programs are the worst spaghetti code imaginable. It’s too easy to make a bad C++ program, and then YOU/WE get stuck trying to make it into something useful.
This is probably because technical schools were pushing C++ and JAVA for the last decade or so, so every idiot and their dog who thinks “they be progamor” writes truly dreadful C++ that somehow manages to be adopted by people/companies.
… and this is true of any programming language. The problem lies with people overcomplicating and overthinking their code – and C++, like other languages that have object implementations, is ripe with opportunity to make those mistakes.
Objects are great for self contained modules where you need to pass data between functions as a set, where a simple pointer to the data being processed isn’t enough. Binary Trees, relational datasets – Objects kick ass.
The problem arises when programmers start throwing objects at EVERY library they make – be it C++, Java, Javascript, PHP – Objects are generally slower for flat function operations, more complicated, and more code. Time and time again I come across libraries where no data is being shared between the functions, but all the functions are in the same object… and the object/functions would only ever be declared once in any program that uses it. The advantage to doing this is what exactly? Extra memory overhead of allocating the object, extra overhead of initializing the object, where’s the benefit?
IT often seems programmers have forgotten the most basic rule of writing software – the less code you use, the less there is to BREAK.
Goes hand in hand with the attitude many programmers have about things like strict typecasting, predeclaration of variables, and semantic function/variable names (can you tell I’m a Wirth fan?) – Many seem to view the above as ‘too rigid’ and ‘too strict’ or even ‘too much effort’ when they prevent you from making errors in the first place. (How’s the old Pascal joke go? The compiler won’t let you shoot yourself in the foot…)
But this is why machine language has fallen into disuse – it’s certainly no more cryptic than C, and while people might tout portability as a concern let’s face it, x86 has won this round – No, it’s that the strict rules are too much for most programmers to deal with given how most of them sleaze out code like they were working for IBM back in the 70’s getting paid by the K-LoC…
… and again that’s got NOTHING to do with the language used. You make a better language, programmers will take the same sleazeball shortcuts, use badly thought out and/or planned methodologies, and vomit up the same rubbish they do today trying to pass it off as code.
Kind of like HTML/CSS – where people who wrote pages with crap nested tables around elements for no good reason now just churn out crap nested div’s resulting in two to three times the markup needed for the layout they are making, using cryptic nonsensical classnames, the wrong tags around elements, and hordes of tags that don’t even do anything… You know, 70K of markup for 12k of content?
Same dance, just a different tune.
For me, I learnt a small amount of C++ when I was going through university/polytechnic. The problem comes right back to understanding objects and other concepts. I’ve always held the view that unless one 100% understands all the concepts behind C++ then one should avoid using the language.
For me, I’ve tried to wrap my head around the object orientated ideas and other C++ concepts – and I just couldn’t understand it. Rather than muddling through creating ugly code I’ve decided to stick with C. I also think that there is an over marketing of C++ and object orientation, especially by managers and IT recruiters. Rather than choosing the ‘best tool for the job’, there seems to be a gravitation towards the ‘coolest’ and ‘newest’ tool for the job.
That’s because, IMHO, the C++ implementation of objects is one of the most piss poor out there, and is the LAST place to learn how they work/why they should be used… Which goes to what you said about learning it and understanding the concepts behind it BEFORE you try to write anything serious in it.
Object Pascal / Modula makes learning the concepts clearer/easier – Partly because of the forward declaration giving you your structure beforehand. Even smalltalk is clearer and gets the CONCEPT across faster. Once you have the understanding of the processes and structure you can apply it to other programming languages in a sound manner.
Of course, Pascal for LEARNING? Who’d have thunk it?
Edited 2008-10-12 00:58 UTC
Unfortunately in New Zealand, thanks to the ‘arrangement’ with Microsoft, they got rid of Pascal for a learning tool and replaced it with Visual Basic – yes, you heard it correct, Visual Basic is being used as a learning tool.
You’d be surprised. My schooldays from 6th grade up until highschool graduation saw us go through pre-PC machines up and over gw/q/turbo basic, turbo/borland pascals, turbo c/c++, borland then ms c++, but looking back, I think we spent the most time with pascal, which was nice (thinking back).
I find most of today’s complainers, who applaud about one and cry over another language’s strengths and weaknesses, not really worthy of spending much time with. They don’t like one ? I couldn’t care any less. When we (and I) had to solve a problem, choosing a language was the last step I ever took. Sometimes it matters less, sometimes it matters more, you always have to have some reason for picking one, besides personal preference.
But pascal, well, always remains one love of mine
I think that it’s a matter of how you think about programming. There is a type of person that finds C natural, and another type of person that finds C++ natural, and the two do not overlap very much.
I’d guess that this difference in psychology is what drove Stroustrup to develop C++ despite working alongside the guys who developed C. I wonder if people brought up on Pascal see any wirth in C++. C and Pascal is another similar psychological split.
You’re my hero!
I am really pleasently surprised by messages posted here.
I expected standard C++ bashing, which seems to be fancy these days. But it looks like people still understand virtues of this wonderful and useful tool!
All the C++ bashers it seems have gathered at slashdot. Just wait until this article appears there and go see the comments.
Most of the people there seem to be advocating the language du jour, or LISP, or Haskell. The fact is, these (LISP and Haskell) are not new languages, and have had many opportunities to prove themselves. Though, almost noone uses them for writing large real-life applications.
You could argue how much of that is actually due to the greatness of the language, as opposed to just the way things are.
C is far from being the portable language it is made to be, without the preprocessor anything beyond hello world wouldn’t compile on *any* machine.
However, C was tied to UNIX which was given for free with code to many universities. Then came C++ with many pitfalls, but you could keep all the C code, and people started to drift to that as the preferred OOP language from more pure approaches. Not because it was a superior language, but because it was C with classes.
With time C++ grew and incorporated, language-of-the-jour paradigms, albeit with an ugly syntax, and got the best compilers and libraries. It might be the choice that makes more sense, but that doesn’t make it a good language.
Of course, the “status quo” has a large influence, but additionally I think that imperative (and OO) programming correspond more to the way our mind maps problems to code. You can see that difference between, say, a Java course or a Prolog course at a university (BTW I love Prolog, and write Prolog for food at the moment). Java is picked up very easily by nearly everyone, Prolog often takes a few weeks to get, and some people never get it. Rather than subdividing problems in steps (which is our daily manner of solving problems) it requires a programmer to map a problem to a set of predicates that can be used to prove a result (and often also vise versa). Prolog is natural for certain problems, and easier if you are well-schooled in logics. Likewise, many functional languges are natural for certain problems and easier when you are well-schooled in mathematics. But a considerable amount of programmers that churn out Visual Basic or Java code will have trouble using other paradigms, and will not need it most of the time.
For this reason, I think the current trend of mixing some concepts from functional programming with imperative languages is more interesting. Programmers can continue with what maps well with our brains, and use functional programming where it fits very well with specific problems.
C++ has developed a lot since the mid-eighties. It’s not just C plus classes anymore, and if you restrict yourself to a modern subset (by using STL extensively), it’s a nice and comfortable language, with an elegance that leave a lot to desire in other languages (e.g. iterators are painfully limited in most languages and most static languages have no support for generic programming beyond type erasure).
The painful thing is code that was written by programmers who still think C++ is C with some added conveniences. That code is often full of redundant algorithms (that should be replaced by STL algorithms), use of arrays, C-style character strings, global variables, no use of RAII, etc. And that is a disadvantage of C++: it allows people to be stuck somewhere between the old world and the new world, which is bad for developers from both sides.
I agree with you… I never was able to see the light behind Prolog
…that I can say here: That man just doesn’t know how to write C++ code.
If you try hammering in Pythonisms into C++ code, then, yeah, it might turn out brittle (if every Python app i know would immediately fault whenever a runtime error comes along, then I’m sure more Python apps would fail than C++ apps). Furthermore, the brittleness he says exists can be possibly only attributed to editing C++ code: Final C++ code, once it runs, is (I’m sure but have no data to back it up right now) on average more stable than Python or C. I simply love C++ because of that feature (so yeah this here is biased but I’m not losing sight for facts).
Obfuscated. Hell, yeah, it ain’t BASIC, sorry if you can’t deal with some level of COMPLEXITY (which simply != obfuscation).
Rigid, yes it IS rigid in a sense, but what this builds is stability, not brittleness. Software is algorithms, not art. The art lies in writing it, but the final piece is as much algorithm as finding the LCM of some set of numers. So sorry if it FAULTS when the app isn’t written the right way. Yes, faults, which is the only right thing to do during testing, because you DON’T want it to fault when possibly lives of people are at stake (nor do you want e.g. Python apps to warn you but it seems this is being ignored all too often, because final releases turn out to have a lot of warnings a lot of times.)
As for unwieldy, I can’t follow there. The base language is very slim.
+1 for you!
Back in 1988 I completed my Master’s thesis on speculations about extending the functional programming language Lucid to deal with Real-Time systems, as in Avionics. It would be so elegant and rigorous. I still think that any programmer is likely to be smitten with the elegance of functional concepts AT FIRST SIGHT, or even with less-ambitious pretty-wrapper-languages which merely do away with pointers, and explicitly-programming-threads, and…
In addition to elegance, it will save us from (( C++ slobbering toddlers playing with nail guns )), that phrase has a ring to it.
However your attempts to wrap the universe somehow always end up bloated – in situations requiring actual programming it can end up be SIMPLER to have those POWERFUL primitives of pointers-and-threads at your direct command rather than trying to work through someone’s idea of a Universe-Wrapper.
C++ using the STL, SQLite, and Poco is simple and creates readable code. People and corporations have come to late to tell me C++ is hard, unusable or too complex.
To everyone else go ahead a learn a new language every 5 years while I perfect the one that runs on everything.
Never heard of Poco before. That looks pretty nice – essentially the same kind of stuff that’s available in .NET and Java’s class libraries, but is missing from C++’s standard library. I’ll have to look into that one.
I’d probably add Boost to that list. Much of the functionality I use from Boost is also present in Poco (some seems to have derived from Boost, in fact), but Boost contains so much more.
There’s also a lot of good stuff in the C++0x proposal, whenever that gets finished and widely implemented. Much of the additions to the standard library are already available in the latest versions of GCC and MSVC, or through Boost (where many of the additions originated) otherwise.
All we really need is a really good, portable UI toolkit that can be used seamlessly with all those other modern C++ libraries, without either using old-style C++ or even C code (Gtk, Win32), or pulling in their own implementations of everything (Qt, MVC).
C++ is a systems language that you can pretty much build anything. It allows for both object orientated programming as well as the needed procedural style programming. It’s beauty (if used properly but not always done however) is to procedurally use objects.
Consider the code sample below and tell me this is not very simple:
********************************
class Paper
{
private:
std::string Color;
std::string Text;
public:
Paper();
~Paper();
// Getters
std::string GetColor(void);
std::string GetText(void);
// Setters
void SetColor(std::string Color);
void SetText(std::string Text);
};
// Create some blank paper. Everthing is free inside the computer!
Paper1 Paper;
Paper2 Paper;
// Set some info about each piece
Paper1.SetColor(“White”);
Paper1.SetText(“Buy some eggs and Milk\nDon’t forget the cheese!\n”);
Paper2.SetColor(“Green”);
Paper2.SetText(“You may have already won one Million Dollars!\n”);
// Create a container to hold paper and put some paper in it.
std::vector<Paper> MyTrashCan;
MyTrashCan.push_back(Paper1);
MyTrashCan.push_back(Paper2);
// See what is in the Trash can. Thus:
for (size_t i = 0; i < MyTrashCan.size(); i++)
{
//Print out to the screen or over a TCP connection
std::cout << MyTrashCan[i].GetColor();
std::cout << MyTrashCan[i].GetText();
}
********************************
Mmmm… compile time error. The right way would be:
Paper Paper1;
Paper Paper2;
BTW, I don’t like C++ syntax at all… It’s verbose like Java and ugly like Perl. The worst of two worlds.
Problems will start if there is anything else than single Color and Text attributes. What about:
and the existing code will still work, but will be much slower than Java.
But that is not a problem of C++ core language, but STL…
Yes that would allow for multiple Text types quite simply. Gains in STL will help performance. Of course one could use their own custom vector class. I show this to illustrate how easy C++ is. I use a similar class design to handle a complex object that has many forms of recursiveness in it. Using SQLite, and Borland’s VCL has made programming the windows platform child’s play. I plan to replace the VCL with QT or wxWidgets at a later date if needed.
Your line above shows the flaw in C++. How do you get the TCP connection? While one could argue the the C++ language is ok what it’s missing out on are standardised cross-platform libraries for things outside of data structures.
Libraries is the strength of Java (and .NET somewhat, if all you care about is the desktop on x86 architectures).
Ok, so maybe you don’t need sockets, so where are the standardised cross-platform C++ guis (that don’t need precompilers or macro magic). Or how about threading? When multiple threads own your Paper class who is responsible for cleaning it up? Where is the standard way of documenting the class for maintenance programmers new to the system? (sure doxygen is great, but it ain’t standard on C++ projects).
Despite the power of C++ as a language it is weak in areas such as legibility, cross-platform standard libraries, and thread-safe programs that can be maintained by mortals (not just the ‘elite’ that visit sites like this). This is why C++ has been marginalised by Java and the much-simpler C (still used for systems programming).
Here are the statistics:
http://www.langpop.com/
http://www.tiobe.com/index.php/content/paperinfo/tpci/
Sure C++ and C# are used (and admittedly are the right fit for some projects), but not as heavily as many fanboi would like you to think.
You raise valid concerns for someone who is not using C++ day in and day out. So let me shortly address them.
* Legibility: Use only the STL and the below libraries in a procedural style way interacting with your objects/classes.
* Cross-platform standard libraries: Poco C++, Boost, SQLite, wxWidgets are very free and very commercial quality. QT is very solid as well.
* Thread-safe programs that can be maintained by mortals: This is hard in any language. The latest version of Boost is moving toward making this easier. The early years of getting our heads around Object Design was hard. Until we fully understand threading it will be hard. Don’t fret because C++ will be the first to fully utilize and set the pattern for other languages in this area.
I understand the mental handicap of learning something new or just plain not liking something. But modern C++ programming from scratch (avoiding any C style thinking) is very easy to read, maintain, develop, and obtain performance to create simple or demanding applications with.
I don’t wish to convert anyone only to say that it is very nice sipping the cool glass of lemonade that is C++ nowadays so don’t feel sorry for us. 10 years ago… yes… maintaining someone else poor C++ style… yes that is a lot of work but not anymore with modern styles.
Edited 2008-10-13 02:30 UTC
Just to make clear, I used C++ day in and day out for ten years. This is not a case of “I dipped my toes in the water but it was a bit chilly”. I got fed up with the gcc and Visual C++ headers changing things (mostly slight changes to macros) around with each release – which meant you had to keep porting to new versions of the C++ compilers. I got fed up with adjusting everything so I could link alls sotrs of modules togther due to different name-mangling schemes used by different compilers. I got fed up with the compiler producing ridiculous illegible template compile error messages. I got fed up with both g++ and Microsoft having compilers that didn’t conform to Standard C++. Then Microsoft declared it would never implement a 100% conforming version of C++, followed by a warping C++ with a bunch of extra crap to shim it into .NET. Once your program gets big (back then I was working on PhD thesis software was around 100k lines of C++ that took around 5 years to build and maintain) I found it just too much of a PITA.
I used to believe in C++, but now I realise simpler is better (though I’m not reductionist enough to switch to Lisp). For a long time C++ was better than Java ’cause it was smaller and a lot faster. It’s only advantage these days is it has a smaller runtime footprint in many cases, but in restricted-memory (embedded) systems you have a restricted problem domain so you might as well use C instead since it is so much simpler than C++.
Sorry, perhaps I wasn’t clear enough in my earlier post. None of these are a part of Standard C++ so you can’t guarantee they’ll be available in any new C++ environment. For example, I often have to work with the endorsed tools an enterprise client has chosen, so I don’t always get to use non-standard stuff – this isn’t a problem with Java since it comes with a lot more stuff as standard.
From this I guess you must either be involved with Microsoft or Boost. Sorry, but your last sentence is pure marketing drivel to someone who’s both the trenches and also does reconnaissance from the high ground from time to time. Until C++ sorts out automated memory management using threads will be more difficult than Java for very complex programs (where long-lived multi-threaded programs share state). Myself and my colleagues routinely write complicated multi-threaded programs in Java that would take far longer to build in C++ (mostly due to the memory debugging required under multi-threaded conditions). That reduced time means a lower cost of development to our clients, and that’s what it is all about (anyone who doesn’t care about cost is either not paying or considering the development bill).
Even FORTRAN is ‘easy to read’ if you are the only person writing the program. The more you read other people’s code the more you appreciate what simplification has to offer. When I write C++ these days I use a modern style, but I find that the productivity and ease-of-development still isn’t anywhere Java. I find in big projects (where I used to use C++) I’ll use Java, and in small projects I’ll use C. For me, despite the years of investment in the language, C++ just doesn’t pull its weight anymore. I think that’s why there has been a move away from it (not because developers are unaware of its features).
C++ is good if you like more features. It’ll let you get from A to B when few other languages can, but you have to walk a tightrope to get there. Java is good if you see greater elegance in simplicity (same as Zune vs iPod/iPhone I guess).
Thanks for taking the time to respond.
Albert Einstein:
If you still have to care about memory management in C++, you are doing something wrong…
If your C++ code has more than one delete per ten thousand lines and more than one new per two thousand lines, you still have something to learn
Anyway, C++ has one major disadvantage. As it is around for a long time and as it has more than single vendor (unlike Java and C#), there have emerged many ways how to do C++ code.
That is why I keep saying that people should rather compare Java/C# to Qt/wxWidgets/U++ etc… than to C++.
I also believe that C++ standard library (and particulary STL) is way suboptimal. It makes you wish C++ had garbage collector…
Used properly, C++ can beat just about everything in runtime performance and in productivity IN THE SAME TIME. It is like free lunch. Of course, you need to invest in the steep learning curve to get there..
(A bit of self-promotion, I believe that these examples nicely demonstrate this:
http://www.ultimatepp.org/www$uppweb$comparison$en-us.html
)
c++ is still my favourite language. For some projects I’ve worked on, its great knowing exactly what type each variable is, and having this forced everywhere in the project. Its also great having structures that a set size.
Some things are a bit difficult but one must remember that c++ came before most of today’s dynamic/scripted languages. Newer languages came with better garbage collection and memory management, and typeless variables, since this was considered better for most things (and I agree). But C++ still has its place I believe.
We have enough mainstream languages now to be able to choose the right language for the task at hand. We dont need any new languages to learn.
C++ is a political translation technique that is wasting everybodys time. Were in 2008! – Not 1978. I have 7921 characters lef.. shoot.. 7889 aw dam.. 7875 ah! nevermind.
I was wondering if I should still contribute to this thread but in the end I could not contain myself.
First of all, lets say that there are still lots of places where using C++ makes sense. Specially on the games area, number crunching applications, and constrained resource environments, to name a few.
But on the day to day applications of the IT industry, C++ role has long been replaced by Java and C#.
Like it or not, these languages allow for better productivity and are fast enough for many applications.
And they are not interpreted. On C#’s case the bytecodes are always compiled before execution. On Java’s case it is a mix of compilation and interpretation depending on the method call count threshold.
On the telecomunications industry, where I work, there are network elements, where the software is Java based with the JVM running directly on the hardware.
The C++ build model is pre-historic with all the include files and explicit compile/link phases.
Splitting class declaration/definitions in two files
also does not make much sense nowadays. The C# separate class model is a better one.
Several years ago IBM tried to sort out the problem with Visual Age for C++, but this was long ago.
We are in 2008, on the verge of having C++0x approved and I am not aware of a single 100% AnsiC++ 98 standard compliant compiler.
And all the comments about boost, Qt, wxWidgets are good, but useless if your company does not agree with their usage, or they do not support your target environment.
So C++ is still an important language, but stop trying to portrait modern C++ as a no problems language that everyone would easily pick up.
The IT industry (corporate work place aka Corporate America) has always used the worst of the industry Microsoft/Sun/IBM backed development tools.
Object Pascal and C++ are the tools of choice for the free thinking ISV market. C++/Delphi for ISV custom/speed software and everything else for Corporate.