Displaying 10 results from an estimated 10 matches for "fileerror".
2012 Jun 20
0
[LLVMdev] object construction patterns and unique_ptr
...or you don't.
I do agree that either you successfully parsed the file and have a full File object or you failed and have some sort of error. That means they are mutually exclusive, so having every File object carry an error_code is a waste and confusing. But, that also make the case for the FileError subclass...
> 4) Doesn't require polymorphic types (but they can be supported if needed). Essentially, you can wrap a *specific* file type, rather than being forced to use some generic file type.
Yes, the template lets you do that. But in the specific case of the linker, it will always be...
2012 Jun 20
3
[LLVMdev] object construction patterns and unique_ptr
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
2012 Jun 19
2
[LLVMdev] object construction patterns and unique_ptr
...File object. But there is a method on File objects to query if they are valid or not. If they are not, there is a method to get the error_code and/or error string.
>
> I like this with some modifications.
>
>>>> 2) A variation on this is to have a new subclass of File called FileError. If the Reader cannot construct a real FileFoo object because of some error, it instead constructs a FileError object and returns that. The FileError object has methods to get the error_code and/or error string.
>
My intuition is the opposite here. If you add the error information to the lld...
2012 Jun 15
3
[LLVMdev] object construction patterns and unique_ptr
...age 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 they are valid or not. If they are not, there is a method to get the error_code and/or error string.
2) A variation on this is to have a new subclass of File called FileError. If the Reader cannot construct a real FileFoo object because of some error, it instead constructs a FileError object and returns that. The FileError object has methods to get the error_code and/or error string.
With both these ideas the Reader method is:
virtual std::unique_ptr<lld::Fil...
2012 Jun 20
1
[LLVMdev] object construction patterns and unique_ptr
...ou don't.
> I do agree that either you successfully parsed the file and have a full File object or you failed and have some sort of error. That means they are mutually exclusive, so having every File object carry an error_code is a waste and confusing. But, that also make the case for the FileError subclass...
>
>> 4) Doesn't require polymorphic types (but they can be supported if needed). Essentially, you can wrap a *specific* file type, rather than being forced to use some generic file type.
> Yes, the template lets you do that. But in the specific case of the linker, it wi...
2012 Jun 18
0
[LLVMdev] object construction patterns and unique_ptr
...d always returns a File object. But there is a method on File objects to query if they are valid or not. If they are not, there is a method to get the error_code and/or error string.
I like this with some modifications.
>>> 2) A variation on this is to have a new subclass of File called FileError. If the Reader cannot construct a real FileFoo object because of some error, it instead constructs a FileError object and returns that. The FileError object has methods to get the error_code and/or error string.
I dislike this variant because a FileError is not a File.
>>> With both th...
2012 Jun 16
0
[LLVMdev] object construction patterns and unique_ptr
...he File class. That is the factory method always returns a File object. But there is a method on File objects to query if they are valid or not. If they are not, there is a method to get the error_code and/or error string.
>
> 2) A variation on this is to have a new subclass of File called FileError. If the Reader cannot construct a real FileFoo object because of some error, it instead constructs a FileError object and returns that. The FileError object has methods to get the error_code and/or error string.
>
> With both these ideas the Reader method is:
>
> virtual std::uni...
2012 Jun 18
6
[LLVMdev] object construction patterns and unique_ptr
...class. That is the factory method always returns a File object. But there is a method on File objects to query if they are valid or not. If they are not, there is a method to get the error_code and/or error string.
>>
>> 2) A variation on this is to have a new subclass of File called FileError. If the Reader cannot construct a real FileFoo object because of some error, it instead constructs a FileError object and returns that. The FileError object has methods to get the error_code and/or error string.
>>
>> With both these ideas the Reader method is:
>>
>> v...
2012 Jun 19
0
[LLVMdev] object construction patterns and unique_ptr
...hat is the factory method always returns a File object. But there is a
method on File objects to query if they are valid or not. If they are not,
there is a method to get the error_code and/or error string.
> >>
> >> 2) A variation on this is to have a new subclass of File called
FileError. If the Reader cannot construct a real FileFoo object because of
some error, it instead constructs a FileError object and returns that. The
FileError object has methods to get the error_code and/or error string.
> >>
> >> With both these ideas the Reader method is:
> >>...
2005 Feb 14
8
DONT_RESOLVE_DLL_REFERENCES info
For future reference, it looks like we should avoid
DONT_RESOLVE_DLL_REFERENCES in any extensions.
http://weblogs.asp.net/oldnewthing/archive/2005/02/14/372266.aspx
Regards,
Dan