October 2008 - Boost - lists.boost.org

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

status on Coroutine library?
by Tim Michals 07 Oct '08

07 Oct '08

What is the status of the coroutine library? _________________________________________________________________ Get more out of the Web. Learn 10 hidden secrets of Windows Live. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!5…

1 0

[config] Any reason not to enable long long support in for Sun's compiler?
by John Maddock 07 Oct '08

07 Oct '08

Title says it all really, any reason why I should define BOOST_HAS_LONG_LONG for sun's compiler? Seems to all work OK... John.

2 2

[lambda] Serialising Lmanda functions
by Robert Jones 07 Oct '08

07 Oct '08

Is there a 'standard' solution to this problem? #include <list> #include <iostream> #include "boost/lambda/lambda.hpp" typedef std::list<unsigned> List; std::ostream & operator<<( std::ostream & s, const List & ); int main( ) { using namespace boost::lambda; List my_list; ( std::cout << _1 << "\n" )( my_list ); } The compiler cannot find a match for operator<<() because the operator and the type are defined in different namespaces, but it's really a nuisance! - Rob.

2 1

Difficulties checking into release ready branch
by Robert Ramey 07 Oct '08

07 Oct '08

In following instructions to commit to the releae ready branch I get the following message: Modified: BoostRelease\boost\archive\impl\basic_binary_iprimitive.ipp Error: Commit failed (details follow): Error: Your file or directory 'impl\basic_binary_iprimitive.ipp' is probably out-of-date Error: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit). This was after a bunch of files got commit successfully. In the past when problems like this occured (as they often seem to), repeating the operation (with maybe an intervening clean up) seemed to plow through the situation. But this time it seems something is permantly stuck. Any help would be appreciated. Robert Ramey

2 2

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

[spirit1] including type_traits.hpp
by Richard Webb 06 Oct '08

06 Oct '08

When looking at <http://thread.gmane.org/gmane.comp.lib.boost.devel/180769>, i noticed that <boost\spirit\home\classic\core\parser.hpp> includes <boost/type_traits.hpp>, when only part of it (remove_reference.hpp?) actually seems to be required. Not really a problem, but including the full type_traits.hpp does add quite a bit of weight to my precompiled header.

2 2

[RFC] Protocol for operator. (dot) overloading
by Corrado Zoccolo 06 Oct '08

06 Oct '08

Hi boosters, I think that Adobe poly approach on "operator . overloading" could be extracted as orthogonal to the polymorphic object container concept, and easily generalized to serve all kinds of wrappers. My proposal (see code in the vault: *http://tinyurl.com/5xo9or*) is to have a class template (interface<T,W,B>) that describes the interface of type T, forwarding any operation to the implementation type, got directly from the wrapper (W). B is used when vertical inheritance is needed, either to benefit of EBO or to insert a base class on top of the hierarchy (see type_erasure_wrapper). There is actually a fourth boolean parameter, that will be explained later. interface<T,W,B> can be partially specialized for user types (and libraries can provide the specializations for theirs), leaving the wrapper as free parameter, so that the same specialization can be used for any wrapper we can subsequently write, thus decoupling the interface description step from the interface usage by a wrapper. The interface is separated in 3 parts: * const interface (interface<const T, W, B>) * mutable interface (interface<T, W, B, false>) for const propagating wrappers (inherits from the const interface) * mutable interface (interface<T, W, B, true>) for non const propagating wrappers (simply a copy of the previous one, but with all members/member functions declared const) *Example, for std::string* // sample (*const*) interface for std::string template<typename W, typename B> struct interface<const std::string, W, B> : B { typedef const std::string type; std::size_t size() const { return get_()->size(); } const char * c_str() const { return get_()->c_str(); } // free operators as friend template<typename W1, typename B1> friend std::string operator+ (const interface<const std::string,W,B>& lhs, const interface<const std::string,W1,B1>& rhs) { return *lhs.get_()+*rhs.get_(); } // snip other overloads of operator+ private: typename interface_hook_type<type, W>::type get_() const { return static_cast<W const*>(this)->get_(); } }; // sample (*mutable*) interface for std::string template<typename W, typename B> struct interface<std::string, W, B, false> : interface<const std::string, W, B> { typedef std::string type; void swap(std::string& other) { get_()->swap(other); } std::string& operator=(std::string other) { get_()->swap(other); return *get_(); } std::string& append ( const std::string& str ) { return get_()->append(str); } //snip other overloads of append private: typename interface_hook_type<type, W>::type get_() { return static_cast<W*>(this)->get_(); } }; // mutable, version for non-const propagating wrappers template<typename W, typename B> struct interface<std::string, W, B, true> : interface<const std::string, W, B> { typedef std::string type; void swap(std::string& other) const { get_()->swap(other); } std::string& operator=(std::string other) const { get_()->swap(other); return *get_(); } std::string& append ( const std::string& str ) const { return get_()->append(str); } //snip other overloads of append private: typename interface_hook_type<type, W>::type get_() const { return static_cast<W const*>(this)->get_(); } }; In the archive, you can find: * interface.hpp = definition of interface class template * string_interface.hpp = partial specialization of interface class template for std::string * pair_interface.hpp = partial specialization of interface class template for std::pair (interesting for the way to handle first and second) * wrappers.hpp = some example wrappers. We distinguish between wrappers that propagate their constness to their wrapped type (value semantics, like containers) and wrappers that do not propagate constness (ptr semantics, like reference_wrapper, smart pointers), and provite examples for both. A wrapper (computation_wrapper) is provided in both flavors. * lockable.hpp = a more complex example wrapper. lockable<T> (locking proxy) automatically locks when accessing a method of T through the wrapper. * test{1,2,3,4,5,6}.cc instantiate the wrappers on various types, showing which expressions are well formed and which are't. ** test1: lockable<T> ** test2: string interface (methods & operators), reference vs. value wrappers ** test3: type_erasure_wrapper<I,T> ** test4: const-propagating vs. non-const propagating wrappers, in various scenarios (const wrapper<T>, wrapper<const T>, const wrapper<const T>) ** test5: computation_wrapper<T>, and fundamental types ** test6: pair interface Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo@gmail.com PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

2 2

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