September 2006 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Bugs-1567829 ] Memory leaks with signal::connect?
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567829, was opened at 2006-09-29 11:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567829&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: signals Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Memory leaks with signal::connect? Initial Comment: Hello, I'm sending this message a second time (I didn't receive any response and still have this problem) I'm using boost::bind and boost::signal with VC6. VC6 is detecting some memory leak for a certain type of signal.connect(). I've done a little test program to check if the problem was due to some bug or special configuration in my main program, but the memory leaks are still detected in the test situation. Let me explain the structure of my test program. I have a main, and in the main, an object CCloneAppRecipe named clone. The class CCloneAppRecipe contains a member m_PtrTestMem (a shared pointer, but a raw point or an object does the same thing) of the class CTestMem. CTestMem contains 3 instances of the class CTestTab, and the class CTestTab contains a boost signal typedef boost::signal0<void> TypeSignalTest; TypeSignalTest m_SignalTest; In my main, I invoke clone.connectPtrTestMem(). clone.connectPtrTestMem() then invokes CTestMem::ConnectSignalTriplePtrTab(boost::bind (&CloneAppRecipe::test, this)); ConnectSignalTriplePtrTab() then invokes ConnectSignal (TypeSignalTest::slot_type slot) for each of the 3 instances of the class it contains. ConnectSignal then calls m_SignalTest.connect(slot). And I have a memory leak: 2 blocks of 16 bytes. If I connect only one instance of CTestTab, no leak. Two instances, one leak of 16 bytes. Three, two leaks of 16 bytes, and so on. I connect the m_SignalTest with a CCloneAppRecipe's slot. If I connect it to a CTestMem slot, I have no leak. Or if I place 3 instances of CTestTab directly in the CCloneAppRecipe class (so I don't use CTestMem anymore), I have no leak. But that's not what I need to do. I've tested plenty of variations (shared_pointer or object, etc.) Does anybody have a clue. Thanks #include "stdafx.h" #include "CloneAppRecipe.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif int main() { CloneAppRecipe t; // cree un leak t.connectPtrTestMem(); getchar(); return 0; } void CloneAppRecipe::connectPtrTestMem() { //m_ptrTestMem is a boost::shared_ptr m_ptrTestMem->ConnectSignalTriplePtrTab(boost::bind (&CloneAppRecipe::test, this)); } void CloneAppRecipe::test() const { } void CTestMem::ConnectSignalTriplePtrTab(const TypeSignaTest::slot_type& slot) { //m_ptrTestTab are boost::shared_ptr m_ptrTestTab1->ConnectSignal(slot); m_ptrTestTab2->ConnectSignal(slot); m_ptrTestTab3->ConnectSignal(slot); } void CTestTab::ConnectSignal(const TypeSignalTest::slot_type& slot) { m_SignalTest->connect(slot); } CTestTab::~CTestTab() { m_SignalTest->disconnect_all_slots(); } here is my complete test program. // TestMemBis.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include "CloneAppRecipe.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif int main() { CloneAppRecipe t; // cree un leak t.connectPtrTestMem(); getchar(); return 0; } // CloneAppRecipe.h: interface for the CloneAppRecipe class. // ////////////////////////////////////////////////////////////////// //// #if !defined(AFX_CLONEAPPREC__INCLUDED_) #define AFX_CLONEAPPREC__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #include "TestMem.h" class CloneAppRecipe { public: CloneAppRecipe(); ~CloneAppRecipe(); private: // desactive constructeur copie et operateur= CloneAppRecipe( const CloneAppRecipe& rhs ); CloneAppRecipe& operator=( const CloneAppRecipe& rhs ); // slot pour connecter void test() const; public: void connectPtrTestMem(); boost::shared_ptr<TestMem> m_ptrTestMem; }; #endif // CloneAppRecipe.cpp: implementation of the CloneAppRecipe class. // ////////////////////////////////////////////////////////////////// //// #include "stdafx.h" #include "CloneAppRecipe.h" #include "TestTab.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif CloneAppRecipe::CloneAppRecipe() : m_ptrTestMem( new TestMem() ) { } CloneAppRecipe::~CloneAppRecipe() { } void CloneAppRecipe::test() const { } void CloneAppRecipe::connectPtrTestMem() { m_ptrTestMem->ConnectSignal(boost::bind (&CloneAppRecipe::test, this)); } // TestMem.h: interface for the TestMem class. // ////////////////////////////////////////////////////////////////// //// #if !defined(AFX_TESTMEM__INCLUDED_) #define AFX_TESTMEM__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 class TestTab; class TestMem { public: typedef boost::signal0<void> TypeSignalTest; TestMem(); ~TestMem(); void ConnectSignal(const TypeSignalTest::slot_type& slot) const; private: // desactive constructeur copie et operateur= TestMem( const TestMem& rhs ); TestMem& operator=( const TestMem& rhs ); boost::shared_ptr<TestTab> m_ptrTestTab1; boost::shared_ptr<TestTab> m_ptrTestTab2; boost::shared_ptr<TestTab> m_ptrTestTab3; }; #endif // !defined (AFX_VISIONPARAMTABMANAGER_H__F0F26B98_D7D0_489E_AD5F_0D DEBF9A2D4F__INCLUDED_) // TestMem.cpp: implementation of the TestMem class. // ////////////////////////////////////////////////////////////////// //// #include "stdafx.h" #include "TestMem.h" #include "TestTab.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif TestMem::TestMem() : m_ptrTestTab1( new TestTab() ), m_ptrTestTab2( new TestTab() ), m_ptrTestTab3( new TestTab() ) { } TestMem::~TestMem() { } void TestMem::ConnectSignal(const TypeSignalTest::slot_type& slot) const { m_ptrTestTab1->ConnectSignal(slot); m_ptrTestTab2->ConnectSignal(slot); m_ptrTestTab3->ConnectSignal(slot); } // VisionParamGenericTab.h: interface for the CVisionParamGenericTab class. // ////////////////////////////////////////////////////////////////// //// #if !defined(AFX_TEST_TAB) #define AFX_TEST_TAB #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 typedef boost::signal0<void> TypeSignalTest; class TestTab { public: TestTab(); ~TestTab(); void ConnectSignal(const TypeSignalTest::slot_type& slot); private: // desactive constructeur copie TestTab( const TestTab& rhs ); TestTab& operator=( const TestTab& rhs ); TypeSignalTest m_SignalTest; }; #endif // TestTab.cpp: implementation of the TestTab class. // ////////////////////////////////////////////////////////////////// //// #include "stdafx.h" #include "TestTab.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif TestTab::TestTab() { } TestTab::~TestTab() { m_SignalTest.disconnect_all_slots(); } void TestTab::ConnectSignal(const TypeSignalTest::slot_type& slot) { m_SignalTest.connect(slot); } // stdafx.h : include file for standard system include files, // or project specific include files that are used frequently, but // are changed infrequently // #if !defined (AFX_STDAFX_H__4BC26E01_A411_43B7_9129_B453770CBE84__INCLU DED_) #define AFX_STDAFX_H__4BC26E01_A411_43B7_9129_B453770CBE84__INCLU DED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers #include <stdio.h> #include <afx.h> #include "CloneGeneral.h" #include "BoostIInclude.h" #endif // !defined (AFX_STDAFX_H__4BC26E01_A411_43B7_9129_B453770CBE84__INCLU DED_) CloneGeneral.h #define AFX_GENERAL_H__F3520E35_333F_11D5_A855_000103C25D02__INCL UDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 //#define for if (1) for // TODO_PASSAGE_6.0_8.0 #define BOOST_NO_INTRINSIC_WCHAR_T // requis parce que BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) // est défini 2 fois sinon et ca ne compile pas. // disable auto-linking for Boost #define BOOST_ALL_NO_LIB #endif // !defined (AFX_GENERAL_H__F3520E35_333F_11D5_A855_000103C25D02__INC LUDED_) BoostIInclude.h #if !defined (AFX_SVBOOSTBIND_H__F3520E35_333F_11D5_A855_000103C25D02_ _INCLUDED_) #define AFX_SVBOOSTBIND_H__F3520E35_333F_11D5_A855_000103C25D02__ INCLUDED_ #pragma warning(push,1) #include "boost/bind.hpp" #include "boost/signal.hpp" #include "boost/shared_ptr.hpp" #pragma warning(pop) #ifdef _DEBUG #pragma comment(lib, "libboost_signals-vc6-mt-gd.lib") #else #pragma comment(lib, "libboost_signals-vc6-mt.lib") #endif #endif // !defined (AFX_SVBOOSTBIND_H__F3520E35_333F_11D5_A855_000103C25D02_ _INCLUDED_) _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567829&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1567828 ] Memory leaks in adjacency_list?
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567828, was opened at 2006-09-29 11:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567828&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Memory leaks in adjacency_list? Initial Comment: Hello, I've been in fight with memory leaks in my application for some days. And now I found that most memory is losing while using adjacency_list<> (boost 1.33.1 + VC++6.0). Basically we've lost about 100Kb after each graph life cycle (created - changed - removing). Moreover, I guess, I found the similar problem on the very simple test: #include "..\boost_1_33_1\boost\graph\adjacency_list.hpp" using namespace boost; typedef adjacency_list<> Graph; void main() { int num_vertex = 10000; Graph* graph = new Graph(); for(int j=0; j<num_vertex; ++j) { add_vertex(graph); } delete graph; } Here I've lost some memory too (about 20 Kb). Maybe I'm doing something wrong? Thanks _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567828&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1567821 ] Const correctness violation
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567821, was opened at 2006-09-29 11:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567821&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: function Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Const correctness violation Initial Comment: Boost.Function does not preserve const correctness for reference wrappers e.g. class function_object_type { public: void operator()() const {} }; void f() { const function_object_type const_function_object; boost::function<void()> function(boost::ref(const_function_object)); assert(function.target<function_object>() == &const_function_object); //const lost } I can see two possible solutions for this: add a flag: enum cv_qualifiers { const_ = 1, volatile_ = 1 << 1}; or don't unwrap references for target: function.target<boost::reference_wrapper<function_object> >() The first method seems preferable because it doesn't require the interface to change. In Christ, Steven Watanabe ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567821&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1567818 ] Fruchterman-Reingold grid performance can be improved
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567818, was opened at 2006-09-29 11:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567818&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Fruchterman-Reingold grid performance can be improved Initial Comment: Jens Müller schrieb: I have the code at home, so I'll send it this afternoon. It's attached ... Please test if it's faster for you, too ... Index: fruchterman_reingold.hpp =========================================== ======================== RCS file: /cvsroot/boost/boost/boost/graph/ fruchterman_reingold.hpp,v retrieving revision 1.11 diff -r1.11 fruchterman_reingold.hpp 134c134 < std::size_t adj_start_row = row == 0? 0 : row - 1; --- /* std::size_t adj_start_row = row == 0? 0 : row - 1; 147a148,201 } */ // Alternative 1: std::size_t adj_start_row = row == 0? 0 : row - 1; std::size_t adj_end_row = row == rows - 1? row : row + 1; std::size_t adj_start_column = column == 0? 0 : column - 1; std::size_t adj_end_column = column == columns - 1? column : column + 1; for (std::size_t other_row = adj_start_row; other_row <= adj_end_row; ++other_row) for (std::size_t other_column = adj_start_column; other_column <= adj_end_column; ++other_column) if ((other_row <= row && other_column <= column && (other_row != row || other_column != column)) || (other_column == column+1 && other_row == row - 1)) { // Repulse vertices in this bucket bucket_t& other_bucket = buckets[other_row * columns + other_column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } } // Alternative 2: /* if (row != 0) { std::size_t other_row = row - 1; if (column != 0) { std::size_t other_column = column - 1; // field 1 bucket_t& other_bucket = buckets[other_row * columns + other_column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } } // field 2 bucket_t& other_bucket = buckets[other_row * columns + column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } if (column != columns - 1) { // field 3 std::size_t other_column = column + 1; bucket_t& other_bucket = buckets[other_row * columns + column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } 148a203,215 } if (column != 0) { std::size_t other_column = column - 1; // field 4 bucket_t& other_bucket = buckets[row * columns + other_column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } } */ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567818&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1567812 ] Numbered headers don't work with "preferred" syntax
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567812, was opened at 2006-09-29 11:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567812&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: signals Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Numbered headers don't work with "preferred" syntax Initial Comment: Hi, I'd like to write the "Preferred syntax" of a signal while including a header for a fixed number of parameters. This works for boost::function, but not for boost::signal. Surprisingly, it seems that signal1.hpp does only generate a signal1 template, in contrast to function1.hpp. :[ Couldn't that be aligned to boost::function? #include <boost/function/function1.hpp> typedef boost::function1<void, void> F1; // compiles typedef boost::function<void (void)> F2; // compiles #include <boost/signals/signal1.hpp> typedef boost::signal1<void, void> S1; // compiles typedef boost::signal<void (void)> S2; // does not compile -- David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567812&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1567811 ] Johnson All-Pairs needs better "no path" information
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567811, was opened at 2006-09-29 11:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567811&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Johnson All-Pairs needs better "no path" information Initial Comment: Hi, The Johnson's SP algorithm as implemented in the BGL does not easily provide a way to determine whether two vertices are do have a path between them. I include below a simplified version of the example provided with the BGL. Running it I get the output below: D[0][0]=0 D[0][1]=3 D[0][2]=-4 D[1][0]=2147483647 <- no path between nodes '1' and '0' D[1][1]=0 D[1][2]=2147483643 <- no path between nodes '1' and '2' D[2][0]=-2147483645 <- no path between nodes '2' and '0' D[2][1]=-2147483645 <- no path between nodes '2' and '1' D[2][2]=0 That is, there isn't one single value that represents lack of connectivity - one has to pick a value close enough to 'inf' and discriminate with that. Shouldn't 'inf' (however represented) describe lack of connectivity? (To get around this problem, at the moment I run a transitive closure before JSP and use the result of that to determine whether two vertices are connected). Does this make sense or am I missing something? Thanks, Andrea #include <boost/property_map.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/johnson_all_pairs_shortest.hpp> #include <iostream> int main() { using namespace boost; typedef adjacency_list<vecS, vecS, directedS, no_property, property< edge_weight_t, int, property< edge_weight2_t, int > > > Graph; const int V = 3; typedef std::pair < int, int >Edge; Edge edge_array[] = { Edge(0, 1), Edge(0, 2) }; const std::size_t E = sizeof(edge_array) / sizeof(Edge); Graph g(edge_array, edge_array + E, V); property_map < Graph, edge_weight_t >::type w = get(edge_weight, g); int weights[] = { 3, -4 }; int *wp = weights; graph_traits < Graph >::edge_iterator e, e_end; for (boost::tie(e, e_end) = edges(g); e != e_end; ++e) w[*e] = *wp++; std::vector < int >d(V, (std::numeric_limits < int >::max)()); int D[V][V]; johnson_all_pairs_shortest_paths(g, D, distance_map(&d[0])); std::cout << " "; std::cout << std::endl; for (int i = 0; i < V; ++i) for (int j = 0; j < V; ++j) std::cout << "D[" << i << "][" << j << "]=" << D[i][j] << std::endl; return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567811&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

std::tr1::unordered* and functional/hash
by Dave Handley 29 Sep '06

29 Sep '06

My first question here is a simple one - are there any plans for an implementation of unordered_set etc. from TR1 to be included in boost. Since the vast majority of the std::tr1 libraries are from boost, except for this one, it seems an obvious gap to try and fill. My second thought concerns the interface in std::tr1 for unordered_set - specifically for the find, count and equal_range functions. In the std::tr1 documents that I have read, the interface is very vanilla: // lookup iterator find(const key_type& k); const_iterator find(const key_type& k) const; size_type count(const key_type& k) const; std::pair<iterator, iterator> equal_range(const key_type& k); std::pair<const_iterator, const_iterator> equal_range(const key_type& k) const; However, the interface we use on our internal version of this is slightly different - based primarily on the interface for boost.multi_index: template <typename CompatibleKey> iterator find(const CompatibleKey &k); template <typename CompatibleKey, typename CompatibleHash, typename CompatiblePred> iterator find(const CompatibleKey &k, const CompatibleHash &hash, const CompatiblePred &pred); etc. This is useful for performance reasons in many cases. For example, in the case of an unordered_set<std::string> we can then provide a hash function and comparator that work with both std::string and const char *. This can then either be provided through the type of the container, or simply through the second version of the find function. For example: struct StringHasher { size_t operator()(const char *str_) const; size_t operator()(const std::string &str_) const; }; struct StringComparator { bool operator()(const char *lhs_, const std::string &rhs_) const; bool operator()(const std::string &lhs_, const char *rhs_) const; bool operator()(const std::string &lhs_, const std::string &rhs_) const; }; typedef std::tr1::unordered_set<std::string, StringHasher, StringComparator> Set1; typedef std::tr1::unordered_set<std::string> Set2; Set1 set1; set1.find("abc"); // This will not create a std::string temporary in the find function. Set2 set2; set2.find("abc", StringHasher(), StringComparator()); // This will also not create a temporary set2.find("abc"); // This will create a temporary My final thought is that it would be useful if the boost.functional/hash provided functionality as standard similar to the StringHasher/StringComparator above. I use this sort of code a lot when I'm working with hash containers and boost.multi_index and it seems wasteful to have to rewrite it regularly - especially when it is so simple to do. Any thoughts on these points? Dave Handley

1 0

[boostbook] Allow SVN dates in last-revision
by Julio M. Merino Vidal 29 Sep '06

29 Sep '06

Hello, While developing my SoC project under a Subversion repository I found that the 'Last revised' entry in the main documentation page generated by Boostbook did not appear correctly. Upon further investigation, it appears that Boostbook's HTML generation code only recognizes CVS' $Date$ tag format. Therefore it failed to process SVN's entity contents and resulted in an empty date string. The attached patch adds support for SVN dates and tries to automatically detect the appropriate format. I hope this is correct and can be integrated into the tree. Thanks. -- Julio M. Merino Vidal <jmmv84(a)gmail.com> The Julipedia - http://julipedia.blogspot.com/

2 1

[Boost-bugs] [ boost-Bugs-1567797 ] GraphViz reader ignores graph properties
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567797, was opened at 2006-09-29 11:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567797&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: GraphViz reader ignores graph properties Initial Comment: The GraphViz reader ignores all graph properties. Oops! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567797&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [asio] SSL operation sporadically returns "Access is denied"
by Christopher Kohlhoff 29 Sep '06

29 Sep '06

Hi Scott, I was about to write to say that I ran your previous test program for about half an hour without any problems. > I started thinking about my own client code and read up on the > socket class. The docs say the socket object is unsafe for > shared objects. So I put locks around every async_read or > async_write operation. However, it still fails. > > Is the problem with my code the fact that 2 threads are using > the same socket? Yes, that is a problem. I don't know if it is *the* problem. > Is that just not possible? Rather than using a mutex, a better approach would be to use an asio::strand object. You can use a strand to wrap your handlers and they won't be executed concurrently (see the last timer tutorial for an example). A mutex will *not* give the correct behaviour in the case of "composed" operations like boost::asio::async_write. (Note: i'm assuming you're using the latest code in CVS here.) However, I am not confident that the current SSL wrapper implementation is thread safe even if you use a strand. It may simply be safer at this time to stick to using an individual SSL object from a single thread. In practice that means only calling io_service::run() from a single thread. What exactly is it that you want to do with the second thread? There may be another way of structuring it to give the same effect while keeping all access to the ssl/socket object from the one thread. Cheers, Chris

1 0