search for: r_unwindprotect

...ause new problems? d) Are there alternative/better solutions? Any feedback on this is highly appreciated. Below you can find a template which, combines the proposed solutions (and skips all non-illustrative checks of return values). Additionally, R_CheckUserInterrupt() is used in combination with R_UnwindProtect() to regularly check for interrupts from the main thread, while still being able to cleanly cancel the threads before fun_running_in_main_thread() is left via a longjmp. This is e.g. required if the secondary threads use memory which was allocated in fun_running_in_main_thread() using e.g. R_alloc(...

...t; d) Are there alternative/better solutions? >> Any feedback on this is highly appreciated. >> Below you can find a template which, combines the proposed solutions (and skips all non-illustrative checks of return values). Additionally, R_CheckUserInterrupt() is used in combination with R_UnwindProtect() to regularly check for interrupts from the main thread, while still being able to cleanly cancel the threads before fun_running_in_main_thread() is left via a longjmp. This is e.g. required if the secondary threads use memory which was allocated in fun_running_in_main_thread() using e.g. R_alloc(...

...d) Are there alternative/better solutions? > > Any feedback on this is highly appreciated. > > Below you can find a template which, combines the proposed solutions (and skips all non-illustrative checks of return values). Additionally, R_CheckUserInterrupt() is used in combination with R_UnwindProtect() to regularly check for interrupts from the main thread, while still being able to cleanly cancel the threads before fun_running_in_main_thread() is left via a longjmp. This is e.g. required if the secondary threads use memory which was allocated in fun_running_in_main_thread() using e.g. R_alloc(...

...) Are there alternative/better solutions? > > Any feedback on this is highly appreciated. > > Below you can find a template which, combines the proposed solutions (and skips all non-illustrative checks of return values). Additionally, R_CheckUserInterrupt() is used in combination with R_UnwindProtect() to regularly check for interrupts from the main thread, while still being able to cleanly cancel the threads before fun_running_in_main_thread() is left via a longjmp. This is e.g. required if the secondary threads use memory which was allocated in fun_running_in_main_thread() using e.g. R_alloc(...

...well as lang2) can throw an error, this error has to be > caught via R API and handled (e.g. by throwing as exception or something > else, indeed that exception then needs to be caught and possibly > converted back when leaving again to C stack frames). An R/C API you can > use here is R_UnwindProtect. This is of course a bit of a pain, and one > does not have to worry when programming in plain C. > > I suppose Rcpp provides some wrapper around R_UnwindProtect, that would > be a question for Rcpp experts/maintainers. > > Best > Tomas > >> >> ? Any tips, cor...

Dear r-devel folks, [if this is more appropriate for r-pkg-devel please let me know and I'll repost it over there ...] I'm writing to ask for help with some R/C++ integration idioms that are used in a package I'm maintaining, that are unfamilar to me, and that are now being flagged as problematic by Tomas Kalibera's 'rchk' machinery (https://github.com/kalibera/rchk);

...) Yes, eval (as well as lang2) can throw an error, this error has to be caught via R API and handled (e.g. by throwing as exception or something else, indeed that exception then needs to be caught and possibly converted back when leaving again to C stack frames). An R/C API you can use here is R_UnwindProtect. This is of course a bit of a pain, and one does not have to worry when programming in plain C. I suppose Rcpp provides some wrapper around R_UnwindProtect, that would be a question for Rcpp experts/maintainers. Best Tomas > > Any tips, corrections, pointers to further documentation, e...

...sort of issue will arise. What I believe we should do, and what Rcpp has made steps towards, is make it possible to interact with some subset of the R API safely from C++ contexts. This has always been possible with e.g. R_ToplevelExec() and R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). In theory, as a prototype, an R package could provide a 'safe' C++ interface to the R API using R_UnwindProtect() and friends as appropriate, and client packages could import and link to that package to gain access to the interface. Code generators (as Rcpp Attributes does) can handle so...

...ed during the call. > What I believe we should do, and what Rcpp has made steps towards, is make it possible to interact with some subset of the R API safely from C++ contexts. This has always been possible with e.g. R_ToplevelExec() and R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). In theory, as a prototype, an R package could provide a 'safe' C++ interface to the R API using R_UnwindProtect() and friends as appropriate, and client packages could import and link to that package to gain access to the interface. Code generators (as Rcpp Attributes does) can handle so...

...call. > > >> What I believe we should do, and what Rcpp has made steps towards, is make it possible to interact with some subset of the R API safely from C++ contexts. This has always been possible with e.g. R_ToplevelExec() and R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). In theory, as a prototype, an R package could provide a 'safe' C++ interface to the R API using R_UnwindProtect() and friends as appropriate, and client packages could import and link to that package to gain access to the interface. Code generators (as Rcpp Attributes does) can handle so...

Dear all, I try to understand why on my computer I do not clear all data with this code: #include <R.h> static int count = 0; class A { public: A(){ printf("c %d\n", count); count++; } ~A(){count--; printf("d %d\n", count); } }; extern "C" { void testAL(){ A a; { A b; } error("does not write [d 0]"); } }

First, thank you to Tomas for writing his recent post[0] on the R developer blog. It raised important issues in interfacing R's C API and C++ code. However I do _not_ think the conclusion reached in the post is helpful > don?t use C++ to interface with R There are now more than 1,600 packages on CRAN using C++, the time is long past when that type of warning is going to be useful to the

Hi Simon, Widespread errors would have caught my earlier as the way that code is using only one initialization of the embedded R, is used quite a bit, and is covered by quite a few unit tests. This is the only situation I am aware of in which an error occurs. What is a "correct context", or initial context, the code should from ? Searching for "context" in the R-exts manual

...age C code instead NAMED or SET_NAMED. * The object header layout has been changed to support merging the ALTREP branch. This requires re-installing packages that use compiled code. * 'Writing R Extensions' now documents the R_tryCatch, R_tryCatchError, and R_UnwindProtect functions. * NAMEDMAX has been raised to 3 to allow protection of intermediate results from (usually ill-advised) assignments in arguments to BUILTIN functions. Package C code using SET_NAMED may need to be revised. DEPRECATED AND DEFUNCT: * Sys.timezone(location = FA...

...age C code instead NAMED or SET_NAMED. * The object header layout has been changed to support merging the ALTREP branch. This requires re-installing packages that use compiled code. * 'Writing R Extensions' now documents the R_tryCatch, R_tryCatchError, and R_UnwindProtect functions. * NAMEDMAX has been raised to 3 to allow protection of intermediate results from (usually ill-advised) assignments in arguments to BUILTIN functions. Package C code using SET_NAMED may need to be revised. DEPRECATED AND DEFUNCT: * Sys.timezone(location = FA...