April 2009 - Boost - lists.preview.boost.org

Building stage by default, pt. 2
by Vladimir Prus 19 Apr '09

19 Apr '09

Hi, previously, we discussed that building the 'stage' target by default would be a good idea -- since some users forget that and don't have an easy way to get at built libraries. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/182787 I've now implemented the change, taking into account the comments in that thread. In particular: - the message now uses absolute paths - the location of headers is explicitly specified Here's an example of the message that is output if you do "./bjam" in Boost root: Building C++ Boost. After the build, the headers will be located at /home/ghost/Work/Boost/boost-svn The libraries will be located at /home/ghost/Work/Boost/boost-svn/stage/lib Use 'bjam install --prefix=<path>' if you wish to install headers and libraries to a different location and remove the source tree. I was considering outputting a 'summary' at the end of the build, as opposed at the beginning, but that would require some Boost.Jam changes and therefore cannot be accomplished at this point of release cycle. Anybody wishes to comment on the wording before this gets merged to release branch? - Volodya

3 6

Re: [boost] [boost::exception] operator >>
by Gaydov Victor 19 Apr '09

19 Apr '09

> > Emil Dotchevski <emildotchevski(a)gmail.com> wrote: >> > hello! i'm using boost::exception in one project and did small modification >> > for myself, what do you think about it ? >> > >> > i don't want to create a lot of exception classes, because my 'catches' will >> > use only a few of them anyway. but while exception is throwing, some >> > functions add different information to it (with operator <<) that is useful >> > in diagnostic messages. >> > >> > so when we decide to extract that information from exception, we need to >> > study what useful information it has. instead of using if-else it'll be nice >> > to use inheritance of _errors_ (not exceptions), for example: >> > >> > throw our_exception () << error_1 (); >> > ... >> > catch (our_exception & e) >> > { >> > re-throw e << error_2 (); >> > } >> > ... >> > catch (our_exception & e) >> > { >> > shared_ptr <base_of_error_1_and_2> ptr; >> > while (e >> ptr) >> > cout << ptr->format_error_message(); >> > } >> > > I understand what you are doing but I don't understand why. Could you > provide a non-abstract example of a use case that benefits from this > addition? No problem. We have to basic exception classes: errors associated with external files or system calls and internal interpreter errors. To work properly, program don't need a lot of information about errors, but we need this information in error messages. boost::exception gives simple way to collect error context so each function does not need to worry about errors it catches, but should just add its context. In result, content of exception depends on it path throw function and modules. A few pieces of code (i omit boring parts): struct silent : virtual exception { inline silent (guid_t e) : exception (e) {} }; struct critical : virtual exception { inline critical (guid_t e) : exception (e) {} }; template <typename level> struct system_error : public level { inline system_error (guid_t e) : exception (e), level (e) {} }; struct info { virtual void printf (boost::format &) const = 0; virtual guid_t format (void) const = 0; virtual ~info () {} }; // in RL we generate them using boost macros :) struct module_info_e : public info { guid_t format (void) const { return 101; } void printf (boost::format & dest) const { const boost::tuple < string, string > & tuple = static_cast < const boost::error_info< module_info_e, boost::tuple <string, string> > *> (this) -> value(); dest % tuple.get<0>() % tuple.get<1>() ; } }; typedef boost::error_info < module_info_e, boost::tuple < string, string > > module_info ; enum { bad_module }; ....... // in Module::arch_dependent::load throw system_error <silent> (bad_module); ..... // in Module::load catch (silent & e) { throw e << module_info (make_tuple ("1.so", "error while loading")); } ..... // in Script::run that can run command that loads module (or not, we don't know) catch (silent & e) { throw e << context_info (make_tuple (current_line)); } ..... // some function that should be stable catch (exception & e) { print_error (e); } print_error() is a point where we should discover exception content. In above example it is like this: ostringstream message; for (boost::shared_ptr <info const> base ; e >> base ; ) { boost::format format (Sys::Instance().Reader <Resources> :: get <char_t*> (base->format ( ))); // get format string for error base->printf (format); // fill format string with error info content message << format << std::endl; } If we use exception hierarchy instead of error information hierarchy we don't have such freedom like this (using virtual functions) because we can't combine error information so random. So it is main purpose -- to avoid worrying about what errors we are catching). Also IMHO it is not too beautiful because a lot of functions shouldn't know anything about error information, only about exceptions, so they should be separated. I don't insist on this, just report changes that I need for myself. I'm sorry i'm too verbose (or sorry if i'm not verbose enough :)

1 0

C++ function bind
by claud.86＠email.it 19 Apr '09

19 Apr '09

Hi to all, i use libboost recently, it is the ideal solution for my software c++. Now I'm using asio and I need to invoke a function like this: fun(time_from_string("2010-01-30 5:03:02"),bind(&timer::run,this)); The body of fun will look like this: void fun(ptime t,void h) { ... timer.async_wait(h); ... } Obviously the return of the type of bind is not void and that is why there is an error. What kind should be the h parameter? Which is the prototype of fun? Thanks for your attention Claudio -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it: http://www.email.it/f Sponsor: Tutto in tempo reale sul tuo cellulare: news, messaggistica istantanea, email e molto altro ancora con m.email.Scopri di più Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8919&d=20090417

3 2

Extracting floating point constant exponent/mantissa at compile time
by Joel Falcou 19 Apr '09

19 Apr '09

I'm seeking a way to perform compile-time "bitwise" casting of floating value aka turning a float into an uint32_t value with the same bit pattern. Eg: -3.14f becoming 0xC048F5C3 I saw a mpl::double_ in the vault but I can't make tail nor head of the trick used in the large macros.hpp file. Considering I only need the capability of storing a flaot as a bit pattern and don't need the additional arithmetic, can someone enlighten me on the process used in mpl::double ?

2 5

[ptr_container] Documentation refers to a nonexistent member function
by Michael Marcin 19 Apr '09

19 Apr '09

The docs mention a release_back method which doesn't seem to exist. http://tinyurl.com/dyaumy -- Michael Marcin

2 1

[range] Extended... maybe?
by Vladimir.Batov＠wrsa.com.au 19 Apr '09

19 Apr '09

I am trying something looking fairly reasonable: string str1 = boost::replace_all_copy(str, 'x', '0'); It obviously fails to compile with: error: no matching function for call to 'begin(const char&)' error: no matching function for call to 'end(const char&)' as replace_all_copy() wants boost::ranges for the 2nd and 3rd parameters: replace_all_copy( const SequenceT &, const Range1T &, const Range2T &); and 'x' and '0' are not boost::ranges. Would that be sensible to extend boost::range along the following lines to allow string_algo to work with individual characters? namespace boost { template<> struct range_iterator<char> { typedef char* type; }; template<> struct range_const_iterator<char> { typedef char const* type; }; namespace range_detail { template<> inline char const* boost_range_begin(char const& c) { return &c; } template<> inline char const* boost_range_end(char const& c) { return &c + 1; } } } Thanks, Vladimir. P.S. I do understand that the following works string str1 = boost::replace_all_copy(str, "x", "0");

6 8

[1.39] Release notes
by Daniel James 19 Apr '09

19 Apr '09

Hello all, If you haven't already, please can you add your release notes for 1.39. It's the same procedure as always, the notes are stored in 'boost_1_39_0.qbk' in the directory: https://svn.boost.org/svn/boost/website/public_html/beta/feed/history If you don't know quickbook please don't worry about the syntax, I'll clean up any problems and rebuild the page daily - all that matters is that your intent is clear. If for any reason you can't commit to the website then email your notes to the list and I'll add them. thanks, Daniel

1 0

[fusion] fix for Ticket #2761
by Stjepan Rajko 19 Apr '09

19 Apr '09

Hi, The attached (minimal) patch addresses ticket #2761: https://svn.boost.org/trac/boost/ticket/2761 I tested the fix on my platform (gcc 4.0.1/darwin) and it didn't break any tests. Could this be committed to trunk? (I *think* I might even be able to do the commit myself, if it is OK). Thanks, Stjepan

1 0

[smart_ptr] make_shared perfect forwarding bug
by Frank Mori Hess 18 Apr '09

18 Apr '09

Perfect forwarding doesn't seem to work quite correctly with boost::make_shared. The attached program, which tries to pass a move-only type through make_shared fails to compile with gcc in c++0x mode. To fix it, I had to change the definition of detail::forward in make_shared.hpp to use rvalue references: #if defined( BOOST_HAS_RVALUE_REFS ) template< class T > T&& forward( T &&t ) { return t; } #endif This is just based on looking at how gcc implements std::forward. Is this the right fix?

2 1

[boost::exception] operator >>
by Gaydov Victor 18 Apr '09

18 Apr '09

hello! i'm using boost::exception in one project and did small modification for myself, what do you think about it ? i don't want to create a lot of exception classes, because my 'catches' will use only a few of them anyway. but while exception is throwing, some functions add different information to it (with operator <<) that is useful in diagnostic messages. so when we decide to extract that information from exception, we need to study what useful information it has. instead of using if-else it'll be nice to use inheritance of _errors_ (not exceptions), for example: throw our_exception () << error_1 (); ... catch (our_exception & e) { re-throw e << error_2 (); } ... catch (our_exception & e) { shared_ptr <base_of_error_1_and_2> ptr; while (e >> ptr) cout << ptr->format_error_message(); } i attached 'test.cpp' and 'operator.cpp' with stupid realization and example. if somebody thinks it can be useful of cause i can rewrite it to make it more practical.

2 2