Boost logo

Boost :

From: rtorchon_at_[hidden]
Date: 2000-11-22 21:39:49

please unsubscribe me from this list

                    .com To: boost_at_[hidden]
                    11/22/2000 Subject: [boost] Digest Number 285
                    06:24 PM
                    respond to

There are 25 messages in this issue.

Topics in this digest:

      1. Re: New New Callbacks Uploaded
           From: "William Kempf" <sirwillard_at_[hidden]>
      2. Re: New New Callbacks Uploaded
           From: "William Kempf" <sirwillard_at_[hidden]>
      3. Re: Re: New New Callbacks Uploaded
           From: "Peter Dimov" <pdimov_at_[hidden]>
      4. Re: Patches for MSVC6
           From: Jens Maurer <Jens.Maurer_at_[hidden]>
      5. Re: New New Callbacks Uploaded
           From: "William Kempf" <sirwillard_at_[hidden]>
      6. Re: Patches for MSVC6
           From: "Andreas Scherer" <as_at_[hidden]>
      7. Re: Patches for MSVC6
           From: "David Abrahams" <abrahams_at_[hidden]>
      8. Re: Re: New New Callbacks Uploaded
           From: Karl Nelson <kenelson_at_[hidden]>
      9. Re: New New Callbacks Uploaded
           From: Jesse Jones <jejones_at_[hidden]>
     10. Re: New New Callbacks Uploaded
           From: Jesse Jones <jejones_at_[hidden]>
     11. Re: Re: New New Callbacks Uploaded
           From: Kevlin Henney <kevlin_at_[hidden]>
     12. Re: New New Callbacks Uploaded
           From: Kevlin Henney <kevlin_at_[hidden]>
     13. Re: Re: New New Callbacks Uploaded
           From: Kevlin Henney <kevlin_at_[hidden]>
     14. Re: Re: New New Callbacks Uploaded
           From: Kevlin Henney <kevlin_at_[hidden]>
     15. Re: New New Callbacks Uploaded
           From: "Greg Colvin" <gcolvin_at_[hidden]>
     16. Re: New New Callbacks Uploaded
           From: Kevlin Henney <kevlin_at_[hidden]>
     17. Re: generic polyvalent input/output ['pickle']
           From: Jens Maurer <Jens.Maurer_at_[hidden]>
     18. Re: gcc and std::numeric_limits
           From: Jens Maurer <Jens.Maurer_at_[hidden]>
     19. Re: Re: New New Callbacks Uploaded
           From: Jesse Jones <jejones_at_[hidden]>
     20. Re: New New Callbacks Uploaded
           From: Jesse Jones <jejones_at_[hidden]>
     21. Re: Portable binary integers [was generic polyvalent I/O]
           From: Luis Coelho <luis.coelho_at_[hidden]>
     22. Re: gcc and std::numeric_limits
           From: Beman Dawes <beman_at_[hidden]>
     23. Re: New New Callbacks Uploaded
           From: Jesse Jones <jejones_at_[hidden]>
     24. Re: Formal Review: Concept Checking
           From: Beman Dawes <beman_at_[hidden]>
     25. Re: generic polyvalent input/output ['pickle']
           From: Beman Dawes <beman_at_[hidden]>


Message: 1
   Date: Wed, 22 Nov 2000 21:03:37 -0000
   From: "William Kempf" <sirwillard_at_[hidden]>
Subject: Re: New New Callbacks Uploaded

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <8vgkjo+102eg_at_e...>, William Kempf <sirwillard_at_my-
>> writes
> >I've not looked at Jesse's new code yet, but Doug's code doesn't
> >to open up the possiblity of runtime errors that you suggest.
> >Neither does it require that any parameters or other types be
> >constructible. Care to elaborate on the problems you think you
> The compile-time interface to the callback class offers versions of
> operator() that cannot be satisfied at runtime.

Again, I won't comment on Jesse's implementation, but it's possible
to implement this idiom with the result of it being a compile time,
not run time, error to use an erroneous operator() overload.

> >As for why it's desirable... it eliminates redundant information
> >the declaration. Why should you have to specify the number of
> >parameters when you declare the type with explicit parameters?
> >just cleaner to say:
> >
> >callback<void, int, float> cb;
> >
> >instead of:
> >
> >callback2<void, int, float> cb;
> I understand that the syntax is desirable, but I don't think it
> be at the expense of safety.

I'd agree, but I don't see safety issues here.

> It should be possible, with appropriate specialisations, to make the
> unwanted overloads of the callback unusable for a given number of
> arguments.

It doesn't really even require specializations, though it does
require some meta programming. Doug's version is already safe in
this regard.

> Another thought: Would it be possible to do a little currying to
wrap up
> the way that extra arguments are handled internally? This would
have the
> benefit of (1) enforcing only legal use, (2) simplifying the
> implementation, and (3) keeping the size of classes and number of
> virtuals flying around to a minimum.

Again, I think Doug's addressed this fairly well. There may yet be
some tricks to reduce code bloat in his implementation, but in
general it's satisfactory now.

Bill Kempf


Message: 2
   Date: Wed, 22 Nov 2000 21:15:39 -0000
   From: "William Kempf" <sirwillard_at_[hidden]>
Subject: Re: New New Callbacks Uploaded

--- In boost_at_[hidden], Karl Nelson <kenelson_at_e...> wrote:
> [....]
> > > 2) Second it makes for really poor code clarity as the class
> > > have to implement all of the operator() even through it uses
> > > only one of them...
> > >
> > > class callback {
> > > ...
> > > return_type operator()() { ... }
> > > return_type operator()(P1 p1) { ... }
> > > return_type operator()(P1 p1,P2 p2) { ... }
> > > return_type operator()(P1 p1,P2 p2,P3 p3) { ... }
> > > return_type operator()(P1 p1,P2 p2,P3 p3,P3 p3) { ... }
> > > ...
> > > };
> >
> > The callback class doesn't have to implement all operator()
overloads, though the alternative requires deriving from a base class
which has the proper overload. The first option is slightly more
readable for the "callback" class itself, the second option gives the
best error messages (since only one operator() exists).
> I don't believe that deriving directly will work, or at least I
> seen one without the construction I showed above.

Look at Doug's implementation. All that would be required is to
derive from the "impl" class instead of containing it. He's done the
work or factoring out the unneeded overloads using a simple bit of
meta programming.

> > > 5) It caps the number of callback which limits the application
> > > somewaht. That is with the callback#, the user can always call
> > > the macro generator to produce another set of classes for a
> > > larger number of parameters.
> >
> > Not necessarily. In my original event library, I used this
technique and had scripts to generate the event classes. The only
reason this has yet to be done for any of the current callback
library candidates is that it is less manageable in the prototype
> However, this won't link unless all the code is compiled against
> same number.

In general, I don't think this is that big of an issue. If you
supply a reasonable number to begin with, it's very unlikely that
more will be needed. It's generally bad programming practice to
write functions that take large numbers of arguments to begin with.
Generate a callback that takes up to 10 arguments and I think there's
little danger of someone needing more.

Bill Kempf


Message: 3
   Date: Wed, 22 Nov 2000 23:06:05 +0200
   From: "Peter Dimov" <pdimov_at_[hidden]>
Subject: Re: Re: New New Callbacks Uploaded

From: "William Kempf" <sirwillard_at_[hidden]>

> --- In boost_at_[hidden], "Peter Dimov" <pdimov_at_m...> wrote:
> > A list of pros and cons won't help, because a cloning callback and a
> > reference counted callback are different concepts. Sometimes you'll
> need the
> > one, sometimes the other.
> This I'm not so sure about. Yes, their behavior is radically
> different. However, I find it difficult to think of specific
> situations where one would be the answer while the other would not.
> Can you spark my thinking on this?

The "pro ref-counting" example is easy, I already offered it (the STL
algorithms assume that copies are equivalent.)

To be honest, I don't immediately see a killer example that demonstrates a
situation where a cloning callback would be the answer but the counted
callback will not fit. Cloning just "feels right" to me.

The counted callback more closely mirrors a function pointer, in the case
where the function has state (static variables.)

All this seems to point toward reference counted semantics, but as I said,
my intuition doesn't agree. :-)

Here's another tricky point:

callback<int, int> c(F());
callback<void, char> c2(c);

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