On 6/7/2014 5:23 AM, Daniel James wrote:
On 7 June 2014 05:47, Edward Diener
wrote: On 6/6/2014 5:23 PM, Daniel James wrote:
On 6 June 2014 21:41, Edward Diener
wrote: Looking through code in MPL, and other long-standing libraries may be similar, the need to keep compiler workarounds in the code for compilers which are obsolete, or do not implement basic parts of even the C++ 98 standard, makes understanding and updating code fairly difficult in many cases. I believe that Boost has a right to say to those who still want to use some of these compilers with Boost that they will have to stick to previous versions. It really becomes difficult for a number of Boost libraries to move forward if they have to continually support poorly conforming compilers. As obvious examples I would not bother trying to support VC++ versions prior to VS2005/VC8 and I would not bother trying to support gcc versions prior to 4.0 etc.
It would be nice if you responded to what I wrote rather than what you imagined I wrote. The problem with the MPL changes was that they were non-trivial, and for a library which is very arcane (with or without workarounds), has little maintenance and a lot of dependants, some of which are unmaintained. Also, many of the dependants hadn't merged Stephen Kelly's changes (some still haven't) and it wasn't clear if it was safe to merge MPL before them. It was nothing to do with maintaining support for Visual C++ 7.0.
What does the quoted contents above have anything to do to what you wrote anywhere ? In other words my response was to a post by John Maddock and has nothing to do with anything you wrote on this thread.
It's do with what I wrote in objection to Stephen Kelly's changes to MPL, this would have been clearer if I hadn't cut my reply to the previous paragraph:
On 6 June 2014 21:41, Edward Diener
wrote: Based on Stephen Kelly's recommendations I actually removed a bunch of old workarounds in MPL for compilers which we don't support anymore. I even posted about it on this mailing list. But Daniel james objected to this being done for the 'develop' branch of MPL so I posted the change to a remote branch of MPL called 'remotes/origin/mfixes'.
I removed the quote and my reply because you clarified in your other mail that it was wrong:
On 6 June 2014 22:20, Edward Diener
wrote: I gave the wrong information. The changes were actually pushed on MPL to 'remotes/origin/SKChanges'. At one point there were in MPL 'develop' and having watched the regression tests I wanted to merge them into MPL 'master'. I believe Daniel James reverted them on 'develop'. My 'remotes/origin/mfixes' was something else related to testing clang on Windows with VC++ RTL.
In both emails you named me as the person objecting to changes.
Which was true, you objected to the changes and therefore I did not follow through by updating 'master' from those changes in 'develop'.
So, you're arguing for changes I reverted, and making clear that I reverted them. That does suggest that this what you're writing has a lot to do with my objections to them. If it didn't, why mention me twice?
I just mentioned what factually occurred.
The implication of your mail is that the changes were reverted in order to keep support for compilers such as Visual C++ 7.0, which is not true.
You are reading into my current replies to John Maddock and Peter Dimov things which are not there and then accusing me of not replying "to what I wrote rather than what you imagined I wrote". Please do not do that. I was not replying to you in either situation. I was just giving my opinion about supporting obsolete compilers in the first instance and factually giving information about MPL changes in the second instance. I did not offer criticism of you in either case.
This is what I wrote back in March:
On 20 March 2014 22:39, Daniel James
wrote: I think the best thing to do for MPL is to revert Stephen Kelly's changes, and put them on a branch so that they can be reconsidered later.
And indeed I put them on a branch and brought that to Peter Dimov's notice recently in reply to his current posts.
I'm not
saying they're bad - at the very least, removing support for old versions of Visual C++ is a good idea. But I think we need to sort out the libraries' dependants first. I'm going to try to start on some of these soon, but it'll take a while.