In message <20050130183325.M46945@crystalclearsoftware.com>, Jeff Garland <jeff@crystalclearsoftware.com> writes
On Sun, 30 Jan 2005 17:55:55 +0100, Terje Slettebø wrote
Because of this, Kevlin Henney and I was wondering whether or not MSVC 6 support for this component (and components in Boost in general) is no longer demanded, or in general, what the required conformance level is?
We've discussed this a number of times, but there is no 'boost-wide' policy. Some libraries have slowly started dropping VC6 support -- spirit comes to mind. Some authors (as I recall the Boost.Python folks) have a strong user base still using VC6 and don't want to cut it off. With date-time I've been taking the approach of attempting to maintain existing functionality, but new functionality that breaks VC6 is essentially simply marked. Even maintaining existing functions takes significant effort because of the VC6 fragilities. For example, someone recently reported that VC6 with STLPort and date-time creates an ICE.
Personally, I think the time has come to cut the cord on VC6 testing and compatability. In my mind Boost as a whole is being held back by the time Boost developers waste hacking apart their implementations and answering questions for this 7 year old, seriously non-compliant compiler. Perhaps the fact that we move on will spur some people to upgrade compilers, improving the life of a few c++ developers along the way (I suppose this also might increase sales in Redmond -- of course they already mention Boost on the VC7 packaging...). And the folks stuck with VC6 can always use older versions of Boost or test out new versions against VC6 for themselves, submit patches, or pay someone to do this work.
BTW, I have an interest in your decision b/c date-time depends on lexical_cast. So far whatever is breaking the regression tests doesn't seem to be affecting date-time...
My current thinking is that the lexical_cast incorporated in the next Boost release should retain VC6 compatibility. This release is primarily about fixing bugs and adding a couple of capabilities for common cases that are not currently accommodated. This will leave those who depend on VC6 with a stable version to fall back on. The next version would then break with VC6 compatibility to include a couple of generalisations, such as replacing full template specialisations and non-templated overloads with partial specialisations and templated overloads where those are more appropriate. Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________