Anyone have opinions on whether the cast machinery should be taught to handle unique_ptr? Presumably that'd involve cast, etc, returning raw pointers when it was passed references to unique_ptr, which might be surprising/error-prone? But the only errors would be: 1) double delete - if the result of the cast was used to take ownership because the caller didn't realize there was a unique_ptr that held ownership (eg: a function that returns a reference to a unique_ptr, passed to cast, then ownership taken) 2) dangling pointers - but this wouldn't be more or less likely with the change to cast.
On 15 Apr 2014, at 06:47, David Blaikie <dblaikie at gmail.com> wrote:> Anyone have opinions on whether the cast machinery should be taught to > handle unique_ptr? > > Presumably that'd involve cast, etc, returning raw pointers when it > was passed references to unique_ptr, which might be > surprising/error-prone? > > But the only errors would be: > > 1) double delete - if the result of the cast was used to take > ownership because the caller didn't realize there was a unique_ptr > that held ownership (eg: a function that returns a reference to a > unique_ptr, passed to cast, then ownership taken) > > 2) dangling pointers - but this wouldn't be more or less likely with > the change to cast.I'm not convinced that allowing it to accept unique_ptr types would be significantly less typing than requiring users to pass the result of the get() method to the cast and it does sound like hiding the explicit ownership control would be more error prone. That said, it might be useful to have variants of dyn_cast<> that would take a unique_ptr and return another unique_ptr to the cast type, complete with ownership transfer, or leave the original unique_ptr intact if the cast failed. David
> On Apr 15, 2014, at 0:01, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> On 15 Apr 2014, at 06:47, David Blaikie <dblaikie at gmail.com> wrote: >> >> Anyone have opinions on whether the cast machinery should be taught to >> handle unique_ptr? >> >> Presumably that'd involve cast, etc, returning raw pointers when it >> was passed references to unique_ptr, which might be >> surprising/error-prone? >> >> But the only errors would be: >> >> 1) double delete - if the result of the cast was used to take >> ownership because the caller didn't realize there was a unique_ptr >> that held ownership (eg: a function that returns a reference to a >> unique_ptr, passed to cast, then ownership taken) >> >> 2) dangling pointers - but this wouldn't be more or less likely with >> the change to cast. > > I'm not convinced that allowing it to accept unique_ptr types would be significantly less typing than requiring users to pass the result of the get() method to the cast and it does sound like hiding the explicit ownership control would be more error prone.++> That said, it might be useful to have variants of dyn_cast<> that would take a unique_ptr and return another unique_ptr to the cast type, complete with ownership transfer, or leave the original unique_ptr intact if the cast failed.I suppose the name would be dyn_move<> or something? How often is this useful?