- Boost - lists.boost.org

[date_time] performance tests
by Greg Rubino 13 Oct '11

13 Oct '11

Hi all, Does anyone know of/have an open source suite of performance tests for Boost.Date_Time? If not, I'll post back with whatever I come up with. Thanks, Greg

1 0

Checking interest in to_string functions
by Antony Polukhin 13 Oct '11

13 Oct '11

As was mentioned in `[boost] to_string(v)` 1) Functions to_string and to_wstring are part of the upcoming C++0x standard. However, there are no functions for char16_t and char32_t conversions. 2) Some users can't use C++11 in some projects for quite some time, but can use boost. 3) "to_string(5)" is a lot shorter than "lexical_cast<std::string>(5)". Some users would like to use a shorter form. Is there interest in stoi, stoll, stof, to_string, to_wstring, to_u16string, stod and other functions for char, wchar_t, char16_t and char32_t conversions? Shall I add them to lexical_cast library, or as a separate conversion library? Best regards, Antony Polukhin

8 15

[ASIO] tcp::socket::async_connect() connections count
by Jim Xochellis 13 Oct '11

13 Oct '11

Hi list, I am testing a slightly modified version of the chat_client/chat_server ASIO examples and I have noticed that, immediately after the tcp::socket::async_connect() call from inside the chat_client constructor, the client is creating and establishing not one, but three TCP connections, only one of which is targeting to the server-port. Furthermore, calling repeatedly the async_connect() seems to constantly create three connections per call. I have also noticed that other programs in my system, which also communicate via TCP (ie the hyper-terminal), only open one connection at the client side. Is this async_connect() behavior, which I have mentioned above, the expected/natural behavior, or maybe I am doing something wrong? If this behavior is expected, is there a reason for it? Do I have a choice to change it? Please note that there is a near-4000 outbound concurrent connections default limit in many Windows-XP installations, hence this question has a practical meaning. Configuration informations: OS: Windows XP Pro SP3 Boost version: 1.46.1 IDE: MVS 2005 Thank you in advance, Jim Xochellis ----- Homepage: https://sites.google.com/site/xochellis/ -- View this message in context: http://boost.2283326.n4.nabble.com/ASIO-tcp-socket-async-connect-connection… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[filesystem] scoped_file feature request?
by Beman Dawes 13 Oct '11

13 Oct '11

There is a long outstanding feature request, #1090 from Marcus Lindblom, requesting the following be added to Boost.Filesystem: class scoped_file { public: explicit scoped_file(const boost::filesystem::path& file) : m_path(file) {} ~scoped_file() { boost::filesystem::remove(m_path); } private: boost::filesystem::path m_path; }; My weakly held opinion is that this request should be rejected. Rationale: Easy enough for users to do themselves, so it doesn't justify the additional surface area it would add to of the library. Does anyone have a killer argument for adding it? --Beman

5 12

Dennis Ritchie passed away
by Nevin Liber 13 Oct '11

13 Oct '11

<https://plus.google.com/101960720994009339267/posts/ENuEDDYfvKP> via Rob Pike - 8:02 PM - Public I just heard that, after a long illness, Dennis Ritchie (dmr) died at home this weekend. I have no more information. I trust there are people here who will appreciate the reach of his contributions and mourn his passing appropriately. He was a quiet and mostly private man, but he was also my friend, colleague, and collaborator, and the world has lost a truly great mind. -- Nevin Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

2 1

BGL: labelled edge graph
by Shaun Jackman 12 Oct '11

12 Oct '11

Hi, I have a directed acyclic word graph (DAWG) [1] for which the fundamentally efficient operation takes a vertex descriptor and an edge label and returns an edge descriptor (if that edge exists). An out_edge_iterator can be used to iterate over the edges to find the edge with the specified label, but it's not very efficient. I plan to extend the BGL API to add the needed functionality. I wanted to check first that this function doesn't already exist, and if it doesn't, ask for suggested names. I was thinking of... pair<edge_descriptor, bool> out_edge( vertex_descriptor u, edge_label i, Graph g); The type of edge_label would depend on the graph. For me, it's a char. This sort of labelled edge navigation also applies to a de Bruijn graph [2]. Cheers, Shaun [1] http://en.wikipedia.org/wiki/Directed_acyclic_word_graph [2] http://en.wikipedia.org/wiki/De_Bruijn_graph

2 1

[numeric][interval] clang support patch
by Jürgen Hunold 12 Oct '11

12 Oct '11

Hi, I've been running into the (in-)famous clang bug http://llvm.org/bugs/show_bug.cgi?id=6907 which prevents detail/c99sub_rounding_control.hpp from working. Boost contains workaround code in <boost/detail/fenv.hpp> which is used by the patch attached. Ok to commit? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

3 3

[thread] How to return a lazy future ?
by Ivan Le Lann 12 Oct '11

12 Oct '11

Hi, Boost.Thread documentation has a section regarding the creation of lazy futures. http://www.boost.org/doc/libs/1_47_0/doc/html/thread/synchronization.html#t… The code on this page runs fine, but I can't find a way to return such future. Naïve code below exits with a boost::broken_promise in unique_future::get(). boost::unique_future <int> create_future() { boost::packaged_task<int> task(calculate_the_answer_to_life_the_universe_and_everything); task.set_wait_callback(invoke_lazy_task); return task.get_future(); } int main() { assert(create_future().get()==42); } Exceptional finish is marked in packaged_task destructor. And regardless of exceptions, since set_wait_callback want something that operates on packaged_task and not on pointed task_base, the code is doomed to do an access violation. So, is there any way to return lazy futures ? Regards, Ivan

1 0

Disable_if_type / is_pair
by Olaf van der Spek 12 Oct '11

12 Oct '11

Hi, I've got a find wrapper (returning a pointer instead of an iterator) that works for map, unordered map, ptr map, etc. I'd like to extent it to set and mult_index. What is the recommended way to disable the second overload? I didn't find a is_pair type_trait or disable_if_type. I call the find() member, which for example vector doesn't have. How should I use the free find() if a member find() isn't available? template <class T, class U> typename T::value_type::second_type* find_ptr(T& c, U v) { typename T::iterator i = c.find(v); return i == c.end() ? NULL : &i->second; } template <class T, class U> typename iterator_traits<typename T::iterator>::pointer find_ptr(T& c, U v) { typename T::iterator i = c.find(v); return i == c.end() ? NULL : &*i; } Greetings, Olaf

2 6

[chrono][system] Make possible to don't provide hybrid error handling.
by Vicente J. Botet Escriba 11 Oct '11

11 Oct '11

Hi, Boost.Chrono provides by default an hybrid error handling for the Clock::now() function, implementing the following prototype Clock::now(system::error_code&= boost::throws()); Now that the standard has accepted the prototype Clock::now() noexcept; and set as NAD-Future the Beman proposal (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3314.html#935) The hybrid prototype can not be noexcept, as the use of boost::throws() force to throw an exception on error. We need to overload the function as follows: Clock::now() noexcept; Clock::now(system::error_code&); This lost the advantages of the announced by the hybrid error handling design (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html) as we are forced to have two implementations. In addition, while most of the uses of now(ec) expect that there is no exception, the prototype can not state it using noexcept, if the boost::throws() semantic is taken in account. Due to this split, we can now make Boost.Chrono a real header-only library if we admit to renounce to use the hybrid interface. The library could add a macro that prevent the inclusion of these prototype, as e.g. BOOST_CHRONO_DONT_PROVIDE_HYBRID_ERROR_HANDLING. The experience while using these hybrid approach and mixing all these semantics has shown me that this doesn't promotes good design and doesn't compose well. Split the prototypes is cleared. system_clock::time_point system_clock::now() noexcept { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) // Note that this call is used only when the platform provides this interface. { BOOST_ASSERT(0 && "Boost::Chrono - Internal Error"); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(system::error_code & ec) { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { if (BOOST_CHRONO_IS_THROWS(ec)) //[1] { boost::throw_exception( system::system_error( errno, BOOST_CHRONO_SYSTEM_CATEGORY, "chrono::system_clock" )); } else { ec.assign( errno, BOOST_CHRONO_SYSTEM_CATEGORY ); return time_point(); } } if (!BOOST_CHRONO_IS_THROWS(ec)) // [2] { ec.clear(); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } Note how the test on whether the ec is thows() in [1] to throw and in [2] see if the ec can be cleared are obscuring what in principle was simple. It will be maybe better to add yet a 3rd prototype that forces the throw_on_error. Clock::now() noexcept; Clock::now(system::error_code&) noexcept; Clock::now(throw_on_error_t&); system_clock::time_point system_clock::now() BOOST_CHRONO_NOEXCEPT { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { BOOST_ASSERT(0 && "Boost::Chrono - Internal Error"); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(system::error_code & ec) { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { ec.assign( errno, BOOST_CHRONO_SYSTEM_CATEGORY ); return time_point(); } ec.clear(); return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(throw_on_error_t & /*tag*/) noexcept { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { boost::throw_exception( system::system_error( errno, BOOST_CHRONO_SYSTEM_CATEGORY, "chrono::system_clock" )); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } While these functions are quite simple and repeating the code is not an issue, when the logic is more complex, this could become a maintenance issue that should be resolved other techniques, as using internal functions, policies, ... I see three alternatives: A- Standard Clock::now() noexcept; B- Standard+Hybrid Clock::now() noexcept; Clock::now(system::error_code&); // takes care of boost::throw() C-Standard+EC+TOE Clock::now() noexcept; Clock::now(system::error_code&) noexcept; Clock::now(throw_on_error_t&); A breaks code using the error_code. C breaks code using the boost::throws() Yet another temporary alternative: D- Clock::now() noexcept; Clock::now(system::error_code&); // takes care of boost::throw() but it is deprecated Clock::now(throw_on_error_t&); We can start by providing D and let the user using boost::throws to move to throw_on_error, and the move to C. In addition the library must provide the user the possibility to don't include the extensions. Which way do you prefer? What do you think? Best, Vicente

4 6