print alphabet

[Bill Cunningham]

I have seen code used like this before but my code won't compile.
I want to print the letters a-z but this doesn't work. Should I be
using enum?

B

#include <stdio.h>

int main()
{
char alpha[a - z];
int i;
for (i = 0; i < 27; i++) {
printf("%c\n", d);
return 0;
}
return 0;
}

Why don't you try to do one thing at a time? Your mention of enum
sounds to me like you think there is a better way of writing the
code, if you just knew what that way was. So my suggestion is,
decide whether to:
o - fix the code you posted
o - write a new program to print the alphabet, perhaps using enum.

Fiddling with two problems at once is very confusing.

[snip]

Tell me about it.

Bill

 

[Ian Collins]

Fiddling with two problems at once is very confusing.

[snip]

Tell me about it.

You should tell us. You are the expert after all.

 

[Nick Keighley]

osmium wrote:

Why don't you try to do one thing at a time?  Your mention of enum
sounds to me like you think there is a better way of writing the
code, if you just knew what that way was.  So my suggestion is,
decide whether to:
o - fix the code you posted
o - write a new program to print the alphabet, perhaps using enum.

Fiddling with two problems at once is very confusing.

[snip]

Tell me about it.

so why do you keep on doing it?

 

[Bill Cunningham]

or

#include <stdio.h>
int main(void) {
for(int i = 'a'; i <= 'z' && putchar(i); i++);
putchar('\n');
return 0;
}

I thought I could somehow use that a-z. So I don't want a char but an
int. This looks like the closest thing to what I am wanting. I'll try it.
Thanks

Bill

 

[osmium]

I thought I could somehow use that a-z. So I don't want a char but an
int. This looks like the closest thing to what I am wanting. I'll try it.

First of all neither a nor z are characters. 'a' and 'z' are characters.

Second of all, you are not permitted to use a hyphen to indicate
"inclusive". That is something that is common in the *English* language;
the rules for the *C* language are different.

And quite rigorous as well as you are finding out.

 

[Denis McMahon]

#include <stdio.h>

int main()
{
char alpha[a - z];
int i;
for (i = 0; i < 27; i++) {
printf("%c\n", d);
return 0;
}
return 0;
}

what type is d and where is it (a) declared and (b) defined?

The following seems to work:

/************** start **************/
#include <stdio.h>

int main()
{
int i;
for(i=0;i<26;i++)printf("%c\n",'a'+i);
return 0;
}
/*************** end ***************/

Rgds

Denis McMahon

 

[Tom St Denis]

On 8/7/2010 2:37 PM, Vincenzo Mercuri wrote:
[...]

#include <stdio.h>
int main(void) {
for(int i = 'a'; i <= 'z' && putchar(i); i++);
putchar('\n');
return 0;
}

That only works in characters sets where the letters 'a' through 'z' are
contiguous.  As I recall, letters in EBCDIC are not contiguous.

Things I've never personally witnessed:

1. Easter Bunny
2. Peace in my time
3. A machine that uses EBCDIC.

Tom

 

[Seebs]

Things I've never personally witnessed:

1. Easter Bunny

I have!

.... Well.

Okay, I saw a sorta scruffy guy missing a few teeth who smelled of booze
in a bright pink bunny suit, handing out candy. On Easter.

.... And come to think of it, I think I once saw a picture of a rabbit
humping a chicken.

So I think on average I've seen the Easter Bunny.

-s

 

[osmium]

Things I've never personally witnessed:

3. A machine that uses EBCDIC.

That's a reason to use this newsgroup to learn C only as a last resort. The
advise and commentary is a mixture of down to earth stuff and obscure stuff
(such as this) that only a very few people (language lawyers for example)
know or care about. Bill has no way to tell them apart.

It's kind of like learning first grade English from a rotating panel of
teachers, some of whom are frustrated linguists. How can you demonstrate
how smart you are to a first grader?

 

[Seebs]

That's a reason to use this newsgroup to learn C only as a last resort. The
advise and commentary is a mixture of down to earth stuff and obscure stuff
(such as this) that only a very few people (language lawyers for example)
know or care about. Bill has no way to tell them apart.

I don't see how the character set thing is all that arcane. In particular,
I should point out: It's fairly obvious that, for a couple billion real-world
use cases, the a..z range is NOT the whole set of lower case letters, and the
others aren't adjacent to them...

-s

 

[Ben Bacarisse]

1. Easter Bunny

How would I know?

2. Peace in my time
Nope.

3. A machine that uses EBCDIC.

Lots. All a long time ago (though I think they still exist). I've used
even odder character sets like 6-bit encodings and I use even odder ones
now (Unicode).

The point of this is not to say to how old I am, but to plead the case
for accepting a broader view than what is currently commonplace. The
idea of iterating though the alphabet by incrementing a code did not
make any sense at one time, and it does not make much sense now[1]. The
fact that there was a brief moment in history when (a) the most common
code had consecutive letters and (b) the US/UK Latin alphabet[2] was all
that mattered to computer folk should not limit our programming of
textual programs.

Of course, we have no idea what the point of the code was. If the
intent was to see what gets printed for every int value between 'a' and
'z' then the program was absolutely fine.

[1] Many Unicode alphabets have gaps or unexpected numberings.

[2] I know it's more than US and UK but I needed a shorthand. You can't
print the alphabet that Spanish children are taught by iterating from
ASCII 'a' to ASCII 'z'.

 

[Barry Schwarz]

On 8/7/2010 2:37 PM, Vincenzo Mercuri wrote:
[...]

#include <stdio.h>
int main(void) {
for(int i = 'a'; i <= 'z' && putchar(i); i++);
putchar('\n');
return 0;
}

That only works in characters sets where the letters 'a' through 'z' are
contiguous.  As I recall, letters in EBCDIC are not contiguous.

Things I've never personally witnessed:

1. Easter Bunny
2. Peace in my time
3. A machine that uses EBCDIC.

I guess you never use an ATM. What do you think is on the other end of
its comm link?

 

[Barry Schwarz]

I have seen code used like this before but my code won't compile. I want
to
print the letters a-z but this doesn't work. Should I be using enum?

B

#include <stdio.h>

int main()

i would use
int main(void)

{
char alpha[a - z];

there is not varible a not z
could do 'z'-'a'
but why use it?

i would have to write
'z'-'a'+4

What is the significance of the magic number 4?

 

[Nick Keighley]

from the original post:
char alpha[a - z];

    I thought I could somehow use that a-z.

why? What book, magazine, tea leaf reading or web site give you the
slightest hint this was possible in the C language? Did you get a
syntax error for this constuct? What did it say? Why did you ignore
it?

 

[Nick Keighley]

Tom St Denis <[email protected]> writes:

<snip>

[stuff he's never seen]

Lots.  All a long time ago (though I think they still exist).  I've used
even odder character sets like 6-bit encodings and I use even odder ones
now (Unicode).

Baudot. 5 unit! with letter shift and figure shift!

[ yes I have written C programs, for money, that processed baudot
data ]

<snip>

 

[Ian Collins]

from the original post:
char alpha[a - z];

I thought I could somehow use that a-z.

why? What book, magazine, tea leaf reading or web site give you the
slightest hint this was possible in the C language? Did you get a
syntax error for this constuct? What did it say? Why did you ignore
it?

There be trolls in these parts.

 

[Malcolm McLean]

 The
fact that there was a brief moment in history when (a) the most common
code had consecutive letters and (b) the US/UK Latin alphabet[2] was all
that mattered to computer folk should not limit our programming of
textual programs.

ASCII has been a great success.

Of course non-English speakers often want special characters. The
problem is there are too many of them (characters, not non-English
speakers).

For a lot of applications, you need to be able to knock up a font
quickly. 256 character set fonts are doable by a single person in
areasonable amount of time, and take only a reasonable amount of
memory for the table. Go to 1024 characters and producing the font
starts to be a serious problem, storing it is also often a problem.
There's also the keyboard issue. English letters can be entered on any
keyboard, foreign letters only on special keyboards of with clumsy
interfaces.

So in fact C scripts, html, and so on is built on ascii. If you want a
Greek charater you tye &Alpha; in Ascii.

 

[Bartc]

Lots. All a long time ago (though I think they still exist). I've used
even odder character sets like 6-bit encodings and I use even odder ones
now (Unicode).

I thought Unicode used ASCII (character codes 32 thru 127 at least). (And
the 'sixbit' I once used was just ASCII 32 to 95, offset to start at 0.)

EBCDIC should be put painlessly to sleep... It was a terrible encoding. The
A-Z range is ubiquitous and deserves a concise, consecutive encoding.

The whole of Unicode is a nightmare to deal with (for example, the exact
same glyph having dozens of character codes), and it's nice to have one sane
corner of it where things are kept simple.

[2] I know it's more than US and UK but I needed a shorthand. You can't
print the alphabet that Spanish children are taught by iterating from
ASCII 'a' to ASCII 'z'.

And the Italian alphabet had just 21 letters at one time. Now with foreign
words and www, everyone will recognise the same 26 letters we use in
English. (Although I understand in Spanish things like ñ and ll might be
letters in their own right.)

 

[Malcolm McLean]

And the Italian alphabet had just 21 letters at one time. Now with foreign
words and www, everyone will recognise the same 26 letters we use in
English. (Although I understand in Spanish things like ñ and ll might be
letters in their own right.)

There are all sorts of problems. For instance in Hebrew a mem (M)
looks different if it is at the end of a word. But it's still thought
of as the same letter. Also, if you want to show the vowels, they are
traditionally written below the consonants. The dagesh (hard symbol)
is weitten as a dot within the letter it qualifies.

 

[Ben Bacarisse]

 The
fact that there was a brief moment in history when (a) the most common
code had consecutive letters and (b) the US/UK Latin alphabet[2] was all
that mattered to computer folk should not limit our programming of
textual programs.

ASCII has been a great success.

True, but not relevant. It's success was brief.

Of course non-English speakers often want special characters. The
problem is there are too many of them (characters, not non-English
speakers).

You missed the point. Maybe I should not have put it in a footnote.
What constitutes an alphabet is disconnected from the character codes.
A program to list the letters of the Spanish alphabet can work in ASCII
but not by counting codes because "ll" is a separate letter.

For a lot of applications, you need to be able to knock up a font
quickly. 256 character set fonts are doable by a single person in
areasonable amount of time, and take only a reasonable amount of
memory for the table. Go to 1024 characters and producing the font
starts to be a serious problem, storing it is also often a problem.

I am not denying that may be reasons to limit the character sets a
particular program supports.

There's also the keyboard issue. English letters can be entered on any
keyboard, foreign letters only on special keyboards of with clumsy
interfaces.

There is nothing complicated or clumsy about typing ll. German
keyboards have no trouble with ß (neither does mine for that matter but
I know its simpler with a German keyboard).

So in fact C scripts, html, and so on is built on ascii. If you want a
Greek charater you tye &Alpha; in Ascii.

I don't want to start an off-topic argument but you are simply wrong
about HTML. The document character set is Unicode and the transfer
encoding is specified by the protocol header and can be anyone of over
250 character sets accepted by the IANA. They include various EBCDIC
flavours.

The on-topic point about C is also not correct. The source character
set is chosen to contain only those characters that are common to
several character sets (ASCII included) but it excludes some ASCII
characters quite deliberately and it certainly does not mandate ASCII as
the encoding. I've written source code in EBCDIC on numerous occasions.