
Hello Developers, I would like to retrofit some type-traits in boost, but I have read https://pdimov.github.io/articles/phasing_out_cxx03.html. Now I don't know how to do it best, as the boost-type-traits may be removed. Would the following procedure make sense? We get the std-traits and concepts in a namespace boost::meta, eg file boost/type_traits/meta.hpp: #ifndef BOOST_META_HPP #define BOOST_META_HPP #include <type_traits> #if defined(__cpp_concepts) #include <concepts> #endif namespace boost::meta { template <typename Type> using is_integral = std::is_integral<Type>; template <typename Type> inline constexpr bool is_integral_v = std::is_integral_v<Type>; template <typename Type> using is_pointer = std::is_pointer<Type>; template <typename Type> inline constexpr bool is_pointer_v = std::is_pointer_v<Type>; ... all other #if defined(__cpp_concepts) template <typename Type> concept integral = std::integral<Type>; template <typename Type> concept pointer = is_pointer_v<Type>; ... #endif } // boost::meta #endif // BOOST_META_HPP Then you could possibly map this in boost/type_traits.hpp to boost:: (if that makes sense): #ifndef BOOST_TYPE_TRAITS_HPP #define BOOST_TYPE_TRAITS_HPP #include <boost/type_traits/meta.hpp> remove boost implementations namespace boost { using namespace boost::meta; } // boost #endif // BOOST_TYPE_TRAITS_HPP In this way, new traits can be added in boost/type_traits/meta.hpp that are based on the std-traits, e.g. is_logic namespace boost::meta { template <typename Type> struct is_logic : std::false_type{}; template <typename Type> inline constexpr bool is_logic_v = is_logic<Type>::value; template <> struct is_logic<bool> : std::true_type{}; #if defined(__cpp_concepts) template <typename Type> concept logic = is_logic_v<Type>; #endif } // boost::meta and in this case add in boost/logic/tribool.hpp namespace boost::meta { template <> struct is_logic<boost::tribool> : std::true_type{}; } // boost::meta Or do you have a better idea? regards Gero

On 2020-09-12 15:47, Gero Peterhoff via Boost wrote:
Hello Developers, I would like to retrofit some type-traits in boost, but I have read https://pdimov.github.io/articles/phasing_out_cxx03.html. Now I don't know how to do it best, as the boost-type-traits may be removed.
Given that Boost.TypeTraits are not equivalent in some instances to std type traits, I don't think we're going to remove them any time soon. At least, I would be opposed to such a move. You can opportunistically use std type traits and fallback to Boost.TypeTraits in some simple cases, but that doesn't really make much sense in Boost since that doesn't remove the dependency on Boost.TypeTraits and requires workarounds in cases when the type traits don't match. Also, we normally don't include all-in-one headers like <boost/type_traits.hpp> because that brings way more code than necessary. This is one of the drawbacks of <type_traits> and one of the reasons to use Boost.TypeTraits, actually.

Am 12.09.20 um 16:15 schrieb Andrey Semashev via Boost:
Given that Boost.TypeTraits are not equivalent in some instances to std type traits, I don't think we're going to remove them any time soon. At least, I would be opposed to such a move.
You can opportunistically use std type traits and fallback to Boost.TypeTraits in some simple cases, but that doesn't really make much sense in Boost since that doesn't remove the dependency on Boost.TypeTraits and requires workarounds in cases when the type traits don't match.
Also, we normally don't include all-in-one headers like <boost/type_traits.hpp> because that brings way more code than necessary. This is one of the drawbacks of <type_traits> and one of the reasons to use Boost.TypeTraits, actually.
- Is there an overview/documentation which Boost.TypeTraits differ from the standard? - Would it make sense to only keep these different/additional Boost.TypeTraits and remove the standard-compliant ones?

On 10/3/20 11:53 AM, Gero Peterhoff via Boost wrote:
Am 12.09.20 um 16:15 schrieb Andrey Semashev via Boost:
Given that Boost.TypeTraits are not equivalent in some instances to std type traits, I don't think we're going to remove them any time soon. At least, I would be opposed to such a move.
You can opportunistically use std type traits and fallback to Boost.TypeTraits in some simple cases, but that doesn't really make much sense in Boost since that doesn't remove the dependency on Boost.TypeTraits and requires workarounds in cases when the type traits don't match.
Also, we normally don't include all-in-one headers like <boost/type_traits.hpp> because that brings way more code than necessary. This is one of the drawbacks of <type_traits> and one of the reasons to use Boost.TypeTraits, actually.
- Is there an overview/documentation which Boost.TypeTraits differ from the standard?
I haven't seen an overview. But you could read Boost.TypeTraits docs and compare it to the standard to see if there is a difference. Some differences are not documented, I think, like support for 128-bit integers for example.
- Would it make sense to only keep these different/additional Boost.TypeTraits and remove the standard-compliant ones?
IMO, no, because there are C++03 libraries and there are no standard type traits in C++03.

On 10/3/20 12:30 PM, Andrey Semashev wrote:
On 10/3/20 11:53 AM, Gero Peterhoff via Boost wrote:
Am 12.09.20 um 16:15 schrieb Andrey Semashev via Boost:
Given that Boost.TypeTraits are not equivalent in some instances to std type traits, I don't think we're going to remove them any time soon. At least, I would be opposed to such a move.
You can opportunistically use std type traits and fallback to Boost.TypeTraits in some simple cases, but that doesn't really make much sense in Boost since that doesn't remove the dependency on Boost.TypeTraits and requires workarounds in cases when the type traits don't match.
Also, we normally don't include all-in-one headers like <boost/type_traits.hpp> because that brings way more code than necessary. This is one of the drawbacks of <type_traits> and one of the reasons to use Boost.TypeTraits, actually.
- Is there an overview/documentation which Boost.TypeTraits differ from the standard?
I haven't seen an overview. But you could read Boost.TypeTraits docs and compare it to the standard to see if there is a difference. Some differences are not documented, I think, like support for 128-bit integers for example.
I should add that in some cases Boost.TypeTraits work around bugs in the standard type traits, which is also not documented. For example, std::alignment_of would give incorrect result for 64-bit types on 32-bit targets and boost::alignment_of works as expected.
- Would it make sense to only keep these different/additional Boost.TypeTraits and remove the standard-compliant ones?
IMO, no, because there are C++03 libraries and there are no standard type traits in C++03.

Am 03.10.20 um 11:34 schrieb Andrey Semashev via Boost:
On 10/3/20 12:30 PM, Andrey Semashev wrote:
On 10/3/20 11:53 AM, Gero Peterhoff via Boost wrote:
Am 12.09.20 um 16:15 schrieb Andrey Semashev via Boost:
Given that Boost.TypeTraits are not equivalent in some instances to std type traits, I don't think we're going to remove them any time soon. At least, I would be opposed to such a move.
You can opportunistically use std type traits and fallback to Boost.TypeTraits in some simple cases, but that doesn't really make much sense in Boost since that doesn't remove the dependency on Boost.TypeTraits and requires workarounds in cases when the type traits don't match.
Also, we normally don't include all-in-one headers like <boost/type_traits.hpp> because that brings way more code than necessary. This is one of the drawbacks of <type_traits> and one of the reasons to use Boost.TypeTraits, actually.
- Is there an overview/documentation which Boost.TypeTraits differ from the standard?
I haven't seen an overview. But you could read Boost.TypeTraits docs and compare it to the standard to see if there is a difference. Some differences are not documented, I think, like support for 128-bit integers for example.
I should add that in some cases Boost.TypeTraits work around bugs in the standard type traits, which is also not documented. For example, std::alignment_of would give incorrect result for 64-bit types on 32-bit targets and boost::alignment_of works as expected.
I think it would make more sense to document this. So not every user has to find out for himself.
- Would it make sense to only keep these different/additional Boost.TypeTraits and remove the standard-compliant ones?
IMO, no, because there are C++03 libraries and there are no standard type traits in C++03.
Boost should be changed to C++11 and C++03 support removed? https://pdimov.github.io/articles/phasing_out_cxx03.html

On 10/3/20 1:25 PM, Gero Peterhoff via Boost wrote:
Am 03.10.20 um 11:34 schrieb Andrey Semashev via Boost:
On 10/3/20 12:30 PM, Andrey Semashev wrote:
On 10/3/20 11:53 AM, Gero Peterhoff via Boost wrote:
- Would it make sense to only keep these different/additional Boost.TypeTraits and remove the standard-compliant ones?
IMO, no, because there are C++03 libraries and there are no standard type traits in C++03.
Boost should be changed to C++11 and C++03 support removed? https://pdimov.github.io/articles/phasing_out_cxx03.html
"Should" is the wrong word. Individual library authors are allowed to do that. But there may be reasons not to.

On 10/3/2020 6:25 AM, Gero Peterhoff via Boost wrote:
Am 03.10.20 um 11:34 schrieb Andrey Semashev via Boost:
On 10/3/20 12:30 PM, Andrey Semashev wrote:
On 10/3/20 11:53 AM, Gero Peterhoff via Boost wrote:
Am 12.09.20 um 16:15 schrieb Andrey Semashev via Boost:
Given that Boost.TypeTraits are not equivalent in some instances to std type traits, I don't think we're going to remove them any time soon. At least, I would be opposed to such a move.
You can opportunistically use std type traits and fallback to Boost.TypeTraits in some simple cases, but that doesn't really make much sense in Boost since that doesn't remove the dependency on Boost.TypeTraits and requires workarounds in cases when the type traits don't match.
Also, we normally don't include all-in-one headers like <boost/type_traits.hpp> because that brings way more code than necessary. This is one of the drawbacks of <type_traits> and one of the reasons to use Boost.TypeTraits, actually.
- Is there an overview/documentation which Boost.TypeTraits differ from the standard?
I haven't seen an overview. But you could read Boost.TypeTraits docs and compare it to the standard to see if there is a difference. Some differences are not documented, I think, like support for 128-bit integers for example.
I should add that in some cases Boost.TypeTraits work around bugs in the standard type traits, which is also not documented. For example, std::alignment_of would give incorrect result for 64-bit types on 32-bit targets and boost::alignment_of works as expected.
I think it would make more sense to document this. So not every user has to find out for himself.
- Would it make sense to only keep these different/additional Boost.TypeTraits and remove the standard-compliant ones?
IMO, no, because there are C++03 libraries and there are no standard type traits in C++03.
Boost should be changed to C++11 and C++03 support removed? https://pdimov.github.io/articles/phasing_out_cxx03.html
Boost seeks to ensure that the many Boost libraries which can still work at the C++03 level also work at the C++11 on up levels. It would be foolish to eliminate these libraries if they are still useful to programmers compiling at the C++11, C++14, c++17, AND c++20 levels just because they also happen to work at the C++03 level. At the same time Boost is not supporting the C++03 level any more, and libraries are free to move from the C++03 level to the C++11 level or higher if they wish.

Gero Peterhoff wrote:
Hello Developers, I would like to retrofit some type-traits in boost, but I have read https://pdimov.github.io/articles/phasing_out_cxx03.html. Now I don't know how to do it best, as the boost-type-traits may be removed.
Boost.TypeTraits is not made obsolete by C++11, so it won't be removed. It contains both non-standard traits and traits that have been added in a later standard (17, 20). F.ex. https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr...

Hi Peter, i implemented signature_of similar to the function_traits. This is more flexible, but requires C++20. #include <iostream> #include <cstdlib> #include <utility> #include <boost/type_traits/signature_of.hpp> int foo(bool, float&, const uint64_t, const double&); template <typename Type> void show_type() noexcept { std::cout << typeid(Type).name() << std::endl; } template <typename Tuple> void show_tuple_types() noexcept { auto show_elems = []<std::size_t... Idx>(const std::index_sequence<Idx...>&) noexcept { (show_type<std::tuple_element_t<Idx, Tuple>>(), ...); }; show_elems(std::make_index_sequence<std::tuple_size_v<Tuple>>{}); } int main(const int argc, const char** args) { using sig_foo = boost::signature_of<foo>; // or &foo std::cout << "foo\n"; std::cout << "result:\t\t\t" << typeid(sig_foo::result_type).name() << std::endl; std::cout << "tuple<arguments>:\t" << typeid(sig_foo::argument_type).name() << std::endl; std::cout << "argument size:\t\t" << boost::argument_size_v<foo> << std::endl; std::cout << "argument types are:\n"; show_tuple_types<typename sig_foo::argument_type>(); using sig_baz = boost::signature_of<&bar::baz>; std::cout << "\nbaz\n"; std::cout << "result:\t\t\t" << typeid(sig_baz::result_type).name() << std::endl; std::cout << "tuple<arguments>:\t" << typeid(sig_baz::argument_type).name() << std::endl; std::cout << "argument size:\t\t" << boost::argument_size_v<&bar::baz> << std::endl; std::cout << "argument types are:\n"; show_tuple_types<typename sig_baz::argument_type>(); return EXIT_SUCCESS; } (Hint: typeid ignore references) regards Gero Am 12.09.20 um 17:35 schrieb Peter Dimov via Boost:
Gero Peterhoff wrote:
Hello Developers, I would like to retrofit some type-traits in boost, but I have read https://pdimov.github.io/articles/phasing_out_cxx03.html. Now I don't know how to do it best, as the boost-type-traits may be removed.
Boost.TypeTraits is not made obsolete by C++11, so it won't be removed. It contains both non-standard traits and traits that have been added in a later standard (17, 20). F.ex.
https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Gero Peterhoff wrore:
Hi Peter, i implemented signature_of similar to the function_traits. This is more flexible, but requires C++20.
There's no need for C++20 here, 11 is enough. See also https://github.com/boostorg/type_traits/issues/147 that I just opened for other reasons.

Ok, this version works with C++11, but the call is slightly different: using sig_foo = boost::signature_of<decltype(&foo)>; using sig_baz = boost::signature_of<decltype(&bar::baz)>; and boost::argument_size_v<decltype(&foo)> boost::argument_size_v<decltype(&bar::baz)> But there is still one problem: if a parameter is const it is not recognized. Do you have an idea? Am 12.09.20 um 20:50 schrieb Peter Dimov via Boost:
Gero Peterhoff wrore:
Hi Peter, i implemented signature_of similar to the function_traits. This is more flexible, but requires C++20.
There's no need for C++20 here, 11 is enough. See also https://github.com/boostorg/type_traits/issues/147 that I just opened for other reasons.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Gero Peterhoff wrote:
But there is still one problem: if a parameter is const it is not recognized. Do you have an idea?
Parameters are never const. https://godbolt.org/z/cMajnP

I'm not a big fan of the NTTP used especially as e.g. for overloaded operator() the result is ambigious. What was the reason for choosing it? Besides that as Peter said the tuple/MPL list of arguments is a good idea. Another good idea is improved handling of member functions. E.g. in C++11 and up you don't only have const and noexcept but also rvalue and lvalue specifiers. So that could be added too Regards, Alex Am 12.09.20 um 20:33 schrieb Gero Peterhoff via Boost:
Hi Peter, i implemented signature_of similar to the function_traits. This is more flexible, but requires C++20.
#include <iostream> #include <cstdlib> #include <utility> #include <boost/type_traits/signature_of.hpp>
int foo(bool, float&, const uint64_t, const double&);
template <typename Type> void show_type() noexcept { std::cout << typeid(Type).name() << std::endl; } template <typename Tuple> void show_tuple_types() noexcept { auto show_elems = []<std::size_t... Idx>(const std::index_sequence<Idx...>&) noexcept { (show_type<std::tuple_element_t<Idx, Tuple>>(), ...); };
show_elems(std::make_index_sequence<std::tuple_size_v<Tuple>>{}); }
int main(const int argc, const char** args) { using sig_foo = boost::signature_of<foo>; // or &foo std::cout << "foo\n"; std::cout << "result:\t\t\t" << typeid(sig_foo::result_type).name() << std::endl; std::cout << "tuple<arguments>:\t" << typeid(sig_foo::argument_type).name() << std::endl; std::cout << "argument size:\t\t" << boost::argument_size_v<foo> << std::endl; std::cout << "argument types are:\n"; show_tuple_types<typename sig_foo::argument_type>();
using sig_baz = boost::signature_of<&bar::baz>; std::cout << "\nbaz\n"; std::cout << "result:\t\t\t" << typeid(sig_baz::result_type).name() << std::endl; std::cout << "tuple<arguments>:\t" << typeid(sig_baz::argument_type).name() << std::endl; std::cout << "argument size:\t\t" << boost::argument_size_v<&bar::baz> << std::endl; std::cout << "argument types are:\n"; show_tuple_types<typename sig_baz::argument_type>();
return EXIT_SUCCESS; }
(Hint: typeid ignore references)
regards Gero

On 14. Sep 2020, at 11:04, Alexander Grund via Boost <boost@lists.boost.org> wrote:
I'm not a big fan of the NTTP used especially as e.g. for overloaded operator() the result is ambigious. What was the reason for choosing it?
Besides that as Peter said the tuple/MPL list of arguments is a good idea. Another good idea is improved handling of member functions. E.g. in C++11 and up you don't only have const and noexcept but also rvalue and lvalue specifiers. So that could be added too
AFAIU Boost.CallableTraits can do all this and more. https://www.boost.org/doc/libs/1_74_0/libs/callable_traits/doc/html/callable... https://www.boost.org/doc/libs/1_74_0/libs/callable_traits/doc/html/callable... https://www.boost.org/doc/libs/1_74_0/libs/callable_traits/doc/html/callable... The args are returned as a std::tuple, which is Boost.Mp11 compatible.

oops, i forgot struct bar { constexpr void baz(int) const noexcept {} }; Am 12.09.20 um 17:35 schrieb Peter Dimov via Boost:
Gero Peterhoff wrote:
Hello Developers, I would like to retrofit some type-traits in boost, but I have read https://pdimov.github.io/articles/phasing_out_cxx03.html. Now I don't know how to do it best, as the boost-type-traits may be removed.
Boost.TypeTraits is not made obsolete by C++11, so it won't be removed. It contains both non-standard traits and traits that have been added in a later standard (17, 20). F.ex.
https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr... https://www.boost.org/doc/libs/1_74_0/libs/type_traits/doc/html/boost_typetr...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
Alexander Grund
-
Andrey Semashev
-
Edward Diener
-
Gero Peterhoff
-
Hans Dembinski
-
Peter Dimov