- Boost-users - lists.boost.org

is_sequence
by Wolfgang Meyer 11 May '04

11 May '04

Is boost::mpl::is_sequence supposed to work with gcc 3.2.2 ? I'm trying to use it, but get "false" for boost::mpl::is_sequence<std::list<int> >::value using boost 1.31.0. The same happens with boost::mpl::has_begin. I'm working with FreeBSD 5.1. Any hints how to get it to work would be greatly appreciated. Wolfgang Meyer

2 1

BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Witz 11 May '04

11 May '04

if the following code is commented out from visualc.hpp the standard streaming operators become available for mersenne_twister - and they seem to work fine. is this a bug or have i just been fortunate in my experimentation? #if _MSC_VER <= 1310 # define BOOST_NO_MEMBER_TEMPLATE_FRIENDS #endif ian whittley

2 2

BGL: using an edge_descriptor as key in a map
by boost＠spyderworks.de 11 May '04

11 May '04

Hi, is it possible to use an edge_descriptor (boost::graph_traits<G>::edge_descriptor) as key in a map? I intend to write a visitor class which sets a boolean to each edge, and therefore I need the edge as key. The result of my first try is, that the compiler complains about the missing '<' operator of the key in the map. Best regards Stefan Rauch

2 1

RE: [Boost-users] help: boost::thread and compile error
by Ben Hutchings 10 May '04

10 May '04

Guillermo Martony <gmartony(a)cue.com.uy> wrote: > Greetings, > The following code taken from an example compiles without errors: > > #include <boost/thread/thread.hpp> > #include <boost/thread/xtime.hpp> > #include <iostream> > class thread_alarm > { <snip> > }; > > int main() > { > int secs = 5; > std::cout << "setting alarm for 5 seconds..." << std::endl; > thread_alarm alarm(secs); > boost::thread thrd(alarm); > thrd.join(); > return 0; > } > > But adding a std::fstream varible to the thread_alarm class: <snip> > Results in the following compilation error: > > c:\opt\include\boost\function\function_template.hpp(289): > error C2664: 'void > boost::function0<R,Allocator>::assign_to(Functor)' : cannot convert > parameter 1 from 'const thread_alarm' to 'thread_alarm' > with > [ > R=void, > Allocator=int, > Functor=thread_alarm > ] The boost::thread constructor copies its argument, so the thread_alarm class needs to be copiable, but std::fstream is not copiable. You might be better off using Boost.Bind to produce a lightweight functor.

1 0

boost::bind vs boost::mem_fun (was RE: [Boost-users] Re: shared_ptrs with std::mem_fn)
by Mark Storer 10 May '04

10 May '04

> > template<class _R, class _Ty> > > class mem_fun_t : public unary_function<_Ty *, _R> { > > public: > > explicit mem_fun_t(_R (_Ty::*_Pm)()) > > : _Ptr(_Pm) {} > > _R operator()(_Ty *_P) const > ^^^^^^^ > > {return ((_P->*_Ptr)()); } > > private: > > _R (_Ty::*_Ptr)(); > > }; > > --- > > <...> > No, the relevant part is the signature I highlighted above. <...> > > All I have to say is "use boost::mem_fn, which works, and never > touch the one in std::". Thanks for clearing that up, it was really bugging me. So to speak. ;) I've recently started using boost::bind, and I think I'm in love. But boost::mem_fun raises another question in my mind: Are there any cases where "boost::bind( &foo::bar, _1 )" is superior to "boost::mem_fun( &foo::bar )" (other than a few less keys to press)? I'd say that boost::bind is clearly supperior when "bar" takes a parameter, but when it does not, the water gets a little muddy. I'd imagine that you wouldn't get the long stream of error messages (expected N params not Y, expected N + 1 params, not Y, expected N + 2 ...) from bind when all the different variants miss, but is there anything else? --Mark Storer Senior Software Engineer Verity, Inc.

1 0

RE: [Boost-users] boost 1.30 / date_time / link problem with VC7
by Ben Hutchings 10 May '04

10 May '04

Dan Dimerman <dan_dimerman(a)hotmail.com> wrote: > I'm having the following problem when linking a MSWindows MFC > application with the static library libboost_date_time.lib using > DevStudio .Net 7.0. > > The output looks like this: > > ------ Build started: Project: Main, Configuration: Debug Win32 ------ > Linking... > MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: __thiscall > type_info::type_info(class type_info const &)" > (??0type_info@@AAE@ABV0@@Z) already defined in libcmtd.lib(typinfo.obj) > MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: class type_info & > __thiscall type_info::operator=(class type_info const &)" > (??4type_info@@AAEAAV0@ABV0@@Z) already defined in > libcmtd.lib(typinfo.obj) > LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with > use of other libs; use /NODEFAULTLIB:library > Debug/Main.exe : fatal error LNK1169: one or more multiply > defined symbols found > > I am working with the "Multi-threaded Debug (/MTd)" version of > libraries. > Tried using alternatives, but I got errors elsewhere and the > errors above persisted. > From boost, I am using the library built at "My Documents\Visual > Studio Projects\boost\libs\date_time\build\bin\libboost_date_time.lib > \vc7\debug\runtime-link-dynamic" > > Any help will be greatly appreciated... You are using the debug DLL version of the date_time library. In order to share a heap with the main program this uses the debug DLL version of the C++ run-time library (MSVCRTD) and requires that the main program uses it too. You must either: (1) Build and use the debug multi-threaded static version of the date_time library. (2) Use the debug DLL versions of the C++ run-time library and MFC in your main program.

2 1

help: boost::thread and compile error
by Guillermo Martony 10 May '04

10 May '04

Greetings, The following code taken from an example compiles without errors: #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> #include <iostream> class thread_alarm { public: thread_alarm(int secs) : m_secs(secs) { } void operator()() { boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += m_secs; boost::thread::sleep(xt); std::cout << "alarm sounded..." << std::endl; } private: int m_secs; }; int main() { int secs = 5; std::cout << "setting alarm for 5 seconds..." << std::endl; thread_alarm alarm(secs); boost::thread thrd(alarm); thrd.join(); return 0; } But adding a std::fstream varible to the thread_alarm class: #include <fstream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> #include <iostream> class thread_alarm { public: thread_alarm(int secs) : m_secs(secs) { } void operator()() { boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += m_secs; boost::thread::sleep(xt); std::cout << "alarm sounded..." << std::endl; } private: int m_secs; std::fstream fs; // only this line was added }; int main() { int secs = 5; std::cout << "setting alarm for 5 seconds..." << std::endl; thread_alarm alarm(secs); boost::thread thrd(alarm); thrd.join(); return 0; } Results in the following compilation error: c:\opt\include\boost\function\function_template.hpp(289): error C2664: 'void boost::function0<R,Allocator>::assign_to(Functor)' : cannot convert parameter 1 from 'const thread_alarm' to 'thread_alarm' with [ R=void, Allocator=int, Functor=thread_alarm ] I'm using Microsoft Studio .NET 2002 Thanks in advance for any help. Guillermo Martony

1 0

Building 1.31.0 with intel-linux for Itanium 2
by Richard Hadsell 10 May '04

10 May '04

I am trying to build the Boost libraries on an Itanium 2 Linux machine using Intel C++ 8.0. The problem is that bjam is creating a directory path for the release versions that uses the string "ebug release" instead of "release". For example: MkDir1 bin/boost/libs/regex/build/libboost_regex.a/intel-linux/ebug release intel-linux-C++-action bin/boost/libs/regex/build/libboost_regex.a/intel-linux/ebug release/c_regex_traits.o ... Despite the directory that it creates with an embedded space, everything actually continues quite well, until it tries to run ranlib: intel-linux-Archive-action bin/boost/libs/regex/build/libboost_regex.a/intel-linux/ebug release/libboost_regex-il-1_31.a Ranlib bin/boost/libs/regex/build/libboost_regex.a/intel-linux/ebug release/libboost_regex-il-1_31.a ranlib: bin/boost/libs/regex/build/libboost_regex.a/intel-linux/ebug: No such file or directory ranlib bin/boost/libs/regex/build/libboost_regex.a/intel-linux/ebug release/libboost_regex-il-1_31.a ...failed Ranlib bin/boost/libs/regex/build/libboost_regex.a/intel-linux/ebug release/libboost_regex-il-1_31.a... I built bjam with this: build.sh intel-linux And I built the libraries with this: bjam -sTOOLS=intel-linux -sINTEL_PATH=/usr/local/intel/compiler80/ia64 --with-python-root=/usr --stagedir=stage -sBUILD="debug release <threading>single" stage Can anyone suggest what might be wrong with my system? It is a loaner, so everything is untested as far as I'm concerned. I have no idea what other tools in addition to Bjam itself might be involved in causing this problem. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

3 5

Re: [Boost-users] Posix extended regexp
by Manish Madan 08 May '04

08 May '04

Thanks a lot for the help John, it works now regards Manish >>> john(a)johnmaddock.co.uk 5/6/2004 1:58:27 AM >>> > What am I doing wrong? > > Here's my short matching function: > > bool MatchRegExp(const std::string& matchThis, const std::string& > againstThis) > { > try > { > const boost::regex e(againstThis);//, > boost::regex_constants::icase); > return boost::regex_match(matchThis, e, > boost::regex_constants::extended); > } > catch(boost::bad_expression be) > { > return false; > } > > } You're passing the wrong constants in all the wrong places, it should have been: const boost::regex e(againstThis, boost::regex::extended); return boost::regex_match(matchThis, e, boost::match_default); You can omit the match_default flag (since it's the default anyway), and if you wanted case insensitive matching it would have been: const boost::regex e(againstThis, boost::regex::extended | boost::regex::icase); Oh, and don't forget to check the difference between regex_match and regex_search (the match version requires all of the text to match). John. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 2

RE: [Boost-users] Re: shared_ptrs with std::mem_fn
by Mark Storer 08 May '04

08 May '04

> boost::mem_fn erases the need for a separate mem_fn_ref. If > http://www.boost.org/libs/bind/mem_fn.html fails to explain it to you, > please ask more specific questions. I thought I'd been pretty specific... guess not. Allow me to reiterate: Why doesn't std::mem_fun work with a container of boost::shared_ptr? I fiddled around with my compiler for a while (vc6), but ended up with a wildly unhelpful error message. Given the following lines of code (among others): --- typedef std::vector<boost::shared_ptr<std::string> > Strings; Strings strings; std::for_each( strings.begin(), strings.end(), std::mem_fun(std::string::size) ); --- my compiler puked up the following wildly useless error message: --- error C2664: 'mem_fun' : cannot convert parameter 1 from 'unsigned int (__thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::*' to 'unsigned int (__thisca ll std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::*' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast --- Allow me to pull out those two types for easier viewing: unsigned int (__thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::* unsigned int (__thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::* Golly. Those 'two' types are about as related as you can get. So why won't std::mem_fun work through boost::shared_ptr's operator->? Here's the mem_fun that ships with VC6: --- template<class _R, class _Ty> class mem_fun_t : public unary_function<_Ty *, _R> { public: explicit mem_fun_t(_R (_Ty::*_Pm)()) : _Ptr(_Pm) {} _R operator()(_Ty *_P) const {return ((_P->*_Ptr)()); } private: _R (_Ty::*_Ptr)(); }; --- The relevant portion to our discussion is: "{return ((_P->*_Ptr()); }" which can be further boiled down to: return _P->_Ptr(); This looks an awful lot like it should work with a shared_ptr's operator->(). So why doesn't it? I admit that this is more of a C++ question than a boost one, but it's not too much of a tangent and I *am* curious. Mentioning mem_fun_ref in my previous post only served to muddy the waters. My apologies. --Mark Storer Senior Software Engineer Verity, Inc.

2 1