- Boost - lists.boost.org

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

link error "can not open file "libboost_regex-vc80-mt-gd-1_36.lib"
by ipangth 06 Oct '08

06 Oct '08

I built boost_1.36_0 with vs2005, used command "bjam.exe --build-dir="D:\src\boost_1_36_0" --toolset=msvc --build-type=complete stage". Then i built a project using regex, and link error "can not open file "libboost_regex-vc80-mt-gd-1_36.lib" ". I check the stage diretory, found regex libs: libboost_regex-vc80-mt-s-1_36.lib libboost_regex-vc80-mt-s.lib libboost_regex-vc80-mt-sgd-1_36.lib libboost_regex-vc80-mt-sgd.lib libboost_regex-vc80-s-1_36.lib libboost_regex-vc80-s.lib libboost_regex-vc80-sgd-1_36.lib libboost_regex-vc80-sgd.lib There are no "libboost_regex-vc80-mt-gd-1_36.lib" here. How can i get the "libboost_regex-vc80-mt-gd-1_36.lib" ? PS. I have a machine which has vs2005 and vs2008 install, when i built boost on it, it always uses vs2008 to compile. How can i just use vs2005 buiding it? -- Best regards, PangYongQiang

2 4

[asio] ip::tcp::iostream usage
by Gregory Dai 05 Oct '08

05 Oct '08

The classic example: int main() { boost::asio::ip::tcp::iostream s("www.boost.org", "http"); s << "GET / HTTP/1.0\r\n"; s << "Host: www.boost.org\r\n"; s << "\r\n" << std::flush; std::cout << s.rdbuf(); return 0; } It works. But with a server on port 8080, it does not seem to work anymore. The host line was changed to s << "Host: www.boost.org:8080\r\n"; of course.

2 2

[tr1][spirit][hash] Boost trunk +VC9 - autolinking libboost_math
by Richard Webb 05 Oct '08

05 Oct '08

When test building some code with VC9 + the current Boost trunk i had a link failure due to a missing libboost_math_c99-vc90-mt-1_37.lib, which i hadnt built because i'm not using the math lib. On investigation, this seems to be down to using Spirit/Hash(via multi_index) when the "boost/tr1/tr1" dir is in the include path. More specifically, the files: spirit\home\classic\core\primitives\impl\numerics.ipp functional\detail\float_functions.hpp do an include <cmath>, which in this case includes <boost\tr1\cmath.hpp>, which then includes <boost/math/tr1.hpp>, autolinking and all. I can work around the problem by building the math lib or turning off auto linking for it but it seems wrong that i have to do that. Is there a better official solution for this, such as using <config/no_tr1/cmath.hpp> instead of <cmath> ? Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-tr1--spirit--hash--Boost-trunk-%2BVC9---autolinking-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[xpressive] recursive calls for matching repetitions.
by Raindog 05 Oct '08

05 Oct '08

Eric, I was recently hit by a stack overflow due to the way xpressive makes recursive calls when dealing with patterns like *_, etc and was wondering if there is an alternative, more efficient way of matching these types of patterns. p.s I know about keep() but that can get cumbersome to use everywhere.

2 1

[variant] unreferenced formal parameter warning from VC9
by Richard Webb 05 Oct '08

05 Oct '08

(i think i might have mentioned this before, but it still happens with the current code, so...) Using Variant on VC9 with warning level 4 can result in an unreferenced parameter warning: boost/variant/variant.hpp(289) : warning C4100: 'operand' : unreferenced formal parameter This can be silenced by extending the existing Borland workaround to apply to VC as well. For example, change the existing: #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x0551)) operand; // suppresses warnings to #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x0551)) || BOOST_WORKAROUND(BOOST_MSVC, >= 1400) operand; // suppresses warnings Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-variant--unreferenced-formal-parameter-warning-from-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0