Re: [boost] Overloading a function taking a boost::function

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-12 19:15:06

----- Original Message -----
From: "Paul Mensonides" <pmenso57_at_[hidden]>

> > Paul,
> >
> > I don't mean to be harsh, but so what? I'm going to use the library
that's
> > part of Boost. Having your techniques incorportated in the
> > Boost.Preprocessor lib would be interesting, but for that you need to
get
> > Vesa's attention, not mine.
> >
> > -Dave
>
> Dave, I asked a question about what would be the requirements of a
> 'function_traits' class.  You got involved by posting the
arg_tuple_size.hpp
> file as an example of what that kind of thing requires--as a way (I
assume) to
> say that it is a total pain, etc..

Sorry, I guess I should've given some explanation. I didn't mean to say
that. I was just trying to show that we can count arguments at compile time
for compilers without PTS.

> I responded with an example that disproves
> that it is a total pain with the right mechanisms to do that kind of
> thing--which is exactly the kind of mechanism that is necessary for a
full-blown
> function_traits implementation.  That is all.  I have been working on the
> preprocessor iteration mechanism concurrently, and that is partially why
I asked
> the question about function_traits--to see if my prototype could handle
> everything that was required.  Furthermore, I am not proposing that you
change
> your python library to use a preprocessor library that is not part of
> Boost--obviously.

Sorry, it wasn't obvious to me. Since I complained about the slow EDG
preprocessor several weeks ago you've posted several re-writes of my code
which used your faster technique. It's really cool and interesting, but I
have my hands full with the techniques I already have, so I can't start
using yours at the moment.

> I don't even know Python for that matter--it is not my area.
> Without better support for expansion and debuggable output, the
preprocessor
> library is seriously lacking.

I tend to agree.

> You, as a user of it, should have at least a mild
> interest in that--

definitely! But you've already proven long ago that your technique is fast.

> given that you have a pre-expanded version already (which
> defeats the purpose of generating it with the preprocessor and makes the
> preprocessor usage of intellectual value only).

Not exactly. If someone needs more than the 15 arguments I am generating
they can get that just from the compiler command-line. However, that's
pretty unlikely, isn't it?

> Vesa is not the only relevant
> person and before I am going to fully integrate it with the existing
> preprocessor library, I'd like to see if it is worthwhile to do so and
what
> things might be missing or whether it should be implemented totally
separately.
> Also, I don't know the existing library that well enough, and the
documentation
> is not exactly extensive.  In other words, it will take a lot of my time
to
> integrate it fully--which I won't do if there is no interest.

I'd be very interested, if it were done. I believe that your techniques are
effective.

-Dave