[Shifted Pointer] Review Request
Greetings, I would like to request a review of the Shifted Pointer utility. I am happy to say that I've corrected some bugs within the library itself and now it seems to be working well with all test files. As pointed out by John Maddock, some pool functions such as ordered_free() can still be optimized in speed or replaced but for now I would like to keep the interface as it is until perhaps some changes to the pool can be proposed. Once again to compile the test executables (with gcc): $ svn co http://svn.boost.org/svn/boost/sandbox/shifted_ptr $ cd shifted_ptr/libs/smart_ptr/example $ make shifted_ptr_test3 And its documentation can be found here: http://fornux.com/personal/philippe/devel/shifted_ptr/libs/smart_ptr/doc/ Regards, -Phil
Message du 22/04/11 06:40 De : "Phil Bouchard"
A : boost@lists.boost.org Copie à : Objet : [boost] [Shifted Pointer] Review Request
Greetings,
I would like to request a review of the Shifted Pointer utility. I am happy to say that I've corrected some bugs within the library itself and now it seems to be working well with all test files. As pointed out by John Maddock, some pool functions such as ordered_free() can still be optimized in speed or replaced but for now I would like to keep the interface as it is until perhaps some changes to the pool can be proposed.
Once again to compile the test executables (with gcc): $ svn co http://svn.boost.org/svn/boost/sandbox/shifted_ptr $ cd shifted_ptr/libs/smart_ptr/example $ make shifted_ptr_test3
And its documentation can be found here: http://fornux.com/personal/philippe/devel/shifted_ptr/libs/smart_ptr/doc/
Hi, this is much better, but I guess that a tutorial and some user land examples will be needed. I would also appreciate if you had used the Boost tools for the documentation and for the running the tests. In any case if the library is accepted you will need to be familiar with. Best, Vicente
On 4/21/2011 10:31 PM, Vicente BOTET wrote:
Hi,
this is much better, but I guess that a tutorial and some user land examples will be needed.
No problem.
I would also appreciate if you had used the Boost tools for the documentation and for the running the tests. In any case if the library is accepted you will need to be familiar with.
I have an issue with bjam on Cygwin preventing me from using the tools correctly. I will have access to a Linux platform shortly. Thanks, -Phil
AMDG On 04/21/2011 10:57 PM, Phil Bouchard wrote:
On 4/21/2011 10:31 PM, Vicente BOTET wrote:
I would also appreciate if you had used the Boost tools for the documentation and for the running the tests. In any case if the library is accepted you will need to be familiar with.
I have an issue with bjam on Cygwin preventing me from using the tools correctly. I will have access to a Linux platform shortly.
What is the problem? Boost.Build is supposed to work on Cygwin. If it doesn't, it's a bug. In Christ, Steven Watanabe
On 4/22/2011 7:06 AM, Steven Watanabe wrote:
AMDG
What is the problem? Boost.Build is supposed to work on Cygwin. If it doesn't, it's a bug.
bjam was returning: $ bjam toolset=gcc Access is denied. Access is denied. Access is denied. http://boost.2283326.n4.nabble.com/bjam-quot-Access-is-denied-quot-td3434409... -Phil
On 4/21/2011 10:31 PM, Vicente BOTET wrote:
Hi,
this is much better, but I guess that a tutorial and some user land examples will be needed.
I've added a small tutorial that basically already covers all that is needed to know as far as its usage is concerned: https://svn.boost.org/svn/boost/sandbox/pack_ptr/libs/smart_ptr/doc/tutorial... Thanks, -Phil
On Thu, Apr 21, 2011 at 9:38 PM, Phil Bouchard <philippe@fornux.com> wrote:
Greetings,
I would like to request a review of the Shifted Pointer utility. I am happy to say that I've corrected some bugs within the library itself and now it seems to be working well with all test files. As pointed out by John Maddock, some pool functions such as ordered_free() can still be optimized in speed or replaced but for now I would like to keep the interface as it is until perhaps some changes to the pool can be proposed.
Once again to compile the test executables (with gcc): $ svn co http://svn.boost.org/svn/boost/sandbox/shifted_ptr $ cd shifted_ptr/libs/smart_ptr/example $ make shifted_ptr_test3
And its documentation can be found here: http://fornux.com/personal/philippe/devel/shifted_ptr/libs/smart_ptr/doc/
I haven't looked too deeply into it, but this syntax seems scary: shifted_ptr<int> v = new shifted<int>(11); Is there a way to hide that detail? Perhaps construct with values which internally store shifted<T> from that value? Just seems error prone and unintuitive. -- GMan, Nick Gorski
On 4/21/2011 10:53 PM, GMan wrote:
I haven't looked too deeply into it, but this syntax seems scary:
shifted_ptr<int> v = new shifted<int>(11);
Is there a way to hide that detail? Perhaps construct with values which internally store shifted<T> from that value? Just seems error prone and unintuitive.
You are referring to intrusive members and this is the approach taken by intrusive_ptr<>. Intrusive members become a problem when multiple inheritance is used and/or virtual inheritance because the intrusive member might or might not be duplicated in the object. Perhaps an abbreviation can be used but for now this is the price to pay to use Shifted Pointer. Thanks, -Phil
On 04/21/2011 11:17 PM, Phil Bouchard wrote:
On 4/21/2011 10:53 PM, GMan wrote:
I haven't looked too deeply into it, but this syntax seems scary:
shifted_ptr<int> v = new shifted<int>(11);
Is there a way to hide that detail? Perhaps construct with values which internally store shifted<T> from that value? Just seems error prone and unintuitive.
You are referring to intrusive members and this is the approach taken by intrusive_ptr<>. Intrusive members become a problem when multiple inheritance is used and/or virtual inheritance because the intrusive member might or might not be duplicated in the object.
Perhaps an abbreviation can be used but for now this is the price to pay to use Shifted Pointer.
I think he is just suggesting to replace "new shifted<T>(...)" with "make_shifted<T>(...)" or something similar, where make_shifted returns a shifted_ptr<T> directly rather than a raw pointer to shifted<T>.
On 4/22/2011 12:03 AM, Jeremy Maitin-Shepard wrote:
I think he is just suggesting to replace
"new shifted<T>(...)"
with
"make_shifted<T>(...)"
or something similar, where make_shifted returns a shifted_ptr<T> directly rather than a raw pointer to shifted<T>.
make_shifted<>() would make overloading of the allocator less flexible. This is why I opted for operator new. -Phil
On Fri, 22 Apr 2011 13:30:59 +0600, Phil Bouchard <philippe@fornux.com> wrote:
On 4/22/2011 12:17 AM, Ilya Sokolov wrote:
shifted_ptr<int> v = new shifted<int>(11);
@Phil Bouchard: shouldn't the constructor be explicit?
I am not under the impression that is a necessity.
Then the following code is not exception-safe: void foo(shifted_ptr<int> a, shifted_ptr<int> b); void bar() { foo(new shifted<int>(42), new shifted<int>(43)); } due to unspecified order of arguments' evaluation.
On 4/22/2011 1:00 AM, Ilya Sokolov wrote:
Then the following code is not exception-safe:
void foo(shifted_ptr<int> a, shifted_ptr<int> b);
void bar() { foo(new shifted<int>(42), new shifted<int>(43)); }
due to unspecified order of arguments' evaluation.
I don't see how explicit constructors would change anything: void foo(shifted_ptr<int> a, shifted_ptr<int> b); void bar() { foo(shifted_ptr<int>(new shifted<int>(42)), shifted_ptr<int>(new shifted<int>(43))); } -Phil
Phil Bouchard <philippe <at> fornux.com> writes:
I would like to request a review of the Shifted Pointer utility.
Is it possible to select a name for this library that identifies what it is used for rather than how it does it? ----FROM THE DOCS---- The name shifted_ptr<T> first comes from one of its caracteristic where the reference counter is allocated at the same time the pointee object is. Only the pointer to the object is known by shifted_ptr<T> and in order to access the reference counter, the pointer to the top of the object is "shifted" up. The name of the class shifted<T> used to instanciate all pointee objects is simply taken from the name shifted_ptr<T> it will be assigned to. ----FROM THE DOCS---- rc_pointer? set_based_reference_counted_pointer? heap_set_shared_pointer? Also, the documentation needs an editorial pass through at some point by a native speaker that groks the approach. It is not easy reading at this point. For example, the paragraph above might be rewritten: -----REWRITE----- The name shifted_ptr<T> is inspired by the specific reference counting algorithm used. When an object pointed to by a shifted_ptr<T> is allocated, the reference counter for that object (set of objects?) is allocated at the same time. However, the shifted_ptr<T> doesn't actually keep a pointer to the reference counter. It calculates its address on the fly by "shifting up" the pointer to the object to that of the reference counter. The type used to instantiate the objects managed by the shifted_ptr<T> is likewise named shifted<T>. -----REWRITE----- Is that clearer? Based on my rewrite, the name "shifted_ptr" is an artefact of the algorithm used, not informative regarding what it does or how it is used. Joel
On 4/22/2011 7:36 AM, Joel Young wrote:
Phil Bouchard<philippe<at> fornux.com> writes:
I would like to request a review of the Shifted Pointer utility.
Is it possible to select a name for this library that identifies what it is used for rather than how it does it?
How about: set_ptr<int> p = new set_node<int>(11); Any better suggestions are welcome. -Phil
On 4/22/2011 9:08 AM, Phil Bouchard wrote:
How about: set_ptr<int> p = new set_node<int>(11);
I just renamed Shifted Pointer to Set Pointer. It renamed documentation can be found here: https://svn.boost.org/svn/boost/sandbox/set_ptr/libs/smart_ptr/doc/index.htm... Thanks, -Phil
On 4/22/2011 9:08 AM, Phil Bouchard wrote:
How about: set_ptr<int> p = new set_node<int>(11);
set_ptr reminds me of std::set*, but maybe thats just me. Is "grouped_ptr" a good idea? (Hoping it's not too much work for you to rename this stuff.) -- GMan, Nick Gorski
On 4/22/2011 6:33 PM, GMan wrote:
set_ptr reminds me of std::set*, but maybe thats just me. Is "grouped_ptr" a good idea? (Hoping it's not too much work for you to rename this stuff.)
set is shorter than grouped so it might be more convenient to type down. -Phil
On Fri, Apr 22, 2011 at 6:47 PM, Phil Bouchard <philippe@fornux.com> wrote:
set is shorter than grouped so it might be more convenient to type down.
Well `ctr` is shorter than `counter`, but less explanatory. :) pack sounds alright, but pack also says "compressed" to me. Let's just give it more time and see what other people say. -- GMan, Nick Gorski
GMan? The Stack overflow GMan? On Fri, Apr 22, 2011 at 10:04 PM, GMan <gmannickg@gmail.com> wrote:
On Fri, Apr 22, 2011 at 6:47 PM, Phil Bouchard <philippe@fornux.com> wrote:
set is shorter than grouped so it might be more convenient to type down.
Well `ctr` is shorter than `counter`, but less explanatory. :) pack sounds alright, but pack also says "compressed" to me.
Let's just give it more time and see what other people say.
-- GMan, Nick Gorski _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 4/22/2011 8:04 PM, GMan wrote:
Well `ctr` is shorter than `counter`, but less explanatory. :) pack sounds alright, but pack also says "compressed" to me.
Let's just give it more time and see what other people say.
Thanks, that's good enough. I'll rename it to pack_ptr this way "new set<>()" won't clash with "std::set". -Phil
On 4/22/2011 8:46 PM, Phil Bouchard wrote:
Thanks, that's good enough. I'll rename it to pack_ptr this way "new set<>()" won't clash with "std::set".
Ok I just renamed it and it is accessible at: https://svn.boost.org/svn/boost/sandbox/pack_ptr/libs/smart_ptr/doc/index.ht... -Phil
participants (8)
-
Andrey Asadchev -
GMan -
Ilya Sokolov -
Jeremy Maitin-Shepard -
Joel Young -
Phil Bouchard -
Steven Watanabe -
Vicente BOTET