Subject: RE: Macros (was RE: [hackers-il] Sash)

From: Chen Shapira <[email-masked]>
Date: Mon, 10 Jul 2000 14:53:34 +0200

> I don't think there is extra overhead to an inlined function call as
> compared to a macro. They are basically the same. Of course, inlining
> is no more than a hint to the compiler, not a directive, so you cannot
> be 100% sure that your function will be inlined. On the other hand,
> it might be a good idea to trust the compiler that it has a good
> reason not to inline.

Not knowing whether a function was inlined or not can be annoying while
debugging. Especially on diffrent machines with diffrent compilers.
One of the good reasons to uppercase #define is to know what to expect while
debugging.

and on the same point: "hard" optimizations of code, especially for modern
processors (with pipelines) can cause some wierdities - like blocks of code
disapearing, assigments ignored, and erasing a comment makes the code run
faster...

> If you are sure that none of the bad properties of C macros are
> important, and the design arguments I listed are not important,
> then there is no problem with macros. From your description, it looks
> like you use them in your own code only, and not in an interface, so
> the issues I listed are not relevant to you.

So to some up:
Use macros on Array sizes, and when efficiency is really on the line.
Use inlined functions when efficiency is on the line, but consistancy and
predictability isn't, and consider portability too.
Remember that you are risking the debug 

anything I lost?

---

From: Moshe Zadka <[email-masked]>
Date: Mon, 10 Jul 2000 15:24:13 +0300 (IDT)

> One of the good reasons to uppercase #define is to know what to expect while

The solution is easy: never debug an optimized version of your program. If
your program runs differently with optimizations, it's a bug in the
optimize, anyway. (well, with the exception of relying on undefined
behaviour, which is usually one of the easier bugs to fix)

> Remember that you are risking the debug 

Debugging macros is usually harder, so I'm not really sure if it's clearly
a disadvantage to the debug to inline.
--
Moshe Zadka <[email-masked]>
There is no GOD but Python, and HTTP is its prophet.
http://advogato.org/person/moshez

---

From: Omer Mussaev <[email-masked]>
Date: Mon, 10 Jul 2000 14:34:40 +0300

> Remember that you are risking the debug

In addition to points you had cleared out, there are following important, IMHO,

issues:
being consistent in routine work, since you do overlook the routine pieces
while debugging
being consistent in debugging approach, since you can not learn from random
distribution

Thus, having a set of nice macros to do the job is good, as long as you are
familiar
with those macros, the code they evaluate to and the code that may come out of
optimizer.

On the other side, if you can tell when a function that is marked as inlined is
going
to be inlined indeed, you can surely benefit from the fact that funcion is a
nice thing
to debug.

> ------------------------------------------------------------------------
> CLICK HERE AND START SAVING ON LONG DISTANCE BILLS TODAY!
> http://click.egroups.com/1/6755/12/_/_/_/963230352/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> [email-masked]

--
Omer Mussaev    051-308-214   mailto:[email-masked]
systems programmer, Mercury Interactive/RND/Conduct/core

---

From: Oleg Goldshmidt <[email-masked]>
Date: 10 Jul 2000 20:11:48 +0300

> Remember that you are risking the debug 

My first comment was: Use macros and inlining in the guts of your
implementation, but not in the interface.

-- 
Oleg Goldshmidt <[email-masked]> 
"... We work by wit, and not by witchcraft;
 And wit depends on dilatory time." [Shakespeare]