[Rcpp-devel] assert() for Rcpp?

[Miratrix, Luke]

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?


(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