There is lots of sweet stuff in TR2. Is that going to be in C++17?
I understand that TR1 was completed in 2005 and had to wait until C++11 to be standardized.
But I also understand that TR2 is already complete?
My link to C++17 doesn't mention anything about TR2, but I am hoping...
Maybe.
The point of TR (and now technical specifications) is to allow something to mature independent of the standard iteration process. They can publish a TS, see how it works, see if there are any problems in the implementation and/or use of the feature, and if everything works they can then "fold" it into the full standard.
Each TS is considered on its own merits to see if it will be folded into the next standard.
See http://isocpp.org/std/status (thanks #BenjaminLindley) for current status of the Technical Specification working groups.
Any of them, if completed well prior to 2017, could be folded into the standard. It is unlikely they all will be.
A goal is that we can get the std::experimental features to play with (and use if we are willing to accept the ground shifting under our feet) earlier, while having the features once added to std with fewer regrets and specification changes after that point. There are probably also massive organizational overhead advantages to decoupling the main line standard from each of these side projects and allowing them to evolve independently.
The purpose of a Technical Report, or Technical Specification as they are now, is to gain implementation experience and feedback from implementors and users, to better assess the suitability of features for standardization. One would need a crystal ball to know if a particular TS will be included in a future standard, and which future standard that might be.
Version 1 of the Library Fundamentals TS appears to have passed its final ballot at the November 2014 committee meeting, and version 2 is currently being drafted to incorporate feedback and new proposals. This means it is getting closer to being something which implementors and industry users are happy with, and version 1 is now an immutable specification which implementors can choose to conform to. It is still more than possible for later versions, and later standards, to change in ways which would be incompatible with version 1.
Here's a list (from your wikipedia link) of the features of TR2 - and my comments:
Threads - Included in C++11
The Asio C++ library - this is being considered for a future C++ standard
Signals/Slots - no action at this time (that I know of)
Filesystem Library - FileSystem Technical Specification
Boost Any Library - Part of the Library Fundamentals Technical Specification
Lexical Conversion Library - no action at this time (that I know of)
New String Algorithms - no action at this time (that I know of)
Toward a More Complete Taxonomy of Algebraic Properties for Numeric Libraries in TR2 - no action at this time (that I know of)
Adding heterogeneous comparison lookup to associative containers for TR2 - * Included in C++14*
Related
When the C++ committee publish a new feature that will be part of the standard library in the next standard of the language, do they also release some source code or some kind of guidance on how to implement that feature?
Let's take unique_ptr as an example. The language committee just defines an interface for that class template and let the compiler vendor implement it as it wants? How exactly does this process of implementation of the standard library features occur?
Can anyone implement parts of the standard library for a platform that doesn't have support for them yet? Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that? Where should I look for information? If I decide to open source my project, can I do that? Will I need to follow exactly what the standard says, or I can write a non-compliant version?
Usually,
every new library feature goes through a proposal.
If the proposal makes it to the C++ committee's Library Evolution Working Group, it goes through a series of iterations (a "tough ground" as I am aware).
It undergoes a series of refinement process as described here
Should it require a (TS) Technical Specification (since C++11), it goes there to be baked. Take for example, the #include <filesystem> was in a Filesystem TS prior to C++17.
One thing I believe the committee likes, is an implementation experience.
More information can be found on the ISOCpp site
Well, as to the implementation:
There are quite a number of "library features" that cannot be implemented purely as a library. they require compiler support. And in these case, compilers provides "intrinsic" that you could hook on to. Take for example, clang provides intrinsics for certain type_traits
Most library features have some implementation experience, mostly from the Boost libraries.
You could actually look into the source code for the default standard library that ships with your compiler:
libc++ for Clang
libstdc++ for GCC
Sadly most of the implementations use a whole bunch of underscores. Mostly because they are reserved for use by the "Standard Library".
Can anyone implement parts of the standard library for a platform that doesn't have support for it yet?
Yes, you can, so far your compiler supports that platform, and the platform or Operating System provides usable API. For example. std::cout, elements of std::ifstream, and so much more requires platform specific support.
Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that?
You can look into the code of others and start from there. We learn from giants. Some Open Source Examples:
ETL
StandardCPlusPlus
uClib++
How could I do that? Where should I look for information?
You could check the paper that introduced the feature into the C++ library. For example, std::optional has a stand-alone implementation here which was used as a reference implementation during the proposal stages.
You could check the standard library, and do a laborious study. :-)
Search the internet. :-)
Or write it from scratch as specified by the standard
Will I need to follow exactly what the standard say or I can write a non-compliant version?
There's is no compulsion to follow what the C++ standard library specifies. That would be your "own" library.
Formally, no. As with all standards out there, C++ Standard sets the rules, and does not gives implementation. However, from the practical standpoint, it is nearly impossible to introduce a new feature into Standard Library without proposed implementation, so you often can find those attached to proposals.
As for your questions on "can you write non-compliant version", you can do whatever you want. Adoption might depend on your compliance, or might not - a super-widely adopted MSVC is known to violate C++ standard.
Typically, a new feature is not standardized, unless the committee has some solid evidence that it can be implemented, and will be useful. This very often consists of a prototype implementation in boost, a GNU library, or one of the commercial compiler vendors.
The standard itself does not contain any implementation guidance - it is purely a specification. The compiler vendors (or their subcontractors) choose how to implement that specification.
In the specific case of unique_ptr, it was adopted into the standard from boost::unique_ptr - and you can still use the latter. If you have a compiler that will compile for your microcontroller, it is almost certain that it will be able to build enough of boost to make unique_ptr work.
There is nothing stopping you from writing a non-conforming implementation (apart from the trivial point that if you sold it as being standards-conforming, and it wasn't you might get your local equivalent of Trading Standards come knocking.)
The committee does not release any reference implementations. In the early days, things got standardized and then the tool developers went away and implemented the standard. This has changed, and now the committee looks for features that have been implemented and tested before standardization.
Also major developments usually don't go directly into the standard. First they become experimental features called a Technical Specification or TS. These TS may then be incorporated into the main standard at a later date.
You are free to write you own implementation of the C++ standard library. Plum Hall has a test suite (commercial, I have no connection, but Plum Hall are very involved with C++ standardization).
I don't see any issue with not being conformant. Almost all implementations have some extensions. Just don't make any false claims, especially if you want to sell your product.
If you're interested in getting involved, this can be done via your 'National Body' (ANSI for the USA, BSI for the UK etc.). The isocpp web site has a section on standardization which would be a good starting place.
When the C++ committee publish a new feature that will be part of the standard library in the next standard of the language, do they also release some source code or some kind of guidance on how to implement that feature?
Let's take unique_ptr as an example. The language committee just defines an interface for that class template and let the compiler vendor implement it as it wants? How exactly does this process of implementation of the standard library features occur?
Can anyone implement parts of the standard library for a platform that doesn't have support for them yet? Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that? Where should I look for information? If I decide to open source my project, can I do that? Will I need to follow exactly what the standard says, or I can write a non-compliant version?
Usually,
every new library feature goes through a proposal.
If the proposal makes it to the C++ committee's Library Evolution Working Group, it goes through a series of iterations (a "tough ground" as I am aware).
It undergoes a series of refinement process as described here
Should it require a (TS) Technical Specification (since C++11), it goes there to be baked. Take for example, the #include <filesystem> was in a Filesystem TS prior to C++17.
One thing I believe the committee likes, is an implementation experience.
More information can be found on the ISOCpp site
Well, as to the implementation:
There are quite a number of "library features" that cannot be implemented purely as a library. they require compiler support. And in these case, compilers provides "intrinsic" that you could hook on to. Take for example, clang provides intrinsics for certain type_traits
Most library features have some implementation experience, mostly from the Boost libraries.
You could actually look into the source code for the default standard library that ships with your compiler:
libc++ for Clang
libstdc++ for GCC
Sadly most of the implementations use a whole bunch of underscores. Mostly because they are reserved for use by the "Standard Library".
Can anyone implement parts of the standard library for a platform that doesn't have support for it yet?
Yes, you can, so far your compiler supports that platform, and the platform or Operating System provides usable API. For example. std::cout, elements of std::ifstream, and so much more requires platform specific support.
Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that?
You can look into the code of others and start from there. We learn from giants. Some Open Source Examples:
ETL
StandardCPlusPlus
uClib++
How could I do that? Where should I look for information?
You could check the paper that introduced the feature into the C++ library. For example, std::optional has a stand-alone implementation here which was used as a reference implementation during the proposal stages.
You could check the standard library, and do a laborious study. :-)
Search the internet. :-)
Or write it from scratch as specified by the standard
Will I need to follow exactly what the standard say or I can write a non-compliant version?
There's is no compulsion to follow what the C++ standard library specifies. That would be your "own" library.
Formally, no. As with all standards out there, C++ Standard sets the rules, and does not gives implementation. However, from the practical standpoint, it is nearly impossible to introduce a new feature into Standard Library without proposed implementation, so you often can find those attached to proposals.
As for your questions on "can you write non-compliant version", you can do whatever you want. Adoption might depend on your compliance, or might not - a super-widely adopted MSVC is known to violate C++ standard.
Typically, a new feature is not standardized, unless the committee has some solid evidence that it can be implemented, and will be useful. This very often consists of a prototype implementation in boost, a GNU library, or one of the commercial compiler vendors.
The standard itself does not contain any implementation guidance - it is purely a specification. The compiler vendors (or their subcontractors) choose how to implement that specification.
In the specific case of unique_ptr, it was adopted into the standard from boost::unique_ptr - and you can still use the latter. If you have a compiler that will compile for your microcontroller, it is almost certain that it will be able to build enough of boost to make unique_ptr work.
There is nothing stopping you from writing a non-conforming implementation (apart from the trivial point that if you sold it as being standards-conforming, and it wasn't you might get your local equivalent of Trading Standards come knocking.)
The committee does not release any reference implementations. In the early days, things got standardized and then the tool developers went away and implemented the standard. This has changed, and now the committee looks for features that have been implemented and tested before standardization.
Also major developments usually don't go directly into the standard. First they become experimental features called a Technical Specification or TS. These TS may then be incorporated into the main standard at a later date.
You are free to write you own implementation of the C++ standard library. Plum Hall has a test suite (commercial, I have no connection, but Plum Hall are very involved with C++ standardization).
I don't see any issue with not being conformant. Almost all implementations have some extensions. Just don't make any false claims, especially if you want to sell your product.
If you're interested in getting involved, this can be done via your 'National Body' (ANSI for the USA, BSI for the UK etc.). The isocpp web site has a section on standardization which would be a good starting place.
The Filesystem Technical Specification (TS) has recently been merged into the C++17 standard.
The same TS is also available for C++14, but in this case it's technically only "experimental". However the fact that it's been approved for C++17 makes me think it's mature enough and that it can be used safely.
When working on a C++14 project that will most likely be upgraded to C++ 17 in the future, and assuming the compiler I use supports it on both versions, would you advise against using the "experimental" TS, considering that it will officially be part of the next standard?
My question of course extends to any TS that has been accepted in a future C++ version and that is available for earlier standards.
The real question is whether or not somebody's implemented it, not whether or not it's been approved/merged/whatever of some arbitrary document. Features can be excised, added or modified at any point in time of the standardization process. We've seen things get cut from C++14 right before release and also things that couldn't make it that were later amended. Vendors rely on specific versions of documents when implementing features and so the only surefire way is to consult the documentation of whatever compiler you're using.
Actual implementations can contains features that are not in the current standard, and can have flaws in other features that are defined in the standard or even can fail to implement specific parts - Microsoft was know to let parts of the standard unimplemented.
But if a compiler supports a feature, and if that feature is part of next standard, there is little risk if any that it will disappear in a future version of that particular compiler.
Simply, some other compiler may not implement it as soon as it is approved in standard, but you know whether it is a problem in you specific use case.
Is it safe to use a C++ Technical Specifications approved for a future standard in a earlier standard?
It depends on what you mean by "safe"
Is it portable?
No.
Does it work?
You need to check the release notes of your toolset's version, and the release notes of your standard library's version (they may be different).
Will it work tomorrow?
Who knows?
Should I invest time in code that assumes it works?
probably not.
In summary, the answer is "no".
Use the boost version until the standard is published and your compiler and standard library conforms to it.
I have a few questions about the standardization, in particulair the prototype of Net TS1 coming this year (see here).
When does it exactly come?
Does it support portable binairy serialization?
Can it serialize to iostreams like files/std::cout etc?
Is there some other place where I can find the current status besides the mailing lists?
When will GCC/Clang implement it?
About the filesystem (Filesys TS):
It was supposed to be finished as prototype this month, why can't I find anything anywhere?
Is it the same a boost::filesystem? (So it can easily be ported.)
I hope I'm not asking too much questions, and I also hope some can be answered!
The latest full Networking Library proposal, based on Boost.Asio, was published in 2007. At that time, C++0x was still planned for sometime before 2010 and there was also a plan for a C++ Technical Report 2. The idea was to get the Networking Library into TR2.
Working on C++0x clearly stole everybody's attention, because not much else happened with the networking library until after it was published. In 2012, they produced a Networking Library Status Report and noticed that a lot had changed with Boost.Asio in the past 5 years. A study group was formed (SG4) to work on the Networking Library.
Now TR2 doesn't seem to be a happening, and it's full steam ahead for C++14 and beyond. As far as I can tell, there has been no explicit mention of a planned time frame for SG4. However, since it was formed, these are the most up-to-date papers from the mailings:
Using Asio with C++11 (N3388)
Urdl: a simple library for accessing web content (N3477)
C++ Internet Protocol Classes (N3477)
A URI Library for C++ (N3507)
IP Address Design Constraints (N3565)
A Three-Class IP Address Proposal (N3603)
Network Byte Order Conversion (N3620)
So combine these with the full TR2 proposal and you have a pretty good picture of the current status.
When does it exactly come?
There doesn't seem to be a specific time frame. Hopefully we'll see a technical specification sometime before C++14 (maybe even in 2013), but this is merely speculation. It'll be done when it's done.
Does it support portable binary serialization?
I don't think so. I can't find any mention of serialization in any of the papers. I think it's probably beyond the scope of the Networking Library.
Can it serialize to iostreams like files/std::cout etc?
See above.
Is there some other place where I can find the current status besides the mailing lists?
Not at the moment. However, they have been gradually making the mailing lists for each of the study groups public, so maybe SG4 will be made public soon. If it is, we'll get a better view of current progress.
When will GCC/Clang implement it?
Not yet!
In January 2013, revision 4 of the Filesystem Library proposal hit the mailing list. Again, I see no explicit time frame, but this and the Networking Library are the two library study groups with the most focus right now. Hopefully we'll be able to see a technical specification for this too sometime this year or at least before 2014.
It was supposed to be finished as prototype this month, why can't I find anything anywhere?
I haven't seen anything about a prototype, but I guess things sometime take a little longer than planned. Perhaps it just isn't public yet. The Bristol meeting is being held next month and all study groups' progress reports are on the agenda. I'm sure we'll see a technical specification when it's ready.
Is it the same a boost::filesystem?
Pretty much! Take a look at the latest revision; it mentions that it is heavily based on the Boost Filesystem Library version 3. There is a small section on differences:
In the Boost library, facilities in class path to handle narrow (i.e. char) character strings with encodings other than the operating system's native encoding depend on codecvt arguments. In the proposal, these facilities depend on locale arguments and additional UTF-8 facilities have been added. The Filesystem Study Group believes this approach is more reliable and useful, particularly as UTF-8 use continues to spread.
Otherwise, the proposal is very similar to the Boost library. Indeed, most of the proposed wording is generated from the same source as the Boost library's reference documentation.
Like all formal ISO C++ documents, Technical Specifications come when they're done. What it will support is hard to say up front. Features may be cut if they're not ready, or conversely publication may be delayed to get a wanted feature in. E.g. C++98 was delayed for ~2 years to merge in the STL.
The FileSystem TS is indeed being derived from Boost FileSystem, so there is very likely a high degree of commonality.
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.