1. How does a registrar work?
A registrar is a node in a doubly linked list of static objects. The node constructor does *not* initialize the forward and backward pointers. Instead it relies on initialization to zero. This prevents order-of-construction problems. See https://github.com/jll63/Boost.OpenMethod/blob/master/include/boost/openmeth...
2. What kind of hashing are we doing?
It is described here: https://jll63.github.io/Boost.OpenMethod/#virtual_ptr_description_19 Perfect (collision-free) hashing, using the fastest possible hash function: (M * value) >> S, where M and S are found by random search. Hashing can be customized, or eliminated altogether in some use-cases.
3. "When an error is encountered, the program is terminated by a call to abort" what errors are there? Just pure virtual?
Other errors are: referencing a class that was not registered, failure to find hash factors, and dynamic vs static type mismatch in a "final" construct. By default, the library calls a vectored error handler that does nothing in release mode, and prints a diagnostic in debug mode; then it `abort`s. The error handler can be set to a function that throws an exception to prevent termination. By default, the library is exception agnostic.
4. Why do we need multiple policies and facets in a single project? Why couldn't we use a single one (at least for policies) project-wide?
Possible reasons: * A library author may use open-methods internally, and may want to use a specific policy, without depending on, or interfering with, code from the application, or other libraries. * Classes, methods, and overriders involved in dynamic loading may need an extra indirection for the v-table pointer, which other sets of classes and methods may not need. * If a subset of the classes uses only "final" constructs, or intrusive vptrs (https://jll63.github.io/Boost.OpenMethod/#virtual_ptr_with_vptr), or some other sort of vptr placement, there is probably no need to include them in the hash table. * For the library's unit tests ;-)
5. Do you have any real-world use-cases?
The library is derived from YOMM2 (https://github.com/jll63/yomm2), which has users, and even contributers! You can take a look at past issues and PRs, and google YOMM2. I also got feedback like "if I had known this existed, I would have used it". That is one of my motivations for submitting to Boost.
I looked at the ast.cpp example, but was a bit disappointed that it was a single argument method.
I deliberately de-emphasize multiple dispatch. It breaks my heart when someone walks out of one of my talks, saying: multi-methods, cool! but I never had any use for that. I insist that "multi" is the cherry on the "open" cake. A study showed that, even in languages that natively support multi-methods, the majority of methods have a single virtual parameter (https://openaccess.wgtn.ac.nz/articles/thesis/Multiple_Dispatch_in_Practice/...). Here is an example of triple dispatch: https://github.com/jll63/Boost.OpenMethod/blob/master/examples/adventure.cpp. By the way, TADS (a text game oriented language) natively supports multi-methods. J-L On Mon, Apr 28, 2025 at 12:35 PM Klemens Morgenstern via Boost <boost@lists.boost.org> wrote:
On Sun, Apr 27, 2025 at 9:15 PM Дмитрий Архипов via Boost < boost@lists.boost.org> wrote:
Dear Boost community. The peer review of the proposed Boost.OpenMethod will start on 28th of April and continue until May 7th. OpenMethods implements open methods in C++. Those are "virtual functions" defined outside of classes. They allow avoiding god classes, and visitors and provide a solution to the Expression Problem, and the banana-gorilla-jungle problem. They also support multiple dispatch. This library implements most of Stroustrup's multimethods proposal, with some new features, like customization points and inter-operability with smart pointers. And despite all that open-method calls are fast - on par with native virtual functions.
You can find the source code of the library at https://github.com/jll63/Boost.OpenMethod/tree/master and read the documentation at https://jll63.github.io/Boost.OpenMethod/. The library is header-only and thus it is fairly easy to try it out. In addition, Christian Mazakas (of the C++ Alliance) has added the candidate library to his vcpkg repository (https://github.com/cmazakas/vcpkg-registry-test). The library is also available in Compiler Explorer under the name YOMM2.
I got a few questions for the author:
1. How does a registrar work? 2. What kind of hashing are we doing? 3. "When an error is encountered, the program is terminated by a call to abort" what errors are there? Just pure virtual? 4. Why do we need multiple policies and facets in a single project? Why couldn't we use a single one (at least for policies) project-wide? 5. Do you have any real-world use-cases? I looked at the ast.cpp example, but was a bit disappointed that it was a single argument method.
Thanks,
Klemens
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost