- Boost - lists.boost.org

boost.org Source-Code, Concepts & Idioms.
by mbiddeg＠mtn.co.ug 16 Oct '08

16 Oct '08

Good morning Guys. Do you think it feasible to have a section in boost.org that shows (& permits download) the libraries' source-code at its bare-minimum, without all the configuration to clutter the code? The only problem with easily & clearly understanding the boost libraries is the abundance of conditional compilation directives, & a multitude of macros for some libraries. This makes it hard to read & understand. Seeing the bare source-code without the directives & macros (I know it is very necessary for portability, & avoiding boiler-plate code) would make the concepts easier to understand. In addition, I do agree with Scott Meyers in the section below, from the link: http://www.artima.com/cppsource/top_cpp_aha_moments.html#r10 "...Second, I think it's regrettable that this kind of innovation doesn't often get written up and disseminated for the wider C++ development community. Boost does an enviable job of fostering the creation of useful software, including user-level documentation that is at least serviceable. I wish it did a better job of getting the word out on the design and implementation techniques employed by the library authors, because there's some really interesting-and largely unknown-stuff going on under the hood in Boost libraries..." What is your opinion on both these issues? I do believe the entire C++ community would benefit from both. Awaiting your feedback. Thank you. Have a nice day. ______________________________________________________________________ Kizza George Mbidde | Interconnect Billing Systems Analyst | MTN Uganda | MTN Towers 22 Hannington Road | P.O. Box 24624 Kampala Uganda | East-Africa | email: mbiddeg(a)mtn.co.ug [cid:image001.png@01C92D0F.BE2B7C10]

9 18

[1.37.0][Test] Test branches/release regression test failures
by Beman Dawes 16 Oct '08

16 Oct '08

See http://beta.boost.org/development/tests/release/developer/test.html While the revision 49313 commits cleared some errors, there are still several others that need to be resolved. Thanks, --Beman

2 1

[parameter] Redefining BOOST_PARAMETER_MAX_ARITY
by Jamie Allsop 16 Oct '08

16 Oct '08

Should I expect to be able to redefine BOOST_PARAMETER_MAX_ARITY and be able to compile? <http://www.boost.org/doc/libs/1_36_0/libs/parameter/doc/html/reference.html…> For example using, #define BOOST_PARAMETER_MAX_ARITY 6 #include <boost/parameter/name.hpp> #include <boost/parameter/preprocessor.hpp> // ... code here ... does not compile. Before I spend time digging into the source to figure out the problem I thought I'd post in case the answer was 'no'. Also I wonder if there is some theoretical or practical upper limit? Thanks, Jamie

4 7

Re: [boost] New library in Vault: Msm (Meta State Machine)
by christophe henry 15 Oct '08

15 Oct '08

Ah yes. The link to the Vault Msm Directory: http://www.boostpro.com/vault/index.php?direction=0&order=&directory=Msm& _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=…

2 1

Support for Cell processor
by Joel Falcou 15 Oct '08

15 Oct '08

Several boost libraries compile without any problem on the cell BE processor in PPU and SPU mode like most of the preprocessor or meta-programming one. However, it's impossible to use any C++ code that include *any* part of std cause it makes the resulting binary too big for the spu linker. For some boost libraries, the std include is merely used for some optionnal display. For others, large parts of functionnalities is made useless. As I've been toying with this architecture for quite a bit now, I'm on the verge to patch my local boost with a way to detect compilation on Cell SPU and to remove inadequate include from some libraries. Considering the potential interest in supporting this architecture, would libraries developpers mind if I submit ticket with patches for this support integration when the actual pacthes is aimed at making the core of the libraries to be used on Cell BE SPU and to add things like #error or #warning that explicitely states that this library or features is disabled ? What's the current stance on adding new architectural support into boost ? Regards -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

7 12

[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