Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-05-20 16:59:37


Here is a repost of my review because the subject of the original post wasn't
conforming to the guidelines 8-)

--- original message ---

> What is your evaluation of the design?

Not much to say about the (typeof-) client interface, as these are basically
macro-ized keywords of a language extension (in case of 'auto' even language
history).

I don't like the '_TPL' suffix - I'ld prefer 'TEMPLATED' to be spelled out.

Making libraries work with Boost.Typeof implies collecting a lot of information
about types and templates which could be useful in other places as well:
For example it would be possible to collect the names as well (and require them
to be fully qualified) to allow an efficient "compile time type info" facility
to be built upon it. There might be more interesting ideas in this direction
(and that's the primary reason for me to mention it here).

In the registration interface there is no way to get rid of the one #include per
file, so I would prefer a table passed as "named external argument" for the
registration data:

     #define BOOST_TYPEOF_REGISTRATION <table>
     #include BOOST_TYPEOF_REGISTER()

This allows to hide the "registration group issue" from the user and enforces
proper handling. Even better: it allows to completely get rid of it (well, in
some sense) and use a "dense index space" instead, which in turn allows a more
efficient encoding. A downside is, that it's no longer possible to invoke a
registration from within another macro (which is ugly but maybe practical).
It also would allow "vertical repetition constructs" to be used, which do
improve diagnostics both for tracking down typos of the client and for the
maintainer. However, I am not too sure about this part of the suggestion,
because it is likely to cost some preprocessing time.

> What is your evaluation of the implementation?

 From what I have seen, the implementation seems well structured and even reads
good (and it's really easy for things to look messy when there is a lot of
preprocessor code around).

> What is your evaluation of the documentation?

The documentation works for me and I'm not too ambitios about it because the
usage is straightforward. The page title (<TITLE>Contents</TITLE>) could be a
bit more expressive, I guess ;-).

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

Very useful, as the language currently lacks a way to transport a type from
expression scope to class scope.

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

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

I have looked into it once in a while throughout its evolution and recently
started actually using it.

I didn't have any problems with my primary compilers, which are among the
officially supported ones and did some testing on my secondary computer (running
linux) while writing this review:

All tests failed with Intel 7.0 and Intel 8.1 ("no instance of function template
boost::type_of::at matches the argument list * - in BOOST_TYPEOF_TPL").

> Are you knowledgeable about the problem domain?

A bit - I once implemented a minimalist typeof emulator (it's only capable of
handling type template parameters and requires a class to be defined to "do the
actual typeof thing", though).

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

Yes, I do.

Regards,

Tobias


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk