- Boost-users - lists.boost.org

Re: [Boost-users] Why is boost::thread::mutex noncopyable?
by Phil Endecott 01 Jan '06

01 Jan '06

>>Can someone help me to understand why boost::thread::mutex is >>noncopyable? I expect that there is a good reason, but I can't see it >>at the moment. > > http://www.boost.org/doc/html/threads/faq.html#id2786688 Thanks for the link. Here is the text: Why do Mutexes have noncopyable semantics? To ensure that deadlocks don't occur. The only logical form of copy would be to use some sort of shallow copy semantics in which multiple mutex objects could refer to the same mutex state. This means that if ObjA has a mutex object as part of its state and ObjB is copy constructed from it, then when ObjB::foo() locks the mutex it has effectively locked ObjA as well. This behavior can result in deadlock. Other copy semantics result in similar problems (if you think you can prove this to be wrong then supply us with an alternative and we'll reconsider). I disagree with the first comment: "The only logical form of copy would be to use some sort of shallow copy semantics in which multiple mutex objects could refer to the same mutex state." What's wrong with the copy of a mutex being a new independent mutex? (There's a problem if you copy a locked mutex, but I don't propose to do that.) --Phil.

3 2

Re: [Boost-users] Why is boost::thread::mutex noncopyable?
by Phil Endecott 01 Jan '06

01 Jan '06

>>Can someone help me to understand why boost::thread::mutex is >>noncopyable? I expect that there is a good reason, but I can't see it >>at the moment. > > http://www.boost.org/doc/html/threads/faq.html#id2786688 I'm being a bit dense - a subsequent FAQ shows how you can write a copy-constructor for a struct that contains a mutex that explicitly copies the data, giving you a new default-constructed mutex. The constructor can even lock the thing it is copying. --Phil.

1 0

Why is boost::thread::mutex noncopyable?
by Phil Endecott 31 Dec '05

31 Dec '05

Dear All, Can someone help me to understand why boost::thread::mutex is noncopyable? I expect that there is a good reason, but I can't see it at the moment. In my multithreaded application I have a struct with some uninteresting data in it, but I want updates to the struct as a whole to be atomic so I have a mutex. For example: struct person { string firstname; string surname; mutex m; }; I want to be able to put these structs in a container. Say a map: map<int,person> people; person p; people.insert(make_pair(1,p)); But I can't do this because the mutex is noncopyable and inserting copies it. Yes, I could have a map<int,person*>. But I don't understand why I'm forced to do that. Of course, copying a struct person while the mutex is locked would be a bad thing to do. And copying the struct is not thread safe. But higher-level constraints can prevent this sort of thing from happening; for example, I might create my map while only one thread exists. Can anyone offer any insight? Thanks, --Phil.

2 1

Re: [Boost-users] [multi_index] const_mem_fun with an inherited memberfunction
by JOAQUIN LOPEZ MU?Z 31 Dec '05

31 Dec '05

Hello Matt, ----- Mensaje original ----- De: Matt Steele <steelerm(a)netlab.uky.edu> Fecha: Sábado, Diciembre 31, 2005 8:21 am Asunto: [Boost-users] [multi_index] const_mem_fun with an inherited memberfunction > I am trying to use Boost.Multi-index (version 1.33.0) to store a > set of > boost::tuples, and it appears that const_mem_fun has some difficulties > when the desired member function is inherited from a base class. The > following typedef > > typedef multi_index_container< > tuple<int>, > indexed_by< ordered_non_unique< const_mem_fun< tuple<int>, > const int&, > &tuple<int>::get<0> > > > > > > > > my_tuple_container_type; > > yields this error (edited for clarity) on my compiler (g++ 4.0.3): > > &TupleBaseClass<int>::get' is not a valid template argument for > type > 'const int& (tuple<int>::*)()const' because it is of type > 'const int& (TupleBaseClass<int>::*)const' > note: standard conversions are not allowed in this context > > > Now the declaration of boost::tuple has something like this: > > template <class T> > class tuple : public TupleBaseClass<T> { > public: > typedef typename TupleBaseClass<T> inherited; > ... > }; > > (Also, as far as I can tell, get<0>() is declared and implemented in > TupleBaseClass, not tuple). The public typedef 'inherited' looked > promising, so I modified my code as follows: > > typedef multi_index_container< > tuple<int>, > indexed_by< ordered_non_unique< const_mem_fun< > tuple<int>::inherited, > const int&, > &tuple<int>::get<0> > > > > > > > > my_tuple_container_type; > > and that compiles. > > I have a few questions/comments about all this. First of all, is my > compiler correct to generate the error for the first case? Unfortunately, it is correct. There are some quirks about the contravariance rules of pointer to members in C++. For instance, the following is legal (as expected): struct A { int x; }; struct B:A{}; int main() { int B::* p=&B::x; } whereas the following is not: struct A { int x; }; struct B:A{}; template<int B::*Ptr> struct foo{}; int main() { // error: argument of type "int A::*" is incompatible with // template parameter of type "int B::*" foo<&B::x> f; } To me, this is a defect in the standard, but there might be a reason for this behavior. I'll go ask in comp.std.c++. > Secondly, is > the above workaround satisfactory? My opinion is that it's a little > ungainly; it appears to me that boost::tuple is a derived type for > implementation reasons, and I'd rather not have to know about that > fact. It is unsatisfactory for two reasons: 1. As you say, having to expose an implementation artifact is ugly. 2. I think that the code won't work as expected: const_mem_fun has some overloads of operator() in order to support chained pointers (http://tinyurl.com/9cd2v) that will hide the implicit conversion from const tuple<int>& to const tuple<int>::inherited&. Could you please try to insert some element in my_tuple_container_type? My hunch is that you'll get a compiler error about tuple<int> not having operator*. Please report back. As for issue #2, I've corrected the problem (for SFINAE-capable compilers) for the next Boost 1.34 release. Even so, issue #1 remains. My suggestion is that you simply provide a user-defined key extractor like this (uncompiled, beware typos): template<typename Tuple,int N> struct tuple_member_extractor { typedef typename boost::tuples::element<N,Tuple>::type result_type; const result_type& operator()(const Tuple& t)const { return boost::tuples::get<N>(t); } }; Hope this helps; I'd appreciate if you reported on the success/failure of this approach. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] multi_index new user question
by JOAQUIN LOPEZ MU?Z 31 Dec '05

31 Dec '05

Hello Evan, ----- Mensaje original ----- De: Evan Carew <carew(a)pobox.com> [...] > int main(){ > const people_set::nth_index<2>::type& resstreet_index=ps.get<2>(); > pair<people_set::iterator, people_set::iterator> range; > range = resstreet_index.equal_range((*domoItor).first); > } > > The above code doesn't compile. > > - ---Fourth entry: > By changing the pair instance to: > > pair<people_set::nth_index<2>::type::iterator, > people_set::nth_index<2>::type::iterator> range; > > I finally got it to compile. I managed this not by reading the > tutorialfor the library (the information isn't there) Well, you're right there's no explicit mention to this issue in the tutorial. The info can be extracted from the reference, though. In any case, I'll try to improve the docs on this and add some comments on how to obtain index iterators. Thanks for the feedback! > but from > reading the > rather prodigious code in multi_index. Wow, this is quite an achievement. The code can look very unintelligible. > > - ---Fifth entry: > Am I headed in the right direction, or is there specific interface > that > defines the iterator types in a less painful/safe way? > You've used one of several syntaxes for getting the type of the index #2 iterator. Other possibilities are: people_set::index<resstreetnum>::type::iterator people_set::nth_index_iterator<2>::type people_set::index_iterator<resstreetnum>::type nth_index<people_set,2>::type::iterator index<people_set,resstreetnum>::type::iterator nth_index_iterator<people_set,2>::type index_iterator<people_set,resstreetnum>::type Since you've assigned tags to your indices, it is probably nicer to use some of the tag variations instead of those based on the index ordinal. Other than this, no syntax is particularly clearer or more concise. You may also want to follow Todd Day's suggestion in another reply to your post, and use some typedef's in order to increase code readability. For instance, if you define typedef people_set::index<resstreetnum>::type resstreet_index_type; then the iterator you're looking for is simply resstreet_index_type::iterator which looks quite obvious, since it follows exactly the same pattern as you'd adopt for an STL container. HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[bind] Specifying bind types
by David A. Greene 31 Dec '05

31 Dec '05

I have a situation where I need to be able to specify the type of object that will be created by an invocation of bind(): template<typename F> class Callback { public: Callback(F func) ... } template<typename F, typename Arg> class OneMoreArgCallback : public Callback<SOME_BIND_TYPE> { public: OneMoreArgCallback(F func, Arg arg) : Callback(boost::bind(func, arg, _1)) {}; } What's the best way to do this? typeof? -Dave

3 3

Re: [Boost-users] The boost Tokenizer package: split into a vectorof vectors of tokens
by Alex Vinokur 31 Dec '05

31 Dec '05

nitin motgi wrote: > > > > > if(It != string_find_iterator()) cout << "(" << i << ", " << j << ") : " > > << (*It) << endl; > > > Modify this line to (*It) ==> (*It++) > if(It != string_find_iterator()) cout << "(" << i << ", " << j << ") : " << > (*It++) << endl; > string s = "ab cd \n xy z\n123"; > And output would be > $ ./a.exe > (0, 0) : ab > (0, 1) : cd > (1, 0) : > (1, 1) : > (2, 0) : xy > (2, 1) : z [snip] How to interpret that output? * Why are there two spaces between 'cd' and 'xy'? * Why are there no spaces 'xy' and 'z'? * Why is '123' missing? -- Alex Vinokur email: alex DOT vinokur AT gmail DOT com http://mathforum.org/library/view/10978.html http://sourceforge.net/users/alexvn

1 0

[multi_index] const_mem_fun with an inherited member function
by Matt Steele 31 Dec '05

31 Dec '05

I am trying to use Boost.Multi-index (version 1.33.0) to store a set of boost::tuples, and it appears that const_mem_fun has some difficulties when the desired member function is inherited from a base class. The following typedef typedef multi_index_container< tuple<int>, indexed_by< ordered_non_unique< const_mem_fun< tuple<int>, const int&, &tuple<int>::get<0> > > > > my_tuple_container_type; yields this error (edited for clarity) on my compiler (g++ 4.0.3): &TupleBaseClass<int>::get' is not a valid template argument for type 'const int& (tuple<int>::*)()const' because it is of type 'const int& (TupleBaseClass<int>::*)const' note: standard conversions are not allowed in this context Now the declaration of boost::tuple has something like this: template <class T> class tuple : public TupleBaseClass<T> { public: typedef typename TupleBaseClass<T> inherited; ... }; (Also, as far as I can tell, get<0>() is declared and implemented in TupleBaseClass, not tuple). The public typedef 'inherited' looked promising, so I modified my code as follows: typedef multi_index_container< tuple<int>, indexed_by< ordered_non_unique< const_mem_fun< tuple<int>::inherited, const int&, &tuple<int>::get<0> > > > > my_tuple_container_type; and that compiles. I have a few questions/comments about all this. First of all, is my compiler correct to generate the error for the first case? Secondly, is the above workaround satisfactory? My opinion is that it's a little ungainly; it appears to me that boost::tuple is a derived type for implementation reasons, and I'd rather not have to know about that fact. Thank you. Matt Steele

1 0

Re: [Boost-users] multi_index new user question
by Todd Day 31 Dec '05

31 Dec '05

I've got the following in my project // dummies needed for tagging struct by_name {}; struct by_id {}; struct by_vreg {}; // breaking this up into two steps makes things easier on the compiler, and produces readable? error messages struct ParmListIndices : multi_index::indexed_by < multi_index::sequenced<>, multi_index::ordered_unique<multi_index::tag<by_name>, multi_index::const_mem_fun<ParmBase, string, &ParmBase::GetNameStripped> >, multi_index::ordered_non_unique<multi_index::tag<by_id>, multi_index::const_mem_fun<ParmBase, int, &ParmBase::GetID> >, multi_index::ordered_non_unique<multi_index::tag<by_vreg>, multi_index::const_mem_fun<ParmBase, int32, &ParmBase::GetVreg> > > {}; struct ParmList : multi_index::multi_index_container<ParmBase*, ParmListIndices> {}; typedef multi_index::nth_index<ParmList, 1>::type ParmList_by_name; typedef multi_index::nth_index<ParmList, 2>::type ParmList_by_id; typedef multi_index::nth_index<ParmList, 3>::type ParmList_by_vreg; typedef pair<ParmList::iterator, bool> ParmListResultPair; Note that I used structs to wrap a complicated multi_index instead of using typedefs. I learned this trick from a previous web discussion about multi_index. This relieves stress on the compiler (important for MSVC7.1 with maximum debugging turned on) and makes the error messages easier to read. I used typedef shortcuts for referring to the nth_index'es 'cause structs don't work there. This allowed me to write the following fairly simple looking code. Note the type of the variable "byName" and the iterator "f" below. ParmBase* ParmGroup::FindName(const string& name) { ParmList_by_name& byName = pParmList->get<by_name>(); ParmList_by_name::iterator f = byName.find(name); return (f != byName.end()) ? *f : NULL; } These sorts of tricks make the code a little bit more readable. You can do a similar thing for your iterator pair in your range variable. -todd- > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Evan Carew > Sent: Friday, December 30, 2005 1:03 PM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] multi_index new user question > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The following is todays log of my efforts to get multi_index to work: > > - ---First entry: > I'm using boost multi index for the first time. I've managed to populate > the container with my data & now I am trying to get the non-unique > ordered index to work. Does anyone have a source example (not from the > boost.multiindex tutorial please) used to get a list, set, whatever, of > tuples from such a search on such an index? > > Thanks, > Evan Carew > > P.S. > G++ V3.4.2 > Boost version 103300 > > - ---Second entry: > Hmm... Looks like their list server is down. I am unable to register. <sigh> > > - ---Third entry: > Well, lets try this example source code: > > > typedef multi_index::multi_index_container< > person, > multi_index::indexed_by< > multi_index::ordered_unique< > multi_index::tag<voterid>, > BOOST_MULTI_INDEX_MEMBER(person,unsigned long,voterid)>, > multi_index::ordered_non_unique< > > multi_index::tag<lastname>,BOOST_MULTI_INDEX_MEMBER(person,string,lastna me) > >, > multi_index::ordered_non_unique< > multi_index::tag<resstreetnum>, > BOOST_MULTI_INDEX_MEMBER(person,int,resstreetnum)> > > > people_set; > > ..... > > int main(){ > const people_set::nth_index<2>::type& resstreet_index=ps.get<2>(); > pair<people_set::iterator, people_set::iterator> range; > range = resstreet_index.equal_range((*domoItor).first); > } > > The above code doesn't compile. > > - ---Fourth entry: > By changing the pair instance to: > > pair<people_set::nth_index<2>::type::iterator, > people_set::nth_index<2>::type::iterator> range; > > I finally got it to compile. I managed this not by reading the tutorial > for the library (the information isn't there) but from reading the > rather prodigious code in multi_index. > > - ---Fifth entry: > Am I headed in the right direction, or is there specific interface that > defines the iterator types in a less painful/safe way? > > Evan Carew

1 0

multi_index new user question
by Evan Carew 30 Dec '05

30 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following is todays log of my efforts to get multi_index to work: - ---First entry: I'm using boost multi index for the first time. I've managed to populate the container with my data & now I am trying to get the non-unique ordered index to work. Does anyone have a source example (not from the boost.multiindex tutorial please) used to get a list, set, whatever, of tuples from such a search on such an index? Thanks, Evan Carew P.S. G++ V3.4.2 Boost version 103300 - ---Second entry: Hmm... Looks like their list server is down. I am unable to register. <sigh> - ---Third entry: Well, lets try this example source code: typedef multi_index::multi_index_container< person, multi_index::indexed_by< multi_index::ordered_unique< multi_index::tag<voterid>, BOOST_MULTI_INDEX_MEMBER(person,unsigned long,voterid)>, multi_index::ordered_non_unique< multi_index::tag<lastname>,BOOST_MULTI_INDEX_MEMBER(person,string,lastname)>, multi_index::ordered_non_unique< multi_index::tag<resstreetnum>, BOOST_MULTI_INDEX_MEMBER(person,int,resstreetnum)> > > people_set; ..... int main(){ const people_set::nth_index<2>::type& resstreet_index=ps.get<2>(); pair<people_set::iterator, people_set::iterator> range; range = resstreet_index.equal_range((*domoItor).first); } The above code doesn't compile. - ---Fourth entry: By changing the pair instance to: pair<people_set::nth_index<2>::type::iterator, people_set::nth_index<2>::type::iterator> range; I finally got it to compile. I managed this not by reading the tutorial for the library (the information isn't there) but from reading the rather prodigious code in multi_index. - ---Fifth entry: Am I headed in the right direction, or is there specific interface that defines the iterator types in a less painful/safe way? Evan Carew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDtaBppxCQXwV2bJARAtYyAJ4lZRAoEbT1m0jsllTGAfmUZEpqSwCguhZO V18uawK1QSD2iJF00hPm4qA= =qn+Q -----END PGP SIGNATURE-----

1 0