On Tue, Feb 24, 2015 at 10:59 AM, Tim Keitt <tke...@utexas.edu> wrote:
> > > On Tue, Feb 24, 2015 at 9:45 AM, Miratrix, Luke <lmirat...@fas.harvard.edu > > wrote: > >> >> As an inexperienced person myself, I was trying to wrap a C++ stand-alone >> package so it could be called from R and was trying to preserve some of >> the safety features and error-checking. My understanding of asserts is >> they are to catch disasters that indicate bugs in the code itself, and are >> thus distinct from normal exceptions. They therefore print out the failed >> check and a line-number in the source file and bail. >> >> When using Rcpp, I came up against CRAN¹s admonition to not print to >> stderr and so couldn¹t use assert() and stay ³legal.² But I found this >> out only after annoying people by not doing what I was supposed to do. >> Given that, having assert() redefined so it is compliant with CRAN and >> plays nice with R, but also maintains its behavior would be pretty cool, I >> think. >> >> All this being said, Nathan Kurz¹s comments also seem good except I think >> it is ³illegal² to print to STDERR directly before aborting, since it is >> only aborting the C++ part, and not the entire R session. Hence my hack >> of printing to a string buffer and then handing it to the Rf_error call. >> I don¹t know the guts of Rf_error, but I had assumed it would copy the >> string to its own world before unwinding the stack. If it doesn¹t then I >> agree this is going to cause problems. What is the correct way to pass a >> message up, then? >> > > If I recall, the other prohibition of CRAN is to never ever call abort (R > owns the event loop) so assert-like behavior is not gonna fly. > Double negative, but you get the idea. > > THK > > >> >> >> (Sorry for delay in posting this: the rcpp devel list does not get along >> with my mail client.) >> >> >> >> Sincerely, >> >> Luke Miratrix >> Assistant Professor of Statistics >> >> Note: Due to my RSI (wrist trouble), e-mail often abrupt. >> >> >> -- >> >> Department of Statistics >> Science Center >> >> Harvard University >> 1 Oxford Street >> Cambridge MA 02138-2901 >> >> >> lmirat...@stat.harvard.edu >> 510-735-7635 >> >> >> >> >> >> >> On 2/18/15, 3:25 PM, "Dale Smith" <dsm...@nexidia.com> wrote: >> >> >I haven't been very active lately with Rcpp, but I like Nathan's advice >> >below. Don't redefine assert(), I think that's not friendly to >> >inexperienced people and will just generate more questions. >> > >> >Dale Smith, Ph.D. | Data Scientist | nexidia | office: +1 404 495 7220 >> >ext 4008 | fax: +1 404 495 7221| nexidia.com >> > >> >-----Original Message----- >> >From: rcpp-devel-boun...@lists.r-forge.r-project.org >> >[mailto:rcpp-devel-boun...@lists.r-forge.r-project.org] On Behalf Of >> >Nathan Kurz >> >Sent: Wednesday, February 18, 2015 3:19 PM >> >To: Miratrix, Luke >> >Cc: rcpp-devel@lists.r-forge.r-project.org >> >Subject: Re: [Rcpp-devel] assert() for Rcpp? >> > >> >On Tue, Feb 17, 2015 at 4:41 PM, Miratrix, Luke >> ><lmirat...@fas.harvard.edu> wrote: >> >> The proposed code: >> >> >> >> #include <stdio.h> >> >> >> >> #ifdef NDEBUG >> >> # define assert(EX) >> >> #else >> >> # define assert(EX) (void)((EX) || (__assert (#EX, __FILE__, >> >> __LINE__),0)) #endif >> >> >> >> void __assert (const char *msg, const char *file, int line) { >> >> char buffer [100]; >> >> snprintf( buffer, 100, "Assert Failure: %s at %s line #%d", msg, >> >> file, line ); >> >> ::Rf_error( buffer ); >> >> } >> > >> >Getting more people using assert-like macros seems like a great idea. >> >Weighing in as a C programmer with limited knowledge of Rcpp, I'd >> >suggest: >> > >> >1) Don't redefine assert() or __assert(). You'll confuse people and it >> >will somehow manage to break things. Instead, define your own macro with >> >a different name, likely one in all caps that starts with "R_" or >> "RCPP_". >> > >> >2) Only keep the name 'assert' in the macro if you are keeping the >> >semantics of assert(), that is, it dies on failure if NDEBUG not defined. >> > If it prints a warning and recovers, or defaults to off, use >> >a different word. I personally don't like the inverted NDEBUG >> >approach, so would suggest a different semantics and different word. >> > >> >3) It's debatable if you want to allow it to be turned off or not. >> >If it can be turned off, people will misuse it to guard against errors >> >and be surprised when it doesn't. I often use a noisy warning that >> >only runs when DEBUG is positively defined (DEBUG_WARN_IF) and an abort >> >that cannot be turned off (ERROR_ABORT_IF). >> > >> >4) Don't try to snprintf() to a local buffer and then return. I >> >don't know C++ semantics for exceptions, but at least in C, combining >> >local stack variables with stack unwinding is asking for trouble. If you >> >are aborting, print to STDERR directly. If you are continuing, use a >> >normal heap allocation. >> > >> >Nathan Kurz >> >n...@verse.com >> >_______________________________________________ >> >Rcpp-devel mailing list >> >Rcpp-devel@lists.r-forge.r-project.org >> >https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >> >> _______________________________________________ >> Rcpp-devel mailing list >> Rcpp-devel@lists.r-forge.r-project.org >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > > > > -- > http://www.keittlab.org/ > -- http://www.keittlab.org/
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel