Re: [boost] [iostreams][vc8]deprecetedstandardlibrarymemberfunctions; fatal linker error

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-07-02 13:57:48

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