Re: type traits, reflection, and whatnot

[Phil Edwards <phil at jaj dot com>]

On Sun, Jan 12, 2003 at 02:13:16PM +0100, Gabriel Dos Reis wrote:
> compiler a la sizeof, e.g. __is_fundamental(T), __is_scalar(T), while
> others are implemented at the library level, more or less like
> <typeinfo> or <exception>.
[...]
> There would be little (or no) need for specializations if we choose
> the "right" primitives.

Initially I liked the proposal's suggestion of a single operator,
__traits_of, which evaluates to a bitmask containing the various traits.
Then __is_foo<T>::value = __traits_of(T) & FOO_MASK for each 'foo' trait.
(The suggestion of multiple operators, __is_class, __is_union, etc, was
also in the proposal, but the thought of so many additional extention
operators bothered me.)

The major difficulty with that approach, as I see it, is providing an
out-of-line definition of is_foo::value.  Right now the language requires
it, and even after core issue 48 relaxes the requirement, GCC currently
is not optimizing away the need for storage (like 2.x did).

As it happens, that was the criterion which shaped my current approach,
which (in the library) simply provides forward declarations for each of
the classes, e.g.,

    template <typename _T> struct is_void;

When they are used,

    bool b = std::is_void<int>::value;

a rarely-taken code path in pt.c starts to instantiate the template,
notices that the type is still incomplete, then checks for the presence
of one of the traits classes.  It then specializes the type "on the fly,"
with the specialization looking like

    template <>
      struct is_void<int> : public __gnu_cxx::__false_type
      {
      };

where the base classes are taken from the proposal and modified only
enough to fit into v3's naming scheme.  This lets us implement as many
traits as we wish without having to worry about defining 'value' members,
and pay only for the space of 2 bool's.

Having implemented the proposal twice, once in library code and now inside
the compiler, I truly believe that doing it in library code is much more
trouble.


> | The win is that none of the data structures used to handle the ss13s need
> | to be initialized in the compiler unless we see the new pragma.
> 
> I do not believe we need pragmas.  I certainly do want it be possible
> to use some of the type traits machinery without having to include
> whathever header or saying whatever pragmas.

Well, the original idea was to extend the library more than anything else.
Getting the machinery without including the header seems like bypassing much
of the idea.  (Not necessarily a bad thing, if that's what we decide to do.)

Which part(s) of the machinery did you have in mind?


> Pragmas are useful when used appropriately, but I'm not sure there are
> need or even convenient here.

I'm not wedded to pragmas, but it was by far the easiest way to signal,
"from now on, recognize these name specially," once the appropriate header
was included.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002