- Boost - lists.boost.org

[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

Re: [boost] [filesystem] scoped_file feature request?
by Andrzej Krzemienski 11 Oct '11

11 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 Hi, I would add to the rationale for rejection, that scoped_file's destructor performs an operation that might throw an exception, which is counter to well established practices in C++. You could use the error_code version, but that would hide the error if any occurs. Regards, &rzej

1 0

BOOST_FORCE_INLINE
by Mathias Gaunard 11 Oct '11

11 Oct '11

I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp Who do I need to contact to make this happen?

16 31

Problems with proto and /clr
by Jorge Lodos Vigil 11 Oct '11

11 Oct '11

Hi In boost 1.47 proto stopped compiling with /clr in VS2008 and VS2010. Take the calc3 example, for instance. The root problem is that /clr is instantiating templates that normally are not. The change in proto is the new is_applyable metafunction. In normal compilation, when the received parameter is not callable mpl::and_ ensures that there is no need to fully instantiate the is_transform metafunction parameter. Apparently when using /clr it gets instantiated any way. You may verify this commenting out the 3 BOOST_MPL_ASSERT_RELATION lines in calc3 sample (so it will compile) and adding the following in the main function: // This is an instantiation of is_applyable that causes problems typedef boost::mpl::max<CalculatorGrammar,boost::proto::_state> is_applyable_parameter_t; // This is why it normally compiles BOOST_MPL_ASSERT_NOT((boost::proto::is_callable<is_applyable_parameter_t>)); // The following correctly fails to compile, the is_transform metafunction must never be instantiated //bool is_tranform = boost::proto::is_transform<is_applyable_parameter_t>::value; // This is the line that does not compile with /clr but normally does typedef mpl::and_<mpl::false_, boost::proto::is_transform<is_applyable_parameter_t> > problem_t; This code fails to compile with /clr, because is_applyable_parameter_t is instantiated and CalculatorGrammar is not comparable. Before I continue to dig in proto code, try workarounds and create tickets, I thought I might ask these questions here: 1. In case a workaround can be found (decomposing is_applyable in 2 metafunctions, for instance) is it of interest to support /clr? 2. Is this situation a compiler bug, a proto bug or just bad luck + undefined behavior? I'll appreciate any comment you may have on this. Please note that this causes xpressive and probably spirit to fail compilation with /clr. On a side note note, if there is interest to support /clr, it should not be a problem to modify MSVC test scripts. Only the /clr parameter must be added to the command line, nothing else. Apparently there is no big demand for C++ with /clr, but if there is interest I could try to modify tests scripts and correct any problem that may surface. Thank you in advance for your time. Best regards Jorge

2 1