U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » U++ Library support » U++ Core » NTL and C4251

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Re: NTL and C4251 [message #2791 is a reply to message #2790]

Tue, 25 April 2006 14:33

jmansion
Messages: 15
Registered: April 2006
Location: London

Promising Member

>BTW, when developing Esc interpreter, I have never had any >formal grammar for the language - descent parser C++ code is >as good as the formal grammar description.

Ugh! Do your spurs jingle! Wink

I think that's a mistake.

AST -> Abstract Syntax Tree

CoCo/R -> a recursive descent parser generator. Pat Terry had a book on the C/C++ version which is now out of print so the book is online. The Java and C# versions make life a doddle, and Pat has a new (and very good IMO) book on them.

Info is here: http://www.ssw.uni-linz.ac.at/Research/Projects/Coco/

I utterly dispute any suggestion that its not a timesaver. Its just so easy to iterate the language design itself, and it makes writing 'little languages' a pleasure. The output is quite readable, and will probably not be too different to what you write by hand.

I still favour a hand built scanner and LEMON for my current project, because I think I can go fastest this way. Tho I harbour a concern that actually my carefully written scanner will be only slightly faster than I'd get from re2c or ragel.

We'll have to agree to differ.

Report message to a moderator

Re: NTL and C4251 [message #2792 is a reply to message #2791]

Tue, 25 April 2006 15:03

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

jmansion wrote on Tue, 25 April 2006 08:33

CoCo/R -> a recursive descent parser generator. Pat Terry had a book on the C/C++ version which is now out of print so the book is online. The Java and C# versions make life a doddle, and Pat has a new (and very good IMO) book on them.

Info is here: http://www.ssw.uni-linz.ac.at/Research/Projects/Coco/

Ah, yes, I think that it is exactly what I am speaking about Wink

I have gone through examples and I believe that the grammar description there is as long as the descent parser I would write for that... Wink

OK, I believe that it can save some time as long as you have description ready before starting the job...

Mirek

Report message to a moderator

Re: NTL and C4251 [message #2794 is a reply to message #2792]

Tue, 25 April 2006 15:19

jmansion
Messages: 15
Registered: April 2006
Location: London

Promising Member

>OK, I believe that it can save some time as long
>as you have description ready before starting the job...

You must type a lot faster than I do then. I think its actually most handy when evolving the grammar. I like to write the grammar, and then write some candidate inputs and see if they feel right, for the things I want to express. And then change things around a bit and try again.

Having that sort of tool makes it easy - I don't add the AST code and semantic actions until I'm happy with the structure, and there's no way I could iterate that fast even using Java or C# with a hand-written parser, let alone C++.

I can't believe that anyone would argue that parser creation isn't a whole lot faster with a good generator tool, particularly if you care about whether your off-the-cuff implementation actually handles an ambiguous grammar in a particular way through accident - I'd rather have a formal grammar specification and a tool that can warn me of ambiguities. Not least, it also makes it easier to create alternate implementations in other languages.

Its certainly the case that a hand-written parser can be faster and have better diagnostics support, if you work hard enough at it.

James

Report message to a moderator

Re: NTL and C4251 [message #2796 is a reply to message #2794]

Tue, 25 April 2006 15:43

unodgs
Messages: 1366
Registered: November 2005
Location: Poland

Ultimate Contributor

jmansion wrote on Tue, 25 April 2006 09:19

Notice that grammar for C++ is already definied and approved, so there is no need for expeiments with grammar!

Report message to a moderator

Re: NTL and C4251 [message #2797 is a reply to message #2796]

Tue, 25 April 2006 16:06

jmansion
Messages: 15
Registered: April 2006
Location: London

Promising Member

>Notice that grammar for C++ is already
>definied and approved, so there is no
>need for expeiments with grammar!

I disagree. The grammar as defined cannot be implemented directly - it requires infinite lookahead to determine which symols refer to types and which to variable declarations. There may be other issues too.

You need to transfrom it to one that can build a basic parse tree and then do a lot of the work subsequently, even in a plain class declaration. Personally I would value an ability to iterate cheaply at that stage, where I'm working with something that has a reasonable declarative correspondence to the ANSI 'grammar', rather than C++ code, but clearly YMMV.

James

Report message to a moderator

Re: NTL and C4251 [message #2799 is a reply to message #2794]

Tue, 25 April 2006 20:10

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

jmansion wrote on Tue, 25 April 2006 09:19

You must type a lot faster than I do then.
I can't believe that anyone would argue that parser creation isn't a whole lot faster with a good generator tool

Just for reference, I am speaking about code like this:

http://upp.sourceforge.net/reference$CParser.html

Quote:

I'd rather have a formal grammar specification and a tool that can warn me of ambiguities.

Not least, it also makes it easier to create alternate implementations in other languages.

I guess above two points are quite valid - I have to agree with those advantages.

Quote:

Its certainly the case that a hand-written parser can be faster and have better diagnostics support, if you work hard enough at it.

Couriously, I always thought that the only problem of my hand-written parsers is somewhat worse perfomance compared to generated ones Wink

Mirek

[Updated on: Tue, 25 April 2006 20:10]

Report message to a moderator

Re: NTL and C4251 [message #2816 is a reply to message #2799]

Wed, 26 April 2006 10:02

jmansion
Messages: 15
Registered: April 2006
Location: London

Promising Member

> Couriously, I always thought that the only
> problem of my hand-written parsers is somewhat
> worse perfomance compared to generated ones

Parser or scanner?

Anyway - are you using recursive descent throughout? (Sorry, haven't looked at CParser yet).

I seem to remember that when we wrote the Acorn BBC Micro C compiler, it got a big boost when the expression parser was moved from a recursive descent routine to a precedence engine.

But you'd have to ask Dave Christensen because that was a very long time ago, and I think he wrote that bit.

Anyway - its probably not worth worrying about this, 'cos I doubt that anyone has stomach for an implementation now. And I'd rather you guys wrote the MacOS port and integrated a real web widget and spreadsheet anyway. Smile

Report message to a moderator

Re: NTL and C4251 [message #2817 is a reply to message #2816]

Wed, 26 April 2006 10:10

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

jmansion wrote on Wed, 26 April 2006 04:02

Anyway - are you using recursive descent throughout? (Sorry, haven't looked at CParser yet).

CParser is a little bit misleading name - in fact it is primitive lexical tool for languages with similar lexical structure to C (I mean, same identifier, literal and comment rules).

Quote:

Anyway - its probably not worth worrying about this, 'cos I doubt that anyone has stomach for an implementation now.

Well, it is relevant to some degree even now as there is mixed heurestic-descent parser to get Assist++ info out of C++ sources in TheIDE... (of course, heurestic part IMHO makes it hard to implement using code generator anyway Wink

Mirek

Report message to a moderator

Pages (2): [ « ‹ 1 2]

Previous Topic:	TimeDate.cpp [BUG][FIXED]
Next Topic:	Array container does only serialize base classes

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Apr 27 18:07:25 CEST 2024

Total time taken to generate the page: 0.03416 seconds