[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enhancement request: enabling Variant in C parsers

From: Akim Demaille
Subject: Re: Enhancement request: enabling Variant in C parsers
Date: Wed, 24 Oct 2018 20:01:11 +0200

Hi Victor!

> Le 24 oct. 2018 à 18:14, Victor Khomenko <address@hidden> 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
- 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

>  * 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.

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]