Wow, I'm impressed by all the activity since I last checked email!
1) If we stick to standard C++, and depend only on libraries that are also
standard, we won't have a porting problem to any OS that has a conforming
C++ compiler.
2) We still have a porting issue to VC and C, but that can be overcome by
having a set of helper functions in a library that take the output object as
an argument.
3) boost and spirit are both ported to all important compilers so would be
good libraries to help with the parsing.
4) I think the most important part of the work is specifying the output
object. The details of actually doing the coding are not as critical. If we
standardize on the output object, though, then everyone could get moving on
making their apps compatible. Making an object that is easy to use and
handles every case will be difficult, but I'm sure it is possible,
especially if there are access functions.
5) I like the idea of having a tune be the atom. The "file fields" is an
issue that needs to be handled, probably by the super parser. We might need
to pass both the active file fields and the tune to the parser. Both a play
back program and a music printing program are interested in one tune at a
time, and they are common types of programs.
6) We could make the super parser part of the package, too, so there are two
functions we support: break the file into tunes, and parse the tunes.
Paul Rosen
--- Life is a musical, every once in a while
the plot stops and you start singing and dancing ---
http://home.earthlink.net/~paulerosen/brbb/
http://home.earthlink.net/~theplums/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
