In article <MATT.95Mar13221305@physics2.berkeley.edu>, matt@physics2.berkeley.edu (Matt Austern) writes:
|> In article <3k1p9o$drf@jupiter.SJSU.EDU> horstman@sjsumcs.sjsu.edu (Cay Horstmann) writes:
|>
|> > That is because C++ templates do not specify any requirements for the
|> > instantiation types. The rule is that T is a legal type if we try it and
|> > it doesn't break. Other programming languages manage to do better in this
|> > regard.
|>
|> Yep.  I think we've all had painful experiences with templates, trying
|> to figure out just why we got that mysterious error message at link
|> time, what it's doing coming from debugged library code that came from
|> the compiler vendor, and what in the world it has to do with the code
|> we wrote.
|>
|> Part of this is because templates are immature: compiler vendors
|> haven't yet learned how to implement templates in such a way that
|> you get sensible error messages.  Only part, though.  Part of it
|> has to do with the language itself.
|>
|> I'd really like to see some sort of constrained genericity for C++
|> templates (like Eiffel has), or else something like gcc's signatures.
|>

Well, I've used construct such as

  template <class D> class Base {
  public:
    void foo(Whatever item) {... ; D::bar(item); ...}
  private:
    Base();
    ~Base();
    Base(const Base<D>&);
    Base<D>& operator=(const Base<D>&);
  friend class D;
  };

  class Derived : public Base<Derived> {
  private:
    void bar(Whatever item);
  friend class Base<Derived>;
  };

  ...
  aDerived.foo();
  ...

The purpose is to seal tightly the cooperation of Base and Derived,
and avoid virtual dispatch overhead. The constraint on D is that it
must provide a bar(some_ancester_of_Whatever) method. I don't think
signatures would help here. I wonder whether it would be possible
to express this constraint (e.g. though derivation, as Eiffel does)
without overhead (e.g. virtual dispatch and a vtbl pointer).

Any hint ?

--chris@etca.fr
Le monde entier est un cactus, il est impossible de s'asseoir (J. Dutronc).


|> --
|>
|>                                --matt