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

Deprecation warnings on g++ 7.1.0 at MacOS 10.12.4 #689

Closed
alexcpsec opened this Issue May 5, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@alexcpsec

Not a big deal, everything working as intended, but you may want to look at these warnings when building code with Rcpp using g++ 7.1.0

In file included from /Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/include/Rcpp/Module.h:338:0,
                 from /Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/include/Rcpp.h:64,
                 from osutil.cpp:1:
/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/include/Rcpp/module/Module_Property.h:103:41: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
     void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
                                         ^~~~~
/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/include/Rcpp/module/Module_Property.h:161:41: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
     void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
                                         ^~~~~
@eddelbuettel

This comment has been minimized.

Show comment
Hide comment
@eddelbuettel

eddelbuettel May 5, 2017

Member

Appreciate that! Noticed that 7.1 is out and that I can probably get it in Debian unstable too.

Would you know what the new and recommended form is?

Member

eddelbuettel commented May 5, 2017

Appreciate that! Noticed that 7.1 is out and that I can probably get it in Debian unstable too.

Would you know what the new and recommended form is?

@alexcpsec

This comment has been minimized.

Show comment
Hide comment
@alexcpsec

alexcpsec May 5, 2017

Sorry, no clue. C++11 reads like black magic incantations to me. :(

Sorry, no clue. C++11 reads like black magic incantations to me. :(

@eddelbuettel

This comment has been minimized.

Show comment
Hide comment
@eddelbuettel

eddelbuettel May 5, 2017

Member

Some somewhat dense stuff here at cppreference.com.

Member

eddelbuettel commented May 5, 2017

Some somewhat dense stuff here at cppreference.com.

@kevinushey

This comment has been minimized.

Show comment
Hide comment
@kevinushey

kevinushey May 5, 2017

Contributor

Here's the associated paper:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html

From what I read, the tl;dr is: don't use exception specifications to dictate what type of exception can / should be thrown; just leave it out. It's only worth specifying when you want to indicate that a function will not throw an exception (as it enables certain optimizations).

The simplest fix is to just delete that throw(...) code.

Contributor

kevinushey commented May 5, 2017

Here's the associated paper:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html

From what I read, the tl;dr is: don't use exception specifications to dictate what type of exception can / should be thrown; just leave it out. It's only worth specifying when you want to indicate that a function will not throw an exception (as it enables certain optimizations).

The simplest fix is to just delete that throw(...) code.

@eddelbuettel

This comment has been minimized.

Show comment
Hide comment
@eddelbuettel

eddelbuettel May 5, 2017

Member

Thanks so much -- I can certainly fire up a Debian unstable Docker container and try that.

Member

eddelbuettel commented May 5, 2017

Thanks so much -- I can certainly fire up a Debian unstable Docker container and try that.

@epipping

This comment has been minimized.

Show comment
Hide comment
@epipping

epipping May 6, 2017

Contributor

I've just come across these warnings as well. However, while in C++11 and C++14 mode they're indeed warnings, in C++17 mode they're errors for me, making this quite a bit more pressing (since all you need to do to get these errors is to #include <Rcpp.h>, this renders Rcpp unusable with g++ in C++17 mode for now).

In file included from /usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/Module.h:338:0,
                 from /usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp.h:64,
                 from foo.cc:1:
/usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/module/Module_Property.h:103:41: error: ISO C++1z does not allow dynamic exception specifications
     void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
                                         ^~~~~
/usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/module/Module_Property.h:161:41: error: ISO C++1z does not allow dynamic exception specifications
     void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
                                         ^~~~~
make: *** [foo.o] Error 1
g++-7 -I/usr/local/Cellar/r/3.4.0_1/R.framework/Resources/include -DNDEBUG   -I"/usr/local/lib/R/3.4/site-library/Rcpp/include" -I"/Users/pipping" -I/usr/local/opt/gettext/include -I/usr/local/opt/readline/include -I/usr/local/include  -std=c++17 -fPIC  -g -O2  -c foo.cc -o foo.o

According to this thread on gcc-dev there is no way to demote this error to a warning.

Contributor

epipping commented May 6, 2017

I've just come across these warnings as well. However, while in C++11 and C++14 mode they're indeed warnings, in C++17 mode they're errors for me, making this quite a bit more pressing (since all you need to do to get these errors is to #include <Rcpp.h>, this renders Rcpp unusable with g++ in C++17 mode for now).

In file included from /usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/Module.h:338:0,
                 from /usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp.h:64,
                 from foo.cc:1:
/usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/module/Module_Property.h:103:41: error: ISO C++1z does not allow dynamic exception specifications
     void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
                                         ^~~~~
/usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/module/Module_Property.h:161:41: error: ISO C++1z does not allow dynamic exception specifications
     void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
                                         ^~~~~
make: *** [foo.o] Error 1
g++-7 -I/usr/local/Cellar/r/3.4.0_1/R.framework/Resources/include -DNDEBUG   -I"/usr/local/lib/R/3.4/site-library/Rcpp/include" -I"/Users/pipping" -I/usr/local/opt/gettext/include -I/usr/local/opt/readline/include -I/usr/local/include  -std=c++17 -fPIC  -g -O2  -c foo.cc -o foo.o

According to this thread on gcc-dev there is no way to demote this error to a warning.

@eddelbuettel

This comment has been minimized.

Show comment
Hide comment
@eddelbuettel

eddelbuettel May 6, 2017

Member

We will take care of them.

In the meantime, and as you're at it, could you confirm that commenting out / removing these two suppresses the issue? It should have no effect on code or behaviour.

Member

eddelbuettel commented May 6, 2017

We will take care of them.

In the meantime, and as you're at it, could you confirm that commenting out / removing these two suppresses the issue? It should have no effect on code or behaviour.

@epipping

This comment has been minimized.

Show comment
Hide comment
@epipping

epipping May 6, 2017

Contributor

The change

--- /usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/module/Module_Property.h.bak	2017-05-06 14:13:01.000000000 +0200
+++ /usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/module/Module_Property.h	2017-05-06 14:14:02.000000000 +0200
@@ -100,7 +100,7 @@
     SEXP get(Class* object) {
         return Rcpp::wrap( (object->*getter)() ) ;
     }
-    void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
+    void set(Class* object, SEXP value) {
         (object->*setter)(
                           Rcpp::as< typename Rcpp::traits::remove_const_and_reference< PROP >::type >( value )
                            ) ;
@@ -158,7 +158,7 @@
     SEXP get(Class* object) {
         return Rcpp::wrap( (object->*getter)() ) ;
     }
-    void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
+    void set(Class* object, SEXP value) {
         setter( object,
                 Rcpp::as< typename Rcpp::traits::remove_const_and_reference< PROP >::type >( value )
                 ) ;

allows me to compile the file in C++17 mode, yes.

Update: It might be worth mentioning that even with -Wall -Wextra, afterwards, I do not get any warnings.

Contributor

epipping commented May 6, 2017

The change

--- /usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/module/Module_Property.h.bak	2017-05-06 14:13:01.000000000 +0200
+++ /usr/local/lib/R/3.4/site-library/Rcpp/include/Rcpp/module/Module_Property.h	2017-05-06 14:14:02.000000000 +0200
@@ -100,7 +100,7 @@
     SEXP get(Class* object) {
         return Rcpp::wrap( (object->*getter)() ) ;
     }
-    void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
+    void set(Class* object, SEXP value) {
         (object->*setter)(
                           Rcpp::as< typename Rcpp::traits::remove_const_and_reference< PROP >::type >( value )
                            ) ;
@@ -158,7 +158,7 @@
     SEXP get(Class* object) {
         return Rcpp::wrap( (object->*getter)() ) ;
     }
-    void set(Class* object, SEXP value) throw(std::range_error,Rcpp::not_compatible){
+    void set(Class* object, SEXP value) {
         setter( object,
                 Rcpp::as< typename Rcpp::traits::remove_const_and_reference< PROP >::type >( value )
                 ) ;

allows me to compile the file in C++17 mode, yes.

Update: It might be worth mentioning that even with -Wall -Wextra, afterwards, I do not get any warnings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment