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.
Someone brought this article to my attention that claims (I'm paraphrasing) the STL term is misused to refer to the entire C++ Standard Library instead of the parts that were taken from SGI STL.
(...) it refers to the "STL", despite the fact that very few people still use the STL (which was designed at SGI).
Parts of the C++ Standard Library were based on parts of the STL, and it is these parts that many people (including several authors and the notoriously error-ridden cplusplus.com) still refer to as "the STL". However, this is inaccurate; indeed, the C++ standard never mentions "STL", and there are content differences between the two.
(...) "STL" is rarely used to refer to the bits of the stdlib that happen to be based on the SGI STL. People think it's the entire standard library. It gets put on CVs. And it is misleading.
I hardly know anything about C++'s history so I can't judge the article's correctness. Should I refrain from using the term STL? Or is this an isolated opinion?
The "STL" was written by Alexander Stepanov in the days long before C++ was standardised. C++ existed through the 80s, but what we now call "C++" is the language standardised in ISO/IEC 14882:2014 (and earlier versions, such as ISO/IEC 14882:2011).
The STL was already widely used as a library for C++, giving programmers access to containers, iterators and algorithms. When the standardisation happened, the language committee designed parts of the C++ Standard Library (which is part of the language standard) to very closely match the STL.
Over the years, many people — including prominent book authors, and various websites — have continued to refer to the C++ Standard Library as "the STL", despite the fact that the two entities are separate and that there are some differences. These differences are even more pronounced in the upcoming new C++ standard, which includes various features and significantly alters some classes.
The original STL is now often called "an implementation of the C++ Standard Template Library" (rather backwards to actual history!), in the same way that your Microsoft Visual Studio or GCC ships an implementation of the C++ Standard Library. But the "Standard Template Library" and the "Standard Library" are not the same thing.
The battle is about whether the current Standard Library should be called "the STL" in whole or in part, and/or whether it matters what it's called.
For "STL"
There is a school of thought that says that everybody knows now that "STL" means the standard library, just as everybody now knows that "C++" is the ISO-standardised language.
It also includes those who believe that it doesn't really matter as long as all parties understand what is being talked about.
It's a term made even more prevalent by the nature of the beast, much of which makes heavy use of the C++ feature known as "templates".
For "C++ Standard Library" (or stdlib)
However, there is another school of thought — to which I subscribe — that says that this is confusing. People learning C++ for the first time do not know this distinction, and may not notice small language differences.
The author of that article has numerous times encountered people who believe that the entire C++ Standard Library is the STL, including features that were never part of the STL itself. Most vocal proponents of "the STL", in contrast, know exactly what they mean by it and refuse to believe that not everybody "gets it". Clearly, the term's usage is not uniform.
In addition, there are some STL-like libraries that are in fact implementations of the original STL, not the C++ Standard Library. Until recently, STLPort was one of them (and even there, the confusion abounds!).
Further, the C++ Standard does not contain the text "STL" anywhere, and some people habitually employ phrases like "the STL is included in the C++ Standard Library", which is plain incorrect.
It's my belief that continuing to propagate the usage of the term in this way will just lead to the misunderstanding going on forever. Alas, it may be entirely counter-productive to attempt to change things, even if it's supposed to be for the better. We may just be stuck with double-meanings forever.
Conclusion
I appreciate that this post has been a little biased: I wrote the article you linked to. :) Anyway, I hope this helps to explain the battle a bit better.
Update 13/04/2011
Here are three perfect examples of someone who is using "the STL" to refer to the entire C++ Standard Library. It continues to baffle me that so many people swear blind that nobody ever does this, when it's plain to see almost on a daily basis.
There is no one answer that's really correct. Alexander Stepanov developed a library he called STL (working for HP at the time). That library was then proposed for inclusion in the C++ standard.
That basically "forked" development. The committee included some parts, rejected others completely, and redesigned a few (with Alexander's participation). Development of the original library was later moved to Silicon Graphics, but continued separately from the C++ standard library.
After those pieces were added to the standard library, some other parts of the standard library were modified to fit better with what was added (e.g., begin, end, rbegin and rend were added to std::string so it could be used like a container). Around the same time, most of the library (even pieces that were completely unrelated) were made into templates to accommodate different types (e.g., standard streams).
Some people also use STL as just a short form of "STandard Library".
That means when somebody uses the term "STL" they could be referring to any of about half a dozen different things. For better or worse, most people who use it seem to ignore the multiplicity of meanings, and assume that everybody else will recognize what they're referring to. This leads to many misunderstandings, and at least a few serious flame-wars that made most of the participants look foolish because they were simply talking about entirely different things.
Unfortunately, the confusion is likely to continue unabated. It's much more convenient to refer to "STL" than something like "the containers, iterators, and algorithms in the C++ standard library, but not including std::string, even though it can act like a container." Even though "C++ standard library" isn't quite as long and clumsy as that, "STL" is still a lot shorter and simpler still. Until or unless somebody invents terms that are more precise (when necessary), and just as convenient, "STL" will continue to be used and confusion will continue to result.
The term "STL" or "Standard Template Library" does not show up anywhere in the ISO 14882 C++ standard. So referring to the C++ standard library as STL is wrong. The term "C++ Standard Library" or "standard library" is what's officially used by ISO 14882:
ISO 14882 C++ Standard:
17 - Library introduction [lib.library]:
This clauses describes the contents of the C++ Standard Library, how
a well-formed C++ program makes use of
the library, and how a conforming
implementation may provide the
entities in the library.
...
STL is a library originally designed by Alexander Stepanov, independent of the C++ standard. However, some components of the C++ standard library include STL components like vector, list and algorithms like copy and swap.
But of course the C++ standard includes much more things outside the STL, so the term "C++ standard library" is more correct (and is what's actually used by the standards documents).
I've made this same argument recently, but I believe a little tolerance can be allowed. If Scott Meyers makes the same mistake, you're in good company.
From the GNU Standard C++ Library (libstdc++) FAQ:
The STL (Standard Template Library) was the inspiration for large chunks of the C++ Standard Library, but the terms are not interchangeable and they don't mean the same thing. The C++ Standard Library includes lots of things that didn't come from the STL, and some of them aren't even templates, such as std::locale and std::thread.
Libstdc++-v3 incorporates a lot of code from the SGI STL (the final merge was from release
3.3). The code in libstdc++ contains many fixes and changes compared to the original SGI code.
In particular, string is not from SGI and makes no use of their "rope" class (although that is included as an optional extension), neither is valarray nor some others. Classes like vector<> were from SGI, but have been extensively modified.
More information on the evolution of libstdc++ can be found at the API evolution and backwards compatibility documentation.
The FAQ for SGI's STL is still recommended reading.
FYI, as of March 2018 even the official STL web site www.sgi.com/tech/stl/ is gone.
In layman words: STL is part of Standard Library.
C++ Standard Library is group into:
Standard Functional Library
-I/O,
-String and character handling,
-Mathematical,
-Time, date, and localization,
-Dynamic allocation,
-Miscellaneous,
-Wide-character functions
Standard OOP and Generics Library
-The Standard C++ I/O Classes
-The String Class
-The Numeric Classes
-The STL Container Classes
-The STL Algorithms
-The STL Function Objects
-The STL Iterators
-The STL Allocators
-The Localization library
-Exception Handling Classes
-Miscellaneous Support Library
So if you are talking about STL as Standard Library, it is OK and just remember that STL implementations allow for generics and others are more specific to one type.
Please refer to https://www.tutorialspoint.com/cplusplus/cpp_standard_library.htm
C++ Standard Library includes C++ STL
The contents of the C++ standard library are:
C++ version of C language header file
C++ IO header file
C++ STL
So please don’t confuse the C++ standard library with STL.
for example boost::function is moved almost entirely to std::function, the same is with boost::shared_ptr
But I can't find std::any?
Was it renamed or was not it placed in new standard at all by any reason?
Since the question was asked, we advanced towards std::experimental::any as an optional feature voted out of C++14 standard.
It was then implemented in GCC 5.1, at least.
The feature was since then standardized in C++17 resulting in std::any. See also C++17's std::variant for a type-safe union which either holds one of a limited known-types alternative, or is empty (thanks remy-lebeau for the tip).
Not every library from boost makes it into the standard (and even those that do may have components removed). Generally the commitee is pretty conservative when it comes to adding to the standardlibrary (since it's next to impossible to get something removed at a later point if the inclusion was a mistake (.e.g. because there is a better alternative)).
boost::function and boost::shared_ptr where pretty much a given for inclusion since they where already part of tr1. boost::any on the other hand did not make the cut. It might however be included in the standard library at a later point (e.g. in the next technical report, look here). While boost::any is nice to have, I wouldn't rate it as quite as important as e.g. shared_ptr.
Concluding: boost::any is not part of C++11, since the committee didn't see any pressing need to include it
Std::any was recently accepted into the c++17 standard:
http://en.cppreference.com/w/cpp/utility/any
I think the default position was that a library would NOT be included in the new standard unless it was submitted to be included and then passed the committee.
I am not sure if boost::any was ever submitted. Probably not. However you can still use boost::any.
My guess is that with C++11 boost libraries will be rewritten, some will be considered redundant and others will be changed to use move semantics, initializer lists and auto thus being written in C++11 style with C++11 features.
Most likely new libraries will all be in C++11 but existing boost packages will be kept as available for some time to come as many will not have switched to C++11 compilers yet. I would also guess that only features of C++11 that are implemented by all the main compilers will go into the package at first.
This is probably more a question for programmers than stackoverflow, and even better for comp.std.c++.moderated and boost mailing lists.
I'm trying to get my program working without boost usage, but can't find an alternative of some useful patterns. Namely, I can't find boost::optional-likewise pattern in the standard library. Is there some standard alternative for boost::optional (C++11 or somewhere else)?
Short answer: No.
Long answer: Roll your own according to the boost spec. The documentation is quite exhaustive and the code isn't that complex, but this still requires above average C++ skills.
To update this answer: C++14 unfortunately did not ship with std::optional. The current proposal (Revision 5) is N3793 and it is expected to be shipped as a separate technical specification or to become part of C++17.
There is currently a proposal for C++14 (or C++17). So the answer is (probably) not yet :).
Like pmr explained, it is not possible right now, and will not be until C++17 is out.
However, you should be able to use this single header library on github as a drop in replacement of boost- or std optional. It has no dependencies (except a c++11/c++14 capable compiler).
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.