[boost] [Review] Boost.Type Traits Extension by Frederic Bron

Subject: [boost] [Review] Boost.Type Traits Extension by Frederic Bron
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-03-15 19:47:07

This is my review of the Boost Type Traits Extension by Frederick Brron.

     * What is your evaluation of the design?

The design is very straightforward, and easy to use. Although I do not 
anticipate the need to check the return from the operator traits I am 
glad that is part of the library.

The only suggestion I would like to make regarding the design is in the 
default argument for the return value, which tells the implementation 
not to check for the return value. While it is wildly improbable that 
any user of the operator traits would actually want to have a trait 
whose return is actually 'void', it is still theoretically possible. 
Therefore I think that the default for the return value, which means to 
not check for the return value, should be an unspecified marker type in 
the type_traits::detail namespace. It is a convention of all Boost 
libraries that any library's detail namespace is to be used only by the 
implementation of that library and not by a user of that library. So 
using an unspecified marker type in the type traits detail namespace 
should be fine.

     * What is your evaluation of the implementation?

I did not look at the source code.

I do have a large reservation from reading the documentation, so let me 
explain it now.

The ideal situation when using template metaprogramming constructs, such 
as the type traits operators metafunctions, is that an instantiation of 
the metafunction should never produce a compiler error. This is 
particularly true of metafunctions which return a boolean constant 
value, since the boolean value can encapsulate the notion of true or 
false when using the metafunction based on input types. Of course it may 
be the nature of C++ that this ideal situation can not be met. But then 
the user of the metafunction has to be able to instruct his end-users 
about whatever limitation exists and make allowance for it.

In the type traits operators library there are documented two major 
situations where the use of a type will produce a compiler error and not 
just a false boolean constant value. This is a painful situation. I 
realize these two situations are fully documented in the "Known Issues" 
area of the Operator Type Traits documentation.

But now let us take a look at the template metaprogrammer who wishes to 
use some subset of the type traits operators in his own library based on 
a type his end-user may pass to him. What this programmer wishes to do 
is to use a type traits operator if a type passed to him supports it, 
otherwise not use the operator at all. Unfortunately the end-user of 
that library passes a type which may or may not support such 
functionality, not knowing that the type will trigger a compiler error 
because the type traits operators are being used internally and some 
known issues exist which that type encompasses.

What that template metaprogrammer must then do is to add another 
template parameter to his template, and documentation which explains to 
his end-user the specific situations whch trigger compiler errors in the 
type traits operators, that if a type is being passed which could cause 
the type traits compiler error conditions he must set this other 
parameter to false so that the compiler error can be avoided. This is a 
difficult way to program metafunctions successfully. So it is very 
disappointing that these "Known Issues" exist and it would be very 
worthwhile if a way could be found around them, by something different 
in the internal implementation, if that were possible.

     * What is your evaluation of the documentation?

The documentation is thorough and complete.

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

I think it is very useful.

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

Tested with VC 8,9,10 and everything worked as expected. I have also 
integrated into another library on which I am working and that was 
successful also.

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

I read the docs, tested the library under Windows, and tried it in my 
own library, so it was pretty thorough.

     * Are you knowledgeable about the problem domain?

Yes.

And finally, every review should answer this question:

     * Do you think the library should be accepted as a Boost library? 
Be sure to say this explicitly so that your other comments don't obscure 
your overall opinion.

I vote for the library to be accepted into Boost. I would also like to 
see if the "Known Issues" could not be solved, not necessarily by the 
author of the library who has put so much effort and work into it, but 
possibly by other Boost experts who might find some solution to these 
issues which mar the library somewhat for me. But even if these issues 
could never be solved the library is worthwhile enough to be accepted.

Edward Diener