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
> > has to know about it:
> That's a dependency :)
> 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
> 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
> up with at the moment. Shouldn't the naming be consistent? ref_t and
> 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
> I can't say that I like that sort of coupling, but the idea of silent
> frightens me to the core (dump).
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk