Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Histogram of character frequencies

Reply
Thread Tools

Histogram of character frequencies

 
 
James Kuyper
Guest
Posts: n/a
 
      12-02-2007
Johannes Bauer wrote:
....
> And the comment you used "//" is *not* valid C, it's C++. So this simple
> line of code contains lots of mistakes, each and every one should be
> avoided in order to create portable code.


C standard, 6.4.9p2:

"Except within a character constant, a string literal, or a comment, the
characters // introduce a comment that includes all multibyte characters
up to, but not including, the next new-line character. The contents of
such a comment are examined only to identify multibyte characters and to
find the terminating new-line character."
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      12-02-2007
Johannes Bauer wrote:
>

.... snip ...
>
> You code contains errors. Why do you post it here? To learn
> something? Then accept the hints you're given. You'll be grateful
> at some point in time, although you're currently obviously far
> too stubborn to realize what you're doing.
>
> If you need somebody to pet you and tells you your code is great,
> this is probably the wrong place.


He could try alt.applause.crud.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      12-02-2007
James Kuyper wrote:
> Johannes Bauer wrote:
> ...
>> And the comment you used "//" is *not* valid C, it's C++. So this
>> simple line of code contains lots of mistakes, each and every one
>> should be avoided in order to create portable code.

>
> C standard, 6.4.9p2:
>
> "Except within a character constant, a string literal, or a comment,
> the characters // introduce a comment that includes all multibyte
> characters up to, but not including, the next new-line character.
> The contents of such a comment are examined only to identify
> multibyte characters and to find the terminating new-line character."


That is for C99. C90 doesn't accept it. They are also a grave
mistake on Usenet, because of line wrapping characteristics.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.


--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Tor Rustad
Guest
Posts: n/a
 
      12-02-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Johannes Bauer wrote:
>> (E-Mail Removed) schrieb:


==============================================
----->>> ***READ THE C FAQ*** NOW!!! <<<<-----
......>>> ***READ THE C FAQ*** NOW!!! <<<<.....
......>>> ***READ THE C FAQ*** NOW!!! <<<<.....
----->>> ***READ THE C FAQ*** NOW!!! <<<<-----
==============================================

>>> int x[256]; // frequencies

>> Global.

>
> It's completely acceptable to have variables defined at file scope in
> C!


I once asked a COBOL programmer how to create local variable in that
language, the answer I got was:

"What is a local variable?"



>>> void main()

>> Illegal.

>
> Why does everyone have this hangup about this? I took a class in C a
> while back and my teacher always used void main() { ... }. I can
> confirm that it works fine with both MicroSoft compiler and BorLand.


LOL, yet another "void main" fan boy to be eaten in c.l.c!

FYI, you haven't written a valid C program yet, and your teacher hasn't
told you about *Standard C*, which is the topic here.

==============================================
----->>> ***READ THE C FAQ*** NOW!!! <<<<-----
......>>> ***READ THE C FAQ*** NOW!!! <<<<.....
......>>> ***READ THE C FAQ*** NOW!!! <<<<.....
----->>> ***READ THE C FAQ*** NOW!!! <<<<-----
==============================================


--
Tor <(E-Mail Removed) | tr i-za-h a-z>
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      12-02-2007
(E-Mail Removed) wrote:

> Johannes Bauer wrote:
>> (E-Mail Removed) schrieb:
>>
>> > int x[256]; // frequencies

>>
>> Global.

>
> It's completely acceptable to have variables defined at file scope in
> C!


Yes, but in most cases it is not good programming practise.
Indiscriminate use of file and program scope objects were among many of
the reasons a lot of programmers abandoned C in favour of "OO"
languages, which discourage such features even more.

You won't feel the need to encapsulate data for small or even midsize
programs, but believe me, if ever you do go on to work on large
systems, your cavalier programming methodology will be instantly
rejected.

>> > void main()

>>
>> Illegal.

>
> Why does everyone have this hangup about this? I took a class in C a
> while back and my teacher always used void main() { ... }. I can
> confirm that it works fine with both MicroSoft compiler and BorLand.


Unfortunately most C programming classes in India are "tool centric",
i.e., they pick an implementation like Turbo C or MSVC and teach
a "dialect" of C that they (the instructors) figured out from their own
half-baked education and their perusal of the documentation for these
compilers. And the documentation usually encourages extensions and
usually fails to provide sufficient warnings about non-standard
constructs.

In the "Real World" C has an internationally accepted Standard, name
ISO/IEC 9899:1999, the latest working draft of which can be downloaded
here:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

The actual Standard is available for a cost from ISO and other national
Standards bodies like BIS:

The Standard is the only contract you can trust between you the
programmer and _any_ implementation that claims conformance to it.
Extensions are almost always a much weaker contract between you and a
specific implementation. They need not be supported by any other
conforming implementation (thus linking your code to a particular
compiler) and even the the implementation that does support it today
could drop support tommorrow.

And void main() is not defined as portable by the Standard.

>> Either you are pretty dumb or you actually do not read ANY of the
>> answers which are given to you. I vote for number one.

>
> I read the answers but mostly people only comment on trivial things
> that aren't even errors! I'll be glad to have substantial comments on
> my code.


Your failure to include the relevent headers and your incorrect use of
the feof() functions _are_ real errors. They may happen to work in a
particular run, but nothing whatsoever can be guaranteed about such
broken code.

<snip>

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-02-2007
CBFalconer wrote:
> James Kuyper wrote:
>> Johannes Bauer wrote:
>> ...
>>> And the comment you used "//" is *not* valid C, it's C++. So this
>>> simple line of code contains lots of mistakes, each and every one
>>> should be avoided in order to create portable code.

>> C standard, 6.4.9p2:
>>
>> "Except within a character constant, a string literal, or a comment,
>> the characters // introduce a comment that includes all multibyte
>> characters up to, but not including, the next new-line character.
>> The contents of such a comment are examined only to identify
>> multibyte characters and to find the terminating new-line character."

>
> That is for C99. C90 doesn't accept it. They are also a grave
> mistake on Usenet, because of line wrapping characteristics.


Since it is supported by the current version of the standard, Johannes
was wrong to claim that it "is *not* valid C".

I'm don't care about the fact that C90 doesn't accept it. And I only
consider them "a grave mistake on usenet", if they occur on a line long
enough for line wrapping to be a problem. That wasn't true in this case.
It will have to indented many times before it wraps.
 
Reply With Quote
 
rajash@thisisnotmyrealemail.com
Guest
Posts: n/a
 
      12-02-2007
James Kuyper wrote:
> (E-Mail Removed) wrote:
> > Johannes Bauer wrote:
> >> (E-Mail Removed) schrieb:
> >>
> >>> int x[256]; // frequencies
> >> Global.

> >
> > It's completely acceptable to have variables defined at file scope in
> > C!

>
> What's acceptable is not always a good idea. Global objects have many
> disadvantages; they should be avoided except when necessary; they aren't
> necessary in this case.


In this case they help simplify the code - the array gets initialized
to 0 at compile-time, instead of needing extra code for an
initialization loop bad for efficiency!

>
> > Why does everyone have this hangup about this? I took a class in C a
> > while back and my teacher always used void main() { ... }. I can
> > confirm that it works fine with both MicroSoft compiler and BorLand.

>
> That doesn't make it legal. A conforming implementation of C is allowed
> to reject a program which declares main() that way.


But no "conforming implementation" on Windows rejects it! I don't
believe any C compiler anywhere would reject it.

>
> ...
> > I read the answers but mostly people only comment on trivial things
> > that aren't even errors! I'll be glad to have substantial comments on
> > my code.

>
> Several of the "trivial" things people have commented on ARE errors, and
> serious ones - you don't seem to understand how serious. Most
> importantly, #inclusion of the appropriate standard headers is
> absolutely essential for your code to even compile, at least under most
> implentations of C. If what you've given us is the complete text of your
> program, and if you are using a compiler which accepts your code as
> written, junk it - it's teaching you some very bad habits.


OK you're right I should remember that. However I don't think it's the
end of the world - the standard library is always linked in so the
right functions will be found in the end by the linker.

>
> Also, you're using feof() incorrectly, and until you understand why the
> way that you're using it is incorrect, I would not recommend relying
> upon any of your programs to function properly.


I don't really understand the problem with feof - it just checks if
the EOF indicator is set in a given FILE * struct. Anyway I'll read
about it.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      12-02-2007
(E-Mail Removed) wrote:

> James Kuyper wrote:
>> (E-Mail Removed) wrote:
>> > Johannes Bauer wrote:
>> >> (E-Mail Removed) schrieb:
>> >>
>> >>> int x[256]; // frequencies
>> >> Global.
>> >
>> > It's completely acceptable to have variables defined at file scope
>> > in C!

>>
>> What's acceptable is not always a good idea. Global objects have many
>> disadvantages; they should be avoided except when necessary; they
>> aren't necessary in this case.

>
> In this case they help simplify the code - the array gets initialized
> to 0 at compile-time, instead of needing extra code for an
> initialization loop bad for efficiency!


This is an especially poor argument for justifying file scope objects.

>> > Why does everyone have this hangup about this? I took a class in C
>> > a while back and my teacher always used void main() { ... }. I can
>> > confirm that it works fine with both MicroSoft compiler and
>> > BorLand.

>>
>> That doesn't make it legal. A conforming implementation of C is
>> allowed to reject a program which declares main() that way.

>
> But no "conforming implementation" on Windows rejects it! I don't
> believe any C compiler anywhere would reject it.


Did you see the post by "Chad" were his conforming compiler refused to
compile your code?

>> > I read the answers but mostly people only comment on trivial things
>> > that aren't even errors! I'll be glad to have substantial comments
>> > on my code.

>>
>> Several of the "trivial" things people have commented on ARE errors,
>> and serious ones - you don't seem to understand how serious. Most
>> importantly, #inclusion of the appropriate standard headers is
>> absolutely essential for your code to even compile, at least under
>> most implentations of C. If what you've given us is the complete text
>> of your program, and if you are using a compiler which accepts your
>> code as written, junk it - it's teaching you some very bad habits.

>
> OK you're right I should remember that. However I don't think it's the
> end of the world - the standard library is always linked in so the
> right functions will be found in the end by the linker.


Please read the thread titled "Question regarding malloc casing" where
it is made clear that not including a prototype in scope for Standard
library functions is simply begging to invoke undefined behaviour.

In short the compiler generates correct function call and return code at
the machine level based on the function signature. Providing the wrong
signature (which is what happens when you fail to prototype the
function), leads the compiler to generate _wrong_ function call and
return code at the machine level, which will likely cause subtle errors
and data corruption.

>> Also, you're using feof() incorrectly, and until you understand why
>> the way that you're using it is incorrect, I would not recommend
>> relying upon any of your programs to function properly.

>
> I don't really understand the problem with feof - it just checks if
> the EOF indicator is set in a given FILE * struct. Anyway I'll read
> about it.


No. In C you must first try to read from a stream using an I/O function
like getc() etc. When the function returns an EOF or an error return,
only then is it meaningful to check whether the actual cause for the
failure is an end-of-file condition (feof(s) returns true), or some
other unspecified error (ferror(s) returns true).

Please read the FAQ. It will help you avoid making many silly mistakes
and assumptions.

<http://www.c-faq.com/>

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-02-2007
santosh wrote:
> (E-Mail Removed) wrote:
>
>> James Kuyper wrote:
>>> (E-Mail Removed) wrote:
>>>> Johannes Bauer wrote:

....
>>>> Why does everyone have this hangup about this? I took a class in C
>>>> a while back and my teacher always used void main() { ... }. I can
>>>> confirm that it works fine with both MicroSoft compiler and
>>>> BorLand.
>>> That doesn't make it legal. A conforming implementation of C is
>>> allowed to reject a program which declares main() that way.

>> But no "conforming implementation" on Windows rejects it! I don't
>> believe any C compiler anywhere would reject it.

>
> Did you see the post by "Chad" were his conforming compiler refused to
> compile your code?


To be fair, the fact that main() was declared as void was not the reason
why Chad's compiler refused the code. Chad was using gcc, and my copy of
gcc accepts void main, unless I choose an option like -pedantic-errors.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-02-2007
(E-Mail Removed) wrote:
> James Kuyper wrote:
>> (E-Mail Removed) wrote:
>>> Johannes Bauer wrote:
>>>> (E-Mail Removed) schrieb:
>>>>
>>>>> int x[256]; // frequencies
>>>> Global.
>>> It's completely acceptable to have variables defined at file scope in
>>> C!

>> What's acceptable is not always a good idea. Global objects have many
>> disadvantages; they should be avoided except when necessary; they aren't
>> necessary in this case.

>
> In this case they help simplify the code - the array gets initialized
> to 0 at compile-time, instead of needing extra code for an
> initialization loop bad for efficiency!


You can zero initialize automatic variables, too:

int x[256] = {0};

The speed difference between initialization during program startup vs.
after program startup isn't normally large enough to justify worrying
about. The difference in the maintainability of a program that uses
global variables and one that keeps variable as local as possible is far
more important.

>>> Why does everyone have this hangup about this? I took a class in C a
>>> while back and my teacher always used void main() { ... }. I can
>>> confirm that it works fine with both MicroSoft compiler and BorLand.

>> That doesn't make it legal. A conforming implementation of C is allowed
>> to reject a program which declares main() that way.

>
> But no "conforming implementation" on Windows rejects it! I don't
> believe any C compiler anywhere would reject it.


I believe that gcc is available for Windows, and is conforming to the
C90 standard with the right options turned on, and conforms fairly well
with C99 with different options turned on. If, in addition, you turn on
the -pedantic-errors option, it rejects "void main()".

....
> OK you're right I should remember that. However I don't think it's the
> end of the world - the standard library is always linked in so the
> right functions will be found in the end by the linker.


That's not true, in general. On most systems I've used, the part of the
standard library which is described in math.h is NOT always linked in;
you have to explicitly add the linker option -lm to link in the math
library. More esoterically, if you want to link C modules to a main
program written in Fortran (something I haven't had to do, but people I
work with do this all the time), the compiler will not automatically
tell the linker where to find the C libraries; you have to do that
explicitly yourself.

However, I wasn't talking about linking. I was talking about
compilation. In general, your code won't compile correctly without the
declarations that come from the appropriate standard library headers.
Those declarations are needed for the compiler to generate the correct
code for linking to the corresponding standard library functions. You
might have some "lucky" accidents with a particular compiler where
defective code appears to behave as you intended it to, but that same
code will not compile correctly under other implementations of C.

>> Also, you're using feof() incorrectly, and until you understand why the
>> way that you're using it is incorrect, I would not recommend relying
>> upon any of your programs to function properly.

>
> I don't really understand the problem with feof - it just checks if
> the EOF indicator is set in a given FILE * struct. Anyway I'll read
> about it.


Yes, do. The key point is that the EOF indicator is cleared when you
open the file; it's pointless to check it until you've started reading
the file. You should always check the return values from the functions
which read a file; if they indicate a failure, the requested data was
not actually read, and you shouldn't attempt to process it. If you've
already checked for failure from the reading functions, the only time
you actually need to use either feof() or ferror() is after you've had a
failure indication.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
D80 histogram vs histogram on computer Martin Sørensen Digital Photography 14 12-19-2007 09:41 PM
numpy: frequencies robert Python 2 11-18-2006 05:41 PM
Arbitrary Clock Frequencies From Base Clock abhisheknag@gmail.com VHDL 5 06-23-2006 12:45 PM
B vs G: Frequencies Used? (PeteCresswell) Wireless Networking 2 01-01-2006 08:16 PM
Cordless keyboard mouse frequencies Melv Computer Support 7 11-29-2003 03:34 AM



Advertisments