I have been a user of yomm11 for quite some time. At the time where I started using it I faced a problem with the use of multi-methods from classes, which I solved by using a suggestion by @jll63.

The example elaborated at the time is attached for reference: much like in the matrix example, multi-methods are used to handle a hierarchy of classes, however in this case the "entrypoint" is a public method of the Painter class.

The requirement was to access some private member of the Painter class from the multi-methods. Since it is not possible to declare a multi-method as a member of the class, the solution was to friend the class generated by the preprocessor, and pass the instance to the various multi-methods.

However, in yomm2 the same solution seems more difficult to achieve: the library generates a numeric ID for the namespace where it declares the methods, which I presume depends on the order of declaration and thus cannot be reliably predicted. Attached is my attempt to solve this, but I have the feeling that it is a brittle solution.

Any suggestions for the above? Would a variant of declare_method and define_method, to use within a class eligible for implementation? For example:

class Painter
{
public:
    void paint(const Geometry& geometry);
private:
    int counter = 0;
    declare_class_method(void, paintObject, (virtual_<const Geometry&>));
};

define_class_method(void, Painter, paintObject, (const Geometry& /*geometry*/)) {
    // ...
}

Thanks for this library. It feels like I have a new superpower!

According to the reference doc, it should be possible to dispatch on shared_ptr<Animal> const& but if I add the const ref qualifier, I get lots of template error messages, the first of which says Static_assert failed due to requirement 'shared_ptr_traits<const std::__1::shared_ptr<ScalarT<double> > &>::is_shared_ptr'. I assume I am doing something wrong.

Here is an example. It works as is. But if I change the #if 1 to #if 0 to enable const ref for all arguments, then it doesn't compile.

I am compiling with Clang in Xcode 12.3.

#include <yorel/yomm2/cute.hpp>
#include <iostream>
#include <memory>
#include <string>

#if 1
#define CONSTREF
#else
#define CONSTREF const&
#endif

using yorel::yomm2::virtual_;

class Value { // base class for values
public:
	virtual ~Value() = default;
};

class Scalar : public Value {};  // base class for scalars

template <class T>
class ScalarT : public Scalar {
	T x_;
public:
	ScalarT(T x) : x_(x) {}
	T x() const noexcept { return x_; }
};

// convenience function to create a shared ScalarT.
template <class T>
std::shared_ptr<Value> num(T x) { return std::make_shared<ScalarT<T>>(x); }

register_class(Value);
register_class(Scalar, Value);
register_class(ScalarT<int>, Scalar);
register_class(ScalarT<double>, Scalar);

declare_method(std::shared_ptr<Value>, plus,
	(virtual_<std::shared_ptr<Value> CONSTREF>, virtual_<std::shared_ptr<Value> CONSTREF>));
	
declare_method(std::string, str,
	(virtual_<std::shared_ptr<Value> CONSTREF>));

define_method(std::shared_ptr<Value>, plus,
	(std::shared_ptr<Value> CONSTREF a, std::shared_ptr<Value> CONSTREF b))
{
	throw std::runtime_error("unsupported values in plus");
}

define_method(std::shared_ptr<Value>, plus,
	(std::shared_ptr<ScalarT<int>> CONSTREF a, std::shared_ptr<ScalarT<int>> CONSTREF b))
{
	return num(a->x() + b->x());
}

define_method(std::shared_ptr<Value>, plus,
	(std::shared_ptr<ScalarT<double>> CONSTREF a, std::shared_ptr<ScalarT<double>> CONSTREF b))
{
	return num(a->x() + b->x());
}

define_method(std::string, str, (std::shared_ptr<Value> CONSTREF a))
{
	throw std::runtime_error("unsupported value in str");
}

define_method(std::string, str, (std::shared_ptr<ScalarT<int>> CONSTREF a))
{
	return std::to_string(a->x());
}

define_method(std::string, str, (std::shared_ptr<ScalarT<double>> CONSTREF a))
{
	return std::to_string(a->x());
}

int main(int argc, const char * argv[])
{
	yorel::yomm2::update_methods();
	
	auto a = num(1);
	auto b = num(2);
	auto c = num(3.01);
	auto d = num(4.001);
	std::cout << str(plus(a, b)) << "\n";
	std::cout << str(plus(c, d)) << "\n";
	return 0;
}

HI @jll63,

Thanks for the lib again, still playing with it. Seeing this error in runtime destructor, do you know what may cause this? (not repro debug build on mac, haven't done debugging it on linux server yet assuming this is something wrong related to runtime struct for certain case)

*** Error in `./NodeServer': free(): corrupted unsorted chunks: 0x000000000155b170 *** *** Aborted at 1563204608 (unix time) try "date -d @1563204608" if you are using GNU date *** PC: @ 0x0 (unknown) *** SIGABRT (@0x3bb20000227b) received by PID 8827 (TID 0x7f8a872cf080) from PID 8827; stack trace: *** @ 0x7f8a86cb6330 (unknown) @ 0x7f8a860dfc37 gsignal @ 0x7f8a860e3028 abort @ 0x7f8a8611c2a4 (unknown) @ 0x7f8a8612882e (unknown) @ 0x698710 __gnu_cxx::new_allocator<>::deallocate() @ 0x695988 std::allocator_traits<>::deallocate() @ 0x690eee std::_Vector_base<>::_M_deallocate() @ 0x68b38f std::_Vector_base<>::~_Vector_base() @ 0x687785 std::vector<>::~vector() @ 0x687120 yorel::yomm2::detail::runtime::~runtime() @ 0x681898 yorel::yomm2::detail::update_methods() @ 0x6862f5 yorel::yomm2::update_methods() @ 0x41ebdd RunServer() @ 0x41abda main

call stack in GDB: (gdb) bt #0 0x00007ffff6df1c37 in __GI_raise ([email protected]=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff6df5028 in __GI_abort () at abort.c:89 #2 0x00007ffff6e2e2a4 in __libc_message ([email protected]=1, [email protected]=0x7ffff6f40350 "*** Error in `%s': %s: 0x%s \n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff6e3a82e in malloc_printerr (ptr=, str=0x7ffff6f404a0 "free(): corrupted unsorted chunks", action=1) at malloc.c:4998 #4 _int_free (av=, p=, have_lock=0) at malloc.c:3842 #5 0x00000000006b269a in __gnu_cxx::new_allocatoryorel::yomm2::detail::rt_method::deallocate(yorel::yomm2::detail::rt_method, unsigned long) () #6 0x00000000006b011c in std::allocator_traits<std::allocatoryorel::yomm2::detail::rt_method >::deallocate(std::allocatoryorel::yomm2::detail::rt_method&, yorel::yomm2::detail::rt_method, unsigned long) () #7 0x00000000006abcec in std::_Vector_base<yorel::yomm2::detail::rt_method, std::allocatoryorel::yomm2::detail::rt_method >::_M_deallocate(yorel::yomm2::detail::rt_method, unsigned long) () #8 0x00000000006a6703 in std::_Vector_base<yorel::yomm2::detail::rt_method, std::allocatoryorel::yomm2::detail::rt_method >::~_Vector_base() () #9 0x00000000006a2f8b in std::vector<yorel::yomm2::detail::rt_method, std::allocatoryorel::yomm2::detail::rt_method >::~vector() () #10 0x00000000006a29c6 in yorel::yomm2::detail::runtime::~runtime() () #11 0x000000000069d306 in yorel::yomm2::detail::update_methods(yorel::yomm2::detail::registry const&, yorel::yomm2::detail::dispatch_data&) () #12 0x00000000006a1d63 in yorel::yomm2::update_methods() () #13 0x0000000000413622 in main (argc=1, argv=0x7fffffffe808) at /home/shawncao/nebula/src/service/node/NodeServer.cpp:178

Outline

We are using yomm2 as a dependency of our library on a range of machines, and many of them do not have boost installed by default. System administrators often do not want to install boost system wide. This makes compiling yomm2 difficult, and it would be better if yomm2 took care of its boost dependency itself. This PR implements that feature in the same way we deal with google/benchmark already.

Comments

• This PR raises the minimum CMake version from 3.0 to 3.5 since boost's CMake code requires it.
• Boosts CMake code is still not officially supported, so some hacky code was required to make it work.
• The boost dependency is "PUBLIC", meaning that depending projects also need it - it is thus installed along with yomm2.
• I have tested this with CMake 3.5 and 3.19 on my own machine - nowhere else yet.

I enjoyed your cppcon video, and I'm having fun playing with your library - thanks!

If I forget a define_method, I can get an error callback with set_method_call_error_handler.

If I forget a register_class, I get a segfault during update_methods.

I understand that it can't just magically work, and I like that it fails early ( during update_methods, which hopefully I'm calling right from the top of main ).

Is there any way to throw, or at least abort with relavent stderr text in this case ( without significant additional expense )?

I can provide a sample if necessary, but just removing a register_class from an example should do it.

Sorry for the pull request out of the blue. I am suggesting major changes to the CMake scripts of yomm2. First let me explain why I was motivated to make these changes

Motivation

When using yomm2 as a dependency, we usually employ the same technique as suggested at for googletest: Download, build and locally install yomm2 automatically during CMake configure step using ExternalProject_Add and include the result in our main build. For yomm2, it was not possible to use CMake's find_package command to include yomm2 in our build since yomm2 does not define a proper CMake package upon installation. This is only a minor inconvenience, but was enough to motivate me to work on yomm2's CMake scipts. Additionally, "benchmark" was always downloaded even when YOMM2_ENABLE_BENCHMARKS was not set to ON, which takes unnecessary time.

Content of Pull Request

I have mainly made two changes:

1. Defined CMake package building instructions (install instructions) for yomm2
2. Overhaul of how the "benchmark" dependency is pulled and built

As for the first point, the commits are fairly short and are the best explanation of the content of my changes that I can come up with at the moment.

For the second point, there are a few advantages to the new method of automatically downloading and building "benchmark"

• We no longer use add_subdirectory, so a different CMAKE_BUILD_TYPE can be used (always RELEASE atm)
• We only download "benchmark" if YOMM2_ENABLE_BENCHMARKS=ON and it is not already installed
• Since "benchmark" is built during the configure stage, we can use find_package to include it (better encapsulation) The only disadvantage I can come up with is that we use execute_process to execute a second cmake during the configure stage. Command line settings are not automatically transferred to this nested call, but I cannot come up with a case where that would be a problem.

Conclusion

I believe the suggested changes make yomm2 a more complete library, as it is now a fully defined CMake package that can easily be used from user side code (like the library we're working on).

Please let me know if you have any questions, and I will try to respond quickly!

I enjoyed your articles on the algorithms and data structures you used to generate yomm11's dispatch tables. I don't see any comparable description for yomm2, and the comparison to yomm11 suggests the internals are substantially different. If this is the case, do you expect to write an article or summary of yomm2's algorithms?

Add C++17 as a required feature of the library in a generic way. This should probably be sufficient to allow the library to be packaged for OSX in vcpkg.

• minor changes for preferred way to fiddle with flags

Three things here:

1. Travis

• The script did not detect that hybrid builds were broken. That's because it didn't exit in error when intermediate steps failed.
• I also cleaned it up a bit, now CONFIG is used to specify all configurations (i.e. also the hybrid ones).
• I added a dimension to the build matrix: with or without Boost pre-installed.
• At the end, I run make install, and check that Boost libs were also installed if they were not already available. I don't know why, but installing does not work for hybrid builds so I skip this step in that case. To be investigated.

2. Hybrid builds were broken after the auto-fetch work. My fix involves a few symlinks. If you have a better solution, please tell me.
3. I moved the dependencies directory to the build area. It seems much cleaner to me, some users want to keep their source tree entirely free of artifacts. It leads to redundant downloads when building several configurations, but the cost is not huge and we don't run cmake that frequently. It also makes testing cmake related work easier, as deleting the build dir suffices to start again from scratch (a couple of times I forgot to rm dependencies and puzzled over the output).

• Support shared library builds of yomm2 via CMake option YOMM2_SHARED
• If shared library build is on, force hidden visibility on *nix which greatly reduces .so size

Hello and thanks for the wonderful library.

Is there any way to dispatch on arbitary values, not just types? Coming from a clojure background, I am trying to replicate some of the behaviour of clojures multimethods.

In clojure the method declaration takes a function some_fn and before dispatching, it calls some_fn(arg1,args2, ...) and then dispatches based on the return value of that function.

This enables for example dispatching on certain values in the argument and adding new behaviour later based on these fields.

Some pseudo code of what I wanted to write:

struct Customer{
  //some fields
  int accessLevel;
};

declare_method(std::string, purchase_rare_item, [](Customer& c){return c.accessLevel;});

define_method(std::string, purchase_rare_item, default) {
    return "not allowed";
}

define_method(std::string, purchase_rare_item, 4) {
    return "please refer to the VIP auction page"
}

define_method(std::string, purchase_rare_item, 5) {
    return "thank you for your purchase."
}

The alternative would be to write a closed switch.

My current workaround idea is just to create a lot of classes, so I can have the type dispatch. But it gets quite ugly. I would like for example to dispatch on whatever is the first item in a std::vector and I feel bad creating subtypes of that. Or is your advice to just go with this?

What if the existing class I want to dispatch on has no virtual functions? Should I just wrap them in one with for example a virtual destructor?