CG>
  > JdeBP> It is uninformed, narrowminded, and foolish to think that the _dos_x
  > JdeBP> functions are "portable" or "generic".
 As the name suggests, they a
  > JdeBP> *DOS* functions, and are provided with DOS C++ compilers as wrappers
  > JdeBP> the DOS API (which can only be accessed directly using assembly
  > JdeBP> language).
  >
  > I don't appreciate you referring to me as such.
CG>

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

CG>
  >   > It also states this is for DOS, Windows, Win386, Win32, OS/2 1.x(al
  >   > OS/2-32(DOS/PM).
  >
  >     That leads me to believe it IS portable.
CG>

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

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

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

  The library functions that are marked as "ISO Standard C" (a.k.a.
  "ANSI") are the only ones that are likely to be generic and portable
  (and even then there are some tricky caveats with implementation defined
  behaviour).  Other library functions, such as the common strdup()
  function, _might_ be portable and generic, simply because they don't do
  much that is platform-dependent anyway.

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

  It's very common for a C/C++ compiler to be misleading about portability
  issues, not least (I suspect) because portability is a sales point.
  It's also equally common for "DOS compatibility" to be confused with
  portability, especially by programmers coming from DOS, who have yet to
  escape the mental straitjacket of "DOS think".

CG>
  > JdeBP> So instead of _gaining_ from stubbornly sticking to the old DOS
  > JdeBP> wrapper functions, you are in fact _losing_ by doing so.
  >
  >     No I am not.
CG>

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

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

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01