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

Problems with CVS
by Mateusz Łoskot 01 Jan '06

01 Jan '06

Hi, Yesterday I met some problems with accessing Boost CVS. I started to checkout the CVS HEAD using anonymous user. The process was going well but after a few minutes I got many timeouts errors. I tried to checkout again and update my existing sandbox but without any success. Here are errors I got when using command line CVS client: D:\__projects_mloskot\boost>cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost login Logging in to :pserver:anonymous@cvs.sourceforge.net:2401:/cvsroot/boost CVS Password: cvs [login aborted]: Error reading from server cvs.sourceforge.net: 0: No such file or directory D:\__projects_mloskot\boost>cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost co -P boost cvs [checkout aborted]: Error reading from server cvs.sourceforge.net: 0: Invalid argument D:\__projects_mloskot\boost>cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost update -P boost cvs [update aborted]: Error reading from server cvs.sourceforge.net: 0: Invalid argument As I checked CVS Web Browser is working well, so CVS on SF.net seems to be up. Am I doing something wrong? Cheers -- Mateusz Łoskot http://mateusz.loskot.net

1 1

Re: [Boost-users] [multi_index] const_mem_fun with an inherited member function
by JOAQUIN LOPEZ MU?Z 01 Jan '06

01 Jan '06

----- Mensaje original ----- De: Matt Steele <steelerm(a)netlab.uky.edu> Fecha: Domingo, Enero 1, 2006 8:32 pm Asunto: Re: [Boost-users] [multi_index] const_mem_fun with an inherited member function [...] > Your suggestion worked without any changes (runtime tested it > with a few toy calls to insert()/find() ). However, if instead of > invoking the global get<>() function template, I try to call the > member function template, > > return t.get<N>(); > > I get this compile error: > > error: invalid use of member (did you forget the '&' ?) > > Do you know if this code should compile? If not, is there a way > to call > a member function template in this context without relying on a global > function wrapper? Try return t.template get<N>(); Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] [multi_index] const_mem_fun with an inherited member function
by Matt Steele 01 Jan '06

01 Jan '06

Hello Joaquin, Thank you for your response. > 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. You're right; the code fails to compile and for the reason you give. > 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. > Your suggestion worked without any changes (runtime tested it with a few toy calls to insert()/find() ). However, if instead of invoking the global get<>() function template, I try to call the member function template, return t.get<N>(); I get this compile error: error: invalid use of member (did you forget the '&' ?) Do you know if this code should compile? If not, is there a way to call a member function template in this context without relying on a global function wrapper? Thanks, Matt

1 0

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