Defects of the STL [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

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 ther开发者_开发知识库e 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 ...)

---

• 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.

---

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.