Hello, Glen Fernandes has kindly contributed an implementation of make_shared_array and allocate_shared_array. These are like make_shared and allocate_shared, except that they take a size_t argument N and allocate an array of N elements. Glen has made the functions return a shared_ptr, mostly because they are non-intrusive and it's not possible to return a shared_array without changes to shared_ptr and shared_array. But we can make such changes when we put the functions in Boost. So the question is, should we? It makes almost no sense to have a function called make_shared_array that does not, in fact, make a shared_array. On the other hand, Glen posits that some people may prefer to use shared_ptr instead of shared_array in their code for various reasons, one of which is that shared_array's default constructor can throw. Opinions?
On Thu, Nov 1, 2012 at 1:07 PM, Peter Dimov <lists@pdimov.com> wrote:
Glen has made the functions return a shared_ptr, mostly because they are non-intrusive and it's not possible to return a shared_array without changes to shared_ptr and shared_array.
Why's that impossible?
But we can make such changes when we put the functions in Boost. So the question is, should we?
It makes almost no sense to have a function called make_shared_array that does not, in fact, make a shared_array. On the other hand, Glen posits that some people may prefer to use shared_ptr instead of shared_array in their code for various reasons, one of which is that shared_array's default constructor can throw.
Due to the allocation of the counter? Can't that be fixed? I'd like to see make_shared_array. I'd also like to see compatibility between shared_ptr and shared_array where they can share the counter. Shared_ptr should be able to point to an element of the array and shared_array should be able to point to an array member of the object pointed to by shared_ptr. Wouldn't mind a variant of shared_array that knows it's size either. Does Glen's make_shared_array have variants for both initialized and uninitialized allocations (for builtin types)? -- Olaf
Olaf van der Spek wrote:
On Thu, Nov 1, 2012 at 1:07 PM, Peter Dimov <lists@pdimov.com> wrote:
Glen has made the functions return a shared_ptr, mostly because they are non-intrusive and it's not possible to return a shared_array without changes to shared_ptr and shared_array.
Why's that impossible?
The implementation uses the allocator constructor and the aliasing constructor of shared_ptr, and shared_array doesn't have them.
Hi Olaf,
Wouldn't mind a variant of shared_array that knows it's size either.
There is shared_range, an iterator_range subclass with shared ownership semantics, that we put together awhile ago: https://github.com/RhysU/shared_range Any reason this doesn't meet your needs for a shared_array-that-knows-its-size? I've been happily using it for some time. - Rhys
On Thu, Nov 1, 2012 at 4:06 PM, Rhys Ulerich <rhys.ulerich@gmail.com> wrote:
Hi Olaf,
Wouldn't mind a variant of shared_array that knows it's size either.
There is shared_range, an iterator_range subclass with shared ownership semantics, that we put together awhile ago: https://github.com/RhysU/shared_range
Any reason this doesn't meet your needs for a shared_array-that-knows-its-size? I've been happily using it for some time.
But it's not in Boost. Any plans to propose it? Almost forgot about it, was weird seeing my name there. ;) -- Olaf
There is shared_range, an iterator_range subclass with shared ownership semantics, that we put together awhile ago: https://github.com/RhysU/shared_range
But it's not in Boost. Any plans to propose it?
Think it's worth proposing as a Boost.Range utility class? - Rhys
On Fri, Nov 2, 2012 at 3:27 PM, Rhys Ulerich <rhys.ulerich@gmail.com> wrote:
There is shared_range, an iterator_range subclass with shared ownership semantics, that we put together awhile ago: https://github.com/RhysU/shared_range
But it's not in Boost. Any plans to propose it?
Think it's worth proposing as a Boost.Range utility class?
I'd propose it as shared_array2. :p I think the functionality is more important than the name though and I'd definitely like to see functionality like that in Boost. -- Olaf
Olaf van der Spek wrote:
Does Glen's make_shared_array have variants for both initialized and uninitialized allocations (for builtin types)?
This is a thorny issue. Some people want initialized allocations, some don't. I'm personally in the initialized camp, so I think that make_shared_array should initialize. But there is a legitimate need to allocate big uninitialized arrays. We probably ought to provide both. So how about... make_shared_array<T>( size_t n, Args&&... args ) // uses new(pv) T( args... ) make_shared_array_noinit<T>( size_t n ) // uses new(pv) T allocate_shared_array<T>( A const& a, size_t n, Args&&... args ) // uses new(pv) T( args... ) for now, but // A::construct( pv, args... ) at some point // when std::allocator_traits becomes widespread
On Fri, Nov 2, 2012 at 1:37 AM, Peter Dimov <lists@pdimov.com> wrote:
Does Glen's make_shared_array have variants for both initialized and uninitialized allocations (for builtin types)?
This is a thorny issue. Some people want initialized allocations, some don't. I'm personally in the initialized camp, so I think that make_shared_array should initialize. But there is a legitimate need to allocate big uninitialized arrays. We probably ought to provide both. So how about...
How thorny can it be? Providing two variants seems like an easy and good solution. What's the use case for default/zero initialized arrays of builtin types though? In most of not all cases I'd expect the user to fill the array with other data. -- Olaf
John Maddock wrote:
What's the use case for default/zero initialized arrays of builtin types though?
Do you really never initialize your arrays?
Isn't this a case of "it depends"? Sometimes it's completely wasted cycles, sometimes it's essential...
It is. Olaf is arguing that there is never a need to initialize an array when the elements are of a built-in type such as double or T*.
Isn't this a case of "it depends"? Sometimes it's completely wasted cycles, sometimes it's essential...
It is. Olaf is arguing that there is never a need to initialize an array when the elements are of a built-in type such as double or T*.
...though this doesn't uniformly hold true for, e.g., doubles. In numerical algorithms, it can sometimes be natural to additively accumulate on each iteration. Initialization to zero on allocation can serve to a) simply expressing an algorithm and b) pull the data into cache prior to a compute loop. Not that a simple memset after the allocation wouldn't suffice, but the expressiveness of "give-me-a-zeroed-array-of-doubles" as a single statement is crisp at times. - Rhys
On Fri, Nov 2, 2012 at 2:55 PM, Peter Dimov <lists@pdimov.com> wrote:
John Maddock wrote:
What's the use case for default/zero initialized arrays of builtin >> types though?
Do you really never initialize your arrays?
Isn't this a case of "it depends"? Sometimes it's completely wasted cycles, sometimes it's essential...
It is. Olaf is arguing that there is never a need to initialize an array when the elements are of a built-in type such as double or T*.
No, I'm not. I'm just wondering what the use case is and how often it's used. -- Olaf
On Fri, Nov 2, 2012 at 12:37 AM, Peter Dimov <lists@pdimov.com> wrote:
Olaf van der Spek wrote:
Does Glen's make_shared_array have variants for both initialized and
uninitialized allocations (for builtin types)?
This is a thorny issue. Some people want initialized allocations, some don't. I'm personally in the initialized camp, so I think that make_shared_array should initialize. But there is a legitimate need to allocate big uninitialized arrays. We probably ought to provide both.
what about a boost::uninitialized object which is implicitly convertible to any T and will return an uninitialized T? On existing code (think std::vector<int> x(my_size, boost::uninitialized) ) there is hope that optimizing compilers may see the dead read and optimize initialization loops away, while new code may explicitly overload on the boost::uninitialized type. -- gpd
On Nov 2, 2012, at 9:33 AM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
On Fri, Nov 2, 2012 at 12:37 AM, Peter Dimov <lists@pdimov.com> wrote:
Olaf van der Spek wrote:
Does Glen's make_shared_array have variants for both initialized and
uninitialized allocations (for builtin types)?
This is a thorny issue. Some people want initialized allocations, some don't.
what about a boost::uninitialized object which is implicitly convertible to any T and will return an uninitialized T?
That would only work for built-in types and for UDTs with a default ctor that leaves the data members uninitialized. ___ Rob
Hi Peter & Glen, On Thu, Nov 1, 2012 at 6:07 AM, Peter Dimov <lists@pdimov.com> wrote:
It makes almost no sense to have a function called make_shared_array that does not, in fact, make a shared_array. On the other hand, Glen posits that some people may prefer to use shared_ptr instead of shared_array in their code for various reasons, one of which is that shared_array's default constructor can throw.
I agree that make_shared_array should return a shared_array. I would much rather see shared_array improved to allow such an allocation strategy -- I patch my local copy to have an aliasing constructor & an implicit conversion to const. A non-throwing default constructor would be very welcome too. I don't like the idea of returning shared_ptr due to concerns with implicit conversion from derived to base. Also, the lack of operator[] would make such usage unnatural (perhaps Glen uses a patched shared_ptr?) The only way I'd want a shared_ptr returned is if shared_ptr were partially specialized like unique_ptr -- i.e., I could write shared_ptr<int []>. (Not to go OT, but would a (presumably large) patch with this change be considered?) Thanks, Nate
Hi Nate, I have desired shared_ptr<T[]> for a while now; if it is considered appropriate for shared_ptr to support that I would like to help make that happen. My functions could be provided as just allocate_shared<T[]> and make_shared<T[]> in that case. I agree that while named "make_shared_array" and "allocate_shared_array" they should really return shared_array<T>. I also like the suggestions Peter had to fix shared_array (e.g. nothrow construction) and perhaps to allow obtaining a shared_ptr<T> from shared_array<T>. Glen On Thu, Nov 1, 2012 at 10:04 AM, Nathan Crookston <nathan.crookston@gmail.com> wrote:
Hi Peter & Glen,
On Thu, Nov 1, 2012 at 6:07 AM, Peter Dimov <lists@pdimov.com> wrote:
It makes almost no sense to have a function called make_shared_array that does not, in fact, make a shared_array. On the other hand, Glen posits that some people may prefer to use shared_ptr instead of shared_array in their code for various reasons, one of which is that shared_array's default constructor can throw.
I agree that make_shared_array should return a shared_array. I would much rather see shared_array improved to allow such an allocation strategy -- I patch my local copy to have an aliasing constructor & an implicit conversion to const. A non-throwing default constructor would be very welcome too.
I don't like the idea of returning shared_ptr due to concerns with implicit conversion from derived to base. Also, the lack of operator[] would make such usage unnatural (perhaps Glen uses a patched shared_ptr?)
The only way I'd want a shared_ptr returned is if shared_ptr were partially specialized like unique_ptr -- i.e., I could write shared_ptr<int []>. (Not to go OT, but would a (presumably large) patch with this change be considered?)
Thanks, Nate
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have desired shared_ptr<T[]> for a while now; if it is considered appropriate for shared_ptr to support that I would like to help make that happen. My functions could be provided as just allocate_shared<T[]> and make_shared<T[]> in that case. I'd definitely like that syntax best. I'd be happy to work on such a
Hi Glen, On Thu, Nov 1, 2012 at 5:45 PM, Glen Fernandes <glen.fernandes@gmail.com> wrote: thing as well -- I'd just want to know if it's unacceptable from the start.
I agree that while named "make_shared_array" and "allocate_shared_array" they should really return shared_array<T>. I also like the suggestions Peter had to fix shared_array (e.g. nothrow construction) and perhaps to allow obtaining a shared_ptr<T> from shared_array<T>. Due to my concerns with misusing a shared_ptr to polymorphic types, I'd want such a conversion to be as visible as possible. Given the following: shared_array<int> sa(new int[500]); shared_ptr<int> sp1(sa);//1 shared_ptr<int[]> sp2(sa);//Hypothetical 2 shared_ptr<int> sp3 = static_pointer_cast<int>(sa);//3
I'd suggest 1 wasn't explicit enough (despite being explicitly constructed), 2 would be just fine, and 3 (though overloading the function might be unwise) would be fine for those that really want it. Thanks, Nate
To me, intuitively (but also probably without the necessary historical context on shared_ptr design) I would think it was acceptable for us to work on, but then I wonder why is C++11's std::shared_ptr not already like this? Peter, is the right direction to implement T[] support in shared_ptr or to fix shared_array? Nate, I agree that it makes sense for any construction of one from the other to be explicit. Glen On Thu, Nov 1, 2012 at 5:32 PM, Nathan Crookston <nathan.crookston@gmail.com> wrote:
Hi Glen,
I have desired shared_ptr<T[]> for a while now; if it is considered appropriate for shared_ptr to support that I would like to help make that happen. My functions could be provided as just allocate_shared<T[]> and make_shared<T[]> in that case. I'd definitely like that syntax best. I'd be happy to work on such a
On Thu, Nov 1, 2012 at 5:45 PM, Glen Fernandes <glen.fernandes@gmail.com> wrote: thing as well -- I'd just want to know if it's unacceptable from the start.
I agree that while named "make_shared_array" and "allocate_shared_array" they should really return shared_array<T>. I also like the suggestions Peter had to fix shared_array (e.g. nothrow construction) and perhaps to allow obtaining a shared_ptr<T> from shared_array<T>. Due to my concerns with misusing a shared_ptr to polymorphic types, I'd want such a conversion to be as visible as possible. Given the following: shared_array<int> sa(new int[500]); shared_ptr<int> sp1(sa);//1 shared_ptr<int[]> sp2(sa);//Hypothetical 2 shared_ptr<int> sp3 = static_pointer_cast<int>(sa);//3
I'd suggest 1 wasn't explicit enough (despite being explicitly constructed), 2 would be just fine, and 3 (though overloading the function might be unwise) would be fine for those that really want it.
Thanks, Nate
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
To me, intuitively (but also probably without the necessary historical context on shared_ptr design) I would think it was acceptable for us to work on, but then I wonder why is C++11's std::shared_ptr not already like this? Howard Hinnant mentioned[1] that it was mostly because no proposal was made, and apparently experimented with such a thing himself (he
Glen, On Fri, Nov 2, 2012 at 9:36 AM, Glen Fernandes <glen.fernandes@gmail.com> wrote: maintains libc++). I'm not on the standards committee's reflectors, but there was apparently lively discussion on shared_ptr<T[]> pointer arithmetic.
Nate, I agree that it makes sense for any construction of one from the other to be explicit. Yes -- emphasizing more than just calling an explicit constructor.
Thanks, Nate [1] http://stackoverflow.com/questions/8947579/why-isnt-there-a-stdshared-ptrt-s...
Nathan Crookston wrote:
[1] http://stackoverflow.com/questions/8947579/why-isnt-there-a-stdshared-ptrt-s...
Each time the subject has come up, people have always asked for a specialization. In fact, there is no need for one as the primary template already mostly works for T[], it just needs a few small fixes here and there. We even get T[] -> T const[] conversions for free, since T(*)[] is convertible to T const(*)[]. Had I realized that before...
On Fri, Nov 2, 2012 at 10:09 AM, Peter Dimov <lists@pdimov.com> wrote:
Each time the subject has come up, people have always asked for a specialization. In fact, there is no need for one as the primary template already mostly works for T[], it just needs a few small fixes here and there. We even get T[] -> T const[] conversions for free, since T(*)[] is convertible to T const(*)[]. Had I realized that before...
Interesting. If/when the code is ready to view, I'd be curious to see how it's accomplished. Thanks, Nate
Nathan Crookston wrote:
Interesting. If/when the code is ready to view, I'd be curious to see how it's accomplished.
Voila: https://svn.boost.org/trac/boost/changeset/81149 Glen Fernandes wrote:
Maybe I (and Nate) can help you with those tests.
Thanks for the offer, but I managed. :-) You could take a look at them and see if I made some obvious mistake, since compile-fail tests pass if one does something stupid. :-)
On Fri, Nov 2, 2012 at 11:47 AM, Peter Dimov <lists@pdimov.com> wrote:
Nathan Crookston wrote:
Interesting. If/when the code is ready to view, I'd be curious to see how it's accomplished.
Voila:
https://svn.boost.org/trac/boost/changeset/81149 Very slick. Compiler errors for using operator* on a shared_ptr<T[]> are a little circuitous, but not too bad. . . though once everyone has a compiler-implemented static_assert such errors will be nicer.
I assume that, using the aliasing constructor, I'll be able to write something like the following: shared_ptr<int[]> a1(new int[500]); shared_ptr<int[]> a2(a1, &a1[250]); a1.reset();//a2 is still okay after this line.
Glen Fernandes wrote:
Maybe I (and Nate) can help you with those tests.
Thanks for the offer, but I managed. :-)
You could take a look at them and see if I made some obvious mistake, since compile-fail tests pass if one does something stupid. :-) They all looked good to me -- including the coverage.
I'm excited to update my code to use this. A few questions: Should shared_ptr<T[]> be constructable from shared_array<T>? It seems like the following syntax is possible (my toy code seemed to work): shared_ptr<B> sp1 = make_shared<B>(<B ctor args>);//1 shared_ptr<B[]> sp2 = make_shared<B[]>(number_of_B);//2: Default constructed shared_ptr<B[]> sp3 = make_shared<B[]>(number_of_B, <B ctor args>);//3: All initialized to this. shared_ptr<int[]> sp4 = make_shared<int[]>(number_of_ints);//4: uninitialized shared_ptr<int[]> sp4 = make_shared<int[]>(number_of_ints, 5);//5: all initialized to 5 Are there potential ambiguities with the previous? Thanks again for working on this. Nate
Nathan Crookston wrote:
On Fri, Nov 2, 2012 at 11:47 AM, Peter Dimov <lists@pdimov.com> wrote:
Voila:
Very slick. Compiler errors for using operator* on a shared_ptr<T[]> are a little circuitous, but not too bad. . . though once everyone has a compiler-implemented static_assert such errors will be nicer.
I think that it's possible to remove op* completely in C++11 by using a defaulted template parameter, as in template<class R = sp_dereference<T>::type> R operator* () const; with sp_dereference<T[]> not having ::type. But this means even more #ifdefs, and it's already much too #ifdef-y for my taste, so...
I assume that, using the aliasing constructor, I'll be able to write something like the following: shared_ptr<int[]> a1(new int[500]); shared_ptr<int[]> a2(a1, &a1[250]); a1.reset();//a2 is still okay after this line.
I see no reason for you to not be able to. :-)
Should shared_ptr<T[]> be constructable from shared_array<T>?
At the moment I'm inclined to leave shared_array as is, purely as a legacy, and focus on shared_ptr<T[]> as the spiffy new way forward.
It seems like the following syntax is possible (my toy code seemed to work): shared_ptr<B> sp1 = make_shared<B>(<B ctor args>);//1 shared_ptr<B[]> sp2 = make_shared<B[]>(number_of_B);//2: Default constructed shared_ptr<B[]> sp3 = make_shared<B[]>(number_of_B, <B ctor args>);//3: All initialized to this. shared_ptr<int[]> sp4 = make_shared<int[]>(number_of_ints);//4: uninitialized shared_ptr<int[]> sp4 = make_shared<int[]>(number_of_ints, 5);//5: all initialized to 5
Glen just proposed the same syntax, and I like it, although I prefer shared_ptr<int[]> sp4a = make_shared<int[]>(number_of_ints);//4a: initialized to 0 shared_ptr<int[]> sp4b = make_shared_noinit<int[]>(number_of_ints);//4b: uninitialized
On 02/11/2012 09:20 p.m., Peter Dimov wrote:
Glen just proposed the same syntax, and I like it, although I prefer
shared_ptr<int[]> sp4a = make_shared<int[]>(number_of_ints);//4a: initialized to 0 shared_ptr<int[]> sp4b = make_shared_noinit<int[]>(number_of_ints);//4b: uninitialized
I would prefer shared_ptr<int[]> sp4a = make_shared<int[]>(number_of_ints); //4a: initialized to 0 shared_ptr<int[]> sp4b = make_shared<int[]>(number_of_ints, noinit); //4b: uninitialized similar to std::nothrow, although it introduces a new type and constant for no particular benefit. Just my $0.02 Agustín K-ballo Bergé.- http://fusionfenix.com
On Fri, Nov 2, 2012 at 6:20 PM, Peter Dimov <lists@pdimov.com> wrote:
Nathan Crookston wrote:
On Fri, Nov 2, 2012 at 11:47 AM, Peter Dimov <lists@pdimov.com> wrote:
Voila:
Very slick. Compiler errors for using operator* on a shared_ptr<T[]> are a little circuitous, but not too bad. . . though once everyone has a compiler-implemented static_assert such errors will be nicer.
I think that it's possible to remove op* completely in C++11 by using a defaulted template parameter, as in
template<class R = sp_dereference<T>::type> R operator* () const;
with sp_dereference<T[]> not having ::type. But this means even more #ifdefs, and it's already much too #ifdef-y for my taste, so...
I assume that, using the aliasing constructor, I'll be able to write something like the following: shared_ptr<int[]> a1(new int[500]); shared_ptr<int[]> a2(a1, &a1[250]); a1.reset();//a2 is still okay after this line.
I see no reason for you to not be able to. :-)
Should shared_ptr<T[]> be constructable from shared_array<T>?
At the moment I'm inclined to leave shared_array as is, purely as a legacy, and focus on shared_ptr<T[]> as the spiffy new way forward. Fair enough -- I'll be planning to convert my usage to shared_ptr<T[]> when it makes it to a release.
It seems like the following syntax is possible (my toy code seemed to work): shared_ptr<B> sp1 = make_shared<B>(<B ctor args>);//1 shared_ptr<B[]> sp2 = make_shared<B[]>(number_of_B);//2: Default constructed shared_ptr<B[]> sp3 = make_shared<B[]>(number_of_B, <B ctor args>);//3: All initialized to this. shared_ptr<int[]> sp4 = make_shared<int[]>(number_of_ints);//4: uninitialized shared_ptr<int[]> sp4 = make_shared<int[]>(number_of_ints, 5);//5: all initialized to 5
Glen just proposed the same syntax, and I like it, although I prefer
shared_ptr<int[]> sp4a = make_shared<int[]>(number_of_ints);//4a: initialized to 0 shared_ptr<int[]> sp4b = make_shared_noinit<int[]>(number_of_ints);//4b: uninitialized
To be clear, is there still a version that would initialize the array to a particular value? While I'd prefer to only initialize if an initializer is given (like std::vector<int>), so long as some incantation allows me to opt-out then I'll be fine. To explain my most common use case: I personally use such arrays when dealing with imagery -- I usually allocate the array, then copy the data in from some external source. So, I'll generally call the uninitialized version. I understand other people's use cases differ. Thanks, Nate
Nathan Crookston wrote:
To be clear, is there still a version that would initialize the array to a particular value?
Yes,
shared_ptr<int[]> sp5 = make_shared<int[]>(number_of_ints, 5);
will still work.
While I'd prefer to only initialize if an initializer is given (like std::vector<int>), ...
std::vector<int> initializes to zero. :-)
On Fri, Nov 2, 2012 at 7:03 PM, Peter Dimov <lists@pdimov.com> wrote:
Nathan Crookston wrote:
While I'd prefer to only initialize if an initializer is given (like std::vector<int>), ...
std::vector<int> initializes to zero. :-)
Oops, right. I forgot it uses T() to initialize in that case. Then no complaints given a noinit version. Thanks, Nate
On Sat, Nov 3, 2012 at 1:20 AM, Peter Dimov <lists@pdimov.com> wrote:
At the moment I'm inclined to leave shared_array as is, purely as a legacy, and focus on shared_ptr<T[]> as the spiffy new way forward.
What about a variant (of either shared_ptr<T[]> or shared_array) that knows it's size and can thus be used as a range/sequence? There's demand for it too. -- Olaf
On Sat, Nov 3, 2012 at 1:11 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Sat, Nov 3, 2012 at 1:20 AM, Peter Dimov <lists@pdimov.com> wrote:
At the moment I'm inclined to leave shared_array as is, purely as a legacy, and focus on shared_ptr<T[]> as the spiffy new way forward.
What about a variant (of either shared_ptr<T[]> or shared_array) that knows it's size and can thus be used as a range/sequence? There's demand for it too.
Peter? -- Olaf
I see that a commit with the following syntax has occurred on trunk. On Fri, Nov 2, 2012 at 6:20 PM, Peter Dimov <lists@pdimov.com> wrote:
shared_ptr<int[]> sp4a = make_shared<int[]>(number_of_ints);//4a: initialized to 0 shared_ptr<int[]> sp4b = make_shared_noinit<int[]>(number_of_ints);//4b: uninitialized
I have one minor suggestion. Given that the make_shared variant which produces shared_ptr<T[]> is spelled make_shared<T[]>, I think it would be very confusing to have the following not work: #include <boost/make_shared.hpp> int main() { auto pInt = boost::make_shared<int[]>(500); return 0; } I would suggest that make_shared_array.hpp be included by make_shared.hpp -- likewise for allocate_shared. Perhaps the array header files should be placed in detail, though I think it's less confusing to include make_shared_array.hpp and not have the non-array make_shared functions. Thanks, Nate
On Nov 2, 2012, at 1:47 PM, "Peter Dimov" <lists@pdimov.com> wrote:
Nathan Crookston wrote:
Interesting. If/when the code is ready to view
Voila:
Thank you Peter! After this gets some traction, to ensure it is hardened, we'll need a proposal to add it to the Standard. I'd be willing to help with that, though I'm not likely to be able to present it. ___ Rob
Glen Fernandes wrote:
Peter, is the right direction to implement T[] support in shared_ptr or to fix shared_array?
I think that the right direction is to implement shared_ptr<T[]>. In fact, I have already done so. My problem now is that it requires 48 compile-fail tests, each in its own file. :-/
Maybe I (and Nate) can help you with those tests. On Fri, Nov 2, 2012 at 8:51 AM, Peter Dimov <lists@pdimov.com> wrote:
Glen Fernandes wrote:
Peter, is the right direction to implement T[] support in shared_ptr or to fix shared_array?
I think that the right direction is to implement shared_ptr<T[]>. In fact, I have already done so. My problem now is that it requires 48 compile-fail tests, each in its own file. :-/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Nov 2, 2012 at 9:51 AM, Peter Dimov <lists@pdimov.com> wrote:
Glen Fernandes wrote:
Peter, is the right direction to implement T[] support in shared_ptr or to fix shared_array?
I think that the right direction is to implement shared_ptr<T[]>. In fact, I have already done so. My problem now is that it requires 48 compile-fail tests, each in its own file. :-/
This is great news! (About shared_ptr<T[]>, not all the test file additions.) Thanks, Nate
participants (9)
-
Agustín K-ballo Bergé -
Giovanni Piero Deretta -
Glen Fernandes -
John Maddock -
Nathan Crookston -
Olaf van der Spek -
Peter Dimov -
Rhys Ulerich -
Rob Stewart