On 31/05/2019 14:49, Niall Douglas wrote:
> On 31/05/2019 09:07, Peter C++ wrote:
>> The code uses something called bitfiel in line 4 and 25. is that just an enum class?
>
> bitfield(name) is a standin for whatever bitfield implementation C2x or
> C++ 23 ends up choosing.
>
>> Also, why does the design use virtual functions? If it is about platform differences, this is a compile time issue and not run time.
>
> This is really great feedback, thank you. You caused me to spend a good
> 15 minutes wondering why this was the case myself, and I wrote the thing.
>
> I believe that you are correct, and they are unnecessary. The reference
> implementation was originally a much more complex and powerful solution.
> Having built out a lot of complexity for all sorts of use cases, I ended
> up purging most of it as it wasn't needed 99% of the time. However I
> purged only the topmost API i.e. I ended up with the super simple
> signal_guard() API. I didn't refactor raised_signal_info, as it was
> debugged and performance tuned.
>
> But I think that you are right, the virtual functions can be removed
> entirely, and the implementation simplified. Thank you for spotting it.

The reference library has been refactored to remove all unnecessary
virtual functions along with much other simplification, and can be
viewed at:

https://github.com/ned14/quickcpplib/blob/master/include/signal_guard.hpp

Other changes:

1. The proposed API now has a C API suitable for sending to POSIX and
WG14, in addition to a C++ API.

2. signal_guard_install instances now compose without limit.


What's still missing:

1. Global handlers which are threadsafe.

2. C API for signal_guard_install.


I should fix the last remaining missing parts in the next few days, but
they're icing on the cake. The cake itself is baked.

Niall