Re: [OpenMethod] review starts on 28th of April

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2025-05-05 10:28:13

> > > 1. I've tried playing with custom RTTI, because that's what the clang AST
> > > API uses. When implementing boost_openmethod_vptr, I used
> > > default_policy::static_vptr<T>. But that seems to defeat the purpose of
> > > policies and scoping - is there a way to obtain the policy that invoked
> > > boost_openmethod_vptr?
> >
> > Ah, good point. I'm going to look into this. Since we cannot specialize function
> > templates, I'll probably have to pass a Policy& as a parameter.
> >
> > Logically, with_vptr should usable several times in the same hierarchy, adding
> > several vptrs to the objects. It makes sense, because external vptrs already
> > permit associating several vpts to the same object.
> >
> > Can you share your code? My first idea would be a clang policy. I guess that you
> > put a switch in boost_openmethod_vptr?
>
> Since building with the clang API itself is a nightmare, I've created
> a toy example, but with the same idea:
>
> enum class kind : std::uintptr_t { unknown, n1, n2 };
>
> class base_node {
>     kind k_;
>
>   protected:
>     base_node(kind k) noexcept : k_(k) {
>     }
>
>   public:
>     kind getKind() const {
>         return k_;
>     }
> };
>
> class node1 : public base_node {
>   public:
>     node1() noexcept : base_node(kind::n1) {
>     }
> };
>
> class node2 : public base_node {
>   public:
>     node2() noexcept : base_node(kind::n2) {
>     }
> };
>
> boost::openmethod::vptr_type boost_openmethod_vptr(const base_node& b) {
>     switch (b.getKind()) {
>     case kind::n1:
>         return boost::openmethod::default_policy::static_vptr<node1>;
>     case kind::n2:
>         return boost::openmethod::default_policy::static_vptr<node2>;
>     default:
>         return boost::openmethod::default_policy::static_vptr<base_node>;
>     }
> }
>
[snip]

> > 5. I got the impression that virtual_ptr can't be used with custom RTTI. Is
> > that true?
> >
> > No it's not, that would be very disappointing ;-)
> >
> > virtual_ptr obtains the vptr from the policy, which is the second template
> > parameter with the default value BOOST_OPENMETHOD_DEFAULT_POLICY.
>
> When explaining virtual_, the documentation states:
>
> "By itself, virtual_ does not provide any benefits. Passing the
> virtual argument by reference almost compiles to the same code as
> creating a virtual_ptr, using it for one call, then throwing it way.
> The only difference is that the virtual argument is passed as one
> pointer instead of two.
>
> However, we can now customize how the vptr is obtained. When the
> method sees a virtual_ parameter, it looks for a boost_openmethod_vptr
> function that takes the parameter (by const reference), and returns a
> vptr_type. ..."
>
> Which suggests that my boost_openmethod_vptr won't be called unless I
> use virtual_. How would I write my example above so it calls
> boost_openmethod_vptr?

Answering my own question again, and for reference, if you implement a
custom RTTI facet, you don't need boost_openmethod_vptr - this
function is performed by the dynamic_type function of the facet.
What's the rationale behind having these two ways of achieving the
same thing?

Thanks,
Ruben.