August 2009 - Boost - lists.boost.org

Re: [boost] [serialization] Linker errors in trunk
by Hartmut Kaiser 09 Sep '09

09 Sep '09

> Sorry, resending as it ended up on the wrong list... > > ----------------------------- > > Since the latest changes in trunk I'm seeing linker errors while > linking with the serialization library (VS2005 SP1, > boost_serialization-vc80-mt-gd-1_40.lib): > > runtime_support.obj : error LNK2001: unresolved external symbol > "__declspec(dllimport) public: __thiscall > boost::archive::archive_exception::archive_exception(enum > boost::archive::archive_exception::_exception_code,char const *,char > const *)" > (__imp_??0archive_exception@archive@boost@@QAE@W4_exception_code@012@PB > D1@Z) > > (note the leading underscore in _exception_code) > > Which is really strange as this symbol is the only missing one. > > OTOH, the library exports the symbol: > > boost::archive::archive_exception::archive_exception( > enum boost::archive::archive_exception::exception_code, > char const *,char const *); > > (note the missing underscore in exception_code) > > If I change the first parameter of the archive_exception constructor to > be a 'int' everything builds fine. Ok, I solved it. The MS header file excpt.h has a #define exception_code _exception_code which leads to problems if not consistently included. Doh! What a mess. The bottom line is, that archive_exception.cpp needs to be compiled with exactly the same windows headers included (excpt.h gets included by windows.h) as any sources including archive_exception.hpp, which is generally not possible to ensure. The only fail-proof way I could see is to always have #if defined(BOOST_WINDOWS) #include <excpt.h> #endif inside archive_exception.hpp, globally mapping exception_code to _exception_code. Patch attached. Ok to commit? Regards Hartmut

4 9

Arbitrary precision arithmetic
by Scott Johnson 07 Sep '09

07 Sep '09

Greetings. This is my first post to the mailing list, so I'll try not to act stupid. :) The recent release of Boost (1.39.0), in the boost::rational library documentation, broadly hints at (and expresses a fond wish for) an arbitrary-precision integer ("bignum") library; however none currently exists within Boost. There are numerous such libraries out in the wild (many targeted towards C); though some of them are under incompatible licenses. (One interesting starting point would be libtommath, by Tom St. Denis; it appears to be a pretty robust and functional C library; which now has a C++ wrapper--albeit one that doesn't meet boost standards. It also contains numerous other useful number-theoretic functions, many of which appear to not be dependeing on the underlying bigint type. And it's in the public domain, or at least appears to be...) Searching through the mailing list, I've seen numerous references to creating such a thing, some of them dating back nearly ten years--but none yet seems to exist. This is something, I think, which would be Really Useful to add to boost. I wasn't able to locate any current boost project or proposal to create such a thing--though it's certainly possible I looked up the wrong keyword(s). So, my possibly impertinent newbie question: Is anyone (seriously) working on such a thing, for inclusion in boost? Are there any nasty (political) obstacles to such a thing being added? Thanks! -- engineer_scotty (no, not that one) If life gives you lemons, drink Hefeweizen

12 21

[ptr_container] Questionable strong guarantee of ptr_map::insert()
by Kazutoshi Satoda 05 Sep '09

05 Sep '09

Hi, With current implementation of ptr_map::insert(), if an exception is thrown, the objected pointed by the passed pointer is deleted. Is this really providing strong guarantee as documented? I understand strong guarantee as described here. http://www.boost.org/community/exception_safety.html > The strong guarantee: that the operation has either completed > successfully or thrown an exception, leaving the program state exactly > as it was before the operation started. I think ptr_map::insert() doesn't provide this guarantee because deleting the object is a change of the program state. As more concrete problem, see the attached code. I couldn't find any way to provide strong guarantee for delayed_inserter::insert_ready() using ptr_map. I want ready_value unchanged if an exception is thrown during the insertion. Looking for a solution on a similar situation, I found constructors of shared_ptr. Its documentation clearly says that "If an exception is thrown, delete p is called". And for auto_ptr version, it provides strong guarantee by taking the auto_ptr as non-const reference. I think ptr_map::insert() should follow this manner; document the deletion on exception for raw pointer version, and provide strong guarantee with insert(const key_type& key, std::auto_ptr<U>& x) . The the auto_ptr& version can be a better replacement of the raw pointer version. The required temporary of auto_ptr, instead of key_type, is more expressive (about the purpose of the temporary), and matches the Best Practices shown in the documentation of shared_ptr. http://www.boost.org/libs/smart_ptr/shared_ptr.htm#BestPractices But, introducing the auto_ptr& version seems to cause some change of behavior in client codes using the current pass-by-value version. Is it valid to request (create a ticket) for strong guaranteed (taking auto_ptr&) version while having this compatibility concern? Regards. -- k_satoda #include <memory> #include "boost/ptr_container/ptr_map.hpp" namespace ptr_map_insert_strong_guarantee_demo { class value { public: explicit value(int source); // ... }; class delayed_inserter { public: // ... // This is called from context that knows key and source of value, // but doesn't know the time of insertion. void ready_new(int key, int source) { // OK. // This implementation offers strong guarantee for this call. std::auto_ptr<value> new_value(new value(source)); ready_key = key; ready_value = new_value; } // This is called from context which doesn't know key and value, // but knows the time of insertion. void insert_ready() { if (ready_value.get() != 0) { // I want to offer strong guarantee for this call, // but boost::ptr_map deosn't provide the way to do that; // *** ready_value is deleted when an exception is thrown. *** map.insert(ready_key, ready_value); } } // ... private: int ready_key; std::auto_ptr<value> ready_value; boost::ptr_map<int, value> map; // ... }; }

8 17

wait-free fast-pathed, bounded-time, 100% starvation-free rw-mutex...
by Chris M. Thomasson 04 Sep '09

04 Sep '09

I was wondering if the following invention of mine might be of use to Boost: http://software.intel.com/en-us/forums/intel-threading-building-blocks/topi… (please __read_all__; thank you) Here are some performance numbers wrt my algorithm versus NPTL on Linux (fedora 10), and OpenSolaris: http://groups.google.com/group/comp.programming.threads/msg/3e7531657a11baf0 My invention has some very interesting properties that simply do not exist for 99% of all the other rw-mutex algorithms I have seen to date. It's 100% starvation free and has bounded wait time for readers and writers. Heck, even the Microsoft rw-mutex algorithm in Vista does not come close to that: http://msdn.microsoft.com/en-us/library/aa904937(VS.85).aspx They clearly state that their algorithm is not fair. The algorithm I have observed in OpenSolaris does not meet this goal as well. Another nice property is that the algorithm has wait-free fast-paths. If readers hit a fast-path, then they are going to get wait-free access to the protected data-structure. The same goes for writers. The underlying operation is a single atomic fetch-and-add operation: http://software.intel.com/en-us/forums/intel-threading-building-blocks/topi… In fact, the algorithm only needs fetch-and-add; no stupid CAS-loops are required. Please take not that there are absolutely no loops in the algorithm; this is one reason why it's bounded time and starvation free. Also, it has conditional reader-to-writer upgrades and non-conditional writer-to-reader downgrade capabilities. This is something that does not exist in the Microsoft implementation, or even the OpenSolaris, or basically any Linux implementation I have observed. Same goes for OSX. Therefore, I think this particular algorithm might be of use to Boost. Any thoughts? Thank you all for you're valuable time; I really do appreciate it! :^)

4 14

[date_time, Boost 1.40.0]
by Christoph 03 Sep '09

03 Sep '09

including boost/date_time/posix_time/posix_time.hpp or boost/date_time/gregorian/gregorian.hpp gives lots of warning for the following line(s): (boost/date_time/gregorian/conversion.hpp; posix_time, tooo) line 44 std::tm datetm = {}; // zero initialization is needed for extension members, like tm_zone I admit I don't understand the comment. Is it possible to fix that (correctly) such that including the header does not produce like 20 warnings in each .cpp file including the header? (I am using linux running gcc 4.1.2) Best regards Christoph

4 5

[pool] patch to make pool support zero sized allocations.
by Steven Watanabe 02 Sep '09

02 Sep '09

AMDG The patch at https://svn.boost.org/trac/boost/attachment/ticket/386/pool.patch allows the pool classes to support zero sized allocation, by returning a null pointer. std::vector sometimes allocates a zero sized block, so this is necessary for pool_allocator. Returning a null pointer is the simplest solution and I'm that the standard allows an allocator to return the null pointer when asked for a block of zero elements. Okay to commit? In Christ, Steven Watanabe

1 1

windows timeout implementation
by Gennadiy Rozental 01 Sep '09

01 Sep '09

Hi, I have windows timeout support implemented for boost::execution monitor. It requires multithreading and thus introduces additional dependencies. I am thinking of making it available with compile time flag. Any comments/suggestions are welcome. Gennadiy

4 4

[polygon] examplefile compilation failed
by Joachim Faulhaber 01 Sep '09

01 Sep '09

Hi Luke and polygonists! I had problems compiling the example files from the doc's main page with msvc-9. None of custom_p*.cpp examples compiled. Also the connectivity_extraction_usage.cpp example failed. (1) connectivity_extraction_usage.cpp: #include <boost/gtl/gtl.hpp> must be replaced by #include <boost/polygon/polygon.hpp> namespace gtl = boost::polygon; has to be added. (2) custom_point.cpp: compilation yields: 1>.\custom_point.cpp(75) : error C2757: 'gtl' : a symbol with this name already exists and therefore this name cannot be used as a namespace name 1>.\custom_point.cpp(77) : error C2143: syntax error : missing ';' before '<' 1>.\custom_point.cpp(77) : error C2913: explicit specialization; '::geometry_concept' is not a specialization of a class template and many errors more after replacing gtl:: by boost::polygon:: and namespace gtl { ... } by namespace boost { namespce polygon { ... } } and adding typedef int coordinate_type; to struct CPoint the code finally compiled. Are these examples intended to be excercises ;) HTH Joachim

3 6

C++ MapReduce performance - compared to C Phoenix
by Jose 31 Aug '09

31 Aug '09

I wanted to share some performance numbers to encourage others to write examples or applications using the C++ multi-core mapreduce library being developed by Craig H. I ran some tests comparing the C++ version to the C version, for the word_count example. The tests are run on a X86_64 linux Fedora 10 with 2 cores. The results below show that the C++ MapReduce (mr) has very similar performance to the C version (mr-c). The tests start running phoenix first. Run 3 and 4 show that c++ mr is slightly faster. When using 1MB MR_L1CACHESIZE (which should be the best comparison) shows that mr-c is a little bit faster but not much. 1-mr-c 0m18.077s 2-mr 0m13.818s 3-mr-c 0m14.828s 4-mr 0m14.148s 5-mr-c-1MB 0m14.006s 6-mr-c-2MB 0m14.084s Note: The C++ version uses a chunk size of 1MB while the C version uses by default a chunk size of 64KB (which can be changed with the variable MR_L1CACHESIZE) regards jose

1 0

Boost.MapReduce: what next?
by Craig Henderson 31 Aug '09

31 Aug '09

I am thinking now about how to progress my MapReduce library that is in the Boost SandBox. I have completed the single-machine implementation; it's performance is comparable to other libraries such as Phoenix (http://mapreduce.stanford.edu) and has been tested by a few people on this list. There has, however, been little interest in the library so far from Boost users/developers which surprises me. I don't know if that is because of the single-machine limitation and people don't see any value that MR can bring to multi-threaded programming? So where do I go next with the library? Options that I see are: 1. Complete the documentation and submit the current library to Boost for a formal review. I'm not clear there is sufficient interest, though. 2. Continue to develop the library in the sandbox to multi-machine implementation and work towards submitting that for formal review. Is there interest for this? 3. Accept that Boost is not an appropriate forum for a MapReduce library and find an alternative community to develop the library. Looking at the download figures from the Vault, there has been a reasonable number of downloads; Of course there is no way to tell the number of people looking at the sandbox implementation. Perhaps the library has some silent interest? Please let me know your thoughts. Thanks -- Craig Craig Henderson <http://craighenderson.co.uk/> http://www.craighenderson.co.uk http://www.siteupdatenotification.com

6 9