- Boost - lists.boost.org

version conflicts: is there a solution?
by Lewis Hyatt 28 Jun '09

28 Jun '09

Hi Everyone- This has been discussed before (http://thread.gmane.org/gmane.comp.lib.boost.devel/180008) but I think my question is along a slightly different line so I thought I would ask about it. Let's say I want to compile and distribute a library (without the source), and I happen to use some boost header-only libraries as an implementation detail in some of my functions. None of the headers associated with my library include boost headers; it's purely an internal detail. Now, it seems to me that users of my library will still have to be aware of the fact that I used boost in my implementation -- specifically, if they happen to use different versions of the same boost libraries in their code, then the ODR is violated and the behavior is undefined. I realize this isn't a boost-specific problem (it would affect any library of template functions), but I am wondering if there is a boost-specific solution already worked out? Has anyone thought about this? It seems to me that in this case, what would be ideal would be if I could do: #define BOOST_NAMESPACE some_unique_namespace_for_boost #include "boost/algorithm/string.hpp" BOOST_NAMESPACE::shared_ptr<void> x; //or whatever Then I can insure there are no ODR violations and I don't need to bother users of my library with the fact that I used boost at all. Other than the sheer annoyance of having to go through all the boost code to use this macro, is there a strong downside to this approach? Alternatively, I could try: namespace { #include "boost/..." } But I don't know, could this work? Or are there boost headers that rely on fully qualified references like ::boost::algorithm::whatever? I'd appreciate anyone's thoughts on this issue, thanks! -Lewis

8 17

Building boost against uClibc on arm machine
by Piotr Borys 28 Jun '09

28 Jun '09

Hello all. I'm trying to cross-compile boost for arm machine running linux with uClibc. Most of the libs are built ok, but some of them (including one of the most important to me: thread) failed. One of the mesgs was: -------------------------------- gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.3.2/debug/threading-multi/pthread/thread.o libs/thread/src/pthread/thread.cpp: In static member function 'static unsigned int boost::thread::hardware_concurrency()': libs/thread/src/pthread/thread.cpp:394: error: 'get_nprocs' was not declared in this scope -------------------------------- and somehow I'm afraid this is related to uClibc... some facts: Boost 1.39.0 G++ 4.3.2 (cross sysrooted compiler) Any help what I can take a look on? cheers -- Piotr "utak3r" Borys http://utak3r.pl

3 4

[Graph] iterator range splitting
by Tim Keitt 28 Jun '09

28 Jun '09

I've run into some problems with the Graph library as there is a lot of code that splits iterator ranges. An example of this is: (from depth_first_search.hpp) template <class VertexListGraph, class DFSVisitor, class ColorMap> void depth_first_search(const VertexListGraph& g, DFSVisitor vis, ColorMap color) { // // should the below not be: // graph_traits<VertexListGraph>::iterator vi, vend; // tie(vi, vend) = vertices(g); // if ( vi == vend ) ... ??? // or perhaps to be more terse // if ( empty_range(vertices(g)) ) // where empty_range(g) compares first and second // if (vertices(g).first == vertices(g).second) return; depth_first_search(g, vis, color, *vertices(g).first); } This is causing problems in my code where I have defined custom graph classes. In my case out_edges(g) != out_edges(g) because memory is allocated within the out_edges call and successive calls will return different ranges (vertex ranges are not a problem in my case as I use a simple counting iterator). Must out_edges(g) == out_edges(g) for a graph class to meet the Graph library requirements? If not, then a good bit of the code needs to be altered and possibly some of the iterator macros deprecated. Below I've located every instance where the first or second member of an iterator pair is thrown away. These cases are only problematic if the retained iterator is later compared to an iterator from another range. The fix is simple. One only needs to retain both members of the iterator pair. I am willing to provide a patch if it is agreed that the current code is wrong. THK egrep '(vertices|edges)$.*$\.(first|second)' * adjacency_list_io.hpp: for (vi = vertices(graph).first; vi != vertices(graph).second; ++vi){ adjacency_list_io.hpp: for (ei = edges(graph).first; ei != edges(graph).second; ++ei){ adjacency_list_io.hpp: for (vi = vertices(this->graph).first; vi != vertices(this->graph).second; ++vi){ adjacency_matrix.hpp: return *vertices(g).first; adjacency_matrix.hpp: return *vertices(g).first; adj_list_serialize.hpp: for (vi = vertices(graph).first; vi != vertices(graph).second; ++vi) { adj_list_serialize.hpp: for (ei = edges(graph).first; ei != edges(graph).second; ++ei){ bc_clustering.hpp: if (edges(g).first == edges(g).second) return; bc_clustering.hpp: edge_descriptor e = *max_element(edges(g).first, edges(g).second, cmp); bc_clustering.hpp: } while (!is_done && edges(g).first != edges(g).second); cuthill_mckee_ordering.hpp: if (vertices(G).first == vertices(G).second) cuthill_mckee_ordering.hpp: if (vertices(G).first == vertices(G).second) depth_first_search.hpp: if (start_vertex != implicit_cast<Vertex>(*vertices(g).first)){ vis.start_vertex(start_vertex, g); depth_first_search.hpp: if (vertices(g).first == vertices(g).second) depth_first_search.hpp: depth_first_search(g, vis, color, *vertices(g).first); depth_first_search.hpp: if (vertices(g).first == vertices(g).second) depth_first_search.hpp: *vertices(g).first), edge_connectivity.hpp: std::set_difference(vertices(g).first, vertices(g).second, edge_connectivity.hpp: std::set_difference(vertices(g).first, vertices(g).second, fruchterman_reingold.hpp: Dim minX = position[*vertices(g).first].x, maxX = minX; fruchterman_reingold.hpp: Dim minY = position[*vertices(g).first].y, maxY = minY; graph_test.hpp: bgl_first_9 = vertices(g).first, bgl_last_9 = vertices(g).second; graph_test.hpp: bgl_first_9 = vertices(g).first, bgl_last_9 = vertices(g).second; howard_cycle_ratio.hpp: if (boost::out_edges(vd1, m_g).first == boost::out_edges(vd1, m_g).second) throw bad_graph(m_vim[vd1]); howard_cycle_ratio.hpp: mcr_edge_t ed = *boost::out_edges(vd1, m_g).first; howard_cycle_ratio.hpp: good_vertex = boost::target(*boost::out_edges(good_vertex, m_pi_g).first, m_pi_g); howard_cycle_ratio.hpp: pi_edge_t tmp_ed = *(boost::out_edges(vd, m_pi_g).first); howard_cycle_ratio.hpp: remove_edge(*(out_edges(m_g2pi_g_vm[vd], m_pi_g).first), m_pi_g); is_kuratowski_subgraph.hpp: bipartition_start = next(next(next(vertices(K_3_3).first))); is_kuratowski_subgraph.hpp: si = vertices(contracted_graph).first; isomorphism.hpp: for (typename graph_traits<Graph1>::edge_iterator e1 = edges(g1).first; isomorphism.hpp: e1 != edges(g1).second; ++e1) { isomorphism.hpp: for (typename graph_traits<Graph2>::edge_iterator e2 = edges(g2).first; isomorphism.hpp: e2 != edges(g2).second && !found_edge; ++e2) { iteration_macros.hpp: bgl_first_9 = vertices(g).first, bgl_last_9 = vertices(g).second; iteration_macros.hpp: BGL_FIRST(__LINE__) = vertices(GNAME).first, BGL_LAST(__LINE__) = vertices(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = vertices(GNAME).first, BGL_LAST(__LINE__) = vertices(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = edges(GNAME).first, BGL_LAST(__LINE__) = edges(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = edges(GNAME).first, BGL_LAST(__LINE__) = edges(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = adjacent_vertices(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = adjacent_vertices(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = adjacent_vertices(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = adjacent_vertices(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = out_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = out_edges(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = out_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = out_edges(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = in_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = in_edges(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = in_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = in_edges(UNAME, GNAME).second; \ johnson_all_pairs_shortest.hpp: typename Traits2::vertex_descriptor s = *vertices(g2).first; kamada_kawai_spring_layout.hpp: for (vertex_iterator ui = vertices(g).first, end = vertices(g).second; kamada_kawai_spring_layout.hpp: vertex_iterator ui, end = vertices(g).second; kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: vertex_descriptor p = *vertices(g).first; kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { king_ordering.hpp: if (vertices(G).first == vertices(G).second) king_ordering.hpp: if (vertices(G).first == vertices(G).second) metric_tsp_approx.hpp: Vertex v(*vertices(g).first); metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, w, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, w, id, vis); metric_tsp_approx.hpp: Tree t(mst, *vertices(mst).first, minimum_degree_ordering.hpp: adj_iter nu = adjacent_vertices(u_node, G).first; planar_canonical_ordering.hpp: vertex_t first_vertex = *vertices(g).first; prim_minimum_spanning_tree.hpp: choose_param(get_param(params, root_vertex_t()), *vertices(g).first), prim_minimum_spanning_tree.hpp: (g, *vertices(g).first, predecessor_map(p_map). property_iter_range.hpp: return std::make_pair(iter(vertices(graph).first, get(tag, graph)), property_iter_range.hpp: iter(vertices(graph).second, get(tag, graph))); property_iter_range.hpp: return std::make_pair(iter(vertices(graph).first, get(tag, graph)), property_iter_range.hpp: iter(vertices(graph).second, get(tag, graph))); property_iter_range.hpp: return std::make_pair(iter(edges(graph).first, get(tag, graph)), property_iter_range.hpp: iter(edges(graph).second, get(tag, graph))); property_iter_range.hpp: return std::make_pair(iter(edges(graph).first, get(tag, graph)), property_iter_range.hpp: iter(edges(graph).second, get(tag, graph))); push_relabel_max_flow.hpp: current(num_vertices(g_), out_edges(*vertices(g_).first, g_).second), push_relabel_max_flow.hpp: current[u] = out_edges(u, g).first; push_relabel_max_flow.hpp: current[v] = out_edges(v, g).first; push_relabel_max_flow.hpp: for (ai = current[u], ai_end = out_edges(u, g).second; push_relabel_max_flow.hpp: current[u] = out_edges(u, g).first; push_relabel_max_flow.hpp: for (; current[u] != out_edges(u, g).second; ++current[u]) { push_relabel_max_flow.hpp: if (current[u] == out_edges(u, g).second) { push_relabel_max_flow.hpp: ai = out_edges(u, g).first; push_relabel_max_flow.hpp: while (excess_flow[u] > 0 && ai != out_edges(u, g).second) { push_relabel_max_flow.hpp: ai = out_edges(u, g).first; random.hpp: i = vertices(g).first; random.hpp: return *vertices(g).first; random.hpp: i = edges(g).first; random.hpp: return *edges(g).first; sloan_ordering.hpp: s = *(vertices(G).first); undirected_dfs.hpp: if (start_vertex != *vertices(g).first){ vis.start_vertex(start_vertex, g); undirected_dfs.hpp: undirected_dfs(g, vis, vertex_color, edge_color, *vertices(g).first); undirected_dfs.hpp: *vertices(g).first), -- Timothy H. Keitt http://www.keittlab.org/

6 16

Re: [boost] Warning. Possible virus at vault (thread_lokeable)
by raindog＠macrohmasheen.com 27 Jun '09

27 Jun '09

If anyone still has a copy of it somewhere, can you send it to me? ------Original Message------ From: Rene Rivera Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Jun 27, 2009 6:47 AM Subject: Re: [boost] Warning. Possible virus at vault (thread_lokeable) Niels Dekker - address until 2010-10-10 wrote: > Agustín K-ballo Bergé wrote: >> The recently uploaded 'thread_lokeable' file at the vault contains an >> executable that appears to be a virus. virustotal.com reports 6/41 hits. >> The name of the owner (marc0x) appears at some hacker related forums. >> >> I don't know what should be done in such cases, so I hope some >> administrator would read this message and take a look at the file. > > I don't know what to do either, but I've just mailed your finding to > Info (at) boostpro.com > > FYI, I've just downloaded the file, thread_lokeable.zip, and AVG > reported to me that the executable it contains (thread_lokeable.exe) is > a "Trojan horse Dropper.VB.CFQ" Thanks for noticing and reporting it. It's taken care of. Although I may have deleted an extra user or two along the way :-\ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

Warning. Possible virus at vault
by Agustín K-ballo Bergé 27 Jun '09

27 Jun '09

The recently uploaded 'thread_lokeable' file at the vault contains an executable that appears to be a virus. virustotal.com reports 6/41 hits. The name of the owner (marc0x) appears at some hacker related forums. I don't know what should be done in such cases, so I hope some administrator would read this message and take a look at the file. Agustín K-ballo Bergé.-

3 2

[hash][msvc 8.0] <boost/functional/hash/detail/float_functions.hpp> issuing a using namespace std directive?
by JOAQUIN M. LOPEZ MUÑOZ 27 Jun '09

27 Jun '09

If I compile the following wih MSVC++ 8.0: #include <list> typedef list<int> foo; the compiler complains, fairly enough, with some syntax error due to the fact that there's no "list" in the global namespace (we missed a prefixing std::). But if I now try this: #include <boost/functional/hash/detail/float_functions.hpp> #include <list> typedef list<int> foo; compilation succeeds! Somehow, <boost/functional/hash/detail/float_functions.hpp> is importing namespace std into the global namespace, presumably with a using directive. I tried to examine the offending header an saw no obvious using directive to blame, so I hope someone more knowledgeable can take a look at this problem. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 19

[function] Unmerged changes and open tickets
by Daniel James 27 Jun '09

27 Jun '09

Hi all, Boost.Function doesn't seem to have been merged to release for the last 8 months. There are also a number of open tickets which look fairly easy to fix. So, if no one objects, I'll try to deal with them in a few days time and then merge outstanding changes a little while later. These tickets fix various problems: https://svn.boost.org/trac/boost/ticket/2642 https://svn.boost.org/trac/boost/ticket/2847 https://svn.boost.org/trac/boost/ticket/2929 https://svn.boost.org/trac/boost/ticket/3012 There's also an optimization which looks sensible to me: https://svn.boost.org/trac/boost/ticket/2319 Daniel

1 0

[ptr_container] ptr_vector across DLL boundaries
by Robert Dailey 27 Jun '09

27 Jun '09

Hi, Suppose I have a DLL that allocates a few objects and places them in a ptr_vector. I then pass this ptr_vector to my executable via a move operation (basically a swap, not a copy). The executable would keep the ptr_vector by value and eventually delete it when it falls out of scope. Is there any danger in doing this? My goal is to make sure that the same memory manager is used to delete the items as was used to create them.

5 28

[variant] Visual Studio debug visualizers
by Dmitry Vinogradov 25 Jun '09

25 Jun '09

I wrote a simple debug visualizer for boost::variant and I want to share it with community. boost::variant<*,*,*,*,*,*,*,*,*,*,*> { preview ( #( #switch($c.which_) #case 0 ( *($T1 *)&($c.storage_.data_) ) #case 1 ( *($T2 *)&($c.storage_.data_) ) #case 2 ( *($T3 *)&($c.storage_.data_) ) #case 3 ( *($T4 *)&($c.storage_.data_) ) #case 4 ( *($T5 *)&($c.storage_.data_) ) #case 5 ( *($T6 *)&($c.storage_.data_) ) #case 6 ( *($T7 *)&($c.storage_.data_) ) #case 7 ( *($T8 *)&($c.storage_.data_) ) #case 8 ( *($T9 *)&($c.storage_.data_) ) #case 9 ( *($T10 *)&($c.storage_.data_) ) ) ) children ( #( value: #switch($c.which_) #case 0 ( *($T1 *)&($c.storage_.data_) ) #case 1 ( *($T2 *)&($c.storage_.data_) ) #case 2 ( *($T3 *)&($c.storage_.data_) ) #case 3 ( *($T4 *)&($c.storage_.data_) ) #case 4 ( *($T5 *)&($c.storage_.data_) ) #case 5 ( *($T6 *)&($c.storage_.data_) ) #case 6 ( *($T7 *)&($c.storage_.data_) ) #case 7 ( *($T8 *)&($c.storage_.data_) ) #case 8 ( *($T9 *)&($c.storage_.data_) ) #case 9 ( *($T10 *)&($c.storage_.data_) ) ) ) }

3 8

Fixed point structure size
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, An important feature of the fixed point template is that it takes up no more space than the underlying integer. It should be possible to use reinterpret_cast to convert a third party integer pointer (representing fixed ints) to a fixed point template pointer. The way I ensure that in my fixed point template is with a #pragma: #pragma pack(push, 1) ... template struct ... #pragma pack(pop) This is supported by MSVC++ as well as gcc. However it is only defacto standard, so it might not work on any other compiler. Is there a more standard way to make sure that the struct is not padded to some memory alignment size? Soren

2 1