I know that some C++ Standard Library headers are originated from the STL, such as vector. But I'm failing to find an up-do-date list of STL headers which are still not incorporated by the Standard Library. Do they exist?
PS: I would like to have them listed, and also to know if all major implementations include them or where to get them, if possible.
Note, this is a function by function break down, rather than a by header breakdown, because it seems to be more useful.
If we examine SGI's documentation of the STL we find the following:
slist has been renamed std::forward_list.
bit_vector has been replaced by a template specification of std::vector<bool>. The implementation of this may (not must) optimize for space in the way that bit_vector does.
hash_set and friends are now spelled like unordered_set. Functionality seems to be the same. (Thanks T.C.!)
rope is missing. There is no equivalent data structure in the standard library. I could not find a relevant WG21 discussion on the topic.
sequence_buffer is missing, because this was primarily used for back inserting a rope.
random_sample and random_sample_n are missing. The reason is discussed in N3547:
After WG21 consideration at the Sophia-Antipolis meeting, Austern updated the proposal.
Among other changes, he withdrew [random_sample and random_sample_n]: “The LWG was concerned that they might not be well enough understood for standardization. . . . It may be appropriate to propose
those algorithms for TR2” [
Aus08b
]. The wiki minutes of the discussion are equally terse: “Bjarne
feels rationale is insufficient. PJ worries we will get it wrong. Lawrence worries that people will
roll their own and get it wrong. Good candidate for TR2” [
LWG08
]. The subsequent vote regarding
these proposed algorithms achieved a solid LWG consensus (10-1, 2 abs.) in favor of their future
inclusion in a Technical Report (now termed a Technical Specification)
A version of the random_sample_n algorithm has made it to the Library Fundamentals TS and is called std::experimental::sample, the latest iteration of the proposal N3925 was adopted in 2014-02 but remains not yet part of the standard, I suppose we'll see in in C++17. (Thanks T.C.!)
lexicographical_compare_3way is missing. It was seen as "not important enough" to standardize according to N2666.
power is spelled pow and does not have the generalized capabilities that power does.
identity, project1st, project2nd, select1st and select2nd never made it to standardization. I could not find a discussion regarding why.
subtractive_rng is missing as well. Presumptively because <random> would be superseding this problem space.
binder1st, binder2nd, ptr_fun, pointer_to_unary_function, pointer_to_binary_function, mem_fun (and friends), unary_compose, and binary_compose are missing or deprecated. They are more or less superseded by std::bind and friends.
construct and destroy have been moved into the allocator class and do not exist as standalone functions. (Thanks T.C.!)
temporary_buffer is missing. But get_temporary_buffer and return_temporary_buffer are available. I haven't been able to find out exactly why, but what chatter I have ran across seems to imply that it's broken in some way pretty fundamentally, and lots of people have been trying to fix it. Exactly what and how remains a mystery to me.
Related
C++20 introduces <format>(and sooner C++23 introduces <print>). I like those methods, and I always try to use std::format when it's supported rather than use a series of <<.
But I notice that this evolution seems to only appear in the output. Why isn't there something like <scan> for input?
std::format and std::print are already quite a big library addition in itself and I could image that the limited resources for the standard committee to consider the addition of additional features didn't allow them to consider an input equivalent at the same time.
It might also be that the committee wanted to collect more experience with std::format/std::print first before adding an input equivalent or that there are objections to such an addition in principle, in the proposed implementation details or the priority of such an addition.
I couldn't find any definitive statements pointing towards any of these directions and I have no insider knowledge.
Anyway, the committee is still considering a std::scan proposal as follow-up to the std::format proposal, see https://github.com/cplusplus/papers/issues/493 for a log of the procedure the proposal has gone through so far. You can also see there polls on design directions, etc. There seems to not have been much activity since 2019, but I am not sure whether this really means anything or not.
In a reddit thread here from March 2022, Elias Kosunen, one of the authors of the proposal and author of scnlib mentions that there are still some unsure design questions that need to be made sure of before going forward with the proposal, hoping to be able to target C++26, but acknowledging that a farther delay would be preferable to adding a "half-baked" design to the standard.
In short, restrict is supposed to tell the compiler that the pointers cannot point into the same memory location. Which is very useful for, say, function arguments and further compiler optimization. In scientific computing, restrict is very widely used.
Currently, restrict keyword is only a part of C99, but not a part of C++. We know that a lot of C++ compilers support __restrict__ as an extension. This question also talks in detail about what restrict and __restrict__ do.
Now, the discussion in the aforementioned question happened a long time ago and does not talk about C++17, C++20, nor plans for future standards. I found n3988 proposal that discusses restrict-like aliases in C++, complexities with richer syntaxis in C++, and potential remedies.
According to the IBM blog (2014), n3988 was encouraged for future work.
This question talks about the history of restrict and C++ without anything conclusive regarding the actual implementation and mentions the papers I already listed or the one mentioned in the comments (p1296).
I was not able to find anything beyond that on the plans of supporting restrict in the upcoming C++ (as far as I know, it's not a part of C++17). It seems like a very useful functionality, so I wonder
if I missed something in terms of proposals/discussion?
is there other information on the restrict usage in C++?
are there alternative ways to make the compiler optimizations (allowed by __restrict__) possible by using only "standard" functionality?
Nothing like C’s restrict is in even C++20. The paper already mentioned was well-received at a preliminary presentation in November 2018, perhaps because it avoids the critical difficulty with a qualifier—that no one, even in C, understands how it interacts with the rest of the type system. Part of this is because adding restrict doesn’t change the meaning of any one pointer, but affects its relationship with some set of other pointers (whose membership is not well-specified) based on what arithmetic is performed with them later. Another part is because C++ allows so many operations with types: what would std::vector<T *restrict> mean, and what would be the type of indexing a std::vector<T> &restrict?
Just what practical optimization opportunity will be offered by such a contract-based approach is not yet clear; there are still many unanswered questions about contracts and optimization in general.
Stephan T Lavavej's initial proposal for make_unique was N3588
It included the following functions:
make_unique<T>(args...)
make_unique_default_init<T>()
make_unique<T[]>(n)
make_unique_default_init<T[]>(n)
make_unique_value_init<T[]>(n, args...)
make_unique_auto_size<T[]>(args...)
However, the final propsal, N3656, only includes make_unique (both forms). I am unable to find any discussion on the other forms of the function. I read the minutes of the Bristol meeting, but they don't even reference the original proposal.
Why were these extra functions not included in the final draft?
I read the minutes of the Bristol meeting, but they don't even reference the original proposal.
The minutes are accurate. N3588 (original recipe, without Standardese) was not discussed in the full committee, only N3656 (extra crispy, with Standardese) was discussed there. If you haven't been to a meeting, this might seem strange, but what happens is that the Working Groups (Core, Evolution, Library, Library Evolution) and the Study Groups (Filesystem, etc.) work during the week in parallel, eventually conducting straw polls (where anyone can vote) to determine what should be brought to the full committee. On the second to last day, the full committee (100+ people) meets, where the formal motions are briefly discussed, and straw polls (where only voting members may vote) are taken. If anyone is concerned that features aren't baked enough, or that there will be integration problems with other features, etc. then this is discussed here - but the full committee doesn't look at the microscopic details of a proposal. Basically if something is controversial enough to warrant that, it won't survive a vote anyways, so it'll be withdrawn from consideration for that meeting. Then on the last day, the full committee meets again, and the real votes are taken (voting members only). In general there should be no surprises during the real votes, since the day before was a test run.
The LWG minutes aren't publicly available, but I can tell you what happened. N3588 deliberately contained no Standardese - what I did there was explore the design space, figuring out what new-expressions we should imitate, and arguing for or against various things. I was planning to receive feedback from the LWG, then draft Standardese for the next meeting (Chicago), since writing up anything complicated takes me a lot of time to get exactly right (it takes more time than actually implementing it, since Standardese carefully dances around implementation details like SFINAE). While presenting the proposal, I explained how I was not a great fan of default-init (which I deride as garbage-init), but had outlined how it could be done anyways. I also explained that I had learned more about the array-init cases since writing the proposal (while receiving feedback from MS devs). Interestingly, the Core Language provides sequencing guarantees for braced-init-lists, so new X[3]{ f(), g(), h() } calls those functions left-to-right. Function calls don't get those guarantees, which (in my opinion) mortally wounds attempts to wrap array-init like in my original proposal. There are clever ways to achieve the sequencing guarantees with slightly different user syntax and even more implementation complexity, which I explained to the LWG. At this point, I really wanted to drop array-init, and I was lukewarm on default-init (which is easy to specify and implement, but I view it as essentially unnecessary). The LWG's reaction was that they wanted the simplest forms only - no array-init and not even default-init. I was super happy to hear this, and I was able to write up the necessary Standardese at the meeting itself (at like 4 AM). So that's where N3656 came from. The LWG took another look at it, and with one minor tweak (changing make_unique<T[N]>'s return type from void to unspecified, which I did before it was "set in stone") was ready to bring it to the full committee.
Then, as you saw in the minutes, the concern was that we might be moving too fast with make_unique. N3588 was in the pre-meeting mailing on-time, but this was the first time it had appeared - almost all proposals take more than a single meeting to move from first appearance to formal motion (my first proposal, the transparent operator functors, was an even more unusual exception as it appeared and was voted in without changes in Portland). This was a totally valid concern, by the way. In the end, the vote passed - members don't have to explain their votes, but my sense was that it was a combination of the proposal being very small, nobody having objections to the actual content, and an implementation being available.
Now I'm going to have to think about all this stuff again for make_shared!
I was looking at a job posting recently and one of the requirements was that a person be a 9/10 in their knowledge of STL.
When I judge my skills, to me a 10 is someone that writes advanced books on the subject, such as Jon Skeet (C#), John Resig (JavaScript) or Martin Odersky (Scala).
So, a 9/10 is basically a 10, so I am not certain what would be expected at that level.
An example of some questions would be found at: http://discuss.joelonsoftware.com/default.asp?joel.3.414500.47
Obviously some coding will be needed, but should everything be expected to be memorized, as there is quite a bit in STL.
In some cases Boost libraries extend STL, so should it be expected that I would be using Boost also, as I may sometimes confuse which function came from which of the two libraries.
I am trying to get an idea if I can answer questions that would be expected of a STL expert, though it is odd that being a C++ expert wasn't a requirement.
UPDATE
After reflecting on the answers to my question it appears that what they may be looking for is someone that can see the limits of STL and extend the library, which is something I haven't done. I am used to thinking within the limits of what STL and Boost give me and staying within the lines. I may need to start looking at whether that has been too limiting and see if I can go outside the box. I hope they don't mean a 9 as Google does. :)
Funny -- I don't consider myself a 9/10 in STL (I used to be, but I'm a bit rusty now), and I do fully agree with #joshperry's important terminological distinguo (I've often been on record as berating the abuse of STL to mean "the parts of the C++ standard library that were originally inspired by SGI's STL"!-), yet I consider his example code less than "optimally STL-ish". I mean, for the given task "Put all the integers in a vector to standard out.", why would anyone ever code, as #joshperry suggests,
for(std::vector<int>::iterator it = intVect.begin(); it != intVect.end(); ++i)
std::cout << *it;
rather than the obvious:
std::copy(intVect.begin(), intVect.end(), std::ostream_iterator<int>(std::cout));
or the like?! To me, that would kind of suggest they don't know about std::ostream_iterator -- especially if they're supposed to be showing off their STL knowledge, why wouldn't they flaunt it?-)
At my current employer, to help candidates self-rate about competence in a technology, we provide a helpful guide -- "10: I invented that technology; 9: I wrote THE book about it" and so on down. So, for example, I'd be a 9/10 in Python -- only my colleague and friend Guido can fairly claim a 10/10 there. STL is an interesting case: while Stepanov drove the design, my colleague Matt Austern did the first implementation and wrote "the" book about it, too (this one) -- so I think he'd get to claim, if not a 10, a 9.5. By that standard, I could be somewhere between 7 and 8 if I could take an hour to refresh (custom allocators and traits are always tricky, or at least that's how I recall them!-).
So, if you're probing somebody who claims a 9, grill them over the really hard parts such as custom allocators and traits -- presumably they wouldn't miss a beat on all the containers, algorithms, and special iterators, so don't waste much interview time on those (which would be key if you were probing for a 7 or 7.5). Maybe ask them to give a real-life example where they used custom traits and/or allocators, and code all the details of the implementation as well as a few sample uses.
BTW, if you're the one needing to cram on C++'s standard library at an advanced level, I'm told by knowledgeable and non-rusty friends that Josuttis' book nowadays is even more useful than my friend Matt's (unfortunately, I've never read Josuttis in depth, so I can't confirm or deny that - I do see the book has five stars on Amazon, which is impressive;-).
It is just a dumb requirement for a job. When hiring you want a good great programmer first, specific knowledge second.
It would be reasonable, at this day and age, to expect knowledge/familiarity/etc with the STL. But unless the job is to reimplement the STL, you don't need 9/10. Even if that is the job, you still just need a great programmer that has lots of experience with templates (making not just using).
For example, for all the answers to "output the integers of a vector", probably the exact same code is generated. Only the version that has been templated to handle any container of any items shows a hint of 'great' vs good (just a hint). ie the ability to abstract.
Anyhow, just go for it. Be ready to use the STL to help solve other problems. Nothing more.
(In fact, for most of the interviews I've been in, the requirement was to NOT use the STL. ie - write a function that reverses a string. My first answer is that there is probably something in the std lib that would do that. Then they say, right, of course, but what if you had to write it yourself...)
I should preface this by noting that I think the same criteria should be applied not only to STL (regardless of which definition you prefer for that), but to many other types of things as well.
From my perspective, simply knowing the existing STL components and being able to apply them well probably should not qualify as a 9/10. Rather, I'd consider that level about 7/10. 8/10 is when the person is able to extend the STL by providing new components that follow its philosophy and fit with existing components naturally and easily.
By 9/10, I'd expect to see somebody who can not only provide new components, but is able to improve some of the existing ones, such as Boost::bind. For 10/10, I'd expect to see this go beyond the rather ad hoc, localized improvements of a 9/10, and moving toward looking at a more architectural level, such as using ranges instead of individual iterators. For a concrete example, consider the difference between Boost's ranges and Andrei Alexandrescu's ideas for ranges. Boost's ranges are handy, useful and convenient, but they change what you type, not how you think. Andre's version of ranges is much more all-encompassing -- an architectural solution that changes how you design and think about code, not just how you type it.
Well, you could walk into the interview and say "I noticed that your posting asked for someone knowledgeable in STL but that term is sometimes used to mean: (1) C++ standard library; (2) the library Stepanov designed at HP; (3) the parts of [1] based on [2]; (4) specific vendor implementations of either [1], [2], or [3]; (5) the underlying principles of [2]. As such, the term is highly ambiguous, and must be used with extreme caution. If you meant [1] and insist on abbreviating, "stdlib" is a far better choice."*
Honestly though since it is a library it is somewhat finite and probably not composeable to nauseating infinitum like a language proper. So I would say any question that had them use some of the stdlib algorithms would be effective to see if they knew them well.
With iterators being an integral part of the stdlib I would also maybe ask them to "Put all the integers in a vector to standard out." I would expect something like:
// thanks to onebyone
std::copy(vec.begin(), vec.end(), std::ostream_iterator<int>(std::cout, " ");
If they write something like the following they probably aren't very familiar with iterators:
for(int i = 0; i < vec.size(); ++i)
std::cout << vec[i];
Also one interesting thing to look for is if they do using namespace std at the top of their code file. Ask them why, and if they don't say something along the lines of "I use that for short demo code only" or if they put it in a header file, thank them for coming in and send them out the door.
Another aspect of the stdlib is it's heavy use of templates, the person should have a good understanding of basic template programing for type substitution. Maybe ask them to "Write a function that will write all of items of any stdlib container to standard out". I would expect to see something like:
template<typename InputIter>
void Output(InputIter it, InputIter end) {
while(it != end)
std::cout << *it++;
}
These are probably not 9/10 questions but interesting ones I think a 2-3/10 should know.
One 9/10 difficulty I would say is to write a derived iostream properly without using the boost stream base classes. But there is probably quite a difference between using the stdlib and extending it...
*(thanks to nolyc on freenode ##C++ for the quote)
9/10 is quite subjective. I have been asked good questions about STL. These are examples:
When should you use a deque vs a vector (knowledge of how they are internally implemented is helpful)
Recognize STL code that uses invalid references, or can end up using invalid references.
Implement simple operations on different containers, and know where and when to use std::algorithm vs member functions of a container.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
As you may have heard, the last meeting of the C++ standards committee voted to remove concepts from the next C++ standard. Of course, this will affect other features and would seem to throw the standard wide open again. If that is the case, which other features do you think should be stripped away (or added), and why?
Links:
Removal of Concepts -- Danny Kalev (on the decision to remove concepts)
Simplifying the use of Concepts -- Bjarne Stroustrup (on the problems with concepts as they look now)
The Long Pole Gets Longer -- Martin Tasker (on the impact to the schedule for C++0x if concepts have to be fixed)
The C++0x "Remove Concepts" Decision - Stroustrup on the issue on Dr. Dobbs
Trip Report: Exit Concepts, Final ISO C++ Draft in ~18 Months - Herb Sutter
Concepts Get Voted Off The C++0x Island - Jeremy Siek defending the current Concepts spec
What Happened in Frankfurt? - Doug Gregor on C++Next (on the history and removal of Concepts).
Of course, this will affect other
features and would seem to throw the
standard wide open again.
Hardly. They still want to wrap up the standard soon, which is one of the main reasons for removing concepts. Making it "wide open" to unrelated changes would just throw away everything they gained by ditching concepts.
Anyway.... Of the remaining C++0x additions, I can't think of anything else I'd want to remove. I agree with their decision regarding concepts though. Stroustrup's paper really outlined some serious problems, The current specification for concepts would admittedly simplify template error messages, but it would do so by dramatically reducing the usefulness of generic programming -- a price I'm not willing to pay.
When I first read that paper, it scared me, because I assumed it was too late in the process for making serious changes to the spec. Turns out it wasn't, and the committee was willing to take dramatic action.
But apart from this, I think C++0x is in good shape. The remaining new features all look worthwhile.
Of course, there are plenty of existing features I'd love to remove. Primarily the vector<bool> specialization. There are other popular examples of features that didn't work out (the export keyword, exception specifications), but the vector specialization is the only one of them that can't be ignored. As long as we don't try to export templates, it doesn't matter that the keyword exists (and isn't implemented by compilers), and we can just refrain from using exception specs, but every time we need a vector of bools, we're bitten by the stupid premature optimization that slipped into the current standard.
Unfortunately, it seems like they've given up on removing it. (Last I checked, it wasn't even deprecated).
Of course, plenty of old C cruft could be ditched too, but recently, I've discovered that the one change I'd really love to see is...... ditching the Iostreams library. Toss it out, and build a new STL-style I/O library based on generic programming.
The current OOP-styled Iostreams library is ugly, slow, overcomplicated and inflexible. There's too much voodoo involved in defining new streams, too few standard stream types involved, too little flexibility (the problem that made me realize how limited the library is, was that I needed to extract a float from a string. Easy to do with stringstream, but if you need to do it often, you don't want to have to copy the input string every time (as the stringstream does) -- where's the stream that works on an existing iterator range? Or a raw array, even?)
Throw IOstreams out, develop a modern replacement, and C++ will be vastly improved.
And perhaps do something about the string class as well. It works sort of ok'ish as it is now, but really, what's with the huge number of member functions? Most of them would work better, and be more general, as free functions. Too much of the standard library relies specifically on the string class, when it could in principle work with any container, or even an iterator (std::getline, I'm looking at you)
Personally, I want C++ to finally break away from C. No more pre-processor, no more header files. I basically want D, but without all the stuff that D tacks on, using the STL.
None, I think the rest of the draft was great - a large number of very small pieces that can be correctly implemented independently, allowing vendors to evolve toward complete support and allowing users to take a "shopping list" approach.
Quite a different situation with contracts, as they were like a whole new parallel type system and would have been very likely to have led to different compilers ending up with their own backward compatibility problems, very similar to CSS in web browsers.
There are two things I think should be added to C++0x, I've thought of both these myself and then found that others have suggested them before but it doesn't seem like they're going to happen.
1. Defaulting Move Constructors and Move Assignment Operators
Writing a move constructor is a manual and error prone activity, if a member is added it must be added to the move constructor and assignment operators and std::move must be used religiously. That's why I think these functions should be defaultable.
movable(movable&&) = default;
movable& operator=(movable&&) = default;
Edit (2009-10-01): Looks like this is going to happen after all.
2. Override Type Deduction for Expression Templates
Expression templates often define types that should not be used directly, a case in point is the return value of std::vector<bool> operator[](size_type n), if auto or decltype are used on this kind of object unexpected behaviour may ensue.
Therefore a type should be able to say what type it should be deduced to be (or prevent deduction using = delete syntax).
Example for vector addition.
// lazy evaluation of vector addition
template<typename T, class V1, class V2>
class vector_add {
V1& lhs_;
V2& rhs_;
public:
T operator[](size_t n) const
{ return lhs_[n] + rhs_[n]; }
// If used by auto or decltype perform eager creation of vector
std::vector<T> operator auto() const
{
if (lhs_.size() != rhs_.size())
throw std::exception("Vectors aren't same size");
std::vector<T> vec;
vec.reserve(lhs_.size());
for (int i = 0; i < lhs_.size(); ++i)
vec.push_back(lhs_[i] + rhs_[i]);
return vec;
}
To me the problem is not what other features should be stripped away, but how complex will other features be after concepts have been removed. That and how much longer will it take for the rest of the features to be rephrased without concepts.
A lot of features assumed that concepts would be accepted into the language and the wording is expressed in terms of concepts. (I wonder if any proposed feature depends on concepts).
I also wonder how other libraries will evolve (think boost::type_traits) to take the niche left by concepts. Part of what concepts provided can be implemented (even if in a more cumbersome way) in terms of traits applied to the type arguments.
To me, the most important thing that concepts added to the language was an expressive formulation of compilation errors, which is nowadays one of the places where C++ is most criticized.
R.I.P. concepts.
Do whatever you want with concepts, but for god's sake keep threads and atomics, we absolutely need them. Perhaps add thread groups and support for cooperative threads a.k.a. fibers. IMO these are far more important than concepts, because everyone uses/will soon be using threads.
I'd like to remove =delete.
There's already a common and accepted idiom for acheiving the same effect (declare the function in question as private). I think this feature will just generate lots of 'I used =delete to remove a base class function from my derived class, but it can still be called using a base class pointer' questions.
Not to mention confusing people between the (now) two meanings of the delete keyword.
Strip away the pages of error messages on template code!
IIRC concepts should solve a big C++ coder problem: Human readable error messages for the STL. Its bad news that this issue isn't addressed.
The un-named function / lambda function stuff makes me nervous. Function objects are perfectly good and are explicit, thus easier to read and find.
On the other hand I kinda liked concepts, though I certainly would not have used them every day.