[vinkelhake]

The real advantage of a scoped lock is that it promises to release the mutex, no matter how the scope is exited. If this LOCKED macro is used and an exception is thrown from within the block, that mutex now stays locked.

> The only gotcha is, there is some overhead involved in this approach. The class instance takes up some space on the stack (several bytes) for every lock acquisition.

Not so fast. A decent compiler will eliminate the overhead and not actually allocate stack space for the lock. Here's an example using one of the lock guards in C++:

    struct foo {
      int var;
      std::mutex m;
    };
    
    void process1(foo& f) {
      std::lock_guard<std::mutex> lock(f.m);
      ++f.var;  
    }

    void process2(foo& f) {
      f.m.lock();
      ++f.var;  
      f.m.unlock();
    }

GCC 4.8.1 generates identical code for process1 and process2.

[lbrandy]

Indeed. Sorry OP, your solution:

(1) avoids best practice (RAII) using...

(2) a flawed rationale (ignoring the existence of compiler optimizations)...

(3) without measurement to demonstrate the supposed flaw in the best practice (which would have surfaced the flawed rationale)...

(4) and therefore implements a micro-optimization with no actual win...

(5) and introduces a bug in the process (it's not exception safe).

[s_kanev]

OP here. Totally agree. TIL about RAII. That particular codebase doesn't use c++ exceptions, but still not a reason for a roll-your-own solution if something as efficient is in the standard library.

[dicroce]

Does it use the STL? The STL will throw. Does it use the new operator? new will throw unless you specifically tell it not to.

[s_kanev]

Ok, should've been more specific -- it doesn't catch any exceptions and lets them bring down the program and have the project maintainer check what they did wrong.

[stinos]

This. For at least three typical 'best practice' reasons. I know there are times best practices can be nicely ignored, but this is not one of those occasions. On the contrary. Let me lay them out again:

- these are the days of C++11 where scoped locks are readily available

- premature optimization

- macros are evil

[pjmlp]

One of the reasons C++ gets bad reputation, is those Cisms that people insist on writing, when the language offers much better alternatives.

[stinos]

Which is mostly due to lack of education. If you don't ever spent time learning, but just coding, you don't know better. And sometimes it's all too easy to get thrapped into it due to deadlines and whatnot. A former collegue of mine, unfortunately, was the best example: programmed for like 15 years years and still wrote like it was all 'C with classes' (not that there ever was such a thing). You know, writing declarations at the top of functions etc. Missing out on C++11 is just as bad.

[pjmlp]

Fully agree.

Personally I never liked straight C.

For me it was just a short transition between Turbo Pascal and C++, only to be used when required to do so. Around 1993 or so.

I devoured every book and publication about C++ I could put my hands on. Always trying to educate others how to write safe and portable C++.

Nowadays I am into JVM and .NET mostly, but when I reach for C++ it is with regard to the latest standards.

Every now and then, I still see C++ code that is basically the C subset without using any improvements of C++ over C.

[dmm]

C with classes is what the google c++ style guide mandates: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

No exceptions, no boost, no lambda, no rtti, streams only for logging, avoid operator overloading, etc.

[vinkelhake]

The Google C++ style guide has its quirks, but describing it as "C with classes" is flat out wrong.

> no boost

Not true, select parts of Boost are available.

> no lambda

The C++11 features are being rolled in gradually. Lambda expressions are now permitted.

> no rtti

The guide says "avoid RTTI" and urges the developer to come up with a different design. This is very much in line with C++ best practice overall. There's no ban on RTTI.

[dmm]

Version 3.274 says:

Do not use lambda expressions, or the related std::function or std::bind utilities.

[pjmlp]

I don't agree with Google's style guide, besides they are not perfect.

[rmcclellan]

There was a C with Classes.

http://www.stroustrup.com/bs_faq.html#invention

[pjmlp]

There is no reason to code in 2014 as if CFront was just released today.

[twoodfin]

Yeah, they even admit that their macro compiles to identical code as the original RAII version. Where's the "overhead"?

As a general rule, if your C++ compiler can statically see the layout of your structures and the implementation of your functions, it will produce code as efficient as inlining everything yourself. Sufficiently complex functions make the benefits of inlining a judgment call on the compiler's part, but for something as simple as an RAII scoped lock, the abstraction is free.

[infogulch]

Wait... if it's identical, how can it be safe against exceptions? `process2` isn't.

[saurik]

In addition to twoodfin's answer, I will point out that even if the code could throw, the code for the function would still be identical for when a throw did not occur (as in, we would see identical output with the addition of some code that would seemingly never be used or executed), on "good architectures", due to zero-cost exceptions (which only incur overhead during unwind; if no exception is thrown the code executed is exactly identical to if exceptions were not possible).

[twoodfin]

gcc can statically determine that incrementing f.var will not throw.