Review Requests: shifted_ptr, list, stack & roofof
Greetings Boost: I am happy re-submitting after 4 years my final design and implementation proposal of "shifted_ptr" which includes very useful tools named "list", "stack" and "roofof". The new containers consisting of STL-like ones but offering external access to the nodes, removing the need of dynamically allocated nodes and thus offers multi-dimensional control over their elements. "roofof" is a one line helper function used in conjunction with the mentionned containers to find the root address of the class housing the member used by the container in question. In contrast with its previous submission, "shifted_ptr" now relates to a memory manager of constant complexity and of size: sizeof(void *) * 2. It take advantage of the low-memory consuption, fast execution and very versatile interface. It proposes a very different concept, removes the need of current functions such as: "enable_shared_from_this", destroys the "cyclic pointer" problem and is now perfectly type-safe. The former reference counted smart pointer was renamed to "shifted_ptr_base" and merged properly with Boost standards. Morever "shiifted_ptr" is closely tied to the current "shared_ptr" that uses objects derived from "sp_counted_base". This was extended to objects deriving from "owned_base", which includes the necessary information that is handled by the smart pointer plus a smart destructer that differentiates arrays from standard objects and destroys the object accordingly. I have not yet written entirely its documentation but I have included a well documented reference to its API. I would like to schedule a review for now and by then the documentation shall be completed. I am also aware the library doesn't yet handle multi-threaded applications but I would like to start with getting the library better known. The theory behind is perfectly reliable but I can't say I forgot technical issues. The library is located at: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename... Thank you, Phil Bouchard
AMDG Phil Bouchard wrote:
Greetings Boost:
I am happy re-submitting after 4 years my final design and implementation proposal of "shifted_ptr" which includes very useful tools named "list", "stack" and "roofof".
<snip>
The library is located at: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename...
You should not define now as a macro. Not to mention that now is a very non-descriptive name. IMO, it should be spelled make_shifted_ptr<T>(); In Christ, Steven Watanabe
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47D547F9.8060305@providere-consulting.com... [,,,]
You should not define now as a macro. Not to mention that now is a very non-descriptive name. IMO, it should be spelled make_shifted_ptr<T>();
That is exactly the preferred way to wrap the constructor but I wanted to demonstrate it is perfectly and type-safe to use that macro as an alternative for this unique case. It does not limit in any way also the number of arguments and doesn't prevent usages of non-constant argument if the make_shifted_ptr<>() adds such modifier. The "now" keyword should be read as an interjection between the pointee and the pointer meaning: "the object pointed to by P is now a D". In the case the object created by "now" isn't affected to any pointer then the code isn't human-redable anymore. Ex.: shifted_ptr<int> P = now (int)(9); // Ok now (int)(10); // Apocryphal Nevertheless I will add the wrapper function but I haven't seen standard support for variable argument listing. -Phil
"Phil Bouchard" <philippe@fornux.com> wrote in message news:fr5dem$g9a$1@ger.gmane.org... [...]
alternative for this unique case. It does not limit in any way also the number of arguments and doesn't prevent usages of non-constant argument if the make_shifted_ptr<>() adds such modifier.
[...] Please disregard that constness comment. -Phil
AMDG Phil Bouchard wrote:
"roofof" is a one line helper function used in conjunction with the mentionned containers to find the root address of the class housing the member used by the container in question.
If I remember correctly from the Intrusive review, virtual inheritance can make roofof blow up. In Christ, Steven Watanabe
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47D549EE.6050303@providere-consulting.com... [...]
If I remember correctly from the Intrusive review, virtual inheritance can make roofof blow up.
Unfortunately, yes. I would be possible adding a BOOST_STATIC_ASSERT the resulting pointer address is lesser than the member variable inside the function but obviously this will not be portable. Here is a list of things that still need to be done: - Replace owned<>::p_ with boost::optional<> - Add user-defined destructor to the pointee - Multi-threaded support - More aggresive internal usages of roofof<>() - Struct "set" and owned_base::last allocated from a private pool - make_shifted_ptr<>() That's about it I believe. -Phil
"Phil Bouchard" <philippe@fornux.com> wrote in message news:fr5fi3$n7c$1@ger.gmane.org... [...]
Here is a list of things that still need to be done: - Replace owned<>::p_ with boost::optional<> - Add user-defined destructor to the pointee - Multi-threaded support - More aggresive internal usages of roofof<>() - Struct "set" and owned_base::last allocated from a private pool - make_shifted_ptr<>()
I know also that the stack segment and the heap could be fragmented as their memory usage is unlimited on some system. Right now I am assuming the stack and the heap segments are contiguous blocks but may have to be changed obviously. -Phil
on Tue Mar 11 2008, "Phil Bouchard" <philippe-AT-fornux.com> wrote:
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47D549EE.6050303@providere-consulting.com...
[...]
If I remember correctly from the Intrusive review, virtual inheritance can make roofof blow up.
Unfortunately, yes. I would be possible adding a BOOST_STATIC_ASSERT the resulting pointer address is lesser than the member variable inside the function but obviously this will not be portable.
If I understand correctly, none of this code is technically portable; it is only "portable in practice" because of the way C++ is commonly implemented. Is that correct? It's not necessarily an argument against these proposals, but all Boost library submissions should be very clear about where they rely on unspecified or undefined behavior. -- Dave Abrahams Boost Consulting http://boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87skyvltul.fsf@gutsy.luannocracy.com... [...]
If I understand correctly, none of this code is technically portable; it is only "portable in practice" because of the way C++ is commonly implemented. Is that correct?
It's not necessarily an argument against these proposals, but all Boost library submissions should be very clear about where they rely on unspecified or undefined behavior.
No it is perfectly portable, this function called "roofof" simply cannot be applied to classes having virtual inheritance. It can be kept as an internal routine quite simply and used with PODs and classes having simple inheritances. sh::list<> and sh::stack<> classes can be used for different things also. I will write a pool allocator quickly using sh::list<> with the sh::roofof<> function for demonstration. I will also rename these for sh::intrusive_list<> and sh::intrusive_stack<>. -Phil
AMDG Phil Bouchard wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87skyvltul.fsf@gutsy.luannocracy.com...
[...]
If I understand correctly, none of this code is technically portable; it is only "portable in practice" because of the way C++ is commonly implemented. Is that correct?
It's not necessarily an argument against these proposals, but all Boost library submissions should be very clear about where they rely on unspecified or undefined behavior.
No it is perfectly portable, this function called "roofof" simply cannot be applied to classes having virtual inheritance. It can be kept as an internal routine quite simply and used with PODs and classes having simple inheritances.
roofof /does/ use undefined behavior. You can't just go dereferencing the null pointer... ((T *)(0)->* q) In Christ, Steven Watanabe
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47D9554B.9000003@providere-consulting.com... [...]
roofof /does/ use undefined behavior. You can't just go dereferencing the null pointer...
((T *)(0)->* q)
I heard offsetof() was going to be part of the next standards and that a POD will be redefined to allow non-virtual inheritances. I will change that portion of the code accordingly. -Phil
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47D9554B.9000003@providere-consulting.com... [...]
roofof /does/ use undefined behavior. You can't just go dereferencing the null pointer...
((T *)(0)->* q)
Until offsetof() gets standardized: - I have changed the code for the following: ((T *)(alignment_of<detail::max_align>::value)->* q) And made the following changes: - I have prefixed sh::list & sh::stack with "intrusive_" - Simplified "owned_base::last" type with "std::stack<owned_base::owned_base *>" -Phil
AMDG Phil Bouchard wrote:
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47D9554B.9000003@providere-consulting.com...
[...]
roofof /does/ use undefined behavior. You can't just go dereferencing the null pointer...
((T *)(0)->* q)
Until offsetof() gets standardized: - I have changed the code for the following: ((T *)(alignment_of<detail::max_align>::value)->* q)
How is that better?
And made the following changes: - I have prefixed sh::list & sh::stack with "intrusive_"
You might look at Boost.Intrusive In Christ, Steven Watanabe
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47DE9618.6030802@providere-consulting.com... [...]
- I have changed the code for the following: ((T *)(alignment_of<detail::max_align>::value)->* q)
How is that better?
Well I anticipate certain compilers will report a warning or even an error when faced with a null pointer being dereferenced. This address dissosiates the pointer from an undefined behavior and is aligned for all types.
And made the following changes: - I have prefixed sh::list & sh::stack with "intrusive_"
You might look at Boost.Intrusive
How nice is that? member_hook<> template argument is a very nice way of implementing it. I haven't seen that class in the latest version of the code but this surely needs to be present. It looks like a intrusive::stack<> derivative will need to be implemented also. At the same time let's keep sizeof(stack_member_hook<>) == sizeof(void *) and let's make sure it can be used in an union (without constructor / destructor)... for very versatile usages. -Phil
AMDG Phil Bouchard wrote:
- I have changed the code for the following: ((T *)(alignment_of<detail::max_align>::value)->* q)
How is that better?
Well I anticipate certain compilers will report a warning or even an error when faced with a null pointer being dereferenced.
Which compilers? IMO, you shouldn't make the code even more obscure until it's known for certain to be a problem.
This address dissosiates the pointer from an undefined behavior and is aligned for all types.
5.5/4: "If the dynamic type of the object does not contain the member to which the pointer refers, the behavior is undefined." In Christ, Steven Watanabe
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47DFF458.7010409@providere-consulting.com... [...]
Which compilers? IMO, you shouldn't make the code even more obscure until it's known for certain to be a problem.
Well 0 is considered to be a null pointer, not a pointer to 0x0000. This can potentially be replaced by "nullptr" in the next revision, which shouldn't be assumed to be a pointer to 0x0000. Having a non-null constant removes this nullness ambiguity. I see there is a BOOST_PYTHON_OFFSETOF macro that exists and which uses this technique. It is unfortunate offsetof() doesn't take a real pointer-to-member address.
This address dissosiates the pointer from an undefined behavior and is aligned for all types.
5.5/4: "If the dynamic type of the object does not contain the member to which the pointer refers, the behavior is undefined."
"operator ->" can be used in an address constant expression without being considered to be a dereference because of "operator &". 5.19/4: An address constant expression is a pointer to an lvalue designating an object of static storage duration, a string literal (_lex.string_), or a function. The pointer shall be created explicitly, using the unary & operator, or implicitly using a non-type template parameter of pointer type, or using an expression of array (_conv.array_) or function (_conv.func_) type. The subscripting operator [] and the class member access . and -> operators, the & and * unary operators, and pointer casts (except dynamic_casts, _expr.dynamic.cast_) can be used in the creation of an address constant expression, but the value of an object shall not be accessed by the use of these operators. [...] -Phil
on Wed Mar 19 2008, "Phil Bouchard" <philippe-AT-fornux.com> wrote:
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47DFF458.7010409@providere-consulting.com...
[...]
Which compilers? IMO, you shouldn't make the code even more obscure until it's known for certain to be a problem.
Well 0 is considered to be a null pointer, not a pointer to 0x0000. This can potentially be replaced by "nullptr" in the next revision, which shouldn't be assumed to be a pointer to 0x0000. Having a non-null constant removes this nullness ambiguity.
I see there is a BOOST_PYTHON_OFFSETOF macro that exists and which uses this technique. It is unfortunate offsetof() doesn't take a real pointer-to-member address.
That's only there because one old compiler's "standard" offsetof macro was incorrectly generating errors, even for POD types. It's not a justification for anything; just a workaround for a broken compiler. -- Dave Abrahams Boost Consulting http://boost-consulting.com
on Thu Mar 13 2008, "Phil Bouchard" <philippe-AT-fornux.com> wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87skyvltul.fsf@gutsy.luannocracy.com...
[...]
If I understand correctly, none of this code is technically portable; it is only "portable in practice" because of the way C++ is commonly implemented. Is that correct?
It's not necessarily an argument against these proposals, but all Boost library submissions should be very clear about where they rely on unspecified or undefined behavior.
No it is perfectly portable, this function called "roofof" simply cannot be applied to classes having virtual inheritance. It can be kept as an internal routine quite simply and used with PODs and classes having simple inheritances.
sh::list<> and sh::stack<> classes can be used for different things also. I will write a pool allocator quickly using sh::list<> with the sh::roofof<> function for demonstration. I will also rename these for sh::intrusive_list<> and sh::intrusive_stack<>.
I'm sorry I wasn't clearer; I was actually referring to shifted_ptr. -- Dave Abrahams Boost Consulting http://boost-consulting.com
Hi Phil, I have received your request and have added Shifted Pointer to the review queue. Cheers, ron On Mar 10, 2008, at 6:59 AM, Phil Bouchard wrote:
Greetings Boost:
I am happy re-submitting after 4 years my final design and implementation proposal of "shifted_ptr" which includes very useful tools named "list", "stack" and "roofof". The new containers consisting of STL-like ones but offering external access to the nodes, removing the need of dynamically allocated nodes and thus offers multi-dimensional control over their elements. "roofof" is a one line helper function used in conjunction with the mentionned containers to find the root address of the class housing the member used by the container in question.
In contrast with its previous submission, "shifted_ptr" now relates to a memory manager of constant complexity and of size: sizeof(void *) * 2. It take advantage of the low-memory consuption, fast execution and very versatile interface. It proposes a very different concept, removes the need of current functions such as: "enable_shared_from_this", destroys the "cyclic pointer" problem and is now perfectly type-safe. The former reference counted smart pointer was renamed to "shifted_ptr_base" and merged properly with Boost standards.
Morever "shiifted_ptr" is closely tied to the current "shared_ptr" that uses objects derived from "sp_counted_base". This was extended to objects deriving from "owned_base", which includes the necessary information that is handled by the smart pointer plus a smart destructer that differentiates arrays from standard objects and destroys the object accordingly.
I have not yet written entirely its documentation but I have included a well documented reference to its API. I would like to schedule a review for now and by then the documentation shall be completed. I am also aware the library doesn't yet handle multi-threaded applications but I would like to start with getting the library better known. The theory behind is perfectly reliable but I can't say I forgot technical issues.
The library is located at: http://www.boost-consulting.com/vault/index.php? action=downloadfile&filename=shifted_ptr-2.0.zip&directory=Memory&
Thank you, Phil Bouchard
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
participants (4)
-
David Abrahams -
Phil Bouchard -
Ronald Garcia -
Steven Watanabe