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

2016-02-29 Thread Jim Porter via cfe-users
On 2/29/2016 12:15 PM, Brian Cole via cfe-users wrote: Was hoping for something that would be C++03 compatible as well since we still have C++03 compilers to target as well. If you're #including , haven't you locked yourself into C++11 (or better) anyway? In that case, you should use curly bra

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

2016-02-29 Thread 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 OE

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

2016-02-29 Thread 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 st

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

2016-02-29 Thread don hinton via cfe-users
Or use initialization list with assignment: OELock lock = {mutex}; On Mon, Feb 29, 2016 at 1:22 PM, don hinton wrote: > 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 wrot

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

2016-02-29 Thread 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 wrote: > Was hoping for something that would be C++03 compatible as well since we > still have C++03 compilers to target as well. > > F

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

2016-02-29 Thread Brian Cole via cfe-users
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 mailto:hinto...@gmail.com>> Date: Monday, February 29, 2016 at 10:38 AM To: Brian L Cole mailto:co...@eyesopen.com>> Cc: "cfe-users@lists.llvm.org

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

2016-02-29 Thread 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@lists.llvm.org> wrote: > Since switching over to clang C++11 on OS X, we had this weird C++ oddity > s

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

2016-02-29 Thread Brian Cole via cfe-users
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 funct

[cfe-users] Binary instruction operand type - Fast-math-flags - Vectorized IR code

2016-02-29 Thread Simona Simona via cfe-users
Hello, I'm using LLVM 3.4 and noticed that some of the IR binary instructions have the following format: = frem [fast-math flags]* , ; yields ty:result I'm mainly interested in extracting the type of the operands, regardless of whether the fast-math-flags are set or not. In the cas