Re: why are locations dictated by bison?

[Hans Aberg]

Akim Demaille wrote:
>Sorry, you're wrong: it is _thanks_ to Flex that I can use a class
>here.  I _want_ one for the rest of my application.  Don't tell me how
>I have to make my application, I know better than you (even if I'm
>wrong).  You pretend you can make it simpler to me; I'm asking you to
>send the scanner I sent _simplified_ thanks to your work.
...
>#define YY_USER_INIT                           \
>  do {                                         \
>    yylloc->begin.filename = current_file;     \
>    yylloc->end.filename = current_file;       \
>  } while (0)
>
>#define YY_USER_ACTION                         \
>    yylloc->column (yyleng);

I can only give the suggestion I made:

In addition to the YY_USER_INIT and YY_USER_ACTION, one has two macros
YY_LOCATION_BEGIN and YY_LOCATION_END executed at the same spots. If one
decides to use %locations, but does not define those macros, they will
record into some default structure the info you have written out by hand.
This Flex default locations structure will be synched with the new Bison
locations default. The %locations command may have options telling which
type of data to record (line/column/position/file info/begin-end).

Thus the simplification of your code would be to use %locations instead of
YY_USER_INIT and YY_USER_ACTION macros, and then you do not need to put in
locations actions into the rules, except to override the default.

In view of that you already use std::operator new() and such C++ stuff, the
locations overhead is likely to be insignificant.

  Hans Aberg