I'm trying to learn C on my own and, apparently, my brain went on
vacation somewhere. I just can't figure out how to parse the following
function call:
"void fillDeck( Card * const wDeck, const char * wFace[], const char *
wSuit[])"
Card is aliased before that call with:
"typedef struct card Card"
the card structure is define before that with:
"struct card {
const char *face;
const char *suit;
};"
and the paramter passed via wDeck is defined in main as:
"Card deck[ 52 ]" /* an array of 52 card structures */
Looking around the web, this seems to be a fairly standard example
program. In that call to fillDeck, the first parameter seems to parse
as sending a pointer to an instance of type Card (in this case, the
address to the first Card in the 52 element array of Cards) but making
sure the receiving function can't modify it (with the "const"
modifier). I've got to be reading that wrong, because the sole purpose
of fillDeck is to modify wDeck by filling it using a for loop:
"for ( i = 0; i <= 51; i++ ) {
wDeck[ i ].face = wFace[i % 13 ];
...."
Can anyone shed some light on how I'm misreading that function call?
Probably related to it: can anyone tell me why the dereferencing
operator * is separated from its variable? IOW, why
"void fillDeck( Card * const wDeck,..."
instead of
"void fillDeck( Card *const wDeck,..." (*const instead of * const)
or, heck,
"void fillDeck( Card const *wDeck,..." (const *wDeck instead of * const
wDeck)? 18 2057
"DaveLessnau" <dl******@mail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com... I'm trying to learn C on my own and, apparently, my brain went on vacation somewhere. I just can't figure out how to parse the following function call:
"void fillDeck( Card * const wDeck, const char * wFace[], const char * wSuit[])"
That's not a function call, but a declaration (which is
missing the terminating semicolon. It declares:
'fillDeck' is a function which does not return a value, and
takes three arguments:
1. A constant pointer ('constant' meaning that its value is not
allowed to be changed) to an object of type 'wDeck'.
2. A pointer to a constant object of type 'char'.
3. A pointer to a constant object of type 'char'. Card is aliased before that call with:
"typedef struct card Card"
the card structure is define before that with:
"struct card { const char *face; const char *suit; };"
and the paramter passed via wDeck is defined in main as:
"Card deck[ 52 ]" /* an array of 52 card structures */
The name of an array, used in a value context (one of which
is passing it as a function argument), automatically converts
to a pointer to its first element. So the call:
fillDeck(deck, /* other args */);
causes the address of 'deck[0]' (the first array element)
to be passed as the first argument. Looking around the web, this seems to be a fairly standard example program. In that call to fillDeck, the first parameter seems to parse as sending a pointer to an instance of type Card (in this case, the address to the first Card in the 52 element array of Cards) but making sure the receiving function can't modify it (with the "const" modifier).
It must not modify the pointer value, modifying what
it points to is fine.
I've got to be reading that wrong,
Perhaps.
because the sole purpose of fillDeck is to modify wDeck by filling it using a for loop:
Yes, the elements of the array are modified, but the pointer
containing its address is not. "for ( i = 0; i <= 51; i++ ) { wDeck[ i ].face = wFace[i % 13 ]; ..."
Can anyone shed some light on how I'm misreading that function call?
See above.
Probably related to it: can anyone tell me why the dereferencing operator * is separated from its variable? IOW, why
"void fillDeck( Card * const wDeck,..."
instead of
"void fillDeck( Card *const wDeck,..." (*const instead of * const)
That's a syntactical issue. The whitespace is not germane. Equally
valid, and having the same meaning:
Card*const wDeck
Card * const wDeck
Card
*
const
wDeck
/* etc */ or, heck,
"void fillDeck( Card const *wDeck,..." (const *wDeck instead of * const wDeck)?
Now you've changed the syntax. The placement of the asterisk
with respect to the const modifier affects the meaning.
Using type 'int' for simplicity's sake:
int *p; /* non-const pointer to non-constant int */
const int *p; /* non-const pointer to constant int */
int const *p; /* non-const pointer to constant int */
int * const p; /* constant pointer to non-constant int */
const int * const p; /* constant pointer to constant int */
int const * const p; /* constant pointer to constant int */
Note that in the case where 'const' appears to the left of
the asterisk, placing it before or after the 'int' does
not change the meaning.
-Mike
Thanks. Amongs my key misunderstandings was "Yes, the elements of the
array are modified, but the pointer containing its address is not." I
was mixing up the addresses and the values. Also, your table at the
end showing the differences between constant/non-constant pointers to
constant/non-constant values helped tremendously.
Thanks again.
Groovy hepcat Mike Wahler was jivin' on Mon, 10 Jan 2005 23:30:23 GMT
in comp.lang.c.
Re: Parse "Card * const wDeck"'s a cool scene! Dig it! "DaveLessnau" <dl******@mail.com> wrote in message news:11**********************@c13g2000cwb.googleg roups.com... "void fillDeck( Card * const wDeck, const char * wFace[], const char * wSuit[])"
'fillDeck' is a function which does not return a value, and takes three arguments:
1. A constant pointer ('constant' meaning that its value is not allowed to be changed) to an object of type 'wDeck'.
That's a const pointer to type Card. wDeck is the name of the
parameter.
[Snip.] Probably related to it: can anyone tell me why the dereferencing operator * is separated from its variable? IOW, why
"void fillDeck( Card * const wDeck,..."
instead of
"void fillDeck( Card *const wDeck,..." (*const instead of * const)
That's a syntactical issue. The whitespace is not germane. Equally valid, and having the same meaning:
It's a style issue, rather than a syntactical one. The syntax allows
either. As you say, the white space is not germane.
--
Dig the even newer still, yet more improved, sig! http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
DaveLessnau wrote: I'm trying to learn C on my own [but] apparently, my brain went on vacation somewhere. I just can't figure out how to parse the following function call:
void fillDeck(Card*const wDeck, const char* wFace[], const char* wSuit[]);
Card is aliased before that call with:
typedef struct Card Card;
the card structure is define before that with:
struct Card { const char *face; const char *suit; };
and the paramter passed via wDeck is defined in main as:
Card deck[ 52 ]; // an array of 52 card structures
Looking around the web, this seems to be a fairly standard example program.
Unfortunately, it is a very poor design as well as a very common design.
In that call to fillDeck, the first parameter seems to parse as sending a pointer to an instance of type Card (in this case, the address to the first Card in the 52 element array of Cards) but making sure the receiving function can't modify it (with the "const" modifier). I've got to be reading that wrong, because the sole purpose of fillDeck is to modify wDeck by filling it using a for loop:
for (size_t i = 0; i < 52; ++i) { wDeck[i].face = wFace[i%13]; // ...
Can anyone shed some light on how I'm misreading that function call? Probably related to it: can anyone tell me why the dereferencing operator * is separated from its variable? IOW, why
void fillDeck(Card*const wDeck, ...
instead of
void fillDeck(Card *const wDeck, ... // (*const instead of * const)
or, heck,
void fillDeck(Card const *wDeck, ... // (const *wDeck instead of * const wDeck)?
A better design would be
typedef struct Deck {
Card deck[52];
} Deck;
Deck Deck_create(const char* wFace[], const char*wSuit[]) {
Deck deck;
for (size_t i = 0; i < 52; ++i) {
deck.deck[i].face = wFace[i%13];
// ...
}
return deck;
}
Which you could call like this:
Deck wDeck = Deck_create(wFace, wSuit);
instead of like this:
Deck wDeck;
fillDeck(wDeck.deck, wFace, wSuit);
"Peter "Shaggy" Haywood" <ph******@alphalink.com.au.NO.SPAM> wrote in
message news:41**************@news.alphalink.com.au... Groovy hepcat Mike Wahler was jivin' on Mon, 10 Jan 2005 23:30:23 GMT in comp.lang.c. Re: Parse "Card * const wDeck"'s a cool scene! Dig it!
"DaveLessnau" <dl******@mail.com> wrote in message news:11**********************@c13g2000cwb.googleg roups.com... "void fillDeck( Card * const wDeck, const char * wFace[], const char * wSuit[])" 'fillDeck' is a function which does not return a value, and takes three arguments:
1. A constant pointer ('constant' meaning that its value is not allowed to be changed) to an object of type 'wDeck'.
That's a const pointer to type Card. wDeck is the name of the parameter.
Oops. :-) [Snip.]
Probably related to it: can anyone tell me why the dereferencing operator * is separated from its variable? IOW, why
"void fillDeck( Card * const wDeck,..."
instead of
"void fillDeck( Card *const wDeck,..." (*const instead of * const) That's a syntactical issue. The whitespace is not germane. Equally valid, and having the same meaning:
It's a style issue, rather than a syntactical one.
Style of syntax, OK? :-)
The syntax allows either. As you say, the white space is not germane.
-Mike
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cr**********@nntp1.jpl.nasa.gov... A better design would be
typedef struct Deck { Card deck[52]; } Deck;
IMO even better would be to dump the array and use a container.
-Mike
"Mike Wahler" <mk******@mkwahler.net> writes: "E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:cr**********@nntp1.jpl.nasa.gov... A better design would be
typedef struct Deck { Card deck[52]; } Deck;
IMO even better would be to dump the array and use a container.
What do you mean by "container"? Are you thinking of C++?
--
Keith Thompson (The_Other_Keith) ks***@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.
Keith Thompson wrote: Mike Wahler writes:
E. Robert Tisdale wrote:
A better design would be
typedef struct Deck { Card deck[52]; } Deck; IMO even better would be to dump the array and use a container.
What do you mean by "container"?
A container is an object that contains objects of some type.
An array is an example of a container.
A list is a container.
A queue is a container.
I believe that Mike is correct.
A container for a Deck of Card's would be even better
but I didn't want to confuse the issue
which I believe was the return value.
Are you thinking of C++?
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes: Keith Thompson wrote:
Mike Wahler writes:
E. Robert Tisdale wrote:
A better design would be
typedef struct Deck { Card deck[52]; } Deck;
IMO even better would be to dump the array and use a container. What do you mean by "container"?
A container is an object that contains objects of some type. An array is an example of a container. A list is a container. A queue is a container.
Thanks, but I was asking Mike Wahler what *he* meant by "container".
--
Keith Thompson (The_Other_Keith) ks***@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.
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "Mike Wahler" <mk******@mkwahler.net> writes: "E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:cr**********@nntp1.jpl.nasa.gov... A better design would be
typedef struct Deck { Card deck[52]; } Deck;
IMO even better would be to dump the array and use a container.
What do you mean by "container"? Are you thinking of C++?
Yes, I seem to be lost again, dammit. :-)
Thanks for the heads-up.
-Mike
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cs**********@nntp1.jpl.nasa.gov... Keith Thompson wrote:
Mike Wahler writes:
E. Robert Tisdale wrote:
A better design would be
typedef struct Deck { Card deck[52]; } Deck;
IMO even better would be to dump the array and use a container.
What do you mean by "container"?
A container is an object that contains objects of some type. An array is an example of a container. A list is a container. A queue is a container.
I believe that Mike is correct. A container for a Deck of Card's would be even better but I didn't want to confuse the issue which I believe was the return value.
No, Keith's assumption was correct, I was talking about
a C++ standard library container, and forgot where I was.
-Mike
Mike Wahler wrote:
.... snip ... No, Keith's assumption was correct, I was talking about a C++ standard library container, and forgot where I was.
Failure to discriminate between a ladies tea and a cathouse has
been known to lead to embarassing moments.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
E. Robert Tisdale wrote: Keith Thompson wrote:
Mike Wahler writes:
E. Robert Tisdale wrote:
A better design would be
typedef struct Deck { Card deck[52]; } Deck;
IMO even better would be to dump the array and use a container.
What do you mean by "container"?
A container is an object that contains objects of some type. An array is an example of a container. A list is a container. A queue is a container.
Arrays are objects.
Lists and queues aren't objects.
--
pete
"pete" <pf*****@mindspring.com> wrote in message
news:41***********@mindspring.com... E. Robert Tisdale wrote:
<snip> >IMO even better would be to dump the array and use a container.
What do you mean by "container"?
A container is an object that contains objects of some type. An array is an example of a container. A list is a container. A queue is a container.
The above is C++ or rather OOA/D jargon, which does not (or very poorly)
translate into the sequential approach of imperative languages like C.
Arrays are objects. Lists and queues aren't objects.
Hence the confusion.
On Tue, 11 Jan 2005 13:43:59 -0800, E. Robert Tisdale wrote: Keith Thompson wrote:
.... What do you mean by "container"?
A container is an object that contains objects of some type. An array is an example of a container. A list is a container. A queue is a container.
I believe that Mike is correct. A container for a Deck of Card's would be even better
By your definition a container for a deck of cards would be able to hold a
number of decks of cards, which is probably not needed. Here Deck is in
effect a container for cards, although not with all the OO baggage.
Lawrence
"CBFalconer" <cb********@yahoo.com> wrote in message
news:41***************@yahoo.com... Mike Wahler wrote: ... snip ... No, Keith's assumption was correct, I was talking about a C++ standard library container, and forgot where I was.
Failure to discriminate between a ladies tea and a cathouse has been known to lead to embarassing moments.
Unless the tea is held in said cathouse. :-)
(Some amusing metaphors spring to mind, but
decorum prohibits me expressing them here. :-) )
-Mike
Lawrence Kirby wrote: E. Robert Tisdale wrote:
Keith Thompson wrote:
What do you mean by "container"?
A container is an object that contains objects of some type. An array is an example of a container. A list is a container. A queue is a container.
I believe that Mike is correct. A container for a Deck of Card's would be even better
By your definition a container for a deck of cards would be able to hold a number of decks of cards, which is probably not needed. Here Deck is in effect a container for cards, although not with all the OO baggage.
I would gladly carry "the OO baggage" in this case.
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cs**********@nntp1.jpl.nasa.gov... By your definition a container for a deck of cards would be able to hold
a number of decks of cards, which is probably not needed. Here Deck is in effect a container for cards, although not with all the OO baggage.
I would gladly carry "the OO baggage" in this case.
Porter! porter! Here, take this and follow me to
gate 17, please.
:-)
-Mike This discussion thread is closed Replies have been disabled for this discussion. Similar topics
2 posts
views
Thread by Joshua Beall |
last post: by
|
1 post
views
Thread by bucher |
last post: by
|
3 posts
views
Thread by H. S. |
last post: by
|
3 posts
views
Thread by Alexander Farber |
last post: by
|
4 posts
views
Thread by C. J. Clegg |
last post: by
|
9 posts
views
Thread by Gary |
last post: by
|
26 posts
views
Thread by =?gb2312?B?wNbA1rTzzOzKpg==?= |
last post: by
|
20 posts
views
Thread by liujiaping |
last post: by
|
4 posts
views
Thread by adam.timberlake |
last post: by
| | | | | | | | | | |