On Sun, Jul 17, 2011 at 10:05 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 7/16/2011 3:02 PM, Lorenzo Caminiti wrote:
12. [WANT] Are the metafunction MTFC macros really needed? The docs say they reduce compile-time (compared to using MPL placeholders) but no evidence is shown to support that...
Extra macros complicate the library API so if they are provided for reducing compile-time there should be some benchmarking showing their benefits. If not, these macros should be removed.
[NOTE] If these macros are shown to be beneficial, I'd rename them with a METAFUNC postfix because I find it more readable. For example:
HAS_TYPE_METAFUNC HAS_MEMBER_FUNCTION_METAFUNC
I supplied them merely as a convenience. In an early mailing list message about the TTI library from Dave Abrahams, before this review, he suggested that passing metafunctions as data as a metafunction class would generally be faster than passing them via placeholder expressions. I do not mind eliminating them if it seen as overkill.
If there is evidence (compile-time data and possibly some explanation) of that MTFC have faster compile-time, leave the macros. However, I thinks you either (1) measure the compile-times add the evidence in the docs or (2) you remove the MTFC macros.
Having the MTFC macros does not hurt anything. There is no reason to not supply them purely as a convenience.
As a user of your library, how would I decide if I should use MTFC or not? The docs say MTFC might be faster but the docs don't say of how much, for which compiler, etc. Please keep your users in mind, if you provide the MTFC functionality to your users, you need to provide them also with all the information they need to make the informed decision of when to use such functionality or not.
13. [WANT] Are the nullary metafunctions really needed?
Functionally, no, which the documentation explicitly explains. Syntactically I feel they are much easier to use once they are understood.
The docs say they simplify the syntax but no side-by-side example comparing the syntax with and without the nullary type metafunctiosn is provided...
Unless their benefit is clearly shown, the nullary metafunctions should be remove to simplify the library API.
I will add side by side examples showing the simpler syntax of using the nullary metafunctions. I do show the different syntaxes for similar situations in the doc, but not side by side.
Can you please reply to this email with a short example that compares the two syntaxes so we can all take a look at it?
Why not just ignore them if you do not like their syntax ? After all tghey
Because as a new user of your library I think "are they important?", "shall I learn them?", "do I need/want their simpler syntax?". So if they really offer a benefit (even just syntactical), they should be there, just illustrate their benefit better.
There are sections in the doc about "Nullary Type Metafunctions" and "Using the Nullary Type Metafunctions". I will work on expanding the documentation in these sections, perhaps adding some more sections, so that others understand the syntactical advantage of using the nullary metafunctions if they want to do so.
Again, can you please reply to this email with a short example that compares the two syntaxes so we can all (i.e., all Boosters) take a look at it?
22. [WANT] I'd add an annex to the docs to compare this library with other libraries (e.g., the "mirror" library?) that exist out there for introspection (i.e., some sort of literature review).
if there were an existing Boost library I might do it.
Why would you compare Boost.TTI only with other Boost libraries? You should do a literature search on C++ introspection in general and compare Boost.TTI with *all* known C++ introspection library even/especially if they are not in Boost.
I disagree with you. It is not the responsibility of a library developer to investigate and document every other possibile similar library. I can understand that if there were a C++ standard library or a Boost library which offered similar features to what another Boost library is attempting to provide, then it would be good for the developer to compare his library to what is already exists in that domain to illustrate the advantages and disadvantages of one's own approach.
What do other Boosters think of this?
I would also comment on possible C++ standard extensions or compiler specific support for introspection.
Which C++ standard ( 2003 or C++0x ) ? For the latter I still have much to learn since it is so new.
Both standards 2003 and C++0x. Plus you should look at compiler-specific extensions (maybe Clang has some introspection feature??). For example, SFINAE *might* allow to detect the private trait in C++0x but not in C++03 (I don't really know but a Boost introspection library should know and document that).
Again, the idea for this "comparison" annex is to be as complete as possible (like a literature search when you write an academic paper). This might not change your library functionality at all but it will clearly position the features offered by your library with respect to what can be done (or will be possible) with C++ introspection and it will benefit your library users so they will know if a trait they are interested in introspecting can or not be introspected in C++.
I can see this, but I really know little, except for extended SFINAE in C++0x, which could be mentioned. I will mention that in my docs. if there are any other features, even compiler specific features, which aid in the introspection of inner elements, I would be glad to be informed about them and use them.
A Boost library is not an academic paper, and I have the greatest respect for academic scholarship. There is just so much information that the library developer should be expected to present to the end-user.
What do other Boosters think also of this? Thanks, --Lorenzo