April 2010 - Boost - lists.preview.boost.org

Re: [boost] Crypto Proposal
by Chad Seibert 14 Apr '10

14 Apr '10

Straight from the maintainer. Hi Chad, I don't think I would be comfortable with this; past conversations on the list have suggested a sizeable population of the users is avoiding boost for one reason or another and there was some pushback in terms of even using boost in the library in a way that would require it for basic functionality. This change would leave these users high and dry. I'll admit I perhaps didn't read your proposal as carefully as I should have; I had been under the impression that you would be creating more or less a boost.crypto that provided crypto functionality that happened to use botan internally but did not expose much or any of botan's API directly. Sorry for the miscommunication/mess. :( -Jack I don't know what this means in terms of the project - whether we'll go with a different project or just borrow bits from Botan. I am truly sorry I didn't look into this earlier; it was entirely my fault and I apologize for not looking into this issue earlier. Chad Seibert _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

Re: [boost] Crypto Proposal
by Chad Seibert 14 Apr '10

14 Apr '10

Thanks for all the feedback! > On 11/04/2010 7:25 PM, Rob Riggs wrote: > On 04/11/2010 10:53 AM, Chad Seibert wrote: >> Here's an example of boostified code, from one of the examples on the >> site. It's not too different from the original code (it's just >> commented out); this is because I don't want it to be a chore to port >> from Botan to Boost.Botan. Also, it is intuitively designed and I see >> no reason to change it. Of course, if it needs redesigning, we can >> discuss that afterwards > ... >> //std::auto_ptr<PKCS8_PrivateKey> >> privkey(PKCS8::load_key(arg_ca_key, rng, arg_passphrase)); >> std::auto_ptr<boost::botan::pkcs8::private_key> >> privkey(pkcs8::load_key(arg_ca_key, rng, arg_passphrase)); > Hi Chad, > > Would it make sense to have privkey() return the private key by value? > Is it non-copyable? > I think the reason is because a PKCS#8 key can be RSA/DSA or whatever else. > I'd like to be able to hold keys by value but I'm not sure whether that > is useful. I can't really see a need to copy keys around, but then again > who knows? > A Boostified Botan should consider this problem as Botan requires the > use of lots of yucky pointers in places because of the polymorphism. It's returned by pointer, since private keys are memory locked by SecureVector (see http://files.randombit.net/botan/doxygen/html/namespaceBotan_1_1PKCS8.html) to prevent flushing to disk (and other potential bugs noted here: http://files.randombit.net/botan/doxygen/html/secmem_8h-source.html) A bigger issue I see is AlgorithmIdentifier/OID mess I see in http://files.randombit.net/botan/doxygen/html/namespaceBotan.html#378aea09f…. Definitely needs to get replaced with something else. There is some rational reasoning with this, though. For example, when we load a pksc#8 key, we get an algo id, which leads to a huge if/else if statement (http://files.randombit.net/botan/doxygen/html/namespaceBotan.html#378aea09f…) It's also dependent on which libraries get build (the BOTAN_HAS_* defines). In any case, it's still far from perfect and needs to be thoughtout. I'll think about it, and get back to you. > On 12/04/2010 7:52 AM, Domagoj Saric wrote: > IMNHO that's a failed test by any standard (worse than OpenSSL and Crypto++)... > (must I really pay for e.g. virtual inheritance, dynamic_casts, > by-std::string-runtime-algorithm-lookups etc. etc... for such a simple use > case?)... > 1) If you write such simple applications, you are very lucky > 2) I think one "issue" on Botan for Windows is the entropy gatherer. > It's slow and takes a lot of memory if.. memory serves. For applications > where entropy is not THAT important, I replace it. For applications > where it IS important, I would take out life insurance. That's because you built Botan in whole; it has the ability to build only parts of itself. If we don't like the inheritance structure, I can certainly remove it when porting. For example, despite public keys being very similar in structure, they should NOT inherit from a common base simply because they are entirely different objects. Also, I certainly agree that the runtime lookup of algos is REALLY BAD and doesn't take advantage of the IH, as noted above. I agree it needs to be replaced. As for the RNG's they are easily swapped, so maybe a less expensive one should be created in the process? >> From this I gather that the original author plans to continue to develop and > maintain the original library, in which case I wonder what would be the purpose > of having a library that is nothing more but a 'parallel' 'boostified' version > of the original that in itself offers nothing new and is updated only after the > original one is updated? > I also think it is useless if Jack does not intend to treat the Boost > version as *the* version. > However, in the transition period, I think it is only sensible that the > student manually merges changes. Will take some planning... I agree that this version should become *the* version, but I was completely absent-minded and didn't bring that up when discussing this with him. I'll ask him ASAP. Hopefully this alleviates some issues, Chad Seibert _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

FW: deadline_timer and a crash at ~io_service -> timer_base::destroy()
by Vance Grkov 14 Apr '10

14 Apr '10

Hi, I am getting a crash at the scope end (before the "catch") below in the code. This is the stack trace and the source. Does anyone know what is the problem with this code? Appreciate your help! 000801c7() > BoostThreadPoolTest.exe!boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::timer_base::destroy() Line 211 + 0xe bytes C++ BoostThreadPoolTest.exe!boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::destroy_timer_list(boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::timer_base * & t=0x00338da0) Line 415 C++ BoostThreadPoolTest.exe!boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::destroy_timers() Line 189 C++ BoostThreadPoolTest.exe!boost::asio::detail::win_iocp_io_service::shutdown_service() Line 148 + 0x2c bytes C++ BoostThreadPoolTest.exe!boost::asio::detail::service_registry::~service_registry() Line 75 + 0xf bytes C++ BoostThreadPoolTest.exe!boost::asio::detail::service_registry::`scalar deleting destructor'() + 0x2b bytes C++ BoostThreadPoolTest.exe!boost::asio::io_service::~io_service() Line 52 + 0x2e bytes C++ BoostThreadPoolTest.exe!wmain(int argc=1, wchar_t * * argv=0x003371d8) Line 152 + 0x27 bytes C++ BoostThreadPoolTest.exe!__tmainCRTStartup() Line 583 + 0x19 bytes C BoostThreadPoolTest.exe!wmainCRTStartup() Line 403 C kernel32.dll!_BaseProcessStart@4() + 0x23 bytes #include "stdafx.h" #include <iostream> #include <boost/thread.hpp> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/asio.hpp> #define THREAD_POOL_SIZE 10 void TimerCallback(boost::system::error_code ec, std::size_t i, std::size_t retry) { std::stringstream tmp; tmp << "Timer(" << ec.value() << ":" << ec.message() << "-" << retry << "-" << i << ")\n"; } // // MAIN // int _tmain(int argc, _TCHAR* argv[]) { try { boost::asio::io_service io(THREAD_POOL_SIZE); boost::asio::io_service::work *moreWorkToCome = new boost::asio::io_service::work(io); // Create a pool of worker threads. std::vector<boost::shared_ptr<boost::thread> > threads; for (std::size_t i = 0; i < THREAD_POOL_SIZE; ++i) { boost::shared_ptr<boost::thread> thread(new boost::thread( boost::bind(&boost::asio::io_service::run, &io) )); threads.push_back(thread); } // Lets enqueue more tasks to run after a given time std::vector<boost::asio::deadline_timer *> timers; for (std::size_t i = 1; i<50; i++) { boost::asio::deadline_timer *timer = new boost::asio::deadline_timer(io); timer->expires_from_now(boost::posix_time::seconds(3)); timer->async_wait(boost::bind(&TimerCallback, boost::asio::placeholders::error, i, 0)); timers.push_back(timer); } std::cout << "\nALL TASKS QUEUED\n"; // Now that all tasks have been queued we don't want to hold on any of the worker threads delete moreWorkToCome; std::cout << "\nRELEASE THE THREAD POOL\n"; // Wait for all tasks to be processes which also means all threads in the pool will exit. for (std::size_t i = 0; i < threads.size(); ++i) threads[i]->join(); // Cancel all timers (just in case) for (std::size_t i = 0; i < timers.size(); ++i) timers[i]->cancel(); io.stop(); std::cout << "\nPOOL DOWN\n"; } <-------------------------------------------- CRASH catch(...) { std::cout << "ERROR"; } std::cout << "\nEXIT\n"; return 0; } Hotmail: Trusted email with powerful SPAM protection. Sign up now. _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969

2 1

[range] iterator_range::operator[] broken
by Eric Niebler 14 Apr '10

14 Apr '10

Neil, I know you patched this a mere 5 hours ago, but it's still broken. The attached patch *really* fixes the problem, I think. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 4

[GSoC] Boost.Matrix RFC
by Kornel Kisielewicz 14 Apr '10

14 Apr '10

Hello all, Last year I submitted a proposal for Boost.Matrix as a GSoC project, that provoked quite a bit discussion. Considering the fact that it wasn't unanimously rejected, and that a few things have changed since then (Boost.Geometry acceptance) as did my skills, I'd like to take the liberty of resubmitting my proposal to the list, with a request for comments. The proposal follows: == Boost.Matrix == uBLAS is Boost's general linear algebra library, and it is a fine library indeed. However, in some cases it's design decisions, while quite rational for the general use case, are restrictive. This proposal is about a new library that would address some of these issues in the specific situation of vector and matrix operations on fixed sized structures. Suggested is a new library boost::matrix. The library would introduce a single container class that allows representation of fixed size vectors and matrices, and their respective standard operations. The library would define the following template template<typename T, std::size_t Rows, std::size_t Cols, class Traits> matrix and standard operations on it. The class would make heavy use of template specialization to allow efficient vector operations (matrices with size 1xN ), and provide efficient operations for the common sizes (2-4). The class will provide the interface of STL containers with the exact concept depending on the Traits used. Care will be taken to allow transparent usage within STL and other boost libraries. In general, this library would be similary scoped as Boost.Quaternion. Recently a new library has been accepted into boost -- Geometry. As the library is deeply about matrices and vectors, and has much in common with this proposal, I'd like to take a deep focus on providing maximum interopeability between Geometry and Matrix. == Rationale == Boost.Matrix aims to be for uBLAS, what Boost.Array is for vectors - a fixed size version to remove the overhead. The need is however greater, because while uBLAS provides a template for a fixed-sized version of it's arrays, the template is just a cover for the original uBLAS matrices. While the performance is comparable, the size includes a unnecessary field size. In cases that make heavy use of fixed sized matrices and vectors ( like real-time computer graphics ), such a tradeoff is unacceptable - due to increased memory consumption as well as effective vectorized math operations, and alignment of structures passed ( a single 4D vector should effectively fit a 128 bit register, and a single 128 bit move operation ). Also, knowing the dimensions of a matrix/vector at compile time, allows for a more efficient operation implementation, both from the programmers side ( better algorithms ), as well as from the compilers side (optimization). Finally, the uBLAS introduces a lot of unneccessary bloat for users wanting only a 2,3,4 vector and 3,4 matrix classes. == Primary deliverables == Boost.Matrix library, with the following features: * a boost::matrix base container class for 2-dimensional matrices, with the proper behavious and semantics of a container, written following the boost coding guidelines, and with full portability in mind * specializations for efficient vector (1xN matrix) handling * operators for readable but efficient vector/matrix math * operator specializations for matrices and vectors of the most common size (2-4) for most efficient implementation * efficient implementation of interoperability of Boost.Matrix with other boost libraries (uBLAS, Quaternion and upcoming Boost.Geometry in particular) == Secondary deliverables == * performance test suite, for testing optimizations * unit tests for the whole library providing full operation coverage and code-coverage * documentation for the whole library in the BoostBook format, as well as doxygen markup for all the code == Bonus deliverables == ( if time allows these will be delivered during program timeline, if not, they will be implemented afterwards ) * performance tests on different compilers/architectures, further optimizations * support for further boost libraries ( Boost.Assign, sandbox libraries, etc. ) == Design issues == * compile-time concept checking to only generare functions that make sense for the given type ( no floating point operations for integral types ) * usage of template expressions to unroll the operations at compile-time to allow the compiler to optimize them ( needs to be tested case by case with the performance test suite ) and elimination temporaries * care to keep most useful memory alignment ( to provide ease of use with direct usage in architecture dependent pipelines ) -- possibly an alignment trait * design with architecture-dependent optimizations in mind ( ease of expansion ) * keeping all the standard boost practices, including workarounds for non-conformant compilers == Research == Several existing implementations were studied and evaluated before the repeated submission of this idea. I intend to encompass most of the good things I found in the following implementations into a small but very useful library: * Boost.uBLAS (obviously) * Eigen - http://eigen.tuxfamily.org/ (heavyweight) * CGAL - http://www.cgal.org/ (license issues) * Matrix Template Library - http://osl.iu.edu/research/mtl/ (similar issues to uBLAS) * VCGLib - http://vcg.sourceforge.net/ (GPL) * nVidia's vector and matrix classes (found in nVidia examples) -- regards, Kornel Kisielewicz http://chaosforge.org/

9 16

Re: [boost] [iterator] reverse_iterator<counting_iterator<T>>
by Arno Schödl 13 Apr '10

13 Apr '10

"Stewart, Robert" <Robert.Stewart(a)sig.com <mailto:Robert.Stewart@sig.com> > wrote in message news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com <news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com> ... > this->base() calls iterator_adaptor<>::base(), which returns a reference to the underlying iterator it holds. Passing that reference to boost::prior() means that prior() pre-decrements the iterator within the iterator_adaptor. It would be odd for that >decrement operator to return anything but a reference to the decremented object, so boost::prior() returns a reference to its decremented argument, a reference to the decremented iterator within the iterator_adaptor. > I see no problem. boost::prior(...) internally makes a copy of its iterator argument, decrements it and returns it by value, so far so good. counting_iterator::operator* then returns a reference into this (temporary) iterator. Returning from reverse_iterator::dereference() destroys the temporary iterator, but still returns the reference pointing into it. I overlooked that I already filed a defect a while ago for it: https://svn.boost.org/trac/boost/ticket/2640 <https://svn.boost.org/trac/boost/ticket/2640> It would be great to have it fixed, because the bug is quite subtle and may go undetected for a while. 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

3 4

[serialization] serialization lib not thread safe?
by Jean-Marie Auffray 13 Apr '10

13 Apr '10

I use boost serialization in multi threaded application. Sometimes application crashed. I manage to avoid bug if I recompile boost serialization with BOOST_SPIRIT_THREADSAFE defined in jam file : http://archive.netbsd.se/?ml=boost-build&a=2008-07&t=8023861 But I would like keep boost default installation. I read multi thread limitations here : http://www.boost.org/doc/libs/1_42_0/libs/serialization/doc/special.html But I don't find how to use singleton to avoid crash, I attach test files to reproduct crash. I use 1.36 in test files, but same bug seems to occure in next release. How can I add singleton from serialization to avoid crash? I try some solutions but failed to find a good implementation. Thanks for help.

2 1

release managers: permission to merge?
by Frank Mori Hess 13 Apr '10

13 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to the calendar, the release branch went into "closed except by permission" yesterday. Is it all right for me to merge to release the fix for this ticket: https://svn.boost.org/trac/boost/ticket/4089 The changeset in question is https://svn.boost.org/trac/boost/changeset/61243 I've tested it locally, but have just comitted it to trunk so the tests there haven't cycled yet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkvEbewACgkQ5vihyNWuA4XawACg1jS8IZun6NJ52GkCa2V3i4nc PAIAoJlaXBs4NqY5mfGiHMoVAYJsTSVp =NiyZ -----END PGP SIGNATURE-----

2 1

Guidelines on wiki
by Daniel James 13 Apr '10

13 Apr '10

Hello, I've copied the guidelines onto the wiki now, you can see them at: https://svn.boost.org/trac/boost/wiki/Guidelines/ Any comments? I've changed the beta site to redirect to them. I haven't linked to them from the front page of the wiki as they aren't 'official' yet. I'll be moving more pages over soon-ish. Any ideas about how the wiki should be structured? Daniel

5 10

[iterator] reverse_iterator<counting_iterator<T>>
by Arno Schödl 13 Apr '10

13 Apr '10

Hello, boost::reverse_iterator::dereference() is typename super_t::reference dereference() const { return *boost::prior(this->base()); } boost::constant_iterator<T>::reference_type is T const&. So reverse_iterator< constant_iterator<T> >::dereference returns a reference to a temporary variable. Not good. I suggest removing the reference from boost::constant_iterator::reference_type, making it T. The rule would be that reference_type must only be a reference if the reference is pointing to some underlying container, not to the iterator itself. 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

[iterator] Re: counting_iterator<int>::difference_type
by Arno Schödl 13 Apr '10

13 Apr '10

> > 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. > You are able to override the difference_type by providing your own type. > See: > boost::counting_iterator<int,boost::use_default,int>::difference_type I know and I did it already. I just want to question whether the default is sensible, given the rest of the language. 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

1 0

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

Re: [boost] Crypto Proposal
by Chad Seibert 12 Apr '10

12 Apr '10

> Hi, > > Perhaps this link will work: > > http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/chads… > Yep, it worked, thanks. > Thanks to all who gave advice, please ask if you have any questions! > It all sounds very good. Can you give an example of what porting some > Botan functionality would look like? Would it be as simple as replacing > the namespace Botan with boost::crypto/whatever in the source code? > An example of what one of the Botan tutorial examples would look like in > the new world would be nice. > Honestly, I think there is no point if you can't commit to part 2. > However, splitting it up into GSoC/non-GSoC is smart on your part. How > do you plan to commit to part 2? > Thanks and good luck :) Here's an example of boostified code, from one of the examples on the site. It's not too different from the original code (it's just commented out); this is because I don't want it to be a chore to port from Botan to Boost.Botan. Also, it is intuitively designed and I see no reason to change it. Of course, if it needs redesigning, we can discuss that afterwards. Also, there are at least 600 files to move that total 2 mb's of source, so it'll take a while, even if it is just changing namespaces and the like. But I'll get started on part 2 if part 1 finishes early. As for committing to part 2, I have some (rough) guidelines for the work to be done afterwards. I'm also taking a lighter courseload so I can spend more time working. I don't know how else to convince you. Anyways, thank you for considering my proposal! Chad Seibert #include <boost/botan.h> #include <iostream> #include <memory> int main(int argc, char* argv[]) { if(argc != 5) { std::cout << "Usage: " << argv[0] << " <passphrase> " << "<ca cert> <ca key> <pkcs10>" << std::endl; return 1; } try { const std::string arg_passphrase = argv[1]; const std::string arg_ca_cert = argv[2]; const std::string arg_ca_key = argv[3]; const std::string arg_req_file = argv[4]; //AutoSeeded_RNG rng; boost::botan::rng::auto_seeded rng; //X509_Certificate ca_cert(arg_ca_cert); boost::botan::x509::certificate ca_cert(arg_ca_cert); //std::auto_ptr<PKCS8_PrivateKey> privkey(PKCS8::load_key(arg_ca_key, rng, arg_passphrase)); std::auto_ptr<boost::botan::pkcs8::private_key> privkey(pkcs8::load_key(arg_ca_key, rng, arg_passphrase)); //X509_CA ca(ca_cert, *privkey); boost::botan::x509::ca ca(ca_cert, *privkey); // got a request //PKCS10_Request req(arg_req_file); boost::botan::pkcs10::request req(arg_req_file); // you would insert checks here, and perhaps modify the request // (this example should be extended to show how) // now sign the request //X509_Time start_time(system_time()); //X509_Time end_time(system_time() + 365 * 60 * 60 * 24); //X509_Certificate new_cert = ca.sign_request(req, rng,start_time, end_time); boost::botan::x509::time start_time(system_time()); boost::botan::x509::time end_time(system_time() + 365*60*60*24); boost::botan::x509::certificate new_cert = ca.sign_request(req, rng, start_time, end_time); // send the new cert back to the requestor //std::cout << new_cert.PEM_encode(); std::cout << new_cert.pem_encode(); } catch(std::exception& e) { std::cout << e.what() << std::endl; return 1; } return 0; } _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28…

4 3

[preprocessor] BOOST_PP_IS_UNARY()
by Lorenzo Caminiti 11 Apr '10

11 Apr '10

Hello all, Do you know what are the drawbacks of using BOOST_PP_IS_UNARY()? If you have used it, what is your experience with its portability? BOOST_PP_IS_UNARY() is *not* part of the Boost.Preprocessor public API as it is #defined in boost/preprocessor/detail/is_unary.hpp. However, Boost.Preprocessor, Boost.Typeof, and Boost.Spirit seem to use BOOST_PP_IS_UNARY() at least internally: $ find /usr/include/boost/ -name "*.[hc]pp" -exec grep -Hn "BOOST_PP_IS_UNARY" {} \; /usr/include/boost/preprocessor/facilities/apply.hpp:24:# define BOOST_PP_APPLY_I(x) BOOST_PP_EXPR_IIF(BOOST_PP_IS_UNARY(x), BOOST_PP_TUPLE_REM_1 x) /usr/include/boost/typeof/template_encoding.hpp:61: BOOST_PP_IS_UNARY(x),\ /usr/include/boost/spirit/utility/rule_parser.hpp:826: BOOST_PP_EXPR_IIF(BOOST_PP_COMPL(BOOST_PP_IS_UNARY(elem)),elem) In addition, Paul Mensonides mentioned the following in http://lists.boost.org/Archives/boost/2004/08/70238.php > Paul Mensonides wrote: > I know. They (and other types of detection macros) are very useful. Right now, > the Borland configuration is used by the IBM preprocessor and the Sun > preprocessor also. I'd like to know whether or not those macro definitions work > correctly on those preprocessors before I add it. Though those macros aren't > part of the public interface, they are part of the internal interface. I.e. > they are used internally as if they were a public interface (though they are > used carefully on some preprocessors). They are stable, and the worst thing > that might happen in the future is that they will be moved to a different > directory. Thus, you can use them, but beware of VC and versions of MWCW prior > to v9. They in particular have severe problems with expansion order. E.g. VC > will even fail this test: My Boost.Contract code internally uses BOOST_PP_IS_UNARY() and it works fine on GCC 4.2.4 (Ubuntu Linux), MSVC 8.0 (Windows XP), and GCC 3.4.4 (Cygwin) but I have not tried other compilers (including Borland's). Thank you. Lorenzo

1 1

[Locale] Static locale initialisation
by Alexander Lamaison 11 Apr '10

11 Apr '10

I'm encountering a crash with Boost.Locale as the process terminates I initialise the global Boost.Locale in the contructor of a class with a single static instance (the ATL module to be exact) as I don't have access to the code of my main method (it comes from the Boost.Test runner). A static object seems to be the only logical place to put this code: #include <boost/locale.hpp> // boost::locale::generator class CModule : public ATL::CAtlModule { public : CModule() : ATL::CAtlModule() { try { // Initialise Boost.Locale translation mechanism generator gen; gen.add_messages_path("C:/My/Path"); gen.add_messages_domain("swish"); std::locale::global(gen("")); // default locale } catch (std::exception) {} } HRESULT AddCommonRGSReplacements(IRegistrarBase*) { return S_OK; } }; CModule _AtlModule; // Global module instance However, when I run my EXE, it crashes as it terminates with: Unhandled exception at 0x5ba43d93 (msvcp80d.dll) in test-shell_folder.exe: 0xC0000005: Access violation reading location 0x0321f4e4. and the following stack trace: msvcp80d.dll!std::_DebugHeapDelete<std::locale::facet>(std::locale::facet * _Ptr=0x023af590) msvcp80d.dll!_Deletegloballocale(void * ptr=0x5bb25258) msvcp80d.dll!tidy_global() msvcp80d.dll!_Init_atexit::~_Init_atexit() msvcp80d.dll!`dynamic atexit destructor for 'init_atexit''() msvcp80d.dll!_CRT_INIT(void * hDllHandle=0x5ba30000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) msvcp80d.dll!__DllMainCRTStartup(void * hDllHandle=0x5ba30000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) msvcp80d.dll!_DllMainCRTStartup(void * hDllHandle=0x5ba30000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) ntdll.dll!_LdrpCallInitRoutine@16() ntdll.dll!_LdrShutdownProcess@0() ntdll.dll!_RtlExitUserProcess@4() kernel32.dll!76843b69() msvcr80d.dll!__crtExitProcess(int status=0x00000000) msvcr80d.dll!doexit(int code=0x00000000, int quick=0x00000000, int retcaller=0x00000000) msvcr80d.dll!exit(int code=0x00000000) test-shell_folder.exe!__tmainCRTStartup() test-shell_folder.exe!mainCRTStartup() If I move the initialisation code to run just before each point I need to use translate() then it works fine. So maybe this has something to do with the way static data is destroyed. This is on Windows - not sure about other platforms. Any ideas? Many thanks. Alex Lamaison P.S. I realise Boost.Locale isn't in Boost yet but previous discussions have been here so it seems a reasonable place to ask.

2 19

Re: [boost] [GSoC]Bits and Ints
by shiyang yang 10 Apr '10

10 Apr '10

Hi Thanks for the help. But I am still not very sure about the meaning of dynamic_bitfields. Does it mean the size of the bitfield is dynamic? Shiyang

3 2