Author of "Modern C++ Design": STL iterators must die
boostcon.com/site-media/var/sphene/sphwiki/at...Posted May 8, 2009, 3:58 AM UTC
246341
boostcon.com
The idea of using ranges instead of iterators has been around for a long time. We were discussing it on comp.std.c++ back in 2003, for example, and I doubt we were the first. That said, it's good to see someone more visible in the C++ community advocating the idea. As others have pointed out, it has been implemented in various places already, Boost among them, but it hasn't really caught on widely yet.
I think the label "range" is unfortunate, though. The real power of this approach, IMHO, is not the way it simplifies code operating over a range of container elements, welcome though that simplification may be. More valuable is that now we have the implementation of iteration/generation separated from the interface, which gives us a limited form of lazy evaluation. Put another way, we can write and compose reasonably efficient filters, reversers, strides, list comprehensions, generators, and so on. Alexandrescu touches on this briefly in the presentation, but I think perhaps he undersells it.
29
Thank you for actually talking about the topic and providing a related link, instead of jumping into a giant flamewar about C++ and all related languages just because the guy used C++.
You know what would be nice, is if all these flamers would actually post some code showing how this range idea would work in their language of choice.
10
I think the label "range" is unfortunate, though
Yeah, they're just non-stupid iterators aren't they? The examples in the presentation feel much like Python's iterators (although they're bidi, Python's iterators usually aren't)
2
I think the important thing is that they present data as a linear sequence. That's all many algorithms really care about. It doesn't matter whether the data originally comes from an ordered linear structure like an array or linked list, or from a graph structure that's been flattened, or from an unordered set that's been assigned an arbitrary order because you've got to process its elements one by one, or even from a stream that you represent as an infinite sequence.
Note that this isn't necessarily the same as identifying a specific set of values, because order matters. For example, you might traverse a tree in depth-first or breadth-first order, even though you would eventually consider the same range of nodes either way. So while the term "range" makes sense immediately if we're talking about an inherently linear data structure like a linked list, in general it is only meaningful once we've defined an order for our sequence.
Note also that this is a separate concept from how an algorithm traverses the sequence, for example, whether it uses a single pass or random access. IMHO, the STL actually gets this part right, because it distinguishes things like forward iterators from bidirectional ones. But there is a difference between this traversal process and the process of constructing the sequence to be traversed, and I think it would be helpful if we could model both of them cleanly in our designs.
10
Note also that this is a separate concept from how an algorithm traverses the sequence, for example, whether it uses a single pass or random access.
How the algorithm traverses the sequence is the entire point of iterators. If you can randomly access elements through an iterator it's just a list, and a ListView would work just as well... instead of obj = iterator.next() you'd say obj = listview.hideFirst(). The point of iterators is entirely so that you can't do random access on them.
Really the only use for iterators is to cause an algorithm to efficiently look at any given structure. If you have a singly linked list then code that does "for(i=size-1; i>0; i--)" will be really slow.
I'd rather see a kind of ListView than iterators anyway. It would basically be what ranges are, only with even more flexibility; everything is a list after all. For instance, you could create a CachingLinkedListView that remembers some node locations so that random access is not incredibly slow.
3
Who on earth would search a linked list using an index? This is why all computers need to armed with a 0.50 cal to euthanise anyone stupid enough to do this.
1
If you have a singly linked list then code that does "for(i=size-1; i>0; i--)" will be really slow.
That is what skip lists are for.
0
Oh I hadn't thought of it that way, but now that you point it out you're right.
2
I owe an apology to Randall Munroe, the man behind xkcd.com. I used one of his comics in the presentation without credit. I've added the appropriate credit now and asked the conference organizers to replace the presentation file.
edit: Boostcon organizers replaced the PDF. Thanks to Hartmut Kaiser for a quick turnaround.
23
The use of ranges completely obsoletes the old iterator design. Andrei has designed a set of ranges and algorithms to demonstrate.
20
The old iterator design still has the advantage of being syntactically compatible with pointers.
9
Which is not that big of an advantage given how little regular arrays are being used in modern C++. Also converting a pair of pointers to a range would be trivial (mk_range(ptr1, ptr2)).
23
That may be a useful abstraction but STL's mistake was making it the abstraction.
7
That doesn't even make any sense whatsoever. The STL is about generic programming using containers, algorithms, and iterators. They all work together. There is no "the abstraction." The entire point of the STL is to avoid abstractions.
-1
The STL iterator concept is an abstraction, and it is the fundamental abstraction that glues together STL containers and algorithms. The concept is refined and ramified into several varieties (bidirectional, random access, etc) but there is a common denominator.
If you think STL has no abstractions, you need to look up the word's meaning in a dictionary. It's true that Stepanov wanted to avoid what is usually called the abstraction penalty by not relying on virtual functions but that is not to say there are no abstractions in the STL; generic programming requires abstractions. The issue of whether the abstractions can be resolved at run-time or compile-time is separate.
3
Semantically as well, for the most part.
4
Why the downmod? Koenig has said much the same thing. Iterators are an extension of the concept of a pointer.
5
I upvoted you because you're correct. That was the entire point of the iterator.
1
C++ is the steampunk of programming languages: modern ideas realized with victorian technology.
19
Nice quote. Mind if I steal it?
1
feel free :-)
1
Not trying to troll, but after using functional languages for a bit, it's hard not to look at C++ (I've used it for about 10 years) and wince. In languages like OCaml, you can display everything in a collection x using something like "iter display x" and sum all the numbers in a list using "fold_left (+) 0 x". The code for this in C++ is hugely verbose, error prone and conceptionally very complex.
18
I've been doing C++ for 6-ish years now, and started doing serious Erlang last year: what a breath of fresh air that was. Your comment is spot on.
8
I remember I used to think I was so clever reading the C++ language specification (in other words, finding out all the behaviour that was undefined) and reading all the horribly complex design hacks you need to get usable code. When I learnt a language like OCaml, it was so refreshing how little there was to the language. There really isn't much to learn at all and you can do mostly everything you can in C++ more easily, quickly, with less errors and with much less thought. I always used to read about how "good C++ programmers know how to avoid that" for e.g. memory leaks; it's just too exhausting being a mythical good C++ programmer. Life doesn't have to be that hard most of the time.
10
yer hired.
2
Interesting. Although I personally can't stand seeing Complex numbers used as a paradigm for the fabled "nonintuitive concept". They are as intuitive when related to the plane as the Reals are intuitive when related to the line.
15
Actually, Relativity, at least the Special Theory, -was- intuitive to Einstein. It was the result of a simple "what if?" idea.
But he is correct that STL is not responsible for lack of lambdas. That's still one of those "maybe next time" features that the language itself would need to support.
8
C++0x does, hideous syntax though
10
The math sure wasn't. Lorentz did it before he did. Einstein just said the obvious after that. Everybody else couldn't because they were thinking wrongly. But then that is the definition of genius right?
9
Funny. His book kind of almost convinced me that C++ must die. Really.
14
It was aimed at library writers mainly I think. I didn't get very much out of it either(policies are a notable exception).
1
Too true for words!
-4
Wow, I never thought anyone could make STL code look beautiful. Will this really work in practice like it does in the slides?
13
Although nobody has yet built a C++ version of ranges, there is a D programming language implementation and it works in practice.
13
nobody has yet built a C++ version of ranges
How so? It seems that Torjo and Wilson did just that:
"Currently, there are two implementations of the Range concept in C++, in the Boost and STLSoft libraries." http://rangelib.org/#implementations
"Before going into details, it's important to state that there is nothing about the Range concept that limits its implementation to C++. We're intending to look into its application to other languages, such as C# and C++.NET. Matthew is currently integrating ranges into the D language's standard template library, DTL." CUJ, October 2004
14
I can't say for sure but I got the impression that c++ doesn't have ranges as the fundamental component, as opposed to slapping them on top of iterators.
2
"We're intending to look into its application to other languages, such as C# and C++.NET."
In .NET we already have exactly the same feature - it is called IEnumerable<T>.
1
[deleted]
1
Almost sounds like he's pushing for using D instead of C++.
9
I am.
22
[deleted]
3
Of course you are. You have a book on D coming out that you need to promote and you in no way would purposefully neglect to mention that C++ 0x added a ranged for-loop. Or how about the things you can do inside of a for-loop with iterators that you can't do with ranges?
Or let's talk about how you purposefully make your syntax look cleaner by using "R" for ranges in
template <class R, class T> R find(R r, T value);
but neglect to show the construction of the range so that it would look nicer than the ranged iterator constructor of the standard STL?
-2
I think there is some priority inversion somewhere. First, I'm not cracking D to be good because I'm writing a book on it; I'm writing a book on D because I believe D is good, at least at the kind of things I'm interested in doing. Second, when writing slides it is routine to leave out the obvious and inconsequential details; it hasn't occurred to me that that could be interpreted as malice. Third, slides never convey 100% of the information in a talk, and there has been plenty of clarification of the ranges' limitations in comparison to iterators (ranges are a higher-level abstraction and as always there will be things that you can do with iterators that you can't comfortably do with ranges); much of the punchline of the talk is that all of STL and much more can be implemented at no additional cost by sticking to the range abstraction and foregoing a few capabilities of iterators. Finally, I thought I've done and am doing enough for and with C++ such that nobody in their right mind could accuse me of rigging comparisons. Live and learn :o).
edit: Upon second read I understand you think my using of the one-character "R" for ranges vs. the two-characters "It" for iterators is a little malice aimed at making iterator code look bulkier. I never use "I", "l", "o", and "O" as symbols. It's in Sutter's and my Coding Standards book. It didn't occur to me to use e.g. "Rg" instead of "R" lest a conspiracy would be unveiled.
9
I wasn't aware D had the STL now.
What does he mean?
6
He probably means that many features of the STL can be found in D's standard library.
eg. http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html
7
Evidence: No language has supported the STL “by chance.”
◦ In spite of relentless “feature wars”
◦ C++, D the only ones
◦ Both were actively designed to support the STL
I can't prove it without actually implementing the STL, but I am almost sure that it could be done in ML using functors. This flies in the face of the last assertion.
5
Infact, something similar does exist, but I imagine some of its inpiration originates from STL:
http://ocaml-reins.sourceforge.net/
I haven't actually used it, though, so I don't know how pervasive iterators are in it. But it does have the concept.
2
Looks like he re-invented Python iterators for C++.
5
Yeah that's exactly what I thought when I reached the examples (Zip&al), ranges really are just non-stupid iterators.
Though apparently he wants ranges to be bidirectional iterators, I think Python iterators are solely unidirectional (though you can reverse them)
4
I didn't see it explicitly mentioned, but I think they also want to support random-access iterators, to accomplish this (page 44):
//sort the two in lock step
sort(zip(vs,vd));
That's not possible with Python iterators. In Python you have to build a temporary array to be sorted.
4
That is correct. A category of ranges does offer random access by simply adding the appropriate function or operator; I didn't make that obvious point because for the audience of the talk, it was a foregone conclusion. Anyway, the claim stands - the sort function as defined in D's std.algorithm is able to sort several ranges in lockstep (by using zip), which is quite a trick because sort is not easily decomposable that way.
6
is able to sort several ranges in lockstep
What does it mean to sort in lockstep? Does it sort in lexicographic order?
2
I saw that, but I'm not sure what to make of it, I'm not sure of the semantics this would have.
1
Because "Andrei Alexandrescu: Iterators Must Go" doesn't sound as dramatic?
5
Good god, C++ is ugly. I've been writing in Obj-C and C# for about 6 years now, so I've been out of the C++ world for a while.
Every once in a while I'm reminded why I never looked back... this is one of those times.
3
yes, because
[object method:arg1 Arg2Name:arg2 Arg3Name:arg3];
looks so much better than
object.method( arg1, arg2, arg3 );
It's all preference, but I think objective c is pretty ugly and misshapen in its own right.
29
Compare a ten parameter ObjC method to a ten parameter C++/Java/C# method, and you'll see why ObjC got it right.
Compare a one parameter ObJC initializer to a one parameter C++/Java/C# constructor, and you'll see why ObjC got that right too!
11
If you are regularly writing 10 parameter methods by hand, you are doing it wrong.
21
It's called an exaggeration.
Though it does have drawbacks, Smalltalk's system is clear, expressive and strongly enhances readability no matter the parameter count of the method (*).
* as long as the message name is correctly thought, but nothing can fix stupid namings.
1
Yeah, but no matter what else is true, Objective-C still requires that the name of the first argument be encoded into the method name somehow in order for the code to read properly.
Considering how much of your time is spent writing methods, it would be sweet if the language didn't bludgeon me with this idiocy on every one. It's a little known metric, but "lines_of_code / times_I_scream_fuckmonkey" is a pretty good one, and Objective-C doesn't fare quite so well there.
Also, it might just be me, but if you have to do without GC in Objective-C, as you do in the iPhone, then it has the absolute worst memory model I've ever seen. Either just do it for me or let me handle it, but don't make me babysit your internal model of the program just so you can figure out how to free the memory properly.
2
It took me ages to get my head around the memory management but now I'm there I kinda get it. I was a hard and fast C++ guy for ages, with all the "if you made it, you get rid of it again" idioms that tended to litter my code. But Objective-C's memory handling makes it easier to bat the 'ownership' of objects between parent objects without worrying how you express "so now you have to delete it, unless you set the fooBar flag in the other parent class and etc etc".
The other thing that takes a while but works when you get there is the idea that most classes, especially collections, are immutable. Strings, maps, arrays ... all immutable (unless you use the mutable one). But it makes sense when you combine it with the memory management and being able to send pointers to things around without losing sleep over who will eventually deallocate it ... because loads of things can have a pointer to a single immutable map and nobody worries about whether or not it's going to change "underneath" you. Good for thread safety too, eh?
7
Objective-C still requires that the name of the first argument be encoded into the method name somehow in order for the code to read properly.
You don't get it. There is no "name of the first argument", Objective C comes from Smalltalk, the whole thing is the method name (or more precisely the message name in Smalltalk lingo): message names are compound.
In malloc's (very bad) example the name of the message isn't method, it's method:arg2Name:arg3Name:. Smalltalk doesn't have named parameters.
That's simple, powerful, and more importantly geared towards readability. Code is usually read more than it's written, and Smalltalk (and therefore Obj-C) gives the programmer the ability to make message names extremely clear, making code unambiguous.
4
I have been coding embedded systems for 8 years now.
Other than the HIDEOUS and I do mean AWEFUL, SPAWN OF Cthulu, Kim-Jong Ill, Satan, and Hitler, signing requirements and signing tools, the iphone sdk, memory model, coding etc has been the most pleasant embedded development platform I have seen ever.
I've worked on tons of bare metal microcontroller designs, 5 embedded linux platforms, some javaME, some winCE, and a bit of palm even. Nothing has come CLOSE to how pleasant all portions of working on the iPhone API/tools/memory model.
I think you're just not used to embedded development. The iphone is a GREAT platform for developing an embedded application.
The memory tool is suburb for debugging these types of problems (which actually astounded me, I was expecting it to be bad).
Any platform that comes with not only GDB working great, but builds on top of it in a useful way is a godsend to me.
2
Write a ten parameter method and fail at programming.
2
Obviously the people who wrote the Win32 API were champions at failing at programming.
6
Write a ten parameter method and fail at programming.
Only because your language of choice does. Do a little research.
2
C++ is only beautiful when you are :
1/ using it as C with classes 2/ and restrain yourself to using it only when you truly need speed and nothing else
Objective C, is a C with classes. And nothing more. And that's why it's so much better than the tentacular, "modern" C++ which piled features after features over a language which couldn't truly take it so the grammar can't be parsed by a smart IDE and so on.
6
C++ is only beautiful when you are suffering from a brain disease
FTFY
0
[object method:arg1 Arg2Name:arg2 Arg3Name:arg3];
Except that's not how Objective-C is used at all. You're going to see more something like this:
[UIView setAnimationTransition:UIViewAnimationTransitionFlipFromLeft forView:self cache:false];
Please tell me how this is better:
UIView.setAnimationTransition(UIViewAnimationTransitionFlipFromLeft, self, false);
The whole point is that it is, to a point, self documenting and more explanatory.
6
Please tell me how this is better:
Well if it's Java, you'll be writing setAnimationTransitionForViewWithCache, and then you shoot yourself.
10
I know, so you can accidentally write
UIView.setAnimationTransition(UIViewAnimationTransitionFlipFromLeft, false, self);
instead!
2
It's all preference
Speaking as someone who's lived with both for years, no, it's not. The syntax for Obj-C is clearly superior. The runtime behavior(dynamic everything) and deployment targets (OSX or Linux + GPL) on the other hand may not be what you're looking for.
I think objective c is pretty ugly and misshapen in its own right.
What experience do you have to back that up?
5
The syntax for Obj-C is clearly superior
No, named parameters are clearly superior.
However objC not allowing you to name your message explicitly is actually not ideal in some cases, and requires more OO than is strictly necessary lots of time. For objC, you have to do
[screen drawAt:[pos x:30 y:30]];
If you could instead do
[screen #drawAt x:30 y:30];
I'd say it wins hands down, but the fact you have to often make a ton of parameter objects means you're suffering through a little OO cruft.
On the balance though, I think the OO cruft is worth it to get the named params, if I have to pick between C/++ and ObjC call semantics.
personally I prefer the python semantics because it has a name for the method and names for the parameters.
screen.drawAt(x=30, y=30)
(I write iPhone apps as a large portion of my daily life these days. I can think of at least 5 parameter objects I've had to write that I wouldn't have written in the same application written in python).
2
However objC not allowing you to name your message explicitly
explain.
[screen drawAt:[pos x:30 y:30]];
Why not [screen drawAtX:30 y:30]; ? And why create an object when a struct would do?
2
No, named parameters are clearly superior.
Objective C doesn't have named parameters any more than Smalltalk had. It has compound message names.
Don't see them as named parameters and don't compare them to Python's, they're not the same thing.
2
Objective-C syntax is so great that all the other new languages have picked it up now. Oh wait...
An Objective-C's programmer love for the language must be like a mother's love for her child: everyone thinks he's butt ugly but she thinks he's adorable!
-6
It doesn't take long and when you get there it's got some wonderful elegance to it. Like...
[self drawCollapsedRegionBetween:regionStartPoint and:regionEndPoint];
Now, I'm a believer in commenting but, well, you just don't need to, do you? XCode also has tab completion that actually works now so the actual number of key presses involved in this is quite small and the scope for error similarly reduced.
5
Objective-C syntax
First of all, it's not Objective-C's syntax so much as Smalltalk's.
is so great that all the other new languages have picked it up now. Oh wait...
Does not follow. Smalltalk has a message cascading operator, nobody else ever picked it up even though it's one of the smartest things I've ever seen. Smalltalk had gotten rid of such stupidity as if, while or for statements using functions and method calls instead, no other "mainstream" language ever picked it up, ...
Instead, with have C augmented with classes augmented with a GC augmented with a stdlib slightly less shitty than nothing. And it sucks goat balls through a straw. Language and feature popularity is not linked to their quality. At all.
3
I have worked in both C++ and Objective-C for a long while and can see the pros and cons of the method call syntax in each language.
C++ strength is that simple expressions remain simple, adding less visual clutter to the code stream. This involves judicious use of the dreaded operator overloading, especially when chaining functions or operators together.
C++:
array[i][j][k]
Objective-C:
[[[array objectAtIndex:i] objectAtIndex:j] objectAtIndex:k]
The operator[] is much easier to parse than objectAtIndex:.
C++:
object.doThis(x).doThis(y).doThis(z)
Objective-C:
[[[object doThis:x] doThis:y] doThis:z]
The C++ version is easier to type too, since you don't have to go back and add in an opening [ every time you pile a new call onto the chain. Better still when there are default arguments so you don't have put a bunch of NULL's for missing arguments.
On the other hand, for calls with complex or multiple arguments, Objective-C's self-documenting methods are so much easier to read.
C++:
file = CreateFile(a, b, c, d, e, f, g);
Objective-C:
[view dragImage:a at:b offset:c event:d pasteboard:e source:f slideBack:g]
In Objective-C, this is almost as good as named parameters. On the C++ side, this can be alleviated by proper naming of the actual parameters, but it's not always possible to give the actual parameters names that make sense in the context of the function call, as opposed to in the context of the rest of the code.
3
[object method:arg1 Arg2Name:arg2 Arg3Name:arg3];
...
object.method( arg1, arg2, arg3 );
Will you be happy with the following?
CALL METHOD OF OBJECT PASSING ARG1, ARG2 AND ARG3 RETURNING ARG4.
Expressive, innit?
2
C++ is ugly when you use their streams and STL.
It's o.k. if you use Qt on top of it. Sometimes it's rather cute, that you finally really can program cross-plattform for Win, WinCE, Linux, MacOSX and have GUI, i18n, l10n, unicode, nice containers etc everywhere.
11
And this is why the more esoteric languages are just that : esoteric. In the real world, the available platform libraries matter infinitely more than the check-list style language features wars promoted by the language zealots...
2
I think the word you're looking for is 'esoteric'.
6
Thanks, corrected.
2
Objective-C syntax is probably one the worst I've seen, C++ included. +, -, @, it's insane!
Edit: Ok downmodders, I dare you to name one programming language with syntax worse that Objective-C (besides whitespace)!
-7
Perl.
5
I've coded perl for a while, it's syntax really isn't so bad as long as you use it right and code cleanly. I can't say I've ever used objective-c though
2
I think this one's a tie.
-1
C++. Shells. COBOL. MUMPS.
4
The warts in the Objective-C syntax (which exist to make it fully compatible with C) are a minor little annoyance in comparison to the massive benefits of the rest of the language design. You'd be forgiven for complaining about them after programming in it for a week or two, but after that they really fade into utter unimportance.
1
Please note: “The D Programming Language” soon to appear on Safari’s Rough Cuts.
How soon? I would eagerly subscribe to it, just to have an early peek at this.
2
I'm submitting the first three chapters on Monday, May 11th. With overheads and all, it may take a couple of weeks until the PDF is available.
edit: Fixed date. What was I thinking? Ranges, probably :o).
9
Is this a trick? Friday is May 8th! What year are you submitting?!?
3
Pages 27-30 are my favourite. (Actual .pdf pages, not the numbers in lower left corner.)
And 54, yes.
1
Yes! I've had ideas similar to these in my head for years, only I used the word enumerators instead of ranges. I thought it was nonsense to always go around with two things (two iterators) to represent one set of enumerated items.
To check if begin==end to see if there are no elements to iterate is a bad idea (better enumerator.isEmpty() or something).
And why do we call begin() and end() iterators if they don't iterate? they always point to the same positions.
A selection of all or some items in a set in a particular order should be one object (a range, or an enumerator), not two things. And the enumerator should be able to give us a "next item" and to check whether it contains more items. A bit like the Enumerator class in Java but more C++-style with templates.
1
[deleted]
1
sometimes i think that these "modern C++" guys are living in some parallel world. clearly they need a language with type inference, pattern matching and algebraic data types, like ML or Haskell, yet it looks like there is no ML or Haskell in this world, and they are trying to do everything patching good old C.
if language was not designed around certain concepts, it looks weird and ugly when you try to use these alien concepts in it. and STL/Boost is weird and ugly indeed, and i think no amount of thinking or patching can fix this.
I don't know about you, but I live in a world where:
matter.
ok, let's go through these bullets (by the way, i worked as a C++ programmer for years, now i work as Common Lisp programmer, also i have considerable experience with other languages, so i sort of know what i'm talking about):
by the way, you forgot to mention portability, C++ completely sucks at it.
Hey killerstorm, let's go through them.
STL is the official standard C++ library and Boost is a widely used one. I agree that the syntax is not so nice and that they can be unintuitive, personally I got used to them and maybe I don't see some of the weirdness. The point was more about FP vs OOP and procedural though. I think you'll agree that the functional is much stronger in Haskell than in C++ though and that it's harder to wrap your head around the first. I'm familiar with functional concepts in C++ and Python, but find Haskell alien.
It is, but even so it is a remarkably popular language, much more than Haskell or ML I would dare say.
You'd be surprised at how good the support has gotten these days. Let's take VC++ 2008's debugger support: it can show you how many references are in a shared_ptr or what the elements of a vector are as a tooltip! New compilers don't have any problems compiling either STL or Boost.
Compile performance problems that is, not runtime performance trouble! You're right that Boost can be pretty compile intensive (STL not so much). I personally don't use the Boost libraries that are known to be template metaprogramming heavy (e.g Lambda). You'll have to remember that some of these libraries are experimental and pushing the language's limits. Others were good enough that they got included in TR1. :)
Internationalization: the STL in theory should have handled this, but it's exaggeratedly complicated. Batteries not included indeed... However, you can (and probably should) use ICU or Qt or some other library and all your headaches will go away.
C++ works well at what I'm trying to do. If not, I learn and use something else as I have before. That something else is not Haskell.
Yeah, I did. C++ is jokingly called the most unportable portable programming language. In my experience, the portability depends a lot on what you're doing and at what level you're programming.
If you're letting the libraries do the work for you, it's reasonably easy. If you have to go all the way down, it can be very difficult.
Bottom line: switching to Haskell/ML is much more disruptive than continuing with C++ and learning some new concepts.
I find German to be a completely alien language, so clearly it must be less intuitive than the ones I speak.
C++ is faaaar harder to wrap your head around than Haskell. The sheer size and number of ugly hacks/corners (usually due to back-compat issues) makes it a royal pain to do real work in it.
Lamport says: Programmers will find any excuse to dismiss an approach that would require them to learn something new.
I have a friend. They do high end C++ where they work. They can't find people competent enough to write it; who know enough about C++ and the STL. They've been trying to hire a couple more people for years, and no one knows their stuff well enough to even make it to the in person interviews.
I claim the language is both needlessly complex and non-productive compared to other languages, which is why most of the people smart enough to do it well are either in a niche for life that they love, or have moved onto a language and technology that lets them get a lot more done.
Try nvcc (CUDA compiler) 2.1 then get back to me.
not to mention...
The first three are really, really huge for desktop apps. I have a desktop app I wrote in Java (www.filephile.net) and the next version is being redone in C/C++ for these reasons.
All the users say "I love the app, but I hate that it has to run a JVM." Same would go for any other higher level language. VMs suck for packageable/distributable apps, and VM performance also sucks... people want desktop apps to be very very lightweight. Memory footprint is a bigger problem than CPU use... Java is respectable on the latter but not the former.
Don't even mention Adobe AIR. It's worse than Java.
Did you really say that C++ has an advantage over Java in portability and ease of installation?
Yup. I routinely write C++ that uses boost, stl, and stdint.h and compiles on Windows, OSX, and Linux without a ./configure script or #ifdef's.
But that's not really what I meant. What I meant is from the user/customer's point of view. Even if it's painful for you to port, once you have it ported and compiled it installs easily on the user's end. The user doesn't have to fiddle with JVMs, and you don't have to ship your own private JVM with every package you ship.
1> Java is compilable. Try it sometime.
2> JVM applications are as fast as compiled code given the correct optimizer
3> Python is very easy to package into a desktop application, and damn easy to package into an installer (for windows at least, haven't tried for mac/linux).
4> .NET is trivially easy to package into an installer.
5> Memory footprint is NOT a big problem. The VM (for most VM's) takes up a MUCH smaller portion of memory then any non-trivial program itself does. Repeat after me: A VM is just a program that executes another program, it is not a collection of libraries, that's an SDK.
For instance, with JConsole (in java 5 and later) you can see what is taking up your memory, for a long time now you've been able to reduce the code cache of the JIT compiler down to bad idea low levels, and you can similarly limit the memory usage in a dozen different ways.
I think you overestimate what the memory footprint is on a LOT of VM technologies. I mean python with the repl running is 3mb, java is about 2.8 MB, aka, all WAAAAY under the cache size on modern processors, therefore "small enough" by far.
I think you're not working with anyone who cared enough to google up some JVM size configuration parameters if that's your reason to avoid JVM languages. (BTW, I think Java is the COBOL of the 21st century*, but I think the JVM is cool as all hell of a platform).
Shameless stolen from: http://www.youtube.com/watch?v=3HCZ23JUrvA
And what language is the JVM written in? C++...
(2) is true to a certain extent, certainly not at the moment that the garbage collector runs, which makes a difference for certain classes of computationally-bound applications.
(4) That's just complete nonsense,.
(5) That's just a fucking outright lie. The JVM is not magic; it can not break the space/time tradeoff. The JVM itself might be small, but the memory it consumes to perform its garbage collection is not.
Bullshit.
The same app in C++ uses 1/6th the memory of its Java counterpart. Execution times are not that different, but memory footprint sucks.
Java: distributability, packaging, memory footprint sucks.
Python: distributability and packaging sucks, slow and less responsive
.NET: MS only walled garden, unless you want to distribute Mono
Ruby: dog slow VM
... and so on.
I think we can agree that C++ has more libraries than Haskell, but not more libraries than any language targeting the JVM with good Java interop (like Clojure). All your other points are worthless.
So you have a half a point there.
the only valid defense for c++ is performance. and it doesn't matter in most things I do, as I tested and saw that the jit compilers can even beat it for some tasks. for all the others bullets, high level languages kicks its ass
One bar I always use on all run-time optimizations (which C/C++ are):
Will all the time saved by all the customers in the world who use the app, add up to the difference in the development time between this choice and the unoptimized choice.
And the answer is: Damn rarely.
That works until you get a competitor that produces snappy applications while yours are still lagging. Users do actually care about that - even the one-second-lag they might get will bother them and make them hate the application. And it doesn't matter that it will cost them only few minutes of their life-time in the long run.
You have to add a lot of features to make up for a slow application.
So you are the reason I'm continually breaking my mouse waiting for the computer to perform some trivial operation.
In my domain, yes. And in a lot of other domains where real-time guarantees and response times are critical.
Not everyone works on web pages and idle desktop apps.
Learn about Profile-Guided optimization.
Learn about embedded programming.
OCaml can often match or even beat C++ performance. If you're doing multi-core then Haskell can often be a very good choice for getting better performance.
The C++ performance defense is losing validity.
I'll believe that C++ has lost when OCaml, Haskell, or Lisp get to the top of the Programming Language Shootout. Currently, all three of those are behind C++ in the quad-core rankings, by a factor of between 2 and 4.
Yeah, Haskell's much faster when you use two cores to do the work of C++ one core.
C++ caters to a different problem domain than ML and Haskell. There is some overlap between C++ and high-level langauges, and in the domain of overlap the high-level languages usually win. But don't dismiss C and C++ programmers as idiots.
my comment was not about C and C++ propgramming languages, but about attempts to cram high-level constructs like polymorphism and metaprogramming while retaining all old features.
if language with required characteristics was built from scratch it could be much more clean. for example, BitC seems to be a right thing in this direction -- it combines s-expression syntax, type inference and is suitable for doing low-level stuff (it was designed to make OS kernels). another example is D -- they have added some useful features into the language so they do not need to do everything via god-awful templates all way down.
It might not be obvious, but the purpose of "modern C++" is not to lure people into using C++.
There is a large amount of C++ out in the industry. Code that is in production. For the people that work with this code it doesn't really matter that there are languages that offer other features.
arguably it makes programming C++ even harder -- now C++ programmer has a dilemma, whether to do something with good old classes and pointers, which is usually not safe/not cool, or do it with STL/Boost, which is cool and automatic, but compiles for ages, produces absolutely incomprehensible errors and does not play well with the rest of stuff.
there are lots of different ways to write C++ code and they play with each other not better than if you'd include some Haskell library via FFI. e.g. some libraries use return codes (old ones, system ones), other onese throw exceptions (modern perversions). if you throw exception where old code was expecting it, it will be a total disaster.
This has nothing to do with what is "cool" or not. We ask ourselves:
The answer to both of those questions (for us, mind you) is a definitive yes. This presentation and the work that is done on C++0x is for us, not for the people that is sitting on a fat Haskell or ML codebase.
in real world any thing has it drawbacks, and this boost stuff has its problems too. so it is really hard to say if boost stuff improves code and productivity or not.
yep, maybe you can spend less time on memory managemenent and its problems and your code looks shorter and more elegant, but now you waste your time waiting while it compiles, you need to decipher cryptic errors, and it is damn hard to understand that shorter code, especially for a person who does not know boost (but knows C++), and you waste some time porting your code when a new version of boost is released.
so it is not that simple, and unless you've done some formal testing, you can't definitely say if it improves productivity or not.
i do not understand your "us" against "you", I am a C++ programmer too, and we had different experience in our team -- while most of STL stuff was ok, boost was too much (except some pieces which were fitting well). also i was working in other teams which were more actively using boost, and it was sort of a disaster: it was looking very promising (that's what i mean by "cool") at start but later was huge waste of time.
i understand that it might be a bad idea to switch to something else if you have a fat C++ codebase, but if you're working with C++ currently your opinion is biased. i worked with both C++ and Haskell, but currently not working with any of them, so i guess i'm more neutral, and i say that C++ is shit from this neutral position.
by the way, usual path of migration from C++ is via Python -- you learn dark side of the Boost, then you find Boost.Python which makes wonderful Python wrappers (in both directions), then you write more and more Python and less and less C++.
Swapping to a 2 language (C++ dynamic library loaded from a front end language) approach is a time tested way to not screw yourself over porting to a new language, but at the same time, obtaining fast complexity/development time gains by using that other language where possible.
Python/weave wrappers are particularly compelling to show the approach off (you can do includes/link against libraries pretty easily): http://www.scipy.org/PerformancePython
(I used to be a C++ developer, and occasionally am still. It's just often the wrong choice now, even for other C++ developers. If you're smart enough to do C++ correctly, you're smart enough to do python or ruby effortlessly, or C# with very little work).
Is it possible to port most of your code to another (easier) language but keeping core functionality as C++ .. thus saving maintenance time in the future? Has that been considered?
At least that can be solved by throwing money at the problem.
ummm, not really. we've tried distributed building when project builds became too slow, and even compiling at ~10 CPUs at once was not really fast (faster than on single machine, of course), and it looked like adding more CPUs won't make it faster. (at least for our project, bigger ones could benefit from more CPUs.)
[deleted]
if you want it formal way, "classic" C++ is quite verbose and error-prone. template metaprogramming allows you to do a lot of things automatically, for example, smart pointers do automatic memory management. generic algorithms and data structure libraries can drammatically simplify code, but all these abstraction come at cost..
now, if you had some STL or Boost programming experience, you should know what i mean by "cool". so STFU, bitch
Well, yes - c++ is not the language trying to be clean but the language trying to allow you doing everything. That's the deal. So it's worse in the "clean" section but there's not much where you have to say "c++ can't be used for that".
And at least I can life with a lot of pain and ugliness as long as the language still allows me to do the stuff I want to do.
You can do anything in assembly.
I wasn't so much thinking about the "talking to the machine" part. Though c++ also allows you doing that (including using assembly). But I refered to the stuff killerstorm mentioned here - concepts which are already cleanly implemented in other languages. Like patching OO on top of c. Or adding templates to c++. Or supporting functional programming constructs.
What will other languages like ML or Haskell do when new concepts come around? Refuse to add them to keep the languages clean?
C++ has to add stuff to stay alive. I know lot of people would prefer seeing it die, but well - why should c++ guys care about that? I just use the language (more than a decade already) and enjoy that it's getting better and better for me. So well, c++ might be weird and ugly - but so far the amount of thinking and patching that was put into it allowed me to continue working with it and actually I felt that it always improved the language.
This is actually why Lisp is good. None of concepts other than macros and a few basic forms are built in.
I don't see how that is even remotely possible ;-)
The thing is, they've been looking at ML and Haskell. They'll get there in 50 years, guaranteed.
yup, just like putting a ferrari engine in a chevette.