- Boost - lists.boost.org

[boost][serialization] Adding State to Archives
by martin.ecker＠tab.at 13 May '04

13 May '04

Hello, I was wondering what the best way would be to extend the serialization library to allow storing state in e.g. the archive objects during the serialization process. We could use such a facility in our project for various purposes. For example, it would be possible to influence the serialization of certain classes, i.e. make them write out only their internal state but not any pointers or references to other objects, or something like that. Another use case for having state variables in archives: We're using another library in our project that has its own serialization system. So instead of writing boost::serialization code for the classes of this library we want to use its serialization system. This is straightforward enough by having the library serialize into a memory buffer which is then written out using boost::serialization's binary_object. However, we also need to do proper tracking of pointers for that library, so we can't just create a new memory buffer every time we encounter a pointer to one of its objects during serialization. Therefore it would be convenient to store an "archive" object of the library's serialization system (which calls an archive a "stream") in the boost::serialization archive and simply write all objects of the library we encounter to it. The library's serialization system will track all these objects for us in a similar way boost::serialization does. Then at the end of the serialization process we write the additional serialization data out to the archive using a binary_object. In general, there are a lot of use cases I can think of where having state variables in an archive is useful (setting flags to influence the serialization process, deserializing smart pointers, registering objects upon deserialization in some kind of object registry, etc.). One way of achieving all this would, of course, be to derive from one of the existing archive classes and add the required functionality. However, we don't want to lose the flexibility of being able to write out data to a binary, text, XML, or any other archive with some other kind of representation. So basically we're looking for a good way of inserting an additional layer in between the archives and the actual serialize functions that can store state variables. Thanks for any comments. Best Regards, Martin Ecker TAB Austria Industrie- und Unterhaltungselektronik GmbH & CoKG http://www.tab.at

1 0

Lambda/functions
by Darren Cook 13 May '04

13 May '04

I've a set of trees (e.g. a set of identically structured XML documents) and I want to be able to return a reference to a certain position in the tree. My test tree node is [1] below, with a test tree [2]. I think I can solve this with boost::function and boost::lambda. E.g. this works: boost::function1<int,Node&> best2; best2=bind(&Node::value2,_1); std::cout<<"best2(root)="<<best2(root)<<"\n"; std::cout<<"best2(child[0])="<<best2(root.children[0])<<"\n"; I also need to be able to treat "number of children" the same way I can treat value1 or value2. I've now worked this out as: best2=bind(&std::vector<Node>::size,bind(&Node::children,_1)); Going strong, but now I want to refer to the "value1 of the first child". Following the patterns of the previous ones I thought it would be: best2=bind(&Node::value2, bind( &std::vector<Node>::at, //Ask for an element bind(&Node::children,_1), //Get the vector object 0 ) //Ask for element zero ); That fails with a short error message [3], which is so rare when dealing with BLL that I thought I might be able to understand it, but no, I couldn't work out which bit it didn't like. Can anyone help? Also, is there any limit to how deep I can nest these binds? I think I'm going to need 3 more levels, but it would be useful to know if it is unlimited. Darren [1]: class Node{ public: std::vector<Node> children; int value1,value2; public: Node(int v1,int v2):value1(v1),value2(v2){} friend std::ostream& operator<<(std::ostream& s,const Node& obj){ s<<"value1="<<obj.value1<<",value2="<<obj.value2<<",children.size="<<obj.children.size()<<"\n"; return s; } }; [2] Example usage: Node root(1,111); root.children.push_back(Node(2,222)); std::cout<<root<<root.children[0]; [3]: function.cpp: In function `int main(int, char**)': function.cpp:69: no matching function for call to `bind(<unknown type>, const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, boost::lambda::detail::unspecified> >, boost::tuples::tuple<std::vector<Node, std::allocator<Node> > Node::*, const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, int)'

1 0

RE: [boost] Re: static sized strings
by Martin Bosticky 13 May '04

13 May '04

I have already written code that allows me to create std like strings of fixed upper bound length. If such thing doesn't exist in boost, I am willing to submit and help standardise my code. Eg. // create a string with upper bound length of 4 characters. boost::slstring<4> myLimitedString; My implementation has the ability to quickly copy between strings with the same upper bound (ie without checking the max length). But during assignments from char* or normal std::string objects or strings with different upper bound, the upper bound condition is checked and exception is thrown if there is an error. Martin. Martin Bosticky Software Engineer Action Information Management Ltd. Tel: (01225) 711200 Fax: (01225) 711222 Email: mbosticky(a)aimltd.co.uk -----Original Message----- From: John Nagle [mailto:nagle@animats.com] Sent: 12 May 2004 23:00 To: boost(a)lists.boost.org Subject: [boost] Re: static sized strings Reece Dunn wrote: > Rob Stewart wrote: > >> From: John Nagle <nagle(a)animats.com> >> > >> > STL strings are variable-sized, with no limit. When you >> > add characters, "size()" increases. Should fixed-size >> ^^^^ >> I presume you're referring to fixed-capacity strings which can >> have a variable size, right? Yes. > yup. The idea is to make it a buffer-overflow safe replacement for C > style character buffers, e.g.: > > char buf[ 100 ]; > ::sprintf( buf, "...", ... ); Yes. >> If the string if (sic) fixed-capacity *and* there remains sufficient >> capacity, c_str() can null terminate the buffer. If there isn't >> sufficient remaining capacity, then throw an exception. Done that way, if you write char_string<4> s; strcat(s,"ABCDE"); // truncates at "ABCD", no null. printf("s=%s\n",s.c_str()); // c_str throws exception which is quite different from classic <string.h> semantics. You couldn't use that as a drop-in replacement for C strings. Nor is it compatible with STL basic_string semantics. I'd suggest consistent null-terminated semantics for char_string. >> IOW, make it a runtime error to fix the capacity too small to >> permit null termination when calling c_str(). That still leaves >> room for things like the 4-character file signature to which you >> referred, and yet prevents buffer overrun, but doesn't require >> foregoing flexibility. If you want a 4-char file signature, you can use "boost::array<char,4>", which does that job. Is there any real need for that functionality in char_string? char_string might have some convenience template functions to interconvert "boost::array" and "boost::char_string". > That is a good idea. It will mean keeping track of the string length, Yes, that seems to be necessary. What about the base class issue? There's a need to be able to write something like "char_string_base& s" when you want to pass around fixed-capacity strings of more than one capacity. > Regards, > Reece _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email message contains confidential information and is intended for the use of its intended recipient only. Access to this email by anyone else is unauthorised. If you are not the intended recipient you are hereby notified that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If this communication has been sent to you in error, please notify us immediately. Action Information Management Ltd. 129 Devizes Road, Hilperton, Trowbridge, Wiltshire BA14 7SZ. Tel: +44 (0) 1225 711200 Fax: +44 (0) 1225 711222 Website www.aimltd.co.uk email: support(a)aimltd.co.uk

1 0

[boost] Finding operator==(directory_iterator&, directory_iterator&)
by DY, JERRY U (SBCSI) 12 May '04

12 May '04

In trying to compile the filesystem library, I'm getting an error that the compiler cannot find the operator== for the following function: bool is_empty_directory( const fs::path & dir_path ) { return fs::directory_iterator(dir_path) == end_itr; } aCC-C++-action ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/acc/debug /operations_posix_windows.o Error 226: "../../../libs/filesystem/build/../src/operations_posix_windows.cpp", line 176 # No appropriate function found for call of 'operator =='. class directory_iterator doesn't declare it, neither do ancestors iterator_facade and iterator_facade_types. Can't find free function for operator==(directory_iterator&, directory_iterator&), operator==(iterator_facade&, iterator_facade&), operator==(iterator_facade_types&, iterator_facade_types&) or any of its variants. Is it using the default compiler-generated operator== in directory_iterator? Can somebody who is familiar with the filesystem library code assist me so I can generate a test case for the HP aC++ team? Thanks! -Jerry

2 1

Re: [boost] Big integer library
by Richard Peters 12 May '04

12 May '04

I have once again uploaded a new version of my big integer library (available at http://groups.yahoo.com/group/boost/files/big_integer/, version 0.3). The divison algorithm is completely new, and this time it is fast (it now uses Knuth's algorithm). The code is also reorganised, which made it quite easy to build in support for GNU MP and CLN. When either of those two libraries is available, set BOOST_BIG_INTEGER_USE_GMP or BOOST_BIG_INTEGER_USE_CLN, and those libraries will be used to implement the basic arithmetic functions. Those libraries aren't completely supported yet, a few functions (mostly conversion functions from types larger than int) need to be implemented correctly (it's kindof hacked together right now), and most noticeable, cln hasn't got power_mod yet, because I was unable to find the matching function in the cln library. That aside, it shows that it is quite easy to make the library work with other libraries to provide speedy implementations with a uniform interface. Best regards, Richard Peters ----- Original Message ----- From: "Joel Young" <jdy(a)cs.brown.edu> > > I made a simple program with some big numbers that demonstrate the > speed difference: > > The summary is that big_integer is making millions of > iterator calls and lexicographical_compares, while even > boost::rational using long long is just making a few calls > to things like boost::gcd. > > Joel

3 2

[Boost-bugs] [ boost-Bugs-952713 ] incomplete connected components with disjoint_sets
by SourceForge.net 12 May '04

12 May '04

Bugs item #952713, was opened at 2004-05-12 10:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=952713&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: incomplete connected components with disjoint_sets Initial Comment: I am trying to understand why the order in which I add edges to an adjacency_list graph has some effect on the connected components I get using incremental_components. Using the listing below, with Boost release 1.30.0 (also 1.31.0) with g++ 2.95 (cygwin) I get the following: > g++ -I./boost_1_31_0 -o ok -ftemplate-depth-40 incremental-components-eg-bug.cpp > ./ok rank[0] = 0 rank[1] = 0 rank[2] = 0 rank[3] = 1 rank[4] = 0 parent[0] = 3 parent[1] = 3 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 1 0 This is what I expect. If I change the order in which I add edges to the graph, I get a different answer: > g++ -I./boost_1_31_0 -DSHOWBUG -o bug -ftemplate- depth-40 incremental-components-eg-bug.cpp > ./bug rank[0] = 0 rank[1] = 0 rank[2] = 1 rank[3] = 2 rank[4] = 0 parent[0] = 3 parent[1] = 2 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 0 This is not what I expect. The single connected component has lost a vertex. But it should be the same graph, the only difference being the order in which I called add_edge(). Is this a bug or a misunderstanding on my part? Any advice would be appreciated... Jeff #include <iostream> #include <vector> #include <algorithm> #include <utility> #include <boost/graph/adjacency_list.hpp> #include <boost/pending/disjoint_sets.hpp> #include <boost/graph/incremental_components.hpp> int main(int, char *[]) { using namespace boost; // Create a graph typedef adjacency_list < vecS, vecS, undirectedS > Graph; typedef graph_traits < Graph >::vertex_descriptor Vertex; const int N = 5; Graph G(N); add_edge(0, 3, G); add_edge(0, 4, G); #ifndef SHOWBUG add_edge(1, 4, G); add_edge(1, 2, G); #else add_edge(1, 2, G); add_edge(1, 4, G); #endif // create the disjoint-sets object, which requires rank and parent vertex properties std::vector < Vertex > rank(num_vertices(G)); std::vector < Vertex > parent(num_vertices(G)); typedef graph_traits<Graph>::vertices_size_type* Rank; typedef Vertex* Parent; disjoint_sets < Rank, Parent > ds(&rank[0], &parent [0]); // determine the connected components, storing the results in the disjoint-sets object initialize_incremental_components(G, ds); incremental_components(G, ds); for (unsigned int i = 0; i < rank.size(); ++i) { std::cout << "rank[" << i << "] = " << rank[i] << std::endl; } for (unsigned int i = 0; i < parent.size(); ++i) { std::cout << "parent[" << i << "] = " << parent[i] << std::endl; } typedef component_index < unsigned int >Components; Components components(parent.begin(), parent.end()); for (Components::size_type i = 0; i < components.size (); ++i) { std::cout << "component " << i << " contains: "; for (Components::value_type::iterator j = components [i].begin(); j != components[i].end(); ++j) std::cout << *j << " "; std::cout << std::endl; } return EXIT_SUCCESS; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=952713&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Request for small test in VC7.1
by JOAQUIN LOPEZ MU?Z 12 May '04

12 May '04

I'd appreciate if someone on the list could try the following in VC7.1 and report the results: template<typename T> struct A { template<typename Q> void operator()(const Q&){} }; template<typename T> struct B: private A<T> { using A<T>::operator(); }; int main() { B<char> b; b(3); return 0; } The regression tests for multi_index seem to indicate that VC7.1 is having trouble with this kind of construct and I'd like to make sure before applying any fix. Curiously enough, this problem also shows up in GCC for versions under 3.4, as confirmed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9810 Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

RE: [boost] Re: changing aCC-Link-action
by DY, JERRY U (SBCSI) 12 May '04

12 May '04

I've attached changes with your suggestions. I tested it and it worked!! I'm starting to like bjam, now how does it compare to ant?? =) (we're still using gnu make here). I've also added the line: flags acc CFLAGS <inlining>off : +d The +d option prevents inlined functions from being inlined, useful for debugging -- assuming that's what the option is meant to do. -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Wednesday, May 12, 2004 7:54 AM To: boost(a)lists.boost.org Subject: [boost] Re: changing aCC-Link-action Rene Rivera wrote: > flags acc CFLAGS <target-types>$(SHARED_TYPES) : +z ; > flags acc LINKFLAGS <target-types>$(SHARED_TYPES) : -b ; Oops :-) That should be "target-type", singular not plural. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Regression tests: EXIT STATUS: 666
by Joaquín Mª López Muñoz 12 May '04

12 May '04

Regression status reports list the following run output for some tests of my lib in CWPro8: EXIT STATUS: 666 And nothing more (see for instance http://tinyurl.com/2e56z) Anyone has a clue what this is about? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

boost::date_time: ISO compliant IO for periods/durations?
by Daniel Krügler 12 May '04

12 May '04

Hello boosters, I would like to know whether there already exist ISO 8086 conforming extractors/inserters for the duration/period classes? Specifically I am looking for io/string functions which can handle "Periods of Time, no Specific Start or End", which begin with a 'P' following a list of periods, e.g. "P18Y9M4DT11H9M8S" (18 years, 9 months, 4 days, 11 hours, 9 minutes and 8 seconds) (I am using the term period in the sense ISO 8086 seems to do, i.e. including durations and periods - or did I overlook something?) Thanks for any help, Daniel

3 5