Hello,
I have question concerning such code:
__try
{
...
} __except(EXCEPTION_EXECUTE_HANDLER)
{
printf("Exception code: %.8x\n", GetExceptionCode());
}
Is C related code? Or maybe C++?
opexoc
Dec 7 '07
142 3790
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
--
Come to the Internet! See the savagery and viciousness underlying the
sleek facade of the hi-tech world. Travel to new places and do new things!
Enjoy feelings that would otherwise never occur if it were not for the
Internet.
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
[...]
>I have yet to see ANY proposal from the to improve ANYTHING.
.... 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'.
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites: [...]
>>I have yet to see ANY proposal from the to improve ANYTHING.
... 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'.
Um, where? Seriously, I don't understand what you're getting at.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Charlton Wilbur <cw*****@chromatico.netwrote:
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. ;)
jacob navia <ja***@nospam.comwrote:
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.
Ed Jensen wrote:
jacob navia <ja***@nospam.comwrote:
>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.
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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia said:
Ed Jensen wrote:
>jacob navia <ja***@nospam.comwrote:
>>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.
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.
--
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
jacob navia <ja***@nospam.comwrote:
>>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.
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.
>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".
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.
>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.
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 Heathfield <rj*@see.sig.invalidwrites:
jacob navia said:
>Ed Jensen wrote:
>>jacob navia <ja***@nospam.comwrote: 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.
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
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_(prog...ajor_compilers http://www.25hoursaday.com/C99.html http://softwarecommunity.intel.com/a...s/eng/2635.htm
Ed Jensen wrote:
jacob navia <ja***@nospam.comwrote:
>>>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.
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.
>>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".
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.
The problems that C has are fixable, and the
interest that simple languages arise is a proof that
a simple language is better for many applications than an overly
complex one like C++.
My compiler system has been downloaded more than 500 000
times in our main distribution site. Not counted there
are all the other downloads in other sites. Last week end
we went past the 2 000 downloads over a weekend.
C is interesting for many people. Many user of lcc-win
like it because it is so simple, small and efficient,
like the language it implements.
>>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.
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.
Ok, do not worry. I think my energies are well spent here because
what I want is to convince people. If you try to convince people
that already agree with you, nothing is gained.
:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On 17 Dec 2007 at 18:34, jacob navia wrote:
My compiler system has been downloaded more than 500 000
times in our main distribution site. Not counted there
are all the other downloads in other sites. Last week end
we went past the 2 000 downloads over a weekend.
"1,000,000 heroin addicts can't be wrong!"
(seen on a tee shirt)
CJ wrote:
On 17 Dec 2007 at 18:34, jacob navia wrote:
>My compiler system has been downloaded more than 500 000 times in our main distribution site. Not counted there are all the other downloads in other sites. Last week end we went past the 2 000 downloads over a weekend.
"1,000,000 heroin addicts can't be wrong!"
(seen on a tee shirt)
Well... thanks.
I know my compiler is addictive but I never dared to tell anyone.
:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Ed Jensen wrote:
>jacob navia <ja***@nospam.comwrote:
>>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.
You confirm my sentence above.
Pointing out that changes to the standard don't seem to be effective in
creating changes in real-world compilers is a very different thing from
saying that changes are bad.
James Kuyper wrote:
jacob navia wrote:
>Ed Jensen wrote:
>>jacob navia <ja***@nospam.comwrote: 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.
You confirm my sentence above.
Pointing out that changes to the standard don't seem to be effective in
creating changes in real-world compilers is a very different thing from
saying that changes are bad.
Well, let's hope that this was the Ed's intent. Personally I do not
think that trying to evolve C is pointless.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
....
Since C99 left the standard library virtually
untouched (and this is one of the main problems with C)
Entirely new headers include <iso646.h>, <complex.h>, <tgmath.h>,
<inttypes.hand <stdint.h>, <stdbool.h>. Changes were made to <float.h>
and <stdarg.h>. Substantial additions were made to the format strings
used by the printf() family. The vscanf() and snprintf() families of
functions were added to <stdio.h>. The single biggest and most important
library change was the addition of a huge number of functions to the
<math.hlibrary.
If what you're complaining about is that they didn't make the changes
you think should have been made, then say so. But please don't try to
suggest that they made almost no changes.
Richard Heathfield <rj*@see.sig.invalidwrites:
<shrugIt needs to lose gets(), ato*(), and perhaps one or two others, but
it's more or less there. qsort, bsearch, and strtok all need updating (or
rather, new versions need to be written, complete with new names).
The biggest problem with ato*() is the undefined behavior upon
out-of-range values. Thus, I think that ato*() could be saved
simply by requiring them to be implemented as the obvious
wrappers around strto*(). Many implementations do so anyhow.
--
Ben Pfaff http://benpfaff.org
James Kuyper wrote:
jacob navia wrote:
...
>Since C99 left the standard library virtually untouched (and this is one of the main problems with C)
Entirely new headers include <iso646.h>,
This is iso646.H
#define and &&
#define and_eq &=
#define bitand &
#define bitor |
#define compl ~
#define not !
#define not_eq !=
#define or ||
#define or_eq |=
#define xor ^
#define xor_eq ^=
And you tell me that this is a BIG STEP FORWARD ???
<complex.h>,
Complex numbers make the language heavier without solving the
problem of how to add new numeric types to the language.
<tgmath.h>,
Generic functions is a GREAT idea ("tg" stands for type generic")
but it wasn't incorporated to the language but *only* to some
functions!
<inttypes.h>
Well, there is nothing spectacular there. Useful yes.
and <stdint.h>, <stdbool.h>.
bool is a good idea.
Changes were made to <float.h>
and <stdarg.h>.
Nothing substantial really.
Substantial additions were made to the format strings
used by the printf() family.
No. Only long long and long double support, if I recall correctly.
The vscanf() and snprintf() families of
functions were added to <stdio.h>. The single biggest and most important
library change was the addition of a huge number of functions to the
<math.hlibrary.
Yes, but erf() lgamma and others aren't really essential to the
language itself.
If what you're complaining about is that they didn't make the changes
you think should have been made, then say so. But please don't try to
suggest that they made almost no changes.
If you reread my message I never said they made no changes!
I have been trying to implement libraries and language modifications
since a long time and it is hard, really. The last weekend I
implemented
int fn(void)
{
int array[] = { 1,2,3, SomeFunction(56),88,66 };
}
And it took me a LOT of time to do that without breking the small
compiler I distribute.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
In article <fk**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>The main errors of C99 were:
1) The obsolete C library (not even gets() was taken out)
2) The bad string data type was mainteinaed without any
real alternative even considered...
3) The error prone malloc/free system was left untouched.
Not the most evident enhancements (size of an allocated
block returned in a library function call) were
introduced. size_t malloc_sizeof(void *);
I don't think those are the problems at all. Removing gets() would
not have any real world effect. If you don't like the strings, then C
is probably not your language. Likewise malloc() and free(), though I
have nothing against optional garbage collection. The ability to find
the size of an allocated block is only of the tiniest use.
I think the problem is that the changes weren't of much interest. Complex
numbers are needed only by a tiny corner of the C community, and could have
been provided by a completely separate standard. Similarly the floating
point stuff. Variable-length arrays are useful, but not so useful as to
justify C90-incompatibility in themselves, for most programmers. There's
just no compelling reason for most users to change.
-- Richard
--
:wq
Richard Tobin wrote:
In article <fk**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>The main errors of C99 were:
1) The obsolete C library (not even gets() was taken out)
2) The bad string data type was mainteinaed without any real alternative even considered...
3) The error prone malloc/free system was left untouched. Not the most evident enhancements (size of an allocated block returned in a library function call) were introduced. size_t malloc_sizeof(void *);
I don't think those are the problems at all. Removing gets() would
not have any real world effect. If you don't like the strings, then C
is probably not your language. Likewise malloc() and free(), though I
have nothing against optional garbage collection. The ability to find
the size of an allocated block is only of the tiniest use.
That would allow to BOUNDS CHECK an object access!
That is not "tiny" (at least in my opinion :-)
The problem NOW is given a pointer to a malloced object there is no
way to know how big it is to verify that accessing a given offset will
be out of bounds or not!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Richard Heathfield wrote:
jacob navia said:
....
>o Complex numbers. This can be done as a result of operator overloading much more easily. As they are now, they add another 3 types of numbers to the already quite rich number zoo.
Better still, just leave them out completely. People who need complex
numbers will have no difficulty implementing them using structs and
doubles.
Implementing even ordinary arithmetic for complex numbers has pitfalls.
Naive implementations of complex multiplication or division are prone to
unnecessary overflows and loss of precision. The transcendental
functions are much worse. Only a very small percentage of programmers
ever have a need to call a transcendental function with a complex
argument, but that small percentage is still a large number of
programmers. It is a much larger number than the number of programmers
who have the expertise needed to implement such functions reliably,
efficiently, and accurately. I don't have that expertise; I know just
enough about the pitfalls to be glad that I can rely upon someone else,
hopefully substantially better qualified than I am, to have implemented
those functions correctly.
The language-level support of complex numbers opened up C for the first
time as a reasonable alternative to languages such as Fortran for
certain kinds of numerical work. Implementation as structs would have
required such horribly convoluted code, unless C++ features such as
references and operatore overloads were added as well. Whether the
group of people who benefited was large enough to justify adding complex
math to the language is a different question, but there was little point
in doing it at any level other than direct support in the language itself.
On 17 Dec 2007 at 20:23, jacob navia wrote:
3) The error prone malloc/free system was left untouched.
Not the most evident enhancements (size of an allocated
block returned in a library function call) were
introduced. size_t malloc_sizeof(void *);
With due respect, this is an idiotic suggestion. The programmer knows
what parameter he passed to malloc, so he already knows the allocated
size without needing a special library function to tell him.
CJ wrote:
On 17 Dec 2007 at 20:23, jacob navia wrote:
>3) The error prone malloc/free system was left untouched. Not the most evident enhancements (size of an allocated block returned in a library function call) were introduced. size_t malloc_sizeof(void *);
With due respect, this is an idiotic suggestion. The programmer knows
what parameter he passed to malloc, so he already knows the allocated
size without needing a special library function to tell him.
A conforming implementation is free to allocate a block larger than
requested; most real implementations do so. Some implementations round
upward to the next multiple of a fixed block size. Some implementations
round upward to the next power of 2.
On 17 Dec 2007 at 23:48, James Kuyper wrote:
CJ wrote:
>On 17 Dec 2007 at 20:23, jacob navia wrote:
>>3) The error prone malloc/free system was left untouched. Not the most evident enhancements (size of an allocated block returned in a library function call) were introduced. size_t malloc_sizeof(void *);
With due respect, this is an idiotic suggestion. The programmer knows what parameter he passed to malloc, so he already knows the allocated size without needing a special library function to tell him.
A conforming implementation is free to allocate a block larger than
requested; most real implementations do so. Some implementations round
upward to the next multiple of a fixed block size. Some implementations
round upward to the next power of 2.
Are you suggesting that the programmer should concern himself with the
internal implementation details of malloc()?
The only conceivable uses I can think of are:
1) the programmer has allocated some memory and needs a bit more, so
does something like
if(actually_allocated(p) >= WHAT_I_NEED_NOW)
/* do nothing! */
else
/* use realloc on p */
but in this case, if enough memory has already secretly been assigned by
malloc then the realloc() call is likely to be of negligible cost
anyway.
2) misguided attempts at bounds checking:
void some_library_function(char * mallocd_pointer, size_t index)
{
if(index >= actually_allocated(mallocd_pointer))
/* go boom */
...
}
This has two problems: a) the function can only accept a pointer
returned by malloc() ; b) if the programmer got lucky and supplied an
index that was beyond the memory he knew he had available, but which
just happened to lie inside the additional memory his particular
malloc() implementation had assigned, this would disguise the bug in his
code and likely make it extremely difficult to find and fix.
CJ wrote:
On 17 Dec 2007 at 23:48, James Kuyper wrote:
>CJ wrote:
>>On 17 Dec 2007 at 20:23, jacob navia wrote: 3) The error prone malloc/free system was left untouched. Not the most evident enhancements (size of an allocated block returned in a library function call) were introduced. size_t malloc_sizeof(void *); With due respect, this is an idiotic suggestion. The programmer knows what parameter he passed to malloc, so he already knows the allocated size without needing a special library function to tell him.
A conforming implementation is free to allocate a block larger than requested; most real implementations do so. Some implementations round upward to the next multiple of a fixed block size. Some implementations round upward to the next power of 2.
Are you suggesting that the programmer should concern himself with the
internal implementation details of malloc()?
No, I'm not advocating this change, just explaining it. Requiring an
implementation to report the actual size of an allocation is much less
of an imposition than requiring it to report the requested size.
Currently, most implementations where there is a difference between the
requested and actual size, keep no record of any kind about the
requested size. Requiring that they report the requested size would add
to the amount of information they would be required to store.
jacob navia <ja***@nospam.comwrites:
Ed Jensen wrote:
>jacob navia <ja***@nospam.comwrote:
>>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.
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".
[...]
Really? They've *fully* implemented the C99 standard? If so, that's
good news (but I'd like to hear it from a reliable source).
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson said:
jacob navia <ja***@nospam.comwrites:
<snip>
>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".
[...]
Really? They've *fully* implemented the C99 standard? If so, that's
good news (but I'd like to hear it from a reliable source).
It depends on your definition of "many". There are some C99-conforming
implementations about, but they are few and far between. The suggestion
that the industry has embraced C99 is laughable, and those of us (such as
myself) who have expressed apathy towards C99 have generally done so
because C99 programs cannot be considered to be widely portable, precisely
because C99 is not widely implemented.
It is up to implementors. If they want C programmers to use C99, they must
take the lead by providing implementations. Some have done so, but too
few. Until, at the very least, GNU C (i.e. gcc and glibc together) and
Microsoft C conform to C99, there is no point in using its features in
code where portability is a high priority.
--
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
Richard Heathfield wrote:
Keith Thompson said:
>jacob navia <ja***@nospam.comwrites:
<snip>
>>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".
[...]
Really? They've *fully* implemented the C99 standard? If so, that's good news (but I'd like to hear it from a reliable source).
It depends on your definition of "many". There are some C99-conforming
implementations about, but they are few and far between. The suggestion
that the industry has embraced C99 is laughable, and those of us (such as
myself) who have expressed apathy towards C99 have generally done so
because C99 programs cannot be considered to be widely portable, precisely
because C99 is not widely implemented.
The only incentive I've seen to implement parts of C99 is POSIX
requiring them.
--
Ian Collins.
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>jacob navia <ja***@nospam.comwrites:
<snip>
>>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".
[...]
Really? They've *fully* implemented the C99 standard? If so, that's good news (but I'd like to hear it from a reliable source).
It depends on your definition of "many". There are some C99-conforming
implementations about, but they are few and far between.
[...]
Are you saying that IBM and Intel have fully implemented C99? And
whether you're saying it or not, have they? And in which compilers?
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson said:
Richard Heathfield <rj*@see.sig.invalidwrites:
<snip>
>There are some C99-conforming implementations about, but they are few and far between.
[...]
Are you saying that IBM and Intel have fully implemented C99? And
whether you're saying it or not, have they?
Well, I don't know about Intel, but IBM appear to have gained C99
certification for their XL and VisualAge compilers. Other companies on the
list are Dinkumware (for their library, obviously), Edison, Lund, and Sun.
And in which compilers?
See http://www.peren.com/pages/cvsa_isocvpl.htm
The absence of Microsoft, Borland, and especially GNU from that list is
significant.
--
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
Nick Keighley wrote:
On 17 Dec, 18:24, Richard <rgr...@gmail.comwrote:
>Richard Heathfield <r...@see.sig.invalidwrites:
jacob navia said: Ed Jensen wrote: jacob navia <ja...@nospam.comwrote:
>>>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.
>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
Nice snipping.
did Richard heathfield do the 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.
<snip>
this undermines your claim (I'm guessing the page is quite old
(so why quote it?))
<snip>
Here is a webpage that claims to list fully conforming C99 compilers. I
suspect the inclusion of the Intel C++ compiler in that list.
<http://geocities.com/avsharath/c99compilers.htm>
Basically, C started as a systems programming language and is once
again, presently, largely a systems programming language. For many
years it was widely used for end user applications, but C++ and Java
have increasingly encroached this segment. Given the power of modern
systems C is unlikely to be used for writing complete end user
applications for the PC market.
Given this scenario it is not hard to understand why C99 has failed so
remarkably in uptake, as compared with the earlier standard. It offers
little to systems programming and even lesser to end user application
programming. Much of the additions of C99 have to do with numerical
work, but I doubt that it is widely used in this area as well.
Certainly, very few programmers have found C99's extensions to be
indispensable or invaluable. In comparison, many of C89's
standardisations were very useful.
C99 is virtually worthless to implement for Microsoft and Borland, given
that they are advocating the use of C#/.NET, in preference to even C++.
The few compilers that have taken pains to implement the C99 standard
(for example Comeau, IBM XL, gcc etc.), have done so almost as an
altruistic afterthought. Certainly, I doubt that the sales or
popularity of their compilers would have significantly suffered if they
have completely ignored C99.
C99 is largely a failure, as the Committee seems to have not given
sufficient thought to "why" their Standard would actually be
implemented. The best thing they can do now is to not yield to "special
interest groups" and include even more features that will be
disparately implemented, but rather, be very conservative with
additions. They could perhaps consider deprecating or removing the
least implemented parts of C99, but that may be too much, as it would
break backwards compatibility. Also further efforts for compatibility
with C++ would be nice.
I think that C has pretty much evolved as much as it could. Minor
changes are ignored by many significant implementors while major
changes (like thread support or jacob's proposals), lack any consensus
to be standardised and implemented.
Keith Thompson wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Keith Thompson said:
>>jacob navia <ja***@nospam.comwrites:
<snip>
>>>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". [...]
Really? They've *fully* implemented the C99 standard? If so, that's good news (but I'd like to hear it from a reliable source).
It depends on your definition of "many". There are some C99-conforming implementations about, but they are few and far between.
[...]
Are you saying that IBM and Intel have fully implemented C99? And
whether you're saying it or not, have they? And in which compilers?
Yes, PERENNIAL have validated IBM's C99 implementation, as they have for
Dinkum/EDG, Sun, and Lund. http://www.peren.com/pages/cvsa_set.htm
I have not seen a similar list from Plum Hall, but my guess is that
their list of C99 validated compilers, is non-empty too.
IIRC, Intel do claim C99 conformance with the -Za switch.
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
jacob navia wrote:
>
.... snip ...
>
Since C++ is the better C, there is no need to improve C, and C99
was ignored.
The main errors of C99 were:
1) The obsolete C library (not even gets() was taken out)
Much of the library has to be system specific. It is one thing to
build a library for X86 use. It is quite another to build
libraries for all the systems (even the majority) that gcc already
supports. Almost all the purely compiler work for the gcc system
has been done.
You are not capable of ignoring gets() when writing software? You
could use ggets, which is not standard, but will compile on any
standard system. It will duplicate the ease of use of gets,
without the problems. See:
<http://cbfalconer.home.att.net/download/>
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Ed Jensen wrote:
jacob navia <ja***@nospam.comwrote:
>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.
No, they simply are not willing to put in the effort. I suspect
that once the gcc library problems are solved the presence of that
one will galvenize a few more. Of course, attempts to go off in
un-approved peculiar directions will incompatible extensions do not
help.
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
James Kuyper wrote:
jacob navia wrote:
...
>Since C99 left the standard library virtually untouched (and this is one of the main problems with C)
Entirely new headers include <iso646.h>, <complex.h>, <tgmath.h>,
<inttypes.hand <stdint.h>, <stdbool.h>. Changes were made to
<float.hand <stdarg.h>. Substantial additions were made to the
format strings used by the printf() family. The vscanf() and
snprintf() families of functions were added to <stdio.h>. The
single biggest and most important library change was the addition
of a huge number of functions to the <math.hlibrary.
iso646.h has been available since C95.
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Richard Heathfield wrote:
>
.... snip ...
>
It is up to implementors. If they want C programmers to use C99,
they must take the lead by providing implementations. Some have
done so, but too few. Until, at the very least, GNU C (i.e. gcc
and glibc together) and Microsoft C conform to C99, there is no
point in using its features in code where portability is a high
priority.
Microsoft won't. They have gone off on their .net and C# stuff, so
have no interest. Gnu will eventually get there, but the problem
is the large variety of systems to be served. It is not as easy as
revising the compiler. Not only does a customized library have to
be created, it has to be issued, and available on the destination
machine.
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer said:
Richard Heathfield wrote:
>>
... snip ...
>> It is up to implementors. If they want C programmers to use C99, they must take the lead by providing implementations. Some have done so, but too few. Until, at the very least, GNU C (i.e. gcc and glibc together) and Microsoft C conform to C99, there is no point in using its features in code where portability is a high priority.
Microsoft won't. They have gone off on their .net and C# stuff, so
have no interest.
I agree. Hence, C99 is de facto dead in the water.
Gnu will eventually get there,
I don't share your confidence. I don't think they care enough. I think
they'll get to the point (if they haven't already) where they say "this
far we will go to accommodate the ISO folks... but NO FURTHER!", because
of conflicts where they genuinely believe that the existing GNU feature is
superior to the C99 equivalent. I suspect this has already happened. For
example, I don't suppose GNU's VLAs will ever be "fixed" to be
C99-conforming.
--
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
In article <47***************@yahoo.com>,
CBFalconer <cb********@maineline.netdecreed:
....
>one will galvenize a few more. Of course, attempts to go off in un-approved peculiar directions will incompatible extensions do not help.
Aren't we the authoritrian???
CBFalconer wrote:
Richard Heathfield wrote:
>>
... snip ...
>> It is up to implementors. If they want C programmers to use C99, they must take the lead by providing implementations. Some have done so, but too few. Until, at the very least, GNU C (i.e. gcc and glibc together) and Microsoft C conform to C99, there is no point in using its features in code where portability is a high priority.
Microsoft won't. They have gone off on their .net and C# stuff, so
have no interest.
Microsoft do not recommend use of C anymore at all. For system level
work (like device drivers) they recommend C++ and C#/C++/.NET for
applications.
Gnu will eventually get there, but the problem
is the large variety of systems to be served. It is not as easy as
revising the compiler. Not only does a customized library have to
be created, it has to be issued, and available on the destination
machine.
The problem is, C99 standardised several features that were simply not
used widely enough, or felt to be really all that useful, for
implementors to put in the considerable effort needed to implement all
of them. Each class of implementor has implemented a subset of their
choosing that is relevant (or perceived as relevant) to their user
base.
No one has readily accepted the entire standard, like C90 was accepted.
I think, more than anything the relative failure of C99 reflects, more
than anything, changes in the C community. C is simply not as
ubiquitous as it once was. Where it's still used, C90 seems to be
largely enough (with perhaps a vendor chosen subset of C99). In the PC
applications space, it's firmly C++ and higher up in the abstraction
ladder.
Kenny McCormack wrote:
In article <47***************@yahoo.com>,
CBFalconer <cb********@maineline.netdecreed:
...
>>one will galvenize a few more. Of course, attempts to go off in un-approved peculiar directions will incompatible extensions do not help.
Aren't we the authoritrian???
Don't you know???
--
Self-Knowledge Hedgehog
Nit-picking is best done among friends.
On 21/12/2007 21:39, Kenny McCormack wrote:
Looks like somebody's mommy didn't love him enough.
What a surprise that the only one who defends the unhinged spamming Frog
is a notorious troll...
In article <fk**********@aioe.org>, root <no***@nospam.invalidwrote:
>On 21/12/2007 21:39, Kenny McCormack wrote:
>Looks like somebody's mommy didn't love him enough.
What a surprise that the only one who defends the unhinged spamming Frog is a notorious troll...
Who's defending Jacob? I was attacking you. Get it straight.
root said:
On 21/12/2007 21:39, Kenny McCormack wrote:
>Looks like somebody's mommy didn't love him enough.
What a surprise that the only one who defends the unhinged spamming Frog
is a notorious troll...
Racial/nationalist slurs have no place in civilised debate, and it is
everyone's duty to stand up against such attacks. Jacob's articles can and
indeed should be attacked on technical grounds (and moral grounds, when
he's spamming), but it is puerile to attack him for being French.
--
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
In article <Js******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>the anonyous coward blathered:
>On 21/12/2007 21:39, Kenny McCormack wrote:
>>Looks like somebody's mommy didn't love him enough.
What a surprise that the only one who defends the unhinged spamming Frog is a notorious troll...
Racial/nationalist slurs have no place in civilised debate, and it is everyone's duty to stand up against such attacks. Jacob's articles can and indeed should be attacked on technical grounds (and moral grounds, when he's spamming), but it is puerile to attack him for being French.
True. But we are dealing with somebody who just doesn't get it.
Our help is probably better expended on more deserving candidates. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: David Turner |
last post by:
Hi all
I noticed something interesting while testing some RAII concepts
ported from C++ in Python. I haven't managed to find any information
about it on the web, hence this post.
The problem...
|
by: dkcpub |
last post by:
I'm very new to Python, but I couldn't find anything in the docs or faq
about this. And I fished around in the IDLE menus but didn't see anything.
Is there a tool that can determine all the...
|
by: OvErboRed |
last post by:
I just read a whole bunch of threads on microsoft.public.dotnet.* regarding
checked exceptions (the longest-running of which seems to be <cJQQ9.4419
$j94.834878@news02.tsnz.net>.
My personal...
|
by: Gianni Mariani |
last post by:
I'm involved in a new project and a new member on the team has voiced a
strong opinion that we should utilize exceptions.
The other members on the team indicate that they have either been burned...
|
by: RepStat |
last post by:
I've read that it is best not to use exceptions willy-nilly for stupid purposes as they can be a major performance hit if they are thrown. But is it a performance hit to use a try..catch..finally...
|
by: dcassar |
last post by:
I have had a lively discussion with some coworkers and decided to get
some general feedback on an issue that I could find very little
guidance on. Why is it considered bad practice to define a...
|
by: cat |
last post by:
I had a long and heated discussion with other developers on my team on when
it makes sense to throw an exception and when to use an alternate solution.
The .NET documentation recommends that an...
|
by: Anonieko |
last post by:
Understanding and Using Exceptions
(this is a really long post...only read it if you (a) don't know what
try/catch is OR (b) actually write catch(Exception ex) or catch{ })
The first thing I...
|
by: Zytan |
last post by:
I know that WebRequest.GetResponse can throw WebException from
internet tutorials. However in the MSDN docs:
http://msdn2.microsoft.com/en-us/library/system.net.webrequest.getresponse.aspx
It...
|
by: RedSon |
last post by:
Chapter 3: What are the most common Exceptions and what do they mean?
As we saw in the last chapter, there isn't only the standard Exception, but you also get special exceptions like...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
| |