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

From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2025-05-05 01:10:28

> First, thanks for all the effort you put into writing a solid library on an
> experimental subject.

Hi Yannick! Thank you for the feedback.

> 1. Concerning the overrider selection, when the perfect match is not found, it
>    is said that an arbitrary choice is made.

Everybody seems to dislike this, including myself. It is the behavior specified
in N2216.

> My tests on virtual inheritance and two dimensions dispatch showed that this
> is the last defined compatible overrider that is chosen. Do you confirm ?

I don't. It's a secret ;-) Only I can use that knowledge in my unit tests.

The only guarantee is that the same overrider is always picked for the same set
of virtual arguments for the duration of the process.

> 2. The class virtual_ptr<Class> accepts only classes that inherit Class. Would
>    it be possible to accept inheritance unrelated classes e.g.
>    std::filesystem::path and std::string ?

Not directly. What would the method signature, and the method call look like?
You could wrap them in a class hierarchy, e.g. AbstractPath, FileSystemPath and
StringPath. I have some ideas about supporting std::any virtual
parameters though,
where the overriders would specify an exact type, something like:

    BOOST_OPENMETHOD(delete, (virtual_<std::any> path), void);

    BOOST_OPENMETHOD_OVERRIDE(delete, (std::filesystem::path path), void) {
        ...
    }

    BOOST_OPENMETHOD_OVERRIDE(delete, (std::string path), void) {
        ...
    }

> 3. Would it be possible to get rid of the class declarations ? Indeed they are
>    already declared in the template parameter of the virtual_ptr<> arguments
>    so they could be implicitly defined here.

Ah but you are forgetting about intermediate classes in the hierarchy, between
the method and the overrider:

    struct A { ... };
    struct I : A { ... };
    struct B : I { ... };

    BOOST_OPENMETHOD(whatever, (virtual_ptr<A>), void);

    BOOST_OPENMETHOD_OVERRIDE(whatever, (virtual_ptr<B>), void) {
        ...
    }

    auto p = std::make_unique<I>();
    whatever(*p);

That being said, with_vptr must be called at every level of the hierarchy, and
indeed, it does class registration for you.

At some point in the future, reflection might be good enough to help with this.

J-L

On Sun, May 4, 2025 at 4:11 PM Yannick Le Goc <ylegoc_at_[hidden]> wrote:
>
> Hi Jean-Louis,
>
> First, thanks for all the effort you put into writing a solid library on an experimental subject.
> I have a few questions.
>
> 1. Concerning the overrider selection, when the perfect match is not found, it is said that an arbitrary choice is made.
> My tests on virtual inheritance and two dimensions dispatch showed that this is the last defined compatible overrider that is chosen.
> Do you confirm ? Or what is the algorithm ?
>
> 2. The class virtual_ptr<Class> accepts only classes that inherit Class. Would it be possible to accept inheritance unrelated classes e.g. std::filesystem::path and std::string ?
>
> 3. Would it be possible to get rid of the class declarations ? Indeed they are already declared in the template parameter of the virtual_ptr<> arguments so they could be implicitly defined here.
>
> Yannick
>
>
> On Sun, May 4, 2025 at 11:15 AM Jean-Louis Leroy via Boost <boost_at_[hidden]> wrote:
>>
>> >     struct dynamic_policy
>> >         : boost::openmethod::default_policy::fork<dynamic_policy>::replace<
>> >               boost::openmethod::policies::extern_vptr,
>> >               boost::openmethod::policies::vptr_vector<
>> >                   dynamic_policy,
>> >                   boost::openmethod::policies::indirect_vptr>> {};
>> >
>> > Committing this code to any project I've worked on would've left most of my
>> > coworkers absolutely checked out.
>>
>> With the changes in the review branch, you can now say:
>>
>>     struct dynamic_policy
>>         : boost::openmethod::default_policy::fork<dynamic_policy>::add<
>>             boost::openmethod::policies::indirect_vptr>> {};
>>
>> I am pretty sure I can make this work:
>>
>>     struct map_policy
>>         : default_policy::fork<map_policy>::with<vptr_map<map_policy>> {};
>>
>> I.e. instead of saying `replace<Facet1, Implementation1>::replace<Facet2,
>> Implementation2>` you can just say `with<Implementation1, Implementation2>`. If
>> an implementation of the same facet exists in the policy, it will be replaced
>> with the new one, otherwise the implementation will be added. Not in the review
>> branch yet.
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost