June 2012 - Boost-users - lists.boost.org

[boost::format] operator % could use call_traits<..>::parameter_type
by Luc Bourhis 25 Jun '12

25 Jun '12

Hi, consider a library featuring code like template <..., unsigned Rank, ...> struct Foo { ... static unsigned const rank = Rank; .... }; as well as boost::format(...) % Foo::rank Such code will link if and only if a definition for Foo::rank is provided because the interface of operator % is template <class T> operator%(const T& x) This is not possible in the library, as I do not know which values of Rank will be used by client code. Thus the only possibility is a hat trick like boost::format(...) % (Foo::rank+0) If operator % took integral types by value instead, this would alleviate the problem. Hence the suggestion to use call_traits<T>::parameter_type instead of T const &. Of course, the same could be said of many functions other than format::operator% Best wishes, Luc Bourhis

2 2

Trouble linking with boost::program_options on OSX 10.7
by Jürgen Simon 24 Jun '12

24 Jun '12

Hi, I have boost 1.49 installed through homebrew on OSX 10.7. I'm attempting to compile a program making use of boost::program_options. I get the following error: Undefined symbols for architecture x86_64: "boost::program_options::detail::cmdline::get_canonical_option_prefix()", referenced from: boost::program_options::basic_command_line_parser<char>::run() in meanshift_clustering.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) I clearly remember that this used to compile in the past. In the meantime I had uninstalled and re-installed boost a few times. I double-checked the invocation though, the paths are correct: Ld Debug/meanshift_clustering normal x86_64 cd myproject setenv MACOSX_DEPLOYMENT_TARGET 10.7 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -Lmyproject/Debug -Fmyproject/Debug -filelist myproject/myproject.build/Debug/meanshift_clustering.build/Objects-normal/x86_64/meanshift_clustering.LinkFileList -mmacosx-version-min=10.7 -Wl,-search_paths_first -Wl, -headerpad_max_install_names myproject/Debug/libmyproject.dylib /usr/local/lib/libradolan.dylib /usr/local/lib/libnetcdf_c++.dylib /usr/local/lib/libnetcdf.dylib /usr/local/lib/libboost_system-mt.dylib /usr/local/lib/libboost_program_options-mt.dylib /usr/local/lib/libboost_thread-mt.dylib /usr/local/lib/libhdf5.dylib /usr/local/lib/libhdf5_hl.dylib -o myproject/Debug/meanshift_clustering I checked with nm if the symbol is in /usr/local/lib/libboost_program_options-mt.dylib and it is not. This makes me think it's some kind of problem with boost. I do not reference this symbol in my code directly, anywhere. -- View this message in context: http://boost.2283326.n4.nabble.com/Trouble-linking-with-boost-program-optio… Sent from the Boost - Users mailing list archive at Nabble.com.

2 1

Boost Program Options: Any way to have variable number of "objects" each with parameters?
by Charles Mills 24 Jun '12

24 Jun '12

I really like the Boost Program Options library. I've used it for one program now with great effect and I'd like to use it for another, but can't figure out how to structure what I need to do so that Boost PO could handle it. I am solely interested in the ".ini file" for this - command line is irrelevant. The problem is "how does a program allow the specification of a variable number of 'objects' each of which has parameters of its own?" Here is a hypothetical program that exemplifies the problem. Suppose a program were going to create multiple geometric shapes of some sort. An ideal (unsupported by PO) .ini file might look like rectangles=3 rectangle[0].width=5 rectangle[0].height=10 rectangle[1].width=3 etc. circles=2 circle[0].diameter=4 etc. Can anyone suggest a way to accomplish this with Boost PO? I'm real flexible on what the .ini file might look like so long as it solves the problem and is reasonably explicable to a user. (No need for it to look almost like the above.) Thanks, Charles

3 6

BGL Python lib compilation error.
by vy 24 Jun '12

24 Jun '12

Hi, I am new to BGL as well as python and need to install BGL support for Python. I followed the following steps for the installation. 1. downloaded Boost current : 1.49.0: & bootstrap with --with-python=/usr/bin/python 2. downloaded bgl-python from 'svn co https://svn.osl.iu.edu/svn/projects/viz/bgl-python' 3. set the environ variable BOOST_ROOT to "dir head of Boost1_49_0 src code" 4. run bjam in bgl-python. dir I get 2 compilation errors. ...failed gcc.compile.c++ bin.v2/gcc-4.6/release/graphml.o... ...skipped <pbin.v2/gcc-4.6/release>_graph.so for lack of <pbin.v2/gcc-4.6/release>graphviz.o... ...failed updating 2 targets... ...skipped 1 target... === The errors are related to read/write_graphviz() read/write_graphml() in files graphviz.cpp and graphml.cpp : Anyone who have fixes are work around, kindly please let know. Thanks a lot, in advance. Example error output given below: [1] In file included from src/graphviz.cpp:11:0: 17 boost-python/boost_1_49_0/boost/graph/graphviz.hpp: In function ‘void boost::write_graphviz(std::ostream&, con st Graph&, VertexPropertiesWriter, EdgePropertiesWriter, GraphPropertiesWriter, VertexID, typename boost::enable_if_c<boost::i s_base_and_derived<boost::vertex_list_graph_tag, typename boost::graph_traits<Graph>::traversal_category>::value, boost::graph ::detail::no_parameter>::type) [with Graph = boost::graph::python::basic_graph<boost::undirectedS>, VertexPropertiesWriter = b oost::dynamic_properties, EdgePropertiesWriter = std::basic_string<char>, GraphPropertiesWriter = boost::graph::python::object _as_string_property_map<boost::graph::python::basic_descriptor<void*, boost::undirectedS> >, VertexID = boost::graph::python:: basic_index_map<boost::graph::python::basic_descriptor<void*, boost::undirectedS>, boost::adj_list_vertex_property_map<boost:: adjacency_list<boost::listS, boost::listS, boost::undirectedS, boost::property<boost::vertex_index_t, unsigned int>, boost::pr operty<boost::edge_index_t, unsigned int>, boost::no_property, boost::listS>, unsigned int, const unsigned int&, boost::vertex _index_t> >, std::ostream = std::basic_ostream<char>, typename boost::enable_if_c<boost::is_base_and_derived<boost::vertex_lis t_graph_tag, typename boost::graph_traits<Graph>::traversal_category>::value, boost::graph::detail::no_parameter>::type = boos t::graph::detail::no_parameter]’: 18 boost-python/boost_1_49_0/boost/graph/graphviz.hpp:286:5: instantiated from ‘void boost::write_graphviz(std: :ostream&, const Graph&, VertexPropertiesWriter, EdgePropertiesWriter, GraphPropertiesWriter, typename boost::enable_if_c<boos t::is_base_and_derived<boost::vertex_list_graph_tag, typename boost::graph_traits<Graph>::traversal_category>::value, boost::g raph::detail::no_parameter>::type) [with Graph = boost::graph::python::basic_graph<boost::undirectedS>, VertexPropertiesWriter = boost::dynamic_properties, EdgePropertiesWriter = std::basic_string<char>, GraphPropertiesWriter = boost::graph::python::ob ject_as_string_property_map<boost::graph::python::basic_descriptor<void*, boost::undirectedS> >, std::ostream = std::basic_ost ream<char>, typename boost::enable_if_c<boost::is_base_and_derived<boost::vertex_list_graph_tag, typename boost::graph_traits< Graph>::traversal_category>::value, boost::graph::detail::no_parameter>::type = boost::graph::detail::no_parameter]’ 19 src/graphviz.cpp:105:5: instantiated from ‘void boost::graph::python::write_graphviz(const Graph&, const string&, const stri ng&) [with Graph = boost::graph::python::basic_graph<boost::undirectedS>, std::string = std::basic_string<char>]’ 20 src/graphs.hpp:28:1: instantiated from here 21 boost-python/boost_1_49_0/boost/graph/graphviz.hpp:260:5: error: no match for call to ‘(boost::graph::python:: object_as_string_property_map<boost::graph::python::basic_descriptor<void*, boost::undirectedS> >) (std::ostream&)’

1 0

[range] boost::size wrong return type?
by Oswin Krause 24 Jun '12

24 Jun '12

Hi list, I'm using boost 1.49 and get an annoying number of signed/unsigned comparison warnings when i use boost::size. Which is because the return type seems to be signed When I look at boost/range/size.hpp, i get template<class SinglePassRange> inline BOOST_DEDUCED_TYPENAME range_difference<SinglePassRange>::type <--signed size(const SinglePassRange& rng) But the documentation for random access ranges tells otherwise: Expression: boost::size(a) Return Type: boost::range_size<X>::type and Forward Range defines range_size as: boost::range_size<X>::type An unsigned integral type that can represent any nonnegative value of the Range's distance type. assuming the documentation does not lie, I propose the following fix template<class SinglePassRange> inline BOOST_DEDUCED_TYPENAME range_size<SinglePassRange>::type size(const SinglePassRange& rng) Greetings, Oswin

2 1

boost::wave::context deadlocks when called from a DLL
by Julien Lebot 24 Jun '12

24 Jun '12

Hi all, I'm having some issue with boost::wave::context: I have a function called PreProcessSource, which allocates a boost::wave::context and does some preprocessing; nothing fancy at all. std::string PreProcessSource(const std::string& instring, const std::string& defines) { typedef boost::wave::cpplexer::lex_token<> token_type; typedef boost::wave::cpplexer::lex_iterator<token_type> lex_iterator_type; typedef boost::wave::context<std::string::iterator, lex_iterator_type> context_type; std::string source = instring; context_type ctx(source.begin(), source.end()); // DEADLOCK here ctx.set_language(boost::wave::enable_emit_line_directives(ctx.get_language(), true)); if(!defines.empty()) { std::vector<std::string> tokens; Split<std::string>(defines, tokens, ","); std::vector<std::string>::const_iterator cit = tokens.begin(); for (;cit != tokens.end(); ++cit) ctx.add_macro_definition(*cit); } context_type::iterator_type first = ctx.begin(); context_type::iterator_type last = ctx.end(); std::string outstring; while (first != last) { const token_type::string_type& value = (*first).get_value(); std::copy(value.begin(), value.end(), std::back_inserter(outstring)); ++first; } return outstring; } In the past it used to work fine, albeit with boost 1.47.0: Library Nitro is a DLL that hosts the PreProcess source function, the executable uses the Nitro DLL and can call PreProcess source, and Nitro DLL can also sometimes call the function itself. But right now this is no longer the case: whenever Nitro DLL calls the function itself, or Nitro DLL calls another function, which in turn calls back into Nitro DLL PreProcess function, it deadlocks. If DO_DEADLOCK is defined to 1 in the following piece of code, the deadlock will happen: // In executable class Tutorial01 : public Game { public: // ... Tutorial01() : Game() { #if !DO_DEADLOCK std::stringstream sstream; sstream << "void main(inout float4 vtxInput : POSITION) { }" << std::endl << std::endl; std::string source = sstream.str(); std::string defines = ""; std::string shaderCode = Nitro::PreProcessSource(source, defines); #endif } void LoadContent() { #if DO_DEADLOCK std::stringstream sstream; sstream << "void main(inout float4 vtxInput : POSITION) { }" << std::endl << std::endl; std::string source = sstream.str(); std::string defines = ""; std::string shaderCode = Nitro::PreProcessSource(source, defines); #endif // Original code that deadlocks too. // Calls in the DLL, which will call PreProcessSource. // effect->Initialize(device, source, "DX11"); } // ... }; int APIENTRY wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow) { Tutorial00 app; app.Run(); return 0; } Note that the constructor is called directly from the executable, whereas LoadContent is called from the DLL: // In Nitro DLL void Game::Run() { try { // ... LoadContent(); // ... } catch(/* ... */) { } } The code is compiled for x64 and in debug mode. I compile boost myself into a DLL (using bcp to get the files for the libraries I use) with the following options: Preprocessor: WIN32 BOOST_ALL_NO_LIB BOOST_ALL_DYN_LINK BOOST_THREAD_BUILD_DLL _DLL _DEBUG _WINDOWS _USRDLL Code Generation: C++ Exceptions (/EHsc) Multi-threaded Debug DLL (/MDd) Function-level linking (/Gy) Streaming SIMD Extensions 2 (/arch:SSE2) (/arch:SSE2) Fast floating point model (/fp:fast) DLL A uses the same code gen options, and has the following preprocessor macros defined: _WINDLL _UNICODE UNICODE WIN32 _WINDOWS BOOST_ALL_NO_LIB _DEBUG The executable and unit test executable uses the same code gen options, and have the following preprocessor macros defined: BOOST_ALL_NO_LIB UNICODE _UNICODE _MBCS I have tried various combinations of preprocessor definitions (with _DEBUG and without, with BOOST_THREAD_USE_DLL, and without; to no avail). Here is the (cleaned up) stack trace of the deadlock: ntdll.dll!0000000076dc135a() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] KernelBase.dll!000007fefd4f10dc() Nitro.dll!boost::call_once<void (__cdecl*)(void)>(boost::once_flag & flag, void (void)* f) Line 197 + 0x18 bytes C++ Nitro.dll!boost::call_once(void (void)* func, boost::once_flag & flag) Line 28 C++ Nitro.dll!boost::spirit::classic::static_<boost::thread_specific_ptr<boost::weak_ptr<boost::spirit::classic::impl::grammar_helper ... Line 72 + 0x13 bytes C++ Nitro.dll!boost::spirit::classic::impl::get_definition<boost::wave::util::time_conversion::time_conversion_grammar, ... Line 241 + 0x17 bytes C++ Nitro.dll!boost::spirit::classic::impl::grammar_parser_parse<0,boost::wave::util::time_conversion::time_conversion_grammar, ... Line 296 + 0xa bytes C++ Nitro.dll!boost::spirit::classic::grammar<boost::wave::util::time_conversion::time_conversion_grammar, ... Line 55 + 0x3c bytes C++ Nitro.dll!boost::spirit::classic::grammar<boost::wave::util::time_conversion::time_conversion_grammar, ... Line 65 + 0x75 bytes C++ Nitro.dll!boost::spirit::classic::impl::phrase_parser<boost::spirit::classic::space_parser>::parse<char const * __ptr64,boost::wave::util::time_conversion::time_conversion_grammar> ... Line 136 C++ Nitro.dll!boost::spirit::classic::parse<char const * __ptr64,boost::wave::util::time_conversion::time_conversion_grammar, ... Line 155 + 0x3a bytes C++ Nitro.dll!boost::spirit::classic::parse<char,boost::wave::util::time_conversion::time_conversion_grammar, ... Line 173 + 0x23 bytes C++ Nitro.dll!boost::wave::util::time_conversion::time_conversion_helper::time_conversion_helper(const char * act_time) Line 123 C++ Nitro.dll!boost::wave::util::predefined_macros::predefined_macros() Line 196 + 0x38 bytes C++ ... Nitro.dll!Nitro::PreProcessSource(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & instring, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & defines) Line 51 + 0xa0 bytes C++ Tutorial01.exe!Tutorial01::LoadContent() Line 70 + 0x33 bytes C++ Nitro.dll!Nitro::Game::Run() Line 40 C++ Tutorial01.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 149 C++ Tutorial01.exe!__tmainCRTStartup() Line 547 + 0x42 bytes C Tutorial01.exe!wWinMainCRTStartup() Line 371 C kernel32.dll!00000000766a652d() ntdll.dll!0000000076d9c521() It seems boost::wave is trying to parse some time stamp, and by doing so instantiates a grammar and that's when things seem to go bad. The deadlock happens inside the constructor of the context type, and the Visual Studio debugger points me to line 197 in boost\thread\win32\once.hpp BOOST_VERIFY(!::boost::detail::win32::WaitForSingleObject( event_handle,::boost::detail::win32::infinite)); When called directly from the executable, I have noticed that the once_flag.status value is 0, and it exits the loop on the first iteration, whereas when it's called from inside the DLL, the once_flag.status value is 53, and it goes around the loop twice before falling into the WaitForSingleObject. I'm not sure if that's even relevant but I've exhausted all the possibilities and I'm out of ideas. I'd be grateful if anyone could shed some light on this. Best Regards, Julien Lebot

2 3

issue about include boost thread header in MFC dll
by young 23 Jun '12

23 Jun '12

I have a MFC dll application. I try to use Boost thread in the dll. #include "stdafx.h" #include "interface.h" #include "MFCDLL.h" #include <boost/thread.hpp> // The one and only CMFCDLLApp object CMFCDLLApp theApp; EXPORT32 int __stdcall func() { AFX_MANAGE_STATE(AfxGetStaticModuleState()); ... return DLL_OK; } The build is OK. But when I call the func, it crashes. If I comment the line: //#include <boost/thread.hpp> Then it works well. So how to use thread in MFC dll? -- View this message in context: http://boost.2283326.n4.nabble.com/issue-about-include-boost-thread-header-… Sent from the Boost - Users mailing list archive at Nabble.com.

3 5

Filesystem: Choose random file from directory
by Andrej van der Zee 23 Jun '12

23 Jun '12

Hi, I have a directory with about 500.000 thousand small files in it. I need to randomly select one of those file. What would be the *most efficient* way to achieve this? Thank you, Andrej

4 4

[serialization] mingw Deriving from boost::archive::xml_iarchive
by Ken 23 Jun '12

23 Jun '12

Hi, We have a boost archive class derived from boost::archive::xml_iarchive_impl, like this: class XmlInputArchive : public boost::archive::xml_iarchive_impl< XmlInputArchive >, public boost::archive::detail::shared_ptr_helper Its purpose is to provide diagnostics information when deserialising xml archive input, ie. which tag is failing. In porting from 1_41 to 1_49 on mingw this no longer links because the boost::archive::basic_xml_grammar<char> class's symbols are no longer exported from the serialization library. The functions this class overrides are the protected functions: void load_start( const char * name ); void load_end( const char * name ); The existing boost::archive::xml_iarchive class derives from xml_iarchive_impl, and as these functions are protected in the latter, they are not available to a class derived from boost::archive::xml_iarchive class directly. And, for the same reason, we can't create an archive class that delegates to a boost::archive::xml_iarchive instance. So neither deriving from boost::archive::xml_iarchive nor using one as a delegate are feasible solutions. Is there a way of creating an xml_iarchive class that has access to the load_start, load_end functions? Or perhaps there is another way to get the diagnostics information about which xml tags are being processed? Thanks, Ken Appleby

2 2

Advance usage of mutil index,need help.
by 张大千 23 Jun '12

23 Jun '12

this is the story: suppose you have some files(files1,files2,files3) and some usergroup(ug1,ug2,ug3). and this is the struct file{ string name; set<string> group; } and file1.name = "file1"; file1.group.insert("ug1"); file1.group.insert("ug2"); file1.group.insert("ug3"); file2.name = "file2"; file2.group.insert("ug2"); file3.name = "file3"; file3.group.insert("ug3"); and i need search by file name or group, and file name should can be support fuzzy search (eg. *ile , *1 ....) can boost mutil index do this,if can ,what kind index need? or there is other way to do this?

1 0