<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lib.boost.devel">
    <title>gmane.comp.lib.boost.devel</title>
    <link>http://blog.gmane.org/gmane.comp.lib.boost.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242403"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242402"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242395"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242394"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242371"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242370"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242335"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242333"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242320"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242307"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242295"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242287"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242280"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242274"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242269"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242267"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242266"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242255"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242254"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lib.boost.devel/242230"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242403">
    <title>Weirdness in SVN</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242403</link>
    <description>&lt;pre&gt;Ok, this is quite worrisome to me.

This morning, bug #6136 was reopened:
https://svn.boost.org/trac/boost/ticket/6136

This is an "unused variable warning" in Boost.DateTime. 
I fixed this bug in the trunk: https://svn.boost.org/trac/boost/changeset/80699
I merged this bug fix (and several others) to the release branch: https://svn.boost.org/trac/boost/changeset/80797

But the files (both trunk and release) appear not to contain the change.
If I do a "svn diff", the changes appear in the diff, but the file doesn't contain the change.

I checked the other files referenced in change set 80797, and they appear to be fine - just this one.

Any idea what could be happening here? 
My only explanation at the moment is that "Subversion is lying to me", and that's both (a) a huge potential problem, and (b) doesn't suggest a course of action.


$ svn diff trunk/boost/date_time/format_date_parser.hpp -r 80698
Index: trunk/boost/date_time/format_date_parser.hpp
=========================================================&lt;/pre&gt;</description>
    <dc:creator>Marshall Clow</dc:creator>
    <dc:date>2013-06-19T13:50:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242402">
    <title>[mailing list] Duplicated thread - Best way to proceed</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242402</link>
    <description>&lt;pre&gt;The thread:  [boost] [range] Best way to count the elements in a filtered
range?

I sent an email with an unregistered email adress to the list. As expected,
I did not receive a confirmation about the mail being accepted.

I resent the mail with my registered email adress. As expected, the new
mail was accepted.

However, the unaccepted mail started getting replies.

- What is the best way to proceed?
- Why did the email sent with the unregistered email address get replies?
- Shouldn't it have been rejected right away?

Bests,
Gonzalo BG

_______________________________________________
Unsubscribe &amp;amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

&lt;/pre&gt;</description>
    <dc:creator>Gonzalo Brito Gadeschi</dc:creator>
    <dc:date>2013-06-19T12:20:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242395">
    <title>[range] Best way to count the elements in a filtered range?</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242395</link>
    <description>&lt;pre&gt;I wonder what is the recommended way to count the elements in a filtered
range.

Let range be a random access range, and filter the result of
filtered(predicate),

auto filtered_range = range | filter;
count_if( filtered_range, [](const&amp;amp;){ return true; }); // (&amp;amp; omitted in
lambda)

counts the elements in a filtered range.

_If_ this is the best way to count the elements in a filtered range, what
about defining

Range boost::count(Range&amp;amp;&amp;amp; r);

to count all element in the range? It could call size() if available and
count_if otherwise.

Bests,
Gonzalo BG

_______________________________________________
Unsubscribe &amp;amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

&lt;/pre&gt;</description>
    <dc:creator>Gonzalo BG</dc:creator>
    <dc:date>2013-06-19T10:41:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242394">
    <title>[range] Best way to count the elements in a filtered range?</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242394</link>
    <description>&lt;pre&gt;I wonder what is the recommended way to count the elements in a filtered
range.

Let range be a random access range, and filter the result of
filtered(predicate),

auto filtered_range = range | filter;
count_if( filtered_range, [](const&amp;amp;){ return true; }); // (&amp;amp; omitted in
lambda)

counts the elements in a filtered range.

_If_ this is the best way to count the elements in a filtered range, what
about defining

Range boost::count(Range&amp;amp;&amp;amp; r);

to count all element in the range? It could call size() if available and
count_if otherwise.

Bests,
Gonzalo BG

_______________________________________________
Unsubscribe &amp;amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

&lt;/pre&gt;</description>
    <dc:creator>Gonzalo Brito Gadeschi</dc:creator>
    <dc:date>2013-06-19T10:39:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242371">
    <title>concurrent garbage collector</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242371</link>
    <description>&lt;pre&gt;Hey Boost,

  After struggling with breaking shared_ptr cycles in my app, I wrote a little concurrent garbage collector which uses boost::lockfree::queue. Its actually fairly general purpose, and I've released the code here:

https://gist.github.com/wtholliday/5793270

Inspired by my question on stack overflow:

http://stackoverflow.com/questions/17116189/concurrent-garbage-collection-for-a-c-graph-data-structure

I'm also working on releasing my unit test... its just quite dependent on other code.

For the interface: the basic idea is you have a RootPtr&amp;lt;T&amp;gt; used to manage the collector's root set (please forgive my propensity for CamelCase). You have to explicitly manage references between collectable objects (via AddEdge and RemoveEdge functions), but I think that could be made safe using another smart pointer type which knows the collectable object which owns it. At this point I'm not too concerned about performance, as my object graphs aren't that big. I bet a GC guru could implement this without using a &lt;/pre&gt;</description>
    <dc:creator>Taylor Holliday</dc:creator>
    <dc:date>2013-06-17T20:41:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242370">
    <title>Is anybody working on the Boost Windows installer?</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242370</link>
    <description>&lt;pre&gt;Hi,

Good morning.

I am new to Boost and this mailing list.

When I visited BoostPro computing in order to download the Windows installer, I did not see any installer beyond version 1.51.

Since BoostPro donated the installer source code to the community, I am checking to see if anybody is updating the installer for the newer Boost versions.

In case nobody is working on this, then I thought I would try to do it. :-)

Thanks,
Antony

_______________________________________________
Unsubscribe &amp;amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

&lt;/pre&gt;</description>
    <dc:creator>Antony Maria Sakkariaz</dc:creator>
    <dc:date>2013-06-17T14:45:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242335">
    <title>How do I specify no padding bytes within a struct/class?</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242335</link>
    <description>&lt;pre&gt;I've never done this before, so I'm asking first: how do I specify that a
struct/class should have no padding at all, at the start, end, or middle?
My classes have internal arrays, and specifying no padding lets users use an
array of classX&amp;lt;T&amp;gt; as an array of T (just like C++11 std::complex).
Complier-specific answers are OK, as long as I can use preprocessor flags to
isolate them.

I have a preprocessor flag that's currently set to 0 to indicate that
there's no packing.  I'll change it to 1 whenever I get a compiler's packing
support.

Daryle W.


_______________________________________________
Unsubscribe &amp;amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

&lt;/pre&gt;</description>
    <dc:creator>Daryle Walker</dc:creator>
    <dc:date>2013-06-17T16:41:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242333">
    <title>[New][Multiprecision] Getting errors while writinghypercomplex classes.</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242333</link>
    <description>&lt;pre&gt;I've banged out (yet another) complex number class at
&amp;lt;https://github.com/CTMacUser/Complex&amp;gt;.  The current commit has an SHA of
"b866cda91ccdb4aa87c199c6d9e7c776fee61bcc."  Right now, I'm writing this
code on a 32-bit Windows 8 system using Code::Blocks with a packaged MinGW
GCC 4.7 by TDM.  In many of the incremental changes, I ran into internal
compiler errors.  I don't know if my code is too unusual or it's the
compiler.  I'm asking if you guys can check out the code with other
compilers (GCC 4.7 besides MinGW/TDM, GCC 4.8, Clang 3.x, non-Windows, etc.)
so we can figure out what bug goes where.

There are two class templates:
- boost::math::complex_it&amp;lt;Number, Rank&amp;gt;
- boost::math::complex_rt&amp;lt;Number, Rank&amp;gt;

"Number" is a Regular type that supports math operations plus Boolean
conversions.  "Rank" is the Cayley-Dickson hypercomplex level.  Use 0 as a
shell for real numbers, 1 for regular complex numbers, 2 for quaternions, 3
for octonions, etc.  The "complex_it" class template stores all the
components direc&lt;/pre&gt;</description>
    <dc:creator>Daryle Walker</dc:creator>
    <dc:date>2013-06-17T16:32:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242320">
    <title>[phoenix] Using Phoenix lambdas on top of custom Protoexpressions</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242320</link>
    <description>&lt;pre&gt;Hello,

I am working on VexCL (https://github.com/ddemidov/vexcl) - a vector
expression template library for OpenCL. I have recently added support for
automatic generation of OpenCL kernels from generic functors (description
of the feature: https://github.com/ddemidov/vexcl#function-generator).

In order to implement this, I pass the instances of vex::symbolic&amp;lt;T&amp;gt; class
to the given functor. vex::symbolic&amp;lt;T&amp;gt; dumps to output stream any
arithmetic operations it is being subjected to, and that's how I am able to
construct the OpenCL kernel source. The symbolic&amp;lt;T&amp;gt; class is of course a
Boost.Proto terminal.

Now, it seems natural to use Boost.Phoenix to provide the generic functors
for the function generator. And indeed it is possible with simple
expressions (see
https://github.com/ddemidov/vexcl/blob/a95dfdd68/tests/generator.cpp#L124).
However, if I try to bring cmath functions overloads from
&amp;lt;boost/phoenix/stl/cmath.hpp&amp;gt; and use those (
https://github.com/ddemidov/vexcl/commit/b95da14e51), I get compilation
err&lt;/pre&gt;</description>
    <dc:creator>Denis Demidov</dc:creator>
    <dc:date>2013-06-17T05:33:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242307">
    <title>[test] resolution of test time information</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242307</link>
    <description>&lt;pre&gt;Hi

I'm new to the boost test library and it seems to fill my needs of a
testing framework quite well.

One thing that i haven't managed to figure out is if it's possible to
increase the resolution of the timekeeping information, it currently seems
to be reported with a resolution of 10 milliseconds.

Is it possible to reduce that somehow?

best regards
Alexander Kjäll

_______________________________________________
Unsubscribe &amp;amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

&lt;/pre&gt;</description>
    <dc:creator>Alexander Kjäll</dc:creator>
    <dc:date>2013-06-16T06:59:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242295">
    <title>[1.54] [thread] MSVC build broken</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242295</link>
    <description>&lt;pre&gt;Hi,

I've noticed that my Boost.Log tests on MSVC are failing massively. The build 
log hints that Boost.Thread might be the culprit, and its tests are also 
failing on MSVC with the following error:

..\boost/thread/future.hpp(1127) : error C2248: 
'boost::unique_lock&amp;lt;Mutex&amp;gt;::operator =' : cannot access private member 
declared in class 'boost::unique_lock&amp;lt;Mutex&amp;gt;'
        with
        [
            Mutex=boost::mutex
        ]
        ..\boost/thread/lock_types.hpp(110) : see declaration of 
'boost::unique_lock&amp;lt;Mutex&amp;gt;::operator ='
        with
        [
            Mutex=boost::mutex
        ]

This is happening on release branch. Could this be fixed?


_______________________________________________
Unsubscribe &amp;amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

&lt;/pre&gt;</description>
    <dc:creator>Andrey Semashev</dc:creator>
    <dc:date>2013-06-15T10:23:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242287">
    <title>[optional][thread] Returning a future in an optional fails</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242287</link>
    <description>&lt;pre&gt;I just hit this using VS2012/boost 1.54 beta.

    #include &amp;lt;boost/optional.hpp&amp;gt;
    #include &amp;lt;future&amp;gt;

    boost::optional&amp;lt; std::future&amp;lt;void&amp;gt; &amp;gt; top() { return std::async( []{ int
i=0; ++i;  } ); }

    int main()
   {
      auto opt = top();
    }

Error:

1&amp;gt;E:\Projects\SDK\boost\boost\include\boost-1_54\boost/optional/optional.hpp(347):
error C2248: 'std::future&amp;lt;void&amp;gt;::future' : cannot access private member
declared in class 'std::future&amp;lt;void&amp;gt;'
1&amp;gt;          C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\include\future(1238) : see declaration of
'std::future&amp;lt;void&amp;gt;::future'
1&amp;gt;          C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\include\future(1200) : see declaration of 'std::future&amp;lt;void&amp;gt;'
1&amp;gt;
 E:\Projects\SDK\boost\boost\include\boost-1_54\boost/optional/optional.hpp(346)
: while compiling class template member function 'void
boost::optional_detail::optional_base&amp;lt;T&amp;gt;::construct(const std::future&amp;lt;void&amp;gt;
&amp;amp;)'
1&amp;gt;          with
1&amp;gt;          [
1&amp;gt;              T=std::future&amp;lt;void&amp;gt;
1&amp;gt;          ]
1&amp;gt;
 E:&lt;/pre&gt;</description>
    <dc:creator>Klaim - Joël Lamotte</dc:creator>
    <dc:date>2013-06-14T19:24:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242280">
    <title>link to old TR1 draft on boost.org</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242280</link>
    <description>&lt;pre&gt;The Boost home page links to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf but
that draft was replaced by N1836.

_______________________________________________
Unsubscribe &amp;amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

&lt;/pre&gt;</description>
    <dc:creator>Jonathan Wakely</dc:creator>
    <dc:date>2013-06-14T18:06:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242274">
    <title>Proposal for a thread "collision" detector</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242274</link>
    <description>&lt;pre&gt;I would like to know if Boost community could be interested in
adopting a check mechanism that is able to detect if a not supposed
thread safe class is used by multiple threads in unsafe way. This
tecnique has saved us a lot of headache especially when code refactoring
on old code is performed.

Better to explain it, without enter in the detail of the implementation,
with some examples:


Example: Queue implementation non thread-safe but still usable if clients
         are synchronized somehow.


  class NonThreadSafeQueue {
   public:
    ...
    void push(int) { DFAKE_SCOPED_LOCK(push_pop_); ... }
    int pop() { DFAKE_SCOPED_LOCK(push_pop_); ... }
    ...
   private:
    DFAKE_MUTEX(push_pop_);
  };


 Example: Queue implementation not usable even if clients are synchronized,
          so only one thread in the class life cycle can use the two members
          push/pop.

          In this case the macro DFAKE_SCOPED_LOCK_THREAD_LOCKED pins the
          specified critical section the first time a thread&lt;/pre&gt;</description>
    <dc:creator>Gaetano Mendola</dc:creator>
    <dc:date>2013-06-14T10:43:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242269">
    <title>[c++11]</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242269</link>
    <description>&lt;pre&gt;This was probably discussed many times already, but I seem to not have been paying close enough attention.

Maybe someone can point me to the discussions in the archives...

With all of the cool new language features of C++11, am I correct in assuming that boost library developers have no real opportunity to use any of it in order to be backwards compliant with all the older standard?

I realize there are many boost equivalents already in place, but when would it become permissible to use native C++11 syntax?

Thanks,
-Sid


_______________________________________________
Unsubscribe &amp;amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

&lt;/pre&gt;</description>
    <dc:creator>Sid Sacek</dc:creator>
    <dc:date>2013-06-14T09:35:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242267">
    <title>Future of Boost.Signals</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242267</link>
    <description>&lt;pre&gt;Doug Gregor has indicated to me that he is not able to continue with the development/maintenance of Boost.Signals.
[ This is not a surprise, the last significant change to the library was back in 2004. ]

Fortunately, Frank Hess' Signals2 library is going strong, and he has a porting guide for people currently using Boost.Signals at: http://www.boost.org/doc/html/signals2/api_changes.html#signals2.porting

For the upcoming 1.54 release, I have added notes to this effect to the Boost.Signals documentation, and added a warning to &amp;lt;boost/signals.hpp&amp;gt;. 

The warning states:
Boost.Signals is no longer being maintained and is now deprecated. Please switch to Boost.Signals2. 
To disable this warning message, define BOOST_SIGNALS_NO_DEPRECATION_WARNING

Note: There have been no code changes to Boost.Signals. All code that uses it will continue to work.

&lt;/pre&gt;</description>
    <dc:creator>Marshall Clow</dc:creator>
    <dc:date>2013-06-13T17:45:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242266">
    <title>Tips to fix boost::asio::windows::random_access_handle which is seriously broken</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242266</link>
    <description>&lt;pre&gt;Dear Boost,

The forthcoming GSoC Boost.AFIO library has found a problem with
boost::asio::windows::random_access_handle in that it appears to clamp
buffer sizes to 64Kb and not increment overlapped offsets during
multi-buffer reads and writes, and which is reported at
https://svn.boost.org/trac/boost/ticket/8669. These are desirable features
for network i/o, not so for file i/o.

As my work on the existing code base which Paul is porting to Boost is now
complete and purring beautifully on POSIX, I'm thinking I might as well go
fix the Boost.ASIO Windows IOCP problem. Before I begin, can I ask here if
anyone else has done some work on this topic from which I might be able to
borrow? The thread at
http://comments.gmane.org/gmane.comp.lib.boost.asio.user/3676 suggests that
if I use async_write_some() then I can bypass the 64Kb clamp using "my own
completion condition". I'm thinking that
boost::asio::windows::random_access_handle really ought to actually
implement random access, so rather than hacking around th&lt;/pre&gt;</description>
    <dc:creator>Niall Douglas</dc:creator>
    <dc:date>2013-06-13T15:22:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242255">
    <title>[thread] Use of synchronized_value&lt;&gt; member in a constructor</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242255</link>
    <description>&lt;pre&gt;I am using now Boost 1.54.0 Beta (r84749).

I am writting code similar to the following (but a bit more complex) :

struct SequenceInfo
{
SequenceId id;
ProjectId project_id;
std::string name;
        //....
};

class Sequence
{
    boost::synchronized_value&amp;lt;SequenceInfo&amp;gt; m_info;

public:

    explicit Sequence( SequenceId new_id, SequenceInfo info )
          : m_info( std::move(info) )
    {
          m_info-&amp;gt;id( new_id ); // mutex lock
    }
// ...
};

My current understanding of concurrent access practice is that
it is not necessary to use synchronization mechanisms associated to member
objects
manipulated into a constructor, because it can happen on only one thread.

If I am correct, then the lock of the synchronized_value is unnecessary.
I suspect that there might be other cases like this one where
the object responsable for the synchronized object should be able, rarely,
to access the object unsafely.

Suggestion: add an unsafe access to the object, in a very visible way.

    m_info.unsafe_access().i&lt;/pre&gt;</description>
    <dc:creator>Klaim - Joël Lamotte</dc:creator>
    <dc:date>2013-06-12T19:29:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242254">
    <title>[Multiprecision] High-performance radix-2 floating-pointback-end</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242254</link>
    <description>&lt;pre&gt;Hi

This is my first post on the mailing list , so apologies if it doesn't
follow any of the protocols.

I was looking at  GSoC projects this year for Boost and I am wondering if
someone is working on a high-performance radix-2 floating-point back-end
for Boost.Multiprecision. If not , I would be interested in doing this
project .I am currently a Masters student interning at a tech company in
Seattle but I would be able to devote 15-20 hours a week for this project.
I have a fairly good background in C++ and numerical programming.So in case
no else is working on it (for GSoC or otherwise ) , I would be really
interested . If someone is already working on it, I would be interested in
some other projects I could potentially work on .

Looking forward to a reply.

Regards
&lt;/pre&gt;</description>
    <dc:creator>Aditya Jain</dc:creator>
    <dc:date>2013-06-11T21:51:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242230">
    <title>[type_erasure] Compilation time</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242230</link>
    <description>&lt;pre&gt;Hello Steven,

Is there anyway to not include some definitions in header to delay
instantiation for use with explicit template instantiations in specific
translation units with type_erasure?

I have a CORBA library which uses type_erasure for each interface defined
in IDL. The problem is that if I include too many #include's for the
precompiled headers which use type_erasure, then the compiler ends up
consuming too much memory (&amp;gt;10GB), which makes it unfit for 32bit compilers
which can use at most 3GB.

Regards,
&lt;/pre&gt;</description>
    <dc:creator>Felipe Magno de Almeida</dc:creator>
    <dc:date>2013-06-09T20:50:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lib.boost.devel/242209">
    <title>[multiprecision] Are these types suitable as numeric types for unit tests?</title>
    <link>http://comments.gmane.org/gmane.comp.lib.boost.devel/242209</link>
    <description>&lt;pre&gt;I'm writing new numeric types, and my unit tests use MPL lists of numeric types.  I usually use stuff like int, unsigned, and double, but now I'm adding cpp_int and cpp_dec_float_50.  Those types were OK when I was just doing type equalities and sizeof checks.  Now I'm doing tests that use objects of those types and I'm getting problems.

//====
typedef boost::mpl::list&amp;lt;int, unsigned, cpp_int&amp;gt;     test_integer_types;
typedef boost::mpl::list&amp;lt;double, cpp_dec_float_50&amp;gt;  test_floating_types;

//...

BOOST_AUTO_TEST_CASE_TEMPLATE( test_complex_component_access1, T,
 test_integer_types )
{
    typedef complex_it&amp;lt;T, 0&amp;gt;                  real_type;
    typedef complex_it&amp;lt;T, 1&amp;gt;               complex_type;

    real_type               a;
    real_type const &amp;amp;       aa = a;
    complex_type            b;
    complex_type const &amp;amp;    bb = b;

    a[ 0 ] = 6;
    BOOST_CHECK_EQUAL( a[0], T(6) );
    BOOST_CHECK_EQUAL( T(6), aa[0] );

    b[ 0 ] = 5;
    b[ 1 ] = 7;
    BOOST_CHECK_EQUAL( b[0], T(5) );
    BOOST_CHECK_EQUA&lt;/pre&gt;</description>
    <dc:creator>Daryle Walker</dc:creator>
    <dc:date>2013-06-08T06:57:47</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lib.boost.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lib.boost.devel</link>
  </textinput>
</rdf:RDF>
