October 2008 - Boost - lists.preview.boost.org

[1.37] Merge permission sought (not a repost :-)
by Nicola Musatti 15 Oct '08

15 Oct '08

Hallo, I'd like to merge the attached patch to release. May I proceed? Thanks! Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/ Index: float_functions.hpp =================================================================== --- float_functions.hpp (revision 49317) +++ float_functions.hpp (working copy) @@ -60,7 +60,7 @@ # endif // Dinkumware. -#elif (defined(_YVALS) && !defined(__IBMCPP__)) || defined(_CPPLIB_VER) +#elif ((defined(_YVALS) && !defined(__IBMCPP__)) || defined(_CPPLIB_VER)) && !defined(__BORLANDC__) // Some versions of Visual C++ don't seem to have the C++ overloads but they // all seem to have the c99 float overloads # if defined(BOOST_MSVC)

3 5

[1.37] Merge permission sought (the last one, promise!)
by Nicola Musatti 15 Oct '08

15 Oct '08

Hallo, Much to my dismay I realized this morning that I left the following patch behind: http://svn.boost.org/trac/boost/attachment/ticket/2346/boost_type_traits.pa… I'm fully aware that it is rather extensive to be applied this late in the cycle. However it is specific to Borland/CodeGear and has gone through a few test cycles on trunk without causing problems. Unfortunately due to the fundamental role that the type_traits library plays in the implementation of many other libraries, without this patch most of the other Borland/CodeGear related ones have no effect. I discussed this with John Maddock and he agreed to perform the merge if I obtained your permission. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

3 3

[GIL] compile time concerning apply_operation and explicit instantiation
by Philipp Reh 15 Oct '08

15 Oct '08

Hi, I'm using GIL's dynamic image extension, namely any_image_views in certain places. However on every occasion where an any_image_view is used I have to include apply_operation.hpp so the operations can be instantiated. On gcc-4.3.2 the inclusion of this header raises the compilation time at least tenfold. Somewhere on this list I found the claim that gil::variant is supposed to reduce compilation time over boost::variant but for at least gcc-4.3.2 this is untrue. There are several places in which I use boost::variant and even with binary visitation the compilation time is barely unnoticable. To work around this problem, I tried to explicitly instantiate the functions generated for my any_image_view. Trying this technique with apply_operation and detail::destructor_op failed. Looking at nm's output told me that what I explicitly instantiated and what the binary needs had at least its mpl::vector elements reversed. So, I basically have two questions: 1) Wouldn't it be nicer to use boost::variant for gil, too? As far as I can see it does everything that is needed plus it compiles a lot faster (at least on gcc). 2) Is it possible to explicitly instantiate the apply_operation function with the needed operations and if how so? If someone needs the code I tried and the error messages, I can post them. Philipp -- View this message in context: http://www.nabble.com/-GIL--compile-time-concerning-apply_operation-and-exp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[function] Thread-safety regression in 1.36.0?
by Aleksey Gurtovoy 15 Oct '08

15 Oct '08

Doug, Emil, It seems that the problematic code discussed in http://thread.gmane.org/gmane.comp.lib.boost.devel/164902/, filed as a bug (http://svn.boost.org/trac/boost/ticket/1260) and consequently fixed in the trunk has been (inadvertently?) reverted by changeset 43884, "Change Boost.Function allocator behavior, from Emil Dotchevski" (http://svn.boost.org/trac/boost/changeset/43884) Am I missing something obvious? -- Aleksey Gurtovoy MetaCommunications

2 3

[python] borrowed
by Robert Dailey 14 Oct '08

14 Oct '08

What is the purpose of boost::python::borrowed? The documentation has no description for this member that I can see.

3 4

[release mgt] Eric Niebler joining release management team
by Beman Dawes 14 Oct '08

14 Oct '08

Eric Niebler is joining the release management team. Eric will be helping out with general release management and quality control. Like Rene Rivera and Daniel James, he will backup Beman so that release management isn't dependent on any single person. Thanks to Eric for agreeing to help out! --Beman

4 3

Ticket #2115 Avoid bad Apple macros
by Beman Dawes 14 Oct '08

14 Oct '08

> Apple has a header called <AssertMacros.h> that #defines both “check” > and “check_error.” These macros naturally collide with the same names > in Boost. We should consider a global change. What global change? That Boost not use these names? What about the other horrid macros in that header? Here is a list from Marshall: debug_string, check, ncheck, check_string, ncheck_string, check_noerr, check_noerr_string, verify, nverify, verify_string, nverify_string, verify_noerr, verify_noerr_string, verify_action, require, nrequire, require_action, nrequire_action, require_quiet, nrequire_quiet, require_action_quiet, nrequire_action_quiet, require_string, nrequire_string, requireaction_string, nrequireaction_string, require_noerr, require_noerr_action, require_noerr_quiet, require_noerr_action_quiet, require_noerr_string, require_noerr_action_string. Marshall comments: IMHO, the really nasty ones are: check, verify, require and check_error. > That would also > probably require a global policy change for checkins. > > Assigning to Beman, Cc'ing John M, component "inspection script" > assigned to John although I might be wrong about that, but obviously > we need to discuss this. Maybe we'll decide to make it "wontfix" I really don't want to start a policy of avoiding every name that is defined in any vendor header. I forget the details, but at least one vendor has shipped a header defining "read" and "write" macros! The fix for this one is to complain to Apple. They need to provide a new new header that supplies the functionality but using macro naming discipline, deprecate the old header, and add a warning to the old header suggesting that users migrate to the new header. If they wanted to be really helpful, they could provide a script to automatically change the old names to the new names. And if they have any other headers that fail to apply macro naming discipline, they should do the same for those headers too. By "naming discipline", I mean something like the Boost policy for macro names always being all uppercase and beginning with BOOST_. --Beman

8 14

New library in Vault: Msm (Meta State Machine)
by christophe henry 14 Oct '08

14 Oct '08

Hi, Following advice from Dave Abrahams and Aleksey Gurtovoy who were nice enough to have a look at the doc, I just uploaded to the Vault the first version of Msm and would be delighted to have as many people as possible have a look at it and give their opinion before I dare request a formal review. Msm offers an alternative to Boost.Statechart by implementing a relatively big subset of the UML State machine specification at high run speed and staying as close as possible to the beautiful Domain-Specific-Language described in the "C++ template metaprogramming" book. Tutorials and features can be found in doc/index.html. In doc you will also find the tutorials' code. Christophe _________________________________________________________________ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

2 1

[parameter] error in BOOST_PARAMETER_NAME reference docs
by Ryan Gallagher 14 Oct '08

14 Oct '08

There appears to be an error in the BOOST_PARAMETER_NAME reference docs. See: http://tinyurl.com/4my48e This lists that the macro parameter "name" can be of the form: "(tag-name, namespace-name) object-name" Where "tag-name" is a structure defined in namespace "namespace-name" and "object-name" is an instance of: "::boost::parameter::keyword<tag-namespace::tag-name>::instance" (Also note that "tag-namespace" should be "namespace-name" here.) However, the implementation appears to actually be "(object-name, namespace-name) tag-name" However, this information is repeated under the "Fine-Grained Name Control" section, in which it appears to be correct. -Ryan

1 0

[1.37.0][Spirit] Spirit branches/release regression test failures
by Beman Dawes 14 Oct '08

14 Oct '08

See http://beta.boost.org/development/tests/release/developer/spirit.html Note that many of these tests were run after the revision 49310 branches/release commits. Please resolve these failures as soon as possible. Thanks, --Beman

2 1