Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #45607 > unrolled thread

Challenge: tightest code to find-replace a string

Back to article view | Back to comp.lang.c

Contents

  Challenge: tightest code to find-replace a string DFS <nospam@dfs.com> - 2014-06-06 00:08 -0400
    Re: Challenge: tightest code to find-replace a string DFS <nospam@dfs.com> - 2014-06-06 04:34 -0400
      Re: Challenge: tightest code to find-replace a string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-06-06 10:04 +0000
      Re: Challenge: tightest code to find-replace a string Mark Storkamp <mstorkamp@yahoo.com> - 2014-06-06 07:27 -0500
      Re: Challenge: tightest code to find-replace a string Robert Wessel <robertwessel2@yahoo.com> - 2014-06-06 11:55 -0500
        Re: Challenge: tightest code to find-replace a string Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-06-06 20:47 +0200
    Re: Challenge: tightest code to find-replace a string Ike Naar <ike@iceland.freeshell.org> - 2014-06-06 06:05 +0000
      Re: Challenge: tightest code to find-replace a string Noob <root@127.0.0.1> - 2014-06-06 10:17 +0200
        Re: Challenge: tightest code to find-replace a string Ian Collins <ian-news@hotmail.com> - 2014-06-08 21:20 +1200
    Re: Challenge: tightest code to find-replace a string Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-06 14:41 +0100
      Re: Challenge: tightest code to find-replace a string "BartC" <bc@freeuk.com> - 2014-06-06 16:29 +0100
        Re: Challenge: tightest code to find-replace a string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-06-06 17:27 +0000
        Re: Challenge: tightest code to find-replace a string Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-06 22:16 +0100
          Re: Challenge: tightest code to find-replace a string "BartC" <bc@freeuk.com> - 2014-06-06 23:26 +0100
            Re: Challenge: tightest code to find-replace a string Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-06 23:38 +0100
      Re: Challenge: tightest code to find-replace a string Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-06 08:31 -0700
        Re: Challenge: tightest code to find-replace a string Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-06 22:12 +0100
      Re: Challenge: tightest code to find-replace a string Chad <cdalten@gmail.com> - 2014-06-07 12:19 -0700
        Re: Challenge: tightest code to find-replace a string Chad <cdalten@gmail.com> - 2014-06-07 13:38 -0700
          Re: Challenge: tightest code to find-replace a string raltbos@xs4all.nl (Richard Bos) - 2014-06-08 10:34 +0000
      Re: Challenge: tightest code to find-replace a string DFS <nospam@dfs.com> - 2014-06-07 18:30 -0400
        Re: Challenge: tightest code to find-replace a string Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-08 13:09 +0100
          Re: Challenge: tightest code to find-replace a string DFS <nospam@dfs.com> - 2014-06-08 12:42 -0400
            Re: Challenge: tightest code to find-replace a string Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-09 01:44 +0100
              Re: Challenge: tightest code to find-replace a string Siri Crews <chine.bleu@yahoo.com> - 2014-06-08 22:15 -0700
                Re: Challenge: tightest code to find-replace a string Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-09 12:58 +0100
              Re: Challenge: tightest code to find-replace a string Ike Naar <ike@iceland.freeshell.org> - 2014-06-09 06:40 +0000
                Re: Challenge: tightest code to find-replace a string Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-09 13:04 +0100
                  Re: Challenge: tightest code to find-replace a string "BartC" <bc@freeuk.com> - 2014-06-09 15:27 +0100
                    Re: Challenge: tightest code to find-replace a string Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-06-09 16:22 +0100
                      Re: Challenge: tightest code to find-replace a string "BartC" <bc@freeuk.com> - 2014-06-09 18:06 +0100
                      Re: Challenge: tightest code to find-replace a string "BartC" <bc@freeuk.com> - 2014-06-09 22:38 +0100
        Re: Challenge: tightest code to find-replace a string Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-10 00:57 -0700
    Re: Challenge: tightest code to find-replace a string DFS <nospam@dfs.com> - 2014-06-07 17:36 -0400
      Re: Challenge: tightest code to find-replace a string "BartC" <bc@freeuk.com> - 2014-06-08 09:57 +0100
        Re: Challenge: tightest code to find-replace a string DFS <nospam@dfs.com> - 2014-06-08 12:43 -0400
          Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-08 15:27 -0700
          Re: Challenge: tightest code to find-replace a string "BartC" <bc@freeuk.com> - 2014-06-09 10:02 +0100
            Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-09 08:03 -0700
      Re: Challenge: tightest code to find-replace a string Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-08 04:43 -0700
        Re: Challenge: tightest code to find-replace a string DFS <nospam@dfs.com> - 2014-06-08 13:26 -0400
        Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-08 15:24 -0700
          Re: Challenge: tightest code to find-replace a string Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-09 08:39 -0700
            Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-09 08:57 -0700
              Re: Challenge: tightest code to find-replace a string Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-09 09:52 -0700
                Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-09 11:25 -0700
                  Re: Challenge: tightest code to find-replace a string Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-09 13:42 -0700
                    Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-09 15:02 -0700
                    Re: Challenge: tightest code to find-replace a string Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-09 16:04 -0700
                      Re: Challenge: tightest code to find-replace a string raltbos@xs4all.nl (Richard Bos) - 2014-06-10 10:23 +0000
            Re: Challenge: tightest code to find-replace a string raltbos@xs4all.nl (Richard Bos) - 2014-06-09 16:57 +0000
              Re: Challenge: tightest code to find-replace a string raltbos@xs4all.nl (Richard Bos) - 2014-06-10 10:06 +0000
    Re: Challenge: tightest code to find-replace a string "Chris M. Thomasson" <no@spam.invalid> - 2014-06-09 12:43 -0700
      Re: Challenge: tightest code to find-replace a string "Chris M. Thomasson" <no@spam.invalid> - 2014-06-09 14:32 -0700
        Re: Challenge: tightest code to find-replace a string "Chris M. Thomasson" <no@spam.invalid> - 2014-06-09 16:09 -0700
        Re: Challenge: tightest code to find-replace a string James Kuyper <jameskuyper@verizon.net> - 2014-06-09 21:35 -0400
      Re: Challenge: tightest code to find-replace a string DFS <nospam@dfs.com> - 2014-06-10 09:39 -0400
        Re: Challenge: tightest code to find-replace a string James Kuyper <jameskuyper@verizon.net> - 2014-06-10 11:26 -0400
        Re: Challenge: tightest code to find-replace a string raltbos@xs4all.nl (Richard Bos) - 2014-06-11 16:16 +0000
        Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-11 09:25 -0700
          Re: Challenge: tightest code to find-replace a string Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-11 13:48 -0700
            Re: Challenge: tightest code to find-replace a string "BartC" <bc@freeuk.com> - 2014-06-11 22:04 +0100
              Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-11 14:59 -0700
            Re: Challenge: tightest code to find-replace a string Ike Naar <ike@iceland.freeshell.org> - 2014-06-11 21:35 +0000
            Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-11 14:56 -0700
              Re: Challenge: tightest code to find-replace a string Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-12 02:24 -0700
                Re: Challenge: tightest code to find-replace a string Keith Thompson <kst-u@mib.org> - 2014-06-12 09:09 -0700
                  Re: Challenge: tightest code to find-replace a string Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-13 00:40 -0700
                    Re: Challenge: tightest code to find-replace a string "BartC" <bc@freeuk.com> - 2014-06-13 09:17 +0100
    Re: Challenge: tightest code to find-replace a string "Chris M. Thomasson" <no@spam.invalid> - 2014-06-14 13:12 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#45607 — Challenge: tightest code to find-replace a string

* reads an existing file
* writes changes to new file
* counts replacements made by line
* counts total replacements made
* no fancy usage of sed!

I KNOW someone can better my piddly effort below (actually one I found 
online and made mods to):
=================================================================================
#include <stdio.h>
#include <string.h>

int findreplace(void)
{
     int 	bufferSize = 0x1000;
     int 	i = 0, k = 0, j = 0;
     char      buffer[bufferSize];
     FILE     *inFile = fopen("random_in.txt", "rt");
     FILE     *outFile = fopen("random_out.txt", "w+");
     char     *find = "46";
     char     *replace = "----";

     if(inFile == NULL || outFile == NULL)
     {
         printf("Error opening file(s)");
         return 1;
     }

     printf("Replace '%s' with '%s':\n", find, replace);

     while(fgets(buffer, bufferSize, inFile) != NULL)
     {
         char *stop = NULL;
         char *start = buffer;
         k = 0;

         while(1)
         {
             stop = strstr(start, find);

             if(stop == NULL)
             {
                 fwrite(start, 1, strlen(start), outFile);
                 break;
             } else {
		fwrite(start, 1, stop - start, outFile);
		fwrite(replace, 1, strlen(replace), outFile);
		start = stop + strlen(find);
		k++;
	    }
         }

         i++;
         j += k;
         printf("Line %d: %d replacements made\n", i, k);
     }
	printf("%d replacements made.\n", j);
	
     fclose(inFile);
     fclose(outFile);

     return 0;
}


int main(void) {
	findreplace();
	return 0;
}

=================================================================================

input (random_in.txt)

14513111664214260256543011122553234523520226455552
41602561064325541006060354620223361346535061545034
63164621623130051346620535103421535300201464252314
30013144611120401561305220534605456101542562311260
30501506124251042546364005110661421500320026101445
35355334213621124600100142264440253516210400362562
65140560414014522562466550406113020500531011441421
60543325410345553336424511333322104440166124450061
44310321435636412163052026304311532342515351020026
10536502643531635353214012163164121056142415600245

output (random_out.txt)

14513111664214260256543011122553234523520226455552
4160256106432554100606035----202233613----535061545034
6316----216231300513----620535103421535300201----4252314
3001314----1112040156130522053----05456101542562311260
305015061242510425----364005110661421500320026101445
3535533421362112----00100142264440253516210400362562
65140560414014522562----6550406113020500531011441421
60543325410345553336424511333322104440166124450061
44310321435636412163052026304311532342515351020026
10536502643531635353214012163164121056142415600245

=================================================================================


[dfs@home files]$ ./find_replace
Replace '46' with '----':
Line 1: 0 replacements made
Line 2: 2 replacements made
Line 3: 3 replacements made
Line 4: 2 replacements made
Line 5: 1 replacements made
Line 6: 1 replacements made
Line 7: 1 replacements made
Line 8: 0 replacements made
Line 9: 0 replacements made
Line 10: 0 replacements made
10 replacements made.

=================================================================================

[toc] | [next] | [standalone]

#45609

On 6/6/2014 12:27 AM, Stefan Ram wrote:
> DFS <nospam@dfs.com> writes:
>> I KNOW someone can better my piddly effort below (actually one I found
>> online and made mods to):
>
>    What you wrote does not replace strings that contain
>    line breaks or occur at 0x1000 boundaries.

OK.

But the challenge isn't to say what it can't do.  It's to show a tighter 
piece of code that does it as well or better.

Looking forward to your entry!

[toc] | [prev] | [next] | [standalone]

#45613

On Fri, 2014-06-06, DFS wrote:
> On 6/6/2014 12:27 AM, Stefan Ram wrote:
>> DFS <nospam@dfs.com> writes:
>>> I KNOW someone can better my piddly effort below (actually one I found
>>> online and made mods to):
>>
>>    What you wrote does not replace strings that contain
>>    line breaks or occur at 0x1000 boundaries.
>
> OK.
>
> But the challenge isn't to say what it can't do.  It's to show a tighter 
> piece of code that does it as well or better.

But to do that you need to understand what the program is supposed to
accomplish.

And by the way, I don't understand what "tight" means.  I'd personally
optimize for memory and I/O use.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#45616

On 6/6/14, 3:34 AM, DFS wrote:
> On 6/6/2014 12:27 AM, Stefan Ram wrote:
>> DFS <nospam@dfs.com> writes:
>>> I KNOW someone can better my piddly effort below (actually one I found
>>> online and made mods to):
>>
>>    What you wrote does not replace strings that contain
>>    line breaks or occur at 0x1000 boundaries.
>
> OK.
>
> But the challenge isn't to say what it can't do.  It's to show a tighter
> piece of code that does it as well or better.
>
> Looking forward to your entry!
>
>
>

But it does disqualify your entry as it doesn't accomplish the stated 
goal. Looking forward to your fix!

[toc] | [prev] | [next] | [standalone]

#45621

On Fri, 06 Jun 2014 04:34:05 -0400, DFS <nospam@dfs.com> wrote:

>On 6/6/2014 12:27 AM, Stefan Ram wrote:
>> DFS <nospam@dfs.com> writes:
>>> I KNOW someone can better my piddly effort below (actually one I found
>>> online and made mods to):
>>
>>    What you wrote does not replace strings that contain
>>    line breaks or occur at 0x1000 boundaries.
>
>OK.
>
>But the challenge isn't to say what it can't do.  It's to show a tighter 
>piece of code that does it as well or better.
>
>Looking forward to your entry!


Well, since it apparently doesn't actually have to work, here's my
entry:

int findreplace(void)
{
    return 0;
}


I suspect it will be difficult to beat.

But seriously, if you want to judge someone's code as being tighter
than some other code, the baseline code should at least work!

[toc] | [prev] | [next] | [standalone]

#45624

On 06.06.2014 18:55, Robert Wessel wrote:

> Well, since it apparently doesn't actually have to work, here's my
> entry:
> 
> int findreplace(void)
> {
>     return 0;
> }

Actually, this fulfills the requirement pretty much in all cases. All
cases in which the search string has no occurences, that is.

> I suspect it will be difficult to beat.

Here's my take at it:

int findreplace(int searchstring) {
	if (searchstring < 2) {
		return 0;
	} else if (searchstring == 2) {
		return 1;		
	} else {
		for (int i = 2; i < searchstring; i++) {
			if ((searchstring % i) == 0) {
				return 0;
			}
		}
		return 1;
	}
}

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#45610

On 2014-06-06, DFS <nospam@dfs.com> wrote:
>          while(1)
>          {
>              stop = strstr(start, find);
>
>              if(stop == NULL)
>              {
>                  fwrite(start, 1, strlen(start), outFile);
>                  break;
>              } else {
> 		fwrite(start, 1, stop - start, outFile);
> 		fwrite(replace, 1, strlen(replace), outFile);
> 		start = stop + strlen(find);
> 		k++;
> 	    }
>          }

This could be simplified to

         while (stop = strstr(start, find), stop != NULL)
         {
            fwrite(start, 1, stop - start, outFile);
            fputs(replace, outFile);
            start = stop + strlen(find);
            k++;
         }
         fputs(start, outFile);

[toc] | [prev] | [next] | [standalone]

#45611

Ike Naar wrote:

>  while (stop = strstr(start, find), stop != NULL)

This doesn't "feel" very idiomatic.

Perhaps

  while ((stop = strstr(start, find)) != NULL)

or even

  while (stop = strstr(start, find))

The second one raises warnings with most compilers.

  while ((stop = strstr(start, find)))

may shut them up.

[toc] | [prev] | [next] | [standalone]

#45643

Noob wrote:
> Ike Naar wrote:
>
>>   while (stop = strstr(start, find), stop != NULL)
>
> This doesn't "feel" very idiomatic.
>
> Perhaps
>
>    while ((stop = strstr(start, find)) != NULL)
>
> or even
>
>    while (stop = strstr(start, find))
>
> The second one raises warnings with most compilers.
>
>    while ((stop = strstr(start, find)))
>
> may shut them up.

Or just write:

     const size_t findSize = strlen(find);
     const char* stop      = strstr(start, find);

     while( stop )
     {
       fwrite(start, 1, stop - start, outFile);
       fputs(replace, outFile);
       start = stop + findSize;
       k++;
       stop = strstr(start, find);
     }

     fputs(start, outFile);

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#45618

DFS <nospam@dfs.com> writes:

> * reads an existing file
> * writes changes to new file
> * counts replacements made by line
> * counts total replacements made
> * no fancy usage of sed!

It reports rather than counts these matches.  I would never write a
function with this spec. because it destroys its usefulness in other
contexts.  A function should do one thing well.

I'd write a string match/replace function that returns the number of
matches.  If I needed the counts reported by line, I'd write a wrapper
that adds those.

int replace_string(const char *match, const char *repl, int stopper,
                   FILE *fi, FILE *fo)
{
     int nmatches = 0, c;
     const char *mp = match;
     while ((c = fgetc(fi)) != EOF && c != stopper)
          if (c == *mp) {
               if (!*++mp) {
                    ++nmatches;
                    fputs(repl, fo);
               }
          }
          else {
               mp = match;
               fputc(c, fo);
          }
     return nmatches;
}

Called with stopper == EOF it processes a whole file.  Note how removing
the line buffer actually simplifies the code, whilst also removing an
unnecessary restriction.  It's not uncommon for this to happen (there
was a recent thread about this).

Called with stopper == '\n' it processes a line and so this wrapper
prints the report:

void replace_string_report(const char *match, const char *repl,
                          FILE *fi, FILE *fo)
{
     int total_matches = 0, lineno = 0;
     while (!feof(fi)) {
          int nm = replace_string(match, repl, '\n', fi, fo);
          printf("\nLine %d: %d replacements\n", ++lineno, nm);
          total_matches += nm;
     }
     printf("%d replacements\n", total_matches);
}

Here's the driver for testing.

int main(int argc, char **argv)
{
     if (argc > 2) {
          FILE *fin  = argc > 3 ? fopen(argv[3], "r") : stdin;
          FILE *fout = argc > 4 ? fopen(argv[4], "w") : stdout;
          if (fin && fout)
               replace_string_report(argv[1], argv[2], fin, fout);
     }
}

Functions that mix tasks that can be logically separated are best
avoided.  Functions with hard-wired file names and strings are, well,
let's just say, sub-optimal.  Students used to say "but it's because I'm
just testing" but a simple driver like the one above makes testing
much easier than having the files and strings hard wired.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#45619

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.55d78fa3ca96ce6aed82.20140606144139BST.87r432w3xo.fsf@bsb.me.uk...
> DFS <nospam@dfs.com> writes:
>
>> * reads an existing file
>> * writes changes to new file
>> * counts replacements made by line
>> * counts total replacements made
>> * no fancy usage of sed!

> int main(int argc, char **argv)
> {
>     if (argc > 2) {
>          FILE *fin  = argc > 3 ? fopen(argv[3], "r") : stdin;
>          FILE *fout = argc > 4 ? fopen(argv[4], "w") : stdout;
>          if (fin && fout)
>               replace_string_report(argv[1], argv[2], fin, fout);
>     }
> }
>
> Functions that mix tasks that can be logically separated are best
> avoided.  Functions with hard-wired file names and strings are, well,
> let's just say, sub-optimal.  Students used to say "but it's because I'm
> just testing" but a simple driver like the one above makes testing
> much easier than having the files and strings hard wired.

The OP's findreplace() function where everything was hard-coded inside it, 
rather than being passed as arguments did grate a little (that would also be 
the first thing I'd change).

But I wouldn't bother with command line parameters for testing until it's 
finished. Far easier to just write:

 int main(void) {
   replace_string_report("46","----", "random_in.txt", "random_out.txt");
 }

(Although you'd have to decide whether file names or handles are going to be 
passed. If this is the only find&replace operation on the file, then file 
names are probably more appropriate, although it will need more 
error-checking inside the function.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#45622

On Fri, 2014-06-06, BartC wrote:
...

> The OP's findreplace() function where everything was hard-coded inside it, 
> rather than being passed as arguments did grate a little (that would also be 
> the first thing I'd change).
>
> But I wouldn't bother with command line parameters for testing until it's 
> finished. Far easier to just write:
>
>  int main(void) {
>    replace_string_report("46","----", "random_in.txt", "random_out.txt");
>  }
>
> (Although you'd have to decide whether file names or handles are going to be 
> passed. If this is the only find&replace operation on the file, then file 
> names are probably more appropriate, although it will need more 
> error-checking inside the function.)

The easiest and most useful is to default to stdin and stdout, just
like sed(1) does.  The second most useful is to emulate Perl's <>
operator (stdin, or a sequence of named files, including "-" which
means stdin).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#45626

"BartC" <bc@freeuk.com> writes:
<snip>
> But I wouldn't bother with command line parameters for testing until
> it's finished. Far easier to just write:
>
> int main(void) {
>   replace_string_report("46","----", "random_in.txt", "random_out.txt");
> }

For a few lines of code you get much greater flexibility in testing.
Maybe your environment does not make command-line programs easy to run?

> (Although you'd have to decide whether file names or handles are going
> to be passed. If this is the only find&replace operation on the file,
> then file names are probably more appropriate, although it will need
> more error-checking inside the function.)

Why would you ever use file names?  It's inherently a stream operation,
so limiting it to named files just makes it clunky, in my view.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#45629

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.07e37551ed04d6f2aaf2.20140606221629BST.87ha3xvivm.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

>> (Although you'd have to decide whether file names or handles are going
>> to be passed. If this is the only find&replace operation on the file,
>> then file names are probably more appropriate, although it will need
>> more error-checking inside the function.)
>
> Why would you ever use file names?  It's inherently a stream operation,
> so limiting it to named files just makes it clunky, in my view.

I don't understand streams. I like things to have a beginning and an end,
and a whole file is a well-understood chunk of data to work on, if it's not
possible to just  work on strings (which would be my approach; then it would
be independent from files *and* streams).

Imagine if you were creating some string functions where strings didn't have
a well-defined end and could conceivably have an unlimited length...



-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#45630

"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.07e37551ed04d6f2aaf2.20140606221629BST.87ha3xvivm.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>
>>> (Although you'd have to decide whether file names or handles are going
>>> to be passed. If this is the only find&replace operation on the file,
>>> then file names are probably more appropriate, although it will need
>>> more error-checking inside the function.)
>>
>> Why would you ever use file names?  It's inherently a stream operation,
>> so limiting it to named files just makes it clunky, in my view.
>
> I don't understand streams. I like things to have a beginning and an end,
> and a whole file is a well-understood chunk of data to work on, if it's not
> possible to just  work on strings (which would be my approach; then it would
> be independent from files *and* streams).

A stream can have an end.  And not all named files do.  I don't think
this is useful distinction.

Anyway, if you don't like streams, I see no reason to make you like
them.  I like my way and I imagine you are happy with yours.

> Imagine if you were creating some string functions where strings didn't have
> a well-defined end and could conceivably have an unlimited length...

That does not sound like what I meant by "this is a stream operation".
It certainly does not apply in the case being discussed.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#45620

On Friday, June 6, 2014 2:41:39 PM UTC+1, Ben Bacarisse wrote:
>
> int replace_string(const char *match, const char *repl, int stopper, 
>                    FILE *fi, FILE *fo)
> 
> {
>      int nmatches = 0, c;
>      const char *mp = match;
> 
>      while ((c = fgetc(fi)) != EOF && c != stopper)
>           if (c == *mp) {
>                if (!*++mp) {
>                     ++nmatches;
>                     fputs(repl, fo);
>                }
>           }
>           else {

              /* bug here? fwrite(match, mp-match, 1, of); */
>                mp = match;
>                fputc(c, fo);
> 
>           }
> 
>      return nmatches;
> 
> }
> 
> 
I think there's a bug in this. Fix untested.

[toc] | [prev] | [next] | [standalone]

#45625

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Friday, June 6, 2014 2:41:39 PM UTC+1, Ben Bacarisse wrote:
>>
>> int replace_string(const char *match, const char *repl, int stopper, 
>>                    FILE *fi, FILE *fo)
>> 
>> {
>>      int nmatches = 0, c;
>>      const char *mp = match;
>> 
>>      while ((c = fgetc(fi)) != EOF && c != stopper)
>>           if (c == *mp) {
>>                if (!*++mp) {
>>                     ++nmatches;
>>                     fputs(repl, fo);
>>                }
>>           }
>>           else {
>
>               /* bug here? fwrite(match, mp-match, 1, of); */

Yes, thanks.  The unmatched portion needs to be printed on failure.

>>                mp = match;
>>                fputc(c, fo);
>> 
>>           }
>>      return nmatches;
>> }

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#45637

Ack, my browser refuses to include the quoted text in my reply. Anyhow, having strings hardwired into a function in some cases could possibly change and/or break a function. The one example that comes to mind are functions that add text to some kind of graphic. If the string name was hardwired in, the computer could possibly interpret that string as a single point on the plane. That could be bad since a piece of text can sometimes span across a line.

[toc] | [prev] | [next] | [standalone]

#45639

From my limited experience, the problem comes from if you view the function as performing some kind of action on a string. From this vantage point, the function would move the string along some line as it executes. Once the function is done, the string would stop at some point. Now if you would let s represent some string, the same thing would happen. However, s would be the entire length of the traversal.

[toc] | [prev] | [next] | [standalone]

#45644

Chad <cdalten@gmail.com> wrote:

> From my limited experience,

Very limited. Stop posting in a vacuum.

Richard

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web