Old 7th October 2003, 06:26   #1
WHEREamI
Major Dude
 
Join Date: Jul 2002
Location: Wasabidev
Posts: 606
Suggested addition to SDK (small, easy)

just a simple suggestion of something to add to bfc/std.h and std.cpp

code:

/* bfc/std.h */

//in file part:

EXTC COMEXP char FGETC(FILE *stream);

//...

#ifndef REAL_STDIO
//...
#define fgetc FGETC
//...
#endif

///////////////////////////////////

/* bfc/std.cpp */

EXTC COMEXP char FGETC(FILE *stream)
{
char c;
FREAD(&c,1,1,stream);
return c;
}



i've added this to a .h / .c pair that i use when i need to read files in wasabi, because a find that i often want to use fgetc(), but it's not overidden in Wasabi. it seems to me it should be. is there any reason that it shouldn't?

thanx,

~WHEREamI
WHEREamI is offline  
Old 17th October 2003, 00:55   #2
WHEREamI
Major Dude
 
Join Date: Jul 2002
Location: Wasabidev
Posts: 606
any reactions? is this a good idea? bad idea?
WHEREamI is offline  
Old 18th October 2003, 17:33   #3
InfernalProteus
Junior Member
 
Join Date: Sep 2003
Location: India
Posts: 40
Send a message via ICQ to InfernalProteus Send a message via Yahoo to InfernalProteus
WHEREamI, it does seem like a very valid suggestion.

Perhaps you should remove "Don't listen to me. I'm usualy wrong." from your signature...
Have/Show some confidence in yourself man !

Just kiddin,
Brian.
InfernalProteus is offline  
Old 18th October 2003, 20:54   #4
WHEREamI
Major Dude
 
Join Date: Jul 2002
Location: Wasabidev
Posts: 606
why doesn't it seem valid? i use it all the time. it seems like if WASABI overides many of the stream/file functions of the CRT, then maybe all of them should be. they also very correctly provide a switch to disable them (REAL_STDIO) if needed. when processing data files, or the headers of mp3's, like i am, it seems appropriate to read the file stream one byte at a time, but WASABI doesn't provide a direct method of doing this.

Your thoughts would be appreciated.

(btw, sig edited)

~WHEREamI
WHEREamI is offline  
Old 26th October 2003, 04:59   #5
WHEREamI
Major Dude
 
Join Date: Jul 2002
Location: Wasabidev
Posts: 606
my appologies to Brian. i mis-read his post as "doesn't seem valid"

however, i have since thought of counter-arguments to implementing this function. A call to FREAD() makes calls through the api and goes several calls deep before returning the data, and to do this for a mere ONE character seems wastefull of processor time. a more efficient method would be to read a chunk of data into a buffer, and play with the buffer instead.

on the other hand, perhaps you don't know how much to read for some reason, and it would be "bad" for some reason to read too much.

But some un-knowing n00b (like i was not too long ago ) might try to use fgetc() with a FILE* that actually points to a filereader, not realizing that fgetc() is not overidden. then program go KABOOM!! maybe.

Be nice to hear Brennan's take on this, if he were around. Russ? any thoughts from you?

~WHEREamI
WHEREamI is offline  
Old 26th October 2003, 14:23   #6
Darkain
Major Dude
 
Darkain's Avatar
 
Join Date: Apr 2001
Location: Tacoma, WA
Posts: 1,224
Send a message via ICQ to Darkain Send a message via AIM to Darkain Send a message via Yahoo to Darkain
reading 1 byte at a time is a little slow tho, dont you think? instead, wouldnt you read a larger chunk of the file to memory, and THEN process it?

-=- Darkain Dragoon -=-
-=- RM-X Home Page - Controlling Winamp via RM-900, RM-1000, RM-1500, ATI Remote Wonder, Joysticks, Gamepads, Wheels, Keyboard shortcuts, Multimedia keyboards, across the net, and much more! -=- Defenestration !!! -=-
Darkain is offline  
Old 26th October 2003, 21:13   #7
WHEREamI
Major Dude
 
Join Date: Jul 2002
Location: Wasabidev
Posts: 606
that was the counter-point i brought up myself. Though, with the CRT, it would actually be a waste of memory to fread() into a buffer, and then process a byte at time, since fgetc(), etc, are all buffered routines anyway.

i guess my point is more the following: What would be the effects of some programmer unwittingly using fgetc() mixed with fopen() (#defined to FOPEN())? for most files (especially "file:"s, it would be ok, since FOPEN actually returns a CRT-style FILE*. but i would imagine there would be instances that the component opens something with the zip filereader, and then starts calling fgetc(), passing the address of a svc_fileReader instead of a FILE*. Probably would cause an access violation.

I guess what i'm saying is, perhaps it should be there, but commented "//Don't use this!" for those who bother to read Std.h/cpp.

Thanks for your thoughts Darkain.

~WHEREamI
WHEREamI is offline  
Old 27th October 2003, 03:24   #8
Darkain
Major Dude
 
Darkain's Avatar
 
Join Date: Apr 2001
Location: Tacoma, WA
Posts: 1,224
Send a message via ICQ to Darkain Send a message via AIM to Darkain Send a message via Yahoo to Darkain
Quote:
Originally posted by WHEREamI
that was the counter-point i brought up myself. Though, with the CRT, it would actually be a waste of memory to fread() into a buffer, and then process a byte at time, since fgetc(), etc, are all buffered routines anyway.

i guess my point is more the following: What would be the effects of some programmer unwittingly using fgetc() mixed with fopen() (#defined to FOPEN())? for most files (especially "file:"s, it would be ok, since FOPEN actually returns a CRT-style FILE*. but i would imagine there would be instances that the component opens something with the zip filereader, and then starts calling fgetc(), passing the address of a svc_fileReader instead of a FILE*. Probably would cause an access violation.

I guess what i'm saying is, perhaps it should be there, but commented "//Don't use this!" for those who bother to read Std.h/cpp.

Thanks for your thoughts Darkain.

~WHEREamI
also remember this... alot of things are different between platforms, and alot of things are changing right now... there has been alot of work to make the source code as platform independant as possible... right now, they are just #defines, but later on, that may change, i dunno. bas may get crazy and make his own file handing routines that are universal (or perhaps he already has, i think?)

granted there are uses for getc and other various things... eh... i dunno what im trying to say anymore.

-=- Darkain Dragoon -=-
-=- RM-X Home Page - Controlling Winamp via RM-900, RM-1000, RM-1500, ATI Remote Wonder, Joysticks, Gamepads, Wheels, Keyboard shortcuts, Multimedia keyboards, across the net, and much more! -=- Defenestration !!! -=-
Darkain is offline  
Old 27th October 2003, 05:37   #9
WHEREamI
Major Dude
 
Join Date: Jul 2002
Location: Wasabidev
Posts: 606
Quote:
Originally posted by Darkain
right now, they are just #defines, but later on, that may change, i dunno. bas may get crazy and make his own file handing routines that are universal (or perhaps he already has, i think?)

granted there are uses for getc and other various things... eh... i dunno what im trying to say anymore.
just #defines?? i don't think there's any way other than #defines to overide a library function, other than removing the library. in order to do that, Std.h would have to not #include <stdio.h> (it could be in Std.cpp though, and hide it from users of Std.h). and then to regain that functionality somehow... is that what bas *might* working on? (who's bas neway?)

heh... i'm not real sure why we're talking about this still either. I think we both agree that, at least for now, fgetc() should stay out of the sdk.

hmm... thought of another idea. Nullsoft could overide the FILE* typedef to some Wasabi class that also buffers, like the CRT _iobuff. then fgetc() might work quite efficiently. for the future i guess.

~WHEREamI
WHEREamI is offline  
 
Go Back   Winamp & Shoutcast Forums > Winamp3 > Wasabi Development

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump