
Douglas Gregor wrote:
On Feb 20, 2006, at 12:22 PM, Lars Gullik Bjønnes wrote:
We se some strange problems with GCC 4.1 (the prerelease/release candidate) with use of boost::signal and boost::bind. Have anyone run the regressions tests for this GCC version?
g++ (GCC) 4.1.0 20060219 (prerelease
We get errors of this form: [snip] <gcc41-1.diff>
Any opinions on this?
Hmmm, I'm surprised that patch fixes the problem.
Is it something strange hidden in our code, boost or a real regression in gcc?
There is definitely a bug in Boost.CVS. However, I didn't think that GCC 4.1 should be susceptible to the bug; I remember fixing this bug for GCC 4.0.1, and it works there. So we might actually have two bugs; I really don't know
The Boost bug is an interaction between the storage optimizations that went in to Bind (to make the storage optimizations of Function actually useful) and the visit_each mechanism.
You're mixing these up. The bug in this thread is present in 1.33.1 which doesn't have the storage optimization. It only shows up on proper two-phase lookup compilers because the primary declaration of visit_each wasn't #included.
I've taken a stab at a fix (to Bind) that seems to solve the problem for me on GCC 3.3; it should solve the problems on other compilers as well.
Attached is a patch to bind and a test case that illustrates the problem. Peter, could you take a look?
The patch seems good to me. There are several things that I don't like in the test, though; (a) it doesn't actually test anything, (b) it uses boost/test instead of lightweight_test.hpp, (c) it binds std::plus<> with one argument, which is invalid and can be rejected by a conforming bind. I tried to fix it, but an interesting question has come up. The primary visit_each is defined as: template<typename Visitor, typename T> inline void visit_each(Visitor& visitor, const T& t); By forcing a const qualification on the visited object, this interface prevents a visitor from mutating it (in addition to breaking when a function is being passed for t.) Is this deliberate or accidental? I've also found bind_visitor.cpp. Looks like it expects a certain number of visitations, though, so the storage optimization will break it either way. Anyway. Could you please look at the attached test case and confirm that it passes with your patch applied?