March 2006 - Boost-users - lists.preview.boost.org

[multi_array] Resize changes storage order irreversibly
by Antonio Piccolboni 06 Mar '06

06 Mar '06

Hi, I noticed that after a resize the storage order is reset to the default value. This is apparent not only printing the contents (see attached test case) but also by inspecting strides() directly. Not only this breaks my program, but the only way to set the storage order is apparently in the constructor and therefore resize becomes de facto unusable for non default storage orders, so I don't even have a workaround. I couldn't find anything regarding this in the docs. I believe this is a serious bug. Can anyone advise? Antonio #include <boost/multi_array.hpp> #include <iostream> int main() { typedef boost::multi_array<double,3> array_type; int tiling_graph_storage_order[] = {2, 0, 1}; bool tiling_graph_index_order[] = {true, true, true}; array_type A(boost::extents[3][4][2], boost::general_storage_order<3>(tiling_graph_storage_order, tiling_graph_index_order)); for (int i = 0; i < 3; i++) { for (int j = 0; j < 4; j++) { for (int k = 0; k < 2; k++) { A[i][j][k] = 100 * i + 10 * j + k + 10000; } } } for (int i = 0; i < A.num_elements(); i++) { std::cout << *(A.origin() + i) << std::endl; } A.resize(boost::extents[3][4][2]); std::cout << "After resize" << std::endl; for (int i = 0; i < 3; i++) { for (int j = 0; j < 4; j++) { for (int k = 0; k < 2; k++) { std::cout << A[i][j][k] << std::endl; } } } }

2 2

Re: [Boost-users] How to organize my Unit Tests
by Dmitry Bufistov 06 Mar '06

06 Mar '06

> Mateusz Å�oskot wrote: > > >>3. Include Boost.Test source code and allow user of my project to build > >>UTF library on his own. Here I expect some problems with bjam/makefiles > >>incompatibility. So, bjam would be required on user's platform. > >>Simply, this solution seems to be quite confusing for user. > > > > Hello Mateusz, > > One obsevation concerning 3th approach for using boost.test framework. > > You just can include > > #include <boost/test/included/unit_test_framework.hpp> > > to your project and compile everything using your build system, isn't it? >Hi Dmitry, >But what about building Unit Test Framework library? >How should I provide building it? Using bjam (bjam would be requirement) >or own home-made makefiles for UTF? >Cheers It is for sure that I didn't build anything separate in boost (of cause exept the "date_time" library ) and things more or less work for me. I have just to projects in my solution - second is unit_test_framework and I doesn't link with external boost libraries. You can try to compile and execute the following code (without any external linking): Good luck! --dima // BOOST_TEST_TEST.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <boost/test/included/unit_test_framework.hpp> using namespace boost::unit_test; void test1_suit1() { BOOST_REQUIRE(false); } void test2_suit1() { BOOST_REQUIRE(false); } void test1_suit2() { BOOST_REQUIRE(false); } test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* master_test_unit = BOOST_TEST_SUITE("Master"); test_suite* ts_1 = BOOST_TEST_SUITE( "test_suite1" ); ts_1->add( BOOST_TEST_CASE( &test1_suit1), 1 ); ts_1->add( BOOST_TEST_CASE( &test2_suit1), 1 ); test_suite* ts_2 = BOOST_TEST_SUITE( "test_suite2" ); ts_2->add( BOOST_TEST_CASE( &test1_suit2), 1 ); /**Add test suites here in order to run them**/ master_test_unit->add(ts_1); master_test_unit->add(ts_2); return master_test_unit; }

2 1

How to organize my Unit Tests
by Mateusz Łoskot 06 Mar '06

06 Mar '06

Hi, I'd like to ask yet another questions related to Unit Test Framework usage. Especially, I'm interested in best practice of Unit Tests organization in the project. I have a project that consists of more than 100 classes. Some of those classes are general purpose (e.g. Point) but some are organized in components (e.g. spatial index component consisting of 5 classes). Now, I'd like to add Unit Tests (yes, I know I should have them prepared before I created those classes ;-)). I've read almost all docs about Boost.Test, downloaded from CVS. I know how to create Test Case and how to combine those cases into Test Suite. I also read introductory docs from "Tutorials and usage recommendations" part as well as I walked through unit_test_examples but I'm still a bit confused about the bigger picture. As far as I understand, every Test Case or Test Suite of cases is to be compiled to separate executable. Is this correct? So, unit_test_example_01.cpp and unit_test_example_02.cpp and so on create separate programs that can be executed e.g. from Visual Studio Post-Build Event as explained in docs. More precisely, every .cpp file that: - include #include <boost/test/unit_test.hpp> - uses defines cases using BOOST_AUTO_TEST_CASE - or defines suites of cases using BOOST_TEST_SUITE + BOOST_AUTO_TEST_CASE will be a separate program. Right? So, if I have 100 classes and I'd like to define Test Suite, with a number of Test Cases in every suite, for every my class then should I expect I will get 100 test executables? From Visual Studio point of view, I will have 100 projects in my test solution. Am I right? I feel I don't understand something, so I'd be very thankful for some light on this subject. So, what is the best way to organize Test Cases and Suites for my 100 classes? Should I try to build them into one executable or into number of separate executables as described in my assumptions above? If there are e.g. 100 executables for my 100 tests, how should I run them e.g. during complete rebuild of project using automake or bjam? Not using Visual Studio Post-Build Events, should I run those tests from makefiles/jamfiles or there is a kind of test runner program I can use? Best regards -- Mateusz Łoskot http://mateusz.loskot.net

3 3

Property map design
by Daniel Mitchell 06 Mar '06

06 Mar '06

I'd like to know a little more about the design rationale for property maps, specifically the (maybe implicit) decision not to overload operator[] with respect to constness. The design leads to a situation that is, in some respects, at odds with convention. The most obvious point of conflict is put_get_helper. In fact, I wouldn't be surprised if the decision not to overload operator[] was simply a consequence of writing put_get_helper. (Pure speculation.) template<class Reference, class PropertyMap> struct put_get_helper { }; template<class R, class P, class K> R get( put_get_helper<R,P> const& map, K const& key ); template<class R, class P, class K, class V> void put( put_get_helper<R,P> const& map, K const& key, V const& value ); In contrast with standard containers, the constness of the property map isn't correlated to the constness of its elements. I wonder why the above wasn't written as template<class Reference, class PropertyMap, class ConstReference> struct put_get_helper { }; template<class R, class P, class C, class K> R get( put_get_helper<R,P,C>& map, K const& key ); template<class R, class P, class C, class K> C get( put_get_helper<R,P,C> const& map, K const& key ); template<class R, class P, class C, class K, class V> void put( put_get_helper<R,P,C>& map, K const& key, V const& value ); Another point of conflict is the property_map traits class, with its nested 'type' and 'const_type'. Doesn't convention suggest that 'type const' is the appropriate type for a non-mutable property map? My initial statement was that the design leads to a situation that is *in some respects* at odds with convention. When property maps are viewed, not as first class containers of their data, but as having more-or-less the same status as container iterators, the situation clarifies. I suppose that must have been the author's intent. // A deficient, but harmless implementation of put(), get() for iterators. template<class Reference, class Iterator> struct put_get_helper { }; template<class R, class I, class K> R get( put_get_helper<R,I> const& it, K const& key ); template<class R, class I, class K, class V> void put( put_get_helper<R,I> const& it, K const& key, V const& value ); // Parallel to property_map. template<class Container> struct container_iterator { typedef typename Container::iterator type; typedef typename Container::const_iterator const_type; };

2 1

Linking problems with 'scoped_static_mutex_lock' from regex library?!
by Arno 06 Mar '06

06 Mar '06

Hi all, I have successfully build boost 1.33.1 on solaris 2.8 with SunStudio 10 with stlport and try now to build my application what was running with boost 1.31 on windows. I have had no problems during compiling my stuff all seems to be fine, but when I am linking I get some unreferenced symbols in my code what I didn't know, because I don't know, that I am using it. So the linker said, that he can't find 'boost::scoped_static_mutex_lock::~scoped_static_mutex_lock()' and 'boost::scoped_static_mutex_lock::scoped_static_mutex_loc(boost::static_mutex&,bool) '. After a littele bit of investigation I found the definition of this class in a Header 'regex/pending/static_mutex.hpp'. I link actualy the libraries 'libboost_regex-sw-1_33_1', 'libboost_thread-sw-mt-1_33_1' and 'libboost_date_time-sw-1_33_1' to my application have I to link something more or do I have to make something else to get these build running! Thanks for any help! regards Arno

2 1

Re: [Boost-users] Getting started with Boost: what did you need to know?
by Merrill Cornish 06 Mar '06

06 Mar '06

David, At the risk of annoying some Boost developers... My single biggest complaint is the Boost documentation-- not so much that the libraries are undocumented, but that it's so hard to find your way through the documentation that is provided. There is the documentation on the Boost site rooted under Libraries | Documentation. Then there is the documentation under doc/html in the Boost source tree. Then there is the documentation under libs/<libraryName>/doc in the source tree. Sometimes, they are the same, sometimes, the libs documentation has extra stuff. Why? A side effect of having HTML documentation is that there is no index--a valuable tool when you are trying find your way through new territory. The Boost documentation standard recommends having a table of contents-like list of topics on the first page of a library's documentation. Sounds good, but since there usually isn't any paragraphing levels shown, what you get is a list of topics, some of which repeat with no indication of which are subtopics of which. The naming of documentation files can be misleading also. The discussion of mutexes (with no specific mention of threads) is called "thread" while the discussion of threading (with no specific mention of mutexes) is call "threads" [note the plural]. Or, maybe it's the other way around. The available documentation takes a scatter gun approach at to the intended audience. Under mutexes (whatever its name), there is a treatise (as I remember) on all possible mutex alternatives. It's only later that the reader discovers none of them are actually implemented. Similarly, the serialization documentation has a long discussion on shared pointers in a file named shared_ptr.html. Another file named shared_ptr2.html starts out by saying that about the stuff you just read in shared_ptr.html "Unfortunately, this way of doing it suffered from some undesirable features." This is a lot like giving someone detailed driving directions only to say, "if you go this far, you've taken a wrong turn." The documentation is written so that in order to do almost anything, you have to read everything, including all of the "here are all the wrong turns I took in developing this library" pages. For example, the documentation for the serialization library seems straightforward, but you'll probably miss the special macro you are supposed to use if you are serializing an abstract class. The Boost documentation is serverly in the need of global editing. Merrill

4 4

[BGL] Why this is not compiled?
by Dmitry Bufistov 06 Mar '06

06 Mar '06

Hi all, I'm trying to compile the following code and have some compiler errors (MSVC 8). // TestBoostGraph1.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <string> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/adjacency_matrix.hpp> #include <boost/graph/graphviz.hpp> #include <boost/graph/iteration_macros.hpp> #include <boost/graph/graph_utility.hpp> #include <boost/graph/copy.hpp> ///Just for read "work around" ///Two typedefs for modeling both "discrete" & "continues" nets typedef int discret_net_t; typedef double continues_net_t; /// typedef enum {PLACE, TRANSITION} node_type_t; /*! * If you need some more properties, then you should define your property class that derived from * basic_vertex_properties<>; - for nodes, * basic_edge_properties<>; - for edges * Example: struct my_node_prop : basic_vertex_properties<discret_net_t> { typedef double node_delay_t; node_delay_t m_node_delay; }; typedef CPetriNet<adj_list, boost::vecS, boost::listS, boost::bidirectionalS, my_node_prop> petri_net_t * * The types of all property values must be Copy Constructible, Assignable and Default Constructible!! */ template <class T = discret_net_t> struct basic_vertex_properties { typedef std::string node_name_type; typedef int node_index_t; basic_vertex_properties(node_type_t nt = TRANSITION) : m_node_type(nt) { m_token_number = T(0);} T m_token_number; ///Only for place, possible costruct "continues" nets node_name_type m_node_name; node_type_t m_node_type; ///Vertex could be "Place" or "transition" node_index_t m_node_index;///Internal property for convenient vertices lookup }; ///Basic properties for edge template <class T = discret_net_t> struct basic_edge_properties { typedef int edge_index_t; basic_edge_properties(T ew = 0) : m_weight(ew) {} T m_weight; ///possible construct "continues" nets edge_index_t m_edge_index; ///Internal property for convenient vertices lookup; }; using boost::bidirectionalS; using boost::directedS; using boost::no_property; struct my_ver_p : public basic_vertex_properties<discret_net_t> { double m_node_delay; }; struct my_edge_p : public basic_edge_properties<discret_net_t> { double m_edge_delay; }; int _tmain(int argc, _TCHAR* argv[]) { typedef boost::adjacency_list<boost::listS, boost::listS, directedS, my_ver_p> adj_list1_t; adj_list1_t c(10); boost::property_map<adj_list1_t, my_ver_p::node_name_type my_ver_p::* >::type node_name_map1(boost::get(&my_ver_p::m_node_name, c)); boost::print_graph(c, node_name_map1) ; return 0; } 1>------ Build started: Project: TestBoostGraph1, Configuration: Debug Win32 ------ 1>Compiling... 1>TestBoostGraph1.cpp 1>d:\documents and settings\dmitry\my documents\visual studio 2005\projects\testboostgraph1\testboostgraph1\testboostgraph1.cpp(78) : error C2664: 'boost::bundle_property_map<Graph,Descriptor,Bundle,T>::bundle_property_map(const boost::bundle_property_map<Graph,Descriptor,Bundle,T> &)' : cannot convert parameter 1 from 'boost::bundle_property_map<Graph,Descriptor,Bundle,T>' to 'const boost::bundle_property_map<Graph,Descriptor,Bundle,T> &' 1> with 1> [ 1> Graph=adj_list1_t, 1> Descriptor=void *, 1> Bundle=my_ver_p, 1> T=basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> and 1> [ 1> Graph=boost::adjacency_list<boost::listS,boost::listS,boost::directedS,my_ver_p>, 1> Descriptor=boost::detail::edge_desc_impl<boost::directed_tag,void *>, 1> Bundle=basic_vertex_properties<discret_net_t>, 1> T=basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> and 1> [ 1> Graph=adj_list1_t, 1> Descriptor=void *, 1> Bundle=my_ver_p, 1> T=basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> Reason: cannot convert from 'boost::bundle_property_map<Graph,Descriptor,Bundle,T>' to 'const boost::bundle_property_map<Graph,Descriptor,Bundle,T>' 1> with 1> [ 1> Graph=boost::adjacency_list<boost::listS,boost::listS,boost::directedS,my_ver_p>, 1> Descriptor=boost::detail::edge_desc_impl<boost::directed_tag,void *>, 1> Bundle=basic_vertex_properties<discret_net_t>, 1> T=basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> and 1> [ 1> Graph=adj_list1_t, 1> Descriptor=void *, 1> Bundle=my_ver_p, 1> T=basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called 1>TestBoostGraph1 - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== if change graph representation to following typedef boost::adjacency_list<boost::listS, boost::listS, directedS, basic_vertex_properties<> > adj_list1_t; then this compiles without any error: adj_list1_t c(10); boost::property_map<adj_list1_t, basic_vertex_properties<>::node_name_type basic_vertex_properties<>::* >::type node_name_map1(boost::get(&basic_vertex_properties<>::m_node_name, c)); but with this I again have some error (just change "type" to "const_type" adj_list1_t c(10); boost::property_map<adj_list1_t, basic_vertex_properties<>::node_name_type basic_vertex_properties<>::* >::const_type node_name_map1(boost::get(&basic_vertex_properties<>::m_node_name, c)); 1>------ Build started: Project: TestBoostGraph1, Configuration: Debug Win32 ------ 1>Compiling... 1>TestBoostGraph1.cpp 1>d:\documents and settings\dmitry\my documents\visual studio 2005\projects\testboostgraph1\testboostgraph1\testboostgraph1.cpp(79) : error C2664: 'boost::bundle_property_map<Graph,Descriptor,Bundle,T>::bundle_property_map(const boost::bundle_property_map<Graph,Descriptor,Bundle,T> &)' : cannot convert parameter 1 from 'boost::bundle_property_map<Graph,Descriptor,Bundle,T>' to 'const boost::bundle_property_map<Graph,Descriptor,Bundle,T> &' 1> with 1> [ 1> Graph=const adj_list1_t, 1> Descriptor=void *, 1> Bundle=basic_vertex_properties<discret_net_t>, 1> T=const basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> and 1> [ 1> Graph=adj_list1_t, 1> Descriptor=void *, 1> Bundle=basic_vertex_properties<discret_net_t>, 1> T=basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> and 1> [ 1> Graph=const adj_list1_t, 1> Descriptor=void *, 1> Bundle=basic_vertex_properties<discret_net_t>, 1> T=const basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> Reason: cannot convert from 'boost::bundle_property_map<Graph,Descriptor,Bundle,T>' to 'const boost::bundle_property_map<Graph,Descriptor,Bundle,T>' 1> with 1> [ 1> Graph=adj_list1_t, 1> Descriptor=void *, 1> Bundle=basic_vertex_properties<discret_net_t>, 1> T=basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> and 1> [ 1> Graph=const adj_list1_t, 1> Descriptor=void *, 1> Bundle=basic_vertex_properties<discret_net_t>, 1> T=const basic_vertex_properties<discret_net_t>::node_name_type 1> ] 1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called 1>TestBoostGraph1 - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== What is wrong here? Any help would be greatly appreciated, Thanks in advance, --dima // TestBoostGraph1.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <string> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/adjacency_matrix.hpp> #include <boost/graph/graphviz.hpp> #include <boost/graph/iteration_macros.hpp> #include <boost/graph/graph_utility.hpp> #include <boost/graph/copy.hpp> ///Just for read "work around" ///Two typedefs for modeling both "discrete" & "continues" nets typedef int discret_net_t; typedef double continues_net_t; /// typedef enum {PLACE, TRANSITION} node_type_t; /*! * If you need some more properties, then you should define your property class that derived from * basic_vertex_properties<>; - for nodes, * basic_edge_properties<>; - for edges * Example: struct my_node_prop : basic_vertex_properties<discret_net_t> { typedef double node_delay_t; node_delay_t m_node_delay; }; typedef CPetriNet<adj_list, boost::vecS, boost::listS, boost::bidirectionalS, my_node_prop> petri_net_t * * The types of all property values must be Copy Constructible, Assignable and Default Constructible!! */ template <class T = discret_net_t> struct basic_vertex_properties { //typedef node_type_t my_node_type; typedef std::string node_name_type; typedef int node_index_t; basic_vertex_properties(node_type_t nt = TRANSITION) : m_node_type(nt) { m_token_number = T(0);} T m_token_number; ///Only for place, possible costruct "continues" nets node_name_type m_node_name; node_type_t m_node_type; ///Vertex could be "Place" or "transition" node_index_t m_node_index;///Internal property for convenient vertices lookup }; ///Basic properties for edge template <class T = discret_net_t> struct basic_edge_properties { typedef int edge_index_t; basic_edge_properties(T ew = 0) : m_weight(ew) {} //private: T m_weight; ///possible construct "continues" nets edge_index_t m_edge_index; ///Internal property for convenient vertices lookup; }; using boost::bidirectionalS; using boost::directedS; using boost::no_property; struct my_ver_p : public basic_vertex_properties<discret_net_t> { double m_node_delay; }; struct my_edge_p : public basic_edge_properties<discret_net_t> { double m_edge_delay; }; int _tmain(int argc, _TCHAR* argv[]) { //typedef boost::adjacency_list<boost::listS, boost::listS, directedS, my_ver_p> adj_list1_t; typedef boost::adjacency_list<boost::listS, boost::listS, directedS, basic_vertex_properties<> > adj_list1_t; adj_list1_t c(10); boost::property_map<adj_list1_t, basic_vertex_properties<>::node_name_type basic_vertex_properties<>::* >::const_type node_name_map1(boost::get(&basic_vertex_properties<>::m_node_name, c)); boost::print_graph(c, node_name_map1) ; return 0; }

3 2

Resolving TR1/Boost conflicts
by Scott Meyers 06 Mar '06

06 Mar '06

Is there a Boost policy on resolving conflicts between Boost behavior and the TR1 spec? As an example, std::tr1::is_base_of<T, T> returns true, but boost::is_base_of<T, T> returns false. Changing Boost behavior would presumably break existing code, but failing to implement TR1 semantics is likely to be confusing/surprising to many. My understanding is that Boost is committed to bringing its TR1-like libraries into conformance with TR1, but it'd be helpful if people who follow Boost more closely than I could confirm that. Thanks, Scott

2 1

Newbie Build Problem - Debug Assertion Failed
by Eric Hill 06 Mar '06

06 Mar '06

New install of Visual C++ 2005 Express New install of the Platform SDK New download of boost-jam-3.1.12 I get the attached error when the build script tries to launch jam0. Any ideas? Reinstall something maybe? Eric --- Begin Build Log --- C:\boost-jam-3.1.12>build Setting environment for using Microsoft Visual Studio 2005 x86 tools. ### ### Using 'vc8' toolset. ### C:\boost-jam-3.1.12>rd /S /Q bootstrap C:\boost-jam-3.1.12>md bootstrap C:\boost-jam-3.1.12>cl /nologo /RTC1 /Zi /MTd -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib /Febootstrap\jam0 [snipped] command.c compile.c debug.c execnt.c expand.c filent.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c Generating Code... Compiling... regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c w32_getreg.c native.c set.c path.c regex.c property-set.c sequence.c Generating Code... Compiling... order.c Generating Code... C:\boost-jam-3.1.12>.\bootstrap\jam0 -f build.jam --toolset=vc8 "--toolset-root=C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\ " clean

2 2

[multi_array] How to use std algorithms, like for_each?
by Christian Henning 06 Mar '06

06 Mar '06

Hi there, I'm a little confused by the documentation of the multi_array lib. The begin() is supposed to return an iterator, but dereferencing doesn't resolve into the value type. This makes it a little complicated to use multi_arrays with standard algorithms. Please consider the following code snippet which wont compile on VC 7.1. class tVoxel { public: typedef short tValue; tVoxel(): _oValue( 0 ) {} tVoxel(tValue oValue): _oValue( oValue ) {} void set( const tValue& oValue ) { _oValue = oValue; } tValue& get() { return _oValue; } const tValue& get() const { return _oValue; } private: tValue _oValue; }; int _tmain(int argc, _TCHAR* argv[]) { typedef boost::multi_array<tVoxel, 3> tVolume; tVolume oVolume( boost::extents[3][3][3] ); tVolume::const_iterator iVoxel = oVolume.begin(); tVolume::const_iterator iVoxelEnd = oVolume.end(); const tVoxel& oVoxel = iVoxel->get(); return 0; } The error message goes like: error C2039: 'get' : is not a member of 'boost::detail::multi_array::const_sub_array<T,NumDims>' with [ T=tVoxel, NumDims=2 ] Do I miss something important, here? Thanks for your help, Christian

2 1