If you’ve worked with Visual Studio lately you’ve no doubt seen the warning about a standard POSIX system call (strcmp(), etc.) being “deprecated”.
Based on what I’ve been able to discover in various QA forums and discussions around the ‘net, it appears the MS is basically trying to discourage people from writing cross-platform code, and doing it in a most disingenuous way.
The problem isn’t that MS would prefer that people use their MS-specific calls rather than POSIX calls, since this is MS we’re talking about here that type of mentality goes without saying. What is wrong is the claim that a valid POSIX function is deprecated.
In any context outside of the MS world, this is a lie. Period. POSIX is very much alive and well, no matter how badly MS may want it to go away. If you work in an MS-only environment you might not be very familiar with POSIX, but it has been there for a long time now, and it’s not going to vanish any time soon.
By convention, implementation-specific names are marked with a leading underscore, so that’s a dead give-away right there that something fishy is afoot. Why would MS redefine an existing POSIX function like itoa()? It’s an industry standard, not something implementation-specific. Because they don’t want you to use it, of course, and by misleading programmers into using _itoa instead they have set the stage to point the call to their own run-time library functions. Personally, I think the end game plan here is to eliminate any support for the POSIX libraries and functions–less support costs in the compiler group, doncha know, plus developer lock-in. Win-win for MS. But that’s just a supposition on my part, I have no way to prove that.
In a posting on Google Groups P.J. Plauger wrote about this. Here’s an except:
“I’m the guy who insisted back in 1983 that the space of names available to a C program be partitioned into:
a) those defined by the implementation for the benefit of the programmer (such as printf)
b) those reserved to the programmer (such as foo)
c) those reserved to the implementation (such as _unlink)
We knew even then that “the implementation” was too monolithic–often more than one source supplies bits of the implementation–but that was the best we could do at the time. Standard C++ has introduced namespaces to help, but they have achieved only a fraction of their stated goals. (That’s what happens when you standardize a paper tiger.)
In this particular case, POSIX supplies a list of category (a) names (such as unlink) that you should get defined when and only when you include certain headers. Since the C Standard stole its headers from Unix, which is the same source as for POSIX, some of those headers overlap historically. Nevertheless, compiler warnings should have some way of taking into account whether the supported environment is “pure” Standard C++ (a Platonic ideal) or a mixed C/C++/POSIX environment. The current attempt by Microsoft to help us poor programmers fails to take that into account. It insists on treating unlink as a category (b) name, which is myopic.” (italics mine)
In my opinion, Plauger is being too nice about it. I may not like MS very much for various reasons, but those generally don’t have anything to do with their operating systems, at least not since they scooped up Dave Cutler and some other VMS folks from DEC and came out with NT (OS/2 was good, too, and I liked that a lot–but someone higher up the food chain had a tiff with IBM and it died on the vine). Other than OS/2, pure MS operating systems (if the pre-NT versions of Windows could even be called an OS) prior to NT basically sucked, but we should all know that by now, and I do give them points for at least trying.
So, no, it’s not about Windows, per se; I don’t like MS because of crap like this nonsense with “deprecated” POSIX calls. And COM, and OLE, and .net, but those are all different topics.
You can find a list of all the POSIX functions MS wants to deprecate here, which is basically everything a Unix or Linux programmer might use on a regular basis.
If you are working with cross-platform code then about the only options available to you are (a) put in ugly things like “#define itoa _itoa”, (b) put _CRT_NONSTDC_NO_DEPRECATE in the preprocessor definitions in Visual Studio, (c) ignore the pointless warnings, or (d) switch to either Windows or Linux exclusively, and use only MS-specific calls or POSIX, and forget about writing cross-platform code.
I don’t find any of these options acceptable, but I currently use option (b) just to get legacy Windows code to compile without pages of annoying warnings.
Since I’m now in a position to chart the course for all future software development efforts where I work, we’re going to switch everything over to Linux and Python, and be done with it. In my work environment there’s nothing that Windows can do that I can’t do just as well (or better) with Python and Linux. The user-interfaces written in Python will be inherently cross-platform, and Linux is a much cleaner and more streamlined programming environment with a long history of established industry standards and conventions behind it.
Not clear on what POSIX is and why it matters? Here are some links that might help: