-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
83 lines (60 loc) · 3.43 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
========================
unique_ptr for C++03
(c) 2013 Andrew Ho
Distributed under the Boost Software License, Version 1.0. (See
accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt)
========================
This library provides C++11 unique_ptr for C++03 compilers.
It tries to emulate standard behavior as closely as possible.
The library will map to standard features when available.
Some implementation details borrowed from Howard Hinnant's implementation:
http://home.roadrunner.com/~hinnant/unique_ptr03.html
============
Dependencies (only used when standard features not available)
============
Boost.Move (maps to standard features when available)
Boost.TypeTraits
Boost.Config
============
Limitations
============
- There is provisional support for nullptr/nullptr_t emulated using nat's (not a type, basically undefined/hidden classes).
Anywhere nullptr is used, you should be able to use NULL. However, using NULL is ambiguous under C++11...
Perhaps we could expose BOOST_NULLPTR used internally to switch between NULL and nullptr?
- The class is not "move-constructable" from a std::auto_ptr if the compiler does not support true rvalue references.
To move an auto_ptr's resource to a unique_ptr in a C++03/C++11 independent manner:
my_uptr(my_aptr.release());
- unique_ptr can only be stored in move-aware containers. Unfortunately, C++03 containers such as std::vector, std::map, etc. are not move aware.
This isn't necessarily a limitation of this implementation, but of the container implementation.
- swap can't perfectly forward deleters/user-defined pointers without C++11. I'm unsure of a good way around this.
There might be limited applications for argument dependent lookup, though I have my doubts this is a preferred solution.
The implementation doesn't use std::swap directly, just swap.
============
Usage/Building
============
This is a header-only library.
To use this class, include <boost/unique_ptr.hpp>.
For std::default_delete emulation you can include <boost/default_delete.hpp> (this is included by boost/unique_ptr.hpp).
All items are found in the boost namespace. See the standard C++11 library documentation for library documentation.
===========
Notes
===========
http://cplusplus.github.io/LWG/lwg-active.html#2118
The C++11 standard currently mandates that a unique_ptr<T[], D> is only move-constructable/move-assignable from a unique_ptr<U[], E>
iff U[] is the same as T[] and D is the same as E.
This prevents code like this:
unique_ptr<T[], D> uptr1;
unique_ptr<T[], D&> uptr2(move(uptr1));
However, this limitation is not placed on single element unique_ptr.
This implementation allows this to compile while a C++11 standard library implementation might not.
The change basically allows for similar construction semantics as single element unique_ptr.
Note that unique_ptr<U[]> is still not move-constructable/move-assignable from a unique_ptr<T[]> if U is a child of T.
Testing with GCC 4.8.1, I have found this change also applied.
===========
TODO
===========
As part of C++14's working draft it has been proposed/accepted to include make_unique.
There are plans to include this in this library, but it has not been implemented yet.
Compile time tests are done. Unless stated in the limitations, code which should compile with C++11 std::unique_ptr will compile with this
emulation, and code which should fail to compile do fail to compile. Runtime verification of results are still in the works.