[range] broken PTS work-arounds
Boost.range has a pile of work-arounds that made it "work" on old compilers that don't do partial template specialization. Nobody is testing those compilers anymore, so it's not surprising that those work-arounds are now broken. To wit, the following program: #include <boost/range/iterator_range.hpp> int main() {} fails to compile on VC6. If nobody is interested in these old compilers, fine. But it seems odd to be shipping work-around code that doesn't work. Should all the PTS work-around code be removed? Or can it be patched up without too much effort? I don't care either way, I just don't want broken code to be shipped. -- Eric Niebler Boost Consulting www.boost-consulting.com
Hi, On Sun, Nov 18, 2007 at 12:29:16PM -0800, Eric Niebler wrote:
Boost.range has a pile of work-arounds that made it "work" on old compilers that don't do partial template specialization. Nobody is testing those compilers anymore, so it's not surprising that those work-arounds are now broken. To wit, the following program:
#include <boost/range/iterator_range.hpp>
int main() {}
fails to compile on VC6. If nobody is interested in these old compilers,
I tried to compile all headers using a g++ 4.3 snapshot and noticed no problems except: boost/range/mfc.hpp: error: afx.h: No such file or directory boost/range/atl.hpp: error: atldef.h: No such file or directory boost/range/sub_range.hpp: error: missing binary operator before token "(" The last error is fixed by including <boost/detail/workaround.hpp>. The first two include header files I do not know and probably belong to a non-free system I would never use. I suggest to test for this stupid system (if my assumption is true) to get proper error messages. Jens
Jens Seidel wrote:
Hi,
On Sun, Nov 18, 2007 at 12:29:16PM -0800, Eric Niebler wrote:
Boost.range has a pile of work-arounds that made it "work" on old compilers that don't do partial template specialization. Nobody is testing those compilers anymore, so it's not surprising that those work-arounds are now broken. To wit, the following program:
#include <boost/range/iterator_range.hpp>
int main() {}
fails to compile on VC6. If nobody is interested in these old compilers,
I tried to compile all headers using a g++ 4.3 snapshot and noticed no problems except:
<snip> Please don't hijack my thread. Your post is not in response to mine. You should start a new thread. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Boost.range has a pile of work-arounds that made it "work" on old compilers that don't do partial template specialization. Nobody is testing those compilers anymore, so it's not surprising that those work-arounds are now broken. To wit, the following program:
#include <boost/range/iterator_range.hpp>
int main() {}
fails to compile on VC6. If nobody is interested in these old compilers, fine. But it seems odd to be shipping work-around code that doesn't work. Should all the PTS work-around code be removed? Or can it be patched up without too much effort? I don't care either way, I just don't want broken code to be shipped.
I'm of the opinion developers should start to remove workaround code that isn't being tested anymore, particularly if it makes the source code harder to read and maintain. But to me that is something that should happen over time, not something worth stopping the 1.35.0 show for. --Beman
on Sun Nov 18 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Eric Niebler wrote:
Boost.range has a pile of work-arounds that made it "work" on old compilers that don't do partial template specialization. Nobody is testing those compilers anymore, so it's not surprising that those work-arounds are now broken. To wit, the following program:
#include <boost/range/iterator_range.hpp>
int main() {}
fails to compile on VC6. If nobody is interested in these old compilers, fine. But it seems odd to be shipping work-around code that doesn't work. Should all the PTS work-around code be removed? Or can it be patched up without too much effort? I don't care either way, I just don't want broken code to be shipped.
I'm of the opinion developers should start to remove workaround code that isn't being tested anymore, particularly if it makes the source code harder to read and maintain.
I may start to test vc6 again soon, but I am not claiming that should hinder Boost in its overall transition away from supporting it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Eric Niebler wrote:
#include <boost/range/iterator_range.hpp>
int main() {}
fails to compile on VC6. If nobody is interested in these old compilers, fine. But it seems odd to be shipping work-around code that doesn't work. Should all the PTS work-around code be removed? Or can it be patched up without too much effort?
It seems easy to be patched. (You can install free evc4 if you want a free vc6 compiler.) Well, I guess Eric is angry because Boost.Foreach doesn't compile with vc6. I too am anxious because msvc-7.1 regression results are invisible. Regards, -- Shunsuke Sogame
shunsuke wrote:
Eric Niebler wrote:
#include <boost/range/iterator_range.hpp>
int main() {}
fails to compile on VC6. If nobody is interested in these old compilers, fine. But it seems odd to be shipping work-around code that doesn't work. Should all the PTS work-around code be removed? Or can it be patched up without too much effort?
It seems easy to be patched. (You can install free evc4 if you want a free vc6 compiler.) Well, I guess Eric is angry because Boost.Foreach doesn't compile with vc6. I too am anxious because msvc-7.1 regression results are invisible.
Oh, I'm not angry. It's true, I discovered the problem by doing my once-yearly testing of foreach on vc6, but if we decide to drop vc6 support, I won't shed a tear. If someone submitted patches for vc6/evc4, that'd be nice and I bet Thorsten would appreciate it. <nudge> Beman hit the nail on the head. It's probably time to start phasing out the old work-around code, but I agree it's not critical for 1.35. You're right about msvc-7.1 results, though. It's a release compiler, and we have no test results for it. Hrm. -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (5)
-
Beman Dawes -
David Abrahams -
Eric Niebler -
Jens Seidel -
shunsuke