- Boost - lists.boost.org

seeking review assistant for Conversion
by Gordon Woodhull 18 Jul '11

18 Jul '11

Hi All, I'm looking for someone to assist in managing the Conversion review at the end of August. This is a great way for people who are new to Boost to learn how the review process works. I especially recommend that prospective library authors try this experience in order to understand how consensus is forged during reviews. I believe that having multiple people managing the review will also help provide a more thorough report, keeping topics from being overlooked or discounted. Responsibilities: - read all reviews and discussion - participate in the review to ensure that discussion comes to some resolution - prepare notes which I will edit and submit as the final review report To be sure, I will not leave all the work to you! We'll either write separate reports and then merge them, or work together on the report more interactively. If the message volume is large, we may split up the topics. If you're interested, please write to me privately. Of course, any public discussion of the review process is also appreciated! Thanks, Gordon P.S. In addition to being a great experience and service to the community, this is something that might look good on your CV. :-)

1 0

Re: [boost] [contract] oldof failure not in N1962?
by Andrzej Krzemienski 18 Jul '11

18 Jul '11

> As far as I can see, N1962 does not say what to do in case of a failure > while evaluating and copying an oldof expression. For example, what shall > Contract Programming do if there is a memory error while taking a copy of > size() to later check the following postcondition? Hi Lorenzo, If we could agree that throwing an exception indicates that the system that hosts the program is in the state where it cannot execute our program anymore (lack of memory, threads), you could just let the thrown exception fly out of your function, as though it was the function that threw it. The function leaves objectsin the correct state: precondition was checked and held, function execution has not yet started. The downside of this solution is that it throws something that the caller might not haave expected. Another valid solution would be "if you cannot check the correctness, at least let the function work". That is, you swallow the exception and abandon checking the postcondition. On the other hand, one may want something opposite: do not let my program run unless you are absolutely sure all checks have succeeded. In this case you might want to signal it, but since it is neither precondition nor postcondition violation, perhaps you need an another callback: "on_inability_to_validate". Then anyone could do what they think is best: 1. Pass the exception 2. Skip postcondition 3. terminate Regards, &rzej

1 0

[type traits extension] test for const volatile& as return type
by Frédéric Bron 18 Jul '11

18 Jul '11

I am still working on the extension of the type trait library to operator detection. I was pretty happy having now all my tests passing with g++, in particular for all possible combinations of const, volatile and reference. I have now some troubles with the intel compiler. The following program reproduces a part of the internal implementation of the operator traits (with T defined below): #include <iostream> void g(T) { std::cout<<"g(T)\n"; } void g(...) { std::cout<<"g(...)\n"; } int main() { int i(0); g(i--); return 0; } This is what I get with g++ 4.6.0 for different values of T: - int&: g(...) - const int&: g(T) - volatile int&: g(...) - const volatile int&: g(...) This is what I get with intel 11.1: - int&: g(...) - const int&: g(T) - volatile int&: g(...) - const volatile int&: error: initial value of reference to const volatile must be an lvalue g++ is just fine for what I want to do but intel issues an error if T is "const volatile&" so that the program cannot compile and the g(...) is not chosen. Does anybody understands if this is the right behaviour according to the standard or if g++ is right chosing g(...)? Cheers, Frédéric

7 21

logging
by Jeff Graham 18 Jul '11

18 Jul '11

Hello, Does anyone know when we can expect a blessed logging facility to make it into an official release of boost? There seem to be 2 logging candidates: 1) one by Andrey Semashev (provisionally accepted 16 months ago in March 2010). 2)one by John Torjo that seems to have finished development 3 years ago at version 0.22.7 in Feb 2008. On John's blog it says it was up for review then. Then a post in May 2008 at http://boost.2283326.n4.nabble.com/what-s-up-with-the-logging-libraries- td2579613.html seems to indicate there will be another version with "quite a rewrite" and implying that may be the version to be reviewed. Can someone give any update on either logger, and if there is any plan for getting them into boost? Thanks

9 15

date_time: second_clock::local_time() results in free in a different heap, vs2008
by Mike Vasiljevs 18 Jul '11

18 Jul '11

When using *Visual Studio 2008, x64, windows 7 *boost release 1.45 *Debug DLL (linked against static C runtime, /MTd) loaded/unloaded by Host application using release C runtime (debug version not avaiable!). *calling "second_clock::local_time()", as in date_time examples Deallocation problems occur when dll is unloaded. Most likely release runtime tries to free debug heap block (as far as i can tell at first inspection). The problem also occurs by calling localtime on its own: time_t tnow; time(&tnow); struct tm *time_local= localtime(&tnow); // use time_local... the following code, where "tm" is stored in local data segment, so no problem occurs, unfortunately highly unportable code: static __time64_t tnow; _time64(&tnow); static struct tm time_local; _localtime64_s(&time_local, &tnow); // use time_local... greetings mike

1 0

[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