Exceptions in C/C++

[Richard Heathfield]

jacob navia said:

I have yet to see ANY proposal from the to improve ANYTHING.

That's because the best place to post suggested improvements to the
language is the comp.std.c group. The comp.lang.c group deals with the
language as it is and was. The comp.std.c group deals with what the
language might become.

Even the small improvements of C99 will be rejected (see the
countless posts of Heathfield about how bad C99 is, non portable
whatever)

I do actually think that some of the C99 changes are for the better. For
example, compound literals are a good idea. But yes, portability is still
a big problem for C99.

If you do not repair a house, it will break down and disappear.

Programming languages are not houses.

Programming languages (like all software) must be constantly kept up
to date, things that looked OK are not OK anymore in the ever changing
software environment of TODAY.

If you keep changing the language, you make it impossible (or unprofitable,
which can amount to the same thing) for implementors to keep in step with
the Standard. This has already happened with C99, and it's likely to
happen with any future changes to the language as well. That doesn't mean
that C should stagnate, but it does mean that developers who need to write
portable code will do well to avoid features that are not widely
implemented. So even if you do succeed in getting ISO to adopt your
changes, they are unlikely to be widely implemented or used.

If you insist in living in the past, you can freeze the language like
Heathfield, using a compiler from the last century and feeling clever
with it, like those homeowners that always postpone any repairs
until it is too late.

It is precisely because C is so stable that I can continue to use a
compiler for many years and still be sure that the code I write will work
on implementations that I've never even heard of, but which other people
use regularly. I see that as a good thing.

There is not a engineering argumentation anymore. Heathfield argues that
COBOL still gives you enough to make a living coding for old
applications somewhere.

That isn't what I said.

Obviously he thinks that C should go the same way,

That isn't what I said.

since
there is so much software written in C that until it disappears it will
take a while.

That isn't what I said.

But not the shadow of any engineering argument.

The engineering argument is simple: C is popular at least in part because
it is portable. Making many large changes to the language will make it
harder for implementors to keep up with the language, and so the features
you wish to add won't be used by those writing portable code. Those who
are happy to use non-portable code can *already* use extensions that
implement the changes you want to make.

Heathfield agrees that C is "less visible" and thinks it is a good
thing.

I didn't say I thought it was a good thing. I said I didn't think it
mattered very much. C's future is secure.

No. They are against ANY change. Even C99 is too much change for them.

C99 is too much change for *you* - the implementor. It's EIGHT YEARS since
C99 was published. How many conforming C99 implementations do we have?
Almost none, and even your own implementation doesn't conform to C99.
Programmers *can't* use the full range of features introduced by C99 if
they want their code to remain portable to your implementation (or to MS,
or to Borland, or to gcc...). And now you want to push the goalposts even
further away. That simply doesn't make sense.

<snip>

 

[James Kuyper]

I have yet to see ANY proposal from the to improve ANYTHING.

Well, this is hardly the appropriate place for such proposals; which is
part of the point. Look at comp.std.c and you'll see lots of proposals.
Not many of them come from comp.lang.c regulars, I'll agree. But just
because they don't have suggestions of their own and don't like your
suggestions doesn't mean that they're inherently opposed to good
suggestions.

Even the small improvements of C99 will be rejected (see the
countless posts of Heathfield about how bad C99 is, non portable whatever)

If you would read his messages a little more closely, he's lamenting the
slow rate of adoption of C99, not opposing it's adoption. He's taking
the point of view that until it's fully implemented by widely-used
implementations, he won't make any use of it at all. I think that's a
self-defeating attitude; the more people that use those portions of C99
that can be used, where they can be used, the greater the pressure will
be to implement more of it, and more widely. However, there's a real
cost to being the leading edge, and I can't fault him for not wanting to
pay that cost.

If you do not repair a house, it will break down and disappear.

No one's suggesting that C never be repaired; people just disagree about
which parts need repair, and how urgently, and by what method.

Heathfield agrees that C is "less visible" and thinks it is a good
thing.

"becoming less visible", as he went to great lengths to tell you, means
something very different from "going extinct". You show no sign of
actually having read that explanation.

No. They are against ANY change. Even C99 is too much change for them.

C99 is on topic for this newsgroup; even the one you treat as if he were
Satan Incarnate, Richard Heathfield, has said as much. I've posted C99
code as answers to questions posed in this newsgroup, and met only
minimal objections on the basis of the fact that it wasn't C90.

That would be new. Up to now none of them has said something
like that, but... it is never too late

I think it, I just haven't bothered saying so before. Others have
implied it. Any change that significantly reduces C's simplicity
advantage over C++, while reducing the differences between the two
languages, will reduce the incentives for sticking with C, and several
of your suggestions fall into that category. Other people have pointed
this out as an objection to your suggestions, though not in exactly
those words.

As I told you above, if you do not keep software up to date it just
breaks down and is abandoned. It is NOT that you WANT that, it is
just a fact of life.

Then don't accuse people of actively wanting the language to become
extinct, whose only "crime" has been disagreeing with your assessment of
how urgent the need is to update the language. That's slander, pure and
simple.

 

[William Pursell]

They do not want anything. They want just C89 forever. The language
becomes obsolete, people turn away from it.

People do not necessarily turn away from it.
In the last 2 years, I have turned TO it precisely
because it is simple, clean(arguably), elegant,
and powerful. I (and I speak only for myself...
you seem to have a tendency to group everyone who disagrees
with you into one large homogenous group of "regulars",
which is odd considering that you are certainly a
"regular" by any usual definition of the word)
do not want "C89" forever.
I would love it if C99 were widely implemented.
I would love it if C embraced namespaces. I
would love it if the library added a
"read_my_mind_and_solve_my_problem()"
function, too. That would be great: every program
would be:

int main( void ) { solve_it(); return 1; }

and this entire newsgroup could degenerate into
a discussion of the headers that I left off
and the non-portability of returning 1.

I certainly acknowledge that I am in a minority
for embracing C recently, but there are good
reasons for doing so. The higher level languages
obscure details. Sometimes that is good, sometimes
it is not. Two items in particular that I think
are a bad idea are try/catch and operator
overloading. The former because it is infinitely
abusable and the latter because it inappropriately
hides complexity. I love operator overloading,
and I love try/catch...but not when I am using
C. I think they would harm the language.

 

[William Pursell]

Unable to argue, put forward any arguments.

Typical.

Just hoping that I will disappear, that C will remain in 1989
forever.

Jacob, this is precisely the type of response that
gives people a negative impression of you. The
fact that Brian thinks that discussions with you
are pointless in no way indicates that he is unable
to argue or put forward arguments. It is certainly
understandable for you to take offense at his
description of your ideas as "whacked-out", but
lashing out at him with a personal attack (even
if you consider it to be defensive) does not
help your case.

 

[Keith Thompson]

I have yet to see ANY proposal from the to improve ANYTHING.
Even the small improvements of C99 will be rejected (see the
countless posts of Heathfield about how bad C99 is, non portable whatever)

[...]

It is an unfortunate fact that C99 code is less portable than C90
code, because there are far fewer conforming C99 implementations thatn
conforming C90 implementations. Do you dispute that?

You want C99 to be more widely adopted. So do I. So, I believe, does
Richard.

Because Richard and I are not implementers, there's not much we can do
to make that happen.

You, on the other hand, are an implementer. Updating lcc-win32 to
*fully* support the C99 standard would do more to encourage its
adoption than anything any of us can say here in comp.lang.c or over
in comp.std.c. I'd even seriously consider using lcc-win32 myself.

 

[Keith Thompson]

After a LONG discussion about gets() in comp.std.c,
where I participated with many
others, Mr Gwyn felt necessary to bring the matter to the committee.

He wanted a more modest proposal, where there would be an implicit
BUFSIZE limit for gets().

The committee seized the opportunity and declared gets() obsolete.

Well, obsolescent, not obsolete (there's a difference).

But yes, the discussion took place in comp.std.c, not here in
comp.lang.c.

 

[Bart van Ingen Schenau]

o C++ is *the* monster language.
o Java/C# Proprietary stuff that is slow, memory hungry because
of their virtual machine runtime
o Basic. No standard, you are at the mercy of the changes Microsoft
makes to the language.

The choice of C is because it is a non OO language, that is basically
very simple. What looks like a paradox it is not any: I want to keep the
simplicity of C and *at the same time* I want to enhance it so it
can be used a s a normal programming language.

With the enhancements you proposed, you will bring C closer to those
monster languages you mention. So I can only conclude that you want C
to become a monster language as well.

The way C is headed now is to extinction, and that is what most of the
"regulars" here actually want: a language that is so frozen in its
bugs that all reasonable software developers do not see it as an
alternative.

And with your 'enhancements', the road to extinction becomes only
shorter.
Why use the crippled C++ (that C would become) if you can have the
real deal?
Don't bother answering that. Given the attitude you show, I see no
reason in continuing this discussion.

This is not what I have ever proposed. I proposed 2 major enhancements:
operator overloading, and try/catch. That is all.

In this thread maybe, but in other threads, you proposed other changes
(like GC).

Bart v Ingen Schenau

 

[Nick Keighley]

(e-mail address removed) wrote:


If you do not repair a house, it will break down and disappear.
Programming languages (like all software) must be constantly kept up
to date, things that looked OK are not OK anymore in the ever changing
software environment of TODAY.

this is a very strained analogy. A programming alnguage is not a
house.

If you insist in living in the past, you can freeze the language like
Heathfield, using a compiler from the last century and feeling clever
with it

*last century*? You mean only 7 years ago? I expect some of my
software
to keep running a bit longer than that. Sometimes we are legally
obliged to guarentee that.

There is not a engineering argumentation anymore.

I don't think you are using engineering arguments. If we are going
to follow this sort of argument I'd say you were trying to abolish
the
hexagonal bolt. "It's so last century". Ignoring the vast investment
in hexagonal bolts. And the tools to use them.

As I told you above, if you do not keep software up to date it just
breaks down and is abandoned.

software does not "break down". If you're going to claim to be
using "engineering arguments" then you have to start being more
precise
in your language. For instance no regualr has stated that they want C
to become obsolete. Despite that fact that you keep on claiming it.

It is NOT that you WANT that, it is
just a fact of life.

no, it is an untrue statement.

 

[Default User]

jacob navia said:
[whatever]

It is hardly surprising that some
people no longer see any point in arguing with you.

If only that were true. Seriously.




Brian

 

[Default User]

You make a good point. I think it's important not to let jacob's
misstatements go entirely unanswered, but I'll consider trying not to
engage him in argument as much as I have been.

That sounds good. I completely support correction in that case.




Brian

 

[Default User]

The
fact that Brian thinks that discussions with you
are pointless in no way indicates that he is unable
to argue or put forward arguments.

The main reason is that I have no interest. Some people seem immune to
logic and reasoned discourse. Jacob is one such. I have had him
killfiled for quite some time now.

I really believe that the best thing for the newsgroup is for everyone
to stop arguing with him. Correct his errors and misstatements once, so
that newbies aren't confused, then move on.

I have considered a filter for Jacob's name in the body of any message.
That would indeed clean up things to certain extent for me, but doesn't
help the group overall.




Brian

 

[Steve Thompson]

On Wed, Dec 12, 2007 at 01:11:24AM +0100, jacob navia wrote:
[snip]

Typical.

Many different things are typical on Usenet. Nevertheless...

Just hoping that I will disappear, that C will remain in 1989
forever.

So why don't you write or adopt a C compiler and undertake to maintain it
for as long as you need it? Just asking, of course. If you really need
that language version, maintaining your own C compiler is a course of
action you should put under consideration, IMHO.


Rergards,

Steve

 

[CBFalconer]

.... snip ...

You, on the other hand, are an implementer. Updating lcc-win32 to
*fully* support the C99 standard would do more to encourage its
adoption than anything any of us can say here in comp.lang.c or over
in comp.std.c. I'd even seriously consider using lcc-win32 myself.

You forgot to include the word 'accurate'.

 

[Keith Thompson]

You forgot to include the word 'accurate'.

Um, where? Seriously, I don't understand what you're getting at.

 

[Ed Jensen]

I've been participating in this newsgroup for over a decade, long
enough to remember the Scott Nuds and Portable ASM debacle; I don't
think I need an anonymous troll telling me what to think about
regulars of long standing.

With the success of the JVM, CLR, LLVM, and a plethora of languages
that compile to bytecode...one must wonder if Scott was somewhat
right.

 

[Ed Jensen]

No. They are against ANY change. Even C99 is too much change for them.

C99 is proof that trying to evolve C is probably pointless.

Implementors are already ignoring C99. Even if your suggested changes
became part of a future C standard, chances are implementors would
just ignore that standard, just as they ignore the C99 standard.

Your energies would probably be better spent working on your own
language or perhaps on the D programming language or something.

 

[jacob navia]

C99 is proof that trying to evolve C is probably pointless.

You confirm my sentence above.

Implementors are already ignoring C99. Even if your suggested changes
became part of a future C standard, chances are implementors would
just ignore that standard, just as they ignore the C99 standard.

You confuse this newsgroup and the C language.
IBM, Intel, and many other companies have already
implemented the C99 standard. Do not confuse the
reject of C99 in this newsgroup with the "reject of C99".

Your energies would probably be better spent working on your own
language or perhaps on the D programming language or something.

I think I am old enough to know what I do without having to follow your
advice.

 

[Richard Heathfield]

jacob navia said:

You confirm my sentence above.

No, he doesn't, and - as is so often the case - it is difficult to see how
you derive your conclusion. He is not saying that he, or anyone else in
this group, is against change. He is merely pointing out the practical
reality that even currently-sanctioned changes are not being implemented
by people such as yourself. The people who have demonstrated themselves to
be against changing C are those who have chosen not to make their existing
implementations C99-conforming. This includes you.

 

[Ed Jensen]

You confirm my sentence above.

I'm not against C evolving, I just recognize the fact that even if the
standard evolves, it won't be widely implemented enough to matter.

You confuse this newsgroup and the C language.
IBM, Intel, and many other companies have already
implemented the C99 standard. Do not confuse the
reject of C99 in this newsgroup with the "reject of C99".

You're right that some implementors have implemented C99, but I'm not
sure that's enough to keep C from losing more and more developers.

I think I am old enough to know what I do without having to follow your
advice.

Sorry, Jacob, I didn't mean it to sound offensive, I just think you
have plenty of good ideas and lots of energy that might be better
spent elsewhere.

 

[Richard]

jacob navia said:


No, he doesn't, and - as is so often the case - it is difficult to see how
you derive your conclusion. He is not saying that he, or anyone else in
this group, is against change. He is merely pointing out the practical
reality that even currently-sanctioned changes are not being
implemented

Nice snipping. As usual you sneakily snip to support your own minority
views and try to get one over on Jacob. Where your need to do this comes
from is anybodies guess.

The fact is that there ARE moves to C99.

Whether you like it or not.

http://en.wikipedia.org/wiki/C_(programming_language)#Support_by_major_compilers
http://www.25hoursaday.com/C99.html
http://softwarecommunity.intel.com/articles/eng/2635.htm