Weird Parser Problem...

[screwtape]

I'm in a CS graphics class, which is basically an openGL class. Anyway, for all our homeworks so far we've had to use a paser library to read in datafiles that was written over 6 years ago. Its really weird, he source code of the lib is not writen by c but some BNF expressions. The c code is generated by yacc. This means that its not compatible with any other libraries that aren't in pure C. I've tried to incorporate other libraries, namely GLUI, that have been written in C++ but the compiler doesn't like it when I do that, it screws up the parser library if I try to compile it in C++. The parser also screws up some basic functions, for example I can't call the scanf function.

The complete parser library can be found at:

cse.unl.edu/home/classes/cse470/pub/lib/parser/*.*

Not only that but the parser doesn't support several things that are found in some of the datafiles, including multiple light sources, ambience, and some others.

It seems to me that it at least at one point was a pretty common parser scheme because we have about a hundred datafiles that have been written to suit it by authors from around the world.

Does anyone know anything about this parser scheme? Does anyone know if there is a better version of the same scheme? One that perhaps was written in actual C or C++ code and supports all features?

I also have certain problems with certain datafiles written for the scheme, they cause my program to crash or freeze up. I know its nothing wrong with the program itself because plenty of the datafiles DO work. This class is starting to get on my nerves, who ever wrote the parser file was a complete idiot and I don't feel like going through and rewriting it, so ANY help would be much appreciated. Also at the same site you can search around and look at the datafiles to see the format that they are in. Thanks...

[john]

Yuckon Ho,

yacc, or "yet another compiler compiler", generates source code from BNF (er, some form of syntax which looks kinda like this::=something [ <else> ]* =). BNF/EBNF isn't a language per se, but a syntax for describing syntax.

i haven't used yacc, inicidentally.

however. linking C with C++ isn't a completely transparent problem, but its not an infeasiably difficult one. the main trick is to tell your C++ compiler not to mangle the names of the yacc generated C code. (C++ "mangles" function names to make them unique based on their parameters, which is how it allows you to over-ride functions). Since C DOESN"T allow over-riding, it doesn't mangle names (with the exception of uniformly prefixing each identifier with '_'. well, i've seen some compilers do that=)

to tell C++ not to mangle C names, you'll just need to to

extern "C" {
... /* your c prototypes here */
}


>>
Not only that but the parser doesn't support several things that are found in some of the datafiles, including multiple light sources, ambience, and some others.
<<

then modify the BNF and regenerate the code.

yacc might also target C++, too, you know. it MIGHT. you could check out lexx and byson (i think byson is just the gnu version of yacc, tho)

cheers,
John

[rts]

I've had plenty of experience with flex and bison (the GNU equivalents of lexx and yacc), and can attest that they do in fact play nicely with C++, as long as you follow all the usual rules about making C and C++ play nice together. And you certainly can call "scanf" if you're using bison/yacc generated code.

As for your program crashing and/or freezing up, how do you now it's the lexer/parser and not your own code? If you've fired up the debugger and know where it dies, why don't you fix it and be a hero to countless generations of CS graphics students at your university yet to come?

(insert obligitory commment about poor state of CS education here)