Defects of the STL

Question

While the C++ standard libraries are very generic and efficient libraries, some minor details of their interfaces just seem disappointing.

Algorithms cannot take containers directly. std::sort(myvec.begin(), myvec.end()); instead of std::sort(myvec); (I don't really see a valid why the second form was not provided from the beginning)
Most of function member taking string require const char * instead const std::string&. (C++ strings are std::string, at least there should be an overload)

As far as I know these two minor defects are supposed to be corrected in the c++0x standard.

Can you see other of these minor defects ?
Why do you think it is a defect ?
Will it be corrected some day?

(of course the debate here is not for or against generic programming, nor in fact about general design issues. Just missing overloads, missing algorithms version, unhandy interface ...)

@Ugo: You're asking us why we think they're defects. That's a loaded question; not everyone shares your opinion on that. Why do **you** think they're defects? — In silico, Nov 06 '10 at 21:26
@Kirill: CW is dead. (Look it up on meta. I'm too lazy to find it for you.) — sbi, Nov 06 '10 at 21:29
I think it's pretty well understood that the standard library fails on many modern design aspects. Ranges would improve usability, for example, there are way too many member functions, etc. Unfortunately, it's not just something they can say "well let's just drop all the bad stuff."; it would break too much code. — GManNickG, Nov 06 '10 at 21:30
@sbi: Is [this is what you're looking for](http://meta.stackexchange.com/questions/392/should-the-community-wiki-police-be-shut-down/7183#7183)? — In silico, Nov 06 '10 at 21:32
@Kirill: Yes, they can. Plus there's other ways a question can become CW. However, you cannot bully questioners to turn their question CW anymore. And that was the point of that decision. — sbi, Nov 06 '10 at 21:39
`copy_if` and `iota` are missing. If this question is to be a useful resource, perhaps it should *start* with a list of the changes made to the standard containers and algorithms in C++0x, rather than inviting dozens or hundreds of answers listing each one. — Steve Jessop, Nov 06 '10 at 21:46
+1 for being downvoted without reason. Also, to those discussing CW, which I gather refers to a Community Wiki?, isn't it rather backwards to first complain about the OP not making the posting CW (how can posters be expected to know about it, really?) and then discover that he can't (shouldn't one check first, and then complain)? — Cheers and hth. - Alf, Nov 06 '10 at 22:01
@Alf: it's a recent change to the mechanics of CW, which AFAIK was "announced" only via an edit to a question over on meta, which most people don't read at all, let alone that exact question. I'm not sure what the frequency is with which users should read the entirety of meta in order to ensure that their favourite features haven't vanished, but it's inevitable that the way people will learn about such feature changes is trying to use them, or talking about them, and being told they're gone by someone who happens to know :-) — Steve Jessop, Nov 06 '10 at 22:07
@Ugo: I think this question is a good one, it could foster useful debate. And the reactions illustrate nicely what's wrong with SO: an emphasis on avoiding reasoning. No rep for CW question, then CW made less available; people downvoting without giving reason (avoiding reasoning); people voting to close question that requires reasoning; people being afraid that that's "subjective". User interface that doesn't support discussion (e.g. no threading). And so on. It's almost like a psy-op against reasoning. Argh. Sorry for blow-out / rant / letting out steam, but really! — Cheers and hth. - Alf, Nov 06 '10 at 23:57
@Alf: I think SO is leaning towards more practicality. I don't think I agree with the trend, but it seems to me that if Ugo was actually designing a language, then he could ask questions about language design. So some scope for reasoning. However, speculative discussions about how C++ (or any other existing system) could/should be improved (for whoever's value of "improved") just aren't welcome. And I don't think that change is just because C++0x has hit FCD ;-) And I don't really like the way meta works, but it's better than when SO used uservoice. — Steve Jessop, Nov 07 '10 at 00:52
@Alf: "an emphasis on avoiding reasoning" That's pretty arrogant, to me. You should consider SO might have different goals then your own. The removal of question CW makes much more sense for a Q&A site. If your question isn't worth reputation, it isn't worth being asked; the site focuses on real, answerable, closed-ended questions. — GManNickG, Nov 07 '10 at 04:25
@GMan: you're violently agreeing with my assessment. :-) And offering extra arguments in that direction. He he, I doubt that was the intention. Cheers, — Cheers and hth. - Alf, Nov 07 '10 at 09:54
@Steve: Favorite http://meta.stackexchange.com/questions/59445/recent-feature-changes-on-stack-overflow, and you'll be noticed on updates. — sbi, Nov 07 '10 at 19:01

sbi · Answer 1 · 2010-11-07T19:08:26.207

4

Algorithms cannot take containers directly. std::sort(myvec.begin(), myvec.end()); instead of std::sort(myvec);

This one is actually a feature (it allows looping over C arrays), although, as GMan already said in a comment, it could be improved.

Most of function member taking string require const char * instead const std::string&

This one is plain wrong, since most of the STL functions aren't members, most of them aren't functions, but function templates, and (almost?) none of them deal with strings exclusively.
(You're probably talking about file stream, which are part of the standard library, but not of that part of the standard library which stems from the STL. And, of course, there are reasons for why they were made taking const char*, although this, too, could be improved on.)

So it seems, as many who criticize the STL, you don't know enough about it to be in a position to do this. That doesn't mean there is nothing to criticize about it. But, as in other fields, before you go and do this, you should at least know why things are the way they are.

edited Nov 07 '10 at 19:08

answered Nov 06 '10 at 21:32

sbi

219,715
46
258
445

4

@sbi: You've missed the point. It's not about why should there be std::sort(container.begin(), container.end()), but why there should not also be std::sort(container) as well. I don't really see the issue as it's easy to add your own. – Puppy Nov 06 '10 at 21:36
@DeadMG: Many, if not most, of the algorithms of the STL are easy to write. Yet they're in the std lib. So this is not a valid argument. – sbi Nov 06 '10 at 21:41
@sbi Don't take it like this. I have been using the standard library for quite a long time and I don't criticize it. And you are right the second point refers to the IOstream Library. – log0 Nov 06 '10 at 21:44
@sbi: I disagree. I've seen so many posts on SO asking how to write a linked list that I've started to think that it's a good thing that it provides some good basics. Moreover, the std::sort(container) overload is *especially* easy to write, as you can just delegate it to the existing std::sort, whereas if you had to implement the original, you'd have to write an actual sort. – Puppy Nov 06 '10 at 21:44
1

OP should be wanting interfaces like [Boost.Range](http://www.boost.org/doc/libs/1_44_0/libs/range/doc/html/range/reference/algorithms/mutating/sort.html). – kennytm Nov 06 '10 at 21:46
@DeadMG: I have taught C++. Believe me, for a novice there's just as much to get wrong about such overloads as there is about `std::for_each()`. – sbi Nov 06 '10 at 21:50
@sbi You are not answering the question. You are rejecting my example without rational reasons. And finally your are being aggressive. (just to let you know ^^) – log0 Nov 06 '10 at 22:31
@Ugo: There are some question which are best answered by telling why the question is wrong. (No, that's a fact. There _are_ such questions. How would someone answer the question "Why are you stupid?" See, I said there are.) There's reasons why the std lib is what it is today. There's certainly a lot of room to discuss the merits of it being this way, and whether there wouldn't be a better way for it to serve the same goals. But this would require your question to be phrased differently. – sbi Nov 07 '10 at 19:06
Had you asked "Why can't I pass a container to `std::sort`? Am I missing something?", people would have told you why, how you can work around it, and that this is about to change with the new standard. Criticizing a piece of work, while clearly not even being to even properly _name_ the thing, is likely to get the response to first get familiar with it. – sbi Nov 07 '10 at 19:10
Now, I can understand how one would find things strange coming to the STL (and the rest of the std lib) from one of these strict OO languages. In fact, I have felt the same when I needed to learn C# a while ago, so I know the feeling. But that doesn't necessarily mean that the language is "wrong", it just means it is _strange_. Each language comes with its own set of paradigms and philosophies, and one cannot judge the language adequately before one has understood those. Up to then, it's much better to ask "Why are things the way they are?" and learn, than to propose "Things are wrong." – sbi Nov 07 '10 at 19:14
Now, please read my answer again, and read it with the voice of someone who has programmed in C++ for >15 years (and thus has actually seen a part of its evolution happening, which includes the adoption of the STL, which seemed a _very_ strange beast to us back then), one who has taught C++ for a decade (and thus dealt with a lot of novices being puzzled), one who has mostly avoided the common language wars one the net (and thus isn't already angered by unfair critique). Read it in a calm and disimpassioned voice. See? No aggression. Just facts. `:)` – sbi Nov 07 '10 at 19:26
@sbi The fact is you are speaking too much. – log0 Nov 08 '10 at 09:13
@sbi "Many, if not most, of the algorithms of the STL are easy to write. Yet they're in the std lib. So this is not a valid argument." That's just pure arrogance. A lot of algorithms which appear really easy i.e. min/max are a hard to write "correctly". – Ricky65 Oct 19 '11 at 14:41
@Ricky65: Are you really talking about `std::min()` and `std::max()`? Or is this supposed to be a joke? Am I missing something? – sbi Oct 20 '11 at 08:12
@sbi no. Read http://drdobbs.com/184403774 – Ricky65 Oct 29 '11 at 18:35
@Ricky65: I know that article. Those are pure syntactical quibbles stemming from the fact that Andrei wants the versatility of the macro only where it's beneficial, but not where it could hurt. I used to be impressed by this article ten years ago, but nowadays I just shrug and think "So?" If you don't want the dangers of C-style casting, you need to spell it out explicitly and lengthily, if you don't want the dangers of a macro, you need to live with the ensuing restrictions. That doesn't change that the algorithm, that what's between the function's `{` and `}`, is very easy to write. – sbi Oct 29 '11 at 19:04
@Ricky65: Just as `std::foreach()` is rather easy to write, and `std::find()`. Yet they are codified in the std lib, _which was my actual point_. (The reasons they are still in the lib are that 1) you could still fail at writing a very simple algorithm and 2) `std::find()` is much easier to understand that your own algorithm.) – sbi Oct 29 '11 at 19:06

score -6 · Answer 2 · edited May 10 '12 at 16:51

-6

Regarding algorithms such as sort, just define wrappers as you like them.

And if you don't like to define individual wrappers, then define a macro

#define ALL_OF( container ) startOf( container ), endOf( container )

With suitable startOf and endOf function templates this works nicely for both raw arrays and standard library containers.

I.e. your first problem isn't a problem.

Regarding const char* arguments, it's generally not a problem that they're not string const&. However, it would have been nice if the standard library had a standard low-overhead string carrier and that was used. And it's a real problem that wide character strings are not supported for e.g. file stream constructors (Windows code has to use non-standard extensions): this is a case where a correct program, for the execution environment, can not be expressed in standard C++ using only the standard library.

And ditto, of course, for main, which is an issue that spans core language and library.

edited May 10 '12 at 16:51

GEOCHET

21,119
15
74
98

answered Nov 06 '10 at 21:33

Cheers and hth. - Alf

142,714
15
209
331

3

Agree that first problem isn't a problem, but that macro "solution" is not one to be encouraged... – Oliver Charlesworth Nov 06 '10 at 21:35
1

@Oli: would you care to explain why you think so? – Cheers and hth. - Alf Nov 06 '10 at 21:39
@Alf P. Steinbach: For starters, you can't put macros in namespaces, and in your macro whatever is replaced for `container` will be evaluated *twice*. (By the way, I didn't downvote the post.) – In silico Nov 06 '10 at 21:42
@Alf: Well, the usual arguments against macros in the context of C++. It's not type-safe, and it can lead to hard-to-debug compiler errors, for starters (although I concede that you get these anyway with templates...). Incidentally, it wasn't me who downvoted. – Oliver Charlesworth Nov 06 '10 at 21:42
@Oli: well, the one problem I see with it is possibility of name collision, but that's ordinarily fixed by a prefix (e.g. `BOOST_ALL_OF` or `CPPX_ALL_OF`). I don't agree with the problems you list, for this particular macro. That is, I fail to see how they could ever be problems, but the name thing is... Cheers, – Cheers and hth. - Alf Nov 06 '10 at 21:45
@In silico: re namespaces, yes (that's a cost), re evaluated twice, nope, not a practical problem (using a macro like that one knows what it does, and a person who could write `ALL_OF( f( blah, blah ) )` is presumbaly not a C++ programmer in the first place. :-) – Cheers and hth. - Alf Nov 06 '10 at 21:51
3

@Alf: If a function `f` returns `vector&`, then it's a weakness of the macro approach that `sort(ALL_OF(f(blah)))` executes the function twice. Not an insoluble problem, of course, the user can always give a name to the return from the function. A decent range abstraction would be better, albeit several hundred or thousand times more work to implement. If "no one knows what it does", that's merely a weakness of the macro's documentation ;-p – Steve Jessop Nov 06 '10 at 21:59
@Steve: the weakness is a weakness only in that the macro doesn't solve *all* cases. That's the same argument as has been proffered against standard `toupper` functionality, it just argumentative. That this is not an "insoluble problem", well it's not a problem in the first place. :-) A "decent range abstraction" can't address the issue except by adding overloads. And with overloads you don't need it. Although I tend to agree with Andrei that it would be nice. "no one knows what it dows", hello, what planet? It's so simple! Cheers, – Cheers and hth. - Alf Nov 06 '10 at 22:33
@Alf: sorry, regarding "no one knows", I just misread your comment. For the rest, I'm not *particularly* against your macro, I just think it's kind of weak. Personally, I'd rather type `startOf(x), endOf(x)` than get into the business of macros which cross syntactic borders and evaluate multiple times. Maybe when coding my brain is closer to breaking point than my fingers. – Steve Jessop Nov 06 '10 at 22:54
@Steve: yeah, I've not used since defined it long ago. :-) However, the OP might find it reduces the, well, problem. – Cheers and hth. - Alf Nov 06 '10 at 23:27
@Steve @Alf: C++0x has suitably defined `startOf` and `endOf` function templates named `std::begin` and `std::end` that work with arrays, containers, and can be specialized for user-defined types. – James McNellis Nov 07 '10 at 09:18
@James: AFAIK it was Dietmar Kuehl who originally identified the triple `startOf`, `endOf` and `countOf` as important (with different names). Here's one [C++98 implementation](http://alfps.wordpress.com/2010/05/10/how-to-avoid-disastrous-integer-wrap-around/#wrappers). I don't know where Dietmar's original is, this is just one of those "well-known concepts" (well, except, evidently, on SO) floating around. Cheers & hth., – Cheers and hth. - Alf Nov 07 '10 at 10:09

Defects of the STL

2 Answers2