From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23128 invoked by alias); 15 May 2006 11:57:12 -0000 Received: (qmail 23120 invoked by uid 22791); 15 May 2006 11:57:11 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0102.google.com (HELO nz-out-0102.google.com) (64.233.162.192) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 May 2006 11:57:09 +0000 Received: by nz-out-0102.google.com with SMTP id m22so158931nzf for ; Mon, 15 May 2006 04:57:07 -0700 (PDT) Received: by 10.65.251.20 with SMTP id d20mr1668482qbs; Mon, 15 May 2006 04:57:06 -0700 (PDT) Received: by 10.64.213.6 with HTTP; Mon, 15 May 2006 04:57:06 -0700 (PDT) Message-ID: <553911630605150457h36bc27d9w66eff467888e69ea@mail.gmail.com> Date: Mon, 15 May 2006 11:57:00 -0000 From: "Paolo Brandoli" To: pthreads-win32@sourceware.org Subject: Re: Using pthread_t as a key in a map In-Reply-To: <4467E5FA.3020300@ecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <553911630605091355q64a6eec6i76cadef9b9efa0e@mail.gmail.com> <4467E5FA.3020300@ecosm.com> X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2006/txt/msg00020.txt.bz2 Hi Will, What I'm trying to do is to order the pthread_t pointers so I can simulate the windows function "WaitForMultipleObjects"; I have to order the pthread_t in a consistent way before attempting to lock several mutexes at once. The way the pthread_t is defined in the library doesn't allow to use the < and > operators; those operators can be used when pthread_t is defined as a pointer (like in the pthreads implementation on posix systems) and not as a structure containing a pointer (as in win32-pthread). I defined the operator for ptw32_handle_t, but it works for pthread_t (since it is a synonim for ptw32_handle_t). Anyway your considerations are right since this breaks the compilation on C compilers. On C++ compilers it just remove the errors when I try to compare two pthread_t values. I'm trying to find a more elegant solution, but I'm just staring at the monitor and nothing pops up in my brain. Paolo Brandoli On 5/15/06, Will Bryant wrote: > Hi Paolo, > > Bear in mind that pthreads-win32 is written in C, and operator > overloading is a C++ feature, so adding that would prevent > pthreads-win32 from compiling with C apps. > > One alternative is to make a custom comparator type and use that in the > map declaration - or you could even simply move those operator overloads > to your own units (they don't have to be defined where the type being > compared is declared, as long as they've visible at the point where > they're used - ie. your map declaration). > > But bear in mind that in any case, making use of the ptw32_handle_t type > makes your code nonportable, and since portability is generally the > reason one is using pthreads-win32 in the first place, this is perhaps > not the best design for general use. > > Will > > > Paolo Brandoli wrote: > > I have a source code that uses the pthread_t as a key in a std::map. > > Because pthread-win32 defines pthread_t as a structure, the > > compilation fails. > > > > I added the following lines in my pthread.h header in order to allow > > the usage of pthread_t in the map: > > > > bool operator < (const ptw32_handle_t& left, const ptw32_handle_t& righ= t) > > { > > return left.p < right.p; > > } > > > > bool operator > (const ptw32_handle_t& left, const ptw32_handle_t& righ= t) > > { > > return left.p > right.p; > > } > > > > Bye > > Paolo Brandoli > > http://www.puntoexe.com > > > > > -- > Will Bryant > > > >