Help a beginner - simple lowercase to uppercase and so on function
bpasc...@googlemail.com
I'm posting quite a lot, i'm learning c without any solid programming
experience. So when my code doesn't work after looking why if i can't
get to know why, I ask here and i keep on coding as well.
So below is a simple lowercase to uppercase code from a to z that
doesn't fully work. I use gcc on linux and i've tried on gcc on
Windows and the output is quite the same (however nothing is return in
djgpp windows).
In gcc linux, It takes the input but it returns it after some delay
and it adds some characters i have never seen at this stage of
learning and nowwhere since i use a computer...
I don't know if it's the right way to do this, i wish pointers
wouldn't be involved for this. I can't think of a way to do this with
functions to split actions. Once this part below works, i'd like to
add some more string functions on the model of the function (UppStrg)
below :
#include <stdio.h>
#include <string.h>
void UppStrg(char *Low, char *Upp, int cnt) ;
int main(void)
{
int n = 40 ;
char Txt1[n] ;
char Txt2[n] ;
int i ;
printf("\n\nThis program reads and converts : 1- a lower case string
into upper case : \n") ;
do
{
printf("\nEnter a lowercase string : \n") ;
scanf("%s", Txt1) ;
n = strlen(Txt1) ;
for ( i = 0 ; i <= n ; i++ )
{
if ( (Txt1[i] <= 'a' ) || (Txt1[i] >= 'z') ) /* IF checks if there
are any characters other than lowercase letters */
printf("\nThere are no lowercase letters in this string !\n\n") ;
else
UppStrg(&Txt1[i], &Txt2[i], n) ;
}
} while ( (Txt1[i] <= 97 ) && (Txt1[i] >= 123) ) ;
for ( i = 0 ; i <= n ; i++ )
putchar(Txt2[i]) ;
printf("\n\n") ;
return 0 ;
}
/* Function that should move a lowercase letter into uppercase */
void UppStrg(char *Low, char *Upp, int cnt)
{
int i ;
for ( i = 0 ; i <= cnt ; cnt++ )
*(Upp+i) = *(Low+i) - 'a' + 'A';
}
bartc
<bpasc...@googlemail.com> wrote in message
news:754ef01c-2aeb-4adb...@j21g2000vbn.googlegroups.com...
> So below is a simple lowercase to uppercase code from a to z that
> doesn't fully work. I use gcc on linux and i've tried on gcc on
> Windows and the output is quite the same (however nothing is return in
> djgpp windows).
> In gcc linux, It takes the input but it returns it after some delay
> and it adds some characters i have never seen at this stage of
> learning and nowwhere since i use a computer...
>
> I don't know if it's the right way to do this, i wish pointers
> wouldn't be involved for this. I can't think of a way to do this with
> functions to split actions. Once this part below works, i'd like to
> add some more string functions on the model of the function (UppStrg)
> below :
>
>
> #include <stdio.h>
> #include <string.h>
>
> void UppStrg(char *Low, char *Upp, int cnt) ;
>
> int main(void)
> {
> int n = 40 ;
> char Txt1[n] ;
> char Txt2[n] ;
You're using variable arrays here. Not causing your problems but take a bit
more care to use.
> int i ;
>
> printf("\n\nThis program reads and converts : 1- a lower case string
> into upper case : \n") ;
>
> do
> {
> printf("\nEnter a lowercase string : \n") ;
> scanf("%s", Txt1) ;
>
> n = strlen(Txt1) ;
>
> for ( i = 0 ; i <= n ; i++ )
> {
> if ( (Txt1[i] <= 'a' ) || (Txt1[i] >= 'z') ) /* IF checks if there
> are any characters other than lowercase letters */
> printf("\nThere are no lowercase letters in this string !\n\n") ;
> else
> UppStrg(&Txt1[i], &Txt2[i], n) ;
> }
>
> } while ( (Txt1[i] <= 97 ) && (Txt1[i] >= 123) ) ;
These 2 nested loops are a mess. Once you've detected a character is not
lower case, you want to break out of the inner loop.
The Uppstrg() functions converts a single character, or a whole string? If a
whole string, it should be outside the inner loop, with Tx1 and Txt2
arguments. If a single character, you shouldn't use "&", and you need to
rewrite UppStrg! This is mainly why the program is doing strange things.
The conditional to the outer do-while loop is meaningless. 'i' is undefined
at this point. (I'm not familiar with how scanf forces a new input line, so
I'd would read the input a little differently myself, perhaps using fgets()
or getchar())
Your for-loop is also looking at the 0-terminator of the string, which is
not necessary; make i count from 0 to <n.
> void UppStrg(char *Low, char *Upp, int cnt)
> {
> int i ;
>
> for ( i = 0 ; i <= cnt ; cnt++ )
> *(Upp+i) = *(Low+i) - 'a' + 'A';
If you're going to assume Ascii code, then just subtract 32 from the
character code...
Usually case conversion code will work with any character, and ignore
anything not a..z or A..Z, depending which way it's going. (There are anyway
standard C functions for case-converting characters or strings.)
--
bartc
Doug Miller
>Hi,
>
>I'm posting quite a lot, i'm learning c without any solid programming
>experience. So when my code doesn't work after looking why if i can't
>get to know why, I ask here and i keep on coding as well.
>
>So below is a simple lowercase to uppercase code from a to z that
>doesn't fully work. I use gcc on linux and i've tried on gcc on
>Windows and the output is quite the same (however nothing is return in
>djgpp windows).
Is there some reason you don't simply use toupper() ?
pete
> Hi,
>
> I'm posting quite a lot, i'm learning c without any solid programming
> experience. So when my code doesn't work after looking why if i can't
> get to know why, I ask here and i keep on coding as well.
>
> So below is a simple lowercase to uppercase code from a to z that
> doesn't fully work. I use gcc on linux and i've tried on gcc on
> Windows and the output is quite the same (however nothing is return in
> djgpp windows).
>
> In gcc linux, It takes the input but it returns it after some delay
> and it adds some characters i have never seen at this stage of
> learning and nowwhere since i use a computer...
>
> I don't know if it's the right way to do this, i wish pointers
> wouldn't be involved for this. I can't think of a way to do this with
> functions to split actions. Once this part below works, i'd like to
> add some more string functions on the model of the function (UppStrg)
> below :
>
>
> #include <stdio.h>
> #include <string.h>
>
> void UppStrg(char *Low, char *Upp, int cnt) ;
/* BEGIN new.c */
#include <stdio.h>
#include <limits.h>
#define STRING "It was intended to be a hint."
#define UPPER "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
#define LOWER "abcdefghijklmnopqrstuvwxyz"
void UppStrg(char *low);
int to_upper(int c);
char *str_chr(const char *s, int c);
int main(void)
{
char a[] = STRING;
puts(a);
UppStrg(a);
puts(a);
return 0;
}
void UppStrg(char *low)
{
while (*low != '\0') {
*low = to_upper(*low);
++low;
}
}
int to_upper(int c)
{
const char *upper;
const char *const lower = LOWER;
upper = CHAR_MAX >= c && c > '\0' ? str_chr(lower, c) : NULL;
return upper != NULL ? UPPER[upper - lower] : c;
}
char *str_chr(const char *s, int c)
{
while (*s != (char)c) {
if (*s == '\0') {
return NULL;
}
++s;
}
return (char *)s;
}
/* END new.c */
--
pete
Gordon Burditt
>doesn't fully work. I use gcc on linux and i've tried on gcc on
>Windows and the output is quite the same (however nothing is return in
>djgpp windows).
What is the function UppStrg supposed to do? Does it convert *ONE*
character to upper case, or does it convert the whole string? Your
code doesn't seem to be very consistent on this topic.
If it is supposed to convert *ONE* character, why does UppStrg
contain a loop?
If it is supposed to convert the whole string, why doesn't it test
each character to determine whether it is lower case before converting
it to upper case? It's particularly a BAD idea to convert the
string terminator '\0' to upper case.
If it is supposed to convert the whole string, why is it called
inside a loop in main() for each character of the string?
Your main() program contains many assumptions that are only valid
for ASCII: the assumption that the codes for 'a' thru 'z' are
contiguous, and what characters are represented by the codes 97 and
123.
>#include <stdio.h>
>#include <string.h>
>
>void UppStrg(char *Low, char *Upp, int cnt) ;
>
>int main(void)
>{
> int n = 40 ;
> char Txt1[n] ;
> char Txt2[n] ;
>
> int i ;
>
> printf("\n\nThis program reads and converts : 1- a lower case string
>into upper case : \n") ;
>
> do
> {
> printf("\nEnter a lowercase string : \n") ;
> scanf("%s", Txt1) ;
>
> n = strlen(Txt1) ;
>
> for ( i = 0 ; i <= n ; i++ )
> {
> if ( (Txt1[i] <= 'a' ) || (Txt1[i] >= 'z') ) /* IF checks if there
>are any characters other than lowercase letters */
> printf("\nThere are no lowercase letters in this string !\n\n") ;
> else
> UppStrg(&Txt1[i], &Txt2[i], n) ;
Note: if i > 0, the length of the string you are passing to UppStrg
is *NOT* n, it's less than that, because some of the n characters
are before the beginning of the string.
Do you ever terminate the string in Txt2? Why not? That's likely to
get random garbage printed after the end of the string.
> }
>
> } while ( (Txt1[i] <= 97 ) && (Txt1[i] >= 123) ) ;
>
> for ( i = 0 ; i <= n ; i++ )
> putchar(Txt2[i]) ;
> printf("\n\n") ;
>
> return 0 ;
>}
>
>/* Function that should move a lowercase letter into uppercase */
*ONE* letter? Or a whole bunch? Please make up your mind.
>void UppStrg(char *Low, char *Upp, int cnt)
>{
> int i ;
>
> for ( i = 0 ; i <= cnt ; cnt++ )
> *(Upp+i) = *(Low+i) - 'a' + 'A';
Why does this loop ever terminate? Shouldn't i change? Why does
cnt change? I'm guessing that this loop runs over 30,000 times, and
maybe over 2 billion times, each time it is called. This is not very
efficient.
>}
luserXtrog
<bpascal...@googlemail.com> wrote:
> Hi,
>
> I'm posting quite a lot, i'm learning c without any solid programming
> experience. So when my code doesn't work after looking why if i can't
> get to know why, I ask here and i keep on coding as well.
>
> So below is a simple lowercase to uppercase code from a to z that
> doesn't fully work. I use gcc on linux and i've tried on gcc on
> Windows and the output is quite the same (however nothing is return in
> djgpp windows).
>
> In gcc linux, It takes the input but it returns it after some delay
> and it adds some characters i have never seen at this stage of
> learning and nowwhere since i use a computer...
When that happens, it means the ends of your strings (the terminating
nul) is getting snipped. Step one: check loop conditions and array
lengths.
> I don't know if it's the right way to do this, i wish pointers
> wouldn't be involved for this. I can't think of a way to do this with
> functions to split actions.
I'd make a function to transpose one character (int tr(int)).
And then one to loop across the string calling that function
for each character. And I'd probably do it in place instead of
copying at to a new array (why would you need both?).
> Once this part below works, i'd like to
> add some more string functions on the model of the function (UppStrg)
> below :
>
> #include <stdio.h>
> #include <string.h>
>
> void UppStrg(char *Low, char *Upp, int cnt) ;
>
> int main(void)
> {
> int n = 40 ;
> char Txt1[n] ;
> char Txt2[n] ;
>
> int i ;
>
> printf("\n\nThis program reads and converts : 1- a lower case string
> into upper case : \n") ;
>
> do
> {
> printf("\nEnter a lowercase string : \n") ;
> scanf("%s", Txt1) ;
>
> n = strlen(Txt1) ;
>
> for ( i = 0 ; i <= n ; i++ )
> {
> if ( (Txt1[i] <= 'a' ) || (Txt1[i] >= 'z') ) /* IF checks if there
> are any characters other than lowercase letters */
> printf("\nThere are no lowercase letters in this string !\n\n") ;
> else
> UppStrg(&Txt1[i], &Txt2[i], n) ;
> }
Your spacing makes this very difficult to read.
I don't understand why you need all that space.
I also don't understand why you're calling UppStrg
in this loop. You're incrementing the offset and
asking it to modify 40 elements starting at each position.
Every time through this loop after the first, you're
asking UppStrg to modify elements that are outside of
the bounds of the array.
UppStrg should be called once for each string.
If you need to verify that the string consists
only of lowercase characters, you can use some
kind of flag value that's set in the loop when
a bogus character is encountered and then check
after the loop whether it was set. Or you can
use some standard library functions. I recently
discovered this one:
if (strspn(s,"abcdefghijklmnopqrstuvwxyz") == strlen(s))
printf("char *s consists wholy of lowercase letters\n");
> } while ( (Txt1[i] <= 97 ) && (Txt1[i] >= 123) ) ;
>
> for ( i = 0 ; i <= n ; i++ )
> putchar(Txt2[i]) ;
> printf("\n\n") ;
>
> return 0 ;
>
> }
>
> /* Function that should move a lowercase letter into uppercase */
>
> void UppStrg(char *Low, char *Upp, int cnt)
> {
> int i ;
>
> for ( i = 0 ; i <= cnt ; cnt++ )
> *(Upp+i) = *(Low+i) - 'a' + 'A';
>
> }
>
>
Dude, use the array notation for strings. It's prettier.
Upp[i] = Low[i] - 'a' + 'A';
I don't like the arithmetic here, either. It would make more
sense to me to add the difference rather than subtracting the
sum. But better that all these (IMHO) is
char *al="abcdefghijklmnopqrstuvwxyz";
char *AL="ABCDEFGHIJKLMNOPQRSTUVWXYZ";
...
Upp[i] = AL[strchr(al, Low[i]) - al];
This way doesn't assume ASCII, but it assumes that you've already
made sure the string consists only of lowercase characters.
Otherwise strchr will return NULL and NULL - al is not a valid
index into the AL array.
--
lxt
Richard Heathfield
> Hi,
>
> I'm posting quite a lot,
Too much, perhaps? Not that there's a limit, but for your own
benefit it may be better to think more and post less.
> i'm learning c without any solid
> programming experience. So when my code doesn't work after looking
> why if i can't get to know why, I ask here and i keep on coding as
> well.
Better to stop, think, and think again.
> So below is a simple lowercase to uppercase code from a to z that
> doesn't fully work.
Except that it's not simple, makes some very bad assumptions, and
has at least one major security hole.
I recommend that you study the following code:
#include <stdio.h>
#include <ctype.h>
int main(void)
{
int ch;
while((ch = getchar()) != EOF)
{
putchar(toupper(ch));
}
return 0;
}
Never mind what your program actually does. What is your program
*supposed* to do, that the above program does not do? Identifying
those differences (if any) will enable us to give you much better
assistance.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
bartc
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
news:wu-dndqB-aDxnfHX...@bt.com...
> bpasc...@googlemail.com said:
>
>> Hi,
>>
>> I'm posting quite a lot,
>
> Too much, perhaps? Not that there's a limit, but for your own
> benefit it may be better to think more and post less.
Leave him be; he's single-handedly keeping this group alive it seems to me.
--
Bart
Nick Keighley
<bpascal...@googlemail.com> wrote:
> I'm posting quite a lot, i'm learning c without any solid programming
> experience.
the only way to get the experience is to practice programming.
Though you could be a little more sytematic...
> So when my code doesn't work after looking why if i can't
> get to know why, I ask here and i keep on coding as well.
you could try debugging it. Looking isn't enough.
> So below is a simple lowercase to uppercase code from a to z that
> doesn't fully work.
<snip>
> I don't know if it's the right way to do this, i wish pointers
> wouldn't be involved for this.
you could use arrays rather than pointers.
> I can't think of a way to do this with
> functions to split actions.
imagine you had a friend looking over you shoulder and you explaining
what the different steps of the program does. Or add comments to
explain
what blocks of code (not lines!) do.
So your program does the following
read a line
check the line is all lower case letters
convert each character to upper case
print the new line
that gives you four possible functions. The middle two
can also be tested on their own.
#include <assert.h>
/*returns true(1) if all the characters are lower case
and false(0) otherwise */
int is_all_lower (const char s[], int size);
/* terminates the program if is_all_lower() doesn't return the
expected
answer */
void test_is_all-lower (const char s[], int size, int expected_result)
{
/* this crashes if we don't get the expected answer */
assert (is_all_lower (s,size) == expected_answer);
}
void test (void)
{
test_is_all_lower ("abc", 3, 1);
test_is_all_lower ("Abc", 3, 0);
test_is_all_lower ("abC", 3, 0);
test_is_all_lower ("@bc", 3, 0);
test_is_all_lower ("a@c", 3, 0);
test_is_all_lower ("a", 3, 1);
}
int main (void)
{
test();
return 0;
}
> Once this part below works, i'd like to
> add some more string functions on the model of the function (UppStrg)
> below :
>
> #include <stdio.h>
> #include <string.h>
>
> void UppStrg(char *Low, char *Upp, int cnt) ;
>
> int main(void)
> {
> int n = 40 ;
your posts would look better on the internet if you used a smaller
indentation. Maybe 4 chatacters (my favourite) or even less.
> char Txt1[n] ;
beginning identifiers with an upper case less is an odd convention.
And using a constant like n won't work on older versions of C.
<snip>
> scanf("%s", Txt1) ;
scanf() is tricky to use correctly (fgets() followed by sscanf() is
better).
But if you do use it you *must* check its return value.
> n = strlen(Txt1) ;
re-using variables for multiple purposes is a bad idea. Modern
computers
have *billions* of bytes of RAM.
> for ( i = 0 ; i <= n ; i++ )
I really *hate* this. Could you use less blank space?
for (i = 0; i < n; i++)
You also had an off by one error. Suppose n is 10 your loop runs 11
times.
[code reformatted]
> if ( (Txt1[i] <= 'a' ) || (Txt1[i] >= 'z') )
> printf("\nThere are no lowercase letters in this string !\n\n") ;
really? What about "abcdefghijklmnopqrstuvwxyZ"? Any lower case
letters?
<snip>
> } while ( (Txt1[i] <= 97 ) && (Txt1[i] >= 123) ) ;
you know about character constants ('a' etc) why start using integers?
<snip>
Richard Heathfield
>
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:wu-dndqB-aDxnfHX...@bt.com...
>> bpasc...@googlemail.com said:
>>
>>> Hi,
>>>
>>> I'm posting quite a lot,
>>
>> Too much, perhaps? Not that there's a limit, but for your own
>> benefit it may be better to think more and post less.
>
> Leave him be;
I'm not attacking him. I'm trying to help him. Sometimes you just
have to stop and think instead of doing doing doing all the time.
It takes time to think things through, and comp.lang.c is not
supposed to be a substitute for thinking for yourself.
> he's single-handedly keeping this group alive it
> seems to me.
If that's true, the group deserves to die. But I don't think it /is/
true.
I note that you snipped (without marking the snippage of) my example
program which, as far as I can tell without further feedback from
the OP, does exactly what he needs. He would do well to dwell upon
its simplicity, and consider why he felt the need to make his
program so complicated. Cutting out deadwood is an important skill,
and one that needs to be thought about, not just posted about.
bartc
> I note that you snipped (without marking the snippage of) my example
It wasn't relevant to my point.
> program which, as far as I can tell without further feedback from
> the OP, does exactly what he needs. He would do well to dwell upon
> its simplicity, and consider why he felt the need to make his
> program so complicated. Cutting out deadwood is an important skill,
> and one that needs to be thought about, not just posted about.
I assumed the OP's code was a learning exercise.
--
bartc
Richard Heathfield
> Richard Heathfield wrote:
[more stuff here, which bartc again snipped without marking the
snippage]
>
>> I note that you snipped (without marking the snippage of) my
>> example
>
> It wasn't relevant to my point.
That explains why you snipped it, but not why you didn't mark the
snippage. Nor does it explain why you snipped text /this/ time
around without marking it. I hope I may presume that you agree 100%
with the text you snipped.
>> program which, as far as I can tell without further feedback from
>> the OP, does exactly what he needs. He would do well to dwell
>> upon its simplicity, and consider why he felt the need to make
>> his program so complicated. Cutting out deadwood is an important
>> skill, and one that needs to be thought about, not just posted
>> about.
>
> I assumed the OP's code was a learning exercise.
Yes, and the part you snipped was a teaching exercise. When you said
"leave him be", you gave the impression that I was attacking the
OP. The part you quietly snipped was clear evidence to the
contrary.
Richard Bos
> I'm posting quite a lot, i'm learning c without any solid programming
> experience.
This is not the best idea to start with. Your own nick should give you a
hint in a more advisable direction.
> So when my code doesn't work after looking why if i can't get to know
> why, I ask here and i keep on coding as well.
This, by contrast, is a very bad idea. _First_ get it right, then
complicate it.
> } while ( (Txt1[i] <= 97 ) && (Txt1[i] >= 123) ) ;
Comparing against unencoded ASCII values is a bad idea for more reasons
than just portability.
> for ( i = 0 ; i <= cnt ; cnt++ )
Your spacing doesn't make your code any easier to read.
Richard
Keith Thompson
> On 26 July, 01:23, "bpascal...@googlemail.com"
> <bpascal...@googlemail.com> wrote:
>> � � � � � � � � scanf("%s", Txt1) ;
>
> scanf() is tricky to use correctly (fgets() followed by sscanf() is
> better).
> But if you do use it you *must* check its return value.
Even that isn't sufficent. scanf with a "%s" format is inherently
unsafe; it will attempt to read an arbitrarily long space-delimited
word, and store that word in an object that cannot possibly be large
enough to store all possible inputs.
[...]
>> � � � � � � � � for ( i = 0 � � ; � � � i <= n � � � ; � � � i++ )
>
> I really *hate* this. Could you use less blank space?
Another style point: don't put blanks in front of your semicolons.
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Chris M. Thomasson
news:754ef01c-2aeb-4adb...@j21g2000vbn.googlegroups.com...
>
> I'm posting quite a lot, i'm learning c without any solid programming
> experience. So when my code doesn't work after looking why if i can't
> get to know why, I ask here and i keep on coding as well.
>
> So below is a simple lowercase to uppercase code from a to z that
> doesn't fully work. I use gcc on linux and i've tried on gcc on
> Windows and the output is quite the same (however nothing is return in
> djgpp windows).
___________________________________________________________
#include <stdio.h>
#include <ctype.h>
char*
strtoupper(
char* const buf
) {
char* cur = buf;
while (*cur) {
*cur = toupper(*cur);
++cur;
}
return buf;
}
int main(void) {
char str[] = "1 plus 1 = two";
puts(strtoupper(str));
return 0;
}
___________________________________________________________
Richard Heathfield
<snip>
> char*
> strtoupper(
You just trod on the implementation's namespace.
<snip>
pete
> #include <ctype.h>
>
>
> char*
> strtoupper(
> char* const buf
> ) {
> char* cur = buf;
> while (*cur) {
> *cur = toupper(*cur);
> ++cur;
> }
> return buf;
> }
If I were to use a const qualified object,
in a function like that,
it would be declared in the the function body.
#include <ctype.h>
char *
str_toupper(char *buf)
{
char *const r = buf;
while (*buf != '\0') {
*buf = toupper(*buf);
++buf;
}
return r;
}
--
pete
bpasc...@googlemail.com
I'd first say thanks for your replies.
I'd study carefully what was said here, at this time i'm not sure i
can understand everything but it should take shape with more practice
of C.
I don't spend too much time thinking before i post because it's not
certain i'll keep studying at that pace.
For the code, I think (a little late) the mistake that made it not
work (compile and return something) is about thses loops where <= n
was replaced with < n (the '\0' can't be uppercase):
main :
for ( i = 0 ; i < n ; i++ )
{
if ( (Txt1[i] <= 'a' ) || (Txt1[i]
>= 'z') )
printf("\nThere are no lowercase
letters in this string !\n\n") ;
else
UppStrg(&Txt1[i], &Txt2[i], n) ;
}
void UppStrg :
for ( i = 0 ; i < cnt ; i++ )
*(Upp+i) = *(Low+i) - 'a' + 'A';
With these modification, it compiles and returns uppercase letters
however not regarding if true or not "There are no lowercase letters
in this string !" in gcc linux.
In Windows djgpp it just doesn't compile unless the loop in main looks
like :
for ( i = 0 ; i < n ; i++ )
UppStrg(&Txt1[i], &Txt2[i], n) ;
Some posts above seem to tell why. I'll read them carefully again.
I'd expect this code to make upppercase a whole string and not just
one charactere entered at a time if i answer right your question. Ok,
this code is not taking many consideration such as non ascii letters
or uppercase letters... Also the non-official purpose is to put at
work my understanding of loops and functions which needs more work
regarding the time i have spent on this i think.
About the spacing : I first find it easier to spot mistakes and i have
read spacing would play a role in other languages such as python. I'm
not preparing to switch to python this way yet, i'd like a good
understanding of c maybe to program with linux os...i don't know what
i'll be able to do and when.
Thx,
Pascal Baro
Morris Keesan
characters in your source, have your tab stops set to
something other than "every eight columns", and don't
realize what your code looks like when
viewed by other people. It looks like this:
> for ( i = 0 ; i < n ; i++ )
> {
> if ( (Txt1[i] <= 'a' ) || (Txt1[i]
Notice that there is a huge amount of whitespace around your
';' and "||", which makes the code extremely hard to read for
anyone used to any other C code. That's what people are complaining about.
Assuming ASCII, or some other character set where all of the lowercase
letters are contiguous, with 'a' having the lowest numeric value
and 'z' the highest,
> for ( i = 0; i < n; i++ )
> {
> if ( (Txt1[i] <= 'a' ) || (Txt1[i] = 'z') )
> printf("\nThere are no lowercase letters in this string
> !\n\n") ;
For EVERY CHARACTER IN Txt1 that is not a lowercase letter, this will
print "There are no lowercase letters". Even if the call to UppStrg made
sense, and even if UppStrg were coded properly, if Txt1 contained the
string "Pascal Baro" then the loop would print, THREE TIMES, the message
"\nThere are no lowercase letters in this string !\n\n". I don't think
this
is what you want.
Morris Keesan
> Chris M. Thomasson wrote:
>
>> #include <ctype.h>
>> char*
>> strtoupper(
>> char* const buf
>> ) {
>> char* cur = buf;
>> while (*cur) {
>> *cur = toupper(*cur);
>> ++cur;
>> }
>> return buf;
>> }
>
> If I were to use a const qualified object,
> in a function like that,
> it would be declared in the the function body.
Why? Do you really find it more readable to be
modifying your parameters?
Peter Nilsson
> Chris M. Thomasson wrote:
> > #include <ctype.h>
> >
> > char*
> > strtoupper(
> > char* const buf
> > ) {
> > char* cur = buf;
> > while (*cur) {
> > *cur = toupper(*cur);
> > ++cur;
> > }
> > return buf;
> > }
>
> If I were to use a const qualified object,
> in a function like that,
> it would be declared in the the function body.
Why?
> #include <ctype.h>
>
> char *
> str_toupper(char *buf)
> {
> char *const r = buf;
>
> while (*buf != '\0') {
> *buf = toupper(*buf);
This does have a problem in that plain char may be signed.
> ++buf;
> }
> return r;
> }
#include <ctype.h>
char *str_toupper(char *s)
{
unsigned char *r = (void *) s;
while (*r = toupper(*r)) r++;
return s;
}
--
Peter
pete
> On Mon, 27 Jul 2009 05:52:33 -0400, pete <pfil...@mindspring.com> wrote:
>
>> Chris M. Thomasson wrote:
>>
>>> #include <ctype.h>
>>> char*
>>> strtoupper(
>>> char* const buf
>>> ) {
>>> char* cur = buf;
>>> while (*cur) {
>>> *cur = toupper(*cur);
>>> ++cur;
>>> }
>>> return buf;
>>> }
>>
>>
>> If I were to use a const qualified object,
>> in a function like that,
>> it would be declared in the the function body.
>
>
> Why? Do you really find it more readable to be
> modifying your parameters?
I modify parameters at every given opportunity.
That's a large part of the point of having parameters.
I've never written a prototype with a const qualified parameter.
>>
>> #include <ctype.h>
>>
>> char *
>> str_toupper(char *buf)
>> {
>> char *const r = buf;
>>
>> while (*buf != '\0') {
>> *buf = toupper(*buf);
>> ++buf;
>> }
>> return r;
>> }
>>
>
--
pete
lovecrea...@gmail.com
> pete <pfila...@mindspring.com> wrote:
> > Chris M. Thomasson wrote:
> > > char*
> > > strtoupper(
> > > char* const buf
> > > ) {
> > If I were to use a const qualified object,
> > in a function like that,
> > it would be declared in the the function body.
>
> Why?
The value of arguments won't be modified.
I think this was discussed here before, and you obviously know it.
I also prefer pete's methold.
> > #include <ctype.h>
>
> > char *
> > str_toupper(char *buf)
> > {
> > char *const r = buf;
>
> > while (*buf != '\0') {
> > *buf = toupper(*buf);
>
> This does have a problem in that plain char may be signed.
The signedness of char isn't specified.
toupper() accepts an int, so I don't see problems here :)
>
> > ++buf;
> > }
> > return r;
> > }
pete
I have no experience working outside of the "C" locale,
which why I'm not sure, but I think you would be defeating
the locale-specific behavior that toupper is supposed to have.
--
pete
pete
> *(Upp+i) = *(Low+i) - 'a' + 'A';
>
> With these modification, it compiles and returns uppercase letters
That is not nearly as interesting as you might think.
That is "learning C from your compiler".
For example: learning C from some C89 compilers,
has lead many to believe that omitting <stdlib.h>
and casting the return value from malloc,
is just as good as #including <stdlib.h> when malloc is used.
And the beliefs of those many, were wrong.
What most of us here are mostly interested in discussing here,
is how to write code that will work even with a compiler
that hasn't yet been created.
--
pete
pete
> pete <pfila...@mindspring.com> wrote:
>
>>Chris M. Thomasson wrote:
>>
>>>#include <ctype.h>
>>>
>>>char*
>>>strtoupper(
>>>char* const buf
>>>) {
>>> char* cur = buf;
>>> while (*cur) {
>>> *cur = toupper(*cur);
>>> ++cur;
>>> }
>>> return buf;
>>>}
>>
>>If I were to use a const qualified object,
>>in a function like that,
>>it would be declared in the the function body.
>
>
> Why?
I've never worked with any code
that had a const qualified parameter.
--
pete
Nick Keighley
> >> Chris M. Thomasson wrote:
> >>> #include <ctype.h>
> >>> char*
> >>> strtoupper(
> >>> char* const buf
> >>> ) {
> >>> char* cur = buf;
> >>> while (*cur) {
> >>> *cur = toupper(*cur);
> >>> ++cur;
> >>> }
> >>> return buf;
> >>> }
>
> >> If I were to use a const qualified object,
> >> in a function like that,
> >> it would be declared in the the function body.
I'm not sure why. Am I missing some subtlety?
> > Why? Do you really find it more readable to be
> > modifying your parameters?
>
> I modify parameters at every given opportunity.
why? I modify a parameter only if necessary.
> That's a large part of the point of having parameters.
not in my world
> I've never written a prototype with a const qualified parameter.
a good time to start!
<snip>
Nick Keighley
<bpascal...@googlemail.com> wrote:
> I'd first say thanks for your replies.
> I'd study carefully what was said here, at this time i'm not sure i
> can understand everything but it should take shape with more practice
> of C.
> I don't spend too much time thinking before i post because it's not
> certain i'll keep studying at that pace.
do more thinking
> For the code, I think (a little late) the mistake that made it not
> work (compile and return something) is about thses loops where <= n
> was replaced with < n (the '\0' can't be uppercase):
don't think, test! By which I mean, don't guess that your code works;
test it.
> main :
> for ( i = 0 ; i < n ; i++ )
> {
> if ( (Txt1[i] <= 'a' ) || (Txt1[i]>= 'z') )
>
> printf("\nThere are no lowercase
> letters in this string !\n\n") ;
> else
> UppStrg(&Txt1[i], &Txt2[i], n) ;
> }
>
> void UppStrg :
>
> for ( i = 0 ; i < cnt ; i++ )
> *(Upp+i) = *(Low+i) - 'a' + 'A';
>
> With these modification, it compiles and returns uppercase letters
> however not regarding if true or not "There are no lowercase letters
> in this string !" in gcc linux.
sorry I didn't understand that
> In Windows djgpp it just doesn't compile unless the loop in main looks
> like :
>
> for ( i = 0 ; i < n ; i++ )
> UppStrg(&Txt1[i], &Txt2[i], n) ;
please post the complete coce that compiles under gcc Linux but not
under Windows djgpp. At the core it's the same compiler so it *ought*
to compile on both.
> Some posts above seem to tell why. I'll read them carefully again.
>
> I'd expect this code to make upppercase a whole string and not just
> one charactere entered at a time if i answer right your question.
the question was (or should have been) "does the function UppStrg()
convert a single character to upper case or does it convert the whole
string?". If it converts the entire string how many times would you
expect your code to call it? How many times does your program call it?
> Ok,
> this code is not taking many consideration such as non ascii letters
> or uppercase letters... Also the non-official purpose is to put at
> work my understanding of loops and functions which needs more work
> regarding the time i have spent on this i think.
>
> About the spacing : I first find it easier to spot mistakes
whilst making it harder for every other C programmer in the galaxy.
Please switch to a more conventional layout. It will become readable
with practice.
> and i have
> read spacing would play a role in other languages such as python.
well you aren't programming in Python at the moment.
> I'm
> not preparing to switch to python this way yet, i'd like a good
> understanding of c maybe to program with linux os...i don't know what
> i'll be able to do and when.
In english we have the expression "don't change horses in mid-stream".
So stick with one language until you're reasonably happy with it.
Then learn another one. The first language is the hardest.
--
Nick Keighley
"Programs must be written for people to read, and only
incidentally for machines to execute."
- Abelson & Sussman, Structure and Interpretation of Computer Programs
bartc
"pete" <pfil...@mindspring.com> wrote in message
news:qYGdnfKKlNgm-_PX...@earthlink.com...
>>> If I were to use a const qualified object,
>>> in a function like that,
>>> it would be declared in the the function body.
>> Why? Do you really find it more readable to be
>> modifying your parameters?
>
> I modify parameters at every given opportunity.
>
> That's a large part of the point of having parameters.
How about here:
int main(int argc, char **argv) ?
Parameters are always input data to a C function. You can modify them if
they are not quite right, or if they are doing double duty as local
variables. But usually they are left alone.
I suspect you weren't being serious however..
--
Bart
James Kuyper
>> I modify parameters at every given opportunity.
>
> why? I modify a parameter only if necessary.
It's a variable, for which space has already been allocated - why waste
it?. If at some point in the function I no longer need to retain it's
original value, I feel perfectly free to change that value, I only
declare it const if I see no reason to change it. However, I only change
the value if I can reasonably say that the new and old values are in
some sense different values of the same thing.
That's the same rule I apply to any other variable. I don't re-use
variables for different purposes in the same block of code; that just
leads to confusion. I count on the compiler to notice that usage of one
variable never overlaps usage of another variable, and to save space by
using the same location in memory for both variables - it's better (and
far more reliable) about noticing such things than I am.
>> That's a large part of the point of having parameters.
>
> not in my world
Nor mine.
Chris M. Thomasson
news:foadnSqLw44PBPPX...@earthlink.com...
That's your _personal_ experience; so be it.
struct foo {
int x;
};
void
foo_foo(
struct foo* const self
) {
/* [...]; */
}
What's wrong with that?
Beej Jorgensen
>
>
>int main(int argc, char **argv) ?
Nothing is fundamentally wrong with modifying those, or the strings
pointed to by argv:
C99 5.1.2.2.1p2:
# The parameters argc and argv and the strings pointed to by the argv
# array shall be modifiable by the program, and retain their last-stored
# values between program startup and program termination.
I've seen argc modified in command line parsing, and it's not entirely
rare in Unix to modify argv which can, on some(?) Unices, cause the "ps"
command to show different values for the names of running programs.
Personally, I leave argc and argv as-is--but I acknowledge there is no
reason for that other than preference.
>Parameters are always input data to a C function. You can modify them if
>they are not quite right, or if they are doing double duty as local
>variables. But usually they are left alone.
One argument for leaving them alone might be one of code maintenance.
For instance, if one is modding a large function and sees parameter
numCPUs, one is probably going to expect it contains the number of CPUs.
But this assumption will be wrong at the end of the function if there is
something like a while(numCPUs--) loop in there somewhere. (A point
which would be caught with a code read or test, but then you're just
going to need to store numCPUs in another temp variable, anyway...)
As inputs to the function, I feel there is something slightly more
sacred to the parameters than typical local variables, I guess! If
sqrt() gets parameter x, its entire external world is x; everything it
needs to know about everything needed for its calculation is x*. So I
suppose I'd prefer to leave its modification until the end of the
function when its no longer needed (e.g. in strcpy(), feel free to
modify the "src" parameter because it happens at the end of the
function.)
-Beej
* exceptions aside
bartc
news:h4n7ps$905$1...@news.eternal-september.org...
> bartc <ba...@freeuk.com> wrote:
>>"pete" <pfil...@mindspring.com> wrote in message
>>> I modify parameters at every given opportunity.
>>int main(int argc, char **argv) ?
>
> Nothing is fundamentally wrong with modifying those, or the strings
> pointed to by argv:
>
> C99 5.1.2.2.1p2:
> # The parameters argc and argv and the strings pointed to by the argv
> # array shall be modifiable by the program, and retain their last-stored
> # values between program startup and program termination.
I don't understand how this applies to argc which is a copy of the value
provided by the environment. main() is free to do what it likes with it. And
surely the actual number of command params provided cannot be changed
anyway.
> I've seen argc modified in command line parsing, and it's not entirely
> rare in Unix to modify argv which can, on some(?) Unices, cause the "ps"
> command to show different values for the names of running programs.
Well that comes under:
>>... You can modify them if they are not quite right...
Although modifying *argv or **argv has nothing to do with modifying (value)
parameters.
>One argument for leaving them alone might be one of code maintenance.
> For instance, if one is modding a large function and sees parameter
> numCPUs, one is probably going to expect it contains the number of CPUs.
> But this assumption will be wrong at the end of the function if there is
> something like a while(numCPUs--) loop in there somewhere. (A point
> which would be caught with a code read or test, but then you're just
> going to need to store numCPUs in another temp variable, anyway...)
Exactly. Either a lot of care is needed or numCPUs should be renamed so it's
not quite so specific.
--
Bart
Richard Heathfield
> "Beej Jorgensen" <be...@beej.us> wrote in message
> news:h4n7ps$905$1...@news.eternal-september.org...
>> bartc <ba...@freeuk.com> wrote:
<snip>
>
>>>... You can modify them if they are not quite right...
>
> Although modifying *argv or **argv has nothing to do with
> modifying (value) parameters.
You can alter argv if you like.
++argv;
is fine (and indeed commonplace).
You can alter **argv if you like, provided you don't overstep
bounds:
argv[0][0] = 'X';
is fine, albeit not all that useful.
But you *must not* alter *argv.
argv[0] = NULL;
is bad practice, and invokes undefined behaviour.
Quoth the Standard: "The parameters argc and argv and the strings
pointed to by the argv array shall be modifiable by the program,
and retain their last-stored values between program startup and
program termination." No such licence is given for the pointers
that make up the array to whose first element argv points.
pete
Nothing, really;
just like your previous code example.
--
pete
spinoza1111
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
>
> news:wu-dndqB-aDxnfHX...@bt.com...> > Too much, perhaps? Not that there's a limit, but for your own
> > benefit it may be better to think more and post less.
>
> Leave him be; he's single-handedly keeping this group alive it seems to me.
Heathfield is a bully. His *modus operandi* is to say something
wounding and critical that makes him the wise, all-knowing Parent and
his mark the Child in such a way that any self-defense from the latter
can be dismissed as whining. He enables other posters to then attack
the mark *du jour*.
Because his own accomplishments are very small, he especially enjoys
trying to destroy reputations of people who make real contributions
including Jacob Navia and Herbert Schildt.
Here, the OP exposes his vulnerability and like a real man questions
his own behavior. This opened him up to an attack from Heathfield, who
never with any sincerity questions his own world view, up to and
including Heathfield's self-serving claims about the "power" of C.
Heathfield is a homophobe and a religious fundamentalist who is made
anxious when two male posters have a friendly and equal exchange where
they admit their own limitations. This, I believe, is why he so
constantly feels the need to interrupt conversations where he is not
wanted.
He relies on the corporate assumption that there is, or should be, no
seniority or expertise EXCEPT seniority and expertise as a form of
terror, which can destroy people.
He is a cold and malicious person. Please just ignore him.
>
> --
> Bart
spinoza1111
>
> >> Chris M. Thomasson wrote:
>
> >>> #include <ctype.h>
> >>> char*
> >>> strtoupper(
> >>> char* const buf
> >>> ) {
> >>> char* cur = buf;
> >>> while (*cur) {
> >>> *cur = toupper(*cur);
> >>> ++cur;
> >>> }
> >>> return buf;
> >>> }
>
> >> If I were to use a const qualified object,
> >> in a function like that,
> >> it would be declared in the the function body.
>
> > Why? Do you really find it more readable to be
> > modifying your parameters?
>
> I modify parameters at every given opportunity.
>
> That's a large part of the point of having parameters.
>
> I've never written a prototype with a const qualified parameter.
That's C's pathology in a nutshell. Don't piss out the window. In
Beautiful Code, Brian Kernighan exhibits "beautiful" code which uses a
parameter as a work area. He thinks it's kewl. It is not.
Part of programming maturity is realizing that you DON'T have the
right to modify things.
>
>
>
>
>
>
>
> >> #include <ctype.h>
>
> >> char *
> >> str_toupper(char *buf)
> >> {
> >> char *const r = buf;
>
> >> while (*buf != '\0') {
> >> *buf = toupper(*buf);
> >> ++buf;
> >> }
> >> return r;
> >> }
>
> --
> pete- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Richard Heathfield
> On Jul 26, 6:11 pm, "bartc" <ba...@freeuk.com> wrote:
>> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
>>
>> news:wu-dndqB-aDxnfHX...@bt.com...
>>
>> > bpascal...@googlemail.com said:
>>
>> >> Hi,
>>
>> >> I'm posting quite a lot,
>>
>> > Too much, perhaps? Not that there's a limit, but for your own
>> > benefit it may be better to think more and post less.
>>
>> Leave him be; he's single-handedly keeping this group alive it
>> seems to me.
>
> Heathfield is a bully. His *modus operandi* is to say something
> wounding and critical
I don't see anything wounding about being advised to think more and
post less when one is thinking too briefly and writing too quickly.
The advice was intended to be helpful and constructive, and I
believe that it achieved this objective. What did *you* do to help
the OP?
> that makes him the wise, all-knowing Parent
You're full of it...
<snip>
> Heathfield is a homophobe
...and that's a lie.
<snip>
> This, I believe,
> is why he so constantly feels the need to interrupt conversations
> where he is not wanted.
As I have tried to explain to you before but you appear unable to
comprehend, Usenet is a threaded discussion medium, so it's
actually impossible to interrupt a conversation.
> He relies on the corporate assumption that there is, or should be,
> no seniority or expertise EXCEPT seniority and expertise as a form
> of terror, which can destroy people.
On the contrary, I stand by the principle that we should pay more
attention to those who know their subject than those who don't.
That is why I pay so little attention to you.
> He is a cold and malicious person. Please just ignore him.
If he wants to learn C, he would do better to listen to people who
know C than to people (like you) who don't.
Richard Heathfield
> On Jul 28, 10:47 am, pete <pfila...@mindspring.com> wrote:
<snip>
>>
>> I modify parameters at every given opportunity.
>>
>> That's a large part of the point of having parameters.
>>
>> I've never written a prototype with a const qualified parameter.
>
> That's C's pathology in a nutshell. Don't piss out the window. In
> Beautiful Code, Brian Kernighan exhibits "beautiful" code which
> uses a parameter as a work area. He thinks it's kewl. It is not.
>
> Part of programming maturity is realizing that you DON'T have the
> right to modify things.
Realising falsehoods is hardly mature.
If you don't wish to modify the parameter, const-qualify it. If you
do, don't. Whether you have the right to modify parameters is
properly a decision for you, the programmer, to make.
jacob navia
> spinoza1111 said:
>
>> On Jul 28, 10:47 am, pete <pfila...@mindspring.com> wrote:
> <snip>
>>> I modify parameters at every given opportunity.
>>>
>>> That's a large part of the point of having parameters.
>>>
>>> I've never written a prototype with a const qualified parameter.
>> That's C's pathology in a nutshell. Don't piss out the window. In
>> Beautiful Code, Brian Kernighan exhibits "beautiful" code which
>> uses a parameter as a work area. He thinks it's kewl. It is not.
>>
>> Part of programming maturity is realizing that you DON'T have the
>> right to modify things.
>
> Realising falsehoods is hardly mature.
>
> If you don't wish to modify the parameter, const-qualify it. If you
> do, don't. Whether you have the right to modify parameters is
> properly a decision for you, the programmer, to make.
>
Modifying a functions parameters is always a bad idea.
o It makes the function not restartable.
o Under the debugger you can't know what was the parameter
you received when the function misbehaves. You can't debug it.
o The small gain in storage you gain is not worth the
associated risks.
Richard Heathfield
> Richard Heathfield wrote:
<snip>
>>
>> If you don't wish to modify the parameter, const-qualify it. If
>> you do, don't. Whether you have the right to modify parameters is
>> properly a decision for you, the programmer, to make.
>>
>
> Modifying a functions parameters is always a bad idea.
I disagree. So do K&R (in K&R2, at least). See p105.
> o It makes the function not restartable.
You lost me. I am sure it is possible to construct a function in
which modifying its parameter makes it non-restartable, but you
don't /have/ to construct functions that way.
> o Under the debugger you can't know what was the parameter
> you received when the function misbehaves. You can't debug it.
Maybe you can't, but I can - by setting a breakpoint at an
appropriate place and making a note of the value before the mod.
> o The small gain in storage you gain is not worth the
> associated risks.
What risk do you see in:
void intcopy(int *s, int *t, int term)
{
while((*s++ = *t++) != term) {}
}
that isn't also present in:
void intcopy(int *s, int *t, int term)
{
int *u = s;
int *v = t;
while((*u++ = *v++) != term) {}
}
?
Ben Pfaff
> What risk do you see in:
>
> void intcopy(int *s, int *t, int term)
> {
> while((*s++ = *t++) != term) {}
> }
>
> that isn't also present in:
>
> void intcopy(int *s, int *t, int term)
> {
> int *u = s;
> int *v = t;
> while((*u++ = *v++) != term) {}
> }
I would say that the latter is riskier, because there are more
entities for me to keep track of as I read it. It is easier to
understand the behavior of three variables than five.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
bartc
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
> jacob navia said:
>
>> Richard Heathfield wrote:
> <snip>
>>>
>>> If you don't wish to modify the parameter, const-qualify it. If
>>> you do, don't. Whether you have the right to modify parameters is
>>> properly a decision for you, the programmer, to make.
>>>
>>
>> Modifying a functions parameters is always a bad idea.
> What risk do you see in:
>
> void intcopy(int *s, int *t, int term)
> {
> while((*s++ = *t++) != term) {}
> }
It's more of a problem in this form:
void intcopy(int *dest, int *source, int term)
{
while((*dest++ = *source++) != term) {}
}
At the end of the while loop, dest and source don't point where you might
expect from their names, at least for someone looking to extend it.
And (a bit of a long-shot), if your code is ported to a language where
parameters are passed by reference, it may generate side-effects in the
caller.
> that isn't also present in:
>
> void intcopy(int *s, int *t, int term)
> {
> int *u = s;
> int *v = t;
> while((*u++ = *v++) != term) {}
> }
>
> ?
--
Bart
Richard Heathfield
>
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:YO2dnZlBmeXSOe3X...@bt.com...
>> jacob navia said:
>>
>>> Richard Heathfield wrote:
>> <snip>
>>>>
>>>> If you don't wish to modify the parameter, const-qualify it. If
>>>> you do, don't. Whether you have the right to modify parameters
>>>> is properly a decision for you, the programmer, to make.
>>>>
>>>
>>> Modifying a functions parameters is always a bad idea.
>
>> What risk do you see in:
>>
>> void intcopy(int *s, int *t, int term)
>> {
>> while((*s++ = *t++) != term) {}
>> }
>
> It's more of a problem in this form:
>
> void intcopy(int *dest, int *source, int term)
> {
> while((*dest++ = *source++) != term) {}
> }
>
> At the end of the while loop, dest and source don't point where
> you might expect from their names,
They point where I might expect from the code. Note, too, that to
find fault with my code you had first to change it, which suggests
to me that the problem you envisage is avoidable.
> at least for someone looking to extend it.
My expectation from reading the code is met by the actual behaviour
of the code? Why should my expectation change just because I then
decide to extend the code?
> And (a bit of a long-shot), if your code is ported to a language
> where parameters are passed by reference, it may generate
> side-effects in the caller.
A long shot? That's practically interstellar. If side effects are
your worst problem when taking code written in C and pretending it
is written in some other language, you are most fortunate.
<snip>
bpasc...@googlemail.com
> --
> Nick Keighley
>
> "Programs must be written for people to read, and only
> incidentally for machines to execute."
> - Abelson & Sussman, Structure and Interpretation of Computer Programs
Thanks
pete
> This, I believe, is why he so
> constantly feels the need to interrupt conversations where he is not
> wanted.
That's what you are doing here.
The topic is:
Help a beginner - simple lowercase to uppercase and so on function
--
pete
Richard Heathfield
> spinoza1111 wrote:
>
>> This, I believe, is why he so
>> constantly feels the need to interrupt conversations where he is
>> not wanted.
>
> That's what you are doing here.
Um, no, he isn't. He is simply spinning off a sub-thread. The
original discussion has not been interrupted. It has died, it's
true, but that death bears all the hallmarks of natural causes.
> The topic is:
> Help a beginner - simple lowercase to uppercase and so on
> function
That's the topic with which the thread started. This subthread has
drifted, but anyone wishing to contribute to the thread's original
topic can do so by replying to an upthread article.
spinoza1111
> Richard Heathfield wrote:
> >spinoza1111said:
>
A Daniel, a Daniel come to judgement. Five star post.
spinoza1111
> jacob navia said:
>
>
>
> > Richard Heathfield wrote:
> <snip>
>
> >> If you don't wish to modify the parameter, const-qualify it. If
> >> you do, don't. Whether you have the right to modify parameters is
> >> properly a decision for you, the programmer, to make.
>
> > Modifying a functions parameters is always a bad idea.
>
> I disagree. So do K&R (in K&R2, at least). See p105.
>
> > o It makes the function not restartable.
>
> You lost me. I am sure it is possible to construct a function in
> which modifying its parameter makes it non-restartable, but you
> don't /have/ to construct functions that way.
He lost you. You cannot interrupt the function in the debugger, make a
correction to the source, and restart the function from the beginning,
because it's changed its parameter. You can reset the parameter but
that's one more detail.
A real programmer has a strong idea in his mind of a pure zuivere
reine Procedure operating on distinct data.
>
> > o Under the debugger you can't know what was the parameter
> > you received when the function misbehaves. You can't debug it.
>
> Maybe you can't, but I can - by setting a breakpoint at an
> appropriate place and making a note of the value before the mod.
>
> > o The small gain in storage you gain is not worth the
> > associated risks.
>
> What risk do you see in:
>
> void intcopy(int *s, int *t, int term)
> {
> while((*s++ = *t++) != term) {}
>
> }
>
> that isn't also present in:
>
> void intcopy(int *s, int *t, int term)
> {
> int *u = s;
> int *v = t;
> while((*u++ = *v++) != term) {}
>
> }
Semantically as opposed to syntactically, the programs are identical.
If their INTENT is to modify s and t neither suck and the first is
better. We're talking about the modification of value parameters as
seen in Dennis Ritchie's scanner as reproduced in Beautiful Code.
A real programmer doesn't piss on value parameters even though they
are copies of original values on the stack, because before becoming a
coding ape, a real programmer studied real math. He has learned the
power of functions.
>
> ?
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> Forged article? Seehttp://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
Phil Carmody
> jacob navia said:
>
>> Richard Heathfield wrote:
> <snip>
>>>
>>> If you don't wish to modify the parameter, const-qualify it. If
>>> you do, don't. Whether you have the right to modify parameters is
>>> properly a decision for you, the programmer, to make.
>>>
>>
>> Modifying a functions parameters is always a bad idea.
>
> I disagree. So do K&R (in K&R2, at least). See p105.
<AOL/>
>> o It makes the function not restartable.
>
> You lost me. I am sure it is possible to construct a function in
> which modifying its parameter makes it non-restartable, but you
> don't /have/ to construct functions that way.
I conclude he's got an allergy to, or a phobia of, tail recursion.
And probably other wonderfully useful programming paradigms too, I
wonder.
Phil
--
If GML was an infant, SGML is the bright youngster far exceeds
expectations and made its parents too proud, but XML is the
drug-addicted gang member who had committed his first murder
before he had sex, which was rape. -- Erik Naggum (1965-2009)
Phil Carmody
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:YO2dnZlBmeXSOe3X...@bt.com...
>> jacob navia said:
>>
>>> Richard Heathfield wrote:
>> <snip>
>>>>
>>>> If you don't wish to modify the parameter, const-qualify it. If
>>>> you do, don't. Whether you have the right to modify parameters is
>>>> properly a decision for you, the programmer, to make.
>>>>
>>>
>>> Modifying a functions parameters is always a bad idea.
>
>> What risk do you see in:
>>
>> void intcopy(int *s, int *t, int term)
>> {
>> while((*s++ = *t++) != term) {}
>> }
>
> It's more of a problem in this form:
>
> void intcopy(int *dest, int *source, int term)
> {
> while((*dest++ = *source++) != term) {}
> }
>
> At the end of the while loop, dest and source don't point where you
> might expect from their names, at least for someone looking to extend
> it.
Nope, you're thinking of this form:
void intcopy(int *deststart, int *sourcestart, int term)
{
while((*deststart++ = *sourcestart++) != term) {}
spinoza1111
wrote:
> Richard Heathfield <r...@see.sig.invalid> writes:
> > jacob navia said:
>
> >> Richard Heathfield wrote:
> > <snip>
>
> >>> If you don't wish to modify the parameter, const-qualify it. If
> >>> you do, don't. Whether you have the right to modify parameters is
> >>> properly a decision for you, the programmer, to make.
>
> >> Modifying a functions parameters is always a bad idea.
>
> > I disagree. So do K&R (in K&R2, at least). See p105.
>
> <AOL/>
>
> >> o It makes the function not restartable.
>
> > You lost me. I am sure it is possible to construct a function in
> > which modifying its parameter makes it non-restartable, but you
> > don't /have/ to construct functions that way.
>
> I conclude he's got an allergy to, or a phobia of, tail recursion.
> And probably other wonderfully useful programming paradigms too, I
> wonder.
His practice makes it rather hard to optimize compilers. Of course C
optimizers will not if competently written confuse a parameter without
const with a read-only parameter. But the clowns here who are proud of
the studly way they modify non-const parameters passed by value and
without taking the address aren't even aware of how their code can't
be improved by an optimizer, or they are proud of this fact.
Using a non-const parameter without & is like the consultant who
borrows your watch to tell you the time, and walks away with the
watch. The caller never sees these monkeyshines: HIS copy of the
variable is unchanged. Nonetheless the programmer has offended against
the notion of a software contract.
Many runtimes will access local variables faster than parameters
especially for modification. The storage efficiency of munging a
parameter is canceled here by time inefficiency.
And there always remains the practical fact that good C programmers,
especially those coming in from safe languages, will always be
surprised to find that the non-const, non-ref parameter's input value
has changed when they need the original value after the end of the
loop.
Modifying these parameters is bad style.
bartc
"Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in message
news:87k51ql...@kilospaz.fatphil.org...
> "bartc" <ba...@freeuk.com> writes:
>> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
>> news:YO2dnZlBmeXSOe3X...@bt.com...
>>> jacob navia said:
>>>
>>>> Richard Heathfield wrote:
>>> <snip>
>>>>>
>>>>> If you don't wish to modify the parameter, const-qualify it. If
>>>>> you do, don't. Whether you have the right to modify parameters is
>>>>> properly a decision for you, the programmer, to make.
>>>>>
>>>>
>>>> Modifying a functions parameters is always a bad idea.
>>
>>> What risk do you see in:
>>>
>>> void intcopy(int *s, int *t, int term)
>>> {
>>> while((*s++ = *t++) != term) {}
>>> }
>>
>> It's more of a problem in this form:
>>
>> void intcopy(int *dest, int *source, int term)
>> {
>> while((*dest++ = *source++) != term) {}
>> }
>>
>> At the end of the while loop, dest and source don't point where you
>> might expect from their names, at least for someone looking to extend
>> it.
>
> Nope, you're thinking of this form:
>
> void intcopy(int *deststart, int *sourcestart, int term)
> {
> while((*deststart++ = *sourcestart++) != term) {}
> }
OK, more like this then:
void intcopy(int *originaldeststart, int *originalsourcestart, int term)
{
while((*originaldeststart++ = *originalsourcestart++) != term) {}
}
--
Bart
Nick Keighley
> Richard Heathfield wrote:
<snip>
> > If you don't wish to modify the parameter, const-qualify it. If you
> > do, don't. Whether you have the right to modify parameters is
> > properly a decision for you, the programmer, to make.
>
> Modifying a functions parameters is always a bad idea.
>
> o It makes the function not restartable.
>
> o Under the debugger you can't know what was the parameter
> you received when the function misbehaves. You can't debug it.
>
> o The small gain in storage you gain is not worth the
> associated risks.
how do you return more than one thing?
ErrorCode calculate_average (double *average,
const int values[],
int count);
how would you code this?
void swop (int *n, int *m);
jacob navia
The value the calculate-average receives is the address
where it should store the result. That value is not modified
at all!
> how would you code this?
>
> void swop (int *n, int *m);
>
Same as above
Dik T. Winter
...
> Using a non-const parameter without & is like the consultant who
> borrows your watch to tell you the time, and walks away with the
> watch.
What is the sense of using '&' with a non-const parameter in C?
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
spinoza1111
wrote:
> On 29 July, 18:28, jacob navia <ja...@nospam.org> wrote:
>
> > Richard Heathfield wrote:
>
> <snip>
>
> > > If you don't wish to modify the parameter, const-qualify it. If you
> > > do, don't. Whether you have the right to modify parameters is
> > > properly a decision for you, the programmer, to make.
>
> > Modifying a functions parameters is always a bad idea.
>
> > o It makes the function not restartable.
>
> > o Under the debugger you can't know what was the parameter
> > you received when the function misbehaves. You can't debug it.
>
> > o The small gain in storage you gain is not worth the
> > associated risks.
>
> how do you return more than one thing?
You don't use C. Or, didn't your mother teach you about structs?
>
> ErrorCode calculate_average (double *average,
> const int values[],
> int count);
>
> how would you code this?
I wouldn't. Although it is "good" C, sub specie aeternitatis it's
actually a bone-head mess.
You have two pieces of information in two different places, and if
count is incorrect, you will wind up crashing...or using random data
with no error indication whatsoever.
And DON'T start that shit about "competent programmers", because it's
stupid and macho talk. YOU have no control over the subroutine
parameters as passed, and note that you CANNOT check count for
correctness.
Whereas in a modern language, "count" wouldn't be necessary being the
upper bound.
But even competent programmers in older languages such as Fortran knew
how to minimize the number of different things being returned which
you don't. Void the return but return something that cannot
mathematically be a sensible average in "average".
spinoza1111
> In article <38bd29e0-d231-4b76-a16d-e6b7cd0c4...@y10g2000prf.googlegroups.com>spinoza1111<spinoza1...@yahoo.com> writes:
> ...
> > Using a non-const parameter without & is like the consultant who
> > borrows your watch to tell you the time, and walks away with the
> > watch.
>
> What is the sense of using '&' with a non-const parameter in C?
Clarification: I meant a non-const parm not declared using the inverse
operator *, but it was pretty obvious what I meant. Part of the
problem, and I've said this before, is that Ritchie designed-in some
fairly perverse thought patterns in order to be cute as a member of a
protected technical caste. This means that it's impossible to speak
with either intelligence or elegance about C.
Dik T. Winter
> On Jul 30, 8:14=A0pm, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote:
...
> > What is the sense of using '&' with a non-const parameter in C?
>
> Clarification: I meant a non-const parm not declared using the inverse
> operator *, but it was pretty obvious what I meant. Part of the
> problem, and I've said this before, is that Ritchie designed-in some
> fairly perverse thought patterns in order to be cute as a member of a
> protected technical caste.
Value parameters that act as local variables is not entirely newly thought
off by Ritchie...
Antoninus Twink
> bpasc...@googlemail.com said:
>> I'm posting quite a lot,
>
> Too much, perhaps? Not that there's a limit, but for your own
> benefit it may be better to think more and post less.
Physician, heal thyself.
> Better to stop, think, and think again.
"Indeed".
Antoninus Twink
> bartc said:
>> Leave him be;
>
> I'm not attacking him. I'm trying to help him.
Sure, Heathfield.
Like you don't attack Jacob, do you? You "just try to help him". Of
course.
If it has a tail and barks, you can't blame Bart for calling it a dog.
Antoninus Twink
> spinoza1111 said:
>
> ...and that's a lie.
Really? It would certainly fit with your christian fundamentalist
beliefs.
We know that you're an anti-semite, but I'd be interested to see the
evidence of your homophobia.
Antoninus Twink
> jacob navia said:
>> o Under the debugger you can't know what was the parameter
>> you received when the function misbehaves. You can't debug it.
>
> Maybe you can't, but I can - by setting a breakpoint at an
> appropriate place and making a note of the value before the mod.
Great, Heathfield.
It is clear that Jacob was referring to debugging from a core file, but
as usual you deliberately misinterpret what he was saying.
Phil Carmody
> In article <38bd29e0-d231-4b76...@y10g2000prf.googlegroups.com> spinoza1111 <spino...@yahoo.com> writes:
> ...
> > Using a non-const parameter without & is like the consultant who
> > borrows your watch to tell you the time, and walks away with the
> > watch.
>
> What is the sense of using '&' with a non-const parameter in C?
What does that even mean?
(I come from a school that differentiates between arguments and
parameters. I suspect that different interpretations of the words
may lead to different evaluations of the above, but would rather
not delve into such perversities unguided.)
Phil Carmody
Yeah!
Don't do that.
I'm glad we're all finally agreed on something.
Ben Pfaff
> "Dik T. Winter" <Dik.W...@cwi.nl> writes:
>> What is the sense of using '&' with a non-const parameter in C?
>
> What does that even mean?
void foo(int x)
{
&x;
Phil Carmody
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>
>> "Dik T. Winter" <Dik.W...@cwi.nl> writes:
>>> What is the sense of using '&' with a non-const parameter in C?
>>
>> What does that even mean?
>
> void foo(int x)
> {
> &x;
> }
No "using" there. Representing, yes, but no "using".
Keith Thompson
> "Dik T. Winter" <Dik.W...@cwi.nl> writes:
>> In article
>> <38bd29e0-d231-4b76...@y10g2000prf.googlegroups.com>
>> spinoza1111 <spino...@yahoo.com> writes: ...
>> > Using a non-const parameter without & is like the consultant who
>> > borrows your watch to tell you the time, and walks away with the
>> > watch.
>>
>> What is the sense of using '&' with a non-const parameter in C?
>
> What does that even mean?
I think spinoza1111 is advocating the use of reference parameters,
and not realizing that they exist in C++ but not in C.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
spinoza1111
> In article <f529bebf-2884-46e1-aa7c-e89aa4657...@g1g2000pra.googlegroups.com>spinoza1111<spinoza1...@yahoo.com> writes:
> > On Jul 30, 8:14=A0pm, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote:
> ...
> > > What is the sense of using '&' with a non-const parameter in C?
> >
> > Clarification: I meant a non-const parm not declared using the inverse
> > operator *, but it was pretty obvious what I meant. Part of the
> > problem, and I've said this before, is that Ritchie designed-in some
> > fairly perverse thought patterns in order to be cute as a member of a
> > protected technical caste.
>
> Value parameters that act as local variables is not entirely newly thought
> off by Ritchie...
No, he had twenty years of bad practice to draw upon: weekend hippie
programmers who thought they were being clever.
Suppose you want to run your C source code on a machine, on whose
stacks the parameters are read-only. For whatever reason, you can only
modify your local variables.
I don't know whether such a machine exist but it could.
Modifying a parameter on the stack is to assert in a hidden fashion
that "I have access to the stack for modification, and I know it".
Hidden assertions are bugs waiting to happen.
spinoza1111
> Phil Carmody <thefatphil_demun...@yahoo.co.uk> writes:
> > "Dik T. Winter" <Dik.Win...@cwi.nl> writes:
> >> In article
> >> <38bd29e0-d231-4b76-a16d-e6b7cd0c4...@y10g2000prf.googlegroups.com>
> >> > Using a non-const parameter without & is like the consultant who
> >> > borrows your watch to tell you the time, and walks away with the
> >> > watch.
>
> >> What is the sense of using '&' with a non-const parameter in C?
>
> > What does that even mean?
>
> [...]
>
> and not realizing that they exist in C++ but not in C.
These tiresome verbal quibbles are the stock in trade
Of fat bearded and pompous men, who then pretend
That their roteish knowledge of words and words only, their pedantry,
Is true knowledge. Passing by reference in C
Is passing an address by value, and is oft distinguished
By calling it passing by reference. But Fat Bastards
And other dastards of the data processing tribe,
Like to interrupt conversation between friends
And destroy even the semblance of comitious amity
Replacing it by frowns, hard looks and contumacious contumely,
And this is why they pretend to be so fussy about terminology.
They question credibility with no necessity, and men defend themselves
'Gainst such vile reproach as is natural, men not being elves,
Sprites that can turn aside and shyly flee to forest wide.
Dolt, I have long forgot more C than thou shalt ever see
Fool, I have gained wisdom enow for its usage to eschew.
Creep, my use of words deceivest thou thy dull villain's brain:
Pedant, thy open and knavish tricks I hereby do disdain.
Ape, keepst thou thy paw from response:
Snake, crawls't away whilst thou livest for this nonce.
I was passing gas by value coding parms before thou wast born:
I was referencing inversely to asterisk when men did thee as infant,
scorn.
Call me by reference, call me by name,
Call me what name thou wilt, you'll me not shame:
Call me by value, caitiff, and make an end
Thee thy Sophist's words to wisdom only pretend.
spinoza1111
Let's drink a toast the Antoninus Twink
He's nailing Heathfield. Buy the man a drink.
Chris M. Thomasson
> Chris M. Thomasson said:
>
> <snip>
>
>> char*
>> strtoupper(
>
> You just trod on the implementation's namespace.
>
> <snip>
Oh shi%! ;^(...
Phil Carmody
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>> "Dik T. Winter" <Dik.W...@cwi.nl> writes:
>>> In article
>>> <38bd29e0-d231-4b76...@y10g2000prf.googlegroups.com>
>>> spinoza1111 <spino...@yahoo.com> writes: ...
>>> > Using a non-const parameter without & is like the consultant who
>>> > borrows your watch to tell you the time, and walks away with the
>>> > watch.
>>>
>>> What is the sense of using '&' with a non-const parameter in C?
>>
>> What does that even mean?
> [...]
>
> I think spinoza1111 is advocating the use of reference parameters,
> and not realizing that they exist in C++ but not in C.
Oh gawd. I think you're right. That's just plain sad.
Richard Heathfield
<snip>
> Suppose you want to run your C source code on a machine, on whose
> stacks the parameters are read-only. For whatever reason, you can
> only modify your local variables.
>
> I don't know whether such a machine exist but it could.
On such a machine, the implementation would be required by the
Standard to find somewhere else other than a stack in which to pass
parameters.
> Modifying a parameter on the stack is to assert in a hidden fashion
> that "I have access to the stack for modification, and I know it".
Taking the stack out of the equation, since C doesn't require one:
Modifying a parameter is to assert that one may modify parameters. The
C Standard supports this assertion.
> Hidden assertions are bugs waiting to happen.
There's nothing hidden about it. See ISO/IEC 9899.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
This line unintentionally left unblank
Richard Heathfield
If by "nailing" you mean "lying about", perhaps. I have no idea why he
ascribes either anti-Semitism or homophobia to me, but it's simply
false, like much that he says about me. It's about as accurate as
your own claims that I'm a Nazi working for MI5.
spinoza1111
> spinoza1111said:
>
> <snip>
>
> > Suppose you want to run your C source code on a machine, on whose
> > stacks the parameters are read-only. For whatever reason, you can
> > only modify your local variables.
>
> > I don't know whether such a machine exist but it could.
>
> On such a machine, the implementation would be required by the
> Standard to find somewhere else other than a stack in which to pass
> parameters.
>
> > Modifying a parameter on the stack is to assert in a hidden fashion
> > that "I have access to the stack for modification, and I know it".
>
> Taking the stack out of the equation, since C doesn't require one:
>
> Modifying a parameter is to assert that one may modify parameters. The
> C Standard supports this assertion.
Reason not the need, like Lear?
Mathematically speaking, you never need to either modify the values of
parameters that are accessible to the callers, and you never need to
re-use the space occupied by value parameters by overwriting them with
your own silly values.
In the first case, in an object oriented language, you always have the
ontological choice to declare a new Thing which includes things. It
has long been trivial to "wrap" > 1 value in structs in C, and if I
were a nasty person like you, I'd of course now be claiming, falsely,
that you don't know structs.
But I'm not a nasty piece of work, like you. You know structs but
somehow when you claimed that you need to alter the values of
parameters passed "by reference" (prefixed with asterisks) you forgot
about structs. This is called a brain fart, and the charter of this ng
needs to be amended, calling for any poster, who exagerrates brain
farts, Malapropisms, incorrect "terminology" and other aporias into
libelous claims that the neurologically flatulent, the Malaprop, the
users of incorrect words, and the rest of the Aporiites are globally
incompetent, to be shunned.
Furthermore, you don't see that the more assertions a program depends
upon the unsafer it is, not only in the groves of academe but also in
the real world, such as that chip shop you infest. Occam's Razor is in
Fluellen's words an excellent moral, and it applies more to
propositions than to things.
Good programmers do ontology. Instead of relying on mythological
knowledge they see that (for example) a function's normal return and
its "error code" form mathematically speaking the single value of the
function.
Bad programmers instead pride themselves on knowing a lot of rote
detail and lust to impose this rote detail on others.
So: don't use value parms as notepaper. Create a local variable like a
normal person and either name it after its purpose, or if you must use
it in different ways in different areas of your code, call it after
its overall function. I like intIndex1/2 ... n in memory of the
limited set of index registers on second generation machines.
>
> > Hidden assertions are bugs waiting to happen.
>
> There's nothing hidden about it. See ISO/IEC 9899.
Wow, soon to be a major motion picture. The C Standard. Featuring Herb
Schildt taking your girl while you hold his ball.
spinoza1111
> spinoza1111said:
>
>
>
>
>
> >> On 29 Jul 2009 at 17:24, Richard Heathfield wrote:
>
> >> >spinoza1111said:
> >> >> Heathfield is a homophobe
>
> >> > ...and that's a lie.
>
> >> Really? It would certainly fit with your christian fundamentalist
> >> beliefs.
>
> >> We know that you're an anti-semite, but I'd be interested to see
> >> the evidence of your homophobia.
>
> > Let's drink a toast the Antoninus Twink
> > He's nailing Heathfield. Buy the man a drink.
>
> If by "nailing" you mean "lying about", perhaps. I have no idea why he
> ascribes either anti-Semitism or homophobia to me, but it's simply
> false, like much that he says about me. It's about as accurate as
> your own claims that I'm a Nazi working for MI5.
Your conduct (spreading rumors about people) is isomorphic to anti-
Semitic conduct in the sense that its structures are the same. You
also delight in making sure that posters fall to blows rather than
become friends, and this is due, I believe, to homophobia.
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> This line unintentionally left unblank- Hide quoted text -
>
> - Show quoted text -
spinoza1111
wrote:
> Keith Thompson <ks...@mib.org> writes:
> > Phil Carmody <thefatphil_demun...@yahoo.co.uk> writes:
> >> "Dik T. Winter" <Dik.Win...@cwi.nl> writes:
> >>> In article
> >>> <38bd29e0-d231-4b76-a16d-e6b7cd0c4...@y10g2000prf.googlegroups.com>
> >>> > Using a non-const parameter without & is like the consultant who
> >>> > borrows your watch to tell you the time, and walks away with the
> >>> > watch.
>
> >>> What is the sense of using '&' with a non-const parameter in C?
>
> >> What does that even mean?
> > [...]
>
> > and not realizing that they exist in C++ but not in C.
>
> Oh gawd. I think you're right. That's just plain sad.
(Sigh). The value of the address is on the stack. So it's to the
literal minded incompetent a call by value. However, the value of the
address is easily "dereferenced" using, if memory serves...wait
a...minute...oh yes, asterisk (god forbid Ritchie should use English).
All parameters are passed in C "by value" in that sense alone. But if
that were the only sense, then call by reference in any runtime that
uses a stack would involve the absurd algorithm of "moving" the byref
value to the stack, somehow destroying its original "version", letting
the subroutine do its wicked will, and then moving it back.
Some idiot may have done this. Some foul troll.
Of course, by reference calling in a programming language is SUPPORTED
by passing the address by value. I am surprised you don't know this.
Gee, you're probably incompetent and a pedophile (when in Rome...).
>
> Phil
> --
> If GML was an infant, SGML is the bright youngster far exceeds
> expectations and made its parents too proud, but XML is the
> drug-addicted gang member who had committed his first murder
> before he had sex, which was rape. -- Erik Naggum (1965-2009)- Hide quoted text -
Richard Heathfield
> On Jul 31, 12:25 pm, Richard Heathfield <r...@see.sig.invalid>
> wrote:
>> spinoza1111said:
>>
>> <snip>
>>
>> > Suppose you want to run your C source code on a machine, on whose
>> > stacks the parameters are read-only. For whatever reason, you can
>> > only modify your local variables.
>>
>> > I don't know whether such a machine exist but it could.
>>
>> On such a machine, the implementation would be required by the
>> Standard to find somewhere else other than a stack in which to pass
>> parameters.
>>
> Oooooohhh the Standard.
Yes, the Standard. In this case, as in a great many cases, a knowledge
of the Standard means that we don't have to run from chimerae such as
"not having the right to modify parameters", because the Standard
explicitly gives us this right, and therefore we know we can do this
provided we are using a conforming implementation.
>> > Modifying a parameter on the stack is to assert in a hidden
>> > fashion that "I have access to the stack for modification, and I
>> > know it".
>>
>> Taking the stack out of the equation, since C doesn't require one:
>>
>> Modifying a parameter is to assert that one may modify parameters.
>> The C Standard supports this assertion.
>
> Reason not the need, like Lear?
That appears to be a non sequitur. If we need to modify parameters, we
can do that. If we /wish/ to modify parameters, we can do that. If we
choose not to modify parameters, we can refrain (and employ the
assistance of the language in preventing us from doing so
accidentally).
> Mathematically speaking, you never need to either modify the values
> of parameters that are accessible to the callers, and you never need
> to re-use the space occupied by value parameters by overwriting them
> with your own silly values.
Ignoring "silly", it is true that you never /need/ to modify parameter
values, because it's possible (and indeed easy) to make copies and
modify the copies. It is nevertheless sometimes clearer to modify
parameter values than to modify copies thereof, and clear code pays
dividends when it comes to maintaining the program.
> In the first case, in an object oriented language, you always have
> the ontological choice to declare a new Thing which includes things.
> It has long been trivial to "wrap" > 1 value in structs in C, and if
> I were a nasty person like you, I'd of course now be claiming,
> falsely, that you don't know structs.
Mu.
> But I'm not a nasty piece of work, like you. You know structs but
> somehow when you claimed that you need to alter the values of
> parameters passed "by reference" (prefixed with asterisks) you
> forgot about structs.
Perhaps you would care to support this assertion with a message ID.
> This is called a brain fart,
If it happened (and if you interpreted it correctly, which is
unlikely).
> and the charter of this ng needs to be amended,
This newsgroup has no charter.
<snip>
> Furthermore, you don't see that the more assertions a program
> depends upon the unsafer it is,
The Standard makes certain guarantees on which a programmer can rely
if he (or she) is using a conforming implementation (and makes
further guarantees for those using conforming hosted
implementations). If you are not using a conforming implementation,
then you cannot rely on such guarantees. This is surely obvious.
<nonsense snipped>
> So: don't use value parms as notepaper.
You have not explained why one should not do this.
All else being equal, one should feel free to modify parameters when
it makes the code clearer and easier to read, but not when it
doesn't.
<nonsense snipped>
Richard Heathfield
<snip>
> Your conduct (spreading rumors about people)
Mu.
<snip>
Dik T. Winter
> On Jul 30, 10:20 pm, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote:
> com>spinoza1111<spinoza1...@yahoo.com> writes:
...
> > > Part of the
> > > problem, and I've said this before, is that Ritchie designed-in some
> > > fairly perverse thought patterns in order to be cute as a member of a
> a
> > > protected technical caste.
> >
> > Value parameters that act as local variables is not entirely newly thought
> > off by Ritchie...
>
> No, he had twenty years of bad practice to draw upon: weekend hippie
> programmers who thought they were being clever.
The Algol 60 report is quite clear about it.
"4.7.3.1. Value assignment (call by value). All formal parameters quoted
in the value part of the procedure declaration heading are assigned the
values (cf. section 2.8. Values and types) of the corresponding actual
parameters, these assignments being considers as being performed
explicitly before entering the procedure body. The effect is as though
an additional block embracing the procedure body were created in which
these assignments were made to variables local to this fictitious block
with types as given in the corresponding specifications (cf. section
5.4.5). As a consequence, variables called by value are to be considered
as nonlocal to the body of the procedure, but local to the fictitious
block (cf. section 5.4.3)."
And who of J.W. Backus, F.L. Bauer, J. Green, C. Katz, J. McCarthy, P. Naur,
A.J. Perlis, H. Rutishauser, K. Samuelson, B. Vauquois, J.H. Wegstein,
A. van Wijngaarden or M. Woodger are the "weekend hippie programmers"
avant le lettre?
> Suppose you want to run your C source code on a machine, on whose
> stacks the parameters are read-only. For whatever reason, you can only
> modify your local variables.
Well, apparently the people mentioned above gave clear semantics...
> Modifying a parameter on the stack is to assert in a hidden fashion
> that "I have access to the stack for modification, and I know it".
Wrong. See the semantics above.
Dik T. Winter
...
> Of course, by reference calling in a programming language is SUPPORTED
> by passing the address by value. I am surprised you don't know this.
There is one more thing needed to support it. Within the body of the routine
there should be no distinction whether a parameter is by reference or by
value, accessing its value should be the same.
Or do you assert that C also has call by reference to reference, ad
infinitum?
spinoza1111
> spinoza1111said:
>
>
>
>
>
> > On Jul 31, 12:25 pm, Richard Heathfield <r...@see.sig.invalid>
> > wrote:
> >> spinoza1111said:
>
> >> <snip>
>
> >> > Suppose you want to run your C source code on a machine, on whose
> >> > stacks the parameters are read-only. For whatever reason, you can
> >> > only modify your local variables.
>
> >> > I don't know whether such a machine exist but it could.
>
> >> On such a machine, the implementation would be required by the
> >> Standard to find somewhere else other than a stack in which to pass
> >> parameters.
>
> > Oooooohhh the Standard.
>
> Yes, the Standard. In this case, as in a great many cases, a knowledge
> of the Standard means that we don't have to run from chimerae such as
> "not having the right to modify parameters", because the Standard
> explicitly gives us this right, and therefore we know we can do this
> provided we are using a conforming implementation.
Yeah, the standard is a big fat help when you're using a non-
conformant compiler. Non-conformant compilers are Legion, but we can
always defraud the user by saying that our non-working code is
"standard".
>
> >> > Modifying a parameter on the stack is to assert in a hidden
> >> > fashion that "I have access to the stack for modification, and I
> >> > know it".
>
> >> Taking the stack out of the equation, since C doesn't require one:
>
> >> Modifying a parameter is to assert that one may modify parameters.
> >> The C Standard supports this assertion.
>
> > Reason not the need, like Lear?
>
> That appears to be a non sequitur. If we need to modify parameters, we
> can do that. If we /wish/ to modify parameters, we can do that. If we
> choose not to modify parameters, we can refrain (and employ the
> assistance of the language in preventing us from doing so
> accidentally).
>
Remind me never to pass you any parameters. I don't want you munging
even copies I never see. It makes me ill to think of your clunky code
destroying the values I have passed to you. When your code crashes as
it probably does, I don't want to simultaneously have you whine that
it is standard and thus bug-free, and try to recover what I sent you.
I will never, not in a million years, give you a job if I am in a
position to do so, and I will refuse any job offers from you. Aren't
you glad we've cleared this up?
Dijkstra said somewhere that a good programmer has good taste, unlike
Charlie the Tuna what tasted good.
Programming on purpose means not messing around, and programmers who
think that it shows intelligence to mung parameters not intended to
be munged are messing around and showing off. I don't care if they are
"Dennis Ritchie".
> > Mathematically speaking, you never need to either modify the values
> > of parameters that are accessible to the callers, and you never need
> > to re-use the space occupied by value parameters by overwriting them
> > with your own silly values.
>
> Ignoring "silly", it is true that you never /need/ to modify parameter
> values, because it's possible (and indeed easy) to make copies and
> modify the copies. It is nevertheless sometimes clearer to modify
> parameter values than to modify copies thereof, and clear code pays
> dividends when it comes to maintaining the program.
The incompetent programmer is among other things prone to profoundly
narcissistic reasoning. He reasons that what is clear to him at the
time is Clear for all time.
>
> > In the first case, in an object oriented language, you always have
> > the ontological choice to declare a new Thing which includes things.
> > It has long been trivial to "wrap" > 1 value in structs in C, and if
> > I were a nasty person like you, I'd of course now be claiming,
> > falsely, that you don't know structs.
>
> Mu.
>
> > But I'm not a nasty piece of work, like you. You know structs but
> > somehow when you claimed that you need to alter the values of
> > parameters passed "by reference" (prefixed with asterisks) you
> > forgot about structs.
>
> Perhaps you would care to support this assertion with a message ID.
Do your own homework, or sue me.
>
> > This is called a brain fart,
>
> If it happened (and if you interpreted it correctly, which is
> unlikely).
>
> > and the charter of this ng needs to be amended,
>
> This newsgroup has no charter.
Lucky you
>
> <snip>
>
> > Furthermore, you don't see that the more assertions a program
> > depends upon the unsafer it is,
>
> The Standard makes certain guarantees on which a programmer can rely
> if he (or she) is using a conforming implementation (and makes
> further guarantees for those using conforming hosted
> implementations). If you are not using a conforming implementation,
> then you cannot rely on such guarantees. This is surely obvious.
This is absurd. To say that a programmer should be held harmless for
the mess he makes (such as destroying the value of parameters in such
a way as to make a program hard to debug when it crashes near its end)
because he's "conformed" to the standard is weasel-assed reasoning. To
depend on a maximal set of assertions in a situation of uncertainty is
foolishness.
>
> <nonsense snipped>
>
> > So: don't use value parms as notepaper.
>
> You have not explained why one should not do this.
>
> All else being equal, one should feel free to modify parameters when
> it makes the code clearer and easier to read, but not when it
> doesn't.
>
> <nonsense snipped>
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> This line unintentionally left unblank- Hide quoted text -
spinoza1111
> In article <e2956860-1a9d-45f7-a5e6-0de40f2e7...@l35g2000pra.googlegroups.com>spinoza1111<spinoza1...@yahoo.com> writes:
> ...
> > Of course, by reference calling in a programming language is SUPPORTED
> > by passing the address by value. I am surprised you don't know this.
>
> There is one more thing needed to support it. Within the body of the routine
> there should be no distinction whether a parameter is by reference or by
> value, accessing its value should be the same.
That's nice. But it's not the same, is it? If you have the address you
must dereference it to get the value.
>
> Or do you assert that C also has call by reference to reference, ad
> infinitum?
No. I am saying that C has call by reference in the stupidest possible
way. It exposes the mothering address of data which is a security hole
of the first water. Hey let's index on the address and find out what
else is in storage!
spinoza1111
They explained value parameters elegantly. But it's just nuts to say
that they used value parameters as work areas heavily. My guess is
that when storage was limited they did so reluctantly, because
gentlemen and scholars starting with Kong Fu-Zi (Confucius) believe in
what Confucius called The Rectification of Names. Using a field named
intCount which holds (sadly enough) the size of an array to decrement
down to zero makes intCount, at the end of execution, a false name and
deceives the program maintainer, often repeatedly. It creates
confusion and ill-will, as Master Kong knew the non-rectification of
names caused warlordism and oppression.
To list heavyweights and this passage from the Algol 60 report is
dreamlike associative logic, like saying that "C is used widely in
embedded programs therefore I should be able to use it for business
data processing so there".
>
> > Suppose you want to run your C source code on a machine, on whose
> > stacks the parameters are read-only. For whatever reason, you can only
> > modify your local variables.
>
> Well, apparently the people mentioned above gave clear semantics...
They may have been concerned with storage efficiency on small
machines. Need we be?
Richard Heathfield
> On Jul 31, 4:04 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
<snip>
>> [...] the Standard explicitly gives us this right, and therefore
>> we know we can do this provided we are using a conforming
>> implementation.
>
> Yeah, the standard is a big fat help when you're using a non-
> conformant compiler.
If you're using a non-conforming compiler, you're not writing in C.
That should make you very happy, right?
> Non-conformant compilers are Legion, but we can
> always defraud the user by saying that our non-working code is
> "standard".
It's pretty easy to find a conforming C90 implementation for most
platforms nowadays. The most likely problem you'll hit is not so much
non-conformance as the lack of a libc - a "freestanding
implementation". I've never hit that problem personally, however,
despite having worked with several freestanding implementations.
<nonsense snipped>
> Programming on purpose means not messing around, and programmers who
> think that it shows intelligence to mung parameters not intended to
> be munged are messing around and showing off.
You are attempting to impose an arbitrary restriction on parameters
that simply does not exist in the real world. I can see why a
programmer might decide to refrain from altering parameters as a
conscious self-limiting choice. (I myself make many such choices
whilst programming, although that doesn't happen to be one of them.)
What I don't see is why anyone would consider it bad practice.
> I don't care if they are "Dennis Ritchie".
I know you don't. It seems that you struggle with the concept of
expertise.
<snip>
>> > In the first case, in an object oriented language, you always
>> > have the ontological choice to declare a new Thing which includes
>> > things. It has long been trivial to "wrap" > 1 value in structs
>> > in C, and if I were a nasty person like you, I'd of course now be
>> > claiming, falsely, that you don't know structs.
>>
>> Mu.
>>
>> > But I'm not a nasty piece of work, like you. You know structs but
>> > somehow when you claimed that you need to alter the values of
>> > parameters passed "by reference" (prefixed with asterisks) you
>> > forgot about structs.
>>
>> Perhaps you would care to support this assertion with a message ID.
>
> Do your own homework, or sue me.
It's your job, not mine, to back up your claims with supporting
evidence. If you can't be bothered to do that, don't be surprised if
I don't believe you.
<snip>
>> > Furthermore, you don't see that the more assertions a program
>> > depends upon the unsafer it is,
>>
>> The Standard makes certain guarantees on which a programmer can
>> rely if he (or she) is using a conforming implementation (and makes
>> further guarantees for those using conforming hosted
>> implementations). If you are not using a conforming implementation,
>> then you cannot rely on such guarantees. This is surely obvious.
>
> This is absurd. To say that a programmer should be held harmless for
> the mess he makes (such as destroying the value of parameters in
> such a way as to make a program hard to debug when it crashes near
> its end)
Who said anything about "hard to debug"?
<snip>
spinoza1111
> spinoza1111said:
I certainly do, because most programming "experts" are aliterate,
narrow, dull and unimaginative. They substitute work hours for thought
and wind up getting screwed by employers who use a macho definition of
easily verified "success": they prefer fast code, and meeting
deadlines, because these can be measured, and they can be ranked.
They are unable to talk about technology per se but turn to
personalities in order that their own weaknesses not be exposed.
Dennis Ritchie might be one of these "experts". Kernighan was awed by
the fact that he took only an hour (ooooo) to develop a program
mislabeled as "handling regular expressions", but he did so by (1) not
handling regular expressions in a meaningful way and (2) lazily using
parameters as work areas.
None of these experts are scientists, applied or otherwise, and post
Sep 11 and post crash it is clear to me at least that computers should
have been programmed by scientists and not cheesy little technicians.
Dan Henry
Call you a troll, I've done.
--
Dan Henry