- Boost-users - lists.preview.boost.org

[Interprocess] Container of containers LRU
by Matthieu Tourne 23 May '11

23 May '11

Hi, I'm looking into implementing an object cache available from multiple processes, I naturally found the boost::interprocess library mostly adapted for this. My problem is how to implement a cache eviction mechanism (LRU or other) when shared memory segment has been filled up. My problem gets worse, when I start using containers of containers, as described here : http://www.boost.org/doc/libs/1_46_1/doc/html/interprocess/allocators_conta… So I have that allocator that I use everywhere, like in the example : typedef managed_shared_memory::segment_manager segment_manager_t; typedef allocator<void, segment_manager_t> void_allocator; I use it to create a boost::interprocess::map of objects, which in turn can contain a boost::interprocess::map of strings in shared memory as well. So to recap, I have an map of Object like an "object store" and each Object can contain a "dictionary" (map of strings) of unknown size, all of those living in a shared memory segment. My problem, is that shared memory segments are of a given size and any of the allocate() operation that the allocator is going to perform (when adding a new Object, or a new element in a dictionary) can throw a boost::interprocess::bad_alloc exception. So I'm wondering if there is a more suited library to do persistent caching of objects between processes, with a way to automatically evicts "old cache" from the memory. Or if there is a way to implement my own allocator that would be more aware of my design, and would deallocate one of the Objects and the associated dictionary if an allocate() were to fail. I've been scratching my head for a little while now, and any suggestions or example of code would be really appreciated! Thank you, Matthieu.

1 0

[Lambda] Getting the bind incantation correct.
by Robert Jones 23 May '11

23 May '11

Hi All I'm trying to use std::vector::push_back() within a Boost.Lambda expression, but am finding it impossible to bind correctly. Can anyone tell me what I'm doing wrong in this code? Thanks in advance, - Rob. #include <vector> #include <boost/function.hpp> #include <boost/lambda/bind.hpp> void f( ) { namespace ll = boost::lambda; using boost::function; typedef unsigned char Id; typedef std::vector<Id> Ids; ll::placeholder1_type x; Ids ids; void ( Ids::* push_back )( const Ids::value_type & ) = & Ids::push_back; function<void(Id)> my_push = ll::bind( push_back, ids, x ); // Line 18 (void)my_push; } > g++ ignore.cpp [...lots of template instantiation errors, then...] ignore.cpp:18: instantiated from here /usr/include/boost/lambda/detail/actions.hpp:96: error: no matching function for call to ‘boost::lambda::function_adaptor<void (std::vector<unsigned char, std::allocator<unsigned char> >::*)(const unsigned char&)>::apply(void (std::vector<unsigned char, std::allocator<unsigned char> >::* const&)(const unsigned char&), const std::vector<unsigned char, std::allocator<unsigned char> >&, unsigned char&)’ /usr/include/boost/lambda/detail/actions.hpp:96: error: return-statement with a value, in function returning 'void'

3 4

Review Wizard Report for May 2011
by Ronald Garcia 23 May '11

23 May '11

============================================== Review Wizard Status Report for May 2011 ============================================== News ==== 1. Process Library Rejected 2. Phoenix Library Accepted 3. XInt Library Rejected 4. Type Traits Extensions Accepted 5. Locale Library Accepted 6. Convert Library Withdrawn 7. Conversion Library Accepted Provisionally 8. Context Library Accepted Provisionally 9. Boost 1.46.1 Released Revised Libraries: Asio, Filesystem, Fusion, Graph, ICL, Math, Polygon, Proto, Property Tree, Signals2, TR1, Unordered Revised Tools: Quickbook Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * AutoIndex(Tool) - reviewed May 2011; review manager: Daniel James. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * GIL.IO - accepted January 2011; author: Christian Henning. * Type Traits Extensions - accepted March 2011; author: Frederic Bron. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Phoenix - accepted March 2011; author: Joel de Guzmann. * Move - accepted February 2011; author: Ion Gaztanaga. * Geometry Library - accepted November 2009; author: Barend Gehreis et al. * Ratio - accepted October 2010; author: Vicente Botet. * Chrono - accepted January 2011; author: Vicente Botet. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Switch - accepted provisionally January 2008; author: Steven Watanabe. * Log - accepted provisionally March 2010; author: Andrey Semashev. * Context - accepted provisionally May 2011; author: Oliver Kowalke. General Announcements ===================== As always, we need experienced review managers. The review schedule has grown substantially but we have few volunteers, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Endian * Conversion * Sorting (M) * AutoBuffer * Containers * Lockfree * Fiber (M) * Quaternions, Vectors, Matrices (M) * Stopwatches * Variadic Macro Data (M) * Type Traits Introspection * Block Pointer (M) * Heaps * Assign v2 * Network (M) * Algorithm * Local (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&fil…>`__ | http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Endian ------ :Author: Beman Dawes :Review Manager: Joel Falcou :Download: http://svn.boost.org/svn/boost/sandbox/endian/ :Description: Conversion ---------- :Author: Vicente Botet :Review Manager: Gordon Woodhull :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=co…>`__ :Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic ``convert_to`` function which can be specialized by the user to make explicit conversion between unrelated types. * a generic ``assign_to`` function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between ``std::complex`` of explicitly convertible types. * conversion between ``std::pair`` of explicitly convertible types. * conversion between ``boost::optional`` of explicitly convertible types. * conversion between ``boost::rational`` of explicitly convertible types. * conversion between ``boost::interval`` of explicitly convertible types. * conversion between ``boost::chrono::time_point`` and ``boost::ptime``. * conversion between ``boost::chrono::duration`` and ``boost::time_duration``. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al…>`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. AutoBuffer ---------- :Author: Thorsten Ottosen :Review Manager: Robert Stewart :Download: http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip :Description: Boost.AutoBuffer provides a container for efficient dynamic, local buffers. Furthermore, the container may be used as an alternative to std::vector, offering greater flexibility and sometimes better performance. Containers ---------- :Author: Ion Gaztanaga :Review Manager: John Maddock :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Documentation: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h…>`__ :Description: Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. Lockfree ------------------ :Author: Tim Blechmann :Review Manager: Hartmut Kaiser :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Documentation: http://tim.klingt.org/boost_lockfree/ :Description: Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. Lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack Fiber ----- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Description: C++ Library for launching fibers (micro-threads) and synchronizing data between the fibers. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Stopwatches ----------- :Author: Vicente Botet :Review Manager: Anthony Williams :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=st…>`__ :Description: On top of the standard facilities of Boost.Chrono, Stopwatches provides: * Stopwatches: A facility to measure elapsed time with the ability to start, stop, suspend, or resume measurement. * Stopwatch concept * Scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * stopwatch, model of Stopwatch capturing elapsed Clock times. * stopwatch_accumulator, model of Stopwatch capturing accumulated elapsed Clock times. * Stopclocks: a complete time reporting package that can be invoked in a single line of code. * stopwatch_reporter, convenient reporting to an output stream (including wide char streams) of the elapsed time of models of Stopwatch results. * stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Type Traits Introspection ------------------------- :Author: Edward Diener :Review Manager: Joel Falcou :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/tti/>`__ :Description: The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox <https://svn.boost.org/svn/boost/sandbox/block_ptr/>`__ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Heaps ----- :Author: Tim Blechmann :Review Manager: Andrew Sutton :Download: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz :Description: The Heap library is an implementation of priority queues, data structures that order their elements priority. They are useful in a number of different applications especially graph search algorithms and queuing systems. Whereas the STL provides a class template std::priority_queue, Boost.Heap implements data structures with different features and performance characteristics. One key feature is the inclusion of "mutable" heaps, which allow the priorities of enqueued objects to modified and their position in the queue updated. The heaps in the library also support merging, stable sorting, and equality and less-than comparison. Assign v2 --------- :Author: Erwann Rogard :Review Manager: John Bytheway :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/assign_v2>`__ :Description: This library is an upgrade of Boost.Assign 1.0 that redefines its functionality, with optional C++0x support and new features. It expresses repetitive statements for assigning or inserting elements via a basic grammar. Network ------- :Author: Dean Michael Berris :Review Manager: Needed :Download: http://cplusplus-soup.com/2011/04/18/cpp-netlib-0-9-0-released/ :Description: This is a library that provides application layer protocol support using modern C++ techniques. It is light-weight, fast, cross-platform and is intended to be as easy to configure as possible. Algorithm --------- :Author: Marshall Clow :Review Manager: Dave Abrahams :Download: `Boost Sandbox Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.…>`__ :Description: Boost.Algorithm is a collection of general purpose algorithms. While Boost contains many libraries of data structures, there is no single library for general purpose algorithms. Even though the algorithms are generally useful, many tend to be thought of as "too small" for Boost. An implementation of Boyer-Moore searching, for example, might take a developer a week or so to implement, including test cases and documentation. However, scheduling a review to include that code into Boost might take several months, and run into resistance because "it is too small". Nevertheless, a library of tested, reviewed, documented algorithms can make the developer's life much easier, and that is the purpose of this library. Local ----- :Author: Lorenzo Caminiti :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/local/>`__ :Description: This library supports local functions, local blocks, and local exits Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

2 1

Re: [Boost-users] [BGL] Problems with planar_face_traversal
by "Ulrich Küttler" 23 May '11

23 May '11

>On Sun, May 22, 2011 at 2:39 PM, "Ulrich Küttler" ><ulrich.kuettler(a)web.de> wrote: >>> >>>I'd love to help out - can you give a self-contained example that >>>doesn't use read_graphviz and your dot file (e.g., construct the graph >>>in the code)? Or, failing that, maybe just describe what's going wrong >>>and how that differs from what you expect to see? >>> >> >> Hi Aaron, >> >> thanks a lot. Here is a self-contained version of my example. The graph is the same. I used boost 1.46.1 on gcc linux to run it. >> >> The graph contains 22 vertices and is supposed to look like this: >> >> 0--- 4--- 6--- 8---10---12---14---16---18---20--- 1 >> | | | | | | | | | | | >> 2--- 5--- 7--- 9---11---13---15---17---19---21--- 3 >> >> Thus, there are 10 faces with 4 vertices each and one face with 22 vertices. At least that is what I suppose there should be. >> >> However, the face traversal results in the following faces (vertices): >> >> 0 12 17 16 >> 12 0 16 18 19 17 >> 1 13 14 15 >> 13 1 15 14 11 9 8 10 >> 2 3 5 7 6 4 >> 3 2 20 18 16 17 19 21 >> 2 4 5 3 21 20 >> 5 4 6 8 9 7 >> 6 7 9 11 10 8 >> 10 11 14 13 >> 19 18 20 21 >> > >Hi Ulrich, > >The diagram you drew above doesn't match the edges you've created in >test_planar2.cpp (for example, test_planar2.cpp adds the edge (0,12), >but that edge doesn't appear in your diagram.) So I'm working off of >the diagram, not the edges you've added in the file, since it's pretty >clear to me what's going on in your diagram. > >What you're getting back is a valid face traversal, as far as I can >tell - I drew it out based on the output and it looks correct (I >modified test_planar2.cpp to reflect the graph you drew above.) The >problem is in your assertion that there are 10 faces with 4 vertices >each and one face with 22 vertices. > >Recall that a "planar embedding" is any clockwise arrangement of the >adjacent vertices around each vertex in a planar graph. The important >fact to realize is that for any planar graph, there's not necessarily >one unique planar embedding. The set of faces of a planar graph are a >function of the planar embedding, not unique to the graph itself, so >there might also be many correct decompositions of a planar graph into >a set of faces. In your drawing, you've singled out one particular >planar embedding that has 10 faces with 4 vertices each and one face >with 22 vertices, but in your code, you're allowing the BGL to create >a planar embedding for you which is not the same as the planar >embedding you have in mind. If you were to manually create the planar >embedding you have in mind above instead, you'd see the face traversal >output you expect. > Hi Aaron, thank you very much. The diagram is indeed the graph I expected. I did not realize that the planar embedding of the graph is not unique. Now this gives me another problem to solve, since I'm looking for a certain set of faces. My current attempt is to add vertices and edges in order to obtain an unique embedding. However, I'm still working on that. Thanks for your advice. Ulrich ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

1 0

BoostCon video mirror
by Jeroen Habraken 23 May '11

23 May '11

Hi, After becoming annoyed with blip.tv I've created a mirror of the BoostCon videos with the help of Nikhef (http://www.nikhef.nl/en/) It can be found at http://wipkip.nikhef.nl/events/BoostCon/2010/ and there's a quick overview over at http://vexocide.org/boostcon.html. If desired we'll gladly host the 2011 videos as well. Regards, Jeroen Habraken

1 0

[Interprocess] error_code_t = 9 (already_exists_error) while opening a fixed_managed_shared_memory
by Gaetan Gaumer 23 May '11

23 May '11

Hello Ion and other Interprocess users, we are currently working with fixed_managed_shared_memory segments and we have a strange behavior while opening existing segments. Sometimes (we did not found the exact scenario yet...), when we try to open a fixed_managed_shared_memory in open_only mode with the code below, we get an interprocess_exception with the an error_code_t = 9 ( already_exists_error ). try{ managedSharedMemorySegment = new fixed_managed_shared_memory(boost::interprocess::open_only, memorySegmentName, memorySegmentMappingAdress); }catch (boost::interprocess::interprocess_exception e){ return e.get_error_code(); } A first sight this error_code seems very strange, because in open_only mode the segment is intended to already exists so that should not be an error. Walking the code I found in the mapped_region constructor the following code which trigger the exception : 522: //Check for fixed mapping error if(address && (old_base != address)){ error_info err = system_error_code(); this->priv_close(); throw interprocess_exception(err); } It seems that the mmap function returns an address different that the given one, which is considered an error. So I have two questions : 1) Do you have an idea why the mmap function maps the segment at a different address from the provided one, knowing that this address is the one returned from code below on another process (so should be valid) ? try{ managedSharedMemorySegment = new fixed_managed_shared_memory(boost::interprocess::create_only, memorySegmentName, memorySegmentSize); memorySegmentMappingAdress = managedSharedMemorySegment->get_address(); }catch (boost::interprocess::interprocess_exception e){ return e.get_error_code(); } 2) In the mapped_region constructor, when a non null address value is given as a parameter, could we use the MAP_FIXED flag to force the mmap function to map the segment at the provided address ? Thank you for reading and for your help. Gaëtan

4 9

Problem with boost 1.36 on RHEL4
by Sunil Thomas 23 May '11

23 May '11

Hi all! I am struggling with some unit tests that fail only on RHEL4 release build. They pass on RHEL4 debug, RHEL5 release/debug, likewise also pass on win32, win64 (using either vc8 or vc9).. I've run the debug RHEL4 mode using valgrind, using a minimal case that reproduces the problem and here's what I see (I used the "full, no-reachable mode" to run valgrind; and I see the same output minus line #s, even running valgrind on RHEL4 release build, since that is the only platform-build combo where the test failure happens): ----------------------------------------------------------------------------------------------------------------------------- ==12285== Memcheck, a memory error detector. ==12285== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==12285== Using LibVEX rev 1575, a library for dynamic binary translation. ==12285== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==12285== Using valgrind-3.1.1, a dynamic binary instrumentation framework. ==12285== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==12285== For more details, rerun with: -v ==12285== ==12285== My PID = 12285, parent PID = 12284. Prog and args are: ==12285== ./xrestunittest_xconn_rescalerd ==12285== ==12285== Syscall param sigaltstack(ss) points to uninitialised byte(s) ==12285== at 0x3AD682EDA9: sigaltstack (in /lib64/tls/libc-2.3.4.so) ==12285== by 0x6488638: boost::detail::signal_handler::~signal_handler() (in /net/ rpenas1.xcp.chevrontexaco.net/vol/vol2/data/grp2/sypb/devl/xrest/trunk/3rdp… ) ==12285== by 0x648975E: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (in /net/ rpenas1.xcp.chevrontexaco.net/vol/vol2/data/grp2/sypb/devl/xrest/trunk/3rdp… ) ==12285== by 0x6489813: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (in /net/ rpenas1.xcp.chevrontexaco.net/vol/vol2/data/grp2/sypb/devl/xrest/trunk/3rdp… ) ==12285== by 0x648F2E4: boost::unit_test::framework::run(unsigned long, bool) (in /net/ rpenas1.xcp.chevrontexaco.net/vol/vol2/data/grp2/sypb/devl/xrest/trunk/3rdp… ) ==12285== by 0x649BD02: boost::unit_test::unit_test_main(bool (*)(), int, char**) (in /net/ rpenas1.xcp.chevrontexaco.net/vol/vol2/data/grp2/sypb/devl/xrest/trunk/3rdp… ) ==12285== by 0x4147F0: main (init.cpp:132) ==12285== Address 0x7FEFFF3B0 is on thread 1's stack ==12285== ==12285== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 4 from 1) ==12285== malloc/free: in use at exit: 190,112 bytes in 1,869 blocks. ==12285== malloc/free: 23,128 allocs, 21,259 frees, 2,520,845 bytes allocated. ==12285== For counts of detected errors, rerun with: -v ==12285== searching for pointers to 1,869 not-freed blocks. ==12285== checked 2,184,272 bytes. ==12285== ==12285== LEAK SUMMARY: ==12285== definitely lost: 0 bytes in 0 blocks. ==12285== possibly lost: 0 bytes in 0 blocks. ==12285== still reachable: 190,112 bytes in 1,869 blocks. ==12285== suppressed: 0 bytes in 0 blocks. ==12285== Reachable blocks (those to which a pointer was found) are not shown. ==12285== To see them, rerun with: --show-reachable=yes --------------------------------------------------------------------------------------------- Any ideas from boost experts here on how to resolve this problem is sincerely appreciated.. Thanks in advance, --Thomas.

1 0

What's the status of log library?
by archie14 22 May '11

22 May '11

When the log library (http://boost-log.sourceforge.net/) will be the part of official boost distribution? If there is no log library currently included in boost then what is the one most in use?

5 5

regex_replace for removing words
by Kraus Philipp 22 May '11

22 May '11

Hello, I have some texts and I would like to remove words. Each word for removing is in a std::vector<std::string> and I use a std::string for separating the words on the text. My first idea is to use the boost:split for splitting words of the text, in the result vector I remove the words, which should be removed, and recreate the text from the vector by concatination the elements. But another idea is to create a regexpr with the removing word and the separators and use regex_replace for removing. Which idea is the better one or is there another way to removing word of a text? Thanks PHil

2 2

Re: [Boost-users] [BGL] Problems with planar_face_traversal
by "Ulrich Küttler" 22 May '11

22 May '11

> >I'd love to help out - can you give a self-contained example that >doesn't use read_graphviz and your dot file (e.g., construct the graph >in the code)? Or, failing that, maybe just describe what's going wrong >and how that differs from what you expect to see? > Hi Aaron, thanks a lot. Here is a self-contained version of my example. The graph is the same. I used boost 1.46.1 on gcc linux to run it. The graph contains 22 vertices and is supposed to look like this: 0--- 4--- 6--- 8---10---12---14---16---18---20--- 1 | | | | | | | | | | | 2--- 5--- 7--- 9---11---13---15---17---19---21--- 3 Thus, there are 10 faces with 4 vertices each and one face with 22 vertices. At least that is what I suppose there should be. However, the face traversal results in the following faces (vertices): 0 12 17 16 12 0 16 18 19 17 1 13 14 15 13 1 15 14 11 9 8 10 2 3 5 7 6 4 3 2 20 18 16 17 19 21 2 4 5 3 21 20 5 4 6 8 9 7 6 7 9 11 10 8 10 11 14 13 19 18 20 21 Maybe it is a misinterpretation on my part, maybe I did make a mistake. I just don't see it. Ulrich PS: My first example lacked the edge index initialization. The above problem, however, occurs with an initialized edge index. ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

2 1