Zitat von Vicente Botet Escriba <vicente.botet@wanadoo.fr>:
One try-catch block instead on two :)
has no advantage.
On TBoost.STM the restat operation is less expensive than creating a transaction.
do you wish to change/extend the ResourceManager concept because of this? in what way?
Sometimes the user can not throw an exception because s/he is handling already an exception, on it is in a no throw function destructor, ... In these cases it will be more convenient to just state that the transaction could only abort.
ok. what does the call to transaction::commit() then do? throw? which exception?
This use is simple for the user perspective and efficient from the implementation point of view. I respect you wish to provide only a macro, but IMO there are more use cases than one on which macros could be used.
ok, my main point is that TRANSACT_ATOMIC/TRANSACT_COMMIT should be not made more complicated in favor of more sophisticated use cases. if there is a seperate set of macros, that's fine. but if these should not be STM-specific but usable with Boost.Transact in general, please describe what changes to the TransactionManager/ResourceManager concepts and the basic_transaction class you require for implementing the macros. (one of which would be reusing transaction objects, as discussed above. what else?)
With my macros or with yours, the user needs to be aware that the transaction block is included on a internal loop.
not necessarily. when you "return" from a transaction scope, commit() isn't reached, so the transaction is not committed. in this case: do{ return 1; }while(a++ == 5); you don't expect that the side effects of the while-clause still takes effect. so I don't see a problem in the behaviour that "return" omits the commit either. you could of course offer a macro like COMMIT_AND_RETURN.