[Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...

...

On 09/27/2010 02:40 AM, Daniel James wrote:

...

On 26 September 2010 18:43, Olivier Bertrand wrote: It looks like this change broke Boost.Config on VC6:

https://svn.boost.org/trac/boost/changeset/61434

If that's true then very little of Boost 1.44 will work on that compiler, since almost everything depends on the config headers. Is it worth fixing? Something like this was inevitable once testing stopped.

Looks like that change was made 5 months ago and nobody noticed until now.

...

On Thu, Sep 30, 2010 at 3:11 PM, Marsh Ray wrote:

...

As a long time Boost user (yes, even since the VC6 days) I suggest that Boost make an explicit policy change.

Not only should VC6 be deprecated, not supported, and otherwise ignored in Boost, but all its vestigial compatibility workaround code should be actively ripped out!

It's largely clutter at this point, and these breaks are evidence that it's poorly maintained and not used or tested much either. A dangerous breeding ground for bugs.

This is when somebody raises their hand and says "But I need VC6 because it's the only way I can build something for these military embedded WinCE98 things we're still contractually obligated to support for another 13 years". We should all be very sympathetic, but that application should probably stay on the last Boost release that works for them.

Just think how much fun it will be to grep for those VC6 macros and submit all those negative-LoC patches!

On 01/10/2010 8:15 PM, OvermindDL1 wrote:

...

Also speaking as a user of Boost since using VC6, +1 VC6 was such a horrible system, so much code could be cleaned up if its support were stripped out.

Now, we needn't speak ill of the dead. VC6 was great in a lot of ways, e.g., compared to what came before it. However, the fact that MS has completely stopped supporting it means that security bugs in some of the runtime libs may not be getting patches. To continue to support the use of such a product could be complicit in producing insecure systems. On 10/01/2010 09:27 PM, Damien Hocking wrote:

From experience with other C++ projects that required long-term support, dropping VC6 removed a lot of nasty special-case code. It supported writing broken C++. VC6 is now 12 years old, and the updated, compliant Visual Studio Express is free for the 32-bit Windows platform and VC6 never did 64-bit anyway.

The platform SDK compiler is sometimes pretty decent, too.

+1 to dropping it.

Well, this thread is on the users' list. I would think that the developers on the codebase would like this more than anybody. As a developer on (other stuff) myself, I also know how reluctant I am to take away any functionality at all that some user somewhere may be depending on, at least without a good reason. So one tends to error on the side of not changing anything, lest you have no justification for the occasional minor accidental build bug. It may be that all they need is a representative group of users to make a clear statement of preference. Not a demand or anything, just "preemptively endorsing" an easy improvement they've probably been wanting to do anyway. With users on board, it could just be a Boost code policy statement to empower developers to remove the VC6-specific cruft as the opportunity arises. I find that the dead stuff obscures and distracts from the relevant stuff and sometimes makes it a little harder to figure out what's going on. Troubleshooting some of these type system errors leaves me with little brainpower to spare! If the code doesn't get a little spring cleaning once in a while, the dead wood will just builds up more and more over time. A codebase as big as Boost could probably have a ongoing minor project for dusting and vacuuming. Heck, maybe there's some magic preprocessor that can do much of it automatically. Of course, if anyone has a real objection (perhaps unlikely at this point) they can share it here. Let's collect simple "+1"s from the user community on this thread and then ask nicely on the dev list. - Marsh