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

Moving my Boost installation
by Robert Jones 05 Jan '11

05 Jan '11

I have Boost installed under Fedora13 in /usr/include, not installed by me, but I imagine done as part of installing Fedora. I have a codebase that uses Boost and builds perfectly, using gcc 4.5.1 Now, if I move my Boost installation mv /usr/include/boost ~rgj/xx and add an appropriate include directive to my compile lines, I get compile errors from Boost headers /home/rgj/xx/boost/date_time/gregorian/conversion.hpp: In function ‘tm boost::gregorian::to_tm(const boost::gregorian::date&)’: /home/rgj/xx/boost/date_time/gregorian/conversion.hpp|44 col 23| error: missing initializer for member ‘tm::tm_sec’ etc, etc Obviously I'm having a minor aberration here...what am I doing wrong? Thx, - Rob.

2 2

[property_tree] Parsing JSON
by Olivier Tournaire 05 Jan '11

05 Jan '11

Hi all, I am currently trying to parse a JSON file, but cannot figure how to achieve this task (see for instance http://ax.itunes.apple.com/WebObjects/MZStoreServices.woa/wa/wsSearch?term=… ). Here is a piece of code: #ifndef ITUNES_JSON_STRUCTURE_HPP #define ITUNES_JSON_STRUCTURE_HPP #include <boost/property_tree/ptree.hpp> #include <string> class itunes_json_structure { public: void load(const std::string &filename); boost::property_tree::ptree m_ptree; }; #endif // ITUNES_JASON_STRUCTURE_HPP #include "itunes_jason_structure.hpp" #include <boost/property_tree/json_parser.hpp> #include <iostream> using namespace std; void itunes_json_structure::load(const string &filename) { using boost::property_tree::ptree; try { // Load the JSON file into the property tree. If reading fails // (cannot open file, parse error), an exception is thrown. read_json(filename, m_ptree); cout << "resultCount = " << m_ptree.get<string>("resultCount") << endl; ptree all_results = m_ptree.get_child("results"); // HERE!!! How can I read the content of the "results" node???? } catch(exception &e) { throw e; } } I am unable to read the content of the "results" node. Could you please give me some help? Regards, Olivier

6 18

[math] fpclassify.hpp fails to compile with Intel icc 11.1
by Gabriel Redner 05 Jan '11

05 Jan '11

Hi all, The following code fails to compile with icc 11.1 under Linux: ========== #include <boost/math/special_functions/fpclassify.hpp> int main() {} ========== The full error is: ========== /usr/include/c++/4.4.5/cmath(500): error: identifier "__builtin_fpclassify" is undefined return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL, ^ detected during: instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::fpclassify(_Tp) [with _Tp=long double]" at line 104 of "/usr/include/boost/math/special_functions/fpclassify.hpp" instantiation of "bool boost::math_detail::is_nan_helper(T, const boost::true_type &) [with T=long double]" at line 137 of "/usr/include/boost/math/special_functions/fpclassify.hpp" instantiation of "int boost::math::detail::fpclassify_imp(T, const boost::math::detail::generic_tag<true> &) [with T=long double]" at line 242 of "/usr/include/boost/math/special_functions/fpclassify.hpp" compilation aborted for main.cpp (code 2) ========== The same code compiles fine under icc 12.0. I also tried explicitly adding: #define BOOST_MATH_DISABLE_STD_FPCLASSIFY before including the header, but got the same error. The math library docs say that icc 10.0 and later are fully supported with no serious caveats, so I presume this is a bug. Should I file a ticket? Please let me know if there is any other information about my system which could be useful to know. Thanks, -Gabe

3 5

Visualizer for boost::tuple
by Mohamed Bana 05 Jan '11

05 Jan '11

Hello, I can't seem to find a visualizer for boost::tuple, does anyone have one lying around somewhere? I'm using Visual Studio 2005, if that's of any help. I appreciate the help. —Mohamed

3 2

Re: [Boost-users] Mingw64 Boost Threads Build
by Dustin T. Clifford 04 Jan '11

04 Jan '11

Jim, The build worked! It's the first successful MinGW64 build that I have had. This build was performed from within Cygwin using the mingw64 toolset. I am attempting a build with the MinGW build you pointed me to. Thank again! However, when I attempt to compile the archive into my library I get the below error. Isdmain.o:Isdmain.cpp:(.text+0x16c3): undefined reference to `boost::thread::start_thread()' Isdmain.o:Isdmain.cpp:(.text+0x9982): undefined reference to `boost::thread::~thread()' Isdmain.o:Isdmain.cpp:(.text+0x9d1a): undefined reference to `boost::thread::~thread()' Isdmain.o:Isdmain.cpp:(.text+0x9dee): undefined reference to `boost::thread::~thread()' Isdmain.o:Isdmain.cpp:(.text+0x9e65): undefined reference to `boost::thread::~thread()' Isdmain.o:Isdmain.cpp:(.text+0xbbc3): undefined reference to `boost::thread::start_thread()' Isdmain.o:Isdmain.cpp:(.text+0xbc7e): undefined reference to `boost::thread::~thread()' Isdmain.o:Isdmain.cpp:(.text+0xbc96): undefined reference to `boost::thread::~thread()' Isdmain.o:Isdmain.cpp:(.text+0xca96): undefined reference to `boost::thread::~thread()' Isdmain.o:Isdmain.cpp:(.text+0xe23a): undefined reference to `boost::thread::thread()' Isdmain.o:Isdmain.cpp:(.text+0xe252): undefined reference to `boost::thread::thread()' Isdmain.o:Isdmain.cpp:(.text+0x10): undefined reference to `boost::thread::~thread()' Isdmain.o:Isdmain.cpp:(.text+0x30): undefined reference to `boost::thread::~thread()' Isdmain.o:Isdmain.cpp:(.text$_ZN5boost6threadaSENS_6detail13thread_move_tIS0_EE[boost::thread::operator=(boost::detail::thread_move_t<boost::thread>)]+0x131): undefined reference to `boost::thread::~thread()' I have examined the library symbols and, indeed, I cannot find the appropriate externs. I jumped from 1.35.0 to 1.45.0. I was just wondering if you have any idea why this would start happening? Am I missing something? Any help would be greatly appreciated. Dustin P.S. I will let you know if this changes with the new MinGW64 build. From: Jim Bell [mailto:Jim@JC-Bell.com] Sent: Tuesday, January 04, 2011 12:04 PM To: Dustin T. Clifford Subject: Re: [Boost-users] Mingw64 Boost Threads Build I did run the regression test last night, FYI... http://www.boost.org/development/tests/trunk/developer/thread.html Last column. All tests pass but one. HTH. -Jim On 1/4/2011 10:39 AM, Dustin T. Clifford wrote: Jim, Thank you. I am going to try your patch now. I will let you know how things work out. Thanks again! Dustin From: Jim Bell [mailto:Jim@JC-Bell.com] Sent: Friday, December 31, 2010 10:35 AM To: boost-users(a)lists.boost.org<mailto:boost-users@lists.boost.org> Cc: Dustin T. Clifford Subject: Re: [Boost-users] Mingw64 Boost Threads Build I have a trunk regression-test platform that runs Mingw64 on Win7-64. It's experimental and isn't in the regression matrix right now, but works as well as any MinGW platform (or pretty close). I use GCC 4.6 from here <http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20W…><http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20W…>. CygWin's not installed on this machine. I've attached my complete set of patches. A little cryptic (and patches a pretty recent trunk revision), but should give you a set of changes that ought to get you close. You should be able to use the pre-built bjam (32-bit). <http://www.boost.org/doc/libs/1_45_0/more/getting_started/windows.html#get-…><http://www.boost.org/doc/libs/1_45_0/more/getting_started/windows.html#get-…> boostrap.bat needs a little hacking for gcc. Good luck! -Jim On 1:59 PM, Dustin T. Clifford wrote: Good Afternoon, We have been using boost-threads for our native APIs and, thus far, Boost has been a godsend! We had a recent request to build a 64-bit version of this API. To accomplish this we have attempted to build using MinGW64. Unfortunately, I have had zero luck getting boost-threads to build. I can build the 32-bit address model without a problem but 64-bit continues to elude me. I first tried Boost 1.35.0 and have now moved on to 1.45.0. I believe that the environment is set up correctly (see below). This build is being performed on a Windows 7 64-bit using MinGW64 from Cygwin. export CC=x86_64-w64-mingw32-gcc.exe export CXX=x86_64-w64-mingw32-g++.exe export LD=x86_64-w64-mingw32-ld.exe I have, also, modified my PATH to use the appropriate 64-bit bintools and aliased gcc, g++ and ld to the 64-bit MinGW64 compilers and linkers. To build Boost I have used the following with no success. boostrap.sh address-model=64 -prefix=<install> --with-libraries=thread; bjam -a install; boostrap.sh -prefix=<install> --with-libraries=thread; bjam -a address-model=64 install; boostrap.sh -prefix=<install> --with-libraries=thread; bjam -a install; The last build attempt succeeds but appears to have built 32-bit binaries. The previous two fail in building boost-threads complaining that 'address-model-64' is not found for certain build artifacts. I have, also, tried the above with a prebuilt bjam with the same results. I have tried much more than what I have cited here (including MSVC builds) with no success (some built but resulted in 32-bit binaries). I have scoured Google and found many talking about this but most either had no resolution or contained instructions that conflicted or made no sense. Does anybody have any insight into how I can produce a 64-bit boost-threads archive? Any help would be greatly appreciated. Thanks in advance, Dustin P.S. If I have missed any information or you need more (build logs are too big to attach), please, let me know.

2 3

Re: [Boost-users] [Proto] Vector Example Compilation Failure
by Hossein Haeri 04 Jan '11

04 Jan '11

Hi Erik, > This is the same problem as last time, although you would need to dig > into BOOST_PROTO_DEFINE_OPERATORS to know that. I see. Would it be too much trouble to ask for an explanation on how you got there from the compiler spew? > I don't think gcc-4.5 was available when Boost 1.42 was released, so > it's not surprising there are problems. Would it be possible for you to > use a more recent version of Boost? It would be a pain 'cause I need to port a lot of things. (Proto is not the only part of Boost that we use.) Anyhow, the bigger pain is that I have no much clue about Proto error messages and our company is committed to be a long-term user of Proto. Therefore, learning how to demystify Proto error messages is of much importance to me and I'm ready to pay the porting price if that's what it takes. :D But, seriously, have you ever thought of including a section or two on how to do that in the Proto documentation? The other (sort of related) thing is that it's come to my attention that Fusion knowledge comes very handy in Proto development. This is though not encouraged at all and I don't really think that the documentations of Fusion and Proto are that nicely tied. TIA, --Hossein

4 7

[Proto] callable_context
by Hossein Haeri 04 Jan '11

04 Jan '11

Dear all, I am trying to use callable_contexts to evaluate expressions like: x >> f >> g >> h; where this would be equivalent to h(g(f(x))). I have derived my context from callable_context, and thought I have overloaded for relevant tags (terminal and shift_right). GCC 4.5.1 (MinGW32, WinXP, SP3) stops with an error message which is cryptic to my current level of knowledge about Proto. I guess that's because I haven't done the job correctely. For your reference, I have included a copy of my program as well as the error GCC gives me in the P.S. section of this posting. Any ideas please? TIA, --Hossein P.S. <code> #include <iostream> #include <boost/proto/proto.hpp> namespace mpl = boost::mpl; namespace proto = boost::proto; using proto::_; using namespace std; struct EWGrandDad { int evaluate() const; }; typedef proto::terminal<double (*) (double)> FunctionType; template<typename> struct EmtExpr; struct EmtGrammar: proto::or_ < proto::terminal<EWGrandDad>, proto::shift_right<EmtGrammar, FunctionType> > {}; struct EmtDomain: proto::domain<proto::generator<EmtExpr>, EmtGrammar> {}; template<typename Expr> struct EmtExpr : proto::extends<Expr, EmtExpr<Expr>, EmtDomain> { typedef proto::extends<Expr, EmtExpr<Expr>, EmtDomain> base_type; EmtExpr(const Expr& e = Expr()): base_type(e) {} }; struct EWBase : EmtExpr<typename proto::terminal<EWGrandDad>::type> { typedef typename proto::terminal<EWGrandDad>::type expr_type; EWBase(): EmtExpr<expr_type>(expr_type::make(EWGrandDad())) {} }; struct EW1: EWBase { EW1(int n1, int n2): n1_(n1), n2_(n2) {} int evaluate() const {return n1_ * n2_;} int n1_, n2_; }; double times2(double d) {return d * 2;} double minus1(double d) {return d - 1;} struct EmtContext: proto::callable_context<const EmtContext> { typedef double result_type; result_type operator() (proto::tag::terminal, const EWGrandDad& ew) const { return ew.evaluate(); } template<typename Expr> result_type operator() (proto::tag::shift_right, const Expr& e, FunctionType f) const { return f(proto::eval(e, *this)); } }; int main() { EmtContext emtCtx; cout << "result = " << emtCtx(EW1(4, 5) >> &times2 >> &minus1); return 0; } </code> <error message> main.cpp: In function 'int main()': main.cpp:82:63: error: no match for call to '(EmtContext) (const boost::lazy_enable_if_c<true, boost::proto::generatorns_::generator<EmtExpr>::result<EmtDomain(boost::proto::exprns_::expr<boost::proto::tag::shift_right, boost::proto::argsns_::list2<const EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::shift_right, boost::proto::argsns_::list2<const EW1&, EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<double (* const&)(double)>, 0l> > >, 2l> >&, EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<double (* const&)(double)>, 0l> > >, 2l>)> >::type)' main.cpp:67:14: note: candidate is: EmtContext::result_type EmtContext::operator()(boost::proto::tag::terminal, const EWGrandDad&) const </error message>

3 7

Mingw64 Boost Threads Build
by Dustin T. Clifford 04 Jan '11

04 Jan '11

Good Afternoon, We have been using boost-threads for our native APIs and, thus far, Boost has been a godsend! We had a recent request to build a 64-bit version of this API. To accomplish this we have attempted to build using MinGW64. Unfortunately, I have had zero luck getting boost-threads to build. I can build the 32-bit address model without a problem but 64-bit continues to elude me. I first tried Boost 1.35.0 and have now moved on to 1.45.0. I believe that the environment is set up correctly (see below). This build is being performed on a Windows 7 64-bit using MinGW64 from Cygwin. export CC=x86_64-w64-mingw32-gcc.exe export CXX=x86_64-w64-mingw32-g++.exe export LD=x86_64-w64-mingw32-ld.exe I have, also, modified my PATH to use the appropriate 64-bit bintools and aliased gcc, g++ and ld to the 64-bit MinGW64 compilers and linkers. To build Boost I have used the following with no success. boostrap.sh address-model=64 -prefix=<install> --with-libraries=thread; bjam -a install; boostrap.sh -prefix=<install> --with-libraries=thread; bjam -a address-model=64 install; boostrap.sh -prefix=<install> --with-libraries=thread; bjam -a install; The last build attempt succeeds but appears to have built 32-bit binaries. The previous two fail in building boost-threads complaining that 'address-model-64' is not found for certain build artifacts. I have, also, tried the above with a prebuilt bjam with the same results. I have tried much more than what I have cited here (including MSVC builds) with no success (some built but resulted in 32-bit binaries). I have scoured Google and found many talking about this but most either had no resolution or contained instructions that conflicted or made no sense. Does anybody have any insight into how I can produce a 64-bit boost-threads archive? Any help would be greatly appreciated. Thanks in advance, Dustin P.S. If I have missed any information or you need more (build logs are too big to attach), please, let me know.

3 4

filesystem3 with qt at windows
by Eirik Haaversen 04 Jan '11

04 Jan '11

Hi all, I'm trying to build the tut2 example in boost version 1.44 using qt's build system (.pro) file. I get the following error when I run nmake after qmake: Microsoft (R) Program Maintenance Utility Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. e:\terratec\projects\common\Qt\4.6.3\bin\qmake.exe -win32 -o Makefile fr edag.pro e:\terratec\projects\common\MicrosoftVisualStudio9.0\VC\BIN\nmake.exe -f Makefile.Debug Microsoft (R) Program Maintenance Utility Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. link /LIBPATH:"e:\terratec\projects\common\Qt\4.6.3\lib" /NOLOGO /DEBUG /SUBSYSTEM:CONSOLE /MANIFEST /MANIFESTFILE:"debug\fredag.intermediate.manifest" /OUT:debug\fredag.exe @C:\DOCUME~1\builder\LOCALS~1\Temp\nmEB2.tmp fredag.obj : error LNK2019: unresolved external symbol "private: static class st d::codecvt<unsigned short,char,int> const * & __cdecl boost::filesystem3::path:: wchar_t_codecvt_facet(void)" (?wchar_t_codecvt_facet@path@filesystem3@boost@@CAA APBV?$codecvt@GDH@std@@XZ) referenced in function "public: static class std::cod ecvt<unsigned short,char,int> const & __cdecl boost::filesystem3::path::codecvt( void)" (?codecvt@path@filesystem3@boost@@SAABV?$codecvt@GDH@std@@XZ) fredag.obj : error LNK2019: unresolved external symbol "void __cdecl boost::file system3::path_traits::convert(unsigned short const *,unsigned short const *,clas s std::basic_string<char,struct std::char_traits<char>,class std::allocator<char > > &,class std::codecvt<unsigned short,char,int> const &)" (?convert@path_trait s@filesystem3@boost@@YAXPBG0AAV?$basic_string@DU?$char_traits@D@std@@V?$allocato r@D@2@@std@@ABV?$codecvt@GDH@5@@Z) referenced in function "public: class std::ba sic_string<char,struct std::char_traits<char>,class std::allocator<char> > const __thiscall boost::filesystem3::path::string(class std::codecvt<unsigned short,c har,int> const &)const " (?string@path@filesystem3@boost@@QBE?BV?$basic_string@D U?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z) fredag.obj : error LNK2019: unresolved external symbol "void __cdecl boost::file system3::path_traits::convert(char const *,char const *,class std::basic_string< unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsi gned short> > &,class std::codecvt<unsigned short,char,int> const &)" (?convert@ path_traits@filesystem3@boost@@YAXPBD0AAV?$basic_string@GU?$char_traits@G@std@@V ?$allocator@G@2@@std@@ABV?$codecvt@GDH@5@@Z) referenced in function "void __cdec l boost::filesystem3::path_traits::convert(char const *,class std::basic_string< unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsi gned short> > &,class std::codecvt<unsigned short,char,int> const &)" (?convert@ path_traits@filesystem3@boost@@YAXPBDAAV?$basic_string@GU?$char_traits@G@std@@V? $allocator@G@2@@std@@ABV?$codecvt@GDH@5@@Z) debug\fredag.exe : fatal error LNK1120: 3 unresolved externals NMAKE : fatal error U1077: 'e:\terratec\projects\common\MicrosoftVisualStudio9.0 \VC\BIN\link.EXE' : return code '0x460' Stop. NMAKE : fatal error U1077: 'e:\terratec\projects\common\MicrosoftVisualStudio9.0 \VC\BIN\nmake.exe' : return code '0x2' Stop. It builds fine on Linux and Mac. I appreciate all hints. BR. Eirik

1 0

Improving extern template usage
by Jens Auer 04 Jan '11

04 Jan '11

Hi, I've been playing around with the extern template implementation of Visual C++ (2005 and 2010) to reduce our overly long build times. Microsoft's implementation does only omit implicit definitions for member functions not defined inline in the class body. This makes the feature rather useless to reduce build times, as most functions in the boost library (and Microsoft's STL) seem to be declared inline and get implicitly instantiated every time, thus forcing the linker to remove them which is quite costly. This behavior is also perfectly valid with the standard where an exception is made for member functions of template classes defined inline. Would it be reasonable to change the coding guidelines to only define trivial member functions in the class body and provide the definitions separatly after the class declaration? I think gcc does implicitly sinatntiate these member functions, but the MS compilers are widely used and a large number of users would benefit.

1 0