- Boost - lists.preview.boost.org

Re: [boost] [Boost-commit] svn:boost r68912 - in branches/release: boost libs/utility
by Steven Watanabe 17 Feb '11

17 Feb '11

AMDG On 2/15/2011 6:54 AM, bdawes(a)acm.org wrote: > Author: bemandawes > Date: 2011-02-15 09:54:16 EST (Tue, 15 Feb 2011) > New Revision: 68912 > URL: http://svn.boost.org/trac/boost/changeset/68912 > > Log: > Merge trunk BOOST_ASSERT_MSG additions > Properties modified: > branches/release/boost/static_assert.hpp (contents, props changed) > branches/release/libs/utility/assert.html (contents, props changed) > branches/release/libs/utility/assert_test.cpp (contents, props changed) > Text files modified: > branches/release/boost/static_assert.hpp | 10 ++++- > branches/release/libs/utility/assert.html | 74 ++++++++++++++++++++++++++++++++++----- > branches/release/libs/utility/assert_test.cpp | 44 +++++++++++++++++++++++ > 3 files changed, 116 insertions(+), 12 deletions(-) > First of all, this breaks the tests because it merges the tests for BOOST_ASSERT_MSG, but not the header. Second, this is a new feature. Shouldn't it wait till after 1.46 goes out? In Christ, Steven Watanabe

4 4

Serialization of std::shared_ptr
by Loïc Joly 16 Feb '11

16 Feb '11

Hello, I'm using the std::shared_ptr provided with MSVC 2010. I'd like to be able to use boost.serialization to serialize some of those shared_ptrs. I could find an old thread stating that std::tr1::shared_ptr were not handled (and it looked impossible to make them work). Is the situation the same with std::shared_ptr? I thought of the "solution" of using boost::shared_ptr instead of std::shared_ptr, but it is currently not the prefered option: We have parts of our program independant from boost that use std::shared_ptr, we would like those parts to remain independant from boost. And we have other parts of our program where shared_ptr is used without qualification, and where a "using namespace std" directive is active. Switching to boost would incur either qualifying all shared_ptr uses, or adding a "using namespace boost" but that would introduce ambiguities. Thank you for your help! -- Loïc

2 3

[1.46.0] Final release procedure this Sunday?
by Beman Dawes 16 Feb '11

16 Feb '11

I'd like to start the final release procedure for 1.46.0 on Sunday, the 20th. That's mostly for personal reasons; next week is going to be very busy for me, so its either this Sunday or not until the following Sunday. Starting final release on Sunday means Friday is really the last day to merge fixes. Otherwise there isn't time for enough tests to cycle. Is that schedule OK? --Beman

1 0

[UTF String] UTF String library 1.5 ready for perusal
by Chad Nelson 16 Feb '11

16 Feb '11

It's a little later than I'd planned, but the second version of the UTF String library is now available for download, at <http://www.oakcircle.com/toolkit.html>. I'd appreciate comments or (constructive) criticisms on it. This version is substantially better than the original. The design has been somewhat simplified, removing extraneous features like null-string emulation. Each of the classes now contain as many of the std::string functions as I could efficiently add (essentially all of them in utf32_t), including I/O stream functions, and also features code-point iterators. It includes conversion classes for many common code-pages too. (I have not yet added true *character* iterators. That's going to require more study. But the code-point iterators should be pretty useful even without that.) There may well be bugs in it. I've only just completed it, I haven't used this version in anything but test code yet. It's also still *not* ready for submission... it's closer, but at the very least I'd like to add a few more code-pages to it first (so it can handle any code-page that Windows is likely to throw at it), and break up the code-page cpp files. Artyom, it might interest you to note that its capabilities are very similar to those outlined in your "realistic API proposal" (<http://lists.boost.org/Archives/boost/2011/01/176046.php>), though the design itself is different. It doesn't handle Unicode normalization, case handling, comparison, or search, but all the other capabilities are there. Your API could be implemented on top of utf8_t fairly easily. -- Chad Nelson Oak Circle Software, Inc. * * *

12 34

[C++0x] Emulation of scoped enums
by Beman Dawes 16 Feb '11

16 Feb '11

The improved type safety of the C++0x scoped enum feature is attractive, so I'd like to start using it as it becomes available in compilers. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a description. Note that the committee changed the name from strongly typed enums to scoped enums. See the attached for a boost/detail header that provides macro wrappers that use scoped enums if available, otherwise fall back on C++03 namespaces and unscoped enums. It lets a library write: BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END ... BOOST_SCOPED_ENUM(algae) sample( algae::red ); void func(BOOST_SCOPED_ENUM(algae)); and then a user can write: sample = algae::green; func( algae::cyan ); Comments or suggestions appreciated, --Beman // scoped_enum_emulation.hpp ---------------------------------------------------------// // Copyright Beman Dawes, 2009 // Distributed under the Boost Software License, Version 1.0. // See http://www.boost.org/LICENSE_1_0.txt // Generates C++0x scoped enums if the feature is present, otherwise emulates C++0x // scoped enums with C++03 namespaces and enums. The Boost.Config BOOST_NO_SCOPED_ENUMS // macro is used to detect feature support. // // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying type. // // See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a // description of the feature. Note that the committee changed the name from // strongly typed enums to scoped enums. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); #ifndef BOOST_SCOPED_ENUM_EMULATION_HPP #define BOOST_SCOPED_ENUM_EMULATION_HPP #include <boost/config.hpp> #ifndef BOOST_NO_SCOPED_ENUMS # define BOOST_SCOPED_ENUM_START(name) enum class name # define BOOST_SCOPED_ENUM_END # define BOOST_SCOPED_ENUM(name) name #else # define BOOST_SCOPED_ENUM_START(name) namespace name { enum enum_t # define BOOST_SCOPED_ENUM_END } # define BOOST_SCOPED_ENUM(name) name::enum_t #endif #endif // BOOST_SCOPED_ENUM_EMULATION_HPP

14 27

Preventing Boost.Pool from allocating too much memory - need your help.
by John Maddock 16 Feb '11

16 Feb '11

There is a long standing bug against Boost.Pool that points out that it allocates far too much memory when the size of the requested block is oddly sized: https://svn.boost.org/trac/boost/ticket/1252 For example if you request blocks of size 1501 bytes then you actually get 6004 byte sized blocks because Pool uses LCM to calculate a size that can store both a pointer and the requested block. There's some dispute on the Trac ticket whether the correct solution is to just round up the block size to a multiple of the pointer size. I'd like to run my take on this past you all and check I have the right fix ;-) ! So here goes - if we round up to the nearest multiple of pointer-alignment-size then: 1) The actual alignment requirements of the block (which only the client of Boost.Pool knows) must be a factor of the block size (otherwise arrays of blocks would be incorrectly aligned). 2) If the requested block has an alignment requirement >= pointer type, then of necessity alignment_of<void*>::value will be a factor of the block size and no rounding occurs or is necessary. 3) If the requested block has an alignment requirement < pointer type, then we may round up the block size, but this will only *increase* the alignment of the returned blocks so is always safe. Note that (2) assumes that all alignments are powers of 2, if that isn't true, then all bets are off. But I'm assuming there are no real-world architectures that violate that assumption? Thanks in advance, John.

1 0

[Serialization] extra_detail namespace breaks ability to multiply export classes
by Number Cruncher 16 Feb '11

16 Feb '11

I've been using serialization in a client-server application where the client and server support different archive types, and the same "message" classes need to be exported for a different set of archives in the client and server cases. For example: *Client*: links to libNetwork. libNetwork supports export of Message class by, e.g. Message.hpp: struct Message { }; BOOST_CLASS_EXPORT_KEY(Message) network.cpp: #include <network_oarchive.hpp> #include <network_iarchive.hpp> #include <Message.hpp> BOOST_CLASS_EXPORT_IMPLEMENT(Message) template void Message::serialize<network_oarchive>(.......); template void Message::serialize<network_iarchive>(.......); On the server, I also need serialization support for Message over a new archive type which only the server knows about: *Server*: links to libNetwork AND libServer. libServer supports export of Message class by, e.g. server.cpp: #include <server_oarchive.hpp> #include <server_iarchive.hpp> #include <Message.hpp> BOOST_CLASS_EXPORT_IMPLEMENT(Message) template void Message::serialize<server_oarchive>(.......); template void Message::serialize<server_iarchive>(.......); For boost 1.43 and earlier, this was all fine; the client had sufficient serialization code for its archives and so did the server. With 1.45, boost/export.hpp dropped the anonymous namespace used for GUID instatiation so now the boost::archive::detail::extra_detail::init_guid<Message>::g symbol is multiply defined (first in libNetwork, then in libServer) and I can't link. If drop the BOOST_CLASS_EXPORT_IMPLEMENT from libServer, I get unregistered class exceptions on the server, because the guid_initializer in libNetwork never "knew" about my server_oarchive. What was wrong with the anonymous namespace usage? Any help appreciated, Simon

1 0

[Tokenizer]Usage and documentation
by Max 16 Feb '11

16 Feb '11

Hello, I'm using boost::tokenizer to do some simple parsing of data file in a format specified by the following rules: - One record of several fields in a single line - Adjacent data fields in a record separated by space char's(space or tab), with or without "," - String without space(s), with or without quotation marks - String with space(s), with quotation marks One example of a 4-field-per-record file is like: "string 2" 3 4 5 4.3 "String", 2, 3.04 4 3 AnyOtherText, 2, 3.04 4 3 I am using the following code to get a line at first, supposing 'input' has the contents of the data file: typedef boost::tokenizer<boost::char_separator<char> > tokenizer; boost::char_separator<char> sep("\n", " "); tokenizer tokens(input, sep); for(tokenizer::iterator beg=tokens.begin(); beg!=tokens.end(); ++beg) { } Then for each *beg, I parse each line with this typedef boost::tokenizer<boost::char_separator<char> > tokenizer; tokenizer tokens (*beg, boost::char_separator<char>(", ")); tokenizer::iterator it= tokens.begin(); But I cannot get the expected output. And, at the mean time, I found the doc of boost::tokenizer quite slim and not easy to find the information that I need. Does anybody else have the same feeling, or, is the fact that nobody is actually using it but turning to any other better lib? Thanks for any help. B/Rgds Max

4 12

Re: [boost] Boost.Dynamic Config
by Ivan Le Lann 16 Feb '11

16 Feb '11

----- "Dan Weber" <dan(a)marketsoup.com> a écrit : > Hi Mathias, > > I've found that property_tree and program_options are deficient in > solving this problem. > > For instance, property_tree requires full serialization back and > forth > for each time you write to the underlying data store, so it could not > guarantee that it has the most accurate data all the time. > Maybe property_tree can be extended to support this use case. It seems Boost.MultiIndex usage is isolated in implementation. Is there anything that prevents basic_ptree to use an adaptor to external data source ? Regards, Ivan.

2 1

Re: [boost] [Boost-interest] C++ library for runtime-concepts (type-erasure)
by Andrzej Krzemienski 16 Feb '11

16 Feb '11

> DEFINE_ERASURE( Calculator, (add)(sub), > virtual double add(double) = 0; > virtual double sub(double) = 0; > ) > I would like feedback on how such an implementation would be received by the community. Hi, I think this macro would not work for the following interface: DEFINE_ERASURE( Dict, (getPair), virtual pair<string, string> getPair() = 0; ) This is because the comma comma 'pair' will be interpreted as separatinh third from the fourth macro param. Regards, &rzej

2 1

Initial review of Boost Process
by Edward Diener 16 Feb '11

16 Feb '11

This is an initial review of Boost Process based just on reading the documentation, I hope to find some time to try out the library within the next few days. I am pretty knowledgable about child processes, more on Windows than Linux, but I understand well how starting another process works in general. I was able to generate the documentation from the jamfile in the doc directory of the library. The documentation updated the targets successfully but there were a few messages which need to be fixed: "xslt-xsltproc.windows bin\msvc-10.0\debug\threading-multi\autodoc-xml.doxygen xslt-xsltproc.windows bin\msvc-10.0\debug\threading-multi\autodoc-xml.boostbook common.copy autodoc.xml bin\msvc-10.0\debug\threading-multi\autodoc-xml.boostbook 1 file(s) copied. xslt-xsltproc.windows bin\msvc-10.0\debug\threading-multi\process.docbook Cannot find method named 'boost::process::detail::basic_status::async_wait' Cannot find method named 'boost::process::detail::basic_status::async_wait' Cannot find class named 'boost::system::system_error' Cannot find class named 'boost::system::system_error' Cannot find class named 'boost::filesystem::filesystem_error' Reference to class 'pipe' is ambiguous. Found: Match in namespace ::boost::process:: Match in namespace ::boost::process::behavior:: Reference to class 'pipe' is ambiguous. Found: Match in namespace ::boost::process:: Match in namespace ::boost::process::behavior:: xslt-xsltproc-dir.windows html\standalone_HTML.manifest Computing chunks... Writing standalone_HTML.manifest ...updated 13 targets..." In the "Configuring runtime contexts" topic I did not feel there is a clear explanation of some of the context members. What is the 'env' member ? The synopsis says it is of type 'environment' but there is no explanation what this means. Is the parent's environment inherited by the child process ? Are there any environment variables automatically inherited by the child process ? The context's streams member and its meaning is incomplete. What is the stream_type ? The various built-in functors, which are described as behaviors are also incomplete in their explanation. What these are, and what they do, needs to be explained. The synopsis doc for the stream_id says it is a "NativeStreamId" but it does not tell one what that is. Are streams other than standard input, standard output, or standard error supported ? In the "Communicating with Child Processes" documentation, it mentions the various pipe behaviors. An example is given of synchronous I/O using 'pipe'. But then the last line tells us that for asynchronous I/O one uses 'pipe'. This is confusing. In the "Asynchronous I/O" section it repeats again that one uses 'pipe' for ansynchronous I/O but then the example uses 'async_pipe' instead. Again this is very confusing. In the "Terminating a Process" section it does not explain how a process is terminated. I think that needs to be in there. In the "Creating new stream behaviors" section I am shown example code for redirecting a stream but there is no explanation of how this works. There needs to be. It would be nice if some mention were made about Boost.Interprocess and if there is any redundancy between Process and the facilities in the Interprocess library. Also any needed explanation of how one uses Process with the facilities in Boost.Interprocess would be helpful. I think the documentation is organized well but is too sparse in places. I will try to use Process and hopefully I can review it further. But I would not initially recommend it with documentation which is this incomplete. The design does seem both clean and focused on what creating, communicating, and controlling a child process is supposed to do, and I like it that the library seeks to do specific things and not try to overextend itself. But it clearly needs a fuller doc. Edward Diener

1 0

[string] Yet another Unicode string class
by Anders Dalvander 15 Feb '11

15 Feb '11

I'm working on yet another Unicode string class/library from another set of features and requirements. * It is designed around the codepoint concept. * It uses (currently forward-) iterators for encoding and decoding. * It has a minimal interface, mostly constructors and iterator access. * Most other functions can (hopefully) be free functions. * It uses basic_string as backend. * It has fast access to underlying basic_string. * It is (currently) using some C++0X features (mainly decltype). * It is (currently) immutable and shares data, and thus fast to copy. Some of these features and requirements may be unacceptable to some of you, but I'm open to suggestions and comments. // Copyright (c) 2011 Anders Dalvander. // // Distributed under the Boost Software License, Version 1.0. // (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) template <typename encoding> class basic_text { public: typedef encoding encoding_type; typedef typename encoding_type::codeunit_type codeunit_type; typedef typename encoding_type::codepoint_type codepoint_type; typedef std::basic_string<codeunit_type> string_type; typedef typename string_type::const_iterator codeunit_iterator; typedef typename encoding_type::decode_iterator<codeunit_iterator> codepoint_iterator; typedef codepoint_iterator const_iterator; typedef codepoint_iterator iterator; basic_text() : s(std::make_shared<string_type>()) { } template <typename other_encoding> basic_text(const basic_text<other_encoding>& text) : s(std::make_shared<string_type>( encoding_type::encode_iterator<decltype(std::begin(text))> (std::begin(text), std::begin(text), std::end(text)), encoding_type::encode_iterator<decltype(std::begin(text))> (std::end(text), std::begin(text), std::end(text)))) { } // TODO: Use some default_encoding traits type. template <typename container> explicit basic_text(const container& c) : s(std::make_shared<string_type>( encoding_type::encode_iterator<decltype(std::begin(c))> (std::begin(c), std::begin(c), std::end(c)), encoding_type::encode_iterator<decltype(std::begin(c))> (std::end(c), std::begin(c), std::end(c)))) { } template <typename codepoint_iterator> basic_text(codepoint_iterator first, codepoint_iterator last) : s(std::make_shared<string_type>( encoding_type::encode_iterator<codepoint_iterator> (first, first, last), encoding_type::encode_iterator<codepoint_iterator> (last, first, last))) { } codepoint_iterator begin() const { return codepoint_iterator (codeunit_begin(), codeunit_begin(), codeunit_end()); } codepoint_iterator end() const { return codepoint_iterator (codeunit_end(), codeunit_begin(), codeunit_end()); } codeunit_iterator codeunit_begin() const { return std::begin(*s); } codeunit_iterator codeunit_end() const { return std::end(*s); } const string_type& str() const { return *s; } const codeunit_type* c_str() const { return s->c_str(); } private: typedef std::shared_ptr<const string_type> pointer_type; pointer_type s; }; typedef undefined-type utf8_encoding; typedef basic_text<utf8_encoding> u8text; typedef undefined-type utf16_encoding; typedef basic_text<utf16_encoding> u16text; typedef undefined-type utf32_encoding; typedef basic_text<utf32_encoding> u32text; typedef undefined-type wchar_encoding; typedef basic_text<wchar_encoding> wtext; typedef undefined-type ascii_encoding; typedef basic_text<ascii_encoding> ascii_text; Usage: int main() { const uint32_t cps[] = {0x41,0x42,0x80,0x800,0x10000,0x10ffff}; // construct from codepoint range u8text u8txt(std::begin(cps), std::end(cps)); // construct from encoded container, // currently treats each element as a codepoint u8text u8txt2("test"); // sharing is caring u8text u8txt3 = u8txt; // construct from codepoint range u16text u16txt(std::begin(cps), std::end(cps)); // construct from text, transcodes range u16text u16txt2 = u8txt; // construct from text, transcodes range u32text u32txt = u8txt; // using policy (possible extension) ascii_text ascii(u8txt, replace_policy(0xff)); } void OpenFileWin32(const u8text& txt) { CloseHandle(CreateFileW(wtext(txt).c_str(), ...)) } typedef undefined-type posix_encoding; typedef basic_text<posix_encoding> posixtext; void OpenFilePosix(const u8text& txt) { close(open(posixtext(txt).c_str(), ...)) } Regards, Anders Dalvander -- WWFSMD?

10 14

Re: [boost] [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
by Darren Garvey 15 Feb '11

15 Feb '11

On 11 February 2011 23:30, Boris Schaeling <boris(a)highscore.de> wrote: > On Fri, 11 Feb 2011 16:39:35 +0100, Jeff Flinn < > TriumphSprint2000(a)hotmail.com> wrote: > > [...]I think with the right abstractions the seemingly contradictory goals >> can be accommodated. That's what I'm attempting to find. As stated at a >> previous boostcon: "... abstractions are discovered not invented..." >> >> >> IMHO, previous version of process have not discovered the proper >> abstractions. I'm sure that the entirely different paradigms between windows >> and posix have contributed to the difficulties so far. It's difficult to be >> a master of the subject matter in both domains. >> >> I think building upon existing boost filesystem and iostreams libraries >> and their abstractions that do successfully address platform differences >> will make the effort more successful. Additionally I think it's mandatory >> for a design to directly acknowledge the multi-phase constraints of the >> fork/exec paradigm. Also it's mandatory to break down the historical >> monolithic approaches into more tenable pieces. >> > > Thanks for your comments, Jeff, Ilya and Nat! How would you (and others) > feel about a Boost.Process library which only aims to replace std::system() > with a more powerful function? You could configure the child process a bit > (its streams, environment variables and a few more things) and that's all. > This would be a less ambitious goal but obviously more easily to reach. I > was under the impression that we want more? Maybe we still want more but > settle realistically for this goal? I've not caught up on all of the discussion about the pending review yet, but it seems to be hitting a few familiar issues this time around, unfortunately. I'd like Boost.Process to either mimic the Python subprocess module (as Nat mentioned) or to provide a few low-level pieces: 1. std::system replacement allowing me to do the call in an async way and capture the output. Ideally implemented in such a way that a "process pipeline" library could be implemented on top of Boost.Process. Pipelining input / output between different work items is a more general domain than fits in Boost.Process, IMHO. 2. Way to get process id in a platform independent way. 3. Way to look up location of processes and get a Boost.Filesystem path. 4. Version of "std::system" that works with Boost.Filesystem 5. Version of std::system that allows passing a custom set of environment variables 6. Expose a "native_handle_type" from the library, whatever that native handle type is. There seems to be a lot of justified disagreement about what the high-level view of the library should be, yet all but point 1 are almost trivially implemented in a cross-platform way and entirely orthogonal to the rest of any Boost.Process library. I'd like to see just points 2-6 addressed, reviewed and released before tackling the bigger picture. The disagreements over scope are a showstopper for any progress and threaten to lead Boost.Process astray for another another couple of years unless they are worked around, ie. by reducing scope, perhaps to the point that Boost.Process starts life as a basic utility library. Evolutionary rewrites and breaking changes are much better than nothing. After all, we're up to V2.x of Boost.Spirit and V3 of Boost.Filesystem and all versions have been immensely useful for us end users. Kind Regards, Darren

5 24

Implicit Convert from own Typ to Boost::Variant Type
by a.mueller 15 Feb '11

15 Feb '11

Hi, i'm new here and i hope you can help me. My problem i have a class with a Boost Variant type as member and a implicit convert operator from my class to this Variant type. But when i want use the conversion in my programm the Compiler give me a error. Compiler Version gcc 4.4.1 on Ubuntu system Boost version 1.45 Example Program: #include <iostream> #include <boost/variant.hpp> #include <boost/lexical_cast.hpp> using namespace std; 　 typedef boost::variant<float,int> Testtyp; class Testtypcontainer { public: Testtypcontainer():m_testtyp((float) 5.5){} Testtyp m_testtyp; template<class T> void settesttyp(T testvalue){m_testtyp =testvalue;} Testtyp gettesttyp(){return m_testtyp;} operator Testtyp() const{ return m_testtyp; } }; int main(){ Testtyp help1; Testtypcontainer help3; cout<<help3.gettesttyp()<<endl; help1=(Testtyp)help3; // generate compile error return 0; } P.s. Sorry for my bad english

2 2

Boost.Dynamic Config
by Dan Weber 15 Feb '11

15 Feb '11

Hi guys, I feel as part of the Boost community and having worked on multiple platforms that we're missing something to manage reading/writing configuration information for an application thread safely across platforms. The best example I know of that handles this job is Qt's QSettings which writes to the registry on windows, inis on linux, and some sort of xml on Mac OS X. The inspiration for this comes from the fact that I am looking to build web browser plugins that run on multiple platforms. I started by looking at how I could extend boost::program_options, and decided it wasn't the right tool because it was primarily for reading configurations, but not really writing to them. Likewise, it doesn't appear to provide anything in terms of thread safety. The interface should model after several things already in existence such as: QSettings, std::map, and tbb::concurrent_hash_map. It should also take into consideration how systems such as the Windows Registry works, as well as browser specific configuration systems like the one that comes with Mozilla Firefox, and of course file based storage. It should be easily extensible with a simple interface to implement a new backend with minimal work. At a later date, I think it should also be able to support things like boost::property_map or boost::fusion to make it easy to insert and extract objects from the underlying configuration system with automatic type conversion. I'm not sure how to combine it with boost::fusion or boost::property_map yet, so I'm hoping that's where you guys come in. Thanks, Dan Here is a preliminary interface: namespace boost { namespace dynamic_config { template<typename charT> class backend { public: enum operation_performed { none, // e.g. no value changed insert, update }; bool insert(basic_string<charT> key, (int, basic_string<charT>, bool, int64_t, char) value); // These values may be easily implementable with boost::variant, or separately if enable_if is used. bool update(basic_string<charT> key, (see above..) value); // Note this returns operation performed because optional locking will be done around these functions, so combining insert with update replaces a possible race condition over those 2 operations performed separately operation_performed replace(basic_string<charT> key, (...) value); template <T> bool select(basic_string<charT> key, T& value); // returns success if retrieved, this can also use boost::optional otherwise bool delete(basic_string<charT> key, bool cascade); // cascade takes effect if key takes a whole tree with it }; template <typename charT, typename Backend, typename Mutex> class property_config : boost::noncopyable { public: property_config(); property_config(basic_string<charT> organizationName, basic_string<charT> applicationName); // Pretty much required for use in the windows registry and in firefox ~property_config(); size_type erase(basic_string<charT> key); void clear(); template<typename T> bool find(basic_string<charT> key, T & value); template<typename T> bool insert(basic_string<charT> key, T value); template<typename T> bool update(basic_string<charT> key, T value); template<typename T> backend::operation_performed replace(basic_string<charT> key, T value); template<typename T> bool select(basic_string<charT> key, T& value); template<typename T> bool delete(basic_string<charT> key, T& value); }; template <typename charT, typename Backend, typename Mutex> template <typename T> backend::operation_performed property_config<charT, Backend, Mutex>::replace(basic_string<charT> key, T val) { scoped_lock(mutex_); backend_.replace(key,val); } } }

4 6

Bug fix in WFMO from the Boost vault
by Emil Dotchevski 14 Feb '11

14 Feb '11

Hello, I had uploaded a portable Wait For Multiple Objects based on Boost Thread in the vault. Few months ago a memory leak was reported and I finally fixed it this weekend. If you're one of the few people using it, you can download the new version from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=wfmo.z…. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[Git] Boost Filesystem now has public GitHub repository
by Beman Dawes 14 Feb '11

14 Feb '11

I'm now doing routine maintenance and development of the Boost Filesystem library via a public Git repository hosted on GitHub. See https://github.com/Beman/filesystem The point of this public repo is to gain actual use experience with Git and with a modularized Boost library. Modularization followed the pattern ryppl is proposing - the top level directory is the same as the current SVN list/filesystem, with the addition an "include" directory with a "boost" sub-directory containing the current SVN boost/filesystem stuff. None of the existing filesystem content was changed. So that the development environment will be identical to the current SVN trunk, I setup my local filesystem trunk repository using a little script: svn export %BOOST_TRUNK% fs-trunk cd fs-trunk/libs rm -r filesystem git clone git@github.com:Beman/filesystem.git filesystem cd ..\boost del filesystem.hpp rm -r filesystem mklink filesystem.hpp ..\libs\filesystem\include\boost\filesystem.hpp mklink /d filesystem ..\libs\filesystem\include\boost\filesystem The effect is to export the SVN trunk, then replace libs/filesystem with a git clone of the public repository. boost/filesystem is replaced with a symlink to libs\filesystem\include\boost\filesystem Note that no changes whatsoever needed to be made to either my Visual Studio or Boost.Build setups, Jamfiles, or anything else. Everything just works. The setup is a pleasure to use. I commit changes locally whenever it makes sense, without any need to maintain stability. Then when work reaches a stable state, I push it out to GitHub. When it comes time to apply the changes to the Boost repo, I'm applying the diffs locally and then committing. If Boost were using Git, I'd send a "pull" request. So far this whole experiment has been very reassuring. No problems and everything worked instantly. There was almost no learning curve, since I'd already been using Git and GitHub for awhile. --Beman

9 17

[config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?
by Mostafa 14 Feb '11

14 Feb '11

Hi, I propose the introduction of BOOST_SYMBOL_IMPORT_VISIBLE to Boost.Config that behaves like BOOST_SYMBOL_IMPORT in all cases except gcc (and like compilers?) where it expands to "__attribute__((visibility("default")))". I believe this is need to address the following two scenarios: (For gcc, assume all libraries are built with the following option: -fvisibility=hidden) ********** Scenario 1 ********** Export class MyException from Library A. Catch MyException in Library B, and be able to throw or rethrow it from Library B. Catch MyException in Library C. To be able to do this with gcc, MyException has to be visible from Library B since the exception handler in Library C will look for the class definition of MyException in Library B [1]. I don't believe it's possible to do this "out of the box" with Boost.Config and still support gcc and msvc libs. Conventionally, one would do the following: //--------------- //Start Library A //--------------- #ifdef MYLIB_BUILD #define MYLIB_API BOOST_SYMBOL_EXPORT #else #define MYLIB_API_BOOST_SYMBOL_IMPORT #endif class MYLIB_API MyException ... { ... }; //------------- //End Library A //------------- But this technique fails to make MyException visible from Library B with gcc. And where I to use BOOST_SYMBOL_VISIBLE instead, it would fail to export MyException from Library A with msvc. ********** Scenario 2 ********** Export class MyShape from Library A. Import class MyShape from Library A into Library B and have Library B export the following the function: MyShape & foo(); Import MyShape and foo into Library C, and Library C export the function: MyShape & bar(); To be able to do this with gcc, MyShape has to be visible from Library B and Library C [2]. Conventionally, one would do the following: //--------------- //Start Library A //--------------- #ifdef LIB_A_BUILD #define LIB_A_API BOOST_SYMBOL_EXPORT #else #define LIB_A_API_BOOST_SYMBOL_IMPORT #endif class LIB_A_API MyShape ... { ... }; //--------------- //Start Library B //--------------- #ifdef LIB_B_BUILD #define LIB_B_API BOOST_SYMBOL_EXPORT #else #define LIB_B_API_BOOST_SYMBOL_IMPORT #endif LIB_B_API MyShape & foo(); //--------------- //Start Library C //--------------- #ifdef LIB_C_BUILD #define LIB_C_API BOOST_SYMBOL_EXPORT #else #define LIB_C_API_BOOST_SYMBOL_IMPORT #endif LIB_C_API MyShape & bar(); But this leads back to the same problem/proposed solution as Scenario 1. Thanks in advance, Mostafa [1] http://gcc.gnu.org/wiki/Visibility: "Problems with C++ exceptions (please read!)", 2nd Paragraph. [2] http://gcc.gnu.org/wiki/Visibility: "Problems with C++ exceptions (please read!)", 3rd Paragraph.

7 22

Re: [boost] [UTF String] Feedback on UTF String library, please
by Brent Spillner 14 Feb '11

14 Feb '11

On 2/11/2001 17:05:25, Phil Endecott wrote: >Brent Spillner wrote: >>>Just when is it really valid to want to jump the 278th "abstract >>>character" in a string? >>> >>>Seriously, how often do these situations arise? >> >> Well, Boyer-Moore string searching, obviously. > >If you're doing Boyer-Moore on a UTF-8 string you should normally do it >on the bytes, not on the codepoints, so there is no need for random >access to the codepoints. This works because of the particular >properties of UTF-8, and will be faster because you don't have the >overhead of the UTF-8 decoding. The discussion was about 'abstract characters,' not codepoints. I think a codepoint iterator is likely useful too, but for most applications the character view is required. >The exception would be if you want to do comparison at the "grapheme >cluster" level, i.e. if you want to consider a single-codepoint, >multi-byte representation of e.g. an accented character as equal to the >multiple-codepoint, multi-byte representation comprising a base Yes, I think that's the behavior desired for most applications. >character plus a combining accent. I would suggest that it would be >better to first normalise your strings, so that this doesn't arise. ...but I think that's a little too glib. If you have the string "résumé" in your data store, and a user enters "resume" as a search key, then you either have to search independently for each plausible variant for "resume," or you have to maintain a parallel, accent-free copy of the original text and the means to translate indices into the accent-free version into indices into the rich version, or you have to have some notion of 'abstract character' comparison and iteration. I think the last solution is by far the most preferable, particularly for a low-level library. This is how people actually use strings in practice, after all. >Even if you did want to do Boyer-Moore on the codepoint-sequence, I >think that using std::advance to move a bidirectional iterator would >not change its complexity order. It clearly won't; you need to ::advance at most O(n) times, and Boyer-Moore is already a linear complexity algorithm (and I'd be amazed to see a sublinear one for the general case.) But since the whole algorithm is linear, those extra O(n) iterator advancements past code units that you already know to be irrelevant could be a measurable contributor to the total run time. >Are you suggesting some sort of indexed string? I guess you could use >an augmented tree to provide O(log N) access to the N'th character in a >UTF-8 string. In fact didn't someone propose something like that a few Yes, that's what I was thinking. >months ago? Not as a string but as a "vector whose iterators are not >invalided" or "list with random access" or something? Good to know; I'll take a look at that.

2 1

[function_types] Number of default parameters
by Lorenzo Caminiti 14 Feb '11

14 Feb '11

Hello all, Is there a way to determine at compile-time the number of parameters with default values from a function type? For example, can I program the following `count_defaults` metafunction? count_defaults< bool(*)(int x, int y) >::value // == 0 count_defaults< bool(*)(int x, int y = 1 >::value // == 1 count_defaults< bool(*)(int x = 2, int y =1) >::value // == 2 (If this is possible, it could be added to Boost.FunctionTypes.) Thank you. -- Lorenzo

5 7

TTI library updated in the sandbox to version 1.3
by Edward Diener 13 Feb '11

13 Feb '11

I have updated the TTI library in the sandbox 'tti' directory to version 1.3. 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. With this update no functionality in the library has changed, but names have changed. The major change is that the library has been Boostified for possible review. 1) The update changes the library to use the Boost naming conventions. 2) The names of the main header files have been shortened and changed to 'tti.hpp' and 'tti_vm.hpp' respectively. 3) The macros in the library now start with BOOST_TTI. 4) The main namespace is now boost::tti. 5) Other filenames now follow Boost filename convention. 6) The documentation is distributed in both HTML and PDF format with indexes, and can be regenerated. 7) The variadic macro support in the library only works with the latest version 1.3+ of the variadic_maco_data library in the sandbox. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. If you are at all interested in compile-time introspection of types, please take a look at the functionality of this library. There is a readme.txt in the top-level directory, for anyone browsing the sandbox. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1 and VC++ 8.0, 9.0, 10.0. It may also work with other compilers. Questions, comments, suggestions, and bug reports are all welcome.

2 3

[local] Bound types for concepts, etc?
by Lorenzo Caminiti 13 Feb '11

13 Feb '11

On Sun, Feb 6, 2011 at 2:25 PM, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > As I said, it does. With Boost.Local, you can still call polymorphic > functions on the variables captured from scope without specifying the types > of the arguments. I am thinking to provide the type of the bound parameters within the local function body as `<BOUND_PARAM_NAME>_type`. This way you can use such types to check concepts, etc... Is there value in this? #include <boost/local/function.hpp> #include <boost/concept_check.hpp> #include <iostream> template<typename T> class Addable { T x; T y; void return_type(T); // Used to check addition returns type `T`. public: BOOST_CONCEPT_USAGE(Addable) { return_type(x + y); // Check addition `T operator+(T x, T y)`. } }; struct pod {}; int main() { pod sum; // Can't be added. int factor = 10; BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { // In here `sum_type` and `factor_type` are the types of the respective bound parameters. BOOST_CONCEPT_ASSERT((Addable<sum_type>)); sum = sum + factor * num; // Error because `sum`'s type can't be added :( } BOOST_LOCAL_FUNCTION_END(add) add(100.0); return 0; } On GCC: $ g++ -Wall -Werror -I../../.. concepts.00.cpp concepts.00.cpp: In static member function ‘static void main()::boost_local_auxXfunctorXadd::boost_local_auxXbody(main()::boost_local_auxXfunctorXadd&, int, main()::boost_se_capture_t_1_add35&, double)’: concepts.00.cpp:39: error: no match for ‘operator+’ in ‘sum + (#‘float_expr’ not supported by dump_expr#<expression error> * num)’ concepts.00.cpp: In destructor ‘Addable<T>::~Addable() [with T = pod]’: /usr/include/boost/concept/detail/general.hpp:29: instantiated from ‘static void boost::concept::requirement<Model>::failed() [with Model = Addable<pod>]’ concepts.00.cpp:37: instantiated from here concepts.00.cpp:22: error: no match for ‘operator+’ in ‘((Addable<pod>*)this)->Addable<pod>::x + ((Addable<pod>*)this)->Addable<pod>::y’ Note: In this specific case even the GCC error without the concept assert (error on line 39) is pretty clear but in general allowing programmer to add concept specifications might lead to better error reporting and a better specification of the local function. -- Lorenzo

2 2

Variadic_macro_data library updated to version 1.3
by Edward Diener 13 Feb '11

13 Feb '11

I have updated the variadic_macro_data library in the sandbox 'variadic_macro_data' directory to version 1.3. 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. With this update no functionality in the library has changed, but names have changed. The major change is that the library has been Boostified for possible review. 1) The update changes the library to use the Boost naming conventions. 2) The name of the main header file has been shortened and changed to 'vmd.hpp'. 3) The macros in the library now start with BOOST_VMD. 4) Other filenames now follow Boost filename convention. 5) The documentation is distributed in both HTML and PDF format with indexes, and can be regenerated. There is a readme.txt in the top-level sandbox directory, for anyone browsing the sandbox. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.3.3, 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1 and VC++ 8.0, 9.0, 10.0. It should also work with other compilers which support variadic macros. Questions, comments, suggestions, and bug reports are all welcome.

1 0

Errors in "getting started" documentation
by Loïc Joly 12 Feb '11

12 Feb '11

Hello, I recently upgraded to the 1.45 version on windows, with VC++2010. I noticed several errors in the documentation. I think they are really important, because installation is the first thing people will ever encounter from boost, and if the installation procedure is buggy, people might decide not to look any further. http://www.boost.org/doc/libs/1_45_0/more/getting_started/windows.html#get-… If we get a prebuild bjam program, the compilation step will fail. We need to get a bjam by executing the bootstrap file in the distribution, not by downloading it. http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.r… This section does not refer to msvc 10.0, so it may look like this compiler version is not supported. (btw, should this kind of problem be reported in trac or here ?) Regards, -- Loïc Joly

1 0

Re: [boost] [UTF String] Feedback on UTF String library, please
by Brent Spillner 12 Feb '11

12 Feb '11

On 02/11/2011 14:09:27 Marsh Ray wrote: >So let me ask the question: > >Just when is it really valid to want to jump the 278th "abstract >character" in a string? > >Seriously, how often do these situations arise? Well, Boyer-Moore string searching, obviously. And as noted previously, short snippets of null-terminated text are not the only things that people store within a std:string or behind a char *. There's a tremendous amount of data out there in fixed-column databases, for example, and undoubtedly many maintainers who'd like a painless way to upgrade the column unit from 'byte' to 'generic character.' It's also probably a logical fallacy to assume that every string algorithm on every device supported by Boost will always be cache-limited. If strings for you are just handles that you pass to other people's APIs, then no, you don't need random access to the contents. But if you're seriously aiming to create a Unicode-aware drop-in replacement for existing string classes, then it ought to support all of the existing code that assumes efficient random access. And if you can provide measurable speedup for at least the common case, even at the cost of a few extra bits per data chunk, that's worth pursuing.

2 1