Re: [boost] [Boost-users] TTI library updated in the sandbox
At Sun, 06 Feb 2011 17:44:02 -0500, Edward Diener wrote:
On 2/6/2011 4:14 PM, Dave Abrahams wrote:
Couple o' things:
On Sun, Feb 6, 2011 at 12:39 PM, Edward Diener<eldiener@tropicsoft.com> wrote:
Features of the update include support for the older gcc 3.4.2 and 3.4.5, finer-grained introspection for the basic macro metafunctions, documentation examples, better and tighter design, and better use of Boost MPL methodology ( metafunctions are now passed as lambda expressions and metafunction globbing has been removed from the two metafunctions where it previously existed ). You can view the changes in the History section of the documentation.
FWIW, passing lambda expressions instead of metafunction classes is a trade-off: it's more expressive, but will lengthen compile times. For the implementation of a boost library, it's probably better to err on the side of speed.
I could create metafunction classes for use instead of having the end-user use placeholder expressions. Is that what you are suggesting for better compiler speed ? It should be easy enough to do. I was influenced by your MPL book and how easy it is for the end-user to use placeholder expressions.
Maybe I misunderstood you. I took you to be saying that you were using placeholder expressions in the library's implementation. Supporting the user who wants to pass placeholder expressions is a good idea. Using metafunction classes in your library's implementation is also a good idea.
The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also lifts functionality, for the purposes of orthogonality, from Boost.MPL regarding introspection of types and templates.
Orthogonality in what sense? Duplicating functionality seems like the opposite of orthogonality.
I am certainly willing and comfortable removing from the TTI library the TTI_HAS_TYPE and TTI_HAS_TEMPLATE metafunction macros, which just duplicates the functionality of the corresponding BOOST_MPL_HAS_XXX_TRAIT_DEF and BOOST_MPL_HAS_XXX_TEMPLATE_DEF respectively. But let me first argue for why I included them
I don't have any argument with the choice to include them.
and what I mean when I say orthogonality:
1) The functionality is complete in a single library for what the library wishes to do. In this case it is to introspect the inner elements of a type. I have functionality to introspect member data and functions and static data and functions, and some new functionality to introspect types ( checking for the actual type ) and class templates ( specifying the exact template parameters ), so it seemed natural for me that I should just as well also provide functionality in general for types and templates, even if it was to provide the exact same functionality which is in Boost MPL. This is more a situation of completeness than orthogonality, but I felt that providing all of the functionality the library promises was more important than duplicating the MPL functionality. And of course the duplication code-wise is just minimal since I am not recreating the macros which constitute BOOST_MPL_HAS_XXX_TRAIT_DEF and BOOST_MPL_HAS_XXX_TEMPLATE_DEF but just using the MPL macros internally and delegating to their already existing functionality.
2) For the nullary type metafunctions in my library I have corresponding type and template functionality, to be used where the types are nullary metafunctions. It would have felt odd, in the sense of the nullary type metafunctions being orthogonal in functionality to the macro metafunctions, not to also have the same type and template functionality in the macro metafunctions.
3) I wanted the naming I used to be consistent with the other names in the library. So instead of BOOST_MPL_HAS_XXX_TEMPLATE_DEF I have TTI_HAS_TEMPLATE, instead of BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF I have TTI_TRAIT_HAS_TEMPLATE, instead of BOOST_MPL_HAS_XXX_TRAIT_DEF I have TTI_HAS_TYPE and instead of BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF I have TTI_TRAIT_HAS_TYPE. This sort of ease of use, because the naming is consistent, is important to me when I think about design for an end-user. Of course the documentation can tell the end-user to use the already existing MPL macros to get type and template introspection instead of providing my own set that does the exact same thing and just reuses the MPL functionality. But I felt it more natural to provide my own.
I hope you know that there is no attempt being made to create the TTI_HAS_TYPE and TTI_HAS_TEMPLATE metafunction macros without acknowledging that I am just lifting this from the MPL library. It is in the description when I post on this NG and it is in the documentation in the Acknowledgments section. I would be glad to put it anywhere else. At the same time I can remove it easily enough from the TTI library but I think in that case it would be less complete as a compile-time introspection library if I did.
Sorry, that part was tl;dr'd. I'm just pointing out that using the term "orthogonal" doesn't make much sense on the surface here, and if it requires that much explanation to get it to make sense, maybe you should choose a different word. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 2/6/2011 7:21 PM, Dave Abrahams wrote:
At Sun, 06 Feb 2011 17:44:02 -0500, Edward Diener wrote:
On 2/6/2011 4:14 PM, Dave Abrahams wrote:
Couple o' things:
On Sun, Feb 6, 2011 at 12:39 PM, Edward Diener<eldiener@tropicsoft.com> wrote:
Features of the update include support for the older gcc 3.4.2 and 3.4.5, finer-grained introspection for the basic macro metafunctions, documentation examples, better and tighter design, and better use of Boost MPL methodology ( metafunctions are now passed as lambda expressions and metafunction globbing has been removed from the two metafunctions where it previously existed ). You can view the changes in the History section of the documentation.
FWIW, passing lambda expressions instead of metafunction classes is a trade-off: it's more expressive, but will lengthen compile times. For the implementation of a boost library, it's probably better to err on the side of speed.
I could create metafunction classes for use instead of having the end-user use placeholder expressions. Is that what you are suggesting for better compiler speed ? It should be easy enough to do. I was influenced by your MPL book and how easy it is for the end-user to use placeholder expressions.
Maybe I misunderstood you. I took you to be saying that you were using placeholder expressions in the library's implementation. Supporting the user who wants to pass placeholder expressions is a good idea. Using metafunction classes in your library's implementation is also a good idea.
Above in my blurb for the library I am writing "lambda expressions", which can support an end-user who uses either a placeholder expression or a metafunction class ? Maybe you read it too fast and assumed just "placeholder expressions" instead. I do not generate a metafunction class for each of the metafunction macros but your comment made me realize that I can easily do so. In that way an end-user can either use a placeholder expression or a generated metafunction class to pass the macro metafunctions around. Of course anyone is free to create their own metafunction class also.
The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also lifts functionality, for the purposes of orthogonality, from Boost.MPL regarding introspection of types and templates.
Orthogonality in what sense? Duplicating functionality seems like the opposite of orthogonality.
I am certainly willing and comfortable removing from the TTI library the TTI_HAS_TYPE and TTI_HAS_TEMPLATE metafunction macros, which just duplicates the functionality of the corresponding BOOST_MPL_HAS_XXX_TRAIT_DEF and BOOST_MPL_HAS_XXX_TEMPLATE_DEF respectively. But let me first argue for why I included them
I don't have any argument with the choice to include them.
and what I mean when I say orthogonality:
1) The functionality is complete in a single library for what the library wishes to do. In this case it is to introspect the inner elements of a type. I have functionality to introspect member data and functions and static data and functions, and some new functionality to introspect types ( checking for the actual type ) and class templates ( specifying the exact template parameters ), so it seemed natural for me that I should just as well also provide functionality in general for types and templates, even if it was to provide the exact same functionality which is in Boost MPL. This is more a situation of completeness than orthogonality, but I felt that providing all of the functionality the library promises was more important than duplicating the MPL functionality. And of course the duplication code-wise is just minimal since I am not recreating the macros which constitute BOOST_MPL_HAS_XXX_TRAIT_DEF and BOOST_MPL_HAS_XXX_TEMPLATE_DEF but just using the MPL macros internally and delegating to their already existing functionality.
2) For the nullary type metafunctions in my library I have corresponding type and template functionality, to be used where the types are nullary metafunctions. It would have felt odd, in the sense of the nullary type metafunctions being orthogonal in functionality to the macro metafunctions, not to also have the same type and template functionality in the macro metafunctions.
3) I wanted the naming I used to be consistent with the other names in the library. So instead of BOOST_MPL_HAS_XXX_TEMPLATE_DEF I have TTI_HAS_TEMPLATE, instead of BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF I have TTI_TRAIT_HAS_TEMPLATE, instead of BOOST_MPL_HAS_XXX_TRAIT_DEF I have TTI_HAS_TYPE and instead of BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF I have TTI_TRAIT_HAS_TYPE. This sort of ease of use, because the naming is consistent, is important to me when I think about design for an end-user. Of course the documentation can tell the end-user to use the already existing MPL macros to get type and template introspection instead of providing my own set that does the exact same thing and just reuses the MPL functionality. But I felt it more natural to provide my own.
I hope you know that there is no attempt being made to create the TTI_HAS_TYPE and TTI_HAS_TEMPLATE metafunction macros without acknowledging that I am just lifting this from the MPL library. It is in the description when I post on this NG and it is in the documentation in the Acknowledgments section. I would be glad to put it anywhere else. At the same time I can remove it easily enough from the TTI library but I think in that case it would be less complete as a compile-time introspection library if I did.
Sorry, that part was tl;dr'd. I'm just pointing out that using the term "orthogonal" doesn't make much sense on the surface here, and if it requires that much explanation to get it to make sense, maybe you should choose a different word.
OK. Perhaps I should write "for the purpose of completeness" instead. Orthogonality, as in 2) above, was one part of why I chose to include them.
participants (2)
-
Dave Abrahams -
Edward Diener