December 2006 - Boost - lists.preview.boost.org

If boost::fusion is the hammer, then what's the nail?
by Weapon Liu 20 Dec '06

20 Dec '06

I think this is the right place to ask this question. As cool as boost::fusion is, there's still one question that bothers me, that is, if boost::fusion is the hammer, then what's the nail? I sure know that it's generic( more so than boost::tuple) and it's complete( with a bundle of algorithms and cool utilities), and it seems that it "solves" some problem quite well( when I read the documents). However, I found it bothering that the documents didn't even mention one real-world application( boost libs aside). Based on my experience, the most frequent scenarios where boost::tuple/fusion is useful are those where one needs a generated-on-the-fly struct for holding return values bundle, or where one needs to return multiple values transparently( well, nearly so), just like those lua does. Other than that, I can't really imagine a scenario where this kinda stuff kicks butts. The biggest disadvantage of boost::fusion, I think, is that the size of it is known and fixed at compile time, which renders it not so qualified as a truly heterogeneous container. And by the bye, that it can be used to build a handy pseudo-struct that enables full introspection really is a good and fancy feature. However, there's something fundamentally irremediable of it, that is, it can't be used to build a full-fledged class( rather than a POD-struct), which, I think, will too reduce its usefulness w.r.t. this kinda situations. I personally very like this fancy facility, and that's why I present these mumbles here to annoy you guys( if so, my apologies go here:-)) Any comments?

12 56

Re: [boost] Accumulators accumulators. roc_distribution
by Matt Doyle 20 Dec '06

20 Dec '06

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Niitsuma Hirotaka > > Could you please send a complete program that demonstrates > the problem? > > Thanks. > > plz see > roc_curve.hpp > > In this file > accumulators.roc_curve > is implimented, but I can not complie this by some err. > May be defining accumulators inside accumulators > causes some problem. > > roc_distribution.hpp > is simple impl without using accumulators inside accumulators. > It works. > test program is test.cpp > If I understand the implementation of the library correctly nesting accumulators within other accumulators is not a problem. In fact IIRC that was one of the examples. What might be a problem though is having multiple instances of the same accumulator. I was meaning to ask Eric about that but I wanted to try it first, looks you got there before me :) Matt Scanned by McAfee GroupShield {X3BTB534}

2 1

Re: [boost] [asio] header order dependence with <windows.h>
by Matthew Herrmann 19 Dec '06

19 Dec '06

> > Message: 8 > Date: Tue, 19 Dec 2006 20:34:14 +0300 > From: ???? ????????? <olegabr(a)mail.ru> > Subject: Re: [boost] [asio] header order dependence with <windows.h> > To: boost(a)lists.boost.org > Message-ID: <E1Gwir0-0003QL-00.olegabr-mail-ru(a)f80.mail.ru> > Content-Type: text/plain; charset=koi8-r > > Sebastian Redl wrote: > >>> >> It means that while the issue under discussion is not resolved - asio can not be targeted as a proposal for inclusion into the std. and it leads to the conclusion that it doesn't conform to boost goals. sad... >>> >> >>> >> > I disagree. The header order dependency is not something inherent to the >> > ASIO library. If ASIO were to become a standard, then this >> > platform-specific issue would be for the compiler vendor to resolve. For >> > example, MS might have to break back compatibility by not getting the >> > <winsock.h> stuff by default in <windows.h> unless a compiler switch is >> > enabled. >> I'm not sure about this. If the library is required to be header-only by design, then it imposes constraints on the implementation, such as vulnerability to header order dependencies. Either asio will need to be insulated against ordering in system headers, or the system headers on all target platforms will need to provide stronger guarantees on being free of such dependencies. A question of immovable objects and irresistible forces. Best Regards, Matthew Herrmann

1 0

Re: [boost] ptr_container: ptr_map.insert() not compiling?
by Daniel Wallin 19 Dec '06

19 Dec '06

Thorsten Ottosen wrote: > Duane Murphy wrote: >> I'm trying to use boost::ptr_map<> and cannot get calls insert to compile. >> >> I'm on Mac OS X using gcc 3.3 with Xcode. >> >> Even the most basic code fails to compile: >> >> boost::ptr_map< in, int* > my_map; >> int * val = new int( 22 ); >> my_map.insert( 1, val ); > > See http://www.boost.org/libs/ptr_container/doc/ptr_map_adapter.html > > The first argument needs to be a reference: > > int key = 1; > my_map.insert( key, new int(22) ); > > 1.34 adds the followinf overload: > > template< class U > > std::pair<iterator,bool> > insert( const key_type& key, std::auto_ptr<U> x ) > > which does allow the key to be an rvalue (just don't create the auto_ptr > in the function call). Thorsten, I've suggested this before: http://article.gmane.org/gmane.comp.lib.boost.devel/132706/match=re+ptr+con… but I'll try again. Taking the key by reference guarantees nothing except confused users. A more sane way to solve this would be to delay possible implicit conversions until after the pointer has been protected: template <class K, class U> std::pair<iterator, bool> insert(K const& k, U* p) { std::auto_ptr<U> owned(p); this->insert(implicit_cast<key_type const&>(k), owned); } -- Daniel Wallin Boost Consulting www.boost-consulting.com

2 1

Closing your support request
by David Abrahams 19 Dec '06

19 Dec '06

Please see http://sourceforge.net/tracker/index.php?func=detail&aid=1616142&group_id=7… And if you reopen it, please log in to SF and put yourself on the Cc list for this issue; we won't email you about further changes. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[parallel][cvs] source files include wrong head mpi.h?
by gchen 19 Dec '06

19 Dec '06

I am trying to compile the new library parallel in cvs. But its source files are including a file "mpi.h", which does not exists. I bet it should be "mpi.hpp". Regards gchen

3 2

Accumulators accumulators. roc_distribution
by Niitsuma Hirotaka 19 Dec '06

19 Dec '06

Now I am trying to describe Boost.accumulators. roc_distribution To define ROC curve data, we need two p_square_cumulative_distribution 1. cumulative_distribution ture or false potive 2. cumulative_distribution ture or false negative One of the cumulative_distribution can be defined by using dependencies struct roc_distribution : depends_on< p_square_cumulative_distribution > … But I can not find way to use two different cumulative_distribution in single acc class. How to use two different cumulative_distribution in single acc class like the following ? struct roc_distribution_impl... { template<typename Args> void operator ()(Args const &args,bool positive_or_negative) if(positive_or_negative) positive_p_square_cumulative_distribution … else negative_p_square_cumulative_distribution … … }

2 2

Problem with libs/system/src/error_code.cpp
by Glenn Schrader 19 Dec '06

19 Dec '06

I had a problem compiling boost on a sparc solaris 2.8 platform. After a bit of digging the change below (notice the end of the #if). The code in the #else calls strerror_r but solaris doesn't have it. Is this the correct place to send this sort of thing or is there a more formal bug tracking system? Thanks, -glenn BEFORE: std::string errno_md( const error_code & ec ) { # if defined(BOOST_WINDOWS_API) || defined(__hpux) || (defined(__linux) && !defined(__USE_XOPEN2K)) const char * c_str = std::strerror( ec.value() ); return std::string( c_str ? c_str : "EINVAL" ); # else char buf[64]; AFTER: std::string errno_md( const error_code & ec ) { # if defined(BOOST_WINDOWS_API) || defined(__hpux) || (defined(__linux) && !defined(__USE_XOPEN2K)) || defined(__sun) const char * c_str = std::strerror( ec.value() ); return std::string( c_str ? c_str : "EINVAL" ); # else char buf[64];

8 28

Re: [boost] [asio] header order dependence with <windows.h>
by Олег Абросимов 19 Dec '06

19 Dec '06

Christopher Kohlhoff wrote: > On Sun, 17 Dec 2006 21:50:09 +0200, "Yuval Ronen" > <ronen_yuval(a)yahoo.com> said: >> Yes, and to solve it I strongly suggest that you define >> WIN32_LEAN_AND_MEAN as a global define for all you translation units. It >> removes most of the junk inside windows.h, including winsock.h, as far >> as I remember. > > Yes, that is a good idea. Sorry, but I don't think so. 1) This issue will continuously frustrate new users, like it was with Serialization lib. 2) boost goal is to provide libraries that can be candidates to inclusion into the standard. I can not imagine that order of standard headers inclusion would affect my program well-formedness. It means that while the issue under discussion is not resolved - asio can not be targeted as a proposal for inclusion into the std. and it leads to the conclusion that it doesn't conform to boost goals. sad... 3) I can not see why you need to include all these platform dependent definitions in each header file. I believe that applying some kind of Bridge pattern would help to localize these platform dependent definitions/declarations in .cpp files only. 4) I understand that it is not an easy task and it is up to yours to consider my opinion, but I would appreciate if you include this issue into your TODO list. Best, Oleg Abrosimov

2 1

[test][msvc-6.5] Internal Compiler Error on release mode tests
by Anthony Williams 18 Dec '06

18 Dec '06

Hi all, There are a lot of tests that are causing Internal Compiler Errors on msvc-6.5~release. Several of them are in the tests for the test library itself, such as this one: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/o… and this one: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/o… Both these failures occur on a seemingly innocuous BOOST_CHECK_EQUAL. Any ideas? Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

7 45