Hi!
12-Июн-2006 18:24 [EMAIL PROTECTED] (Eric Auer) wrote to
[email protected]:
>>> typedef unsigned char byte; /* eliminate troubles with sign extension */
>>> #define MK_PTR(type,seg,ofs) \
------------^^^^^^
>>> ((type FAR*) MK_FP (seg, ofs)) /* safer edition of MK_FP */
>>> typedef struct { byte col, row; } SCRPOS;
>>> #define _scr_page (* MK_PTR (volatile const byte, 0, 0x462))
>>> #define _scr_pos_array MK_PTR (volatile const SCRPOS, 0, 0x450)
>>> unsigned mywherex (void) {
>>> return _scr_pos_array [_scr_page].col + 1;
>>> unsigned mywherey (void) {
>>> return _scr_pos_array [_scr_page].row + 1;
EA> I would recommend not to override byte and MK_FP locally.
I not _override_ `byte' (there is no such type in standard) - here this
type I introduce just for conveniency. You may not use `byte' (only explicit
`unsigned char'), but this decreases readability.
Also, I _not_ override MK_FP: see underlined name above.
EA> implementation of mywherex and mywherey, although I wonder
EA> why 0:0x4nn would be better than 0x40:nn - I think it is not.
It better, at least, because generates shorter code: "xor ax,ax/mov
es,ax" instead "mov ax,40/mov es,ax".
EA> It is better to EXPLICITLY use 0x40, to make it obvious to
EA> people who read the source code that 40:xx is accessed. Even
EA> if this means that FreeCOM will be 2.5 bytes larger ;-) .
:) May be. May be, 40:xx is more obvious - though, for me this is equal
to 0:4xx (which shorter - in source and code). :)
>>> BC> +void outc(char c)
>>> BC> + fflush( stdout );
>>> BC> write( 1, &c, 1 );
>>> Why not use fwrite() here?
>> Because the code that's there works just as well.
EA> I think you wanted to say void outc(char c) { fflush(stdout);
EA> write(1,&c,1); } and that code does NOT work well. If you
EA> flush stdout each time that you write a single character,
EA> you get very slow output. My question is: Why do you need
EA> fflush here? I would suggest to use outc only at places where
EA> handle-oriented output is already used, and use fwrite (or,
EA> if that exists, fputc / fputs), at places which use FILE output.
No, Eric, I think, _in FreeCOM_ better to remain FILE*-oriented output
(but isolate it in own functions, like outc()). Why?
- this eases portability.
- you shouldn't worry about own buffering (for long output, like in DIR).
- you shouldn't worry about using *printf() functions family with
handle-oriented IO.
EA> In the long run, it would be cool to get rid of FILE style
EA> access at most places in FreeCOM, but that would be much work.
Yes. And this is reason, why to remain this task for future work
(which, probably, will never doing).
>>> BC> +#define putchar outc
>>> Why not use outc() explicitly?!
>> Why?
EA> of using a local define. Just a matter of style of course.
Not only "a matter of style" - this potential troublesome point,
especially outc() behavior isn't identical to putchar().
EA> Of course Arkady sometimes suggests peephole improvements which
EA> actually make code less readable, but it is still better to
EA> appreciate his comments and improve all problematic issues which
EA> he found. It is not mean personal / against you, it is only meant
EA> to make FreeCOM even better.
Yes!
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
