- Boost - lists.boost.org

[Pool] Arbitrary sized elements?
by Phil Bouchard 13 May '08

13 May '08

Greetings: I was wondering if they were any intent to add a derivative of Boost.Pool which will handle types of arbitrary sizes. It won't benefit from speed optimization but certainly from its members functions such as is_from(), obliteration properties and independent memory area. This is basically were shifted_ptr is heading to because allocated blocks from new_sh() cannot be mixed with global allocations. If there isn't any intent to do so then I'll experiment using mmap() functions and Win32 variants. Thanks, -Phil

1 1

[Regex] Word boundary pattern does not match
by Teddy Brielle 13 May '08

13 May '08

Hi, I use the boost v1.35 regex library on Windows XP. I would like to find the '*' character from an input string only if this character is not bound to a word (for replacement purpose). I then use the following regular expression pattern to find occurrences in my input string: \B\*\B But this regular expression seems not to match any '*' character of the following input string: * test *test test* * te*st * I would expect that the regular expression would match the 1st, 4th and 6th '*' character. I have performed further tests with the pattern \b*\b, which works and matches the 5th '*' character. Here is the code I use : void Replace(std::string& string, std::string& pattern, std::string& replacementString) { try { std::string newString; // Looking for matching substrings (case insensitive) boost::regex expression (CStringToStdString(pattern), boost::regex::perl|boost::regex::icase); std::string::const_iterator start = string.begin(); std::string::const_iterator end = string.end(); boost::match_results<std::string::const_iterator> what; boost::match_flag_type flags = boost::match_default; while (boost::regex_search(start, end, what, expression, flags)) { // Replace the matching occurrence with the replacement string newString = newString + std::string(start, what[0].first); newString = newString + replacementString; // Next... start = what[0].second; } newString = newString + std::string(start, string.end()); string = newString; } catch (std::runtime_error e) { // Return string as is. TRACE(e.what()); } } and here are the provided parameters: string = "* test *test test* * te*st *"; pattern = "\\B\\*\\B"; replacementString = ""; Have I done something wrong in my pattern or in my code (match flags,...) ? Thanks in advance for your help. Regards, Teddy

2 1

Newbie question on asio and TCP/IP
by Me here 13 May '08

13 May '08

Hi, I'm writing program with asio from 1.35.0 to read the data from a hardware device which sends data to my PC to port 7000. The sample below fails on Windows with exception code 10022, text "An invalid argument was supplied". Where's the fault? Can someone help please? Alexander ----------- sample code ------------- #include <iostream> #include <boost/asio.hpp> using boost::asio::ip::udp; int main(int argc, char* argv[]) { try { boost::asio::io_service io_service; udp::endpoint sender_endpoint( udp::v4(), 7000 ); udp::socket socket(io_service); socket.open( udp::v4() ); char packet[1024]; size_t len = socket.receive_from( boost::asio::buffer(packet), sender_endpoint); std::cout << "Works\n"; } catch(const std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

2 1

[asio] 1.35.0 documentation to pdf problem?
by Jonathan Biggar 13 May '08

13 May '08

I'm trying to build a .pdf of boost.asio documentation, but it fails with this message (and two more identical errors with different stack traces): > javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: > file:/home/corvette/jon/tech/boost-1.35.0/libs/asio/doc/../../../bin.v2/libs/as > io/doc/gcc-4.1.2/debug/standalone_doc.fo:24047:598: Error(24047/598): fo:list-bl > ock is missing child elements. > Required Content Model: marker* (list-item)+ > at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:168) > at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) > at org.apache.fop.cli.Main.startFOP(Main.java:166) > at org.apache.fop.cli.Main.main(Main.java:197) Anybody have any suggestions or better luck? -- Jon Biggar Floorboard Software jon(a)floorboard.com jon(a)biggar.org

2 1

Compilation error in mutex.hpp
by Stas Khirman 13 May '08

13 May '08

Just found a compilation problem in include/boost-1_35/boost/pool/detail/mutex.hpp line 67. While compiling with VS2005 under WinXp, got compilation error "C2872: 'CRITICAL_SECTION' : ambiguous symbol". ( project is quite complicated, with many includes and soon) Fix is trivial: ::CRITICAL_SECTION mtx; // note "::" to resolve symbol mix-up.

1 0

How to review futures?
by John Phillips 13 May '08

13 May '08

I'm looking to see if there are any good ideas for how to review the two futures libraries that are both currently in the queue. Since they are two different approaches to the same problem domain, isolated sequential reviews does not seem to be a good idea. So far, the best thought I've had on the subject is to run a single review that includes both libraries, where it is explicitly part of the review to discuss which parts of which realizations are the best choice. This process will need to keep the proposals before the committee in mind, but it is a way to compare and contrast the strengths of the two in close proximity. If we do this, there are a couple of questions that should be added to the usual review process. * Which interface choices are best suited to the problem domain? * Should Boost offer competing implementations of this feature? * Should the libraries be melded together? * Should a subset of the approved library be restricted to only the facilities and interface in the standardization committee proposal? There are my initial thoughts. I would like to hear from others on this, as well. I especially would like to hear from the authors and from anyone who has been involved in the evolving standards proposal. Thanks for your ideas. John Phillips Review Wizard

5 7

[smart_ptr] Proposal to add new_shared function
by Andrey Semashev 12 May '08

12 May '08

Hi, I've seen this topic floating around but it seems it didn't make it into boost for some reason. I propose to add a new helper function for shared_ptr, namely new_shared. The function would dynamically allocate an object and return shared_ptr that points to it. The function provides the following benefits: - It may perform better than allocating the object and constructing shared_ptr explicitly. Obviously, it allows to get rid of the additional allocation for the counter object. - The function is effectively a safer replacement for the core operator new. It solves the frequently missed memory leak pointed out by Meyers: foo(shared_ptr< A >(new A), bar()); I've made a quick implementation that supports the following: - Arbitrary number of constructor arguments. C++0x features (variadic templates and rvalue references) are supported in addition to the traditional and more limited C++03 version. - Support for custom deleters, which are now more "destroyers" because a deleter used with the new_shared function should not free memory from the destroyed object. - Support for custom allocators. It is through allocators the memory for both the object and the counter are allocated and deallocated. - The shared_ptr implementation is intact, the new feature is a pure addition (however, it could be made a bit more effective with a little help from shared_ptr). The implementation is available in the Vault: http://tinyurl.com/6sxtpg Some quick examples of use: shared_ptr< A > p1 = new_shared< A >(); // default ctor shared_ptr< B > p2 = new_shared< B >(x, y, z); // parametrized ctor shared_ptr< C > p3 = new_shared< C >(ref(x)); // passing references // using custom deleter shared_ptr< D > p4 = new_shared< D >(use_deleter(d)); // using custom allocator shared_ptr< E > p5 = new_shared< E >(use_allocator(a)); // you can mix the above cases shared_ptr< F > p6 = new_shared< F >( use_deleter(d), use_allocator(a), x, ref(y)); shared_ptr< G > p7 = new_shared< G >( use_allocator(a), use_deleter(d), z); The use_allocator and use_deleter arguments may be in either order, but must be the first arguments of new_shared, if used. Do you think this would be a reasonable addition to Boost.SmartPtr?

2 2

GCC Visibility Support
by Steven Dodd 12 May '08

12 May '08

I think it would be worthwhile to extend Boost to support GCC's (relatively) new visibility features. For those unfamiliar with GCC's visibility features, please read the following articles for background: http://gcc.gnu.org/wiki/Visibility http://developer.apple.com/technotes/tn2007/tn2185.html Please forgive any ignorance displayed in the following proposal - I'm new to Boost, and only more-so to Boost library development! I've reviewed all of the messages I could find on the mailing list related to this subject, but didn't see one that provided a comprehensive proposal for adding full visibility support. So here goes: There are essentially two use-cases which need to be addressed: ( 1 ) Compiling Boost with restricted visibility In this case, the user wants to gain the full benefits of restricted symbol visibility, and so they want to compile both their own code and Boost with restricted symbol visibility. That is, they want to build Boost with some combination of the GCC flags: -fvisibility=hidden, -fvisibility-inlines-hidden, and -fvisibility-ms-compat (OS X specific). In order to build Boost properly with restricted symbol visibility, Boost needs to be configured to mark all public symbols as such. On Windows, Boost already does this by (A) defining BOOST_HAS_DECLSPEC in <config/platform/win32.hpp>, and (B) defining and using library-specific _DECL macros (e.g. BOOST_FILESYSTEM_DECL = __declspec(dllexport) or __declspec(dllimport) depending on whether the library is being built, or used). What needs to be done to support GCC's symbol visibility restriction is to generalize the support already in place for Windows, along the following lines: - Rename BOOST_HAS_DECLSPEC to BOOST_HAS_SYM_CONTROL, and define this symbol in appropriate config headers. For GCC, this should be an optional feature, and I'm not sure of how to best allow users to enable/disable it (e.g. how to integrate it as a Boost.Build option). Change all locations to use the new name. - Introduce macro, BOOST_SYM_EXPORT, and define as __declspec(dllexport) on Windows, and as __attribute__((visibility("default"))) for GCC. Change all locations currently hard-coding __declspec( dllexport ) to use BOOST_SYM_EXPORT instead. - Introduce macro, BOOST_SYM_IMPORT, and define as __declspec(dllimport) on Windows, and as __attribute__((visibility("default"))) for GCC. Change all locations currently hard-coding __declspec( dllimport ) to use BOOST_SYM_IMPORT instead. This approach should work "out-of-the-box" when using GCC's -fvisibility-ms-compat mode (MSVC++ compatibility mode), since it already works on Windows. However, this approach will likely be incomplete when using GCC's -fvisibility=hidden mode. Reason being, unlike the visibility-ms-compat mode, this mode does not automatically mark types with "vague linkage" as visible (e.g. type_info). As a result, exceptions thrown in one DSO will not be caught in other DSOs. It is beyond my understanding of Boost to propose a comprehensive set of changes required to address the problem. ( 2 ) Compiling Boost with normal visibility, but enabling linkage into user-code compiled with restricted visibility In this case, the user wants to build their own code with restricted symbol visibility, but wants to link against a copy of Boost compiled with default visibility (e.g. most likely, a pre-built Boost binary). Presently, upon doing so, the user will find themselves faced with a slew of linker warnings regarding the mismatch in visibility levels between Boost symbols compiled into user-code vs. in the Boost libraries. In order to resolve this issue properly (e.g. not just silence the linker), Boost needs to be modified to wrap all Boost types in "default" visibility instructions, like so: #pragma GCC visibility push(default) ... boost types ... #pragma GCC visibility pop Boost's existing ABI facility is sufficient for this task, were it employed consistently by all Boost libraries (unfortunately, as far as I can tell, it is not): - Create file <boost/config/abi/gcc_default_visibility_prefix.hpp> with the following contents: #pragma GCC visibility push(default) - Create file <boost/config/abi/gcc_default_visibility_suffix.hpp> with the following contents: #pragma GCC visibility pop - In the appropriate config header, define BOOST_ABI_PREFIX as "boost/config/abi/gcc_default_visibility_prefix.hpp", define BOOST_ABI_SUFFIX as "boost/config/abi/gcc_default_visibility_suffix.hpp", and define BOOST_HAS_ABI_HEADERS. Note: this should be the default for GCC, however, if the user has requested restricted symbol visibility, as in use-case (1), then these BOOST*ABI macros must not be defined, or the prefix/suffix headers at least need to conditionally define the visibility based on some other macro definition... I look forward to comments! Cheers, Steven Dodd sdodd<at>view22<dot>com

1 0

[graph] [serialization] serialized descriptors
by Carlos Rafael Giani 12 May '08

12 May '08

Hello, there is utility code for serializing an adjancency_list graph to an archive in the BGL. But I wonder about two things: 1) I have a list of descriptors in my program. This list is a selection of vertices. If I want to serialize my program's states, I need to serialize the graph as well as this selection. This means I have to serialize references to vertices. Now AFAIK I cannot simply serialize descriptors, because they essentially are pointers. I need a persistent ID. Is there existing functionality for this? If not, I have to either use one of the vertex properties as ID, or autogenerate IDs (for example, by using casting the descriptors to an intptr_t and using this value as ID) and upon deserialization use these for mapping the right descriptors back into the list. 2) One vertex property is a map of boost::any values. map < string, any > to be exact. Does the BGL serialize the properties? If so, how does it deal with boost::any constructs?

2 2

[thread] thread_group create_thread template function
by vicente.botet 12 May '08

12 May '08

Hi, the thread_group::create_thread takes a const function0<void> parameter: thread* create_thread(const function0<void>& threadfunc); The function0 implies already a memory allocation. The templated version look like: template <class Threadable> thread* thread_group::create_thread(Threadable threadfunc) { // No scoped_lock required here since the only "shared data" that's // modified here occurs inside add_thread which does scoped_lock. std::auto_ptr<thread> thrd(new thread(threadfunc)); add_thread(thrd.get()); return thrd.release(); } Which works faster because no need to allocate memory for the boost::function0<void()>. Anthony, if there is nothing wrong, could this substitute the create_thread function in next Boost::thread release? Best regards _____________________ Vicente Juan Botet Escriba

2 2