Re: Usage of auto keyword in X3 tutorials

Hello Baptiste,

On Fri, Nov 11, 2016 at 3:26 PM, Baptiste Wicht <[email protected]>
wrote:

> Hi Stephan,
>
> For the particular example, you can probably get around using auto by
> using std::function. The problem here is not related to spirit X3 but to
> the use of lambda expressions for which you cannot know the type but you
> store them in a std::function of the correct type. Replacing auto
> functors by std::function is likely to be detrimental to performance
> though.
>
> If you also don't like generic lambda, you can compute the type of
> context using typedefs without too much issue to avoid the "auto& ctx",
> but I don't really see the point.
>

Indeed. This would not be very nice. And in fact, I like generic lambdas a
lot. They are the prime reason I wanted to check out X3 since according to
my knowledge Spirit2 doesn't allow native lambdas in semantic actions and
forces me to use phoenix, which has a tendency to cause problems and longer
compile times.

For example, the other day I wanted to parse a string into the new qvm
vector types and there was no way to make phoenix accept their X() Y() or
Z() accessors. I tried for a long time all sorts of variants and ended up
having to create a slim wrapper which exposed the getters and setters as
regular functions to finally make it work with phx::bind as a last resort.
Quite clunky and not nice. With lambdas this might just have worked.
So don't get me wrong, I like many of the new C++ features a lot. Just
abhor auto for reasons that may not belong here.


But you gonna have other problems if you don't like auto if you have
> a big grammar. For instance, if you look at this:
> http://ciere.com/cppnow15/x3_docs/spirit/tutorials/rexpr.html With
> larger grammars, you are going to use auto for the definitions of the
> rules. In that particular case, the type of the definitions should only
> be deduced, never written even with typedefs... Unless you can to use
> decltype, but I guess you don't like it either. In that case, I don't
> know how to do it without auto, but there is probably a solution.
>

Yes, that example is even more along the lines of what concerned me.

Honestly, since x3 is a C++14 library and makes extensive use of modern
> C++, I would not use it without using auto. Using x3 without auto would
> feel like a crippled version of x3, in my opinion (just like C++>11
> without auto is crippled).
>

Got it. I guess I won't switch then. The tradeoff seems to be too much
right now.

Moreover, auto usage in Spirit is not only related to x3. In Qi, you
> could already use auto rules in order to improve performance.
>

Are you sure about that? I use spirit almost exclusively by defining
grammars. Both qi and karma, mostly symmetrical. So my general pattern is
to have a rather large set of grammars like this:


template <typename Iterator>
struct username_parser : qi::grammar<Iterator, std::string()> {
username_parser() : username_parser::base_type(m_start, "username") {

m_start %= ... define my stuff ...
}

qi::rule<Iterator, std::string()> m_start;
};

which I then combine to the actual larger grammars that I really need
(identical pattern).

All those are kept hidden in a header that is only included by a compile
unit which then exposes plain functions to do the parsing in order to keep
compile times in check by not letting anything spirit out into the rest of
the code.

Which means I use the rule definitions a lot.

Are you saying that above example would be better by using auto instead of
the rule definition? Or are you referring to the "auto" parser which
chooses a generic parser by attribute type? Because I am using this,
although rarely.

Cheers,

Stephan




>

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general