[cfe-users] Anyway to prevent this code from compiling?

[don hinton via cfe-users]

Yes, get ride of using namespace std.

The problem is the parsing.  Since mutex is a type, OELock lock(mutex) is
function declaration, i.e., returns an OELock and takes a mutex as a
parameter.

Could you use factory function instead?

lass OELock
{
  OEMutex &_mutex;
  OELock();
  //OELock(const OELock&); // is this a problem for you???
  OELock& operator=(const OELock&);
  OELock(OEMutex &_mutex) : _mutex(_mutex) { _mutex.Acquire(); }
public:
  static OELock makeLock(OEMutex &mutex) { return OELock(mutex);}

  ~OELock() { _mutex.Release(); }
};

OELock lock(mutex);

int main()
{
  OELock lock = OELock::makeLock(mutex);
}



On Mon, Feb 29, 2016 at 1:28 PM, Brian Cole <coleb at eyesopen.com> wrote:

> Anything that can be added to the OELock class to make it uncompilable in
> that context? Getting users to change how they initialize a scoped lock
> won’t be easy.
>
> A “just as easy” solution is to remove the ‘using namespace std’. I guess
> this is why Google banned ‘using namespace foo;’ in their style guide:
> https://google.github.io/styleguide/cppguide.html#Namespaces
>
> From: don hinton <hintonda at gmail.com>
> Date: Monday, February 29, 2016 at 11:22 AM
>
> To: Brian L Cole <coleb at eyesopen.com>
> Cc: "cfe-users at lists.llvm.org" <cfe-users at lists.llvm.org>
> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>
> you could try adding an extra set of parentheses, but you won't get as
> good an error message.
>
> OELock lock((mutex));
>
> On Mon, Feb 29, 2016 at 1:15 PM, Brian Cole <coleb at eyesopen.com> wrote:
>
>> Was hoping for something that would be C++03 compatible as well since we
>> still have C++03 compilers to target as well.
>>
>> From: don hinton <hintonda at gmail.com>
>> Date: Monday, February 29, 2016 at 10:38 AM
>> To: Brian L Cole <coleb at eyesopen.com>
>> Cc: "cfe-users at lists.llvm.org" <cfe-users at lists.llvm.org>
>> Subject: Re: [cfe-users] Anyway to prevent this code from compiling?
>>
>> Try using initialization list syntax.  That way the parser won't think
>> you are declaring a function.
>>
>> OELock lock{mutex};
>>
>>
>>
>> On Mon, Feb 29, 2016 at 12:02 PM, Brian Cole via cfe-users <
>> cfe-users at lists.llvm.org> wrote:
>>
>>> Since switching over to clang C++11 on OS X, we had this weird C++
>>> oddity surface while writing some new code. The problem is that ‘mutex’ is
>>> no longer a variable, it is a class type that can be interpreted as a
>>> function argument. That is, the following line of code can be interpreted
>>> as a function declaration now:
>>>
>>> OELock lock(mutex);
>>>
>>> Instead of a scoped lock acquisition as has been convention for some
>>> time now. The full code to recreate the subtle bug is as follows:
>>>
>>> #include <mutex>
>>>
>>> using namespace std;
>>>
>>> struct OEMutex
>>> {
>>>   void Acquire() {}
>>>   void Release() {}
>>> };
>>>
>>> static OEMutex _mutex;
>>>
>>> class OELock
>>> {
>>>   OEMutex &_mutex;
>>>   OELock();
>>>   OELock(const OELock&);
>>>   OELock& operator=(const OELock&);
>>>
>>> public:
>>>   OELock(OEMutex &mutex) : _mutex(mutex) { _mutex.Acquire(); }
>>>   ~OELock() { _mutex.Release(); }
>>> };
>>>
>>> int main()
>>> {
>>>   OELock lock(mutex);
>>> }
>>>
>>> Ideally, we would like the compilation to fail and tell the user the
>>> ‘mutex’ variable can not be found. Any clever C++ trick to do that? We’ve
>>> tried declaring the move constructors of OELock to be private, but it still
>>> compiles (maybe that’s SFINAE?).
>>>
>>> Thanks,
>>> Brian
>>>
>>>
>>> _______________________________________________
>>> cfe-users mailing list
>>> cfe-users at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20160229/8c226464/attachment.html>