[Rcpp-devel] assert() for Rcpp?

[Tim Keitt]

On Tue, Feb 24, 2015 at 9:45 AM, Miratrix, Luke <lmiratrix at 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
>
>
> lmiratrix at stat.harvard.edu
> 510-735-7635
>
>
>
>
>
>
> On 2/18/15, 3:25 PM, "Dale Smith" <DSmith at 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-bounces at lists.r-forge.r-project.org
> >[mailto:rcpp-devel-bounces at 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 at lists.r-forge.r-project.org
> >Subject: Re: [Rcpp-devel] assert() for Rcpp?
> >
> >On Tue, Feb 17, 2015 at 4:41 PM, Miratrix, Luke
> ><lmiratrix at 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
> >nate at verse.com
> >_______________________________________________
> >Rcpp-devel mailing list
> >Rcpp-devel at 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 at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel




-- 
http://www.keittlab.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20150224/a950b7aa/attachment.html>