[Rcpp-devel] assert() for Rcpp?

Dale Smith DSmith at nexidia.com
Wed Feb 18 21:25:58 CET 2015


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


More information about the Rcpp-devel mailing list