Re: Usage of auto keyword in X3 tutorials
Baptiste Wicht <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <20161111142615.GA25813@frigg> |
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. 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. 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). Moreover, auto usage in Spirit is not only related to x3. In Qi, you could already use auto rules in order to improve performance. Hope that helps Baptiste On Fri, Nov 11, 2016 at 01:55:46PM +0100, Stephan Menzel wrote: > Hello everyone, > > as a long term user of spirit I finally wanted to take a lot at the X3 docs > to see what changes. > What I noticed quickly is the abundance of "auto" in the tutorials which > leads me to believe that the ease of use is probably in parts due to this. > > Am I right with this? My problem is a deep distrust of auto and I have > banned it in all our code. > Looking at this for example: > http://ciere.com/cppnow15/x3_docs/spirit/tutorials/complex___our_first_complex_parser.html > > Would this still look easy if instead of auto there would be actual types > or typedefs? > > Or, to phrase my question more tongue in cheek: Would auto haters like the > step towards X3? > > Thanks for opinions.. > > 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 ------------------------------------------------------------------------------ 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
signature.asc
(application/pgp-signature, 801 B)
-----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYJdUEAAoJEMVWa2x/iEUyrZoQAISFai2FF42zCO8Qv83Tj45a skxbnoaWfS/2KxIqyO+4XeHj6Csap7gsosm3YM7OwtsNMTgQ91EJCd+az3d7SdTT tHWkLalrhXx+5MvwMYM+S1ubyfl6DnQBEGkNxzGG5Sn1vcUu0cA1yN4jrPVXERFh KrjxGnTTpVQuMQzoUwjiPQCKL1ZCM8pNMCVzjuTavBJXpWWhKgwbzyKrQ2FVIqvA cKN2/HGA7dqaZtKUx5V1g8SMr5MGPmXYzAUNEgwbJoRy6Uxb9g7uRR/Ncoc05Iih sm0dxrBJh2N3PxrxTALYSHLvP+NsnOP6YDPwirDRFZnirG3og5zAr4dNuYjuO5eu X3irUI/e/lWKfzpS/bd0cb43zgKSOUPWrJwSG95ITzV6vRK8wN+8UwyBka1rJ5PT uUMajLErcTCZRvsHe+Zd/1Paqg8OJDW/CWVA6loqutpji+66WDme+qQj+Q7oHFF2 ggwuQKvi3XzSaHj2Eyn5emgwCZ9GrHvefT6RJp6QMsOtxM0S0JldZ6g2QE6ivtY3 qQgfyesem1FnQHaQk+4zVa5I1QtLXiuOEw1iL7jvZXO7PCA5eLns1ChmE+zMjgDl 69ENE9rM9SVsqNhC9lpiifrdHANygQhyrsF5cV+XiTBDJQG6t5iynQzcydRvAlQQ qu3huI0he4K5jrK6y8OK =eJ6g -----END PGP SIGNATURE-----