This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients Rhamphoryncus, amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti, lemburg, loewis, pitrou, vstinner
Date 2010-11-27.02:20:43
SpamBayes Score 1.1140712e-06
Marked as misclassified No
Message-id <AANLkTinuDRo6iEM9V0KjZ8Hg4sMR1u-2+G3kzuoZkbK7@mail.gmail.com>
In-reply-to <1290822064.34.0.077074392707.issue10542@psf.upfronthosting.co.za>
Content
On Fri, Nov 26, 2010 at 8:41 PM, STINNER Victor <report@bugs.python.org> wrote:
..
> I don't like macro having a result and using multiple instructions using the evil
> magic trick (the ","). It's harder to maintain the code and harder to debug than
> a classical function.
>

You are preaching to the choir.  In fact, my first version
(issue10521-unicode-next.diff attached to  issue10521) used a
function.   I would not worry about implementation at this point,
though.  Let's find the best abstraction first.

> Don't you think that modern compilers are able to inline the code?
> (If not, we may add the right C attribute/keyword)

Not in C.  In C++, I could use a reference to the pointer incremented
by the macro, but in C, I have to use an address.  Once you take an
address of a variable, the compiler will refuse to put it in a
register.  So no, I don't think we can write an ANSI C function that
will be as efficient as the macro.
History
Date User Action Args
2010-11-27 02:20:45belopolskysetrecipients: + belopolsky, lemburg, loewis, amaury.forgeotdarc, Rhamphoryncus, pitrou, vstinner, eric.smith, ezio.melotti
2010-11-27 02:20:43belopolskylinkissue10542 messages
2010-11-27 02:20:43belopolskycreate