• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
I_Smell_Tuna

C - Typedef and function pointers

25 posts in this topic

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

Share this post


Link to post
Share on other sites
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.
0

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.
0

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.
0

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?
0

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?
0

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.
0

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.
0

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 }?

0

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
0

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.

0

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.
0

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.
0

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
0

Share this post


Link to post
Share on other sites
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);

0

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
0

Share this post


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

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
0

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.
0

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?
0

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.
0

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?
0

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0