473,320 Members | 2,112 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

which is the better path

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;

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

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

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];
}
____________________________________________
/* 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};

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]);
}

}

Nov 14 '05 #1
52 2227
Darklight wrote:
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 third array ?
Which answer is the better practice;

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

int array2[MAX] = {1,2,3,4,5};
int array3[MAX] = {6,7,8,9,10};
Why are those arrays globals ?
int sumarray(int array2[], int array3[]);
You don't need this if you put the whole function first.
int main(void)
{
sumarray(array2,array3);
summarray() returns an int, why do you do with it ?
And where is the result ?
return 0;
}

int sumarray(int array2[], int array3[])
{ The size of arrays shoud be passed as a param. And why 'array2' and
'array3' ? Where is 'array1' ?
int ctr; One usually uses 'i' for loop indices.
int total[MAX]; (bis) The size of arrays shoud be passed as a param
for(ctr = 0; ctr < MAX; ctr++)
{
total[ctr] = array2[ctr] + array3[ctr];
printf("Total %d\n",total[ctr]);
What is this printf() doing here ?
}
return total[count];
Er... did you ever try and *compile* this code ?
}
____________________________________________
/* 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}; Ok, they are at least at the right place
sumarray(a,b);
Where is the result ?
return 0;
}

void sumarray(int first[], int second[])
{ array size should be passed as a parameter. int total[SIZE];
int ctr; same as above
for(ctr = 0; ctr < SIZE; ctr++)
{
total[ctr] = first[ctr] + second[ctr];
printf("Total %d\n",total[ctr]); same as above }

}


Both are somewhat ugly. Try again.
Tips :
- pass the array len and the 'result' array as params
the proto for sumarray() should look like :
int * sumarray(int first[], int second[], int total[], size_t len);

- move the printf() out of sumarray()
- use 'i' for the loop indice

HTH
Bruno

Nov 14 '05 #2
Darklight <ng******@netscape.net> scribbled the following:
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.
That's all? The function doesn't need to DO anything with the third
array?
Which answer is the better practice; /*EX9.C*/
#include<stdio.h>
#define MAX 5 int array2[MAX] = {1,2,3,4,5};
int array3[MAX] = {6,7,8,9,10};
int sumarray(int array2[], int array3[]); 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];
count is undeclared.
}
____________________________________________
/* 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}; 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]);
} }


I like the second one better, because it has the arrays local to main()
instead of global.
You don't appear to use the return value from sumarray() in the first
one for anything either.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge
Nov 14 '05 #3
On Tue, 17 Feb 2004 21:33:11 +0100, in comp.lang.c , Bruno Desthuilliers
<bd*****************@free.quelquepart.fr> wrote:
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.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #4
Mark McIntyre wrote:
On Tue, 17 Feb 2004 21:33:11 +0100, in comp.lang.c , Bruno Desthuilliers
<bd*****************@free.quelquepart.fr> wrote:

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.

You're right.

<OP>
I take this comment back.
</OP>

Bruno

Nov 14 '05 #5
Darklight wrote:

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;

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

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

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];
}
____________________________________________
/* 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};

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]);
}

}


/* EX9-1.C*/

#include <stdio.h>

#define N(A) (sizeof A / sizeof *A)

void sumarray(int *, int *, int *, size_t);

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

sumarray(a, b, total, N(a));
return 0;
}

void sumarray(int *first, int *second, int *total, size_t size)
{
while (size-- != 0) {
*total = *first++ + *second++;
printf("Total %d\n", *total);
++total;
}
}

--
pete
Nov 14 '05 #6
pete wrote:

Darklight wrote:

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;

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

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

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];
}


/* EX9-1.C*/

#include <stdio.h>

#define N(A) (sizeof A / sizeof *A)

void sumarray(int *, int *, size_t);

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

sumarray(a, b, N(a));
return 0;
}

void sumarray(int *first, int *second, size_t size)
{
while (size-- != 0) {
printf("Total %d\n", *first++ + *second++);
}
}

--
pete
Nov 14 '05 #7
In <c0**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> scribbled the following:
On Wed, 18 Feb 2004, Joona I Palaste wrote:
Anupam <an**************@persistent.co.in> scribbled the following:
> pete <pf*****@mindspring.com> wrote:
> > #define N(A) (sizeof A / sizeof *A)
>
> Please note that it is inadvisable to write a macro and leave it
> unprotected by surrounding brackets.

You mean that it should be like this?
#define N(A) (sizeof (A) / sizeof *(A))
If so, then I agree with you.

Devil's advocate: Pete's way works, as long as you only use the
macro in its intended form:

T my_array[foo];
something involving N(my_array);

Certainly if you try to do

something involving N(my_array+42);

it will fail horribly, but then Joona's modification would also fail
horribly given that input. So in this case it's a choice between
icky behavior on wrong input and... icky behavior on wrong input.


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.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #8
In <ho********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> writes:
On Tue, 17 Feb 2004 21:33:11 +0100, in comp.lang.c , Bruno Desthuilliers
<bd*****************@free.quelquepart.fr> wrote:
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.


Non sequitur. If the function's prototype definition precedes its usage,
no declaration is needed. This reduces the program's maintenance
overhead.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #9
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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?
and certain expressions involving the . or the -> operator.
Could we have some examples?

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.
Anything I've forgotten?


You've made up far too much...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #10
In <40***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #11
Dan Pop <Da*****@cern.ch> scribbled the following:
In <c0**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
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.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"A bicycle cannot stand up by itself because it's two-tyred."
- Sky Text
Nov 14 '05 #12
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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?

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.
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. 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.
Anything I've forgotten?


You've made up far too much...


I don't think so.
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #13
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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.
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.
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 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?
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.
Anything I've forgotten?


You've made up far too much...


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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #14
In <c1**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Dan Pop <Da*****@cern.ch> scribbled the following:
In <c0**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #15
Dan Pop <Da*****@cern.ch> scribbled the following:
In <c1**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Dan Pop <Da*****@cern.ch> scribbled the following:
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.
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. 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?


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.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd
Nov 14 '05 #16
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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". 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.
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #17
On 18 Feb 2004 19:17:21 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:
Dan Pop <Da*****@cern.ch> scribbled the following:
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"?


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


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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #18
On Wed, 18 Feb 2004 05:08:59 GMT, in comp.lang.c , CBFalconer
<cb********@yahoo.com> wrote:
Mark McIntyre wrote:
<bd*****************@free.quelquepart.fr> wrote:
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?

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #19
Mark McIntyre <ma**********@spamcop.net> scribbled the following:
On 18 Feb 2004 19:17:21 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:
Dan Pop <Da*****@cern.ch> scribbled the following:
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"? 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.
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...
Yes, I agree. Can Dan explain it or will he finally have to admit to
making a mistake?
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?


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.


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

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"There's no business like slow business."
- Tailgunner
Nov 14 '05 #20
In <c1**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Dan Pop <Da*****@cern.ch> scribbled the following:
In <c1**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Dan Pop <Da*****@cern.ch> scribbled the following:
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.


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


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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #21
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:

In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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.
What is the type of this expression if I don't apply the sizeof
(or unary &) operator to it? ^^


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #22

On Thu, 19 Feb 2004, Dan Pop wrote:

Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Dan Pop <Da*****@cern.ch> scribbled the following:
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
Nov 14 '05 #23
Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:
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 *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #24
Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:
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.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #25
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

Da*****@cern.ch (Dan Pop) writes:

> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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.
What is the type of this expression if I don't apply the sizeof
(or unary &) operator to it? ^^


Pointer to char.


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.
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #26
Christopher Benson-Manica <at***@nospam.cyberspace.org> scribbled the following:
Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:
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.


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

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Parthenogenetic procreation in humans will result in the founding of a new
religion."
- John Nordberg
Nov 14 '05 #27
CBFalconer <cb********@yahoo.com> spoke thus:
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...)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #28
Darklight <ng******@netscape.net> wrote in message news:<c0**********@hercules.btinternet.com>...
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[i] = arr1[i] + arr2[i];
}
}

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[i]);
}
return 0;
}
Nov 14 '05 #29
In <c1**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:
Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:
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.


On the contrary, *successful* attempts at humour are seldom lost on me.
It's Joona that regularly misses them.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #30
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:

In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

>Da*****@cern.ch (Dan Pop) writes:
>
>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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.
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


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #31
Dan Pop <Da*****@cern.ch> scribbled the following:
In <c1**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:
Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:
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.

On the contrary, *successful* attempts at humour are seldom lost on me.
It's Joona that regularly misses them.


Dan is as fond of calling me humourless as he is of calling Mark
McIntyre an idiot. It's those mannerisms of his that makes him amazingly
funny. As long as you don't take them seriously, that is. Dan Pop's
advice about C, though - THAT should be taken seriously.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The question of copying music from the Internet is like a two-barreled sword."
- Finnish rap artist Ezkimo
Nov 14 '05 #32
Joona I Palaste wrote:
.... snip ...
Dan is as fond of calling me humourless as he is of calling Mark
McIntyre an idiot. It's those mannerisms of his that makes him
amazingly funny. As long as you don't take them seriously, that
is. Dan Pop's advice about C, though - THAT should be taken
seriously.


In the last week or so something seems to have driven him from his
normal jolly carefree self, and he has become especially intent on
picking, shall we say, nits.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #33
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

Da*****@cern.ch (Dan Pop) writes:

> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
>
>>Da*****@cern.ch (Dan Pop) writes:
>>
>>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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.


Your implication is wrong. There are millions of things which I never
mention, but which still happen.
My point is that the *only* possible inference from your answer is the
one I've made. Therefore, your answer is incorrect.


I've already explained why your inference is incorrect, but feel free
to believe what you must.
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #34
In <c1**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Dan Pop <Da*****@cern.ch> scribbled the following:
In <c1**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:
Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:
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.

On the contrary, *successful* attempts at humour are seldom lost on me.
It's Joona that regularly misses them.


Dan is as fond of calling me humourless as he is of calling Mark
McIntyre an idiot. It's those mannerisms of his that makes him amazingly
funny.


Those "mannerisms" are based on reading your (and Mark McIntyre's) posts
ever since you joined the newsgroup. And they will change, as soon as I
detect a systematic change in the input.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #35
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:

In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

>Da*****@cern.ch (Dan Pop) writes:
>
>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
>>
>>>Da*****@cern.ch (Dan Pop) writes:
>>>
>>>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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.


Your implication is wrong. There are millions of things which I never
mention, but which still happen.


But they're irrelevant to our issue. The point is that your statement
is wrong by not mentioning the things that are highly relevant to it.

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #36
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

Da*****@cern.ch (Dan Pop) writes:

> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
>
>>Da*****@cern.ch (Dan Pop) writes:
>>
>>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
>>>
>>>>Da*****@cern.ch (Dan Pop) writes:
>>>>
>>>>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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.


Your implication is wrong. There are millions of things which I never
mention, but which still happen.


But they're irrelevant to our issue. The point is that your statement
is wrong by not mentioning the things that are highly relevant to it.

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.


No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #37
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:

In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

>Da*****@cern.ch (Dan Pop) writes:
>
>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
>>
>>>Da*****@cern.ch (Dan Pop) writes:
>>>
>>>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
>>>>
>>>>>Da*****@cern.ch (Dan Pop) writes:
>>>>>
>>>>>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> 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.

Your implication is wrong. There are millions of things which I never
mention, but which still happen.


But they're irrelevant to our issue. The point is that your statement
is wrong by not mentioning the things that are highly relevant to it.

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.


No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.


This is what you actually implied, by not mentioning the possibility of
exceptions.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #38
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.
No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.


This is what you actually implied, by not mentioning the possibility of
exceptions.


In <c1**********@sunnews.cern.ch>, you replied to my statement
Given

struct {
char a [3];
} foo;

`foo.a' has array type.


with the statement
Nope. The type of this expression is pointer to char.


You didn't mention any exceptions. Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator, or does your "exceptions which are not mentioned don't exist"
rule only apply to me, and not to you?

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #39
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.

No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.
This is what you actually implied, by not mentioning the possibility of
exceptions.


In <c1**********@sunnews.cern.ch>, you replied to my statement
Given

struct {
char a [3];
} foo;

`foo.a' has array type.


with the statement
Nope. The type of this expression is pointer to char.


You didn't mention any exceptions.


There are NO exceptions, as long as we are talking about this expression.
Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator,
In this case, it is NOT an expression, it is a subexpression in a larger
expression.
or does your "exceptions which are not mentioned don't exist"
rule only apply to me, and not to you?


It is a universal rule, of course.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #40
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

Da*****@cern.ch (Dan Pop) writes:

> It's like saying "it rains every day" and then trying to save your ass
> by claiming that "unless it doesn't" also applies to it.

No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.

This is what you actually implied, by not mentioning the possibility of
exceptions.


In <c1**********@sunnews.cern.ch>, you replied to my statement
Given

struct {
char a [3];
} foo;

`foo.a' has array type.


with the statement
Nope. The type of this expression is pointer to char.


You didn't mention any exceptions.


There are NO exceptions, as long as we are talking about this expression.
Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator,


In this case, it is NOT an expression, it is a subexpression in a larger
expression.


Are you saying that a subexpression is not an expression? `foo.a'
seems to fulfill the criteria of 6.5#1 even when it is part of a
larger expression. And according to the grammar rules, the operand
of the `sizeof' operator is a unary-expression (6.5.3#1), and a
unary-expression is an expression (6.5.N#1, N = 4 to 17).

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #41
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:

In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

>Da*****@cern.ch (Dan Pop) writes:
>
>> It's like saying "it rains every day" and then trying to save your ass
>> by claiming that "unless it doesn't" also applies to it.
>
>No, that analogy is faulty. It would be a good analogy if I had said
>"expressions of array type retain their array type in /every/ context",
>and then later claimed that there are exceptions to "every context".
>But that's not what I actually said.

This is what you actually implied, by not mentioning the possibility of
exceptions.

In <c1**********@sunnews.cern.ch>, you replied to my statement

> Given
>
> struct {
> char a [3];
> } foo;
>
> `foo.a' has array type.

with the statement

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

You didn't mention any exceptions.


There are NO exceptions, as long as we are talking about this expression.
Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator,


In this case, it is NOT an expression, it is a subexpression in a larger
expression.


Are you saying that a subexpression is not an expression? `foo.a'
seems to fulfill the criteria of 6.5#1 even when it is part of a
larger expression. And according to the grammar rules, the operand
of the `sizeof' operator is a unary-expression (6.5.3#1), and a
unary-expression is an expression (6.5.N#1, N = 4 to 17).


I am saying that, when presented *alone*, foo.a is supposed to be
treated as such (i.e. as a *complete* expression) and not as part of
a larger expression.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #42
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

Da*****@cern.ch (Dan Pop) writes:

> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
>
>>Da*****@cern.ch (Dan Pop) writes:
>>
>>> It's like saying "it rains every day" and then trying to save your ass
>>> by claiming that "unless it doesn't" also applies to it.
>>
>>No, that analogy is faulty. It would be a good analogy if I had said
>>"expressions of array type retain their array type in /every/ context",
>>and then later claimed that there are exceptions to "every context".
>>But that's not what I actually said.
>
> This is what you actually implied, by not mentioning the possibility of
> exceptions.

In <c1**********@sunnews.cern.ch>, you replied to my statement

>> Given
>>
>> struct {
>> char a [3];
>> } foo;
>>
>> `foo.a' has array type.

with the statement

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

You didn't mention any exceptions.

There are NO exceptions, as long as we are talking about this expression.

Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator,

In this case, it is NOT an expression, it is a subexpression in a larger
expression.


Are you saying that a subexpression is not an expression? `foo.a'
seems to fulfill the criteria of 6.5#1 even when it is part of a
larger expression. And according to the grammar rules, the operand
of the `sizeof' operator is a unary-expression (6.5.3#1), and a
unary-expression is an expression (6.5.N#1, N = 4 to 17).


I am saying that, when presented *alone*, foo.a is supposed to be
treated as such (i.e. as a *complete* expression) and not as part of
a larger expression.


No, you said "In this case, it is NOT an expression [...]", not "In this
case, it is NOT a complete expression [...]".

That said, I disagree that an expression which is presented without
context is supposed to be treated as a complete expression. If the
intention is to present a complete expression, it is easy enough to make
that clear, e.g. by turning it into an expression statement. But in the
absence of context, no context can be assumed.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #43
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
That said, I disagree that an expression which is presented without
context is supposed to be treated as a complete expression.


It is the only meaningful approach, as it is completely impractical to
try to speculate on ALL the possible contexts in which that expression
could be used as a subexpression.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #44
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
That said, I disagree that an expression which is presented without
context is supposed to be treated as a complete expression.


It is the only meaningful approach, as it is completely impractical to
try to speculate on ALL the possible contexts in which that expression
could be used as a subexpression.


There was no need to speculate. I was merely enumerating /possible/
expressions with array type, i.e. expressions which have array type in
at least one context. Therefore, it wasn't necessary to consider all
possible contexts.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #45
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
That said, I disagree that an expression which is presented without
context is supposed to be treated as a complete expression.
It is the only meaningful approach, as it is completely impractical to
try to speculate on ALL the possible contexts in which that expression
could be used as a subexpression.


There was no need to speculate. I was merely enumerating /possible/
expressions with array type, i.e. expressions which have array type in

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^at least one context. Therefore, it wasn't necessary to consider all ^^^^^^^^^^^^^^^^^^^^possible contexts.


Where did you say that in the post that started this discussion?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #46
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

That said, I disagree that an expression which is presented without
context is supposed to be treated as a complete expression.

It is the only meaningful approach, as it is completely impractical to
try to speculate on ALL the possible contexts in which that expression
could be used as a subexpression.


There was no need to speculate. I was merely enumerating /possible/
expressions with array type, i.e. expressions which have array type in

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at least one context. Therefore, it wasn't necessary to consider all

^^^^^^^^^^^^^^^^^^^^
possible contexts.


Where did you say that in the post that started this discussion?


I didn't. But I also didn't explictly talk about all contexts.
Therefore, that omission makes my original statement misleading,
but not wrong.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #47
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:

In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

>That said, I disagree that an expression which is presented without
>context is supposed to be treated as a complete expression.

It is the only meaningful approach, as it is completely impractical to
try to speculate on ALL the possible contexts in which that expression
could be used as a subexpression.

There was no need to speculate. I was merely enumerating /possible/
expressions with array type, i.e. expressions which have array type in

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at least one context. Therefore, it wasn't necessary to consider all

^^^^^^^^^^^^^^^^^^^^
possible contexts.


Where did you say that in the post that started this discussion?


I didn't. But I also didn't explictly talk about all contexts.
Therefore, that omission makes my original statement misleading,
but not wrong.


Restrictions not explicitly mentioned (or implied by the context) don't
exist. This makes your original statement wrong. Furthermore, your
original statement was true only in *exceptional* cases and wrong in the
rest of the cases.

Compare your original statement with its negation (both are false,
as such) and see which of them correctly covers more cases.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #48
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

Da*****@cern.ch (Dan Pop) writes:

> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
>
>>That said, I disagree that an expression which is presented without
>>context is supposed to be treated as a complete expression.
>
> It is the only meaningful approach, as it is completely impractical to
> try to speculate on ALL the possible contexts in which that expression
> could be used as a subexpression.

There was no need to speculate. I was merely enumerating /possible/
expressions with array type, i.e. expressions which have array type in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at least one context. Therefore, it wasn't necessary to consider all
^^^^^^^^^^^^^^^^^^^^
possible contexts.

Where did you say that in the post that started this discussion?
I didn't. But I also didn't explictly talk about all contexts.
Therefore, that omission makes my original statement misleading,
but not wrong.


Restrictions not explicitly mentioned (or implied by the context)
don't exist.


I still disagree, but if such a rule existed, your reply to my statement
Given

struct {
char a [3];
} foo;

`foo.a' has array type.


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


would have been wrong, as there is no explictely mentioned or implied
context.
This makes your original statement wrong. Furthermore, your
original statement was true only in *exceptional* cases and wrong in the
rest of the cases.

Compare your original statement with its negation (both are false,
as such) and see which of them correctly covers more cases.


How can my original statement be wrong, true in exceptional cases, and
false at the same time? If it was true, even if only in exceptional
cases, it cannot also be wrong and false.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #49
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:

In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:

>Da*****@cern.ch (Dan Pop) writes:
>
>> In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
>>
>>>That said, I disagree that an expression which is presented without
>>>context is supposed to be treated as a complete expression.
>>
>> It is the only meaningful approach, as it is completely impractical to
>> try to speculate on ALL the possible contexts in which that expression
>> could be used as a subexpression.
>
>There was no need to speculate. I was merely enumerating /possible/
>expressions with array type, i.e. expressions which have array type in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>at least one context. Therefore, it wasn't necessary to consider all
^^^^^^^^^^^^^^^^^^^^
>possible contexts.

Where did you say that in the post that started this discussion?

I didn't. But I also didn't explictly talk about all contexts.
Therefore, that omission makes my original statement misleading,
but not wrong.


Restrictions not explicitly mentioned (or implied by the context)
don't exist.


I still disagree, but if such a rule existed, your reply to my statement
Given

struct {
char a [3];
} foo;

`foo.a' has array type.


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


would have been wrong, as there is no explictely mentioned or implied
context.


The lack of context *implies* a complete expression.
This makes your original statement wrong. Furthermore, your
original statement was true only in *exceptional* cases and wrong in the
rest of the cases.

Compare your original statement with its negation (both are false,
as such) and see which of them correctly covers more cases.


How can my original statement be wrong, true in exceptional cases, and
false at the same time? If it was true, even if only in exceptional
cases, it cannot also be wrong and false.


Of course it can. Consider the statement "it rains". Without aditional
context, it can be both true and false. If we manage to define a default
context, we can establish whether it's true or false. The exceptional
cases (if mentioned), could have established a context in which your
statement was true. In their absence, the statement was false.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Bob Roberts | last post by:
How can I make it so that I can pass anything into os.system() any command that I would type into the command line (bash on cygwin)? For example, "lower" is a small script of mine that I use...
9
by: Robert Lario | last post by:
C# verses VB.Net Which Way to go. I am sure this issues has come up before. Please direct me to any good articles that cover this issue. Ideally some neutral assessment.
1
by: Pieter | last post by:
Hi, I have this Warning for several forms when using the DockPanel Suite of Weifen Luo in VS.NET 2005. I read a lot about this CLS-compliant stuff, but I don't now how to chech actually which...
2
by: Marty | last post by:
The Image web control works with the relative path supplied, but the HTML image control with the same path doesn't. I seem to be spending more time trying to figure out ASP.Net's shortcomings and...
14
by: J.S. | last post by:
In a Windows Form application, which is the better method to concatenate large blocks of code? 1. Reading the text from text files. 2. Adding the text to the VB file itself? Thanks! J.S. ...
122
by: seberino | last post by:
I'm interested in knowing which Python web framework is most like Ruby on Rails. I've heard of Subway and Django. Are there other Rails clones in Python land I don't know about? Which one...
12
by: DFS | last post by:
I need to scan various network folders and capture all the filenames and create dates. ======================================================= 1st effort used the typical drive scan cFile =...
7
by: jtbjurstrom | last post by:
Bear with me because we are new to WCF and have been going through documentation and samples trying to absorb as much as possible in a short amount of time. Any suggestions would be much...
5
by: daokfella | last post by:
I have a custom web.config section similar to the following: <CustomAuthSettings attr1="" attr2=""> <Locations RedirectUrl="Invalid.aspx"> <add Path="test.aspx" Roles="1,2,3" Permissions="4,5,6"...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.