Would you use these/how are they?

[Jones]

I've just finished the first part of FLX's file handling system, which it will use itself primarily, but will also be available to the user, of course.

Here are the calls, and the results of each function:

FLX_findOpenFileSlot() - will find the first open slot in FLX's file array.

FLX_locateFileSlot(int *name) - will find a specific file in the array.

FLX_loadFile(char *path, char *read_or_write, int *name) - will load a text file into the FLX file array and give it the name the user designates.

FLX_closeFile(int *name) - schedules the named file for deletion. (From the array!)

FLX_cleanFiles() - deletes all files scheduled for demolition.

FLX_checkFiles() - check the array for files with matching names, that would be an error, but FLX would plow on anyway, deleting/finding the FIRST file with that name. If you're smart, you'll name all your file slot differently and never need this command. It's probably quite system costly, as it use nested while loops.

Do you think these would be easy enough to work with? The next batch will include FLX_loadCharFromFile & FLX_loadIntFromFile, to get ints and chars out of the file data in the array.

I just wondered if any of you actually see these as useful, or would suit the most common programming style?

An example of them in use:



// myName represents 35, which is a perfectly valid file code. Any int is.
int myName = 35;

int main() {


// Load myfile.txt in read mode, with the name myName.
FLX_loadFile("myfile.txt", "r", myName);

// Get the FLX subsystem slot number, you'd never need this. ;)
int theSlot = FLX_locateFileSlot(myName);

cout << "This slot: " << theSlot << endl;

// Designate the file as demolition-ready, and clean the array.
FLX_closeFile(myName);
FLX_cleanFiles();

return 0;

}


Of course, none of these have any real applicable use yet, I just wondered if they appeared useful.

Jeez sounds kinda stupid now. :D

Anyway, once the set is finished they'll be great. :wow:

I just wanted your opinions.

Thanks.

[Zekaric]

I see one error already. You have as the prototype int *name but when you use it in the example it looks like you are just passing the int not the pointer to the int. Officially the compiler should complain that you are passing an int where and int * is required. I'll just assume this is a copy paste error. The main reason I'm saying this is that most often when I see int *, it usually is used in returning a value instead of providing one to the function.

Maybe I'm not entirely apreciating the scope you are hoping to achieve with these routines. File access to be cross platform? Zip file, some sort of virtual file system or resorce access layer?

From the looks of it, it may be for cross platform with the loadChar, loadInt etc. functions you plan on putting in. Meaning that it will take care of byte ordering. I think many of us have done the same thing at least once. I have and use one myself. I didn't go as far as putting in named files though but I can probably see why you'd do that.

You'll find though that certain things are easier done with a specific format. A few here would advocate XML and the use of a library for accessing the XML (there are quite a few good ones out there.) For an ASCII representation that format is hard to beat for ease of access. Although XML isn't a good solution for everything.

For binary access, that's a different matter. It could all depend on what your desire is for the file format.

[Jones]

It was a copy paste error, I wrote them all in as pointers, they should not be. Thank you. :)

This is intended to be part of a greater whole, FLX which I made a post called "Uh... I need a name?" about in the Concepts section. I believe you already posted in it.

I was just wondering if the array system seemed too inflexible, I just finished loosening it up so that immediat access is provided, rather than waiting for a flush like command. The "load word from file" function is nearing completion, and then the load in from file will basically be the same but with char-to-int conversion. (FLX also has a function for doing that).

But once this is done, the decks will be clear to start by Units and Map management system. I've already commenced with the building of "FLX Unit Designer" an applescript application that generates all the unit data/scripts based on inputted value. (Speaking of which, would somebody be intrested in making a cocoa version of said program? <- that is secondary however, until the actual management system is complete).

Thanks for your input!

[Zekaric]

...
I was just wondering if the array system seemed too inflexible, I just finished loosening it up so that immediat access is provided, rather than waiting for a flush like command. The "load word from file" function is nearing completion, and then the load in from file will basically be the same but with char-to-int conversion. (FLX also has a function for doing that).Your own char to int converter? I'm getting nervous now. :) Mainly because there are standard ones that can't be beat. Had a similar situation at work where a third party lib had one of it's own too and it blew chuncks on some ugly numbers we provided it. Very sad. The standard atof() atoi() and other options worked better.

But once this is done, the decks will be clear to start by Units and Map management system. I've already commenced with the building of "FLX Unit Designer" an applescript application that generates all the unit data/scripts based on inputted value. (Speaking of which, would somebody be intrested in making a cocoa version of said program? <- that is secondary however, until the actual management system is complete).

Thanks for your input!Well I don't know if I really gave much value in anything I've said. It seems a bit too soon to say if these will be adopted by anyone sonce there is too little to go on at the moment. Let this not dicourage plugging on though. My only hint would be to not reinvent too much of the lowlevel stuff and spend more time on the harder things. But then, like lego, you need the small pieces in place to make the bigger thing.

[Jones]

Your own char to int converter? I'm getting nervous now. :) Mainly because there are standard ones that can't be beat. Had a similar situation at work where a third party lib had one of it's own too and it blew chuncks on some ugly numbers we provided it. Very sad. The standard atof() atoi() and other options worked better.

There are built in char to int convertors?

Mines pretty limited, it can take up to 7 digits, although that can be expanded by editing 2 numbers. I find it unlikely that anyone would need more than that.

It would take to long to kill a unit with 9 734 812 health. And if anyone tries to make a map that's 9 000 000 pixels wide and long, I will slap them... hard.

;)

[Zekaric]

char charBuffer[] = "123456789";
char *charPointer;
int intValue;

/* method 1: Not the quickest way but works. */
sscanf(charBuffer, "%d", &intValue);

/* method 2: A bit faster. */
intValue = atoi(charBuffer);
/* or (but the same as atoi on a 32 bit computer.) */
intValue = atol(charBuffer);

/* Method 3: probably not much different than ato*() functions.*/
intValue = strtol(charBuffer, &charPointer, 10);

For floats/doubles atof(). There maybe the converse functions as well, itoa() etc.; but these may be named differently as they initially were not really part of stdlib.