Larry Evans <cppljevans@cox-internet.com> writes:
On 01/24/2006 04:43 PM, David Abrahams wrote:
Larry Evans <cppljevans@cox-internet.com> 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