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

[don hinton via cfe-users]

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/845f5a03/attachment.html>