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? In the cases I've seen there is a safe alternative provided. In any case, there needs to be a Boost-wide solution for these problems. I'm seeing similar stuff in the date-time warnings for std::localtime, etc. Some of these have translated into are actual date-time test failures because they tightened up what they allowed in a tm struct. In some previous email (as I recall on boost-testing) it appears they are going to backtrack on that, but my guess is their new implementation is technically within the spec -- so really it is a specification problem.
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. 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 ;-) Jeff