-
-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible Rcpp hotfix release to appease compiler nags w.r.t. deprecated pre-C++11 idioms #1201
Comments
Can't we just drop the inheritance on As for the version, my vote goes for four dots. |
I wondered about that too. And I don't feel I have a good handle on why it was needed in the past, but flipping to
The only problem with that is that we already use that form for 'interim test releases' i.e. the micro-snapshots between the releases. It's a bit murky to use the same form both ways. Part of me wants a clearer distinction. |
Most probably it was never needed. I would try a full revdep check without them, and I wouldn't expect any trouble. I mean, the definition of I checked other projects just in case, and they just remove them (example).
Fine for me. |
I don't have time or energy for that. I will make the minimal change to
Checking shows we have really made an 1.0.8.1 since January so maybe the standard '.hotfix' form works. |
Or maybe we do it two step. Get a narrower fix out now, and if anyone (you?) feels motivated to dig deeper prior to 1.0.9 we do that. It looks like a fairly marginal feature either way so probably not the issue to go all in on (and I do want to get back to UNWIND_PROTECT). |
I pushed a somewhat minimal fix (to two header files) plus the needed updates to mark it as a new version 1.0.8.2 (because .1 is currently committed) and started a full reverse-depends check (using Debian testing, i.e. standard compiler). I will email Kurt and he can test it against the newer gcc/g++-12 (which I could activate too). This will likely be a PR "shortly". |
Kurt Hornik emailed me because of an (unrelated) RcppArmadillo issue (involving a possible need for
-latomic
on Debian, that is still TBD) and noted that newer compilers nag a bit with respect tostd::unary_function()
andstd::binary_function()
. See for example in the results for RcppRedis which I looked at yesterday when it updated:When he emailed me earlier yesterday he only mentioned the thrid of these for
StringTransformer
and I quickly played with fix -- this is in fact simple enough thanks tostd::function
-- usingstd::function<bool(int)>
instead of the deprecatedstd::unary_function<int, bool>
is all it took in another example. I think replacingstd::binary_function
will be equally simple.The question now is how to best implement the check as we need to keep the old code for compatibility's sake. Shall we just use
#if __cplusplus >= 201103L
to flip all C++11 or later compilation to use
std::function()
? Or are there any downsides I am not seeing?(We will of course test fully at CRAN).
While we are at this we should probably also cherry-pick in #1193 which fixed a minor hoopla w.r.t. to C++98.
So these two changes, and we call it Rcpp 1.0.8-1 ? (And I will make sure to turn the unit test for three vs four version numbers off.)
Or do we have preference for four dots and call it 1.0.8.1 ?
The text was updated successfully, but these errors were encountered: