On 4 May 2004, at 23:43, Steven Bennett wrote:
Christian M. Cepel wrote:
I had envisioned the parser working with a controlling program thus...
o Program is responsible for helping the user to navigate the filesystem (including url locations) to locate the file to be parsed.
This creates two scenarios. 1. In the case of a local file, the file is locked for access. File reference is passed to the parser. 2. In the case of a non local file, or an 'unsaved' buffer in the program, a file reference is not appropriate.
<Discussion snipped>
IMHO, memory is cheap, most every OS in wide use today supports some kind of
virtual memory, and abc files are, in general, relatively miniscule. In
fact, it wouldn't surprise me one bit if the data structure returned by the
parser is significantly larger in memory use than the text fed into it.
So I would recommend you avoid the file reference entirely and work only on
a passed in memory buffer. You don't have to worry about it changing under
you, or any file idiosyncrasies of the underlying system, and it will
simplify your code quite a bit.
I agree. File systems work differently on different platforms, and the
decisions about how to use them have to be made by the person writing the
containing program. Just pass in a pointer to the text to be parsed, plus
the length of the buffer, and maybe a selection range if you want the
parser to be capable of parsing a part of the tune.
The only environment where I see a potential issue with doing it that way
might be a PDA trying to handle a Huge ABC collection file. But were I
coding a parent program for such a beast, I'd write a brute force pre-parser
to split the collection into individual tunes which get fed to the parser
individually anyway. So again, the parser shouldn't have to worry about
memory use.
Yep.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
