Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-25 15:06:46


Larry Evans <cppljevans_at_[hidden]> writes:

> On 01/24/2006 04:43 PM, David Abrahams wrote:
> > Larry Evans <cppljevans_at_[hidden]> writes:
> [snip]
> >>in http://www.boost.org/doc/html/visit_each.html, i.e. the user must
> >>explicitly call v(x) for each subobject, x, of T.
> >
> >
> > Correct.
> >
> >
> >>However, the phrase, 'for each subobject' in visit_each.html
> >>is not really accurate since there is the subobject:
> >>
> >> minstd_rand& tracked_bridge::rand_gen;
> >>
> >>in tracking_bridge.
> >
> >
> > Technically speaking, that code is wrong and the phrase is accurate.
>
> The original purpose of the fields_visitor library was to visit the
> smart pointers in an object (it's used in the current policy_ptr
> library in sandbox). Thus "correct" visit_each would not be a good
> substitute since "correct" visit_each, which visited all subobjects
> instead of just the smart pointers, could involve mostly useless
> visiting (e.g. if the object contained no smart pointers).

...which would mostly compile away to nothing.

> Practically, the user, as done in random_signal_system.cpp, could
> write technically wrong code to just visit the smart_pointers;

Anyway, don't you want to visit every UDT that you don't have inside
knowledge about?

> however, as mentioned in my previous post, this might not be easy
> since smart pointers could be in superclasses or data members which
> the user is not that familiar with.

Exactly. So you may as well visit_each, IMO.

In fact, why bother with smart pointers if you're going to visit
anyway? You may as well use raw pointers, no?

> [snip]
> >>Anyway, the essential difference
> >>is that with visit_each, the user has to know which subobjects to
> >>visit and has to explicitly code the visit. OTOH, with fields_visitor,
> >>the user can select
> [snip]
> >>the object by "declaring" it visitable by wrapping
> >>it in something derived from registrar_heirarchy.
> >
> >
> > I don't see how wrapping the object is going to tell your registrar
> > where the subobjects are.
>
> The fields_visitor.ug.zip uploaded 24.01.2006 04:29 contains
> html/participants.html which partly explains this in item 2 in the
> <formalpara> titled "prevents thread safety". Briefly, for each type,
> T, there's a singleton, descriptor_builder, which creates an
> instance, SomeT, of T after setting a global variable, pointer_T, to
> &SomeT. This global variable is a flag to all registrars to calculate
> the offset of their registrant (a field in T) with respect to
> pointer_T and store that in a singleton fields_descriptor for T.
> After SomeT is built, it's destroyed and pointer_T is reset.

Heavy, man.

> >>The visit_each method is less intrusive (no need to modify the class
> >>to be visited), but more work.
> >>
> [snip]
> >
> > A lot of code, almost no comments. It's not very clear what it's
> > supposed to be doing or illustrating.
> >
>
> OK. I'll work on it. Thanks.
>
> >
> >>The other example program, simple_*.cpp, shows how to do it just
> >>using fields_visitor.
> >
> >
> > where is that? You must mean simple_record_field_traversal_test.cpp
>
>
> Yes. I thought simple_*.cpp would suggest all files starting with
> simple_ and ending with .cpp. Since there's only one in the
> directory, I thought it would be clear. Sorry.

Sorry, I missed the *.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk