Re: [boost] bind.hpp updated

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-13 11:56:17

From: "Douglas Gregor" <gregod_at_[hidden]>
> > The visitor does not need to depend on the bind library being used, it
only
> > has to know about it:
>
> That's a dependency :)

True.

> At the very least this sort of customization has to be taken out of the
> visitor, or if it is to be in the visitor it should be in a base class
that
> all visitors are expected to derive from.

True, if you take the view that the Visitor is a documented concept that is
part of some interface.

I was thinking about the case where you're writing a library that needs to
interoperate with bind.hpp (among others) so you define a corresponding
visitor as an implementation detail. The user doesn't see the visitor. If
you can hide the 'visitation' in a .cpp file (hmm, can this be done?) the
user won't be hurt by the extra dependencies.

> True. Perhaps there is a greater need for ref_t and value that I can't
come
> up with at the moment. Shouldn't the naming be consistent? ref_t and
value_t
> or reference and value?

Well, ref_t is named ref_t because 'ref' is already taken. :-) If 'value'
goes into boost it could become value_t as well.

I'm not sure whether this would help, however, since other bind libraries
may not wrap their parameters in a 'value' as bind.hpp does.

> For any Boost library it likely won't be fragile, because visit.hpp will
> theoretically exist in Boost, and even if I only have enough time to grunt
> "visit.hpp" I'll be begging binding library authors to add support for it.

If there is such thing as boost/visit.hpp at all. When I wrote 'visit.hpp' I
meant 'the (not exposed to the user) part of your library that visits.' :-)

> Having visit.hpp include support for all known libraries won't be as
fragile.
> I can't say that I like that sort of coupling, but the idea of silent
errors
> frightens me to the core (dump).

Likewise.

--
Peter Dimov
Multi Media Ltd.