Why C++ is not my favourite language
snell-pym.org.uk
snell-pym.org.uk
C++ programmers: we do the dirty work so you don't have to.
"As long as we limit the comparison to things (our language) does well, and exclude things C/C++ do that (our language) can't do at all, (our language) totally 0wnz C/C++".
Lets face it C++ is something like 30 years old this year. For a 30 year language to have so many flaws, and for newer languages to make a better job of integrating OO while still keeping the power: you have to ask whether the C++ community really knows all about technology and nothing about design. The whole project has been mislead from start to finish. It strikes me it had to take a couple of ada programmers to write the STL.
* VM implementations (I mentioned Factor, but also HotSpot, Microsoft's CLR, SquirrelFish, TraceMonkey, V8 and Opera's Carakan are all high-performance VMs written in C++ (x). Note also that all major layout engines are written in C++. Complex but fast and highly-tuned beasts)
* Production rendering. PRMan, MentalRay and pretty much every other renderer in day-to-day use on film and video post-production are written in C++.
People who write these systems care deeply about performance. They'll dip into assembly when they have to. While fast, C won't cut it because in these cases, it doesn't give you enough abstraction to avoid making your code a mess (strong typing, operator overloading and templates in particular, but also virtual method dispatch)*. I'm sure if you ask them, they'd tell you that they'd love to use something nicer and more modern. But it doesn't yet exist.
This is not to say that C++ is the right tool for writing web applications, or even the average desktop application, or even - increasingly these days - games. But somebody needs to write the stack underneath, and that stack needs to be fast.
(x) note Mono as an example of a VM that sticks with C. But it contains a lot of object-oriented shennanigans that probably could be better expressed in C++, and the core developers came from a strong C culture.
Perhaps nobody would have invented C++ if D would have come earlier.
- Of course there are lots of good things written in C++, there are also lots of dreadful things. This is not a reflection on the language so much but the talent of the developers involved. If nothing good had been written in the language in the last 30 years then it would be a real disaster.
- C continues to be used for very large projects, you only have to look at linux. One of the problems with C++ is the amount of bad programming there is. Perhaps this is because such poor examples are given by the in the Standard C++ Programming book.
There is of course objective-C, I wonder whether the first version of Doom was objective-C: there is a high possibility given it's NextStep lineage.
I'm not sure if I'd go this far but have your read: http://thread.gmane.org/gmane.comp.version-control.git/57643...
С - simple and stable, C++ - huge and changing. C - portable and easily parseable, C++ - unpredictable and unparseable. C - good, C++ - bad.
1) it set out to be a no-compromise systems programming language
2) it's being designed by people with an deep and intimate knowledge of C++ (Walter Bright wrote a C++ compiler - no mean feat, and Alexander Stepanov was Mr STL)
These guys know the good, the bad and the ugly of C++ much better than most. From the stuff I've seen so far (check out Stepanov's presentations on an iterator-free STL, or adding functional purity, and also look at the work on making floating point more rigorous) this could finally be a worthy successor.
The old C infrastructure is really outdated already -- you can use C and a very limited subset of C++ (without OO), and be perfectly happy.
How's it outdated? Linux kernel is written in it.
As for limited subset, people would push and push the boundaries until your code grows fangs and horns
A lot of functional programming languages have also become quite fast in the last decade. While there are in a sense more fluid than C++, they are normally considered static (and not dynamic) languages.
If you want to compare asymptotic speeds where programmer-hours invested goes to infinity, the lower level languages will probably always win. Like assembler, C or C++.
For benchmarks see: http://shootout.alioth.debian.org/
The king of dynamic language performance right now is LuaJIT, which crushes Perl, Python, and Ruby and performs admirably relative to Smalltalk and Scheme.
On a side note, a lot of the benchmarks had to be reformulated after lazy languages got fast. As far as I know, a benchmark at this side prescribes which algorithm you should use. Haskell (and e.g. Clean) just ignored a lot of the baggage because it was not used any further.
As you don't say how far "in the past" maybe that's nonsense or maybe that's true.
> a lot of the benchmarks had to be reformulated after lazy languages got fast
That's nonsense.
Programs for one benchmark - binary-trees - had to be rewritten because "this is an adaptation of a benchmark for testing GC so we are interested in the whole tree being allocated before any nodes are GC'd" and with lazy evaluation GC gobbles up nodes before the whole tree's allocated -
http://shootout.alioth.debian.org/u32q/benchmark.php?test=bi...
Every week there are new programs, often from people who haven't contributed a program before.
One of these days someone will find a way to make effective use of all the cores for n-body, maybe.
I do not know why this fact remains so little-known.
[1] http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd...
I'm pretty sure that C++ code (which allows templates, function objects etc) can be written to do the same.
Of course, then we'll get into discussions about whether the C++ code is "idiomatic", requires "wizardry" etc.
The biggest win I see for JIT'd dynamic languages is their ability to optimize across source files. I wish C++ had the capacity to slurp in ALL of a project's C/C++ files and compile it one pass.
In these days of 16G developer desktops, is this an unreasonable demand? :)
Now, let's just wait for my colleague to start ribbing me for keeping our project written in C again... ;-)
Yes, there's a lot of depth to C++ but you derive a lot of benefit from other's wizardry even if you're not a magician yourself.
Maybe this guy didn't invest as much time on C++ as he did on his other languages.
If you are just plugging components together I can think of better languages.
In my experience C++ demands more time that most languages to master. Which is a far longer time than, say, C.
The idea that you can write (!) sane code in C++ by using a simple/sane subset is of course true. But the problem is that in a language of this complexity no two people are going to be able to agree on what that sane subset is. One person may love auto_ptr and use it everywhere, confusing her coworkers who don't get reference counting idioms, but love the STL...
By the time you manage to get your project's coding standards hammered out and enforced, and get it rigged up so it can talk to your external libraries that don't adhere to those standards, you might as well have given up and used C to begin with.
I've done plenty of C++ in past jobs... which is why my day job is in C :-)
SRFI-4 (http://srfi.schemers.org/srfi-4/srfi-4.html) provides a standard interface for dealing with 'homogenous vectors' (eg, arrays of unboxed integers or floats), which is great for shuffling bytes.
For bits, there's the usual bitwise-or and all that.
However, both could be improved somewhat; what the Factor folks have done with their struct arrays is IMHO superier.
No, one of the requirements for static optimization is that a language be statically typed. It does not follow that there are no ways to make dynamic languages fast, just that they mostly have to use different techniques.
Perhaps some of them could be applied, but a highly complicated base language with extensive mutation semantics (including pointer aliasing) probably mean they'll be so limited in their applicable scope, and so difficult to implement, that it's not an attractive activity for C++ compiler writers...
Strict typing was mostly about trapping programming errors at compilation rather than runtime. Perhaps something despite all the effort C++ has struggled to improve defect count through typing (C++ systems often fail for far more obscure reasons, and the strict typing can cause hideous compile-time errors).