Re: [Hla-stdlib-talk] HLA StdLib project Task List
Brought to you by:
evenbit
From: Frank K. <fbk...@co...> - 2006-08-03 00:54:21
|
rh...@cs... wrote: >>To get things kind of organized, we might want to put together a "task >>list" of items that project participants could work on. Some items that >>have come up recently: >> >> 1) fileio.append implementation not consistent > > Yes. Consistently raises an exception, actually. The constant exists (for Linux), but isn't checked for in the open routine. I can see three approaches to this. 1) Remove it, 'cause it isn't portable. If we do this with every new OS that's added, we'll soon have a very small standard library. Easy to maintain! :) 2) Let it work for Linux, and raise an exception for Windows. Not very portable. :( 3) *Make* it portable! The Windows API apparently hasn't got an "open for append" option (dos didn't - my 8-bit Atari did... Progress!). H:A can accept that option, open the file (read/write, I guess - open for append for readonly isn't too useful), and "seek" (SetFilePointer) to the end of it - "SetFilePointer (handle, 0, 0, w.FILE_END);", as a guess. Unless there are issues I don't see, this shouldn't be hard. >> 2) fileio.eof code is "crufty" according to Frank :) > > The whole concept of how testing for end of file needs to be rethought. We > may want to clean this up a tiny bit and then develop a new fileio package > that does I/O completely differently. FWIW, I withdraw my objection to that. "feof" isn't too pretty, but I don't see how else you'd do it. I was under the impression that "fread" *didn't* return the number of bytes read. I don't know if I misunderstood what I was looking at, or if it's been changed, but it *does* return the number of bytes read. So we don't need to do... read one or more bytes maybe process 'em write one or more bytes check for EOF if not, do more ... which is what I thought was "crufty". We can: read one or more bytes if zero, goto we_be_done process? write do more ... so we can "just don't do it". There's a lot of example code that *does* do it. Not a library problem. >> 3) Windows-only functions (fileio.move and copy, etc) being removed >>from the library. Randy, could you give us a complete list of these? > > > conv.cstr and conv.a_cstr are being deprecated. Though there are > equivalent routines in the str package. > > Also, fileio.cd, .gwd, .delete, .size, and several others are being > deprecated and moved into a new "filesys" namespace. It would be nice to > have a *lot* of new routines added to the filesys module. In particular, > one that would be nice to have *immediately* is a directory iterator that > returns strings containing all the filenames in a given directory. I smiled when I heard you were working on a "findfirst" and "findnext" for Linux :) We've got readdir (89) and getdents (141). I started out with getdents, which reads a buffer-full of dirents*, since readdir, which just gets one, is "obsolete". This introduced another "loop" into what was a recursive routine anyway... I think readdir would have been easier. (* actually, seems to read some maximum number of entries, no matter how big your buffer is) (note: the dirent structure is one of the things that *is* different in BSD - joy!) > In other news: I am working away on the fileio module right now, doing a > lot of clean up. I'm hoping that in about a week I'll be able to post the > code and we can get started on the multi-lingual header files and unit > tests for that module. > > I would advise against *any* modifications to the existing library code. > Almost every routine is going to have at least minor changes when I begin > posting new code. That means that any effort expended right now may be > wasted. In the event that the new code introduces bugs (I've heard of this happening), you'll wish you had the changes documented in a CVS repository, or some such... Best, Frank |