February 2011 - Boost-users - lists.preview.boost.org

[phoenix] V2, V3 and the amount of memory needed by the compiler to just include them
by Mathieu Champlon 01 Mar '11

01 Mar '11

Hello, Phoenix is an outstanding component, I have no doubt about that. However I have had some mixed results for my use case using V2 and now switching to V3. I'm writing a (header only/template) library which uses Boost.Phoenix internally. By nature this library (a mock object library) often ends up in precompiled headers because it's convenient to have it de facto included for whole (unit test) applications. By default Microsoft Visual Studio allocates a certain amount of memory for compiling a precompiled header, and if it actually needs more then it fails to compile. For instance with only : #include <boost/phoenix/phoenix.hpp> Here is the error message with vc80 : ...boost/fusion/container/vector/vector10.hpp(52) : error C3859: virtual memory range for PCH exceeded; please recompile with a command line option of '-Zm160' or greater ...boost/fusion/container/vector/vector10.hpp(52) : fatal error C1076: compiler limit : internal heap limit reached; use /Zm to specify a higher limit The location of the error is irrelevant, the value suggested by the compiler is what matters. Here it suggests to add /Zm160 to the command line. This is pretty huge, the default is actually /Zm100, and I'd say "big" Boost libraries are around 50. /Zm100 now means 75MB since vc90 instead of 50MB for vc80, which helps a bit, but still... Here is a quick survey I did with vc80, using a /Zm1 to trigger an error every time. The number on the right is the required /Zm value for including only the file on the left. boost/phoenix/phoenix.hpp 160 "equivalent of content of boost/phoenix/phoenix.hpp for Phoenix 2" 107 boost/phoenix/core/nothing.hpp 61 boost/spirit/home/phoenix/core/nothing.hpp 52 boost/phoenix/statement/throw.hpp 62 boost/spirit/home/phoenix/statement/throw.hpp 54 boost/phoenix/bind.hpp 43 boost/spirit/home/phoenix/bind.hpp 56 boost/bind.hpp 17 boost/lambda/bind.hpp 27 boost/lambda/lambda.hpp 30 boost/function.hpp 36 boost/function_types/function_type.hpp 31 boost/test/auto_unit_test.hpp 41 boost/concept_check.hpp 16 boost/type_traits/remove_reference.hpp 12 boost/proto/proto.hpp 55 boost/proto/domain.hpp 20 Note that an empty pch requires /Zm11 Now extracting only the includes from Phoenix to other Boost libraries using : grep -rh "include <b" . | sort -u And removing all boost/phoenix, the result is /Zm56 for V3 and /Zm65 for V2. So V3 reduces the code of Phoenix itself but now uses (a lot) more of other Boost libraries, which incidentally is consistent with the main target of V3 switching to Boost.Proto Of course the resulting amount of memory required for my library is not the sum of the memory required for each included library taken separately (mostly because they re-use each others). And furthermore I can mostly work around the issue by using only phoenix::bind and rewrite some of the missing bits (for instance phoenix::throw_ and phoenix::nothing) But even then and with carefully selecting the includes, it ends up pretty close to the default /Zm100. This means that if the users of my library add a couple more libraries to their pch (Boost.Test comes to mind), they will most certainly go over the limit. All right, after boggling a bit, they will add a bigger /Zm and forget about it for a while, until they upgrade either my library or Boost. Suddenly a lot of their test applications fail to compile because instead of some /Zm112 it now requires /Zm113, and they will need to go over all their projects and update them... For having this happening at my day job on a regular basis, I can attest first hand it is indeed annoying ! I started by saying I have had mixed results using Phoenix, this is because on one hand I resorted to rewriting what I needed using only phoenix::bind and I fear for the future usability of Phoenix, but on the other hand switching to V3 boost/phoenix/bind.hpp actually saves some memory compared to V2 boost/spirit/home/phoenix/bind.hpp ! Regards, MAT.

9 15

[Units] Variant runtime analysis
by Samuel Debionne 01 Mar '11

01 Mar '11

Hello all, My use case is the following : I have a function that returns quantities of different units depending on its input parameters (different derivatives). I could split the function in two parts that returns one unit only, but that would move the problem to an other place in my code. Is there any way to handle this, without breaking the dimensional analysis ? I have been playing with things like : quantity<variant<force, length, energy> > but it doesn't seems to go anywhere... Samuel

3 6

boost::range : comparison operators
by er 01 Mar '11

01 Mar '11

Hello, I'm interested in make_iterator_range( container ); defined in http://svn.boost.org/svn/boost/trunk/boost/range/iterator_range_core.hpp in order to adapt container to have comparison operators. While, template< class IteratorT, class ForwardRange > inline bool operator<( const ForwardRange& l, const iterator_range<IteratorT>& r ) is defined, operator>, for example, isn't. Is there a functionality that provides all operators? Thanks.

2 2

Boost + ICU in Windows with MinGW
by Jose Mondefo 01 Mar '11

01 Mar '11

Hi mates, I have a question about boost compiled with icu support for using it in another library (freeling). All this work is in windows using mingw32, the icu 4.2.1 library and boost 1_40. I compile boost with the following bjam line $ bjam toolset=gcc variant=release threading=multi threadapi=win32 link=shared runtime-link=shared --prefix=$PREFIX --user-config=tools/build/v2/user-config.jam -j 2 --with-filesystem --with-program_options --with-regex define=U_STATIC_IMPLEMENTATION=1 -sHAVE_ICU=1 -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged -a --build-type=complete stage I applied the following patch before compilation, without it I don't get the boost_regex-mt.lib and boost_regex_mt.dll, but the libboost_regex-mt.lib. https://build.opensuse.org/package/view_file?file=boost-regexdll.patch&pack… This compilation works great, and also the compilation of the freeling library, which generates an exe. But after that, If I try to run the generated exe (with the boost dlls ) I get this error terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> > what(): Could not initialize ICU resources Could anyone help me undersanding this error? I suppose it has something to do with some missing ICU files, and I'm sure i make some mistake in the compilation process but I didn't get where is it. I also tried building boost with link=static runtime-link=static, but of course if I do that I don't get the boost_regex-mt.lib but the libbost_regex-mt.lib (and i need the dynamic library for compilation of the freeling library). I now this is not the ICU forum, but if it helps for catching the problem ICU was compiled this way a) apply some diffs from this patch http://devs.openttd.org/~terkhen/libicu/libicu_4_6_mingw32.diff (reference link http://wiki.openttd.org/Compiling_on_MinGW#Compiling_libicu), to make it compile in MinGW (not all cause there are some difference between icu 4.2.1 and 4.6). b) After that run $ ./configure --prefix=/mingw/ --disable-strict --disable-threads $ make install This compilation doesn't generate any dll, only the libs for making boost compile. Thanks in advance and best regards, and sorry if this mails is a mess, I only try to give all the information I think is useful.

2 3

Compilation error using boost::filtered_graph when trying to access graph properties via boost::graph_bundle
by Tony Cook 28 Feb '11

28 Feb '11

Hi, The following test program highlights an compilation error issue when using a boost::filtered_graph to access graph properties. I am using Boost 1.46.0 #include <boost/graph/adjacency_list.hpp> #include <boost/graph/filtered_graph.hpp> class TestGraph { class VertexProperties { public: bool mFlag ; } ; class EdgeProperties { public: bool mFlag ; } ; class GraphProperties { public: bool mFlag ; } ; typedef boost::adjacency_list <boost::vecS, boost::listS, boost::undirectedS, EdgeProperties, VertexProperties, GraphProperties> GraphType ; template <typename GraphType> class EdgePredicate { public: EdgePredicate () : mpGraph (0) {} public: EdgePredicate (GraphType& vrGraph) : mpGraph (&vrGraph) {} public: template <typename EdgeType> bool operator()(const EdgeType& vEdge) const { return (*mpGraph)[vEdge].mFlag ; } private: GraphType* mpGraph ; } ; template <typename GraphType> class VertexPredicate { public: VertexPredicate () : mpGraph (0) {} public: VertexPredicate (GraphType& vrGraph) : mpGraph (&vrGraph) {} public: template <typename VertexType> bool operator()(const VertexType& vVertex) const { return (*mpGraph)[vVertex].mFlag ; } private: GraphType* mpGraph ; } ; typedef boost::filtered_graph<GraphType, EdgePredicate<GraphType>, VertexPredicate<GraphType> > FilteredGraphType ; ... void foo () { GraphType graph ; FilteredGraphType filter (graph, EdgePredicate<GraphType> (graph), VertexPredicate<GraphType> (graph)) ; graph [boost::graph_bundle].mFlag = true ; filter [boost::graph_bundle].mFlag ; // ***** Does not compile - see below ... } } ... gcc 4.5.2 issues the following error message In member function 'typename boost::graph::detail::bundled_result<Graph, Descriptor>::type& boost::filtered_graph<Graph, EdgePredicate, VertexPredicate>::operator[](Descriptor) [with Descriptor = boost::graph_bundle_t, Graph = boost::adjacency_list<boost::vecS, boost::listS, boost::undirectedS, TestGraph::EdgeProperties, TestGraph::VertexProperties, TestGraph::GraphProperties>, EdgePredicate = TestGraph::EdgePredicate<boost::adjacency_list<boost::vecS, boost::listS, boost::undirectedS, TestGraph::EdgeProperties, TestGraph::VertexProperties, TestGraph::GraphProperties> >, VertexPredicate = TestGraph::VertexPredicate<boost::adjacency_list<boost::vecS, boost::listS, boost::undirectedS, TestGraph::EdgeProperties, TestGraph::VertexProperties, TestGraph::GraphProperties> >, typename boost::graph::detail::bundled_result<Graph, Descriptor>::type = TestGraph::VertexProperties]': Visual Studio 2005 issues this error at the same line (see above) error C2440: 'return' : cannot convert from 'TestGraph::GraphProperties' to 'TestGraph::VertexProperties &' test-graph-types.h(78) : see reference to function template instantiation 'TestGraph::VertexProperties &boost::filtered_graph<Graph,EdgePredicate,VertexPredicate>::operator []<boost::graph_bundle_t>(Descriptor)' being compiled with [ Graph=TestGraph::GraphType, EdgePredicate=TestGraph::EdgePredicate<TestGraph::GraphType>, VertexPredicate=TestGraph::VertexPredicate<TestGraph::GraphType>, Descriptor=boost::graph_bundle_t ] The error originates in boost filtered_graph.hpp line 201 199 // Bundled properties support 200 template<typename Descriptor> 201 typename graph::detail::bundled_result<Graph, Descriptor>::type& 201 operator[](Descriptor x) 203 { return const_cast<Graph&>(this->m_g)[x]; } The bug appears to be that using Descriptor = boost::graph_bundle somehow selects the wrong return type for operator[](Descriptor) selecting TestGraph::VertexProperties instead of the expected TestGraph::GraphProperties This is confirmed by redeclaring the GraphType as typedef boost::adjacency_list <boost::vecS, boost::listS, boost::undirectedS, EdgeProperties, VertexProperties, VertexProperties> GraphType ; i.e. the type for the graph properties happens to be the same as that used for the Vertex properties. Now it compiles cleanly!! Can someone help me locate the origin of this problem. I need to patch this quickly :( It should be noted that there are no problems accessing vertex and edge bundled properties via a filtered_graph - only the graph bundled properties exhibit this issue. TIA Tony

2 2

Re: [Boost-users] Boost + ICU in Windows with MinGW
by Jose Mondefo 28 Feb '11

28 Feb '11

In my past email I made a mistake, the ICU configure method I use was a) ./configure --prefix=/mingw/ --enable-static --disable-shared --disable-strict --disable-threads and not b) ./configure --prefix=/mingw/ --disable-strict --disable-threads The a) configure command generates a boost_regex-mt.lib of around 3.5MB. I use the b) command first, but that gives me a boost_regex-mt.lib of about 2MB, and got compilation errors with the freeling library about icu methods not found, for example u_tolower_42. From: soloninguno(a)hotmail.com To: boost-users(a)lists.boost.org Subject: Boost + ICU in Windows with MinGW Date: Mon, 28 Feb 2011 15:42:32 -0300 Hi mates, I have a question about boost compiled with icu support for using it in another library (freeling). All this work is in windows using mingw32, the icu 4.2.1 library and boost 1_40. I compile boost with the following bjam line $ bjam toolset=gcc variant=release threading=multi threadapi=win32 link=shared runtime-link=shared --prefix=$PREFIX --user-config=tools/build/v2/user-config.jam -j 2 --with-filesystem --with-program_options --with-regex define=U_STATIC_IMPLEMENTATION=1 -sHAVE_ICU=1 -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged -a --build-type=complete stage I applied the following patch before compilation, without it I don't get the boost_regex-mt.lib and boost_regex_mt.dll, but the libboost_regex-mt.lib. https://build.opensuse.org/package/view_file?file=boost-regexdll.patch&pack… This compilation works great, and also the compilation of the freeling library, which generates an exe. But after that, If I try to run the generated exe (with the boost dlls ) I get this error terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> > what(): Could not initialize ICU resources Could anyone help me undersanding this error? I suppose it has something to do with some missing ICU files, and I'm sure i make some mistake in the compilation process but I didn't get where is it. I also tried building boost with link=static runtime-link=static, but of course if I do that I don't get the boost_regex-mt.lib but the libbost_regex-mt.lib (and i need the dynamic library for compilation of the freeling library). I now this is not the ICU forum, but if it helps for catching the problem ICU was compiled this way a) apply some diffs from this patch http://devs.openttd.org/~terkhen/libicu/libicu_4_6_mingw32.diff (reference link http://wiki.openttd.org/Compiling_on_MinGW#Compiling_libicu), to make it compile in MinGW (not all cause there are some difference between icu 4.2.1 and 4.6). b) After that run $ ./configure --prefix=/mingw/ --disable-strict --disable-threads $ make install This compilation doesn't generate any dll, only the libs for making boost compile. Thanks in advance and best regards, and sorry if this mails is a mess, I only try to give all the information I think is useful.

1 0

[asio] basic handle query
by Sean Farrow 28 Feb '11

28 Feb '11

Hi: I need to work with multiple basic handles and have a question: If I have a vector of basic handles and have them associated to the same io_service, do I have to call run everytime a new handle is added? Or will as I'm hoping the first io_service.run pick up the new handles if there added after the initial run call. Any help appreciated. Cheers Sean.

2 1

Can I delete/resize a multi_array??
by Ramon F Herrera 28 Feb '11

28 Feb '11

I recently discovered the multi_array, which was the answer to my prayers: typedef boost::multi_array<string, 2> ExpressionArrayType; ExpressionArrayType exprTable(boost::extents[extreme_row][extreme_col]); But now I need more functionality, which can be either: (1) Erase the current "exprTable" and create a new one, with different dimensions. (2) Resize the current dimensions. I have tried things like: ~exprTable; ~exprTable(); delete &exprTable; I have RTFM and Googled but still could use some guidance.... TIA, -RFH

3 4

[tr1/config] portably including unordered_<X>
by Jim Bell 28 Feb '11

28 Feb '11

It appears that <boost/tr1/unordered_X.hpp> includes the native <unordered_X> when Boost.config says it's able. So if one were writing a portable library that uses boost (or bug-fixing an existing boost component), would including <boost/tr1/unordered_X.hpp> be the way to bring it in, or should one look at BOOST_HAS_TR1_UNORDERED_SET and make a decision that way? There's no mechanism analogous to BOOST_HAS_HASH / BOOST_HASH_<X>_HEADER that has to be navigated, right?

2 1

Re: [Boost-users] boost::asio from C++ Forms App in VS 2010
by Alan Vella 28 Feb '11

28 Feb '11

> On 2/25/2011 3:18 PM, Alan Vella wrote: >> Hi all, >> >> I'm trying to port a C++ project from gcc (on MinGW) to Visual Studio >> 2010 inside a Visual C++ Windows Forms application. The code was >> originally written on a Windows XP 32-bit machine. Now it is being >> ported into a Windows 7 32-bit machine. This project uses quite a few >> boost libraries, including the boost::asio library. When I try to >> compile the code in VS2010 I get the following errors: > > If it's an option, you might try VS2008. I've had boost related compile > failures on VS2010 with code that compiles and runs fine on VS2008. > Hi Dave, Thanks for your reply. Unfortunately compiling the code in VS2008 throws the same kind of errors + more! Did nobody ever come across these errors? The first lines seem to point towards a solution: Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For example: 1> - add -D_WIN32_WINNT=0x0501 to the compiler command line; or 1> - add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions. 1> Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target). But I'm not sure what they mean. Regards, Alan. _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com

2 1