- Boost - lists.boost.org

[chrono] monotonic_clock ofr cygwin
by vicente.botet 02 May '09

02 May '09

Hi, The Boost.Chrono do not compiles on cygwin. The MONOTONIC_CLOCK is not available. I have just defined the monotonic_clock as system_clock and all works right. Attached the patch. Do you agree to commit it? Best, Vicente

2 1

Intentions of Boost.TR1
by David Abrahams 02 May '09

02 May '09

I just saw this post on comp.lang.c++.moderated. I wonder if the Boost.TR1 documentation shouldn't clarify its intended use or degree of conformity. I don't think TR1 conformity is something we have been paying much attention to, is it? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 4

German Boost book updated
by Boris Schaeling 02 May '09

02 May '09

For those who know German: I've added five more chapters to my Boost book at http://www.highscore.de/cpp/boost/. There are now altogether 16 chapters covering 29 Boost libraries. The book does not try to replace the documentation but is written in a tutorial style to give developers a kick start. It explains what the numerous libraries are good for and how they are used without going too much into detail. Any feedback is, as always, appreciated! Boris

2 2

Boostcon Boost++0x Session
by Michael Caisse 02 May '09

02 May '09

Dave - I am sorting out which sessions to attend and wish there was more of me. For the Boost++0x sessions reading a tutorial is a prerequisite. Is the tutorial on the boostcon site and I just failed to find it? Thank you- michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 3

how to build boost version 1_34_1 with gcc in non-standard location?
by Oliver Kullmann 01 May '09

01 May '09

Hello, I'm wrestling here for a long time with the following problem, and I would be very glad if somebody could help me here (seems to be straight-forward, but I can't find anything anywhere on the subject): I have to build some C++ code which doesn't compile with the system gcc version 4.3.1. So I have installed gcc version 4.1.2 locally. Now that C++ code uses Boost version 1_34_1, and doesn't compile with higher versions. Alright, so I install 1_34_1; very unfortunately, linking is necessary, and here is the problem: Obviously I have to build Boost 1_34_1 with the locally build gcc 4.1.2, and now how can I tell the Boost-build where to find gcc??? What I found is to use PACKAGEPATH/bjam/bjam --toolset=gcc-4.1.2 --toolset-root=PATH_TO_GCC_DIR --prefix=INSTALLATION_DIR --build-dir=BUILD_DIR "-sGCC_ROOT_DIRECTORY=PATH_TO_GCC_DIR" install --without-python However, as I had to found out after some time, this doesn't have any effect --- Boost just builds with the system compiler, and ignores all these specifications of PATH_TO_GCC_DIR. Now what is the right way to do it?? I would be really glad for help. Oliver

2 2

[Graph] transitive reduction
by boese-wolf＠math.uni-frankfurt.de 30 Apr '09

30 Apr '09

Hi! May I propose the following implementation for a transitive reduction to be added to the boost graph library? I'm a novice and the quality of the code I produced surely does not meet boosts standards, but maybe with some help, I'm able to improve it. So, please don't shoot me. #ifndef MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED #define MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED #include <vector> #include <algorithm> //std::find #include <boost/concept/requires.hpp> #include <boost/concept_check.hpp> #include <boost/graph/topological_sort.hpp> #include <boost/graph/graph_traits.hpp> #include <boost/property_map.hpp> //I actually didn't care which of those heades include some of the //others and whicht could be left out, for this reason, I simply added a //header when I used a function, described to be in this header by the //boost graph documentation //also I didn't got all of the concepts thin. Am I suppose to check //for all concepts, which are needed for functions I call? (As if I //wouldn't do that, the users would see the functions called by //complaining about missings concepts, which would be clearly an error //message revealing internal implementation and should therefore be avoided?) //the pseudocode which I followed implementing this algorithmn was taken //from the german book Algorithmische Graphentheorie by Volker Turau //it is proposed to be of O(n + nm_red ) where n is the number //of vertices and m_red is the number of edges in the transitive //reduction, but I think my implementation spoiled this up at some point //indicated below using namespace boost; template <typename Graph, typename GraphTR, typename G_to_TR_VertexMap, typename VertexIndexMap> BOOST_CONCEPT_REQUIRES( ((VertexListGraphConcept< Graph >)) ((IncidenceGraphConcept< Graph >)) ((MutableGraphConcept< GraphTR >)) ((ReadablePropertyMapConcept< VertexIndexMap, typename graph_traits<Graph>::vertex_descriptor >)) ((Integer< typename property_traits< VertexIndexMap >::value_type >)) ((LvaluePropertyMapConcept< G_to_TR_VertexMap, typename graph_traits<Graph>::vertex_descriptor >)), (void)) transitive_reduction( const Graph& g, GraphTR& tr, G_to_TR_VertexMap g_to_tr_map, const VertexIndexMap & g_index_map ) { typedef typename graph_traits<Graph>::vertex_descriptor Vertex; typedef typename graph_traits<Graph>::vertex_iterator VertexIterator; typedef typename std::vector<Vertex>::size_type size_type; std::vector<Vertex> topo_order; topological_sort( g, std::back_inserter( topo_order ) ); std::vector<size_type> topo_number_storage( num_vertices(g) ); iterator_property_map<size_type*, VertexIndexMap, size_type, size_type&> topo_number( &topo_number_storage[0], g_index_map ); { typename std::vector<Vertex>::reverse_iterator it = topo_order.rbegin(); size_type n = 0; for(; it != topo_order.rend(); ++it,++n ) { topo_number[ *it ] = n; } } std::vector< std::vector< bool > > edge_in_closure(num_vertices(g), std::vector<bool>( num_vertices(g), false)); { typename std::vector<Vertex>::reverse_iterator it = topo_order.rbegin(); for( ; it != topo_order.rend(); ++it ) { g_to_tr_map[*it] = add_vertex(tr); } } for( typename std::vector<Vertex>::iterator it = topo_order.begin(); it != topo_order.end(); ++it ) { size_type i = topo_number[ *it ]; edge_in_closure[i][i] = true; std::vector<Vertex> neighbors; //I have to collect the successors of *it and traverse them in //ascending topological order. I didn't know a better way, how to //do that. So what I'm doint is, collection the successors of *it here { typename Graph::out_edge_iterator oi,oi_end; for( tie(oi, oi_end) = out_edges( *it, g ); oi != oi_end; ++oi ) { neighbors.push_back( target( *oi, g ) ); } } { //and run through all vertices in topological order for( typename std::vector<Vertex>::reverse_iterator rit = topo_order.rbegin(); rit != topo_order.rend(); ++rit ) { //looking if they are successors of *it if( std::find( neighbors.begin(), neighbors.end(), *rit) != neighbors.end() ) { size_type j = topo_number[ *rit ]; if( not edge_in_closure[i][j] ) { for(size_type k = j; k < num_vertices(g); ++k) if( not edge_in_closure[i][k] ) //here we need edge_in_closure to be in topological order, edge_in_closure[i][k] = edge_in_closure[j][k]; //therefore we only access edge_in_closure only through //topo_number property_map add_edge(g_to_tr_map[*it], g_to_tr_map[*rit], tr); } //if ( not edge_in_ } //if (find ( } //for( typename vector<Vertex>::reverse_iterator } // { } //for( typename vector<Vertex>::iterator } //void transitive_reduction #endif //#ifndef MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED Best regards, Eric

2 3

[ANN] GCC 4.4.0 Released
by Eric Niebler 29 Apr '09

29 Apr '09

This might interest some here: http://gcc.gnu.org/ml/gcc/2009-04/msg00590.html It'd be nice to get some test coverage. Any takers? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 6

[multi-index] Changing hash_index_node.hpp to double linked list
by brad higgins 29 Apr '09

29 Apr '09

I am using boost multi-index, with a hashed-non-unique lookup. In my data, I am expecting many hash collisions. When I erase the multi- index, I find very poor performance. On investigation, I found that the hash collision data structure is a single linked list, and that removing an element involves traversing the entire list. Removing all of the elements involves traversing the list many times. Since my data has many collisions, I am traversing a very long list very many times. I know that the hash table is not designed for use with many collisions, but it is still faster in my testing on insert and serialization than the ordered_non_unique index specifier. I may end up using ordered_non_unique to avoid the worst-case erase() performance, and it may be good enough for the insert() performance. However, I would like to investigate making the hash collisions double- linked. I tried editing boost/multi_index/detail/hash_index_node.hpp, to make it a double-linked list, but I am seeing one of the included tests fail (test_safe_mode). I can't spot any bugs in my hash_index_node.hpp changes. What, apart from hash_index_node.hpp, needs to be updated, to support a double- linked list? boost/multi_index/detail/bucket_array.hpp? Others? Thanks, Brad

3 3

[encrypted strings]
by Sid Sacek 29 Apr '09

29 Apr '09

Does boost have any compile-time classes for string encryption? Is it even possible? When a hacker dumps an executable, they can see all of the strings the program might use, and some of those strings may contain sensitive information. Does boost have any classes that can encode the strings at compile-time? Ideally, the third string in the code below would never compile the "secret" string into the final binary. Regards, -Sid void foo( void ) { char const * s1 = "abc"; string s2 = "xyz"; encrypted_string s3( "secret" ); }

11 28

Re: [boost] [multi-index] Changing hash_index_node.hpp to double linked list
by JOAQUIN M. LOPEZ MUÑOZ 28 Apr '09

28 Apr '09

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de brad higgins [bhiggins(a)arbor.net] Enviado el: martes, 28 de abril de 2009 21:56 Para: boost(a)lists.boost.org Asunto: Re: [boost] [multi-index] Changing hash_index_node.hpp to double linked list > Hi Joaquín, > Thanks for the quick response. I have attached the files I edited. > > Thank you very much for the help, Please allow a day or two till I find time to delve into this. I'll get back to you. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0