$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.