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

thread (read_writ_mutex and recursive)
by Gordon Smith 16 Sep '04

16 Sep '04

Are there any plans for a recursive version of the read_write_mutex? Gordon.

2 1

Building boost graph library for Visual C++ 7.1
by Brian Parker 16 Sep '04

16 Sep '04

Hi, I have performed a fresh install of Boost 1.31.0 under Windows (Visual C++ 7.1) and everything built and installed OK except that the Boost Graph Library libraries needed for GraphViz interface (libbglvis.lib) were not built or installed. Does anyone have any suggestions for building this library? I am not familiar with the jam file format. Thanks, Brian Parker

2 1

program_options (Use "/" instead of "-")
by Gordon Smith 16 Sep '04

16 Sep '04

Does program_options support use of "/" instead of "-"? Gordon.

4 5

Re: [Boost-users] Compiling for Solaris, gcc, and STLport
by Tim Clemons 15 Sep '04

15 Sep '04

I found that the following lines in my BOOST_USER_CONFIG allowed for wide character support: #define BOOST_COMPILER_CONFIG "boost/config/compiler/gcc.hpp" #define BOOST_STDLIB_CONFIG "boost/config/stdlib/stlport.hpp" #define BOOST_NO_STDC_NAMESPACE #define BOOST_PLATFORM_CONFIG "boost/config/platform/solaris.hpp" #define BOOST_NO_COMPILER_CONFIG #define BOOST_STRICT_CONFIG I'm not sure why I defined BOOST_NO_COMPILER_CONFIG, or if it was even necessary (it was getting pretty late into the night). I think defining BOOST_STRICT_CONFIG was what did it. On Wed, 2004-09-15 at 04:59, John Maddock <john(a)johnmaddock.co.uk> wrote: > I guess this is a configuration error: to see what Boost config macros are > getting defined, cd into libs/config/test then: > > bjam config_info > > you'll then need to dig down into the bin directory until you find > config_info.out which will have the output from the program - it'll tell you > which macros were defined. # > > As for why they were defined - well I guess either > boost/config/stdlib/stlport.hpp or boost/config/stdlib/libstdcpp3.hpp must > be setting them depending on whether you're using STLPort or not. My guess > is that STLPort hasn't had wide character support enabled for that platform > yet, and that the Boost config system is picking up on that and disabling it > for boost as well. > > Let me know what you find, > > John.

1 0

BGL Graph Strong Components with VC 6
by Daren Grant 15 Sep '04

15 Sep '04

Greetings all , I know this is an odd question especially as the current version of the boost graph library is completely unuseable with VC 6 , but I am using boost_1_27_0 atm , and using the depth_first_search without problems , I have the requirement to also use the strong_components( calls but unfortunately all I get is INFERNAL COMPILER ERRORS ... sorry that should have read INTERNAL ;) ..... does anyone know of a version of the BGL where dfs , and strong_components worked on VC 6 , or a url where i can get archived test results from previous boost builds on specific compilers ? Before I get the string of update to vc 7.1 , I'd love to but my hands are tied :( MTIA

1 1

multi_index - type problems
by Lars Kunert 15 Sep '04

15 Sep '04

Hi! for some reason these two typdefs do not work in my code: typedef typename PriorityQueue::nth_index<0>::type DissimilarityIndex; typedef typename PriorityQueue::index<DissimilarityT>::type DissimilarityIndex; When I actually use them: const DissimilarityIndex& di =_priority_queue.get<DissimilarityT>(); I get error-messages like this: ../../../pocket_graph/src/clustering/NearestNeighbors.h:300: error: invalid initialization of reference of type 'typename boost::multi_index::multi_index_container<Value1, IndexSpecifierList1, Allocator1>::nth_index<0>::type&' from expression of type 'const boost::multi_index::detail::ordered_index<boost::multi_index::const_mem_fun<NearestNeighborPair<uint>, float, &NearestNeighborPair<uint>::dissimilarity>, std::less<float>, boost::multi_index::detail::ordered_index<boost::multi_index::const_mem_fun<NearestNeighborPair<uint>, uint, &NearestNeighborPair<uint>::object>, std::less<uint>, boost::multi_index::detail::ordered_index<boost::multi_index::const_mem_fun<NearestNeighborPair<uint>, uint, &NearestNeighborPair<uint>::nearest_neighbor>, std::less<uint>, boost::multi_index::detail::index_base<NearestNeighborPair<uint>, boost::multi_index::indexed_by<boost::multi_index::ordered_non_unique<boost::multi_index::tag<DissimilarityT, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::multi_index::const_mem_fun<NearestNeighborPair<uint>, float, &NearestNeighborPair<uint>::dissimilarity>, boost::multi_index::detail::null_arg>, boost::multi_index::ordered_unique<boost::multi_index::tag<ObjectT, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::multi_index::const_mem_fun<NearestNeighborPair<uint>, uint, &NearestNeighborPair<uint>::object>, boost::multi_index::detail::null_arg>, boost::multi_index::ordered_non_unique<boost::multi_index::tag<NearestNeighborT, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::multi_index::const_mem_fun<NearestNeighborPair<uint>, uint, &NearestNeighborPair<uint>::nearest_neighbor>, boost::multi_index::detail::null_arg>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, std::allocator<NearestNeighborPair<uint> > >, boost::multi_index::tag<NearestNeighborT, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::multi_index::detail::ordered_non_unique_tag>, boost::multi_index::tag<ObjectT, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::multi_index::detail::ordered_unique_tag>, boost::multi_index::tag<DissimilarityT, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::multi_index::detail::ordered_non_unique_tag>' The following typedef works: typedef typename boost::multi_index::index<PriorityQueue,DissimilarityT>::type DissimilarityIndex; The first two typedefs are in some way the more "natural" way to use indices and I wonder if I have just missed to set some preprocessor symbol... ...I am using gcc 3.2.2 Thanks, Lars

2 1

bgl: Walking through two adjacency lists in parallel
by Lars Kunert 15 Sep '04

15 Sep '04

Hi! I am using a graph with setS as EdgeList template-parameter. I currently try to implement to get the number of neighbors which two vertices have in common. I tried to solve this problem by walking thought both out_edge_iterator - ranges in parallel. tie( i, i_end ) = out_edges( vertex_i, graph ); tie( j, j_end ) = out_edges( vertex_j, graph ); int a =0; for( ;; ) { if( *i == *j ) { ++i; ++j; ++a; if( i == iend ) return a; if( j == jend ) return a; } else if( *i < *j ) { // PROBLEM ++i; if( i == iend ) return a; } else /* ( *i > *j ) */ { ++j; if( j == jend ) return a; }; }; return 0; }; And get the following error message: ../../../pocket_graph/src/clustering/GraphAssociation.h:147: error: no match for 'operator<' in 'boost::iterator_facade<I, V, TC, R, D>::operator*() const [with Derived = Which basicaly tells me that operator< is not defined for an edge descriptor. After digging through some bgl-code I found the class stored_edge (in detail/adjacency_list.hpp ) template <class Vertex> class stored_edge : public boost::equality_comparable1< stored_edge<Vertex>, boost::less_than_comparable1< stored_edge<Vertex> > > { public: typedef no_property property_type; inline stored_edge() { } inline stored_edge(Vertex target, const no_property& = no_property()) : m_target(target) { } // Need to write this explicitly so stored_edge_property can // invoke Base::operator= (at least, for SGI MIPSPro compiler) inline stored_edge& operator=(const stored_edge& x) { m_target = x.m_target; return *this; } inline Vertex& get_target() const { return m_target; } inline const no_property& get_property() const { return s_prop; } inline bool operator==(const stored_edge& x) const { return m_target == x.get_target(); } inline bool operator<(const stored_edge& x) const { return m_target < x.get_target(); } //protected: need to add hash<> as a friend static no_property s_prop; // Sometimes target not used as key in the set, and in that case // it is ok to change the target. mutable Vertex m_target; }; for some reason I can not use operator<() or get_target(), but accessing m_target directly works (cause its mutable???)... } else if( i->m_target < j->m_target ) { // SOLUTION ?! However - I feel a bit uneasy to use such a low level interface... Does anyone know of a better solution? Thanks for your help! Lars

2 1

Compiling for Solaris, gcc, and STLport
by Tim Clemons 15 Sep '04

15 Sep '04

On attempting to link against the boost_regex libraries, I'm finding that regex methods and template functions that take wchar_t are not resolving. Examining the libraries with nm show that these methods are not present. My understanding is that wchar_t support for Solaris was only recently introduced in version 3.4.x, so I wondering if the bjam files are taking this into account yet. I'm currently specifying the build with the following invocation: # bjam "-sTOOLS=gcc-stlport" "-sBUILD=release debug <cxxflags>-fPIC" Can I add to this to force the build to use wchar_t? Appreciate the help. -- Tim.

2 1

Problems when linking to regex library.
by Guan Bin 15 Sep '04

15 Sep '04

In my program, I used regex library. When I build the program to the release version, everything is ok. But when I build the debug version, some link error occurs: --------------------------------------------------------------- error LNK2001: unresolved external symbol "void * __cdecl boost::re_detail::get_mem_block(void)" (?get_mem_block@re_detail@boost@@YAPAXXZ) error LNK2001: unresolved external symbol "void __cdecl boost::re_detail::put_mem_block(void *)" (?put_mem_block@re_detail@boost@@YAXPAX@Z) --------------------------------------------------------------- the tools I use: VC6 + sp5 boost_1_31_0 the regex build process: nmake -fvc6.mak nmake -fvc6.mak install Why the link error occurs? How can I fix it? --

2 2

installing limited libraries
by Andrew Dennison 14 Sep '04

14 Sep '04

How do you have bjam install a very limited set of libraries (ie one library only) without having to explicitly list all libraries except the one or two that you might want with a --without-<library> flag?

2 1