Boost logo

Boost :

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-11-13 18:47:16

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of David Abrahams

> > along with detection for other types of members such as data, function,
> > static function, static data?
> Not sure about that part. I mean, I know it would be useful, but I'm
> not certain whether it's useful *enough*. I just have no opinion.

So far I'm only checking for member functions, but I think I'd have used
this technique a lot in the past if it had been available to me.

It would take too much space to describe what I'm doing with it, but I
remember a compelling example that was in CUJ a while back (paraphrased):

   struct use_copy_constructor {

      template <typename T> static T* clone(const T& t) {
         return new T(t);

   struct use_clone_function {

      template <typename T> static T* clone(const T& t) {

         return t.clone();

   template <typename T> T* clone(const T& t) {

      return mpl::if_<



> > These types of inspection can provide very nice resolutions to
> > problems that otherwise require more intrusive solutions like
> > derivation or specialization.
> Occasionally.

I think people will begin to see more opportunities to use this type of
introspection, especially with the advent of tools like enable_if.

> > Anyway, if there's another solution in the works I'll drop it, but
> > otherwise I would be happy to boostify and document what I've got.
> I think I'd like it to work the way the MPL one does; we're already
> re-using that facility in several libraries. But I guess I understand
> why you want to say has_member_type when you need a separate test for
> has_member_data. OK, a mild vote yes from me.

I'll keep everything as close to the MPL version as possible. To start with
I'll only do has_member_type and has_member_function to see how they're



Boost list run by bdawes at, gregod at, cpdaniel at, john at