Subject: Re: [boost] [function] new implementation
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2010-10-30 21:54:29
> "Hartmut Kaiser" <hartmut.kaiser_at_[hidden]> wrote in message
> > That looks promising. Therefore, I tried to replace boost::function
> >with your new implementation. Everything compiled fine but things got
> >ugly when I was running my applications. I was seeing unexpected
> >exceptions from apparently empty function object instances. I little
> >investigation brought up the following. The code failing is roughly
> > Apparently, the code above works just fine as long as everything is
> >compiled into a single executable, but it starts failing if A::call()
> >is implemented in a separate shared library (this problem is probably
> >limited to Windows platforms as well, as there each module gets its
> >own instances of static data members).
> Hi, thank you very much for testing and providing such good feedback!
> You are completely right in detecting and identifying the culprit...This
> is a new issue inherent to implementations that use on-empty
> handlers/targets instead of the if-empty-then checks.
> I've fixed my implementation which you can grab again from the sandbox
> (the vault still has the old one). The new implementation has only
> slightly more expensive (public) empty() and (private, rarely used)
> vtable::move calls but it should now work even in the across-shared-
> modules-boundaries use case you described.
> I ran regression tests with VC10 and now all of them pass cleanly, i.e.
> the assertions in Program Options are gone...and thanks to your feedback
> now I know what caused them...the tests used DLLs (causing exactly the
> behaviour you described) when run by the automated regression tests
> procedure and did not use them when run straight from the IDE...so once
> again thanks for very useful feedback ;-)
> ps. I hope I did not break anything for other compilers...did not have the
> time now to run tests for them also...
Thanks for the fix! Everything seems to work now (VS2010, 64 bit, I have not
tried any other compiler, though). Great news.
> > in a separate shared library (this problem is probably limited to
> > Windows platforms as well, as there each module gets its own instances
> > of static data members).
> Shouldn't the same hold for .dynlibs and .sos?
That depends on the system. I believe on Linux (.so) it would have worked.
> "What Huxley teaches is that in the age of advanced technology, spiritual
> devastation is more likely to come from an enemy with a smiling face than
> from one whose countenance exudes suspicion and hate."
> Neil Postman
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk