Doubts about pointers

[John Bode]

Please don't top-post; it makes following the discussion difficult.

Thanks for the answer. I guessed that is what would happen but I
couldn't find any documentation, can you provide a link to the relevant
Borland documentation?

Actually I'm mostly learning C from the book by H. Schildt, which is
excellent but it doesn't mention near and far pointers at all. I find
them quite confusing, so I think any book should explain them clearly.

As others have probably pointed out by now, "near" and "far" pointers
are not part of the core C language; they're extensions specific to a
couple of platforms, so a book on generic C isn't going to mention
them at all.

As for Schildt...

The man's an engaging writer, but he's not known for technical
accuracy. The first edition of "C: The Complete Reference" was
incredibly DOS-centric, chock-full of technical errors and bad
programming habits, and much of the example code was poorly written
and wouldn't even compile.

He may have improved over time, but it seems his books still receive
poor reviews. I personally would stick with Kernighan and Ritchie's
"The C Programming Language", 2nd ed.

As for being obsolete, the good thing is that Borland have released
Turbo-C for free now, so there's no need to worry about Micro$oft
license fees. Also C doesn't change much!

Actually, the latest revision (C99) introduces a lot of new stuff.

[snip]

 

[Richard Heathfield]

John Bode said:

As for Schildt...

The man's an engaging writer, but he's not known for technical
accuracy.

....in much the same way that the South Pole is not known for its sun-soaked
sandy beaches.

 

[santosh]

Do those better systems allow you to test your code for portability to
16-bit systems?

I should have said better for most purposes, or at least, for my
purposes, for I no longer write for 16 bit systems. Also DOS and Turbo
C allow you to compile and test code for only one particular 16 bit
architecture.

A beginner to C today should almost always start with something like
Windows or Linux and an appropriate compiler and learn portable C
programming, unless he has specific requirements or restrictions to use
DOS and Turbo C.

 

[Keith Thompson]

I should have said better for most purposes, or at least, for my
purposes, for I no longer write for 16 bit systems. Also DOS and Turbo
C allow you to compile and test code for only one particular 16 bit
architecture.

A beginner to C today should almost always start with something like
Windows or Linux and an appropriate compiler and learn portable C
programming, unless he has specific requirements or restrictions to use
DOS and Turbo C.

Chuck specifically said that the "only real purpose" of TC2.01 is to
check portability to 16 bit systems. If you want to make sure that
your code doesn't implicitly assume that INT_MAX is 2**31-1, and
doesn't break if INT_MAX is 2**15-1, then TC2.01 would seem to be a
reasonable tool for that specialized job (I assume; I've never used it
myself). If that's not something you happen to need, that's fine, but
then I don't quite see the point of your response.

I don't think anyone was seriously advocating TC2.01 for beginning C
programmers.

 

[Richard Heathfield]

Keith Thompson said:

I don't think anyone was seriously advocating TC2.01 for beginning C
programmers.

I would advocate as many C compilers as possible for beginning C
programmers. Why exclude Turbo C?

 

[santosh]

Keith Thompson said:



I would advocate as many C compilers as possible for beginning C
programmers.

Why does one need as many compilers as possible to learn ANSI C? Don't
you think the beginner is going to get confused under masses of
implementation extensions?

I would have thought the correct course was to learn first standard C
(with *a* conforming implementation) and then learn the tools for the
system which interest you.

Why exclude Turbo C?

To use it well, the beginners would have to be taught the usage of an
almost extinct system, and information about memory models that they
are unlikely to encounter outside the course, which would in any case
be a waste of time in a C course. And it was, I believe, pointed out in
a recent thread that the freely downloadable version of Turbo C fails
to conform even with the C90 standard.

So what are the compelling reasons to make beginners of today start with
Turbo C?

 

[Richard Heathfield]

santosh said:

Why does one need as many compilers as possible to learn ANSI C?

So that one does not get confused by masses of implementation extensions.

Don't
you think the beginner is going to get confused under masses of
implementation extensions?

Not at all. If you want to teach them implementation extensions, use just
one compiler. If you want to teach them ISO C, use lots of compilers, and
never tell them which one you're going to use for testing their program.

I would have thought the correct course was to learn first standard C
(with *a* conforming implementation) and then learn the tools for the
system which interest you.

Apart from the "*a*", yes, I agree.

To use it well, the beginners would have to be taught the usage of an
almost extinct system, and information about memory models that they
are unlikely to encounter outside the course,

Um, no. You don't need to know anything about any of that, if you're
writing in ISO C. Don't confuse "the kind of programming I often see
written by Turbo C users" with "the kind of programming Turbo C requires".

which would in any case
be a waste of time in a C course. And it was, I believe, pointed out in
a recent thread that the freely downloadable version of Turbo C fails
to conform even with the C90 standard.

Not by a huge amount. I think the only non-conformance issue that I ever
came across in real code was the CLOCKS_PER_SEC thing, and it's not as if
that's difficult to work around.

So what are the compelling reasons to make beginners of today start with
Turbo C?

None whatsoever. My point is not "start with Turbo C" but rather "start
with anything, it doesn't matter, who cares? C is C". I have taught C to
people using Turbo C, Borland C, Microsoft C, C/370, gcc, Digital Mars,
and no doubt one or two others that I've forgotten. C is C, whatever you
compile it on (or even if you don't compile it at all).

 

[Nick Keighley]

Nick Keighleywrote:


Those are NOT 16 bit systems.  They cannot be used to check code
executes correctly on a minimal system.

I can't find anywhere the OP had this as a requirement.

 

[dj3vande]

santosh said:

Not at all. If you want to teach them implementation extensions, use just
one compiler. If you want to teach them ISO C, use lots of compilers, and
never tell them which one you're going to use for testing their program.

No, test it with *all* of the compilers you mention to them, and tell
them that.


dave
(builds even his Windows-specific code on three different platforms)

 

[Richard Heathfield]

(e-mail address removed) said:

No, test it with *all* of the compilers you mention to them, and tell
them that.

I'll buy that, provided the only conditional preprocessor directives
allowed are for guards against multiple inclusion.

 

[dj3vande]

(e-mail address removed) said:


I'll buy that, provided the only conditional preprocessor directives
allowed are for guards against multiple inclusion.

I would be inclined to just decide that if somebody can write
conditionally compiled code that works as desired for N different
compilers, for sufficiently large N, then probably either they
understand portability well enough to be trusted to use extensions when
they decide it's worth the effort, or they're masochistic enough to
re-write the entire program for every compiler you use and nothing you
can do will get through to them.

Or, if you really want to be evil, have your test script invoke every
compiler with flags equivalent to
"-D__GNUC__=3 -D_MSC_VER=1200 -D_WIN32 -D__unix__"
(plus any other predefined macros they might be checking for) to make
the conditional compilation directives useless.


dave
(plus, '#ifdef USE_UNSTABLE_VERSION' is rather convenient at times)

 

[CBFalconer]

Keith Thompson wrote:
.... snip ...

I should have said better for most purposes, or at least, for my
purposes, for I no longer write for 16 bit systems. Also DOS and
Turbo C allow you to compile and test code for only one
particular 16 bit architecture.

Then you are not writing portable code.

 

[CBFalconer]

I can't find anywhere the OP had this as a requirement.

It's part of the C standard.

5.2.4.2.1 Sizes of integer types <limits.h>

[#1] The values given below shall be replaced by constant
expressions suitable for use in #if preprocessing
directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
the following shall be replaced by expressions that have the
same type as would an expression that is an object of the
corresponding type converted according to the integer
promotions. Their implementation-defined values shall be
equal or greater in magnitude (absolute value) to those
shown, with the same sign.

...

-- minimum value for an object of type int
INT_MIN -32767 // -(215-1)

-- maximum value for an object of type int
INT_MAX +32767 // 215-1

-- maximum value for an object of type unsigned int
UINT_MAX 65535 // 216-1

 

[Nick Keighley]

Nick Keighleywrote:



It's part of the C standard.  

what are you talking about? The OP wants to learn C. He's using
an old version of Turbo C. He says he's doing this to avoid
"license fees". I pointed out some free C compilers.

So where in the C standard does it say the Original Poster
needs to compile on a 16 bit system?

<snip big lump of standardese>

 

[santosh]

what are you talking about? The OP wants to learn C. He's using
an old version of Turbo C. He says he's doing this to avoid
"license fees". I pointed out some free C compilers.

So where in the C standard does it say the Original Poster
needs to compile on a 16 bit system?

<snip big lump of standardese>

He is saying that since the standard guarantees only 16 bits for int,
one should use Turbo C to compile their code, to ensure portability to
16 bit systems.

 

[Richard Heathfield]

santosh said:

He is saying that since the standard guarantees only 16 bits for int,
one should use Turbo C to compile their code, to ensure portability to
16 bit systems.

Turbo C is not the only compiler that supports 16-bit code. So do all
versions of Microsoft C prior to VC2.0. So does Borland C (certainly up to
5.02, anyway). So does DJGPP (which is also available without charge, by
the way). There's nothing sacrosanct about Turbo C.

 

[santosh]

santosh said:



Turbo C is not the only compiler that supports 16-bit code. So do all
versions of Microsoft C prior to VC2.0.

Yes, but I doubt that many people still have access to copies of MSVC <
v2.0.

So does Borland C (certainly
up to 5.02, anyway).

So does DJGPP (which is also available without charge, by the way).

No, DJGPP only generates 32 bit code.

There's nothing sacrosanct about Turbo C.

It is however probably the only easily available 16 bit compiler for DOS
at this time. It used to very popular with IT training centres uptil a
few years back, but you'll struggle to find many, even here. Most have
switched over to gcc and MSVC.

As far as checking code for portability to 16 bit systems, yes it's
somewhat useful there, but that not a very compelling advantage to use
it, IMO.

 

[Richard Heathfield]

santosh said:

Richard Heathfield wrote:


Yes, but I doubt that many people still have access to copies of MSVC <
v2.0.

Well, *I* do, and that's what matters, right?

No, DJGPP only generates 32 bit code.

Hmmm. I take it back. (Coulda sworn it were 16-bit... Oh well, that might
teach me to be more careful about trusting to memory.)

As far as checking code for portability to 16 bit systems, yes it's
somewhat useful there, but that not a very compelling advantage to use
it, IMO.

Well, it doesn't hurt. More compellingly, though, are these advantages: the
IDE is dead easy to use; and the compiler is astoundingly quick on modern
machines. (It was pretty darn quick even on 8086s.)

 

[CBFalconer]

santosh said:



Turbo C is not the only compiler that supports 16-bit code. So do
all versions of Microsoft C prior to VC2.0. So does Borland C
(certainly up to 5.02, anyway). So does DJGPP (which is also
available without charge, by the way). There's nothing sacrosanct
about Turbo C.

BTW, DJGPP uses gcc. It doesn't prepare 16 bit C code. I believe
it has something available to handle some of its own system
specific code, but not a general 16 bit C compiler.

 

[santosh]

santosh said:


Well, it doesn't hurt. More compellingly, though, are these
advantages: the IDE is dead easy to use; and the compiler is
astoundingly quick on modern machines. (It was pretty darn quick even
on 8086s.)

And another major problem is that you are pretty much forced to use
Windows. Turbo C doesn't work properly under DOSEmu, from my personal
experience. Now most IT training centres already have loads of Windows
machines, so it's not a major problem for them, but many interested
individuals are increasingly using something like Linux, FreeBSD or
OpenSolaris, and Turbo C is pretty much out of question.

So in summary I would say that Turbo C is useful if you already have a
Windows installation and you don't, for some reason or other, like
large implementations like MSVC or Cygwin, or you are particular about
checking your code under a 16 bit implementation (not many do this,
IME), or are developing for DOS or some DOS based embedded devices
(again very rare).

I agree that it's a marvellous piece of programming, but then so were
many DOS/CP-M programs of that era.