bison-patches
[Top][All Lists]
Advanced

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

C++ skeleton, questions about location.hh and position.hh


From: Fernando Ferreira
Subject: C++ skeleton, questions about location.hh and position.hh
Date: Mon, 25 Jun 2007 08:10:07 +0100
User-agent: Thunderbird 2.0.0.0 (X11/20070525)

(Sorry for forwarding this email to the bison-patches list, I just realize that it would have a better target audience if sent to the developers list than to the general help list)

Greetings fellow developers!

I have a question concerning to location.hh and position.hh, files
created by bison when generating parsers using the C++ skeleton: is the
only change from parser to parser that bison generates using that
skeleton is the namespace name that encloses the classes?

Notice that this is pretty much a rhetorical question, because I took
the time to verify the source code for the skeleton, straight from CVS,
and I come up to the conclusion that yes, the only different among
location.hh and position.hh created by bison for every generated parser
is that these classes get enclosed by the namespace defined in the
%name-prefix directive, or the namespace yy, by default.


I came to that conclusion by inspecting the file bison/data/location and
looking for every possible instance of an embedded macro, by using "grep
] location.cc", as I suppose m4 macros are enclosed by ][ (I'm not sure
because, before this project, I never came in contact with m4).

address@hidden:~/Projectos/bison/data$ grep ] location.cc
@output(b4_dir_prefix[]position.hh@)
b4_copyright([Positions for Bison parsers in C++],
  [2002, 2003, 2004, 2005, 2006])[
 ** Define the ]b4_percent_define_get([[namespace]])[::position class.
namespace ]b4_percent_define_get([[namespace]])[
]m4_ifdef([b4_location_constructors], [
: filename (0), line (]b4_location_initial_line[), column (]b4_location_initial_column[)
])[
inline void initialize (]b4_percent_define_get([[filename_type]])[* fn)
      line = ]b4_location_initial_line[;
      column = ]b4_location_initial_column[;
      column = ]b4_location_initial_column[;
      column = std::max (]b4_location_initial_column[u, column + count);
    ]b4_percent_define_get([[filename_type]])[* filename;
]b4_percent_define_flag_if([[define_location_comparison]], [[
]])[
#endif // not BISON_POSITION_HH]
@output(b4_dir_prefix[]location.hh@)
b4_copyright([Locations for Bison parsers in C++],
  [2002, 2003, 2004, 2005, 2006])[
 ** Define the ]b4_percent_define_get([[namespace]])[::location class.
namespace ]b4_percent_define_get([[namespace]])[
]m4_ifdef([b4_location_constructors], [
])[
inline void initialize (]b4_percent_define_get([[filename_type]])[* fn)
]b4_percent_define_flag_if([[define_location_comparison]], [[
]])[
#endif // not BISON_LOCATION_HH]
m4_changecom([#])

My conclusions about that fact being correct, and taking in account that
these 2 classes are very simple, probably being the only possible
implementation taking in account the data structure and task to be
performed, and also taking in account that 'n' different parsers
generated by bison belonging to the same project would replicate these
classes 'n' times, I further ask: wouldn't it be better if they were 1)
not members of the generated parser namespace, or any other namespace at
all and 2) much like FlexLexer.h, in the Flex project, distributed along
with the project as a header file on $PREFIX/include?

Thanks for your time, and have a good day!

Fernando Ferreira




reply via email to

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