Uncaught v8pp::class_<T, v8pp::shared_ptr_traits> is already registered in isolate XXX before of v8pp::class_<T v8pp::raw_ptr_traits>

[yonatan-mitmit]

This issue is more of a design question.
Why did you decide to have the ptr_traits separate in all but the v8pp::classes registry.
This means that if someone uses class_<X,shared_ptr_traits> and another class Y has an X*/X& inside, that X&/X* cannot be wrapped.

The check in classes::find explicitly validates the same traits are used, but this means that if X is wrapped with shared_ptr_traits it cannot be used as member in another wrapped class.

[pmed]

If I understood question, design decision is simple: both X and Y wrapped classes shall use the same pointer traits.

[rubenlg]

This design is very limiting when using other smart pointer libraries. For example, I tried to wrap parts of the OpenSceneGraph library, which has its own osg::ref_ptr<X> pointer type (similar to std::shared_ptr, but with intrusive reference counting for better cache coherency), and it's really challenging, at least with pointer traits.

The reason is precisely the intrusive reference counting which forces every class that needs to be wrapped with osg::ref_ptr to extend osg::Referenced (that's where the counter resides). Only certain objects extend that class (those that need reference counting because they are nodes in the graph). As soon as I try to wrap any object that is not reference counted (e.g. an osg::Matrix), I can't compile the project, because it's not possible to construct a osg::ref_ptr around that object.

Ideally, v8pp would support different pointer traits for each wrapped object so that we can use it to wrap existing third-party libraries that weren't necessarily written with v8pp in mind.