July 2011 - Boost - lists.preview.boost.org

[mpi] Unresolved external
by Nils van der Struis 18 Jul '11

18 Jul '11

Hi all, I installed the boostpro libraries version 1.46.1. Then I got the openmpi 1.4.3 sources and successfully built them with cmake/VS2008. Now I'm trying to run some example code: #include <boost/mpi.hpp> #include <iostream> #include <string> #include <boost/serialization/string.hpp> namespace mpi = boost::mpi; int main(int argc, char* argv[]) { mpi::environment env(argc, argv); mpi::communicator world; if (world.rank() == 0) { world.send(1, 0, std::string("Hello")); std::string msg; world.recv(1, 1, msg); std::cout << msg << "!" << std::endl; } else { std::string msg; world.recv(0, 0, msg); std::cout << msg << ", "; std::cout.flush(); world.send(0, 1, std::string("world")); } return 0; } This keeps giving me the linker error below. My dependencies are libmpi.lib, libmpi_cxx.lib, boost_mpi-vc90-mt-1_46_1.lib, libboost_mpi-vc90-mt-1_46_1.lib. I also tried with the pre built openmpi version 1.5.3 library files, this didn't help. Error 1 error LNK2019: unresolved external symbol "public: __thiscall boost::mpi::communicator::operator struct ompi_communicator_t *(void)const " (??Bcommunicator@mpi@boost@@QBEPAUompi_communicator_t@@XZ) referenced in function "protected: void __thiscall boost::mpi::communicator::send_impl<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >(int,int,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,struct boost::mpl::bool_<0>)const " (??$send_impl@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@communicator@mpi@boost@@IBEXHHABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@U?$bool_@$0A@@mpl@2@@Z) MPITest.obj MPITest I suppose this is caused by the boost.org libraries?! Could somebody help me out here?Thanks

1 0

[local] Review request
by Lorenzo Caminiti 18 Jul '11

18 Jul '11

Hello all, I happy to announce that I have released Boost.Local 0.2.0 incorporating the many valuable suggestions that I have received from this mailing list. I would like to request to add Boost.Local to the review schedule and for any volunteer to be the review manager. Thank you! Boost.Local supports local functions, local blocks, and local exits for C++. For example: #include <boost/local/function.hpp> #include <boost/local/block.hpp> #include <boost/local/exit.hpp> #include <algorithm> #include <iostream> #include <cassert> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, const bind factor, bind& sum) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) add(100.0); size_t size = 2; double* nums = new double[size]; BOOST_LOCAL_EXIT(const bind& size, bind nums) { if (size && nums) delete[] nums; std::cout << "Freed array: " << nums << std::endl; } BOOST_LOCAL_EXIT_END nums[0] = 90.5; nums[1] = 7.0; std::for_each(nums, nums + size, add); // `add` as template parameter BOOST_LOCAL_BLOCK(const bind& sum) { assert(sum == 1975.0); // so far `sum` is 10*100+10*90.5+10*7=1975 std::cout << "Asserted summation: " << sum << std::endl; } BOOST_LOCAL_BLOCK_END return 0; } Documentation: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html Source code: http://svn.boost.org/svn/boost/sandbox/local/ Release Notes for Version 0.2.0 (2011-05-14) 1. Replaced parenthesized syntax with variadic and sequencing macro syntaxes. 2. Profiled library performances against other approaches. 3. Replaced virtual functor trick with casting functor trick (for smaller run-time). 4. Optimized library run-time (rearranging code and not using casting functor trick on compilers that accept local classes as template parameters). 5. Added BOOST_LOCAL_FUNCTION_NAME(inline ...) and BOOST_LOCAL_FUNCTION_NAME(recursive ...). 6. Added BOOST_LOCAL_TYPEOF. 7. Added bind(type) to specify bind type explicitly (skipping Boost.Typeof type deduction). 8. Removed boost::local::function (use boost::function instead). 9. Added boost::local::function::overload to overload local functions (and functors in general). 10. Implemented support for nesting local functions, blocks, and exits into one another. Boost.Local was used by Gregory Crosswhite in one of his project: https://github.com/gcross/CodeSearch -- Lorenzo

6 28

Itanium floating point and negative NaN and changesign function
by Paul A. Bristow 18 Jul '11

18 Jul '11

Antony Polukhin has done some great work on lexical_cast to make it work consistently with nonfinite numbers (infinity and NaNs) without stringstream which required use of a globale C99 facet. // Now try some 'round-tripping', 'reading' "inf" double x = boost::lexical_cast<double>("inf"); // and check we get a floating-point infinity. BOOST_ASSERT(x == std::numeric_limits<double>::infinity()); now does what most people would expect. All lexical_cast tests now pass on the popular platforms - except Itanium platform when parsing -NaN, so lexical_cast<std::basic_string<CharType> > (changesign)(std::numeric_limits<ValType>::quiet_NaN()) ) != -nan \boost-trunk\libs\math\test\test_lexical_cast.cpp I don't access to this platform, or indeed any knowledge of it. The test_sign.cpp which exercises changesign appears to work on this platform. BOOST_CHECK((boost::math::signbit)((boost::math::changesign)(a)) != 0); Can anyone expert on the platform shed any light on this? My reading of some docs only mentions NaN, and never negative ones. Is there anything special about the treatment of negative NaNs? Paul (There are those who believe that negative NaNs should not exist, but I have taken the other view that it is more consistent to permit them, even if their meaning may be uncertain - the *signbit does exist* on most platforms, and so is part of the 'payload' of some 7 (?) bits that the NaN pattern carries. There are similar differences of view on signed zero, but most platforms permit negative zero, mainly because there is a signbit, even for a value of zero.) --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

updating history in beta site
by Vladimir Prus 18 Jul '11

18 Jul '11

I've tried to add some item to 1.47 history in the beta site. I've edited .qbk file, and then went to site_tools directory. According to: http://www.boost.org/development/website_updating.html I am supposed to run 'site-tools.py update' there, but there's no such script, and running 'update.py' results in an error. On the 'live' site, I was able to do that, and in fact, I see new content on: http://www.boost.org/users/history/version_1_47_0.html So, it looks like this functionality is not working just in beta site? Thanks, -- Vladimir Prus CodeSourcery / Mentor Graphics +7 (812) 677-68-40

2 3

[locale] Documentation correction
by Beman Dawes 18 Jul '11

18 Jul '11

The last bullet item on page libs/locale/doc/html/index.html says: Many standard libraries provide only the C and POSIX locales, thus GCC supports localization only under Linux. On all other platforms, attempting to create locales other than "C" or "POSIX" would fail. Actually, locale("") works on most platforms, including PC-BSD and Open Solaris, so needs to be added to the above list of locales that do work. Look at the trunk filesystem regression first test, "locale_info", and click on the Pass link to see the output. locale("") is working pretty much across the board, even on the Darwin tests. Mac OS X is of particular interest because by default locale("") does fall, and the Apple folks have said in the past that they won't fix it. It fails on my Mac mini in the default configuration. Presumably the Darwin regression test machine has something beyond the default configuration. Also, would it be possible to use locales from the Apache library? See http://stdcxx.apache.org/doc/stdlibref/locale.html#Table%C2%A021 --Beman

3 3

[trac] trouble uploading a patch to a ticket
by Jeffrey Lee Hellrung, Jr. 18 Jul '11

18 Jul '11

I'm trying to upload a patch to https://svn.boost.org/trac/boost/ticket/5697 but every time I try for this particular patch I get --------------- Trac Error Submission rejected as potential spam (Akismet says content is spam, External links in post found) --------------- Sometimes I get a captcha thingy, and I enter in the word-things and hit "enter" (cause there's no "Submit" button or something like that), and it just goes to a page that says "Error". I have uploaded other patches to this ticket, so...what gives? Okay, yes, there's some http:// link in the patch, but it's in a comment and I'm not adding it (it's already in the file-to-be-patched). Plus, I don't think it goes anywhere, I tried :/ And I don't see why that would be grounds to reject an attachment. And why the captcha thing doesn't work. For reference, I have attached the patch in this email (and I've also sent it to Dave personally, so I'm not worried (yet) about it getting forgotten). - Jeff

2 2

Boost with Clang via MinGW-w64
by Joshua Boyce 17 Jul '11

17 Jul '11

Hey all, Ruben over at the MinGW-w64 project has started providing a Clang toolchain built upon MinGW-w64. http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-July/016005.html I just tried compiling Boost trunk r72754 with it, and figured I'd post the output here so work can commence bringing it in line with GCC via MinGW-w64. 90% of the errors seem to be a result of a 'call to deleted constructor' which seems to be caused by the shared_ptr library (or its usage)... Then the remaining 5% seem to be quite similar in nature, so it doesn't look like stuff will be too horrible to fix, but I don't know enough about the implementation of shared_ptr to fix it at the moment. One other thing to take into consideration will be the lack of a Clang Windows toolset. Currently when you set your toolset to Clang under MinGW, Boost treats it as Clang-Linux. I'm not sure what exactly that will affect... The script I used and the resulting output is available here: http://www.raptorfactor.com/code/Boost-Clang-MinGW-Output-20110708a.zip Thanks..

4 5

[context] Floating Point Exception
by Daniel Larimer 17 Jul '11

17 Jul '11

Attempting to use the latest Boost.Context implementation on Mac OS X and everything was going fine except for a few small issues: 1) fcontext_x86_64_sysv_macho_gas.S fails to compile because: fcontext_x86_64_sysv_macho_gas.S:50:Unknown pseudo-op: .type fcontext_x86_64_sysv_macho_gas.S:50:Rest of line ignored. 1st junk character valued 95 (_). fcontext_x86_64_sysv_macho_gas.S:51:Alignment too large: 15. assumed. 2) I can fix those errors by commenting out the .type line and changing to .balign 16 or .align 8 3) Compiled with: gcc-4.5.0 -o fcontext_x86_64_sysv_macho_gas.S.o -c fcontext_x86_64_sysv_macho_gas.S 4) protected_stack() cannot map /dev/zero - solutions were to mkfile -n 1m /tmp/zero and then open that - use ::mmap( 0, size__, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0); instead of specifying any file. After getting all of those things "working" I attempted to print out a floating point number and it dies deep inside __ntoa(), but I could get it to crash by doing any floating point operations from within the contexts stack. I noticed that none of the examples test for floating point ops. You might want to include that as part of your standard testing. Dan

2 5

[Pool] Attention all Pool users....
by John Maddock 17 Jul '11

17 Jul '11

Folks, I'm planning on merging the all new and shiny version of Boost.Pool in the sandbox under https://svn.boost.org/svn/boost/sandbox/guild/pool/ into Trunk pretty soon unless anyone objects. There are a lot of bug fixes in this version, plus updated docs (see https://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/pool.pdf) Please let me know if you spot any issues, or if there's something that needs addressing that hasn't been (no promises on that one though!). Regards, John.

2 2

Re: [boost] [Boost-users] [Review] Type Traits Introspection library by Edward Diener starts tomorrow Friday 1
by Frédéric Bron 16 Jul '11

16 Jul '11

>> . BOOST_TTI_HAS_TEMPLATE, BOOST_TTI_VM_HAS_TEMPLATE_CHECK_PARAMS >> and BOOST_TTI_HAS_TEMPLATE_CHECK_PARAMS: not clear from the table what >> it checks for. Is there a class inside T that is declared templaste< >> typename...> name? > > Click on the metafunction name for more info. Yes but it would be better to understand it directly from the table. >> - the documentation of for each macro is too succinct. You should >> re-explain the naming convention that will be used by the macro to >> create the new trait. You could even just give the C++ code that will >> be produced by the macro (just the visible code): >> >> BOOST_TTI_HAS_TYPE(name) >> is equivalent to: >> template< typename T, typename U=notype> >> struct has_type_name { >> const bool value; >> }; >> with value ... >> >> In particular, examples are required for each of them. > > I hear you. I really don't want to duplicate the source code for each in the > doc. Some are pretty long and involved. In fact just the following would be enough: template< typename T, typename U=notype> struct has_type_name; > My tests did not really test > const/volatile cases but I think this is much less of an eventual problem. OK for const but I would not bet on volatile... Good job Eddie. Cheers, Frédéric

1 0