Re: [boost] visit_each

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