<scope> library

Beman Libraries
21

Here is a gist of how the scope_guard machinary could be written:

22

Yes, looks like a good first approximation. Looking at specification from the TS (aka P0052) – and off the top of my head maybe there maybe needs to be:

  • constexpr on various functions (not in TS, but think should be now?)
  • remove iostream include
  • header should be scope - no _guard (I wonder if in beman it should be without .hpp like standard?)
  • constructors are explicit in places in TS - aka:
template<class EFP> explicit scope_guard (EFP&& f)
  • there’s some conditional noexcept logic on scope_success (also scope_guard – more below)
scope_success() noexcept(noexcept(exit_function()));
  • probably should explicitly disable assignment like in spec – should be anyway I think, but can’t hurt
scope_guard (const scope_guard &)=delete;
scope_guard & operator=(const scope_guard &)=delete;
scope_guard & operator=(scope_guard &&)=delete;
  • scope_guard should be in a detail namespace - it’s not part of the api (more below)

Note that a pro-trick when I’m evaluating wording, I copy the synopsis from the paper and work with it until it compiles or doesn’t – so many bugs in wording discovered this way. My point being that what we’re doing here is a backward check of the specification by attempting to implement it.

So my 15 minute check of your implementation against the spec shines the light on at least a couple specification problems from P0052. Specifically

~scope_guard () noexcept(see below )

There’s no text corresponding to see below – in fact there’s almost no specification of scope_guard itself.

The intent in the wording is that scope_guard is exposition-only – that is not available to end users (hence my detail namespace comment above). But you don’t know that because it’s not marked properly as exposition only. Also in the wording it should be called scope-guard (uncompilable kebob case) - it’s just in italics…

Anyway, I think you should turn this draft into an initial PR on top of @river 's.

1 Like
23

Thank you for the information.
My implementation was just to get the example working… there are still many things wrong with it, to make it work in all cases.

I think the correct mindset would be: we are reverse engineering the paper.
I will get on it.

1 Like
24

I’ve started adding issues to the repo to document stuff we’re finding here so it can go into the paper. I’ll be traveling to Europe later today for the Hagenberg c++ meeting so I might be able to get a draft outline for the paper in place. I don’t know if Peter will be there, but I’ll be reaching out to him and the Boost author soon to see if they want to participate.

1 Like
25

An alternative to the synopsis that I provided earlier is now in: GitHub - bemanproject/scope at scope-guard-demo
Available in: include/beman/scope/scope_guard_demo.hpp
Also the example in this branch has been modified to demonstrate how this demo can be used.

The synopsis has already been copied into the main branch, I’m working on making the intial implementaion. The demo code can be used as basis, but it requires a change - from using constructor parameters to using template parameters.

Please review the infrastructure pulls.

1 Like
26
  • exception header

Since scope is fundamentally about dealing with exceptions I think that is a requirement.

I might be overthinking this.

The way I see it, a scope_guard does not deal with exceptions by itself.
Reacting to exceptions is a customization of a scope_guard.
Similarly, making a scope_guard cancelable or releasable is another customization.
These customizations can be applied individually or together, or even with other custom conditions.

As I see it, a scope_guard consists of:

  • an initialization step: creating the scope_guard object,
  • a checking step: verifying if conditions are met to execute the finalization function,
  • a finalization step: executing previously deferred functions if the above check is fulfilled.

scope_fail and scope_success are just convenience classes, which are essentially preconfigured scope_guards.

27

So in the end scope_guard isn’t part of the public interface because it’s marked exposition only in the TS. Hence the only relevant question is do the 3 public interface classes need exceptions – they do and hence my point. What it means is that implementations do not need to create a scope_guard at all – they can just code the 3 types. So users are NOT free to derive to make their own, etc. As I think I put in the design issue I this should be reconsidered I think.

I guess even if scope_guard wasn’t this way it’s in the same header as the others so exception is still needed. And in 3 years the world will start shifting to import std; and it’ll all be water under the bridge.

28

I’ve archived the original repo - @Robert-Andrzejuk you seem to have a fork of it, but there’s little activity. I expect to simply delete it soon.

29

The repo has been deleted.