which is the better path

[Dan Pop]

I negelected the parentheses accidentally.
My own policy is that it's better to use them
around all macro arguments, than it is to figure out
just exactly when they are or aren't useful.

Attaboy! Why bother to engage your brain when you can avoid it by
resorting to mechanical coding?

Beware: some day it could become rusty...

Dan

 

[Joona I Palaste]

Is it because the (my_array+42) bit has type T* instead of type
T[foo]? What does it take to change the type? Addition,
parantheses, or both? What types do these have?
(my_array)
my_array+0
(my_array+0)
my_array+42

Ever considered actually learning C? This issue has been beaten to death
in this very newsgroup.

This to a man who's answered (hopefully correctly) dozens of newbie
questions on comp.lang.c? Of course, you know more about C than I do,
but that's no excuse to imply I haven't learned C.
Seeing as you're Dan Pop, I refuse to take offense.

 

[Martin Dickopp]

Few expressions yield an array type. Among them are the (possible
parenthesesed) identifier referring to the array,

Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

Precisely because of 6.3.2.1#3, which you have quoted yourself, `array'
is converted to a pointer type here. However, if you use it in a context
where no such conversion takes place, e.g. as the operand of the
`sizeof' operator, you'll see that `array' has array type.

Could we have some examples?

Sure. Given

struct {
char a [3];
} foo;

`foo.a' has array type. You can again see this by applying the `sizeof'
operator to it, so that no automatic conversion to a pointer type takes
place.

3 Except when it is the operand of the sizeof operator or the
unary & operator, or is a string literal used to initialize an
array, an expression that has type ``array of type'' is converted
to an expression with type ``pointer to type'' that points to
the initial element of the array object and is not an lvalue.


You've made up far too much...

I don't think so.

 

[Dan Pop]

Few expressions yield an array type. Among them are the (possible ^^^^^^^^^^^^^
parenthesesed) identifier referring to the array,

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

In the underlined text above. In the absence of *any* explicitly
mentioned exception, it says that my code assigns an array to a pointer.

Precisely because of 6.3.2.1#3, which you have quoted yourself, `array'
is converted to a pointer type here. However, if you use it in a context
where no such conversion takes place, e.g. as the operand of the
`sizeof' operator, you'll see that `array' has array type.

Where have you mentioned that in your previous post? Can't see *any*
mention of sizeof there and this is one of the only 2 contexts where
the identifier retains its array type. In *all* the other cases it
doesn't, therefore your statement above is patently wrong.

Could we have some examples?

Sure. Given

struct {
char a [3];
} foo;

`foo.a' has array type.

Nope. The type of this expression is pointer to char.

You can again see this by applying the `sizeof'
operator to it, so that no automatic conversion to a pointer type takes
place.

What is the type of this expression if I don't apply the sizeof
(or unary &) operator to it? It is an expression on its own, right?

I don't think so.

Read the FAQ. It handles the issue, too. But, if you insist on your
stupid position, I can give you one more example: dereferencing a pointer
to an array.

Dan

 

[Dan Pop]

Is it because the (my_array+42) bit has type T* instead of type
T[foo]? What does it take to change the type? Addition,
parantheses, or both? What types do these have?
(my_array)
my_array+0
(my_array+0)
my_array+42

Ever considered actually learning C? This issue has been beaten to death
in this very newsgroup.

This to a man who's answered (hopefully correctly) dozens of newbie
questions on comp.lang.c?

You've been here long enough to be still treated as a newbie and the
issue has been discussed a zillion times since you joined the newsgroup.

It's also covered by the FAQ.

Of course, you know more about C than I do,
but that's no excuse to imply I haven't learned C.

The implication comes directly from the fact that you have asked a newbie
question that is answered in the FAQ. What else could I imply from that?

Dan

 

[Joona I Palaste]

You've been here long enough to be still treated as a newbie and the
issue has been discussed a zillion times since you joined the newsgroup.

I can't parse that. "Ling enough to be still treated as a newbie"?
You mean that people who have just discovered this newsgroup (and thus
spent very little time on it) can't be treated as newbies?

It's also covered by the FAQ.

The implication comes directly from the fact that you have asked a newbie
question that is answered in the FAQ. What else could I imply from that?

So I asked *one* question that is answered in the FAQ. Does that
automatically nullify all my C knowledge?
I repeat, if you weren't Dan Pop, I'd be insulted.

 

[Martin Dickopp]

Few expressions yield an array type. Among them are the (possible ^^^^^^^^^^^^^
parenthesesed) identifier referring to the array,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

In the underlined text above. In the absence of *any* explicitly
mentioned exception, it says that my code assigns an array to a
pointer.

The absence of explicitly mentioned exceptions is to interpreted as
"unless a conversion rule applies". Any other interpretation would be
outright stupid. For example, I wouldn't say that the expression `5' has
type `unsigned int', despite the fact that it is converted to `unsigned
int' in some contexts (e.g. `1U + 5').

and certain expressions involving the . or the -> operator.

Could we have some examples?

Sure. Given

struct {
char a [3];
} foo;

`foo.a' has array type.

Nope. The type of this expression is pointer to char.

You seem to miss the fact that a expression can also be part of a larger
expression. As a complete expression, `foo.a' has pointer type, but this
is not necessarily the case if it is part of a larger expression.

What is the type of this expression if I don't apply the sizeof
(or unary &) operator to it? ^^

Pointer to char. However, since I'm confident you understand what the
English word "if" means, you should see that this is not relevant
to the question what the type of the expression is.

 

[Mark McIntyre]

I can't parse that. "Ling enough to be still treated as a newbie"?

I'd assume that Dan's english failed him here, and he meant to say "you've
not been here long enough to no longer be considered a newby".

FWIW I disagree, you're virtually one of the experts round here.

You mean that people who have just discovered this newsgroup (and thus
spent very little time on it) can't be treated as newbies?

Thats the only way to read what Dan actually wrote...

So I asked *one* question that is answered in the FAQ. Does that
automatically nullify all my C knowledge?

Obviously. After all this group only exists to answer unanswerable
questions, and regulars are not allowed to ask questions, they should know
the answers.

I repeat, if you weren't Dan Pop, I'd be insulted.

Good move.

 

[Mark McIntyre]

Darklight wrote:

int sumarray(int array2[], int array3[]);

You don't need this if you put the whole function first.

True, but prototypes are a Good Thing, and to be encouraged.

Disagree. Unnecessary prototypes are a maintenance nightmare and
ought to be eliminated.

Frankly I don't write unnecesary ones. By experience even in single-file
projects I use headers w/ prototypes because Sods Law says that what today
is a single file shall tomorrow be part of an encrypted code library of
1000 files.

It should never be necessary to write down the same information twice.

Sure. How /do/ you safely call a function from outside the same translation
unit, w/o a prototype?

Also any function not to be accessed outside the source file should be marked static.

Sure. Right up until you realise you need it outside the TU...

This has been the way of things since 1066.

Well, since 1989 anyway. When /was/ static introduced?

 

[Joona I Palaste]

I'd assume that Dan's english failed him here, and he meant to say "you've
not been here long enough to no longer be considered a newby".

FWIW I disagree, you're virtually one of the experts round here.

Thanks, but I disagree. I'm a regular, not an expert.

Thats the only way to read what Dan actually wrote...

Yes, I agree. Can Dan explain it or will he finally have to admit to
making a mistake?

Obviously. After all this group only exists to answer unanswerable
questions, and regulars are not allowed to ask questions, they should know
the answers.

Non sequitur. This group also exists to answer answerable, but *seldom*
asked questions. But regulars are not allowed to ask frequently asked
questions.

 

[Dan Pop]

I can't parse that. "Ling enough to be still treated as a newbie"?
You mean that people who have just discovered this newsgroup (and thus
spent very little time on it) can't be treated as newbies?

Nope, I meant that people who have been here as long as you have can't
be treated as newbies. If my statement was poorly phrased, mea culpa,
English is my third language.

So I asked *one* question that is answered in the FAQ. Does that
automatically nullify all my C knowledge?

It casts a huge question mark over the depth of your C knowledge. Hence
my advice, that you may want to seriously consider instead of loudly
protest...

Dan

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:


Few expressions yield an array type. Among them are the (possible ^^^^^^^^^^^^^
parenthesesed) identifier referring to the array,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

In the underlined text above. In the absence of *any* explicitly
mentioned exception, it says that my code assigns an array to a
pointer.

The absence of explicitly mentioned exceptions is to interpreted as
"unless a conversion rule applies".

But, since a conversion rule applies *by default* here, your statement
is still patently false. Or, at best, highly misleading to the beginner.

Could we have some examples?

Sure. Given

struct {
char a [3];
} foo;

`foo.a' has array type.

^^^^^^^^^^^^^^^^^^^^^
Nope. The type of this expression is pointer to char.

You seem to miss the fact that a expression can also be part of a larger
expression. As a complete expression, `foo.a' has pointer type, but this
is not necessarily the case if it is part of a larger expression.

We are talking about the expression "foo.a", which, according to you,
has array type. Not about any other expression containing "foo.a" as
a subexpression.

Pointer to char.

Yet, you have claimed that it is array of char, in the underlined text
above. Could you make up your mind?

Dan

 

[Arthur J. O'Dwyer]

You've been here long enough to be still treated as a newbie and the
issue has been discussed a zillion times since you joined the newsgroup.

I can't parse that. "L[o]ng enough to be still treated as a newbie"?
You mean that people who have just discovered this newsgroup (and thus
spent very little time on it) can't be treated as newbies?

Nope, I meant that people who have been here as long as you have can't
be treated as newbies. If my statement was poorly phrased, mea culpa,
English is my third language.

Then you meant, "You've been here too long to be treated as a newbie
anymore." ["To be still treated" is probably correct English grammar, but
it sounds really stilted.]
FWIW, I (a native English speaker) assumed that you'd meant "You've
been here a short enough amount of time to still be treated as a newbie,"
and just used "long" rather than "short" for ironic effect. Anyway,
just a grammar flame...

-Arthur

 

[Christopher Benson-Manica]

I can't parse that. "Ling enough to be still treated as a newbie"?

For the record, I can't parse *that*. Unless you were trying your
hand at humor, which is usually lost on Dan anyway.

 

[Christopher Benson-Manica]

I'm a regular, not an expert.

That makes me shudder to think on what *I* might be. With the
exception of your "u" post (a forgiveable error), you're definitely at
least one of the more knowledgeable and trustworthy regulars, FWIW.

 

[Martin Dickopp]

(e-mail address removed) (Dan Pop) writes:


Few expressions yield an array type. Among them are the (possible
^^^^^^^^^^^^^
parenthesesed) identifier referring to the array,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

In the underlined text above. In the absence of *any* explicitly
mentioned exception, it says that my code assigns an array to a
pointer.

The absence of explicitly mentioned exceptions is to interpreted as
"unless a conversion rule applies".

But, since a conversion rule applies *by default* here, your statement
is still patently false.

The conversion rule only applies if the expression is not the operand of
the `sizeof' or unary & operator.

Whether or not it applies by default *here* (by which you mean your
example above, I presume) is not relevant, since I never claimed that
it doesn't apply in your example.

Or, at best, highly misleading to the beginner.

If your point were that my statement is correct, but misleading, I would
have to agree: It would have been clearer if I had explicitly mentioned
the conversion rule. But that's hypothetical, since that is not your
point.

Could we have some examples?

Sure. Given

struct {
char a [3];
} foo;

`foo.a' has array type.
^^^^^^^^^^^^^^^^^^^^^
Nope. The type of this expression is pointer to char.

You seem to miss the fact that a expression can also be part of a larger
expression. As a complete expression, `foo.a' has pointer type, but this
is not necessarily the case if it is part of a larger expression.

We are talking about the expression "foo.a", which, according to you,
has array type. Not about any other expression containing "foo.a" as
a subexpression.

We are talking about the expression `foo.a' in general. Not about a
specific context in which it appears, not even if the context is that
the expression is not part of a larger expression.

Yet, you have claimed that it is array of char, in the underlined text
above. Could you make up your mind?

In assuming that my mind is not made up, you seem to miss the fact that
"What is the type of this expression?" and "What is the type of this
expression if I don't apply the sizeof (or unary &) operator to it?" are
different questions, and therefore the answers can also be different.

 

[Joona I Palaste]

For the record, I can't parse *that*. Unless you were trying your
hand at humor, which is usually lost on Dan anyway.

Typo. "Ling" should have been "long".

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Parthenogenetic procreation in humans will result in the founding of a new
religion."
- John Nordberg

 

[Christopher Benson-Manica]

Disagree. Unnecessary prototypes are a maintenance nightmare and
ought to be eliminated. It should never be necessary to write
down the same information twice. Also any function not to be
accessed outside the source file should be marked static.

This has been the way of things since 1066.

I didn't think the Normans even *had* protypes... I always thought
they wrote their database programs with all 0's. (sorry, Dilbert
reference...)

 

[John Bode]

Question:
Write a function named sumarrays() that accepts two arrays that are the same
size. The function should add each element in the array together and place
the values in the thrid array.

Which answer is the better practice;

The second, but with some caveats.

/*EX9.C*/
#include<stdio.h>
#define MAX 5

int array2[MAX] = {1,2,3,4,5};
int array3[MAX] = {6,7,8,9,10};

You should avoid file scope (global) variable definitions where
possible. For a toy program like this it's no big deal, but as you
start writing larger, more complex programs, they become a pain to
manage effectively.

int sumarray(int array2[], int array3[]);

It's a good idea to pass the array size as a separate parameter along
with the arrays themselves. One of C's quirks is that it doesn't pass
arrays by value (regardless of what the prototype looks like it's
saying); rather, a pointer to the first element of the array gets
passed to the function, so it's impossible to determine the size of an
array that's passed as an argument. Therefore, if you want to sum
arrays of any size (not just a constant size determined at compile
time), you will need to pass the size as a separate parameter:

int sumarray (int *array2, int *array3, size_t arrsize);

int main(void)
{
sumarray(array2,array3);
return 0;
}

int sumarray(int array2[], int array3[])
{
int ctr;
int total[MAX];

for(ctr = 0; ctr < MAX; ctr++)
{
total[ctr] = array2[ctr] + array3[ctr];
printf("Total %d\n",total[ctr]);
}
return total[count];
}

Are you sure you're doing what you mean here? You're returning a
single int value, not an array. Secondly, you're attempting to
subscript with an undeclared variable (count). Thirdly, if you mean
'ctr' instead of 'count', you're attempting to return the value
immediately following the last element of the array, which is probably
not what you want.

____________________________________________
/* EX9-1.C*/
#include<stdio.h>
#define SIZE 5

void sumarray(int [], int []);
int main(void)
{
int a[SIZE] = {1,2,3,4,5};
int b[SIZE] = {6,7,8,9,10};

Better. a and b are limited to auto scope. You should still pass the
array size as a separate parameter.

sumarray(a,b);
return 0;
}

void sumarray(int first[], int second[])
{
int total[SIZE];
int ctr;

for(ctr = 0; ctr < SIZE; ctr++)
{
total[ctr] = first[ctr] + second[ctr];
printf("Total %d\n",total[ctr]);
}

}

It would probably be handy to have the summed array available to other
routines, so you should ideally return it to the caller. Since
functions can't have array return types, you need to either return a
pointer to the array (which means dynamically allocating the array,
which you probably don't want to get into yet), or passing the sum
array as yet another parameter. Here's an example:

#include <stdio.h>

void sumarray (int *arr1, int *arr2, int *sumarr, size_t arrsize)
{
size_t i;

for (i = 0; i < arrsize; i++)
{
sumarr = arr1 + arr2;
}
}

int main (void)
{
int a1[5] = {0,2,4,6,8};
int a2[5] = {1,3,5,7,9};
int sum[5];
int i;

sumarray (a1, a2, sum, 5);
for (i = 0; i < sizeof sum / sizeof sum[0]; i++)
{
printf ("sum[%d]: %d\n", sum);
}
return 0;
}

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:


Few expressions yield an array type. Among them are the (possible
^^^^^^^^^^^^^
parenthesesed) identifier referring to the array,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

In the underlined text above. In the absence of *any* explicitly
mentioned exception, it says that my code assigns an array to a
pointer.

The absence of explicitly mentioned exceptions is to interpreted as
"unless a conversion rule applies".

But, since a conversion rule applies *by default* here, your statement
is still patently false.

The conversion rule only applies if the expression is not the operand of
the `sizeof' or unary & operator.

I.e. in the general case. Hence, it is the default.

Whether or not it applies by default *here* (by which you mean your
example above, I presume) is not relevant, since I never claimed that
it doesn't apply in your example.

You never mentioned it *at all*, which means, by implication, that it
never happens.

If your point were that my statement is correct, but misleading, I would
have to agree: It would have been clearer if I had explicitly mentioned

Your statement is NOT correct, period.

the conversion rule. But that's hypothetical, since that is not your
point.

My point is that the *only* possible inference from your answer is the
one I've made. Therefore, your answer is incorrect.

An exception that is not *explicitly* mentioned in a reply, does NOT
exist. And your reply does NOT mention any exception. Or am I missing
something?

Dan