Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?

Hi Paul, Please find my answers below.

The library looks very nice. A couple of things

Cheers

First, it's not just C++14 only as it relies on compiler intristics which just happen to work on the three major compilers you support. It would be nice if you just relied on the standard library for these things.

Well, the library is pure C++14, however, as you mentioned, it uses an compiler extension to create a compile time string. Having said that, it's totally optional and it doesn't have to be used at all. What I mean by that is that you can write: using namespace msm; auto state = "idle"_s; //or auto state = msm::state<class idle>{}; //or msm::state<class idle> idle; All of them will give the same result, however the first option (non-standard one) just happen to be more convenient.

Most likely, users are going to use the standard `type_traits` header anyway so this will cause a lot of duplication. Futhermore, the implementation of `make_index_sequence` can be much slower performance than the standard library since it doesn't take advantage of the compiler intristics that are available

It's true, however, available standard libraries are not always working the same way. Especially MSVC standard library was giving me a lot of hard times. For example. is_constructible was working differently, make_index_sequence was recursive etc. and therefore I put the implementation in the header as it was easier to maintain it. Anyway, most of the times it uses compiler support either way like __is_base_of, etc., so it's not a big deal. All in all its just 90 lines of code. I'm not saying I won't use type_traits for it, but I don't see much gain from doing it right now as I would have to put a lot of ifdefs there either way :/ Yea, I know about make_index_sequence improvements in clang/gcc, but it's still not available in the newest release of those compilers as far as I remember. I would be really happy to change the implementation into __make_index_sequence, for instance. The other point is the fact that not being depended on STL allows embedded/console games/etc. developers to use the library as they, in a lot of cases, don't have access to STL. To sum up, I agree with your points and maybe the library will use type_traits header at some point, however I don't see a lot of benefits of changing it right now.

Secondly, the documentation for the concepts seems confusing. In the documenatation it show the concept as this:

template concept bool callable() { return requires(T object) { { object(...) } -> TResult; } }

I assume its written like this for notational purposes. However, the example shows it being used like this:

auto guard = [] { return true; }; auto action = [] { };

static_assert(callable); static_assert(callable);

Which is incorrect as in the code its an alias to an `integral_constant`, however, the `integral_constant` doesn't look like its fully implemented, so this fails as well:

auto guard = [] { return true; }; auto action = [] { };

static_assert(callable()); static_assert(callable());

Of course, using `std::integral_constant` would make the above work.

Firstly, I'm not really using concepts-lite in the library, just a some silly emulation, so yea, its just for notation purposes. Secondly, fair point, documentation is wrong there, as above example will not compile. Thanks for pointing that out. Anyway, library is no about concepts, they are not exposed to be used outside of the library. They help getting nicer error messages and they are meant to stay this way. But I get your point and I will change the documentation.

Thirdly, Boost.Hana started out in a similiar fashion, being single header and not relying on the standard library. Of course, as it grew, it needed to use multiple headers and the standard library headers as well.

Yea, I remeber, however this library is meant to stay 'lite'. If it comes to multiple headers. I find it very useful to have just one header in the end. I have been using this approach in my experimental boost.di library too, however, there I generate the header from all hpp files. You can check it here: https://github.com/boost-experimental/di

Finally, I like the documentation setup. I use mkdocs as well for my documenation, and I created a boost theme to try and match the boost documentation. You can see it here: https://github.com/pfultz2/boost-theme Of course, its still a WIP. I, also, like the code snippets with option to compile and run the code online in the documentation. I think I am going to try to setup something similiar for my library as well.

Cheers, and thanks for the link, looks promising. I will defo take a look. Yea, these days we can liven up documentation quite a lot with js. Feel free to use solution provided, we can also merge your boost-theme with my facilities to provide modern way of boost doc with mkdocs? Thank you very much for your feedback! Cheers, Kris -- View this message in context: http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-M... Sent from the Boost - Dev mailing list archive at Nabble.com.