TTI library updated in the sandbox

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

TTI library updated in the sandbox

Edward Diener-3
I have updated the TTI library in the sandbox 'tti' directory to version
1.1. The TTI library, which is an abbreviation for the 'Type Traits
Introspection' library, allows a programmer to introspect at compile
time the inner elements of a C++ type. The introspection process depends
on specifying the name of the inner element by different macros for
different types of elements, and then using a generated metafunction to
determine whether that element exists within the enclosing type. The
inner elements which can be introspected are type, class template,
member data, member function, static member data, and static member
function.

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.

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.

The purpose of the library is to provide a consistent set of interfaces
for doing compile-time introspection of a type, which other template
metaprogrammers can use in their code. If you are at all interested in
compile-time introspection of types, please take a look at the
functionality of this library.

There is a readme.txt in the top-level sandbox tti directory, for anyone
browsing the sandbox for interesting libraries, which basically
replicates what is written here.

There is a build.txt file in the doc subdirectory for building the
documentation and running the tests. The documentation is also included
as part of the sandbox files for those who can not build the docs.

The library has been tested and works with gcc 3.4.2, 3.4.5, 4.3.0,
4.4.0, 4.5.0-1, 4.5.2-1 and VC++ 8.0, 9.0, 10.0. It may also work with
other compilers.

Questions, comments, suggestions, and bug reports are all welcome.

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

Re: TTI library updated in the sandbox

Dave Abrahams
Couple o' things:

On Sun, Feb 6, 2011 at 12:39 PM, Edward Diener <[hidden email]> 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.

> 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.


--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost-users] TTI library updated in the sandbox

Dave Abrahams
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<[hidden email]>  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

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

Re: [Boost-users] TTI library updated in the sandbox

Edward Diener-3
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<[hidden email]>   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.

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

Re: TTI library updated in the sandbox

Vicente Botet
In reply to this post by Edward Diener-3
Edward Diener-3 wrote
I have updated the TTI library in the sandbox 'tti' directory to version

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.

Questions, comments, suggestions, and bug reports are all welcome.
Hi,

excellent news. This would be a good complement to the type traits operators extension under the review schedule.

I will try to give you some comments soon.

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

Re: TTI library updated in the sandbox

Edward Diener-3
On 2/8/2011 12:24 PM, Vicente Botet wrote:

>
>
> Edward Diener-3 wrote:
>>
>> I have updated the TTI library in the sandbox 'tti' directory to version
>>
>> 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.
>>
>> Questions, comments, suggestions, and bug reports are all welcome.
>>
>>
>
> Hi,
>
> excellent news. This would be a good complement to the type traits operators
> extension under the review schedule.
>
> I will try to give you some comments soon.

Thanks ! I would love for you to use the library and tell me what you
think of it.



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

Re: TTI library updated in the sandbox

Vicente Botet
Edward Diener-3 wrote
On 2/8/2011 12:24 PM, Vicente Botet wrote:
>
>
> Edward Diener-3 wrote:
>>
>> I have updated the TTI library in the sandbox 'tti' directory to version
>>
>> 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.
>>
>> Questions, comments, suggestions, and bug reports are all welcome.
>>
>>
>
> Hi,
>
> excellent news. This would be a good complement to the type traits operators
> extension under the review schedule.
>
> I will try to give you some comments soon.

Thanks ! I would love for you to use the library and tell me what you
think of it.
I have installed it and run the test on cygwin-gcc and migw-gcc. Every think is OK, including the VM usage.

I will try to write some basic examples myself before commenting the documentation and the Nullary Type Metafunctions.

Best,
Vicente

P.S. I would prefer that the library uses already standard Boost conventions for filenames, macros and namespaces (boost::tti)
Reply | Threaded
Open this post in threaded view
|

Re: TTI library updated in the sandbox

Edward Diener-3
On 2/8/2011 5:47 PM, Vicente Botet wrote:

>
>
> Edward Diener-3 wrote:
>>
>> On 2/8/2011 12:24 PM, Vicente Botet wrote:
>>>
>>>
>>> Edward Diener-3 wrote:
>>>>
>>>> I have updated the TTI library in the sandbox 'tti' directory to version
>>>>
>>>> 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.
>>>>
>>>> Questions, comments, suggestions, and bug reports are all welcome.
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> excellent news. This would be a good complement to the type traits
>>> operators
>>> extension under the review schedule.
>>>
>>> I will try to give you some comments soon.
>>
>> Thanks ! I would love for you to use the library and tell me what you
>> think of it.
>>
>>
>
> I have installed it and run the test on cygwin-gcc and migw-gcc. Every think
> is OK, including the VM usage.
>
> I will try to write some basic examples myself before commenting the
> documentation and the Nullary Type Metafunctions.

That would be great. Feedback is always welcome.

>
> Best,
> Vicente
>
> P.S. I would prefer that the library uses already standard Boost conventions
> for filenames, macros and namespaces (boost::tti)

I have held off putting anything into the Boost namespace or prepending
BOOST_ to macro names until that time when the library would be reviewed
for inclusion into Boost.

As far as filenames are concerned, I am not aware of any Boost
conventions which apply.

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

Re: TTI library updated in the sandbox

Vicente Botet
Edward Diener-3 wrote
On 2/8/2011 5:47 PM, Vicente Botet wrote:
>
>
> Edward Diener-3 wrote:
> P.S. I would prefer that the library uses already standard Boost conventions
> for filenames, macros and namespaces (boost::tti)

I have held off putting anything into the Boost namespace or prepending
BOOST_ to macro names until that time when the library would be reviewed
for inclusion into Boost.
The problem is if I use your library, which I expect will be accepted soon, for another library I'm preparing for Boost, I will need to change the interface at least for the macros when the library will be accepted. This will not be a big work, but if it can be avoided ...

As far as filenames are concerned, I am not aware of any Boost
conventions which apply.
Please take a look at http://www.boost.org/development/requirements.html

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

Re: TTI library updated in the sandbox

Edward Diener-3
On 2/10/2011 10:37 AM, Vicente Botet wrote:

>
>
> Edward Diener-3 wrote:
>>
>> On 2/8/2011 5:47 PM, Vicente Botet wrote:
>>>
>>>
>>> Edward Diener-3 wrote:
>>> P.S. I would prefer that the library uses already standard Boost
>>> conventions
>>> for filenames, macros and namespaces (boost::tti)
>>
>> I have held off putting anything into the Boost namespace or prepending
>> BOOST_ to macro names until that time when the library would be reviewed
>> for inclusion into Boost.
>>
>
> The problem is if I use your library, which I expect will be accepted soon,
> for another library I'm preparing for Boost, I will need to change the
> interface at least for the macros when the library will be accepted. This
> will not be a big work, but if it can be avoided ...

I am glad you feel my library will be accepted soon. It is encouraging
to hear. I will ask for a review as soon as I feel it is complete. In
that case, however, I need to first ask for a review of my
variadic_macro_data library, which is complete, since the TTI library
depends on the variadic_macro_data library if one chooses to use the
variadic macros in TTI.

I do understand that using Boost in the namespace names and macros makes
it easier for a dependent library, but I always thought that one should
not do this until a library is accepted. Perhaps I am wrong about that,
in which case I can easily change things. Is there any official Boost
policy about whether a potential Boost library should use boost:: as a
top-level namespace and BOOST_ as a macro preface before the library
becomes part of Boost itself ?

>
>
>
>> As far as filenames are concerned, I am not aware of any Boost
>> conventions which apply.
>>
>
> Please take a look at http://www.boost.org/development/requirements.html

I will change the header names to all lower case and separate the parts
of the names with an underscore ( _ ) in the next release of TTI. Thanks
for alerting me to this.

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

Re: TTI library updated in the sandbox

John Maddock-3
> I do understand that using Boost in the namespace names and macros makes
> it easier for a dependent library, but I always thought that one should
> not do this until a library is accepted. Perhaps I am wrong about that, in
> which case I can easily change things. Is there any official Boost policy
> about whether a potential Boost library should use boost:: as a top-level
> namespace and BOOST_ as a macro preface before the library becomes part of
> Boost itself ?

I don't think there's an official policy, although it's common for
submissions to come packaged with all the right namespaces and macro-names
etc.

HTH, John.

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

Re: TTI library updated in the sandbox

Edward Diener-3
On 2/10/2011 11:51 AM, John Maddock wrote:

>> I do understand that using Boost in the namespace names and macros
>> makes it easier for a dependent library, but I always thought that one
>> should not do this until a library is accepted. Perhaps I am wrong
>> about that, in which case I can easily change things. Is there any
>> official Boost policy about whether a potential Boost library should
>> use boost:: as a top-level namespace and BOOST_ as a macro preface
>> before the library becomes part of Boost itself ?
>
> I don't think there's an official policy, although it's common for
> submissions to come packaged with all the right namespaces and
> macro-names etc.

OK, I will change my libraries in the sandbox to use boost guidelines
regarding filenames, boost:: as the top-level namespace name, and BOOST_
starting any macro names for their next release. I had been hesitant to
do this as I thought it would be seen as developers intruding on Boost
standards for libraries which are not yet part of Boost. But as long as
it is acceptable and encouraged there is no reason not to do it
especially as other developers may want to use those libraries.

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