Running a lambda on scope exit seems like such a basic thing, I would expect it to be standardized. Things like unique_ptr are better, when they apply, but I find there is an endless supply of "one-off" destructors are needed, especially when leveraging C-style libraries. Does anyone know if this is coming?
n4189 is a proposal to add make_scope_exit wrappers, and other similar resource handlers, to the language. It is based off of the relatively famous scope_guard talk.
The most recent "current paper status" from LWG is in 2013, prior to the above date.
The contents of C++1z (hopefully C++17) are yet to be determined.
C++1z status for clang does not mention it. C++1z TS for clang does not mention it.
The paper itself contains an example implementation. I do not know what licensing terms it is under.
It would appear that the current version of the scope exit paper, P0052, will be going into the Library Fundamentals v3, for likely adoption in the Post-C++17 standard.
In short, not gonna happen for C++17. Sorry.
Related
Let me give a concrete example to make it more clear what I exactly mean.
I have two drafts of C++ standard: N4296 that is quite old now and more recent revision N4750. There are some subsections that I am interested in, e.g. [unord.hash]. Version N4296 requires from std::hash to provide two nested types argument_type and result_type, but this requirement no longer present in N4750.
How can I find the revision, where this requirement was removed and the motivation for it?
Another source you can use is cppreference. They do a very good job in showing what is different in the different version of the standard. For instance, the std::hash page lists that argument_type and result_type are deprecated in C++17 and removed in C++20. With that information you at least know that the remove happened in a version of the standard between C++17 and C++20, which is lot less versions to look through.
Additionally, in at least some sections, if there was a defect report there will also be a link to that defect report on the page.
You'll still have to do some hunting, but hopefully this will narrow it down for you.
This can actually be kind of hard.
Individual revisions
First, there's the list of closed core language issues (and the equivalent page for library issues), which gives you a paper reference and some date information.
There's the working group's mailings.
There's the standard's source whose history can be examined using Git tools and their friends. The commit log in theory should be useful — though I recommend noting down the name (e.g. a word like "N3690") of the Final Draft for each standard so that you can recognise it in the tag list.
This is your best bet if you're literally looking for the specific revision where a change was introduced.
Between standards
When trying to determine in which standard the change was introduced, personally I tend to just open up individual standard documents and do my own visual bisection. This works well if you know where the feature's wording is located in the standard, and if the wording is mostly compartmentalised in one place, though it can still be time consuming.
For motivations you'll be looking for the original proposal paper. If you manage to find the draft revision where the change was made, hopefully someone will have cross-referenced the name/ID of the proposal.
I also find that Google gives some good results when searching for this if you already have a vague idea of its contents: e.g. "C++ if declaration definition while for consistent proposal".
And, if you don't mind non-authoritative sources (which should nonetheless be reliable), there are usually Stack Overflow answers that track changes between C++ standards, with links to the relevant papers. For example, this answer to "What are the new features in C++17?", which references the changes to std::hash that you mention.
According to Michael Wong the Concurrency TS is not going in, despite complete, apparently
Although there is implementation experience, it was just approved and is too fresh to be voted to be added to C++17.
My favourite proposal was originally in N3327 but I first read of it in N3857/N3784 and had expected it for C++14. futures has had and implementation of .then() in Boost since 2013 and Microsoft has implemented a form of them in PPL so any issues will have been hit upon, discussed and corrected. An asynchronous version of .get() is a necessity and seemed to been decided upon since early-2014 when N3865 ('More Improvements to std::future') talked as if .then() was a given. Which means even with 5 years since N3327 first raised a .then() due to 'streamlining' any well thought out, discussed and implemented proposal is blocked by discussions going on that is tangential to it.
It is now going to be 2020 before it will ship.
Is the Concurrency TS a whole or nothing proposal? And if so why?
It is now going to be 2020 before it will ship.
It's shipping now. Just not in the C++ standard itself.
You shouldn't think of a TS as some kind of fictional document. It's a real thing, and many vendors implement TS's. Microsoft and libc++ have support for the FileSystem TS, for example.
With C++17 feature complete, compiler and standard library vendors have their hands full implementing those features. Not to mention the Concepts TS and so forth. So it's not surprising that the Concurrency TS isn't their highest priority.
As for why parts of Concurrency weren't added to C++17, the minutes of the Jacksonville meeting show that SG1 (the study group for concurrency issues) specifically proposed adding Parallelism TS to the standard, but did not do so for Concurrency TS. So they apparently felt that Concurrency TS was not ready to be added to the standard library, even partially.
Running a lambda on scope exit seems like such a basic thing, I would expect it to be standardized. Things like unique_ptr are better, when they apply, but I find there is an endless supply of "one-off" destructors are needed, especially when leveraging C-style libraries. Does anyone know if this is coming?
n4189 is a proposal to add make_scope_exit wrappers, and other similar resource handlers, to the language. It is based off of the relatively famous scope_guard talk.
The most recent "current paper status" from LWG is in 2013, prior to the above date.
The contents of C++1z (hopefully C++17) are yet to be determined.
C++1z status for clang does not mention it. C++1z TS for clang does not mention it.
The paper itself contains an example implementation. I do not know what licensing terms it is under.
It would appear that the current version of the scope exit paper, P0052, will be going into the Library Fundamentals v3, for likely adoption in the Post-C++17 standard.
In short, not gonna happen for C++17. Sorry.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
How are you using C++0x today?
I'm working with a team on a fairly new system. We're talking about migrating to MSVC 2010 and we've already migrated to GCC 4.5. These are the only compilers we're using and we have no plans to port our code to different compilers any time soon.
I suggested that after we do it, we start taking advantage of some of the C++0x features already provided like auto. My co-worker suggested against this, proposing to wait "until C++0x actually becomes standard." I have to disagree, but I can see the appeal in the way he worded it. Nevertheless, I can't help but think that this counter-argument comes more out of fear and trepidation of learning C++0x than a genuine concern for standardization.
Given the new state of the system, I want for us to take advantage of the new technology available. Just auto, for instance, would make our daily lives easier (just writing iterator-based for loops until range-based loops come along, e.g.).
Am I wrong to think this? It is not as though I'm proposing we radically change our budding codebase, but just start making use of C++0x features where convenient. We know what compilers we're using and have no immediate plans to port (if we ever port the code base, by then surely compilers will be available with C++0x features as well for the target platform). Otherwise it seems to me like avoiding the use of iostreams in 1997 just because the ISO C++ standard was not published yet in spite of the fact that all compilers already provided them in a portable fashion.
If you all agree, could you provide me arguments I could use to strengthen my position? If not, could I get a bit more details on this "until the C++0x is standard" idea? BTW, anyone know when that's going to be?
I'd make the decision on a per-feature basis.
Remember that the standard is really close to completion. All that is left is voting, bugfixing and more voting.
So a simple feature like auto is not going to go away, or have its semantics changed. So why not use it.
Lambdas are complex enough that they might have their wording changed and the semantics in a few corner cases fixed up a bit, but on the whole, they're going to behave the way they do today (although VS2010 has a few bugs about the scope of captured variables, MS has stated that they are bugs, and as such may be fixed outside of a major product release).
If you want to play it safe, stay away from lambdas. Otherwise, use them where they're convenient, but avoid the super tricky cases, or just be ready to inspect your lambda usage when the standard is finalized.
Most features can be categorized like this, they're either so simple and stable that their implementation in GCC/MSVC are exactly how they're going to work in the final standard, or they're tricky enough that they might get a few bugfixes applied, and so they can be used today, but you run the risk of running into a few rough edges in certain border cases.
It does sound silly to avoid C++0x feature solely because they're not formalized yet. Avoid the features that you don't trust to be complete, bug-free and stable, but use the rest.
Theoretical but not practical disadvantages of using C++0x:
Makes it harder to port to different compilers.
Not adhering to any published standard.
Practical advantages of using C++0x:
Makes your daily lives easier, hence more productive.
It's a debate between what's theoretically right, and what's practical. If your team has any intent of actually doing something with this code, the practical should outweigh the theoretical tenfold.
One thing you don't need to (mostly) worry about now is features being added or taken away because the working draft reached "Final Committee Draft" (FCD) back in march. Feature-wise should be frozen, standards committee will not accept any-more proposals for C++0x.
Downside is it's still a draft and not finalized yet, the standards committee are in the phase of making corrections and adjustments before finalizing and publish the ISO standard (expected release to be march 2011). That could mean minor syntactic or semantic/behaviour changes which could make your code not compilable or not work correctly once you compile with a compiler that is more standard compliant than the one you're using at the time you wrote the code.
You'll probably have to wait sometime for compilers like VC++10 to get update with any corrections/adjustments made.
We had the exact same problem so we compromised. We took the C++ 0x TR1 release and then only took the portions that we knew we wanted to use. Sounds like a lot of work, but so far it's worked out well. We're using the regex libraries, tuples, and a couple of others. Once the standard is ratified, then we'll migrate to the full C++ 0x. This obviously isn't the best solution but it was one that has worked well for us.
If you intend to make your system open source within a not-too-far future, then that's an argument for not using too many bleeding-edge features. A production system running Debian or Red Hat won't necessarily have a bleeding-edge compiler installed.
You said
if we ever port the code base, by then surely compilers will be available with C++0x features as well for the target platform
but that a compiler exists for a platform doesn't always mean that it's installed/used/wanted, especially on production systems.
If, on the other hand, you intend to do all the compiling yourself, this is not an issue.
Are there any features of C++0x that are known to be there for sure?
Like, maybe, threads in the standard library?
Actually none. At any point up to the publication of the standard, ISO can change it, since it's subject to the vagaries of the voting process.
In reality, any major feature that's currently in the draft will remain (although tweaking is possible). They've already stated that they'll miss their 2009 delivery and ISO is as political a beast as any country, so they'll not want to miss another one.
So while you won't see tuples or threads or other major library changes being removed, there could be minor variations, nothing that will have a major impact on delivery of the standard (and hopefully, timely implementation by the vendors).
New string literals
auto type deduction
Template typedefs
R-value references
to name a few and most of TR1.
Take a look at the C++0x Wikipedia article -- but it is best to check with your compiler vendor to know what you can use.