Re: [scope] Scope review starts on November 26th

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-11-26 20:14:47

On 11/26/23 20:08, Дмитрий Архипов via Boost wrote:
> I have also posted review announcements on Reddit and in Cpplang Slack
> workspace. Here are some comments I've received:
> 
> 1. Given
>     void f();
> 
>     int main()
>     {
>         auto a = boost::scope::make_scope_fail(f);
>         boost::scope::scope_fail b(f);
>     }
> Only the declaration of b compiles. The one of a fails. I think the
> one of a should compile, too. Something like std::decay instead of
> typename std::remove_cv< typename std::remove_reference< F >::type
>> ::type at https://github.com/Lastique/scope/blob/develop/include/boost/scope/scope_exit.hpp#L535

Will fix, thanks for letting me know.

https://github.com/Lastique/scope/issues/6

> 2. According to http://eel.is/c++draft/lex.name#3.2, identifiers like
> _foo are rerversed at global namespace. The macro BOOST_SCOPE_FINAL
> (https://github.com/Lastique/scope/blob/develop/include/boost/scope/scope_final.hpp#L174)
> expands to something beginning with _boost_scope_final_. I don't think
> that anyone would ever use BOOST_SCOPE_FINAL at global namespace, but
> if they would, this would be a violation of lex.name#3.2

The identifier prefix is chosen this way to avoid scope guards popping
up in autocompletion in various IDEs. The prefix is pretty well
qualified, so it is unlikely to clash with anything, even in the
unlikely case if someone uses it at namespace scope. I'd prefer to keep
it the way it is, unless it causes real problems to someone.

> 3. unique_resource seems interesting, one thing that might be missing
> from this kind of scope based resource management would be a
> shared_resource. In OpenCL, resources are internally reference
> counted, and have the following functions
> 
> clCreate* which returns a new resource (eg clCreateBuffer)
> clRetain* which increments an internal reference counter (eg clRetainMemObject)
> clRelease* which decrements the internal reference counter (eg
> clReleaseMemObject)
> 
> The following types meet this format: cl_mem, cl_event, cl_sampler,
> cl_context, cl_command_queue, cl_device, and probably a few others.
> Its fairly straightforward to crack these into a general type that
> implements shared RAII semantics on top of these. Notably there's no
> (sane) way to ever query the reference count of an object

I did think about shared_resource at some point, but couldn't decide on
the design. Possibly because I currently don't have a use case for it.
My main questions were:

- What to do with resource traits? Should those be exposed in the
shared_resource type? My gut feeling says "yes" as the traits are needed
to be able to tell whether the resource is allocated.

- How to make `reset()` non-throwing? Presumably, one should be able to
call `get()` on a shared_resource that is not in allocated state, and it
should return a reference to a resource object in a deallocated state
(e.g. -1 for an fd). Which means `reset()` may need to allocate memory
or something to create the resource object in that state.

The question above also adds reference counting into this list - should
shared_resource support custom reference counting policies?

In any case, I currently don't have answers to those questions, and
therefore not proposing a shared_resource. It may be added later, when
the answers are more clear. In the meantime, it is always possible to
use `shared_ptr<unique_resource<...>>`, although it may seem clumsy.