[TypeTraits] is it possible to add something to boost.type_traits?
Dear boost implementers, TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used. Regards, F. Bron (See attached file: is_comparable.hpp) Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.
frederic.bron@alcan.com wrote:
Dear boost implementers, TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used.
This has come up often enough that I think this is an excellent idea: I'd be happy to help with macro usage and other details, but the most important thing is for some docs and tests to get written :-) It might also be useful to have a very quick mini-review of an addition like this so folks can check that the names are all sensible choices etc (I have a couple of minor additions that might benifit similarly). If it would help I could set up a directory in the sandbox to add all the changes to? Regards, John Maddock.
This has come up often enough that I think this is an excellent idea: I'd be happy to help with macro usage and other details, but the most important thing is for some docs and tests to get written :-)
OK, I obtained so much from boost that I agree to try to do the job my-self with some help. As I have never done this before, could you give me a procedure/formats to follow?
It might also be useful to have a very quick mini-review of an addition like this so folks can check that the names are all sensible choices etc (I have a couple of minor additions that might benifit similarly). If it would help I could set up a directory in the sandbox to add all the changes to?
Do you mean a directory in the svn structure? This would be great. Fred Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.
This has come up often enough that I think this is an excellent idea: I'd be happy to help with macro usage and other details, but the most important thing is for some docs and tests to get written :-)
I maybe interested to get some insights too on this matter as I have myself some traits like structure that may be useful.
frederic.bron@alcan.com wrote:
This has come up often enough that I think this is an excellent idea: I'd be happy to help with macro usage and other details, but the most important thing is for some docs and tests to get written :-)
OK, I obtained so much from boost that I agree to try to do the job my-self with some help. As I have never done this before, could you give me a procedure/formats to follow?
OK, first off there's an email invitaion to the Sandbox on it's way, once you're signed up then checkout using: svn co https://svn.boost.org/svn/boost/sandbox [local-path] and you'll find a copy of the type_traits lib under /type_traits/. I've already added the two traits I was working on to this, feel free to add yours as well. Procedure wise, if you can follow the existing structure that would be great: use one header per trait and one one .cpp file for each trait test etc. For these traits, can we boilerplate the whole thing so that defining a trait for any binary operator is just something like: #define BOOST_TT_TRAIT_NAME is_equality_comparible #define BOOST_TT_TRAIT_OP == #include <boost/type_traits/detail/binary_op_traits.hpp> ?? Maybe the same for the tests as well if they're very repetitive? With regard to macro usage, the easiest way is to define say for example boost::detail::is_equality_comparible_imp with a member "value" that is either true or false, and then add: BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_equality_comparible,T,::boost::detail::is_equality_comparible<T>::value) To take care of the MPL etc support. Docs require quickbook and xslt support, installation instructions here: http://www.boost.org/doc/libs/1_35_0/tools/quickbook/doc/html/quickbook/inst... Try making sure that you can build the existing docs, and then ping for help if you need it with the quickbook formatting: if you copy an existing traits class and modify that it should be fairly obvious I hope! HTH, John.
OK, first off there's an email invitaion to the Sandbox on it's way, once you're signed up then checkout using: svn co https://svn.boost.org/svn/boost/sandbox [local-path] and you'll find a copy of the type_traits lib under /type_traits/.
I have done this. I have added (yet only local) my file and a test file. How can I run the tests automatically?
Procedure wise, if you can follow the existing structure that would be great: use one header per trait and one one .cpp file for each trait test etc.
Are you sure one header for all comparison operators would not be better than one for each?
With regard to macro usage, the easiest way is to define say for example boost::detail::is_equality_comparible_imp with a member "value" that is either true or false, and then add:
BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_equality_comparible,T,::boost:: detail::is_equality_comparible<T>::value)
This works fine, thanks. F. Bron Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.
frederic.bron@alcan.com wrote:
OK, first off there's an email invitaion to the Sandbox on it's way, once you're signed up then checkout using: svn co https://svn.boost.org/svn/boost/sandbox [local-path] and you'll find a copy of the type_traits lib under /type_traits/.
I have done this. I have added (yet only local) my file and a test file. How can I run the tests automatically?
cd into /libs/type_traits/test/ and run: bjam mytoolset to build and run all the tests: no need to even add your new tests to the Jamfile, they should get picked up automatically :-) You will have to make sure that "mytoolset" has been configured in your user-config.jam, oh wait, since this is in the sandbox also make sure that the environment variable BOOST_ROOT points to a copy of the full boost tree as well.
Procedure wise, if you can follow the existing structure that would be great: use one header per trait and one one .cpp file for each trait test etc.
Are you sure one header for all comparison operators would not be better than one for each?
Honestly, I'm not sure :-( Normally we have one per trait, each with the same name as the trait, I'd rather stick with that unless there's good reason not to. HTH, John.
I am now ready to commit the binary operator traits and corresponding tests (I was able to run the tests automatically with bjam). I would like to commit the doc as well but I cannot use quickbook properly: I have a quickbook binary which seems to work (quickbook --help is fine) and I have added a user-config.jam file in the doc directory with the following line: using quickbook : /cygdrive/d/Softs/builds/boost_1_36_beta/dist/bin/quickbook ; but then I do not know how to generate the doc using bjam. I tried bjam in the sandbox/type_traits/libs/type_traits/doc directory but I obtain the following message: Unable to load Boost.Build: could not find "boost-build.jam" I have no such file in the doc directory. Regards, F. Bron
cd into /libs/type_traits/test/ and run:
bjam mytoolset
to build and run all the tests: no need to even add your new tests to the Jamfile, they should get picked up automatically :-)
You will have to make sure that "mytoolset" has been configured in your user-config.jam, oh wait, since this is in the sandbox also make sure that the environment variable BOOST_ROOT points to a copy of the full boost tree as well.
Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.
frederic.bron@alcan.com wrote:
Unable to load Boost.Build: could not find "boost-build.jam" I have no such file in the doc directory.
Set the environment variable BOOST_ROOT to point to the root directory of the regular full Boost tree and that should fix things. As an asside I'm not sure how well the documentation tools work under cygwin: it's possible you will get problems with \r\n's in files, if so try a full native Win32 toolchain. HTH, John.
I have already tried to set BOOST_ROOT but then bjam starts to build the full boost libraries... How can I say build only the documentation for the directory I am in? F. Bron boost-bounces@lists.boost.org a écrit sur 03/09/2008 13:07:10 :
frederic.bron@alcan.com wrote:
Unable to load Boost.Build: could not find "boost-build.jam" I have no such file in the doc directory.
Set the environment variable BOOST_ROOT to point to the root directory of the regular full Boost tree and that should fix things. As an asside I'm not sure how well the documentation tools work under cygwin: it's possible you will get problems with \r\n's in files, if so try a full native Win32 toolchain.
HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.
frederic.bron@alcan.com wrote:
I have already tried to set BOOST_ROOT but then bjam starts to build the full boost libraries... How can I say build only the documentation for the directory I am in?
Strange, I cd into sandbox/type_traits/libs/type_traits/doc and then: export BOOST_ROOT=../../../../../trunk bjam Builds just the type_traits docs. HTH, John.
frederic.bron@alcan.com wrote:
TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used.
What about the traits-based concept-like library someone was working on? It should allow that kind of checking easily.
frederic.bron@alcan.com wrote:
Dear boost implementers, TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used.
It would really be nice to have type_traits for all the possible user-defined operators. As part of that it seems that boost/detail/is_incrementable.hpp could be lifted from the boost::detail namespace and put into those new type_traits. I know you mentioned subsequently in another post that you are working on more of the operators but I do not know if you had decided to provide type_traits for all of the user-defined operators. If you had not decided to do all of them, I would like to encourage you to do so if you feel that the work to do them is not overwhelming. I will be glad to help test them out from within my own work since I am developing a template library in which I could use all of them.
It would really be nice to have type_traits for all the possible user-defined operators.
For the moment, I am working on <, <=, >, >=, ==, !=, +, -, *, /, %. The main difficulty is to treat operators that are not defined for built-in types as a specialization is to be provided in each case. For %, I have a very long list of exceptions. When you say all operators, do you mean &&, || and bitwise operators? Can you enumerate the operators you're thinking of? Frédéric
Frédéric Bron wrote:
It would really be nice to have type_traits for all the possible user-defined operators.
For the moment, I am working on <, <=, >, >=, ==, !=, +, -, *, /, %. The main difficulty is to treat operators that are not defined for built-in types as a specialization is to be provided in each case. For %, I have a very long list of exceptions. When you say all operators, do you mean &&, || and bitwise operators? Can you enumerate the operators you're thinking of?
The operators which can be user-defined as specified in the C++ standard. These are given in 13.5 1, as: new delete new[] delete[] + - * / % ˆ & | ˜ ! = < > += -= *= /= %= ˆ= &= |= << >> >>= <<= == != <= >= && || ++ -- , ->* -> () [] I personally don't need the first four for what I am working on, but it would be real nice if type_traits exrensions could discover whether any of the remaining ones are defined by the user for a particular T. If the technique of discovering a unary operator, as given in is_incrementable in boost::detail, is known then it seems like it should work for all the unary operators. Similarly if the technique can be expanded to a single binary operator, then it seems like it should work for all the binary operators. I do understand that one technique, as given by Eric Niebler, involves a creative use of the ',' operator through overloading, it so maybe the technique would have to be modified in discovering if the ',' operator itself is overloaded for a given T.
On Wed, Dec 16, 2009 at 5:58 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
Frédéric Bron wrote:
It would really be nice to have type_traits for all the possible user-defined operators.
For the moment, I am working on <, <=, >, >=, ==, !=, +, -, *, /, %. The main difficulty is to treat operators that are not defined for built-in types as a specialization is to be provided in each case. For %, I have a very long list of exceptions. When you say all operators, do you mean &&, || and bitwise operators? Can you enumerate the operators you're thinking of?
The operators which can be user-defined as specified in the C++ standard. These are given in 13.5 1, as:
new delete new[] delete[] + - * / % ˆ & | ˜ ! = < > += -= *= /= %= ˆ= &= |= << >> >>= <<= == != <= >= && || ++ -- , ->* -> () []
I personally don't need the first four for what I am working on, but it would be real nice if type_traits exrensions could discover whether any of the remaining ones are defined by the user for a particular T.
If the technique of discovering a unary operator, as given in is_incrementable in boost::detail, is known then it seems like it should work for all the unary operators. Similarly if the technique can be expanded to a single binary operator, then it seems like it should work for all the binary operators. I do understand that one technique, as given by Eric Niebler, involves a creative use of the ',' operator through overloading, it so maybe the technique would have to be modified in discovering if the ',' operator itself is overloaded for a given T.
I think, actually, if operator, is implemented for T, then the comma-operator-trick no longer works, and we can't figure out most/any of the other operators either. See http://cpp-next.com/archive/2009/10/this-week-in-boost/#more-746 Tony
AMDG Gottlob Frege wrote:
I think, actually, if operator, is implemented for T, then the comma-operator-trick no longer works, and we can't figure out most/any of the other operators either. See http://cpp-next.com/archive/2009/10/this-week-in-boost/#more-746
It still mostly works. There's only a problem if operator, returns void--and you can add as many calls to operator, as you want. There will only be an error if all the ones up to the last return non-void and the last one does return void. In Christ, Steven Watanabe
On 12/16/2009 09:03 PM, Steven Watanabe wrote:
Gottlob Frege wrote:
I think, actually, if operator, is implemented for T, then the comma-operator-trick no longer works, and we can't figure out most/any of the other operators either. See http://cpp-next.com/archive/2009/10/this-week-in-boost/#more-746
It still mostly works. There's only a problem if operator, returns void--and you can add as many calls to operator, as you want. There will only be an error if all the ones up to the last return non-void and the last one does return void.
It's going to be real fun for the poor slobs that run into that corner case. I sometimes get the sense that C++ folks (I include myself in that group) sometimes fail to see what sort of mess we are getting into by relying so much stuff that just "mostly works". So much of Boost MPL-driven stuff just "mostly works" and it can be a real pain to use. The compiler is certainly no help in sussing out the root cause when it doesn't. Rob
It would really be nice to have type_traits for all the possible user-defined operators.
The operators which can be user-defined as specified in the C++ standard. These are given in 13.5 1, as:
new delete new[] delete[] + - * / % ˆ & | ˜ ! = < > += -= *= /= %= ˆ= &= |= << >> >>= <<= == != <= >= && || ++ -- , ->* -> () []
I will stick to binary operators. Thus I leave the others to somebody else because I have been working on it for quite a long time now and would really like to see it in boost soon. Each time a feature is added, it takes very long to make everybody agree on the details which is very good because the resulting code is very high quality then. Also I have not enough time at the moment (and probably up to March 2010) as I am working on a large time consuming musical score project. Therefore if you want to start some work on unary operators, please feel free to do it. Cheers, Frédéric
Frédéric Bron wrote:
It would really be nice to have type_traits for all the possible user-defined operators.
The operators which can be user-defined as specified in the C++ standard. These are given in 13.5 1, as:
new delete new[] delete[] + - * / % ˆ & | ˜ ! = < > += -= *= /= %= ˆ= &= |= << >> >>= <<= == != <= >= && || ++ -- , ->* -> () []
I will stick to binary operators. Thus I leave the others to somebody else because I have been working on it for quite a long time now and would really like to see it in boost soon. Each time a feature is added, it takes very long to make everybody agree on the details which is very good because the resulting code is very high quality then. Also I have not enough time at the moment (and probably up to March 2010) as I am working on a large time consuming musical score project. Therefore if you want to start some work on unary operators, please feel free to do it. Cheers, Frédéric _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, I don't know if you know the Concept Traits library (https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conce...). This library defines operators traits for all the C++ operators. I don't know how your proposal is better then this library (aside this library is abandoned). HTH, Vicente -- View this message in context: http://old.nabble.com/-TypeTraits--is-it-possible-to-add-something-to-boost.... Sent from the Boost - Dev mailing list archive at Nabble.com.
I don't know if you know the Concept Traits library (https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conce...). This library defines operators traits for all the C++ operators.
I don't know how your proposal is better then this library (aside this library is abandoned).
Looks very similar but much more comprehensive! However the return type is not checked. Did you say this library is abandoned? What does this mean? I fair if I have to reimplement all what's in concept-traits library, it will be too much for me alone. Frédéric
Frédéric Bron wrote:
I don't know if you know the Concept Traits library (https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conce...). This library defines operators traits for all the C++ operators.
I don't know how your proposal is better then this library (aside this library is abandoned).
Looks very similar but much more comprehensive! However the return type is not checked. Did you say this library is abandoned? What does this mean?
The authors decided to not continue the development because at the time Concepts should be part of C++0x. AS now Concepts do not belong to C++0x, I have requested the resurrection of this library but no one was volunter.
I fair if I have to reimplement all what's in concept-traits library, it will be too much for me alone.
There is two part of the library that match yours (Operator Traits). http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_tr... http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_tr... The others corresponds to the definition of Concepts for STL. You can let this for others, but IMO it will be a shame to lose the work done in this library for Operator Traits. Best, Vicente -- View this message in context: http://old.nabble.com/-TypeTraits--is-it-possible-to-add-something-to-boost.... Sent from the Boost - Dev mailing list archive at Nabble.com.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Vicente Botet Escriba Sent: Thursday, December 17, 2009 12:48 PM To: boost@lists.boost.org Subject: Re: [boost] [TypeTraits] is it possible to add something to boost.type_traits?
Frédéric Bron wrote:
I don't know if you know the Concept Traits library (https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conce...). This library defines operators traits for all the C++ operators.
I don't know how your proposal is better then this library (aside this library is abandoned).
Looks very similar but much more comprehensive! However the return type is not checked. Did you say this library is abandoned? What does this mean?
The authors decided to not continue the development because at the time Concepts should be part of C++0x. AS now Concepts do not belong to C++0x, I have requested the resurrection of this library but no one was volunter.
I fair if I have to reimplement all what's in concept-traits library, it will be too much for me alone.
There is two part of the library that match yours (Operator Traits). http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_tr... raits_ext http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_tr... atorTraits
The others corresponds to the definition of Concepts for STL. You can let this for others, but IMO it will be a shame to lose the work done in this library for Operator Traits.
GSoC 2010 project? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Frédéric Bron wrote:
It would really be nice to have type_traits for all the possible user-defined operators. The operators which can be user-defined as specified in the C++ standard. These are given in 13.5 1, as:
new delete new[] delete[] + - * / % ˆ & | ˜ ! = < > += -= *= /= %= ˆ= &= |= << >> >>= <<= == != <= >= && || ++ -- , ->* -> () []
I will stick to binary operators. Thus I leave the others to somebody else because I have been working on it for quite a long time now and would really like to see it in boost soon. Each time a feature is added, it takes very long to make everybody agree on the details which is very good because the resulting code is very high quality then. Also I have not enough time at the moment (and probably up to March 2010) as I am working on a large time consuming musical score project. Therefore if you want to start some work on unary operators, please feel free to do it.
OK, thanks ! I will look at is_incrementable in boost::detail to see if I can understand it. The technique used there should theoretically scale to the other unary operators.
participants (11)
-
Edward Diener -
frederic.bron＠alcan.com -
Frédéric Bron -
Gottlob Frege -
joel falcou -
John Maddock -
Mathias Gaunard -
Paul A. Bristow -
Rob Riggs -
Steven Watanabe -
Vicente Botet Escriba