- Boost - lists.boost.org

counting_iterator<int>::difference_type
by Arno Schödl 13 Apr '10

13 Apr '10

Hello, I am sure this has come up a few times, but I could not find the answer in the archive. counting_iterator<int>::difference_type is __int64 by default. I understand the underlying rationale, but I am not sure whether it is the right choice given the existing practice of C/C++. The problem of int minus int overflowing is not restricted to counting_iterator. Still, C/C++ chose to make int minus int -> int, probably for performance reasons. So why shouldn't counting_iterator by default behave the same way? If someone needs something else, she can still override the default. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

2 1

[svn] request for commit permission
by Daniel Walker 13 Apr '10

13 Apr '10

Hello, I recently became the maintainer for Boost result_of. May I have commit permission on svn? Also, if I need to make an account, where do I register? Thanks! Daniel Walker

3 2

[iostreams] Cannot compile against zlib 1.2.4
by Lars Viklund 13 Apr '10

13 Apr '10

Hi list. zlib 1.2.4 was released in mid-March, reorganzing the sources a bit. They removed gzio.c and added in a bunch of new source files, something the Jamfile for iostreams does not particularly appreciate. I submitted a ticket [1] with a somewhat tested solution (remove gzio from the list of sources), but I have no idea whether it's the right way to solve it as I'm not aware of how the guts of zlib_compressor and friends work. How does one go forward with something like this, as I don't think I've seen much activity from the iostreams camp at all lately? It would be awfully nice to get some kind of fix into 1.43.0, as it currently prevents anyone interested in building zlib automagically via bjam from doing so. One thing I guess might get in the way is whether this should support older versions of zlib sources. In my opinon no, as this only applies to people who want to build from their own freshly unpacked zlib source tree, not affecting people who use prebuilt binaries from their distro or downloads. [1] https://svn.boost.org/trac/boost/ticket/4091 -- Lars Viklund | zao(a)acc.umu.se

2 1

VS2005 SP1 Hard Debugger Crash in Class Destructor with Boost.Filesystem
by Jack Yee 13 Apr '10

13 Apr '10

Hello, I have a very strange crash involving the use of auto-linking of the boost::filesystem (1.38/1.42) and putting breakpoints in a unmanaged class destructor. It crashes hard enough that the task must be stopped through the Task Manager. Below is the test case that causes the crash: #include "stdafx.h" #include <vcclr.h> #include "boost/filesystem.hpp" // Note 1 public ref class ClassOne { public: ClassOne() {} ~ClassOne() {} }; class ClassTwo { public: ClassTwo(ClassOne^ p) {one = p;} ~ClassTwo() {one = nullptr;} // Note 2 gcroot<ClassOne^> one; }; int _tmain(int argc, _TCHAR* argv[]) { ClassOne ^one = gcnew ClassOne(); ClassTwo *two = new ClassTwo(one); delete two; // Note 3 return 0; } Note 1 -- Commenting out this header and setting breakpoint at Note 2 will be OK Note 2 -- Putting a breakpoint here with "boost/filesystem.hpp" will cause VS2005 to crash Note 3 -- Putting a breakpoint here with "boost/filesystem.hpp" will be OK BUILD CONFIGURATION: * Common Language Runtime Support (/clr) enable * Preprocessor defines: WIN32;_DEBUG;_CONSOLE; * Standard include and library search paths to your Boost installation. Other Useful information: * Running the program without breakpoints doesn't indicate any errors or non-zero exit codes. * Tried both 1.38 and 1.42 boost libraries * Debugger crash does not happen under VS2008 * Same crash results on Windows XP Professional, Vista Business and Windows 7 machines. Event Viewer Output: Faulting application devenv.exe 8.050727.867, time stamp 0x45d2c842, faulting module OLEAUT32.dll, version 6.0.6001.18000, time stamp 0x4791a74f, exception code 0xc0000005, fault offset 0x00003e56, process id 0x8ec, application start time 0x01cadab2a1430262. Hopefully the example is concise enough that I can get some other willing people to try it out and see if they get the same results. Apologies in advance if there is a typo in the source code as the work machines are isolated from connecting from the Internet. Thanks! Jack

1 0

GSOC 2010 - BGL Graph Connectives.
by Tri Nguyen 12 Apr '10

12 Apr '10

Hi, I am Tri Nguyen from South Plains College. I am interested in Graph Connectives Project of BGL. In this writing, I would like to ask two questions, and then propose my idea of doing four Connectives: union, join, intersection, and difference. My first question is: How big is the graph? Or students will try to do as big as possible. My second question is: What type of data-structures (matrix or list) will be used? I attached my ideas in the PDF file below. Please have a look. I appreciate all responses, Thank you, Tri Nguyen.

4 15

GSoC2010 Sweepline Algorithm
by Andriy Sydorchuk 12 Apr '10

12 Apr '10

Hi, Boost Community! I am interested in participation in GSoC 2010. The project I liked the most is the generic implementation of Sweepline Algorithm. Basically fast and robust Sweepline Algorithm requires implementation of next data structure: 1) Event Queue (priority queue). 2) Sweep Line (self-balancing binary search tree). 3) Output datastructures (voronoi vertices, triangulation edges, etc.). Based on that I got next questions: - Which kind of self-balancing binary trees is better for that kind of approach? I am thinking about Red-Black Trees in prefer to AVL trees, as sweepline algorithm requires more adding and deletion operations. And AVL trees are better for look up operations. - STL library includes two generic implementations of self-balancing binary trees (red-black): map, set. I am quite new with Boost library, but probably there are some more specific self-balancing binary tree implementations there? - For Voronoi diagram and delaunay triangulation input data is set of points. What about input of the Medial Axis problem? -- Best, Andrii Sydorchuk

4 33

[BGL] Revisiting Parallel BGL
by Sandeep Gupta 12 Apr '10

12 Apr '10

Hi, I raised the issue of parallel BFS not working correctly here http://lists.boost.org/boost-build/2009/10/22631.php. The issue remained unresolved. I revisited it for last two days and the incorrectness in likelihood is probably due to initialization of distance property map for all non-start vertex to be infinity. Hope this helps. Thanks Sandeep

3 17

How to use mutable_queue with non basic types
by Emili Hernàndez 12 Apr '10

12 Apr '10

Hi all, I've used mutable_queue with basic types (double and int) with no problem. Now I trying to do it with my own type: typedef MyObject entry_t; typedef vector<entry_t> storage_t; typedef MySortingCriterion comp_t; typedef boost::identity_property_map prop_map_t; typedef boost::mutable_queue<entry_t, storage_t, comp_t, prop_map_t> queue_t; queue_t Q(100, comp_t(), prop_map_t()); The definition compiles ok but when I perform an operation such Q.push(obj) //MyObject obj The following errors appear: C:\boost\boost_1_42_0/boost/property_map/property_map.hpp: In function 'Reference boost::get(const boost::put_get_helper<Reference, PropertyMap>&, const K&) [with PropertyMap = boost::typed_identity_property_map<unsigned int>, Reference = unsigned int, K = boost::shared_ptr<CAStarNode>]': C:\boost\boost_1_42_0/boost/pending/mutable_queue.hpp:94: instantiated from 'void boost::mutable_queue<IndexedType, RandomAccessContainer, Comp, ID>::push(const IndexedType&) [with IndexedType = boost::shared_ptr<CAStarNode>, RandomAccessContainer = std::vector<boost::shared_ptr<CAStarNode>, std::allocator<boost::shared_ptr<CAStarNode> > >, Comp = astarnode::SGreater, ID = boost::typed_identity_property_map<unsigned int>]' ..\CAStar.cpp:62: instantiated from here C:\boost\boost_1_42_0/boost/property_map/property_map.hpp:318: error: no match for 'operator[]' in '(const boost::typed_identity_property_map<unsigned int>&)((const boost::typed_identity_property_map<unsigned int>*)(& pa))[k]' C:\boost\boost_1_42_0/boost/property_map/property_map.hpp:553: note: candidates are: T boost::typed_identity_property_map<T>::operator[](const T&) const [with T = unsigned int] It seems the problem is with property_map. Anyone knows how to solve it?? Thank you very much, Cheers, Emili

2 4

[GSOC] summary of .BigInt library details.
by Ankit Malpani 12 Apr '10

12 Apr '10

hi all, thank you Scott McMurray, Vicente and Bruno for the prompt feedback regarding my proposed BigInt library ideas .(Sorry for the delayed reply as was busy with mid-semester exams.) In general this is what i have gathered from your responses regarding what exactly is being expected by the community from a BigInt library for Boost. 1. frontend based off Boost.Proto 2. backend implemented with the help of Boost libraries like Boost.Math. 3. probably provide two levels of implementations. ( although it would really help if you could weigh the pros and cons of both and eliminate one the the two) 3a. looking at bit-level implementation(less space and probably more execution time) 3b.) digit level manipulation (more space - and probably less execution time). i.e. for an n-digit number is it ok to use up [n/2 to n] bytes of space or necessary to stick to log n amount of space for a BigInt object. my questions are :- 1. Please give your feedback/concerns regarding the above design. 2. Any other libraries like Boost.Math which would help with the backend. -- Ankit Malpani 3rd Year Undergraduate | BE. (Hons) Computer Science BITS Pilani Goa Campus

5 5

[Bind] Function arithmetic (sample impl inside)
by ivan.lelann＠free.fr 12 Apr '10

12 Apr '10

Hi, It's my first message here, so please excuse possible mistakes. I found that Boost.Bind offers logical operators but no arithmetical operators. Looking into boost/bind/bind.hpp, and using "logical_not" impl, I wrote the following naive patch against version 1.40. It is certainly not as robust as Boost exspects, it is quickly tested, but it seems to do the job, as you can see in the test. Please use attached documents as you see fit. Regards, Ivan. PS: attached main.cpp is compiled with g++ 4.4.1, -std=c++0x, "my" bind.hpp in same directory, and boost 1.40 in include path.

2 1