Re: [boost] Interest for policy based smart pointer (smart_ptr)
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news: <news:%3cdqpagd$mov$1@sea.gmane.org> <dqpagd$mov$1@sea.gmane.org>...
On 01/19/2006 05:13 PM, David Maisonave wrote:
[snip]
I read in a previous thread that a policy base smart pointer was
being considered for boost, but I could not find it in the sandbox.
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/poli cy_ptr/ 1. Is there any usage documentation? 2. Has any performance test comparison been done? 3. Can it compile to VC++ 6.0? It looks like work started on this in 2004, but I don't see any logging pass 26 Jun 2005. 4. Is the work for this class at a stand-still?
On 01/19/2006 09:49 PM, Axter wrote:
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news: [snip]
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/poli cy_ptr/
1. Is there any usage documentation?
No. However, there is preliminary docs for a supporting library for precise cycle collection. Please see: http://groups.google.com/group/comp.lang.c++.moderated/msg/4aebebd2ec81a0f8 for an example test. The supporint library is fields_visitor. The preliminary docs are in sanbox in libs/fields_visitor/doc. Results of doc/Jamfile.v2 are in vault under Memory directory in fields_visitor.ug.zip.
2. Has any performance test comparison been done?
None that I'm aware of.
3. Can it compile to VC++ 6.0?
Don't know.
It looks like work started on this in 2004, but I don't see any logging pass 26 Jun 2005.
4. Is the work for this class at a stand-still?
Pretty much. I'm still working on fields_visitor docs. I have had plans for adding other versions of cycle collection and maybe a policy for precise mark-sweep; however, I'm not sure how to do that. Previous attempts at precisely finding roots have been fruitless, AFAICT, except for the Christopher method, which is what's used in the example test mentioned above. The Christopher method is documented in [chri84] shown here: http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbibC.html
Larry Evans <cppljevans@cox-internet.com> writes:
Pretty much. I'm still working on fields_visitor docs.
I hope you're reusing the visitor mechanism provided by the signals library for function detection: http://www.boost.org/doc/html/signals/s05.html#id2739308 -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 01/20/2006 10:00 AM, David Abrahams wrote:
Larry Evans <cppljevans@cox-internet.com> writes:
Pretty much. I'm still working on fields_visitor docs.
I hope you're reusing the visitor mechanism provided by the signals library for function detection: http://www.boost.org/doc/html/signals/s05.html#id2739308
Thanks Dave. I was totally unaware of this. I'll read the docs to see if it'll work. It sure helps to have someone who is familiar with many of the libraries. I guess I should have been more deligent about researching other libraries :(
On 01/20/2006 10:47 AM, Larry Evans wrote:
On 01/20/2006 10:00 AM, David Abrahams wrote: [snip]
http://www.boost.org/doc/html/signals/s05.html#id2739308 [snip] I'll read the docs to see if it'll work. [snip] The file:
http://www.boost.org/doc/html/visit_each.html has: visit_each mechanism allows a visitor to be applied to every subobject in a given object. but there's no definition of subobject or object. Is a subobject any instance of a class, or only those derived from signals::trackable? The file also contains: other uses may surface if used universally (e.g., conservative garbage collection). does the "conservative" qualifier mean the subobjects are located conservatively (e.g. comaring each word in the containing object with some flag value)? TIA.
Larry Evans <cppljevans@cox-internet.com> writes:
On 01/20/2006 10:47 AM, Larry Evans wrote:
On 01/20/2006 10:00 AM, David Abrahams wrote: [snip]
http://www.boost.org/doc/html/signals/s05.html#id2739308 [snip] I'll read the docs to see if it'll work. [snip] The file:
http://www.boost.org/doc/html/visit_each.html
has:
visit_each mechanism allows a visitor to be applied to every subobject in a given object.
but there's no definition of subobject or object.
These terms are defined in the C++ standard.
Is a subobject any instance of a class,
Or a builtin type.
or only those derived from signals::trackable?
The file also contains:
other uses may surface if used universally (e.g., conservative garbage collection).
does the "conservative" qualifier mean the subobjects are located conservatively (e.g. comaring each word in the containing object with some flag value)?
"Conservative garbage collection" usually means that a memory block is considered to be referenced as long as there's a bit pattern somewhere that *could* be a pointer into it. I think the word "conservative" is just wrong in this context and the author meant the opposite -- that memory is considered to be referenced iff there is a real pointer into that memory -- but I could be mistaken. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 01/20/2006 10:00 AM, David Abrahams wrote: [snip]
I hope you're reusing the visitor mechanism provided by the signals library for function detection: http://www.boost.org/doc/html/signals/s05.html#id2739308
From looking at: template<typename V> void visit_each(V& v, const tracking_bridge& t, int) { v(t); v(t.sig); } in $BOOST_ROOT/libs/signals/test/random_signal_system.cpp, I realized the meaning of: a visit_each overload must be supplied for each object type. 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. 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. Maybe "subobjects selected by user in the user's specialization of visit_each" would be more accurate. 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 the object by "declaring" it visitable by wrapping it in something derived from registrar_heirarchy. The visit_each method is less intrusive (no need to modify the class to be visited), but more work. The following code: http://tinyurl.com/dx7rs demonstrates how fields_visitor can be used to emulate a visit_each method. The other example program, simple_*.cpp, shows how to do it just using fields_visitor. FYI, the preliminary fields_visitor users_guide in the vault has been updated. -best regards & thanks for the interest, Larry
Larry Evans <cppljevans@cox-internet.com> writes:
On 01/20/2006 10:00 AM, David Abrahams wrote: [snip]
I hope you're reusing the visitor mechanism provided by the signals library for function detection: http://www.boost.org/doc/html/signals/s05.html#id2739308
From looking at:
template<typename V> void visit_each(V& v, const tracking_bridge& t, int) { v(t); v(t.sig); }
in $BOOST_ROOT/libs/signals/test/random_signal_system.cpp, I realized the meaning of:
a visit_each overload must be supplied for each object type.
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.
Maybe "subobjects selected by user in the user's specialization of visit_each" would be more accurate.
I don't think so. That's tautological.
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
??
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 visit_each method is less intrusive (no need to modify the class to be visited), but more work.
The following code:
demonstrates how fields_visitor can be used to emulate a visit_each method.
A lot of code, almost no comments. It's not very clear what it's supposed to be doing or illustrating.
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 Also not very clear to me. The use of "arg<1>" instead of "_1" is not very idiomatic, which --though it's minor-- doesn't help, IMO. -- Dave Abrahams Boost Consulting www.boost-consulting.com
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). Practically, the user, as done in random_signal_system.cpp, could write technically wrong code to just visit the smart_pointers; 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. [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.
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.
Also not very clear to me. The use of "arg<1>" instead of "_1" is not very idiomatic, which --though it's minor-- doesn't help, IMO.
I'll change it. Thanks.
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
participants (2)
-
Axter -
David Abrahams -
Larry Evans