On Wed, Nov 4, 2009 at 4:06 PM, Patrick Horgan <phorgan1@gmail.com> wrote:
... An example of one of my least favorite avoidable warnings is when one part of boost moves an include file and deprecates the old location, and release after release, I have to look at warnings from other parts of boost. I can't even say what I think about that. I don't think a release should go out with issues like that. Boost should at least be internally consistent, and not have warnings about misusing other parts of boost. You'd think that would be the bare minimum to avoid looking like amateurs. How hard would it have been to fix for example, in 1.40 when I see hundreds of warnings from the graph stuff because: boost/property_map.hpp:15:4: warning: #warning "This header is deprecated. Please use: boost/property_map/property_map.hpp" I'm guessing the graph guys are used to ignoring warnings. But the code was released like this. That's embarrassing. There's probably 35 places they would have had to fix this so that hundreds of errors wouldn't spew out whenever someone used their code. They aren't even willing to grab the low-hanging fruit. There have long been other places where boost code used deprecated headers from the standard libraries. That's unprofessional. Sorry to rant. This is a long standing issue for me and I thought I better write this before I saw the inevitable responses from people trying to justify their bad coding. I really would have ranted then!
The result of this long discussion may well be a Boost policy on warnings. But it the meantime, you might want to open tickets against against libraries that are using long deprecated headers. --Beman