Looking for a C textbook with emphasis on data types

I

ilya2

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*. Or 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?
 
R

Richard Heathfield

(e-mail address removed) said:

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,

Why? That has nothing to do with C.
binary and hexadecimal. For example, it must clear to them why number
353 is actually stored as 0x01 0x61 if it's and INT,

There is no INT type in C. 353 might be stored as 0x0161, but it might be
stored as 0x6101, 0x00006101 (i.e. in 4 octets), or as 0x61010000 (little
endian, four octets to the int), or in any of a zillion other ways.
but 0x33 0x35 0x33 if it's a CHAR*.

C has no CHAR type. To store the characters '3', '5', and '3', you need
three bytes of storage. A pointer to the first of these characters will
/not/ have the value 0x333533 (unless by some astounding coincidence).
Or why converting a numeric CHAR into an INT involves
subtracting 48 --

It doesn't. If you mean turning '4' into 4 or '6' into 6, it involves
subtracting '0', not 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?

Oh my word. Please, please, please don't write your own, until you
understand what you're talking about.
 
A

arun

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 * ??
Or 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?

Ooops...
No please,,, for god's sake.

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

ilya2

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.
 
R

Richard Heathfield

(e-mail address removed) said:
48 is decimal value of '0'.

The C Standard does not guarantee this, and it is certainly not true on some
systems where C is used.
 
A

Andrew Poelstra

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

The size of a monitor is 17 inches. In hexadecimal it is 0x11.


Weird how it looks to others when you assume that everyone is using your
environment, huh.
I know that. I was bringing up an example of a mistake someone
unfamiliar with hexadecimal may make.

If you are so unfamiliar with hexadecimal that you don't know what 0x
means, you shouldn't be learning programming languages, and if your
students do not know what 0x means, you shouldn't teach them anything
else before that.
 
J

Jalapeno

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

Oddly 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.)
 
D

Dann Corbit

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*. Or 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:
"INTERNATIONAL STANDARD ©ISO/IEC ISO/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.
 
K

Keith Thompson

Andrew Poelstra said:
If you are so unfamiliar with hexadecimal that you don't know what 0x
means, you shouldn't be learning programming languages, and if your
students do not know what 0x means, you shouldn't teach them anything
else before that.

The use of a 0x prefix to denote hexadecimal is just syntax, and it's
specific to C (and to languages that borrowed from it). Other
languages use different syntax. It's entirely possible to have a
thorough understanding of hexadecimal without knowing about 0x.

Certainly any C programmer needs to know what 0x means, but it
shouldn't take more than a moment to learn it.
 
I

ilya2

The reference document you seek is called:
"INTERNATIONAL STANDARD ©ISO/IEC ISO/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.

Oversimplifications, 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.
 
D

Dann Corbit

The reference document you seek is called:
"INTERNATIONAL STANDARD ©ISO/IEC ISO/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.

Oversimplifications, 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 Odd Couple", it was a court case where Oscar
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 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 OK [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.
 
A

Andrew Poelstra

Oversimplifications, 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.

Similar to someone's "compiler for nonprogrammers" question, I have to
wonder why you'd have to teach calculus to non-science (by which I
assume you also mean non-math) students.

The basis of C is that you can write a program and it will work on a
SNES, a Commodore 64, and a robotic dragon from the future. It's a
fair bit more important than you'd think to show students how different
systems work, and how to make your code function no matter what the
architecture.

Endianness is vital, as is differently sized primitive types. Charsets
were becoming less important, but now we've got internationalization
and once again it's important that you aren't depending on ASCII.
 
K

Keith Thompson

Oversimplifications, 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.

As long as you know that '0' is '0', you don't need to know or care
that it happens to be 0x30 on your system. If you have an expression
of type char, and you know that its value is in the range '0' to '9',
you can get the integer value of that digit by subtracting '0':

char c = '5';
int n = c - '0';
/* n == 5 */

This is guaranteed to work because the standard requires the digit
characters '0' to '9' to have contiguous representations (it doesn't
make the same guarantee for letters).

Now, given that this is simpler, easier to remember, and more
portable, why should I care that '0' == 0x30 on some but not all
systems?
 
M

Malcolm

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


I know that. I was bringing up an example of a mistake someone
unfamiliar with hexadecimal may make.
Students do need to know that all variables in the computer are ultimately
binary, and that hexadecimal notation is a convenient way of making binary
numbers readable to humans, but nothing more.
They also need to know that ASCII is just an arbitrary set of mappings from
integers to English-language characters.

I would hope that these things are not presented as deep problems. They are
just a few basic facts you need to know before you start serious C
programming.

Data structures. on the other hand, are interesting, because different
structures have different characteristics. Some structures can be updated
very easily, others only with expensive operations. Some are easy to search,
others very slow. Some are easy to implement, others very tricky.
 
E

Eric Sosman

Andrew Poelstra wrote On 07/14/06 15:30,:
[...]
The basis of C is that you can write a program and it will work on a
SNES, a Commodore 64, and a robotic dragon from the future. [...]

If you invoke U.B. on a robotic dragon, you'll
be *really* sorry about the ensuing nasal demons ...
 
A

Al Balmer

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

I'm not sure what you taught them, but it wasn't calculus.
 
R

Richard Bos

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*. Or 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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,581
Members
45,056
Latest member
GlycogenSupporthealth

Latest Threads

Top