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

Dmitry - thanks for being the review manager for this library, and Jean-Louis - thanks for submitting it! I am the technical writer for the C++ Alliance, and have only reviewed the documentation. *Review of OpenMethod library documentation* The documentation falls short in a number of key areas that I try to address in this review. It is good that there is enough information to provide detailed feedback. Currently though the documentation would get a "D" - not a pass mark - a decent base but requires work. INTRODUCTION An introduction to a library should be suitable for developers who are not familiar with the role of open methods. They should already be decent C++ developers. The goal of an introduction is to answer the question - "why should I be interested in this?". I suggest something like this: Open methods are a language mechanism that allows you to define new behaviors (essentially, methods) for existing types *without *modifying those types. C++ doesn't natively support open methods in the way that some dynamic languages (like Common Lisp) do. Keys to the purpose of open methods are the *Open/Closed Principle* (OCP) - where a software entity (class, module, function, etc.) should be *open *for extension but *closed *for modification - and the more complicated concept of *multiple dispatch*. In *single** dispatch* method resolution is based on the runtime type of a single object, usually the one the method is called on. With multiple dispatch method resolution is based on the runtime types of two or more arguments. C++ supports single dispatch via virtual functions, multiple dispatch has to be simulated and is coded into this library. The main advantage of open methods is that they help prevent bugs when modifying stable code. For example, say you have a stable text processor. When a new file format becomes popular (say, a variant of markdown), your code can be extended to support the new format without modifying the existing code. In simple terms, *open methods allow for safer scaling of software*. Another specific use is you can add behavior involving multiple types, for example adding collision handling between type `A` and type `B` that is to date unsupported in your code. Say you had a simulation of watercraft, but had not supported hovercraft. You now add hovercraft, and need to add collision detection, and the effects of the collision to both parties, but would prefer to do this without modifying your existing codebase. This is where multiple dispatch is useful - both as a concept and a feature. This introduction describes two use-cases that are easy to understand and can now be referenced later in the documentation as needed to clarify details. Of course, there may be better use-cases than those I have described here. The current introduction is interesting, but perhaps should be under a secondary heading "History of Open Methods" that follows the intro. To be clear - does the library implement ALL the features of the N2216 paper - if not all, then list those implemented. It is not a good idea to require a reader reference documentation outside of the library for essential knowledge. The N2216 paper is long and heavy-going, but as it's not in our control the link could break during the lifetime of the library (say, 5 to 15 years). It is totally OK to provide references, though expect some reference links to break as time passes. *Required information should be in the library doc*. A kinda nit - this is funny "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - but - is it really true? If you have a class Banana - how do you get the gorilla and jungle - wouldn't it be the other way around (jungle inherits animals, trees, trees inherit fruit etc)? However, if this is true, perhaps give an example to show how it is a problem? GETTING STARTED Following the introduction, there should be a *Getting Started* section which goes over 1) Requirements 2) Steps to install 3) Dependencies (Boost libs, std libs, other libs, etc.) 4) hello world tutorial. Getting up and running should come before Tutorials. PERFORMANCE Perhaps add a table of performance of some sort that readers can relate to - say, comparing an open method to a class method with both doing the same thing. TUTORIALS Great that there is a range of tutorials addressing the worth of open methods. However, they are not really tutorials unless they contain steps for the reader to follow. Step 1 - copy and paste this example. Step 2 - run it and examine the output, Step 3 - add this feature and run again. Step 4 - notice how the output has changed...etc. etc. It would be most useful if the tutorials related to the use-cases first introduced, showing how the desired results are achieved. It is not clear enough what the library does, versus what the sample source code does. Great tutorials have well commented code - ideally you can follow the code flow by reading the comments. TERMS and ACRONYMS Acronyms are introduced that I am unaware of, without an initial explanation. For example, Unlike function declarations, which can occur multiple times in a TU, an overrider declaration cannot. What is a TU? Can this be defined in full on first use? Similar for ADL, AST, CRTP etc. And for terms such as "guide function" - add a definition on first use. REFERENCE If all the components of the library are listed here, great, a reference should be *complete*. I would really like to see the Reference further divided into sections based on type: * Classes ** fields ** methods * Interfaces * Structures * Constants * Macros * Functions (if external to any class) - Currently we have to examine each entry, or guess (I don't like guessing) what each entry is. The biggest missing component though is the "why" (the use-case) - the *Description *of each entry should say in what situation you would be interested in this construct - or to put it another way - what problem does having this solve - or help with ? If references are arranged alphabetically within each section (Classes, Macros etc.) - they are easy to locate. ERRORS and EXCEPTIONS It is not clear to me what errors or exceptions might be thrown by any of the entries. All errors/exceptions thrown by the library code should be listed under the entry that might fire them. For maximum usefulness, include a table of errors and exceptions and* what you should do about it if you get such an error* could be described too - say likely causes and likely resolutions. A complete structured Reference, with descriptions, return values, use cases and errors would be great to see. ACKNOWLEDGEMENTS, REFERENCES The documentation could end with any acknowledgements (designers, testers, motivators) and References such as N2216 and no doubt others. *In Summary:* I had to refer to too much information outside of the library doc to get a basic understanding of the use-cases and problems that are being addressed here. The documentation as it stands describes what the code does but almost entirely from an inward looking perspective and almost never addresses the "when I should use this" from a use-case - or more likely a component of a use-case - perspective. Keys to necessary improvements would be: 1. an introduction explaining the "why I should be interested" with some compelling use-cases. The more relatable the use-cases, the more interest and users you will get. 2. step by step tutorials showing how the concepts of open methods solve problems 3. structured and complete reference *Bonus Points* 1. As open methods would often be added to existing software, are there *Best Practices* on how to design and implement code so that the addition of open methods at a later date is as seamless as can be? If so, add a section entitled Best Practices before the Reference. This would be a good place to reference external books or papers or articles if they are useful. 2. Are there other Boost libraries that play well with OpenMethods - even if you have limited experience of this a start would be helpful. *Having said all this - the case for open methods is quite strong, from the safer scalability of software perspective in particular, and I hope my 2c is useful.* *-* thanks *Peter Turcan* On Tue, Apr 29, 2025 at 12:49 PM Ruben Perez via Boost < boost@lists.boost.org> wrote:

On Tue, 29 Apr 2025 at 18:30, Ruben Perez <rubenperez038@gmail.com> wrote:

...

On Sun, 27 Apr 2025 at 15:15, Дмитрий Архипов 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. [...] * What is your evaluation of the implementation?

I've seen that many of the macros use __COUNTER__ to generate unique identifiers. If I'm reading this correctly, this includes BOOST_OPENMETHOD_DECLARE_OVERRIDER and BOOST_OPENMETHOD_INLINE_OVERRIDE, which are supposed to be safe to be placed in headers. Is this correct?

I've had bad experiences with macros using __COUNTER__ in headers in the past. boost/asio/coroutine.hpp, which simulates coroutines using switch/cases, uses __COUNTER__. Placing such constructs in headers can inadvertently yield ODR violations. In my case, the ODR violation went like this:

// header1 void f1() { BOOST_ASIO_CORO_REENTER(...) { ... } // Internally uses __COUNTER__ }

// header2 void f2() { BOOST_ASIO_CORO_REENTER(...) { ... } // Internally uses __COUNTER__ }

// f1.cpp #include "header1.hpp" // __COUNTER__ here is 0 #include "header2.hpp" // __COUNTER__ here is 1

// f2.cpp #include "header2.hpp" // __COUNTER__ here is 0 #include "header1.hpp" // __COUNTER__ here is 1

This makes f1() and f2() have distinct bodies in f1.cpp and f2.cpp, which is an ODR violation. It caused random test failures under MSVC in Release mode only, and it took me forever to identify the root cause of the issue.

Are the macros I mention also vulnerable to this problem?

Answering my own question: no, they are not because the generated symbols have always static linkage. If used in headers as shown above, several, potentially differently named symbols will be generated, but that's okay since re-registering stuff multiple times seems to be a no-op.

...

Cheers, Ruben.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi Peter, Thanks for your review! I'll think about your remarks on the introduction, and probably blend some of it in.

To be clear - does the library implement ALL the features of the N2216 paper - if not all, then list those implemented.

I'll add a dedicated top-level entry for this. Probably it should not be too close to the top, because it will speak to more hardcore users, not to people who are just discovering open-methods and who have no awareness of N2216.

It is totally OK to provide references, though expect some reference links to break as time passes. *Required information should be in the library doc*.

Ok.

A kinda nit - this is funny "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - but - is it really true?

Yes it is :-D Take the Matrix example, where you want to add serialization to the matrix hierarchy. If you plant a `virtual void to_json(std::ostream&)` in the base class, and implement it in the subclasses, any consumer of your matrix library will drag in the iostream library. Matrix is the banana you wanted. The iostream library is the gorilla. You'll pull iostream's dependencies in as well. Jumping from hierarchy to hierarchy in that fashion, you'll pull much of the entire jungle. People did a lot of this when OOP became mainstream. Later patterns, principles, etc were designed to mitigate the problem. Visitors, dependency injection, interfaces, etc. Open-methods are a solution, but less clumsy I believe. GETTING STARTED

Following the introduction, there should be a *Getting Started* section which goes over 1) Requirements 2) Steps to install 3) Dependencies (Boost libs, std libs, other libs, etc.) 4) hello world tutorial.

Getting up and running should come before Tutorials.

OK, those should not be relegated to the reference. PERFORMANCE

Perhaps add a table of performance of some sort that readers can relate to - say, comparing an open method to a class method with both doing the same thing.

https://jll63.github.io/Boost.OpenMethod/#tutorials_performance does that, but in terms of instructions, not timings. Working on this project has destroyed my faith in micro-benchmarks.

However, they are not really tutorials unless they contain steps for the reader to follow. Step 1 - copy and paste this example. Step 2 - run it and examine the output, Step 3 - add this feature and run again. Step 4 - notice how the output has changed...etc. etc.

It would be most useful if the tutorials related to the use-cases first introduced, showing how the desired results are achieved.

On this subject, what do you think of Andrzej's distaste of the Animals example? And my motivation for it? I don't want to put my words in Andrzej's mouth, you'll find that dialogue easily. I do see his point.

TERMS and ACRONYMS

Acronyms are introduced that I am unaware of, without an initial explanation. For example,

Unlike function declarations, which can occur multiple times in a TU, an overrider declaration cannot.

What is a TU? Can this be defined in full on first use? Similar for ADL, AST, CRTP etc. And for terms such as "guide function" - add a definition on first use.

I *think* I kept the acronyms to the "advanced" parts of the doc. I think that any moderately advanced C++ programmer knows what ADL is...but I will make sure that in any given section the first mention of an acronum is: Argument Dependant Lookup (ADL).

I would really like to see the Reference further divided into sections based on type: * Classes ** fields ** methods * Interfaces * Structures * Constants * Macros * Functions (if external to any class)

So, I struggled with this. I opted for a "thematic" grouping - putting strongly related constructs close to one another in the sidebar. But that grouping jumps across categories. Some facets are templates, some are classes. Should they be scattered between templates and classes? This approach seems to work well only for the macros.

- Currently we have to examine each entry, or guess (I don't like guessing) what each entry is.

Yeah I experimented with other schemes, trying to get guidance from other adoc based documentations. There are many variations. I tried prefixing every entity with its category - e.g. "class template method", "class template method::override", but this causes a lot of wrapping in the left sidebar. I am considering removing the "Reference" level to gain one level. Instead of: Reference BOOST_OPENMETHOD Synopsis Description BOOST_OPENMETHOD_OVERRIDE Synopsis Description ...go straight to : BOOST_OPENMETHOD Synopsis Description BOOST_OPENMETHOD_OVERRIDE Synopsis Description What do you think? I like adoc but it can be limiting...

If references are arranged alphabetically within each section (Classes, Macros etc.) - they are easy to locate.

In YOMM2 I have a flat alphabetically ordered index (https://jll63.github.io/yomm2/#index). Maybe thematic grouping is a bad idea. After all it's a reference, not a novel.

ERRORS and EXCEPTIONS

It is not clear to me what errors or exceptions might be thrown by any of the entries. All errors/exceptions thrown by the library code should be listed under the entry that might fire them. For maximum usefulness, include a table of errors and exceptions and* what you should do about it if you get such an error* could be described too - say likely causes and likely resolutions.

It is hard to document accurately because of the customization points.

A complete structured Reference, with descriptions, return values, use cases and errors would be great to see.

Do you mean this style (from Variant2)? Effects: Initializes the variant to hold the same alternative and value as w. Throws: Any exception thrown by the move-initialization of the contained value. Remarks: This function does not participate in overload resolution unless std::is_move_constructible_v<Ti> is true for all i. I tried it. But it is difficult to squeeze the library's flexibility into this mold. In case of error, it aborts. But before that it calls error handling facet. Which can throw, or not - it's a customization point. I guess I could have a Errors instead of a Throws: Errors: Call the error handler specified in the policy's error_handler facet, then call abort. More importantly, I felt that this style is robotic. What are your favorite Boost documentations?

ACKNOWLEDGEMENTS, REFERENCES

The documentation could end with any acknowledgements (designers, testers, motivators) and References such as N2216 and no doubt others.

Yes.

The documentation as it stands describes what the code does but almost entirely from an inward looking perspective and almost never addresses the "when I should use this" from a use-case - or more likely a component of a use-case - perspective.

1. an introduction explaining the "why I should be interested" with some compelling use-cases. The more relatable the use-cases, the more interest and users you will get.

You seem to agree with Andrzej. By the way (BTW ;-) ) he likes YOMM2's intro better. Can you take a look and tell me what you think? https://github.com/jll63/yomm2

2. Are there other Boost libraries that play well with OpenMethods - even if you have limited experience of this a start would be helpful.

Yes. * Using a flat_unordered_map in place of a std one. That brings dispatch speed closer to my perfect hash solution. * Interoperability with intrusive smart pointers.

I hope my 2c is useful.

You are a technical writer, I am a just code writer trying to do a technical writer's job. That's worth a lot more than 2c ;) J-L

Jean-Louis, Thanks for your feedback on my comments. To answer your specific questions:

On this subject, what do you think of Andrzej's distaste of the Animals example? And my motivation for it? I don't want to put my words in Andrzej's mouth, you'll find that dialogue easily.

I think the Animals scenario is not relatable enough for a developer scanning libraries for one that might help them out. The scenarios I like best are: 1. the new file format I included in the proposed introduction 2. adding new UI widgets in a GUI framework 3. new behaviours (AI, physics) to types in a simulation or game engine 4. extending a logging system with new output I am assuming the main use of your library is enabling developers to plug in new behavior by adding subclasses or overriding virtual functions, without breaking or editing the system’s core - though I do like the idea of adding a "multiple dispatch" scenario or two as it shows the wider flexibility of open methods - though the use-cases here seem much narrower and so specific they might seem contrived.

I am considering removing the "Reference" level to gain one level. Instead of:

Reference BOOST_OPENMETHOD Synopsis Description BOOST_OPENMETHOD_OVERRIDE Synopsis Description

...go straight to :

BOOST_OPENMETHOD Synopsis Description BOOST_OPENMETHOD_OVERRIDE Synopsis Description

What do you think?

I prefer having a top level *Reference *heading. It is in a different style than the introductions and tutorials - and typically is not read in any kind of order. Most use of a reference is to jump into the topic you are working on (class, template, macro, method, structure etc.) - extract the info you need - and then leave the doc without looking outside of that one topic. This means the reference needs to be complete (as you say "robotic" in the sense of consistent and complete). I still prefer grouping all types under a second level heading such as *Macros*, *Templates*, *Classes* etc. Grouping items "thematically" is the thesaurus approach and has some charm to it. Works for overviews, tutorials, architecture descriptions, but for a Reference I prefer to group things rigidly (type then alphabetically), but add a *See Also* heading after each description (say of a template) that has a list of links to other entries that are thematically relevant - or perform the inverse operation (open -> close, add -> delete, etc.).

What are your favorite Boost documentations?

Mostly, Boost library documentation is comprehensive but requires a higher level of assumed knowledge than I would like to see. The usual culprits are an Introduction that does not describe the purpose of the library, or code definitions/examples or output that has no descriptive text. Make it easy for your potential developers by adding descriptive text to just about all entries of source code, syntax, diagrams or output. Some good library Reference sections are in Boost.Hana and Boost.Geometry - note the one sentence introductions to each construct, description of parameters and return values, often an example - all good to see.

You seem to agree with Andrzej. By the way (BTW ;-) ) he likes YOMM2's intro better. Can you take a look and tell me what you think? https://github.com/jll63/yomm2

Yes it is better - especially the detailed list of differences from the stated paper. However, it still lacks relatable use-cases (even as simple as the four I listed in this mail would be great to see - or another list if you have better scenarios) - and it refers to essential information via a link to a paper. If this link breaks (say the site admins "forget" to pay their annual hosting fee!) then essential information is lost. Better to paraphrase the paper into a paragraph or two (or bulleted list) to capture the essential concepts - and provide the link for more detailed info. - Peter On Thu, May 1, 2025 at 6:51 PM Jean-Louis Leroy via Boost < boost@lists.boost.org> wrote:

Hi Peter,

Thanks for your review!

I'll think about your remarks on the introduction, and probably blend some of it in.

...

To be clear - does the library implement ALL the features of the N2216 paper - if not all, then list those implemented.

I'll add a dedicated top-level entry for this. Probably it should not be too close to the top, because it will speak to more hardcore users, not to people who are just discovering open-methods and who have no awareness of N2216.

...

It is totally OK to provide references, though expect some reference links to break as time passes. *Required information should be in the library doc*.

Ok.

...

A kinda nit - this is funny "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - but - is it really true?

Yes it is :-D

Take the Matrix example, where you want to add serialization to the matrix hierarchy. If you plant a `virtual void to_json(std::ostream&)` in the base class, and implement it in the subclasses, any consumer of your matrix library will drag in the iostream library. Matrix is the banana you wanted. The iostream library is the gorilla. You'll pull iostream's dependencies in as well. Jumping from hierarchy to hierarchy in that fashion, you'll pull much of the entire jungle.

People did a lot of this when OOP became mainstream. Later patterns, principles, etc were designed to mitigate the problem. Visitors, dependency injection, interfaces, etc. Open-methods are a solution, but less clumsy I believe.

GETTING STARTED

...

Following the introduction, there should be a *Getting Started* section which goes over 1) Requirements 2) Steps to install 3) Dependencies (Boost libs, std libs, other libs, etc.) 4) hello world tutorial.

...

Getting up and running should come before Tutorials.

OK, those should not be relegated to the reference.

PERFORMANCE

...

Perhaps add a table of performance of some sort that readers can relate to - say, comparing an open method to a class method with both doing the same thing.

https://jll63.github.io/Boost.OpenMethod/#tutorials_performance does that, but in terms of instructions, not timings. Working on this project has destroyed my faith in micro-benchmarks.

...

However, they are not really tutorials unless they contain steps for the reader to follow. Step 1 - copy and paste this example. Step 2 - run it and examine the output, Step 3 - add this feature and run again. Step 4 - notice how the output has changed...etc. etc.

...

It would be most useful if the tutorials related to the use-cases first introduced, showing how the desired results are achieved.

On this subject, what do you think of Andrzej's distaste of the Animals example? And my motivation for it? I don't want to put my words in Andrzej's mouth, you'll find that dialogue easily.

I do see his point.

...

TERMS and ACRONYMS

Acronyms are introduced that I am unaware of, without an initial explanation. For example,

Unlike function declarations, which can occur multiple times in a TU, an overrider declaration cannot.

What is a TU? Can this be defined in full on first use? Similar for ADL, AST, CRTP etc. And for terms such as "guide function" - add a definition on first use.

I *think* I kept the acronyms to the "advanced" parts of the doc. I think that any moderately advanced C++ programmer knows what ADL is...but I will make sure that in any given section the first mention of an acronum is: Argument Dependant Lookup (ADL).

...

I would really like to see the Reference further divided into sections based on type: * Classes ** fields ** methods * Interfaces * Structures * Constants * Macros * Functions (if external to any class)

So, I struggled with this. I opted for a "thematic" grouping - putting strongly related constructs close to one another in the sidebar. But that grouping jumps across categories. Some facets are templates, some are classes. Should they be scattered between templates and classes? This approach seems to work well only for the macros.

...

- Currently we have to examine each entry, or guess (I don't like guessing) what each entry is.

Yeah I experimented with other schemes, trying to get guidance from other adoc based documentations. There are many variations.

I tried prefixing every entity with its category - e.g. "class template method", "class template method::override", but this causes a lot of wrapping in the left sidebar.

I am considering removing the "Reference" level to gain one level. Instead of:

Reference BOOST_OPENMETHOD Synopsis Description BOOST_OPENMETHOD_OVERRIDE Synopsis Description

...go straight to :

BOOST_OPENMETHOD Synopsis Description BOOST_OPENMETHOD_OVERRIDE Synopsis Description

What do you think?

I like adoc but it can be limiting...

...

If references are arranged alphabetically within each section (Classes, Macros etc.) - they are easy to locate.

In YOMM2 I have a flat alphabetically ordered index (https://jll63.github.io/yomm2/#index). Maybe thematic grouping is a bad idea. After all it's a reference, not a novel.

...

ERRORS and EXCEPTIONS

It is not clear to me what errors or exceptions might be thrown by any of the entries. All errors/exceptions thrown by the library code should be listed under the entry that might fire them. For maximum usefulness, include a table of errors and exceptions and* what you should do about it if you get such an error* could be described too - say likely causes and likely resolutions.

It is hard to document accurately because of the customization points.

...

A complete structured Reference, with descriptions, return values, use cases and errors would be great to see.

Do you mean this style (from Variant2)?

Effects: Initializes the variant to hold the same alternative and value as w.

Throws: Any exception thrown by the move-initialization of the contained value.

Remarks: This function does not participate in overload resolution unless std::is_move_constructible_v<Ti> is true for all i.

I tried it. But it is difficult to squeeze the library's flexibility into this mold. In case of error, it aborts. But before that it calls error handling facet. Which can throw, or not - it's a customization point. I guess I could have a Errors instead of a Throws:

Errors: Call the error handler specified in the policy's error_handler facet, then call abort.

More importantly, I felt that this style is robotic.

What are your favorite Boost documentations?

...

ACKNOWLEDGEMENTS, REFERENCES

The documentation could end with any acknowledgements (designers, testers, motivators) and References such as N2216 and no doubt others.

Yes.

...

The documentation as it stands describes what the code does but almost entirely from an inward looking perspective and almost never addresses the "when I should use this" from a use-case - or more likely a component of a use-case - perspective.

...

1. an introduction explaining the "why I should be interested" with some compelling use-cases. The more relatable the use-cases, the more interest and users you will get.

You seem to agree with Andrzej. By the way (BTW ;-) ) he likes YOMM2's intro better. Can you take a look and tell me what you think? https://github.com/jll63/yomm2

...

2. Are there other Boost libraries that play well with OpenMethods - even if you have limited experience of this a start would be helpful.

Yes.

* Using a flat_unordered_map in place of a std one. That brings dispatch speed closer to my perfect hash solution.

* Interoperability with intrusive smart pointers.

...

I hope my 2c is useful.

You are a technical writer, I am a just code writer trying to do a technical writer's job. That's worth a lot more than 2c ;)

J-L

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

вт, 29 апр. 2025 г. в 19:36, Joaquin M López Muñoz via Boost <boost@lists.boost.org>:

This is my review of the Boost.OpenMethod proposal. Thanks to Jean-Louis for his work and to Dmitry for managing!

Thank you Joaquin for your review.

AMDG On 4/30/25 4:15 PM, Jean-Louis Leroy via Boost wrote:

Hi Joaquín,

* Instead of BOOST_OPENMETHOD(poke, (std::ostream&,virtual_ptr<Animal>), void), consider the possibility of using BOOST_OPENMETHOD(poke, void(std::ostream&, virtual_ptr<Animal>)).

I tried since you last suggested this. Couldn't make it work. The macro generates something like:

auto poke(std::ostream& a, virtual_ptr<Animal> b) -> void { method<poke_method(std::ostream& a, virtual_ptr<Animal> b)>::fn(a, b); }

There is no way to peel off the `void` from the signature with the syntax you suggest.

It doesn't need to be peeled off by the macro. You're only using it as a template parameter, so you can just pass the whole signature as a function type. In Christ, Steven Watanabe

AMDG On 5/6/25 4:52 PM, Jean-Louis Leroy via Boost wrote:

Hi Steven,

...

...

I tried since you last suggested this. Couldn't make it work. The macro generates something like:

auto poke(std::ostream& a, virtual_ptr<Animal> b) -> void { method<poke_method(std::ostream& a, virtual_ptr<Animal> b)>::fn(a, b); }

There is no way to peel off the `void` from the signature with the syntax you suggest.

It doesn't need to be peeled off by the macro. You're only using it as a template parameter, so you can just pass the whole signature as a function type.

What about the `void` after the arrow?

You mean like this? BOOST_OPENMETHOD(poke, (std::ostream& a, virtual_ptr<Animal> b) -> void) That's possible. You can get a function type by prepending auto, which can be used for most template parameters and (with some metaprogramming) the return type.

It might work if we could define a function using a function type:

using Signature = void(std::ostream& a, virtual_ptr<Animal> b);

Signature poke { method<poke_method(std::ostream& a, virtual_ptr<Animal> b)>::fn(a, b); }

Alas this is illegal. Not sure why. Probably because of the parameter names...

Right. The function type trick works for everything except the actual function definition (where you need the parameter names).

For what it's worth, here is the syntax that I would like:

BOOST_OPENMETHOD(void poke(std::ostream&,virtual_ptr<Animal>)) { ... }

Would be nice. Too bad it that leaves no way to get poke as a usable identifier. In Christ, Steven Watanabe

Hi Christian, Thanks for the review!

First and foremost, I'd say this library can be dramatically pared down in its interface. What I mean by this, I'm left wondering if we could replace a lot of the customization points with just a set of common choices for RTTI and error handling.

For many years policies in YOMM2 existed in hiding, just for the benefit of unit tests. But it changed due to user feedback.

Why do I need custom RTTI? Why would I want custom RTTI? What's the library not doing for me that I should be considering doing myself?

I very much agreed with you, until someone on reddit convinced me in a snap. He was a game developer, told me that my library was my library was unusable in his field. Why? Because we disable standard RTTI. But why on Earth do that? Because some people look at the strings embedded in the binaries and use the info to reverse-engineer the game, cheat, or whatnot. Games are an important segment of the industry, also I have been eyeing embedded programming.

For example:

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.

Yeah, that's a mouthful. Since reading your reply, I've had ideas for improvements. I'll experiment with them during the week-end, and come back to this.

And because this policy is used in the indirect_vptr example, showcasing how to handle dynamic loading, I was left wondering, shouldn't the library just be exposing this stuff already for me? Why is there an example teaching me how to build it? dyn_vptr seems important enough that I shouldn't have to build it.

Yes, I think I can provide shortcuts for that.

As far as error handling goes,

...

"When an error is encountered, the program is terminated by a call to abort"

This absolutely should be changed, even if it did make me chuckle at first. It's because "abort" is a scary word and I think most readers would drop the library instantly if they read that "when an error occurs, we abort your program".

I realize now that this library means: "we internally use asserts".

No, it *literally* calls abort. I was guided by what happens when you call a pure virtual function. The program aborts, *maybe* with a short diagnostic.

But I still think this is a bad default because the example code in the Error Handling section immediately shows you how to author the thing you actually want: exceptions. This is where the complexity of the library ramps up a lot as now you're introduced to facets and policies.

I think there's maybe a more sane path to error handling here which is to use exceptions by default and then maybe something like an assert version which works in debug or release and then finally a "we just do UB".

To clear any misunderstanding, I think that exceptions are great, far superior to any alternative I know of, except in very specific and rare contexts. So why this choice? A big chunk of the community is allergic to exceptions. Promoting a form of polymorphism that relies on inheritance and tables of function pointers is an uphill battle already. Adding exceptions to the backpack makes it worse. Also, when you call a pure virtual function, it doesn't throw. UB, why not? Sadly it may be better than throwing. But you got me thinking about a "more sane path"... N2216 and the papers that precede it sort of sidestep the question...They require every open-method to have a definition. The motivation is, what should happen if no overrider is applicable. Should we throw an exception? But that is unacceptable in the context of embedded programming. So they require every base-method to have an implementation, problem solved. Then they add "solutions" for dealing with ambiguities. In the first paper, it's using covariant return types as tie-breakers. Eventually, in N2216, they pick "an" overrider after every attempt at finding an only best one have failed. In the end, the open-function mechanism *itself* doesn't need to throw or abort, because it has eliminated every reason to do so. You have to look hard, though, to find an *example* of a base-method implementation. In N2216: bool intersect(virtual Shape&, virtual Shape&) { } This doesn't look good, it silently returns something in a situation that is likely a bug. In Solodkyy's paper "Simplifying the Analysis of c++ Programs": int eval (virtual const Expr&) { throw std::invalid argument ("eval"); } This is better. I think that it is what most base-method implementations will look like. A counter-example is my "animals meet" example: they ignore each other. But it's a made-up example. So why not synthesize an erroring base-method overrider if none has been provided? I can enforce the paper's requirement of a base-method overrider at runtime (in initialize), maybe even at link time (but it would break some regularities elsewhere). It would be a way of copping out of the issue altogether. It would probably make noexcept open-methods feasible without complexifying the policy even more.

The use of trailing return seems to really mess up the asciidoc code examples, especially because it's for stuff like `auto main() -> int` which is tough to defend in and of itself, even as someone who's a huge trailing return fan.

Since the macros follow that order, I changed all the code to follow it as well, hoping to achieve some sort of subliminal teaching ;-)

I had a lot of trouble trying to actually construct a virtual_ptr myself and the reference docs were not helpful because they don't have any examples.

It's a very static-polymorphic thing. The interaction between objects, virtual_ptrs to objects, and virtual smart ptr to objects. I have to improve that part. And yes, provide short examples.

Do we need BOOST_OPENMETHOD_OVERRIDER? It seems like in the code examples, just calling `next()` is sufficient. This code is already so entrenched in macros and I'm not sure another one helps its case.

I think that `next` is the likely correct way in most cases. But you are not forced to use BOOST_OPENMETHOD_OVERRIDER, it's just there in case you feel you need it.

I'm not sure about BOOST_OPENMETHOD_GUIDE either. It seemed like it was needed so we can add overriding functions to types in a different namespace without opening it. I think this is actually something we don't want to encourage for reasons mentioned by Andrzej about this being a potential footgun. I think forcing users to have to open up the namespace is a good thing and kind of mimics the orphan rule in Rust, which is: you own either the trait or the type.

So this is a late addition after a comment from Joaquin. I leaned towards "agree" because this is legal: namespace foo {} void foo::bar() {} But yeah I can easily flip the other way.

Otherwise, I think the library is very enjoyable.

This warms my heart :)

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.

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@gmail.com> 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@lists.boost.org> 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

I replied privately instead of posting to the list. Sorry, very much under the weather ATM. Re-posting to the list, with one extra remark.

Another question concerning the memory footprint.

Suppose we have a class hierarchy of size N so that: struct A1 {...} struct A2 : A1 {...} ... struct AN : AN-1 {...}

Now we define an open method with M virtual arguments BOOST_OPENMETHOD(big, (virtual_ptr<A1>, virtual_ptr<A1>, virtual_ptr<A1>, ..., virtual_ptr<A1>), void);

What set of overriders would be the worst case in terms of memory footprint ? I suppose it would be the complete set of overriders that covers all the tuples possibilty, for which size is N^M. Then would the size of the dispatch table be O(N^M) ?

What set of overriders would be the worst case in terms of memory footprint ? I suppose it would be the complete set of overriders that covers all the tuples possibilty, for which size is N^M.

If each virtual tuple gets its own overrider? In that case, indeed, the dispatch table will be N^M. And that wouldn't even be bad. It would just be what it takes. Any solution in the tune of switches or M-dispatch (and good luck figuring it out, you'd have to generate it) would cost more in terms of code space than it saves in terms of data space. Unless you start playing tricks like putting the shortest possible integers in the dispatch table, indexing a vector of function pointers. Otherwise, it depends. In the extreme case where there is only one overrider for the fallback case (all virtual_ptr<A1>s), the table will have just one cell. The worst, I think, would be overriders on the diagonal only. Maximum waste. On Tue, May 6, 2025 at 1:06 AM Yannick Le Goc <ylegoc@gmail.com> wrote:

Another question concerning the memory footprint.

Suppose we have a class hierarchy of size N so that: struct A1 {...} struct A2 : A1 {...} ... struct AN : AN-1 {...}

Now we define an open method with M virtual arguments BOOST_OPENMETHOD(big, (virtual_ptr<A1>, virtual_ptr<A1>, virtual_ptr<A1>, ..., virtual_ptr<A1>), void);

What set of overriders would be the worst case in terms of memory footprint ? I suppose it would be the complete set of overriders that covers all the tuples possibilty, for which size is N^M. Then would the size of the dispatch table be O(N^M) ?

On Mon, May 5, 2025 at 3:11 AM Jean-Louis Leroy via Boost <boost@lists.boost.org> wrote:

...

...

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@gmail.com> 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@lists.boost.org> 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

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Fri, 2 May 2025 at 20:24, Jean-Louis Leroy via Boost < boost@lists.boost.org> wrote:

...

I am working through the documents and found myself a little troubled that there is a need to initialise the subsystem in main():

I know...I don't like it either...the Dlang version auto-initializes.

...

It occurs to me that this can be solved using the Schwartz Counter (or Nifty Counter) method, which because of inline variables, works fully using only header files as of C++17.

I don't think so. The problem is that initialize() must be called after all the static registrar objects have executed, and before the first method call.

Why? Does dispatch lookup not work with partially populated dispatch maps?

With msvc, I could use init_seg. But I see no general solution. But I would be delighted to be proven wrong.

...

Thanks for your time.

Thank you for your feedback!

J-L

On Fri, May 2, 2025 at 7:24 AM Richard Hodges via Boost <boost@lists.boost.org> wrote:

...

On Sun, 27 Apr 2025 at 15:15, Дмитрий Архипов via Boost < boost@lists.boost.org> wrote:

...

Dear Boost community. The peer review of the proposed Boost.OpenMethod

...

...

start on 28th of April and continue until May 7th. OpenMethods implements open methods in C++. Those are "virtual functions" defined outside of classes.

Thank you, this is a welcome development.

I am working through the documents and found myself a little troubled

will that

...

there is a need to initialise the subsystem in main():

#include <boost/openmethod/compiler.hpp> // only needed in the file that calls boost::openmethod::initialize() auto main() -> int { boost::openmethod ::initialize(); // ... }

This prevents this library being used as a dependent subsystem within other libraries, as the publisher of the library would need to communicate the need for this manual initialisation down the chain of dependent projects. This is brittle.

It occurs to me that this can be solved using the Schwartz Counter (or Nifty Counter) method, which because of inline variables, works fully using only header files as of C++17.

In case this is new information, the Schwartz Counter is the mechanism by which std::cout and std::cin are made available by the standard library.

Thanks for your time.

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Sat, 3 May 2025 at 22:22, Jean-Louis Leroy via Boost <boost@lists.boost.org> wrote:

...

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]

...

3. Some of the complexity with policies (like needing a fork function) seem to be stemming from the point above. What do you think? For instance, couldn't facets be made regular members? Then add/fork can be implementing by just inheriting from a base policy, using regular C++.

Do you mean static or instance members? If it is the latter, then policies would become objects. Which we can pass as template parameters, but it would run into difficulties, because we don't have universal template parameters yet. A simple example: use_classes. It uses std::is_base_of to detect if the last class is a policy. So a policy has got to be a type (unless we change the contracts a lot).

If you mean static members, we are back to the problem of separating my_policy's error stream from your_policy's.

I see, I meant static members. I was thinking of somehow splitting the state part on another object - but it might complicate things further.

...

4. I had the same impression as Joaquin that virtual_ should be used to mark virtual arguments in method definitions, and virtual_ptr and regular references in overriders. What do you think?

So, to make sure that we are on the same page, you mean:

BOOST_OPENMETHOD(poke, (std::ostream &, virtual_<Animal>), void);

BOOST_OPENMETHOD_OVERRIDE( poke, (std::ostream & os, virtual_ptr<Cat> cat), void) { ... }

Yes, this is what I mean.

The problem with this: BOOST_OPENMETHOD would need to foresee what the overrides will look like. It could be:

BOOST_OPENMETHOD_OVERRIDE( poke, (std::ostream & os, Cat& cat), void) { ... }

...when using with_vptr. Or if the user doesn't need the best performance, maybe the body of the overriders does enough work to make the cost of the extra instructions irrelevant.

Yes, either of these would be valid: BOOST_OPENMETHOD_OVERRIDE(poke, (std::ostream & os, Cat& cat), void) { ... } BOOST_OPENMETHOD_OVERRIDE(poke, (std::ostream & os, virtual_ptr<Cat> cat), void) { ... } And I guess you'd need some if constexpr's to create the virtual_ptr or not, and some logic to handle the case where the user declared both of them, which should be illegal.

A secondary benefit: with virtual_ptr in both declarations and overriders, it is easier to explain the (basic) rules. If you look at YOMM2's doc or my talks, I often talk about "peeling off" the "virtual_ decorators". With virtual_ptr at all levels, it is more straightforward to explain.

In regular C++ OOP, we already say "virtual" in base classes and "override" in implementations, so I'm not sure about this.

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? Cheers, Ruben.

...

2. It sounds strange to me that policies have two functions: a. they behave behavior (e.g. what to do in case of error) and b. they act as a type registry. That confused me a lot, because in other libraries I got the impression that policies only do a. Is there anything preventing the separation of concerns here?

In general, policies can have (static) state. For example, vectored_error_handler contains a static std::function. Each policy that uses it needs its own. That's the reason for all the CRTPing, and why `fork` rebinds the first template argument of all the templatized facets to the new policy.

All the methods in the same policy count, at dispatch time, on data created by initialize<Policy>(). That is why methods have to be scoped in the policy. The same holds for class registrars: the type_ids they store at static construction time are not necessarily the same thing in different policies.

...

3. Some of the complexity with policies (like needing a fork function) seem to be stemming from the point above. What do you think? For instance, couldn't facets be made regular members? Then add/fork can be implementing by just inheriting from a base policy, using regular C++.

Do you mean static or instance members? If it is the latter, then policies would become objects. Which we can pass as template parameters, but it would run into difficulties, because we don't have universal template parameters yet. A simple example: use_classes. It uses std::is_base_of to detect if the last class is a policy. So a policy has got to be a type (unless we change the contracts a lot).

If you mean static members, we are back to the problem of separating my_policy's error stream from your_policy's.

As I think I didn't explain myself enough in my previous message, I'd like to expand on what I meant by this. Take the current vptr_vector facet, for example (simplified): template<class Policy, typename Facet = void> class vptr_vector { static std::vector<element_type> vptrs; public: template<typename ForwardIterator> static auto register_vptrs(ForwardIterator first, ForwardIterator last); }; And the current basic_policy implementation (also simplified): // domain<Policy> contains static members template<class Policy, class... Facets> struct basic_policy : abstract_policy, domain<Policy>, Facets... { using facets = mp11::mp_list<Facets...>; }; Could it be possible to write: // Members are no longer static template<class Policy, typename Facet = void> class vptr_vector { std::vector<element_type> vptrs; public: template<typename ForwardIterator> auto register_vptrs(ForwardIterator first, ForwardIterator last); }; // domain now contains regular members (no longer static) template<class Policy, class... Facets> struct basic_policy : abstract_policy, domain, Facets... { std::tuple<Facets...> facets; }; // A method_container is linked to a policy, and is what you use to register methods struct debug_method_container { static debug_policy policy; // Instead of many static members, just this one }; // Register classes and methods BOOST_OPENMETHOD_CLASSES(base_node, node1, node2, debug_method_container) If this is possible, you could simplify how you store facets, making them regular members so you don't need add, replace and fork: // Marker class to say "this facet it not implemented" struct facet_not_implemented {}; struct abstract_policy { facet_not_implemented rtti; facet_not_implemented extern_vptr; facet_not_implemented type_hash; facet_not_implemented error_handler; facet_not_implemented runtime_checks; facet_not_implemented error_output; facet_not_implemented trace_output; }; struct release_policy : abstract_policy { facet_not_implemented rtti; fast_perfect_hash type_hash; vptr_vector<fast_perfect_hash> extern_vptr; vectored_error_handler<facet_not_implemented> error_handler; }; struct debug_policy : release_policy { runtime_checks runtime_checks; basic_error_output<> error_output; basic_trace_output<> trace_output; vectored_error_handler<basic_error_output<>> error_handler; }; This avoids CRTP and all the facets machinery. It also makes dependencies between facets explicit, which I think it's good. Currently, replacing type_hash seems to influence how vptr_vector behaves, but I could only arrive at this conclusion by inspecting the source code. What are your thoughts on this proposal?

I'd recommend to just blanket copy-paste the Unordered approach and then edit it into something workable.

Antora has beautiful documentation output and is dramatically easier to navigate.

Yes, I like Unordered's doc too. Alas when I was looking for docs to imitate, it was still single-page.

AMDG On 5/6/25 10:17 PM, Jean-Louis Leroy via Boost wrote:

...

7. boost::openmethod::type_id is a type alias for std::uintptr_t. I would try to avoid such an alias, since it doesn't add much and makes code more difficult to read. It might be misleading given the existence of the typeid operator.

Hmmm yeah maybe. std::uintptr_t is a bit hard to type...

I think it's fine to have a type alias. type_id is easily confused as being related to typeid/std::type_info/std::type_index, but std::uintptr_t isn't any better, as it's just another integer type and doesn't indicate what it's for.

...

I don't know if having a virtual destructor is common in custom RTTI scenarios, but I'm inclined to think that it's not, as AFAIK a virtual destructor adds standard RTTI information to a type.

I'm pretty sure it doesn't.

According to the standard, it does (any virtual function adds RTTI), but those using custom RTTI typically use a non-conforming implementation by disabling standard RTTI. In Christ, Steven Watanabe

чт, 8 мая 2025 г. в 07:14, Jean-Louis Leroy via Boost <boost@lists.boost.org>:

Hi Steven,

...

Here's an incomplete review. There definitely isn't enough time left for me to finish it today.

If Dmitry agrees, we can extend it a bit. I need more time to "process" Andrzej's review; and I don't want to miss the rest of your feedback.

If the review wizards aren't against it, I have no problem with extending the review period for one day.

чт, 8 мая 2025 г. в 19:07, Matt Borland <matt@mattborland.com>:

I see no issue with an extra day since the next period does not begin until 13 May.

The review period for OpenMethod library has ended. I want to thank everyone who participated in the review process, particularly those who have sent their reviews. I will post the results in a week or two.

Hi Steven, Thank you for the review.

virtual_ptr should not be put in the global namespace.

OK OK I surrender ;-)

"That is because the overrider containers exist in both the canides and felides" The code has "canines" and "felines"

Six years of Latin in high school...

BOOST_OPENMETHOD_OVERRIDER: I think it would be better to make this macro expand to something callable, i.e., add ::fn. That way the name fn can be an implementation detail.

For consistency with BOOST_OPENMETHOD_OVERRIDERS. `fn` is used in other places. OpenMethod makes more internals public for interoperation between the macro and core interfaces. I still have to try your (and Joaquin's) suggestion of replacing the comma before the return type with an arrow in macros like BOOST_OPENMETHOD. If it works (very likely), BOOST_OPENMETHOD_OVERRIDER loses its raison d'être and I will probably remove it.

Why does BOOST_OPENMETHOD_OVERRIDER need the return type?

N2216 lookup. Considering return types as tie-breakers to resolve some ambiguities. Which I am demoting to an opt-in.

BOOST_OPENMETHOD_OVERRIDERS: The documentation of friendship claims that this can be used to grant friendship to all overriders. Is this really all overriders, or is it only overriders in the same namespace?

In the same namespace. Doc fix.

"Be aware, though, that the overriders of any method called poke - with any signature" Does this imply that we can define multiple open methods with the same name, but different argument types?

Yes. See https://github.com/jll63/Boost.OpenMethod/blob/master/examples/matrix.cpp

Switching the default policy based on NDEBUG is dangerous. It's not uncommon to link code build with NDEBUG to code built without it.

Hmmm yes I see that. I am completely separating the release and debug policies in the new design of the policy system. default_policy is a typedef, and, if I understand properly, having a typedef aliasing to different types is not an ODR violation in itself, but it makes it easier to create one. Do you have a better suggestion?

I don't understand the name vectored_error_handler. How is it vectored?

I guess it's boomer-speak... We used to call indirect function calls "vectored". Do you have a better name?

I'm confused about how error handling works. The docs say "When an error is encountered, the program is terminated by a call to abort. If the policy contains an error_handler facet, it provides an error member function (or overloaded functions) to be called with an object identifying the error." I'm guessing this means that abort is called if there is no error handler or if the error handler returns normally.

Yes indeed. I have problems phrasing that, perhaps related to English not being my first language.

I think the facet interface could be simplified.

Following the discussion with Ruben, I came up with a much simpler, safer design. CRTP and `fork` are gone.

In many places the if constexpr(has_facet<>) logic could be simplified by using a no-op implementation of the facets instead of letting facets be missing.

Yeah I actually do that in a couple of places. Like finalize() inherited from a base class by all policies. I sort of felt uneasy with resorting to shadowing.

detail/static_list.hpp: - Most of the iterator functions can be constexpr

For what benefit? It is an implementation detail specifically designed to be used by static ctors...

detail/trace.hpp: - It's a bit weird to have the indent of 4 split into 2*2. It would make more sense for indentation_level to indicate either the exact number of spaces or the depth.

Oh right...but you didn't see it, it's in `namespace detail` ;-)

policies/basic_policy.hpp: - fork_facet is quite dangerous. It assumes that if a facet is a template, the first template parameter is the policy. This is potentially surprising and I don't see where it's documented.

It's better than documented now, it's GONE.

policies/basic_error_output.hpp: - Why use virtual inheritance?

No good reason. Not in the new design.

policies/vptr_vector.hpp: 32: Does using namespace policies do anything?

It imports the names in the current scope? ;-) I do that in the body of some functions.

compiler.hpp: - class_::is_base_of: Why use std::find on an unordered_set?

I think those sets used to be vectors. Maybe they should be again.

266: in compiler::static_type [...] ...seems to be unused.

Yes, I will remove it.

343: if (*method.vp_end == 0) { Since this is inside the loop, won't it only resolve the first type? Actually, I'm really confused about the whole loop. Do we want to process the overriders for each virtual parameter?

That code has nothing to do with resolving overriders. It is for deferred RTTI. For interfacing with custom RTTI schemes that also use static ctors. If the deferred_static_rtti is present, I store a pointer to a function that returns a type_id, instead of the type_id itself. initialize() calls the function and then replaces the function pointer with the type_id. Since initialize() can be called multiple times, I add a flag just after method.vp_end. J-L

Methods: type_id(0) (type_id(23), type_id(4227983)) unkown class 4227983(type_id(4227983)) for parameter #1 unknown class type_id(4227983) Aborted (core dumped)

Oh, right! Thanks. Will fix and add unit tests. J-L

AMDG Sorry for the late feedback. I finally had enough time to get through most of the implementation. boost_openmethod_vptr returns a result that is policy dependent. Should it be possible to overload it based on the policy? At the very least, it should be possible to verify that the policy matches. Custom RTTI: - "is_polymorphic is used to check if a class is polymorphic. This template is required." What does it mean for a type to be polymorphic? It clearly doesn't strictly mean a C++ polymorphic type, because std::is_polymorphic would always be right, then, but I don't see a definition of what it does mean. - It would be helpful for debugging if method dispatch asserted that the policy was initialized. It took me a while to figure out that I was still initializing the default policy and not my custom policy. I think virtual_ptr is doing too much. What would it take to make it possible to implement virtual_ptr without any special support in the core library? - boost_openmethod_vptr provides a way to get the vtable - The rtti policy and/or static_cast should allow downcasting to the overrider parameter type. - The only thing that is clearly missing is the ability to indicate that virtual_ptr is a virtual parameter. I tried using shared_ptr as a parameter type like this: BOOST_OPENMETHOD_CLASSES(Base, Derived) BOOST_OPENMETHOD(foo, (virtual_<std::shared_ptr<Base>>), void) BOOST_OPENMETHOD_OVERRIDE(foo, (std::shared_ptr<Derived>), void) { std::cout << "derived" << std::endl; } - The guide function doesn't work. I don't understand why, since shared_ptr<Derived> is convertible to shared_ptr<Base>. - I tried adding an rtti facet, but it didn't help. The (lack of) type safety is quite concerning. - I don't think the standard guarantees that a function pointer can round-trip through void*. IIRC, an arbitrary function pointer type like void(*)() is guaranteed to work. - I'm particularly concerned about the way reinterpret_cast leaks into user code in the rtti policy's type_name. throw_error_handler directly throws the error type as an exception, but openmethod_error does not inherit from std::exception. Even though this is perfectly legal, dealing with such exception can be rather painful. I don't think that the default error behavior for unimplemented overrides is good. I'm okay with an abort when initialization fails. An error that happens reliably on program startup is not much worse than a compile error. If an unimplemented method aborts, that implies that it is considered a programming error. In this case I want to check for completeness in initialization and fail if anything is missing. If a missing override isn't a bug, then it needs to be recoverable, or at least allow clean shutdown, which means throwing an exception. Unlike some others, I'm actually okay with choosing some overrider when it's ambiguous. It's not a great solution, but it's still better than aborting. Failing on initialization would also be acceptable. I'm not particularly fond of using the covariant return type to choose. It's unlikely to be less surprising than just picking one at random, since that's not how C++ normally does overload resolution. What about prioritizing the leftmost parameter? That's simple and predictable. I'd like to be able to use std::any or boost::type_erasure::any in open methods. - std::any can use .type() - boost::type_erasure::any can either use std::type_info or it can be configured to store a vptr. Both provide any_cast which can be used to cast the value. I defined a custom rtti facet. It doesn't work, and it appears that the reason is that int does not inherit from any, which causes it to not be considered by assign_tree_slots. So, I used class_declaration_aux directly to forcibly make any a base of int, and then it seems to work. The simplest way to solve this is to allow a policy to customize is_base_of and is_abstact. I've attached files that show the result of my experiments (test_te.cpp and test_any.cpp). compiler.hpp: 405-478: Calculating transitive_bases and direct_bases. I don't think this works. The documentation claims that the only restriction is that every type must include its direct base classes, but the loop at 405 does not compute the transitive closure. This can cause direct_bases to contain indirect bases as well. Consider the following example: struct Base { virtual ~Base() = default; }; struct D1 : Base {}; struct D2 : D1 {}; struct D3 : D2 {}; struct D4 : D3 {}; struct D5 : D4 {}; BOOST_OPENMETHOD_CLASSES(Base, D1, D2, D3) BOOST_OPENMETHOD_CLASSES(D2, D3) BOOST_OPENMETHOD_CLASSES(D3, D4) BOOST_OPENMETHOD_CLASSES(D4, D5, D3) ... Inheritance lattice: D3 bases: (D2) derived: (D4, D5) covariant: (D4, D5, D3) compiler.hpp:554: typo "unkown" compiler.hpp:735: if (!cls.used_by_vp.empty()) { for (const auto& mp : cls.used_by_vp) { The if seems redundant. The algorithm for assign_lattice_slots looks pretty inefficient to me. The worst case is O(slots^2 * classes^2). It can also generate results that are obviously silly (at least to a human) pretty easily. I know optimal slot allocation is NP-hard, but I think it can be tweaked in a few ways. Considering the optimization of not storing leading unused slots, filling the lowest available slot is a suboptimal strategy. We can pack it tighter by finding the ranges from bases (and derived) and filling in holes. Notice that the algorithm's correctness does not depend on visiting the nodes in any particular order. If we're allocating from 0, it's probably most effective to visit types bases first instead of depth first. If we're trying to allocate contiguous ranges, we can move both up and down from types that are already visited. I believe that in the absence of virtual inheritance, this is guaranteed to assign slots contiguously without leaving any holes. After assigning a slot, we only need to propagate a single bit across the hierarchy. We don't need to merge all the bit vectors. Finally, we could pull reserved slots up from transitive derived before allocating slots instead of pushing them up to transitive bases of transitive derived after slot allocation. This would reduce the nesting depth of the loops. compiler.hpp:1147: *cls.static_vptr = gv_iter - cls.first_slot; This is quite scary. It's undefined behavior if it goes before the beginning of the vector. I think I can trigger undefined behavior with the following hierarchy C / A B \ / D (see test_vptr_oob.cpp) ... Initializing v-tables at 7c59751e1240 0 7c59751e1240 vtbl for A slots 2-3 ... Notice that the vtable for A is placed first in the vector, but first_slot is 2. In Christ, Steven Watanabe

AMDG On 5/10/25 6:33 PM, Jean-Louis Leroy via Boost wrote:

<snip> I experimented with passing a Policy* as the first argument to the function after Ruben's remarks. It's not hard to make it work, but it requires boost_openmethod_vptr() to either specify the exact policy it expects, or be a template if it wants to ignore it.

I think specifying the exact policy is going to be the right thing most of the time. Do we ever want a vptr to be able to be used with any policy? virtual_ptr has a Policy template param and checks compatibility.

...

I think virtual_ptr is doing too much. What would it take to make it possible to implement virtual_ptr without any special support in the core library? - boost_openmethod_vptr provides a way to get the vtable - The rtti policy and/or static_cast should allow downcasting to the overrider parameter type. - The only thing that is clearly missing is the ability to indicate that virtual_ptr is a virtual parameter.

In YOMM2, virtual_ptr is an afterthought. While preparing OpenMethod for review, I struggled with explaining clearly and simply that `virtual_` should be used only in the base-method, and *not* in the overriders. YOMM2 beginners often struggled with that.

Can we strip off the virtual_? struct NAME ## _overrider<...> { template<typename T> using virtual_ = T; ... }; Actually, what if we make virtual a keyword handled by the macro: BOOST_OPENMETHOD(foo, (virtual T&), void) It would look something like #define HAS_VIRTUAL_TESTvirtual ~,~ #define HAS_VIRTUAL_I(a, b, r, ...) r #define HAS_VIRTUAL(arg) HAS_VIRTUAL_I(HAS_VIRTUAL_TEST ## arg, 1, 0, ~) #define REMOVE_VIRTUALvirtual #define REMOVE_VIRTUAL(arg) REMOVE_VIRTUAL ## arg This won't quite work as is. It needs some work to adjust the order of macro expansion. There's also the problem that the preprocessor's view of the arguments is not the same as the compiler's. So we can insert a dummy argument into the signature, which can be stripped out by metaprogramming: void(next_parameter_is_virtual, T&)

Then I though, on top of that, virtual_ptr gets us dispatch in three instructions instead of nine (for 1-methods). Shouldn't it be the "golden path"? And virtual_ be demoted to an entry point into advanced stuff?

To get the performance benefit, virtual_ptr has to be integrated into the surrounding code. If we're doing that, then it should act more like a normal pointer, and the conversion from a reference (which makes some sense when it's being used as a method parameter type) is not such a good idea.

...

I tried using shared_ptr as a parameter type like this:

<snip>

I am surprised. I have a unit test for that (cast_args_shared_ptr_by_value). You didn't attach the example, here is what I tried:

Maybe I forgot to make Derived inherit from Base. I remember doing that at least once.

<snip>

By the way, do you have an opinion on allowing smart pointers as virtual parameters?

I think it should be allowed. Can I bring my own smart pointer?

...

<snip> throw_error_handler directly throws the error type as an exception, but openmethod_error does not inherit from std::exception. Even though this is perfectly legal, dealing with such exception can be rather painful.

I am not exception-phobic. Quite the opposite. But doing this would mean that the error classes would be different whether or not exceptions are enable. I tried to avoid ifdefs as much as I could...

That's not necessarily true. The actual type thrown can be an internal type that inherits from both std::exception and the error type.

<snip>

...

The simplest way to solve this is to allow a policy to customize is_base_of and is_abstact.

This is an interesting research path...abstract sub-categorization away from inheritance...I think that Clojure does something like that.

A few times people requested value-based dispatch for YOMM2. Like in CLOS. I have a design for this. But then the latest requester wnats dispatch on *ranges* of values. I wonder if there is a general way of allowing such extensions, that is also practical.

Value-based dispatch can sort of be done now by registering a type for each distinct group of values and adjusting dynamic_type to distinguish them. This won't work well with virtual_ptr or any other type that caches the vptr, though. The main issue with ranges is that they can overlap in various ways. You'd need to look at all the ranges that might be used for a given parameter, and find all the subranges where the ranges intersect with each other. For a parameter type T, and a range specification R, the user would need to provide a function that partitions the set of values of type T into subsets. template<typename T> struct partition { // To determine the best match we need to know // whether an input set is a subset of another input set. // To determine whether an overrider matches we need to // know whether a particular subset is part of an input set. bitmatrix subset_info; // When dispatching we need to quickly find the right subset, // which can then be used to look up the std::function<std::size_t(T)> select_subset; }; partition user_defined_make_partition(std::vector<R> input_sets); If the sets are ranges, we can store the boundaries and do a lower_bound search.

<snip>

...

It can also generate results that are obviously silly (at least to a human) pretty easily.

Do you mean silly and incorrect, or just silly?

Just silly. I worked through what it would generate for several hierarchies and was a little surprised.

...

<snip>

...

I believe that in the absence of virtual inheritance, this is guaranteed to assign slots contiguously without leaving any holes.

I am puzzled by this remark, because YOMM2 and OpenMethod are a bit myopic regarding virtual and repeated inheritance.

I'm puzzled by it too. The problem is cycles in the undirected inheritance graph, and I forgot that virtual inheritance isn't the only way to get a cycle.

At the bottom of it, the library suffers from being able to have only one v-table per object. That is why repeated inheritance is not supported. And that is the reason for the contortions about slot allocation.

...

compiler.hpp:1147: *cls.static_vptr = gv_iter - cls.first_slot; This is quite scary. It's undefined behavior if it goes before the beginning of the vector. <snip>

Oh, right. I doubt any real program will crash on this, but you are right, this is UB, and it can be fixed, so let's fix it. It is probably just a matter of ordering the v-tables from lowest first_slot up, and perhaps from highest size up if first_slot is the same.

I think just ordering by first_slot is sufficient, as every vtable that has a slot before first_slot will come before it and every slot should be used in at least one vtable. What if the slots are reserved by an abstract base that has no concrete derived classes? Does that situation get filtered out somewhere earlier?

I guess that you will frown at the idea of using the same trick to avoid storing entries in the perfect hash table that come before the minimum value in the hash function's image.

Yeah, but it's less obvious how to fix it. In Christ, Steven Watanabe

AMDG On 5/12/25 3:10 PM, Jean-Louis Leroy via Boost wrote:

...

Can we strip off the virtual_?

struct NAME ## _overrider<...> { template<typename T> using virtual_ = T; ... };

You mean allow virtual_ in the overrider's parameters? The macro gets: meet, (virtual_<Dog&> dog, virtual_<Cat&> cat)

...and it changes into: meet(Dog& dog, Cat& cat)

I don't see a way of doing this while carrying the parameter's names.

The above would make virtual_ into an alias that just expands to its argument, but this only works when virtual_ is used unqualified.

...

<snip>

It took me a while to see how this could work, and now it's taking me a while to see why it doesn't want to - see https://godbolt.org/z/16nensohc. Probably related to your "order of expansion" comment?

It is appealing but it has problems too. Any comma in the parameter's types will break it.

Not necessarily. You snipped the trick I proposed to deal with that.

YOMM2 uses Boost.PP loops over macro arguments to build the forwarding function, so whenever there is a comma in the parameter types, you have to use tricks like BOOST_IDENTITY_TYPE. For OpenMethod, I moved as much macro-magic to TMP as I could.

#define HAS_VIRTUAL_TESTvirtual ~,~ #define HAS_VIRTUAL_II(a, b, r, ...) r #define HAS_VIRTUAL_I(...) HAS_VIRTUAL_II(__VA_ARGS__) #define HAS_VIRTUAL(arg) HAS_VIRTUAL_I(HAS_VIRTUAL_TEST ## arg, 1, 0, ~) #define REMOVE_VIRTUALvirtual #define REMOVE_VIRTUAL(arg) REMOVE_VIRTUAL ## arg #define IDENTITY(arg) arg #define MARK_VIRTUAL(arg) boost::openmethod::detail::virtual_next, REMOVE_VIRTUAL ## arg #define REMOVE_IF_VIRTUAL(arg) \ BOOST_PP_IIF(HAS_VIRTUAL(arg), REMOVE_VIRTUAL, IDENTITY)(arg) #define MARK_IF_VIRTUAL(arg) \ BOOST_PP_IIF(HAS_VIRTUAL(arg), MARK_VIRTUAL, IDENTITY)(arg) MARK_IF_VIRTUAL(virtual test) REMOVE_IF_VIRTUAL(virtual test) MARK_IF_VIRTUAL(nonvirtual) REMOVE_IF_VIRTUAL(nonvirtual) With this (virtual B, int, virtual C), void becomes void(boost::openmethod::detail::virtual_next, B, int, boost::openmethod::detail::virtual_next, C) which can be turned into void(virtual_<B>, int, virtual_<C>) by TMP. In the function definition, we simply remove the virtual, and everything else, including the argument name is preserved. The main problem is that it blows up when a comma is followed by something that can't be token pasted: (::global, templ<I, (X + Y)>) In Christ, Steven Watanabe