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

Problems on list cover page
by David Abrahams 04 Apr '05

04 Apr '05

HTML tags seem to be showing up as text in the resulting web page: http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

serialization
by Damien * 04 Apr '05

04 Apr '05

has anyone seen this compile error before, and know how to fix it? /usr/local/include/boost-1_32/boost/archive/detail/iserializer.hpp:428: no type named `type' in `struct boost::mpl::eval_if<boost::is_abstract<MyClass>, boost::mpl::identity<boost::archive::detail::load_pointer_type<boost::archive::text_iarchive, MyClass*>::abstract<MyClass> >, boost::mpl::identity<boost::archive::detail::load_pointer_type<boost::archive::text_iarchive, MyClass*>::non_abstract<MyClass> > >' im trying to serialize a polymorphic class that has a pointer to another class of the same type in it. if i comment out that line in the serialization function, the error goes away.

3 7

Re: STL algorithms & references
by David Abrahams 04 Apr '05

04 Apr '05

The following message is a courtesy copy of an article that has been posted to comp.lang.c++.moderated as well. lotusny78(a)yahoo.com writes: > Is there an "easy" way to pass iterators by reference to STL > Algorithms? By easy, I mean not more complicated than using a for > loop. > > e.g. > typedef set<int>::const_iterator cIterType; > cIterType bit = mySet.begin(); > cIterType eit = mySet.end(); > > for_each(ref(bit), ref(eit), > if_(bind(boost::next<cIterType>, boost::ref(bit)) != mySet.end()) > [...] > ); > > The code above, using boost::ref does not compile, at least in part > because boost::reference_wrapper does not contain some STL typedefs. > > If anyone has any ideas, I'd appreciate them. Thanks. This is clearly (to me, but probably not to most other readers of this NG) a Boost.Lambda - related question. If you post it to an appropriate mailing list (see http://www.boost.org/more/mailing_lists.htm) you'll probably get more useful answers. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

GNU GPL
by Uzytkownik 04 Apr '05

04 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Could I use Boost in program under GPL? Regards. - -- Linux user: #376500 (patrz http://counter.li.org/) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCTuvOTCh1hBPsbHURA3shAJ4hncUNBBtoM/V0w8501V3IQE51EwCfUjzJ lxP2qbr+XskDCWmhussuxSU= =uJJp -----END PGP SIGNATURE-----

7 8

[string_algo] new flavour of xxx_copy algorithms
by Yuval Ronen 03 Apr '05

03 Apr '05

Hi. Many algorithms in the string-algo library have 3 versions (I'll take to_upper as an example): 1. In-place modification which takes a SequenceT by ref: template<typename MutableCollectionT> void to_upper(MutableCollectionT &); 2. Copy version which takes a SequenceT by const ref, and returns SequenceT: template<typename SequenceT> SequenceT to_upper_copy(const SequenceT &); 3. Copy version which takes a const ref CollectionT and an OutputIteratorT and the OutputIteratorT after using it: template<typename OutputIteratorT, typename CollectionT> OutputIteratorT to_upper_copy(OutputIteratorT, const CollectionT &) I believe there's room for another version - something that takes a const ref CollectionT, and returns a copy in a SequenceT: template<typename SequenceT, typename CollectionT> SequenceT to_upper_copy(const CollectionT &); The benefits are ease of use combined with performance. IMO, a common scenario is to perform a copy algorithm on a char* string, and returning it as a std::string. Such a thing would be easily done with the proposed extension as: std::string str = to_upper_copy<std::string>("something"); As it is now, I either have to make additional copy (if I use the in-place modification version or the SequenceT copy version), or handle the std::string size my self (if I use the OutputIteratorT version). The new version will allow me to do it elegantly and efficiently. The problem is that it probably can't be an overload of to_upper_copy because it has the same number of arguments as one of the existing overloads, so it will have to have a different name :-( Thanks, Yuval

2 2

extending boost::rational to represent infinities
by Jedediah Smith 03 Apr '05

03 Apr '05

I need a type equivelant to rational<int> but supporting two special values, +inf and -inf which compare greater and less (respectively) to all other values besides themselves. I don't need to perform any arithmetic on the inf values so those operations can be undefined. What is the best strategy for creating such a type? Would it be better to subclass rational or create an underlying integer type with the inf values and use rational based on that underlying type? If the former option, how exactly would I do it?

3 2

Re: BGL: Topological Sort plus ordered out edges
by Elisha Berns 03 Apr '05

03 Apr '05

Hi Again, Below (at the bottom) is the initial reply to my previously posted question on the matter of sorting the out edges of an XSD graph of element dependencies sent by Doug Gregor (and also from Jeremy Seik). I repost their response so everyone can be on the same page regarding what the big deal is: (Me) The problem with this solution is that it is easy to imagine a scenario in which the sub-elements, A B C, are also the children of some other type, ElementY, but in some other order: <ElementY> </C> </B> </A> </ElementY> And using the suggestion below will create a non-directed graph due to the bidirectional edges A->B and B->A or B->C and C->B :( And topological sort won't work when that's the case, as everybody knows. So the assumption that the elements A, B and C will always be found in the same order in an XSD content model, is, to say the least, a weak assumption that can only safely hold true for small, highly controlled schemas. But for large schemas, or schemas I have no control over, that reuse common elements in various orders, all bets are off when the suggested fix will break. So I am a wary of *just* creating extra edges as suggested. I would prefer a more complete solution whereby the edges: ElementY->A ElementY->B ElementY->C Can be ordered somehow using a property or modifying the topological sort algorithm to do this, but right now it's not clear to me where to start. So this is really my question here, how to properly solve this problem in a way that accommodates all possible orderings of the child elements. The only safe assumption is that the parent type (such a ElementX) is unique and that is what makes the edges to its children unique. And also, I'm not concerned about multiple occurrences of child elements (such as two elements of B under ElementX) since those edges can be counted and don't affect the working of the sort. Thanks for any help here, Elisha Berns (Greg) Okay, so we have dependencies in the graph that aren't strictly hierarchical. The easiest answer is to add edges A->B and B->C, because that would illustrate the true dependencies in the example. > And therein lies my question, how do I add to the edge data the > information that signifies a fixed, sequential order among vertices, > when required, that is not to be broken by the sort? For the example > above the edges are: > > ElementX -> A (1) > ElementX -> B (2) > ElementX -> C (3) Unfortunately, I don't know of a good way to do this. topological_sort can only be based on the link structure of the graph. However, we might be able to be a little sneaky by putting the edges into the graph in the reverse order of the dependencies. So when enumerating the out_edges of ElementX, we want to get the edges for C, B, and A, in that order. Then when the depth_first_search instead topological_sort runs, it should give the right ordering. Doug Elisha Berns e.berns(a)computer.org tel. (310) 556 - 8332 fax (310) 556 - 2839

1 0

BGL: Topological Sort plus ordered out edges
by Elisha Berns 03 Apr '05

03 Apr '05

Hi, I got off to a wrong start my posting my question(s) privately, so in everyone's best interest, and certainly my own, I'm just reposting my question here in the hope that someone can comment on how to go about solving the following graph problem: Basically, just to define the context of the question, I need to construct the order in which XML elements need to be serialized to an XML document by reading/analysing an XSD schema document. The parent child relationships in the XSD, inside the type and element definitions give me the basic graph object that I need and after a topological sort it gives the basic order of dependencies within the XSD; however, that being said, the order of elements within individual type definitions (and element definitions also) is lost. For example, if some complex content model has 3 children in a fixed order: <ElementX> </A> </B> </C> </ElementX> the results from the topological sort can give the A B C out of order as C B A. So I need to add some information that expresses the fixed, sequential order of the of the content model for whatever element requires it (in XSD lingo it's a <sequence> particle for complex content). And therein lies my question, how do I add to the edge data the information that signifies a fixed, sequential order among vertices, when required, that is not to be broken by the sort? For the example above the edges are: ElementX -> A (1) ElementX -> B (2) ElementX -> C (3) Elisha Berns e.berns(a)computer.org tel. (310) 556 - 8332 fax (310) 556 - 2839

1 0

[Ann] Parallel BGL 0.5.0 alpha available
by Douglas Gregor 02 Apr '05

02 Apr '05

The Parallel BGL builds on the Boost Graph Library (BGL), offering similar data structures, algorithms, and syntax for distributed, parallel computation that the BGL offers for sequential programs. The Parallel BGL is intended primarily as a research platform, to facilitate both experimentation with and comparison of parallel graph algorithms and to provide solid implementations for solving large-scale graph problems in other application areas. At present, an alpha release of the Parallel BGL is available for download, containing distributed graph algorithms and data structures for use with the Message Passing Interface (MPI). Those familiar with the Boost Graph Library will recognize the same algorithms, interfaces, and data structures in the Parallel BGL. Comments, questions, and feedback are always welcome, but *please* direct your comments to me, personally. The Parallel BGL is not a Boost library (although we may seek acceptance at a later date), The Parallel BGL is being developed by the Open Systems Lab, part of the Pervasive Technologies Laboratory at Indiana University. For more information, see http://www.osl.iu.edu/research/pbgl/ Doug Gregor Post-Doctoral Research Fellow Open Systems Lab, Indiana University

1 0

libs/thread/src/read_write_mutex.cpp non-windows compile broken
by boost＠whaite.ca 02 Apr '05

02 Apr '05

CVS changes checked in on 29 March 2005 have broken linux/gcc thread library compile of read_write_mutex.cpp. Its because BOOST_READ_WRITE_MUTEX_TRACE is #defined only when BOOST_HAS_WINTHREADS. -- Peter Whaite

2 1