C++11 and later support
Closed this issue · 11 comments
Moving the C++11 discussion here so there's a consolidated list of information about what this kind of support could entail. I have been well out of the C++ loop and while I know there have been a ton of changes to the language and stdlib I don't know what can and should be used.
First, Python has done this move with https://github.com/pybind/pybind11 replacing Boost.Python.
For one, Rice would greatly benefit from variadic templates. We could get rid of the code generation scripts that spell out 0 - 15 arguments for method binding, and we would be able to get rid of this artificial limitation.
Looks like we can already support lambdas as per #99 (comment), it would be worth checking the full API to ensure that isn't just a hack and is properly supported.
Also at a higher level, Rice makes use of an API that ruby-core is (was?) trying to deprecate and this could be a good time to look into other ways of hooking our wrappers into Ruby proper. See #105 for more details.
/cc @ankane
Making good progress with this but won't be able to replace all of the codegen, as there at some point simply needs to be direct linkage to the wrapped function and all of its arguments. However, I got rid of a lot of it! See #120
As for rb_frame_method_id_and_class (issue #105), the Ruby team has decided not to deprecate and as of 2.7.0 it's still there and exported, and there's no other way to get this information that's a publicly exported API so won't be making any changes there.
Looks much cleaner 🎉
It looks like C++17 is supported with the changes on master 🎉
With the latest release, Rice fails with:
In file included from /Users/andrew/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/rice-2.2.0/ruby/lib/include/rice/Data_Type.hpp:4:
/Users/andrew/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/rice-2.2.0/ruby/lib/include/rice/Data_Type_defn.hpp:207:10: error:
no template named 'auto_ptr' in namespace 'std'
static std_unique_ptr<detail::Abstract_Caster> caster_;
^~~~~~~~~~~~~~
/Users/andrew/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/rice-2.2.0/ruby/lib/include/rice/detail/ruby.hpp:74:29: note:
expanded from macro 'std_unique_ptr'
#define std_unique_ptr std::auto_ptr
~~~~~^Ah, the conditional for choosing unique_ptr over auto_ptr must not work correctly for newer C++. As for cutting a new release, master currently requires C++14, which is technically a breaking change, but at this point it shouldn't be something other people run into unless they're really on old systems. But then they can just stay on 2.2.0 I guess? I'll check this failure out and look at getting a 2.3.0 out.
It's probably better to do a major version bump for the C++14 change, as I think gems that depend on Rice will need to update their $CXXFLAGS.
Hey @jasonroelofs, wanted to get your latest thoughts on a C++17 release (have a 2nd gem that could use it). Currently, users need to add Rice to their Gemfile manually.
gem 'rice', github: 'jasonroelofs/rice' # for now for c++17Ah, yeah, I really need to carve out some time and ensure things are ok with Ruby 3 on the horizon and to get a new release out for C++14/17. Obviously hasn't been a high priority but I'll try to make it more so.
Thanks @jasonroelofs. fwiw, I was able to get it to build (and passing tests) with Ruby 3 preview 1 with:
CPPFLAGS=-fdeclspec ./configure
# skip bootstrap
makebut not exactly sure the best place to put -fdeclspec.
There's a fix in place for the declspec, and we will definitely get a proper release out soon! The next release will require at least C++14, so going to close out this ticket.
Sounds great, thanks @jasonroelofs!