Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@thrift.apache.org
Date: Wed, 7 Nov 2012 16:07:13 +0000 (UTC)
From: "Bud Bundy (JIRA)" <jira@apache.org>
To: dev@thrift.apache.org
Message-ID: <1780257809.80977.1352304433370.JavaMail.jiratomcat@arcas>
In-Reply-To: <370489719.80953.1352304192590.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (THRIFT-1748) Guard and RWGuard macros defined
 in global namespace
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/THRIFT-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492455#comment-13492455 ] 

Bud Bundy commented on THRIFT-1748:
-----------------------------------

{code}
Index: Mutex.h
===================================================================
--- Mutex.h	(revision 1406661)
+++ Mutex.h	(working copy)
@@ -183,15 +183,6 @@
     const ReadWriteMutex& rw_mutex_;
 };
 
-
-// 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_use_of_Guard(m)
-#define RWGuard(m) incorrect_use_of_RWGuard(m)
-
-
 }}} // apache::thrift::concurrency
 
 #endif // #ifndef _THRIFT_CONCURRENCY_MUTEX_H_
{code}
                
> Guard and RWGuard macros defined in global namespace
> ----------------------------------------------------
>
>                 Key: THRIFT-1748
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1748
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.9
>         Environment: Visual Studio 2010
>            Reporter: Bud Bundy
>            Priority: Trivial
>              Labels: newbie, patch
>
> thrift/concurrency/Mutex.h defines global macros Guard and RWGuard.  Although the purpose is well commented and appreciated - i.e. trying to prevent coders from creating temporary variables and falsely assuming they have a lock - this code does interfere with other packages that define their own Guard classes.  Even when the user/library define Guard in their own namespace, there's a clash.
> Please remove the macros.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira