|
|
Boost : |
From: rtorchon_at_[hidden]
Date: 2000-11-22 21:39:49
please unsubscribe me from this list
boost_at_egroups
.com To: boost_at_[hidden]
cc:
11/22/2000 Subject: [boost] Digest Number 285
06:24 PM
Please
respond to
boost
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-
> deja.com> writes
> >I've not looked at Jesse's new code yet, but Doug's code doesn't
seem
> >to open up the possiblity of runtime errors that you suggest.
> >Neither does it require that any parameters or other types be
default
> >constructible. Care to elaborate on the problems you think you
see?
>
> 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
from
> >the declaration. Why should you have to specify the number of
> >parameters when you declare the type with explicit parameters?
It's
> >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
should
> 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
will
> > > 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
haven't
> 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
stage.
>
>
> However, this won't link unless all the code is compiled against
the
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk