Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #1160
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Newsgroups | comp.programming |
| Subject | Re: parser tokens |
| Date | 2011-12-30 16:09 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <jdknnp$6gr$1@speranza.aioe.org> (permalink) |
| References | <4efd343a$0$18601$bbae4d71@news.suddenlink.net> <zssptqkx73l7.151z78ll8bbk0.dlg@40tude.net> <jdkjb1$qsn$1@speranza.aioe.org> <gq3rcwt0u3m3.lynpff502ffi$.dlg@40tude.net> |
Dmitry A. Kazakov wrote: > On Fri, 30 Dec 2011 14:54:28 +0000, Rui Maciel wrote: > >> Dmitry A. Kazakov wrote: >> >>>> I am wanting to do this in C also. >>> >>> I would suggest a language with OO support. It is much more elegant and >>> easier to implement a table-driven parser in an OOPL. >> >> I don't see why. A LL parser only requires a stack and a table, and an >> object-oriented programming language isn't required to implement any of >> those data structures. > > That depends on what you mean. If you do Turing-completeness, then yes, > you could implement it in C, Forth, Assembler, machine code, even in > Convey's Life gliders. > > If stack and table are handled as abstract data types (ADT), rather than > data structures, then OO gets handy. Why do you even need to abstract the stack and the table of a meek parser? One is used to store symbols, the other is used to map a pair of symbols to a state. What do you gain by abstracting any of these components? And why do you believe that you need an OO language to abstract data? > In fact there is no need to expose > stack (or stacks) at all. OO allows you to encapsulate the parser's state > as an opaque ADT. What is inside is no concern to the end user. And again, > good design is always rewarded. > You get the parser reentrant and recursive > for free. It's widely known that recursive parsers are a bad idea. All they do is replace the parser's stack with the call stack, and that in turn opens the door to nasty problems such as stack buffer overflows and associated security problems. >> Again, I don't see why. If you buffer the data stream then you can scan >> the >> buffered data without knowing where the data came from. You just >> abstract >> the routine which fills the buffer and go on with your business. You >> don't need an OO language to do something which can easily be done with >> basic C techniques, such as function pointers. > > I prefer proper abstractions, which do not leak. I am too old to enjoy > walking minefields of low-level C programming. Please do tell how you go from using a function pointer to causing leaks. Then, please explain how you interpret basic stuff such as function pointers as "a walking minefield of low-level C programming". > OOPL does these function pointers for me automatically. Why should I waste > my time on re-implementing the OOPL's run-time library, testing and > debugging it, rather than focusing on the main objective? Your statement is quite odd. First you suggest that a user abandons C in favour of an OO language, and then you complain that you shouldn't be forced to waste your time re-implementing things, along with testing and debugging them. This is a considerable contradiction. Frankly, it sounds an awful lot like the only tool you have is the proverbial hammer, consisting of a rather limited view on OO programming, and therefore you see every single problem which you face as being the proverbial nail. Rui Maciel
Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
parser tokens "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-29 22:46 -0500
Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 10:50 +0100
Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 14:54 +0000
Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 16:26 +0100
Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 16:09 +0000
Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 18:22 +0100
Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 19:33 +0000
Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 23:08 +0100
Re: parser tokens "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2011-12-30 12:09 +0000
Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 14:43 +0000
Re: parser tokens "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2011-12-31 08:48 +0000
Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 14:23 +0000
Re: parser tokens Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-30 23:41 +0000
Re: parser tokens "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-31 18:26 -0500
Re: parser tokens Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-01 01:51 +0000
Re: parser tokens "Bill Cunningham" <nospam@nspam.invalid> - 2012-01-01 12:17 -0500
Re: parser tokens Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-01 22:17 +0000
Re: parser tokens "BartC" <bc@freeuk.com> - 2012-01-01 22:54 +0000
csiph-web