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

Subject: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?
From: Marsh Ray (marsh_at_[hidden])
Date: 2010-10-02 01:25:43

>>> On 09/27/2010 02:40 AM, Daniel James wrote:
>>>>
>>>> On 26 September 2010 18:43, Olivier
>>>> Bertrand<bertrandop_at_[hidden]> 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<marsh_at_[hidden]> 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