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.
Related
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.
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.
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!
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.