Hi Victor! > Le 24 oct. 2018 à 18:14, Victor Khomenko <[email protected]> a > écrit : > > ** You could use > std::copy(v.begin(), v.end(), > std::ostream_iterator<char>(std::cout, ", ")); > to print out a vector of strings.
I’m an adept of ’no raw loops’, but I always dislike this idiom. It’s incredibly ugly (the kind of C++ that haters love to take as an example of how complex this language is), incredibly verbose (still no ranges–Eric Niebler must be mad–I don’t like that begin and its friend end), and anyway, it’s for terminators. And it’s somewhat too soon to use make_ostream_joiner :) This is a Bison tutorial, not a C++ one. > * Maybe it would be better to have an api flag to suppress/request the > generation of position.hh and stack.hh? %require « 3.2" doesn't seem the > right way of doing this, IMHO: The users may want to use %require "3.2" for > but still need these files for compatibility reasons. It’s been debated, but in the end we’ll stick to require 3.2. - it’s way less code/combinations to maintain and test https://lists.gnu.org/archive/html/bison-patches/2018-10/msg00065.html - the point is to get rid of these files in a few years, so I’m pretty happy if the impetus of using new features from recent release of Bison is bound to the commitment to drop antiquities. > * The trailing return type for function definitions, like > auto to_string (const T& t) -> std::string > is a bad style - this syntax is intended for situations when the return > type of a template function depends on the parameters, e.g. > template<class T> auto plus(T a, T b) -> decltype(a+b){ return > a+b; } > In other situations, the traditional syntax should be preferred. That’s a matter of style, and I disagree. Sure, it’s _needed_ for decltype on incoming arguments, but it’s also just the right thing. C was wrong, and is still wrong about arrays, pointers, and functions. Even Go people, who are clearly the real heirs of C, have departed from C on these three concerns. https://blog.golang.org/gos-declaration-syntax However, if you _really_ think it makes the example harder to understand, I will change it. But they, don’t come up again with ostream_iterator :) > * It is possible to use flex with C++ streams - flex has C++ interface, and > I think C++ parsers should deploy C++ lexers. Yes, but again, it’s a tutorial about Bison. Flex in C++ is a moving target (Hans, that’s your cue :-), and I’m not sure I should show too much about it. > Another thought for future: You mentioned that AST with location information > is in fact the mainstream, but this is never explained in the manual! We don’t speak much of ASTs either :) I don’t think that’s our job here. Don’t you agree? Cheers!
