From: David Abrahams (dave_at_[hidden])
Date: 2004-02-18 08:07:38
Bronek Kozicki <brok_at_[hidden]> writes:
> On Tue, 17 Feb 2004 16:03:11 -0500, David Abrahams wrote:
>> Might be a good idea. I think I'd like to continue to support vc6 at
>> least on the 1.31.x branch, particularly because last-minute changes
>> in the graph library broke Boost.Python on vc6 for 1.31.0
> If we agree to move in this direction, then in release 1.32 (or little
> later) we will be able to drop many workarounds from boost and simplify
> testing. But there is question that you raised:
>> What would we do about Borland, which is in some ways more broken than
>> vc6? They don't ship a compiler I wouldn't consider broken.
> I heard some voices that their new compiler being currently in beta (or
> maybe release candidate?) will be really close to standard. But we can
> be sure that old Borland compilers will still be widely in use, partialy
> due to lack of VCL support in this new compiler.
>> about GCC 2.9Xes, which are standard equipment on some widely-used
>> Linux distros? Way less broken than either of those two compilers,
>> but still way out-of-date...
> I would think that users of MSVC6, old Borland compilers or GCC 2.95 are
> "adoption blockers" and they possibly do not care much about new
> features in boost
Oh, but they do!
Lots of these people just want to use Boost to get a job done. They
don't give a flying hoo-hah what Boost itself needs to do to get *its*
For example, people from all over are picking up Boost.Python + Pyste
and expecting to be able to wrap vc6 code with it. These people have
every reason to want the same features I'd provide to everyone else
if I could find a few more minutes to work on the library ;-)
[The Python Windows distro is still built with vc6 (I don't expect that
to change soon), and the Python developers will tell you that if you
want to build reliable extension modules, you *have* to use vc6.
Depending on what you intend to do with these extension modules,
Another example: I'm sure vc6 users will care about unicode filename
support in the filesystem library when/if we supply it.
> (apparently they also do not care much about decent implementation
> of C++ standard library).
> Thus hopefully they will not mind if we just ask them to use
> releases in 1.31.x branch. But it also means that we will need to
> support two branches for (at least) next two years. This might be
> cumbersome, but on the other hand it should simplify development in
> "current" branch.
Yep. It'll be cumbersome, that's for sure. Would it be any better
than bringing in new "non-vc6" features with #ifdefs and new
non-vc6 libraries without apology?
-- Dave Abrahams Boost Consulting www.boost-consulting.com