-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/03/2010 12:35 PM, Juergen Hunold wrote:
Thanks, I was hoping to get some help with that... bjam isn't exactly an easy tool to learn.
Yes, the learning curve is quite steep ;-)) Feel free to ask, I'm not a guru, but experienced users ;-)
A couple years ago I decided to try switching to bjam for all my projects, and I have ever since. But getting things working with it has never been easy, and I'm never sure that I've gotten things correct.
I'll take a look at your changes later today.
Thanks. I found that the split up "test_add" case is running into a deadlock. Please find the helgrind dump attached. The code in "set_generator" ist trying to lock the mutext which is already locked in the constructor.
That makes sense, the test_add case wasn't designed to be split up. The changes that I'm planning will take care of that problem though.
By the way, why is "random_by_size" a class member ? A far as I can see it could very well be a free function.
:-? I'm not sure what you mean. It *is* a free function... or three, if you include nothrow_random_by_size and fixed_random_by_size. It would have been useful to make it a member function, since the three functions differ only in the types of their return values right now, but I didn't. Unless you're looking at a version of the library that I haven't written yet. ;-)
And I wonder about "return BOOST_XINT_MOVE(p);" instead of "return p;" and let the compiler optimise the return via NRVO...
Does NRVO work with emulated move semantics? I was under the impression that it couldn't, but I could well be wrong, Boost.Move is new to me. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvfAHUACgkQp9x9jeZ9/wQCsQCfYkqzYyCHjfec3ATVpK+gYPZ/ Z2gAnj5Qnd9mnD97DSZRqBa5aYhcuix+ =TVrL -----END PGP SIGNATURE-----