What about: #define LOCKED(lk) for(int i=lk_lock(lk); i == 0; lk_unlock(lk), i++) Probably better to test for 0 exactly, in case it fails. You don't want it to unlock twice just because it returns -1.
This is so wrong on so many levels.
In the C++ bag of tricks: scoped locks
31–40 of 56 posts
Re: In the C++ bag of tricks: scoped locks
#32People have already pointed out the specific problems with this approach so I won't repeat them.
It's worth reiterating, though: If you are writing c++ these days and find yourself reaching for a preprocessor macro, I think that's a good sign you should think really carefully about what you are actually trying to do. Chances are really good there is a (much) better way.
Re: In the C++ bag of tricks: scoped locks
#33Earlier quoted context omitted.
One of the reasons C++ gets bad reputation, is those Cisms that people insist on writing, when the language offers much better alternatives.
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 declara…
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.
Re: In the C++ bag of tricks: scoped locks
#34You can do some of this with the cleanup attribute in GCC, although it doesn't trigger in the case of a longjmp.
[deleted]
Re: In the C++ bag of tricks: scoped locks
#35You're also consuming the variable name i, which everyone else is probably using. Speaking of which, this means you can't have one of your locks scoped inside another one.
Solvable by creating a Preprocessor macro which creates a unique and complex-named identifier.
#define LOCKED(lk) for(int UNIQUE_ID=0; UNIQUE_IDRe: In the C++ bag of tricks: scoped locks
#36Boost.Scopexit addresses this point pretty well I think: http://www.boost.org/doc/libs/1_55_0/libs/scope_exit/doc/htm...
Re: In the C++ bag of tricks: scoped locks
#37The 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…
Wait... if it's identical, how can it be safe against exceptions? `process2` isn't.
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).
Re: In the C++ bag of tricks: scoped locks
#38You can do some of this with the cleanup attribute in GCC, although it doesn't trigger in the case of a longjmp.
Actually, it looks like C++ destructors don't run on longjmp either, though that's less of an issue since C++ actually has real exceptions.
Re: In the C++ bag of tricks: scoped locks
#39Wouldn't this be exception-safe, provided lock_iter defines a ctor, dtor, operator bool() and operator ++()?
#define LOCKED(lk) for (lock_iter i = lk; i; i++)
Re: In the C++ bag of tricks: scoped locks
#40Earlier quoted context omitted.
One of the reasons C++ gets bad reputation, is those Cisms that people insist on writing, when the language offers much better alternatives.
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 declara…
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.