- Boost - lists.boost.org

Re: [boost] Is there a one-to-one map class in boost?
by Wang Weiwei 19 Jul '06

19 Jul '06

>On 7/17/06, Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> wrote: >> On 7/17/06, Wang Weiwei <wwwang(a)ccsdl.org> wrote: >> > Hello, >> > >> > Now I'm finding a one-to-one map class, say map1, that support the following syntax: >> > >> > map1 m; >> > >> > m.insert(std::make_pair(k1, v1)); >> > ... >> > key k; >> > value v; >> > >> > v = m[k]; >> > k = m[v]; >> > >> > I know a pair of std::map could provide such functionality. But I think a single obj, if that class >> > exists, would be more elegant. >> > >> > Is there such a class in boost? >> >> Look for multi_index library. There are examples of such usage. > >I am doing a bidirectional map as one of the boost SoC projects (The >class you are looking for is a particular case of it). Basically it is >a stl map like wrapper around Boost.MultiIndex. I will present a first >release to the list as soon as possible. I invite you to participate >in the discussion that will surely follows. >Just give me a few more days :) Another good news! Of course I could struggle to use a pair of class as a temp/ugly solution, and with in mind that a perfert solution is waiting for me. A few days is not a long time. :-) Thanks in advance. > >Best Regards >Matias Capeletto

2 1

[range][string_algo][string_cvt] string concept
by Oleg Abrosimov 19 Jul '06

19 Jul '06

Hello Pavol and Thorsten! In boost 1.33.1 release string_algo was adopted to use boost::range to deal with string abstraction. but in the current release support for null-terminated strings is deprecated and will disappear from range library in the upcoming 1.34.0 release, as stated in current range' documentation. I'm working on string_cvt library for boost, and it has the same need to express a string type or char sequence type in a general way. My question is - what is a planned replacement for boost::range in a relation to null-terminated strings stuff? What you Pavol is planning to do in string_algo to workaround the deprecation mentioned? And maybe what you Thorsten is planning to provide some special range type that can be used to fill this gap? Thanks in advance, Oleg Abrosimov.

2 1

Fw: [BGL] graph coloring
by Wang Weiwei 19 Jul '06

19 Jul '06

>Hello, > >I'm coloring my graph with the following code: > > typedef std::set<std::pair<int, int> > panel_conn_set_t; > panel_conn_set_t panel_conn_set; > > for(...) > { > // get the information of vertices connectivities > // vertices are referred to with int > panel_conn_set.insert(std::make_pair([some int], [some int])); > } > > typedef boost::adjacency_list<boost::vecS, boost::vecS, > boost::undirectedS, > // use the default color map > property<vertex_color_t, default_color_type>, > no_property> graph_t; > typedef property_map<graph_t, vertex_color_t>::type vertex_color_map_t; > typedef boost::graph_traits<graph_t>::vertex_descriptor vertex_descriptor; > typedef boost::graph_traits<graph_t>::edge_descriptor edge_descriptor; > typedef boost::graph_traits<graph_t>::vertex_iterator vertex_iterator; > typedef boost::graph_traits<graph_t>::vertices_size_type vertices_size_type; > > // the only graph object > graph_t g; > > vertex_color_map_t& vertex_color_map = boost::get(vertex_color, g); > > for(panel_conn_set_t::const_iterator it=panel_conn_set.begin(); it!=panel_conn_set.end(); ++it) > { > // using int directly as vecter descriptor > boost::add_edge((*it).first, (*it).second, g); > } > > // ****** method A ****** > vertices_size_type num_colors = boost::sequential_vertex_coloring(g, vertex_color_map); > > // ****** method B ****** > std::vector<vertices_size_type> color_vec(boost::num_vertices(g)); > boost::iterator_property_map<vertices_size_type*, vertex_index_map> > color(&color_vec.front(), get(vertex_index, g)); > vertices_size_type num_colors = boost::sequential_vertex_coloring(g, color); > >The code for 'method A' does not compile, but those for 'method B'(borrowed from the BGL doc, >seems to be an exterior property map implementation) works well. > >Why? Any help will be appreciated. > >Max > Or, the question may be, how to make the method A code work? that means I want to use an internal color property map associated to the graph obj. Another question here is, as was told in the doc, the result from the above code would not necessarily be the optimum/minimum number of colors. And in the 'Graph Coloring ' section of the doc, an ordering implementation, smallest_last_ordering(), is introduced. Unfortunately, I don't know how to make the code to co-operate with above code to get a better result. As information for your reference, one of my graph running in my program has about 28000 vertices, the result I got from the above code, for this example, is that I can color all of the vertices with 9 distinctive colors. Even though it's not optimum, but it's a fairly good result for me. Of course, any better number will be prefered. Thanks for you concern and help. P.S. Probably, I think I've still not clearly understood that how the boot.PropertyMap lib works with BGL, but definitely I will get it. Thanks again. Max

1 0

[system] system_error first draft
by Beman Dawes 19 Jul '06

19 Jul '06

The filesystem proposal accepted by the LWG for TR2 also includes a <system_error> header with a bit of error reporting machinery. In particular, class error_code to encapsulate error codes from the operating system and class system_error to be thrown by exceptions. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html#Diagnost… The plan is to use these classes uniformly in TR2. Presumably we will want Boost implementations, and use them in other Boost libraries besides Boost.Filesystem. Because there are likely to be other small operating system dependent components in the future, I'm suggesting that they go in a separate Boost.System library. I'm about to post a CPU timer component that would also fit nicely into Boost.System IMO. There is an early version of Boost.System stuff in the vault. Go to the System directory at http://boost-consulting.com/vault/ for system-0.1.zip. The preliminary error_code/system_error docs can be viewed online at http://mysite.verizon.net/beman/system_error.html Note some changes from the TR2 version: * Use of the unspecified-bool-type idom to test an error_code object to see if there is a non-zero error code. * Name changes. The problem with naming is that there are functions whose most obvious name is "errno", given the long C, C++, and POSIX tradition. But 17.4.1.2 of the C++ standard specifically says that errno shall be a macro! Boo. Hiss. So that name is out. I'm very curious to hear if people think the newer names are an improvement over the TR2 versions. And any other comments are welcome! --Beman

7 17

Re: [boost] [BGL] graph coloring
by Wang Weiwei 19 Jul '06

19 Jul '06

>> I'm coloring my graph with the following code: >> >> ��vertex_color_map_t& vertex_color_map = boost::get(vertex_color, g); > But this line didn't cause problem. >I wouldn't have expected the above to compile at all; aren't property maps >returned by value? > >D.

1 0

Re: [boost] [BGL] graph coloring
by Wang Weiwei 19 Jul '06

19 Jul '06

>> The code for 'method A' does not compile > >What error message do you get from the compiler ? Thanks, the very first message is: boost_1_33_1\boost\graph\sequential_vertex_coloring.hpp(50) : error C2440: initialization : cannot convert from "int" to "size_type" Max

1 0

Re: [boost] Please don't define a fake "operator <" justfor orderedcontainers
by Martin Bonner 18 Jul '06

18 Jul '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 11 July 2006 11:18 To: boost(a)lists.boost.org Subject: Re: [boost] Please don't define a fake "operator <" justfor orderedcontainers > Daryle Walker wrote: > >> [1] If you make a fake order for "std::complex<>", would you compare >> real components then imaginary components, or would you use magnitude >> then angle? > > Real, then imaginary. Compare with: Interesting. I would have chosen magnitude and then angle. Why components. > > "If you make a FAKE order for std::string, would you compare left to > right or right to left?" I don't think that is a legitimate comparison. In my world view, strings have a natural order but complex numbers don't. Now admittedly, operator <() for std::string doesn't actually correspond to my natural ordering (Zoë should be less than Zoo, but it isn't), but it is close enough for most purposes and much cheaper than a locale sensitive comparison. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

4 6

Re: [boost] Please don't define a fake "operator <" just forordered containers
by Martin Bonner 18 Jul '06

18 Jul '06

> Daryle Walker wrote: >> ??? Wrote >>> Because operator== has only one purpose in C++: comparison for >>> equality. Operator<, on the other hand, has two common roles. >>> >>> For classes that have natural ordering, it should define this >>> ordering, and then all the other operators (> <= >=) should be >>> defined as well. Classes that doesn't have this natural ordering, >>> often still define operator< just to be able to be used in ordered >>> containers. In such cases, operator< doesn't define a natural >>> ordering because there isn't any. Instead, it just defines an >>> ordering "that works" for ordered containers, nothing more. It >>> doesn't need to compatible with operator== and !=, and defining >>> operators >, <=, >= is misleading and should be avoided. >> >> The later role is invalid. The reason is that the version of STL >> that made it into the Standard specifies an extra parameter for >> ordered containers for a comparison operation. It allows two >> containers of the same element type to use different comparison >> criteria (at compile- and/or run-time). This invalidates the need >> for a fake "operator <" since you can always package the comparison >> routine in an extra parameter. >> Conversely, calling code must not >> hard code use of "operator <" agreed. >> or "std::less<>", disagree >> unless that code >> requires types with a natural ordering. (The standard algorithms >> have variants that either assume "operator <" or take in a >> comparison parameter.) I think specializing std::less<> for types that don't have a natural order is /exactly/ the right way to enable such types to be stored in an associative container. The algorithms are a different case. sort doesn't make sense for a type that doesn't have a natural order, and in that case the user needs to provide an appropriate comparison. >> >> Making a fake "operator <" just for ordered containers invalidates >> the work of those who added comparison parameters in standard >> classes/functions. > > You have a point there, no doubt. On the other hand, Library writers > should supply some kind of functor to be used with their types in > conjunction with ordered containers (when appropriate, and > boost::variant is of course appropriate). How should this functor be > called? You might say there should be some convention, but there isn't > any right now, and some libraries use operator< for this purpose. Is > it > that bad if operator< is the convention? I'm not sure. It's sure is > convenient to use ordered containers like that... And it seems to me > that there is no major drawback to this, because no other order > operator > is provided. But I guess it's highly dependent on taste... > >> The issue is different for the "==" and "!=" operators because two >> objects can have their state checked for equivalence without having >> a standardized order. The "std::complex<>" template classes are an >> example. > > std::complex doesn't have operator<. std::tr1::shared_ptr does. So it > seems the standard isn't very helpfully consistent here... > >>> boost::shared_ptr is a good example of such a class with no natural >>> ordering, with operator== and !=, with operator<, but without the >>> other operators. And shared_ptr is of TR1 strength... >> >> Ordering for pointers is generally defined if both pointers are part >> of the same array segment. (Either one or both of the pointers can >> be at the "one-past-the-end" point of said segment.) If two >> "shared_ptr" objects can be used for points in an array segment[1], >> then comparison can be allowed with ALL four operators ("<", ">", >> "<=", and ">="). Otherwise, none of those operators should be >> defined and any current existence of such operators should be >> considered a bug. > > I didn't quite understand that last paragraph. shared_ptrs doesn't > have > to point to objects in array (actually, they better not), but there > can > be arrays of shared_ptrs. So should the shared_ptr class provide order > operators or shouldn't it? Anyway, the committee already made up it > mind > about the answer to this question... > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

5 7

Re: [boost] Please don't define a fake "operator <" justfororderedcontainers
by Sohail Somani 18 Jul '06

18 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of me22 > Sent: Monday, July 10, 2006 5:07 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Please don't define a fake "operator <" > justfororderedcontainers > > On 7/10/06, Sohail Somani <s.somani(a)fincad.com> wrote: > > Isn't shared_ptr<T> is supposed to be like T* which has ordering? In > > this case, it's a non-issue no? > > > My understanding is that < is only well-defined for pointers into the > same array and that < between to arbitrary pointers is otherwise some > sort of UB. > > It's less<T*> that provides a full ordering for arbitrary T*s. (By > specialising std::less.) Sorry for the double email, but I guess with this information atleast we can verify that operator < is using less?

2 1

[variant] wish list
by Yuval Ronen 18 Jul '06

18 Jul '06

Hi Eric! It's good to see that you've got back to the list. For a long time now, there was no one to answer users' questions and comments, So I'm taking this (rare :-) ) opportunity to present my wish list for Boost.Variant. First of all, I'd like to say that I think it's a great library. I've become addicted to it... However, there are some things I think are missing. 1. add operator != There's operator==, and adding operator!= would be both easy and useful. 2. apply_visitor should accept the visitor by value std algorithms (such as for_each) accept their functors by value, not by [const] reference. I think that visitors should be considered as variant's equivalent to std functors, and thus be passed by value. This will allow me to pass temporary visitor objects, which is a very common use case, just as with std functors. It will also allow you to delete the two versions of apply_visitor (one taking a reference, one taking a const reference), and leave only one. 3. add support for non-copyable types, a-la Boost.Optional's in-place factory I found myself needing a variant of non-copyable types, and had to resort to dynamic allocation to solve it. Luckily for me, it wasn't a performance-critical code, so I could live with it. But of course it's not optimal... 4. add more flavours of get() Currently the get<T>() function has the semantics of "return current value only if it is of type implicitly convertible to T". But there are other usages, even more useful than this (and if there are other get()s, the name of the original get() should be changed to, for example, get_implicit). One of them is "return current value only if it is exactly of type T (using type_info)". The function will not compile if T is not any of the variant's types. A possible name for it could be get_exact(), but of course there might be better names. Another usage I found useful is when all of the variant's types are implicitly convertible to a common T (e.g, they all inherit from T). This function will not compile if any of the variant's types can't be implicitly convertible to T, but if it does compile, then it ensures it can't fail in run-time (in contrast to get_implicit and get_exact, which can fail in run-time). A possible name is get_common(). I've attached a file containing my implementation of get_exact and get_common, in case you're interested. All the preprocessor magic there is beyond my understanding, I just copied it from your code, and hope I didn't make any mistakes... 5. support for reference types I don't know if Boost.Variant currently supports reference types, nor am I certain it should, but it's a possibility... There was a debate about Boost.Optional's support for reference types, which reached no clear conclusion. Maybe you're familiar with the details, but if not, in short, the problem is with code such as int a = ...; int b = ...; optional<int &> x; // x in initialized to 'empty' x = a; // x is binded to a's reference x = b; // is x rebinded to b's reference, or is a assigned the value in b? The reason I bring it up here, is because I think it's relevant to Boost.Variant as well. Variant of reference types will raise the exact same questions, which should probably get the exact same answers. IOW, both the question of whether to support reference types, and the question of how to support them, should apply to both Boost.Optional and Boost.Variant uniformly. It's an open issue. 6. propose it for TR2 For the benefit of all of us... Thanks again for a great library, Yuval #ifndef VariantGet_h #define VariantGet_h #include <Utils/Variant.h> #include <boost/mpl/assert.hpp> #include <boost/mpl/contains.hpp> namespace boost { template <typename T> struct get_common_visitor : public static_visitor<T> { T operator()(T t) { return t; } }; template <typename T, typename Variant> typename add_reference<T>::type get_common(Variant &v) { get_common_visitor<typename add_reference<T>::type> visitor; return v.apply_visitor(visitor); } template <typename T, typename Variant> typename add_reference<const T>::type get_common(const Variant &v) { get_common_visitor<typename add_reference<const T>::type> visitor; return v.apply_visitor(visitor); } template <typename T, typename Variant> void assert_variant_has_type(const Variant &) { BOOST_MPL_ASSERT((mpl::contains<typename Variant::types, T>)); } template <typename T> struct get_exact_visitor : public static_visitor<T> { T operator()(T t) { return t; } }; template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_pointer::type get_exact( boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >* operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U)) { assert_variant_has_type(*operand); typedef typename add_pointer::type U_ptr; if (!operand) return static_cast<U_ptr>(0); if (operand->type() != typeid(U)) return static_cast<U_ptr>(0); detail::variant::get_visitor v; return operand->apply_visitor(v); } template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_pointer<const U>::type get_exact( const boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >* operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U)) { assert_variant_has_type(*operand); typedef typename add_pointer<const U>::type U_ptr; if (!operand) return static_cast<U_ptr>(0); if (operand->type() != typeid(U)) return static_cast<U_ptr>(0); detail::variant::get_visitor<const U> v; return operand->apply_visitor(v); } template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_reference::type get_exact( boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >& operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U)) { typedef typename add_pointer::type U_ptr; U_ptr result = get_exact(&operand); if (!result) throw bad_get(); return *result; } template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_reference<const U>::type get_exact( const boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >& operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U)) { typedef typename add_pointer<const U>::type U_ptr; U_ptr result = get_exact<const U>(&operand); if (!result) throw bad_get(); return *result; } } // namespace #endif /* ! defined VariantGet_h */

6 13