September 2008 - Boost - lists.boost.org

[proto][design]why unary_expr,binary_expr; but no nullary_expr?
by Larry Evans 14 Dec '08

14 Dec '08

Although there's unary_expr<Tag,*>, binary_expr<tag.*,*> in traits.hpp there's no nullary_expr<Tag>. I realize this would be a replacement to the current terminal template but with a user specified tag. After all, if a user specified tag for n-ary (where n>0) expressions *is* desirable, why is a user specified tag for 0-ary expressions *not* desirable? On case where this would be useful is for algebraic morphisms where n-ary ops in a source algebra are mapped to n-ary ops in a target algebra. This *includes* 0-ary ops. An op would be the equivalent to proto tags. I think this could be done by another transform similar to the pass_through transform but allowing transformation of the tag. Currently pass_through just uses the source tag in the target expression. It seems like it should be pretty easy to allow transformation on the tag also.

2 3

[flyweight] post-review version available
by JOAQUIN M. LOPEZ MUÑOZ 08 Nov '08

08 Nov '08

Hello, I'm happy to announce the availability of the post-review version of Boost.Flyweight: *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download as .zip:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Check out from SVN:* https://svn.boost.org/svn/boost/sandbox/flyweight *Tested with:* MSVC++ 8.0 and GCC 3.4.4. Compilation reports most welcome. Older compilers like MSVC++ 6.5 are no longer supported. *What's new:* I've tried to address most of the suggestions and comments raised during the review. The two most important changes are: 1. Alberto Barbati's insightful review has led to the introduction of so-called key-value flyweights (http://tinyurl.com/5mnwjp ). This type of flyweights is meant for the situations where constructing the underlying type is expensive and must be avoided except if absolutely necessary. I think the design is robust enough and covers the variants (inner/outer key) that arose during the discussion with Alberto. 2. A comprehensive performance section is provided (http://tinyurl.com/5ap5kt ). *What's pending* 1. Some of the suggestions given at the review, like reducing intermodule_holder to static_holder when permissible (Vicente Botet) or studying read/write locking policies are still pending or have been postponed to later releases of the library. I felt the current state is sufficiently robust for publication. 2. Serialization support is currently broken, pending the resolution of a proposed feature to add to Boost.Serialization (run-time archive helpers). I'd be very grateful if you can take a look at the post- review version of Boost.Flyweight (specially if you were a reviewer), test it and comment on it, with emphasis on the new features like key-value flyweights. If people are happy with this revision my target release for inclusion will be Boost 1.38. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 12

Review Request: Polynomial
by Paweł Kieliszczyk 30 Oct '08

30 Oct '08

Hi, I'd like to request a review of my polynomial library which I wrote during Google Summer of Code project this year. The zip file is in Boost Vault (called polynomial.zip). It includes the library, tests and documentation. The same files (not compressed) are also available in sandbox: http://svn.boost.org/svn/boost/sandbox/SOC/2008/polynomial/ Thanks -- Pawel Kieliszczyk

3 5

[boost.org] people not updated?
by Thorsten Ottosen 24 Oct '08

24 Oct '08

Hi, It seems like we are missing some of our recent members. -Thorsten

4 3

[Boost.Config] Stlport patch for Sun compilers on Linux
by K. Noel Belcourt 20 Oct '08

20 Oct '08

Hi, I've attached a patch to fix this error with the sun compilers on Linux. http://tinyurl.com/6o4fxg I'm not well versed with the subtleties of Stlport (there may be better ways to code this). The patch merely avoids defining macro BOOST_NO_EXCEPTION_STD_NAMESPACE as the Stlport bundled with the Sun compilers on Linux seems to correctly put all type_info into the std namespace. The Sun compilers on Solaris still require this macro definition. I've tested that this fixes the type_info error with sun-5.9 on Linux and that it doesn't break the Sun tests on Solaris, okay to commit? -- Noel

4 12

ARM thumb support in spinlock_gcc_arm.hpp
by Jerry Napoli 12 Oct '08

12 Oct '08

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

8 13

type_with_alignment.hpp / alignment_of.hpp too heavy
by Emil Dotchevski 08 Oct '08

08 Oct '08

I need to allocate an object of type T, but I also need to bundle it in a single memory allocation with an object of class U. Something like "new std::pair<T,U>" would work, except that U is a rather heavy type and I want to pimpl it away into a cpp. This means that the cpp needs to deal with the alignment of T and U when allocating the memory. For that purpose, I could use type_traits/type_with_alignment.hpp in my header, but when I looked at it, I was blown away by how much crap it includes (remember, I want my header to be very very light.) Then I thought that I could probably build my system by just using type_traits/alignment_of.hpp. It sure would be very light, right? Wrong, it also includes mpl and whatnot. I hope someone shares my frustration. Shouldn't at least alignment_of.hpp be much, much lighter? I'd think that all it should contain is whatever compiler-specific hacks are needed and that's it. What is the justification for including stuff like <boost/mpl/aux_/lambda_support.hpp> in alignment_of.hpp? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

8 9

Speedier test results.
by Rene Rivera 07 Oct '08

07 Oct '08

First, many thanks to Noel and Sandia Labs for the resources to make this possible. Especially since there aren't many places where quad core machines are near the bottom of the speed spectrum :-) So if you didn't notice the testing hiccups during the weekend you missed the fun of watching a new test report generation server being put online. The new server is a magnitude faster than my server. Which means test results are now available approximately on an hourly basis. Note, there are still the usual double delays to account for the time testers take to run the tests. Have fun with the new timely data! -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

4 3

[scope_exit] Status?
by Andrey Semashev 06 Oct '08

06 Oct '08

Hi, I've been wondering what's the status of the Boost.ScopeExit library? It's been accepted more than a year ago, though it didn't make it to neither 1.35 nor 1.36. And I don't see it in trunk either. Is it still alive and expected in 1.37?

2 3

Win64 and abi_prefix.hpp/abi_suffix.hpp warnings
by Chris Newbold 06 Oct '08

06 Oct '08

I know there have been previous discussions about the warnings emitted from abi_prefix.hpp and abi_suffix.hpp on Win64. Was there ever any resolution? To recap, for every header which uses the ABI bookends, the compiler emits four warnings: abi_prefix.hpp(19) : warning C4103: 'abi_prefix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) exceptions.hpp(22) : warning C4103: 'exceptions.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) abi_suffix.hpp(20) : warning C4103: 'abi_suffix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) exceptions.hpp(108) : warning C4103: 'exceptions.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) I'm unclear on the rationale for forcing 8-byte alignment in config/abi/msvc_(pre|suf)fix.hpp: 8-byte alignment is the compiler default. Is there concern over Boost headers being included in a context where the alignment has been otherwise artificially altered? Assuming that's the case, I would like to propose adding a warning suppression to config/warning_disable.hpp to silence this particular warning. Here's a diff of what I'm proposing: @@ -43,5 +43,14 @@ // std library function is encountered. # pragma warning(disable:1786) #endif +#if defined(_MSC_VER) && defined(_M_X64) + // warning: 'file': alignment changed after including header, may + // be due to missing #pragma pack(pop) + // + // Caused by MSVC-specific abi_prefix and abi_suffix bookends which + // twiddle the default structure alignment via #pragma pack(); this + // results in a warning only on x86_64 targets. +# pragma warning(disable:4103) +#endif #endif // BOOST_CONFIG_WARNING_DISABLE_HPP I'd like to get something in for Boost 1.37 as this warning is responsible for a significant amount of spam in our build logs. Comments? -Chris

4 10