Jonathan de Boyne Pollard wrote in a message to Charles Gaefke:

 CG> JdeBP> It is uninformed, narrowminded, and foolish to think that the
 CG> JdeBP> _dos_x functions are "portable" or "generic".

 CG> I don't appreciate you referring to me as such.

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

I think you've gone too far in insulting the ppor guy.  There is no
portable way to access the file system to get a directory listing.  Even
POSIX compliance is pretty difficult in this particular situation.  As a
result, the only option for writing portable code to deal with this is to
write something specific to each platform and encapsulate it reasonably
well, using either conditional compilation in C or some more clever object
oriented mechanism in C++.  If the compiler does this for you and happens
to name the wrappers "_dos_xxxxx" then this may be as good as you
are going to get.

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

You are really just arguing the meaning of the word "portable." 
You have a valid point when you say that many compilers don't support these
wrappers, at least not in this form, but the compiler used in this case
(Watcom) does define them across all of its supported platforms.  Even on
compilers which do not support these particular wrappers, it would be easy
to write them.

 JdBP>   The _dos_XXXX functions are just the DOS API wrappers in
 JdBP> the Microsoft   C++ library.  Some other C++ compilers
 JdBP> provide functions of the same   name for "Microsoft C++
 JdBP> compatibility".  Some have their own DOS API   wrapper
 JdBP> functions.  Borland C++ for OS/2 has `findfirst', for
 JdBP> example,   which it also supports on OS/2 for "DOS
 JdBP> compatibility" -- that doesn't   make `findfirst' portable,
 JdBP> though, even though the situation is exactly   analogous to
 JdBP> `_dos_findfirst' in Microsoft C++.

Nearly all DOS C compilers support the Microsoft dialect, including both
Watcom and Zortech/Symantec which explicitly claim Microsoft C
compatibility, and even Borland since about Borland C++ 2.0.

 JdBP>   The fact that your particular C++ compiler supplies
 JdBP> functions of these   names on the above platforms doesn't
 JdBP> imply portability (since the   functions often have
 JdBP> different semantics on different platforms,   depending from
 JdBP> how well the platform in question can be bent to follow  
 JdBP> the DOS model), nor does it imply genericity (since it is
 JdBP> often the case   that the _dos_XXXX functions cannot handle
 JdBP> some features that are   supported by the native API, and
 JdBP> vice versa -- c.f. the "volume"   attribute for
 JdBP> _dos_findfirst that I mentioned in the last message, or  
 JdBP> the attribute masking provided by the OS/2 DosFindFirst
 JdBP> system API call). 

You would at least have to concede that any compiler which did not support
these wrappers could be made to do so with trivial effort as long as the
underlying platform could, and it makes no difference what you do if the
underlying platform cannot.

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

Obviously true, but what alternative is there in this case?

 JdBP>   I detailed three specific advantages of using the
 JdBP> operating system API   directly, instead of via the DOS API
 JdBP> wrapper functions, which you have   cut out of the above
 JdBP> quote, and showed that there was no loss of   supposed
 JdBP> "portability" or "genericity" in doing so,
since the DOS API
 JdBP>   functions weren't portable or generic in the first place. 
 JdBP> If you   disagree, give specifics.

 JdBP>   Why do you disagree that using DosFindFirst provides
 JdBP> performance   advantages by reducing the number of system
 JdBP> calls required to scan a   directory ?  Why do you disagree
 JdBP> that using DosFindFirst provides   performance advantages by
 JdBP> allowing attribute masking to be performed in   the
 JdBP> filesystem driver rather than in your code (allowing such
 JdBP> processing   to be performed remotely on a fileserver, for
 JdBP> example) ?

Admittedly, it is certainly possible that the native OS/2 approach would
have performance and efficiency advantages.  However, it is also possible
that the compiler could implement the wrappers in such a way as to cache
the directory when running on OS/2, and this would make the wrapped version
effectively as fast and efficient as the native approach.  You could extend
your reasoning to argue against fopen() instead of DosOpen(), fread()
instead of DosRead(), and so on.  Assuming that Watcom implements the
wrappers competently, then the use of the wrappers is "portable"
across platforms if not across compilers.  This may be entirely
satisfactory for the particular job at hand, although your technical points
are entirely valid and correct.
 
-- Mike


---