On the development of C

[Ian Collins]

You can get most of the functionality of C++ templates via the C
preprocessor.

s/most/a small subset/

 

[Guest]

Kaz Kylheku said:


The design flaws in ggets, or some of them at least, have been
pointed out to the author many times. He seems to regard them as
advantages.

One man's design flaw is another man's design feature.
To some extent design *is* a matter of opionion.
ggets() may be a perfectly reasonable design in some applications.

 

[Richard Bos]

Who guarantees that someone won't run a debugger on your program and
change the value of a variable, so that *any* code becomes unsafe?

Did you read the _whole_ of that post? Including the footnote?

Richard

 

[Richard Bos]

To be a spammer, you have to be posting unsolicited commercial material.
Bollocks.

I suspect you meant troll,

I'm not that stupid.

Richard

 

[Richard Bos]

I don't know if this is you or a nymshifter,

That in itself is telling enough.

but it is pure trolling.

Nonsense. It would be if I wrote it just to irritate you, but in fact I
quite meant what I wrote.

For the benefit of all, ggets is written

....by an idiot, who doesn't even know what trolling means.

Richard

 

[Richard Tobin]

Who guarantees that someone won't run a debugger on your program and
change the value of a variable, so that *any* code becomes unsafe?

[/QUOTE]

Did you read the _whole_ of that post? Including the footnote?

Yes, but I took it to refer to faulty compilers. If you take it to
cover external agents like debuggers, then it seems to invalidate the
whole of your article. You're trying to draw a line between the
program itself and external files, but that is a purely theoretical
line. What matters for assessing safety is not what the standard
guarantees, but what you can rely on in practice.

(Of course, it's not just debuggers. If someone can modify your
intermediate files, they can quite likely replace your program
with a completely different one.)

-- Richard

 

[Richard Tobin]

Aha, but you've missed another edge case yourself, and rather an
important one. Who guarantees - _without_ using OS control
functions outside the purview of the Standard - that the file
you've written isn't changed behind your back? You're guaranteed*
that objects inside your program don't change unless you change
them yourself, or they're volatile. You are given no such
guarantee about files.

[/QUOTE]

Most systems will guarantee that access if you open the file for
read/write, and don't close it.

"Most"? Maybe the systems you use. The systems I use require some
kind of locking (or unlinking) to prevent other programs from opening
the file and modifying it.

-- Richard

 

[roctheengy]

But you get the facts wrong:

(1) gets() is not used a lot.
(2) If it gets (no pun intended) used, it would be anyway better to
    rewrite that code...

ITYM - (1) gets() is not used **much** ?

 

[roctheengy]

Keith Thompson wrote:
[...]
jacob's use of the word "lie" is, as usual, inexcusably rude, but
apart from that he has a valid point.
Well, but then you do not ask WHY Mr McIntyre is doing this?
No.  I'm more interested in why you

Obviously if somebody says that MSVC supports C99
that is not a lie.

Just to be clear, I did not say that. I said, in a post sent at 00:00 on
10/03/09
"gcc is close to claiming C99 conformance. MSVC isn't likely to, but
does support much of C99."

So please, before you make up false statements and attribute them to
others, please remember that posts can be persisted.

So. Mr McIntyre says

MSVC supports C99

Again, I did not say that.

and I said that it is a lie.

Even if I had said that, and as I've already noted I did not, it would
/still/ be offensive.

And YOU say that I am "offensive" because
I tell the truth,

You are offensive because you insult people without cause, tell untruths
and then claim that the other person has done it.

I answer that it is not true and that the person telling that is
telling lies.

The first part is not offensive. The second part is not only offensive,
it is completely unnecessary. If you have a correction to make, make it
without insulting people.

This can't even be put down to language differences. I worked for a
French bank for 10 years, some of that time in Paris, and in all my time
there I never heard anyone call another a liar. Its as offensive to
French as it is to English.

The evidence is the text of McIntyre

"MSVC supports C99"

Again, I didn't say that.

But you did 'contribute' things like: (from your first post on the 9th
in this thread)

" Right - so in other words you made a meaningless, unverifiable and
unquantifiable statement - and all in the context of advertising your
C-like dialect which you believe is superior to C. I think most of us
can see through your point here. "

" You don't even know what "straw man" means, I think. "

" A bit like your own long post then? "

and in your second post (as my reader shows) you say of Jacob:

" I hesitate to point it out but this is a deeply disingenuous
statement, "

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Which, IMHO I would liken 'deeply disingenuous statement' to using the
word "lie". You yourself resorted to using sarcasm initially and in
this thread, I found YOU to be jut as offensive, Mark. I understand
both you and Jacob have your differences, but you both should realize
that neither one of you is going to change the other.

You guys are beating a dead horse and only making an already hard-to-
read thread that much harder to get through. It's unfortunate.

 

[Keith Thompson]

On Mar 11, 6:19 pm, Mark McIntyre <[email protected]>
wrote: [...]
You guys are beating a dead horse and only making an already hard-to-
read thread that much harder to get through. It's unfortunate.

And the point of posting this followup 6 days later is ...?

 

[Tony]

You can get most of the functionality of C++ templates via the C
preprocessor.

"Indeed, I used that trick in "C Unleashed" in chapter 13.
By defining a data type, a new sort routine specific to that data type
is created (types with _P2_ in their name are 'pointer to' types):

ALLSORT.H ( 56): #if defined(E_TYPE_UNSIGNED_INT)
ALLSORT.H ( 58): #elif defined(E_TYPE_SIGNED_INT)
ALLSORT.H ( 60): #elif defined(E_TYPE_UNSIGNED_LONG)
ALLSORT.H ( 62): #elif defined(E_TYPE_SIGNED_LONG)
ALLSORT.H ( 64): #elif defined(E_TYPE_UNSIGNED_CHAR)
ALLSORT.H ( 66): #elif defined(E_TYPE_SIGNED_CHAR)
ALLSORT.H ( 68): #elif defined(E_TYPE_UNSIGNED_LONG_LONG)
ALLSORT.H ( 70): #elif defined(E_TYPE_SIGNED_LONG_LONG)
ALLSORT.H ( 72): #elif defined(E_TYPE_FLOAT)
ALLSORT.H ( 74): #elif defined(E_TYPE_DOUBLE)
ALLSORT.H ( 76): #elif defined(E_TYPE_LONG_DOUBLE)
ALLSORT.H ( 78): #elif defined(E_TYPE_P2_UNSIGNED_INT)
ALLSORT.H ( 80): #elif defined(E_TYPE_P2_SIGNED_INT)
ALLSORT.H ( 82): #elif defined(E_TYPE_P2_UNSIGNED_LONG)
ALLSORT.H ( 84): #elif defined(E_TYPE_P2_SIGNED_LONG)
ALLSORT.H ( 86): #elif defined(E_TYPE_P2_UNSIGNED_CHAR)
ALLSORT.H ( 88): #elif defined(E_TYPE_P2_SIGNED_CHAR)
ALLSORT.H ( 90): #elif defined(E_TYPE_P2_UNSIGNED_LONG_LONG)
ALLSORT.H ( 92): #elif defined(E_TYPE_P2_SIGNED_LONG_LONG)
ALLSORT.H ( 94): #elif defined(E_TYPE_P2_FLOAT)
ALLSORT.H ( 96): #elif defined(E_TYPE_P2_DOUBLE)
ALLSORT.H ( 98): #elif defined(E_TYPE_P2_LONG_DOUBLE)
ALLSORT.H ( 100): #elif defined(E_TYPE_STRING)
ALLSORT.H ( 102): #elif defined(E_TYPE_COLLATED_STRING)
ALLSORT.H ( 107): #endif /* defined(E_TYPE_... */"

I've never had any such verbose obstrosity while using the preprocessor to
implement generics. Perhaps your design is wrong?

"However, it is a very poor substitute for templates."

Perhaps templates are a very poor implementation of generics!

Tony

 

[Tony]

s/most/a small subset/

Simple and elegant are key, IMO. "Moving generics into the compiler for
unending exploitation" is bad, IMO (but I'm not trying to sell compilers).

Tony

 

[Ian Collins]

Simple and elegant are key, IMO. "Moving generics into the compiler for
unending exploitation" is bad, IMO (but I'm not trying to sell compilers).

Macro solutions may be simple, but they can be far from elegant and a
nightmare to debug and maintain.

 

[Tony]

Why C?

What's your point? I think you are being facetious (not a bad thing, not
necessarilly good either, just neutral at the outset). I've looked at your
string library. I have to go back and look at it because I don't remember
(if I don't remember, it probably means I rejected it for some reason) much
more than that I looked at it because I too think null-terminated strings
are baggage and were a wrong design choice (I think "the quest for the holy
grail of generality" bit them). (I found another compelling reason for
non-null terminated strings just today, which I'm sure you already know
about, but I am just saying).

Before I even read anymore, I think you may be "selling"? Go for it if so.
I'm developing my own language and I know many others are too. First one to
build a toolkit for language designers wi... well, will be the first one to
give away such a thing (Intel?).

So, I'll snip the rest and perhaps respond to the "facetious" points (but
don't count on it).

Regards,

Tony

 

[Tony]

Why C?

With the development of the c++ language, c was destroyed.

No, not destroyed, stagnated.

Destroyed in the sense that all language development ceased,

Of C, but you didn't say C. Major ommission. I assure you that "all language
development" did not cease.

and "naturally" all developpers changed horses to the "new and improved"
c++,

I used C for a "long" time before migrating to C++. In retrospect,
nevermind!

leaving c as a bad souvenir or at best a curiosity to be used in embedded
systems or similar environments where c++ doesn't cut it.

It's still a jumping off point. That's a lie, in that I don't believe it is
that. The concepts are a good jumping off point. The implementation sucks.

Many c++ books (specially some older ones) start with a chapter telling
people how bad C is, and why c++ solves all the problems of c. Of course
this is not very difficult to do since c remained as it was in 1989,
without any change.

C++ is indeed not "a better C", IMO. I'll go farther: C++ isn't a good GP
language because of it's heritage to C.

Still, I think that c can be a very good language precisely because of its
simplicity.

For us "oldtimers"? Aren't the "new languages" the kids' "rock and roll"?

It is the only high level language where there isn't any "object oriented"
framework that has been implemented in most current languages, from java
to cobol.

Cobol does OO now? (Just a blast from the past... I think they used to kid
me about structures because they said they came from Cobol... they called
them "records". I remember that day well. 1995. (There's a hidden story that
I'm not telling here.))

What are the main issues with C?

That's the wrong question, of course, IMO. "What can be learned or salvaged
from C?", seems more appropriate.

(1) The obsolete c library.

I've NEVER liked it!!! Good riddens! Bury it or drive a wooden stake into
it.

===========================
The c library is part of the language

Not really though, I am using C++ and replacing the std library with my own
library. Similar applies to C std lib.

and it was one of the first standardized, portable implementation of a
language across a number of computers.

Nope. It's the UNIX API. That is all it is. I abstract it less than Win32
API because is far less relevant to me. Nonetheless (is that one word?), the
ISO lib is just another platform (UNIX), IMO.

Its main problems are:

1.1: No support for standard containers like lists or hash tables

I don't see that as a problem at all. I don't think the comittee should be
in the library business. They language definition probably suffers because
of that. Need a container? I recommend Cormen (NOT Knuth!).

1.2: A completely obsolete representation of strings.

"obsolete"? I'm looking into it now, but I think, hardly "obsolete", rather,
bad design!

1.3 Wrongly specified and buggy library functions.

Library should not be part of a language specification, IMO.

2: Language issues
==================

(2.1) It is impossible to create new numeric types

Did you mean that "typedef" is brain-damaged? If so, I agree. (See Ada 2005
for a solution).

(2.2) It is impossible to create another type of strings
------------------------------------------------------
Many libraries exist that implement counted strings, but they all
require the user to forget the natural notation str[5] = 'a' and adopt
a cumbersome notation in the style of:

asgnstr(str,5,'a');

I don't think that is hardly the issue at all. It may be secondary, or
tertiary or... I don't know. But I know it is hardly primary.

3: The proposed solutions
=========================
3.1 The solutions to the language problems.

In the lcc-win compiler I have developed a solution to the language
problems, that simplifies the language and at the same time opens it up
to the user.

Sounds like a NON-solution from the get-go. D is the opposite track, but
still fails. Go figure. Hmm. "Have C compiler, can travel" mantra? (What's
wrong with this picture?"). Which one of these is not like the other...
sorry, I digress.

Operator overloading is an accepted technique in many languages,

It's also condemned for it's potential and common form that makes
cryptic/unmaintainable code.

from the venerable FORTRAN to C#. lcc-win proposes this solution to:

o Develop new kinds of numbers.

For numerics, good. C++ has overloaded operators.

3.2 The solutions to the library problems.
------------------------------------------
Microsoft has proposed a set of more secure functions that should
replace the unsecure ones. The particular definitions of those library
functions aren't so much interesting in this context. What *IS*
relevant is that the error analysis is an integral part of the
specifications.

Hmm. Kinda suspect. Why? Because you are focusing on "throwing errors over
the wall" rather than good design.

All arguments allowed value ranges are described,

Ada2005 has "constraints".

and
the possible errors enumerated. The language should take this way of
specifying the functions inthe library as a guideline to be used in the
specifications of ALL functions in the library.

No one has agreed upon error handling machinery though. Are you suggesting
just by specifying a general approach that the problem is solved? (I'm using
modern-traditional techniques over C++ exceptions and I am developing in C++
(granted, not in a production context right now)).

The new C standard

Ahhhh! So if you thought "a new C standard" is relevant, why didn't you just
say so! (I think "C is mortally wounded").

should specify an interface for containers like lists
or hash tables.

I disagree.

Again, I have developed basic examples in the lcc-win
compiler.

So I'll of course disagree with those container implementations also.

Conclusion
==========

The proposed changes do not alter fundamentally the nature of C.

As you have noted: a NON-solution.

They are very small and maintain the essential simplicity of the
language.

"Life support"? Unplug the respirator already!

True, C is simple.
False.


But, as Einstein said, things should be as simple as possible but not
simpler.

Appeal to long-and-hard-thinker, non-sequitur.

Tony

 

[Tony]

Macro solutions may be simple, but they can be far from elegant and a
nightmare to debug and maintain.

We are agreed that solutionn is yet to be found. Yes? (Facetious: I can do a
lot with a good preprocessor. Language VENDORS ("committee") ....
nevermind.)

Tony

 

[Tony]

There are absolutely no new language features in C99.

Who cares about that? Have compiler and now dying? So let it be written.
RIP.

 

[roctheengy]

On Mar 11, 6:19 pm, Mark McIntyre <[email protected]>
wrote: [...]
You guys are beating a dead horse and only making an already hard-to-
read thread that much harder to get through.  It's unfortunate.

And the point of posting this followup 6 days later is ...?

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

I don't get to read everything written every day and respond
instantly. At this point in the thread (and beyond) I felt no one had
realized Mark essentially said the same thing as "lie" to Jacob and I
wanted to point it out.

Do I need to be timely to make a point?

 

[Keith Thompson]

On Mar 11, 6:19 pm, Mark McIntyre <[email protected]>
wrote: [...]
You guys are beating a dead horse and only making an already hard-to-
read thread that much harder to get through.  It's unfortunate.

And the point of posting this followup 6 days later is ...?

[....]

(Please don't quote signatures.)

I don't get to read everything written every day and respond
instantly. At this point in the thread (and beyond) I felt no one had
realized Mark essentially said the same thing as "lie" to Jacob and I
wanted to point it out.

Do I need to be timely to make a point?

No, but in this case I felt that you were pouring gasoline on a fire
that had already fizzled out.

 

[Guest]

It's still a jumping off point. That's a lie, in that I don't believe it is
that. The concepts are a good jumping off point. The implementation sucks..

I have constant difficulty understanding your posts. *What's* a
"jumping
off point"? C? Do you mean C is a good base for the design of a
language?

For us "oldtimers"? Aren't the "new languages" the kids' "rock and roll"?
what?


Cobol does OO now? (Just a blast from the past... I think they used to kid
me about structures because they said they came from Cobol... they called
them "records". I remember that day well. 1995. (There's a hidden story that
I'm not telling here.))

I think you *always* have a hidden story that you're not telling. I
sometimes
think you must be passing secret messages to some third party.

That's the wrong question, of course, IMO. "What can be learned or salvaged
from C?", seems more appropriate.

I think Jacob wants to extend C

I've NEVER liked it!!! Good riddens! Bury it or drive a wooden stake into
it.

I quite like it.

Not really though,

yes, really. Lots of things other languages put in the language
C puts in the library. The core C language is very small.

I am using C++ and replacing the std library with my own
library. Similar applies to C std lib.

well if you want to, go for it.

Nope. It's the UNIX API.

no it isn't. It really is a highly portable general purpose library.

That is all it is. I abstract it less than Win32
API because [it] is far less relevant to me. Nonetheless (is that one word?), the
ISO lib is just another platform (UNIX), IMO.

Its main problems are:

1.1: No support for standard containers like lists or hash tables

I don't see that as a problem at all.

since you don't think the library should be standardised this doesn't
surprise me!

don't think the comittee should be
in the library business. [he]language definition probably suffers because
of that.

I disagree. Actually many language standards (most language
standards?)
include a library. Ada, Scheme, Algol-68, python, Java, perl.
Ones that don't (or are very small) Pascal, Coral, Algol-60

Did you mean that "typedef" is brain-damaged? If so, I agree. (See Ada 2005
for a solution).

No, he means things like complex and bignum

I don't think that is hardly the issue at all. It may be secondary, or
tertiary or... I don't know. But I know it is hardly primary.

what is the issue then? I'm not necessarily agreeing with Jacob
but at least I know what's he's talking about.

Sounds like a NON-solution from the get-go.

in what way is a non-solution? JN what's to extend and expand C
to rescue it from he perceives as it stagnation. In what way is that
a non-solution?

D is the opposite track, but
still fails. Go figure. Hmm. "Have C compiler, can travel" mantra? (What's
wrong with this picture?").

it's word-salad?

Which one of these is not like the other...
sorry, I digress.


Hmm. Kinda suspect. Why? Because you are focusing on "throwing errors over
the wall" rather than good design.

"you" (Jacob) or "they" (Microsoft)?

Ada2005 has "constraints".


No one has agreed upon error handling machinery though. Are you suggesting
just by specifying a general approach that the problem is solved? (I'm using
modern-traditional techniques over C++ exceptions and I am developing in C++
(granted, not in a production context right now)).


Ahhhh! So if you thought "a new C standard" is relevant, why didn't you just
say so! (I think "C is mortally wounded").


As you have noted: a NON-solution.
?


"Life support"? Unplug the respirator already!


why?



Appeal to long-and-hard-thinker, non-sequitur.

?