Boost logo

Boost :

Subject: [boost] [TTI] Review
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-07-18 01:07:48

Are you knowledgeable about the problem domain?

I have done some metaprogramming and made some use of SFINAE, but my knowledge of the program domain is not extensive.

How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

I have glanced over the documentation a few times over the last few days in order to give myself a chance to ponder it subconsciously, but I have probably only spent about an hour or two in total actively examining and thinking about the library, plus about an hour writing this review.

Do you think the library should be accepted as a Boost library?

I would say yes from what I have seen and understand about the library, but based on my relative lack of knowledge in the program domain and the relatively small amount of time I have spent looking at the library my vote should be weighted accordingly.

What is your evaluation of the design?

1) I agree with others that it makes more sense to inject the metafunctions at the current scope rather at the absolute scope boost::tti.

2) I strongly think that "CREATE_METAFUNCTION_FOR" (or something similar) should be inserted into all of the macro names because otherwise they strike me as being misleading. If I were not familiar with this library and I saw the macro BOOST_TTI_HAS_TYPE(X) in someone else's code, I would be confused because the name of the macro makes it sound like it is asking if X has some type even though the result doesn't seem to be used. By contrast, if I saw the macro BOOST_TTI_CREATE_METAFUNCTION_FOR_HAS_TYPE(X), it would be immediately clear to me that the purpose of this macro is to create a metafunction.

I say this based in part on my own experience. When I was learning how this library worked I started by skimming through the documentation to get a feel for what was going on, and the macro names confused me because I couldn't tell what they were actually doing. I did eventually figure this out when I read through the documentation more closely, but if they had names following the convention I am recommending then I would have immediately understood what they were doing.

Although my proposed change would require additional typing (though unlikely not much, since I suspect most people are like me and just copy and paste from a template), I think that the benefit of improving the clarity would be well worth it.

3) I wonder if it would be better to instead of giving the metafunctions names such as has_type_X, it would make more sense to put them in their own namespace so they they would be referred to as for example has_type::X. This would save use from having to use macro pasting to compute the metafunction names, and would also have the advantage of addressing Lorenzo's concern that a double-underscore might inadvertently be put in a type name. However, I do not have enough experience here to get a full sense of the design implications of choosing this convention over the current convention.

Another possibility is to hide the actual name of the metafunction by using a macro to access it. If my recommendation to insert "CREATE_METAFUNCTION_FOR" in all of the macro names is followed, it would free up the current macro names to be used to refer to the metafunction. That is, rather than code looking like


it would look like


which would have the advantage of hiding the exact name and location of the metafunction as an implementation detail.

To be clear, point #3 is just me pondering other possibilities to invite discussion, and should not be considered a necessary change that needs to be made.

What is your evaluation of the implementation?

I glanced at the code and it looked reasonable on the surface but I am not an expert in metaprogramming so I did not look at it closely.

What is your evaluation of the documentation?

As others have pointed out, the documentation desperately needs more examples. In particular, unless I missed something I do not believe that there are any examples of actually using the library to accomplish something; all of the examples only show which macros should be used to create the metafunctions and what the resulting metafunction is called. In no example did I see an example where the metafunction was actually applied to accomplish something, such as disabling a function using SFINAE.

I suspect that the author assumed that such in-depth examples would not be necessary since anyone reading the documentation would probably be very experienced with metaprogramming and so would already know what to do once they had the introspection metafunctions available to them, but not everyone thinking about using this library will be so experienced at metaprogramming (myself being one member of this ignorant group) and so some examples of how the library could be used to accomplish goals would be incredibly useful to us so that we could get a better sense of exactly how this library works and how we can leverage it to solve practical problems.

What is your evaluation of the potential usefulness of the library?

It seems like this library could be incredibly useful to those who need introspection functionality, but since I do not generally do the type of metaprogramming that this library facilitates this should be considered as just my speculation.

Did you try to use the library? With what compiler? Did you have any problem?

I played with it a little bit and compiled a random selection of the examples successfully.

I used gcc version 4.2.1 on OSX.


Boost list run by bdawes at, gregod at, cpdaniel at, john at