Boost logo

Boost :

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2001-02-14 04:48:04


Hi,

I wonder if the following problem is common enough to make it to the
utility.hpp-header :) When writing templates, I often need the
parameters to be derived from special classes. This is not a "real"
problem as I get massive compiler errors when I forget it. The problem
is, that the error-messages are unreadable. I have enough training ("try
and error :)") to read the compiler output, but my colleague usually has
no clue what's going on and therefore asks me all the time "What's
wrong? What is it [the compiler] trying to tell me?". So I wrote a
helper class:

template< class Parent, class Child > class parent_of
{
public:
  parent_of() {
    if( false ) { // Allow easier optimization
      Child* p; Parent* q = p;
    }
  }
};

this allows me to use:

template< class T > class pointer : parent_of< Object, T >

to express (and document!) that I expect the class T to be derived from
Object. Now if you try to use pointer< X > for a class X that is not
derived from Object, my compiler (gcc) gives the following output:

g++ -ansi -pedantic -o t t.cc
t.cc: In method `parent_of<Object,B>::parent_of()':
t.cc:31: instantiated from here
t.cc:7: type `Object' is not a base type for type `B'

telling me *what* is wrong and *where* the error is (here it's line 31).

So, what do you think? Is this a common problem, does a "stupid" class
like the above help? How do other compiler react on it? I looked at the
concept-check-library from Jeremy, but it seems far to complex for this
case (IMHO). Could / should 'if( false )' be removed? Erm... and while
we are at it: I don't like the name 'parent_of', but I'm pretty bad in
coming up with good names. Any suggestions? :)

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de

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