<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">On Wed, Jun 20, 2012 at 1:07 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Jun 20, 2012 at 12:36 PM, Nick Kledzik <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> wrote:<br>

> On Jun 20, 2012, at 12:28 AM, Chandler Carruth wrote:<br>
>> On Tue, Jun 19, 2012 at 11:18 AM, Jeffrey Yasskin <<a href="mailto:jyasskin@google.com">jyasskin@google.com</a>> wrote:<br>
>> On Jun 18, 2012 1:24 PM, "Nick Kledzik" <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> wrote:<br>
>> ><br>
>> > On Jun 16, 2012, at 3:51 PM, Chris Lattner wrote:<br>
>> > > On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote:<br>
>> > ><br>
>> > >> 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.<br>

>> > >><br>
>> > >> The Reader class currently has an interface that can be simplified down to:<br>
>> > >><br>
>> > >>   virtual error_code readFile(StringRef path, std::unique_ptr<lld::File> &result);<br>
>> > >><br>
>> > >> 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.<br>

>> > ><br>
>> > > Not a c++'11 expert here, but does a returning an std::tuple work?<br>
>> > I talked to Howard about that.  It does work, but it is cumbersome.  Either:<br>
>> ><br>
>> > std::tuple<std::unique_ptr<lld::File>, error_code>  result = reader.readFile(path);<br>
>> ><br>
>><br>
>> 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.<br>

><br>
> I too think that error_or<T> is better than std::pair<error_code, T>:<br>
> * more compact<br>
> * can name fields (e.g. error, object instead of first, second)<br>
> * can embed asserts that object field is not accessed if there is an error.<br>
><br>
> But there are some drawbacks:<br>
> * 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.<br>

<br>
</div>Could you explain this a little further? It doesn't quite make sense<br>
to me. In my (C++11) experience I'd only use a unique_ptr for a<br>
polymorphic type that needs single ownership. For a non-polymorphic<br>
single ownership without any valid copy semantics I would use a<br>
move-only type rather than std::unique_ptr.</blockquote><div><br></div><div>I think he is suggesting that File is always going to be a polymorphic object. </div></div></font></div>