On Thu, Apr 21, 2022 at 8:12 AM Jean Abou Samra <j...@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