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?

Subject: 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?
From: Kris (krzysztof_at_[hidden])
Date: 2016-01-29 07:12:10

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 <class TResult, class T> 
>    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<bool, decltype(guard)>); 
>    static_assert(callable<void, decltype(action)>); 
>
> 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<bool, decltype(guard)>()); 
>    static_assert(callable<void, decltype(action)>()); 
>
>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-MSM-eUML-like-library-which-compiles-up-to-60x-quicker-whils-tp4683016p4683064.html
Sent from the Boost - Dev mailing list archive at Nabble.com.