similar to: Use of C++ in Packages

I think it's also worth saying that some of these issues affect C code as well; e.g. this is not safe: FILE* f = fopen(...); Rf_eval(...); fclose(f); whereas the C++ equivalent would likely handle closing of the file in the destructor. In other words, I think many users just may not be cognizant of the fact that most R APIs can longjmp, and what that implies for cleanup of

tl;dr: we need better C++ tools and documentation. We collectively know more now with the rise of tools like rchk and improved documentation such as Tomas?s post. That?s a start, but it appears that there still is a lot of knowledge that would deserve to be promoted to actual documentation of best practices. I think it is important to not equate C++ as a language, and Rcpp. Also, C++ is not

Jim, I think the main point of Tomas' post was to alert R users to the fact that there are very serious issues that you have to understand when interfacing R from C++. Using C++ code from R is fine, in many cases you only want to access R data, use some library or compute in C++ and return results. Such use-cases are completely fine in C++ as they don't need to trigger the issues

Kevin, > On Mar 29, 2019, at 17:01, Kevin Ushey <kevinushey at gmail.com> wrote: > > I think it's also worth saying that some of these issues affect C code > as well; e.g. this is not safe: > > FILE* f = fopen(...); > Rf_eval(...); > fclose(f); > I fully agree, but developers using C are well aware of the necessity of handling lifespan of objects

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);

One could also argue that paste0("a", "b", "c") is a function call that needs to be evaluated at runtime, whereas "abc" is a string constant understood by the parser, and often also language agnostic. I'd assume compilers and code- and text-search tools do a better job with the latter. /Henrik On Mon, Jun 2, 2025 at 2:18?PM Josiah Parry

I suppose taste is learned as well. It does feel quite odd that the best way to define a long string without a note or text wrapping is by being creative with functions. This is valid in Python, Julia, and Rust (if you add `let` and a terminating semi-colon): my_str = "part1\ part2\ part2" I don't think it is abnormal to expect or desire this type of functionality in our favorite

Please patch Mini-OS so that it uses stddef.h to define size_t and NULL. This problem fixes errors that occur when linking Mini-OS with ANSI standard code that uses stddef.h. John diff -ur oxen-3.0-testing/extras/mini-os/include/lib.h nxen-3.0-testing/extras/mini-os/include/lib.h --- oxen-3.0-testing/extras/mini-os/include/lib.h 2006-04-14 22:21:55.000000000 -0400 +++

> On 3 Jun 2025, at 09:34, Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote: > > One could also argue that paste0("a", "b", "c") is a function call that needs to be evaluated at runtime, whereas "abc" is a string constant understood by the parser, and often also language agnostic. I'd assume compilers and code- and text-search tools

Like Tomas, I find the paste0 readability to be **much** better, partly because it allows for better indentation (as Tomas pointed out). Perhaps a pointless email, but sometimes - for these subjective issues - it is worthwhile to point out a difference in opinion. Best, Kasper On Mon, Jun 2, 2025 at 12:27?PM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 6/2/25 17:37,

Thanks, that's really useful. One more question for you, or someone else here: const ArrayXd glmLink::linkFun(const ArrayXd& mu) const { return as<ArrayXd>(::Rf_eval(::Rf_lang2(as<SEXP>(d_linkFun), as<SEXP>(Rcpp::NumericVector(mu.data(), mu.data() + mu.size())) ), d_rho); } I guess I need that to read

On 5/28/25 04:15, Pavel Krivitsky via R-devel wrote: > Dear All, > > Perhaps this should go in r-package-devel, but I suspect that this is > going to turn into a feature request, and I want to run it by the list > before filing it in the Bugzilla. > > I would like to specify a long string literal without making the line > of code too long. In R, > > "abc >

On 6/2/25 17:37, Josiah Parry wrote: > Tomas, > > Here is a good example of where this functionality would be useful: > https://github.com/R-ArcGIS/arcgislayers/blob/2b29f4c254e7e5a1dadce8d4b0015a70dfae39d4/R/arc-open.R#L19-L56 > > In order to prevent R CMD check notes I have to use `paste0()` to > concatenate long URLs. If we were able to use `\` to > separate the string

Tomas, Here is a good example of where this functionality would be useful: https://github.com/R-ArcGIS/arcgislayers/blob/2b29f4c254e7e5a1dadce8d4b0015a70dfae39d4/R/arc-open.R#L19-L56 In order to prevent R CMD check notes I have to use `paste0()` to concatenate long URLs. If we were able to use `\` to separate the string across multiple lines, it would make the solution much nicer! On Mon, Jun

On 23 February 2015 at 01:29, Kamal Sharma <kgs1.rice at gmail.com> wrote: > Hi Dibyendu, > > It would be very helpful if you could post the original source code or > snippet. > That way, one can investigate deeper to understand the problem. > > Regards, > Kamal Sharma > Hi Kamal, Sure. I guess I ought to create a test that one can look in isolation. I am

Hi, I am encountering a problem that I do not know how to debug. I would greatly appreciate any guidance on this issue. On Windows when I run Lua test cases from JITed code I am getting following error: Unhandled exception at 0x00007FFCEEEAC500 (ntdll.dll) in lua.exe: 0xC0000028: An invalid or unaligned stack was encountered during an unwind operation. This is happening when the Lua code is

On 28 April 2015 at 00:30, Reid Kleckner <rnk at google.com> wrote: > I think Paweł identified the problem. The frames on the stack between the > setjmp and longjmp must have valid unwind information, which is described > here: > https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 > > In particular, it has this line about JITed code: >

On 8/22/20 8:26 PM, Tomas Kalibera wrote: > On 8/22/20 7:58 PM, Jeroen Ooms wrote: >> On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera >> <tomas.kalibera at gmail.com> wrote: >>> On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: >>>> Ah yes, this is related. I reported v2010 below, but it looks like >>>> I was updated to this

On 8/22/20 9:33 PM, Jeroen Ooms wrote: > On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: >> On 8/22/20 8:26 PM, Tomas Kalibera wrote: >>> On 8/22/20 7:58 PM, Jeroen Ooms wrote: >>>> On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera >>>> <tomas.kalibera at gmail.com> wrote: >>>>> On 8/21/20 11:45

On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: > > Ah yes, this is related. I reported v2010 below, but it looks like I was updated to this Insider Build overnight without my knowledge, and conflated it with the new installation R v4 this morning. > > > > I will