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

graphviz compile problem
by Jean Utke 15 Dec '04

15 Dec '04

I am running into a problem compiling code that uses write_graphviz which used to work e.g. for gcc 3.3 and boost versions prior to 1.31. As I am trying to move forward I am testing different gcc and boost versions. Here is the example code: ---------------------------------------------------------------- #include "boost/graph/adjacency_list.hpp" #include "boost/graph/graphviz.hpp" class BoostVertexContentType { public: enum { num=100 }; typedef boost::vertex_property_tag kind; }; class BoostEdgeContentType { public: enum { num=101 }; typedef boost::edge_property_tag kind; }; int main(void) { boost::adjacency_list< boost::listS, boost::listS, boost::bidirectionalS, boost::property<BoostVertexContentType, int>, boost::property<BoostEdgeContentType, int> > b; std::ofstream anOutFileStream; anOutFileStream.open("test.dot",std::ios::out); boost::write_graphviz(anOutFileStream, b); anOutFileStream.close(); } ----------------------------------------------------------------- This compiles ok with gcc 3.3 and boost 1.30.0 / 1.30.2 It does not compile with gcc 3.3/3.4.3 and boost 1.31/1.32 basically complaining about: boost_1_32_0/boost/graph/graphviz.hpp:269: error: no match for `std::basic_ostream<char, std::char_traits<char> >& << const boost::detail::error_property_not_found&' operator My target right now is to use gcc 3.4.3 with boost 1.32. Before I spend time searching for a workaround I hope that somebody has seen this and that there is an easy solution. Thanks, Jean

4 7

[BGL] Bidirectional Graph Concept
by Cromwell Enage 15 Dec '04

15 Dec '04

According to <http://www.boost.org/libs/graph/doc/BidirectionalGraph.html>, adjacency_list with Directed=undirectedS is a model of the Bidirectional Graph Concept. However, the following code fails to compile: #include <boost/concept_check.hpp> #include <boost/graph/graph_concepts.hpp> #include <boost/graph/graph_selectors.hpp> #include <boost/graph/adjacency_list.hpp> int main() { boost::function_requires< boost::BidirectionalGraphConcept< boost::adjacency_list< boost::listS , boost::vecS , boost::bidirectionalS > > >(); boost::function_requires< boost::BidirectionalGraphConcept< boost::adjacency_list< boost::listS , boost::vecS , boost::undirectedS > > >(); return 0; } The error is: boost/graph/detail/adjacency_list.hpp:1984: `struct boost::detail::adj_list_gen<boost::adjacency_list<boost::listS, boost::vecS, boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>, boost::vecS, boost::listS, boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>::config::stored_vertex' has no member named `m_in_edges' Perhaps in_degree() should be specialized for undirected graphs so that it returns the same result as out_degree(). Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

RE: [Boost-users] Re: static boost threads with dynamic runtime
by Simmons, Aaron 15 Dec '04

15 Dec '04

Will this fix be in a 1.32.1? How often are bugfix releases put out? -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Wednesday, December 15, 2004 6:08 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] Re: static boost threads with dynamic runtime On Tue, 14 Dec 2004 12:28:44 -0600, Simmons, Aaron <a-simmons1(a)ti.com> wrote: > > > > I've upgraded to boost 1.32 on Win32 (using vc-7_1). Static linking > to > boost threads is back (yay!), but it doesn't seem to be completely > there. > For instance, there aren't any .lib files if I want to statically > link to > boost threads while using the dynamic runtime. In looking at the > files > generated by the install, there only seems to be > dynamic-runtime/dynamic-threads dlls and > static-runtime/static-threads libs. > Other boost packages have dynamic-runtime/static-boost libs. > > > > Is this intentional (e.g., there are still problems with TSS)? This was an oversight which Stefan Slapeta is fixing (has fixed?) in CVS. There was a bit of discussion about it recently in the Boost development mailing list; see http://lists.boost.org/MailArchives/boost/msg76177.php. Mike _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

boost function ==
by gast128 15 Dec '04

15 Dec '04

Dear all, We all waited for the operator==. Unfortunately it does not compile on VC++ 7.1. What do I wrong: namespace Tstb { int f0 (); int f1 (int a); int f2 (int a, int b); int f3 (int a, int b, int c); } void Test { boost::function<int ()> fc1 = &Tstb::f0; boost::function<int ()> fc2 = &Tstb::f0; boost::function<int ()> fc3 = boost::bind(&Tstb::f1, 2); bool b = false; b = (fc1 == fc2); b = (fc1 == fc3); b = (fc2 == fc3); } It gives: c:\Work\Test\Testmfc\Testboost\Testfunction.cpp(164) : error C2666: 'operator`=='' : 4 overloads have similar conversions c:\Work Sdk\Boost\boost\function\function_base.hpp(562): could be 'boost::enable_if_c<B,T>::type boost::operator ==<boost::function<Signature>>(const boost::function_base &,Functor)' [found using argument-dependent lookup] with [ B=true, T=bool, Signature=int (void), Functor=boost::function<int (void)> ] c:\Work Sdk\Boost\boost\function\function_template.hpp(594): or 'void boost::operator ==<R,Allocator>(const boost::function0<R,Allocator> &,const boost::function0<R,Allocator> &)' [found using argument-dependent lookup] with [ R=int, Allocator=std::allocator<void> ] c:\Work Sdk\Boost\boost\function\function_base.hpp(571): or 'boost::enable_if_c<B,T>::type boost::operator ==<boost::function<Signature>>(Functor,const boost::function_base &)' [found using argument-dependent lookup] with [ B=true, T=bool, Signature=int (void), Functor=boost::function<int (void)> ] or 'built-in C++ operator== (boost::function0<R,Allocator>::safe_bool, boost::function0<R,Allocator>::safe_bool)' with [ R=int, Allocator=std::allocator<void> ] and [ R=int, Allocator=std::allocator<void> ] while trying to match the argument list '(boost::function<Signature>, boost::function<Signature>)' with [ Signature=int (void) ] and [ Signature=int (void) ] etc. Wkr, me

3 3

static boost threads with dynamic runtime
by Simmons, Aaron 15 Dec '04

15 Dec '04

I've upgraded to boost 1.32 on Win32 (using vc-7_1). Static linking to boost threads is back (yay!), but it doesn't seem to be completely there. For instance, there aren't any .lib files if I want to statically link to boost threads while using the dynamic runtime. In looking at the files generated by the install, there only seems to be dynamic-runtime/dynamic-threads dlls and static-runtime/static-threads libs. Other boost packages have dynamic-runtime/static-boost libs. Is this intentional (e.g., there are still problems with TSS)? Thanks, Aaron

3 2

building on HP-UX
by Michael Garriss 15 Dec '04

15 Dec '04

i'm trying to get a product of ours to work on HP-UX. we are using gcc. it seems to build fine but: 1) when i link to a libboost_*.a i get unresolved symbols like this: prompt> g++ -I/home/mgarriss/dev/tp-compiled/include/boost-1_31_0 test.cxx -L/home/mgarriss/dev/tp-compiled/lib/boost-1_31_0 -lboost_regex-gcc -pthread /usr/bin/ld: Unsatisfied symbols: std::allocator<char>::allocate(unsigned long, void const*)(first referenced in /home/mgarriss/dev/tp-compiled/lib/boost-1_31_0/libboost_regex-gcc.a(instances.o)) (code) std::__default_alloc_template<(bool)1, (int)0>::allocate(unsigned long)(first referenced in /home/mgarriss/dev/tp-compiled/lib/boost-1_31_0/libboost_regex-gcc.a(instances.o)) (code) std::allocator<char>::deallocate(char*, unsigned long)(first referenced in /home/mgarriss/dev/tp-compiled/lib/boost-1_31_0/libboost_regex-gcc.a(instances.o)) (code) std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_create(unsigned long, std::allocator<char> const&)(first referenced in /home/mgarriss/dev/tp-compiled/lib/boost-1_3 1_0/libboost_regex-gcc.a(instances.o)) (code) std::__default_alloc_template<(bool)1, (int)0>::deallocate(void*, unsigned long)(first referenced in /home/mgarriss/dev/tp-compiled/lib/boost-1_31_0/libboost_regex-gcc.a(instances.o)) (code) collect2: ld returned 1 exit status 2) when i link to a .sl (which i get by just renaming the .so, not sure if that's right), i get this after running the executable: prompt> g++ -I/home/mgarriss/dev/tp-compiled/include/boost-1_31_0 test.cxx -L/home/mgarriss/dev/tp-compiled/lib/boost-1_31_0 -lboost_regex-gcc -pthread prompt> ./a.out /usr/lib/dld.sl: Unresolved symbol: _ZNSs4_Rep9_S_createEmRKSaIcE (code) from /home/mgarriss/dev/tp-compiled/lib/boost-1_31_0/libboost_regex-gcc.sl ABORT instruction (core dumped) AH! can anyone offer any hints, leads, or advice? INFO: prompt> uname -a HP-UX unknown B.11.11 U 9000/800 180901557 unlimited-user license prompt> gcc -v Reading specs from /opt/gcc-3.3.2/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.2/specs Configured with: ../gcc-3.3.2/configure --prefix=/opt/gcc-3.3.2 --disable-nls --disable-libgcj --disable-shared --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-as=/usr/local/bin/as --with-ld=/usr/bin/ld --enable-threads=posix Thread model: posix gcc version 3.3.2 Thanks in advance, Mike

3 2

[BGL] pathfinding
by Cromwell Enage 15 Dec '04

15 Dec '04

One of the core functions in my multi-state mazes app automagically creates graphs that are conceptually like the one in the attached program. In this case, the shortest path from vertex 0 to vertex 11 is also the only simple path from vertex 0 to vertex 11. Also, unlike a regular maze, there are no dead ends (only cycles), so no matter how far one deviates from this simple path, there is always a way back. To that end, I'm trying to write a function that gives users a path to the end vertex (11) from any other vertex in the maze graph. Unfortunately, this function currently works properly only when given the start vertex (0). I've tried both breadth-first and depth-first search. The cycles seem to be throwing them off in a manner I haven't figured out, yet. I'll keep investigating the problem, but if anyone else has dealt with something like this before, please let me know how I should proceed. Cromwell D. Enage __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 2

crc.hpp with g++ 3.4.2
by Kathryn Hogg 15 Dec '04

15 Dec '04

including boost/crc.hpp when compiling with g++ 3.4.2 yields the following compiler error: /users/kjh/src/toolkits/boost/crc.hpp:464: error: ISO C++ forbids variable-size array `table_type' And the code in question is #if defined(__BORLANDC__) && defined(_M_IX86) && (__BORLANDC__ == 0x560) // for some reason Borland's command line compiler (version 0x560) // chokes over this unless we do the calculation for it: typedef value_type table_type[ 0x100 ]; #else typedef value_type table_type[ byte_combos ]; #endif Apparantly some version of g++ need to be included in the #if test as well. Pretty trivial to do but I thought I'd post here so the maintainers of the crc library can get it officially fixed. -- Kathryn http://womensfooty.com

2 1

Boost.Build: how to specify targets on command line
by Davlet Panech 14 Dec '04

14 Dec '04

Hello, I want to build one variant of a one boost DLL library using the regular bjam scripts; I tried the following tools/build/jam_src/bin.ntx86/bjam \ -q \ -d2 \ -sTOOLS=msvc \ -sBUILD="debug <runtime-link>dynamic <threading>multi" \ boost_date_time which builds *both* the DLL and the static lib, but I want only the DLL. I'm guessing I'd have to replace "boost_date_time" with some mangled "fully-qualified" target name, what is it? Another question, is it possible to "stage" individual libraries? Thanks, D.

1 1

boost/thread/xtime.hpp
by Weston Markham 14 Dec '04

14 Dec '04

The Boost.Threads library provides boost::xtime and boost::xtime_get. I have some questions and concerns about these: I read the page at http://www.cl.cam.ac.uk/~mgk25/time/c/ in order to understand what the intended semantics of boost::TIME_UTC are. I assume that this matches the possible C proposal that is referred to in the Boost documentation. I also read the "Terminology" section of the Boost.Date_Time documentation. 1. First of all, should these (boost::xtime and boost::xtime_get) be treated as deprecated, in favor of the types and functions in Boost.Date_Time? (If so, then my further questions might be merely academic.) 2. It appears that the boost::xtime type is used both for the purpose of measuring the length of an interval of time, as well as for designating individual points in time. Is this correct? 3. thread::sleep (as well as other Boost.Thread functions) delays the execution of a thread for a specified interval, which implicitly begins at (approximately) the time of the call. Is its input parameter intended to be the other endpoint of the interval, or is it intended to measure the length of the interval? Both the documentation and the implementation lead me to believe that the former is the case. However, the documentation seems to me to be slightly ambiguous, and, of course, using a function's implementation to determine its expected behavior is questionable. (A similar question applies to the TimedLock concept, although I haven't looked at its details.) 4. The only type of clock that xtime_get supports (according to the documentation) is TIME_UTC. This does not seem useful to me, because I am mainly interested in providing accuracy for the intervals being timed, as opposed to providing accuracy relative to some externally-defined epoch. 5. Does boost::thread::sleep use the boost::TIME_UTC clock? If the parameter specifies the other endpoint, then I don't see how anything else could make sense. 6. What happens when someone applies a correction to the system time on my machine, in an attempt to synchronize it with UTC? Intuitively, I expect any functions that report UTC time to report a discontinuity, because the newer estimate should always be considered more accurate, but it was not known until the adjustment was made. Consider the code that I currently write in order to "sleep 5 seconds": boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 5; boost::thread::sleep(xt); How long should the waited interval last? In most cases, it will be just under 5 seconds. If a leap second occurs within 5 seconds after the xtime_get, the wait ought to last about 6 seconds. (My guess is that most implementations would not provide this behavior, however.) And in the event that the TIME_UTC clock does not exactly match UTC time, and is subject to adjustments, the sleep could be instantaneous, or perhaps last a minute or more. (Here in my office, my workstation and the phone system disagree by 1 minute right now.) If boost::thread::sleep is intended to wait until a specified UTC time, (this is the conclusion that I have drawn from the documentation and the current implementation) then I think this is a conceptual flaw in the library. I have never had any need to do such a thing. It is always more important to me in this context that the duration of the interval be accurate, rather than its relation to, say, the rotation of the earth. Admittedly, I will get the behavior that I want in most cases. However, it seems senseless to me to confuse the matter of timing short intervals with reasonable accuracy by introducing UTC time, particularly when practically all computing hardware already has the facilities to perform the measurement task at hand, but does not necessarily have any means of discovering the current UTC time. My concerns could be mitigated if boost::TIME_UTC were renamed so that it did not have UTC in its name. It should then be documented as indicating a request for a (monotonic, if possible) clock that is suitable for timing intervals with a resolution around 1 second. The underlying implementations should then prefer system calls that enable accurate measurement of intervals, rather than synchronization with an external time base. Plus, the documentation for boost::thread::sleep should make explicit the manner in which it will interpret its argument. A search of the Boost developers' list on Gmane reveals a "problems with boost::thread" thread that appears to mention the issue of applying adjustments to the clock used for TIME_UTC. (And appears to have good suggestions for adding types to fix the ambiguity that causes questions #2 and #3.) I only found it after typing up the bulk of this message. However, it would be good to know if the future direction of the library is to incorporate the suggestions there. Weston

2 1