http://permalink.gmane.org/gmane.comp.lib.boost.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.boost.user/74188 <pre> I'm not qualified to comment on your specific fix, but I often do see library authors requesting a Trac ticket - especially to attach a proposed patch. That way it doesn't depend on the author to remember a mail message. _______________________________________________ Boost-users mailing list Boost-users&lt; at &gt;lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users</pre> Nat Goodspeed 2012-05-18T02:59:36 http://permalink.gmane.org/gmane.comp.lib.boost.user/74187 <pre>Hi Will, You are correct. It was my fault. It's a non-issue. Thanks again for you advice, Christian </pre> Christian Henning 2012-05-18T00:39:40 http://permalink.gmane.org/gmane.comp.lib.boost.user/74186 <pre> This has already been reported as a bug: https://svn.boost.org/trac/boost/ticket/6638 All the best, Fraser. </pre> Fraser Hutchison 2012-05-17T18:26:13 http://permalink.gmane.org/gmane.comp.lib.boost.user/74185 <pre>Dear list, I have been using boost.iostreams to read gzipped files for some time, but recently have run into some problems with files that are compressed using tools other than gzip (namely bgzip from http://samtools.svn.sourceforge.net/viewvc/samtools/trunk/samtools/). Here is the file: $ hexdump -C ../hello.txt.bgz 00000000 1f 8b 08 04 00 00 00 00 00 ff 06 00 42 43 02 00 |............BC..| 00000010 35 00 f3 48 cd c9 c9 d7 51 28 c9 c8 2c 56 00 a2 |5..H....Q(..,V..| 00000020 44 85 92 d4 e2 12 85 b4 cc 9c 54 3d 2e 00 86 1e |D.........T=....| 00000030 ef a4 1c 00 00 00 1f 8b 08 04 00 00 00 00 00 ff |................| 00000040 06 00 42 43 02 00 1b 00 03 00 00 00 00 00 00 00 |..BC............| 00000050 00 00 |..| 00000052 I think this is valid gzip format (based on reading http://www.gzip.org/zlib/rfc-gzip.html). It differs from what you get by compressing the file using the gzip program in two respects: 1. it uses the 'extra' flag (FLG.EXTRA) to a</pre> Gavin Band 2012-05-17T13:57:24 http://permalink.gmane.org/gmane.comp.lib.boost.user/74184 <pre> No. It should be no problem. Christophe </pre> Christophe Henry 2012-05-17T13:26:16 http://permalink.gmane.org/gmane.comp.lib.boost.user/74183 <pre>Hi Vicente, On Tue, May 15, 2012 at 12:43 PM, Vicente J. Botet Escriba &lt;vicente.botet&lt; at &gt;wanadoo.fr&gt; wrote: Yes, exactly this. No, but you could write your own function to erase them. I understand that is a little bit surprising, but it is exactly the same that will happen if you use and std::set&lt;relation&gt; with a custom Compare functor that compares left keys. In a left based set of relations, the relations are indexed by the left key and the equality is defined ignoring completely the right one. It is not only space optimization, but also performance. When you do not use the default, the internal Boost.MultiIndex ends up having three indexes instead of two. Maybe we should have set the default to unconstrained_set_of_relation. In that case, you will be forced to use the left or right view always. I think that we are a little bit to late in the game for that. If you do not want to pay the extra cost of the third index, while being able to access the relations from above as a set of (left,right) value</pre> Matias Capeletto 2012-05-17T09:06:58 http://permalink.gmane.org/gmane.comp.lib.boost.user/74182 <pre>2012/5/14 Ion Gaztañaga &lt;igaztanaga&lt; at &gt;gmail.com&gt;: You Sir are my hero, now have to figure out how to use it ;) Trying to make it work with btw: http://bitsquid.blogspot.com/2010/09/custom-memory-allocation-in-c.html Cheers, Szymon Gatner </pre> Szymon Gatner 2012-05-17T08:02:52 http://permalink.gmane.org/gmane.comp.lib.boost.user/74181 <pre> Unfortunately, I'm working on iOS in priority. If I can find the time to try with android I'll sure give feedback. Joel Lamotte _______________________________________________ Boost-users mailing list Boost-users&lt; at &gt;lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users</pre> Klaim - Joël Lamotte 2012-05-17T05:13:58 http://permalink.gmane.org/gmane.comp.lib.boost.user/74180 <pre> On Wed, May 16, 2012, at 09:33 PM, Christophe Henry wrote: Thanks Christophe, I'll give it a try. Would you expect any problems if I splice the MSM files from the trunk into a 1.49.0 install? Thanks again, Mark </pre> squiremyrkle< at >fastmail.fm 2012-05-17T04:58:28 http://permalink.gmane.org/gmane.comp.lib.boost.user/74179 <pre>1. I had never tested Boost.Locale on Android    platform, so it likely may not work as-is, but    there should not be big restrictions on that. 2. Boost.Locale does not work on Windows mobile (at least Win CE)    due to lack of basic C functionality like localtime... About Android. Generally Bionic library is very limited so does the standard C++ library can't use the POSIX locale API on this platform, so even if you have standard C++ library it would not likely support locales others than C/POSIX. So this lives "posix" and "std" backends quite useless for anything but "gettext" handing. Now the question is if ICU works on Android. If it does there should be no technical problem. Another thing is that sizeof(wchar_t) == 4 starting from 2.3, so I don't think that Boost.Locale would be even able to compile on older versions. So... If you have android... Why wouldn't you try to compile it and run some tests :-)   Artyom Beilis -------------- CppCMS - C++ Web Framework:   http://cppcms.com</pre> Artyom Beilis 2012-05-17T04:51:37 http://permalink.gmane.org/gmane.comp.lib.boost.user/74178 <pre>Hi, are there limitations in boost.locale that would prevent it's use on mobile platforms? For example: iOS, Android, other mobile platforms that allow native applications Or put in another way: are there known system limitations on some target platforms that prevent the use of all features of Boost.Locale or even forbid it's use? My current understanding is that there is no restriction, but as I am not an expert in this matter I prefer to ask more experienced users. Joel Lamotte _______________________________________________ Boost-users mailing list Boost-users&lt; at &gt;lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users</pre> Klaim - Joël Lamotte 2012-05-17T02:55:50 http://permalink.gmane.org/gmane.comp.lib.boost.user/74177 <pre>Hello! Last update on git[1] - 6 months ago. I do not understand whether boost.lockfree is still developing? After reading this topic[2], I still do not understand whether boost.lockfree be accepted into the boost, and when to expect this? Will boost.lockfree be accepted into boost-1.50? [1] http://tim.klingt.org/git?p=boost_lockfree.git; [2] http://lists.boost.org/Archives/boost/2012/03/191491.php </pre> niXman 2012-05-16T20:34:07 http://permalink.gmane.org/gmane.comp.lib.boost.user/74176 <pre> Hi Mark, you're not doing anything wrong, VC has been giving me a hard time with eUML and submachines. I corrected this in the trunk a while ago but we had no boost version since then, so you'll need to get the current version (the 1.50 will have this change when it comes out). There is a small breaking change (the first since the official release) but the syntax is now actually better and easier, you won't need the helper class. I attach a corrected version of your example, I tested it with VC10 and g++4.5. HTH, Christophe struct context{}; struct entry_state_impl : public msm::front::state&lt;&gt; , public msm::front::euml::euml_state&lt;entry_state_impl&gt; { }; entry_state_impl const entry_state; struct next_state_impl : public msm::front::state&lt;&gt; , public msm::front::euml::euml_state&lt;next_state_impl&gt; { }; next_state_impl const next_state; struct some_event : msm::front::euml::euml_event&lt;some_event&gt;{}; BOOST_MSM_EUML_ACTION(action1) { template &lt;class FSM,class EVT,class SourceState,class TargetStat</pre> Christophe Henry 2012-05-16T19:33:26 http://permalink.gmane.org/gmane.comp.lib.boost.user/74175 <pre>Le 16/05/12 20:17, John M. Dlugosz a écrit : Could you try with trunk? Vicente </pre> Vicente J. Botet Escriba 2012-05-16T18:27:47 http://permalink.gmane.org/gmane.comp.lib.boost.user/74174 <pre> Writing it as two lines, boost::detail::thread_move_t&lt;T&gt; shuttle (x); return shuttle; it's clear that the error is with the return statement. It insists that the copy constructor is callable, even though in reality it is optimized out. That is what the standard says. Perhaps other compilers ignore that fine print. Yet, packaged_task::get_future seems to be able to return just fine. Writing it as: boost::detail::thread_move_t&lt;unique_future&lt;RetType&gt; &gt; shuttle (future_result); return unique_future&lt;RetType&gt;(shuttle); seems to work! Yea! Odd, I had tried the explicit construct around the operator all on one line yesterday, and it didn't help. </pre> John M. Dlugosz 2012-05-16T18:17:01 http://permalink.gmane.org/gmane.comp.lib.boost.user/74173 <pre> Yes, I tried that. I get an error about no viable constructor. I tried the form you show (prefix operator form) and an explicit operator syntax call. </pre> John M. Dlugosz 2012-05-16T17:27:35 http://permalink.gmane.org/gmane.comp.lib.boost.user/74172 <pre>Hello, using a global path variable as in the following sample is no longer possible when using 1.49 under Windows: #include &lt;iostream&gt; #include &lt;boost/filesystem.hpp&gt; boost::filesystem::path global_path("."); int main() { std::cout &lt;&lt; global_path &lt;&lt; std::endl; return 0; } The program crashes while starting. The following backtrace was captured: The program was built using boost 1.49 under Windows 7 and MSVC 10. The same sample works as expected using Boost 1.48 while keeping the rest untouched. Thanks for clarification, Jan. </pre> Jan Boehme 2012-05-16T14:56:50 http://permalink.gmane.org/gmane.comp.lib.boost.user/74171 <pre> implementing shared_ptr instead of iterator during boost::asio::async_write() call fixed the issue. I don't see segmentation fault anymore. Thanks a lot, mustafa -- View this message in context: http://boost.2283326.n4.nabble.com/segmentation-fault-using-boost-asio-in-linux-tp4630119p4630161.html Sent from the Boost - Users mailing list archive at Nabble.com. </pre> mozdemir 2012-05-16T14:01:59 http://permalink.gmane.org/gmane.comp.lib.boost.user/74170 <pre> Olaf Peter wrote I understand that it's not possible to += all types of accumulated statistics, but I will find it extremely useful to be able to do it for a lot of stats that support this (count, sum, moment, covariance, more...). Is there any way of using the accumulator_set interface to achieve the equivalent of acc1 += acc2 ? -- View this message in context: http://boost.2283326.n4.nabble.com/accumulator-operations-tp3637631p4630153.html Sent from the Boost - Users mailing list archive at Nabble.com. </pre> killogre 2012-05-16T06:04:00 http://permalink.gmane.org/gmane.comp.lib.boost.user/74169 <pre>Le 16/05/12 06:13, John M. Dlugosz a écrit : Hi, Boost.Thread move semantic emulation up to 1.49 has many problems. I have reworked the move semantic interfaces adapting them to Boost.Move in trunk (I hope it will be released for 1.50). If you can not use the trunk, have you tried with boost::unique_future&lt;T&gt; f() { /// x return boost::detail::thread_move_t&lt;T&gt;(x); } Best, Vicente </pre> Vicente J. Botet Escriba 2012-05-16T08:45:25 http://permalink.gmane.org/gmane.comp.lib.boost.user/74168 <pre>I'm using Clang on the Mac without the C++11 dialect enabled in this project. With BOOST_NO_RVALUE_REFERENCES defined, in Boost 1.49, how can I write a function returning an object of type unique_future&lt;T&gt; ? I tried changing std::move to boost::move which I expected to work. I tried fiddling with thread_move_t explicitly. I can't get anything to work. What's the magic formula? </pre> John M. Dlugosz 2012-05-16T04:13:31 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.boost.user