http://permalink.gmane.org/gmane.comp.lib.boost.devel 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.devel/230973 <pre> some people have them highlighted to ensure that the editor does not mix tabs/spaces ... _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Tim Blechmann 2012-05-18T09:46:50 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230972 <pre> They clutter the code when spaces are visible. And it's simply untidy. _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Andrey Semashev 2012-05-18T07:44:07 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230971 <pre>On Fri, May 18, 2012 at 9:30 AM, Andrey Semashev &lt;andrey.semashev&lt; at &gt;gmail.com&gt; wrote: No How do they (trailing whitespace) affect reading? </pre> Olaf van der Spek 2012-05-18T07:33:35 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230970 <pre> Are you implying that cleaning the code will make it worse? Personally, I doubt there's a measurable impact on performance of this change, but it improves code clarity. Those extra spaces irritate a little when I read or edit code, so I'm all for it. _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Andrey Semashev 2012-05-18T07:30:02 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230969 <pre>Thanks a lot. I think git can be used above svn, I will try because I really hate bother others with minor commits and unfinished work. Frédéric _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Frédéric Bron 2012-05-18T07:27:28 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230968 <pre> That's an explanation for the easy part, but why is this an improvement? Olaf </pre> Olaf van der Spek 2012-05-18T07:19:41 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230967 <pre> This might help: https://svn.boost.org/trac/boost/wiki/BoostSubversion (linked from svn.boost.org) - Jeff _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Jeffrey Lee Hellrung, Jr. 2012-05-18T07:09:21 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230966 <pre> There's several inofficial Git repositories, some true to the SVN but lagged, some from assorted modularisation efforts. The only way to actually check in code and talk about revision numbers is the SVN repository. Trunk lives at http://svn.boost.org/svn/boost/trunk </pre> Lars Viklund 2012-05-18T07:00:13 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230965 <pre>Olaf van der Spek &lt;ml&lt; at &gt;vdspek.org&gt; On Thu, May 17, 2012 at 1:12 AM, Brian Wood &lt;woodbrian77&lt; at &gt;gmail.com&gt; wrote: It can be done with a simple sed script and applied either to individual libraries or all of Boost. It's a small detail, but I hope it gets some attention. I brought it to Ion's attention as I use the Intrusive library and take a number of steps to reduce the need for new hardware. I won't stop using the library if he doesn't do this, but the squeaky wheel gets the oil. Cheers, Brian Ebenezer Enterprises http://webEbenezer.net &lt;http://webebenezer.net/&gt; _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Brian Wood 2012-05-18T06:58:48 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230964 <pre>I would like to work on a fix for the operator traits applied to STL containers but I have changed my computer and do not remember what is the official repository. Is there an official git repository that can be used? or have we to use the svn repository? What is the address to clone (git) or checkout (svn)? Regards, Frédéric _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Frédéric Bron 2012-05-18T05:50:58 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230963 <pre>BUMP On Tue, May 15, 2012 at 12:05 PM, Robert Dailey &lt;rcdailey.lists&lt; at &gt;gmail.com&gt;wrote: _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Robert Dailey 2012-05-17T20:58:28 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230962 <pre> On 16.05.2012, at 20:08, Klaim - Joël Lamotte wrote: The architecture of PTree means that stateful allocators are impossible (or at least extremely inefficient). So those are not going to appear. Stateless allocators are an option, but there is no concrete plan to add them. Sebastian _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Sebastian Redl 2012-05-17T02:46:29 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230961 <pre>It is inconvenient that no notification email is sent when adding an attachment to a ticket. Alas, it's a limitation of trac for a long time. http://trac.edgewall.org/ticket/2259 Is there any plugin to automatically send notification email when attaching a file to a ticket? If not, probably we should change the message (which is displayed when we attach a file to a ticket) to explicitly say "No notification email will be sent by attaching a file. To automatically send a notification email, please leave some comment in the ticket!" Regards, Michel _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Michel Morin 2012-05-17T15:37:53 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230960 <pre> Third, I want to use boost::any in a value-semantic type. Sometime it would It currently forbids you because Copyable is a requirement on the value type, and is enforced in boost::any::holder&lt;ValueType&gt;::clone. If you want to hold a move only type, you'll have to have a version of detect it and throw an exception when copying is attempted. </pre> Nevin Liber 2012-05-17T15:26:11 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230959 <pre> Done. [Add tr1_result_of specialization and avoid specialization of decltype-based result_of] * Functional/Forward https://svn.boost.org/trac/boost/ticket/6909 * Fusion https://svn.boost.org/trac/boost/ticket/6910 * Phoenix V3 https://svn.boost.org/trac/boost/ticket/6911 * Phoenix V2 https://svn.boost.org/trac/boost/ticket/6912 [Avoid specialization of decltype-based result_of] * Proto https://svn.boost.org/trac/boost/ticket/6913 [Feature request: Add result_of and tr1_result_of specializations for nullary function calls] * Lambda https://svn.boost.org/trac/boost/ticket/6914 Regards, Michel _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Michel Morin 2012-05-17T15:13:34 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230958 <pre>Hi, My current understanding of the new rules of 5 tells me that boost::any isn't "move aware". First, am I correct? Second, I think that adding the move constructor and move operator is trivial. Again, am I correct or is there some tricks to know before adding them? Third, I want to use boost::any in a value-semantic type. Sometime it would keep a unique_ptr. If I understand correctly move semantic and unique_ptr implementation, the current boost::any implementation don't forbid me to use unique_ptr as a value type. Am I correct? Joel Lamotte _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Klaim - Joël Lamotte 2012-05-17T08:33:26 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230957 <pre> Really? Why? Olaf _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Olaf van der Spek 2012-05-17T06:30:24 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230956 <pre> Agree. At least for headers. Based on some experience, I think the really annoying thing is to have your editor or IDE during debugging or from log files or build output, take you to the trouble spot in your code. You see the problem, but do not realize you are in the *wrong* place. So you fix it - you think. So what happens then. If you are lucky, the build fails on next compile as it realizes the content of the derived file, the copy, has changed. But most build tools may not, as the the derived file has been edited. So it is more likely you discover a lot of your changes are overwritten next time you do a rebuild all or make clean. Making the copies read-only may help a bit and remind the anyyed earlier of the issue, but I think forwarding headers is better. If the indirection annoys you in other ways, use a more appropriate file system. I am curious why you consider installing headers for build part of a monolitic arrangement. </pre> Bjørn Roald 2012-05-17T05:41:02 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230955 <pre>Hi, Is there any plan to add custom allocators to boost.property_tree ? Joel Lamotte _______________________________________________ Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </pre> Klaim - Joël Lamotte 2012-05-17T02:08:45 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230954 <pre> The idea looks sound. I am applying the patch now. I took the liberty to rename as_readonly to as_const. What's lacking are tests. Could you please also provide some? Thanks a lot! Regards, </pre> Joel de Guzman 2012-05-17T01:03:51 http://permalink.gmane.org/gmane.comp.lib.boost.devel/230953 <pre>&lt;snip&gt; Yes. Can you file bug reports? Probably. More bug reports, please! :-) </pre> Eric Niebler 2012-05-17T00:45:59 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.boost.devel