Hello!

>>>>> "VB" == Valentin Bonnard <bonnardv@pratique.fr> writes:

VB> Please do not replace macros with something _more_ ugly.

The concept of traits exists already in C++. It is used in the standard
library and was exposed in an article in C++ Report (June 95 - Vol 7/No 5, p
32: A new and useful template technique: "Traits", by Nathan Myers).

What I have in mind is an extension of this concept, which would need a
specific support from the language: it would be a new category of templates.

These new templates would not introduce a new scope at instantiation, but use
the one of the class used to parameterize them.

Let's put a syntax to make things more concrete, e.g. using a new "trait"
keyword (maybe useful for parsing reasons - no claim that "trait" would be or
not suitable as a new keyword, maybe "baggage" is better/more clash-free). The
declaration:

template <class T> trait NoCopy {
  private:
    T(const T&);              // declared but not defined
    void operator=(const T&);
  public:
    T() {}                    // default restored
};

...could only be used by a class (here "trait" could be replaced with
"template", or even removed altogether, in order to avoid introducing a new
keyword):

class X: trait NoCopy {
    // whatever
};

There are many uses for such an extension. A first group would push further
forward the need for macros (e.g. for streaming support in ObjectSpace of
RogueWave toolkits). A more interesting group yet would exploit the better
orthogonality of genericity vs inheritance, by allowing generic features to be
specialized in derived classes.

Consider the problem in emulating this "trait" facility with current
technology:

template <class T> A {
  public:
    virtual void foo(T*);
};

class X: virtual public A<X> {};

If I want to specialized X into Y, there is no simple way in which I can
override "foo" to be more specific when taking a Y as covariant input (er:
there are ways, but they are complex and add indirections).

Note that the first example above cannot be fully satisfactorily
replaced by a simple class: the restriction brought by inheriting from
a NoCopy class can be explicitly worked around:

class Y: NoCopy {
  public:
    Y() {}
    Y(const Y&) {}
    Y& operator=(const Y&) { return *this; }
};

Instances of Y can be copied and assigned to...


Would this qualify as "more ugly" than macros in your mind? :-)
Best Regards!

--
Marc Girod         Nokia Telecommunications  INS/IPS/MS/NOMA
Valimo 1/2         P.O. Box 315              Phone:  +358-9-511 63331
00380 Helsinki     00045 NOKIA Group         Fax:    +358-9-511 63310
Finland                                      marc.girod@ntc.nokia.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]