Macros that affect program flow.

[Derek Atkins]

Quoting Neil Williams <linux at codehelp.co.uk>:

> I've certainly had situations where I had to use the functionality in the
> macro in a function that returned a value. That's why I created the function
> versions in the first place.

That's fine..

>> IMHO this is a DOCUMENTATION problem, not a clarity-of-API issue.
>
> OK.
>
>> Changing the macro not to return would IMNSHO make the developers
>> life more difficult.
>
> True, but you've no problem with having a complimentary function to use when
> the macro cannot be used?

No, I have no objection to the existence of a function and a macro
that complement each other.

>> In my particular case I would just write
>> YET ANOTHER MACRO to use in gnucash, so we don't have duplicated
>> code in every single qof object we define.  So why not just leave
>> that macro, which would get written anyways, in QOF?
>
> I'll reinstate it and leave the function as an alternative.

Works for me.

-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