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

[don hinton via cfe-users]

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/8e30b598/attachment.html>