Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > #undef for function

Reply
Thread Tools

#undef for function

 
 
Sachin
Guest
Posts: n/a
 
      11-25-2005
hi,
Can i use #undef for undefining a function definition and use my
function instead?

like described below

#undef somefunction1

#define somefunction1(a,b) myfunction1(a,b)

If yes what effect will it have on the undefined function code? can i
use the same for standard C library function?

Sachin

 
Reply With Quote
 
 
 
 
Richard Bos
Guest
Posts: n/a
 
      11-25-2005
"Sachin" <(E-Mail Removed)> wrote:

> Can i use #undef for undefining a function definition and use my
> function instead?


You can only use #undef on macros. If your function name has been
#declared as a macro, this will work (FSVO - see below); if it has been
declared as an ordinary function declaration, it will do nothing.

> #define somefunction1(a,b) myfunction1(a,b)


This, however, you can always do. It's hairy, though.

> If yes what effect will it have on the undefined function code?


None. Except that it will never actually be refered to in your code, so
will probably not be linked into the executable.

> can i use the same for standard C library function?


The macro trick, yes. In fact, a compiler's Standard headers often do.
What you cannot portably do is to define a _function_ with the same name
as a library function. Macros, however, are allowed. And even hairier
than re-#defining your own functions. Caveat hacker!

Richard
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      11-25-2005
Richard Bos wrote:

> "Sachin" <(E-Mail Removed)> wrote:
>
>
>>Can i use #undef for undefining a function definition and use my
>>function instead?

>
>
> You can only use #undef on macros. If your function name has been
> #declared as a macro, this will work (FSVO - see below); if it has been
> declared as an ordinary function declaration, it will do nothing.
>
>
>>#define somefunction1(a,b) myfunction1(a,b)

>
>
> This, however, you can always do. It's hairy, though.
>
>
>>If yes what effect will it have on the undefined function code?

>
>
> None. Except that it will never actually be refered to in your code, so
> will probably not be linked into the executable.
>
>
>>can i use the same for standard C library function?

>
>
> The macro trick, yes. In fact, a compiler's Standard headers often do.
> What you cannot portably do is to define a _function_ with the same name
> as a library function. Macros, however, are allowed. And even hairier
> than re-#defining your own functions. Caveat hacker!


If the goal is to replace a Standard function with
your own implementation, note that the macro can only
affect code that is compiled with the macro definition
in place. If your code calls log() and you use a macro
to have it call my_log() instead, that's fine -- but if
the implementation of pow() calls log(), it will still
use log() and not my_log().

In my experience, wholesale overriding of function
names (from the Standard library or from elsewhere in
your own program) is a quick-and-dirty approach. It's
quick and convenient, but eventually the dirt will show.
Better to edit your source so it calls my_log() explicitly;
you'll probably wind up doing so eventually anyhow.

Horror story from a large program I once worked with:
The system-provided malloc() and friends performed poorly
with the amount of memory we used and the patterns in which
it tended to get fragmented. Some bright laddie solved the
problem by implementing a memory-management package more
suited to our program's habits of memory usage, and then
used macros to rename all the malloc(), free(), ... calls
so they went to the replacement package instead. Fine.

... for a while. Then somebody else observed that in
one subsystem of the program there was an atypical pattern
of memory use, where the original malloc() worked better
than the replacement. He added #undef's to the appropriate
set of modules, so calls to malloc() and friends within that
subsystem went to the "real" library while those in other
parts of the program went to our replacement versions. Still
fine.

... for a while longer. Then we decided to add a user-
accessible scripting language to the product, and this entailed
going into all the subsystems and adding various kinds of hooks
to register a system's callable services, provide for callbacks
to user-supplied functions, and so on. Naturally, a lot of
these things involved dynamically-allocated memory -- and when
Subsystem A obtained memory from the "real" malloc() and handed
it to Subsystem B, and then B tried to resize it with the
replacement realloc() ... Well, that's when the fertilizer
hit the air circulator.

Use the #define technique for quick-and-dirty hacks like
introducing instrumented versions during debugging, but don't
rely on it for "serious" code. The code *will* develop, and
the fakery *will* eventually make more trouble than it saved.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Peter Ammon
Guest
Posts: n/a
 
      11-28-2005
Richard Bos wrote:
> "Sachin" <(E-Mail Removed)> wrote:
>
>> Can i use #undef for undefining a function definition and use my
>> function instead?

>
> You can only use #undef on macros. If your function name has been
> #declared as a macro, this will work (FSVO - see below); if it has been
> declared as an ordinary function declaration, it will do nothing.
>
>> #define somefunction1(a,b) myfunction1(a,b)

>
> This, however, you can always do. It's hairy, though.
>
>> If yes what effect will it have on the undefined function code?

>
> None. Except that it will never actually be refered to in your code, so
> will probably not be linked into the executable.


/* Far away, in a distant translation unit, untold riches
* await any hero brave enough to do battle with the evil
* C. P. Reprocessor */

const char* get_the_riches(void) {
return "one million gold coins (chocolate)";
}

/* But oh no! The cackling C. P. Reprocessor has set a devious
* trap for our intrepid hero! If s/he is not careful, s/he shall
* be surely carried off by squawking nasal demons! */

#define get_the_riches() *(int*)(0xCACL)

/* Alas! We begin our story with trepidation.
* Will our hero fall for the trap? Is there no hope for obtaining
* the delicious dubloons? */

int main(void) {

/* Amazing! Our observant hero has deftly applied a powerful
* technique from the CLC sages known as the function pointer.
* The cowed C. P. Reprocessor is defeated! */

(get_the_riches)();

/* Sweet indeed is the ripe, tangy taste of victory.
* Our hero returns successful */

return 0;
}

-Peter

--
Pull out a splinter to reply.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Function versus pointer to function, in context of std::function,huh? Alf P. Steinbach C++ 10 07-27-2011 05:51 AM
Function pointer to void function and int function Giannis Papadopoulos C Programming 5 09-05-2005 09:06 PM
How override ALL function calls? (Is there a "function call function"?) seberino@spawar.navy.mil Python 2 08-01-2005 12:38 PM
write a function such that when ever i call this function in some other function .it should give me tha data type and value of calling function parameter komal C++ 6 01-25-2005 11:13 AM
Passing a C++ object's member function to a C function expecing a function pointer! James Vanns C++ 7 01-21-2004 02:39 AM



Advertisments