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