Mathieu Malaterre
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