I am supposed to teach an introductory C course with an unusual slant,
and have trouble finding an appropriate textbook. The course will begin
traditionally enough with variables, loops, conditionals, structures,
pointers and fopen/fclose. Beyond that, however, every course and
textbook I had seen is heavy on data *structures*, and touches on other
topics lightly if at all. Whereas I need to stress data *types*,
converting them one into the other, and bit manipulation. By the end of
the course I do not care if my students know what a linked list is, let
alone a binary tree, but they must have good understanding of ASCII,
binary and hexadecimal. For example, it must clear to them why number
353 is actually stored as 0x01 0x61 if it's and INT, but 0x33 0x35 0x33
if it's a CHAR*. why converting a numeric CHAR into an INT involves
subtracting 48 -- and not 30, as previous example might suggest.
Is there a textbook with such emphasis on data types, bits, and
hexadecimal, or am I doomed to writing my own?

ilya2@rcn.com wrote:
I am supposed to teach an introductory C course with an unusual slant,
and have trouble finding an appropriate textbook. The course will begin
traditionally enough with variables, loops, conditionals, structures,
pointers and fopen/fclose. Beyond that, however, every course and
textbook I had seen is heavy on data *structures*, and touches on other
topics lightly if at all.

Are you talking about any C book or some data structures book ?

>Whereas I need to stress data *types*,

Is it required ?

converting them one into the other, and bit manipulation. By the end of
the course I do not care if my students know what a linked list is, let
alone a binary tree, but they must have good understanding of ASCII,
binary and hexadecimal.

Which of these is 'C' ?

>For example, it must clear to them why number
353 is actually stored as 0x01 0x61 if it's and INT,

Is it ? its NEWS. What if you are using a machine with little endian
byte ordering ?

>but 0x33 0x35 0x33
if it's a CHAR*.

How can number 353 be char * ?

why converting a numeric CHAR into an INT involves
subtracting 48 -- and not 30, as previous example might suggest.

Who told you to subtract 30 ?
You have to subtract ' 0'. And you would have missed ' 0x' while you
were reading.
It should have been 0x30.

Is there a textbook with such emphasis on data types, bits, and
hexadecimal, or am I doomed to writing my own?

No please,,, for god's sake.

Go and read " the holy book" , The C programming language, by K & R.

"arun" writes:

>Is there a textbook with such emphasis on data types, bits, and
>hexadecimal, or am I doomed to writing my own?
>
No please,,, for god's sake.
Think of the children!!!

>but 0x33 0x35 0x33
if it's a CHAR*.
How can number 353 be char * ?
If it's a character string "353"

why converting a numeric CHAR into an INT involves
subtracting 48 -- and not 30, as previous example might suggest.

Who told you to subtract 30 ?
You have to subtract ' 0'.

48 is decimal value of '0'. In hexadecimal it is 0x30

And you would have missed ' 0x' while you
were reading.
It should have been 0x30.

I know that. I was bringing up an example of a mistake someone
unfamiliar with hexadecimal may make.

ilya2@rcn.com wrote:
why converting a numeric CHAR into an INT involves
subtracting 48 -- and not 30, as previous example might suggest.

Who told you to subtract 30 ?
You have to subtract ' 0'.

48 is decimal value of '0'. In hexadecimal it is 0x30

enough, the hexadecimal value of '0' on every one of my systems
is F0.

I guess I should enroll in your class so I can learn C properly.

(gosh, subtracting 48, wow, I am so glad my boss never gave me that
assignment because I foolishly would have subtracted 240. Maybe that's
why I was never given the assignment to convert a numeric CHAR into an
INT.)

<ilya2@rcn.comwrote in message
news:1152880370.521123.261840@
>I am supposed to teach an introductory C course with an unusual slant,
and have trouble finding an appropriate textbook. The course will begin
traditionally enough with variables, loops, conditionals, structures,
pointers and fopen/fclose. Beyond that, however, every course and
textbook I had seen is heavy on data *structures*, and touches on other
topics lightly if at all. Whereas I need to stress data *types*,
converting them one into the other, and bit manipulation. By the end of
the course I do not care if my students know what a linked list is, let
alone a binary tree, but they must have good understanding of ASCII,
binary and hexadecimal. For example, it must clear to them why number
353 is actually stored as 0x01 0x61 if it's and INT, but 0x33 0x35 0x33
if it's a CHAR*. why converting a numeric CHAR into an INT involves
subtracting 48 -- and not 30, as previous example might suggest.

Is there a textbook with such emphasis on data types, bits, and
hexadecimal, or am I doomed to writing my own?

The reference document you seek is called:
"INTERNATINAL STANDARD IS/IEC IS/IEC 9899:1999 (E)
Programming languages - C"

and it costs $30 or so in PDF format. Its fairly expensive in printed form,
but you can probably run off a copy at Kinkos for a moderate price.

The section you are interested in is:
6. Language

With special ephasis on 6.5 Expressons and 6.7 Declarations

I should mention that most of your comments above are utter nonsense.

Things like ASCII/EBCDIC and big/little endian issues can easily be made
language neutral if you know what you are doing.

Additional reading:
_The C Programming Language_, by Kernighan and Ritchie, 2nd Edition
_C Programming FAQs: Frequently Asked Questions_, by Steve Summit

There is a book that is a bit of overkill for what you are trying to cover,
but which may prove helpful in developing your course outline.

_C Unleashed_ by Richard Heathfield, Lawrence Kirby has a chapter (5)
called "Playing with Bits and Bytes" which should be useful for developing
your course outline.

The reference document you seek is called:
"INTERNATINAL STANDARD IS/IEC IS/IEC 9899:1999 (E)
Programming languages - C"

and it costs $30 or so in PDF format. Its fairly expensive in printed form,
but you can probably run off a copy at Kinkos for a moderate price.

The section you are interested in is:
6. Language

With special ephasis on 6.5 Expressons and 6.7 Declarations

Thank you. I will look into it.

I should mention that most of your comments above are utter nonsense.

, sure. As long as one works on a system where '0'
is 0x30, it is not really necessary to know that on some other system
it can be something else. For that matter, when I taught calculus to
non-science students, I just trashed the whole complex and fiddling
limit theory, and told them that division by zero gives infinity. Not
something I would do to math or physics students, but it worked in the
context. Brickbats welcome.

<ilya2@rcn.comwrote in message
news:1152904575.421861.307100@35g2000cwc.googlegro ups.com
The reference document you seek is called:
"INTERNATINAL STANDARD IS/IEC IS/IEC 9899:1999 (E)
Programming languages - C"

and it costs $30 or so in PDF format. Its fairly expensive in printed
form,
but you can probably run off a copy at Kinkos for a moderate price.

The section you are interested in is:
6. Language

With special ephasis on 6.5 Expressons and 6.7 Declarations

Thank you. I will look into it.

I should mention that most of your comments above are utter nonsense.

, sure. As long as one works on a system where '0'
is 0x30, it is not really necessary to know that on some other system
it can be something else. For that matter, when I taught calculus to
non-science students, I just trashed the whole complex and fiddling
limit theory, and told them that division by zero gives infinity. Not
something I would do to math or physics students, but it worked in the
context. Brickbats welcome.

Teaching {for instance} to make '9' into a 9 by subtracting 48 is simply
wrong.
Right this minute, I am doing a build of a middleware product for IBM
mainframes. That C expression produces the wrong answer on that machine.

'9' - '0' produces the right decimal digit.
'9' - 48 does not produce the right decimal digit.

I remember something from "The Couple", it was a court case where
Madison was the defendent and Felix Unger was defending him. Felix made an
interesting observation about the word 'assume'.

By dissecting the word, he came up with this:
'When you assume you make and [ass] out of [u] and [me].'

When you make unwarranted assumptions about what low level formats underly
data objects, you can get into a world of trouble. As you can see (from the
example above), the correct expression works just as well and is no more
complicated than the one that uses the unwarranted assumption.

Now, you can manipulate bits and bytes according to the formal definition of
the language itself, and you can be guaranteed of results, as the standard
itself defines how things ought to operate. But when you start to make
assumptions that are sometimes true, then eventually, you will get bonked by
it.

There are not a lot of one's complement machines around, so things like:
x&1 (Assumes 2's complement)
verses:
x%2 (works everywhere)
to test for odd numbers are probably K [most of the time]. But in your
ASCII example, there is a very significant portion of the world's data
stored on IBM mainframe machines.

A big focus of this newsgroup is aimed at portable code. Since I program
for literally dozens of different hardware platforms continuously, it is
very valuable for me to have this focus. And to aim for a formal standard
to have guarantees about how things are supposed to work is a very good
engineering practice in general.

ilya2@rcn.com wrote:

I am supposed to teach an introductory C course with an unusual slant,
and have trouble finding an appropriate textbook. The course will begin
traditionally enough with variables, loops, conditionals, structures,
pointers and fopen/fclose. Beyond that, however, every course and
textbook I had seen is heavy on data *structures*, and touches on other
topics lightly if at all. Whereas I need to stress data *types*,
converting them one into the other, and bit manipulation. By the end of
the course I do not care if my students know what a linked list is, let
alone a binary tree, but they must have good understanding of ASCII,
binary and hexadecimal. For example, it must clear to them why number
353 is actually stored as 0x01 0x61 if it's and INT, but 0x33 0x35 0x33
if it's a CHAR*. why converting a numeric CHAR into an INT involves
subtracting 48 -- and not 30, as previous example might suggest.

To any student of ilya2:

Run away. Now. Don't look back.

Now go find a teacher who knows more than sweet Fanny Adams about the
subject he's teaching, 'cause that one didn't.

Richard

"Dann Corbit" <dcorbit@connx.comwrote:

<ilya2@rcn.comwrote in message
news:1152880370.521123.261840@
Is there a textbook with such emphasis on data types, bits, and
hexadecimal, or am I doomed to writing my own?

The reference document you seek is called:
"INTERNATINAL STANDARD IS/IEC IS/IEC 9899:1999 (E)
Programming languages - C"

and it costs $30 or so in PDF format. Its fairly expensive in printed form,

<is
about $60, and has TC1. than that, n1124.pdf is TTBMK still free,
and includes both TCs, but is a public draft.

Richard