Re: [boost] [function] new implementation

Subject: Re: [boost] [function] new implementation
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-10-30 21:06:11

"Hartmut Kaiser" <hartmut.kaiser_at_[hidden]> wrote in message 
news:00b201cb7857$9a5d1330$cf173990$@gmail.com...
> 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 this:
>...snip...
> 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...

> 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?

-- 
"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