- Boost - lists.boost.org

Re: [boost] [OpenMethod] review starts on 28th of April
by Ruben Perez 07 May '25

07 May '25

<CC-ing the mailing list, since you just replied me, and answering inline> On Tue, 6 May 2025 at 01:35, Jean-Louis Leroy <jl(a)leroy.nyc> wrote: > > Your example is very similar to > https://jll63.github.io/Boost.OpenMethod/#tutorials_custom_rtti. > > virtual_ptr does not try to use boost_openmethod_vptr in its constructors. That > is an oversight. It is a recent invention. YOMM2 tests for the presence of a > boost_openmethod_vptr instance variable in the object directly. In that context, > the function is very simple and inlinable, but if it is user-defined, there is > no reason to assume that. So I will make virtual_ptr consider it as well. > > Regardless, the easiest way to handle your example is to put the vptr > acquisition in the policy. dynamic_type returns a type_id, not a vptr. The > function for that is dynamic_vptr. It is not part of a facet, eventhough facets > can provide one. The dispatch mechanism is described here: > https://jll63.github.io/Boost.OpenMethod/#ref_description_17 > > WARNING: if you try that code with the "review" branch, make sure to pull the > latest changes, because they fix a bug I introduced while re-establishing checks > for non-polymorphic classes. > > Thus: > > > // ------------------------ > // you > > #include <cstdint> > > 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) { > } > }; > > // ------------------------ > // me > > // Get kind from static type, as you RTTI system does not provide it as a > // static member. > > template<typename T> > struct kind_of { > static constexpr kind value = kind::unknown; > }; > > template<> > struct kind_of<node1> { > static constexpr kind value = kind::n1; > }; > > template<> > struct kind_of<node2> { > static constexpr kind value = kind::n2; > }; > > #include <boost/openmethod/policies/basic_policy.hpp> > > struct custom_rtti : boost::openmethod::policies::rtti { > template<class Node> > static constexpr bool is_polymorphic = > std::is_base_of_v<base_node, Node>; > > using type_id = boost::openmethod::type_id; > > template<typename T> > static auto static_type() { > return type_id(kind_of<T>::value); > } > > template<typename T> > static auto dynamic_type(const T& obj) { > if constexpr (is_polymorphic<T>) { > return type_id(obj.getKind()); > } else { > return kind::unknown; > } > } > }; > > struct custom_policy > : boost::openmethod::policies::basic_policy<custom_policy, > custom_rtti> { > > static auto dynamic_vptr(const base_node& b) { > switch (b.getKind()) { > case kind::n1: > return custom_policy::static_vptr<node1>; > case kind::n2: > return custom_policy::static_vptr<node2>; > default: > return custom_policy::static_vptr<base_node>; > } > } > }; > > #define BOOST_OPENMETHOD_DEFAULT_POLICY custom_policy > > #include <iostream> > > #include <boost/openmethod.hpp> > #include <boost/openmethod/compiler.hpp> > > BOOST_OPENMETHOD(process, (std::ostream&, virtual_ptr<base_node>), void); > > BOOST_OPENMETHOD_OVERRIDE( > process, (std::ostream & os, virtual_ptr<node1> node1), void) { > os << "process node1\n"; > } > > BOOST_OPENMETHOD_OVERRIDE( > process, (std::ostream & os, virtual_ptr<node2> node2), void) { > os << "process node2\n"; > } > > BOOST_OPENMETHOD_CLASSES(base_node, node1, node2); > > auto main() -> int { > boost::openmethod::initialize(); > > auto a = std::make_unique<node1>(); > auto b = std::make_unique<node2>(); > > process(std::cout, *a); > process(std::cout, *b); > > return 0; > } > > We could also take advantage of the fact that type_ids fall in a short, compact > range. We can use the vptr_vector facet, but there is no need to hash the > type_ids, we can use them as straight indexes. So we don't use a type_hash > facet: > > struct custom_policy > : boost::openmethod::policies::basic_policy< > custom_policy, custom_rtti, > boost::openmethod::policies::vptr_vector<custom_policy>> {}; > > This time dynamic_vptr() is provided by a facet. Everything else stays the same. For the reference, this is what I ended up doing: 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: static constexpr kind node_kind = kind::n1; node1() noexcept : base_node(node_kind) { } }; class node2 : public base_node { public: static constexpr kind node_kind = kind::n2; node2() noexcept : base_node(node_kind) { } }; constexpr const char* kind_to_string(kind k) { switch (k) { case kind::n1: return "node1"; case kind::n2: return "node2"; default: return "<unknown node type>"; } } struct custom_rtti : boost::openmethod::policies::rtti { template<class T> static constexpr bool is_polymorphic = std::is_base_of_v<base_node, T>; template<typename T> static auto static_type() -> std::uintptr_t { if constexpr ( std::is_base_of_v<base_node, T> && !std::is_same_v<base_node, T>) { return static_cast<std::uintptr_t>(T::node_kind); } else { return static_cast<std::uintptr_t>(kind::unknown); } } template<typename T> static auto dynamic_type(const T& obj) -> std::uintptr_t { if constexpr (is_polymorphic<T>) { return static_cast<std::uintptr_t>(obj.getKind()); } else { return static_cast<std::uintptr_t>(kind::unknown); } } template<class Stream> static void type_name(std::uintptr_t type, Stream& stream) { stream << kind_to_string(static_cast<kind>(type)); } }; struct custom_policy : boost::openmethod::policies::basic_policy< custom_policy, custom_rtti, boost::openmethod::policies::runtime_checks, boost::openmethod::policies::basic_error_output<custom_policy>, boost::openmethod::policies::vptr_vector<custom_policy>> {}; BOOST_OPENMETHOD_CLASSES(base_node, node1, node2, custom_policy) BOOST_OPENMETHOD(print, (virtual_<base_node>), void, custom_policy); BOOST_OPENMETHOD_OVERRIDE(print, (base_node&), void) { /* whatever */ } I've just realized that I've disabled hashing by accident, and this happened to work by accident. I think that this implicit dependency between the vptr_vector and the hashing policy is a problem - I prefer explicit dependencies. > > As you see in this example, we don't have to fork policies, we can just > construct them from scratch. Forking was introduced with the idea of tuning > default_policy, without having to replicate it from scratch. Also the > with/without setters are less verbose than the add/replace/remove ones. > > Elsewhere I said that facets categories are a closed set. That is not correct. > The dispatcher and the compiler look only at a closed set of facets > (using if constexpr (Policy::has_facet>)). But some facets, like vptr_vector and > error_handler, look for other facets in the policy, which are not necessarily > referenced directly by the compiler or the dispatcher. In that sense, the set of > facets is actually open. > > I am going to think about your suggested alternative to the facet system. > Seriously, thus it will take me a few days. In the meantime, how would you see > the two example policies above, expressed with your system? This is what it'd look like with my proposal: struct custom_rtti : openmethod::policies::rtti { template<class T> static constexpr bool is_polymorphic = std::is_base_of_v<base_node, T>; template<typename T> auto static_type() const -> std::uintptr_t { /* same definition */ } template<typename T> auto dynamic_type(const T& obj) const -> std::uintptr_t { /* same definition */ } template<class Stream> void type_name(std::uintptr_t type, Stream& stream) const { /* same definition */ } }; struct custom_policy : boost::openmethod::policies::abstract_policy { // enable runtime checks openmethod::policies::runtime_checks runtime_checks; // enable the default error output openmethod::policies::basic_error_output<> error_output; // pass the hashing policy to vptr_vector explicitly, rather than implicitly via the entire Policy // disable_hashing should be either a marker type to tell vptr_vector "I don't have any hashing available" // or implement the type_hash facet and be a no-op (I guess the 1st option is better) openmethod::policies::vptr_vector<openmethod::policies::disable_hashing> extern_vptr; }; // Now register the classes. See below for the definition of registry BOOST_OPENMETHOD_CLASSES(base_node, node1, node2, openmethod::registry<custom_policy>) BOOST_OPENMETHOD(print, (virtual_<base_node>), void, openmethod::registry<custom_policy>); BOOST_OPENMETHOD_OVERRIDE(print, (base_node&), void) { /* whatever */ } // This type needs to be provided by the library, and is in charge of creating the required static storage namespace boost::openmethod { template <class Policy> struct registry { using policy_type = Policy; static Policy policy; }; } There are likely things I'm not seeing now that will probably complicate this. If the review is favorable, I can write a PR with the proposed changes and see if it's viable. > > I would love to ship a fully functional clang RTTI policy right off the bat; it > is an important use-case. > > J-L Thanks, Ruben.

2 3

In 1.88.0, BCP creates project that doesn't build
by Mason Loyet 04 May '25

04 May '25

Hi, I am attempting to use BCP to put boost into a different namespace as below: mkdir myboost_1_88_0 curl -L https://archives.boost.io/release/1.88.0/source/boost_1_88_0.tar.bz2 | tar -xvjf - cd boost_1_88_0 && ./bootstrap.sh && ./b2 tools/bcp && ./dist/bin/bcp --namespace=myboost . ../myboost_1_88_0 cd ../myboost_1_88_0 ./b2 This results in: … error: Unable to find file or target named error: '/boost/align//boost_align' error: referred to from project at error: '/home/mloyet/external/boost-test/myboost_1_88_0/libs/atomic/build' The snippet appears to work for 1.84.0. Has something changed? Am I invoking BCP incorrectly? ________________________________ Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential, or privileged information and/or personal data. If you are not the intended recipient, you are hereby notified that any review, dissemination, or copying of this email is strictly prohibited, and requested to notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. The Company, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request, or solicitation of any kind to buy, sell, subscribe, redeem, or perform any type of transaction of a financial product. Personal data, as defined by applicable data protection and privacy laws, contained in this email may be processed by the Company, and any of its affiliated or related companies, for legal, compliance, and/or business-related purposes. You may have rights regarding your personal data; for information on exercising these rights or the Company’s treatment of personal data, please email datarequests(a)jumptrading.com.

5 5

Library submission, checking out the interest
by Artem Shapovalov 04 May '25

04 May '25

Hello Boost dev community. Hope you are doing well and I'm doing right. I want to make my small contribution with my small library. It's a minimalistic implementation of a message bus that may connect together the pieces of code inside the same binary. Idea is: bring a microservices-like approach and the Publish-Subscribe pattern into a micro-level and allow all of the people not to reinvent the bicycle. Several times, I've re-implemented it because it's useful and had no reference implementation, and this is why I finally decided to make it, and I did. Here, you may check it out, it's generally satisfy some standards of Boost: https://github.com/Artem-Shapovalov/Independency Thanks for your attention. I hope you'll like it and find it useful and worth for Boost Libraries' family. Sincerely,Artem Shapovalov.

2 2

[OpenMethod] A pre-release feedback
by Andrzej Krzemienski 03 May '25

03 May '25

Hi Everyone, The library review starts still in two weeks, but I wanted to give some early feedback. First, I wanted to thank Jean-Louis for exploring the subject, writing and sharing the library, and for submitting it for the Boost Review. My feedback is based on the reading of the documentation, I haven't played with the library just yet. [1]. Animals as examples There are already a number of things in the library that suggest it might not be suitable for production use (I describe them below), but using class Animal as explanatory examples amplifies the impression that this is going to be a toy library. Half of the books I have read on OO use the Animal (or Employee) example, but never in my C++ career did I have to use OO to model something close to "animal". I know they are just examples, but picking one so detached from programming reality is in my estimation harmful. The arithmetic expression example is way better. I, for one, use OO for representing dynamically-configurable parts of the applications, such as plugins or user-selectable sorting or selection predicates. [2]. The motivation In C++ we already have a dynamic-dispatch tool for "closed set of methods with open set of types": virtual functions. We also have a dynamic-dispatch tool for "open set of methods with closed set of types": the visitation of std::variant. You need to provide a motivating example (more convincing than the zoo) that needs exactly this: "open set of methods with the open set of types". The arithmetic expression example doesn't do the job: there is a fixed and well known list of concrete types. Also, the fact that Bjarne Stroustrup wanted to add open methods long ago is insufficient a motivation. [3]. Are open methods compatible with static type checking? It looks that when one of the two things -- number of types, number of methods -- is known statically, the compiler can verify if the programmer didn't forget to take some type or method into account. (Well, sometimes we get the "pure virtual function call" error, but these are very rare cases.) The same seems not to be the case for open methods. What this library advertises as flexibility would be the source of many programmer bugs detected only at runtime, possibly by end users. Imagine that programmer Alice is adding her new type A and plugs it into open methods known to her, and at the same time programmer Bob in another file adds a new open method B known only to him. Bob doesn't know about class A, and Alice doesn't know about open method B. The ISO C++ proposals quoted in the docs mentioned solving this by a mandated or encouraged linker error. Is it possible for this library to diagnose the incomplete specification of an open method in the `initialize()` function? The docs use an expression, "when an error is encountered [...]". But note that in C++ we often use the term "error" to express the situation where a _correct_ program encounters a hostile situation in the environment (lack of resources, bad user input). But openmethod docs actually mean something different: a programmer bug. It is very easy for a programmer to plant a bug in this flexible design. [4] In a similar vein, the decision to select an arbitrary specialization of an open method upon a tie, is another runtime surprise: not even a reported error. For multi methods it is not even clear how a static check for exhaustive unambiguous specialization should work. [5] It is concerning that so many things are defined in the global namespace. The docs say, "First we need to include the library’s main header. It defines a few macros, and injects a name - virtual_ptr - in the global namespace." But then the reference part says that virtual_ptr is in the namespace boost::openmethod. Who is right? The fact that as common a name as `next` is reserved inside open methods is also uncomfortable. Why not use a namespace-scoped name? Next, the docs use the using-directive: `using namespace boost::openmethod;`. This is a bad idea: both for real programs and for the documentation: it is not clear if the library was designed with namespaces in mind. Also, all the examples define open methods in the global namespace. I instead would like the docs to show how to declare open methods in my namespace, as this is a far more probable use case. [6] Friendship It puzzles me how the notion of friendship can be combined with this idea of flexibility in open methods. It is my understanding that open methods are added on top of the existing classes. That is: classes do not have to know that some open method will be added in the future. In other words, open methods are non-intrusive, right? So how would a class know who to grant the friendship to? Also, the examples use the declaration `friend struct`, even though we are talking about methods. I think docs should mention the existence of these structs more prominently. [7] Function signatures Some macros in the library use function types in declarations: `BOOST_OPENMETHOD_OVERRIDERS(poke)<void(std::ostream&, virtual_ptr<Cat>)>` Others specify the type separately: `BOOST_OPENMETHOD_OVERRIDE(value, (virtual_ptr<Plus> node), int)` Is there a reason for this? Can the clever use of macros not offer the same function signature syntax? [8] Passing virtual pointers to const objects If `virtual_ptr<Cat>` is an analogue of this pointer, could we see an example in the docs that shows a virtual pointer to const objects? It would be `virtual_ptr<const Cat>`, I guess? [9] Is this library intended for production use? The library comes with a lot of clever macros, a lot of pointer type templates, a lot of new syntax and runtime surprises (mentioned earlier). I am concerned about how the debugging would look if something goes wrong with the usage of this library. Would you recommend it for use in production systems? Or is it for experimentation? [10] Minor things Section Custom RTTI has sentence: > Now we can include the "core" header and then header `boost/openmethod/core.hpp` is not included. Is it a bug? Regards, &rzej;

3 4

[OpenMethod] Few questions about unreasonable effectiveness of fast_perfect_hash and other minor things
by Ivan Matek 03 May '25

03 May '25

Hi everyone, few questions: 1. fast_perfect_hash achieves performance(load factor) I would assume is impossible, based on perfect hashing talk <https://www.youtube.com/watch?v=yOo6GnbKzp8>. I presume reason why it works so well that compiler places type info data clustered in same region of addresses... Is that correct? 2. regarding static_list: would Boost.Intrusive list work here also, and if so was this considered? 3. basic_error_output does not seem to need the Policy template parameter, is this left for consistency or am I wrong that it is not needed? 4. dynamic_cast_ref docs <https://github.com/jll63/Boost.OpenMethod/blob/ea7dbe86b511797f0281ef07b3ad…> mention that D must match the reference category of B. Would it be possible to static_assert that?

3 5

[OpenMethod] Questions about custom policies.
by Ivan Matek 01 May '25

01 May '25

Hello, I just started with review and I have a cluster of questions, but it is not clear what the root cause of my issues is so apologies if ordering of questions is wrong. 1. I wanted to get hash map stats, but they are not printed in debug policy, even when env variable is set, I must hack release policy like this: - vptr_vector<release>, vectored_error_handler<release>> {}; + vptr_vector<release>, vectored_error_handler<release>, basic_trace_output<release>> {} Is this expected? IDK why debug prints some trace, but not hash info 2. While playing with this I get crashes when I just c/p release policy and rename it, e.g. +struct my_release : basic_policy< + my_release, std_rtti, fast_perfect_hash<my_release>, + vptr_vector<my_release>, vectored_error_handler<my_release>> {}; crashes in template<bool Indirect> inline auto box_vptr(const vptr_type& vp) { if constexpr (Indirect) { return &vp; } else { return vp; } } but when I switch boost::openmethod::initialize<boost::openmethod::policies::my_release>(); to boost::openmethod::initialize<boost::openmethod::policies::release>(); it works fine. It also exibits some other weird behavior, e.g. if I switch debug inheritance from release to my_release crash goes away, even when not using debug... Looks to me I am doing something that is not allowed, but it is not clear what I am doing wrong. regards, Ivan

2 5

[OpenMethod] Some questions
by Andrzej Krzemienski 30 Apr '25

30 Apr '25

Hi Everyone, I have concerns with the design philosophy of OpenMethod library. Giving this flexibility that one person can add new open methods to a class hierarchy in one file and another person can add classes to a class hierarchy in another file independently, this is asking for miscommunication problems (programmer bugs) discovered only at runtime. I tried to recreate this situation that I expect would be common. My first question, even before I run tests is what will happen when I have a class hierarchy: struct Node { virtual ~Node(); }; struct XNode : Node {}; I declare an open method `value()` and override it for XNode in one file, adn in another file I extend the hierarchy with: struct YNode : Node {}; And then in main(), in yet another file, I will call `value()` with `YNode`. The documentation does not give me a clear answer. Section Error Handling says, > When an error is encountered, the program is terminated by a call to abort. And then in the next sentence it talks about different debug and release policies, and ultimately, I do not know if by default abort() is called or not. But that is not the only problem. The docs use the term " When an error is encountered". What is considered "an error" here? How many situations constitute "an error"? The docs should enumerate all these situations. I need to know when my program will be calling `abort()`. So, I dun a Compiler Explorer test: https://godbolt.org/z/3fW8j4eTM And indeed, I get something that looks like abort() But when I wrap the call into a try-catch block, all of a sudden, the implementation seems to pick the wrong overrider and return a value, clearly not the intended one. And the program goes on: https://godbolt.org/z/Y6z3o56h5 This is the worst thing that can happen: a random runtime behavior. Is this a bug? Or am I missing something? Next question that naturally arises: how do I declare `noexcept` open methods with this library? Regards, &rzej;

2 2

Proposal: Abandoning monolithic Boost documentation.
by René Ferdinand Rivera Morell 23 Apr '25

23 Apr '25

Today, in slack, we had a discussion on problems with building the monolithic docs. For context what I'm calling the monolithic docs are these <https://www.boost.org/doc/libs/1_88_0/doc/html/libraries.html>. The main problem that was raised is that a failure in one library causes all the docs to disappear. That problem is due to the nature of DocBook, XSLT, and the single monolithic generation. This is not something that can be resolved at the build system leve. The one solution is to abandon the monolithic build. And instead move to only having per library documentation builds. Hence.. I am proposing we abandon the monolithic documentation build. The benefits: * No longer missing docs from problems in individual libraries. * It's modular. I.e. libraries would build, and include, their docs in the modular layout. Do note that most libraries, more than 2/3, already use modular documentation. So technically this would be completing the modular transition that has already been happening. Thoughts? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

10 25

Review Manager Volunteers
by Matt Borland 23 Apr '25

23 Apr '25

Hi All, Recently, we've seen a shortage of review managers: Joaquin has been looking for one for his bloom-filters library for a few weeks (now solved), and Dmitry recently withdrew his GDB debugging tools due to lack of review manager. Looking at the review schedule for the last few years[1] you'll find a number of repeated names and long-time contributors. In an effort to find new volunteers for review managers I would like to ask what are the showstoppers that keep you from wanting to be a review manager? Time, Training, Recognition, none of the above? I am genuinely curious in an effort to find new volunteers so we can continue to add great libraries to the project. Thank you, and Happy Easter to those that celebrate. Matt [1] https://www.boost.org/community/review_schedule.html

12 25

Printf library suggestion
by Aaron Graham 23 Apr '25

23 Apr '25

I'd like to gauge the interest in adding the following library to boost: https://github.com/rokudev/rostd/blob/main/include/rostd/printx.hpp It's a simple library that checks and rewrites the format string at compile time in order to fortify it for use with printf, leaving the object code with only a call to the underlying C-standard printf-family function. It's a single header and requires C++20 or above (for cNTTP support). It contains these four functions: printf, sprintf, snprintf, fprintf These functions are used like so: printf<"Hello %s\n">("World!"); char buf[20]; sprintf<"Hello %s\n">(buf, "World!"); // yes, it's safe char buf[20]; snprintf<"Hello %s\n">(buf, sizeof buf, "World!"); fprintf<"Hello %s\n">(file, "World!"); Features/rationale: * It provides old-style printf (supports all standard printf specifiers). * Fully type-safe. No format string attacks. Issues are found at compile time. * Length modifiers are deduced; these format strings are portable. (No PRIu64 inttypes stuff needed anymore, just use %u) * Adds %? format specifier (print whatever type is there). * Compiles to std::printf (much smaller object code than std::format). * Provides a way for developers to easily adapt this printf formatting capability to their own functions (logging, etc.) More detailed rationale is here: https://github.com/rokudev/rostd/blob/main/doc/printx.adoc

2 1