- Boost-users - lists.boost.org

[GIL] About `packed_channel_value` (possible improvement)
by TONGARI 14 Feb '13

14 Feb '13

Hi, I took a look into "channel.hpp" and found that packed_channel_value is not very efficient in construction. There are: packed_channel_value(integer_t v) { _value = static_cast< integer_t >( v % num_values ); } // I have no idea why this exists, seems OK to remove it template <typename Scalar> packed_channel_value(Scalar v) { _value = static_cast< integer_t >( v ) % num_values; } IIUC, "v % num_values" above could be replaced with a much cheaper "v & low_bits_mask_t<NumBits>::sig_bits_fast". That is: packed_channel_value(integer_t v) : _value(v & low_bits_mask_t<NumBits>::sig_bits_fast) {} What do you think? Am I missing some point? Thanks.

2 7

[ASIO] Any HTML5 video streaming server with boost asio?
by Goran 14 Feb '13

14 Feb '13

Hi all, do anybody knows something about HTML5 video streaming with boost::asio? I've looked into the tutorials and would like to use the html server examples to integrate into my app. So far anything is clear but video streaming is something I've never done. Are any resources out there? Thanks in advance! G.

1 0

Documentation Install
by Robert Patterson 14 Feb '13

14 Feb '13

I download a tar ball, configured, built and installed (thank you). I then removed the entire build tree and realised I no longer had the docs (linked via libs/index.html). Obviously I can explode the tar ball again, but is there a simple way of keeping the docs without the whole tree - something like ./make installdocs ? Thanks Robert Patterson

1 0

Re: [Boost-users] Boost.Move BOOST_MOVABLE_BUT_NOT_COPYABLE macro
by luke 14 Feb '13

14 Feb '13

(13/02/14 5:57), Ion Gaztañaga wrote:> El 13/02/2013 6:36, luke escribió: >> As deleting the copy constructor fixes the issue (i.e. test(test const&) >> =delete;), would it be at all possible for >> BOOST_MOVABLE_BUT_NOT_COPYABLE to do the same for compilers that support >> the syntax? > > Thanks for reporting it. It's already done. See: > > https://svn.boost.org/trac/boost/ticket/7969 > > If you can confirm the issue is fixed in trunk, I'll close the bug. > > Best, > > Ion Ah I guess I should have checked there first, sorry! http://svn.boost.org/svn/boost/trunk/boost/move/core.hpp works perfectly for me, thanks. Luke

1 0

Boost.Move BOOST_MOVABLE_BUT_NOT_COPYABLE macro
by luke 13 Feb '13

13 Feb '13

Due to GCC 4.7.2 and lower not supporting a change in template deduction rules as explained in the answer below http://stackoverflow.com/questions/14808663/stdunordered-mapemplace-issue-w… the following code will not compile: #include <utility> class test { public: test() =default; private: test(test const&); }; int main() { std::is_convertible<test&, test>::value; }; For the same reason, it is not possible to use classes which use the BOOST_MOVABLE_BUT_NOT_COPYABLE in situations where libstdc++ uses std::is_convertible, for instance when using piecewise construction in std::unordered_map::emplace() (I came across the issue when making an unordered_map of boost::file_mapping) As deleting the copy constructor fixes the issue (i.e. test(test const&) =delete;), would it be at all possible for BOOST_MOVABLE_BUT_NOT_COPYABLE to do the same for compilers that support the syntax?

2 1

[Contract] Eagerly waiting...
by Robert Jones 13 Feb '13

13 Feb '13

Hi Lorenzo (or anyone who knows) AFAICS your contract library seems to have been approved for a while, but not made it into a release. Do you have an ETA for this? Thx, Rob.

2 1

Communication between QThread and boost threads
by ustulation 13 Feb '13

13 Feb '13

The Gui is in Qt and Api is in boost. The Gui is meant to sit on top of Api. One of the functions of Api is to do network level data management, process data in certain ways and communicate with the Gui (ie., bridge Gui with other end of Api). To keep the GUI from freezing Api does it's work in a separate thread. If both Gui and Api had used Qt, communication would have been easier with cross-threaded signal-slot mechanism of Qt. Api emits and returns immediately and vice-versa. So none would be blocked unless explicitly specified (*Qt::BlockingQueuedConnection*). I've been using boost only since a while back as it was required to code new Api in boost. How do i achieve this mechanism in *boost <--> Qt communication*? Api is going to be header+static_library and so Gui and Api will produce single executable. I have to support Linux, Windows and Mac minimum. -- View this message in context: http://boost.2283326.n4.nabble.com/Communication-between-QThread-and-boost-… Sent from the Boost - Users mailing list archive at Nabble.com.

3 5

Re: [Boost-users] [Chrono] Memory leak in Chrono?
by Don 13 Feb '13

13 Feb '13

> Subject: Re: [Boost-users] [Chrono] Memory leak in Chrono? > From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> > Date: 2/12/2013 1:17 PM > > Le 12/02/13 18:13, gast128 a écrit : >> we use Boost.Chrono too. MFC applications incorrectly report memory leaks, which can easily be solved. > Hi, > > if you have some patches to propose to avoids this incorrect reports I would try to include them. Vincente, I am using MFC, but I don't believe this is a MFC false-leak report. I added a destructor for duration_units_default_initializer_t, like this (near the end of chrono/io/duration_units.hpp): ~duration_units_default_initializer_t() { if (duration_units_default_holder<CharT>::initialized_) { delete[] duration_units_default_holder<CharT>::n_d_valid_units_; duration_units_default_holder<CharT>::n_d_valid_units_ = 0; delete[] duration_units_default_holder<CharT>::valid_units_; duration_units_default_holder<CharT>::valid_units_ = 0; duration_units_default_holder<CharT>::initialized_ = false; } } This solves the memory leak, and seems to work fine for my simple test program. But n_d_valid_units_, valid_units_, and initialized_ are static variables, so I assume you want to only create these variables once. When run with my test program and step through it in the debugger, only one instantiation of duration_units_default_initializer_t occurs. (That is, once for each char type, single-byte and wide.) This occurs when the duration_units_default_initializer is instantiated (at the very end of duration_units.hpp). Since this is a global variable, this occurs during application startup and the destructor runs during application shuttdown. But presumably this can occur in some other situations, otherwise why would you have all the logic of making valid_units_ etc. class-static variables. I don't think I understand enough about what is going on to propose a robust solution. Thanks for your help, Don

2 1

boost::thread include order error
by Rob Patro 13 Feb '13

13 Feb '13

Hi, I noticed that when I don't include <boost/thread/thread.hpp> before the standard library includes, I get the following errors: In file included from /fs/szattic-asmg6/rob/dist/include/boost/thread/lock_types.hpp:14:0, from /fs/szattic-asmg6/rob/dist/include/boost/thread/pthread/thread_data.hpp:12, from /fs/szattic-asmg6/rob/dist/include/boost/thread/thread.hpp:17, from /fs/szattic-asmg7/rob/countseq/include/iterative_optimizer.hpp:26, from /fs/szattic-asmg7/rob/countseq/src/sailfish.cpp:33: /fs/szattic-asmg6/rob/dist/include/boost/thread/lockable_traits.hpp:90:37: error: expected identifier before ‘*’ token /fs/szattic-asmg6/rob/dist/include/boost/thread/lockable_traits.hpp:114:37: error: expected identifier before ‘*’ token However, when I move the boost thread include to the top of the set of included headers (above the standard library), the program compiles and runs correctly. What is the reason for this frustrating requirement? Is it possible to eliminate this behavior, so that <boost/thread/thread.hpp> can be included anywhere (or at least after the standard library) ? Thanks, Rob

2 1

[Preprocessor] How to work around empty sequence?
by Adam Badura 13 Feb '13

13 Feb '13

I was using sequences happily until I realized that quite often I will have an empty collection. Yet empty sequences are not supported. So I switched to lists. But they are syntactically so much worse! You have to add that BOOST_PP_NIL. You have to take care of proper nesting of elements. Much less readable and editable in my opinion. This made me consider going back to sequences after all and requiring user to provide some kind of special symbol for empty sequence or end eery sequence with a fixed item so that I will now it is end and not a real item. In my opinion the extra effort would still be less than with the lists while overall "user experience" would be better. (At the expense of complicating my own code - but I'm ready to accept that.) Does anyone of you ever did something like that? Guidelines? Ideas? How do sequence function deal with empty sequences? If I would pass to BOOST_PP_SEQ_ENUM a result of BOOST_PP_SEQ_POP_FRONT on a single-element sequence would it work fine (enumerate nothing)? Or it is not guaranteed?

2 1