Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@thrift.apache.org
Received-SPF: pass (athena.apache.org: domain of ben.craig@ni.com designates
 130.164.80.5 as permitted sender)
In-Reply-To: 
 <CAPtH0jYgc51UKO5FnSPjurYK_2dYDuNxY7Yg7hGoBhatOxpJ8g@mail.gmail.com>
References: 
 <CADH3QDg_YBpz_g2RToEEXq2ECesAwfn3ue4BNQ_tMR+tPVYRFg@mail.gmail.com>
 <CAPtH0jYgc51UKO5FnSPjurYK_2dYDuNxY7Yg7hGoBhatOxpJ8g@mail.gmail.com>
To: dev@thrift.apache.org, user@thrift.apache.org
MIME-Version: 1.0
Subject: Re: thrift/concurrency/Mutex.h bug
From: Ben Craig <ben.craig@ni.com>
Message-ID: <OF771CAAE1.BFF58DEC-ON86257AAF.0055FB89-86257AAF.00562F04@ni.com>
Date: Wed, 7 Nov 2012 09:41:21 -0600
Content-Type: multipart/alternative;
 boundary="=_alternative 00562EDE86257AAF_="

--=_alternative 00562EDE86257AAF_=
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"

I can sympathize with the author of the offending #defines, as I've seen=20
the bug that he references a number of times.  I think that "Guard" is too =

generic to #define away though.  If only compilers would actually warn=20
about the offending usage...


From:   Henrique Mendon=E7a <henrique@apache.org>
To:     user@thrift.apache.org
Cc:     dev@thrift.apache.org
Date:   11/07/2012 04:24 AM
Subject:        Re: thrift/concurrency/Mutex.h bug
Sent by:        hmendonca@gmail.com


Hi Bud,

I wonder why we are not using boost mutex and scoped mutex instead but
those two macros are probably not necessary anyways.
Would you create a patch and copy/adapt those comments to the thrift Mutex
classes themselves?
Thank you!
http://thrift.apache.org/docs/HowToContribute/

Henrique

On 7 November 2012 00:19, Bud Bundy <budric@gmail.com> wrote:

> Hi,
>
> I'm using version 0.9.0.  The following code in=20
thrift/concurrency/Mutex.h
> is causing me great headaches:
>
> // A little hack to prevent someone from trying to do "Guard(m);"
> // Such a use is invalid because the temporary Guard object is
> // destroyed at the end of the line, releasing the lock.
> // Sorry for polluting the global namespace, but I think it's worth it.
> #define Guard(m) incorrect=5Fuse=5Fof=5FGuard(m)
> #define RWGuard(m) incorrect=5Fuse=5Fof=5FRWGuard(m)
>
> The global macro is interfering with another library I'm using that also
> defines a Guard class within their own namespace.  So, no, I don't think
> it's worth it.  I think it's a bug.  I can patch the file by removing=20
those
> two lines, but any way this can be fixed in the trunk?
>
> Thanks.
>


--=_alternative 00562EDE86257AAF_=--