type traits not in boost.type_traits
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
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
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
* 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.
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 robert.stewart@sig.com 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.
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
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 -- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-not-in-boost-type-traits-tp33... Sent from the Boost - Dev mailing list archive at Nabble.com.
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
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>
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.
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_tr... gives some more elaborated concepts that could be added. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-not-in-boost-type-traits-tp33... Sent from the Boost - Dev mailing list archive at Nabble.com.
* 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
participants (6)
-
Edward Diener -
Frédéric Bron -
Jeremiah Willcock -
John Maddock -
Stewart, Robert -
Vicente Botet