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

How to make boost.test log wstring?
by Alexey Badalov 09 Feb '10

09 Feb '10

Boost.test logs to ostream, which does not have an operator for wstring. Consequently, I cannot test wstring values. How can I fix this?

4 6

Boost Graph Lib > A*
by Damien Maupu 09 Feb '10

09 Feb '10

Dear all, First Hello. Then does anybody knows how the a star search works for implicit graph? There is little information on the Internet. I found a pdf: A* Graph Search Within the BGL Framework http://www.cs.rpi.edu/~beevek/research/astar_bgl04.pdf But I wasn't able to run the implicit graph example because I am missing: #include <nonconst_bfs.hpp> and #include "test-astar-visitors.hpp" #include "test-astar-accept.hpp" In the online doc: http://www.boost.org/doc/libs/1_40_0/libs/graph/doc/astar_search.html It is said to use astar_search_no_init but I don't know how. Any clues? Thank you Sincerely, Damien

2 4

xlc boost without bzip2 support - Unresolved symbols
by Radha 09 Feb '10

09 Feb '10

Hi Team, I built boost 1.40 iostream lib with xlc 6.0: setenv NO_BZIP2 1 setenv NO_ZLIB 1 bjam -d+2 --prefix= .... boost/aix64 --with-thread toolset=vacpp cflags="-q64 " cxxflags="-q64" link=shared linkflags="-q64" threading=multi --with-iostreams --layout=versioned install Even when I attempt to build without bzip2 support, why am I getting unresolved symbols at run time of executable linked? Am i missing something here? rtld: 0712-001 Symbol BZ2_bzCompressEnd was referenced from module ....stage-O/lib/aix64/libboost_iostreams-xlc-mt-1_40.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol BZ2_bzDecompressEnd was referenced from module ....stage-O/lib/aix64/libboost_iostreams-xlc-mt-1_40.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol BZ2_bzCompress was referenced from module .... aix64/libboost_iostreams-xlc-mt-1_40.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol BZ2_bzDecompress ....stage-O/lib/aix64/libboost_iostreams-xlc-mt-1_40.so was referenced from module ...stage-O/lib/aix64/libboost_iostreams-xlc-mt-1_40.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol BZ2_bzCompressInit was referenced from module ..stage-O/lib/aix64/libboost_iostreams-xlc-mt-1_40.so(), but a runtime definition of the symbol was not found. Thanks in advance, Radha

2 1

Compile problems Boost for CE (with STLport)
by Tim.Olmer＠priva.nl 09 Feb '10

09 Feb '10

Hi all, I have some problems compiling Boost for Windows CE (with STLport). I get the following compile error when I try to build the signals library: ...updating 16 targets... compile-c-c++ bin.v2\libs\signals\build\msvc-9.0~wm5~stlport\release\link-static\stdli b-stlport\threading-multi\trackable.obj trackable.cpp C:\Program Files\Windows CE Tools\wce600\TestDCOM\include\ARMV4I\../Armv4i/new(59) : error C2375: 'operator new' : redefinition; different linkage predefined C++ types (compiler internal)(23) : see declaration of 'operator new' C:\Program Files\Windows CE Tools\wce600\TestDCOM\include\ARMV4I\../Armv4i/new(65) : error C2375: 'operator delete' : redefinition; different linkage predefined C++ types (compiler internal)(24) : see declaration of 'operator delete' C:\build\STLport\stlport-mainline\stlport\stl/_new.h(134) : error C2264: 'operator new' : error in function definition or declaration; function not called C:\build\STLport\stlport-mainline\stlport\stl/_new.h(135) : error C2264: 'operator delete' : error in function definition or declaration; function not called libs\signals\src\trackable.cpp(30) : error C2264: 'operator delete' : error in function definition or declaration; function not called libs\signals\src\trackable.cpp(45) : error C2264: 'operator new' : error in function definition or declaration; function not called Does anyone have an idea what I am doing wrong? Bjam commando: "bjam.exe" --prefix=c:\build\out --with-signals define=_HAS_ITERATOR_DEBUGGING=0 define=_SECURE_SCL=0 link=static runtime-link=static,shared --toolset=msvc-9.0~wm5~stlport stdlib=stlport install Thanks a lot! Tim P.S. I have attached the user-config and vcvars files. ______________________________________________________________________ Priva B.V. A disclaimer is applicable to this email, please refer to www.priva.nl/disclaimer. Op deze email is een disclaimer van toepassing, ga naar www.priva.nl/disclaimer.

1 0

lexical_cast specializations
by Alan M. Carroll 09 Feb '10

09 Feb '10

I did some searching but did not find anything that directly addresses my issue. I have been working with the QT library and I wanted to optimize boost::lexical_cast for QString. My goal is to have the speed of direct conversions (as QString provides specialized methods for char* and std::string) while keeping the convenience of using lexical_cast by reflex. My results (which seem to work) look like this: namespace boost { template <> inline QString lexical_cast<QString, char const *>(char const * const& src) { return src ? QString(src) : QString(); } template <> inline QString lexical_cast<QString, char *>(char * const& src) { return src ? QString(src) : QString(); } } Is this an appropriate / recommended approach? If not, is there a better one? There are some other cases of a similar nature that I would like to optimize as well.

1 0

[BGL] add_edge also adds a vertex
by Olivier Tournaire 08 Feb '10

08 Feb '10

Hi all, I am facing a problem with BGL. Here is a minimal piece of code which reproduces the problem using namespace boost; typedef adjacency_list_traits < vecS, vecS, directedS > Traits; typedef adjacency_list < vecS, vecS, directedS, property < vertex_index_t, long, property < vertex_color_t, boost::default_color_type, property < vertex_distance_t, long, property < vertex_potential_t, long, // stores the unary energy associated to each vertex property < vertex_predecessor_t, Traits::edge_descriptor > > > > >, property < edge_capacity_t, long, // stores the binary energy associated to each edge property < edge_residual_capacity_t, long, property < edge_reverse_t, Traits::edge_descriptor > > > > Graph; int main(int argc, char** argv) { Graph g; //property_map<Graph, edge_capacity_t>::type capacity = get(edge_capacity, g); //property_map<Graph, edge_reverse_t>::type rev = get(edge_reverse, g); add_vertex(g); add_vertex(g); std::pair< graph_traits<Graph>::edge_descriptor, bool > p = add_edge(*vertices(g).first, *vertices(g).second, g); std::pair< graph_traits<Graph>::edge_descriptor, bool > p_reverse = add_edge(*vertices(g).second, *vertices(g).first, g); std::cout << "num_vertices = " << num_vertices(g) << std::endl; // output: 3!!!! std::cout << "num_edges = " << num_edges(g) << std::endl; // output: 2 long flow = kolmogorov_max_flow(g , *vertices(g).first, *vertices(g).second); // crashes ... return 0; } So, I add 2 vertices in my graph, insert 2 edges between these vertices, and I finally have 3 vertices in my graph. What am I doing wrong? I am on a 32 bit Ubuntu box, with g++ 4.3.4 and boost 1.40 Best regards, Olivier ----------------------------------------------------- Olivier Tournaire MATIS - Institut Géographique National 73, Ave de Paris 94165 St Mandé cedex, France tel: (+33) 1 43 98 84 29 fax: (+33) 1 43 98 85 81

4 8

Re: [Boost-users] boost any questions and praise
by Peter Foelsche 08 Feb '10

08 Feb '10

"Peter Foelsche" <foelsche(a)sbcglobal.net> wrote in message news:... > better make the callback object passed as a reference -- and constant > reference should also be possible I think there is really no use case for this. One should always use boost::variant. In case of later-defined types (e.g. imported via some DLL) one should always use inheritance. Peter

1 0

Re: [Boost-users] boost any questions and praise
by Peter Foelsche 08 Feb '10

08 Feb '10

"Peter Foelsche" <foelsche(a)sbcglobal.net> wrote in message news:... > I agree. > I've made boost::any a template -- so that it get's passed a callback > type. > Is this according to your standards? > I think boost::any without any way to apply something to it, is quite > useless. better make the callback object passed as a reference -- and constant reference should also be possible Peter

1 0

Re: [Boost-users] boost any questions and praise
by Pete Bartlett 08 Feb '10

08 Feb '10

Peter Foelsche wrote: >> >> "Alan Tennant" <alan2here(a)gmail.com> wrote in message >> news:a557f5fb1002011639i142be9a0j29205e3ae643a6a9@mail.gmail.com... >> Thanks :¼) >> >> I can't test it until tomorrow but it looks great. This appears to take >> boost::any closer to boost::variant. >> >> << support is most useful. I presume they still cast back to the >> original object in the same way that boost::any does and any non >> standard object they contain that will work in a stream will now work >> inside the boost::any. >> >> Is this going to be an official update or just a branch for me. >I'm still unclear how to work with the people from boost. >Usually I'm posting something here and hope for an answer. Kevlin, who wrote Any and I presume is still the maintainer, is not often seen on the lists so if you want a patch then I suspect Trac items and perhaps direct emails will be necessary. >> Can I get a mention for inspiring the idea? >> >> Whats the empty struct for in main? >just for testing what happens if some class does not provide the << >operator. > >Peter I only compiled and ran the code in my head but I think it is quite dangerous. Isn't the only reason it compiles is because operator<<(ostream&,any const&) is recursive in the case that the any holds a non-streamable type? E.g. the C in your case. Thus, if the user accidentally tries to stream a non-streamable type he hard-crashes his program by blowing the stack... and because it is an any he has no means of knowing for sure if the contents are streamable at instantiation time. He has to "trust to luck". The OP might not like the term "type-safe" but here the downsides of non-type safety are showing themselves up! Of course a more advanced implementation might go down a has_operator_stream metafunction route. But then you are getting well away from the spirit of Any and towards that of Adobe.Poly as another posted mentioned. Pete

3 2

Problems compiling with Boost
by Carla Strembicke 08 Feb '10

08 Feb '10

Hello, I am a newbie. I am currently implementing some interprocess functionality into my program which must reside on both a windows and linux operating system. I have completed the windows integration ( this is where the code originally resided) and am now moving it to the linux platform : Debian 4.1.1-21 -- I have created my makefile and am using gcc version 4.1.2. I get the following output on my make and cannot figure out how to fix this issue: GNU C++ version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (i486-linux-gnu) compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129583 Compiler executable checksum: 183d42a838ed2b7313bffcb8f2f2fda7 /usr/include/sys/mman.h:141: error: reference to 'mode_t' is ambiguous /usr/include/sys/types.h:72: error: candidates are: typedef __mode_t mode_t /usr/local/boost_1_41_0/boost/interprocess/detail/os_file_functions.hpp:317: error: typedef enum boost::interprocess::mode_t boost::interprocess::mode_t /usr/include/sys/mman.h:141: error: reference to 'mode_t' is ambiguous /usr/include/sys/types.h:72: error: candidates are: typedef __mode_t mode_t /usr/local/boost_1_41_0/boost/interprocess/detail/os_file_functions.hpp:317: error: typedef enum boost::interprocess::mode_t boost::interprocess::mode_t /usr/include/sys/mman.h:141: error: 'mode_t' has not been declared Common/Src/shmem.cpp: In member function 'void CShDBStorage::Close()': Common/Src/shmem.cpp:443: warning: statement has no effect Common/Src/shmem.cpp:452: warning: unused variable 'hdr' make: *** [Common/Src/shmem.o] Error 1 I found a thread regarding this issue on the internet but did not see a solution. http://lists.boost.org/boost-users/2009/06/49236.php Can anybody help? Carla Strembicke Software Developer [cid:imageb2f4fa.jpg@d8df2841.2d3d4834] SUBNET Solutions Inc. www.SUBNET.com<http://www.subnet.com/> Making Substations More Intelligent T: 403.270.8885 F: 403.270.9631 #100, 4639 Manhattan Road SE, Calgary, Alberta, Canada; T2G 4B3 Follow SUBNET: Twitter<http://twitter.com/subnetsolutions> | Facebook<http://www.facebook.com/subnetsolutions> | Linkedln<http://www.linkedin.com/groups?gid=2733031&trk=hb_side_g> Visit the all new SUBNET website at http://www.SUBNET.com<http://www.subnet.com/> CONFIDENTIAL INFORMATION NOTICE: The information contained in this e-mail is privileged, confidential and intended solely for the use of the addressee named above. If the reader of this e-mail is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you received this in error, please contact the sender and destroy all copies of this e-mail. Thank you.

2 4