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!
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.
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.
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.
We've been waiting forever to see if it's going to become a full-fledged language, and yet there doesn't seem to be a release of the formal definition. Just committees and discussions and revising.
Does anyone know of a planned deadline for C++0x, or are we going to have to start calling it C++1x?
Well the committee is currently very busy working on the next revision - every meeting is prefaced by many papers, that are a good indicator of the effort that is going into the new standard: http://www.open-std.org/jtc1/sc22/wg21/
What is a little concerning (but reassuring in the sense that they will not rush publishing a standard just to assuage the public, yet do sense the urgency involved) is that Stroustrup just put out a paper saying that we need to take a second look at concepts and make sure that they are as simple as can be - and has proposed a reasonable solution.
[Edit] For those who are interested, this paper is available at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdf.
C++0x will be a huge improvement upon C++ in many regards, and while I do not speak for the committee - my hope is that it will happen by late 2010.
[Edit] As underscored by one of the commenters, it is worth appreciating that there is significant concern amongst a few committee members that either the quality of the standard or the schedule (late 2010) will have to suffer if concepts are included: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2893.pdf. But whether these concerns will be substantiated is worth being patient about - we will have more information about this once the committee concludes its meeting in Frankfurt this july (the post-meeting mailing can be expected in late-july, early august).
Personally, i sense that it would not be a huge loss to get the standard out without concepts (maintain the late 2010 schedule), and then add them as a TR - versus rushing them through even when there is palpable uneasiness amongst the more seasoned committee members (about concepts) - but I will defer to the committee here - while they have never claimed or been described as perfect, the majority of them are far more qualified to make these decisions than I am and deserve some of our confidence if history is any indicator - I would err on the side of trusting their instincts (over mine) assuming there was some reasonable consensus amongst them.
For some perspective, and so that one does not despair about these obstacles too much, compare this to what happened within the ecmascript community - Brendan Eich, the creator, had some very different design goals for the next revision of ecmascript (es5) from some of the other similarly talented wizards in the ecmascript community - they had multiple meetings and after much discussion (some of it heated ;) formulated a very very reasonable compromise followed by a frenzy of activity that has resulted in ecmascript 5 (all in the span of 1-2 years, including the conflict) which will be an excellent and pragmatic, yet much more conservative than Eich had initially proposed, revision of javascript. I have similar hopes for C++ (acknowledging that C++ is a much much much larger language - but then much more effort has been put in ;)
FTR: C++11 has been approved by ISO on 12 August 2011.
Around 200A or 200B. If you remember the Y2K problem, these are years 199K and 199L ... oops wait, K and L aren't hex digits. Boom!
Slashdot posted a story of an interview with Bjarne Stroustrup, and in it, he drops the bombsheel that the release has been delayed until 2010 or later:
No C++0x, Long Live C++1x (Page 3)!
From Dr. Dobbs:
Concepts were to have been the central
new feature in C++0x
Even after cutting "concepts," the
next C++ standard may be delayed.
Sadly, there will be no C++0x (unless
you count the minor corrections in
C++03). We must wait for C++1x, and
hope that 'x' will be a low digit.
There is hope because C++1x is now
feature complete (excepting the
possibility of some national standards
bodies effectively insisting on some
feature present in the formal proposal
for the standard). "All" that is left
is the massive work of resolving
outstanding technical issues and
comments.
I was on the bleeding edge of MT- and MP-safe C++ programming circa 1997 - 2000. We had to do many things ourselves. It's a bit shocking that the standard has not addressed concurrency in the 9 years since.
So what's the big deal?
No.
I'm not sure what makes you'd think it is. The Dr.Dobbs article doesn't imply that it's the case.
It is a big update, which means a lot of work polishing up the the language spec and fixing errors. That's neither new nor surprising.
And the ISO standardization process takes time. That's not new either. The article you posted says just that -- there's work to be done, but the sky is not falling, it's pretty basic and low-risk work they'll be doing from now on.
There are a couple of reasons why it's taken so long:
The obvious is that they're making a lot of changes, and a few features turned out bigger than expected, and had to be cut. That much goes without saying and is responsible for the delays.
The less obvious, but just as important factor is that they wanted a long time to pass since C++98. They wanted to give the language time to stabilize and mature, get lots of use experience with current language features, and give compilers time to catch up. Until a few years ago, C++ just wasn't ready to be updated. Big commercial compilers were still a mess, and too many people still weren't comfortable with modern C++ design.
That's why things like multithreading has not been addressed until now. It didn't make it in C++98, and they didn't want to make changes too soon after that.
I don't know which year they originally hoped to target, but I doubt it was earlier than 2007 or so. So yes, the new standard has been delayed a bit, but not because the language is "collapsing".
Stroustrup was one of the voters to remove Concepts finally. I don't see C++ collapsing, instead I see that the C++ committee is doing its job. Half-baked features are not the solution for a robust language like C++. A look at what is going to be in C++0x tells you the opposite of what you are saying. Finally, I don't mind to wait to get something good forever, instead of something good for a while :)
No, they are just aware of the responsibility they have. There are a lot of people affected by the decisions of the standard comittee.
On the one hand I'm grateful that they are not repeating the template exports fiasco.
On the other hand the same kind of "responsibility" could have killed off templates entirely before they happened.
I think C++0x is demonstrating that C++ is too mature a language to be experimenting with features still. New cutting-edge features are already present in other languages where they are a better match for the underlying philosophy.