unique_ptr for C++03

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: unique_ptr for C++03

Andrew Ho-2
Markus Mathes <markus.mathes <at> dectris.com> writes:

> Also the commented out code works for me, but I'm basically only using the
> [] operator. For gcc 4.6 to compile its only missing the headers for if_
> and enable_if and some corresponding namespace issues. To me it looks the
> main issue is to get the boost::interprocess way of integration right.
>

At this point it is significantly easier for me to take bits and pieces from
Interprocess unique_ptr or Howard's unique_ptr implementation than start from
either of them and work towards standard compliance (mainly due to handling of
references). I have vetted my implementation to the standard text to get as
close to standard behavior as possible, and implemented the library to use
C++11 features if available.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: unique_ptr for C++03

Andrew Ho-2
In reply to this post by Markus Mathes
> Also the commented out code works for me, but I'm basically only using the
> [] operator. For gcc 4.6 to compile its only missing the headers for if_
> and enable_if and some corresponding namespace issues. To me it looks the
> main issue is to get the boost::interprocess way of integration right.
>
> Markus Mathes

At this time it's significantly easier for me to incorporate bits from
Interprocess unique_ptr or Howard's unique_ptr into my implementation than
try to get either of these implementations to be standard compliant. I have
vetted my implementation to the standard text and it works as expected in
nearly all cases.

The main outstanding detail missing in my implementation that is solved with
Interprocess's implementation is emulating a nullptr_t (Interprocess uses a
nat*).

To get Interprocess updated to be standard compliant and use C++11 features
if available, there are quite a lot of changes required (many minor, a few
fairly large, I listed the ones I immediately found previously).

I can't think of any good methods for getting around the remaining problems
with standard compliance which no C++03 implementation I've seen solves:

1. No construction from std::auto_ptr&&. std::auto_ptr isn't marked as boost
movable, so boost::move doesn't return a BOOST_RV_REF(auto_ptr). I've pretty
much accepted this as a limitation of any C++03 implementation.

2. std::swap isn't move aware. This forces an extra requirement on
deleter_type to be copy-assignable, or use ADL swap. Again, I don't see any
way around this without introducing some non-standard mechanism for move-
aware swap.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: unique_ptr for C++03

Andrew Ho-2
In reply to this post by Markus Mathes
Hi,

> Also the commented out code works for me, but I'm basically only using the
> [] operator. For gcc 4.6 to compile its only missing the headers for if_
> and enable_if and some corresponding namespace issues. To me it looks the
> main issue is to get the boost::interprocess way of integration right.
>
> Markus Mathes

At this time it's significantly easier for me to incorporate bits from
Interprocess unique_ptr or Howard's unique_ptr into my implementation than
try to get either of these implementations to be standard compliant. I have
vetted my implementation to the standard text and it works as expected in
nearly all cases.

The main outstanding detail missing in my implementation that is solved with
Interprocess's implementation is emulating a nullptr_t (Interprocess uses a
nat*). It should be fairly straight forward to extract the code from
Interprocess to get this functionality in my implementation.

To get Interprocess updated to be standard compliant and use C++11 features
if available, there are quite a lot of changes required (many minor, a few
fairly large, I listed the ones I immediately found previously).

I can't think of any good methods for getting around the remaining problems
with standard compliance which no C++03 implementation I've seen solves:

1. No construction from std::auto_ptr&&. std::auto_ptr isn't marked as boost
movable, so boost::move doesn't return a BOOST_RV_REF(auto_ptr). I've pretty
much accepted this as a limitation of any C++03 implementation.

2. std::swap isn't move aware. This forces an extra requirement on
deleter_type to be copy-assignable, or use ADL swap. Again, I don't see any
way around this without introducing some non-standard mechanism for move-
aware swap.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: unique_ptr for C++03

Andrew Ho-2
In reply to this post by Andrew Ho-2
hmm... that's odd that the mailing list wasn't accepting my posts for a while.

Sorry for spamming the list. FYI, this list post is the one I wanted to keep.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12