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

compile-time mapping: a[1] --> a1 ?
by Steven Allmaras 07 Sep '05

07 Sep '05

I would like to do a compile-time mapping of an array accessor to a list of scalars as in the following class: class MyArray1 { public: double& operator[](int n) { ??? } private: double a0, a1, a2, a3 ; } ; int main() { MyArray1 x ; x[1] = 2. ; } I've left off all the extraneous stuff like constructors. I don't know how to write the MyArray1::operator[] so that it will evaluate to one of the data members at compile time; an if-test would correctly evaluate but might not be optimized away and run slowly. Is there some way to do the compile-time evaluation using the MPL? I looked thru the tutorial but did not find anything that looked like it would work. One possibility that I considered was the C preprocessor concatenation operator ##, #define PICKMEMBER(n) a##n double& operator[](int n) { PICKMEMBER(n) ; } Unfortunately, this will not work for expressions like x[i+1]. It probably has additional problems other than being quite distasteful. Obviously, this would all be easy if I just implemented the member data with an array, class MyArray2 { public: double& operator[](int n) { return data[n] ; } private: double data[4] ; } ; In fact, I did do so and everything works fine. The reason that I am trying to implement the list of scalars method is to see if there are any CPU timing differences for my application, which amounts to matrix-vector operations for small, dense vectors whose sizes are known at compile time. I have tried uBlas but was disappointed with the timing results (and yes, I did compile with -DNDEBUG). I've also looked at other packages such as tvmet (it did worse). I finally tried rolling my own vector and matrix classes with lazy evaluation of binary operators via Eckel's "Thinking in C++, Vol 2"; I also studied source for uBlas and tvmet. So far, I am able to beat uBlas on my choice of compilers/platforms, but I'm still not getting the consistent performance that I was hoping for. Why am I so interested in performance? Two reasons. First, if I can get consistently good performance (i.e. performance that is close to raw C or Fortran) for fairly straightforward operations, then I can be more confident that as I increase abstraction, performance will not deteriorate substantially. Second, I am evaluating C++ for applications that have been traditionally written in Fortran -- in my case, CFD codes for airflow simulation. Issues of modularity, extensibility, maintenance, and the fact that very few students are learning Fortran anymore may not be enough to convince my peers. I think I will also need to show that we will not experience a substantial performance hit with C++. Thanks in advance for any help. Steven Allmaras Boeing Commercial Airplanes

3 2

Re: [Boost-users] boost\serialization expects 2 arguments - 3 provided with VC71 /MDd
by Guoxing Yang 07 Sep '05

07 Sep '05

Robert, I really like the boost serialization library. However, I am having a similar compiler error with VC71. I am trying to use the following code for all STL collections. template void LoadFromXml(const std::string &sXmlText, TValue &oValue) { std::istringstream oInStream(sXmlText); assert(oInStream.good()); boost::archive::xml_iarchive oIn(oInStream); oIn >> BOOST_SERIALIZATION_NVP(oValue); // restore from XML archive. } When the VC71 uses Multi-threaded Debug DLL (/MDd) setting, it generates the following compiler error: C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\boost\serialization\split_free.hpp(55) : error C2780: 'void boost::archive::load(Archive &,T &)' : expects 2 arguments - 3 provided C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\boost\archive\detail\iserializer.hpp(514) : see declaration of 'boost::archive::load' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\boost\serialization\split_free.hpp(54) : while compiling class- template member function 'void boost::serialization::free_loader::invoke(Archive &,T &,const unsigned int)' with [ Archive=boost::archive::xml_iarchive, T=std::vector ] C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\boost\serialization\split_free.hpp(70) : see reference to class template instantiation 'boost::serialization::free_loader' being compiled with [ Archive=boost::archive::xml_iarchive, T=std::vector ] C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\boost\serialization\vector.hpp(79) : see reference to function template instantiation 'void boost::serialization::split_free>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::xml_iarchive, _Ty=int, T=std::vector ] Changing the setting to Multi-threaded Debug (/MTd), everything works well. I could not figure out why. Could you please help me? Thanks Yang

2 1

Re: [Boost-users] compile-time mapping: a[1] --> a1 ?
by boost＠dalvander.com 07 Sep '05

07 Sep '05

>I would like to do a compile-time mapping of an array accessor to a list of > scalars as in the following class: Hi Steven, This is something I found floating on the net some time ago, perhaps it will give you some ideas: template <typename T> class Vector4 { typedef T Vector4<T>::* const vec[4]; static const vec v; public: T x, y, z, w; Vector4() : x(0), y(0), z(0), w(0) { } Vector4(T _x, T _y, T _z, T _w) : x(_x), y(_y), z(_z), w(_w) { } const T& operator[](size_t i) const { return this->*v[i]; } T& operator[](size_t i) { return this->*v[i]; } }; template <typename T> const typename Vector4<T>::vec Vector4<T>::v = { &Vector4<T>::x, &Vector4<T>::y, &Vector4<T>::z, &Vector4<T>::w }; template <typename T> class Matrix4 { typedef Vector4<T> Matrix4::* const mat[4]; static const mat a; public: Vector4<T> i, j, k, l; Matrix4() : i(), j(), k(), l() { } Matrix4(const Vector4<T>& _i, const Vector4<T>& _j, const Vector4<T>& _k, const Vector4<T>& _l) : i(_i), j(_j), k(_k), l(_l) { } const Vector4<T>& operator[](size_t i) const { return this->*a[i]; } Vector4<T>& operator[](size_t i) { return this->*a[i]; } }; template <typename T> const typename Matrix4<T>::mat Matrix4<T>::a = { &Matrix4<T>::i, &Matrix4<T>::j, &Matrix4<T>::k, &Matrix4<T>::l }; Cheers, Anders Dalvander

1 0

Thread events
by Johan 't Hart 07 Sep '05

07 Sep '05

Hello, I'm quite a newbie in the boost world, and I read the documentation about boost::threads. Inthere I read that events were not included in boost because they were too error-phrone. That made me wonder how to do multithreading without events, for example, how do you make a thread wait for something to do without events? I don't know how to implement that with just mutexes. Can someone help me? Thanks in advance. Johan 't Hart -- -- Mijn Postvak In wordt beschermd door SPAMfighter 11616 spam-mails zijn er tot op heden geblokkeerd. Download de gratis www.SPAMfighter.com vandaag nog!

1 0

Re: [Boost-users] [serialization, 1_33_0] Correct usage and implementation for serializable objects without default constructors
by Martin Proulx 07 Sep '05

07 Sep '05

> Hello, > > While using the latest release of boost, I've encountered a few > questions concerning the usage of the serialization library with > objects without default constructors. > > Here they are: > > 1-) How can we construct an instance of a serialized object that > doesn't have a default constructor? > > The only option I've figured out is to normally construct an object > with bogus values, then unserialize the real values while reading from > the archive. Example: > > X(0) val; // 0 being some bogus value. > inputStream >> val; // Overwrites all values within val; > > Is this the correct way to do things? > >> No.. But I think what you want can be found in the manual in >> section: If you specialize save/load construct data you will get what >> you want. Use construct in place inside of load construct data. >> Reference/Serializable/Concept/Pointers/Non-Default Constructors. > > 2-) How should we split the serialization between the class' > serialize member versus load/save_construct_data? > > My observations show that when un/serializing objects directly like > shown above, load/save_construct_data aren't needed, so the serialize > member has to handle everything. When serializing a vector<X>, > load/save_construct_data does get called, so we have to un/serialize > some members in those functions as well. At first glance, it seems > some members will have to be un/serialized for the second time within > load/save_construct_data. > > Is that correct? For a class to be correctly un/serializable for all > cases, load/save_construct_data must un/serialize members that are > already taken care of in the serialize member? > >> Nope. >> >> If his isn't simple, then there is something wrong. Check the code >> in test_non_default_ctor . If it still doesn't give you what you >> need, ask again. >> >> RObert Ramey > Hello, Let me rediscuss everything with the example of test_non_default_ctor.cpp at hand. In this example, we have a class A that doesn't have a default constructor. An int is needed by the constructor, which is stored in the i member variable. load/save_construct_data are used to un/serialize the i member, while the serialize member is used for all other members. Looking at this test, I see a couple of behaviors that puzzle me. -) Saving the 'a' instance in the save() function doesn't end up calling save_construct_data. This leaves a serialized version of A which lacks the 'i' member. This makes it impossible to fully restore the 'a' instance. It seems problematic to me that save_construct_data isn't called in this case. In my planned usage, I'd like to fully serialize all members, regardless if the objects are serialized directly or through pointers. I cannot see how to do this without serializing the members needed to reconstruct the object in both serialize and save_construct_data, even if some members will end up serialized twice when an object is stored through a pointer. What's the proper way to serialize all members of a class without a default constructor so that it gets fully serialized regardless how the objects are managed? -) When restoring the 'a' instance within load(), in order to restore it, we first create another 'a' instance (with a different constructor argument), then restore the other members within, leaving untouched the 'i' member. Assuming I'd like to be able to serialize and unserialize completely objects that do not have a default constructor, I'm wondering how I can fully restore an object that doesn't have a default constructor. I currently can only see a single way, and it is the way it's done in load() for the 'a' instance; that is to construct an object with possibly irrelevant constructor arguments, and then unserialize the object from the archive. This has the downside of fully constructing an object with temporary values that will get replaced when we unserialize the real values. I've looked for some other mechanism relying on a copy constructor and something along the lines of load_construct_data, but I haven't found any. Here again, what is the syntax of choice to fully restore an object that doesn't have a default constructor? Thanks! Martin -- Tel: (450) 681-1681, #271 ------------------------------------------------------------------------ OKIOK Enterprise and e-business security solutions Solutions de sécurité d'entreprise et d'affaires électronique Tel. : (450) 681.1681 http://www.okiok.com This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. Si ce message vous a été transmis par erreur, veuillez en informer l'expéditeur et le supprimer immédiatement.

2 1

[BGL] filtered_graph and null_vertex()
by Tiago de Paula Peixoto 06 Sep '05

06 Sep '05

Hello. Is the function graph_traits<G>::null_vertex() defined for G = filtered_graph? When I try to compile the following simple program: -------------------------------------------------------------- #include <boost/graph/adjacency_list.hpp> #include <boost/graph/filtered_graph.hpp> using namespace boost; int main() { typedef adjacency_list<vecS> graph_t; typedef filtered_graph<graph_t,keep_all> f_graph_t; graph_traits<f_graph_t>::vertex_descriptor v = graph_traits<f_graph_t>::null_vertex(); return 0; } -------------------------------------------------------------- I get the following error with GCC 4.0.1 and boost 1.33.0: /usr/include/boost/graph/graph_traits.hpp: In static member function ‘static typename boost::graph_traits<G>::vertex_descriptor boost::graph_traits<G>::null_vertex() [with G = main()::f_graph_t]’: filtered_test.cc:10: instantiated from here /usr/include/boost/graph/graph_traits.hpp:49: error: ‘null_vertex’ is not a member of ‘main()::f_graph_t’ Shouldn't null_vertex() just be defined to return the null_vertex() for the underlying graph, since the vertex descriptors are the same? Do I miss something? -- Tiago de Paula Peixoto <tiago(a)forked.de>

3 3

Multipartite or layered graph
by Nicola Vitacolonna 06 Sep '05

06 Sep '05

Hi, I need to implement a graph whose set of vertices is partitioned into a certain number of ordered subsets (called layers). Edges join vertices from a layer to the next one(s). A critical operation is the iteration over the nodes of a given layer. I think this can be implemented by adding a vertex property to each vertex, that specifies the layer each vertex belongs to. But this does not seem to me the most (time and space) efficient solution: in particular, how can I iterate over the nodes of a given layer without checking every node? I was wondering whether there is a better way to do the job: maybe, using a custom VertexList implemented using a vector for each layer (in this case, should I write my own functions to add/remove vertices? And should I write my own iterators?). Any other idea, or pointer to existing code (I am new to Boost)? Best regards Nicola Vitacolonna

2 1

[serialization, 1_33_0] Correct usage and implementation for serializable objects without default constructors.
by Martin Proulx 06 Sep '05

06 Sep '05

Hello, While using the latest release of boost, I've encountered a few questions concerning the usage of the serialization library with objects without default constructors. Here they are: 1-) How can we construct an instance of a serialized object that doesn't have a default constructor? The only option I've figured out is to normally construct an object with bogus values, then unserialize the real values while reading from the archive. Example: X(0) val; // 0 being some bogus value. inputStream >> val; // Overwrites all values within val; Is this the correct way to do things? 2-) How should we split the serialization between the class' serialize member versus load/save_construct_data? My observations show that when un/serializing objects directly like shown above, load/save_construct_data aren't needed, so the serialize member has to handle everything. When serializing a vector<X>, load/save_construct_data does get called, so we have to un/serialize some members in those functions as well. At first glance, it seems some members will have to be un/serialized for the second time within load/save_construct_data. Is that correct? For a class to be correctly un/serializable for all cases, load/save_construct_data must un/serialize members that are already taken care of in the serialize member? Thanks! Martin -- Tel: (450) 681-1681, #271 ------------------------------------------------------------------------ OKIOK Enterprise and e-business security solutions Solutions de sécurité d'entreprise et d'affaires électronique Tel. : (450) 681.1681 http://www.okiok.com This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. Si ce message vous a été transmis par erreur, veuillez en informer l'expéditeur et le supprimer immédiatement.

2 1

[BGL] using biconnected_components with an exterior property map
by Greg Landrum 06 Sep '05

06 Sep '05

Hi, I'm trying to use the biconnected_components algorithm from v1.33 of the BGL in some code and I've encountered a problem that I just can't seem to get past. The algorithm requires a property map argument that's used to output which component each edge maps to; this is the argument that's giving me fits. I started with a simple-ish case derived from an example in the BGL docs: //------------------------------------------------------------------ namespace boost { struct edge_component_t { enum { num = 555 }; typedef edge_property_tag kind; } edge_component; typedef property< edge_component_t, std::size_t > edge_prop_t; } int main() { using namespace boost; typedef adjacency_list < vecS, vecS, undirectedS, no_property, edge_prop_t >graph_t; typedef graph_traits < graph_t >::vertex_descriptor vertex_t; graph_t g(5); add_edge(0, 1, edge_prop_t(3), g); add_edge(1, 2, edge_prop_t(3), g); add_edge(0, 2, edge_prop_t(3), g); add_edge(2, 3, edge_prop_t(1), g); add_edge(3, 5, edge_prop_t(1), g); typedef property_map < graph_t, edge_component_t >::type edge_map_t; edge_map_t edge_map = get(edge_component, g); graph_traits<graph_t>::edge_iterator edge,endEdges; for(tie(edge,endEdges)=boost::edges(g); edge!=endEdges;++edge){ std::cout << " >Edge1: " << source(*edge,g) << "-" << target(*edge,g) << " <- " << edge_map[*edge] << std::endl; } edge_map_t components = get(edge_component, g); std::size_t num_comps = biconnected_components(g, components); for(tie(edge,endEdges)=boost::edges(g); edge!=endEdges;++edge){ std::cout << " >Edge2: " << source(*edge,g) << "-" << target(*edge,g) << " <- " << edge_map[*edge] << std::endl; } return 0; } //------------------------------------------------------------------ When I run this, I get reasonable results for the connected components, but here's what prints: >Edge1: 0-1 <- 3 >Edge1: 1-2 <- 3 >Edge1: 0-2 <- 3 >Edge1: 2-3 <- 1 >Edge1: 3-5 <- 1 >Edge2: 0-1 <- 2 >Edge2: 1-2 <- 2 >Edge2: 0-2 <- 2 >Edge2: 2-3 <- 1 >Edge2: 3-5 <- 0 Note that the graph's property map values for the edges have changed (Edge2 values vs Edge1 values). So calling biconnected_components() has modified the graph, even though the graph argument is const. This made me sad, but I figured that I should be able to work around it using an exterior property map. According to the docs: "The ComponentMap type must be a model of Writable Property Map. The value type shouch be an integer type, preferably the same as the edges_size_type of the graph. The key type must be the graph's edge descriptor type." So as my next experiment, I decided to attempt to use an associative property map matching these requirements. I tried to define components like this: //------------ typedef std::map< graph_traits<graph_t>::edge_descriptor, int > map_t; map_t base_map; associative_property_map< map_t > components(base_map); //------------ That doesn't compile, the definition of base_map generates an error whose explanation begins with: //---------------- C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\functional(139) : error C2784: 'bool std::operator <(const std::stack<_Ty,_Container> &,const std::stack<_Ty,_Container> &)' : could not deduce template argument for 'const std::stack<_Ty,_Container> &' from 'const boost::graph_traits<G>::edge_descriptor' with [ G=graph_t ] //---------------- My apologies for the horrible interaction between this message and gmail's line wrapping. If it's useful, I can send the entire error message as an attachment. I next tried to create some other kind of exterior property map, but the documentation for how to do this seems to be out of date. There's an explanation of this in the boost wiki at URL: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Documentatio… search for "random_access_iterator_property_map" So my question is: how can I make a call to biconnected_components in a manner that doesn't modify my graph (or any of its associated property maps)? In the event that it matters, I'm building these tests under win2k using visual c++ 7.1 and boost v1.33. -greg

4 7

[graph] cuthill-mckee ordering broken?
by Marco Morandini 06 Sep '05

06 Sep '05

After building the example file cuthill_mckee_ordering.cpp I get ------------------------------ 8 3 0 9 2 5 1 4 7 6 bandwidth: 4 Reverse Cuthill-McKee ordering starting at: 0 9 1 4 6 7 2 8 5 3 0 bandwidth: 4 Reverse Cuthill-McKee ordering: 9 1 4 6 7 2 8 5 3 0 bandwidth: 4 ------------------------------- instead of the expected ------------------------------- Reverse Cuthill-McKee ordering starting at: 6 8 3 0 9 2 5 1 4 7 6 bandwidth: 4 Reverse Cuthill-McKee ordering starting at: 0 9 1 4 6 7 2 8 5 3 0 bandwidth: 4 Reverse Cuthill-McKee ordering: 0 8 5 7 3 6 4 2 1 9 bandwidth: 4 ------------------------------- (the last ordering is different. Even worst, if I comment out the first two code blocks that wraps the call to cuthill_mckee_ordering, and leave only the third, I get ------------------------------- Reverse Cuthill-McKee ordering: 0 0 0 0 0 0 0 0 0 0 bandwidth: 9 Is this correct? Thanks in advance, Marco Morandini boost version: 1.33.0 compiler: marco@mbdyn-mm:~> gcc -v Reading specs from /home/marco/local/gcc-3.4.4/lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: ../configure --enable-languages=c,c++,f77 --prefix=/home/marco/local/gcc-3.4.4 --enable-__cxa_atexit --enable-threads=posix Thread model: posix gcc version 3.4.4 Operating system: Linux, SuSE 9.3

2 1