nothrow by default

Johannes Pfau nospam at example.com
Thu Jan 9 21:29:00 UTC 2020


Am Thu, 09 Jan 2020 12:39:57 -0800 schrieb H. S. Teoh:

> On Thu, Jan 09, 2020 at 07:05:24PM -0000, Johannes Pfau via
> Digitalmars-d wrote:
>> Am Thu, 09 Jan 2020 08:02:16 -0800 schrieb H. S. Teoh:
> [...]
>> I think everyone who wants to move away from exceptions really wants to
>> move away from two things:
>> 
>> 1) Stack unwinding and the overhead it involves (memory,
>>    implementation complexity, ...)
>> 2) (Forced) dynamic allocation of error state. How often do you
>>    actually use more than 1 word of error state?
> 
> What can you practically throw, though, if you only have 1 word of error
> state? I suppose you could store a pointer to some exception object in
> there, but then that brings us back to issue (2). Unless you have some
> kind of thread-local global for storing exception objects?
> 

As far as I understood Sutter's proposal it's one word of 'context'. But 
a function actually returns two words (i.e. two words of state), where 
one is the error category and the second is the context. Essentially 
std::error_code. In practice the category code is a pointer to a dummy 
variable in static data. So for example you could do this:

module filesystem;

ubyte FileSystemErrorClass;

enum FileSystemError
{
    doesNotExist,
    PermissionDenied
}

return Error(&FileSystemErrorClass, FileSystemError.doesNotExist);

if (error.class == &FileSystemErrorClass)
{
    auto kind = cast(FileSystemError)error.context;
}

The ErrorClass is really the Tag, the context is then arbitrary (Tag-
specific) data. I.e. you could reference TLS data, but you could just as 
well allocate data manually and store a pointer to heap memory in the 
context.

Obviously users would not write such low level code, that's just the low 
level ABI.

-- 
Johannes


More information about the Digitalmars-d mailing list