No. of 'a' in a text file

[Gianni Mariani]

I don't see how that makes it acceptable - he didn't even set
followups to comp.lang.c++.

If the OP wanted a C solution, then the poster should have posted to
comp.lang.c only. If you don't want C++ discussion in comp.lang.c then
ask the OP to not cross post or somthing. Seeing as you're posting to
comp.lang.c++, it's hard to argue that there should be no C++ discussion...

<dig motive=jest>

Anyway, you should learn to program in a real language ....

</dig>

 

[Bill Pursell]

In the following, "that ungood thing" refers to multiple
declarations in a single line:

And when you're not doing that ungood thing, writing FILE* f makes sense.

There I disagree. If you're going to have declarations of any
significant complexity, you need to understand why C declaration are
the way they are (declaration follows use). With that understanding,
"FILE *f" just makes more sense.

FILE *f; /* *f is a FILE */
int a[10] /* a[10] is an int (or would be if it existed */

When I look to the declaration section of a block to see
what type f is, I'm interested in seeing what type f is. I don't
want to see what *f is. In other words, I'd rather derive
information about *f from information about f rather
than the other way around.

But in simple cases like "FILE *f" / "FILE* f", it isn't all that big
a deal. Declaring it as "FILE* f" implies that f is a FILE* -- which
happens to be true in this case, but the principle doens't extend to
other forms of declarations. As long as you can keep it straight,
I'll still *prefer* to keep the "*" next to the identifier, but I can
cope with other styles.

In working code, what percentage of declarations are not the
"simple case"? Declarations of function pointers obviously
require special treatment, as do
complex array types, but "T * x" is probably valid 95% of the time.
And the non-simple cases could perhaps be made clearer: eg

typedef int (*int_int_fcn)(int);

int_int_fcn * h;
int (**f)(int);


.....hmmm, perhaps this is a bad example...or perhaps you are,
as usual, correct. The declaration of h was supposed to be
clearer than the declaration of f, but I would argue that this is
not the case.

 

[Default User]

What on earth possessed you to send this to comp.lang.c? Do you
realize that C != C++?

See what I said to Richard. It's wildly unfair to expect other people
to anticipate what's topical regarding other groups in a cross-posted
message, or to refrain from giving replies that are perfectly correct
and topical for their group.

It's the fault of the OP, but that doesn't matter. It would have been
helpful for the clc++ people to cut clc out the their replies, but none
of the clc did that either, so there's plenty of blame to go around.




Brian

 

[Default User]

I don't see how that makes it acceptable - he didn't even set
followups to comp.lang.c++.

What would follow-ups have to do with it? Did you mean "adjust the
newsgroup list"?



Brian

 

[Richard Heathfield]

Default User said:

Richard Heathfield wrote:

I'm sorry Richard, but you're just way off-base here. When messages
are cross-posted like that, you can't use your own group's topicality
to override the other's.

Why not? He did.

 

[Default User]

Default User said:
code. >> Please don't do that again. Thank you.

Why not? He did.

He complained about your posts being off-topic? I must have missed that.




Brian

 

[Richard Heathfield]

Default User said:

He complained about your posts being off-topic?

No, he used the topicality of C++ in comp.lang.c++ to override
comp.lang.c's topic, which is C, not C++.

I must have missed that.

I must have missed the point where this discussion got very dull, but
I'm sure we have passed it by now.

 

[Francine.Neary]

What would follow-ups have to do with it? Did you mean "adjust the
newsgroup list"?

It would be reasonable to say (perhaps not in so many words): "The OP
started a discussion in both clc and clc++. His original post, and all
discussion so far, involved only C code, and shouldn't really have
been crossposted to clc++, for which I curse the OP (and other clc'ers
who replied without spotting that it had been crossposted and removing
clc++). However, as it happens I have an interesting approach to this
in C++. So in case anyone reading the thread in clc would be
interested, I'll crosspost the code, but set followups to clc++ so
that any resulting discussion goes to the right place".

 

[James Kanze]

I've been using the C code below for awhile. It allows me to search for
any pattern of bytes, not just strings (the pattern can contain NULs, in
other words, and can be used to find number images and other patterns of
bits). The approach is

create a buffer to read blocks of the file into
fill the start of the buffer with patlen bytes
loop
fill the rest of the buffer with buflen - patlen bytes
for each byte position in the buffer
if match( buffer byte position, pattern )
return file position
endfor
/* if we're here, we didn't find a match */
copy patlen bytes from the end of the buffer to the start
endloop
return no match found

The business with moving patlen bytes from the end to the start of the
buffer is to catch cases where the match straddles a block boundary (it
starts at the end of one buflen block of bytes and finishes in the next
one).

That brings back memories. I remember doing something
similar back in the 1980's. Using a buffer size of around 32KB,
but with a BM search, instead of trying to match starting at
each character; the results were over twice as fast as fgrep on
the machine I was using. (The strings we were searching were
typically between 8 and 16 characters in length, which meant
that using BM search really made a difference.)

If you need to be very, very fast, over large quantities of
data, it's still probably the best solution (although I'd
consider mmap as well). But it's not something I'd start out
with.

For most uses, maintaining a sliding window into the file,
either with std::deque, std::vector, or a circular queue (or
their equivalents under C) is a lot quicker and easier to
implement.

 

[James Kanze]

"James Kanze" <[email protected]> ha scritto nel messaggionews:[email protected]...

In C, for this specific case, I'd probably write something like: [snip]
FILE* f = fopen( "somefile.txt", "r" ) ;

What's the point of putting f so far on the right?

To make declarations look different from expression statements,
and to allow easily finding what is being declared. Lining up
the symbols being declared has been part of the coding
guidelines in most of the places where I used C; for some
reason, it seems less popular in C++, although I find it even
more important there.

Anyhow, I'd write FILE *f rather than FILE* f, or else when you
write FILE* f, g you'll be surprised by results.

Every coding guideline I've ever seen has forbidden defining
more than one variable per statement. It's just bad programming
practice. Other than that, it's mostly a matter of taste. I
find it cleaner to separate the type from what is being defined.

[snip]> exit( 2 ) ;

The behaviour of this is implementation-defined.

True. I guess I'm just too used to Unix (and it also works
under Windows). EXIT_FAILURE is more portable. (But it
provides less information.)

On the DS9K,
exit(2) makes the program securely erase the whole disk on exit.
The standard way to do that is exit(EXIT_FAILURE);

And the Unix way is exit(2).

You can use declarations after statements only in C99. No
problem if you have a C99-compliant compiler (gcc isn't). The
same for declarations within the guard of a for loop.

I compiled the code with gcc, just to make sure:
gcc -std=c99 -pedantic -Wall
This is 2007, you know, not 1983 (when I first learned C).

 

[James Kanze]

"Alf P. Steinbach" <[email protected]> writes:

[...]

There I disagree. If you're going to have declarations of any
significant complexity, you need to understand why C declaration are
the way they are (declaration follows use).

Except that declaration follows use went out of C the day
typedef's were introduced. And struct's, and all the rest. C's
declaration syntax is an experiment which failed. The basic
idea, applied to the very earliest C, seems interesting (and as
an experiment, was certainly worth doing), but it doesn't scale
properly once users start defining types.

With that understanding,
"FILE *f" just makes more sense.

FILE *f; /* *f is a FILE */
int a[10] /* a[10] is an int (or would be if it existed */

And what do you do once typedefs and user defined struct's enter
into the picture:

typedef int* Toto ;
Toto t ;
struct MyStruct s ;

or from an actual program I wrote (about 20 years ago):

struct T
{
// ...
struct V* (*f[ 8 ])( struct V* ) ;
} ;
struct T a[] = {...} ;
, use:
s = (*p->f[j])( s ) ;

Any relationship between use and definition seems very tenuous,
at best.

There is an argument based on grouping: at the very highest
level, a declaration breaks down into a declaration specifier
and a declarator; the * is part of the declarator. But on the
whole, I think it's just a lot cleaner to think in terms of the
resulting types: conceptually, I'm not declaring *p to be an
int, I'm declaring p to be an int*.

But in simple cases like "FILE *f" / "FILE* f", it isn't all that big
a deal. Declaring it as "FILE* f" implies that f is a FILE* -- which
happens to be true in this case, but the principle doens't extend to
other forms of declarations. As long as you can keep it straight,
I'll still *prefer* to keep the "*" next to the identifier, but I can
cope with other styles.

You have to, if you're going to work in C or in C++. The
declaration syntax is a disaster, but it has to be learned and
lived with. I use Type*, rather than Type *, because that's
what is most frequent in C++, but I don't have any illusions
that one or the other miraculously make the declaration syntax
readable to a beginner.

 

[James Kanze]

Gianni Mariani said:

No, thank you. If I want C++, I know where to find it - but I don't
expect to find it in comp.lang.c.

The original posting (and all of the follow-ups) have been cross
posted to both comp.lang.c and comp.lang.c++. So it's hard to
know what sort of solution the original poster wanted: C or C++.
I know that I'd use different solutions in the two languages.

Anyway, Gianni cross-posted a C++ solution to comp.lang.c,
probably unintentionally, and now you're bitching that it isn't
C in comp.lang.c++, probably unintentionally as well.

 

[James Kanze]

See what I said to Richard. It's wildly unfair to expect other people
to anticipate what's topical regarding other groups in a cross-posted
message, or to refrain from giving replies that are perfectly correct
and topical for their group.

It's also very unrealistic to expect other people to notice the
cross-posting.

It's the fault of the OP, but that doesn't matter. It would have been
helpful for the clc++ people to cut clc out the their replies, but none
of the clc did that either, so there's plenty of blame to go around.

I suspect that many people would have done so if they'd have
noticed. I only noticed the cross-posting by chance; the
original code seems somewhat more idiomatic for C than for C++,
so I responded in that vein (although I believe I did mention
that in C++, better solutions were available). But I'm reading
this in clc++, and had I not noticed the cross-posting, I'd
probably have posted much more C++'ish.

And of course, I'm old enough that it is fun to go back to the
more primitive days of my youth. To the good old days, when men
were men, women were women, and pointers were ints.

 

[James Kanze]

"Bruce !C!+" <[email protected]> ha scritto nel messaggionews:[email protected]...

It'll stop if it hits a null character.
Try while((ch = getc(f) != EOF)

Why not:

int ch,count=0;
while((ch=getc(f))=='a'?++count:ch!=EOF);

Since the goal seems to be as unreadable as possible.

 

[Flash Gordon]

Default User wrote, On 22/04/07 22:35:

I'm sorry Richard, but you're just way off-base here. When messages are
cross-posted like that, you can't use your own group's topicality to
override the other's.

Nor can others use their topicality to override that of comp.lang.c.
When it is cross posted, if posting something not topical in all the
groups then at least followups (if not the entire message) should be
redirected to the subset of groups where the post is topical.

This, of course, is also an example of why cross-posting between
comp.lang.c and comp.lang.c++ is rarely a good thing, since the best C++
solution is often not valid C.

 

[Gianni Mariani]

Flash Gordon wrote:
....

Nor can others use their topicality to override that of comp.lang.c.
When it is cross posted, if posting something not topical in all the
groups then at least followups (if not the entire message) should be
redirected to the subset of groups where the post is topical.

This, of course, is also an example of why cross-posting between
comp.lang.c and comp.lang.c++ is rarely a good thing, since the best C++
solution is often not valid C.

Not all valid C is valid C++ either.

 

[Richard Heathfield]

Gianni Mariani said:

Flash Gordon wrote:
...

Not all valid C is valid C++ either.

Quite so. In fact, a surprisingly small amount of good C is valid C++.

 

[Kenneth Brody]

/*Calculate the no. of occurance of 'ab'. But is this one OK/
EFFICIENT?*/
#include<stdio.h>
int main(void)
{
FILE *f;
long int c,c1,ab=1;
f=fopen("c:/1.txt","r");
while ((c=getc(f))!=EOF && (c1=getc(f))!=EOF) {
if(c=='a' && c1=='b') ab++;}
fclose(f);
printf("No. of 'ab' = %ld\n",ab);
return 0;
}

In addition to the other comments, consider what happens if the
file contains:

abababababab
or
xabababababab

What will your code give as the count for each of the above?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Default User]

Default User said:

No, he used the topicality of C++ in comp.lang.c++ to override
comp.lang.c's topic, which is C, not C++.

He answered in a way that was topical for his group. Very likely he
didn't notice that it was even cross-posted. However, he didn't take
that extra step to chastise someone else for "off-topic" posting for
something that was perfectly topical where another was reading and
responding.

If you failed to notice that it was cross-posted when you complained
about the topicality, then that's certainly understandable. If not,
then as I said you're out of line.

I must have missed the point where this discussion got very dull, but
I'm sure we have passed it by now.

Well, I'm done with it from this point. If you feel like a last
thought, I'll read it with interest but won't be responding (outside of
a direct question or change of direction).



Brian

 

[Francine.Neary]

He answered in a way that was topical for his group. Very likely he
didn't notice that it was even cross-posted. However, he didn't take
that extra step to chastise someone else for "off-topic" posting for
something that was perfectly topical where another was reading and
responding.

If you failed to notice that it was cross-posted when you complained
about the topicality, then that's certainly understandable. If not,
then as I said you're out of line.

It seems to me that there's this difference: although the OP
crossposted, every reply up to that point had included only C code.
When there was a post full of C++, it jumped out immediately reading
it in clc. So I'd assume that if I'd been reading it in clc++ then all
the posts full of C would similarly have jumped out at me, and I'd
either have killed the thread (if my newsreader had that function) or
been alerted to the fact that it had probably been crossposted.