Re: C++ question on wrapper API for setting Guile fluids

[Luca Fascione]

On Thu, Apr 21, 2022 at 8:12 AM Jean Abou Samra <jean@abou-samra.fr> wrote:

> Le 21/04/2022 à 04:57, Dan Eble a écrit :
> >      {
> >        // dwc constructor calls scm_dynwind_begin ()
> >        Dynwind_context dwc;
> >        scm_dynwind_fluid (fluid1, value1);
> >        scm_dynwind_fluid (fluid2, value2);
> >        . . .
> >        // dwc destructor calls scm_dynwind_end ()
> >      }
>
>
>
> Why not. There is likely just one caller that will need to introduce
> several
> fluids at once, but it is probably clearer this way.
>

I'd think you can up this by one, and get a cleaner looking piece of code
if you implement scm_dynwind_fluid() as a forwarded method on your context:

{

  Dynwind_context dwc; // overloaded so you can call
dwc(SCM_F_DYNWIND_REWINDABLE);
  dwc.fluid (fluid1, value1);
  dwc.fluid (fluid2, value2);

  dwc.unwind_handler(handler, data, flags); // overloaded for the SCM vs
void* cases,
  dwc.rewind_handler(handler, data, flags); // overloaded for the SCM vs
void* cases,
                                            // maybe it ought to check if
the constructor was DYNWIND_REWINDABLE and complain
                                            // (only in debug builds?) if
things are not set up right
  dwc.free(something);

}

However in all this, I must say I don't understand this passage in manual:

The context is ended either implicitly when a non-local exit happens, or
explicitly with scm_dynwind_end. You must make sure that a dynwind context
is indeed ended properly. If you fail to call scm_dynwind_end for each
scm_dynwind_begin, the behavior is undefined.

It seems to me the first phrase and the rest slightly contradict each
other: as I hear it, the first phrase says "either the C side calls
scm_dynwind_end(), OR a non-local exit happens", whereas the rest seems to
be saying "the C side _shall_ call scm_dynwind_end". This bothers me,
because in the second case our C++ is nice and lovely, but in the first
meaning the destructor of dwc has to somehow figure out whether a non-local
exit has happened, and avoid calling scm_dynwind_end(). And I don't think
scm library can cope on its own, because these things look to me like they
would nest, so making scm_dynwind_end() idempotent without some sort of
explicit marker on the scope seems... hard.

So yes, I'd think RAII is the idiomatic way to go, I would add the wrappers
because they make the pattern cleaner, but do figure out what's up with
this last question first, because it could bring it all crumbling down.

HTH
Luca