[Gnucash-changes] r13390 - gnucash/trunk/lib/libqof/qof - Implement QOF_COMMIT_EDIT_PART2 as a function instead of a macro.

[Derek Atkins]

Chris Shoemaker <c.shoemaker at cox.net> writes:

> On Sun, Feb 26, 2006 at 11:57:19AM -0500, Derek Atkins wrote:
>> This patch could break a lot of code in lots of places because there
>> is code that expects that QOF_COMMIT_EDIT_PART2() could return
>> (exiting the /caller/ of the macro), but the new macro wont return
>> out of the caller anymore.
>
> Yes, this change would certainly break certain uses of this macro.
> However, of all the uses, only one falls in to that case.  I'll fix
> that one case to use the function directly.

Like I said earlier, the point of the macro was to reduce duplicated
code.  Nowhere is there any rule against macros that affect program
flow.  It's perfectly legal, and in many cases quite convenient, to
have a macro that causes the current function to return.

It's certainly better that having duplicated code in 20 places.

> BTW, eliminating a macro that affects control flow wasn't my
> motivation, but it is a fringe benefit.  It's *horrible* practice and
> we fortunately only depend(ed) on it in one place.

Why is it a "*horrible* practice"?  I'd rather have convenience macros
that affect program flow than have to change code in twenty different
places when some particular behavior changes.

For the record, I wrote it as a macro specifically because I wanted it
to affect program flow.  It was just "luck" that many places didn't
need to use that functionality.

> -chris

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available