Win32 mkdir vs _mkdir

Question

On this page, Microsoft states that POSIX mkdir deprecated in favor of the "ISO C ++ Conformant" _mkdir . The same applies to other similar POSIX functions.

Do they mean obsolete in so far as they relate, or is there some kind of standards body (POSIX, ISO?) That did not approve of it?

In what respect is it more compatible with ISO C ++, and by what standard is it more compatible?

Unfortunately, I do not have access to the actual ISO C ++ standards, although I looked at the last freely available draft for C ++ 11 (N3337), and he did not mention the functions that I could see.

My reason is that I often call these functions POSIX, however I would prefer not to write code against outdated standards.

Answer 1

The outdated name is deprecated, not a function, and only in Visual Studio, not in POSIX.

Basically, the reason is that mkdir not defined as a function of the runtime library in the ISO C ++ standard, and it is expected that the functions of the non-standard runtime library will begin with an underscore. Accordingly, Microsoft added underscores to all non-standard function names in the runtime library. Most of them are POSIX-like functions, although there are a few specific ones for Windows.

The section of the standard that defines the identifiers reserved for use by the implementation is 2.10, paragraph 3. As far as I know, the standard does not explicitly indicate that the implementation cannot use other identifiers, but, apparently, this implies that such an implementation cannot create a legitimate C ++ program that will use the same name in an incompatible way.

In this particular case, this is true only if the program contains the appropriate headers defined for implementation, so I'm not sure that C ++ ISO really requires Visual Studio to reject the old names, but it looks like Microsoft either believed that it did, or that using reserved identifiers is best practice. (Or that the ability to compile a POSIX as-is source should be discouraged, take your choice!)

Additional note. I would suggest that a name conflict can also cause linking problems for more complex programs, even if the headers defined by the implementation are not included. However, it is not clear that function depreciation really helps in this case, since the old names are still present in the library. (They, however, are in a different .lib file and may be improving something.)

Here you can download the November 2014 working draft of the current ISO C ++ standard.