headers
vicente.botet | 6 Sep 06:41

[exception] Incompatibility between boost::throw exception and throw prototype declarations

Hi,

As boost::throw_exception can now throw un unspecified exception throgh the 
use of enable_current_exception, do it is no more possible to use throw 
declaration in the prototype of any function calling functions that directly 
or indirectly calls throw_exception. See enable_current_exception 
declaration in the documentation.

namespace
boost
    {
    template <class T>
    ---unspecified--- enable_current_exception( T const & e );
    }

Does it means that we have a interface change of the boost::throw 
function since it was implemented by the Boost.Exception library on 1.36.0?

Best,

Vicente 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |
headers
Emil Dotchevski | 6 Sep 03:21

possible bug introduced in boost function

I have strong suspicions that the changes in boost::function made
today introduce a serious bug in the lifetime management of the
contained object. I don't have a simple test case to demonstrate it,
but a rather complicated use of boost::function which contains
shared_ptr in a boost::bind results in incorrect refcount which leads
to a crash.

Reverting to revision 48607 makes the shared_ptr refcount correct.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Jerry Napoli | 5 Sep 19:40

ARM thumb support in spinlock_gcc_arm.hpp

Hi,

I'm trying to compile using boost 1_36_0 for ARMv6 Thumb for iPhone 
development.  The compiler used is gcc 4.0.x supplied with the iphone sdk.

I run into issues with the inline assembly inside 
boost/detail/spinlock_gcc_arm.hpp.  It generates a SWP instruction which 
(AFAIK) is not supported in thumb mode.  The gnu arm assembler gives me 
a 'bad instruction ...' error.  I'm able to work around it by modifying 
spinlock.hpp to include spinlock_sp.hpp instead.  But has anyone 
addressed spinlock support for armv6 thumb?

Thanks,
Jerry

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 8 comments |
headers
frederic.bron | 5 Sep 17:28

binary operator raits


I have just commited new traits in the sandbox (sandbox/type_traits) to know if a type is comparable or not.
I have included tests but could not make bjam and quickbook run together so I have no
documentation to commit.
The names of the traits are based on standard header <functional>: is_less_comparable<T>,
is_less_equal_comparable<T>, is_greater_comparable<T>, is_greater_equal_comparable<T>, is_
equal_to_comparable<T> and is_not_equal_to_comparable<T>.

Some comments about these traits:
- I was not able to remove the warnings,
- the traits inherits from true_type is the operator exists, however, I am not sure if we should return true
if the binary operator does not return a type convertible to bool

F. Bron

Avis :
Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou
à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le
détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous
n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes
en tout ou en partie.

Notice:
This message and any attachments are the property of Alcan and are intended solely for the named recipients
or entity to whom this message is addressed. If you have received this message in error
please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are
not allowed to use, copy or disclose the contents or attachments in whole or in part.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Vuille | 5 Sep 16:32

[review] FSM Library review result

This is a brief report of the results of the review of
Andrey Semashev's Finite State Machines (FSM) library.
I want to do justice to the discussions that took place,
and will follow-up with a complete summary next week.

In spite of a good amount of discussion and an extension
of the review period, the number of reviews was smaller
than I had hoped for. Nonetheless, I believe that the library
received an adequate review and, based on the review comments
and other discussions, the FSM library cannot be accepted
into Boost at this time.

A total of four reviews were submitted, as follows:

   Andrea Carbone: YES
   Phil Endecott: NO
   Jeff Flinn: NO
   Chris Knight: NO

Darryl Green also submitted a mini-review, which did not
include an explicit yes or no vote, but expressed doubt
about whether the library should be accepted.

On the positive side, several people noted that the goals
of the library (simplicity and greater performance than
Boost.StateCharts) were valid and that such a library was
needed in some applications. I personally support this view.

I would like to thank Andrey for his efforts in developing
the library. I would like to encourage him to pursue the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berserker | 5 Sep 16:11

Asio and SSL problem

I tried to post this problem in the asio mailing list but I hadn't any feedback, so I'm reporting it here with
the hope that someone can help me.

I have a "stack overflow" problem with the following code (using boost 1.36):

void test_handshake(const std::string &host, const std::string &cert)
{
   boost::asio::io_service service;

   boost::asio::ssl::context sslContext(service, boost::asio::ssl::context::sslv23);
   sslContext.set_verify_mode(boost::asio::ssl::context::verify_peer);
   sslContext.load_verify_file(cert);

   boost::asio::ip::tcp::resolver resolver(service);

boost::asio::ip::tcp::resolver::iterator endpoint_iterator =
resolver.resolve(boost::asio::ip::tcp::resolver::query(host, "443"));
   boost::asio::ip::tcp::resolver::iterator end;

   boost::asio::ssl::stream<boost::asio::ip::tcp::socket> sslSocket(service, sslContext);    

   boost::system::error_code error = boost::asio::error::host_not_found;
   while(error && endpoint_iterator != end)
   {
      sslSocket.next_layer().close();
      sslSocket.next_layer().connect(*endpoint_iterator++, error);
   }

   if(error)
      throw boost::system::system_error(error);
(Continue reading)

Permalink | Reply | 3 comments |
headers
Chris De Vries | 5 Sep 05:05

Mentoring students

Hi,

My name is Chris De Vries and I am involved with the IEEE student branch at
the Queensland University of Technology in Brisbane, Australia [1]. I am
organizing a program that encourages students to become involved with open
source. I am looking for projects that are interested in taking on students.
The branch will be running an information session and I am hoping to list
some projects that are willing to mentor students. Is Boost interested?

Thanks,
Chris De Vries

[1] http://ewh.ieee.org/sb/queensland/qut/
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
vicente.botet | 5 Sep 06:43

[thread_pool] Dependencies between tasks

Hi,

the tread_pool pattern is very useful to improve parallelism. But sometimes we need to constraint this
parallelism, for example
when several task are related to the same 'instance' it could be safer to sequence them.

Is there a mechanism that allows to do thinks like that on the thread_pool library?

Best,

Vicente
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 4 comments |
headers
David Abrahams | 5 Sep 03:48

[testing] How not to mark up explicit failures


https://svn.boost.org/trac/boost/ticket/2258 describes a problem with
explicit failure markup that I suspect is not atypical.  I believe we
need to establish some ground rules for markup that ensure 

 * Boost problems don't pass unnoticed

 * there is a uniform standard for interpreting test results across
   libraries

 * "non-Boost problems" and non-problems don't add alarm bells for
   people reading test results

You can view the markup in question here:
https://svn.boost.org/trac/boost/browser/trunk/status/explicit-failures-markup.xml#L1581

Aside from the specifics in the ticket, the following problems jump out
at me just from looking at that XML:

 * even on compilers that do support nonstandard calling conventions,
   failures in these tests will never be flagged as problematic

 * even on compilers that don't support nonstandard calling conventions,
   these tests will fail and add useless noise to the chart.

I can think of a few general principles and practices that will prevent
such problems:

 * Boost regression tests should test the functionality of code that is
   expected to work, not to test the capabilities of the platform or C++
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Abrahams | 4 Sep 22:37

[1.35.x] Any critical bugfixes?


Hi all,

I'm trying to compile a list of critical bugfixes and workaround for
users of Boost 1.35.0.  I already got this information on Boost.Threads
and Boost.Filesystem from their respective maintainers.  If anyone knows
of further issues I would appreciate hearing about them.  The ideal
would be to refer me to the changeset in our SVN that addresses the
issue, but any information would be most appreciated.

Thanks,

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Ralf W. Grosse-Kunstleve | 4 Sep 21:12

[math] svn rev 48294 (2008-08-22) breaks gcc 3.2 builds

Hi,

This svn revision...

------------------------------------------------------------------------
r48294 | johnmaddock | 2008-08-22 05:51:40 -0700 (Fri, 22 Aug 2008) | 1 line

Merged changes from sandbox, and regenerated the docs.
------------------------------------------------------------------------

broke our gcc 3.2 builds. (Sorry I couldn't report this earlier; I was out of town.)

The minimal reproducer is simply:

#include <boost/math/special_functions/atanh.hpp>

% g++ -c -Iboost atanh.cpp
In file included from boost/boost/math/special_functions/atanh.hpp:24,
                 from atanh.cpp:1:
boost/boost/math/special_functions/log1p.hpp:456: new declaration `
   template<class T> T boost::math::log1pmx(T)'
boost/boost/math/special_functions/math_fwd.hpp:491: ambiguates old declaration 
   `template<class T> boost::math::tools::promote_args<RT, float, float, float, 
   float, float>::type boost::math::log1pmx(T)'

% g++ --version
g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20)

I can make the error go away with the simple-minded patch below, just to prove that the ifdefed-out
code is the only problem for us.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane