November 2007 - Boost - lists.boost.org

Problem with error_code.hpp dependency on winerror.h
by Emil Dotchevski 05 Nov '07

05 Nov '07

I am wondering why does error_code.hpp include <winerror.h>? All it does is translate the error codes defined in <winerror.h> to a enum values defined in error_code.hpp; however this enum is windows-specific anyway and the user can't use it without <winerror.h>. So, why not leave it up to the user to include <winerror.h> if they care about those values to begin with? My problem is that I get a compile error under Windows, because I (indirectly) include error_code.hpp in my own cpp that is supposed to be platform-independent, and as such it does not see the platform SDK. Emil Dotchevski

4 9

Re: [boost] [Boost C++ Libraries] #1408: Missing includes and other compilation errors
by Jens Seidel 05 Nov '07

05 Nov '07

Hi Eric, On Sun, Nov 04, 2007 at 02:43:41PM -0800, Eric Niebler wrote: > Hi, Jens. Thanks for reporting these problems. I don't see a patch attached > to the bug report. Did you forget? no, I did not forget it. My attempt to attach it failed as it was considered as spam. I thought this is true for the bug report itself not just the attachment ... I attached the patch to my message on the boost list and again to this mail. > Boost C++ Libraries wrote: >> #1408: Missing includes and other compilation errors >> -------------------------------------+-------------------------------------- >> Reporter: jensseidel(a)users.sf.net | Owner: eric_niebler >> Type: Patches | Status: new >> Milestone: Boost 1.35.0 | Component: xpressive >> Version: Boost Development Trunk | Severity: Problem Keywords: >> | >> -------------------------------------+-------------------------------------- >> >> First off all xpressive/proto/v1_/proto_fwd.hpp >> includes a non existing header file and is completely unusable. All files >> which include it are unusable as well. >> > > Hmm, the v1_ folder is old code. I'll probably just remove it. OK. >> There is another error I could not fix: >> xpressive/proto/transform/construct.hpp: >> error: default arguments are only permitted for function parameters >> > > I can't reproduce this error. Can you send me a test case, and also tell me > what compiler and version you're using? $ cat test.cpp #include <boost/xpressive/proto/transform/construct.hpp> int main() {} $ g++ --version g++ (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) $ g++ -I .. -pedantic -Wall -W test.cpp In file included from test.cpp:1: ../boost/xpressive/proto/transform/construct.hpp:93: error: expected nested-name-specifier before ‘Visitor’ ../boost/xpressive/proto/transform/construct.hpp:95: error: expected ‘>’ before ‘BOOST_MPL_AUX_LAMBDA_ARITY_PARAM’ ../boost/xpressive/proto/transform/construct.hpp:104: error: type/value mismatch at argument 4 in template parameter list for ‘template<class R, class Expr, class State, int Visitor> struct boost::proto::transform::detail::apply_aux_’ ... After changing typename Visitor into class Visitor in line 93: In file included from test.cpp:1: ../boost/xpressive/proto/transform/construct.hpp:95: error: default arguments are only permitted for function parameters ../boost/xpressive/proto/transform/construct.hpp:104: error: type/value mismatch at argument 4 in template parameter list for ‘template<class R, class Expr, class State, boost::proto::transform::detail::Visitor (* BOOST_MPL_AUX_LAMBDA_ARITY_PARAM)(long int)> struct boost::proto::transform::detail::apply_aux_’ ../boost/xpressive/proto/transform/construct.hpp:104: error: expected a constant of type ‘boost::proto::transform::detail::Visitor (*)(long int)’, got ‘Visitor’ Jens

2 1

Boost.xpressive: [PATCH] Missing includes and other compilation errors
by Jens Seidel 04 Nov '07

04 Nov '07

Hi, I tried to report the following in the bug tracker but failed (not for the first time!) because my message was considered as spam. THIS MAKES TRAC USELESS! FIX IT! OK, since I'm unable to use trac I will report it here and just hope that it will not be ignored. I noticed a few errors in xpressive in currrent trunk. The attached patch fixes all issues I found except two: First off all xpressive/proto/v1_/proto_fwd.hpp includes a non existing header file and is completely unusable. All files which include it are unusable as well. There is another error I could not fix: xpressive/proto/transform/construct.hpp: error: default arguments are only permitted for function parameters Other issues I fixed: * Missing include statements * Removed superfluous semicolons which cause a compiler error with g++ option -pedantic Jens

1 0

Mutli index container - performance varation when erasing large amount of rows in different computers
by Avi Revivo 04 Nov '07

04 Nov '07

Hi All, I am trying to use boost Multi Index Container in my company product to replace an old container that gave the same functionallity but with bad performance. The mutli index container contains 2 non unique ordered indices. The mutli index container will be used to insert large amount of rows sequentially and an erase using one of the ordered indices that will evantually erase around 10,000 rows in one erase operation since the container will contain many duplicate values of the delete key. Testing the insertion of 10,000 rows takes around 60-80ms on a standard PC 3.2GHZ. On a HP G4 server (2 xeon 3.2 cpu's, 4Giga of memroy) the performance is a little better. In both cases the insertion is consistent. However, while erasing elements using one of the indices which incur the erase of 10,000 elements takes around 30ms on the standard PC. However, on the HP G4 the deletion is inconsistent and far worse. It takes between 200ms to 1.4 seconds on different deletion cycles. I am using the same products exactly on both machines. The HP G4 does not have a development envoirment installed on it, the standard pc have visual studio 2005 installed on it. Does anyone have any idea what may cause such exterme difference? Thanks in advance, Avi Nice Systems ltd. -- View this message in context: http://www.nabble.com/Mutli-index-container---performance-varation-when-era… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

[Report] 59 failures on trunk (2007-11-04)
by Douglas Gregor 04 Nov '07

04 Nov '07

Boost regression test failures Report time: 2007-11-04T11:49:19Z This report lists all regression test failures on release platforms. Detailed report: http://boost.org/regression/trunk/developer/issues.html 59 failures in 15 libraries conversion (3) fusion (7) gil (2) graph (3) math (1) numeric/interval (6) optional (4) python (1) regex (1) serialization (10) spirit (12) system (4) test (1) thread (3) wave (1) |conversion| lexical_cast_loopback_test: gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 msvc-8.0 |fusion| filter_view: acc fused: acc fused_function_object: acc fused_procedure: acc make_fused: acc make_fused_function_object: acc make_fused_procedure: acc |gil| main: acc gcc-4.1.2_sunos_i86pc |graph| kolmogorov_max_flow_test: acc max_flow_test: acc transitive_closure_test: gcc-4.1.2_sunos_i86pc |math| test_bessel_j: darwin-4.0.1 |numeric/interval| mul: darwin-4.0.1 darwin-4.0.1 overflow: darwin-4.0.1 darwin-4.0.1 pi: darwin-4.0.1 darwin-4.0.1 |optional| optional_test: darwin-4.0.1 optional_test_ref: darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 |python| exec: gcc-4.1.2_sunos_i86pc |regex| static_mutex_test: gcc-4.1.2_sunos_i86pc |serialization| test_exported_binary_archive: gcc-4.1.2_sunos_i86pc test_exported_binary_archive_dll: gcc-4.1.2_sunos_i86pc test_exported_text_archive: gcc-4.1.2_sunos_i86pc test_exported_text_archive_dll: gcc-4.1.2_sunos_i86pc test_exported_text_warchive: gcc-4.1.2_sunos_i86pc test_exported_text_warchive_dll: gcc-4.1.2_sunos_i86pc test_exported_xml_archive: gcc-4.1.2_sunos_i86pc test_exported_xml_archive_dll: gcc-4.1.2_sunos_i86pc test_exported_xml_warchive: gcc-4.1.2_sunos_i86pc test_exported_xml_warchive_dll: gcc-4.1.2_sunos_i86pc |spirit| custom_real_parser: acc darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 msvc-8.0 custom_real_parser_debug: acc darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 msvc-8.0 |system| error_code_test: acc error_code_test_dll: acc system_error_test: gcc-mingw-3.4.5 system_error_test_dll: gcc-mingw-3.4.5 |test| prg_exec_fail3: gcc-4.1.2_sunos_i86pc |thread| test_shared_mutex: gcc-4.1.2_sunos_i86pc test_shared_mutex_lib: acc gcc-4.1.2_sunos_i86pc |wave| testwave: gcc-mingw-3.4.5

1 0

Explanation of some problems we'll have with svnmerge
by David Abrahams 04 Nov '07

04 Nov '07

I think this only applies to the old branches created by cvs2svn. Anyway, worth knowing. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[gil]:support for png palette images
by Andreas Pokorny 04 Nov '07

04 Nov '07

Hello, I just stumbled across missing support for PNG_COLOR_TYPE_PALETTE in gil. Somehow most monochrome images e.g. generated with gimp use PNG_COLOR_TYPE_PALETTE with two colors, instead of _GRAY with a bit depth of one. So I thought, maybe someone else already added support for such files? regards Andreas

1 0

Deterimining interest in: Optional Polymorphic Value object with Small Object optimization
by Corrado Zoccolo 04 Nov '07

04 Nov '07

Hi Following the recent interest in clone pointers and Polymorphic value object wrappers, I developed a slightly feature enriched Polymorphic Value object, that implements the small object optimization, and models the Optional Pointee concept. It follows a non-intrusive approach to cloning. The code can be found in the boost vault: *http://tinyurl.com/3a6sq8* Motivation: Dynamic polymorphism is a valuable but underestimated tool to the modern C++ programmer. It for example allows the implementation of type erasure and other techniques for physical decoupling. It is also unavoidable every time dynamic dispatching is needed. Unfortunately solutions based on it may often be slow, because traditional dynamic polymorphism is always paired with dynamic allocation. The proposed tool is targeted to ease the usage of dynamic polymorphism in modern C++ context, by giving value semantics to polymorphic objects, as well as providing a well known optimization technique to avoid dynamic allocation when the involved objects are small. Dynamic polymorphism, value semantics and small object optimization constitute a powerful receipt to solve such problems. As evidence boost::function, among the most valuable tools for type erasure and physical decoupling available in boost, is using all three of them. This tool is meant to be a low level tool, on which powerful abstractions like boost::function could be built easily. Basic Usage Example: #include "optional_poly.hpp" #include <iostream> // class with one virtual method but not virtual destructor // optional_poly will know the derived type, so it will call the correct destructor nevertheless struct B { virtual operator int() {return 0;}}; // lack of virtual destructor is intentional // Derived class, with side effect in destructor to show functionality, and overloaded virtual method to determine which one was called struct D : B { operator int() {return 1;} ~D() { std::cerr<<"Got it\n"; } void swap(D&) {} private: void operator=(D const &); }; // swap reachable via ADL. optional_poly will prefer (by default) this to implement its swap method. Using a trait, you can specify if a swap method or no swap at all should be used for a given type void swap(D& a,D& b) { a.swap(b); } int main() { // optional_poly constructor and operator= require that the static type match the dynamic one. // The following commented code is invalid, and will assert at runtime // const B& d=D(); // boost::optional_poly<B> z=d; // asserts, because optional_poly should be constructed with the concrete derived type // this is the correct way to initialize optional_poly. D must be derived from B (static assertion otherwise). boost::optional_poly<B> z=D(); std::cerr<<*z<<"\n"; // this prints 1 boost::optional_poly<B> s; // uninitialized (empty) optional_poly for interface B s.swap(z); // now s has a D, while z is empty std::cerr<<*s<<"\n"; // prints 1 return 0; } A bit more complex example: #include "optional_poly.hpp" #include <boost/none.hpp> #include <iostream> // we will show how simple callable objects can be returned easily and efficiently from a function (i.e. we implement a really small subset of boost::function) struct Callable { virtual void operator()() const=0; }; // inheritance is used here. This wrapper can host function pointers or functors seamlessly, exposing to the outside the Callable interface template<class T> struct MakeCallable: Callable { MakeCallable(const T& t) : val(t) {} T val; void operator()() const { val(); } }; void my_fun() { std::cout<<"got 1\n"; } struct MyFunc { void operator()() const { std::cout<<"got 2\n"; } }; // the function returning different Callable objects depending on the value of the parameter boost::optional_poly<Callable> foo(int i) { switch(i) { case 1: return MakeCallable<void (*)()>(my_fun); case 2: return MakeCallable<MyFunc>(MyFunc()); } return boost::none; } // main shows how foo() is invoked, and its result is used int main() { boost::optional_poly<Callable> c; for(int i=0;i<3; ++i) { c=foo(i); if(c) { std::cout<<"Going to call c for "<<i<<" ... ";(*c)(); } else { std::cout<<"empty c for "<<i<<"\n"; } } return 0; } Output: empty c for 0 Going to call c for 1 ... got 1 Going to call c for 2 ... got 2 Wasn't this easy? And this small example did not dynamically allocate any memory, because the Callable objects are all smaller than the small object threshold (default value is 128, can be overridden specifying a second template parameter to optional_poly, e.g. optional_poly<Callable,0> will always allocate from the heap). Sounds interesting for being submitted to boost? Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto: zoccolo(a)di.unipi.it PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

14 42

[1.35] Where to place PDF versions of docs?
by John Maddock 04 Nov '07

04 Nov '07

Folks I think we need to get organised with PDF's now that we have many more libraries with quickbook/boostbook docs. I don't particularly want these in SVN trunk: apart from anything else it needlessly bloats the download size if folks are happy with HTML versions. Previously I've placed these in the vault, but there's a file size limit there and the new Boost.Math PDF's are too large :-( Another alternative would be the sourceforge file release system, but I don't believe all developers have access to that? So.... how about we either have a directory in the "website" area of SVN for these, or else in the sandbox maybe? Thoughts? John.

10 15

[thread] Missing #include
by Andrey Semashev 03 Nov '07

03 Nov '07

Hi, I think boost/thread/pthread/shared_mutex.hpp in trunk is missing #include <boost/thread/thread.hpp>. Now it complains it doesn't know what this_thread is. I also noticed lots of warnings "unused variable 'res'" and alikes while compiling my projects with GCC 4.2.1 on OpenSUSE. These warnings mostly come from boost/thread/pthread/pthread_mutex_scoped_lock.hpp, boost/thread/pthread/once.hpp, boost/thread/pthread/mutex.hpp, boost/thread/pthread/condition_variable.hpp. I didn't investigate closely, though.

5 6