Should we broaden the topicality of this group?

[Default User]

Philip Potter wrote:

But when the problem is a C problem and not a problem with the
extension-using code, if this isn't the right group, which group is?

Such cases are almost always detected and answered. Perhaps not by the
first responder. Can you produce some examples where such a case was
not correctly answered eventually?




Brian

 

[Keith Thompson]

Kenny McCormack wrote: [SNIP]
Honestly, you are being overly sensitive. I'm sure the vast majority of
participants in this group take that phrase at face value. One thing that
hasn't happened yet to this group is the "Windows vs. Linux (UNIX)" flame
wars found elsewhere. Let's keep it that way.

*Please* don't feed the troll.

 

[santosh]

Richard Heathfield wrote:


I think, but I'm not sure, that some classes in India still use
(recommend?) the old Borland products, including Turbo C. It could be
that they have teaching materials set up to use the extensions from
that.

It's very likely. The main reason would be because the "teachers" were
themselves taught with Turbo C during the 80s and early 90s. A more minor
reason might be that Turbo C is much easier to install under DOS than
DJGPP. A few rather popular indigenous C texts have also used Turbo C.

Thus despite the fact that Turbo C is non-conforming and obsolete, to say
nothing about the system it runs under, most classes here still use it,
invoked from Windows' "DOS Prompt."

Turbo C will run on modern equipment, [ ... ]

Indeed it will, since x86 processors have maintained binary backwards
compatibility.

That doesn't make it a recommended product though.

 

[Keith Thompson]

I guess this proves the point. The regulars are even defensive about
maintaining the purity of the meta-blathering thread of the week, protecting
it against the intrusion of content other than meta-blathering. Yes, I know.
The character/string/macro question is only marginally interesting, which is
why I threw it on this thread to see what would happen.

You said yourself that you were hijacking the thread. I find that
rude.

Since I refuse to post an article consisting only of meta-blather myself,
I'll add some more real stuff.

If you consider this thread to be "meta-blather", why even participate
in it? Why not just start a new thread with a subject that reflects
what you're actually asking about?

It seems to me that you're just being deliberately difficult, and that
your goal is not to get information about C but to disrupt a
discussion that you dislike. Thread topics do drift, and that's fine,
but it's very different from an intentional switch to something that
has nothing whatsoever with anything that's been discussed previously.
And as someone else pointed out, I'm sure a lot of readers have
stopped reading this thread because they're not interested in it
(which is, of course, perfectly fine). Why would you want to exclude
such readers from reading your C question?

I'm not trying to maintain any kind of "purity", just encouraging
people to use (and not to abuse) the tools we already have to organize
a large and active discussion group.

 

[Richard Heathfield]

santosh said:

Thus despite the fact that Turbo C is non-conforming

Not very non-conforming. Good enough for rock n' roll, in fact.

and obsolete,

Foo. If people are still using it, it's still useful.

An excellent little compiler.

 

[santosh]

santosh said:



Not very non-conforming. Good enough for rock n' roll, in fact.


Foo. If people are still using it, it's still useful.

Yes, but it's all a question of proportion. _How_ many programmers are still
using TC? I doubt more than at most about 2 or 3 percent. By your logic a
product/whatever should not be considered obsolete even if one person
happens to find it useful.

An excellent little compiler.

Agreed. I don't want to seem like I dislike TC. I've used it for many years
and it's an excellent piece of programming. However it's age has been
showing for some years now.

 

[J. J. Farrell]

Let's say that he has presented an ANSI C program, but with a terminal
getch().

We all know that Windows compilers tend to run things in temporary shells
that disappear on progream termination, and that this is a fix.

No we don't. Well, we do now but I didn't before I read this. I use
Windows compilers more often than I like, but I've never run a program
from one.

We should
also point out that it renders the program non-portable and is the wrong
answer to the problem.

What we shouldn't do is pretend never to have heard of the getch() function.
This is a techncially correct position which amuses some regulars, but it
irritates others. It is alright from the inside, but it can intimidate
newcomers.

Your point is entirely valid though. I've seen getch() on the end of
some example programs, and made a reasonable guess at what it does
while being puzzled about why it should be done at that point.
However, the poster's problem is often very clear, and unrelated to
any non-Standard or omitted parts of the example. If there's a non-
Standard unsupplied header included, we can't be absolutely certain of
what's going on because we don't know what horrors are hiding in the
header; but in the vast majority of such cases the unknown bits are
not related to the problem. It might be appropriate to say something
like "these bits are non-Standard C, and including them in the example
code might have effects that we don't know about, but it looks very
likely that the problem is 'x'. If that doesn't sort it out, try to
come up with an example of the problem which doesn't include any non-
Standard stuff and post again".

When you can see with near certainty that the problem is a missing
semicolon, or a mis-spelled variable name, it is puerile to send the
poster away because there's a getch() at the end of the code or an
unused inclusion of <conio.h>.

 

[Mark McIntyre]

There's always been some flexibility here. This is a perfectly
friendly newsgroup when people (newbies) remain calm and recognise the
help they're getting for what it is. It's when they fly off the handle
or think everyone owes them something for nothing that we get problems
and topicality wars. Such clueless people should be educated in the
ways of Usenet in general and comp.lang.c in particular, and sent on
their way (to the source of further help).

Well said.

That'll be two cents, thanks.

I'll get my people to email a two-cent note to you....

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

 

[CBFalconer]

Let's say that he has presented an ANSI C program, but with a
terminal getch().

We all know that Windows compilers tend to run things in temporary
shells that disappear on progream termination, and that this is a
fix. We should also point out that it renders the program
non-portable and is the wrong answer to the problem.

What we shouldn't do is pretend never to have heard of the getch()
function. This is a techncially correct position which amuses some
regulars, but it irritates others. It is alright from the inside,
but it can intimidate newcomers.

Fair enough. It would also be worthwhile advising that the getch
is unnecessary, and is more easily replaced by simply running the
object from a CLI window.

 

[Mark McIntyre]

While you can never be /certain/ about code which uses a header you
don't know about, you can be pretty sure that if the poster is trying to
print /any/ pointer as an integer (as the snipped code indicated) that
this is most likely a problem.

I agree - if his questoin was "why does this print garbage?"

If on the other hand, his question was "why does this code not
compile?" the question becomes more interesting.

Perhaps you like to be absolutely sure about everything.

its a dream...
--
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

 

[Richard Heathfield]

santosh said:

santosh said:

and obsolete,

Foo. If people are still using [Turbo C], it's still useful.

Yes, but it's all a question of proportion. _How_ many programmers are
still using TC?

A significant number, to judge by the number of evidently Turbo C based
programs posted here.

I doubt more than at most about 2 or 3 percent.

I don't think such guesstimates mean very much. But let's say you're right.
And let's further say that there are a million people around the world who
program in C (and yes, that's another worthless guesstimate). If your
guess and mine are both right, there are still twenty to thirty thousand
people using Turbo C - quite a lot really.

By your
logic a product/whatever should not be considered obsolete even if one
person happens to find it useful.

<shrug> It's just words. Yes, even if one person happens to find Turbo C
useful, it's still useful *to that one person*. What cares he or she for
its obsolescence or otherwise?

Agreed. I don't want to seem like I dislike TC. I've used it for many
years and it's an excellent piece of programming. However it's age has
been showing for some years now.

<re-shrug> It's a compiler. It produces reasonably tight executable images
in a remarkably short time. It may not be everyone's cup of tea, but it
still works just fine and, in many parts of the world, harsh economic
reality places the likes of Visual Studio beyond the reach of most people.
For them, Turbo C is a cheap and cheerful solution with a usable IDE.

 

[CBFalconer]

These are process standards used on safety critical projects. 61508
for general use and Do178B for airborne. Both are standards that
require the tools used in the development of software are "certified"
(ADA is more commonly used than C for a lot of Do178B work)

So these compilers CBF is suggesting are "faulty" seem to be able
to get "certified" for safety critical use where lives are at stake.

That is how far out of touch CBF is.

No, you seem to be out of touch with c.l.c. Your attitude is fine
on comp.arch.embedded. However here you are discussing some
nebulous non-C compilers, that have some sort of certification for
compiling the unspecified non-C language to some similarly
unspecified runtime environment. From the c.l.c viewpoint the
systems are all faulty. I can safely say the same for Fortran,
Ada, Pascal, Cobol or even Assembly code.

Somehow I doubt that my publishing the performance of my PascalP
compiler on the Pascal Testing Suite in the early 1980s will
encourage people to use it for C code today. That points out the
details of performance (and lack of performance) under both CP/M
and MPE something on the HP3000. At the time it did solidify my
attitude towards using it in medical applications.

 

[CBFalconer]

It is not me who is overly sensitive. Nor is it *me* who is
tempting the fate of a "Windows vs. Linux (UNIX)" flame war.

IOW, you're a lying sack of crap (TM).

Well, you have shown that, even though let out of the PLONK box for
this thread, you are not really a candidate for such gentle
treatment.

 

[Al Balmer]

When you can see with near certainty that the problem is a missing
semicolon, or a mis-spelled variable name, it is puerile to send the
poster away because there's a getch() at the end of the code or an
unused inclusion of <conio.h>.

Agreed, and I don't think it happens, in spite of all those decrying
the practice. It's a red herring.

 

[user923005]

About turbo-C
[snip]

<re-shrug> It's a compiler. It produces reasonably tight executable images
in a remarkably short time. It may not be everyone's cup of tea, but it
still works just fine and, in many parts of the world, harsh economic
reality places the likes of Visual Studio beyond the reach of most people.
For them, Turbo C is a cheap and cheerful solution with a usable IDE.

[snip]

The Watcom C compiler is free and open source.
http://www.openwatcom.org/index.php/Download

The GCC compiler is free and open source.
http://gcc.gnu.org/
On Windows, there is the Mingw version:
http://sourceforge.net/project/showfiles.php?group_id=2435

The Microsoft C compiler (Express) is free:
http://msdn2.microsoft.com/en-us/vstudio/Aa700736.aspx
To do windows stuff, you need the Windows SDK:
http://www.microsoft.com/downloads/...roductID=6F6B7367-A11C-49C3-8CC6-92E74D092146

By contrast, Turbo C is icky(tm).
On the other hand, it is terse and dependable, sort of like C itself.
So maybe not all that icky(tm).

 

[Keith Thompson]

No, you seem to be out of touch with c.l.c. Your attitude is fine
on comp.arch.embedded. However here you are discussing some
nebulous non-C compilers, that have some sort of certification for
compiling the unspecified non-C language to some similarly
unspecified runtime environment. From the c.l.c viewpoint the
systems are all faulty. I can safely say the same for Fortran,
Ada, Pascal, Cobol or even Assembly code.

[...]

Here's where I have to disagree with you, if only on your use of a
single word. Even from the point of view of comp.lang.c, there's
nothing "faulty" about a compiler for something other than C, whether
for it's a C-like language with some non-conforming extensions or for
a different language altogether. The C standard place no constraints
on any implementation that doesn't claim to conform to it.

There is nothing wrong or "faulty" about non-C compilers. They're
just not appropriate subjects for discussion in this newsgroup, that's
all.

 

[CBFalconer]

Default User wrote:
.... snip ...

Turbo C will run on modern equipment, [ ... ]

Indeed it will, since x86 processors have maintained binary
backwards compatibility.

That doesn't make it a recommended product though.

But very handy for checking that code executes correctly on 16 bit
systems.

 

[Philip Potter]

Fair enough. It would also be worthwhile advising that the getch
is unnecessary, and is more easily replaced by simply running the
object from a CLI window.

<OT>Or changing the settings in the compiler so that the output window
doesn't close on program termination.</OT>

 

[Philip Potter]

Such cases are almost always detected and answered. Perhaps not by the
first responder. Can you produce some examples where such a case was
not correctly answered eventually?

No. But it's not enough for a question to be answered eventually; if the
answers were (in the main) aggressive and unhelpful enough, the OP may
be put off asking any more questions here.

(Or they may not. I'm getting into deeply hypothetical territory now,
and I should probably stop.)

 

[Default User]

santosh said:



Not very non-conforming. Good enough for rock n' roll, in fact.


Foo. If people are still using it, it's still useful.

An excellent little compiler.

It certainly works. I used it for several years, including the clunky
IDE. If the instructors have materials and samples that use conio.h
stuff, then it would be an impetus to use TC or some other compatible
Borland product. Not that I think that's a good idea for beginning C
class, of course.




Brian