- Boost - lists.boost.org

[Boost.Regex] Minor documentation issue
by Javier Estrada 20 Dec '06

20 Dec '06

I believe the function validate_card_format should take a const std::string& instead of a const std::string http://www.boost.org/libs/regex/doc/introduction.html bool validate_card_format(const std::string s) { static const boost::regex e("(\\d{4}[- ]){3}\\d{4}"); return regex_match(s, e); }

2 1

[thread] Proposal to add lightweight_mutex and atomic_count
by Andrey Semashev 20 Dec '06

20 Dec '06

Hello, There are "lightweight_mutex.hpp" and "atomic_count.hpp" files in the "detail" directory. I find these tools quite simple and useful in some projects where I don't want to link against the whole Boost.Thread library yet having a degree of portability. But every time I include it the nasty "detail" word in the path always makes me remember that I'm using library's internals that are not the part of public interface. Why not making these tools a part of Boost.Thread library, without any change, of course? A couple of forwarding headers in "boost/thread" and a documentation update would be a nice solution. Thank you. -- Best regards, Andrey mailto:andysem@mail.ru

3 3

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