l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
September 2: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2001 Dec 30 17:04

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] another C question (lex/yacc for parsing input)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] another C question (lex/yacc for parsing input)


  • Subject: Re: [vox-tech] another C question (lex/yacc for parsing input)
  • From: Micah Cowan <micah@coMAPSwanbox.com>
  • Date: Mon, 09 Apr 2001 11:39:18 -0700
  • References: 20010408155050.A17762@dirac.org

On Sun, Apr 08, 2001 at 03:50:50PM -0700, Peter Jay Salzman wrote:
> this is mostly a question of style.  suppose i have a program that does a lot
> of user input processing.  i have two options:
> 
> 1. roll my own parser
> 2. use lex/yacc (or whatever the modern day equivalent is.  bison/flex?)
> 
> 
> i've done option 1.  it works well, but it's not pretty.  lots of calls to
> functions like memmove() to chop, slice and dice strings.
> 
> but it has the nice feature that i don't need to learn yat (yet another thing),
> and a lot can be said for that.  plus, i've already coded it.   i'm looking at
> a semi-major rewrite of my parser to enable some more features, and if i'm
> going to change over to lex/yacc, now would be the time to do it.
> 
> otoh, lex/yacc looks VERY powerful, but it also looks like it has a steep
> learning curve.  i've heard that lex/yacc is pretty slow too.  but i have no
> grounding rod to know "how slow is slow".
> 
> has anyone here used lex/yacc for a parser?   any comments or opinions to help
> me make a choice?
> 
> pete

I doubt it's slower than anything you'd be able to write in short
order - it generates a pretty fast alogirthm; but it does have the
disadvantage of not knowing particulars about your code that you, as
an expert compiler-writer ;) might be able to optimize better.

FWIW, gcc uses yacc (dunno 'bout lex).

I am using flex/bison, and while, yes, there is a learning curve, I've
certainly seen steeper ones (flex in particular was easy to learn in
short order).  And if you plan on doing much parsing in C, it will be
very useful for many future projects - a worthwhile investment, IMO.

I can't think of a good reason why you'd need to use memmove() in your
parser - perhaps you should rethink the algorithm?  I've lately been
very interested in the subject in general, so I've been working
through my copy of the Wizard book.  /Very/ informative reading (the C
code's kinda dated, though).

Micah


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.