Nikola Ikonic wrote:
Hello,
I am working on a modification of C parser and I need some help since
I am having difficulties understanding some issues (I am complete
newbie on GCC). Long story short, I am trying to add a new attribute
to function types (similar to "inline", for example). Let's say
Ian Lance Taylor wrote:
I'm sure Joseph could explain the reasons better, but some of the
problems with the bison parser were 1) it's hard to generate good
error messages at the right places; 2) C is not LALR(1) (at least, not
in a natural sense) because of the declaration syntax; 3) it made it
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> I was quite surprised to see that the C Parser was manually
> implemented and you didn't use any parser generator.
>
> I would be curious regarding this decision. I would think the
> development of a C parser would be an almost unsurmountable task an
On 1/18/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Hi all,
I was quite surprised to see that the C Parser was manually
implemented and you didn't use any parser generator.
I would be curious regarding this decision. I would think the
development of a C parser would be an almost unsurmountabl
Probably someone else may give better answer, but shortly with the
many extensions (ad-hocks) to the C/C++ grammar the task of preparing
the inputs for the lex and bison seems not so trivial. Also, the
automatically generated parser wouldn't be as efficient as it is now.
On 1/18/07, Paulo J. Mato
Volker Reichelt wrote:
> Shouldn't we fold cp_parser_declarator_id into the caller and call
> cp_parser_id_expression directly?
Originally, I was trying to have a function for each non-terminal. I'm
not going to be dogmatic about that, but is there a good reason to
remove the function? As Gaby
On 7 Dec, Nathan Sidwell wrote:
> Gabriel Dos Reis wrote:
>
>> If we make it "static inline", would not we gain the same efficiency
>> and preserve the comments and all that? In general, the methodoly
>> seems to have a function for each non-terminal -- following a long
>> tradition of recursive
Gabriel Dos Reis wrote:
If we make it "static inline", would not we gain the same efficiency
and preserve the comments and all that? In general, the methodoly
seems to have a function for each non-terminal -- following a long
tradition of recursive descent parser -- and maintaining that
princip
Volker Reichelt <[EMAIL PROTECTED]> writes:
| The C++ parser contains the static function
| cp_parser_declarator_id (cp_parser* parser)
| which consists of a lot of comments and a single statement
|
| return cp_parser_id_expression (parser,
| /*template_keywo
