Hello All,
I am trying to pass a struct to a function. How would that best be
accomplished?
Thanks,
Bill
I am trying to pass a struct to a function. How would that best be
accomplished?
Thanks,
Bill
-
-
Re: How to pass a struct to a function
Bill wrote:
Assuming that the function has an argument of the right structure type,I am trying to pass a struct to a function. How would that best be
accomplished?
write an expression evaluating to your struct -- the name of a variable
of that struct type is popular -- in the appropriate argument position
in a call to that function.
What am I missing?
--
The second Jena users conference -- be there or have rdf:type geometric:Squar e.
"What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck Affair/
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
-
Re: How to pass a struct to a function
On Mar 28, 9:48 am, Chris Dollin <chris.dol...@h p.comwrote:Here is what I have so far, won't even compile. And I am:Bill wrote:>I am trying to pass a struct to a function. How would that best be
accomplished?
Assuming that the function has an argument of the right structure type,
write an expression evaluating to your struct -- the name of a variable
of that struct type is popular -- in the appropriate argument position
in a call to that function.
>
What am I missing?
>
--
The second Jena users conference -- be there or have rdf:type geometric:Squar e.
"What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck Affair/
>
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
#include <stdio.h>
#include <string.h>
int AddEntry(struct entry);
struct{
char fName[51];
char lName[51];
char Phone[13];
}Entry;
int main()
{
int retCode;
Entry.fName = "Fred";
Entry.lName = "Flintstone ";
Entry.Phone = "123-456-7890";
retCode = AddEntry(Entry) ;
}
//int AddEntry(char fName[51], char lName[51], char Phone[13])
int AddEntry(struct entry)
{
FILE *fp;
fp = fopen("AppData. dat", "a"); /* open file for writing */
fprintf(fp, "%s", fName); /* write some info */
fprintf(fp, "\t");
fprintf(fp, "%s", lName);
fprintf(fp, "\t");
fprintf(fp, "%s", Phone);
fprintf(fp, "\n");
fclose(fp); /* close the file */
return 1;
}
Comment
-
Re: How to pass a struct to a function
On Mar 28, 9:44 am, "Bill" <bill.war...@al lstate.comwrote :#include <stdio.h>Hello All,
>
I am trying to pass a struct to a function. How would that best be
accomplished?
>
Thanks,
>
Bill
#include <string.h>
/**
* Structure definition has to be visible to
* all functions that use it.
*/
struct foo {
int blah;
char blech[10];
double blurga;
};
/**
* Struct type passed by value.
*/
void printFoo(struct foo myStruct)
{
printf("%d, %s, %f\n", myStruct.blah, myStruct.blech,
myStruct.blurga );
}
/**
* Struct type passed by reference
*/
void printFooByRef(s truct foo *myStruct)
{
printf("%d, %s, %f\n", myStruct->blah, myStruct->blech, myStruct-}>blurga);
int main(void)
{
struct foo theStruct;
theStruct.blah = 1;
strcpy(theStruc t.blech, "ACK!");
theStruct.blurg a = 3.14159;
printFoo(theStr uct);
printFooByRef(& theStruct);
return 0;
}
Comment
-
Re: How to pass a struct to a function
Bill said:
<snip>
You'll want to make this:Here is what I have so far, won't even compile. And I am:
>
#include <stdio.h>
#include <string.h>
>
int AddEntry(struct entry);
>
struct{
char fName[51];
char lName[51];
char Phone[13];
}Entry;
struct entry {
char fName[51];
char lName[51];
char Phone[13];
} Entry;
or, more clearly:
struct entry {
char fName[51];
char lName[51];
char Phone[13];
}; /* defines a type called 'struct entry' */
struct entry Entry; /* creates an object of that type */
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
email: rjh at the above domain, - www.
Comment
-
Re: How to pass a struct to a function
In article <1175093050.949 285.161350@n76g 2000hsh.googleg roups.com>, "Bill"
<bill.warner@al lstate.comwrote :The way I did it was as follows:-I am trying to pass a struct to a function. How would that best be
accomplished?
a) define a type
typedef void (*FPOINT)(void)
b) define the structure including a pointer to the function to be called
typedef struct
{
.......
FPOINT simfunc; /* the function */
.....
.....
}function inst;
This way there can be as many functions as you like and as many different
instances as you like - all with different data.
When you call the function as follows:-
func-simfunc()
The structured data goes with it.
John
--
_ _______________ _______________ ___________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_/ 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk
Comment
-
Re: How to pass a struct to a function
"Bill" <bill.warner@al lstate.comwrite s:Please don't quote signatures. Trim quoted material to what'sOn Mar 28, 9:48 am, Chris Dollin <chris.dol...@h p.comwrote:>Bill wrote:>>I am trying to pass a struct to a function. How would that best be
accomplished?
>Assuming that the function has an argument of the right structure type,
>write an expression evaluating to your struct -- the name of a variable
>of that struct type is popular -- in the appropriate argument position
>in a call to that function.
>>
>What am I missing?
necessary for your followup to make sense to someone who hasn't see
the parent article.
Your program doesn't use anything from <string.h>, so this #includeHere is what I have so far, won't even compile. And I am:
>
#include <stdio.h>
#include <string.h>
directive is unnecessary. But, as we'll see, it *should*, so yes,
you'll need this #include directive.
At this point, you haven't declared a type "struct entry". Becauseint AddEntry(struct entry);
it's an incomplete struct type, there are some interesting details
about how this declaration is handled, but that's not relevant; this
is not what you want, and you'll need to fix it.
Now you declare a struct object, but you *still* haven't declared astruct{
char fName[51];
char lName[51];
char Phone[13];
}Entry;
type "struct entry". In fact, you don't declare "struct entry" (other
than as an incomplete type) anywhere in your program. What you've
done here is (a) declared an anonymous struct type, and (b) declared a
single object of that type, named "Entry". If all you want is a
single object, that might be sensible thing to do (or you might as
well declare the members as individual variables). But since you want
to pass it as an argument to a function, you should give the type a
name when you declare it.
Change the above declaration to:
struct entry {
char fName[51];
char lName[51];
char Phone[13];
};
and place it *above* the function declaration, so AddEntry knows what
a "struct entry" is. (More precisely, so the compiler knows what a
"struct entry" is when it processes the function declaration.)
(There's another common style that uses a typedef to give a structure
type a one-word name, but I won't get into that here.)
This creates a *named* type, called "struct entry". Note that it only
declares the type; unlike your original declaration, it doesn't
declare a variable of that type. I made that change because the
object (note: I'm using the terms "object" and "variable"
interchangeably ) doesn't need to be global (more precisely, at file
scope). You can declare it inside the main() function.
Ok, but "int main(void)" is more explicit, and is preferred.int main()
Add here:{
int retCode;
struct entry Entry;
Though you might pick a more descriptive name than "Entry". In a real
program, you're probably going to have more than one object of that
type; each one should have a name that describes that object.
If the members were char* pointers, you could do this, but you can'tEntry.fName = "Fred";
Entry.lName = "Flintstone ";
Entry.Phone = "123-456-7890";
assign to an array. Read section 6 of the comp.lang.c FAQ,
<http://www.c-faq.com/>. You can use the strcpy function here:
strcpy(Entry.fN ame, "Fred");
You don't do anything with the value of retCode. That's ok in a smallretCode = AddEntry(Entry) ;
sample program, but in a real program you'll probably want to do
something based on the result.
You should add "return 0;" before the closing brace of the main
function. It's not strictly required, but it's a good idea. You can
do more elaborate things if you want your program to report whether it
succeeded or failed.
}It's best to avoid "//" comments when posting to Usenet. The C99>
//int AddEntry(char fName[51], char lName[51], char Phone[13])
standard supports them, as do most exsting pre-C90 compilers (at least
in some mode), but they're not 100% portable. Also, Usenet software
commonly wraps long lines. Wrapping a "//" comment typically creates
a syntax error; a wrapped "/* ... */" comment typically is still a
valid comment.
In a function declaration (without a body), you only need the types ofint AddEntry(struct entry)
the parameters; the names are optional. In a function definition,
though, you have to provide names for the parameters, so the body of
the function can refer to them.
Let's call it "arg", for "argument":
int AddEntry(struct entry arg)
You're opening the file for appending, not just writing. Either{
FILE *fp;
>
fp = fopen("AppData. dat", "a"); /* open file for writing */
mention that in the comment, or just drop the comment; any reader who
doesn't know what fopen() does is going to have bigger problems.
Comments like that are ok if you're trying to convince someone that
you know what you're doing, but they're not useful in providing actual
information to the reader.
You don't check whether the fopen() call succeeded. It returns a null
pointer (NULL) if it fails. Always check the result of fopen(), and
take some corrective action if it fails -- even if the corrective
action is to terminate the program with an error message.
The references to fName, lName, and Phone assume that they exist asfprintf(fp, "%s", fName); /* write some info */
fprintf(fp, "\t");
fprintf(fp, "%s", lName);
fprintf(fp, "\t");
fprintf(fp, "%s", Phone);
fprintf(fp, "\n");
individual variables. They don't; they're members of a structure.
Now that that structure has been declared properly, you can refer to
them as arg.fName and so forth.
These six printf statements can be reduced to one:
fprintf(fp, "%s\t%s\t%s \n", arg.fName, arg.lName, arg.Phone);
fprintf() can fail. Combining the six printfs into one makes it
easier to check the result, and take some corrective action on
failure.
Another vacuous coment.fclose(fp); /* close the file */
And fclose() can also fail. Consult the documentation for each of
these functions to find out how they indicate failure; it's different
for different functions.
You always return the same value. If that's all you're going to do,return 1;
the function might as well not return a value at all (i.e., you can
declare it to return void rather than int). Or you can use the return
value to indicate to the caller whether the function succeeded or
failed. Decide how you want to do this, and *document* your
convention, for example in a comment associated with the function
declaration. One convention is to return 0 (false) for failure, 1
(true) for success. Another convention, since there are more ways to
fail than to succeed, is to return 0 for success, and some non-zero
value for failure; different values can indicate different kinds of
failure.
The values 51 and 13 are "magic numbers"; it's not at all clear what}
they mean, or why you chose those particular values. Declare them as
constants, probably as preprocessor macros:
#define NAME_MAX 51
#define PHONE_MAX 13
Finally, you should learn to understand your compiler's diagnostic
messages (which you didn't show us). The details will vary depending
on which compiler you're using, but any decent compiler will print
messages that will tell an experienced programmer what the problem is,
though they may not always be obvious to a newbie. (They may not be
obvious to an experienced programmer if the compiler writer has
written poor messages, which does happen.)
*Before* you start correcting your code, compile it again, and pay
close attention to what your compiler tells you. If possible, set
options on your compiler to tell it to print lots of verbose warnings.
You'll probably find that your compiler's error and warning messages
will tell you just about everything about your code that I've just
told you, *if* you can understand how it's telling you. Take a look
at what your compiler tells you, and compare it to what I've told you
here.
Note that syntax errors can often confuse the compiler, and make some
of the following messages meaningless. A syntax error is, for
example, something like a missing semicolon or a mismatched
parenthesis. For other errors, like type mismatches, it's generally
easier for the compiler to recover and guess what you meant in the
following code. Fix the syntax errors first, so you can get better
messages for other errors. The very first error message the compiler
gives you is the most reliable; following messages may be the result
of the compiler's confusion.
(For gcc, "-ansi -pedantic -Wall -W -O3" is a good start. ("-O3"
enables optimization; a side effect is that the compiler performs more
analysis and can detect more problems in your code.) For other
compilers, check your documentation.)
--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Comment
-
Re: How to pass a struct to a function
Bill wrote:By naming some instance of the struct in the call to the function.>
I am trying to pass a struct to a function. How would that best
be accomplished?
What's the problem?
struct foo blah = { whatever };
int foulupon(struct foo s) {
/* operate on s */
return something
}
....
if (foulupon(blah) ) ...;
/* blah unchanged, becasue it was passed by value */
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Comment
-
Re: How to pass a struct to a function
On Wed, 28 Mar 2007 21:49:10 BST, Mr John FO Evans
<mijas@orpheusm ail.co.ukwrote in comp.lang.c:
Missing semicolon.In article <1175093050.949 285.161350@n76g 2000hsh.googleg roups.com>, "Bill"
<bill.warner@al lstate.comwrote :>I am trying to pass a struct to a function. How would that best be
accomplished?
The way I did it was as follows:-
>
a) define a type
typedef void (*FPOINT)(void)
Syntax error.b) define the structure including a pointer to the function to be called
>
typedef struct
{
.......
>
FPOINT simfunc; /* the function */
>
.....
.....
}function inst;
NO data goes with it. You just called a function accepting noThis way there can be as many functions as you like and as many different
instances as you like - all with different data.
>
When you call the function as follows:-
>
func-simfunc()
>
The structured data goes with it.
arguments, passing no arguments to it.
If you know what you are talking about, try again to actually explain
it correctly.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
Comment
-
Re: How to pass a struct to a function
On 28 Mar, 22:49, Keith Thompson wrote an excellent article,
most of which I agree with, containing a few items on
which I'd like to comment:
Ack..I'll go into it. I used to always typedefs structs, and(There's another common style that uses a typedef to give a structure
type a one-word name, but I won't get into that here.)
in retrospect I believe it was simply because I didn't understand
the syntax well enough to realize it was unnecessary. Personally,
I find typedef'ing a struct to be a heinous act which should
NOT be done. Declarations of the form "FOO a;" are hardly
clearer than "struct foo a;", and it is impossible to tell
from "FOO a" whether a is a pointer or not--you need to
go look at the typedef. Sometimes it is appropriate to
typedef a struct, but usually it is not.
I disagree that such a comment is "OK". When I see>fp = fopen("AppData. dat", "a"); /* open file for writing */
You're opening the file for appending, not just writing. Either
mention that in the comment, or just drop the comment; any reader who
doesn't know what fopen() does is going to have bigger problems.
Comments like that are ok if you're trying to convince someone that
you know what you're doing, but they're not useful in providing actual
information to the reader.
comments such as that, I tend to think that the
programmer in fact doesn't know what (s)he's doing.
If you happen to have a line of the form:
"data_fp[0] = fopen(data_path[4], "r");", then it would
be appropriate to add a comment explaining why
the fourth data file is being opened on the
zeroth file pointer, but completely pointless comments
serve to show a lack of knowledge on the part of
the programmer. Note that this should NOT serve
as a reason to avoid commenting your code. I have
often been very happy to see comments of the form:
/*
* I'm doing the following because I believe this will
* have this effect..., but I'm not entirely sure.
*/
(These are usually my own comments, BTW). When I
find comments like that, I know that the reason the code
looks a little weird is because the author was
in fact uncertain. There's nothing more annoying
than coming accross a section of arcane code that
you spend 40 hours analyzing only to discover that
it could have easily been re-written in 3 lines
and that all of the side-effects were in fact
totally unnecessary baggage that resulted from
a poor original design. Those 40 hours would
have been saved if a simple comment had been there
stating that the author was clueless and the
code should be redesigned from scratch.
Also annoying is the style which includes:
} /* end of i loop */
If your block is so large that you can't see the
opening brace, a comment doesn't fix the problem.
--
Bill Pursell
Comment
-
Re: How to pass a struct to a function
"Bill Pursell" <bill.pursell@g mail.comwrites:[...]On 28 Mar, 22:49, Keith Thompson wrote an excellent article,
most of which I agree with, containing a few items on
which I'd like to comment:[...]>>>fp = fopen("AppData. dat", "a"); /* open file for writing */
>You're opening the file for appending, not just writing. Either
>mention that in the comment, or just drop the comment; any reader who
>doesn't know what fopen() does is going to have bigger problems.
>Comments like that are ok if you're trying to convince someone that
>you know what you're doing, but they're not useful in providing actual
>information to the reader.
I disagree that such a comment is "OK". When I see
comments such as that, I tend to think that the
programmer in fact doesn't know what (s)he's doing.
If you happen to have a line of the form:
"data_fp[0] = fopen(data_path[4], "r");", then it would
be appropriate to add a comment explaining why
the fourth data file is being opened on the
zeroth file pointer, but completely pointless comments
serve to show a lack of knowledge on the part of
the programmer. Note that this should NOT serve
as a reason to avoid commenting your code.
Fair enough.
A context where an obvious comment might make a bit more sense is in
an introductory tutorial. For example, you might have something like:
fp = fopen("foobar.d at", "w") /* open file for writing */
the first time you introduce the fopen() function.
--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Comment
-
Re: How to pass a struct to a function
On Mar 29, 1:32 am, Keith Thompson <k...@mib.orgwr ote:That is the case. I'm a programmer, but do not use C on a regular"Bill Pursell" <bill.purs...@g mail.comwrites:[...]On 28 Mar, 22:49, Keith Thompson wrote an excellent article,
most of which I agree with, containing a few items on
which I'd like to comment:>fp = fopen("AppData. dat", "a"); /* open file for writing */>You're opening the file for appending, not just writing. Either
mention that in the comment, or just drop the comment; any reader who
doesn't know what fopen() does is going to have bigger problems.
Comments like that are ok if you're trying to convince someone that
you know what you're doing, but they're not useful in providing actual
information to the reader.>I disagree that such a comment is "OK". When I see
comments such as that, I tend to think that the
programmer in fact doesn't know what (s)he's doing.
If you happen to have a line of the form:
"data_fp[0] = fopen(data_path[4], "r");", then it would
be appropriate to add a comment explaining why
the fourth data file is being opened on the
zeroth file pointer, but completely pointless comments
serve to show a lack of knowledge on the part of
the programmer. Note that this should NOT serve
as a reason to avoid commenting your code.
[...]
>
Fair enough.
>
A context where an obvious comment might make a bit more sense is in
an introductory tutorial. For example, you might have something like:
>
fp = fopen("foobar.d at", "w") /* open file for writing */
>
the first time you introduce the fopen() function.
>
--
Keith Thompson (The_Other_Keit h) k...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"- Hide quoted text -
>
- Show quoted text -
basis. I'm a .Net guy. I got fingered for this gig and enjoy
teaching. But I also want to make sure I present quality info to
students. My professional code doesn't contain idiot comments. What
I ultimately present to students does get cleaned up. I was hoping I
could get some advice on a simple method to pass a struct to a
function. Thanks.
Comment
-
Re: How to pass a struct to a function
On 29 Mar 2007 04:22:35 -0700, "Bill" <bill.warner@al lstate.com>
wrote:
Huh? What is the case? Are you commenting on Keith's signature block?>>Keith Thompson (The_Other_Keit h) k...@mib.org <http://www.ghoti.net/~kst>
>San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
>"We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"- Hide quoted text -
>>
>- Show quoted text -
>That is the case. I'm a programmer, but do not use C on a regular
>basis. I'm a .Net guy. I got fingered for this gig and enjoy
>teaching. But I also want to make sure I present quality info to
>students. My professional code doesn't contain idiot comments. What
>I ultimately present to students does get cleaned up. I was hoping I
>could get some advice on a simple method to pass a struct to a
>function. Thanks.
Your comments should be interspersed with properly trimmed quotes, and
signature blocks should not be quoted unless you're commenting on
them. See most of the other posts in this group for examples.
Using Google rather than a real news reader makes this more difficult,
but not impossible.
--
Al Balmer
Sun City, AZ
Comment
-
Re: How to pass a struct to a function
Bill Pursell wrote:.... snip ...>I try to always annotate the closing '}' of a function with the>
Also annoying is the style which includes:
} /* end of i loop */
If your block is so large that you can't see the
opening brace, a comment doesn't fix the problem.
function name. This serves to make the demarcation between
functions obvious. I also add a specific interfunction demarcation
comment. E.g.:
int foo(...) {
...
} /* foo */
/* ------------------ */
char *bar(...) {
...
which I find enhances readability. I will annotate long loops with
?* while(foo) */ etc., although I agree that there is a strong
possibility it should call another routine.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Comment
-
Re: How to pass a struct to a function
CBFalconer <cbfalconer@yah oo.comwrites:
Doesn't a closing brace at the left margin, on an otherwise blankI try to always annotate the closing '}' of a function with the
function name. This serves to make the demarcation between
functions obvious.
line, do the same thing? I would suspect that making the line
longer actually makes it harder to see the end of a function,
because then the form of the line is less distinct.
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein
Comment
Comment