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