April 2007 - Boost-users - lists.boost.org

BGL: INTERNAL COMPILER ERROR in VC7.1
by Yariv Tal 10 Jun '07

10 Jun '07

This one was already posted by Nicholas Burlett awhile back (see http://lists.boost.org/MailArchives/boost-users/msg06534.php) but I have some new info that may help. The problem: ========= When compiling code that uses the boost.graph library the VC7.1 compiler shouts: c:\boost_1_32_0\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(48) : fatal error C1001: INTERNAL COMPILER ERROR As Nicholas already noted, this seems to be due to some compiler problem with the boost.graph out_edge_iterators since it is caused by the following lines in my code: (FilteredGraphGenerator::FilteredGraph is a typedef of a boost::filtered_graph) typedef boost::graph_traits<FilteredGraphGenerator::FilteredGraph> ::out_edge_iterator oedge_iterator; oedge_iterator edgesItr, edgesEnd; boost::tie(edgesItr, edgesEnd) = boost::out_edges(itr->first, m_g.m_filteredGraph); while (edgesItr != edgesEnd) { // do anything! } In fact, it seems to be related to the operator!= between iterators (if the while loop is commented out it compiles). How ever, the error persists even after changing the operator!= to operator== : while (edgesItr == edgesEnd) { // do anything! } ========================================================================== Some findings: =========== * We used to use boost_1_30_0 and the code used to compile PERFECTLY. The problem only appeared after migrating to boost_1_32_0. * Calling directly to the "equal" function in iterator_core_access instead of the operator== works. typedef boost::graph_traits<FilteredGraphGenerator::FilteredGraph> ::out_edge_iterator oedge_iterator; oedge_iterator edgesItr, edgesEnd; boost::tie(edgesItr, edgesEnd) = boost::out_edges(itr->first,m_g.m_filteredGraph); while (boost::iterator_core_access::equal(edgesItr, edgesEnd, boost::mpl::true_())) { // do somthing } * The error message location is at the mpl::apply_wrap2 function. Any relation to the mpl::apply2 function used for declaring the operator== in the BOOST_ITERATOR_FACADE_INTEROP_HEAD macro? Have these functions changed since v1.30.0?

9 8

BOOST: interprocess library
by dhruva 29 May '07

29 May '07

Hi, I would like to know if the "interprocess" library can work with STL packaged with Visual Studio. My current understanding is that "interprocess" uses a modified STL to use shared memory and this is packaged with "interprocess". Since a lot of code we have uses STL from VS (MS Visual Studio), mixing might not be an option. Is there a clean workaround path or is it a known limitation? with best regards, dhruva -- Dhruva Krishnamurthy Contents reflect my personal views only!

2 1

[BGL-Python] __len__ and __iter__ for property maps
by George Sakkis 21 May '07

21 May '07

I'm trying to build BGL-Python from SVN. I managed to build it successfully on Windows (VC 8.0) but I'm having problems with gcc 3.4 on Linux; although it does compile, it doesn't expose in Python two property map methods, __len__ and __iter__. I think I narrowed it down to the non-selection of a template specialization: // boost/graph/python/property_map.hpp namespace boost { namespace graph { namespace python { namespace detail { / * skip other stuff */ template<typename Class, typename T, typename IndexMap> void property_map_extras(Class& pm, type<vector_property_map<T, IndexMap> >) { pm.def("__len__", &py_vector_property_map_length<T, IndexMap>); typedef typename std::vector<T>::iterator value_iterator; simple_python_iterator<value_iterator>::declare("ValueIterator"); pm.def("__iter__", &py_vector_property_map_values<T, IndexMap>); } template<typename Class, typename PropertyMap> inline void property_map_extras(Class&, type<PropertyMap>) { } } // end namespace detail */ So for __len__ and __iter__ to be included, the first overloading of property_map_extras must be called. That's what happens with VC 8.0 (in fact I can remove the second empty function and compiles just fine), but gcc selects the second one. Can anyone help and/or reproduce it ? Thanks, George

2 1

boost in a mixed CLR assemby
by Daniel J. Kelly 09 May '07

09 May '07

I realize it is not officially supported, but has anyone had success using boost libraries in a mixed CLR assembly? I am using visual studio 2005. I have been trying to accomplish this in an applicatation that has a Windows Forms front end, whose enire back end is build of libraries written in standard C++, making extensive use of boost, especially smart pointers and threads. The specific problem I am having involved initializing static variables. For instance, I have a global variable: boost::mutex osmutex; The program compiles and links fine, but during static initialization, I receive an error indicating _CrtIsValidHeapPointer(pUserData) is invalid. Looking at the stack unwind, the calling code is the "dynamic initializer for 'osmutex'". My suspicion is that the boost library is linking to a different run time library than my mixed code, and that the pointer being rejected is happening as a result of it coming from a different heap. I would like try to check this hypothesis by building boost forcing it to link to the correct C++ runtime library used by mixed assemblies (msvcmrtd.dll), but I am not familar enough with the boost build system to do this.

4 3

[1.34.0] problem building bjam
by Dennis Jones 09 May '07

09 May '07

Hi, I tried reporting this over in the .devel group, but it seems to have been filtered out by the moderator, as it never got posted. However, I believe this is a problem that needs to be addressed. Can someone else confirm this? The build script for building bjam with a Borland compiler on Windows assumes the compiler root folder to be C:\Borland\BCC55. Since my system does not use the free command line Borland compiler (and thus does not use the default path), I specified "borland" as my toolset on the command line: c:> build.bat borland This effectively disables the assumed path and attempts to determine the actual path to the compiler. It successfully and correctly determines the path to be "C:\Program Files\Borland\CBuilder5\," but the script subsequently fails to build, giving the message: [COMPILE] bin.ntx86\bjam.exe Error E2194: Could not find file 'Files\Borland\CBuilder5\Bin\..\Include.cpp' Error E2194: Could not find file 'Files\Borland\CBuilder5\Bin\..\Lib.cpp' Just prior to the error, the following is visible: c:\source\3rdParty\boost\boost_1_34_0\tools\jam\src>.\bootstrap\jam0 -f build.jam --toolset=borland "--toolset-root=C:\Program Files\Borland\CBuilder5\Bin\..\ " Indicating that a path containing spaces ("Program Files") apparently confuses the script. My solution to this problem was to create a path corresponding to the assumed path (using linkd to create a junction-point so that I didn't have to re-install the compiler!) and let the script guess which toolset to use. Fortunately, it guesses correctly (borland as opposed to msvc) which results in the assumed path of "c:\borland\bcc55" which then works, thanks to my junction-point. While I was able to get around this problem fairly easily, it probably would have been more difficult if I were not using NTFS (and its support for junction points). I'm not certain, but I would expect this to be a problem for any compiler whose path contains a space -- or did I miss something that is already well-known and/or obvious? - Dennis

2 3

Building Boost 1.34.0 libraries with bjam
by Richard Hadsell 09 May '07

09 May '07

Options for building the Boost libraries with bjam seem to have changed from 1.33 to 1.34. At least, I can't be sure that the result will be the same. I looked at the 1.34.0 beta docs and the common.jam and gcc.jam files, but I am still unsure of what to do. I built the 1.33.x libraries this way: setenv PYTHON_VERSION 2.3 bjam -sTOOLS=gcc -sGCC_ROOT_DIRECTORY=/opt/gcc344 -sGXX="g++344 -m64" -sGCC="gcc344 -m64" --with-python-root=/usr --stagedir=stageFC3 -sBUILD="debug release <threading>multi <shared-linkable>true <instruction-set>opteron" stage Most of the options make it obvious what I want. The '<shared-linkable>true' option was necessary to add '-fPIC', which our binaries need in order to dynamically link (plug-in) shared libraries. I will appreciate any help you can offer in making the transition to 1.34.0 easier. BTW, it would be nice to see a list of available options for each toolset that comes with Boost bjam. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

7 10

Boost 1.34.0 Beta released
by Thomas Witt 08 May '07

08 May '07

The first beta of what will become version 1.34.0 is now available from http://www.boost.org. New Libraries * Foreach Library: BOOST_FOREACH macro for easily iterating over the elements of a sequence, from Eric Niebler. * Statechart Library: Arbitrarily complex finite state machines can be implemented in easily readable and maintainable C++ code, from Andreas Huber. * TR1 Library: An implementation of the C++ Technical Report on Standard Library Extensions, from John Maddock. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Highlights include: Reference Wrappers, Smart Pointers, result_of, Function Object Binders, Polymorphic function wrappers, Type Traits, Random Number Generators and Distributions, Tuples, Fixed Size Array, Hash Function Objects, Regular Expressions and Complex Number Additional Algorithms. * Typeof Library: Typeof operator emulation, from Arkadiy Vertleyb and Peder Holt. * Xpressive Library: Regular expressions that can be written as strings or as expression templates, and that can refer to each other and themselves recursively with the power of context-free grammars, from Eric Niebler. Updated Libraries * Assign Library: o Support for ptr_map<key,T> via the new function ptr_map_insert() o Support for initialization of Pointer Containers when the containers hold pointers to an abstract base class. * Date_time library: o Support for new US/Canada timezone rules and other bug fixes. See Change History for details. * Filesystem Library: Major upgrade in preparation for submission to the C++ Standards Committee for TR2. Changes include: o Internationalization, provided by class templates basic_path, basic_filesystem_error, basic_directory_iterator and basic_directory_entry. o Simplification of the path interface by eliminating special constructors to identify native formats. o Rationalization of predicate function design, including the addition of several new functions. o Clearer specification by reference to POSIX, the ISO/ IEEE Single Unix Standard, with provisions for Windows and other operating systems. o Preservation of existing user code whenever possible. o More efficient directory iteration. o Addition of a recursive directory iterator. * Function Library: Boost.Function now implements a small buffer optimization, which can drastically improve the performance when copying or constructing Boost.Function objects storing small function objects. For instance, bind(&X:foo, &x, _1, _2) requires no heap allocation when placed into a Boost.Function object. * Functional/Hash Library o Use declarations for standard classes, so that the library doesn't need to include all of their headers o Deprecated the <boost/functional/hash/*.hpp> headers. o Add support for the BOOST_HASH_NO_EXTENSIONS macro, which disables the extensions to TR1 o Minor improvements to the hash functions for floating point numbers. * Graph Library: o edmonds_maximum_cardinality_matching, from Aaron Windsor. o lengauer_tarjan_dominator_tree, from JongSoo Park. o compressed_sparse_row_graph, from Jeremiah Willcock and Douglas Gregor of Indiana University. o sorted_erdos_renyi_iterator, from Jeremiah Willcock of Indiana University. o biconnected_components now supports a visitor and named parameters, from Janusz Piwowarski. o adjacency_matrix now models the Bidirectional Graph concept. o dijkstra_shortest_paths now calls vis.initialize_vertex for each vertex during initialization. o Note: the name of the compiled library for the GraphViz reader has changed to boost_graph (from bgl-viz) to match Boost conventions. o See the complete revision history for more information. * MultiArray Library: Boost.MultiArray now by default provides range-checking for operator[]. Range checking can be disabled by defining the macro BOOST_DISABLE_ASSERTS before including multi_array.hpp. A bug in multi_array::resize() related to storage orders was fixed. * Multi-index Containers Library: o New random access indices. o Non key-based indices feature new rearrange facilities. o This version also includes a number of optimizations and usage improvements. For a complete list of changes, see the library release notes. * Optional Library: o boost::none_t and boost::none now added to Optional's documentation o Relational operators now directly support arguments of type 'T' and 'none_t' o operator->() now also works with reference types. o Helper functions make_optional(val), make_optional (cond,val) and get_optional_value_or(opt,alternative_value) added. o Constructor taking a boolean condition (as well as a value) added. o Member function get_value_or(alternative_value) added. o Incompatbility bug with mpl::apply<> fixed. o Converting assignment bug with uninitialized lvalues fixed. * Parameter Library: o Every ArgumentPack is now a valid MPL Forward Sequence. o Support for unnamed arguments (those whose keyword is deduced from their types) is added. o Support for named and unnamed template arguments is added. o New overload generation macros solve the forwarding problem directly. o See also the Python library changes, below. * Pointer Container Library: o Support for serialization via Boost.Serialization. o Exceptions can be disabled by defining the macro BOOST_PTR_CONTAINER_NO_EXCEPTIONS before including any header. This macro is defined by default if BOOST_NO_EXCEPTIONS is defined. o Additional std::auto_ptr<T> overloads added s.t. one can also pass std::auto_ptr<T> instead of only T* arguments to member functions. o transfer() now has weaker requirements s.t. one can transfer objects from ptr_container<Derived> to ptr_container<Base>, * Python Library: o Boost.Python now automatically appends C++ signatures to docstrings. The new docstring_options.hpp header is available to control the content of docstrings. o stl_input_iterator, for turning a Python iterable object into an STL input iterator, from Eric Niebler. o Support for void* conversions is added. o Integrated support for wrapping C++ functions built with the parameter library; keyword names are automatically known to docsstrings. * Signals Library: More improvements to signal invocation performance from Robert Zeh. * Smart Pointers Library: o Allocator support as proposed in N1851 (162 Kb PDF). o pointer_cast and pointer_to_other utilities to allow pointer-independent code, from Ion Gaztanaga. * String Algorithm Library: o lexicographical_compare o join o New comparison predicates is_less, is_not_greater. o Negative indexes support (like Perl) in various algorihtms (*_head/tail, *_nth). * Wave Library: o Wave now correctly recognizes pp-number tokens as mandated by the C++ Standard, which are converted to C++ tokens right before they are returned from the library. o Several new preprocessing hooks have been added. For a complete description please refer to the related documentation page: The Context Policy. o Shared library (dll) support has been added for the generated Wave libraries. o The overall error handling has been improved. It is now possible to recover and continue after an error or a warning was issued. o Support for optional comment and/or full whitespace preservation in the generated output stream has been added. o The Wave library now performs automatic include guard detection to avoid accessing header files more than once, if appropriate. o Full interactive mode has been added to the Wave tool. Now the Wave tool can be used just like Python or Perl for instance to interactively try out your BOOST_PP macros. Additionally it is now possible to load and save the current state of an interactive session (macro tables et.al.). o The overall performance has been improved by upto 40-60%, depending on the concrete files to process. o Support for new pragmas has been added allowing to control certain library features from inside the preprocessed sources (partial output redirection, control of generated whitespace and #line directives). o Optional support for #pragma message "..." has been added. o This version also includes a number of bug fixes and usage improvements. For a complete list of changes, see the libraries change log. Supported Compilers Boost is tested on a wide range of compilers and platforms. Since Boost libraries rely on modern C++ features not available in all compilers, not all Boost libraries will work with every compiler. The following compilers and platforms have been extensively tested with Boost, although many other compilers and platforms will work as well. For more information, see the regression test results. * Apple GCC 4.0.1 on Mac OS X. * Borland C++ 5.8.2 on Windows. * GNU C++ o 3.2.x., 3.3.x, 3.4.x, 4.0.x, 4.1.x on Linux o 4.1.x on Solaris o 3.4.x on Windows * HP aC++ A.06.14. * Intel C++ 9.1 on Windows, 9.0 on Linux. * Metrowerks CodeWarrior 9.4 on Windows. * Microsoft Visual C++ 6.0 (sp5, with and without STLport), 7.0, 7.1, 8.0. Note: Boost does not support the non-standard "Safe" C++ Library shipping with Visual C++ 8.0, which may result in many spurious warnings from Boost headers and other standards-conforming C++ code. To suppress these warnings, define the macro _SCL_SECURE_NO_DEPRECATE. * Sun Studio 11 on Solaris. Acknowledgements A great number of people contributed their time and expertise to make this release possible. Special thanks go to Vladimir Prus for making Boost.Build version 2 a reality, David Abrahams for authoring a new getting started guide and Greg D. for answering countless questions. -- Thomas Witt witt(a)acm.org

8 10

Build/install problems: BOOST 1_34 using VS.net
by dhruva 07 May '07

07 May '07

Hi, I am building BOOST using VS.net as follows (build goes fine): on the command prompt: cmd>bjam --toolset=msvc cmd>bjam --toolset=msvc --prefix=e:\boost install The installed libraries have "vc" instead of "vc71". The auto_link.hpp tries to link to libraries with "vc71". Is this a known issue? I try to build using the --layout=system as: cmd>bjam --toolset=msvc --layout=system cmd>bjam --toolset=msvc --layout=system install The copied libraries have libname-mt.lib (ex: boost_thread-mt.lib). To link with non-versioned plain libraries, I define BOOST_AUTO_LINK_NOMANGLE in the user.hpp. This tries to link with libname.lib (ex: boost_thread.lib) and that file will not be there. Is there something else I need to do or is it a known problem with this BETA? with best regards, dhruva -- Dhruva Krishnamurthy Contents reflect my personal views only!

5 5

[gil] channel_convert question
by Christian Henning 05 May '07

05 May '07

Hi there, what's the difference between the following two lines? float red_1 = channel_convert< bits32f >( 1.f ); float red_2 = channel_convert< bits32f >( (bits32f) 1.f ); The first gives me garbage whereas the second gives the correct result. Regards, Christian

1 1

[gil][bind] How to bind gil::at_c ?
by Christian Henning 05 May '07

05 May '07

Hi there my compiler doesn't like binding the gil::at_c function. I'm using MSVC 7.1 SP1. Please correct if I'm wrong but I think you need to supply a function pointer cast for overloaded function when using this compiler. But for some reasons I cannot make it happen. template < typename CHANNEL > void set_zero( CHANNEL c ) { c = 0; } int main() { rgb8_image_t src; bmp_read_image( ".\\flower.bmp", src ); typedef channel_type<rgb8_pixel_t>::type return_t; add_reference<return_t>::type (*AA)( rgb8_pixel_t& ) = &gil::at_c<0>; for_each( view( src ).begin() , view( src ).end() , bind( &set_zero, bind( AA, _1 ))); return 0; } compiler error is: \gil\repos\gil_2\libs\gil\toolbox\test.cpp(74) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'boost::add_reference<T>::type (__cdecl *)(boost::gil::rgb8_pixel_t &)' with [ T=boost::gil::bits8 ] None of the functions with this name in scope match the target type Thanks ahead, Christian

1 1