Jeff Garland wrote:
On Sat, 2 Jul 2005 10:41:00 -0600, Jonathan Turkanis wrote
Interestingly these API's aren't documented as deprecated in the SDK as far as I can see, so I wonder if someone just made a mistake?
I think it has to be a mistake to deprecate essential member functions without introducing replacements.
I haven't been following this thread closely, but are you saying there aren't some sort of safe replacements?
Apparently so. For many of the deprecated functions there's a recommended safe version with the _s suffix, and most of these are proposed for standardization (see, e.g., http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1055.pdf.) But in the cases I'm talking about, there seem to be no new 'safe' versions. In fact, it's hard see how there could be, since the existing functions already provide a buffer size parameter. For example, what would basic_istream::read_s look like?
It would probably be a good idea if someone would volunteer to give Microsoft's headers a once over and see if there are any other API's that are needlessly deprecated. Certainly there plenty of room for frustration here - I've seen deprecated warning from std::copy and other std lib algorithms (and no *not* using pointers), as well as the C API's.
Maybe they should just deprecate everything, to be on the safe side.
I really don't think we should disparage them for this effort. This is a beta , after all, and it's sort of the point of beta stuff to shake out these sort of issues. I've seen the cost of using some of these unsafe functions in big software systems. You can create incredibly subtle, and hard to find intermitant bugs by doing strcpy into stack-based buffers.
I'm not against the _s functions, by any means, and I'm willing to cut microsoft some slack in a beta product. But it looks like whoever sprinkled the __declspec's all over the place didn't have a clear idea what he was doing.
So the fact that Microsoft is trying to raise awareness and move things forward -- I find it hard to argue against this. This particular approach might appear 'heavy handed', but it has us talking ;-)
About the wrong issues, though ;-) Jonathan