By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,248 Members | 882 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,248 IT Pros & Developers. It's quick & easy.

Difference between Macro and Function...

P: n/a
Hi...in some posts i've read...something about using macro rather then
function...but difference ??.

Best regards....

Nov 14 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
lasek <cl**************@acrm.it> scribbled the following:
Hi...in some posts i've read...something about using macro rather then
function...but difference ??.


Have you read a C textbook? Macros and functions are entirely
different. A macro is, in principle, text processing. Like "Find and
replace" in your text editor. Only it happens automatically in the
compiling process, after tokenisation but before lexical analysis.
Functions, OTOH, are genuine C language constructs and not merely text
processing features.
Functions are handled in all states of the compiling process, right up
to linking. The generated object files make a distinction between each
function, and the linker then links all calls between functions
together. In some cases, even the run-time program knows which function
it's currently executing.
None of this is the case with a macro. Once the preprocessor has
expanded the macro, the rest of the process is handled as if the macro
never existed.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"It's not survival of the fattest, it's survival of the fittest."
- Ludvig von Drake
Nov 14 '05 #2

P: n/a
Thanks a lot for your explanation...but i need more info about how a
variable was handled into a macro...in particular someone wrote that
free()..is a macro or function i don't remember so which difference
between a free() macro and a free() function ??....
remember ny head is very strong :-)))
Nov 14 '05 #3

P: n/a
lasek wrote:
Thanks a lot for your explanation...but i need more info about how a
variable was handled into a macro...in particular someone wrote that
free()..is a macro or function i don't remember so which difference
between a free() macro and a free() function ??....
remember ny head is very strong :-)))


free() is the companion function to malloc() and is definitely a function.
Look up the library documentation; malloc is used to request memory space
and initialize a pointer to it and free() is used to release that memory
space.

macros only exist in the text pre-processing stage of compilation during
which they are expanded into code whereas functions are items which exist
throughout the whole process of compilation, link and execution.

I agree with Joona, the best way forward for you is to read a C text book;
you will learn a lot more about this than from ad-hoc queries about it in
this newsgroup.
Nov 14 '05 #4

P: n/a

KOn Thu, 21 Oct 2004, lasek wrote:
Thanks a lot for your explanation...but i need more info about how a
variable was handled into a macro...in particular someone wrote that
free()..is a macro or function i don't remember so which difference
between a free() macro and a free() function ??....
remember ny head is very strong :-)))


Yeah i wrote that it was todo with being able to change the
contents of a variable using a macros but the variable would have
been out of scope for a function to change it.

Take the follwing example.
Which prints
Macro: 1 Func: 0

#include <stdio.h>

#define ADD(x) x++;
void add(int x) { x++; }

int main() {
int macro = 0;
int func = 0;

ADD(macro);
add(func);

printf("Macro: %d Func: %d\n", macro, func);
return 0;
}

Now if you run the same program though the c pre processor which is the
first stage of the compile you actually get the following program
though i cut stdio.h from this output.

After
gcc -E file.c

# 5 "t.c"
void add(int x) { x++; }

int main() {
int macro = 0;
int func = 0;

macro++;;
add(func);

printf("Macro: %d Func: %d\n", macro, func);
return 0;
}

The macro has completly disappeared and the functionallity of it has been
placed into the code. eg Search and Replace

James

--
--------------------------
Mobile: +44 07779080838
http://www.stev.org
2:00pm up 1 day, 26 min, 3 users, load average: 0.01, 0.02, 0.20

Nov 14 '05 #5

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

john blackburn wrote:
| lasek wrote:
|
|
|>Thanks a lot for your explanation...but i need more info about how a
|>variable was handled into a macro...in particular someone wrote that
|>free()..is a macro or function i don't remember so which difference
|>between a free() macro and a free() function ??....
|>remember ny head is very strong :-)))
|
|
| free() is the companion function to malloc() and is definitely a
function.

Maybe, maybe not. It's up to the implementation.

| Look up the library documentation; malloc is used to request memory space
| and initialize a pointer to it and free() is used to release that memory
| space.

free() could be a wrapper around a function that programmers aren't
supposed to call directly, or it might not use a function at all, just
odd compiler magic.

|
| macros only exist in the text pre-processing stage of compilation during
| which they are expanded into code whereas functions are items which exist
| throughout the whole process of compilation, link and execution.

Again, maybe, maybe not. If a function is always inlined, it's not going
to exist through the linking or execution phases.

|
| I agree with Joona, the best way forward for you is to read a C text book;
| you will learn a lot more about this than from ad-hoc queries about it in
| this newsgroup.

This is the only part of your answer I agree with unreservedly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBd7JxKxatjOtX+j0RAgEnAJ9/l+LENz6NiIpg+ga6QPmsYAcidgCcDmkN
Qr45VSpY+7rmlJ8dhAKoHhw=
=hawe
-----END PGP SIGNATURE-----
Nov 14 '05 #6

P: n/a
Chris Barts wrote:
Again, maybe, maybe not. If a function is always inlined, it's not going
to exist through the linking or execution phases.


An interesting point; does that mean that a source debugger will not be able
to trace calls to that function ?
Nov 14 '05 #7

P: n/a
Chris Barts wrote:
john blackburn wrote:
|
| free() is the companion function to malloc() and is definitely a
function.

Maybe, maybe not. It's up to the implementation.

| Look up the library documentation; malloc is used to request memory space
| and initialize a pointer to it and free() is used to release that memory
| space.

free() could be a wrapper around a function that programmers aren't
supposed to call directly, or it might not use a function at all, just
odd compiler magic.


free() is always a function, in any conforming
implementation. free() may *also* be provided as a
macro, at the implementation's discretion, but it must
in any case exist as a function. The same is true of
all the other Standard library functions (other than
those "functions" that are specifically described as
macros, of course).

The following program must compile and run:

#include <stdio.h>
#include <stdlib.h>

static void do_it( void (*func)(void*), void *arg) {
func(arg);
}

static void not_free(void *arg) {
printf ("not_free: arg = %p\n", arg);
}

int main(void) {
void *ptr = malloc(42);
do_it (not_free, ptr);
do_it (free, ptr);
return 0;
}

This example is both contrived and pointless, but
it's not too hard to come up with a scenario in which
using a pointer to free() makes sense. At the risk of
straying from topicality, imagine a suite of programs
that share a single region of memory. The ordinary
malloc() and free() functions won't manipulate the
shared region, so you might well write shared_malloc()
and shared_free() with identical signatures and similar
semantics. Now, let's suppose you want to write a handy
function to release a linked list which might reside in
either shared or ordinary memory:

void liberate_list(Node *list, void (*liberator)(void*)) {
Node *head;
while ((head = list) != NULL) {
list = head->next;
liberator (list);
}
}

Assuming that you know (somehow) whether the list is in
ordinary or in shared memory, you could write

if (in_ordinary_memory)
liberate_list (list, free);
else
liberate_list (list, shared_free);

.... and the C Standard requires that the pointer to the
function free() work as expected.

--
Er*********@sun.com

Nov 14 '05 #8

P: n/a
john blackburn <jo*********************@lintonhealy.co.uk> wrote in message news:<41***********************@news.zen.co.uk>...
Chris Barts wrote:
Again, maybe, maybe not. If a function is always inlined, it's not going
to exist through the linking or execution phases.


An interesting point; does that mean that a source debugger will not be able
to trace calls to that function ?

In practice it depends on how clever the compiler and debugger are
with regards to inline functions. I've seen debuggers that can step
through an inlined function as well as any other, and I've seen
debuggers that can't see anything but a single statement.
Nov 14 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.