On 1/1/13, Geoffrey Romer gro...@google.com wrote:
AFAICT there's no way to distinguish between safe and unsafe
conversions of user-defined pointers, because that's a property
of the pointer implementation, not the type itself. My PR errs on
the side of trusting the implementation to provide
On 12/28/12, Jonathan Wakely jwakely@gmail.com wrote:
On 28 December 2012 01:51, Lawrence Crowl wrote:
I'm not getting errors when converting from derived to base.
E.g. the following compiles, when it should not.
std::unique_ptrconst base [] acb_ad(new derived[3]);
I get an error:
On 1 January 2013 20:40, Lawrence Crowl wrote:
That was pilot error on my part. However, I've been having trouble
when the argument to the constructor or reset has a conversion
operator. The code does distinquish between a safe conversion to
base and an unsafe conversion to derived.
Here
On 1/1/13, Jonathan Wakely jwakely@gmail.com wrote:
On 1 January 2013 20:40, Lawrence Crowl wrote:
That was pilot error on my part. However, I've been having trouble
when the argument to the constructor or reset has a conversion
operator. The code does distinquish between a safe
On 28 December 2012 01:51, Lawrence Crowl wrote:
I'm not getting errors when converting from derived to base.
E.g. the following compiles, when it should not.
std::unique_ptrconst base [] acb_ad(new derived[3]);
I get an error:
shm$ cat up.cc
#include memory
struct base { };
struct derived
On 12/20/12, Jonathan Wakely jwakely@gmail.com wrote:
This patch started when I noticed that it's not possibly to construct
a shared_ptrT from unique_ptrT[], D, then I discovered we don't
use D::pointer if it exists, and there were a number of other
non-conformance issues with our
This patch started when I noticed that it's not possibly to construct
a shared_ptrT from unique_ptrT[], D, then I discovered we don't
use D::pointer if it exists, and there were a number of other
non-conformance issues with our std::unique_ptrT[], D. I ended up
fixing them by implementing
