- Boost - lists.boost.org

[serialization] working around the pointer_conflict exception?
by T. Farago 01 Sep '09

01 Sep '09

I have implemented the serialise library of BOOST to my own classes. Using a single entry point it recursively goes through every member and saves the values. Of course initial implementation yielded the pointer_conflict expression as for example while going through objects A,B,C object A may have a pointer to B, and only afterwards is B actually saved. I tried - and thought - to fix this by using a two-phased approach. First I save all the actual objects from the entry point, secondly only the pointers. eg save_objects = true; ar & my_object; save_objects = false; ar & my_objects; and inside every class: class A { public: int a; int *b; serialise() { if (save_objects) { ar & a; } else { ar & b; } } }; This seemed sound but only during debugging did I realise that the second run of the serialiser doesn't do anything since my_object is already saved. So this won't work. Does anyone have better ideas on solving this problem, or has encountered and already solved this issue? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

2 2

Boost Polygon library Review
by Kai Benndorf 01 Sep '09

01 Sep '09

Dear developers, we are currently evaluating the boost polygon library as a possible replacement for our currently used package for polygon boolean operations. Because the review process is soon at an end i want to inform you of our experiences so far. For short, i vote for inclusion of the polygon lib into boost. We are evaluating it in the scope of an analysis tool out of the EDA field. One task in this tool is to determine overlays of copper planes on a pcb. For this we need the plane intersection functionality. We have integrated the boost polygon lib currently to use it in parallel to our old library. Up to now we have found no errors in the calculated plane intersections, and there are some quite complicated planes, with complicate holes on the test pcb. This is very promising and the results seem to be reliable. We used the library on Windows XP, MSVC 2008, only. No compilation problems occured. Double vs. integer coordinates. Our planes are described with double coordinates in mm. We convert them for the boost polygon lib to integer by multiplying them with a constant factor. A first try with an factor of 1e5 leaded to an error (overflow?). With a factor of 1e4 this error vanished. Our first approach was to use the polygon and polygon with hole classes provided by the library and copy our coordinates into them. It works, but the creation of the objects with the set( itBegin, itEnd) functions was really slow, especially for copying the holes into the polygon. Our current approach is with some own intermediate polygon and polygon with holes classes, which allocates the necessary memory on creation. This is a lot faster and is really usable. A third and still better approach would be to use the same polygon classes as in the rest of our application, but i postponed this for now. The performance seems to be slower than our old library, but this is not really evaluated yet, there can e.g. still be conversion penalties. The documentation was sufficient enough to integrate the library in our application, but surely can be better. Because i'm not experienced in such an extensive template usage as it is done in the polygon lib, i omit comments about the design of the library. But at least it proved, that it can really be used to work reliable on external polygon objects. Best regards Kai Benndorf

2 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

[GSoC] Boost.Python py3k support project final report
by Haoyu Bai 01 Sep '09

01 Sep '09

Hi, As GSoC is officially finished, this is the final report of the Boost.Python py3k(Python 3) support project. The goal of this project is to provide seamless support for Python 2 and 3 in Boost.Python. So extension modules using Boost.Python can be easily migrated to Python 3. The SVN branch is located at: https://svn.boost.org/svn/boost/sandbox-branches/bhy/py3k/ Status ===== Currently, all the BPL test cases passed when running under Python 3, and there are almost no change for most of the test cases. To support the Python 3 unicode string, some of the default converts between PyString and C/C++ strings are changed to convert between PyUnicode and C/C++ strings. Support for py3k in Boost.Build is done. Also, a piece of document is written in the "News" part of BPL document. API Changes ========== There are some minor API changes: 1) Introduced object.contains where x.contains(y) is equivalent to Python code y in x. Now dict.has_key is just a wrapper of object.contains. 2) When building against Python 3, str.decode will be removed. 3) When building against Python 3, the original signature of list.sort, which is: void sort(object_cref cmpfunc); will change to: void sort(args_proxy const &args, kwds_proxy const &kwds); This is because in Python 3 list.sort requires all its arguments be keyword argument. So you should call it like this: x.sort(*tuple(), **dict(make_tuple(make_tuple("reverse", true)))); // This is equivalent to the Python call x.sort(reverse=true) 4) When building Boost.Python against Python older than 2.6, the following macros will be defined in Boost.Python header: # define Py_TYPE(o) (((PyObject*)(o))->ob_type) # define Py_REFCNT(o) (((PyObject*)(o))->ob_refcnt) # define Py_SIZE(o) (((PyVarObject*)(o))->ob_size) These are macros defined in Python >=2.6 header. We defined for Python < 2.6 so when you are using Boost.Python, these macros will be always available. Please refer to PEP 3123 (http://www.python.org/dev/peps/pep-3123/) for details about these macro. Building and Testing =============== To build Boost.Python with Python 3, first write your user-config.jam contains these line: using python : 2.6 ; using python : 3.2 ; where the "2.6" and "3.2" should be replaced by the actual version of Python 2 and Python 3 on your system, respectively. Then call "bjam", it will build out a "libboost_python.so" and a "libboost_python3.so". The latter one is the Boost.Python library built against Python 3. To run test cases against Python 3, what you need to do is to switch into the libs/python/test, then run: bjam python=3.2 It will automatically call the "2to3" tool to convert the Python source code in test case to Python 3 syntax. So we only need to maintain the test cases in Python 2. Further Works =========== I'm going to merge the py3k branch back to trunk. After the merge, more tests can be done to check is there any regression, also some people may want to start to use it to make your projects run on Python 3. Then I can get some bug report and feedback, thus more improvement is expected. Thanks! -- Haoyu BAI School of Computing, National University of Singapore.

2 1

[polygon] examplefile compilation failed
by Joachim Faulhaber 31 Aug '09

31 Aug '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

factory.hpp missing
by Felipe Magno de Almeida 31 Aug '09

31 Aug '09

Hi, AFAIK, the functional/factory.hpp was accepted in boost a long time ago. But never seem to have made into svn. Does anybody know why? Regards, -- Felipe Magno de Almeida Sent from my Nokia E71

2 1

Re: [boost] Proposal: MapReduce library (single machine)
by Mateusz Berezecki 31 Aug '09

31 Aug '09

Hi , I've just joined this mailing list because of this particular discussion :-) >> 2) have a plan so that the library can eventually range from >> working on 1 multi-core system to distributed >This is the eventual goal, and I have designed the library to be extensible >to be able to do this in the future. With the policy based designed, making >use of the open source projects that you mention should be non-intrusive; >the library allows the user to supply a handler for the intermediate files >(to use kosmosfs or hypertable, for example) I'm going to give it a spin as it happens I'm already having a half-baked distributed backend lacking a mapreduce library for both hypertable and KFS and report back. But this is interesting! Can't stop thinking about it now :-) best, Mateusz

2 1

Help with Boost Preprocessor
by Emil Dotchevski 30 Aug '09

30 Aug '09

Let's say I have a class template functor like this: struct func { typedef void result_type; template <class A1,class A2,class A3> void operator()( A1, A2, A3, int x ) { } }; Given a list of types, I want the function instantiated and called for all permutations of the types in the list; the additional argument(s), x, just need to be forwarded the same for all instances. Actually I got it working, see http://codepad.org/tnYTy9Iw. I don't think that my solution is very good though. First, it has some run-time overhead due to the use of boost::bind in fwd1 and fwd2 (see link above.) Second, I'd like the macro that defines the type list not to be hard-coded in fwd1 and fwd2. Is this possible? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 7