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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-12 21:21:54

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

> > 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.
>
> Ah.  Okay.
>
> > 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'm not expecting you to.  I would appreciate it if you could at least
comment
> on it.

http://aspn.activestate.com/ASPN/Mail/Message/1171869

I wish I had time to fully evaluate every piece of code that someone asked
me for comments on. Seriously, that could get to be a full-time job very
quickly.

> I'm trying to make it as intuitive as possible--as easy to use as
> possible, but, of course, it is easy for me to use (since I wrote it, and
> thoroughly understand it) so I'm somewhat blinded by that. :)

Post a guide to usage somewhere and I'll be glad to look it over.

> > > 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.
>
> :) In time, the speed issue will cease to exist.  If it was only for that
> reason, I would consider it a hack.

Debuggability is important, too, if indeed you've achieved that.

> > > 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.
>
> Yes, but I am trying to polish it up.  Make it faster, easier to use,
more
> debuggable, etc..  There are massive improvements behind the scenes of
the
> various examples that I've posted over time.
>
> To me, (and of course I'm biased) the code seems pretty localized and
intuitive,
> but there might be improvements that others can think of that I have
missed (or
> whatever).

I'm just a user of the Preprocessor lib at the moment; unfortunately I just
don't have time to figure out how things work and how to make them better.

> > > 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?
>
> Yes, however it takes significantly longer to do the 16th instead of say
the
> 10th.  The library needs to be improved to the point that none of this
needs to
> be manually written (or formatted).
>
> > I'd be very interested, if it were done. I believe that your techniques
are
> > effective.

I still don't know whether they can handle nested loops like those found in
boost/boost/python/preprocessed/returning_non_void.hpp. That's important to
me.

-Dave