[Boost-users] Supporting Visual Studio 6 in boost
Mathieu Malaterre
This is not exactly a user question, but I was wondering if a couple
of boost developers could comment on the support of VS6 in boost.
How much time consuming is it ?
Are there plan to actually drop it at some point ?
Were there cases where you had to provide a duplicate implementation
(partial specialization, template template parameter, SFINAE...) with
slight modifications, therefore making the boost code more difficult
to maintain ?
How much did this compiler impact the design of boost API / internals ?
Thanks for comments,
--
Mathieu
Ps: I know there are other buggy compilers out there that are also
'supported', feel free to also add comment for another difficult to
support compiler.
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Doug Gregor
On Dec 11, 2007, at 4:51 AM, Mathieu Malaterre wrote:
> This is not exactly a user question, but I was wondering if a couple
> of boost developers could comment on the support of VS6 in boost.
> How much time consuming is it ?
At one point, it was extremely time-consuming for me, taking up about
1/4 of the time I spent implementing Boost code. Things have gotten
better recently, because I've been ignoring VC6 for new features and
trying to avoid touching any code that is intended to work on VC6.
> Are there plan to actually drop it at some point ?
We dropped VC6 support in the Graph library one or two releases ago.
(Yay!)
I have no plans to drop support for it in other libraries, but I
won't be supporting it in new libraries.
> Were there cases where you had to provide a duplicate implementation
> (partial specialization, template template parameter, SFINAE...) with
> slight modifications, therefore making the boost code more difficult
> to maintain ?
Oh, sure. Some libraries have completely different implementations
for VC6 (e.g., tuple), whereas others have been twisted horribly to
deal with it (Graph).
> How much did this compiler impact the design of boost API /
> internals ?
That's two different questions with two very different answers. We've
pretty strongly resisted any changes to the Boost API to accommodate
broken compilers (of which there are many; VC6 is just the most
popular broken compiler). But lots of developers have mangled the
internals of their libraries to get around compiler (and language)
limitations. In some cases, the latter is more problematic: anything
using the Preprocessor library, for example, is completely and
totally unreadable... but that's not the fault of any compiler.
- Doug
Nicola Musatti
>
> Hi there,
Hallo, Mathieu.
I've been involved in providing workarounds for the last couple of releases of
the Borland/CodeGear compiler, mostly for Boost 1.33.1 and 1.34.x .
[...]
> How much time consuming is it ?
In principle a lot, and it gets worse with every new release, as most Boost
developers are now using reasonably compliant compilers as their principal
development platform and have become accustomed to relying on the full
expressive power of C++, and rightly so.
> Are there plan to actually drop it at some point ?
I believe each developer is free to do as he/she wants, both in terms of
actively working on specific compiler support and in accepting patches for their
libraries.
> Were there cases where you had to provide a duplicate implementation
> (partial specialization, template template parameter, SFINAE...) with
> slight modifications, therefore making the boost code more difficult
> to maintain ?
No, because of lack of time and because I'm not the author of any Boost library.
This means that some libraries just don't work with older compilers. The next
release, 1.35, is going to raise the bar a lot as many libraries rely on SFINAE.
> How much did this compiler impact the design of boost API / internals ?
Speaking for the Borland one, it probably did for some libraries, such as Regex
and Serialization. This has probably been more of a factor with older libraries,
as some 5-6 years ago the Borland compiler was on a par if not better with both
VC++ and g++. However, being less popular than the other two, less effort was
spent in providing workarounds for its limitations.
Cheers,
Nicola Musatti