Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73976 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2015-10-27 09:52 -0700 |
| Last post | 2015-10-31 01:14 -0700 |
| Articles | 20 on this page of 174 — 20 participants |
Back to article view | Back to comp.lang.c
Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 09:52 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:06 -0700
Re: Problem with the function that should display new letter John Gordon <gordon@panix.com> - 2015-10-27 17:16 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:28 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:09 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:12 -0700
Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-27 13:12 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-27 13:23 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-27 13:49 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 21:27 +0000
Re: Problem with the function that should display new letter Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-27 18:00 -0400
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 02:53 +0000
Re: Problem with the function that should display new letter Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 00:43 -0500
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 06:08 +0000
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 08:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 09:26 +0100
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 10:40 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:44 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:35 -0700
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:40 -0400
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:47 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:38 -0700
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 16:46 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:39 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 18:20 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:36 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:09 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:51 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 19:25 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:27 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 10:07 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 00:50 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 21:04 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 01:13 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:40 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:02 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 11:28 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:57 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:53 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 13:33 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:35 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:59 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:04 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:38 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:43 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 12:10 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:58 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 13:55 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 14:02 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 15:01 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 15:44 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:22 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 16:26 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:44 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 18:45 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 19:26 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 20:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 22:59 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 22:48 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 01:14 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:07 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 14:07 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 13:57 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 16:22 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 08:38 -0700
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 17:25 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 12:46 -0700
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:03 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 19:19 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:54 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-30 12:20 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 21:36 +0000
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 10:47 +1300
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 22:25 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:59 +0100
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 10:07 +0100
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 16:25 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:01 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 09:50 -0700
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:57 +0000
Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:25 -0700
Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:23 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:44 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 07:07 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 07:07 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 09:08 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 14:29 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 16:10 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 20:27 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-31 12:40 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 02:16 -0800
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:36 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 10:46 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:56 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:00 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:02 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:05 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:14 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:14 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 11:26 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:26 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:29 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:23 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 07:44 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 11:39 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:52 -0700
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-29 16:02 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:56 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 13:41 -0400
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:46 +0000
Re: Problem with the function that should display new letter Udyant Wig <udyantw@gmail.com> - 2015-10-30 00:14 +0530
Re: Problem with the function that should display new letter raltbos@xs4all.nl (Richard Bos) - 2015-10-29 19:30 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 22:08 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 22:28 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:10 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-30 08:56 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 13:18 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 09:11 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:21 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:04 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:11 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:19 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:24 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:26 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-29 08:31 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:42 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 08:31 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 10:17 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:36 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:18 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:36 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:38 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 02:26 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:32 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 13:39 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 03:59 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 11:18 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:24 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-30 14:18 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:34 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:39 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:57 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:06 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 08:49 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 10:18 -0700
Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-29 11:48 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:23 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:42 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:13 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 10:17 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 10:23 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:39 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:45 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:55 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 07:05 -0700
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-30 23:29 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 01:14 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:02 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 18:05 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:46 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 08:46 -0800
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 23:43 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 16:05 -0800
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 21:41 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 22:46 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 18:22 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:57 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:20 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 13:38 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-31 11:28 -0700
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 00:06 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:58 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-31 01:14 -0700
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-10-30 06:34 -0700 |
| Message-ID | <c167c9ac-7fbc-4494-a7bf-bb708234caa8@googlegroups.com> |
| In reply to | #74269 |
I also see now that my word_index function wouldn't work
as it is: I make it return the value of index only when the
for loop is done with all its iterations, which produces only
the last value of index.
I have just put 'return index;' in the for loop in hope that
this will make it return index after it scanned each letter;
therefore, each index would correspond to each iteration of the
for loop in the new_text function.
I am not sure about the last 'return' in word_index function.
Shall or shall I not attach it? The last return would be needed
to signify the failure, but I don't see why this function
would fail.
int word_index(const char *text, const char *word)
{
int i, index;
int j = 0;
int word_len = strlen(word);
int text_len = strlen(text);
for(i = 0; i < text_len; i++)
{
if (isalpha(text[i]))
{
if (islower(word[j % word_len]))
{
index = word[j % word_len] - 'a';
}
if (isupper(word[j % word_len]))
{
index = word[j % word_len] - 'A';
}
j++;
}
return index;
}
return -1;
}
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-30 13:39 +0000 |
| Message-ID | <n0vrpn$42j$1@dont-email.me> |
| In reply to | #74295 |
On 30/10/15 13:34, Alla _ wrote: > I also see now that my word_index function wouldn't work > as it is: What is the function's job, and why is it called word_index? I could try to guess what it's for, but there are several possibilities, none of which make much sense. Without a clear understanding of the purpose of the function, there is not much point in trying to fix it. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-10-30 06:57 -0700 |
| Message-ID | <9aa22910-5f85-482a-bda9-160fd527edb0@googlegroups.com> |
| In reply to | #74298 |
On Friday, October 30, 2015 at 5:39:15 PM UTC+4, Richard Heathfield wrote:
> On 30/10/15 13:34, Alla _ wrote:
> > I also see now that my word_index function wouldn't work
> > as it is:
>
> What is the function's job, and why is it called word_index?
>
> I could try to guess what it's for, but there are several possibilities,
> none of which make much sense.
>
> Without a clear understanding of the purpose of the function, there is
> not much point in trying to fix it.
>
I apologize: indeed, I forgot to attach my previous description.
Function and description:
The for loop starts.
Checks if the character of the original text at i = 0 is an alphabetic
character, or some other character.
Only if it is an alphabetic letter, then:
- the program checks if a letter of the key word (key word typed in
at the command line) at position [i % length of the key word] is in upper or lower case;
- computes index [] according to the case of the letter (as described
above);
- returns the value of the index (later used in the algorithm
in new_text function).
int word_index(const char *text, const char *word)
{
int i, index;
int word_len = strlen(word);
int text_len = strlen(text);
for(i = 0; i < text_len; i++)
{
if (isalpha(text[i]))
{
if (islower(word[i % word_len]))
{
index = word[i % word_len] - 'a';
}
if (isupper(word[i % word_len]))
{
index = word[i % word_len] - 'A';
}
}
return index;
}
return -1;
}
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-01 09:06 +0000 |
| Message-ID | <n14kiu$e98$1@dont-email.me> |
| In reply to | #74304 |
On 30/10/15 13:57, Alla _ wrote: > On Friday, October 30, 2015 at 5:39:15 PM UTC+4, Richard Heathfield wrote: >> On 30/10/15 13:34, Alla _ wrote: >>> I also see now that my word_index function wouldn't work >>> as it is: >> >> What is the function's job, and why is it called word_index? >> >> I could try to guess what it's for, but there are several possibilities, >> none of which make much sense. >> >> Without a clear understanding of the purpose of the function, there is >> not much point in trying to fix it. >> > > > I apologize: indeed, I forgot to attach my previous description. > > Function and description: > > The for loop starts. That isn't a description of the purpose of the function. It is a description of how you wrote the function. We don't need a description of that, because we have the source code. What we need is a description of what the function's job is. > Checks if the character of the original text at i = 0 is an alphabetic > character, or some other character. > > Only if it is an alphabetic letter, then: > > - the program checks if a letter of the key word (key word typed in > at the command line) at position [i % length of the key word] is in upper or lower case; > > - computes index [] according to the case of the letter (as described > above); > > - returns the value of the index (later used in the algorithm > in new_text function). All of that is to do with implementation. The question I asked is: what is the function's job? The above doesn't answer that question. By now, the thread has moved on a long way. I realise that. Nevertheless, this is an important point and I hope you don't miss it: If you cannot give a clear description of the purpose of the function in a single sentence, you probably didn't give enough thought to designing your program. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-30 08:49 -0700 |
| Message-ID | <lnmvv09x0h.fsf@kst-u.example.com> |
| In reply to | #74266 |
Alla _ <modelling.data@gmail.com> writes:
[...]
> int main (int argc, char *argv[])
> {
> char message[80];
>
> if (argc == 2)
> {
> if (is_word(argv[1])) /** if is_word returns 1, i.e. is TRUE, then
> do the following; if is_word returns zero, then go
> to else part **/
> {
> char *key = argv[1];
>
> printf("Please, enter your message: \n");
>
> if (fgets (message, sizeof message, stdin) != NULL)
> {
> new_text(message, key);
> }
> }
> }
Your comment says that if is_word returns 0, then you go to the else
part. But there is no else part. The "if (argc == 2)" statement does
have an else part, but the "if (is_word(argc[1]))" statement doesn't.
You're using int values to represent true/false conditions. I suggest
that if a value can only be true or false, it should be of a Boolean
type rather than int. It makes the code clearer, since it clearly
documents the fact that there are only two valid values, and what those
values mean.
If you're willing to assume that you have a C99 or later compiler, you
can add
#include <stdbool.h>
and use the type "bool" and constants "false" and "true". If you want
your code to be portable to old pre-C99 compilers, you can achieve very
nearly the same effect by defining your own boolean type:
typedef enum { false, true } bool;
> else
> {
> printf("\a");
Consider whether you what to risk annoying the user by beeping.
If you're the only user and it doesn't bother you, that's fine.
(Personally I prefer programs to be quiet unless they a really good
reason to make noise.)
> printf("Please, provide one argument - a word\n");
> return 1;
> }
>
> return 0;
> }
Consider replacing "return 1;" by "exit(EXIT_FAILURE)" (which
requires <stdlib.h>). But this isn't a big deal.
[...]
> while(word != 0 && word != '\0')
Richard has already discussed this line, but I'll add one more
comment. Without even being sure what "word" denotes that line
jumped out at me as being obviously wrong. The constants 0 and '\0'
mean exactly the same thing as far as the compiler is concerned;
they're both of type int, and they both have the same value. But 0
is used to represent something that's logically an integer, and
'\0' is used to represent something that's logically a character
(specifically a null character). There is no meaning of "word"
for which *both* of these comparisons would make sense.
And that's before we observe that both tests are doing the same thing.
As you gain experience, this kind of error should start jumping out at
you as well.
[...]
> void new_text(char text[], char key_word[])
> {
> int i;
> int len = strlen(text);
> char new_letter;
>
> for (i = 0; i < len; i++)
> {
> if (isalpha (text[i]))
> {
> int letter = text[i];
Why is letter an int rather than a char? There are times when it it
makes sense to store a character value in an int variable, but I don't
believe this is one of them.
> if (islower (letter))
> {
> new_letter = (letter - 'a' + word_index(text, key_word)) % 26 + 'a';
> }
>
> if (isupper (letter))
> {
> new_letter = (letter - 'A' + word_index(text, key_word)) % 26 + 'A';
> }
>
> printf("%c", new_letter);
> }
Defining a variable and storing a temporary value in it *can* make your
code clearer, because it gives an explicit name to a value. But I
probably wouldn't have introduced either "letter" or "new_letter" here.
Here's another way to write the above code:
if (isalpha(text[i]))
{
if (islower(text[i]))
{
printf("%c", (text[i] - 'a' + word_index(text, key_word)) % 26 + 'a');
}
else if (isupper(text[i]))
{
printf("%c", (text[i] - 'A' + word_index(text, key_word)) % 26 + 'A');
}
else
{
printf("%c", text[i]);
}
}
else
{
printf("%c", text[i]);
}
In my opinion (and you're free to disagree), consistently referring to
text[i] directly rather than *sometimes* storing its value in "letter",
and then *sometimes* storing that value in "new_letter", makes the code
more consistent and clearer. (BTW, I'm assuming for now that the
word_index(...) logic is correct; I haven't studied it, so I really
don't know whether it is or not.)
And with this restructuring, I notice that there's still some redundant
code. You have a line that handles the case where isalpha() is true,
but isupper() and islower() are both false. By definition, that can't
happen; the set of "alpha" character is exactly the set of "lower"
characters plus the set of "upper" characters. So you can drop the
"isalpha" call; the characters that are printed directly are those that
are neither upper nor lower:
if (islower(text[i]))
{
printf("%c", (text[i] - 'a' + word_index(text, key_word)) % 26 + 'a');
}
else if (isupper(text[i]))
{
printf("%c", (text[i] - 'A' + word_index(text, key_word)) % 26 + 'A');
}
else
{
printf("%c", text[i]);
}
I personally wouldn't use printf with a "%c" format to print a single
character:
if (islower(text[i]))
{
putchar((text[i] - 'a' + word_index(text, key_word)) % 26 + 'a');
}
else if (isupper(text[i]))
{
putchar((text[i] - 'A' + word_index(text, key_word)) % 26 + 'A');
}
else
{
putchar(text[i]);
}
Finally, I'll mention again that the isupper and islower functions, and
in fact all the functions declared in <ctype.h>, can cause problems when
used with char arguments. To be safe, the argument should be cast to
unsigned char:
if (islower((unsigned char)text[i])) ...
Plain "char" can be a signed type, so a char can have a negative value.
The is*() and to*() functions do not handle negative values. And yes,
that's just as bad as you probably think it is, but we're stuck with it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-10-30 10:18 -0700 |
| Message-ID | <6a270568-681d-4f5a-a769-4550ac584a0b@googlegroups.com> |
| In reply to | #74327 |
> Your comment says that if is_word returns 0, then you go to the else
> part. But there is no else part. The "if (argc == 2)" statement does
> have an else part, but the "if (is_word(argc[1]))" statement doesn't.
>
I see. I have to make only one if statement by combining both conditions in
one. if (argc == 2 && is_word(argv[1])) { do }. Done.
>
> Consider whether you what to risk annoying the user by beeping.
> If you're the only user and it doesn't bother you, that's fine.
> (Personally I prefer programs to be quiet unless they a really good
> reason to make noise.)
I have just found out about this beeping sound; it was fun to use it,
and hear the program producing a sound; this has no meaning, and I
agree that beeping is redundant; used for fun.
> > while(word != 0 && word != '\0')
>
> Richard has already discussed this line, but I'll add one more
> comment. Without even being sure what "word" denotes that line
> jumped out at me as being obviously wrong. The constants 0 and '\0'
> mean exactly the same thing as far as the compiler is concerned;
> they're both of type int, and they both have the same value. But 0
> is used to represent something that's logically an integer, and
> '\0' is used to represent something that's logically a character
> (specifically a null character). There is no meaning of "word"
> for which *both* of these comparisons would make sense.
>
This typo is not in the program anymore.
> As you gain experience, this kind of error should start jumping out at
> you as well.
>
I hope that moment will come.
> > int letter = text[i];
>
> Why is letter an int rather than a char? There are times when it it
> makes sense to store a character value in an int variable, but I don't
> believe this is one of them.
>
It was suggested in the task description, and I agree, because it makes
the later formula more clear.
Also, I decided to use extra variables like letter and new_letter for
the sake of clarity in educational purposes, and to make the code easier
to read. My first version didn't have them. I understand that the code
looks less sophisticated with these variables, and I did that intentionally.
(BTW, I'm assuming for now that the
> word_index(...) logic is correct; I haven't studied it, so I really
> don't know whether it is or not.)
>
I think this is the most important part of this code that doesn't allow
the program to work correctly. I can't find my mistake. I have started a
new thread on this same program because I have made too many mistakes
within this thread, and also for clarity.
> And with this restructuring, I notice that there's still some redundant
> code. You have a line that handles the case where isalpha() is true,
> but isupper() and islower() are both false. By definition, that can't
> happen; the set of "alpha" character is exactly the set of "lower"
> characters plus the set of "upper" characters. So you can drop the
> "isalpha" call; the characters that are printed directly are those that
> are neither upper nor lower:
>
> if (islower(text[i]))
> {
> printf("%c", (text[i] - 'a' + word_index(text, key_word)) % 26 + 'a');
> }
> else if (isupper(text[i]))
> {
> printf("%c", (text[i] - 'A' + word_index(text, key_word)) % 26 + 'A');
> }
> else
> {
> printf("%c", text[i]);
> }
>
This is wonderful. I didn't think about it. Thank you for this also.
I will correct this. Looks efficient.
> I personally wouldn't use printf with a "%c" format to print a single
> character:
>
> if (islower(text[i]))
> {
> putchar((text[i] - 'a' + word_index(text, key_word)) % 26 + 'a');
> }
> else if (isupper(text[i]))
> {
> putchar((text[i] - 'A' + word_index(text, key_word)) % 26 + 'A');
> }
> else
> {
> putchar(text[i]);
> }
>
True. I have already used putchar elsewhere, but somehow forgot about it.
Indeed, fits perfectly in this program. Not that I am judging you suggestions!
It's more about whether I remember and use what I have already learned,
or, as in this case, forget to do so, which is not good. Learning.
> Finally, I'll mention again that the isupper and islower functions, and
> in fact all the functions declared in <ctype.h>, can cause problems when
> used with char arguments. To be safe, the argument should be cast to
> unsigned char:
>
> if (islower((unsigned char)text[i])) ...
>
> Plain "char" can be a signed type, so a char can have a negative value.
> The is*() and to*() functions do not handle negative values. And yes,
> that's just as bad as you probably think it is, but we're stuck with it.
>
I didn't know that. I see now.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2015-10-29 11:48 -0700 |
| Message-ID | <l9q43blu5o1tg6hnj5ip348312ep6jma3i@4ax.com> |
| In reply to | #74185 |
On Thu, 29 Oct 2015 10:17:11 -0700 (PDT), Alla _ <modelling.data@gmail.com> wrote: >I am posting 2 versions - none produce correct outcome. Make life easy on yourself. Stop producing multiple incorrect programs. Work on one program until two things happen: it works correctly AND you understand it. I also suggest you start a new thread for this effort since you have introduced so many errors unrelated to the original program. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-10-30 01:23 -0700 |
| Message-ID | <88567955-b727-482a-b172-32740b3b376a@googlegroups.com> |
| In reply to | #74190 |
On Thursday, October 29, 2015 at 10:48:20 PM UTC+4, Barry Schwarz wrote: > On Thu, 29 Oct 2015 10:17:11 -0700 (PDT), Alla _ > <modelling.data@gmail.com> wrote: > > >I am posting 2 versions - none produce correct outcome. > > Make life easy on yourself. Stop producing multiple incorrect > programs. Work on one program until two things happen: it works > correctly AND you understand it. > > I also suggest you start a new thread for this effort since you have > introduced so many errors unrelated to the original program. > > -- > Remove del for email I thought about starting a new thread, but then I remember once being chided for doing so, and decided to go on in this one. I did two versions only to keep parts that are correct, and not to loose the track of what has been going on. I find it helpful.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-10-30 01:42 -0700 |
| Message-ID | <15986183-71f1-4770-b81b-b1d8c116548d@googlegroups.com> |
| In reply to | #73976 |
I thought it would be correct to show my understanding
of what I tried to depict by the function new_text.
For example, text is 'world, say hello!'. The program correctly
transforms the word 'world' into 'xoqmd'. But then it hits ','
followed by a space ' ', prints them out correctly, and somehow
'forgets' to get back to converting letters. I wonder why. Here
is how I read what I have written:
The for loop starts.
Checks if the character at i = 0 is a letter or another character.
If it is a letter, then:
- it assigns a value of a letter at the position j = 0 to variable letter
- if this letter is in upper case, then it computes a correct index, which
is also based on if the give letter of the index word is in upper or lower case;
assigns a new value to variable new_letter;
- same process if the letter is in lower case.
- prints out a new_letter
- increments index j by 1; hence, index j is incremented only when alphabetical
letters are found, and is not incremented when the program prints out special
or other characters
After new_letter, or letter as it is, is printed out the index i is incremented by one,
and the process should go on until the for loop reaches the final character in text.
void new_text(char text[], char key_word[])
{
int i;
int j = 0;
int len = strlen(text);
int key_len = strlen(key_word);
int key_index;
char new_letter;
for (i = 0; i < len; i++)
{
if (isalpha (text[j]))
{
int letter = text[j];
if (islower (letter))
{
if (islower(key_word[j % key_len]))
key_index = key_word[j % key_len] - 'a';
if (isupper(key_word[j % key_len]))
key_index = key_word[j % key_len] - 'A';
new_letter = (letter - 'a' + key_index) % 26 + 'a';
}
if (isupper (letter))
{
if (islower(key_word[j % key_len]))
key_index = key_word[j % key_len] - 'a';
if (isupper(key_word[j % key_len]))
key_index = key_word[j % key_len] - 'A';
new_letter = (letter - 'A' + key_index) % 26 + 'A';
}
printf("%c", new_letter);
j++;
}
else
printf("%c", text[i]);
}
printf ("\n");
}
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-30 09:13 +0000 |
| Message-ID | <n0vc7c$9jp$1@dont-email.me> |
| In reply to | #74246 |
On 30/10/15 08:42, Alla _ wrote: > I thought it would be correct to show my understanding > of what I tried to depict by the function new_text. I'd agree that this is absolutely vital. I am, however, reluctant to advise you on it until I see some evidence that you've taken note of my earlier advice regarding your argument-checking code. I think it's important advice that is in danger of being overlooked. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-30 10:17 +0000 |
| Message-ID | <87oafgfyoy.fsf@bsb.me.uk> |
| In reply to | #74246 |
Alla _ <modelling.data@gmail.com> writes:
<snip>
> void new_text(char text[], char key_word[])
> {
> int i;
> int j = 0;
> int len = strlen(text);
> int key_len = strlen(key_word);
> int key_index;
> char new_letter;
>
> for (i = 0; i < len; i++)
> {
> if (isalpha (text[j]))
> {
> int letter = text[j];
>
> if (islower (letter))
> {
> if (islower(key_word[j % key_len]))
>
> key_index = key_word[j % key_len] - 'a';
So we do this for every i and if text[j] is alphabetic and if letter is
lower case and if the j mod key_len'th element of key is a lower case
letter? I'm confused just reading it. No wonder you are confused
writing it!
The three most important things in programming are functions, functions
and functions. An if inside an if inside a for is big clue that this
function is doing too much. If you need more clues, just look at how
often you write almost the same code:
> if (isupper(key_word[j % key_len]))
>
> key_index = key_word[j % key_len] - 'A';
>
> new_letter = (letter - 'a' + key_index) % 26 + 'a';
> }
>
> if (isupper (letter))
> {
> if (islower(key_word[j % key_len]))
>
> key_index = key_word[j % key_len] - 'a';
>
> if (isupper(key_word[j % key_len]))
>
> key_index = key_word[j % key_len] - 'A';
>
> new_letter = (letter - 'A' + key_index) % 26 + 'A';
> }
>
> printf("%c", new_letter);
> j++;
> }
So much repetition if huge signal: break this up into more functions.
The end result should be a program where every function is easy to
comprehend. It will probably be only a few lines long and it will have
only one or maybe two structures in it (i.e. a loop in an if or an if in
a loop and so on). These are, of course, just guidelines not hard
rules. By all means have an if in a loop in an if when you feel is
better that way.
The basic idea is to keep asking yourself what is the overall structure
of a function and how could it be written simply if you had access to a
function that did everything else. Here you have a function prints a
derived character for every character in "text". That means you
probably want to write
for (int i = 0; text[i]; i++) {
....
putchar(new_character(....));
....
}
as the basic structure. You need to decide what data the new_character
function needs as this will be the arguments you pass to it. Clearly it
needs text[i], but there will be more. Exactly what is not a trivial
choice to make so I'll stop here and let you do that bit.
And remember, new_character might need to be written using even more
functions!
> else
> printf("%c", text[i]);
> }
> printf ("\n");
> }
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-30 10:23 +0000 |
| Message-ID | <n0vgaq$n4h$1@dont-email.me> |
| In reply to | #74262 |
On 30/10/15 10:17, Ben Bacarisse wrote: <snip> > The three most important things in programming are functions, functions > and functions. You forgot something even more important: functions. I'm surprised at you. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-10-30 06:39 -0700 |
| Message-ID | <5a17a498-8b98-419f-ae0f-c77e57fd6449@googlegroups.com> |
| In reply to | #73976 |
I have corrected the program. It compiles, and runs.
Produces visually correct, but semantically wrong, result :)
Please, enter your message:
world, say hello!
xpsme, tbz ifmmp!
I am sure that the is with the way the program computes index.
Here is the program:
//** Program to cipher the text based on vigenere algorithm **/
#include <stdio.h>
#include <string.h>
#include <ctype.h>
int is_word(const char *string);
int word_index(const char *text, const char *word);
void new_text(char text[], char key_word[]);
int main (int argc, char *argv[])
{
char message[80];
if (argc == 2)
{
if (is_word(argv[1])) /** if is_word returns 1, i.e. is TRUE, then
do the following; if is_word returns zero, then go
to else part **/
{
char *key = argv[1];
printf("Please, enter your message: \n");
if (fgets (message, sizeof message, stdin) != NULL)
{
new_text(message, key);
}
}
}
else
{
printf("\a");
printf("Please, provide one argument - a word\n");
return 1;
}
return 0;
}
int is_word(const char *string)
{
int word = 0;
if (string != NULL)
{
word = 1;
while(word != 0 && *string != '\0')
{
word = (isalpha(*string++)); /** the pointer refers to the address of the first
character, hence *string++ is used **/
/** if the string is not an alphabetical one, then
isalpha returns 0, the while loop terminates, and
the function returns 0 as the value of the word**/
}
}
return word;
}
int word_index(const char *text, const char *word)
{
int i, index;
int j = 0;
int word_len = strlen(word);
int text_len = strlen(text);
for(i = 0; i < text_len; i++)
{
if (isalpha(text[i]))
{
if (islower(word[j % word_len]))
{
index = word[j % word_len] - 'a';
}
if (isupper(word[j % word_len]))
{
index = word[j % word_len] - 'A';
}
j++;
}
return index;
}
return -1;
}
void new_text(char text[], char key_word[])
{
int i;
int len = strlen(text);
char new_letter;
for (i = 0; i < len; i++)
{
if (isalpha (text[i]))
{
int letter = text[i];
if (islower (letter))
{
new_letter = (letter - 'a' + word_index(text, key_word)) % 26 + 'a';
}
if (isupper (letter))
{
new_letter = (letter - 'A' + word_index(text, key_word)) % 26 + 'A';
}
printf("%c", new_letter);
}
else
printf("%c", text[i]);
}
printf ("\n");
}
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-10-30 06:45 -0700 |
| Message-ID | <035ed14d-a9c3-4f6a-bd35-ce64042d012b@googlegroups.com> |
| In reply to | #73976 |
I have spotted another detail: I don't need j in
word_index function. It still doesn't produce correct
result, but j was redundant.
int word_index(const char *text, const char *word)
{
int i, index;
int word_len = strlen(word);
int text_len = strlen(text);
for(i = 0; i < text_len; i++)
{
if (isalpha(text[i]))
{
if (islower(word[i % word_len]))
{
index = word[i % word_len] - 'a';
}
if (isupper(word[i % word_len]))
{
index = word[i % word_len] - 'A';
}
}
return index;
}
return -1;
}
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-30 13:55 +0000 |
| Message-ID | <n0vso8$7pj$1@dont-email.me> |
| In reply to | #74301 |
On 30/10/15 13:45, Alla _ wrote: > I have spotted another detail: I don't need j in > word_index function. It still doesn't produce correct > result, but j was redundant. What do you mean by "correct result"? What is the function supposed to do? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-10-30 07:05 -0700 |
| Message-ID | <a53c110e-bc4a-440a-831a-00f7bc8c159b@googlegroups.com> |
| In reply to | #74302 |
On Friday, October 30, 2015 at 5:55:34 PM UTC+4, Richard Heathfield wrote: > On 30/10/15 13:45, Alla _ wrote: > > I have spotted another detail: I don't need j in > > word_index function. It still doesn't produce correct > > result, but j was redundant. > > What do you mean by "correct result"? What is the function supposed to do? > I was too slow in typing my respond with the description :) Here is also an example: the user types in: ./programname baz // baz is a key word for the cipher the user enters the message: world, say hello! (bazba zba zbazb) the program should convert this phrase to 'xoqmd, rby gflkp!' by correctly computing the index.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-10-30 23:29 +0000 |
| Message-ID | <ZUvo1a.wFU.FTIiF@gmail.com> |
| In reply to | #74301 |
There seem to be a few individuals on this newsgroup who have a
variety of features which they feel ought to be added to the C
standard. I suppose I will have to count myself among their number
due to this post. My gripe with the language is relatively minor. So
far I can do most of what I want to do with existing features, but
there are two things that appear to be missing, one of which appears
to be a major oversight.
First, I have found a few cases where the ability to use GCC macros as
expressions is unavoidable. These are macros encapsulated with ({ ...
}). This appears to be a GCC-ism and while I am not strident about
requiring the standard to change to accommodate this extension, I am
curious to know how widespread this feature is among non-GCC
compilers. If I find that the feature is mainly restricted to GCC I
may decide to refactor affected code as avoiding dependency on GCC is
something of a priority for me.
The second missing feature is more important. As I am attempting to
do some program introspection it has occurred to me that a preprocessor
directive to take the name of an identifier as a char * array would be
extremely valuable. Something like nameof(function) and
nameof(variable) would be invaluable for my purposes. Seeing as how
such a feature would be trivial to implement and would not materially
affect the language syntax I am vaguely astounded to discover that it
does not exist.
Thoughts, flames?
Regards,
Steve Thompson
--
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-31 01:14 +0000 |
| Message-ID | <87io5ndel6.fsf@bsb.me.uk> |
| In reply to | #74383 |
Steve Thompson <stevet810@gmail.com> writes:
<snip>
> First, I have found a few cases where the ability to use GCC macros as
> expressions is unavoidable. These are macros encapsulated with ({ ...
> }). This appears to be a GCC-ism and while I am not strident about
> requiring the standard to change to accommodate this extension, I am
> curious to know how widespread this feature is among non-GCC
> compilers. If I find that the feature is mainly restricted to GCC I
> may decide to refactor affected code as avoiding dependency on GCC is
> something of a priority for me.
Inline functions are generally a better idea but they don't always fit
of course. Do you have an example of when you are forced to use
({...})? In some cases there are portable alternatives.
> The second missing feature is more important. As I am attempting to
> do some program introspection it has occurred to me that a preprocessor
> directive to take the name of an identifier as a char * array would be
> extremely valuable. Something like nameof(function) and
> nameof(variable) would be invaluable for my purposes. Seeing as how
> such a feature would be trivial to implement and would not materially
> affect the language syntax I am vaguely astounded to discover that it
> does not exist.
Again an example would help because it looks like the # operator is what
you want.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-10-31 17:02 +0000 |
| Message-ID | <mjoi8Z.QdQ.LNHPe@gmail.com> |
| In reply to | #74386 |
On Sat, Oct 31, 2015 at 01:14:13AM +0000, Ben Bacarisse wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> <snip>
> > First, I have found a few cases where the ability to use GCC macros as
> > expressions is unavoidable. These are macros encapsulated with ({ ...
> > }). This appears to be a GCC-ism and while I am not strident about
> > requiring the standard to change to accommodate this extension, I am
> > curious to know how widespread this feature is among non-GCC
> > compilers. If I find that the feature is mainly restricted to GCC I
> > may decide to refactor affected code as avoiding dependency on GCC is
> > something of a priority for me.
>
> Inline functions are generally a better idea but they don't always fit
> of course. Do you have an example of when you are forced to use
> ({...})? In some cases there are portable alternatives.
How about this:
#define ARITH_SATURATE(Var, OP, Amt) \
({ \
int result = 1; \
typeof(Amt) amt = Amt; \
typeof(Var) *ptr = &Var; \
typeof(Var) tmp = *ptr; \
typeof(Var) min = ~0; \
typeof(Var) max = ~0; \
\
if(min > 0) \
min = 0; \
\
if(max < 0) \
max = ((1 << (sizeof(*ptr) * 8 - 2)) - 1) - 1 + \
((1 << (sizeof(*ptr) * 8 - 2)) - 1); \
\
*ptr = *ptr OP _amt; \
\
if(unlikely((amt > 0) && (*ptr < tmp))) { \
result = 0; \
*ptr = max; \
} \
\
if(unlikely((amt < 0) && (*ptr > tmp))) { \
result = 0; \
*ptr = min; \
} \
\
arith_assert(result); \
arith_warn(result); \
\
result; \
})
#define ADDS(a, b) ARITH_SATURATE(a, +, b)
... etc.
Please note that this is not tested; I wrote it for the purpose of
seeing how it 'looks'. The idea is obviously to be type agnostic so I
might do saturating arithmetic on signed/unsigned integer types of
arbitrary size, up to the __int128_t type if available. For that
reason it cannot be implemented as an inline function, and I suppose I
am also dependent on the typeof() keyword. Consequently I am
interested to learn whether these (two) idioms are commonplace enough
to rely on them. I do not care so much about odd embedded system
compilers, but the HPC market is another matter entirely. I would
hate to have to generate macros/functions for eight or more different
integer types.
> > The second missing feature is more important. As I am attempting to
> > do some program introspection it has occurred to me that a preprocessor
> > directive to take the name of an identifier as a char * array would be
> > extremely valuable. Something like nameof(function) and
> > nameof(variable) would be invaluable for my purposes. Seeing as how
> > such a feature would be trivial to implement and would not materially
> > affect the language syntax I am vaguely astounded to discover that it
> > does not exist.
>
> Again an example would help because it looks like the # operator is what
> you want.
I am aware of the string concatenation operator and it is not fit to
purpose. Let us say I have a globally scoped variable which
establishes some important value to the program, perhaps a loop
counter which defines the number of times a mutex acquisition will
spin before calling shed_yield(). This is a parameter which might be
run-time tuneable. To make it easier to manage such parameters, I
would like to have a macro which builds a list of marked variables
which might then be fed to a configuration menu at run-time. Therefore
a function with the following invocation pattern would be helpful.
add_instr_var(&var, sizeof(var), VAR_UINT, nameof(var));
This is perhaps a minor nit, but preprocessor substitution adds
additional complexity, and with a macro add_instr_var() can be
theoretically simplified in the code to ADD_INSTR_VAR(var), which
would greatly improve readability. To get around the lack generally
requires two entries in the code for each symbol of interest; one
quoted and one that is not. An alternate solution would involve
digging into the debugging sections (assuming the code is compiled
with debugging info) and would be exceedingly complex in comparison
to the simplicity of a minor language extension.
If you have an alternate strategy I would love to hear it.
Regards,
Steve Thompson
--
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-31 18:05 +0000 |
| Message-ID | <87wpu2ap6g.fsf@bsb.me.uk> |
| In reply to | #74449 |
Steve Thompson <stevet810@gmail.com> writes:
> On Sat, Oct 31, 2015 at 01:14:13AM +0000, Ben Bacarisse wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>> <snip>
>> > First, I have found a few cases where the ability to use GCC macros as
>> > expressions is unavoidable. These are macros encapsulated with ({ ...
>> > }). This appears to be a GCC-ism and while I am not strident about
>> > requiring the standard to change to accommodate this extension, I am
>> > curious to know how widespread this feature is among non-GCC
>> > compilers. If I find that the feature is mainly restricted to GCC I
>> > may decide to refactor affected code as avoiding dependency on GCC is
>> > something of a priority for me.
>>
>> Inline functions are generally a better idea but they don't always fit
>> of course. Do you have an example of when you are forced to use
>> ({...})? In some cases there are portable alternatives.
>
> How about this:
>
> #define ARITH_SATURATE(Var, OP, Amt) \
> ({ \
> int result = 1; \
> typeof(Amt) amt = Amt; \
> typeof(Var) *ptr = &Var; \
> typeof(Var) tmp = *ptr; \
> typeof(Var) min = ~0; \
> typeof(Var) max = ~0; \
> \
> if(min > 0) \
> min = 0; \
> \
> if(max < 0) \
> max = ((1 << (sizeof(*ptr) * 8 - 2)) - 1) - 1 + \
> ((1 << (sizeof(*ptr) * 8 - 2)) - 1); \
> \
> *ptr = *ptr OP _amt; \
> \
> if(unlikely((amt > 0) && (*ptr < tmp))) { \
> result = 0; \
> *ptr = max; \
> } \
> \
> if(unlikely((amt < 0) && (*ptr > tmp))) { \
> result = 0; \
> *ptr = min; \
> } \
> \
> arith_assert(result); \
> arith_warn(result); \
> \
> result; \
> })
>
> #define ADDS(a, b) ARITH_SATURATE(a, +, b)
> ... etc.
>
> Please note that this is not tested; I wrote it for the purpose of
> seeing how it 'looks'. The idea is obviously to be type agnostic
Yes, if you need to be type agnostic your options are very limited.
There is some help in the form of _Generic but it does not scale well to
lots of types and lots of type combinations.
If you need the code to be portable (by avoiding ({})) your simplest
option is to remove the return value and have it put somewhere instead
(i.e. the macro is given the name of a result variable) and the macro
changed to expand to a statement rather than an expression. Not nice,
but that may be all you can do.
> might do saturating arithmetic on signed/unsigned integer types of
> arbitrary size, up to the __int128_t type if available. For that
> reason it cannot be implemented as an inline function, and I suppose I
> am also dependent on the typeof() keyword. Consequently I am
> interested to learn whether these (two) idioms are commonplace enough
> to rely on them. I do not care so much about odd embedded system
> compilers, but the HPC market is another matter entirely. I would
> hate to have to generate macros/functions for eight or more different
> integer types.
>
>> > The second missing feature is more important. As I am attempting to
>> > do some program introspection it has occurred to me that a preprocessor
>> > directive to take the name of an identifier as a char * array would be
>> > extremely valuable. Something like nameof(function) and
>> > nameof(variable) would be invaluable for my purposes. Seeing as how
>> > such a feature would be trivial to implement and would not materially
>> > affect the language syntax I am vaguely astounded to discover that it
>> > does not exist.
>>
>> Again an example would help because it looks like the # operator is what
>> you want.
>
> I am aware of the string concatenation operator and it is not fit to
> purpose.
No, it did seem unlikely, but there was very little to go on.
> Let us say I have a globally scoped variable which
> establishes some important value to the program, perhaps a loop
> counter which defines the number of times a mutex acquisition will
> spin before calling shed_yield(). This is a parameter which might be
> run-time tuneable. To make it easier to manage such parameters, I
> would like to have a macro which builds a list of marked variables
> which might then be fed to a configuration menu at run-time. Therefore
> a function with the following invocation pattern would be helpful.
>
> add_instr_var(&var, sizeof(var), VAR_UINT, nameof(var));
>
> This is perhaps a minor nit, but preprocessor substitution adds
> additional complexity, and with a macro add_instr_var() can be
> theoretically simplified in the code to ADD_INSTR_VAR(var), which
> would greatly improve readability. To get around the lack generally
> requires two entries in the code for each symbol of interest; one
> quoted and one that is not. An alternate solution would involve
> digging into the debugging sections (assuming the code is compiled
> with debugging info) and would be exceedingly complex in comparison
> to the simplicity of a minor language extension.
>
> If you have an alternate strategy I would love to hear it.
I can't follow the requirement. There seem to be other reasons why
ADD_INSTR_VAR(var) can't expand to the call you gave (for example I
don't know the relationship between "var" and "VAR_UINT") but turning
the variable name into a string does not seem to be it. Obviously since
you know about # I must simply be getting the wrong end of this
example. Sorry.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web