On 3/23/2011 8:25 PM, Steven Watanabe wrote:
AMDG
On 03/23/2011 04:10 PM, Edward Diener wrote:
I will be doing that. Unfortunately except for you and John Maddock no one else has ever expressed an interest in TTI.
Well, let me express interest too.
It is very much appreciated. Feel free to look at it and critiqued it if you like and I will gladly listen and explain my decisions.
Maybe that sort of metaprogramming is only of interest to other metaprogrammers and not normal end-users.
That's probably true. I don't need functionality like this often, but when I do need it, it's really important. The most common use case for me is to preserve backwards compatibility when concept requirments change. (For instance, BOOST_MPL_HAS_TEMPLATE_XXX was critical for implementing result_of support in Boost.Lambda.)
The idea of the library is to provide this sort of compile-time introspection for as many nested elements as could be effectively done. I did not succeed for nested function templates but the doc explains why. I did lift the BOOST_MPL_HAS_TEMPLATE_XXX into TTI under another ( I think more user-friendly ) name into TTI. All other elements have a way of being introspected and I did add to my use of BOOST_MPL_HAS_TEMPLATE_XXX more functionality which introspects a specific class template signature, if that would ever be needed. Much of the techniques were borrowed but I think I did a good job of overall design, although it took me a few iterations/releases to settle on the final ways of doing everything. I would like to have it reviewed although I am also working to get VMD into Boost, either as standalone or as part of pp-lib. Since TTI depends optionally on some very small part of VMD, I am trying to get VMD reviewed before TTI. But I know there is precedent for reviewing a library even when it depends on another library which has not been reviewed/accepted into Boost yet. In the case of TTI, I can easily add the VMD functionality which it uses directly into the library if VMD in some form does not get into Boost.