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. 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/
_______________________________________________ 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
