- Boost - lists.preview.boost.org

[graph] a patch for dominator_tree.hpp
by Jongsoo Park 20 Apr '09

20 Apr '09

Hi all, Recently, I've got few mails concerning about the performance of my dominator tree implementation in the boost graph library, which can be solved by a simple modification. The attached file is my patch on that problem which is based on the most recent version in the subversion repository. Could somebody who has a permission to modify the code apply this patch? The patch has only 5 lines difference and I've double checked it works correctly. Thanks, Jongsoo

2 2

[math] merge of signbit(-NaN) fix?
by Francois Barel 20 Apr '09

20 Apr '09

Hi, Boost.Math had some changes on trunk a few months ago, on the implementation of signbit, to fix the invalid result of signbit(-NaN) (fixed by using Johan Rade's fp_traits library). Currently, in order to work with multiple Boost releases, Spirit2x uses: - a custom version of signbit when compiled against an older Boost release, - the Boost.Math implementation when compiled against Boost 1.39 or later (on the assumption that those changes will be in Boost 1.39). But looking at the schedule sent by Beman, we're nearing the 1.39 beta (some time this week), and those changes have not been merged to release branch. I was wondering, is it planned to merge them for 1.39, or will it only be done in a later release? Thanks, François

1 0

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

[1.39.0][flyweight] Failing Mac OS test
by Beman Dawes 18 Apr '09

18 Apr '09

On the release branch, test_intermod_holder is failing for all Mac OS testers. See http://beta.boost.org/development/tests/release/developer/flyweight.html The error message is: terminate called after throwing an instance of 'boost::interprocess::interprocess_exception' what(): File name too long Can we get this fixed for the release? If not, it needs to be marked up as an expected failure. Thanks, --Beman

3 4

The noexcept Specifier & Block
by Alexander Terekhov 18 Apr '09

18 Apr '09

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html#noexcept I gather that noexcept void f() { throw 0; } is supposed to be ill-formed versus well-formed noexcept void f() { noexcept { throw 0; } } invoking undefined behaviour. Well, this is not helpful. Both forms shall be well-formed with defined behaviour: invocation of unexpected() at throw point. regards, alexander.

7 29

RFC: serialization library in C only for C only
by Francis ANDRE 18 Apr '09

18 Apr '09

Hi Boosters Following a recommendation of Robert RAMEY about a serialization library similar to the Boost Serialization library but targeted only for the C language and using only the C language and/or some assembly routines, I am looking for any comments/advises on the feasibility of such library. The initial scope would be: 1/ Serialize/deserialize all primitive C types. 2/ Serialize/deserialize all constructed type like struct and union. 3/ Serialize/deserialize a tree/forest of C structures instances linked by pointers. What would be the charge/effort/workload of such library? Does anybody already try/succeed in building such library? Thank in advance for any comment. Francis ANDRE PS: Solving this issue by building a wrapper from C to the Boost Serialization library is not an option, hence this RFC.

2 2

[1.39.0][Interprocess] release branch test failures
by Beman Dawes 17 Apr '09

17 Apr '09

Interprocess has a few scattered failures. See http://beta.boost.org/development/tests/release/developer/interprocess.html Please fix or markup. Thanks, --Beman

3 3

[1.39.0][Interval] Release branch test failures
by Beman Dawes 17 Apr '09

17 Apr '09

Numeric/interval is failing three tests on some of the Mac OS platforms. See http://beta.boost.org/development/tests/release/developer/numeric-interval.… Please fix or markup. Thanks, --Beman

2 1

Boost.Conversion: request for interest
by vicente.botet 16 Apr '09

16 Apr '09

Hi, I've developed a utility library Boost.Conversion. I would like to know if the Boost community is interested in this library. If this is the case, this library could be scheduled for review quite soon. This library is related to LexicalCast, NumericConversion and (String)Convert, but much less specific. It provides a convert_to generic function (like swap) which can be specialized by the user to convert specific unrelated types, and why not, he could use one of the preceding libraries. This convert_to function can be seen as an extrinsec explicit conversion operator. The livrary provides also an assign_to generic function that can be seen as an extrinsec explicit assignement operator. Please let me know what do you think. What is wrong? What is missing? How can I improve it? Thanks, Vicente == Boost.Conversion == Links:http://www.boostpro.com/vault/index.php?action=downloadfile&filename=… Categories: Utilities Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic convert_to function which can be specialized by the user to make explicit conversion between unrelated types. * a generic assign_to function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between std::pair of explicitly convertible types. * conversion between boost::optional of explicitly convertible types. * conversion between boost::chrono::time_point and boost::ptime. * conversion between boost::chrono::duration and boost::time_duration. Soon conversion between std::vector, boost::array, and boost::tuple of explicitly convertible types. Motivation Imagine you need to convert unrelated types Source and Target. You can get it by defining a specific function such as Target SourceToTarget(Source& v); Imagine now that you need to convert a std::pair<Source, Source> to a std::pair<Target, Target>. Well you can again define a specific function std::pair<Target,Target> PairOfSourceToPairOfTarget(std::pair<Source,Source>& v) { return std::make_pair(SourceToTarget(v.fisrt), SourceToTarget(v.second)); } While the SourceToTarget could be specific, the PairOfSourceToPairOfTarget sould be generic template <typename Target1, typename Target2, typename Source1, typename Source2) std::pair<Target1,Target2> ConvertPair(std::pair<Source1,Source2>& v); In order to do that we need that the pair template parameters define a common function, let it call convert_to, template <typename Target, typename Source) Target convert_to(Source& v); so ConvertPair can be defined as template <typename Target1, typename Target2, typename Source1, typename Source2) std::pair<Target1,Target2> ConvertPair(std::pair<Source1,Source2>& v) { return std::make_pair(convert_to(v.fisrt), convert_to(v.second)); } The issue is that we need to specialize the convert_to function for the classes Source and Target. We can do it as follows template <> Target convert_to<Target, Source>(Source& v) {return SourceToTarget(v);} What about converting std::pair<Source,std::pair<Source,Source>> to std::pair<Target,std::pair<Target,Target>>? The issue now is that convert_to(std::make_pair<to, std::make_pair<to,to>>) do not compiles because the conversion of std::pair is named ConvertPair. So we need to specialize the function convert_to for pairs. With C++0x there is no major problem as it allows partial specialization of function templates. With C++98, we need to use a trick; as it allows partial specialization of classes we can define convert_to by as relying to a specific function of a class, as follows: namespace partial_specialization_workaround { template < typename Target, typename Source > struct convert_to { static Target apply(const Source& val); }; } template < typename Target, typename Source > Target convert_to(const Source& val) { return partial_specialization_workaround::convert_to<Target,Source>::apply(val); } So now we can specialize partial_specialization_workaround::convert_to for pairs as follows: namespace partial_specialization_workaround { template <typename Target1, typename Target2, typename Source1, typename Source2) struct convert_to< std::pair<Target1,Target2>, std::pair<Source1,Source2> > { inline static std::pair<Target1,Target2> apply(std::pair<Source1,Source2>& v) { { return std::pair<T1,T2>(convert_to<T1>(from.first), convert_to<T2>(from.second)); } }; } There is one more issue. The preceding design works well with unrelated classes, but what about classes that already define some kind of conversion, using a constructor or a conversion operator. Do we need to make specialization for these conversion? The answer is no. We need just to define the default implementation of the partial_specialization_workaround::convert_to::apply function to just return the explicit conversion. namespace partial_specialization_work_around { template < typename T, typename U> struct convert_to { inline static T apply(const U& val) { return T(val); } }; } What have we learned? Classes or algorithms relying on a conversion by construction or by the conversion operator can be made more generic by relaying in a function that explicitly states this conversion. So instead of requiring Target(from) requires convert_to<Target>(from) The same applies to classes or algorithms relying on the assignment operator. So instead of requiring to = from requires assign_to(from, to); The default implementation of assign_to relies on the assignement operator namespace partial_specialization_workaround { template < typename Target, typename Source > struct assign_to { inline static To& apply(const Source& from, Target& to) { to = from; return to; } }; } template < typename Target, typename Source > To& assign_to(const Source& from, Target& to) { return partial_specialization_workaround::assign_to<Target,Source>::apply(from, to); } So one of the advantages of using this common functions is uniformity. The other is that now we are able to find all the explicit conversions to one type, as we can do with explict casts.

1 0

Re: [boost] Patches in trac...
by Henrik Sundberg 16 Apr '09

16 Apr '09

On Wed, Apr 8, 2009 at 6:24 PM, Marshall Clow <marshall(a)idio.com> wrote: > The conclusion that was reached at the end of the discussion was that we > wanted to get rid of the "Patches" label for Trac tickets, and to move all > the existing patches to either "Bugs" or "Feature Requests". > > What do people think? You might want to add a keyword "patch" to all tickets containing a patch. Just to make it searchable. /$

3 3

Bugfixing Sprints in Cyberspace?
by David Abrahams 16 Apr '09

16 Apr '09

Hi all, At last count, the Boost Trac had over 700 open tickets. I've been thinking I personally could really use an excuse to concentrate on reducing that number (especially the ones assigned to me ;->). It might be fun to try some kind of organized event along the lines that the Ubuntu people use: https://wiki.ubuntu.com/UbuntuBugDay. Does something like this sound like it could work for us? [Okay, maybe we don't have "virtual hugs" and would have to substitute something.] -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 3

[1.39.0] getting started update
by Vladimir Prus 16 Apr '09

16 Apr '09

The attached patch updates getting started to the changes I've did to simplify build process, described in: http://permalink.gmane.org/gmane.comp.lib.boost.devel/188461 and some other existing reality. Specifically: 1. The bootstrap + bjam procedure is documented. 2. The Boost.System library is added to the list of libraries needing compilation. 3. Unix docs are adjusted to use stage/lib everywhere, as opposed to using 'lib' in some cases. Dave, can you review this? I have regenerated HTML and visually inspected them, but HTML diffs are not included for clarity. Thanks, Volodya

2 2

Improved build process
by Vladimir Prus 16 Apr '09

16 Apr '09

Hello, I have completed a set of changes meant to make building C++ Boost somewhat more streamlined, and avoid common pitfalls reported on IRC and mailing lists. In short, C++ Boost can now be build, on Windows, with: bootstrap.bat bjam and on Linux, with ./bootstrap.sh ./bjam I'd imagine that 95% of users won't need anything else, and two commands is a fairly straigh-forward approach. More specifically, the changes I've made are: 1. Some time ago we discussed the configure/make solution: http://article.gmane.org/gmane.comp.lib.boost.devel/181839/ There are two problems with it: - The naming suggests it's automake/autoconf solution, which is not, and users keep on trying automake idioms to find they don't work. - If you just run "bjam" then whatever settings configure made are not considered -- which is very annoying when user has to tweak things beyond what configure offers. Per that thread, I have did two changes: - Renamed configure to bootstrap.sh, avoiding autoconf connotations - Made bootstrap.sh, instead of generating Makefile, generate project-config.jam -- which is automatically read by Boost.Build. 2. Many users forget to specify 'stage' explicitly, and get a pile of libraries in random places. Now, 'stage' is default, and a message saying where libraries go is printed. See: http://article.gmane.org/gmane.comp.lib.boost.devel/188450 3. On Windows, users had to get or build Boost.Jam, and then copy it in %PATH% and then invoke it. Now, bootstrap.bat is a tiny wrapper that builds Boost.Jam and puts it in the root of C++ Boost source tree. 4. On Windows, release libraries were built by default, and debug were not build at all, which does not match default IDE & autolink behaviour. (I think that on Linux, building release by default is fine, since generally debug and release versions are link-compatible). We now build these two variants by default: <variant>debug <threading>multi <link>static <runtime-link>shared <variant>release <threading>multi <link>static <runtime-link>shared These changes are presently on trunk. Most of them are essentially the matter of proper defaults, and proper messages and proper wrappers, not deep hacking, so they are unlikely to disturbing for release. On the other hand, I would very much appreciate comments on "look&feel". So, if you have some time, give it a try and report your experience. I'll take a look at regression results to see if some unexpected breakage appears, and do other round of manual testing on Monday, and then merge this to release branch. Dave, I understand this requires changes to getting started -- for Unix, they are textual replacements only and I have a local patch for that. For Windows, new text is needed that I'll work on as well and should have a patch for your review by Monday. - Volodya

2 1

[TortoiseSVN] Please upgrade if using TortoiseSVN 1.6.0
by Beman Dawes 15 Apr '09

15 Apr '09

There is a bug in TortoiseSVN 1.6.0 that can cause a log request to loop endlessly under certain conditions. When this happens an endless stream of requests is sent to the server. This may be why the svn.boost.org server is getting hammered, and response time is slow. It affects trac too, as it runs on the same server. The problem is fixed in release 1.6.1, so please upgrade to that release if you are currently running TortoiseSVN 1.6.0. Thanks, --Beman

1 0

Cross compilation problem
by Jostein Austvik Jacobsen 15 Apr '09

15 Apr '09

I'm trying to cross compile boost 1.38 for the gumstix motherboard (ARM) like this: wget --tries=10 http://heanet.dl.sourceforge.net/soruceforge/boost/boost_1_38_0.tar.gz tar xzf boost_1_38_0.tar.gz cd boost_1_38_0 echo "using gc : `${GUMSTIXTOP}/tmp/cross/arm-angstrom-linux-gnueabi7bin/g++ -v 2>&1 | tail --1 | awk '{print $3}'` : ${GUMSTIXTOP}/tmp/cross/arm-angstrom-linux-gnueabi7bin/g++ ; " > tools/build/v2/user-config.jam sudo apt-get install bjam sudo bjam --toolset=gcc-arm --prefix=/opt/gumros install It seems to compile correctly, but when I compile my application that depends on Boost (I have remembered to tell it where to find the cross compiled boost), I get this: /home/jostein/gumstix/gumstix-oe/tmp/cross/lib/gcc/arm- angstrom-linux-gnueabi/4.1.2/../../../../arm-angstrom-linux-gnueabi/bin/ld: skipping incompatible /opt/gumros/lib/libboost_thread-gcc-mt-1_38.so when searching for -lboost_thread-gcc-mt-1_38 This looks like Boost wasn't cross compiled at all (or at least incorrectly). Are there any obvious problems with the way I'm doing this? Eventually, does anyone use bitbake and have a working recipe for one of the newer Boost releases (1.35+)? Regards Jostein

3 6

[signals2][interprocess][1.39] Testing variadic templates
by Daniel James 15 Apr '09

15 Apr '09

Hi, The gcc config hasn't been defining BOOST_HAS_VARIADIC_TMPL correctly when C++0x support is available. I've fixed this in trunk but it means that variadic template support hasn't been tested correctly for a while and there are failures in your regression tests. Can you have a look at them before I merge to release? thanks, Daniel

3 2