bison-patches
[Top][All Lists]
Advanced

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

Re: FYI: line nums in C++


From: Akim Demaille
Subject: Re: FYI: line nums in C++
Date: Thu, 20 Feb 2003 10:06:06 +0100
User-agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2

Hi Paul!

 Paul> Akim Demaille <address@hidden> writes:
 >> -        << " (line " << rline_[n_] << "), ";
 >> +               << " (line " << static_cast <unsigned> (rline_[n_]) << "), 
 >> ";

 Paul> This is the first use of static_cast in lalr1.cc.  I checked, and
 Paul> static_cast wasn't in the original C++, though it was introduced in
 Paul> the first informal C++ draft in December 1993.

Correct.

 Paul> This can easily be programmed around and and it might make sense to
 Paul> rewrite the code to something like the following anyway, as it's more
 Paul> readable when one avoids the cast:

 Paul> unsigned int l_ = rline_[n_];
 Paul> YYCDEBUG << "Reducing via rule " << n_ - 1 << " (line " << l_ << "), ";

Well, I am not convinced that this is more readable.  In particular
the cast here does look like a function call, and this functional
style is more readable to my eyes than something more imperative.
This is also the "answer" given by Stroustrup to this problem.

 Paul> But this raises the more general issue: which C++ variant
 Paul> should lalr1.cc assume?  In other words, should Bison-generated
 Paul> C++ parsers assume the latest C++ standard (ISO/IEC 14882,
 Paul> dated 1998-09-01)?  Or should they also be portable to earlier
 Paul> versions of C++?  

Definitely not.

 Paul> I am not a C++ expert and don't particularly care one way or
 Paul> the other, but the answer to this question should be documented
 Paul> somewhere.

Nothing is documented about lalr1.cc for the time being :)

Indeed, we aim at the most recent standard, as we depend on template,
STL, etc.  And we aim at no portability hassle either :)




reply via email to

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