Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

crash on close cbp project (rev 7773)

<< < (3/6) > >>

oBFusCATed:

--- Quote from: MortenMacFly on February 05, 2012, 04:09:49 pm ---Yes, because if you set the macros to nothing, they will expand to truly nothing. Otherwise they would expand to a semicolon. the latter I believe is "more weird". ;-)

--- End quote ---
No, it is not, because you (almost) never look at the preprocessed code :)
Also is there any particular reason to set the macros to nothing in this case?

MortenMacFly:

--- Quote from: oBFusCATed on February 05, 2012, 04:13:17 pm ---Also is there any particular reason to set the macros to nothing in this case?

--- End quote ---
Yes, if you have followed the discussion with Thomas, instead of locking / unlocking which is excellent for debugging, the better way would be to use a locker object. In that case, the "Unlock" macro has to / will expand to nothing.

oBFusCATed:
I doubt you'll be able the switch to a locker object with just a macro:)

MortenMacFly:

--- Quote from: oBFusCATed on February 05, 2012, 04:21:09 pm ---I doubt you'll be able the switch to a locker object with just a macro:)

--- End quote ---
Why not? The first macro will expand to wxMutexLocker(BLAH) and the second to nothing. That's it.

oBFusCATed:
But then you have no guarantee that the mutex will be unlocked at the correct place/time.


--- Code: ---CC_LOCK(s_lock);
... code 1 ...
CC_UNLOCK(s_lock);
... code 2 ...
CC_LOCK(s_lock);
... code 3 ...
CC_UNLOCK(s_lock);

--- End code ---
Code 2 is executed under a lock and before code3 you have a double locking problem (probably a dead lock).

Navigation

[0] Message Index

[#] Next page

[*] Previous page