Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #111691 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2017-06-07 06:16 -0700 |
| Last post | 2017-06-07 08:53 -0700 |
| Articles | 20 on this page of 122 — 18 participants |
Back to article view | Back to comp.lang.c
memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 06:16 -0700
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 15:47 +0200
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 07:15 -0700
Re: memscan() function or equivalent scott@slp53.sl.home (Scott Lurndal) - 2017-06-07 14:34 +0000
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 07:42 -0700
Re: memscan() function or equivalent scott@slp53.sl.home (Scott Lurndal) - 2017-06-07 14:45 +0000
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:07 -0700
Re: memscan() function or equivalent jameskuyper@verizon.net - 2017-06-07 09:14 -0700
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:33 -0700
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 16:48 +0200
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:31 -0700
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 17:37 +0200
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:47 -0700
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 18:02 +0200
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:09 -0700
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 18:34 +0200
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:54 -0700
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 19:01 +0200
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 10:17 -0700
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 19:53 +0200
Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 22:15 -0700
Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 22:26 -0700
Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 22:56 -0700
Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 23:03 -0700
Re: memscan() function or equivalent scott@slp53.sl.home (Scott Lurndal) - 2017-06-07 16:10 +0000
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:30 -0700
Re: memscan() function or equivalent Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-07 16:50 +0100
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:58 -0700
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:03 -0700
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:07 -0700
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-07 17:30 +0100
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:36 -0700
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-07 17:48 +0100
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:57 -0700
Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 05:54 +0000
Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-07 09:48 -0700
Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-07 20:55 +0100
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-07 22:13 +0100
Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-07 16:02 -0700
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-08 01:26 +0100
Re: memscan() function or equivalent Ian Collins <ian-news@hotmail.com> - 2017-06-08 13:00 +1200
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-08 09:48 +0100
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 08:52 +0200
Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-07 10:00 -0700
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 10:13 -0700
Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-07 11:19 -0700
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 11:27 -0700
Re: memscan() function or equivalent Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-07 21:18 +0100
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 18:18 +0200
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-07 21:15 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 21:16 +0200
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 09:08 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-10 09:56 +0200
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 17:14 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-10 17:38 +0200
Re: memscan() function or equivalent David Kleinecke <dkleinecke@gmail.com> - 2017-06-10 11:52 -0700
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-10 20:03 +0100
Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-10 13:32 -0700
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-10 23:40 +0200
Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 00:53 +0300
Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 01:11 +0300
Re: memscan() function or equivalent Ian Collins <ian-news@hotmail.com> - 2017-06-11 10:26 +1200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 00:32 +0200
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 10:05 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:06 +0200
Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-11 13:19 -0700
Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 02:17 +0300
Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-10 15:21 -0700
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 00:19 +0200
Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 02:15 +0300
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 10:36 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:46 +0200
Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-10 22:25 -0700
Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-10 15:13 -0700
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-10 23:21 +0100
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 00:28 +0200
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-11 10:56 +0100
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 13:27 +0200
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-11 13:19 +0100
Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-11 18:36 +0000
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-11 20:22 +0100
Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 06:09 +0000
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-12 10:38 +0100
Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-12 05:30 -0700
Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 13:51 +0000
Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-12 15:04 +0100
Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 21:26 +0000
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 10:04 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:13 +0200
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 13:38 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 14:18 +0200
Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-11 09:57 -0700
Re: memscan() function or equivalent Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 17:18 +0000
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 09:53 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:00 +0200
Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 13:41 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 21:24 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 21:55 +0200
Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-07 20:54 +0100
Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-07 23:00 +0200
Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-08 08:16 +0100
Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-08 10:55 +0200
Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-08 11:44 +0100
Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-08 13:11 +0200
Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-08 13:45 +0100
Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-08 14:51 +0200
Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-08 08:00 -0700
Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-09 12:26 -0700
Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-10 07:24 +0100
Re: memscan() function or equivalent Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-10 13:17 +0100
Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-10 17:18 +0100
Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-11 18:11 +0000
Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-11 15:08 -0700
Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-12 18:34 +0100
Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-14 09:52 -0700
Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-14 19:56 +0100
Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-14 12:20 -0700
Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-17 06:37 -0700
Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-17 10:02 -0700
Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-07 16:51 +0200
Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 17:00 +0200
Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-07 08:53 -0700
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2017-06-07 22:15 -0700 |
| Message-ID | <402a5cac-7065-4bfb-9de4-5b5b24c738b0@googlegroups.com> |
| In reply to | #111730 |
#define u32 unsigned
//(u33)-1 for error
u32 memscan(char*a,int c,u32 s)
{u32 k;
if(a==0)
if(s==0)return 0;
else return -1;
if(c>0xFF || c<0)
return -1; //assume Ascii
for(k=0;k<s;++k)
if(a[k]==c)++k;
return k;
}
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2017-06-07 22:26 -0700 |
| Message-ID | <80403bad-18dd-4dc7-b351-91cdd2414650@googlegroups.com> |
| In reply to | #111792 |
u32 memtrova(char*a,int c,u32 s)
{u32 i,k;
if(a==0 && s!=0)return -1;
if(a==0 && s==0)return 0;
if(c<0 || c>0xFF)
return -1;
for(i=0,k=0;i<s;++i)
if(a[i]==c)++k;
return k;
}
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2017-06-07 22:56 -0700 |
| Message-ID | <7e1c381f-6667-4c97-bd86-5c873aaecfa5@googlegroups.com> |
| In reply to | #111793 |
#define u32 unsigned
//-1 for error
u32 memtrova(char*a,int c,u32 s)
{u32 i,k;
if(a==0 && s!=0)return -1;
if(a==0 && s==0)return 0;
if(c<0 || c>0xFF || s>0xFFFFFFF0)
return -1;
for(i=0,k=0;i<s;++i)
if(a[i]==c)++k;
return k;
}
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2017-06-07 23:03 -0700 |
| Message-ID | <feb561da-7272-4fbe-afa3-28c4a1d1863d@googlegroups.com> |
| In reply to | #111794 |
#define u32 unsigned
//-1 for error
u32 memtrova(char*a,int c,u32 s)
{u32 i,k;
if(c<0 || c>0xFF || s>0xFFFFFFF0)
return -1;
if(a==0 && s!=0)return -1;
for(i=0,k=0;i<s;++i)
if(a[i]==c)++k;
return k;
}
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-06-07 16:10 +0000 |
| Message-ID | <MzVZA.44403$5D5.21860@fx37.iad> |
| In reply to | #111709 |
GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>On Wed, 7 Jun 2017 08:31:49 -0700 (PDT)
>"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
>
>> This function is different than mine. Mine scans for a consecutive
>> run of characters matching c, and returns the number found. The
>> first non-matching encounter stops its examination.
>>
>> It's akin to x86's REPZ SCASB instruction:
>>
>> https://stackoverflow.com/questions/24221250/skip-spaces-repz-scasb
>
>You should rather look at the strcspn function.
Circa 1965 versions:
strspn instruction: <http://vseries.lurndal.org/doku.php?id=instructions:sde>
strcspn instruction: <http://vseries.lurndal.org/doku.php?id=instructions:sdu>
will scan up to 100 bytes per instruction.
Source level construct (language: BPL, App: Word Processor ADSINP):
INTEGER ln1 (2) = BASE.+32, 00288000
ln2 (2) = BASE.+34, 00289000
ln12 (4) = BASE.+32, 00290000
ln3 (2) = BASE.+36, 00291000
word_length (2) = BASE.+36, 00292000
y_length (2) = BASE.+36, 00293000
lscn (2) = BASE.+38; 00294000
DEFINE etxc = %03%#, 00425000
null = %00%#; 00426000
SCAN input_line FOR etxc; &STRIP TRAILING BLANKS AND & P_007 01141000 001 020792
020792 SDE/16B180 030000 201780
IF LEQ THEN IX1 := lscn + lscn &ETX'S HERE SO THAT THE TRUE & P_007 01142000
ELSE IX1 := 158; &END OF LINE CAN BE FOUND & P_007 01143000 001 020810
020810 GTR/24 020868
020818 MVN/110207 000038 020276
020836 ADD/020207 000038 020276 100008
020860 BUN/27 020886
020868 MVN/11A307 158000 100008
WHILE ((input_line.IX1.1 = " ") OR & P_007 01144000
(input_line.IX1.1=etxc)) AND (IX1 >= 0) DO_ & P_007 01145000 001 020886
020886 CPA/45B101 400000 601780
020904 EQL/22 020938
020912 CPA/45B101 030000 601780
020930 NEQ/25 020990
020938 CPN/46A107 000000 100008
020956 GTR/24 020990
IX1 := IX1 - 2; & P_007 01146000 001 020964
020964 DEC/03A107 200000 100008
OD; & P_007 01147000 001 020982
020982 BUN/27 020886
IX1 := IX1+2; & P_007 01148000 001 020990
020990 INC/01A107 200000 100008
input_line.IX1.1 := etxc; & P_007 01149000 001 021008
021008 MVA/10B101 030000 601780
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-06-07 09:30 -0700 |
| Message-ID | <d9952856-c002-4b9a-89df-c64bd6c78751@googlegroups.com> |
| In reply to | #111720 |
On Wednesday, June 7, 2017 at 12:10:31 PM UTC-4, Scott Lurndal wrote: > GOTHIER Nathan <nathan.gothier@gmail.com> writes: > >You should rather look at the strcspn function. > Circa 1965 versions: I'm sorry ... after I read this line, I blacked out for a while. Thank you, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-06-07 16:50 +0100 |
| Message-ID | <878tl3g5jw.fsf@bsb.me.uk> |
| In reply to | #111702 |
GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> On Wed, 7 Jun 2017 07:15:04 -0700 (PDT)
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
>
>> On Wednesday, June 7, 2017 at 9:50:27 AM UTC-4, GOTHIER Nathan wrote:
>> > /* count the occurrence number of c */
>> > size_t memfrq(const void *s, int c, size_t n);
>>
>> What do these parameters equate to? What are s, c, and n? Can you
>> include the function body so I can see it at work?
>
>
> /*
> The "memfrq" function
>
> Description:
>
> The memfrq function count the occurrence number of c (converted as an
> unsigned char) in the initial n characters (each interpreted as unsigned
> char) of the object pointed to by s.
>
> Returns:
>
> The memfrq function returns the number of c occurences found.
> */
>
> #include <stddef.h>
>
> typedef unsigned char uchar_t;
>
> size_t memfrq(const void *s, int c, size_t n)
> {
> uchar_t *s0 = (uchar_t *) s;
> uchar_t c0 = (uchar_t) c;
> size_t k = 0U;
That looks fussy to me. If you don't keep repeating the type you don't
need to typedef it. I'd also keep the const:
const unsigned char *s0 = s, c0 = c;
size_t k = 0;
> scan:
> {
> if (n > 1)
What do you have against n == 1?!!
> {
> if (*s0 == c0)
> {
> k++;
> }
>
> s0++;
> n--;
>
> goto scan;
> }
Seriously? That's a wind-up, surely?
> return k;
> }
> }
What is the general view of writing things like
k += *s0 == c0;
? I find it compact and natural with no extra cost, at least with
modern compilers.
Anyway, an alternative version (keeping the names):
size_t memfrqBB(const void *s, int c, size_t n)
{
const unsigned char *s0 = s, c0 = c;
size_t k = 0;
while (n-- > 0)
k += *s0++ == c0;
return k;
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-06-07 08:58 -0700 |
| Message-ID | <b1e397b1-a2a2-40ea-80d4-621aec90f780@googlegroups.com> |
| In reply to | #111711 |
On Wednesday, June 7, 2017 at 11:51:09 AM UTC-4, Ben Bacarisse wrote:
> size_t memfrqBB(const void *s, int c, size_t n)
> {
> const unsigned char *s0 = s, c0 = c;
> size_t k = 0;
>
> while (n-- > 0)
> k += *s0++ == c0;
> return k;
> }
Why are you (or is C) opposed to using const char * parameters, or
char parameters? Why use the conversion / translation in local
variable space?
size_t memfrqBB(const char *p, char c, size_t n)
{
for (size_t k = 0; n > 0; n--, p++)
k += (*p == c);
return k;
}
Still not the same function, but I'm curious as to this method of
creating new local variables that aren't necessary.
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-06-07 09:03 -0700 |
| Message-ID | <ceb6a584-cc00-4eeb-a780-0976640b78e0@googlegroups.com> |
| In reply to | #111714 |
On Wednesday, June 7, 2017 at 11:58:58 AM UTC-4, Rick C. Hodgin wrote:
> size_t memfrqBB(const char *p, char c, size_t n)
> {
> for (size_t k = 0; n > 0; n--, p++)
> k += (*p == c);
>
> return k;
> }
By the way, the same function in CAlive syntax:
function memcount
|params const char* p, char c, s32 n
|returns s32 k
{
for (k = 0; n > 0; n--)
k += (*p++ == c);
}
Return parameters (of which there can be more than one), are given
names and are usable as local variables. No return statement is
required, but can still be used, and the are compiler switches
which allow you to test if return values have been set or not.
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-06-07 09:07 -0700 |
| Message-ID | <41f085fe-ee89-4de5-8dcf-8fa66ee53e16@googlegroups.com> |
| In reply to | #111716 |
On Wednesday, June 7, 2017 at 12:03:29 PM UTC-4, Rick C. Hodgin wrote:
> On Wednesday, June 7, 2017 at 11:58:58 AM UTC-4, Rick C. Hodgin wrote:
> > size_t memfrqBB(const char *p, char c, size_t n)
> > {
> > for (size_t k = 0; n > 0; n--, p++)
> > k += (*p == c);
> >
> > return k;
> > }
>
> By the way, the same function in CAlive syntax:
>
> function memcount
> |params const char* p, char c, s32 n
> |returns s32 k
> {
> for (k = 0; n > 0; n--)
> k += (*p++ == c);
> }
>
> Return parameters (of which there can be more than one), are given
> names and are usable as local variables. No return statement is
> required, but can still be used, and the are compiler switches
> which allow you to test if return values have been set or not.
An alternate syntax using a discriminating-for-clause in CAlive:
function memcount
| params const char* p, char c, s32 n
| returns s32 k
{
for (k = 0; n > 0; n--; *p++ == c)
++k; // Increase for each match
}
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-06-07 17:30 +0100 |
| Message-ID | <YSVZA.273972$Ng5.75038@fx08.am4> |
| In reply to | #111716 |
On 07/06/2017 17:03, Rick C. Hodgin wrote:
> On Wednesday, June 7, 2017 at 11:58:58 AM UTC-4, Rick C. Hodgin wrote:
>> size_t memfrqBB(const char *p, char c, size_t n)
>> {
>> for (size_t k = 0; n > 0; n--, p++)
>> k += (*p == c);
>>
>> return k;
>> }
>
> By the way, the same function in CAlive syntax:
>
> function memcount
> |params const char* p, char c, s32 n
> |returns s32 k
> {
> for (k = 0; n > 0; n--)
> k += (*p++ == c);
> }
That's not quite the same, as you're limiting n and return type to
around 2**31.
> Return parameters (of which there can be more than one), are given
> names and are usable as local variables. No return statement is
> required, but can still be used, and the are compiler switches
> which allow you to test if return values have been set or not.
If we're comparing syntaxes, this is how I would write it. I need
explicit returns in this language (I've had one with implicit returns; I
found explicit more readable):
function memfreq(ref byte p, int c, n)int =
int k:=0
to n do
if p++^ = c then ++k fi
od
return k
end
I also limit the memory size, and count, to 'int'. But the size of int
isn't specified. So this is saying I don't care about dealing with
possibly huge memory spans. if I did, I might use 'int64'.
Also, unlike both C and yours, k is only incremented when there's a
match. It doesn't add 0 to k when there is no match. (It will likely
need a branch so is probably not faster, but it expresses what is
happening more clearly I think.
It's also MUCH clearer here that the loop is executed exactly n times.
One more thing with the C version: n is size_t so probably unsigned. If
a small negative value is passed by mistake, the compiler might say
nothing, but it is likely to go badly wrong.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-06-07 09:36 -0700 |
| Message-ID | <816ef4c2-9aef-4b53-84cf-46606683001c@googlegroups.com> |
| In reply to | #111724 |
On Wednesday, June 7, 2017 at 12:30:56 PM UTC-4, Bart wrote:
> On 07/06/2017 17:03, Rick C. Hodgin wrote:
> > On Wednesday, June 7, 2017 at 11:58:58 AM UTC-4, Rick C. Hodgin wrote:
> >> size_t memfrqBB(const char *p, char c, size_t n)
> >> {
> >> for (size_t k = 0; n > 0; n--, p++)
> >> k += (*p == c);
> >>
> >> return k;
> >> }
> >
> > By the way, the same function in CAlive syntax:
> >
> > function memcount
> > |params const char* p, char c, s32 n
> > |returns s32 k
> > {
> > for (k = 0; n > 0; n--)
> > k += (*p++ == c);
> > }
>
> That's not quite the same, as you're limiting n and return type to
> around 2**31.
I'll accept that limitation.
> > Return parameters (of which there can be more than one), are given
> > names and are usable as local variables. No return statement is
> > required, but can still be used, and the are compiler switches
> > which allow you to test if return values have been set or not.
>
> If we're comparing syntaxes, this is how I would write it. I need
> explicit returns in this language (I've had one with implicit returns; I
> found explicit more readable):
>
> function memfreq(ref byte p, int c, n)int =
> int k:=0
>
> to n do
> if p++^ = c then ++k fi
> od
>
> return k
> end
Nice. I'm not big on the this..siht syntax style, but I know it's
very prevalent. And, it's always completely clear.
> I also limit the memory size, and count, to 'int'. But the size of int
> isn't specified. So this is saying I don't care about dealing with
> possibly huge memory spans. if I did, I might use 'int64'.
>
> Also, unlike both C and yours, k is only incremented when there's a
> match. It doesn't add 0 to k when there is no match. (It will likely
> need a branch so is probably not faster, but it expresses what is
> happening more clearly I think.
My discriminating-for-clause version worked that way too.
> It's also MUCH clearer here that the loop is executed exactly n times.
>
> One more thing with the C version: n is size_t so probably unsigned. If
> a small negative value is passed by mistake, the compiler might say
> nothing, but it is likely to go badly wrong.
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-06-07 17:48 +0100 |
| Message-ID | <L7WZA.167699$5t1.71699@fx43.am4> |
| In reply to | #111726 |
On 07/06/2017 17:36, Rick C. Hodgin wrote:
> On Wednesday, June 7, 2017 at 12:30:56 PM UTC-4, Bart wrote:
>> function memfreq(ref byte p, int c, n)int =
>> to n do
>> if p++^ = c then ++k fi
>> od
>> end
>
> Nice. I'm not big on the this..siht
(Did your have some trouble typing that last word correctly?)
syntax style, but I know it's
> very prevalent. And, it's always completely clear.
I also allow 'end', 'endif' or 'end if' in place of 'fi'. Similarly for
other block delimiters. And notice I didn't end with 'noitcnuf', so
there are limits.
The original Algol-68 syntax didn't have that choice (I think if...fi
was designed to mirror (...).)
But more important is that there /are/ block delimiters. Unlike Python,
or when C code decides not to use {...}. (Apart from the potential for
error, a nuisance when you want to add a temporary statements just
before or after s1 here and miss that there are no braces:
if (cond)
s1;
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-06-07 09:57 -0700 |
| Message-ID | <f16d38d1-1c10-4cb0-8158-62df9d49bd77@googlegroups.com> |
| In reply to | #111728 |
On Wednesday, June 7, 2017 at 12:48:51 PM UTC-4, Bart wrote:
> On 07/06/2017 17:36, Rick C. Hodgin wrote:
> > On Wednesday, June 7, 2017 at 12:30:56 PM UTC-4, Bart wrote:
>
> >> function memfreq(ref byte p, int c, n)int =
> >> to n do
> >> if p++^ = c then ++k fi
> >> od
> >> end
> >
> > Nice. I'm not big on the this..siht
>
> (Did your have some trouble typing that last word correctly?)
Nope. But, I was very careful..luferac, for hopefully very obvious
reasons. :-)
> syntax style, but I know it's
> > very prevalent. And, it's always completely clear.
>
> I also allow 'end', 'endif' or 'end if' in place of 'fi'. Similarly for
> other block delimiters. And notice I didn't end with 'noitcnuf', so
> there are limits.
>
> The original Algol-68 syntax didn't have that choice (I think if...fi
> was designed to mirror (...).)
>
> But more important is that there /are/ block delimiters. Unlike Python,
> or when C code decides not to use {...}. (Apart from the potential for
> error, a nuisance when you want to add a temporary statements just
> before or after s1 here and miss that there are no braces:
>
> if (cond)
> s1;
I am a big fan of braces for begin / end. I would like to introduce
some new character combinations that I was use for those markers,
rather than just {..} and {{..}}.
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-06-12 05:54 +0000 |
| Message-ID | <slrn3vfsojsbbs.9t4.ike@iceland.freeshell.org> |
| In reply to | #111728 |
On 2017-06-07, bartc <bc@freeuk.com> wrote: > On 07/06/2017 17:36, Rick C. Hodgin wrote: >> On Wednesday, June 7, 2017 at 12:30:56 PM UTC-4, Bart wrote: > >>> function memfreq(ref byte p, int c, n)int = >>> to n do >>> if p++^ = c then ++k fi >>> od >>> end >> >> Nice. I'm not big on the this..siht > > (Did your have some trouble typing that last word correctly?) > > syntax style, but I know it's >> very prevalent. And, it's always completely clear. > > I also allow 'end', 'endif' or 'end if' in place of 'fi'. Similarly for > other block delimiters. And notice I didn't end with 'noitcnuf', so > there are limits. I've seen 'proc' .. 'corp', it looks nicer than 'function' .. 'noitcnuf'.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-07 09:48 -0700 |
| Message-ID | <lnmv9jkakp.fsf@kst-u.example.com> |
| In reply to | #111724 |
bartc <bc@freeuk.com> writes:
[...]
> One more thing with the C version: n is size_t so probably unsigned.
"probably"?
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-06-07 20:55 +0100 |
| Message-ID | <87shjb4lpl.fsf@gmail.com> |
| In reply to | #111729 |
Keith Thompson <kst-u@mib.org> writes: > bartc <bc@freeuk.com> writes: > [...] >> One more thing with the C version: n is size_t so probably unsigned. > > "probably"? He's writing a C compiler you know.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-06-07 22:13 +0100 |
| Message-ID | <a0_ZA.334611$_f2.135268@fx35.am4> |
| In reply to | #111729 |
On 07/06/2017 17:48, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > [...] >> One more thing with the C version: n is size_t so probably unsigned. > > "probably"? Yes, probably. It was easier to add that word than doing the research needed to eliminate it. But in C, half of this stuff is defined within the standard headers, 'conveniently' split up into dozens of separate files (with the language requiring that there are half a dozen ?time.h or time?.h headers all redefining the same things). Each header can be optionally included, presumably so custom versions can be used, ones where 'size_t' might be signed. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-07 16:02 -0700 |
| Message-ID | <lnink7jta4.fsf@kst-u.example.com> |
| In reply to | #111757 |
bartc <bc@freeuk.com> writes:
> On 07/06/2017 17:48, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> One more thing with the C version: n is size_t so probably unsigned.
>>
>> "probably"?
>
> Yes, probably. It was easier to add that word than doing the research
> needed to eliminate it.
size_t is an unsigned type.
> But in C, half of this stuff is defined within the standard headers,
> 'conveniently' split up into dozens of separate files (with the language
> requiring that there are half a dozen ?time.h or time?.h headers all
> redefining the same things).
No, the standard defines exactly one header named <time.h>. No other
standard header has the string "time" in its name. (A particular
implementation or a separate standard like POSIX might define other
headers such as <sys/time.h>. Some such headers might be intended
to be included in user code, others might exist only to implement
the standard headers.)
size_t is defined in <stddef.h> and in several other standard headers
that need to refer to it.
> Each header can be optionally included, presumably so custom versions
> can be used, ones where 'size_t' might be signed.
I suppose it would be possible for some implementation-specific
header to define "size_t" as a signed type, but it would be
stupid (since such a header could not be used along with any of
the standard headers that define size_t), and I don't believe any
actual implementation would do so.
If you're writing a C implementation, or part of one, this is the
kind of stuff you really need to know.
--
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 | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-06-08 01:26 +0100 |
| Message-ID | <1R0_A.348037$op5.251868@fx39.am4> |
| In reply to | #111766 |
On 08/06/2017 00:02, Keith Thompson wrote: >> But in C, half of this stuff is defined within the standard headers, >> 'conveniently' split up into dozens of separate files (with the language >> requiring that there are half a dozen ?time.h or time?.h headers all >> redefining the same things). > > No, the standard defines exactly one header named <time.h>. No other > standard header has the string "time" in its name. Standard headers are not enough. Most arbitrary programs that you try and compile will use many other headers. With time headers, I've come across time.h and utime.h in the normal include path, and time.h, utime.h and timeb.h in the ./sys part. They're not all Posix. > If you're writing a C implementation, or part of one, this is the > kind of stuff you really need to know. What's in the headers really lies outside a C compiler proper, which knows about signed and unsigned, char, short, normal, long and long long versions of int. It doesn't know about size_t. And what's in real headers is a *lot* messier than the summary in the C standard. Little of that is to do with details of implementation, more like trying to paper over a lot of cracks so that they just about still work. -- bartc
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web