TTI library updated in the sandbox
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.
Couple o' things: On Sun, Feb 6, 2011 at 12:39 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
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.
Orthogonality in what sense? Duplicating functionality seems like the opposite of orthogonality. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Edward Diener-3 wrote:
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 -- View this message in context: http://boost.2283326.n4.nabble.com/TTI-library-updated-in-the-sandbox-tp3262... Sent from the Boost - Dev mailing list archive at Nabble.com.
Edward Diener-3 wrote:
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) -- View this message in context: http://boost.2283326.n4.nabble.com/TTI-library-updated-in-the-sandbox-tp3262... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 2/8/2011 5:47 PM, Vicente Botet wrote:
That would be great. Feedback is always welcome.
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.
Edward Diener-3 wrote:
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 -- View this message in context: http://boost.2283326.n4.nabble.com/TTI-library-updated-in-the-sandbox-tp3262... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 2/10/2011 10:37 AM, Vicente Botet wrote:
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 ?
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.
On 2/10/2011 11:51 AM, John Maddock wrote:
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.
participants (4)
-
Dave Abrahams -
Edward Diener -
John Maddock -
Vicente Botet