• Advertisement
Sign in to follow this  

C - Typedef and function pointers

This topic is 4342 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is there any way to typedef a function pointer. Such as... typedef (*fun_ptr)() funptr; funptr ExAmPlE = (*some_function);

Share this post


Link to post
Share on other sites
Advertisement
Yes, but it's still ugly.

typedef void (*funptr)(void);

void some_function(void);

funptr p_some_function = &some_function;

The name of the typedef goes where the name of the variable is when declaring a function pointer variable.

Share this post


Link to post
Share on other sites

funptr p_some_function = &some_function;


The address of operator isn't needed.


funptr p_some_function = some_function;


The function name supplies the address of the function.

Share this post


Link to post
Share on other sites
It's a good coding habit; when you take the address of a pointer to member function, the ampersand is necessary.

Share this post


Link to post
Share on other sites
What does a member function in C look like? I didn't know that C had such things. C++ sure, but C?

Share this post


Link to post
Share on other sites
And your point is that I should ignore good coding habits just because the file has a .c extension? Next you're going to tell me that I shouldn't bother to put

#ifdef __cplusplus
extern "C" {
#endif

in my C header files because C never defines __cplusplus, right?

Share this post


Link to post
Share on other sites
My point is that there are differences between C and C++ and what constitutes a good coding habit in C++ may not hold for C and vice versa.

Share this post


Link to post
Share on other sites
Then choose a different example to pick on. It's still a good coding habit in C, where hungarian notation is much more common and a programmer with experience in either apps or system hungarian will be distracted by an assignment to a pointer type with a non-decorated symbol name not-preceeded by an ampersand. That is to say something like

lpfFunctionPointer = some_function;

will trigger a warning sign in the back of his head while

lpfFunctionPointer = &some_function;

won't.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
And your point is that I should ignore good coding habits just because the file has a .c extension? Next you're going to tell me that I shouldn't bother to put

#ifdef __cplusplus
extern "C" {
#endif

in my C header files because C never defines __cplusplus, right?

Silly question, but...
I see the beginning { but where's the }?

Share this post


Link to post
Share on other sites
Somewhere after your done declaring your functions and before the #endif of the inclusion guard you would put:

#ifdef __cplusplus
}
#endif

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Then choose a different example to pick on.


Chill out man, i'm not picking on you.

Share this post


Link to post
Share on other sites
Quote:
Original post by LessBread
Quote:
Original post by SiCrane
Then choose a different example to pick on.

Chill out man, i'm not picking on you.

No, but you're picking on the example/habbit, which is all he said you were doing :).

And you're both wrong. Anything you do in C (using or not using ampersands) cannot be considered a good programming habit, because you're doing it in C, which is a bad habit in and of itself :-p.

Share this post


Link to post
Share on other sites
Quote:
Original post by I_Smell_Tuna
If there was a better all-purpose language out there people would be using it. ^^


And they are.

If you take a look at the SourceForge.net Software Map....

C ranks 3rd (16485 projects)
C++ ranks 2nd (17440 projects)
Java ranks 1st (17662 projects)

In terms of number of projects developed using that language.

My comment (C = Bad Habit) was in jest since C has a few good uses (it's ABI for APIs, OS level work, and esoteric platform support come to mind) but when you start implying C is the best all-purpouse language, I have to disagree, and feel like supplying at least some anecdotal evidence to the contrary (i.e. which is the most used). I do think C (and C++) are overused, mainly out of habit/familiarity, which was what I was getting at with my original, overstated stab against C. I'm too lazy to form an opinion on Java, although I suspect I'd decide it was overused as well.

Share this post


Link to post
Share on other sites
Since we're debating syntax choices, I actually prefer this syntax:

typedef void Function(void);

void some_function(void);

Function* func = &some_function;


Not a huge deal, but this feels a bit cleaner to me. The typedef isn't as hard to read and there's no need to use hungarian notation since it's obvious that it's a pointer.

Just my 2 cents.

-John

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
for a function with no input you use a 32 bit pointer
such as
void somefunct(void);
void *functptr=somefunct;

but if you need to use input and returns then you must make room for the extra memory needed

int somefunct(int x, char y, float z);
int (*functptr)(int,char,float)=somefunct;

it makes space for 17 bytes = sizeof(int)+sizeof((void *))+sizeof(int)+sizeof(char)+sizeof(float)

typedef struct STUFFSTRUCT{
int (*somefunct)(int,char,float);
} STUFFSTRUCT;

STUFFSTRUCT stuff;
STUFFSTRUCT *stuffptr;

stuffptr->somefunct=somefunct;
int myint=stuffptr->somefunct(1,*"a",3.0f);

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
for a function with no input you use a 32 bit pointer
such as
void somefunct(void);
void *functptr=somefunct;

but if you need to use input and returns then you must make room for the extra memory needed

int somefunct(int x, char y, float z);
int (*functptr)(int,char,float)=somefunct;

it makes space for 17 bytes = sizeof(int)+sizeof((void *))+sizeof(int)+sizeof(char)+sizeof(float)

typedef struct STUFFSTRUCT{
int (*somefunct)(int,char,float);
} STUFFSTRUCT;

STUFFSTRUCT stuff;
STUFFSTRUCT *stuffptr;

stuffptr->somefunct=somefunct;
int myint=stuffptr->somefunct(1,*"a",3.0f);

Huh? You're wrong on just about every point there.

A pointer to a function is typically the same size as the address size of the system, i.e. 32 bits of a 32-bit architecture. This does not change regardless of the arguments and return type of the function (but will change if you're talking C++ and pointers to members).

If you have a function with no parameters and no return type then you use a pointer to a function taking no parameters and returning void, not a void *. You should only really use void * if you need to be able to store arbitrary types in C.

And *"a" is really poor style. ever heard of 'a'?

Σnigma

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
all must bow down and worship the mastermind, for he is the chosen one!
always correct, always right, always so full of himself

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
all must bow down and worship the mastermind, for he is the chosen one!
always correct, always right, always so full of himself

I certainly hope this was a jab at the previous AP, and not Enigma, who is completely correct. If you don't believe him, feel free to run some tests...sizeof works for pointers too.

CM

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
It's a good coding habit; when you take the address of a pointer to member function, the ampersand is necessary.


Quote:
Original post by SiCrane
And your point is that I should ignore good coding habits just because the file has a .c extension?


Really now you're going overboard. This is just a matter of style and of choice. Not having to take the address explicitly is provided as a convenience, just like easily being able to get the address of the first element of an array. I don't see anyone arguing that whenever you pass an array to a function by iterator to the first element that you explicitly go &my_array[0]. If you want to add extra work for yourself, go ahead, but don't push that on I_Smell_Tuna or LessBread or anyone else. That's just silly. Just explain why you dislike one way and let him decide. I usually explicitly write & when taking the address of a function as well, but who cares if you don't. It's not a bad habbit and it's not deprecated, it's just a different style.

Share this post


Link to post
Share on other sites
C++ fun:

typedef bool(func)(bool);

func x;

struct Z {
func method;
};

void nada(){
func* b;
b = &x;
}
bool Z::method(bool) {return true;}
bool x(bool) {return false;}


Why typedef a function pointer, when you can typedef a function?

Share this post


Link to post
Share on other sites
Quote:
Original post by Polymorphic OOP
Really now you're going overboard.

Please notice that I'm critisizing his crappy reasoning in his objection rather than the objection itself. If you want to object don't just say "C++ HABITS BAD!" Give a reason why you think it's bad. LessBread did not advance a valid reason, he just brought forward meaningless generalities that ignored the fact that C and C++ have a sufficiently common lineage that good habits in either language will come from just the fact the other language exists, such as the #ifdef __cplusplus, and decided to make a snide comment rather than justify his stance.

Quote:

Not having to take the address explicitly is provided as a convenience, just like easily being able to get the address of the first element of an array.

And so are conversion operators, and those are rarely good form. And so is ignoring the return value of system calls. Just because the language lets you get away with it doesn't necessarily mean it's a good idea.

Quote:

I don't see anyone arguing that whenever you pass an array to a function by iterator to the first element that you explicitly go &my_array[0].

That isn't an apples to apples comparison. First off, my_array isn't hungarian, so someone using that array name wouldn't be using those kinds of C type matching skills. In any case, if the array name was properly decorated, you wouldn't need the &, because the type prefix is there, which will satisfy the instintictive pattern matching. In contrast, function names are not decorated with type prefixes under Hungarian, so a the & is needed to match against the pointer type assignment of the pointer type.

Now then, if you want to argue that Hungarian, even in C, isn't a good idea, I'll accept that as a rationale that you wouldn't use the & to prefix the function pointer assignment. I'll wonder how you get any meaningful work done in C, but I'll accept it. If you want to say that your doctor ordered you to avoid using & and other symbols because of carpal tunnel, then ok, fine. I'm sure there are other objections I'll find reasonable. However, vague cries of "C++ HABITS BAD!" is not an acceptable objection.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by Polymorphic OOP
Really now you're going overboard.

Please notice that I'm critisizing his crappy reasoning in his objection rather than the objection itself. If you want to object don't just say "C++ HABITS BAD!" Give a reason why you think it's bad. LessBread did not advance a valid reason, he just brought forward meaningless generalities that ignored the fact that C and C++ have a sufficiently common lineage that good habits in either language will come from just the fact the other language exists, such as the #ifdef __cplusplus, and decided to make a snide comment rather than justify his stance.


I started out by simply saying that the & wasn't needed because the fact is that in this situation it's not. Good coding habit might indicate it's use, but it doesn't make it a requirement. Moreover, focusing attention on your statement about pointers to member functions - which don't exist in C - doesn't constitute bringing foward a meaningless generality. Again, that has nothing to do with good coding habits, so I don't see why you felt compelled to retreat to the shelter of good coding habits unless it was to escape acknowledging clear differences in the languages.

And how did this stupid thread get necroed anyway?

Share this post


Link to post
Share on other sites

This topic is 4342 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Advertisement