Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In the C++ bag of tricks: scoped locks

blog.skanev.org

Post reply on HN
Print view View original

41–50 of 56 posts

Re: In the C++ bag of tricks: scoped locks

#41

Post by rmcclellan »

stinos wrote: post #11
pjmlp wrote: post #9

Earlier 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…

There was a C with Classes.

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

Re: In the C++ bag of tricks: scoped locks

#42

Post by ambrop7 »

I learned about the for loop hack from avr-libc[1][2]. It even does some preprocessor abuse to implement different kinds of atomic and non-atomic sections.

[1] http://www.nongnu.org/avr-libc/user-manual/group__util__atom...

[2] http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/include...

Re: In the C++ bag of tricks: scoped locks

#43

Post by VikingCoder »

JoeAltmaier wrote: post #28
VikingCoder wrote: post #20

You'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.

SUre you could. The{} make it work.

EDIT: I sit corrected. My post is wrong.

No, you can't, and no they don't.

    lock(lk_var) {
        lock(lk_var2) {
            var = var2;
        }
    }
That expands to:

    for(int i=0; (i
You end up with an i scoped inside another i.

Re: In the C++ bag of tricks: scoped locks

#44

Post by VikingCoder »

cjensen wrote: post #35
VikingCoder wrote: post #20

You'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_ID Use __LINE__ to help make the id unique.

Then you still can't forget and do this:

    lock(lk_var) lock(lk_var2)
    {
        lk_var = lk_var2;
    }
Or this:

    lock(lk_var) { lock(lk_var2 { lk_var = lk_var2; } }
Using the pre-processor to solve a regular, every day, hum-drum, solved-a-billion-times RAII problem is bad news.

Re: In the C++ bag of tricks: scoped locks

#46

Post by plorkyeran »

VikingCoder wrote: post #43
JoeAltmaier wrote: post #28

Earlier quoted context omitted.

SUre you could. The{} make it work.

EDIT: I sit corrected. My post is wrong. No, you can't, and no they don't. lock(lk_var) { lock(lk_var2) { var = var2; } } That expands to: for(int i=0; (i You end up with an i scoped inside another i.

C++ has variable shadowing, so that works correctly.

    for (int i = 0; i
prints hello 25 times.

Re: In the C++ bag of tricks: scoped locks

#47

Post by VikingCoder »

plorkyeran wrote: post #46
VikingCoder wrote: post #43

Earlier quoted context omitted.

EDIT: I sit corrected. My post is wrong. No, you can't, and no they don't. lock(lk_var) { lock(lk_var2) { var = var2; } } That expands to: for(int i=0; (i You end up with an i scoped inside another i.

C++ has variable shadowing, so that works correctly. for (int i = 0; i prints hello 25 times.

Oh right. My brain was stuck in another language. Wow, I forgot how much I'd forgotten about C++.

Re: In the C++ bag of tricks: scoped locks

#48

Post by vinkelhake »

dmm wrote: post #40
stinos wrote: post #11

Earlier quoted context omitted.

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.

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.

Re: In the C++ bag of tricks: scoped locks

#49

Post by mpyne »

dllthomas wrote: post #38
dllthomas wrote: post #8

You 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.

longjmp is what the library and standards writers refer to as a "non-local goto" so it's kind of to be expected that it would manage to bypass destructors (I'm not sure how you'd unwind the stack enough to ensure that you've destructed everything created since the corresponding setjmp).

Re: In the C++ bag of tricks: scoped locks

#50

Post by dllthomas »

mpyne wrote: post #49
dllthomas wrote: post #38

Earlier quoted context omitted.

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.

longjmp is what the library and standards writers refer to as a "non-local goto" so it's kind of to be expected that it would manage to bypass destructors (I'm not sure how you'd unwind the stack enough to ensure that you've destructed everything created since the corresponding setjmp).

It's not terribly surprising, but it is worth noting since one use of setjmp/longjmp is to implement exceptions, and one would expect (and desire) destructors to run when unwinding on exceptions.
Post reply on HN