C examples and codes

John Bode wrote:

99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;

99% of people posting in Usenet say crap, and should be avoided like the
plague.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 12 '07 #5

Jalapeno

On Oct 12, 10:47 am, jacob navia <ja...@nospam.orgwrote:

John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;

99% of people posting in Usenet say crap, and should be avoided like the
plague.

99% of all statistics in Usenet are made up.

Oct 12 '07 #6

jacob navia wrote:

John Bode wrote:
>99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;

99% of people posting in Usenet say crap, and should be avoided like the
plague.

But on Usenet, there's always someone watching with a copy of the
standard to hand. If there's crap, it's pointed out.

--
Philip Potter pgp <atdoc.ic.ac.uk

Oct 12 '07 #7

John Bode

On Oct 12, 9:47 am, jacob navia <ja...@nospam.orgwrote:

John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;

99% of people posting in Usenet say crap, and should be avoided like the
plague.

Are you saying I'm wrong? I've yet to see a C tutorial on the Web
that didn't have fundamental mistakes.

Oct 12 '07 #8

Jalapeno wrote:

On Oct 12, 10:47 am, jacob navia <ja...@nospam.orgwrote:
>John Bode wrote:
>>99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;
99% of people posting in Usenet say crap, and should be avoided like the
plague.

99% of all statistics in Usenet are made up.

Of course!

What bothers me is that before his message
I sent a message about my tutorial,
that has taken me years of work.

Before making such sweeping statements, Mr Bode could (maybe)
try to see the tutorials that aren't crap...

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 12 '07 #9

John Bode wrote:

On Oct 12, 9:47 am, jacob navia <ja...@nospam.orgwrote:
>John Bode wrote:
>>99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;
99% of people posting in Usenet say crap, and should be avoided like the
plague.

Are you saying I'm wrong? I've yet to see a C tutorial on the Web
that didn't have fundamental mistakes.

I sent a message (in this same thread) about the tutorial of
lcc-win, available from the web.

I thought you were referring to mine, so maybe I overreacted.

Give it a try. It is not perfect, as anything done by a
human, but it is not just crap.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 12 '07 #10

Richard Heathfield

John Bode said:

On Oct 12, 9:47 am, jacob navia <ja...@nospam.orgwrote:
>John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;

99% of people posting in Usenet say crap, and should be avoided like the
plague.

Are you saying I'm wrong?

He didn't actually claim that you were wrong. And in fact as far as the 99%
goes, he's probably right - which makes a pleasant change for him, so
let's not spoil his moment of correctness, eh?

I've yet to see a C tutorial on the Web
that didn't have fundamental mistakes.

There are a couple that I know of that are not full of fundamental mistakes
- the Steve Summit one, and the one by Tom Torfs.

Their URLs are:

http://www.eskimo.com/~scs/cclass/
http://cprog.tomsweb.net/cintro.html

although Tom's keeps moving around for some reason. Anyway, those are the
last places I knew about. Whenever I discover that Tom's has moved, I
write down the new URL here:

http://www.cpax.org.uk/prg/portable/...p#WebTutorials

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Oct 12 '07 #11

John Bode

On Oct 12, 10:21 am, jacob navia <ja...@nospam.orgwrote:

John Bode wrote:
On Oct 12, 9:47 am, jacob navia <ja...@nospam.orgwrote:
John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;
99% of people posting in Usenet say crap, and should be avoided like the
plague.

Are you saying I'm wrong? I've yet to see a C tutorial on the Web
that didn't have fundamental mistakes.

I sent a message (in this same thread) about the tutorial of
lcc-win, available from the web.

I thought you were referring to mine, so maybe I overreacted.

Ah. I hadn't seen that message before posting mine. No, I wasn't
referring to yours; I haven't seen it yet. Of the ones I *have* seen,
though, the vast bulk are crap.

Oct 12 '07 #12

jacob navia wrote:

Jalapeno wrote:
>On Oct 12, 10:47 am, jacob navia <ja...@nospam.orgwrote:
>>John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;
99% of people posting in Usenet say crap, and should be avoided like the
plague.

99% of all statistics in Usenet are made up.

Of course!

What bothers me is that before his message
I sent a message about my tutorial,
that has taken me years of work.

Before making such sweeping statements, Mr Bode could (maybe)
try to see the tutorials that aren't crap...

I was curious, so I followed your link. Since you advertised an
introduction to C, I clicked on "C tutorial". I got presented with a
list of adverts for books on amazon -- which presumably make you and
Friedrich Dominicus money -- but no C tutorial.

I found that you're selling a C tutorial in your shop. I'm certainly not
going to pay 30 EUR to review it for you. However I can already see that
it's not entirely a tutorial of standard C because it advertises
"Windows C Programming". Not that there's anything wrong with that, but
it's probably not appropriate to advertise it on this group.

--
Philip Potter pgp <atdoc.ic.ac.uk

Oct 12 '07 #13

Shadowman

Philip Potter wrote:

jacob navia wrote:
>Jalapeno wrote:
>>On Oct 12, 10:47 am, jacob navia <ja...@nospam.orgwrote:
John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;
99% of people posting in Usenet say crap, and should be avoided like
the
plague.
99% of all statistics in Usenet are made up.

Of course!

What bothers me is that before his message
I sent a message about my tutorial,
that has taken me years of work.

Before making such sweeping statements, Mr Bode could (maybe)
try to see the tutorials that aren't crap...

I was curious, so I followed your link. Since you advertised an
introduction to C, I clicked on "C tutorial". I got presented with a
list of adverts for books on amazon -- which presumably make you and
Friedrich Dominicus money -- but no C tutorial.

I found that you're selling a C tutorial in your shop. I'm certainly not
going to pay 30 EUR to review it for you. However I can already see that
it's not entirely a tutorial of standard C because it advertises
"Windows C Programming". Not that there's anything wrong with that, but
it's probably not appropriate to advertise it on this group.

No, it's available for free, although a bit hard-to-find.

From the page advertising the books, you need to click on the "get me
to the downloads" button.

--
SM
rot13 for email

Oct 12 '07 #14

Richard

John Bode <jo*******@my-deja.comwrites:

On Oct 12, 9:47 am, jacob navia <ja...@nospam.orgwrote:
>John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;

99% of people posting in Usenet say crap, and should be avoided like the
plague.

Are you saying I'm wrong? I've yet to see a C tutorial on the Web
that didn't have fundamental mistakes.

I am saying your are wrong.

There are surely some mistakes. But that doesn't make them "crap".

Still, you are are most certainly in the right newsgroup.

Oct 12 '07 #15

Philip Potter wrote:

jacob navia wrote:
>Jalapeno wrote:
>>On Oct 12, 10:47 am, jacob navia <ja...@nospam.orgwrote:
John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;
99% of people posting in Usenet say crap, and should be avoided like
the
plague.
99% of all statistics in Usenet are made up.

Of course!

What bothers me is that before his message
I sent a message about my tutorial,
that has taken me years of work.

Before making such sweeping statements, Mr Bode could (maybe)
try to see the tutorials that aren't crap...

I was curious, so I followed your link. Since you advertised an
introduction to C, I clicked on "C tutorial". I got presented with a
list of adverts for books on amazon -- which presumably make you and
Friedrich Dominicus money -- but no C tutorial.

You have to scroll down and press "take me to the downloads" button.

I found that you're selling a C tutorial in your shop.

This is a hardcopy version, the elec tronic version is free.

I'm certainly not
going to pay 30 EUR to review it for you. However I can already see that
it's not entirely a tutorial of standard C because it advertises
"Windows C Programming". Not that there's anything wrong with that, but
it's probably not appropriate to advertise it on this group.

Look, it is a tutorial for C. Since "Standard C" doesn't RUN anywhere
(you need some specific compiler, some specific operating system,
some way of doing windowed output etc) it is a tutorial of
C in a certain context. The first part is about standard C,
the second about windows, and the third is about network programming.

The first part presents a fairly complete view of the language.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 12 '07 #16

Richard

Philip Potter <pg*@see.sig.invalidwrites:

jacob navia wrote:
>Jalapeno wrote:
>>On Oct 12, 10:47 am, jacob navia <ja...@nospam.orgwrote:
John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;
99% of people posting in Usenet say crap, and should be avoided like the
plague.
99% of all statistics in Usenet are made up.

Of course!

What bothers me is that before his message
I sent a message about my tutorial,
that has taken me years of work.

Before making such sweeping statements, Mr Bode could (maybe)
try to see the tutorials that aren't crap...

I was curious, so I followed your link. Since you advertised an
introduction to C, I clicked on "C tutorial". I got presented with a
list of adverts for books on amazon -- which presumably make you and
Friedrich Dominicus money -- but no C tutorial.

You didn't look hard enough in your desire to have a knock at Jacob once more.

I found that you're selling a C tutorial in your shop. I'm certainly

And giving a free tutorial and compiler.

not going to pay 30 EUR to review it for you. However I can already

He didn't ask you to review it for him. He pointed it out to a nOOb who
wishes to learn C.

Oct 12 '07 #17

rosewater

jacob navia wrote:

Philip Potter wrote:
jacob navia wrote:
Jalapeno wrote:
On Oct 12, 10:47 am, jacob navia <ja...@nospam.orgwrote:
John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;
99% of people posting in Usenet say crap, and should be avoided like
the
plague.
99% of all statistics in Usenet are made up.
Of course!

What bothers me is that before his message
I sent a message about my tutorial,
that has taken me years of work.

Before making such sweeping statements, Mr Bode could (maybe)
try to see the tutorials that aren't crap...
I was curious, so I followed your link. Since you advertised an
introduction to C, I clicked on "C tutorial". I got presented with a
list of adverts for books on amazon -- which presumably make you and
Friedrich Dominicus money -- but no C tutorial.

You have to scroll down and press "take me to the downloads" button.

I found that you're selling a C tutorial in your shop.

This is a hardcopy version, the elec tronic version is free.

I'm certainly not
going to pay 30 EUR to review it for you. However I can already see that
it's not entirely a tutorial of standard C because it advertises
"Windows C Programming". Not that there's anything wrong with that, but
it's probably not appropriate to advertise it on this group.

Look, it is a tutorial for C. Since "Standard C" doesn't RUN anywhere
(you need some specific compiler, some specific operating system,
some way of doing windowed output etc) it is a tutorial of
C in a certain context. The first part is about standard C,
the second about windows, and the third is about network programming.

The first part presents a fairly complete view of the language.

Which language? C or lcc-win32? I think we can all guess how
misleading the name "C tutorial" will be for the sort of garbage that
Navia is wont to produce. Non-portable Windows-specific crap.

Oct 12 '07 #18

Richard Heathfield

jacob navia said:

<snip>

Look, it is a tutorial for C.

Have you fixed the problems yet that we found the last time we looked? All
of them?

If so, I guess it's time to find the next bunch of problems. And if not,
why not?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Oct 12 '07 #19

Richard Heathfield

Philip Potter said:

<lots of navibugs snipped>

This is after a quick skim, I haven't read most of it.

That sounds familiar. (We've been here before. And no doubt we'll come here
again.)

If we perform the "Find Bugs In Navia Tutorial" ritual another few dozen
times at the same frequency as currently, and *if* he takes notice - which
isn't a given - then he should have a tutorial of merchantable quality by
about 2185 or so. Until then, the value of the print version is rather
less than the value of the equivalent amount of blank paper. (Blank paper
is useful, you see.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Oct 12 '07 #20

Tor Rustad

Tsb wrote:

I have read about learning C programming language. Lots of them said
the best way to learn C is reading codes.

So where can I find codes and some examples?

Some C books comes with source code, e.g.

"The Standard C Library", by P.J. Plauger

or peek at sourceforge for an open-source project of your interest.

--
Tor <torust [at] online [dot] no>

C-FAQ: http://c-faq.com/

Oct 12 '07 #21

Ben Bacarisse

jacob navia <ja***@nospam.orgwrites:

Philip Potter wrote:

<snip>

However I can already see
>that it's not entirely a tutorial of standard C because it
advertises "Windows C Programming". Not that there's anything wrong
with that, but it's probably not appropriate to advertise it on this
group.

Look, it is a tutorial for C. Since "Standard C" doesn't RUN anywhere
(you need some specific compiler, some specific operating system,
some way of doing windowed output etc) it is a tutorial of
C in a certain context. The first part is about standard C,

That is not really true. The text starts on page 14, and the first
Windows specific parts are on page 17. On page 19 we get "Console
mode programs and windows programs" followed by lost of systems (even
compiler) specific things. I would prefer a C tutorial to have at
most a few references to compiling and running programs or, better, to
have these in a separate part. This is good of you are writing a "C
on Windows" or "lcc-win32" tutorial, but it makes it read rather
muddled for someone using another system and compiler.

You have statements like "transforming one type of pointer into
another needs no code at all at run-time" which is definitely
system-specific, and you assert that "long" and "int" are compatible
types which is, at best an lcc-win32 extension. (Oddly, this is
immediately followed by the correct rules for compatibility which
contradicts the earlier statement.)

I know how hard it is to write a good tutorial, but have quite a few
factual errors. These would be worth correcting, surely?

--
Ben.

Oct 12 '07 #22

Ben Bacarisse wrote:

jacob navia <ja***@nospam.orgwrites:

>Philip Potter wrote:
<snip>
>However I can already see
>>that it's not entirely a tutorial of standard C because it
advertises "Windows C Programming". Not that there's anything wrong
with that, but it's probably not appropriate to advertise it on this
group.
Look, it is a tutorial for C. Since "Standard C" doesn't RUN anywhere
(you need some specific compiler, some specific operating system,
some way of doing windowed output etc) it is a tutorial of
C in a certain context. The first part is about standard C,

That is not really true. The text starts on page 14, and the first
Windows specific parts are on page 17. On page 19 we get "Console
mode programs and windows programs" followed by lost of systems (even
compiler) specific things.

If I do not explain those immediately, they will NOT be able to compile!
Maybe you are new to windows, but windows user do not know a lot about
the command line and do not understand immediately that they should
open a "dos" window.

I would prefer a C tutorial to have at
most a few references to compiling and running programs or, better, to
have these in a separate part. This is good of you are writing a "C
on Windows" or "lcc-win32" tutorial, but it makes it read rather
muddled for someone using another system and compiler.

You have statements like "transforming one type of pointer into
another needs no code at all at run-time" which is definitely
system-specific,

and the sentence CONTINUES "in most implementations!"

and you assert that "long" and "int" are compatible
types which is, at best an lcc-win32 extension.

And MSVC extension and Watcom extension and gcc extension for the
32 bit version of those at least.

(Oddly, this is

immediately followed by the correct rules for compatibility which
contradicts the earlier statement.)

Not "oddly"

I know how hard it is to write a good tutorial, but have quite a few
factual errors. These would be worth correcting, surely?

Well, I do not see any errors. Yes, if you are running linux, my
tutorial would be difficult to follow, but in a few months I will have
the IDE running and lcc-win will be similar to the windows
version.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 12 '07 #23

user923005

On Oct 12, 8:17 am, John Bode <john_b...@my-deja.comwrote:

On Oct 12, 9:47 am, jacob navia <ja...@nospam.orgwrote:

John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;

99% of people posting in Usenet say crap, and should be avoided like the
plague.

Are you saying I'm wrong? I've yet to see a C tutorial on the Web
that didn't have fundamental mistakes.

I don't think you are wrong (at *least* 99% _are_ crap), but there are
good C tutorials.
The tutorials of Tom Torf and Steve Summit spring to mind.

Whatever happened to the one grumpy code monkey?
;-)

Oct 12 '07 #24

user923005

On Oct 12, 7:06 am, Tsb <ntsetsb...@gmail.comwrote:

I have read about learning C programming language. Lots of them said
the best way to learn C is reading codes.

So where can I find codes and some examples?

You are quite likely to pick up bad habits by looking at code.
For instance, nearly all of the samples in the Microsoft C online help
files contain mistakes.

Get a good C book like K&R2:
http://cm.bell-labs.com/cm/cs/cbook/

A good C class at a local college is also a very good idea, if the
instructor is proficient.

Oct 12 '07 #25

rosewater

jacob navia wrote:

Ben Bacarisse wrote:
I know how hard it is to write a good tutorial, but have quite a few
factual errors. These would be worth correcting, surely?

Well, I do not see any errors.

It is this sort of stupidity and arrogance that makes it impossible
for people to take you seriously. Phil Potter just spewed out a list
of elementary errors a mile long, but you refuse to admit your
mistakes. That's the mark of an idiot.

Oct 12 '07 #26

Ian Collins

jacob navia wrote:

Ben Bacarisse wrote:
>jacob navia <ja***@nospam.orgwrites:

>>Philip Potter wrote:
<snip>
>>However I can already see
that it's not entirely a tutorial of standard C because it
advertises "Windows C Programming". Not that there's anything wrong
with that, but it's probably not appropriate to advertise it on this
group.
Look, it is a tutorial for C. Since "Standard C" doesn't RUN anywhere
(you need some specific compiler, some specific operating system,
some way of doing windowed output etc) it is a tutorial of
C in a certain context. The first part is about standard C,

That is not really true. The text starts on page 14, and the first
Windows specific parts are on page 17. On page 19 we get "Console
mode programs and windows programs" followed by lost of systems (even
compiler) specific things.

If I do not explain those immediately, they will NOT be able to compile!
Maybe you are new to windows, but windows user do not know a lot about
the command line and do not understand immediately that they should
open a "dos" window.

The best introductions and tutorials for any languages I have read all
manage to remain platform and compiler neutral, with all system/compiler
specifics left to an appendix.

--
Ian Collins.

Oct 12 '07 #27

Philip Potter <pg*@see.sig.invalidwrites:
[...]

p57:
"1.13.19 unsigned.
Integer types (long long, long, int, short and char) have the most
significant bit reserved for the sign bit. This declaration tells the
compiler to ignore the sign bit and use the values from zero the 2^n
for the values of that type. For instance, a signed short goes from
–32767 to 32767, an unsigned short goes from zero to 65535
(2^16). See the standard include file <stdint.hfor the ranges of
signed and unsigned integer types."

[...]

At the beginning of the paragraph "Integer types" should be "Signed
integer types".

The ranges of the predefined integer types are given in <limits.h>,
not <stdint.h>. The latter may not exist in pre-C99 implementations.
(Does the tutorial mention that C99 is not widely implemented?)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 12 '07 #28

jacob navia wrote:

Philip Potter wrote:
>This is sheer nonsense. Standard C runs anywhere there is a standard C
implementation. (And you shouldn't write programs which require
"windowed output").

Why shouldn't I? I mean using windowed output is quite normal this
days.

If you write to "stdout", the output will be whatever is "normal" for
the implementation.

>>The first part is about standard C,
the second about windows, and the third is about network programming.

The first part presents a fairly complete view of the language.

Here are a few bits I've picked out:

p2: "A program in C is written in one or several text files called
source modules. Each of those modules is composed of functions, i.e.
smaller pieces of code that accomplish some task, and data, i.e.
variables or tables that are initialized before the program starts."

That defines static data, but what about automatic variables and
dynamically allocated data?

You are at page 2. Do not be surprised if I haven't explained
EVERYTHING :-) Read ON!

This isn't merely an incomplete explanation, it's a wrong explanation.
You should focus on what data is, not examples of how data can be created.

>On p18, your example of a typecast is in a position where the cast is
unnecessary:
float f = 67.8f;
double d = (double)f;

Of course it is unnecessary. I just wanted to show an example of a cast,
and what it does. There is an explicit reference to a more detailed
explanation later.

But would it not be more education to use a cast which *is* necessary?
Otherwise you have users saying "what's the point?" -- or worse, users
who don't realise that it is unnecessary!

>On p19 your description of the size of arithmetic types is mostly
wrong. It is true that char is 1 byte (by definition) but it is not
true that short must be 2 bytes, int must be 4, long must be 4 or long
long must be 8.

If you read two sentence before the table you will see:
"The implementation of the C language by the lcc-win compiler..."

You should still explain what standard C requires if you want to claim
this is an introduction to standard C. At the very least you should make
it clear that these sizes may vary on different implementations.

>p21: "Machine addresses are just integers, of course. For instance, if
you have a machine with 128MB of memory, you have 134 217 728 memory
locations."

I don't know what you're talking about, but it's not standard C.
Machine addresses are not necessarily "just integers".

In this implementation (and many others) yes.

The point is that it is more harmful that helpful to think of pointers
as integers. (And that machine addresses are not necessarily just
integers, regardless of how many implementations you find where they are.)

>p54:
"1.13.10 union.
You can store several values in a single memory location or a group of
memory locations with the proviso that they can’t be accessed at the
same time of course. This allows you to reduce the memory requirements
of a structure, or to interpret a sequence of bits in a different
fashion.
For a detailed discussion see “Unions” on page 107."

This isn't very clear. It sounds like I can store multiple variables
in a union simultaneously, provided I don't access them simultaneously.

Well... that's a union dear.

No, it isn't. That suggests that this code:

union {
int i;
long l;
double d;
} onion;
int main(void) {
onion.i = 1;
onion.l = 2;
onion.d = 3.0;
printf("onion.i is %d\n",onion.i);
printf("onion.i is %ld\n",onion.l);
printf("onion.i is %f\n",onion.d);
return 0;
}

will output
onion.i is 1
onion.l is 2
onion.d is 3.0000000

The problem is that I'm not accessing the variables simultaneously, but
I am *using* them simultaneously. There's an important difference.

You *cannot* store multiple values in a union simultaneously. I'm sure
you know this, but your language is sloppy and confusing.

>p57:
"1.13.19 unsigned.
Integer types (long long, long, int, short and char) have the most
significant bit reserved for the sign bit. This declaration tells the
compiler to ignore the sign bit and use the values from zero the 2^n
for the values of that type. For instance, a signed short goes from
–32767 to 32767, an unsigned short goes from zero to 65535 (2^16). See
the standard include file <stdint.hfor the ranges of signed and
unsigned integer types."

Why even mention a sign bit? Also while that is the minimum range for
a signed short, it may be larger (and it wouldn't surprise me if it is
larger on lcc-win32!)

The mentioning of the sign bit makes the whole thing easier to
understand

I disagree. A signed value can be negative. An unsigned value cannot.
What is hard to understand about that?

>p138: Are you really advocating writing programs which do not free()
all that they malloc()?

Yes.
It is very convenient. The lcc compiler does that.

It's terrible practice.

>p146: This is a poor hash function, and you do not explain
sufficiently well the importance of a good hash function.

Yes. It is a hash function that works, but it is surely not the best and
it is not advertised as the best.

No, but it is advertised as a hash function which will do. If it will do
for an example, a user will expect it to do for his code. When he thinks
about hash functions, he will remember the one you provided and
copy/paste it in. (And why shouldn't he? After all, reinventing the
wheel is bad.)

>p182: IEEE 754 floating point is not required by the standard.

????

n1256, 6.10.8p2:
The following macro names are conditionally defined by the implementation:
__STDC_IEC_559__ The integer constant 1, intended to indicate
conformance to the specifications in annex F (IEC 60559 floating-point
arithmetic).

If the implementation does not define __STDC_IEC_559__, it is only
constrained by the lower limits specified in 5.2.4.2.2.

>p190: QFLT_EPSILON is not part of the standard, though it looks like
you state that it is.

Overall, the typesetting is dreadful: on p3, "argument-list" should
not wrap a line. When you introduce main, you italicise it, but when
you introduce printf, you put it in double quotes. On p13, the line
numbers in the second example look like they're part of the code (and
cause syntax errors!) On p18 you have a code example in a proportional
font. On top of all this, there is no Chapter 2!

Yes, it is the windows programming part!

Look again. Windows programming is in Chapter 3. There is no chapter 2.
(Though the contents do reference it.)

>This is after a quick skim, I haven't read most of it. But what I have
read already means I wouldn't recommend this guide to anyone as an
introduction to standard C. In some places, you take care to inform
the reader what is standard and what is lcc-win32 specific, but in
other places you do not. And your explanations and definitions are
sloppy, but an introduction to C must be strict and careful with its
use of words.

I think that you have obviously a bias against me. But your comments
are welcome. I will go on working in this.

Show me an example of bias and I will accept it. I think my comments
have been fair.

--
Philip Potter pgp <atdoc.ic.ac.uk

Oct 12 '07 #29

jjds101

On Oct 12, 10:06 am, Tsb <ntsetsb...@gmail.comwrote:

I have read about learning C programming language. Lots of them said
the best way to learn C is reading codes.

So where can I find codes and some examples?

I would recommend *not* asking in comp.lang.c. If you read the
responses throughout your thread you can see that the regular
contributors are more interested in slinging mud and arguing with each
other than participating in useful discussion.

Usenet is full of kooks and crazies, really. The regulars here all
look like these guys:
http://images.amazon.com/images/P/18...1.LZZZZZZZ.gif

Stick with books, and post your questions to a web forum somewhere.
The information you'll get will be more useful in real-world
programming, and you might even be able to find a good forum where you
can post simple questions. Questions that don't turn into giant flame
wars among Usenet loons who want to prove they have bigger beards than
the next guy.

Read some of the other threads, you'll see what I'm talking about.
There's nothing of value here. Move along before you turn into one.

Oct 12 '07 #30

John Bode

On Oct 12, 1:41 pm, user923005 <dcor...@connx.comwrote:

On Oct 12, 8:17 am, John Bode <john_b...@my-deja.comwrote:

On Oct 12, 9:47 am, jacob navia <ja...@nospam.orgwrote:

John Bode wrote:
99% of the tutorials and examples on the Web are *crap*, and should be
avoided like the plague;

99% of people posting in Usenet say crap, and should be avoided like the
plague.

Are you saying I'm wrong? I've yet to see a C tutorial on the Web
that didn't have fundamental mistakes.

I don't think you are wrong (at *least* 99% _are_ crap), but there are
good C tutorials.
The tutorials of Tom Torf and Steve Summit spring to mind.

Whatever happened to the one grumpy code monkey?
;-)

He's grumpy as ever. He even has a blog
(grumpycodemonkey.blogspot.com) that he hasn't updated in forever.

I just wanted to impress upon the OP that there's a lot of bad
information out there about the C programming language, and that he's
better off sticking with authoritative sources in the beginning.

Oct 12 '07 #31

jacob navia <ja***@nospam.orgwrites:

Ben Bacarisse wrote:

[...]

>and you assert that "long" and "int" are compatible
types which is, at best an lcc-win32 extension.

And MSVC extension and Watcom extension and gcc extension for the
32 bit version of those at least.

(Oddly, this is
>immediately followed by the correct rules for compatibility which
contradicts the earlier statement.)

Not "oddly"

[...]

No, int and long are not compatible types. They are distinct types
that may happen have the same representation in some implementations.

If int and long were compatible types then this:

int *pi = NULL;
long *pl = pi;

would be legal; in fact, it's a constraint violation.

I suggest you look up the word "compatible" in the standard.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 12 '07 #32

Philip Potter wrote:

jacob navia wrote:
>Philip Potter wrote:
>>This is sheer nonsense. Standard C runs anywhere there is a standard
C implementation. (And you shouldn't write programs which require
"windowed output").

Why shouldn't I? I mean using windowed output is quite normal this
days.

If you write to "stdout", the output will be whatever is "normal" for
the implementation.

Yes. Under windows it means that your output is discarded.
Under linux it means the same: your output is not visible.

OF COURSE YOU KNOW THAT. But beginners don't!

>
You should still explain what standard C requires if you want to claim
this is an introduction to standard C. At the very least you should make
it clear that these sizes may vary on different implementations.

Yes
You are right. I added the sizes and size changes for the 64 bit version of
lcc-win. This makes it obvious that those sizes change.

>>p21: "Machine addresses are just integers, of course. For instance,
if you have a machine with 128MB of memory, you have 134 217 728
memory locations."

I don't know what you're talking about, but it's not standard C.
Machine addresses are not necessarily "just integers".

In this implementation (and many others) yes.

The point is that it is more harmful that helpful to think of pointers
as integers. (And that machine addresses are not necessarily just
integers, regardless of how many implementations you find where they are.)

Well, this is a disagreement. I hope you do not mind.

>>p54:
"1.13.10 union.
You can store several values in a single memory location or a group
of memory locations with the proviso that they can’t be accessed at
the same time of course. This allows you to reduce the memory
requirements of a structure, or to interpret a sequence of bits in a
different fashion.
For a detailed discussion see “Unions” on page 107."

This isn't very clear. It sounds like I can store multiple variables
in a union simultaneously, provided I don't access them simultaneously.

Well... that's a union dear.

No, it isn't. That suggests that this code:

union {
int i;
long l;
double d;
} onion;
int main(void) {
onion.i = 1;
onion.l = 2;
onion.d = 3.0;
printf("onion.i is %d\n",onion.i);
printf("onion.i is %ld\n",onion.l);
printf("onion.i is %f\n",onion.d);
return 0;
}

will output
onion.i is 1
onion.l is 2
onion.d is 3.0000000

The problem is that I'm not accessing the variables simultaneously, but
I am *using* them simultaneously. There's an important difference.

You *cannot* store multiple values in a union simultaneously. I'm sure
you know this, but your language is sloppy and confusing.

Mmmm. I will try to rework that sentence. I guess you are right.
Thanks

>>p138: Are you really advocating writing programs which do not free()
all that they malloc()?

Yes.
It is very convenient. The lcc compiler does that.

It's terrible practice.

Why?

The operating system will cleanup after the program closes!
Why it is a bad practice?

I mention this as a valid memory allocation strategy in the chapter
about memory allocation!

If the programs makes only allocation and almost no free() then why
bothering with freeing the memory at all?

>>p146: This is a poor hash function, and you do not explain
sufficiently well the importance of a good hash function.

Yes. It is a hash function that works, but it is surely not the best and
it is not advertised as the best.

No, but it is advertised as a hash function which will do. If it will do
for an example, a user will expect it to do for his code. When he thinks
about hash functions, he will remember the one you provided and
copy/paste it in. (And why shouldn't he? After all, reinventing the
wheel is bad.)

Then he/she will have a hash function that works but it is not very
fast. There are hash functions for different purposes and
you can write BOOKS about the subject!

>>p182: IEEE 754 floating point is not required by the standard.

????

n1256, 6.10.8p2:
The following macro names are conditionally defined by the implementation:
__STDC_IEC_559__ The integer constant 1, intended to indicate
conformance to the specifications in annex F (IEC 60559 floating-point
arithmetic).

If the implementation does not define __STDC_IEC_559__, it is only
constrained by the lower limits specified in 5.2.4.2.2.

OK OK, but is this necessary in a tutorial? I mean why putting all the
complexity of the standard and the possibility of non floating point
implementations into new users of the language?

>>
Yes, it is the windows programming part!

Look again. Windows programming is in Chapter 3. There is no chapter 2.
(Though the contents do reference it.)

I am using an old version of frame maker from adobe since I have no
money for the upgrade (US$ 350).

And it has bugs DAMM!!!
And I did not see that one.

Show me an example of bias and I will accept it. I think my comments
have been fair.

Yes. That is true. Thanks for your help.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 12 '07 #33

J. J. Farrell

On Oct 12, 3:26 pm, Richard <rgr...@gmail.comwrote:

Tsb <ntsetsb...@gmail.comwrites:
I have read about learning C programming language. Lots of them said
the best way to learn C is reading codes.

So where can I find codes and some examples?

The best resources by FAR are the Linux/Gnus source codes. Big dirty
applications with bugs to fix. You might not learn "Ansi C", but you
will learn real world Linux C in no time.. especially if you submit a
bug fix which is not done properly...

On the contrary, there are much better resources along these lines
available. If diving into OS code and OS utilities is an approach you
want to try, I'd recommend the OpenBSD sources at http://www.openbsd.org/.
The code is generally of extremely high quality with few bugs, and
largely written in Standard portable C. The style is generally clear,
straightforward, and easy to read - and consistent.

I'm not sure that diving unguided into such a big sea of code, some of
which is very complex, is a good approach for someone just learning C.
It may suit some people and not others. If you want to try, I'd start
off by finding the source of a small utility whose functionality you
already know, and looking at that.

Oct 12 '07 #34

jacob navia wrote:

Philip Potter wrote:
>jacob navia wrote:
>>Philip Potter wrote:
This is sheer nonsense. Standard C runs anywhere there is a standard
C implementation. (And you shouldn't write programs which require
"windowed output").
Why shouldn't I? I mean using windowed output is quite normal this
days.

If you write to "stdout", the output will be whatever is "normal" for
the implementation.

Yes. Under windows it means that your output is discarded.
Under linux it means the same: your output is not visible.

OF COURSE YOU KNOW THAT. But beginners don't!

Under linux your output appears in the tty you ran the program from.
Under windows you can generally access it: in the DOS box you ran it
from, or in MSVC you can view it in the Output window.

>You should still explain what standard C requires if you want to claim
this is an introduction to standard C. At the very least you should
make it clear that these sizes may vary on different implementations.

Yes
You are right. I added the sizes and size changes for the 64 bit version of
lcc-win. This makes it obvious that those sizes change.

Well that's a start. However when writing portable C it is important to
know the minimum sizes of the types - if you know that int may not be
able to store numbers >32767 you will know to use long for greater numbers.

>The point is that it is more harmful that helpful to think of pointers
as integers. (And that machine addresses are not necessarily just
integers, regardless of how many implementations you find where they
are.)

Well, this is a disagreement. I hope you do not mind.

*shrug* I won't lose any sleep.

>>>p138: Are you really advocating writing programs which do not free()
all that they malloc()?

Yes.
It is very convenient. The lcc compiler does that.

It's terrible practice.

Why?

The operating system will cleanup after the program closes!
Why it is a bad practice?

I mention this as a valid memory allocation strategy in the chapter
about memory allocation!

If the programs makes only allocation and almost no free() then why
bothering with freeing the memory at all?

If you are sloppy with scratch code you will also be sloppy with
production code. If you are in the habit of free()ing every malloc() for
scratch code, you will also be in the habit of free()ing every malloc()
for production code.

>No, but it is advertised as a hash function which will do. If it will
do for an example, a user will expect it to do for his code. When he
thinks about hash functions, he will remember the one you provided and
copy/paste it in. (And why shouldn't he? After all, reinventing the
wheel is bad.)

Then he/she will have a hash function that works but it is not very
fast. There are hash functions for different purposes and
you can write BOOKS about the subject!

That is why good tutorials and textbooks do not define a hash function
when discussing hash tables but instead include references to find good
ones. A poor hash function negates the entire purpose of a hash table!

>>>p182: IEEE 754 floating point is not required by the standard.
????

n1256, 6.10.8p2:
The following macro names are conditionally defined by the
implementation:
__STDC_IEC_559__ The integer constant 1, intended to indicate
conformance to the specifications in annex F (IEC 60559 floating-point
arithmetic).

If the implementation does not define __STDC_IEC_559__, it is only
constrained by the lower limits specified in 5.2.4.2.2.

OK OK, but is this necessary in a tutorial? I mean why putting all the
complexity of the standard and the possibility of non floating point
implementations into new users of the language?

Why put all the complexity of IEC 559 into your tutorial when you can
keep to a general overview of floating point? And why confuse your users
into thinking IEC 559 is guaranteed?

>>Yes, it is the windows programming part!

Look again. Windows programming is in Chapter 3. There is no chapter
2. (Though the contents do reference it.)

I am using an old version of frame maker from adobe since I have no
money for the upgrade (US$ 350).

And it has bugs DAMM!!!
And I did not see that one.

I can recommend pdflatex. It's free. It's not buggy. And it has very
pretty output.

--
Philip Potter pgp <atdoc.ic.ac.uk

Oct 12 '07 #35

Mark McIntyre

On Fri, 12 Oct 2007 12:17:06 -0700, in comp.lang.c , jj*****@yahoo.com
wrote:

>On Oct 12, 10:06 am, Tsb <ntsetsb...@gmail.comwrote:
>>
So where can I find codes and some examples?

.If you read the
responses throughout your thread you can see that the regular
contributors are more interested in slinging mud and arguing with each
other than participating in useful discussion

This is horsefeathers, but from someone posting from a throwaway email
address, we can expect no less. .

>
Stick with books,

This is good advice. Most web tutorials are garbage, written by the
sort of people who contribute articles to Wikipedia.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

Oct 12 '07 #36

Ian Collins

J. J. Farrell wrote:

On Oct 12, 3:26 pm, Richard <rgr...@gmail.comwrote:
>Tsb <ntsetsb...@gmail.comwrites:
>>I have read about learning C programming language. Lots of them said
the best way to learn C is reading codes.
So where can I find codes and some examples?
The best resources by FAR are the Linux/Gnus source codes. Big dirty
applications with bugs to fix. You might not learn "Ansi C", but you
will learn real world Linux C in no time.. especially if you submit a
bug fix which is not done properly...

On the contrary, there are much better resources along these lines
available. If diving into OS code and OS utilities is an approach you
want to try, I'd recommend the OpenBSD sources at http://www.openbsd.org/.
The code is generally of extremely high quality with few bugs, and
largely written in Standard portable C. The style is generally clear,
straightforward, and easy to read - and consistent.

Another alternative that shares the above attributes with the added
bonus of at least one good explanatory book and a great search tool
(http://cvs.opensolaris.org/source/) is the OpensSolaris source.

--
Ian Collins.

Oct 12 '07 #37

jacob navia wrote:

Keith Thompson wrote:
>What is your question? He's right, the C standard doesn't require
IEEE 754 floating point. Do you dispute that, or does your tutorial
not actually make that assumption?

I think that implementations without floating point are disappearing
quite fast. Actually, the only one I used was in a DSP some years ago,
where we did not bother with that since the circuit did not support it
and we had like 40-50K of RAM.

But those are extreme environments.

You misunderstand; the standard allows for floating-point which is not
IEEE 754 (aka IEC 559) floating-point. For example, you could use a
decimal-based system (FLT_RADIX == 10). IEEE 754 has all sorts of
requirements (denormal numbers, infinities, NaNs, and certain
implementation details of math functions) which a specific
implementation may not care to fulfil.

--
Philip Potter pgp <atdoc.ic.ac.uk

Oct 12 '07 #38

Mark McIntyre

On Fri, 12 Oct 2007 20:49:40 +0100, in comp.lang.c , Philip Potter
<pg*@see.sig.invalidwrote:

>jacob navia wrote:
>Philip Potter wrote:

>>The point is that it is more harmful that helpful to think of pointers
as integers. (And that machine addresses are not necessarily just
integers, regardless of how many implementations you find where they
are.)

Well, this is a disagreement. I hope you do not mind.

*shrug* I won't lose any sleep.

Thats fortunate, because you will ***never*** convince Jacob that
pointers are not integers.

>>>>p138: Are you really advocating writing programs which do not free()
all that they malloc()?
>
It is very convenient. The lcc compiler does that.

It's terrible practice.

The operating system will cleanup after the program closes!
Why it is a bad practice?

And what happens when your daemon doesn't terminate, but just keeps on
mallocing more and more memory....

You really are a shockingly bad programmer if you seroiusly advocate
you don't need to clear up after yourself.

>If you are sloppy with scratch code you will also be sloppy with
production code.

Quite.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

Oct 12 '07 #39

Ian Collins

jacob navia wrote:

>
I think that implementations without floating point are disappearing
quite fast. Actually, the only one I used was in a DSP some years ago,
where we did not bother with that since the circuit did not support it
and we had like 40-50K of RAM.

You jest? I bet there's more C written and compilers for 8 bit, limited
memory devices that for systems with FPU support.

But those are extreme environments.

s/extreme/mainstream/

--
Ian Collins.

Oct 12 '07 #40

Mark McIntyre wrote:

On Fri, 12 Oct 2007 20:49:40 +0100, in comp.lang.c , Philip Potter
<pg*@see.sig.invalidwrote:

>jacob navia wrote:
>>>>>p138: Are you really advocating writing programs which do not free()
>all that they malloc()?
>>
It is very convenient. The lcc compiler does that.
It's terrible practice.
The operating system will cleanup after the program closes!
Why it is a bad practice?

And what happens when your daemon doesn't terminate, but just keeps on
mallocing more and more memory....

You really are a shockingly bad programmer if you seroiusly advocate
you don't need to clear up after yourself.

To be fair to Jacob in his tutorial he only advocates this for programs
which do terminate. It's still a shocking habit though.

--
Philip Potter pgp <atdoc.ic.ac.uk

Oct 12 '07 #41

John Smith

jacob navia wrote:

<snip>

I sent a message about my tutorial,
that has taken me years of work.

Before making such sweeping statements, Mr Bode could (maybe)
try to see the tutorials that aren't crap...

Jacob, for a long time I thought you were getting a raw deal in
c.l.c. Now I'm not so sure. The fact of the matter is, you don't
have a particularly good track record. Have you looked at the
most recent post in your own lcc-win32 newsgroup? Does it deserve
a response or do you think it best just to ignore reports of
errors in your code?

JS

Oct 12 '07 #42

jacob navia <ja***@nospam.orgwrites:

Philip Potter wrote:

[...]

>The point is that it is more harmful that helpful to think of
pointers as integers. (And that machine addresses are not
necessarily just integers, regardless of how many implementations
you find where they are.)

Well, this is a disagreement. I hope you do not mind.

Addresses are not integers. If a C tutorial claims that they are,
that alone is enough reason for me to recommend avoiding it.

I hope you do not mind.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 12 '07 #43

rosewater

jacob navia wrote:

Philip Potter wrote:
This is sheer nonsense. Standard C runs anywhere there is a standard C
implementation. (And you shouldn't write programs which require
"windowed output").

Why shouldn't I? I mean using windowed output is quite normal this
days.

Don't be stupid. Most C programs are in embedded systems. Almost all
desktop C programming uses a terminal of some sort, and a significant
proportion is still done via a teleprinter or similar.

>

The first part is about standard C,
the second about windows, and the third is about network programming.

The first part presents a fairly complete view of the language.
Here are a few bits I've picked out:

p2: "A program in C is written in one or several text files called
source modules. Each of those modules is composed of functions, i.e.
smaller pieces of code that accomplish some task, and data, i.e.
variables or tables that are initialized before the program starts."

That defines static data, but what about automatic variables and
dynamically allocated data?

You are at page 2. Do not be surprised if I haven't explained
EVERYTHING :-) Read ON!

If there is incomplete and misleading information on page 2, that
isn't much of an incentive to read ON.

On p19 your description of the size of arithmetic types is mostly wrong.
It is true that char is 1 byte (by definition) but it is not true that
short must be 2 bytes, int must be 4, long must be 4 or long long must
be 8.

If you read two sentence before the table you will see:
"The implementation of the C language by the lcc-win compiler..."

So much for this being the chapter on "standard C".

p54:
"1.13.10 union.
You can store several values in a single memory location or a group of
memory locations with the proviso that they can't be accessed at the
same time of course. This allows you to reduce the memory requirements
of a structure, or to interpret a sequence of bits in a different fashion.
For a detailed discussion see "Unions" on page 107."

This isn't very clear. It sounds like I can store multiple variables in
a union simultaneously, provided I don't access them simultaneously.

Well... that's a union dear.

You should be aware that this sounds extremely camp in English, with
homo-erotic overtones.

True. Eliminated msize and expand. And marked alloca and GC_malloc by
saying that they may be absent in other systems.

Why mention them at all? They're a useless addition to lcc-win32.

>
p138: Are you really advocating writing programs which do not free() all
that they malloc()?
Yes.
It is very convenient. The lcc compiler does that.

Completely barmy. You clearly don't have the first idea about good C
programming practice. Anyone who makes a statement like this has NO
BUSINESS writing a tutorial purporting to teach others C.

I think that you have obviously a bias against me. But your comments
are welcome. I will go on working in this.

Why do you always think the world is against you? If you were prepared
to act on the constructive criticism you receive, your compiler and
its tutorial might not be such a shambles.

Oct 12 '07 #44

John Smith wrote:

jacob navia wrote:

<snip>

>I sent a message about my tutorial,
that has taken me years of work.

Before making such sweeping statements, Mr Bode could (maybe)
try to see the tutorials that aren't crap...

Jacob, for a long time I thought you were getting a raw deal in c.l.c.
Now I'm not so sure. The fact of the matter is, you don't have a
particularly good track record. Have you looked at the most recent post
in your own lcc-win32 newsgroup? Does it deserve a response or do you
think it best just to ignore reports of errors in your code?

JS

Hi John

Your post started a long re-research program trying to find the most
adequate definition of kurtosis. Then, I left it for tomorrow, and
then many other things came. I should have acknowledge that
and tell you I am researching your post.

Excuse me for the delay.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 12 '07 #45

rosewater

jacob navia wrote:

I am using an old version of frame maker from adobe since I have no
money for the upgrade (US$ 350).

And it has bugs DAMM!!!
And I did not see that one.

Well, live by the sword, die by the sword. Given that you choose to
give nothing back to the community, instead releasing your compiler
under a non-free license, you are hardly in a position to complain
that Adobe's software is proprietary.

Why don't you ask your daughter to download the new version at the
same time as she's illegally downloading Japanese movies?

Oct 12 '07 #46

Ben Bacarisse

jacob navia <ja***@nospam.orgwrites:

Ben Bacarisse wrote:
>jacob navia <ja***@nospam.orgwrites:

<snip>

>>Look, it is a tutorial for C. Since "Standard C" doesn't RUN anywhere
(you need some specific compiler, some specific operating system,
some way of doing windowed output etc) it is a tutorial of
C in a certain context. The first part is about standard C,

That is not really true. The text starts on page 14, and the first
Windows specific parts are on page 17. On page 19 we get "Console
mode programs and windows programs" followed by lost of systems (even
compiler) specific things.

If I do not explain those immediately, they will NOT be able to
compile!

I know why you do it. I have no problem with it as a style, but it
means your tutorial reads as being very compiler and OS specific. You
said the first part is about "standard C" but I think there is a lot
of other stuff in there. Personally, I'd put it in an appendix. This
has the advantage that you can have several appendices -- one for each
compiler/IDE/OS or whatever.

>You have statements like "transforming one type of pointer into
another needs no code at all at run-time" which is definitely
system-specific,

and the sentence CONTINUES "in most implementations!"

Not in the version I am looking at right now (download an hour or so
ago). If you have a corrected version I have just wasted my time
looking at. I think the best correction (in a tutorial on C) would
have been to say nothing about code generated from pointer
conversions.

>and you assert that "long" and "int" are compatible
types which is, at best an lcc-win32 extension.

And MSVC extension and Watcom extension and gcc extension for the
32 bit version of those at least.

It is not in gcc as far as I can see. What do you mean by this?

(Oddly, this is
>immediately followed by the correct rules for compatibility which
contradicts the earlier statement.)

Not "oddly"

Eh? You state: "in lcc-win32 for the Intel platform, in 32 bits, long
and int are compatible". Immediately followed by the correct rules
which imply (correctly) that int and long are not compatible types.
It loos odd to me. I don't see how the platform details have anything
to do with it.

>I know how hard it is to write a good tutorial, but have quite a few
factual errors. These would be worth correcting, surely?

Well, I do not see any errors.

And you may have fixed them. We are obviously reading different
texts but there were quote a few in the text I saw.

--
Ben.

Oct 13 '07 #47

Thad Smith

Mark McIntyre wrote:

On Fri, 12 Oct 2007 20:49:40 +0100, in comp.lang.c , Philip Potter
<pg*@see.sig.invalidwrote:

>jacob navia wrote:
>>Philip Potter wrote:
The point is that it is more harmful that helpful to think of pointers
as integers. (And that machine addresses are not necessarily just
integers, regardless of how many implementations you find where they
are.)
Well, this is a disagreement. I hope you do not mind.
*shrug* I won't lose any sleep.

Thats fortunate, because you will ***never*** convince Jacob that
pointers are not integers.

Pointers are objects stored in some number of bytes. A group of bytes
can be interpreted as a bit string, which can be interpreted as an
integer. What's the big deal about interpreting a group of bytes as an
integer? C even defines optional types intptr_t and uinptr_t for that
purpose. The important issue is what meaning, if any, you give to the
value of the integer.

You can say the same thing about floating point representations.

--
Thad

Oct 13 '07 #48