Displaying 6 results from an estimated 6 matches for "error_or".
2012 Jun 20
3
[LLVMdev] object construction patterns and unique_ptr
...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 also really like the variant design. It has a few important advantages
I...
2012 Jun 20
0
[LLVMdev] object construction patterns and unique_ptr
...+'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>:
* mor...
2012 Jun 20
1
[LLVMdev] object construction patterns and unique_ptr
...ut 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>...
2012 Jun 19
0
[LLVMdev] object construction patterns and unique_ptr
....
> >
> > 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.
> Or you use std::tie() but then you still have to declare the two local
variables an...
2012 Jun 18
6
[LLVMdev] object construction patterns and unique_ptr
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
2012 Jun 19
2
[LLVMdev] object construction patterns and unique_ptr
On Jun 18, 2012, at 4:36 PM, Michael Spencer wrote:
>>>>
>>>> In asking around for clean models on how to do this better, I've heard two interesting ideas:
>>>>
>>>> 1) Incorporate the error_code and string message into the File class. That is the factory method always returns a File object. But there is a method on File objects to query if