C++03 unique_ptr emulation

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

C++03 unique_ptr emulation

Howard Hinnant
I've put up a new version of an C++03 emulated unique_ptr here:

http://home.roadrunner.com/~hinnant/unique_ptr03.html

This is a "boost-ized" emulation (uses boost tools and is in boost  
namespace), though I have reason to believe it may not work well on VC+
+05 unless the /Za option is used (I've tested only on gcc 4.0).

I'm aware of Ion's interprocess version (http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/interprocess_smart_ptr.html#interprocess.interprocess_smart_ptr.unique_ptr 
), and thank Ion for his support over the years.  This new version is  
not meant to replace Ion's version. It is simply my current best shot  
at emulating the unique_ptr behavior as specified in the C++0X CD1  
draft.  Booster's are welcome to take parts of this implementation and  
use them in places like interprocess/unique_ptr.  Or to just use this  
unique_ptr directly.  It consists of only one header: unique_ptr.hpp,  
and requires only boost headers, not boost cpp files.

Basic documentation is included at the link.

-Howard

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

Re: C++03 unique_ptr emulation

Ion Gaztañaga
Howard Hinnant wrote:
> I've put up a new version of an C++03 emulated unique_ptr here:
>
> http://home.roadrunner.com/~hinnant/unique_ptr03.html
>
> This is a "boost-ized" emulation (uses boost tools and is in boost
> namespace), though I have reason to believe it may not work well on
> VC++05 unless the /Za option is used (I've tested only on gcc 4.0).

Great!

> I'm aware of Ion's interprocess version
> (http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/interprocess_smart_ptr.html#interprocess.interprocess_smart_ptr.unique_ptr),
> and thank Ion for his support over the years.  This new version is not
> meant to replace Ion's version. It is simply my current best shot at
> emulating the unique_ptr behavior as specified in the C++0X CD1 draft.  
> Booster's are welcome to take parts of this implementation and use them
> in places like interprocess/unique_ptr.  Or to just use this unique_ptr
> directly.  It consists of only one header: unique_ptr.hpp, and requires
> only boost headers, not boost cpp files.

I would be really glad if I could just drop Interprocess' own version,
since your version also covers non-raw pointers. I've seen that move
emulation is done using a conversion operator (I think Boost.Thread uses
the same technique), is that mechanism the best way to achieve this?

Interprocess' own move-semantics are based on Dave Abramams good old
move library so we already have different solutions for the same
problem. I'm aware also of Adobe's Move library but that library
requires Regular types (copy constructible).

It would be great if we could adopt your unique_ptr version and agree a
general move emulation protocol so that we can make Boost libraries
interoperable. Interprocess containers already support emplace and move
semantics so we can have containers of unique_ptrs or boost::threads.

Regards,

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

Re: C++03 unique_ptr emulation

Howard Hinnant
On Jan 2, 2009, at 6:45 PM, Ion Gaztañaga wrote:

> I've seen that move emulation is done using a conversion operator (I  
> think Boost.Thread uses the same technique), is that mechanism the  
> best way to achieve this?

It is my current best effort. :-\  It does not have the move-from-
const bug that my previous effort had.  And it does not require  
clients to be aware of the "rv" or "moved-from" type (which is a  
characteristic I really like).  In this emulation I've made that type  
private to emphasize the encapsulation of it from clients wanting to  
move unique_ptr's.

> Interprocess' own move-semantics are based on Dave Abramams good old  
> move library so we already have different solutions for the same  
> problem. I'm aware also of Adobe's Move library but that library  
> requires Regular types (copy constructible).

<nod>

> It would be great if we could adopt your unique_ptr version and  
> agree a general move emulation protocol so that we can make Boost  
> libraries interoperable.

Agreed.  The thing I like about my current effort is that clients see  
either lvalue or rvalue unique_ptr's (or whatever class you're trying  
to move-enable) and nothing else.  No moved-from wrappers.  Downsides  
include the fact that move(unique_ptr) is a friend of unique_ptr - a  
tight coupling that I would rather not have there.  In C++0X, move is  
a completely generic std-function, a characteristic not achieved by  
this emulation.

> Interprocess containers already support emplace and move semantics  
> so we can have containers of unique_ptrs or boost::threads.

Great! :-)

-Howard

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

Re: C++03 unique_ptr emulation

Dave Abrahams

on Fri Jan 02 2009, Howard Hinnant <hinnant-AT-twcny.rr.com> wrote:

> Agreed.  The thing I like about my current effort is that clients see either lvalue or
> rvalue unique_ptr's (or whatever class you're trying  to move-enable) and nothing
> else.  No moved-from wrappers.  Downsides include the fact that move(unique_ptr) is a
> friend of unique_ptr - a  tight coupling that I would rather not have there.  In
> C++0X, move is  a completely generic std-function, a characteristic not achieved by
> this emulation.

Howard, do you have a test suite I can throw at this?  I'd like to see
if I can decouple that thing for you.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: C++03 unique_ptr emulation

Howard Hinnant
On Jan 2, 2009, at 8:56 PM, David Abrahams wrote:

>
> on Fri Jan 02 2009, Howard Hinnant <hinnant-AT-twcny.rr.com> wrote:
>
>> Agreed.  The thing I like about my current effort is that clients  
>> see either lvalue or
>> rvalue unique_ptr's (or whatever class you're trying  to move-
>> enable) and nothing
>> else.  No moved-from wrappers.  Downsides include the fact that  
>> move(unique_ptr) is a
>> friend of unique_ptr - a  tight coupling that I would rather not  
>> have there.  In
>> C++0X, move is  a completely generic std-function, a characteristic  
>> not achieved by
>> this emulation.
>
> Howard, do you have a test suite I can throw at this?  I'd like to see
> if I can decouple that thing for you.

Although I've been running tests, I don't really yet have a neatly  
packaged test suite.  Part of the problem is that many of the tests  
are "must fail" and I don't know of a portable/automated way to handle  
that kind of test.  Has boost addressed "must fail" tests?

-Howard

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

Re: C++03 unique_ptr emulation

Sebastian Redl
Howard Hinnant wrote:
>
> Although I've been running tests, I don't really yet have a neatly
> packaged test suite.  Part of the problem is that many of the tests
> are "must fail" and I don't know of a portable/automated way to handle
> that kind of test.  Has boost addressed "must fail" tests?
Isn't that what compile-fail Jam instructions are for? Just remember to
put each test case in its own file, or failures will be masked.

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

Re: C++03 unique_ptr emulation

Howard Hinnant
On Jan 3, 2009, at 10:51 AM, Sebastian Redl wrote:

> Howard Hinnant wrote:
>>
>> Although I've been running tests, I don't really yet have a neatly
>> packaged test suite.  Part of the problem is that many of the tests
>> are "must fail" and I don't know of a portable/automated way to  
>> handle
>> that kind of test.  Has boost addressed "must fail" tests?
> Isn't that what compile-fail Jam instructions are for? Just remember  
> to
> put each test case in its own file, or failures will be masked.

I've never used Jam before.  I'll take a look.

-Howard

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

Re: C++03 unique_ptr emulation

Thomas Klimpel
Howard Hinnant wrote:
> I've never used Jam before.  I'll take a look.

It may be a good idea to take the documentation from the side

http://beta.boost.org/doc/

instead of the side

http://www.boost.org/doc/

There seem to be some subtle issues that sometimes prevent the proper updating of the documentation at http://www.boost.org/doc/ (track tickets for this have been filled multiple times). This has hit me when I tried to learn Boost.Build, because I downloaded the (extremely) outdated manual

http://www.boost.org/doc/libs/1_37_0/tools/build/v2/doc/userman.pdf

instead of the current one

http://beta.boost.org/doc/libs/1_37_0/tools/build/v2/doc/userman.pdf

and then subscribed to boost.build asking silly questions that would have been covered at length in the current version of the manual.

A recent message from Steven Watanabe ("This has been available on the beta site since November
http://beta.boost.org/doc/libs/1_37_0?view=categorized
but hasn't been merged to the live site.") just reminded me of this, so I checked and found out that the problems are not resolved yet.


I learned from the comments at the tickets that this is something more subtle/difficult than a simple merge, but as long as these issues are not resolved, it seems better to recommend http://beta.boost.org/doc instead of http://www.boost.org/doc.

Regards,
Thomas

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

winmail.dat (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++03 unique_ptr emulation

Howard Hinnant
On Jan 3, 2009, at 12:56 PM, Thomas Klimpel wrote:

> Howard Hinnant wrote:
>> I've never used Jam before.  I'll take a look.
>
> It may be a good idea to take the documentation from the side
>
> http://beta.boost.org/doc/
>
> instead of the side
>
> http://www.boost.org/doc/
>
> There seem to be some subtle issues that sometimes prevent the  
> proper updating of the documentation at http://www.boost.org/doc/ 
> (track tickets for this have been filled multiple times). This has  
> hit me when I tried to learn Boost.Build, because I downloaded the  
> (extremely) outdated manual
>
> http://www.boost.org/doc/libs/1_37_0/tools/build/v2/doc/userman.pdf
>
> instead of the current one
>
> http://beta.boost.org/doc/libs/1_37_0/tools/build/v2/doc/userman.pdf
>
> and then subscribed to boost.build asking silly questions that would  
> have been covered at length in the current version of the manual.
>
> A recent message from Steven Watanabe ("This has been available on  
> the beta site since November
> http://beta.boost.org/doc/libs/1_37_0?view=categorized
> but hasn't been merged to the live site.") just reminded me of this,  
> so I checked and found out that the problems are not resolved yet.
>
>
> I learned from the comments at the tickets that this is something  
> more subtle/difficult than a simple merge, but as long as these  
> issues are not resolved, it seems better to recommend http://beta.boost.org/doc 
>  instead of http://www.boost.org/doc.

Thanks much Thomas.

-Howard

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

Re: C++03 unique_ptr emulation

Thomas Klimpel
Thomas Klimpel wrote:

> This has  
> hit me when I tried to learn Boost.Build, because I downloaded the  
> (extremely) outdated manual
>
> http://www.boost.org/doc/libs/1_37_0/tools/build/v2/doc/userman.pdf
>
> instead of the current one
>
> http://beta.boost.org/doc/libs/1_37_0/tools/build/v2/doc/userman.pdf
>
> and then subscribed to boost.build asking silly questions that would  
> have been covered at length in the current version of the manual.
Interestingly enough, the above references are both outdated, and both

http://www.boost.org/doc/tools/build/doc/userman.pdf
http://beta.boost.org/doc/tools/build/doc/userman.pdf

seem to be up to date. I just tried reproducing my problems, but now both http://www.boost.org/doc and http://beta.boost.org/doc seem to point me to the correct versions (I can't remember what I did differently some seconds before). Now I'm confused. Perhaps it's really just a simple merge issue?

> Thanks much Thomas.

Sorry for the confusion.

Regards,
Thomas

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

winmail.dat (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++03 unique_ptr emulation

Beman Dawes
In reply to this post by Howard Hinnant
On Sat, Jan 3, 2009 at 11:08 AM, Howard Hinnant <[hidden email]> wrote:

> On Jan 3, 2009, at 10:51 AM, Sebastian Redl wrote:
>
>> Howard Hinnant wrote:
>>>
>>> Although I've been running tests, I don't really yet have a neatly
>>> packaged test suite.  Part of the problem is that many of the tests
>>> are "must fail" and I don't know of a portable/automated way to handle
>>> that kind of test.  Has boost addressed "must fail" tests?
>>
>> Isn't that what compile-fail Jam instructions are for? Just remember to
>> put each test case in its own file, or failures will be masked.
>
> I've never used Jam before.  I'll take a look.

It is a lot of work to gain even a moderately deep understanding of
bjam, but if you treat it like magic, some of the simpler incantations
are very easy to learn. compile-fail tests fall in the simple
category.

In https://svn.boost.org/svn/boost/sandbox/chrono, take a look at
libs/chrono/test/Jamfile.v2 and ratio_fail_test1.cpp.

If I run "bjam --toolset gcc", note that the test is reported as
"**passed**", because there were compile errors.

Temporarily change ratio_fail_test1.cpp so that the ratio multiply
doesn't overflow, and the compile will work but the test will be
reported as failing

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

Re: C++03 unique_ptr emulation

Howard Hinnant
On Jan 3, 2009, at 1:28 PM, Beman Dawes wrote:

> On Sat, Jan 3, 2009 at 11:08 AM, Howard Hinnant  
> <[hidden email]> wrote:
>> On Jan 3, 2009, at 10:51 AM, Sebastian Redl wrote:
>>
>>> Howard Hinnant wrote:
>>>>
>>>> Although I've been running tests, I don't really yet have a neatly
>>>> packaged test suite.  Part of the problem is that many of the tests
>>>> are "must fail" and I don't know of a portable/automated way to  
>>>> handle
>>>> that kind of test.  Has boost addressed "must fail" tests?
>>>
>>> Isn't that what compile-fail Jam instructions are for? Just  
>>> remember to
>>> put each test case in its own file, or failures will be masked.
>>
>> I've never used Jam before.  I'll take a look.
>
> It is a lot of work to gain even a moderately deep understanding of
> bjam, but if you treat it like magic, some of the simpler incantations
> are very easy to learn. compile-fail tests fall in the simple
> category.
>
> In https://svn.boost.org/svn/boost/sandbox/chrono, take a look at
> libs/chrono/test/Jamfile.v2 and ratio_fail_test1.cpp.
>
> If I run "bjam --toolset gcc", note that the test is reported as
> "**passed**", because there were compile errors.
>
> Temporarily change ratio_fail_test1.cpp so that the ratio multiply
> doesn't overflow, and the compile will work but the test will be
> reported as failing

Forget pictures.  A good example is truly worth a thousand words! :-)

Thanks Beman.

-Howard

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

Re: C++03 unique_ptr emulation

Howard Hinnant
In reply to this post by Beman Dawes
On Jan 3, 2009, at 1:28 PM, Beman Dawes wrote:

> It is a lot of work to gain even a moderately deep understanding of
> bjam, but if you treat it like magic, some of the simpler incantations
> are very easy to learn. compile-fail tests fall in the simple
> category.
>
> In https://svn.boost.org/svn/boost/sandbox/chrono, take a look at
> libs/chrono/test/Jamfile.v2 and ratio_fail_test1.cpp.
>
> If I run "bjam --toolset gcc", note that the test is reported as
> "**passed**", because there were compile errors.
>
> Temporarily change ratio_fail_test1.cpp so that the ratio multiply
> doesn't overflow, and the compile will work but the test will be
> reported as failing

Despite the good and generous help, I'm afraid I'm running out of time  
to learn how to use bjam for testing compile time failures.  Here's  
where I'm at:

$ pwd
<snip>/Development/unique_ptr
$ printenv
<snip>
BOOST_ROOT=<snip>/Development/boost-dev/boost-trunk
$ ls
Jamfile.v2 unique_ptr.hpp unique_ptr_fail_test1.cpp
$ cat Jamfile.v2
# Boost unique_ptr Library test Jamfile

# Copyright Howard Hinnant 2009

# Distributed under the Boost Software License, Version 1.0.
# See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt

# See library home page at http://www.boost.org/libs/chrono

project
     : requirements

     ;

    test-suite "unique_ptr"
        :
          [ compile-fail unique_ptr_fail_test1.cpp ]
          ;
$ bjam --toolset gcc
error: Could not find parent for project at '.'
error: Did not find Jamfile.jam or Jamroot.jam in any parent directory.

I'm afraid I don't know what a "parent for project" is.  And while I  
could put an empty Jamfile.jam in a parent directory, I doubt that  
would help much.

Fwiw, the starter docs I have at http://home.roadrunner.com/~hinnant/unique_ptr03.html 
  have both positive and negative example code.  I fear I don't have  
the cycles to really boost-ize this code.  I hope that it is useful to  
some people anyway.

-Howard

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

Re: C++03 unique_ptr emulation

Ion Gaztañaga
In reply to this post by Howard Hinnant
Howard Hinnant wrote:

> On Jan 2, 2009, at 6:45 PM, Ion Gaztañaga wrote:
>
>> I've seen that move emulation is done using a conversion operator (I
>> think Boost.Thread uses the same technique), is that mechanism the
>> best way to achieve this?
>
> It is my current best effort. :-\  It does not have the move-from-const
> bug that my previous effort had.  And it does not require clients to be
> aware of the "rv" or "moved-from" type (which is a characteristic I
> really like).  In this emulation I've made that type private to
> emphasize the encapsulation of it from clients wanting to move
> unique_ptr's.

Ok. For some vector and deque code I've used the is_movable<> trait to
select move_iterator or just raw pointers for internal copies. Maybe
this is still necessary with your conversion operator code. Although a
smart move_iterator could do the job, using raw pointers in those cases
automatically takes advantage of STL uninitialized_copy/copy functions
that automatically use memcpy.

> Agreed.  The thing I like about my current effort is that clients see
> either lvalue or rvalue unique_ptr's (or whatever class you're trying to
> move-enable) and nothing else.  No moved-from wrappers.  Downsides
> include the fact that move(unique_ptr) is a friend of unique_ptr - a
> tight coupling that I would rather not have there.  In C++0X, move is a
> completely generic std-function, a characteristic not achieved by this
> emulation.

Well, not a big problem if the emulation works!

Regards,

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

Re: C++03 unique_ptr emulation

Sebastian Redl
In reply to this post by Howard Hinnant
Howard Hinnant wrote:
> Despite the good and generous help, I'm afraid I'm running out of time
> to learn how to use bjam for testing compile time failures.  Here's
> where I'm at:
> error: Could not find parent for project at '.'
> error: Did not find Jamfile.jam or Jamroot.jam in any parent directory.
>
> I'm afraid I don't know what a "parent for project" is.  And while I
> could put an empty Jamfile.jam in a parent directory, I doubt that
> would help much.
Simply put, Jam thinks of projects as hierarchical. There's the root
project, which is basically "everything that concerns the application"
and there's sub-projects, such as individual libraries, or individual
tools in a tool suite. In Boost, the root project is Boost itself, while
every library is a sub-project. Sub-projects can be further divided,
e.g. into an executable and a test suite.
The root project is controlled by a Jamroot file, while sub-projects use
Jamfile files. If Jam finds a Jamfile, it walks the directory hierarchy
upwards, collecting parent Jamfiles, until it hits the Jamroot - or the
hierarchy root and errors out. The parent projects can introduce
additional names, variables, requirements and dependencies.

So basically, Jam is complaining because you used a Jamfile when your
little project is already the root of all things.

Anyway, I'll try to boostify your project and post back.

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

Re: C++03 unique_ptr emulation

Howard Hinnant
On Jan 3, 2009, at 3:45 PM, Sebastian Redl wrote:

> Howard Hinnant wrote:
>> Despite the good and generous help, I'm afraid I'm running out of  
>> time
>> to learn how to use bjam for testing compile time failures.  Here's
>> where I'm at:
>> error: Could not find parent for project at '.'
>> error: Did not find Jamfile.jam or Jamroot.jam in any parent  
>> directory.
>>
>> I'm afraid I don't know what a "parent for project" is.  And while I
>> could put an empty Jamfile.jam in a parent directory, I doubt that
>> would help much.
> Simply put, Jam thinks of projects as hierarchical. There's the root
> project, which is basically "everything that concerns the application"
> and there's sub-projects, such as individual libraries, or individual
> tools in a tool suite. In Boost, the root project is Boost itself,  
> while
> every library is a sub-project. Sub-projects can be further divided,
> e.g. into an executable and a test suite.
> The root project is controlled by a Jamroot file, while sub-projects  
> use
> Jamfile files. If Jam finds a Jamfile, it walks the directory  
> hierarchy
> upwards, collecting parent Jamfiles, until it hits the Jamroot - or  
> the
> hierarchy root and errors out. The parent projects can introduce
> additional names, variables, requirements and dependencies.
>
> So basically, Jam is complaining because you used a Jamfile when your
> little project is already the root of all things.
>
> Anyway, I'll try to boostify your project and post back.

That is very kind of you.

I've added some tests here:

http://home.roadrunner.com/~hinnant/unique_ptr03.html

I've written a simple bash shell script to handle must-fail tests.  
The testsuite isn't complete, but it is a decent start.  It is fairly  
self-explanatory if you have a bash shell.  Just:

$ ./test
pass

(assuming permissions translate in the zip).  One may have to:

$ chmod 755 test

first.  Oh, and you'll have to change:

INCLUDE="-I/Users/hinnant/Development/boost-dev/boost-trunk -I.."

to point to your boost installation.

-Howard

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

Re: C++03 unique_ptr emulation

Sebastian Redl
Howard Hinnant wrote:
> On Jan 3, 2009, at 3:45 PM, Sebastian Redl wrote:
>
>>
>> Anyway, I'll try to boostify your project and post back.
>
> That is very kind of you.
I did something somewhat simpler. Attached is a patch against Boost
trunk that makes unique_ptr a part of the smart_ptr library, as far as
the header and the tests are concerned. (Those are some of the examples,
not the tests you just uploaded.) The patch does not modify
smart_ptr.hpp, though.
The tests are now executed as part of the normal test suite, and they
all pass. They are somewhat incomplete, though.

Sebastian

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

unique_ptr.patch (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++03 unique_ptr emulation

Howard Hinnant
On Jan 3, 2009, at 4:45 PM, Sebastian Redl wrote:

> Howard Hinnant wrote:
>> On Jan 3, 2009, at 3:45 PM, Sebastian Redl wrote:
>>
>>>
>>> Anyway, I'll try to boostify your project and post back.
>>
>> That is very kind of you.
> I did something somewhat simpler. Attached is a patch against Boost
> trunk that makes unique_ptr a part of the smart_ptr library, as far as
> the header and the tests are concerned. (Those are some of the  
> examples,
> not the tests you just uploaded.) The patch does not modify
> smart_ptr.hpp, though.
> The tests are now executed as part of the normal test suite, and they
> all pass. They are somewhat incomplete, though.

Thanks Sebastian.  I'll continue to make incremental improvements to http://home.roadrunner.com/~hinnant/unique_ptr03.html 
  , and hopefully the goal of simply exposing more C++ programmers to  
a preview of std::unique_ptr will be realized.

-Howard

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

Re: C++03 unique_ptr emulation

Howard Hinnant
On Jan 3, 2009, at 6:41 PM, Howard Hinnant wrote:

> On Jan 3, 2009, at 4:45 PM, Sebastian Redl wrote:
>
>> Howard Hinnant wrote:
>>> On Jan 3, 2009, at 3:45 PM, Sebastian Redl wrote:
>>>
>>>>
>>>> Anyway, I'll try to boostify your project and post back.
>>>
>>> That is very kind of you.
>> I did something somewhat simpler. Attached is a patch against Boost
>> trunk that makes unique_ptr a part of the smart_ptr library, as far  
>> as
>> the header and the tests are concerned. (Those are some of the  
>> examples,
>> not the tests you just uploaded.) The patch does not modify
>> smart_ptr.hpp, though.
>> The tests are now executed as part of the normal test suite, and they
>> all pass. They are somewhat incomplete, though.
>
> Thanks Sebastian.  I'll continue to make incremental improvements to http://home.roadrunner.com/~hinnant/unique_ptr03.html 
>  , and hopefully the goal of simply exposing more C++ programmers to  
> a preview of std::unique_ptr will be realized.

I've uploaded what is I think a fairly complete unique_ptr.hpp and  
testsuite to:

    http://home.roadrunner.com/~hinnant/unique_ptr03.html

If you download the zip, you get the header + testsuite.  The  
testsuite is hierarchical, organized according to N2800's  
[unique.ptr].  One can:

$ export CC=g++
$ export BOOST_INCLUDE="-I/<path-to>/boost-trunk"
$ export SOURCE_INCLUDE="-I/<path-to-unique_ptr.hpp>"

And then cd into any directory under unique.ptr and:

$ ./test

(assumes bash-compatible environment)

This allows you to test as little or as much of the unique_ptr  
testsuite as you want, by cd'ing up or down and just testing what is  
under your pwd.

I haven't put it into a boost sandbox.  I have no objection if someone  
does (and adds-to/modifies it).  I've included Ion on the copyright  
list as I felt I used some of his code.  If you're not comfortable  
with that Ion, just let me know.  If I've missed someone who should be  
on there, please let me know.  I've done a poor job of keeping track  
of who's contributed what and would like to give credit where credit  
is due.

If you want to add to the testsuite it is pretty self-explanatory.  
Just create a test and have the name end with ".pass.cpp" if the test  
is supposed to pass (return 0 on success).  If the test is supposed to  
fail at compile time, name it ending with ".fail.cpp".

Noteworthy points:

*  3 of the tests currently fail for me (fail at compile time,  
supposed to compile, run and pass).  These are all associated with the  
converting constructor specified in [unique.ptr.single.ctor].  When  
the source and target are of different type, this emulation demands  
that the conversion be explicit, and refuses to compile on implicit  
conversions:

unique_ptr<base> b(unique_ptr<derived>());  // ok

unique_ptr<base> b = unique_ptr<derived>();  // causes 3 compile time  
failures under unique.ptr/unique.ptr.single/unique.ptr.single.ctor

I consider this not bad for an emulation.  And otherwise things look  
pretty good.  I was able to get more working than I thought I would.

*  I implemented my own boost::detail::is_convertible instead of using  
boost::is_convertible.  My version does not handle function, array,  
void or abstract types, but does handle move-only types (this is all  
unique_ptr needs) by considering the From to be an rvalue.  The  
implementation is a little squirrelly in that it is different  
depending upon whether From and To are the same type or not.  I  
suspect, but do not know for sure, that this is related to CWG issue  
291 (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#291)  
which has Dave Abraham's fingerprints on it (fwiw I am in favor of the  
resolution of this issue).  A version which took into account array,  
function, void and abstract types could be built upon this (but  
probably wouldn't work for move-only abstract types unless rvalue  
references were supported by the compiler).

*  I implemented an abbreviated version of boost::compressed_pair  
(named detail::unique_ptr_storage) for similar reasons as above:  The  
boost version lacked support for move-only types and unique_ptr needs  
it.  I implemented as little as possible to get unique_ptr up and  
going.  A move-aware compressed_pair (or space-optimizing, move-aware  
tuple) would be most interesting, but is not addressed herein.

*  There are namespace scope definitions for move and forward.  They  
aren't perfect, but they aren't too bad.  There's no doubt there's  
still a little room for improvement on forward (and a unique_ptr test  
to detect any such changes).

*  The move-only class author must know about boost::detail::rv  
(unique_ptr demonstrates use).  The move-only class client needs to  
know only about boost::move and boost::forward.

*  A C++0X version of unique_ptr is not addressed here.  Perhaps it  
will be in the future, I don't know right now.

*  No doubt others (and myself) will find good ways to improve both  
the implementation and testsuite.  But this is the first version I'm  
willing to call fairly complete.  I believe there are 151 tests:  63  
that are supposed to pass and 88 that are supposed to fail.

*  This was all tested on g++ 4.0.  I have no idea what it will take  
to get it working on other compilers.  To the best of my knowledge, it  
should work on any conforming C++03 compiler.

*  This exercise generated one LWG issue against unique_ptr (which I  
haven't yet posted).  As currently specified a unique_ptr<A[],  
Deleter> may convert to a unique_ptr<A, Deleter>.  This implementation  
and testsuite has a test demanding this not happen, and I will get an  
LWG posted to this effect.

-Howard

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

Re: C++03 unique_ptr emulation

Sebastian Redl

On Wed, 7 Jan 2009 20:40:13 -0500, Howard Hinnant <[hidden email]>
wrote:

>
> Noteworthy points:
>
> *  3 of the tests currently fail for me (fail at compile time,  
> supposed to compile, run and pass).  These are all associated with the  
> converting constructor specified in [unique.ptr.single.ctor].  When  
> the source and target are of different type, this emulation demands  
> that the conversion be explicit, and refuses to compile on implicit  
> conversions:
>
> unique_ptr<base> b(unique_ptr<derived>());  // ok
>
> unique_ptr<base> b = unique_ptr<derived>();  // causes 3 compile time  
> failures under unique.ptr/unique.ptr.single/unique.ptr.single.ctor
>
> I consider this not bad for an emulation.  And otherwise things look  
> pretty good.  I was able to get more working than I thought I would.
>

This is consistent with the conversions I could not get to work in my Clang
smart pointers.

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