What C++14/1z standard or TS libraries would you like to have available on a C++11 compiler?
Hi,
I would like to have your feedback on C++ standard library features you
would like to have available for a C++11 compiler.
The idea would be to present a Boost.StdExtensions library that would
provide some of these features for review with some of these features.
Please , let me know if you are interested in participating in this
project and working on some specific parts.
This library should avoid as much Boost dependencies as possible.
How the library could be structured? I believe that it should follow the
C++ standard files.
Which folder should be used? boost/stdext? boost/stdext11?
Which namespace? boost::stdext?
I have prefixed with a * the lines that interest myself and with VBE*
those that I could work on.
The features that need compiler help or that need C++14/17 language
features are excluded and prefixed by N/A.
Please be free to add a * if you are interested and your name as well if
you want to participate.
Best,
Vicente
P.S. The project could be as well extended to C++98 compilers with C++11
standard libraries (But I would not have time to invest in).
P.S.S. I would also be interested in extend the project to extended to
C++14 compilers.
C++14 standard libraries
================
VBE* N3658 - Compile-time integer sequences
* N3654 - Quoted Strings
N3656 - make_unique
VBE* N3462 - std::result_of and SFINAE
* N3668 std::exchange()
N3469 Constexpr Library Additions: chrono
N3470 Constexpr Library Additions: containers
N3471 Constexpr Library Additions: utilities
N3302 Constexpr Library Additions: complex
VBE* N3545 An Incremental Improvement to integral_constant
N3644 Null Forward Iterators
N3670 Addressing Tuples by Type
N3671 Making non-modifying sequence operations more robust
N3642 User-defined Literals
VBE* N3655 TransformationTraits Redux (excluding part 4)
N3657 Adding heterogeneous comparison lookup to associative containers
N3669 Fixing constexpr member functions without const
N3659 Shared Locking in C++
N3779 User-defined Literals for std::complex
N3789 Constexpr Library Additions: functional
N3887 Consistent Metafunction Aliases
N3891 A proposal to rename shared_mutex to shared_timed_mutex
C++1z standard libraries
================
VBE* N3911 TransformationTrait Alias void_t
N4089 Safe conversions in unique_ptr
Vicente J. Botet Escriba wrote:
VBE* N3658 - Compile-time integer sequences
Many implementations are available, but if you need one you can lift without any changes at all, https://github.com/pdimov/mp11/blob/master/include/boost/integer_sequence.hp... https://github.com/pdimov/mp11/blob/master/test/integer_sequence.cpp I think that we probably should put it into type_traits.
N3656 - make_unique
This is already in smart_ptr, I think.
P0033R1 Re-enabling shared_from_this
So is this.
Changes to std::shared_ptr and weak_ptr
And this.
Le 22/05/2016 à 18:06, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
VBE* N3658 - Compile-time integer sequences
Many implementations are available, but if you need one you can lift without any changes at all,
https://github.com/pdimov/mp11/blob/master/include/boost/integer_sequence.hp...
https://github.com/pdimov/mp11/blob/master/test/integer_sequence.cpp
I think that we probably should put it into type_traits. I know of valid implementations. I would like to have them in Boost.
N3656 - make_unique
This is already in smart_ptr, I think. Right.
P0033R1 Re-enabling shared_from_this
So is this. Right.
Changes to std::shared_ptr and weak_ptr
And this. Right.
I would like to reduce dependencies to Boost libraries as much as possible. When the new feature can be implemented only if we have already an implementation of some parts of the standard library this needs evidently much more work. E.g. changing the constexpr of some member functions, ... This is way I'm not interested on working on these features as part of Boost.StdExtensions. I'm interested in working on the new features that can be added on top of a C++11 version? Boost.StdExtensions could be in someway similar to Boost.TR1. But I would like to reduce the dependencies to Boost. Boost.StdExtensions would contain only features that have been approved in a C++ standard version but that are not delivered by the standard library associated to the compiler version. Vicente
On 22 May 2016, at 19:06, Vicente J. Botet Escriba
wrote:. I would like to reduce dependencies to Boost libraries as much as possible.
Why? Will it e.g. be released outside boost? Wouldn't it have to be *completely* independent in that case?
Le 22/05/2016 à 19:53, Thijs (M.A.) van den Berg a écrit :
On 22 May 2016, at 19:06, Vicente J. Botet Escriba
wrote:. I would like to reduce dependencies to Boost libraries as much as possible.
Why?
Because Boost 1.x is too monolitic.
Will it e.g. be released outside boost? Why not? I believe that this should be useful also to on)boost users.
Wouldn't it have to be *completely* independent in that case? I could admit some configuration dependencies that can be avoided easily when delivered standalone.
Vicente
On 5/22/2016 11:40 AM, Vicente J. Botet Escriba wrote:
Hi,
I would like to have your feedback on C++ standard library features you would like to have available for a C++11 compiler.
The idea would be to present a Boost.StdExtensions library that would provide some of these features for review with some of these features.
I do not understand what you are asking about ? Don't most compilers when set to C++11 mode on up support C++ standard libraries which support the use of C++11 idioms ? Evidently I am confused what you are proposing. Could you specify your idea for a Boost.StdExtensions library more clearly.
Please , let me know if you are interested in participating in this project and working on some specific parts.
This library should avoid as much Boost dependencies as possible.
How the library could be structured? I believe that it should follow the C++ standard files. Which folder should be used? boost/stdext? boost/stdext11? Which namespace? boost::stdext?
I have prefixed with a * the lines that interest myself and with VBE* those that I could work on.
The features that need compiler help or that need C++14/17 language features are excluded and prefixed by N/A.
Please be free to add a * if you are interested and your name as well if you want to participate.
Le 22/05/2016 à 18:19, Edward Diener a écrit :
On 5/22/2016 11:40 AM, Vicente J. Botet Escriba wrote:
Hi,
I would like to have your feedback on C++ standard library features you would like to have available for a C++11 compiler.
The idea would be to present a Boost.StdExtensions library that would provide some of these features for review with some of these features.
I do not understand what you are asking about ? Don't most compilers when set to C++11 mode on up support C++ standard libraries which support the use of C++11 idioms ? Evidently I am confused what you are proposing. Could you specify your idea for a Boost.StdExtensions library more clearly.
I'm looking for the C++14/C++1z libraries that are not available with the C++11 compiler. Vicente
On May 22, 2016, at 10:40 AM, Vicente J. Botet Escriba
wrote: Hi,
I would like to have your feedback on C++ standard library features you would like to have available for a C++11 compiler.
The idea would be to present a Boost.StdExtensions library that would provide some of these features for review with some of these features.
I think it would be nice to have C++14 and C++1z missing items in boost, but I think putting all into one monster library is a bad idea. Also, libraries may evolve beyond the standard. For example, the library could provide C++14 integral constant, but it could also provide the operators for it as well, which could be standardized later. This is another reason, it may make sense to split this into smaller libraries.
On 23/05/2016 12:33, Paul Fultz II wrote:
Also, libraries may evolve beyond the standard. For example, the library could provide C++14 integral constant, but it could also provide the operators for it as well, which could be standardized later. This is another reason, it may make sense to split this into smaller libraries.
This has already happened for libraries such as smart_ptr; a subset of the Boost library entered the standard in C++11 (or even earlier in TR1), but it continued to evolve and important features such as P0033R1 won't be added until C++17.
participants (6)
-
Edward Diener
-
Gavin Lambert
-
Paul Fultz II
-
Peter Dimov
-
Thijs (M.A.) van den Berg
-
Vicente J. Botet Escriba