[LLVMdev] object construction patterns and unique_ptr

[Chandler Carruth]

On Wed, Jun 20, 2012 at 1:07 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Wed, Jun 20, 2012 at 12:36 PM, Nick Kledzik <kledzik at apple.com> wrote:
> > On Jun 20, 2012, at 12:28 AM, Chandler Carruth wrote:
> >> On Tue, Jun 19, 2012 at 11:18 AM, Jeffrey Yasskin <jyasskin at google.com>
> wrote:
> >> On Jun 18, 2012 1:24 PM, "Nick Kledzik" <kledzik at apple.com> wrote:
> >> >
> >> > On Jun 16, 2012, at 3:51 PM, Chris Lattner wrote:
> >> > > On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote:
> >> > >
> >> > >> In lld we have a Reader class which is a factory that takes .o
> file(s) and produces an in memory lld::File object(s).  But in doing so,
> there could be I/O errors (file not readable) or file may be malformed.  We
> are also using C++11 in lld, so we use std::unique_ptr for managing object
> ownership.
> >> > >>
> >> > >> The Reader class currently has an interface that can be simplified
> down to:
> >> > >>
> >> > >>   virtual error_code readFile(StringRef path,
> std::unique_ptr<lld::File> &result);
> >> > >>
> >> > >> But this interface has become awkward to use. There are two
> "return" values.  This method is a unique_ptr "source" but the use of a
> by-refernce parameter means you have to start with an uninitialized
> unique_ptr and the readFile() has to std::move() into it.   unique_ptr is
> much nicer to use as a return value.
> >> > >
> >> > > Not a c++'11 expert here, but does a returning an std::tuple work?
> >> > I talked to Howard about that.  It does work, but it is cumbersome.
>  Either:
> >> >
> >> > std::tuple<std::unique_ptr<lld::File>, error_code>  result =
> reader.readFile(path);
> >> >
> >>
> >> I suggest an error_or<T> class that can be combined with any result
> type, not just File. It could be implemented with a fully generic variant
> class, but the interface would likely be better with some specialization to
> errors.
> >
> > I too think that error_or<T> is better than std::pair<error_code, T>:
> > * more compact
> > * can name fields (e.g. error, object instead of first, second)
> > * can embed asserts that object field is not accessed if there is an
> error.
> >
> > But there are some drawbacks:
> > * lld uses C++11, so we thought we'd add explicit ownership by using
> std::unique_ptr.  That means we'd need to layer the templates (e.g.
> error_or<std::unique_ptr<lld::File>>), or forgo using unique_ptr, or cause
> error_or to always internally use unique_ptr.
>
> Could you explain this a little further? It doesn't quite make sense
> to me. In my (C++11) experience I'd only use a unique_ptr for a
> polymorphic type that needs single ownership. For a non-polymorphic
> single ownership without any valid copy semantics I would use a
> move-only type rather than std::unique_ptr.


I think he is suggesting that File is always going to be a polymorphic
object.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120620/5194af3a/attachment.html>