December 2005 - Boost - lists.boost.org

[bug] Error in optional's converting assignment operator
by Joe Gottman 02 Feb '06

02 Feb '06

There is an error in the implementation of the converting assignment operator for optional<T>. It is currently implemented as template<class U> optional& operator= ( optional<U> const& rhs ) { this->assign(rhs.get()); return *this ; } The problem with this is that if rhs is not initialized then rhs.get() asserts. This function should be rewritten as template<class U> optional& operator= ( optional<U> const& rhs ) { if (rhs.is_initialized()) this->assign(rhs.get()); else destroy(); return *this ; } Joe Gottman

3 4

[multi_index] intrusive multi_index poll for interest
by Maxim Yegorushkin 20 Jan '06

20 Jan '06

Motivation Existing practice have shown the need for intrusive containers. Widely used C++ libraries, such as C++ Standard Library and Boost have long missed such facilities so that users had to refrain from using those due to mandatory element copying or fall back to techniques like two phase construction to insert logically non-copyable elements in containers and initialize them after that or insert pointers to dynamically allocated objects which is rather inelegant and inefficient since containers also dynamically allocate nodes. The most common use cases for intrusive containers are: * when one would like to store non-copyable elements in a container * when it's beneficial to avoid needless data copy in performance critical applications The most prominent example of both the use cases, although written for the most part in C rather than C++, is Linux kernel built solely upon intrusive lists, hash tables and trees. Basic usage An intrusive container is not a container in a stl sense, since it does not own its elements. The sole purpose of an intrusive container is to establish ordering between elements. It's a user responsibility to keep an intrusive container up-to-date by calling replace() to alter fields upon which an order is established as well as erase the nodes from the container prior to node's destruction. Aside from that the look and feel are similar to those of an non-intrusive container. Here is how one would declare an intrusive container, an intrusive node and insert removes nodes: struct record; typedef multi_index_container<intrusive<record> > container; struct record : container::node_type {}; bool operator<(record const& a, record const& b); void insert_sample(container* c) { std::auto_ptr<record> p(new record); if(c->insert(*p).second) p.release(); } void erase_sample(container* c, container::iterator pos) { std::auto_ptr<record const> p(&*pos); c->erase(pos); } Here is how one would make a multi-node, i.e. a node that can be enlisted into several containers simultaneously: struct record; struct tag1; struct tag2; typedef multi_index_container<intrusive<record, tag1> > container1; typedef multi_index_container<intrusive<record, tag2> > container2; struct record : container1::node_type, container2::node_type {}; inline bool operator<(record const& a, record const& b); void insert_sample(container1* c1, container2* c2) { struct guard { container1* c1; container2* c2; std::pair<container1::iterator, bool> i1; std::pair<container2::iterator, bool> i2; std::auto_ptr<record> p; ~guard() { if(i1.second && i2.second) { p.release(); } else { c1->erase(i1.first); c2->erase(i2.first); } } guard(container1* c1, container2* c2, std::auto_ptr<record> p) : c1(c1), c2(c2), i1(c1->end(), 0), i2(c2->end(), 0), p(p) {} } guard(c1, c2, std::auto_ptr<record>(new record)); guard.i1 = c1->insert(*guard.p); guard.i2 = c2->insert(*guard.p); } void erase_sample(container1* c1, container2* c2, record* r) { c1->erase(c1->make_iterator(r)); c2->erase(c2->make_iterator(r)); delete r; } The examples are included in test_intrusive.cpp. Current implementation Current implementation although efficient and mostly functional is a proof of concept only. Further design work is required which we rather unclear about and therefore would like to poll for interest and suggestions. Known limitations: * partial template specialization support is required * dereferencing an intrusive container iterator yields a constant, should probably return non-constant * safe mode is not implemented for make_iterator() exposed api http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam…

4 8

BOSOT_ENUM proposal rev 4
by Frank Laub 19 Jan '06

19 Jan '06

I've updated the BOOST_ENUM stuff in the file vault: *http://tinyurl.com/cznqu * Currently, there are three flavors of enumerated types available. 1. BOOST_ENUM This type of enum provides the user with a simple way to express an enum. example usage: BOOST_ENUM(boolean, (False) (True) ) This flavor does not allow each element of the enum to be defined. It is assumed that the first element will begin with the value 0 and the last element will be equal to the count of elements - 1. The following methods are available with this type: static const_iterator begin() static const_iterator end() static boost::optional<const T> get(size_t index) static boost::optional<const T> parse(const char* str) const char* str() const bool operator == (const T& rhs) const bool operator != (const T& rhs) const ostream& operator << (ostream& os, const T& rhs) 2. BOOST_ENUM_VALUES This flavor of enum is the same as the basic enum flavor but it allows the user to specify values for each element. example usage: BOOST_ENUM_VALUES(VirtualKey, (Space)(0x20) (Prior)(0x21) (Next)(0x22) (End)(0x23) (Home)(0x24) ) In addition to the methods described above with the basic flavor, these are also available: static boost::optional<const T> make(size_t value) size_t value() const 3. BOOST_BITFIELD A bitfield is much like a BOOST_ENUM_VALUES except that each value is interpreted as a bitmask. This allows many common bitmask operations to be done in a more elegant way; forcing the user to only use bitmasks that are in the domain of the defined bitfield. example usage: BOOST_BITFIELD(MouseKey, (LeftButton)(0x0001) (RightButton)(0x0002) (Shift)(0x0004) (Control)(0x0008) (MiddleButton)(0x0010) ) This type has all of the methods defined for a BOOST_ENUM_VALUES along with these: static T all_mask() std::string str() const void operator |= (const T& rhs) T operator | (const T& rhs) const size_t operator & (const T& rhs) const // TODO: add some more of these like &=, ~, etc. str() for this type returns a string instead of a const char* because it has to generate the string on the fly for each instance. Perhaps there is a more compile-time approach, but I think this would involve lots of tagged type lists and such. Taking the MouseKey as an example, one can do this: MouseKey mkLeft = MouseKey::LeftButton; MouseKey mkShift = MouseKey::Shift; MouseKey mk = mkLeft | mkShift; cout << mk << endl; The output will be: LeftButton | Shift Implementation notes: Instead of needing an 'Invalid' element, I just use Boost.Optional now. Thanks a ton for that suggestion Yuval! Using a switch/case instead of an array for storage of the strings and values of the enum turned out to be pretty straight-forward. With this approach, as was noted earlier, there should be no thread safety issues. I've looked at the disassembly of an optimized example with VC8 and it looks like the compiler just gets rid of all the overhead anyway. I also found that using a switch/case made it possible to be re-used across the many flavors. These types are now instanciable, and I think it is much easier/cleaner to use. Instances of BOOST_ENUM and BOOST_ENUM_VALUES store not the value of the enum element, but the index that it appears in the defining sequence. BOOST_ENUM is actually special because its index always matches its value. Because of this, BOOST_ENUM_VALUES takes a small hit for the make() method because it needs to walk through all of the available values and find one that matches. The tricky thing for the user is that make() will return the first element that matches. So if a user defines A and B to both be equal to 10, and the user calls make(10), it will return A. However if the user defines B before A, make(10) will return B. BOOST_BITFIELD stores the actual raw value so that all of the bitwise operators will be fast and efficient. In a previous attempt to write this flavor, I used a std::set<size_t> of indicies. This is expensive both for the bitwise operators and the storage requirements for each instance of this type. The consequence of storing the raw value is that the str() method has a bit of overhead since it has to mask off each element and check to see if the remaining bits match any values defined in the sequence. It also means that, like BOOST_ENUM_VALUES, the order in which the user defines each bitfield element can change the resulting string representation. As always, any comments are much appreciated. -Frank

9 40

"Small buffer optimization" for boost::function?
by Alex Besogonov 15 Jan '06

15 Jan '06

Good <time-of-day>! Why not use 'small buffer optimization' for boost::function? Most of allocations are 8-16 bytes - an optimal size for SBO. This optimization will make boost::function _much_ faster - in one of our project boost::function is responsible for 15% of the whole processor time. PS: it will also be nice if something like http://www.codeproject.com/cpp/FastDelegate.asp will be included in Boost (and possibly in TR2). PS: Happy New Year! -- With respect, Alex Besogonov (cyberax(a)elewise.com)

7 22

[MPL.Math] Updated version now available
by Cromwell Enage 15 Jan '06

15 Jan '06

Issues addressed: * All metafunctions that can be instantiated in user code have been registered with Boost.Typeof (see typeof.cpp for a test case). Registration of each metafunction occurs at the end of the header file in which the metafunction is declared, as per the "don't pay for what you don't use" policy. * The BOOST_MPL_AUX_TYPEOF_REGISTER_TYPE_C macro, defined in <boost/mpl/aux_/typeof/register_type_c.hpp>, enables one to register metafunctions that have the following form: template < typename ValueType , ValueType N1 , ValueType N2 , ... > struct metafunction { ... }; This macro is currently used to register rational_c, mixed_number_c, and complex_number_c; it is hoped that vector_c, list_c, range_c, and integral_c will also be registered by it. (The _C suffix indicates that the macro is to be used to register types ending in _c.) * I also suspect that the recent problem with double_::aux::get_value() is one of endianness. Unfortunately I don't know which combination of macros will detect Solaris. Therefore, BOOST_MPL_CFG_IS_LITTLE_ENDIAN, defined in <boost/mpl/aux_/config/endian.hpp>, is currently set to zero. (Double-check me if I named it correctly.) * In case no one has noticed--and judging from the contents of pqs3_0_0.zip, this seems to be the case--there is now a math::inverse metafunction, so you don't need to roll your own reciprocal<>. Cromwell D. Enage __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

4 22

[asio] some stuff about ipv4::address
by Yuval Ronen 12 Jan '06

12 Jan '06

Hi. These are minor things I noticed with, and was bothered by, the asio::ipv4::address class. This is by no means an asio review (although we desperately need some networking library, that's for sure). What I dislike is the string-accepting contructor and the to_string() method. My personal taste is that textual conversions (and the ip::address class is a very good candidate for this) should be made through the standard ostream/istream operators. This has the usual advantages of using an idiom. It also provides standard means to detect parsing error using the ios_base::fail bit. The ip::address currently has the only option of throwing in the string-accepting contructor, however, this is not intuitive, IMHO (and not documented). String conversions can be easily performed using boost::lexical_cast. Another thing is the plethora of assingment operators. Wouldn't a single copy-assignment be enough? And one last suggestion: A construtor taking 4 unsigned chars, allowing this: asio::ipv4::address my_address(192, 168, 0, 1); Thanks for listening, Yuval

8 17

asio review -- IPV4/V6 issue
by Jeff Garland 12 Jan '06

12 Jan '06

A group of folks here in Phoenix got together and had a little asio 'review party'. Before we had too many beers to be useful, there was one primary issue the group discussed that I'd like to bring to the list -- some minor stuff will go offlist to Christopher directly. As was discussed early on in the review asio doesn't currently support ipv6. However, going forward ipv6 support is critical for the "Phoenix Group". Given the current asio interfaces it seems clear that the extension will come in the form of another namespace -- presumably asio::ipv6. This means that client code will need to be modified to make the upgrade to ipv6. The need to modify code for ipv6 support was disliked by the group. It was the consensus of this group that it would be preferable to explore a solution that could support both ipv4 and ipv6 addresses seemlessly without changes to client code. Part of the rationale for this is that most applications don't directly configure the ip addresses in code, but rather read them from configurations. Hence it would be nice if the upgrade was as simple as swithching over the configuration. Thus the same compiled app could directly support ipv4 and ipv6. Thoughts, discussion? Jeff

4 4

[iostreams] [RC_1_33_1] Currently broken on Tru64/CXX and Como 4.3.3
by Markus Schöpflin 09 Jan '06

09 Jan '06

What happened to the iostreams library? It worked fine for those compilers in 1.33.0 as can be seen on http://tinyurl.com/76dqz, but now most tests fail with the following error message: cxx -c -std strict_ansi -nopure_cname -noimplicit_include -timplicit_local -ptr "/house/schoepf/boost/regression/results/bin/boost/libs/iostreams/test/auto_close_test.test/tru64cxx71-006/debug/cxx_repository" -msg_display_number -msg_disable 186,450,1115 -DBOOST_IOSTREAMS_NO_LIB -g3 -O0 -inline none -version V7.1-006 -ieee -gall -D__CNAME_OVERLOADS -model ansi -I"/house/schoepf/boost/regression/results/bin/boost/libs/iostreams/test" -I"/house/schoepf/boost/regression/boost" -o "/house/schoepf/boost/regression/results/bin/boost/libs/iostreams/test/auto_close_test.test/tru64cxx71-006/debug/auto_close_test.o" "/house/schoepf/boost/regression/boost/libs/iostreams/test/auto_close_test.cpp" cxx: Error: /house/schoepf/boost/regression/boost/boost/iostreams/chain.hpp, line 427: #29 expected an expression { return chain_->component_type<N>(); } ---------------------------------------^ cxx: Error: /house/schoepf/boost/regression/boost/boost/iostreams/chain.hpp, line 431: #254 type name is not allowed { return chain_->component<T>(n); } -------------------------------^ cxx: Error: /house/schoepf/boost/regression/boost/boost/iostreams/chain.hpp, line 436: #254 type name is not allowed { return chain_->component<N, T>(); } ----------------------------------^ cxx: Error: /house/schoepf/boost/regression/boost/boost/iostreams/chain.hpp, line 436: #29 expected an expression { return chain_->component<N, T>(); } -------------------------------------^ cxx: Info: 4 errors detected in the compilation of "/house/schoepf/boost/regression/boost/libs/iostreams/test/auto_close_test.cpp". Does this ring a bell with anyone? Markus

3 7

[mpl] mpl::is_sequence problem
by Joel de Guzman 09 Jan '06

09 Jan '06

Hi, A few months ago, I had a problem with mpl::is_sequence. It seems that the problem is not yet fixed. Anyway, to simplify, here's the code that exhibits the problem: #include <boost/mpl/is_sequence.hpp> int main() { bool r = boost::mpl::is_sequence<boost::mpl::int_<0> >::value; return 0; } The code does not compile on all compilers that I use regularly (VC++, g++ and Comeau). Here's a another code that does not compile: #include <boost/mpl/is_sequence.hpp> struct x { typedef int tag; }; int main() { bool r = boost::mpl::is_sequence<x>::value; return 0; } Is there any chance for this to be fixed in the immediate future? I rely on mpl::is_sequence for constrained genericity and concept checking in fusion. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

2 2

Unlisted utilities
by Daryle Walker 08 Jan '06

08 Jan '06

Did you know that we have a BOOST_ASSERT? Its documentation page is at <http://www.boost.org/libs/utility/assert.html>. Unfortunately, that page isn't reachable through our library listing at <http://www.boost.org/libs/libraries.htm>. I found it through the Google-enabled search on the front web page. I guessed, and found, a web page at <http://www.boost.org/libs/utility/> that listed the assert, but that page isn't on the main list either. Of the utilities listed, the assert, iterator adaptors, and throw exception have no corresponding entry in the main library list. We should fix this. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 2