type traits not in boost.type_traits

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

type traits not in boost.type_traits

Frédéric Bron
I found the following files in 1.46.0  that could be either removed or
moved to type_traits:

* graph/detail/is_same.hpp -> already existing type traits library

comment in the file: Deprecate the use of this header. TODO: Remove
this file from trunk/release in 1.41/1.42.
by the way, it seems that the file is never included so that we could
safely remove it.
Can we do that and run the tests to see if everything is still working?

* iostreams/detail/is_dereferenceable.hpp -> could be moved to type
traits but I should have a look to see if I cannot implement it in the
extension
If it is straightforward, I will implement it.

The following will be part of the type trait extension (so let's
review the extension first...):

* detail/is_incrementable.hpp -> has_operator_increment<T>
* exception/detail/is_output_streamable.hpp ->
has_operator_left_shift<std::ostream, T>

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

Re: type traits not in boost.type_traits

Jeremiah Willcock
On Fri, 25 Feb 2011, Frédéric Bron wrote:

> I found the following files in 1.46.0  that could be either removed or
> moved to type_traits:
>
> * graph/detail/is_same.hpp -> already existing type traits library
>
> comment in the file: Deprecate the use of this header. TODO: Remove
> this file from trunk/release in 1.41/1.42.
> by the way, it seems that the file is never included so that we could
> safely remove it.
> Can we do that and run the tests to see if everything is still working?
I have no problem with that.  I'll try to get that done in trunk either
tonight or tomorrow.

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

Re: type traits not in boost.type_traits

Jeremiah Willcock
In reply to this post by Frédéric Bron
On Fri, 25 Feb 2011, Frédéric Bron wrote:

> I found the following files in 1.46.0  that could be either removed or
> moved to type_traits:
>
> * graph/detail/is_same.hpp -> already existing type traits library
>
> comment in the file: Deprecate the use of this header. TODO: Remove
> this file from trunk/release in 1.41/1.42.
> by the way, it seems that the file is never included so that we could
> safely remove it.
> Can we do that and run the tests to see if everything is still working?
OK -- it is gone from the trunk now.  The BGL tests passed without it and
it was not included from anywhere.

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

Re: type traits not in boost.type_traits

John Maddock-3
In reply to this post by Frédéric Bron
> * iostreams/detail/is_dereferenceable.hpp -> could be moved to type
> traits but I should have a look to see if I cannot implement it in the
> extension
> If it is straightforward, I will implement it.
>
> The following will be part of the type trait extension (so let's
> review the extension first...):

Go for it :-)

John.



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

Re: type traits not in boost.type_traits

Stewart, Robert
In reply to this post by Frédéric Bron
Frédéric Bron wrote:
>
> I found the following files in 1.46.0  that could be either removed or
> moved to type_traits:
>
> * graph/detail/is_same.hpp -> already existing type traits library
>
> * iostreams/detail/is_dereferenceable.hpp -> could be moved to type
> traits but I should have a look to see if I cannot implement it in the
> extension

I'm glad you're looking for duplication.  Nice work.  It's complicated, I'm sure, by the various names folks may choose for the same trait, though no doubt prefixes like "is_" help.

Have you looked for compound traits in other libraries that could be added to TypeTraits for convenience?  That is, if it is very common to combine certain traits, then a single trait that captures the compound would simplify a good deal of code.

_____
Rob Stewart                           [hidden email]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: type traits not in boost.type_traits

Vicente Botet
In reply to this post by Frédéric Bron
Frédéric Bron wrote
I found the following files in 1.46.0  that could be either removed or
moved to type_traits:

* graph/detail/is_same.hpp -> already existing type traits library

comment in the file: Deprecate the use of this header. TODO: Remove
this file from trunk/release in 1.41/1.42.
by the way, it seems that the file is never included so that we could
safely remove it.
Can we do that and run the tests to see if everything is still working?

* iostreams/detail/is_dereferenceable.hpp -> could be moved to type
traits but I should have a look to see if I cannot implement it in the
extension
If it is straightforward, I will implement it.

The following will be part of the type trait extension (so let's
review the extension first...):

* detail/is_incrementable.hpp -> has_operator_increment<T>
* exception/detail/is_output_streamable.hpp ->
has_operator_left_shift<std::ostream, T>
Hi,

http://www.boost.org/doc/libs/1_46_0/libs/utility/operators.htm#arithmetic could be a good starting point to name some common groups of operations.

http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_traits/doc/#StandardConceptTraits gives some more elaborated concepts that could be added.

Best,
Vicente
Reply | Threaded
Open this post in threaded view
|

Re: type traits not in boost.type_traits

Frédéric Bron
In reply to this post by Jeremiah Willcock
> OK -- it is gone from the trunk now.  The BGL tests passed without it and it
> was not included from anywhere.

Great job!
Frédéric
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: type traits not in boost.type_traits

Frédéric Bron
In reply to this post by Stewart, Robert
> Have you looked for compound traits in other libraries that could be added to TypeTraits for convenience?  That is, if it is very common to combine certain traits, then a single trait that captures the compound would simplify a good deal of code.

No I have not.
what about is_voidstar? I am using this a lot in my addition.
Would it be meaningful to add this?

I checked a bit more for duplicates:
* these are duplicate:
  . boost/detail/has_default_constructor.hpp and
boost/type_traits/has_trivial_constructor.hpp
  . boost/type_traits/is_float.hpp and
boost/type_traits/is_floating_point.hpp (is_float is not in the
documentation)

* these would be nice to have in type_traits
  . boost/mpl/has_xxx.hpp
  . boost/mpl/math/is_even.hpp
  . boost/icl/type_traits/is_container.hpp
  . boost/icl/type_traits/is_numeric.hpp

* are these duplicates?
  . boost/ptr_container/detail/is_convertible.hpp and
boost/ptr_container/detail/is_convertible.hpp
  . boost/icl/type_traits/is_discrete.hpp and boost/type_traits/is_scalar.hpp
  . boost/preprocessor/facilities/is_empty.hpp and
boost/type_traits/is_empty.hpp
  . is_member_function_pointer.hpp in boost/function_types and boost/type_traits
  . is_member_object_pointer.hpp in boost/function_types and boost/type_traits
  . is_member_pointer.hpp in boost/function_types and boost/type_traits

* will be part of the type trait extension
  . boost/detail/is_incrementable.hpp ->
has_operator_prefix_increment<T> and has_operator_postfix_increment<T>
  . boost/exception/detail/is_output_streamable.hpp ->
has_operator_left_shift<OStream, T>

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

Re: type traits not in boost.type_traits

Vicente Botet
Frédéric Bron wrote
> Have you looked for compound traits in other libraries that could be added to TypeTraits for convenience?  That is, if it is very common to combine certain traits, then a single trait that captures the compound would simplify a good deal of code.

No I have not.
what about is_voidstar? I am using this a lot in my addition.
Would it be meaningful to add this?
What is expected for is_voidstar, is_void_ptr?

* these would be nice to have in type_traits
  . boost/mpl/has_xxx.hpp
This should be taken in account by Boost.TTI

  . boost/mpl/math/is_even.hpp
This has a sens only for integral types. I don't see the need to move it to type_traits. BTW, where these math extensions are documented?

  . boost/icl/type_traits/is_container.hpp
Agree.

  . boost/icl/type_traits/is_numeric.hpp
This seems similar to is_arithmetic but has some particularities.

* are these duplicates?
  . boost/ptr_container/detail/is_convertible.hpp and
    boost/ptr_container/detail/is_convertible.hpp
Here it was you that make the duplication ;-) I guess you are talking of boost/type_traits/is_convertible.hpp. I suspect that this is a duplication, but it is not public. Maybe Ion can use the one provided by type_traits.

  . boost/preprocessor/facilities/is_empty.hpp and
boost/type_traits/is_empty.hpp
boost/preprocessor/facilities/is_empty.hpp  define BOOST_PP_IS_EMPTY. Have you seen the contents of the files you are listing here or you expected someone as me to make the analysis :(?

Best,
Vicente
Reply | Threaded
Open this post in threaded view
|

Re: type traits not in boost.type_traits

Edward Diener-3
In reply to this post by Frédéric Bron
On 2/26/2011 4:21 AM, Frédéric Bron wrote:
>> Have you looked for compound traits in other libraries that could be added to TypeTraits for convenience?  That is, if it is very common to combine certain traits, then a single trait that captures the compound would simplify a good deal of code.

I do not think you should worry too much about what else exists right
now as long as you feel you have a complete set of operators, which
should be the main focus of your library as I see it. There can be time
enough if your library gets accepted into Boost for other implementers
of type traits like extensions to use your operators instead of what
they had been using in order to avoid redundancy. It's not your job to
delay finishing your work in any way to worry about redundancies in all
other Boost libraries.

>
> No I have not.
> what about is_voidstar? I am using this a lot in my addition.
> Would it be meaningful to add this?
>
> I checked a bit more for duplicates:
> * these are duplicate:
>    . boost/detail/has_default_constructor.hpp and
> boost/type_traits/has_trivial_constructor.hpp
>    . boost/type_traits/is_float.hpp and
> boost/type_traits/is_floating_point.hpp (is_float is not in the
> documentation)
>
> * these would be nice to have in type_traits
>    . boost/mpl/has_xxx.hpp

These are in my TTI library as BOOST_TTI_HAS_TYPE and
BOOST_TTI_HAS_TEMPLATE.

>    . boost/mpl/math/is_even.hpp
>    . boost/icl/type_traits/is_container.hpp
>    . boost/icl/type_traits/is_numeric.hpp
>
> * are these duplicates?
>    . boost/ptr_container/detail/is_convertible.hpp and
> boost/ptr_container/detail/is_convertible.hpp
>    . boost/icl/type_traits/is_discrete.hpp and boost/type_traits/is_scalar.hpp
>    . boost/preprocessor/facilities/is_empty.hpp and
> boost/type_traits/is_empty.hpp
>    . is_member_function_pointer.hpp in boost/function_types and boost/type_traits
>    . is_member_object_pointer.hpp in boost/function_types and boost/type_traits
>    . is_member_pointer.hpp in boost/function_types and boost/type_traits
>
> * will be part of the type trait extension
>    . boost/detail/is_incrementable.hpp ->
> has_operator_prefix_increment<T>  and has_operator_postfix_increment<T>
>    . boost/exception/detail/is_output_streamable.hpp ->
> has_operator_left_shift<OStream, T>

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

Re: type traits not in boost.type_traits

John Maddock-3
In reply to this post by Frédéric Bron
> Have you looked for compound traits in other libraries that could be added
> to TypeTraits for convenience? That is, if it is very common to combine
> certain traits, then a single trait that captures the compound would
> simplify a good deal of code.

>I checked a bit more for duplicates:
>* these are duplicate:
>  . boost/detail/has_default_constructor.hpp and
>boost/type_traits/has_trivial_constructor.hpp

No default and trivial constructors are quite different things, note that
there is no way to check for a default constructor within C++03 either.

BTW I can't find any file using this trait?

>  . boost/type_traits/is_float.hpp and
>boost/type_traits/is_floating_point.hpp (is_float is not in the
>documentation)

is_float is depricated and deliberately removed from the docs, it remains
for the sake of legacy code, is_floating_point is the new shiny C++0x name
:-)

There are a few others like that in type traits.

>* these would be nice to have in type_traits
>  . boost/mpl/math/is_even.hpp

It's not a type-trait, just a bit of numerical meta-programming ;-)

HTH, John.

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

Re: type traits not in boost.type_traits

Frédéric Bron
In reply to this post by Frédéric Bron
> * iostreams/detail/is_dereferenceable.hpp -> could be moved to type
> traits but I should have a look to see if I cannot implement it in the
> extension
> If it is straightforward, I will implement it.

I have added that one to the type trait extension as the
implementation is similar to the others (r69313).
- vault unix newlines:
http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.tar.bz2&directory=Extension&
- vault dos newlines:
http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits-dos.tar.bz2&directory=Extension&
- sandbox: http://svn.boost.org/svn/boost/sandbox/type_traits/

Entry point for the documentation is:
type_traits/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html

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

Re: type traits not in boost.type_traits

Frédéric Bron
In reply to this post by Vicente Botet
>> what about is_voidstar? I am using this a lot in my addition.
>> Would it be meaningful to add this?
>
> What is expected for is_voidstar, is_void_ptr?

is_same< T, void* >

>> * are these duplicates?
>>   . boost/ptr_container/detail/is_convertible.hpp and
>>     boost/ptr_container/detail/is_convertible.hpp
>>
>
> Here it was you that make the duplication ;-) I guess you are talking of
> boost/type_traits/is_convertible.hpp.

Yep, sorry for the mistake!

> I suspect that this is a duplication,
> but it is not public. Maybe Ion can use the one provided by type_traits.

>>   . boost/preprocessor/facilities/is_empty.hpp and
>> boost/type_traits/is_empty.hpp
>
> boost/preprocessor/facilities/is_empty.hpp  define BOOST_PP_IS_EMPTY. Have
> you seen the contents of the files you are listing here

I have seen it but did not understand anything!

> or you expected
> someone as me to make the analysis :(?

so yes, sorry.

Frédéric
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost