new type traits

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

new type traits

Boost - Dev mailing list
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
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:

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature_of.hpp (2K) Download Attachment
signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
oops, i forgot

struct bar
{
        constexpr void baz(int) const noexcept {}
};

Am 12.09.20 um 17:35 schrieb Peter Dimov via Boost:

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature_of.hpp (2K) Download Attachment
signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list

> On 14. Sep 2020, at 11:04, Alexander Grund via Boost <[hidden email]> 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_traits/reference.html#callable_traits.reference.ref_args
https://www.boost.org/doc/libs/1_74_0/libs/callable_traits/doc/html/callable_traits/reference.html#callable_traits.reference.ref_function_type
https://www.boost.org/doc/libs/1_74_0/libs/callable_traits/doc/html/callable_traits/reference.html#callable_traits.reference.ref_return_type

The args are returned as a std::tuple, which is Boost.Mp11 compatible.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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?



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: new type traits

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost