- Boost - lists.boost.org

[interprocess] named_condition
by Jan Stetka 05 Dec '08

05 Dec '08

The program stops running when it reaches cond.wait(...); This works ok when its compiled on its own but not with the rest of my code. boost::interprocess::named_mutex nm(boost::interprocess::create_only,"STOP_PH_MTX"); boost::interprocess::named_condition cond(boost::interprocess::create_only,"STOP_PH_CND"); boost::interprocess::scoped_lock<boost::interprocess::named_mutex> stop_ph_lock(nm); cond.wait(stop_ph_lock); boost::interprocess::named_mutex::remove("STOP_PH_MTX"); boost::interprocess::named_condition::remove("STOP_PH_CND");

2 2

Breaking existing libraries
by Tomas Puverle 04 Dec '08

04 Dec '08

You may or may not have noticed a thread I started on boost.users about the breaking changes to Boost.Range. Here’s a short summary: We are currently (firmwide) using boost 1.33.1. I am in the process of trying to migrate and test some of our apps with boost 1.37. In 1.35 there was a breaking change to Boost.Range with respect to how singular ranges behave. This brings up several issues: 1) The breakage was silent. The interface stayed the same but the behavior changed, and drastically so. 2) No communation: While I don’t usually post to boost.devel/boost.user, I and my colleagues still read it. Nobody recalls any mention of this on the list. Searching gmane brings up nothing, either. 3) No documentation on the boost website. As far as I can see, this change was introduced in 1.35 this March. On http://www.boost.org/users/news/version_1_35_0, there is no mention of a breaking change to Boost.Range. 4) The new Boost.Range behaves differently in debug and release builds. The public function is_singular() always returns false in release builds even when it would return true in debug builds. Apart from the fact that this change breaks a lot of our code and obsoletes several useful (necessary?) idioms, the manner in which it happened is far below the standards that one has come to expect from boost. At the moment, I have to say I don’t have a good answer to how to fix our code. However, I would at least like to try to make sure this kind of silent breakage doesn’t happen again. Tom

28 86

[graph] 'short' in bundled property throws boost::bad_any_cast
by remi.chateauneu＠gmx.de 04 Dec '08

04 Dec '08

Hi, I have a graph with a bundled property whose one of the members is a 'short'. When calling read_graphml, it throws an exception: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_any_cast> >' what(): boost::bad_any_cast: failed conversion using boost::any_cast Same problem with 'unsigned short'. With 'int' and 'long', it works.

2 2

[interprocess] maximum length for names of mutexes, memory segments etc.
by JOAQUIN M. LOPEZ MUÑOZ 04 Dec '08

04 Dec '08

A component of Boost.Flyweight called intermodule_holder internally uses some Boost.Interprocess objects with very long names intended to guarantee sistem-wide uniqueness. For instance, this is how such an internal mutex can be named (87 chars): boost_flyweight_intermodule_holder_mutex_5660_601342046_2913549788_3054690985_591945496 Alas seems like 87 chars is too much in some platforms like NetBSD: terminate called after throwing an instance of 'boost::interprocess::interprocess_exception' what(): File name too long See http://tinyurl.com/6m693p . This problem also shows in some of Boost.Inteprocess own tests for NetBSD. Is there any maximum length we can safely commit to across allplatforms? (docs are silent wrt this). Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

[interprocess] preparing containers
by Thorsten Ottosen 04 Dec '08

04 Dec '08

Hi Ion, Some of my students tried to use boost::circular_buffer with Boost.Interprocess allocators. Apparently the docs does not mention circular_buffer as one that is compatible with Boost.Interproccess. What do we need to do to make a container that support the special allocators? In particular, if I want to use boost::ptr_vector, then do I need to have stateful allocators (both the normal container allocator, and the clone_allocator)? Thanks -Thorsten

4 10

Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
by Deane Yang 04 Dec '08

04 Dec '08

Joe Gottman wrote: > Deane Yang wrote: >> Edward Diener wrote: >>> Deane Yang wrote: >>>> >>>> I have an even more extreme view on this. I don't believe any >>>> arithmetic operations should be permitted for constrained numbers. >>>> They just don't make sense (would you ever want to add two different >>>> days of a month?). >>> >>> You have chosen a particular type for which arithmetic operations >>> sometimes make little sense. In many other situations this is not the >>> case. >> >> >> Could you give an example? > > > One example: adding 2 to Monday to get Wednesday, or adding 2 to > Saturday to get Monday. > > But that does not correspond to the built-in arithmetic operation. This is modular arithmetic in disguise, so wouldn't make more sense to use a modular integer class (integers mod 7) and represent the days of the week using the numbers 0 to 6?

2 1

Improving Boostbook's Output
by John Maddock 04 Dec '08

04 Dec '08

Currently the Boostbook XSL stylesheets generate a lot of verbose output when run: to put this in perspective a complete build of the docs under boost-root/doc/ generates 3.1 Mb of messages, quite a large proportion of which are from Boostbook. Consequently at present it's impossible to figure out what represents a real issue, and what's just "chaff". So I'm proposing changing the Boostbook stylesheets as follows: * Add a new xsl:param "boostbook.verbose" which defaults to 0. * For each occurrence of xsl:message in the style sheets, we will either: * Terminate with an error if the message looks like it's a possible genuine error. * Otherwise emit a warning *only* if boostbook.verbose=1 I'm prepared to invest some time to make this work, but any comments or possible issues anyone foresees from this change? Cheers, John.

1 0

Mailing list configuration
by Vladimir Prus 04 Dec '08

04 Dec '08

Hi, it seems that the way most Boost mailing list are configure is fairly inconvenient, especially for newcomers. Here's a typical chain of events: 1. Somebody reads Boost mailing list via Gmane and wants to post. 2. He posts. 3. Gmane responds, asking the user to prove that he exists. Somewhere in the body of the message, Gmane suggest that user subscribes to the mailing list, but it's very easy to miss, and furthermore, those instructions do no work for Boost mailing lists. 4. User replies, and Gmane forwards the message to the list. 5. The list is configured to reject email messages from non-subscribers. When using Gmane, this results in *no notification at all*. 6. User posts directly, and gets bound message saying, literally: allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at boost-docs-owner(a)lists.boost.org and [email address] This message does not even hint that the user has to subscribe. 7. User subscribes. His post in the held for moderation. I have personally was fairly confused by (6) -- where my messages disappear silently, and by (7) -- where the message seem to say my messages are specifically rejected. I suspect many users might not make it to the point (7) at all. Can we configure all mailing list to not reject posts from non-subscribes, instead holding them for moderation. This will also require talking to mailing list admins to enable at least some spam filtering -- presently, messages written in the languages I don't understand seem to freely hit boost-build mailing list moderation queue, and for boost-devel this will be impossible to handle. Comments? - Volodya

2 1

Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
by raindog＠macrohmasheen.com 04 Dec '08

04 Dec '08

Another example: 6 represents june. 6 + 3 is then 3 months after june, otherwise september. 6 + 12 is the next june. ------Original Message------ From: Edward Diener Sender: boost-users-bounces(a)lists.boost.org To: boost-users(a)lists.boost.org Cc: boost(a)lists.boost.org ReplyTo: boost-users(a)lists.boost.org Sent: Dec 3, 2008 8:03 PM Subject: Re: [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today Deane Yang wrote: > Edward Diener wrote: >> Deane Yang wrote: >>> >>> I have an even more extreme view on this. I don't believe any >>> arithmetic operations should be permitted for constrained numbers. >>> They just don't make sense (would you ever want to add two different >>> days of a month?). >> >> You have chosen a particular type for which arithmetic operations >> sometimes make little sense. In many other situations this is not the >> case. > > > Could you give an example? An example of what ? Of a constraint where arithmetic operations make sense ? If we take a constraint representing a percentage between 0 and 100, I think it is perfectly valid to add a percent to what is already there. That is just one of innumerable cases where arithmetic operations of contraints seem perfectly valid to me. Why would you even want to consider limiting constraints by removing arithmetic operations if the underlying type supports such operations ? _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Sent from my Verizon Wireless BlackBerry

2 1

regression in math
by frederic.bron＠alcan.com 04 Dec '08

04 Dec '08

Very strange: nearly all regression tests failed on my linux platform with g++: http://www.boost.org/development/tests/trunk/developer/math.html (look at linux_x86_64, bronf) The reason is the always the same but is strange to me: "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -mfpmath=sse -mieee-fp -march=nocona -fPIC -Wno-missing-braces -DBOOST_ALL_NO_LIB=1 -DBOOST_REGEX_DYN_LINK=1 -DBOOST_UBLAS_UNSUPPORTED_COMPILER=0 -I".." -c -o "/soft/bal/usr/builds/boost_test/results/boost/bin.v2/libs/math/test/dist_bernoulli_incl_test.test/gcc-3.4.6/debug/dist_bernoulli_incl_test.o" "../libs/math/test/compile_test/dist_bernoulli_incl_test.cpp" In file included from ../boost/math/distributions/detail/common_error_handling.hpp:13, from ../boost/math/distributions/bernoulli.hpp:33, from ../libs/math/test/compile_test/dist_bernoulli_incl_test.cpp:9: ../boost/math/special_functions/fpclassify.hpp:170: error: expected unqualified-id before '&&' token This line has been modified recently and seems not to work now with g++: Index: boost/math/special_functions/fpclassify.hpp =================================================================== --- boost/math/special_functions/fpclassify.hpp (revision 50010) +++ boost/math/special_functions/fpclassify.hpp (working copy) @@ -165,7 +165,9 @@ { return BOOST_FPCLASSIFY_PREFIX fpclassify(t); } -#if !defined(__CYGWIN__) && !defined(__HP_aCC) && !defined(BOOST_INTEL) && !defined(BOOST_NO_NATIVE_LONG_DOUBLE_FP_CLASSIFY) +#if !defined(__CYGWIN__) && !defined(__HP_aCC) && !defined(BOOST_INTEL) \ + && !defined(BOOST_NO_NATIVE_LONG_DOUBLE_FP_CLASSIFY) \ + && !(defined(__GNUC__) && !defined(BOOST_MATH_USE_C99)) // The native fpclassify broken for long doubles with aCC // use portable one instead.... F. Bron ___________________________________ Frédéric Bron (frederic.bron(a)alcan.com) Unité ALT, Alcan CRV, BP 27, 38341 Voreppe +33 4 76 57 81 72, +33 6 07 48 56 67 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.

2 1