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

Re: [boost] Boost.Convert+Boost.Parameter
by Vladimir.Batov＠wrsa.com.au 24 Feb '09

24 Feb '09

Trying to use Boost.Parameter as Daniel showed. Wow, that's truly hairy stuff. Obviously I get it wrong somewhere as matching Parameters constructor cannot be found. I am trying to call int ii = convert_to<int>("1", boost::convert_parameters::default_ = -1); when I have declarations below as (I think) Daniel indicated. namespace convert_parameters { BOOST_PARAMETER_NAME((from_, tag) from_) BOOST_PARAMETER_NAME((default_, tag) default_) } template<class TypeOut, class ArgumentPack> TypeOut test(ArgumentPack const& args) { return TypeOut(); } template< class TypeOut, class TypeIn, class A0> convert<TypeIn, TypeOut> convert_to(TypeIn const& value_in, A0 const& a0) { typedef parameter::parameters<parameter::required<convert_parameters::tag::from_> > Parameters; return test<TypeOut>(Parameters(value_in, a0)); } Any help? Please? Thanks, Vladimir.

3 2

[Phoenix2] nothing is not an actor
by Francois Barel 24 Feb '09

24 Feb '09

Hi, In core/nothing.hpp, "nothing" is defined as: null_actor const nothing = null_actor(); which doesn't make it an actor, rather an "actor base". Shouldn't it rather be defined as something like: actor<null_actor> const nothing = null_actor(); Thanks, François

3 2

Re: [boost] wiki.boost.org Ancient
by David Abrahams 24 Feb '09

24 Feb '09

on Mon Feb 23 2009, DongInn Kim <dikim-AT-osl.iu.edu> wrote: > Hi David, > > Can you setup the DNS of wiki.boost.org to just point to 129.79.245.252 without > aliasing for svn.boost.org? > This cause me difficult to setup its vhost properly. > > For example, > > [root@wowbagger wiki.boost.org]# host wiki.boost.org > wiki.boost.org is an alias for svn.boost.org. > svn.boost.org has address 129.79.245.252 > [root@wowbagger wiki.boost.org]# host beta.boost.org > beta.boost.org has address 129.79.245.252 > [root@wowbagger wiki.boost.org]# I could, but --- and I'm no www expert --- I think there ought to be a redirect so that there's a canonical web address for the wiki. Otherwise you get search engines spidering it twice, etc, no? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

Re: [boost] Formal Review Request: Boost.Convert
by Vladimir.Batov＠wrsa.com.au 23 Feb '09

23 Feb '09

Stewart, Robert wrote... > I assume that's a reference to me. My suggestion of "conversion" was as a namespace name. > Were you referring to my suggestion of using "converter" for the function object and "convert" > for the function template that would deduce template parameters? Yes, I was referring to that latter suggestion of yours: >> namespace boost >> { >> ...class convert; > s/convert/converter/ ... > template <class TypeOut, class TypeIn> > TypeOut const > convert(TypeIn _input, TypeOut const & _default) > { > return converter<TypeIn,TypeOut>(_input, _default); > } I've essentially implemented function wrappers as you suggested. Only I called them convert_to() and convert_from() that I am hoping many people will be happy with (remembering string_to/from et al) as the names could not be any clearer: int i = convert_to<int>(str); int i = convert_from(str, -1); int i = convert_from<string, double>(str, -1); That allowed me to keep the function object as "convert" and, say, apply it to algorithms as std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert<string, int>(string(), -1) >> std::hex); which is kinda nice as well. Do you agree? Thanks, Vladimir.

1 0

Re: [boost] Formal Review Request: Boost.Convert
by Vladimir.Batov＠wrsa.com.au 23 Feb '09

23 Feb '09

I've implemented the functionality as I described (convert as a class) and uploaded it as v0.21. I feel it is a considerable step forward in many respects as now it is more of a conversion 'framework' as users can create their specific specializations of boost::convert for their specific needs (as I did with lexical_cast). At the same time it feels reconciliatory as fighting over names could be put to rest (I hope) as we or the users might write simple and generic wrappers to boost::convert. In particular, I added boost::convert_to and boost::convert_from. It's just a suggestion. We might decide to keep them or remove or rename them. I am not fussy about it. So, the deployment loos as follows: // Explicitly specified 'from' and 'to' types. My personal preference int i = boost::convert<string, int>(str, -1); string s = boost::convert<int, string>(-1, "conversion failed"); // Deduced 'from' type. int i = boost::convert_to<int>(str); string s = boost::convert_to<string>(-1); // Both types are deduced. int i = boost::convert_from(str, -1); string s = boost::convert_from(-1, "conversion failed"); Robert suggested renaming 'convert' to 'conversion' but I am not warming up to that (yet, you might have noticed I am slow) as I essentially see 'convert' as a functor, i.e. encapsulating as an action, i.e. a verb is more appropriate. For that reason the code itself looks readable (to me) as "boost::convert<int, string>" reads as 'convert int to string". Thanks, Vladimir.

2 1

[proto] lazy functions in custom domains
by Dean Michael Berris 23 Feb '09

23 Feb '09

Hi Guys, I've recently tried to play around with Boost.Proto and I think I've run into a wall. I was trying to figure this (relatively simple) case out for a while already but it I'm at my wits end not seeing why the implementation doesn't work. I'm pasting the contents of the file (unmodified) which I've tried to follow from the Getting Started document. I was trying to get the custom domain approach working, but I never seem to get the lazy function to be called. The expected result from the code below would be to have multiple lines of output that says "Getting the friends of user # ;)" but I don't see those. There are no compilation errors, and I don't see anything obviously wrong from the implementation and how I understand Lazy functions. I'm just not sure about how lazy functions though can be made part of a domain though -- didn't find anything in the Getting Started guide about it. Help would be very much appreciated (BTW I'm using Proto that's in Boost 1.38.0, building with GCC 4.0 in Mac OSX 10.5.6): ---->8-- #include <iostream> #include <boost/proto/proto.hpp> #include <vector> namespace mpl = boost::mpl; namespace fusion = boost::fusion; namespace proto = boost::proto; using proto::_; using std::vector; using std::cout; using std::endl; struct user_tag; template <class Tag> struct placeholder {}; struct friendster_action_context : proto::callable_context<friendster_action_context const> { uint32_t user_id; friendster_action_context(uint32_t id) : user_id(id) {} friendster_action_context(friendster_action_context const & other) : user_id(other.user_id) {} friendster_action_context & operator= (friendster_action_context other) { other.swap(*this); return *this; } void swap(friendster_action_context & other) { std::swap(user_id, other.user_id); } typedef uint32_t result_type; result_type operator() (proto::tag::terminal, placeholder<user_tag>) const { return this->user_id; } }; template <class Expr> struct friendster_action; struct friendster_action_domain : proto::domain<proto::pod_generator<friendster_action> > {}; template <class Expr> struct friendster_action { BOOST_PROTO_EXTENDS(Expr, friendster_action<Expr>, friendster_action_domain); typedef void result_type; result_type operator()(uint32_t id) const { friendster_action_context ctx; ctx.user_id = id; return proto::eval(*this, ctx); } }; friendster_action<proto::terminal<placeholder<user_tag> >::type> const user = {{}}; struct friend_fun { typedef vector<uint32_t> result_type; template <class T> result_type operator() (T id) const { cout << "Getting the friends of user " << id << " ;)" << std::endl; return result_type(); }; }; template <class Arg> typename proto::result_of::make_expr< proto::tag::function, friend_fun, typename proto::result_of::as_child<Arg const>::type >::type friends(Arg const & arg) { return proto::make_expr<proto::tag::function>( friend_fun(), proto::as_child(arg) ); } #include <algorithm> using namespace std; int main(int argc, char * argv[]) { uint32_t users[] = { 1, 2, 3, 4 }; uint32_t * begin = users; uint32_t * end = users + 4; cout << "Here they are: " << endl; for_each(begin, end, friends(user)); string input; cin >> input; return 0; } ---->8-- -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

2 2

[gil][ublas] Point2DConcept and ublas vector concept
by Christoph Heindl 23 Feb '09

23 Feb '09

Hi, I'd like to use my boost::ublas::bounded_vector types interchangeable with boost::gil::point2 which from my point of view makes totally sense: A convex hull algorithm for 2D would only need to be implemented once (for world coordinates and pixel coordinates) for example. This, however, seems impossible right now because of the differences in their concepts. Is it possible to somehow make a bridge between them (without copying structures)? Any plans to unify those concepts and reuse ublas types? Best regards, Christoph

1 0

Trac tickets: fixed in trunk vs. fixed in release
by Steve M. Robbins 22 Feb '09

22 Feb '09

Hi, For each bug, there are really two levels of "fixed": roughly speaking, the developer considers the issue fixed when it is committed to trunk, while the user considers the issue fixed when it is commited to the release branch. At present, the trac ticket is closed at the first gate. Unfortunately, sometimes the second gate gets forgotten. Could another state be added to the ticket lifecycle to track when it gets merged to release? My aim is to be able to identified "fixed" tickets that are not actually released and, hopefully, to decrease them in number. Maybe there are other ways to achieve this? Regards, -Steve

5 10

[Iterator] Two sets of docs?
by John Maddock 22 Feb '09

22 Feb '09

The iterator library seems to have two sets of docs: one in quickbook format and one in restructured text. Which is the correct up-to-date version, and can we get rid of the other to avoid confusion? Thanks, John.

2 2

[test] [gcc-4.3.2] check_is_close and check_is_small issues
by Dean Michael Berris 22 Feb '09

22 Feb '09

Hi Guys, I have recently upgraded to Boost 1.38 from Boost 1.35 and suddenly I get the following warnings from GCC 4.3.2: ../boost_1_38_0/boost/test/floating_point_comparison.hpp:224: error: 'boost::test_tools::<unnamed>::check_is_close' defined but not used ../boost_1_38_0/boost/test/floating_point_comparison.hpp:246: error: 'boost::test_tools::<unnamed>::check_is_small' defined but not used I have warnings treated as errors in my build and I haven't encountered this issue before. Can this be considered a regression and if yes what can I do to work around it? -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

4 6

[range-ex] generators
by Neal Becker 22 Feb '09

22 Feb '09

I have a question of generate. I believe one usually wants generators to have state. Yet, generator is passed by value. This is awkward, the workaround is to manually specify generate<ForwardRange, Generator&>( rng, gen ); Since Generator is the 2nd template parameter we must specify ForwardRange, which might be complicated. I wonder if we should have: template<class ForwardRange, class Generator> ForwardRange& generate( ForwardRange& rng, Generator & gen );

3 3

[c++0x] OK to merge cpp0x branch config changes to trunk?
by Beman Dawes 22 Feb '09

22 Feb '09

See http://svn.boost.org/svn/boost/branches/cpp0x This branch adds the following config macros: BOOST_NO_CHAR16_T BOOST_NO_CHAR32_T BOOST_NO_CONSTEXPR BOOST_NO_DECLTYPE BOOST_NO_DEFAULTED_FUNCTIONS BOOST_NO_DELETED_FUNCTIONS BOOST_NO_EXPLICIT_CONVERSION_OPERATORS BOOST_NO_EXTERN_TEMPLATE BOOST_NO_RAW_LITERALS BOOST_NO_RVALUE_REFERENCES BOOST_NO_SCOPED_ENUMS BOOST_NO_STATIC_ASSERT BOOST_NO_UNICODE_LITERALS BOOST_NO_VARIADIC_TEMPLATES The particular names were discussed in several threads nearly a year ago. The set of C++0x features detected only covers those available in at least one shipping compiler. Although I've tested locally, I'd appreciate it if someone familiar with Boost.Config could take a look at the branch before the config directories get merged into trunk. --Beman

3 3

[filesystem] security questions
by Sergei Politov 21 Feb '09

21 Feb '09

Hi, In *nix systems it is recommended practice to operate with file descriptors rather than file names. The sample commands sequence is: 1) open file 2) check file status (check symlink for instance) 3) process write operation Unfortunately I cannot find a way to do the same using boost::filesystem API. Is it planned to support such style? Best Regads, Sergei

5 5

[threadpool] new v18
by k-oli＠gmx.de 21 Feb '09

21 Feb '09

Hello, I've uploaded a new version to boost-vault. The new library contains the future library from Anthony Williams (because it seams we don't get boost.future in the next time). regards, Oliver

1 0

Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 21 Feb '09

21 Feb '09

Well, the fishing trip did not work out. :-\ Therefore, I would like to request a formal review for the Boost.String.Convert functionality. I've uploaded the file called boost-string-convert.zip to the Vault (http://www.boostpro.com/vault/index.php) It has the conversion-related header, the test/usage executable and the documentation (MS Word, HTML). Compiled on Linux and Visual Studio 2008. At the bottom is the "motivation" introductory section from the docs. There is very little of actually code, so you might just read it rather that suffering through my document mumble. Currently-known issues. 1) The attention was given to the behavior (to provide simple/advanced conversion-failure check, throw/no-throw behavior, locale, formatting) and not to the efficiency. I am sure people will come up with ways to run this damn thing much faster. I am very much looking forward to your contributions as I do not really feel I am any good at it. 2) I've implemented the recently suggested boost::stirng::convert() interface but that might need some additional work to handle corner cases correctly. I promise to look into it in due course. I would like to thank everyone participated in the lexica_cast and boost::string::convert-related discussions and expressing their views and opinions and coming up with suggestions. All of them were heard, considered and much and truly appreciated. I apologize if in the end it does not look out as you might like to see it. I swear, your contributions were not in vain. Thanks, Vladimir. Motivation I had a need for a convenient and uniform facility to convert values to and from a literal textual form. Such a need is common when converting between internal (to a program) data types and their external representations. Typical applications would be reading of configuration files, packing and unpacking internal data to and from, say, XML, etc. The boost::lexical_cast looked very promising and was the preferred solution compared to others (such as C functions, std::stringstream, etc., see the lexical_cast documentation for more discussion about alternatives). Unfortunately, I needed functionality beyond what lexical_cast was providing (configurable throw/no-throw behavior, formatting support, locale support, etc.). After discussions on the Boost developers list and with the lexical_cast author (Kevlin Henney) and the maintainer (Alexander Nasonov) it was collectively decided that the required functionality extensions were not compatible with the idea of what lexical_cast embodied and a more dedicated family of conversion functions with richer interfaces was needed. That decision resulted in the development of the following header-only string-conversion library described in this document: boost::string::convert() The interface is explicit about its purpose ? string-related -- string-to-type and type-to-string -- conversions. It builds on the lexical_cast past experience, offers the already familiar conversion functionality and more: · throw and no-throw conversion-failure handling behavior; · support for the default value to be returned when conversion fails; · formatting support based on the standard (or user-defined) manipulators (like std::hex, std::scientific, etc.); · locale support; · support for various (boost::range-compliant) char and wchar_t-based containers (std::string, std::wstring, char const*, wchar_t const*, char array[], std::vector<char>, etc.); · no DefaultConstructibility requirement for the Target type; · room to grow.

12 73

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