Re: [Alephmodular-devel] Random rumblings on files and errors

[Dietrich E. <die...@zd...>]

On Wednesday, January 29, 2003, at 08:44 , Br'fin wrote:

> I've been mucking with a spare copy of AM, actually trying to implement 
> what I have described in my draft so far. Which is of course turning up 
> more areas to work upon.
>
> Like, most files are going to be opened in binary mode. So this makes a 
> reasonable default, however, some files in the future are going to be 
> text based, so we should support that as well. I was thinking of 
> exposing the iostream openmode flags as part of the 
> open_file_for_reading/writing business. And just have it default to 
> binary. You could clear it of course by passing 0 for the mode (or a 
> suitably equivalent definition)

Is there really a difference between text and binary mode?  I thought 
that was all arcane.  I've never liked C++ iostreams, they have only 
served to add compile time and code size in the megabytes to my projects.

> The other two aspects I found myself leaning towards were calling 
> conventions and error feedback.
>
> By calling conventions I was thinking of calls like this:
>
> 	virtual bool get_named_child(const char *name, IFileSystemDesc* 
> &out_desc) const = 0;
>
> This is a method to specify a file or directory within a directory. The 
> name of that desc would be the string name.
>
> If the function was successful, then it would return true, and the 
> IFileSystemDesc* would point to a newly acquired class. (Which the 
> caller would need to free currently)
>
> If the function failed, then it would return false, and the 
> IFileSystemDesc* would remain untouched.
>
> And the reason for failure? Well, after a little bit of thinking, I 
> realized that there should be an IError interface with three methods. A 
> protected set_state, a public get_state and a public clear_state. And 
> in thinking of it, it's possible that the state itself could be verbose 
> enough to display/log when dumped to a stream.
>
>
> Why not exceptions? I have not been sold on exception handling in C++ 
> under some warnings of exception handling being there, but less than 
> optimal under C++ (Less practical in terms of speed, doing extra work 
> with stuff too low level for me really to be thinking about :) ) and a 
> simple lack of knowledge on how one is supposed to do it in C++. (Java 
> is at least clear on what things you should be throwing around) 
> Admittedly a nice clear document that counters these perceptions as 
> myth might change my mind.

Believe it or not, exceptions add no speed overhead.  Well, there is 
overhead when they are thrown, but nobody cares how much overhead the 
throwing takes.

Unfortunately, the exceptions that are part of the C++ libraries are 
rather lacking.  It's a whole bunch of unnecessary abstraction in my 
mind.

`new', for example, throws an exception when it allocates something.  
But the exception doesn't contain any more information than that, so it 
is not really helpful.  You could make your own new, new[], delete, and 
delete[] that throw better exceptions.

Basically the brain-damaged part of C++ to which you refer is that an 
exception can be anything.  You can throw an integer [I wonder if you 
can throw a void?].  The remedy is that you just don't deal with it, 
because you won't be throwing them.  Program by contract =)

----------

It seems to me that there is a better way to design these complicated 
file wrappers than putting all the functionality into one big mother 
interface.  I have a few suggestions.

Class: FileSystem
- Manages the translation of paths (or other identifiers) into files
- Locates files
- Manages archives (in the future)
FileHandle* OpenFile (const char* path, Mode mode);
bool FileExists (const char* path);
--- etc ---

Class: FileHandle
- Reads, writes, and seeks
- Manages metadata, such as privileges, file size
virtual size_t Read (void* buffer, size_t amount) = 0;
virtual size_t Write (const void* buffer, size_t amount) = 0;
--- etc ---

The bit about archives is so you could distribute a scenario as a zip 
file or other format.  The FileHandle is only an interface for reading 
and writing data, it could be subclassed to read data from an archive.  
You won't have to include any funky files, FileSystem manages which 
implementation is used.

If the data itself is abstracted to a degree, the files that support 
mmap'ing could do so.  This would provide performance benefits on 
systems with decent virtual memory such as OS X.  I would be willing to 
"put my money where my mouth is" and design and implement the bits, if 
y'all are receptive to the idea...

-----------

On a somewhat related note, it would be nice to choose a style for 
making AlephModular consistent, and maybe organize the files so you can 
actually find what you're looking for.