Other considerations and tips

Native typeof support and emulation

Many compilers support typeof already, most noticeable GCC and Metrowerks.

Igor Chesnokov discovered a method that allows to implement typeof on the VC series of compilers. It
uses a bug in the Microsoft compiler that allows a nested class of base to
be defined in a class derived from base:

Peder Holt adapted this method to VC7.0, where the nested class is a template
class that is specialized in the derived class.

In VC8.0, it seemed that all the bug-featire had been fixed, but Steven Watanabe
managed to implement a more rigorous version of the VC7.0 fix that enables
'typeof' to be supported 'natively' here as well.

For many other compilers neither native typeof
support nor the trick described above is an option. For such compilers the
emulation method is the only way of implementing typeof.

According to a rough estimate, at the time of this writing the introduction
of the typeof, auto, etc., into the C++ standard may not
happen soon. Even after it's done, some time still has to pass before most
compilers implement this feature. But even after that, there always are legacy
compilers to support (for example now, in 2005, many people are still using
VC6, long after VC7.x, and even VC8.0 beta became available).

Considering extreme usefulness of the feature right now, it seems to make
sense to implement it at the library level.

The emulation mode seems to be important even if a better option is present
on some particular compiler. If a library author wants to develop portable
code using typeof, she needs
to use emulation mode and register her types and templates. Those users who
have a better option can still take advantage of it, since the registration
macros are defined as no-op on such compilers, while the users for whom emulation
is the only option will use it.

The other consideration applies to the users of VC7.1. Even though the more
convenient typeof trick is
available, the possibility of upgrade to VC8, where emulation remains the
only option, should be considered.

The emulation mode can be forced on the compilers that don't use it by default
by defining the BOOST_TYPEOF_COMPLIANT
symbol:

g++-DBOOST_TYPEOF_COMPLIANT-I\boost\boost_1_32_0main.cpp

The three participating parties

The Lambda example from the Motivation section requires the following registration:

It may seem that the price for the ability to discover the expression's type
is too high: rather large amount of registration is required. However note
that all of the above registration is done only once, and after that, any
combination of the registered types and templates would be handled. Moreover,
this registration is typically done not by the end-user, but rather by a
layer on top of some library (in this example -- Boost.Lambda).

When thinking about this, it's helpful to consider three parties: the typeof
facility, the library (probably built on expression templates principle),
and the end-user. The typeof facility is responsible for registering fundamental
types. The library can register its own types and templates.

In the best-case scenario, if the expressions always consist of only fundamental
types and library-defined types and templates, a library author can achieve
the impression that the typeof
is natively supported for her library. On the other hand, the more often
expressions contain user-defined types, the more responsibility is put on
the end-user, and therefore the less attractive this approach becomes.

Thus, the ratio of user-defined types in the expressions should be the main
factor to consider when deciding whether or not to apply the typeof facility.

Supported features

The Typeof library pre-registers fundamental types. For these types, and
for any other types/templates registered by the user library or end-user,
any combination of the following is supported:

Pointers;

References (except top-level);

Consts (except top-level);

Volatiles (except top-level);

Arrays;

Functions, function pointers, and references;

Pointers to member functions;

Pointers to data members.

For example the following type:

int&(*)(constvolatilechar*,double[5],void(*)(short))

is supported right away, and something like:

void(MyClass::*)(intMyClass::*,MyClass[10])const

is supported provided MyClass
is registered.

The Typeof Library also provides registration files for most STL classes/templates.
These files are located in the std subdirectory, and named after corresponding
STL headers. These files are not included by the typeof system and have to
be explicitly included by the user, as needed:

What needs to be registered?

It is possible to take advantage of the compiler when registering types for
the Typeof Library. Even though there is currently no direct support for
typeof in the language, the compiler is aware of what the type of an expression
is, and gives an error if it encounters an expression that has not been handled
correctly. In the typeof
context, this error message will contain clues to what types needs to be
registered with the Typeof Library in order for BOOST_TYPEOF
to work.

Limitations

Classes and templates nested inside other templates also can't be registered
because of the issue of nondeduced context. This limitation is most noticeable
with regards to standard iterators in Dinkumware STL, which are implemented
as nested classes. Instead, instantiations can be registered: