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

Re: [Boost-users] Welcome to the "Boost-users" mailing list
by liulewes 07 Feb '09

07 Feb '09

Dear there: I recently started to use the boost graph library and I got the following problem. I'v 2 projects A and B in my vc 7.1 solution. A uses boost graph lib while B is dependent on A. I'v no problem compiling A but got some errors in B like this: C:\Program Files\boost\boost_1_35_0\boost\graph\detail\adjacency_list.hpp(2292): error C2039: 'size_type' : is not a member of 'boost::vec_adj_list_impl<Graph,Config,Base>' with [ Graph=boost::adjacency_list<boost::vecS,boost::vecS,boost::undirectedS,boost::property<vmap_id_t,int,boost::property<boost::vertex_color_t,RGBColor,boost::property<vertex_feature_t,FeatureVector2D<double> *>>>,boost::property<boost::edge_weight_t,double>>, Config=boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS,boost::vecS,boost::undirectedS,boost::property<vmap_id_t,int,boost::property<boost::vertex_color_t,RGBColor,boost::property<vertex_feature_t,FeatureVector2D<double> *>>>,boost::property<boost::edge_weight_t,double>>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::retag_property_list<boost::vertex_bundle_t,boost::property<vmap_id_t,int,boost::property<boost::vertex_color_t,RGBColor,boost::property<vertex_feature_t,FeatureVector2D<double> *>>>>::type,boost::detail::retag_property_list<boost::edge_bundle_t,boost::property<boost::edge_weight_t,double>>::type,boost::no_property,boost::listS>::config, Base=boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS,boost::vecS,boost::undirectedS,boost::property<vmap_id_t,int,boost::property<boost::vertex_color_t,RGBColor,boost::property<vertex_feature_t,FeatureVector2D<double> *>>>,boost::property<boost::edge_weight_t,double>>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::retag_property_list<boost::vertex_bundle_t,boost::property<vmap_id_t,int,boost::property<boost::vertex_color_t,RGBColor,boost::property<vertex_feature_t,FeatureVector2D<double> *>>>>::type,boost::detail::retag_property_list<boost::edge_bundle_t,boost::property<boost::edge_weight_t,double>>::type,boost::no_property,boost::listS>::DirectedHelper ] and even like this: C:\Program Files\boost\boost_1_35_0\boost\pending\container_traits.hpp(150): error C2065: 'list' : undeclared identifier I think that I have all the standard headers included. Where mush I have been wrong? Thanks. _________________________________________________________________ MSN热搜榜，每天最In的信息资讯和热点排行让您一览无余！ http://top.msn.com.cn

2 1

[date_time] Timer anomolies on Windows
by Rush Manbert 07 Feb '09

07 Feb '09

I am trying to implement an accurate cross-platform timer with microsecond resolution. I would like to use the Boost date_time library to replace our current platform-specific code. One reason to do this is because we currently use the Code Audio framework timing services on the Mac and we would like to get away from that. In general, we want to statically link our executables. The current implementation uses the Core Audio framework on the Mac and the QueryPerformanceCounter() API on Windows. Our experience with the Windows code is that it doesn't perform well when measuring any interval less that about 500 msec. I have written a number of tests that get the number of performance counter ticks over various intervals. One test uses the GetTickCount() millisecond timer to measure the intervals. Another test just uses a for loop that increments a variable, because I was suspicious that the millisecond timer was jittery. I have found that the QueryPerformanceCounter() results are unreliable. One test ran tests of durations from 100 msec to 2000 msec and calculated the error between the number of ticks reported and the counter frequence returned by the API QueryPerformanceFrequency call. After getting that result, I wrote the same test that counts boost::posix_time::microsec_clock::local_time() ticks against the millisecond clock. I was initially surprised to see that the error between the counts reported by the API calls and the 1 megahertz expected frequency are nearly identical to the errors I calculated for QueryPerformanceCounter(). This led me to believe that the date_time microsec_clock implementation must be using the QueryPerformanceCounter interface. I have searched the sources, however, and I don't find anything that is Windows-specific. One other odd thing that my tests reveal. If I run a test that times its duration using the GetTickCount() millisecond timer, and calls either QueryPerformanceCounter() or uses microsec_clock to get the number of ticks seen during the interval I find that the values returned by QueryPerformanceCounter() are different for each test duration, as one would expect. Conversely, the tick counts calculated for microsec_clock are identical (with the value 15625) for 1 msec through 16msec. Then at 17 msec test duration, the tick count jumps to 31250. The same count gets reported through durations of 31 msec. At 32 msec the count jumps to 46875 and remains there through a test duration of 47 msec... This looks like the Boost microsec_clock tick count is only updating at 60 Hz. Obviously, I am very bewildered by these results. I would really appreciate it if anyone can enlighten me on the following: 1) On Windows, what API is actually being used to read the clock ticks? 2) Where is the platform-specific code that date_time uses to actually read the counters? 3) Is there really a 60 Hz update to the microsec_clock count value? Here is an example of one of my tests. This one is for the QueryPerformanceCounter() API. The Boost microsec_clock test is nearly identical: int WindowsPerformanceTimerResolutionSubTest (unsigned int testDurationInMillisecs) { LARGE_INTEGER startHighRes; LARGE_INTEGER endHighRes; DWORD start; if (0 == testDurationInMillisecs) { testDurationInMillisecs = 1; } // Sync to clock edge using GetTickCount() windowsSyncToClockEdgeOneMillisecond (); // Get our start time for the performance clock, and the millisecond clock QueryPerformanceCounter (&startHighRes); start = GetTickCount(); // Wait for the required duration while ((GetTickCount() - start) < testDurationInMillisecs) { // Nothing to do } //Get the microsec time at end of test QueryPerformanceCounter (&endHighRes); // Difference divided by number of seconds is ticks per second uint64_t diffTicks = endHighRes.QuadPart - startHighRes.QuadPart; return diffTicks; } Thanks, Rush

1 0

[intrusive] first impression and constant-time removal
by Erik Cassel 07 Feb '09

07 Feb '09

Hello, I like the intrusive library. I'm refactoring my code to use it in many places. One of the benefits of boost::intrusive is the constant-time removal of items from a collection. The documentation doesn't tell you how to remove an element from a list in constant time, so I looked through the API. At first, "remove" looked like a good idea, but this function removes all instances that match a given value - so it is O(n). The unwary programmer will inadvertently use this function, not realizing the huge waste of CPU time. >From what I can tell, the way to remove an element in constant time is this: if (element.is_linked()) list.remove(list.iterator_to(element)); It requires 3 function calls. How about adding the something like the following function to list? void remove_member(reference value) It might follow the same pattern as std::set's erase, which returns the erasure count (0 or 1) as a size_t. Summary: 1) I found the remove() function's name ambiguous. It isn't clear that the complexity is linear time - that it compares elements to a value rather than taking a reference to an actual element. The only hint is the const_reference (rather than a reference) argument. Would "remove_all_matches" would be a better name? 2) Removing an element from a list requires 3 function calls. Wouldn't an std::set-style erase(reference) be a good addition to the API? It could be called "remove_member" or simply "erase". 3) If nothing else, it might be wise to have a small section in the documentation that demonstrates constant-time element removal and warns against improper use of "remove". -Erik

3 7

Compilation problem with 1.37.0 on OS X
by Stephen Blinkhorn 07 Feb '09

07 Feb '09

Hello Boost people, I have problems compiling a project after upgrading to Boost 1.37.0 from an earlier version, dating back to July 08 ish. This is on Mac OS X 10.5.6, XCode 3.1 etc. Swapping back to my older Boost install resolves all problems. Errors: Precompiling /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ AppKit.framework/Headers/AppKit.h powerpc-apple-darwin9-gcc-4.0.1: installation problem, cannot exec '/ Developer/usr/bin/../libexec/gcc/powerpc-apple-darwin9/4.0.1/cc1obj': Argument list too long I don't understand why this causes problems, happens on two different machines after reinstalling GCC etc. Curious. Stephen

2 1

Problem with Iterator passing inside an index... a little complex...
by Rodrigo Dias Ferreira 06 Feb '09

06 Feb '09

Hi There, I am using the Boost.MultiIndex and I am facing a problem that I am try to resolving (debbuging) already about 20 hours... I think I get the problem isolated, but I don't know how to solve, and I don't know if this it is implemented. So I decided to make a example, it is a little big, but I put it as resumed as I could and post here in order to know if anyone could help me out. I will try to explain briefly here, I will copy the main() code right under the explanation, but the whole code of the example is in the end of the e-mail (with the classes and functions) If you want you could try to run too see what is the problem that I am talking about.) When I try to access an pair of iterators pair<propIt,propIt> that I stored inside a class (propertystream_h), somehow is changing to where the iterator points, I think it could be because the object which has originate (Graph) the index is created, stored in in a static index (which I call _graphRep) from the DynamicGraphs, passed to a handler (Graph_h), and then after the Graph goes out of scope it is destroyed. When the Graph_h._localGraph (copy of the iterator->Graph returned by the insertion in the _graphRep) access its member _globalProperties (which is an index containing the fields: {string _key, string _value, propertystream_h _props} from the struct globalPropSchema) through a iterator (let's call it: gpit), then it is fine. But then when I try to access through the gpit->_props._propRangeIt.first, the iterator of the propertystream_h (_propRangeIt.first), then the iterators, some how are messed up. ( -> in this example it points to last element, and then when I get next, never finds the end(). (sometimes it return some trash, sometimes I get segmentation fault). So I would like to know why it is messing with the iterator? And how could I solve this problem? that's it, best regards, Rodrigo P.S.: I hope someone can help me... copy of the main(): int main(){ DynamicGraphs dg; Graph_h graph_h; propertystream_h propS; property_h prop_h; GlobalPropIterator gpit; GlobalProp_h gp_h; propertystream_h ps_h; property_h p_h; graph_h = dg.createGraph("COI:0351-123-4555"); if (!graph_h) cout << "Unsuccessful creation!"<<endl; else cout << "Successful creation!" <<endl; //It works, because it takes from the _localPropRep, and it passes it as value!!! ps_h = graph_h->lookupLocalProp("name"); while(!ps_h.end()){ cout << "LocalProperties: "; p_h=ps_h.next(); cout << "Key: " << p_h.key() << " Value: " << p_h.value() <<endl; } // It does not work, because is accessing the propertystream_h from // the _globalPropRep (index of the tuple // {string globalkey, string value, propertystream_h props} // the propertystream_h it has as member a pair of iterators for another index. // -> after a lot of debugging (about 16h) OI found out that // it seems that during the creation of a graph, // when it passes the graph to graph_h, and goes out of scope, it keep the // iterator reference to the first element, but just that... the next // gives me segmentation fault. Anyone knows how to pass the graph and the its members // the indexes-repositories as value, so it would not depend on the pointing to // the graph that was freed from the memory? gpit = graph_h->properties("*"); if (!gpit) cout << "Not found any property in the globalProperties Repository."<<endl; else{ int i=0; while (!gpit.end()) { gp_h = gpit.next(); cout << "While_1::Iteration_" << ++i << endl; cout << "GlobalProperty key: " << gp_h.key() << endl; cout << "GlobalProperty value: " << gp_h.value() << endl; ps_h = gp_h.propertyStreamHandler(); int j = 0; while (!ps_h.end()){ p_h = ps_h.next(); cout << "While_2::Iteration" << ++j << endl; cout << "GlobalProperty::PropertyStream: key " << p_h.key() << endl; cout << "GlobalProperty::PropertyStream: value " << p_h.value() << endl; } } } } Here it is the code: /* * IndexProblem.cpp * * Created on: Feb 6, 2009 * Author: rodrigo */ #include <boost/multi_index_container.hpp> #include <boost/multi_index/hashed_index.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/composite_key.hpp> #include <boost/tuple/tuple.hpp> #include <boost/tokenizer.hpp> #include <boost/lambda/lambda.hpp> #include <climits> #include <iomanip> #include <iostream> #include <ctime> #include <string> #if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif using std::string; using std::pair; using std::ostream; using std::cout; using std::endl; using boost::multi_index_container; using namespace boost::multi_index; struct property { string _key; string _value; /// Default Constructor property(){} /// Constructor with parameters: initialize the name and graph property(string key, string value) : _key(key), _value(value) {} /// Copy Contructor property(const property &pm) : _key(pm._key), _value(pm._value) {} //For debugging TODO: delete later friend ostream& operator<<(ostream& os, const property &p){ os << "Key: " << p._key << " value: " << p._value << endl; return os; } }; /// Indexing in the data structure PropMap typedef multi_index_container< property, indexed_by< hashed_non_unique< BOOST_MULTI_INDEX_MEMBER(property, string, _key) > > > propIndex; typedef propIndex::iterator propIt; class property_h { private: /// Access to properties through the iterator propIt _pit; public: /// Default Constructor property_h(){} /// Constructor with Parameters: for lookup of Nodes property_h (const propIt &it) : _pit(it){} /// Constructor with Parameters: for lookup of Nodes property_h (const property_h &h) : _pit(h._pit){} /// Returns the key from the property being handled string key() const {return _pit->_key;} /// Returns the value from the property being handled string value() const {return _pit->_value;} }; class propertystream_h { /// _propRangeIt: for keeping a range in order to iterate over the graphs pair<propIt,propIt> _propRangeIt; /// _noMatches: true if there are no matches during the lookup function bool _noMatches; public: /// Default Constructor propertystream_h() : _noMatches(true){} /// Constructor with parameters for local lookup propertystream_h(pair<propIt,propIt> rangeIt, bool noMatches) : _propRangeIt(rangeIt), _noMatches(noMatches){ } /// Default Constructor propertystream_h(const propertystream_h &ps) : _propRangeIt(ps._propRangeIt), _noMatches(ps._noMatches){} // returns null_h on end of stream ... property_h next(){ return property_h(_propRangeIt.first++); } /// This function returns true whenever is the end of the stream bool end(){ return (_propRangeIt.first == _propRangeIt.second); } /// Overload operator!: shows if a creation was unsuccessful bool operator!(){ return _noMatches; } }; struct globalPropSchema{ string _key; string _value; propertystream_h _props; /// Default Constructor globalPropSchema() : _key(""), _value(""), _props(){} /// Parameter Constructor globalPropSchema(string k, string value, propertystream_h props) : _key(k), _value(value), _props(props){} /// Copy Constructor globalPropSchema(const globalPropSchema &gps) : _key(gps._key), _value(gps._value), _props(gps._props){} //TODO: Delete it: Debug friend ostream& operator<<(ostream &os, const globalPropSchema &gps){ os << "Key: " << gps._key << " Value: "<< gps._value << " PropertyStreamAdress: " << &gps._props <<endl; return os; } }; typedef multi_index_container< globalPropSchema, indexed_by< ordered_non_unique< composite_key< globalPropSchema, BOOST_MULTI_INDEX_MEMBER(globalPropSchema, string, _key), BOOST_MULTI_INDEX_MEMBER(globalPropSchema, string, _value) >, composite_key_compare< std::greater<string>, std::less<string> > > > > grobalProperties; /// Iterator for the data structure of the global properties index typedef grobalProperties::iterator globalPropIt; class GlobalProp_h{ private: /// Access to globalPropertiest items through the iterator globalPropIt _gpit; public: /// Default Constructor GlobalProp_h(){} /// Constructor with Parameters: for lookup of Nodes GlobalProp_h (const globalPropIt &it) : _gpit(it){} /// Copy Constructor GlobalProp_h (const GlobalProp_h &gph) : _gpit(gph._gpit){} /// Access to key of globalPropeties items string key(){ return _gpit->_key;} /// Access to value of globalPropeties items string value(){return _gpit->_value;} propertystream_h propertyStreamHandler(){ return _gpit->_props; } }; /// Iterator for the data structure of the global properties index typedef grobalProperties::iterator globalPropIt; class GlobalPropIterator{ private: /// _propRangeIt: for keeping a range in order to iterate over the graphs pair<globalPropIt,globalPropIt> _globalPropRangeIt; /// _noMatches: true if there are no matches during the lookup function bool _noMatches; public: /// Default Constructor GlobalPropIterator(){} /// Constructor with parameters for local lookup GlobalPropIterator(pair<globalPropIt,globalPropIt> rangeIt, bool noMatches) : _globalPropRangeIt(rangeIt), _noMatches(noMatches){} /// Default Constructor GlobalPropIterator(const GlobalPropIterator &gpi) : _globalPropRangeIt(gpi._globalPropRangeIt), _noMatches(gpi._noMatches){} // returns null_h on end of stream ... GlobalProp_h next(){ return GlobalProp_h(_globalPropRangeIt.first++); } /// This function returns true whenever is the end of the stream bool end(){ return (_globalPropRangeIt.first == _globalPropRangeIt.second); } /// Overload operator!: shows if a creation was unsuccessful bool operator!(){ return _noMatches; } }; class Graph { private: propIndex _localPropRep; /// Repository for the properties of the global properties related to the graph; grobalProperties _globalPropRep; public: // TODO: Really constructors /// Default Constructor Graph() {} /// Copy constructors Graph(const Graph &g) : _localPropRep(g._localPropRep), _globalPropRep(g._globalPropRep){} bool addProperty(string key, string value); GlobalPropIterator properties(string pattern) const; /// Function to lookup Local Properties propertystream_h lookupLocalProp(string pattern); friend class Graph_h; }; /// GraphMap: Data Structure for setting an index in the uniqueGraphName and retrieving handler Graph_h struct graphMap { string _name; Graph _graph; /// Default Constructor graphMap(){} /// Constructor with parameters: initialize the name and graph graphMap(string uniqueGraphName, Graph graph) : _name(uniqueGraphName), _graph (graph) {} /// Constructor with parameters: initialize the name and graph graphMap(const graphMap &gm) : _name(gm._name), _graph (gm._graph) {} }; ///ordered_unique Index in the data structure graph_hm typedef multi_index_container< graphMap, indexed_by< ordered_unique< BOOST_MULTI_INDEX_MEMBER(graphMap,string,_name) > > > graphIndex; /// Defing an iterator for the graphMapIndex typedef graphIndex::iterator graphIt; class Graph_h { private: /// \brief GraphIterator: Iterator pointing to the Graph graphIt _git; Graph _localGraph; bool _createSuccess; public: /// Default Constructor Graph_h() : _createSuccess(false) {} /// Constructor with Parameters: for creation of Graphs Graph_h ( pair<graphIt,bool> creation) : _git(creation.first), _createSuccess(creation.second){ _localGraph = creation.first->_graph; } /// Constructor with Parameters: for lookup of Graphs Graph_h (const graphIt &it) : _git(it), _createSuccess(false){ _localGraph = it->_graph; } /// Constructor with Parameters: for lookup of Graphs Graph_h (const Graph_h &h) : _git(h._git), _localGraph(h._localGraph), _createSuccess(h._createSuccess){} bool operator!(){ return !_createSuccess; } /// Operator-> overloading: allows access to graph members Graph* operator->() {return &_localGraph;} }; propertystream_h Graph::lookupLocalProp(string pattern){ pair<propIt,propIt> rangeIt; propIt rangeItfirst = _localPropRep.find(pattern); rangeIt.first = rangeItfirst; rangeIt.second = _localPropRep.end(); if (rangeIt.first != _localPropRep.end()) // second parameter means that the variable noMatches, so false in case that found the key return propertystream_h(rangeIt, false); else //No matches return propertystream_h(rangeIt, true); } GlobalPropIterator Graph::properties(string pattern) const{ pair<globalPropIt,globalPropIt> globalRangePropIt; bool noMatchesTmp=false; //Whole range if (!pattern.compare("*")){ globalRangePropIt.first = _globalPropRep.begin(); globalRangePropIt.second = _globalPropRep.end(); } if (globalRangePropIt.first == globalRangePropIt.second) noMatchesTmp = true; return GlobalPropIterator(globalRangePropIt, noMatchesTmp); } bool Graph::addProperty(string key, string value){ bool boolLocal, boolGlobal; pair <propIt,propIt> rangePropIt; string globalKey = "graph:"; globalKey.append(key); // "graph:namePorperty" boolLocal = _localPropRep.insert(property(key,value)).second; //Defining the whole range for iterate over the local properties rangePropIt.first = _localPropRep.begin(); rangePropIt.second = _localPropRep.end(); //Debug propIt it = rangePropIt.first; cout << "How it should be showed when accessing the iterator..."<<endl; while (rangePropIt.first != rangePropIt.second){ cout << "DEBUG@addProperty: " << *(rangePropIt.first++); } cout << endl; rangePropIt.first = it; //Debug boolGlobal = _globalPropRep.insert( globalPropSchema( globalKey, value, propertystream_h(rangePropIt, false) ) ).second; return (boolLocal && boolGlobal); } class DynamicGraphs { public: /// Data member to represent the graph repository (using ordered_unique index) static graphIndex _graphRep; Graph_h createGraph(string uniqueGraphName); }; graphIndex DynamicGraphs::_graphRep; /// Creation of Graph in DynamicGraphs Graph_h DynamicGraphs::createGraph(string uniqueGraphName){ Graph g; g.addProperty("name", uniqueGraphName); //Test g.addProperty("age", "Unknown"); g.addProperty("color", "blue"); return Graph_h( _graphRep.insert( graphMap( uniqueGraphName, g ) ) ); } int main(){ DynamicGraphs dg; Graph_h graph_h; propertystream_h propS; property_h prop_h; GlobalPropIterator gpit; GlobalProp_h gp_h; propertystream_h ps_h; property_h p_h; graph_h = dg.createGraph("COI:0351-123-4555"); if (!graph_h) cout << "Unsuccessful creation!"<<endl; else cout << "Successful creation!" <<endl; //It works, because it takes from the _localPropRep, and it passes it as value!!! ps_h = graph_h->lookupLocalProp("name"); while(!ps_h.end()){ cout << "LocalProperties: "; p_h=ps_h.next(); cout << "Key: " << p_h.key() << " Value: " << p_h.value() <<endl; } // It does not work, because is accessing the propertystream_h from // the _globalPropRep (index of the tuple // {string globalkey, string value, propertystream_h props} // the propertystream_h it has as member a pair of iterators for another index. // -> after a lot of debugging (about 16h) OI found out that // it seems that during the creation of a graph, // when it passes the graph to graph_h, and goes out of scope, it keep the // iterator reference to the first element, but just that... the next // gives me segmentation fault. Anyone knows how to pass the graph and the its members // the indexes-repositories as value, so it would not depend on the pointing to // the graph that was freed from the memory? gpit = graph_h->properties("*"); if (!gpit) cout << "Not found any property in the globalProperties Repository."<<endl; else{ int i=0; while (!gpit.end()) { gp_h = gpit.next(); cout << "While_1::Iteration_" << ++i << endl; cout << "GlobalProperty key: " << gp_h.key() << endl; cout << "GlobalProperty value: " << gp_h.value() << endl; ps_h = gp_h.propertyStreamHandler(); int j = 0; while (!ps_h.end()){ p_h = ps_h.next(); cout << "While_2::Iteration" << ++j << endl; cout << "GlobalProperty::PropertyStream: key " << p_h.key() << endl; cout << "GlobalProperty::PropertyStream: value " << p_h.value() << endl; } } } } -- ************************************************* Rodrigo Dias Ferreira Master Student of Computational Engineering Technische Universität Dresden - Germany Mobile Phone:+49 171 3158797 E-mail: rodrigodias(a)gmx.de ************************************************* Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

2 1

boost::interprocess::managed_mapped_file and cross arch?
by Ben Martin 06 Feb '09

06 Feb '09

Hi, Has anyone got any tips on using boost::interprocess::managed_mapped_file with the managed_mapped_file::segment_manager allocators and the boost/interprocess/containers in a memory mapped file which can be used across x64 and arm platforms? As everything should be using offset pointers, I get the feeling that there should be some way to make this cross platform utopia happen but thought I'd ask before serious tinkering attempts.

2 1

std::back_inserter() with move semantics?
by Robert Dailey 06 Feb '09

06 Feb '09

Hi, I'm currently using std::back_inserter on a ptr_vector, and the values being inserted are boost::unique_ptr's. back_inserter does simple assignment but I need it to call boost::move() on the thing being assigned (inserted). Does boost have an algorithm that can do this?

1 1

boost::bind
by Hansi 06 Feb '09

06 Feb '09

Hello, I have a problem using boost::bind (version 1.34.1). I don't know whot I make wrong but I think that I can use it in my case. Or I'm wrong? I use VS2005. in some external header file I have the declaration typedef void (* FUNCTION)(int ,void *); void SetCallback(FUNCTION cb); Now I want to call a function inside my class. Maybe with bind? I have tested the following: SetCallback(boost::bind<void>(boost::mem_fn(&Program::OnCallback),this,_1,_2)); but this does not work..have anyone an hint how I can do that? Regards Hansjörg

3 3

[ptr_container] ptr_map and cloning issues
by Robert Dailey 06 Feb '09

06 Feb '09

I have a ptr_map as follows: typedef boost::ptr_map<std::string, Texture> TextureContainer; I only use forward declarations of Texture where needed. When I'm iterating over an instance of TextureContainer, I expect to not have to do more than use the forward declaration since technically we're only iterating pointer values and the definition of Texture is not needed for this. So when I do this: TextureContainer myTextures; TextureContainer::const_iterator it = myTextures.find( "some key" ); The above (second line) results in an extremely complex and long compiler error, but the important part of the error says what I have pasted below. Why is this error happening? Is it trying to clone Texture objects? This shouldn't be happening. *boost/ptr_container/clone_allocator.hpp(34) : error C2514: 'rs::Texture' : class has no constructors C:\IT\work\planb\components\rs/renderer/TextureFwd.hpp(6) : see declaration of 'rs::Texture' C:\IT\work\planb\third_party\boost\1_37_0\boost/ptr_container/clone_allocator.hpp(55) : see reference to function template instantiation 'T *boost::new_clone<U>(const T &)' being compiled*

3 7

boost and std collisons in c++0x
by Ein Held 06 Feb '09

06 Feb '09

Hello I would like to know more about boost's general attitude towards c++0x and the collisions of boost with std. As of now, we move both, ::boost- and ::std-namesspace in the global namespace via using xxx. This is exactly what we want - boost and the stl are both such fundamental libraries that using an explicit namespace specifier everytime we want to use content of these namespaces is not accaptable. This would just blow the code and make it unreadable. Once we move up to c++0x, we will not be able to keep this way of coding up. ::std::tr1 is merged into ::std and so the former tr1 classes will collide with the boost ones if explicit namespace identifiers are missing. I would like to stress the fact that code, perfectly fine to the boost documentation, will fail to compiler most likely. #include <iostream> //This one might include <array> using namespace std; #include <boost/array.hpp> using namespace boost; array<int,1> blub; //fail Is there anything planned to prevent this happen? Thank you

6 8