I agree totally with Zed Shaw on this, but some quick observations:
* C++ circa 2000 (before mainline g++ could handle Alexandrescuisms) is significantly different from C++ circa 2010, albeit in ways that probably upset Shaw even more (the more central role boost has taken, the more "expressive" templates have gotten, don't call me on any of this stuff).
* C++ std::string is an abomination, but you can always just do what I've done and what lots of other C++ programmers whose code I've read have done: just use char* and a simple string library (or a custom string class).
* Ditto for stream IO, which is a huge C++ misfeature but which is also pretty much irrelevant (I know of no part of the standard C++ library outside of things that explicitly support stream I/O that rely on you using it).
* I don't get the POSIX argument at all; just call the POSIX functions, they work fine. Nobody mandates that you use (say) ACE_wrappers to do systems programming.
* const-correctness may be another misfeature (I know I make fun of it), but the point isn't hard to see: if you take the time to const-correct your code, the compiler will spit out errors that would have otherwise been runtime faults.
The problem with std::string is that when I type a quoted string in my code, it isn't natively a std::string, it's natively a char* and gets converted to strings. C++'s biggest mistake was not standardizing early on an official object-oriented string datatype. It should have been in the first version of C++, it should have been treated like a primitive type (even if it isn't), and they should have said "thou shalt use this type for your strings". It makes me sick every time I see some goofy custom string class.
One problem with const-correctness is C++ uses "const&" to mean two different things: it could mean either a reference to a persistent object you're not allowed to change, or it could refer to a temporary object which you're prevented from changing because the changes will disappear. The problem is it conflated access control with lifetime. It would have been better if there were a "temp" keyword - although the last thing C++ needs is more combinatorics of type decorators.
On the subject of consts, though, C++ simply enforces const correctness more, but doesn't the same criticism of confusing const apply to pointers in C as well? You can just as easily declare a "const * const" in C as in C++. So I fail to see why Zed Shaw writing something in C gets him away from that "problem", unless he doesn't write const correct C.
That would have required a decision, and if there's something committees are uniquely unqualified to make, it's decisions.
The fact that it's C++, where the prototypical user believes that they shouldn't pay for what they don't use just makes things worse. Everything being optional means there can be very few synergies in language or standard library design, because if feature A needs feature B to work, people who want A but not B will complain. C++ "chooses" either by omitting both A and B, or creating some low-level error-prone features and hoping users won't chop off too many fingers trying to build their own incompatible versions of A and B. An ill-designed misfit language is all but required by the dynamics of the situation.
The great thing about const is that if you don't like it you can pretty much ignore it. The only time it might be necessary to deal with it is if you are using a library that returns const objects.
If you do like const (which I do) then you can put it in pretty much everywhere, except if you are dealing with a library that isn't "const correct", but then a bit of type casting will save the day.
That's a big advantage of lots of the C++ features - if you don't like them you can often just ignore them.
"If you do like const (which I do) then you can put it in pretty much everywhere"
In retrospect, it might have been better to have a keyword for things that can change. This goes equally for Java and "final". Making immutability the default and mutability opt-in makes for fewer bugs and more reliable programs.
Arguably, this is what Clojure does where you have functional, immutable constructs by default with ways to declare things that can change (refs, etc.).
const by default may not be a bad idea, but immutability of structures/objects in C++ sounds like it would be a huge performance hit to me. I've used an image processing library (CIMG) which lets you do things like `img = img1 * 2 + img2 * 0.5`, instead of editing the image in-place. It's pretty, but with regular 800x600 images the performance was around 2 orders of magnitude below a simple for loop... it made a lot of extra copying and allocation instead of mutating the image.
The thing is, this kind of code isn't an exception in the C++ world. C++ is made for problems where performance matters: image processing, compilers, browsers... immutability works for Clojure, but Clojure is a lot slower than C++. It's more of an "enterprise software" language.
The same can be said of English. And in both cases, there are sundry tasks of limited scope where the language is probably not the most natural choice (e.g. operas). However, when one is simultaneously dealing with multiple, disparate domains/constraints simultaneously (e.g. real-time computer vision), such a language might be the least unattractive option thanks to its inclusiveness.
Except program don't express natural language, and in fact the required context awareness of natural language is exactly what kills many languages and frameworks. I shouldn't have to know all of these things to edit some stranger's code, it should be obvious how it works.
I like the QT library. It is an alternative to all this absurdity. QT's strings, streams and containers have infinitely better syntax than the bondage and discipline of STL. And QT may not be standard but it's going to be more widely used and supported than any string class I might roll myself.
If your currently in an apoplectic fit as to why people don't love C++, const correctness, boost, and the standard library, then read no further.
For those with a slightly broader perspective and an inquisitive mind, perhaps you should take a look at at the Reason C++ framwork, specially if you have never seen C++ in its most pure uncomplicated OO form.
Reason is a C++ framework that ive been writing for about 8 years, which aleviates many of the sources of pain highlighted in this discussion. Writing code with Reason is much more like using a dynamic language, with a full library like Java or .Net.
It supports raii, but doesnt use exception handling and doesnt bother with const nonsense or over the top inheritance restrictions. In fact pretty much everything in Reason is public and designed to be derived, modified or enhanced.
It has generic programming features, but doesnt force you to write everything as templates (a classic mistake that the standard library makes). For example, you can have an iterator of int's without caring what the underlying container type is, so your code and algorithms can actually be generic, not just infectious templates.
Unlike a lot of C++ frameworks and libraries, its not specifically focused on networking, or a few esoteric template classes or collection libraries.
Reason is a fully featured systems programming framework with a complete interface to all the usual posix api's and everything else you would expect from a modern language. It has strings, regexes, streams, parsers, sockets, threads, filesystem, encryption, encoding, xml, xpath, collections, time and date, sql (mysql, postgress, sqlite), http (client/server), smart pointers, formatting, logging, and much more.
But the features are perhaps not as important as how it is written. It is simple, and very object oriented, everything is designed to work togeather cleanly and obey the principle of least surprise. Just like Python and Ruby, Reason allows you to do a lot in a very small amount of code.
So if your wondering how you can have the simplicity of C, with just the good parts of C++, heres your answer.
> const-correctness may be another misfeature (I know I make fun of it), but the point isn't hard to see: if you take the time to const-correct your code, the compiler will spit out errors that would have otherwise been runtime faults.
I think it is so interesting the mentality of static typing people. I would much prefer handling the few resulting run time faults than having to stuff with my code with const.
Anyway, there is no guarantee in C++ that something that compiles with all consts in the world will not throw a segfault at run time in the least expected moment...
I think it's interesting the mentality of dynamic typing die-hards. I find it much easier (for complex projects) to just type "const" where appropriate and let the compiler think about mutability for me, than to think about mutability myself. The mental overhead is definitely superlinear with the complexity of the project, and typing "const" a few times lets me use that resource for more subtle correctness issues.
Of course, one problem with C++ (and, to a lesser extent, C) is that many of those subtle correctness issues are direct results of the type system in the first place. Go figure.
The beauty of dynamic typing is that it makes the writing of the code easier, which makes development shorter, which gives you more time to thoroughly test your code. After years leading a QA team, I'm convinced that more time testing is always superior to more time writing code, even if the code you're writing is there to stop bugs!
The beauty of static typing is that it consists of a proof that entire classes of errors cannot occur when your program runs. Like Dijkstra said, tests can only prove the presence of bugs, never their absence. Static typing proves their absence and is thus extremely useful in writing highly reliable software.
His book "Modern C++ design" is about the fascinating beautiful and downright frightening things that you can do with C++ templates. It is worth a read.
However, to support what Zed is saying, Scott Myers (of Effective C++) was astonished about some of the things done there.
C++ doesn't follow the principle of Least Astonishment in any way that I can think of. And that is not good.
"There appear to be a lot of good rants against C++....Are there any good passionate pro C++ versus C arguments?"
By definition, the people who write the "entertaining" rants against C++ have an axe to grind. The people who like C++ just silently use it, and feel no need to write advocacy blog posts for the language. Even if they were to blog about it, it would be about as compelling as someone advocating for their favorite brand of screwdriver. Like it or not, C++ is the incumbent, and it's neither interesting nor fun to read someone advocating for the status quo.
Whenever you find yourself arriving at an opinion about a programming language solely from rants that you read on some dude's blog, please keep in mind that you're probably being most heavily influenced by the very people least qualified to teach you anything useful about the language. The internet is filled with useful articles about C++, but you don't remember those. You remember that Zed Shaw couldn't figure out how const works in C++, and once wrote a funny email about it.
Indeed. At my last job, working on trading software, we had around 35 maths or physics PhDs working on a C++ application. A few had personal blogs (cats, children, steam engines, etc) but as far as I am aware no-one there argued on the Internet about which language was best. C++ just doesn't attract self-publicists the way Ruby seems to.
> C++ just doesn't attract self-publicists the way Ruby seems to.
That's a cheap shot ... Linus Tolvards is definitely not the Ruby-type.
And his arguments are sound ... for system programming, C is a much better language because it's simpler, lacks magic, making the pieces of code easier to understand without the bigger context, and it's more portable.
And for application-level programming, why would you chose a language without a garbage-collector?
Perhaps you need to run deterministically without a stop-the-world garbage collector? A) the world is bigger than simple web applications and B) some of us have been doing this for a long time.
I wasn't talking about web applications, and modern garbage collectors are not stop-the-world.
Not to mention ... stop-the-world garbage collectors have a good reason for doing what they do. They are defragmenting the memory. You get that for free, when in C++ you would have to deal with hell if your app is doing lots of allocations ... see the shit the Firefox devs had to go through to alleviate the problems of heap fragmentation, and its still a problem.
Ah, but what, you're using both managed code (C#) and unmanaged code (C++) in the same address space, doing memory intensive work using third party proprietary C++ code that does lots of small allocations?
In 32-bit land, it's welcome to OutOfMemoryException because managed code can't allocate a big enough chunk when returning to C#.
No free lunch :)
Either recycle processes often or reserve big enough contiguous chunks in managed code before calling out to the bad C++ code, no amount of good citizenship in managed code will stop the poorly written native code from fragmenting the hell out of your address space.
I've experienced problems with java's concurrent mark and sweep collector. It will stop the world, two times, but two much shorter times than a non-concurrent mark and sweep. So it is definitely an improvement in the duration of the stop-the-world.
The problem tends to be that you need to tune it, and even as you have tuned it, you can not promise that under special condition it will fall back to a more primitive collector since the optimality it was tuned for doesn't hold anymore.
I would never argue giving up garbage collection entirely because of these failure scenarios. I would much rather look at moving some critical part of the code out to a language with manual allocation, and let it perform the latency-sensitive bits.
Another mid-ground is to have separate isolate processes (heaps really) that can be stop-the-world collected without blocking each other. Erlang makes great use of this to accomplish "soft realtime", among other things.
Side rant: it's part of the reason that my Palm Pre will sometimes just hang for a second at the worst times, such as when I go to answer the phone. :(
A simple mark & sweep or stop & copy GC. Collectors which are incremental (work in small steps, not one full pass at a time) and/or generational (using several smaller generations, which are collected individually) break up GC pauses into something less disruptive.
For a good overview, read "Uniprocessor Garbage Collection Techniques" by Paul Wilson (check google scholar). Richard Jones's _Garbage Collection: Algorithms for Automatic Dynamic Memory Management_ is more in depth.
Not necessarily allocating very large chunks in bulk but umm... Allocating nodes for a million nodes of a graph and subsequently processing them. Java JVM fragments memory heavily.
En
> And for application-level programming, why would you chose a language without a garbage-collector?
Because your code uses some finite resources other than memory, and you don't want the ability to forget to release said resources when you're done with them and they go out of scope.
Why should memory management related to managing other resources. Anyway, you might be interested in The Haskell Disciplined Disciple Compiler (http://www.haskell.org/haskellwiki/DDC) which lets you statically encode resource management rules. (And of course spots garbage collection for memory.)
Your objects contain/use various resources, such as memory, file descriptors, mutexes, etc. The way to reclaim any of these is to destroy the object, which lets you reclaim all of them. So memory management is very much tied to other resource management, since they both involve the same thing (deciding when to destroy objects you no longer need). Unfortunately not all resources can be collected equally lazily, so memory-centric GC schemes that ignore the requirements of other resources tend to get in the way (and make you do using(){...} or try/finally to make sure your files are closed, instead of allowing for RAII).
How to unmix: Just e.g. close your files explicitly, but let the memory of the data structures that represent your files be garbage collected normally.
For patterns of usage similar to RAII, Common Lisp uses unwind-protect. I already mentioned Disciplined Disciple Compiler that extends Haskell to give static guarantees for following certain rules for resource management.
Why would you bother: RAII only covers some cases for resource management, and most garbage collectors can take an arbitrary long time to collect an object that's no longer reachable. Which is fine for memory, because memory is fungible, but the attached resources, say mutexen, are not necessarily fungible.
For some concrete examples of the above: WebKit, Chromium, Gecko, and V8 are all C++.
My impression is that there is a very high startup cost with C++ to getting it working on the platforms you want to support and picking the subset that isn't going to screw you. Once you get over the hurdle, the improved memory management (I agree with the post Zed is ranting in response to) starts to pay dividends.
V8 is ringing endorsement for V8. It is just a well-designed JavaScript virtual machine. It's performant because it compiles JavaScript to native code and uses generational garbase collection.
Good advice generally, but what axes do Zed and Linus have to grind? Sounds like both just think C++ enables too much complexity to be worth the benefits.
It's actually possible to make C++ nice, the Grace library is wonderful. If I ever have to C++ again I'm totally grabbing it and using it. The Grace value types and type safe format operations are just the best thing ever.
My problem though is it's not the right tool for the job. Simply having access to C level APIs doesn't instantly mean your language is awesome at making servers and operating systems. Especially if that same language can't quite figure out what the hell really happens on a copy, or during an exception, or can't make decent strings and data buffers.
I figure they have the axe of "I used this for a while, and really grew to hate it when I compared it to these other things I used" to grind. Sometimes the technologies you use just make you want to get something off your chest, you know?
"You'll find crap in C++ like const *const char &, and hell if anyone knows what that really means since even though the pointer to a const to a const reference is consted to hell and back, oh look you can still increment it."
I'm still looking for the part where he doesn't understand how const _works_.
"const *const char &" is not valid C++ syntax, so I'm pretty sure you can't increment it. Therefore, anyone saying you can increment it doesn't understand it. QED.
Oh, you have to read that in the voice of The Comic Book Guy. Then it's fucking hilarious. Here try it:
"You sthee const const &const char[const ] is the proper way to make a thruly safe reference to a conthst char array conthst pointer conthst."
See, prime comedy gold there.
Also, 'cause you guys think the internet should be nothing but a massive academic white paper curated by Knuth, so any amount of hyperbole sends you into a literalism hissy fit.
He mocks that you can attach const nearly anywhere in c++ and it seems to do something different. (Note: This is a generalization, an important aspect of many jokes)
The best pro C++ argument is that for all its flaws there's nothing out there that completely replaces it and it's still widely used.
My own view: I'm not in love with C++, but it's not nearly as bad as everyone makes it out to be. Most of the arguments I hear against C++ are the same tired things I've heard hundreds of times. They all have a grain of truth, but nothing so bad as to condemn the language.
C++ is as bad as they say it is. It is horrible, it is the worst language in the world ... except for all the other (a la Winston Churchill and democracy).
The horrifical complexifications of C++ are just terrible, yet every one of them has a reason behind it. And also, the horrifical complexities are a bit more optional than the horrifical complexities of, say, Java.
There isn't another language that has both the large-scale modularization given by OO and low-level efficiency of direct pointer manipulation and other C features. You get a vast library of available free code and a huge number of available tools to boot.
There is no other language for crafting large-scale, high performance tools. Java and C# can be just as fast but even fast Java has even greater verbosity overhead. And the scripting languages are great yet their resource overhead makes up for their compactness.
C++ is definitely a language of "big design". "Thinking in C++" is a mistake. You should think in your design and implement in C++. Unlike C, C++ seduces people to take the code for the design.
In any case, however flawed, the thing occupies a niche no other language can. I'm sorry.
Well, we can agree to disagree here, but my belief is that OO is a impedence mismatch for writing "low-level efficiency of direct pointer manipulation and other C features". It's kind of like saying, "There is no 16 wheel semi truck that can win the Tour De France." Maybe you shouldn't be using a 16 wheel truck.
If you cut a couple wheels off of an 18-wheeler, you could travel the 3642 km of the Tour de France in about 36 hours of driving, which would be about 3 days on a leisurely, safe schedule. The bicyclists take 22 days to do the same thing.
So, there are really only a couple of problems:
• if you're Zed Shaw, you apparently want to cut two wheels off an 18-wheeler, and if you're Zed Shaw, you're likely to screw up and choose the drive wheels for your demented sacrifice. You do that, the sucker won't even roll.
• the stupid hatas who judge the race won't acknowledge your achievement. Something about the allowed types of bicycle. Is that analogous to how you can't run Ruby on a microcontroller with 1024 bytes of RAM, maybe? Because you can sure as fuck run C++ on it.
Anyway, direct pointer manipulation has been part of OO environments since the beginning. The purest current incarnation might be SqueakNOS (ever seen an IDE driver written in Smalltalk?) or SBCL's alien, but the most practical one is probably C++. Rust, Golang, and ATS seem like up-and-coming contenders.
Edit: oh, I forgot D. D's been an up-and-coming contender for more than ten years now.
If we're both posting, we agree that we disagree... (along with agreeing that Paris is the capital of France..)
Anyway, C++ is more like a construction system which can be used to make a bicycle, a semi, or a six-person tandem which could win the Tour De France.
Which is to say it's pretty clunky for a lot of things. But there are still things where both large scale organization and particular low-calls need to coexist - Databases, large graphics programs, etc. It's not impossible to write these in C or Java obviously but I'd still say C++ is cleaner.
> The horrifical complexifications of C++ are just terrible, yet every one of them has a reason behind it.
Many of the reasons are legacy issues though like using dumb linkers and using the C preprocessor rather than a real module system. Templates are just a huge hack: manipulating the text of the source code to simulate generics and then abusing that feature to get meta programming.
One of the great mysteries of life is why there isn't another language that "has both the large-scale modularization given by OO and low-level efficiency of direct pointer manipulation and other C features" yet doesn't make the same mistakes as C++.
"There isn't another language that has both the large-scale modularization given by OO and low-level efficiency of direct pointer manipulation and other C features."
Arguably this might be true, however if you add another requirement to the list Joe posted it isn't. Cross platform code is important to many people. I work on large scale, performance intensive, cross platform applications. Microsoft tells me I should be doing everything in C#. Apple tells me I should be doing everything in Objective C. I just get on with it and use something that works. A language that gives me the ability to combine high level design with low level efficiency and run on multiple platforms.
I often use a paraphrase of the Winston Churchill quote as well. There are probably many better languages for many other applications, however for high performance, cross platform large scale apps C++ is still the only game in town.
Joe's point that all the complexities have reasons behind them is a really good one. I'd suggest reading Stroustrup's "The Design and Evolution of C++" for more information.
Ironically, the whole iphone apps goldrush seems to have contributed in a big way to increase its mindshare. Obj-C is very beautifully designed, I especially like how it adds message passing OOP to C with very minimal syntax additions. But then calling objc_msgSend for every message send, does have a small performance penalty attached, which mostly static languages like C++ don't have to pay.
vtables in C++ aren't free, but C++ has a couple of advantages here:
• If you're calling a nonvirtual method, you don't have to pay the vtable cost at all, just the cost of passing this. And most methods in C++ are nonvirtual.
• A call through a vtable is typically a couple of indexed fetches and an indirect jump. Objective-C's mechanism involves a hash-table lookup, which is a bit slower.
There is no other language for crafting large-scale, high performance tools is demonstrably false. There are high-volume low latency world-class financial systems written totally in Java.
The seriously complex and high-performance ITA system is written in Lisp.
And if you read Coders at Work, some of the criticisms of C++ suggest that the reason behind many of the C++ features is that Bjarne didn't want to say NO.
And I am happy to leave that particular niche of badness to C++ its own self.
I guess, if you set your mind to it, you could probably make Forth do a nice mixture of low and high-level stuff, too.
But why do people insist on being able to do low and high level stuff in the same language? What's wrong with, say, using Python for high level stuff, and calling into C for low level tasks? C+Python is probably more convenient than C++.
Actually Boost::Python makes python and c++ mix beautifully. I just started playing with it a few days ago and am seriously impressed. I'm planning on using it to write a WSGI gateway to put in front of my bottle.py apps.
I should have said "there is no other language which gives you the latitude for crafting high performance tools". You can indeed create serious high performance systems in a number of languages. The thing about most languages other than C and C++ is that things written in them tend to inherit their qualities - A system written in Java generally use Java's garbage collector. That works great for a number of things but it's still a constraint.
More of C++'s "modularization" features are optional than in the other languages so you have more latitude for creating your tools than anywhere else.
The seriously complex and high-performance ITA system is written in Lisp
Have you worked on it? Do you know this? Is it all written in Lisp, or are the parts that need high-performance and predictability written in C or C++?
There's a lot of language FUD out there. I say this as someone who owns OnLisp, and has spent a lot of time learning Lisp.
Until there's a single, stable, not-on-the-way-to-be-obsoleted version of D, with standard standard library, I'm not inclined to invest too much time in it.
I wish that D1 was oficially killed, and a stable strict subset of D2 ("D1.5") was chosen as a recommended future-proof version.
What you say about Java's verbosity is sort of flawed in the same way that attacks on C++ about its template metaprogramming madness are flawed. Don't confuse a language with what people write in it.
There is a point though. C++ encourages obscure "too clever" constructs, and Java encourages excessive verbosity. But in both cases you can decide not to go there.
As far as I know, there's a lot more to Java that isn't optional: everything must be inside a class definition, everything must use the garbage collector.
In C++, you don't have to declare a single class or create a single template.
Lots and lots of things are bad in C++. But that's because it's an elaborate language with lots of things in it. You only have to use one bad thing at a time ;-).
Basically, any language with lots of modularity and lots of low level access is going to be big and have lots of features that are problematic in some situations.
Say you need both modularity and low level access in a given program. Can they be so entangled that you absolutely have to put both in the same language?
No matter how I put it, I fail to see how C++ can be better than C + (Python or Lua or Haskell, with FFI). Is the concept of using 2 languages at the same time so scary?
"Say you need both modularity and low level access in a given program.
Can they be so entangled that you absolutely have to put both in the
same language?"
That's not always an option if you've performance and memory constrains.
We're using Python only for high level scripting purposes.
If you've a performance critical function, where few data goes in,
long computation and few data out, then it's perfect to implement
this function in C and have a python function calling it.
But if you've a lot of data, then that's not an option. You just can't
copy all the data to C and then after computation back to python,
it will kill the performance gained by the C function implementation.
But also if you're trying to do complex operations on your application
object hierarchy, Python will kill your performance. Only compare
the time for a member/property access in Python and C++.
Is the concept of using 2 languages at the same time so scary?
In all honesty, yes.
But consider this also. The advantage of C++, such as it is, is that the big, harry objects you are creating can call each with just about any calling conventions you chose and you can parameterize them at run time and compile time in whatever crazy way you'd like (pointers, templates, static objects, classes and ponies! (Ponies will only be standardized in C++_2015)). This is why Python, Lua and all each call c/c++ for extensions. But while there are many interesting scripting languages out there, there's no guarantee that any of these languages' calling convention, memory usage and constraints will be what your large objects need. Specifically, to effectively use a particular higher-level language you'd have to know from the beginning that said language's conventions would satisfy your needs from beginning to end.
Add to this the fact that C++ may not be a "good" programming language but that it's not that bad if used with discipline and understanding. The badness of c++ comes from the many, many ways you can shoot yourself in the foot - it still doesn't force to do anything. But how many subtle bugs can creep in if you're sloppy in passing raw pointers to some other language? And using any higher level language will involve forcing yourself to do a number of things that could prove problematic.
| Is the concept of using 2 languages at the same time so
| scary?
Yes, but it seems to be inevitable. Python + C. Haskell + C would be my choices for large scale modeling/data analysis. For apps involving a GUI, I would like to hear others thoughts.
Basically, any language with lots of modularity and lots of low level access is going to be big and have lots of features that are problematic in some situations.
It has grabbed and maintained complete domination of nearly all performance sensitive code in games and desktop software, for nearly a generation now which is an unprecedented reign in computing history. That's a pretty good start to me.
I don't know if he's saying that, but yes, nearly all performance-sensitive code in games and desktop software is written in C++, not C. Objective-C seems to be edging in.
I'm going to keep saying this until I turn blue in the face. Perhaps if I stamp my feet it might get more attention (wink)
Please stop confusing the language with the APIs or the available libraries and features of the language.
This sounds simple, but it's profound: simply because you can do something, that doesn't mean that you have to do it that way.
To use Zed's example, let's say I'm hacking around a lot of strings. What's wrong with rolling a string class, adding a member or two? You only have to carry around a bunch of nonsense if you want to. If you don't want to use templates and strings and such, don't use them.
This is another in a long line of articles that go something like this: We did X in this certain way, and boy did it suck. Therefore all of X is the devil's work and will destroy civilization.
You can put about anything you want in for X. It's like a (oddly enough) template engine for writing blog entries.
You should go through stages in your career, with just about any X. Stage one is that you are ignorant. Stage two is that you've tried it. Stage 3 is expertise. Stage 4 is hate, and Stage 5 is grudging acknowledgement that parts of X are okay for certain situations. You realize that yes, X is done poorly maybe 99% of the time, but lots of smart people worked on it and there are some little gems in there that are useful from time to time.
Looks like Zed is stuck on Stage 4
Throw away the templates, throw away all the library stuff you don't like -- is there a reason to make a class and wrap some things? If so, you can do that in C++. You can't in C. It's a very simple question, and it has nothing to do with any of the things Shaw is going on about.
"What's wrong with rolling a string class, adding a member or two?"
The fact that it's 2010?
A language and its standard library are theoretically different things, but in any practical sense, the choice to use a language carries with it the choice to use its standard library. Additionally, the way the standard library is usually reflects constraints placed on it by its language. Java, for example, has a verbose and ceremonial standard library, and that's not a coincidence.
And the fact that it is 2010 relates exactly how to wrapping character array functions? Because I'm not following. If you're in C and using strings, it's still 1985 for you too.
There may be a larger argument about whether the various standards bodies have so complicated C++ that it's become unwieldy -- the comment about exceptions in destructors has merit.
But that's not the argument he was making.
Good programmers are good because of the things they don't do. It's the guys who want to use every feature and library that are often the ones creating the disasters the rest of us have to maintain. So yes, the features and such of a language can hurt. But that's true of just about any language save some of the hardcore functional ones -- C++ maybe more so than the rest. Being a coder using modern languages means judicious use of complexity. Simple is almost always better. Which is exactly where he's coming from, he just takes his argument too far.
In fact, one of the things C++ teaches you early on -- or you suffer all sorts of pain -- is when to abstract, when not to, when to use libraries, when not to, and the dangers of frameworks. It's the very fact that it's such a complex monster that forces coders to keep it simple, stupid. You don't get that kind of thing out of the box in something like Java. This is more bad than good in terms of delivering solutions, but it also is not all bad. It has merit because it trains programmers about the kinds of disasters they can make. If you can write good, easily understood and maintainable C++ code, I can trust you with about anything. If the first thing you do is jump in the swamp where all the alligators live simply because you can -- templates, large inheritance trees, etc -- then probably not so much.
The C++ standard library and std::string implicitly have specific constraints and use cases, but they were imposed by the design process, not by the language.
C++ has many string types because each string type has its strengths and weaknesses. For instance, QString is a fully-featured and Unicode-aware string written in C++ that I use most of the time.
std::string is good for most things. What are your specific issues with it?
I don't write C++ and have no issue with std::string. I was taking general issue with the OP's general issue with criticizing a std library alongside a language.
"A language and its standard library are theoretically different things, but in any practical sense, the choice to use a language carries with it the choice to use its standard library."
That's less true when talking about C/C++ than other languages. C/C++ are quite often used in embedded systems, which often have problems with dynamic memory allocation, code size, etc. This means that many embedded systems don't use the standard library, or only use portions of it.
"is there a reason to make a class and wrap some things? If so, you can do that in C++. You can't in C."
Yes, you can. Object orientation is a property of the program, not the programming language. Pretty much every time I crack open C now, I'm writing Object-Oriented C.
(Also, immutability is a property of the program, not the programming language. Etc.)
mentally replace "language" with "language environment" and all will make sense to you; it will also put you in line with how most people read this discussion.
You: language = base syntax + semantics Most: language = base syntax + semantics + common idioms + standard library + popular libraries
Buried inside C++ there are some good languages; Which one you would use? take one and leave the other stuffs out.
The problems is that you usually target a subset of C++, and two different company targets different subsets. This produce fragmentation and is not good.
Can this be solved/simplified? ages ago someone proposed an embedded C++ standard, and we have compilers in the embedded fields that support this stardard.
Why it does not succeeds? everybody wanted a different subset of C++.
I love C++, but I upvoted this because most C vs. C++ rants focus on things that are not actually C++'s biggest problems. This is one of the few C++ rants that actually brings up of legitimate points. They are not reasons that would stop me personally from preferring C++ over C, but they are valid criticisms.
P.S. On the subject of format strings vs. cout and the "<<" madness, C++0x's variadic templates will allow a type-safe printf. So hopefully in the future we WILL see C++ move back toward format strings, but without loosing the type safety. It also gives the possibility of instead of having to remember to use %d for ints and %f for floats, we could just use format strings that use {1}, {2}, etc. as format string placeholders, the way C# does. Freeing you from having to specify in the format string what the type is is something C++0x type-safe-printf would allow you to do that you could never do in C.
Actually, this is what I loved about Grace. It was like all the crap that pissed me off about C++'s design decisions just went away. It made C++ so nice to work with.
Call me unlucky, but I've never worked at a company that had a high percentage of programmers (myself probably included) that could write solid C++ using anything more than the absolute basics, i.e. basically a C subset.
I'd pretty much agree with Zed's rant, that C++ often isn't worth the bother, unless you have a project that specifically requires C++ features, and you have a development team that can actually write solid C++.
Maybe I'll call this Jonathan's axiom, but if your team doesn't have enough experience to write in a Lisp-y (or any other genre such as ML-y) language, you probably shouldn't be messing with C++ either.
Not many people that say they can write C++, actually can.
I think this is a key point, the language doesn't matter as much as the capability and training the people using it have. This is why all these language arguments are rather irritating, because I'll typically use what works best. On some projects, C++ is great. On other projects C is best. Python is great for some things too.
Spot on, and a far better critique than Zed Shaws rant, that boils down to 'I dislike the syntax' mostly. Many things are done nicely in C++, and C++ provides far better abstractions than C. However, since new language construct have been stacked on C++ for almost 30 years, the language became huge, as well as the possible interactions between language constructs.
The result is that you will rarely find programmers that understand C++ fully. I have seen a lot of awful code that uses C++ as C with classes, badly. Usually, classes and functions have been written with so little understanding of encapsulation that refactoring is painful. And for properly written C++ programs and libraries, it's usually hard to find people to maintain/modify it.
On the other hand, it is also hard to find good ML/Haskell/whatever programmers. And lots of people get away with writing ugly Python or Ruby code.
I don't get these rants. Both C and C++ are such barebone languages that you can take or leave pretty much everything but the common syntax. Zed decides C's string functions are not up to scratch, and so uses bstring. Plenty feel the same about std::string, and will use bstring's CBString, Qt's QString, or some other class in their C++ code. Exceptions? Take them or leave them. setjmp/longjmp? Take them or leave them. Templates? Take them or leave them. Macros? Take them or leave them.
The problem is, your co-workers will do the same with other features. Unless the project is under a strong dictatorship, you'll end up taking everything.
Freeing the list elements is done in one place only, in the destructor of LinkedList. In C, you have to call some kind of free function in every single place a LinkedList is used. The burden of managing memory is on the user of a library, not on its creator. I don't think this is enough to justify using C++ though.
Thank you for bringing that up. It's called RAII and it's one of my favorite features of C++. The fun thing about it is that it can also be used to manage other resources such as files, sockets, locks or what not.
I really dislike C++ but more to the point I really dislike other people's C++.
This is triple compounded when you only have to do C++ occasionally. I've never even got close to the point of looking at something like const *const char & and reading it like it was something normal like others seem to do.
I really dislike C++ but more to the point I really dislike other people's C++.
That's right on the money. I can find a subset of C++ that I like and that I could program with, but that assumes that I'm not collaborating with someone and that I don't have to use C++ libraries (It's not just the code, it's the APIs, too). The latter is almost worse. I could imagine a company that has some rather strict standards, where the C++ development environment doesn't suck completely. Google's style guide seems to indicate that they might be one of those companies [1]. Much more likely you'd have to work with something like MFC, VLC or the complete boost hodgepodge.
And Zed is right when he's talking about the template meta-programming fad. I haven't seen any project where the pros outweighed the cons. And yes, I've read Alexandrescu.
People often say that you need all those features to build large applications. Which reminds me a lot of the "Doctor, it hurts when I do like this!" joke…
There are some very good template-based libraries. I think STL is mostly ok, but also libraries like Eigen are great, and avoid a lot of code duplication through templates.
Templates as they were used/implemented in earlier days where quite okay, apart from having to use other people's libraries, I preferred to solve problems using generic programming than just building class hierarchies (which now nicely translates to functional programming).
Apart from very crappy compiler support (looking at you, Microsoft) I really liked the STL. It's simple enough (maybe a bit too simplistic).
Template meta-programming is a whole 'nother deal. It's like the rabid daughter of an unhappy marriage between Lisp's macros and Perl. From some angles, she looks rather enticing. Then she bites down on your crotch.
Exceptionally good critique. But there are exceptions: programming for Google's V8 in C++ is a pleasure. I've never seen any interpreter code so clean and easy to extend. Like a breath of fresh air.
No, it's not an "Exceptionally good critique." It's not exceptional, it's not good and it's not a critique.
It's not exceptional because nothing of the points he raises are anything but a re-re-rehash of the same old tiring arguments that have been raised against C++ for 15 years or more.
It's not good because the examples he makes are straight up wrong or so vague as to be useless. His 'const' example is jibberish and the line about adding two integers with templates doesn't make any sense whatsoever. I guess the response to this would be that these points were exaggerations, mere literary style figures, which is fine. But it does take away from the quality of it as a serious post.
And finally it's not a critique. A critique implies some level of sophistication, an honest attempt to understand something and providing well thought-out arguments against the trade offs that were made in the design, or different viewpoints on fundamental issues. This is just a rant, touching on some of the more superficial shortcomings of C++ that are easily worked around and that for the most part haven't hampered tens of thousands of C++ programmers to use the language successfully for 20 years. A rant, yes. Venting, OK. But a critique, this is not.
Hi Zed! Actually my code (unreleased but working prototype for a year) is an nginx server with a CMS module using V8 for scripting and templating web pages. Code is C (nginx module + w/ nginx-api) and C++/JS for the CMS. So I cross 3 languages. Works like a charm: ~6K req/s for complex queries (cached disk access with 1+ lstat() call every second.) Memory usage contained very well (always <20MB.) It's so good I don't touch the GC. Also since its security model for Chrome is among the best the "workers" can be recycled very fast if you create a good context.
The problem with V8, as with almost anything, is it doesn't support well threading and its GC can be a bit unpredictable like any other automagic memory management interpreter. But even so, there are ways to control it.
I certainly relate to what you wrote because I used to be a C++ dev in mid-90s (wintel, shivers.) But if you have some time, have a look at V8 for developers. It rocks. Also the newsgroup has a great community.
That's what I've written a library to fix - it makes it quick and easy to bind C++ api's to make them callable from a dynamic language. Not only can you bind a C++ function with 1 line of code, but if that function returns an object, the returned object's member functions are callable on its scripted instance:
Currently there is only an Io backend, but the library is designed so that the same C++ bindings can be used with multiple different backend languages. It's like Boost::Python on steroids.
I've seen you talk about this on the Io list for a while now, but you never seemed to have posted a link to it. Glad I can finally take a look at it :)
http://www.swig.org/ automatically binds existing C++ software to other programming languages. I use it a lot to call C++ from Python and Java and I must say it is really amazing piece of software.
I don't know if V8 follows the Google C++ Style Guide[1] (I doubt it, but it is possible), but that could explain a lot. I feel that it provides a good balance between power and readability. You don't have the language-within-a-language pattern that arises in some of the boost libraries, but you do get RAII and a few template tricks. The language feels much like a cleaner Java, with very few opportunities to do something incredibly stupid.
However, if I had not been given the style guide and a more experienced reviewer to tell me right from wrong, I would be incredibly frustrated with the language. C++ is complex enough that a book probably isn't enough - you either need a mentor-type person or a very clean open source project to study.
What would be better is if C and C++ divorced each other and people realized that they are two separate languages. All of Google's results for C questions end up linking to some "C/C++" forum, which is almost certainly not what I'm looking for. I'm sure the other way 'round is true too.
Probably another run-of-the-mill confusion of macros for templates.
"LISP" is a convenient red-herring to throw into PL diatribes; it shows the speaker has some authority since he is "aware" of Lisp, and the glowing and mystical connotations that this, vague, awareness carries.
No, more a nod to Lisp getting "metaprogramming" right when C++ screwed them up. If I've gotta do it, I'd rather do it in a language where the turing completeness wasn't designed to be a tarpit.
And there goes my attempt to trick you into becoming a Lisper :-(
Learn CL inside and out, not because you want to be a better programmer, but penning "Lisp is a Ghetto", if you get it right, will guarantee your name echoes in the hallways of hacker heaven long after we're both gone.
I have to agree with the spirit of the article. In the late 80s and early 90s, much of my work was in C++, and I did some mentoring, wrote a bunch of C++ books, etc.
After my C++ period, I did a major project for myself and just used C - like a breath of fresh air after C++
In all my years using C++, I think that the only good applications where C++ made sense was in Nintendo and PC game development at Angel Studios and some VR development for Disney and SAIC. Everything else that I did in C++ should have been done in different languages.
The std::string example given by Zed shows that he didn't hack around C++/STL much.
There is a whole entry in Exceptional C++ Style (or another Herb's book) that says how much std::string sucks and how you can write an equivalent extremely quickly.
Anyway, don't like std::string ? You can use std::vector in place very easily, that's a well known trick (thanks to the guarantee that &v[0] returns a pointer to the data if v is a vector).
He talks about references but he seems to ignore the capability of C++ to offer perfect forwarding which enables you to greatly increase performance and memory usage and that's very difficult to mimic in pure C.
There's a lot to write about inaccuracies in this post actually, but what the point? People who hate C++ will discard them and people who love it already know it.
I tire of reading posts from people who didn't like a language for whatever reason and try to rationalize it.
This is the first time I heard of Grace C++[1]. Looks very useful. I was looking for string that can be used for binary data. Looks like they support that too.
I like C or C++ for native but use C++ more because I write it with simplicity. Complex C++ like MFC, Windows API, template hell is disgusting and wrongly gave C++ a bad name.
C++ OO can be done to really abstract the application but still be very manageable and simple. Also C++ is a game industry cornerstone. I think game code in C is actually harder to consume that game code in C++.
I always see streams brought up as a critique of C++, at least compared to how it is handled by C, and I agree that they are terrible. However, everyone else also agrees that they are terrible, and as an added bonus the C IO functions are still available.
C++ brings a lot of heavy-weight machinery to the table but the best part is that you don't have to use it. If you just want to write C but desire templates to reduce the amount of writing you need to do then so be it, write C-with-templates!
My big beef with the language is mostly due to the legacy crud it is saddled with in the C preprocessor. Many of the build time issues I find myself suffering with are because of people, for example, including Windows.h a) in the first place and b) not defining WIN32_LEAN_AND_MEAN. Junior (and senior, for that matter!) developers seldom know how to properly structure their code so that their iteration times don't plummet.
Thank you for this post. For the life of me I cannot explain why, but it delighted me immensely, and I am inexplicably incapable of reading it in my head without an exaggerated British accent.
Strangely enough, despite being thoroughly american, I am given to british spellings and mannerisms in my writing and speech. I think it has something to do with being really into british humor and fiction for most of my life. (british comedies, Terry Pratchett, Dr. Who...)
I constantly get teased by friends about my british spelling s of common words.
The problem with const string& is that the resulting string is not interned - e.g. one copy in memory, which would later allow to save memory, compare by pointer equality (eq), etc.
I understand that the language cannot express it, and that's why other languages (such as lua) do it the right way - immutable strings all the way, or at least by default (NSString)
That was rather bogus. Sure, destructors are horribly complex in their interaction with all of the other horribly complex C++ features. But unless I'm reading it wrong, Aughey wasn't suggesting using all those other features.
If you have some reasonable self-control, it is quite reasonable to use C++ as a small superset of C.
There are great C++ projects, but the big compile/link times they have are not a small deal. Also the compiled libraries take a lot of space. Examples:
Qt, wxWidgets, LLVM, boost
Hopefully we have IncrediBuild at work, and we don't have to deal all the time with such huge frameworks.
You don't have to build these libraries from scratch every time. You could store pre-compiled binaries in a shared drive for every possible configuration, and developers can simply copy them to their machine. Not that big a deal.
The problem with a lot of these posts on HN is that the audience seems to be rather biased towards low-performance app areas like web, and business apps.
Oh noes! I have to handle 10 requests a second!
Take a look at the SWENG-gamedev mailing list for some of the performance issues that people face in games and game tools.
/pissing-contest
Note: obviously this is not an argument against C instead of C++. It's more to forestall the meta-discussion.
The novice programmer looks at the code and sees bit, bytes, pointers and functions. The advanced programmer looks at the code and sees class hierarchies, design patterns and frameworks. The master programmer looks at the code and sees bit, bytes, pointers and functions.
Before mastering C, bits are bits, bytes are bytes and pointers are pointers. While learning C, bits are no longer bits, bytes are no longer bytes, and pointers are no longer pointers. After mastering C, bits are once again bits, bytes are once again bytes, and pointers are once again pointers.
After getting use to the STL containers... I could never go back to pure C. I use C++ daily and love it. Nothing against C (if that's what you like) it's a great little language.
Why is it that C programmers bitch about C++, but C++ programmers don't bitch about C?
I'll second that. I find Objective-C nice to work with. The real issue is the lack of cross-platform compatibility (think Cocoa). The rest I write in C. That or a dynamic language. Ruby, Javascript, Python--they're all pretty much equivalent for me by now. I can transliterate code between modern implementations of all 3 without a hitch. Practically find & replace fast. Most of the semantics are roughly the same. All support JSON happily.
Lately, I've been using [Jansson](http://www.digip.org/jansson/) for JSON support in C. Wonderfully simple and fast. Also, [zeromq](http://www.zeromq.org/) for everything: logging, sockets, messages. Hoorah. F@&# yeah.
The portable subset of C++ were around long before mozilla, webkit or chromium. Anyone can read mozilla's or google's guidelines about which subset of c++ is safe to use.
One of the best examples is Informix RDBMS which was acquired by IBM in 2000. And the second best is... JVM. ^_^
I never said I didn't know where to get one, or to actually write it. In fact, you can do it way simply with getline(). It just always pissed me off when I hack a little something and there is no split.. I then need to either include boost which is huuuuge compared to my 200 lines file.. code it myself, get a snippet from internet.
The point is: in C++, there are so much things.. It's like a fuckload of thousand of features to satisfy everyone. How the fuck can there be no split? Ruby, split, python, split, java, split, php, split, C# split, C++ -your-20-lines-function-which-only-support-splitting-on-a-char-but-not-on-a-string.
* C++ circa 2000 (before mainline g++ could handle Alexandrescuisms) is significantly different from C++ circa 2010, albeit in ways that probably upset Shaw even more (the more central role boost has taken, the more "expressive" templates have gotten, don't call me on any of this stuff).
* C++ std::string is an abomination, but you can always just do what I've done and what lots of other C++ programmers whose code I've read have done: just use char* and a simple string library (or a custom string class).
* Ditto for stream IO, which is a huge C++ misfeature but which is also pretty much irrelevant (I know of no part of the standard C++ library outside of things that explicitly support stream I/O that rely on you using it).
* I don't get the POSIX argument at all; just call the POSIX functions, they work fine. Nobody mandates that you use (say) ACE_wrappers to do systems programming.
* const-correctness may be another misfeature (I know I make fun of it), but the point isn't hard to see: if you take the time to const-correct your code, the compiler will spit out errors that would have otherwise been runtime faults.