JD>   You'll note that I'm referring to the action, not the actor.  For the
JD>   reasons given in this and the last message, it _is_ uninformed,
JD>   narrowminded, and foolish.  And believe me, I've encountered enough
JD>   uninformed, narrowminded, and foolish people who hold these sorts of
JD>   DOS-centred beliefs to know.  (-:

    That statement makes you look like an all knowing individual, which you 
most certainly not.

JD>   Portability is not simply one library reference for one C++ compiler
JD>   saying that it provides a function of the same name on a selection of
JD>   different platforms.  A _portable_ function would be available on the
JD>   vast majority of C++ implementations.  I can name at least three major
JD>   platforms where _none_ of the C or C++ compilers have a _dos_findfirst
JD>   function.  I'm sure that Dave Noon and friends can name even more.  (-:

    To me, portability means being able to take MY code and make it run in an 
32-bit OS/2 native executable, 32-bit Win95 native executable, and 16-bit DOS 
native executable by compiling it on MY compiler.  That's all I care.  As I 
said in my last message (which it seems you did not read the full length of), 
my goal is to have code that'll work on all the platforms I intend to support.
I could do

#ifdef __OS2__
    (OS/2 specific code)
#else
    (all other code)
#endif

    but why bother?  My application is not catered towards the OS/2 community 
only.  I hate it when developers that make applications ONLY for one platform 
(such as a lot are doing with Win95).

JD>   Functions that "wrap" the API of a specific operating
system, such as
JD>   the _dos_XXXX functions, and that wrap them according to the conventions
JD>   of one particular C++ compiler, are highly unlikely to be portable and
JD>   generic, though.

    And, as I said before, the above #ifdef pragma could already be done by my
compiler.  I have no clue if it does or not, nor do I care.  It does what I 
want, and it does it VERY well.  Everyone who uses my application is astounded
by how fast it runs.  Therefore my compiler is creating excellent code from 
what I consider to be portable source.

JD>   I detailed three specific advantages of using the operating system API
JD>   directly, instead of via the DOS API wrapper functions, which you have
JD>   cut out of the above quote, and showed that there was no loss of
JD>   supposed "portability" or "genericity" in
doing so, since the DOS API
JD>   functions weren't portable or generic in the first place.  If you
JD>   disagree, give specifics.
JD> 
JD>   Why do you disagree that using DosFindFirst provides performance
JD>   advantages by reducing the number of system calls required to scan a
JD>   directory ?  Why do you disagree that using DosFindFirst provides
JD>   performance advantages by allowing attribute masking to be performed in
JD>   the filesystem driver rather than in your code (allowing such processing
JD>   to be performed remotely on a fileserver, for example) ?

    I explained myself before, and I reiterated it above.  I am not going to 
repeat myself again.


C. Gaefke
[lotl2{at}telerama.lm.com]
[CDRMail Author]

--- RG0511/CDRMAIL 1.06b