February 2009 - Boost - lists.boost.org

GMANE gateway to the Boost Users mailing list seems dead
by Vladimir Batov 21 Feb '09

21 Feb '09

... as its overall traffic

2 1

Re: [boost] Formal Review Request: Boost.Convert
by Andrzej Krzemienski 21 Feb '09

21 Feb '09

Hi, I would like to propose removing the default value for the second argument of convert. I believe it may be insecure. Let me explain it by exemple. What did I mean when I wrote the following code: string str = readInput(); int men = convert_to<string, int>(str); 1. I meant: "if conversion is impossible, return 0", because I read the documentation thoroughly. 2. I am a novice and didn't really think about the situation where someone types a non-int string. In case of the first option it is all fine, but if the latter is the case, it may have been better to throw an exception to the user. I would propose, rather than having a default "fallback" value to provide two overloads for convert: one with two parameters where you can provide the fallback value, and the other, one-parameter, that would indicate that you want to throw an exception on failure. Yo do not loose much of your original interface, because you can write more explicitly: int men = convert_to<string, int>(str, 0); I find it better because: 1. It forces the writer to type more clearly his intentions. (Or explicitly confirm that he is aware that the string may not be convertible to int.) 2. Releaves you from providing the throw_t argument altogether. This in turn removes the possibility of writing: convert<string, int>(str, -1) >> throw_t(); // What does -1 mean here? Regards, &rzej

2 2

[utility] A fix for the const issue of value_initialized
by Niels Dekker - mail address until 2010-10-10 20 Feb '09

20 Feb '09

The boost::value_initialized<T> utility has a major issue regarding const-correctness: It has a const-qualified conversion operator, returning a non-const reference to the T object it owns. I have already created a ticket, <https://svn.boost.org/trac/boost/ticket/2548>, and mailed Fernando Cacciola (the author of value_initialized) on this issue. He agrees that it should be fixed, and he allows me to do so. The patch I've attached to the ticked replaces the current conversion operator by two of them, overloaded for const and non-const access: operator T const &() const { return this->data(); } operator T&() { return this->data(); } The patch also fixes value_initialized::data() in a similar way. Please let me know if you have any problem with the patch. Otherwise I'd like to apply it to the trunk by the end of the week: https://svn.boost.org/trac/boost/attachment/ticket/2548/value_initialized_c… Note that the issue has been discussed here already five years ago: http://lists.boost.org/Archives/boost/2004/01/59987.php At that time, some non-conforming compilers couldn't deal with conversion operators overloaded for const and non-const access. But now I've tested the value_initialized patch on a few compilers (MSVC 2003, MSVC 2008, CodeGear), and they all succeeded. After the commit, I'll keep a close look at the regression page, of course. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 1

[ignore this] Hello?
by Andrey Semashev 20 Feb '09

20 Feb '09

test

1 0

[any] Multimethod for boost::any and modified boost::any to fit multi method
by nowake＠fiercewinds.net 20 Feb '09

20 Feb '09

Hi All. I create multi method for boost::any using Modern C++ Design's multi method technique. It can dispatch method dynamically like this: _________________________________________________________________________ struct T1 { string operator()(int value) const { return string("T1(int)"); }; string operator()(double value) const { return string("T1(double)"); }; string operator()(A value) const { return string("T1(A)"); }; }; // "entry" to Multi method bool t10(Multimethod::entry<any, any, T1, int>()); bool t11(Multimethod::entry<any, any, T1, double>()); bool t12(Multimethod::entry<any, any, T1, A>()); struct T2 { string operator()(int value) const { return string("T2(int)"); }; }; // "entry" to Multi method bool t20(Multimethod::entry<any, any, T2, int>()); BOOST_AUTO_TEST_CASE(test04) { any m((T1())); any a(0); BOOST_CHECK_EQUAL( any_cast<string>(Multimethod::apply<any>(m, a)), "T1(int)"); a = 0.0; BOOST_CHECK_EQUAL( any_cast<string>(Multimethod::apply<any>(m, a)), "T1(double)"); a = A(); BOOST_CHECK_EQUAL( any_cast<string>(Multimethod::apply<any>(m, a)), "T1(A)"); m = T2(); a = 0; BOOST_CHECK_EQUAL( any_cast<string>(Multimethod::apply<any>(m, a)), "T2(int)"); }; __________________________________________________________________________ If you are interested in this multi method, please see #2749 for detail. https://svn.boost.org/trac/boost/ticket/2749 Thanks, Nowake

4 10

[asio] two-lock queue deadlocks?
by Dean Michael Berris 20 Feb '09

20 Feb '09

Hi Guys, I've run into an issue with defining BOOST_ASIO_ENABLE_TWO_LOCK_QUEUE when using Boost.Asio in Boost 1.38.0. I'm currently implementing an asynchronous HTTP client and when I wanted to try the experimental feature and on a single-core machine apparently I run into a deadlock when the asynchronous handler is itself posting to the same io_service queue that hosted it. Is this a known issue with BOOST_ASIO_ENABLE_TWO_LOCK_QUEUE, or is this a usage issue? -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

1 0

[asio] Received 3 times RST, ACK before the boost TCP returns connection failure
by allen han 20 Feb '09

20 Feb '09

Hi: Pretty new to use the boost library for networking and experienced a problem to use the TCP socket on client side. 1. using the call below to connect server: mSocket.async_connect(endpoint,boost::bind(&handleConnect, this, boost::asio::placeholders::error, ++aEndPointIterator)); 2. found connection is failed, then close the socket void handleConnect(const boost::system::error_code &aErr, boost::asio::ip::tcp::resolver::iterator aEndPointIter) { if (!aErr) { ... } else if (aEndPointIter != boost::asio::ip::tcp::resolver::iterator()) { doClose(); ... } else { ... doClose(); } } 3. From Ethereal, found that SYN, RST/ACK have been sent 3 times before the connection is closed, Client sent Server SYN, Server sent Clinet RST, ACK Client sent Server SYN, Server sent Clinet RST, ACK Client sent Server SYN, Server sent Clinet RST, ACK Question: Any flag to inform the boost TCP stack to return error if it receives the first RST,ACK?

2 1

[1.38] PDF docs release candidate available
by John Maddock 19 Feb '09

19 Feb '09

The release candidate for the PDF build of the 1.38 docs is now available from http://boost.cowic.de/rc/pdf/, unless anyone spots any last minute issues, I'll put these on sourceforge at the weekend. Enjoy, John.

3 6

[date_time] How to build the docs?
by John Maddock 19 Feb '09

19 Feb '09

Am I correct in thinking that the date_time docs need some manual intervention to build correctly? Any instructions? Thanks, John.

1 0

[fusion] C++0x support?
by Ein Held 19 Feb '09

19 Feb '09

Hello is there any chance for c++0x support (rvalue forwarding for the containers' constructors and operator=s' in particular) for fusion in 1.39? Thank you

1 0