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

[Brian Cole via cfe-users]

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<mailto:hintonda at gmail.com>>
Date: Monday, February 29, 2016 at 11:22 AM
To: Brian L Cole <coleb at eyesopen.com<mailto:coleb at eyesopen.com>>
Cc: "cfe-users at lists.llvm.org<mailto:cfe-users at lists.llvm.org>" <cfe-users at lists.llvm.org<mailto: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<mailto: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<mailto:hintonda at gmail.com>>
Date: Monday, February 29, 2016 at 10:38 AM
To: Brian L Cole <coleb at eyesopen.com<mailto:coleb at eyesopen.com>>
Cc: "cfe-users at lists.llvm.org<mailto:cfe-users at lists.llvm.org>" <cfe-users at lists.llvm.org<mailto: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<mailto: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<mailto: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/ec51b6b4/attachment.html>