October 2011 - Boost - lists.preview.boost.org

[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

[serialization] Technique used for registration of derived through base ( Abrahams wizardy )
by Sebastian Karlsson 11 Oct '11

11 Oct '11

A good while ago I got interested in how the registration process works in boost::serialization, I was never able to understand how the technique works, even if the gist of it is contained in 2 fairly small headers ( boost/serialization/export.hpp & boost/archive/detail/register_archive.hpp ). It would seem the creator of the technique is David Abrahams, so I'm hoping he or anyone else which understands how the registration process works could explain the technique used. >From my understanding it solves the problem of having 2 different sequences of types, and then being able to operate on all the combinations. All the techniques I've seen used previously for this requires the maintenance of some sort of compile time vector of one of the sequences. This is very cumbersome, not only does it needs to manually managed, but the file that defines the vector turns into a large dependency bottleneck. From my understanding the technique used in boost::serialization currently one sequence simply adds an overload to a free function, then at the registration point of the other sequence just having the overloads considered at compile time causes the magic to happen when the return type needs to instantiated. Unless I'm missing something obvious I think it would make for a very interesting subject of an article or discussion on the mailing list. Kind regards, Sebastian Karlsson

1 0

operator traits: ready for addition
by Frédéric Bron 11 Oct '11

11 Oct '11

Dear John, Included is are 2 patches vs trunk with operator traits additions: - boost_type_traits.patch.bz2 to be applied in boost/type_traits - libs_type_traits.patch.bz2 to be applied in libs/type_traits I have also updated the sandbox: :http://svn.boost.org/svn/boost/sandbox/type_traits/ This new version addresses all review comments. Tested with gcc 4.6.1 and intel-linux 12.0. Could be nice if somebody could run the tests with msvc. Hope everything is fine. What would be the best way to add it to the trunk? Regards, Frédéric PS: sorry for the long delay but it is very hard to find some free time with a job and a family.

2 2

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 11 Oct '11

11 Oct '11

On 10/10/2011 4:50 PM, Joel de Guzman wrote: > Everything's green now, Eric. The problem was not pervasive after > all; just a couple of fixes solved everything. Whew! > There's no need to revert. It makes me wonder though if we've missed > something that will blow up in the future. I'll probably have to > scrutinize classes that use proto::extends and check for overloads. The problem is that Spirit defines its own operator overload(s) that compete with Proto's. The officially sanctioned way of doing this with Proto is to use a grammar to restrict Proto's overloads, and then define your own. Admittedly, Proto's docs could be more clear about best practice here. > You might want to warn other proto users of this potential > breaking change. This will need to be mentioned in the release notes, yes. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 11 Oct '11

11 Oct '11

On 10 Oct 2011 10:32:53 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: > Den 07-10-2011 20:45, Joe Mucchiello skrev: >> On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten > Ottosen<thorsten.ottosen(a)dezide.com> wrote: >> >>> Den 06-10-2011 18:27, Phil Endecott skrev: >>>> Thorsten Ottosen wrote: >>>>> Even better, don't use vector<const char*>. What o > you need that for? >>> [snip] >>>> >>>> Here's a real motivating example where I want to use > vector<const >>>> char*>. I have a large file containing null-terminated strings > which I >>>> memory map. After opening the file, I construct some sort of index > of >>>> those strings in a sorted vector. Then I search for things using >>>> std::equal_range, std::lower_bound, or similar. >>> >>> That's a good example, I grant you. >> >> >> I actually have a helper class for this called cstrptr which is a typedef > for the template class >> >> basic_cstrptr<char>. It is a "dumb" wrapper around const > char * that provides some std::string >> > > Also, something like iterator_range<const char*> might be somewhat more > handy to store in the vector. Perhaps in the generic case, but as I said, my class is for magic text found in programs and you practically never need to run generic algorithm against lists of magic text. The value in my class is that it is basically the same size as a pointer to char and has a near nop constructor. But my class might be too specific for boost based on the lack of any reaction to the concept. It is just a little fluff class. Joe

1 0