1. in the prg bellow what vars are stored on stack, heap, data segment?
int i;
void main()
{
int j;
int *k = (void *)malloc(1);
}
(I think j and k are on stack, but where is i?)
2. how to find sizeof variable w/o using sizeof command?
(no clue)
3. what is the o/p of this prg?
void main()
{
int x = 5;
x = x++;
printf("x=%i", x);
}
(I think it shoulld be printing 5 but it prints 6!)
ps: I am using QuickC 2.0
pps: Is very urgent!
Jan 15 '08
77  3783 
Richard Heathfield wrote:
Chris Hills said:
<snip>
>At the time C++ was a superset of C.
C++ has never been a superset of C. If it were, all C programs would be C++
programs, which is clearly not the case.
C++ has never been an exact superset of C, but it has always been
approximately a superset, as a matter of deliberate design. A program
that uses prototypes in every function declaration, and avoids any of
the additional keywords of C++, has a pretty good chance of compiling
under C++ to produce the same behavior as it would when compiled under
C. There are exceptions, but for the most part they're pretty obscure cases.
On Jan 16, 2:57 am, Hans Schneider <h...@localhost.localdomainwrote:
Jack Klein schrieb:
On Tue, 15 Jan 2008 03:41:56 +0100 (CET), Hans Schneider
<h...@localhost.localdomainwrote in comp.lang.c:
void main()
The line above generates undefined behavior, not valid C code.
I didn't write this code, but what is wrong about it?
In 'C: the complete reference' all prgs start like that.
Which says a lot about the quality of 'C: the complete reference'.
James Kuyper said:
Richard Heathfield wrote:
>Chris Hills said:
<snip>
>>At the time C++ was a superset of C.
C++ has never been a superset of C. If it were, all C programs would be
C++ programs, which is clearly not the case.
C++ has never been an exact superset of C,
Precisely my point. I like to speak with precision. :-)
but it has always been approximately a superset,
....ish. Whenever I call malloc, for example, I am writing a C program that
is not a legal C++ program. I could make it a C++ program, but only by
damaging the C code. As written, it is not C++. And quite a few of my
programs call malloc.
--
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
Chris Hills wrote:
CBFalconer <cb********@yahoo.comwrites
>Hans Schneider wrote:
.... snip ...
>>
>>I didn't write this code, but what is wrong about it?
In 'C: the complete reference' all prgs start like that.
If that is the H Schildt (sp?) book, you are lucky. You have now
been advised that it is useless and stuffed full of errors, because
the author doesn't understand C. See if you can get some practical
use of it as a replacement for a log in the fireplace.
For once we agree completely! BTW Ditto for his C++ books
Migawd. Two millenia within 8 years! :-)
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
On Wed, 16 Jan 2008 08:55:45 +0000, Chris Hills <ch***@phaedsys.org>
wrote:
>In article <4d******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>>Chris Hills said:
<snip>
>>At the time C++ was a superset of C.
C++ has never been a superset of C.
According to its author it was when he started.
The Preface to the first edition of "The C++ Programming Language"
says "except for minor differences." The second edition notes that
language changes have been made "to increase C compatibility." It was
never a superset.
--
Al Balmer
Sun City, AZ
On Wed, 16 Jan 2008 10:25:52 +0530, "Ravishankar S"
<ra***********@in.bosch.comwrote:
>Final Note: Why is the compiler called QuickC ? I think perhaps because it
allows you to quickly type any C program
without proper headers and declaration and yet produce some answer.
QuickC was one of the earliest "all in one" programming platforms,
similar to Borland's Turbo C. It provided an IDE, "instant"
compilation and error reporting, execution, and debugging. It was
"quick" compared to the old edit, repeat(compile), link, test cycle.
--
Al Balmer
Sun City, AZ
Richard Heathfield wrote:
....
...ish. Whenever I call malloc, for example, I am writing a C program that
is not a legal C++ program. I could make it a C++ program, but only by
damaging the C code. As written, it is not C++. And quite a few of my
programs call malloc.
You're right, the preferred way to handle calls to malloc() in C code
doesn't work in C++. However, I wouldn't prcall the changes required
to allow it to compiile in both languages "damage". The result is
legal C as well as legal C++. It's just less than ideal for C. That
just balances things: almost any use of malloc() is less than ideal
for C++.
Al Balmer <al******@att.netwrites:
On Wed, 16 Jan 2008 08:55:45 +0000, Chris Hills <ch***@phaedsys.org>
wrote:
>>In article <4d******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>>>Chris Hills said:
<snip>
At the time C++ was a superset of C.
C++ has never been a superset of C.
According to its author it was when he started.
The Preface to the first edition of "The C++ Programming Language"
says "except for minor differences." The second edition notes that
language changes have been made "to increase C compatibility." It was
never a superset.
That makes more sense. For early C++ to have been a true superset of
C, it would have had to have no additional keywords; I doubt that a C
program using "class" as an ordinary identifier was ever a valid C++
program. (I'll grant that such things are "minor differences".)
Speaking of which, it's very common to cite
sizeof('a')
as a construct that's valid in both C and C++, but with different
meanings. Another such construct is
sizeof(1 < 2)
(Relational operators yield int in C, bool in C++.) I suppose it's
less common to apply sizeof to the result of a relational operator.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer wrote:
Hans Schneider wrote:
>Jack Klein schrieb:
>>Hans Schneider <ha**@localhost.localdomainwrote:
... snip ...
>>> void main()
The line above generates undefined behavior, not valid C code.
I didn't write this code, but what is wrong about it?
In 'C: the complete reference' all prgs start like that.
If that is the H Schildt (sp?) book, you are lucky. You have now
been advised that it is useless and stuffed full of errors, because
the author doesn't understand C. See if you can get some practical
use of it as a replacement for a log in the fireplace.
Not bad as a door stop either...
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
On Wed, 16 Jan 2008 10:38:57 -0600, ja*********@verizon.net wrote
(in article
<62**********************************@n20g2000hsh. googlegroups.com>):
Richard Heathfield wrote:
...
>...ish. Whenever I call malloc, for example, I am writing a C program that
is not a legal C++ program. I could make it a C++ program, but only by
damaging the C code. As written, it is not C++. And quite a few of my
programs call malloc.
You're right, the preferred way to handle calls to malloc() in C code
doesn't work in C++. However, I wouldn't prcall the changes required
to allow it to compiile in both languages "damage". The result is
legal C as well as legal C++. It's just less than ideal for C. That
just balances things: almost any use of malloc() is less than ideal
for C++.
How about an answer straight from Stroustrup's FAQ instead. He answers
the question, and if anyone is qualified to do so, he probably fits the
bill: http://www.research.att.com/~bs/bs_faq.html#C-is-subset
That section of his FAQ, and the several after it call out quite a few
reasons that perhaps don't agree with the notion that C is a subset of
C++ in any meaningful way to programmers.
If that isn't sufficient, this might prove helpful as well: http://david.tribble.com/text/cdiffs.htm
It enumerates a painfully long list of differences between ISO C and
ISO C++.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
On Wed, 16 Jan 2008 10:33:44 -0600, Al Balmer wrote
(in article <d3********************************@4ax.com>):
On Wed, 16 Jan 2008 10:25:52 +0530, "Ravishankar S"
<ra***********@in.bosch.comwrote:
>Final Note: Why is the compiler called QuickC ? I think perhaps because it
allows you to quickly type any C program
without proper headers and declaration and yet produce some answer.
QuickC was one of the earliest "all in one" programming platforms,
similar to Borland's Turbo C. It provided an IDE, "instant"
compilation and error reporting, execution, and debugging. It was
"quick" compared to the old edit, repeat(compile), link, test cycle.
I didn't realize anyone still ran it until it came up in this thread.
I bought a copy of it ages ago, I can't find the disks anymore. I
don't recall using it for more than a very brief time.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Nick Keighley <ni******************@hotmail.comwrites:
On 16 Jan, 01:35, andreyvul <andrey....@gmail.comwrote:
>On Jan 14, 9:41 pm, Hans Schneider <h...@localhost.localdomainwrote:
[...]
>Do *not* do
sizeof(void) *at all*, as this is undefined (for good reasons).
ie. it makes no sense.
But be careful. At least one major compiler (gcc) permits
sizeof(void) by default, as an extension. You won't even get a
warning about it unless you use the "-pedantic" option. More
generally, your compiler won't necessarily warn you about non-standard
constructs unless you specifically ask it to operate in conforming
mode.
[...]
and isn't "type" a C++ reserved word?
:-)
Nope. "typedef", "typeid", and "typename" are C++ keywords; "type"
isn't.
[...]
2. how to find sizeof variable w/o using sizeof command?
sizeof is a compiler (not preprocessor) macro.
no, it isn't a macro.
In a vague way, it almost is, in the sense that it's a construct
that's transformed at compilation time into some other construct,
rather than being evaluated during execution. But C has a very
specific meaning for the word "macro", and sizeof doesn't qualify.
[...]
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Chris Hills wrote:
In article <4d******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Chris Hills said:
<snip>
>>At the time C++ was a superset of C.
C++ has never been a superset of C.
According to its author it was when he started.
I belive that Bjarne once said it was designed to be a superset. it
never actually was, at least not once it moved beyond a hobbyist project
and was published.
Things move C++ was based on C89 since then noth C and C++ have moved
in different directions.
In the beginning C++ was a superset of C otherwise they could not have
used the C++ compiler for initial testing and then a C compiler for
final testing,
I'm afraid that logic isn't logical. I can compile some C programmes
with a Pascal compiler - does that make C a superset of pascal?
Randy Howard wrote:
Al Balmer wrote:
>"Ravishankar S" wrote:
>>>Final Note: Why is the compiler called QuickC ?
QuickC was one of the earliest "all in one" programming platforms,
similar to Borland's Turbo C. It provided an IDE, "instant"
compilation and error reporting, execution, and debugging. It was
"quick" compared to the old edit, repeat(compile), link, test cycle.
The name "QuickC" was the continuation of a brand established by the
very popular QuickBASIC, which made BASIC "quick" because it was a
compiler rather than an interpreter. The original DOS QuickC used an
IDE nearly identical to QuickBASIC's, and it was quick (lightweight and
streamlined) compared to the full-blown Microsoft C.
QuickC made the transition to Windows, but survived for only one
version there. It was supplanted by the Visual IDE.
I didn't realize anyone still ran it until it came up in this thread.
I still use the QuickC for Windows 1.0 IDE as my primary editor in
Windows. The text editor in Gnome (gedit) is very similar.
- Ernie http://home.comcast.net/~erniew
On Wed, 16 Jan 2008 21:25:57 -0600, James Kuyper wrote
(in article <9Vzjj.17799$Y63.7388@trnddc03>):
Randy Howard wrote:
...
>How about an answer straight from Stroustrup's FAQ instead. He answers
the question, and if anyone is qualified to do so, he probably fits the
bill:
http://www.research.att.com/~bs/bs_faq.html#C-is-subset
That section of his FAQ, and the several after it call out quite a few
reasons that perhaps don't agree with the notion that C is a subset of
C++ in any meaningful way to programmers.
I interpret that section in almost exactly the opposite fashion. He ends
the section by saying "Except for a few examples such as the ones shown
above ... C++ is a superset of C.".
I'd say he tried to put as favorable spin on it as possible, in light
of the C and C++ standards running off in divergent directions.
>
>If that isn't sufficient, this might prove helpful as well:
http://david.tribble.com/text/cdiffs.htm
It enumerates a painfully long list of differences between ISO C and
ISO C++.
Despite the length of that list, it's no serious constraint on a C
programmer to write code that performs identically whether its compiled
in C90 or in C++98.
If you know both standards very well, it's possible to avoid many of
the pitfalls yes, by spending way more time and effort than it is worth
to write in some jigsaw shaped space where the two intersect cleanly,
and avoiding all the naming conflicts with differences in reserved
words and such.
I'm having difficult imagining very many good reasons to do that. If
you're that fluent in both, then you probably know what projects are
served best by C or C++ and not try to straddle them both.
Writing code that uses features that were new in C99 is trickier. C99
added some features that improved C++ compatibility (// comments,
digraphs, <iso646.h>, and mixing statements with declarations), but
added many other new differences. That's because the C++98 standard was
completed a year before the C99 standard. Future versions of the C++
standard will incorporate many of the features that were added to C in 1999.
We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.
And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway. :)
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Randy Howard <ra*********@FOOverizonBAR.netwrote:
On Wed, 16 Jan 2008 21:25:57 -0600, James Kuyper wrote
(in article <9Vzjj.17799$Y63.7388@trnddc03>):
Writing code that uses features that were new in C99 is trickier. C99
added some features that improved C++ compatibility (// comments,
digraphs, <iso646.h>, and mixing statements with declarations), but
added many other new differences. That's because the C++98 standard was
completed a year before the C99 standard. Future versions of the C++
standard will incorporate many of the features that were added to C in 1999.
We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.
And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway. :)
And if gets() has been replaced by gets_s(), you'll know they've been
0wnz0red, and by whom.
Richard
On Jan 14, 6:41*pm, Hans Schneider <h...@localhost.localdomainwrote:
1. in the prg bellow what vars are stored on stack, heap, data segment?
I don't think I would want to work where you are applying, but it
sounds like you'd be a good fit.
* * int i;
* * void main()
* * {
* * * * int j;
* * * * int *k = (void *)malloc(1);
* * }
(I think j and k are on stack, but where is i?)
Where is i?
Unemployed, undercapitalized and desperate.
pps: Is very urgent!
Landlord says your rent is late.
He might have to litigate.
Don' worry. Be happy!
In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.netwrites
>
>Writing code that uses features that were new in C99 is trickier. C99
added some features that improved C++ compatibility (// comments,
digraphs, <iso646.h>, and mixing statements with declarations), but
added many other new differences. That's because the C++98 standard was
completed a year before the C99 standard. Future versions of the C++
standard will incorporate many of the features that were added to C in 1999.
We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.
There have been suggestions within ISO C to drop some features of C99
in C20** I think it has been realised that no one is going to fully
implement C99 so there is no point on building a new standard on top of
it.
What is needed is to sort of go back to C95 and move forward again
looking at what has actually been implemented and I think the comment
was "implemented by more than two mainstream compilers."
ISO C is going to have to move back to what the serious users are
actually doing i.e. real world C Which will screw all those here who
want only ISO C as described in all versions of ISO/ANSI C and K&R but
not as used in reality.
Where will the pedants here go if items are dropped from ISO C? By the
current definition of what C is from most of them it will include C99
and therefore things that are no longer legal...
>And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway. :)
I expect It will probably get left in so as not to break a lot of
existing code.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills said:
<snip>
ISO C is going to have to move back to what the serious users are
actually doing i.e. real world C Which will screw all those here who
want only ISO C as described in all versions of ISO/ANSI C and K&R but
not as used in reality.
Not at all. If ISO wants to issue a new standard for C, that's fine - it
will become topical here. If that includes library calls for interfacing
with USB devices and for validating holographic security devices on Disney
videos, that's fine too. If it's part of the standard C language or
library, it's topical here.
Where will the pedants here go if items are dropped from ISO C? By the
current definition of what C is from most of them it will include C99
and therefore things that are no longer legal...
So what? All versions of ISO C are topical here. It'll just mean that we
have to say things like "well, you can't do such-and-such in C90, but
there is a way if you have C99 - but if you've got the latest, greatest C
XP or C Vista or whatever it's called, you can't do it any more because it
was dropped". Wordy, but doable.
>>And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway. :)
I expect It will probably get left in so as not to break a lot of
existing code.
There are those who would argue that any code containing a gets call is
already broken.
--
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 <Z7******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>>>And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway. :)
I expect It will probably get left in so as not to break a lot of
existing code.
There are those who would argue that any code containing a gets call is
already broken.
Legally broken? :-) ))
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Thu, 17 Jan 2008 04:39:44 -0600, Chris Hills wrote
(in article <SF**************@phaedsys.demon.co.uk>):
In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.netwrites
>>
We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.
There have been suggestions within ISO C to drop some features of C99
in C20** I think it has been realised that no one is going to fully
implement C99 so there is no point on building a new standard on top of
it.
That is pretty interesting. It's not often that a tech body has the
spine to admit in so public a fashion that their last product was in
need of a good bulldozing.
What is needed is to sort of go back to C95 and move forward again
looking at what has actually been implemented and I think the comment
was "implemented by more than two mainstream compilers."
Just go back to C95 and leave it the hell alone. :-)
ISO C is going to have to move back to what the serious users are
actually doing i.e. real world C Which will screw all those here who
want only ISO C as described in all versions of ISO/ANSI C and K&R but
not as used in reality.
"real world C" means more than one thing, imo. Those that are working
on things that need to run on a lot of different platforms tend to be
more of a stickler for the sandbox model where you only do the things
guaranteed to be valid pretty much everywhere, and if you must jump
outside that, you do it by breaking out the nonstandard pieces and port
the implementation to each platform with conditional code (often behind
an abstraction API).
Another group of "real world C" programmers only care about one, or a
very limited number of platforms, and will write in a variant of C that
is known to work for those, and don't care one way or the other if it
runs on a DS9K, or even a recent OS they don't support.
In both of those cases, existing C compilers are "plenty good". Often
compiling either their own "variant", like stock gcc without the
conformance switches turned on, or strict C89/90/95 conformance enabled
gets both goals achieved.
Neither group needs to see the C standard change much, if at all.
There is another group though that wants C to be more of a true subset
of C++, for reasons that I have never shared. You may have a different
take on it, but getting two different standards bodies to make a
serious attempt at that happening seems unlikely. The very fact that
two different bodies are responsible for it pretty much demonstrates
that yes, in fact they are different languages, and that's fine. It
seems ludicrous to spend a lot of effort to make them more directly
linked just because the names of the languages are very similar.
Where will the pedants here go if items are dropped from ISO C?
I hate to break the news to you, but almost all of the "real world C"
crowd doesn't care one way or the other what the C committee does
anymore. They had all they really needed to get their job done in
1989. The "pedants" will probably be forced to start complaining about
code that is not C20xx clean. And if no compilers are available for it
a decade later, they'll be very lonely, just like the C99 pedants are
today.
By the
current definition of what C is from most of them it will include C99
and therefore things that are no longer legal...
If this C20xx standard comes to pass, it'll probably be yet another $18
(or quite a bit more for a while, then getting reduced when nobody buys
it to $18) pdf file, which will be quietly ignored by the compiler
vendors.
It's possible that something magical will happen, and everything wrong
with C99 will disappear, and everything good about it will stay around,
plus a few new things of value will appear, and gcc, icc, msvc, and 20
or 30 embedded compilers will all move to adopt it ASAP; the programmer
community will all clamor for it and start a mass email and telephone
campaign to the vendor of choice. It's also possible that my local dog
catcher will be named as Imperious Overlord of the Planet by universal
world acclaim. Both are about equally likely.
>And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway. :)
I expect It will probably get left in so as not to break a lot of
existing code.
So it'll be another joke. Hint: All three programs in the world that
use gets() in a perfectly safe way can be modified in a matter of
minutes to work without it, and all the remainder are broken already.
The notion that "we don't want to break code by removing a feature that
makes it almost impossible for it not to be broken by default" is one
of the more silly things I've seen done outside of government.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Chris Hills <ch***@phaedsys.orgwrites:
In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.netwrites
>>
>>Writing code that uses features that were new in C99 is
trickier. C99 added some features that improved C++ compatibility
(// comments, digraphs, <iso646.h>, and mixing statements with
declarations), but added many other new differences. That's
because the C++98 standard was completed a year before the C99
standard. Future versions of the C++ standard will incorporate
many of the features that were added to C in 1999.
We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.
There have been suggestions within ISO C to drop some features of C99
in C20** I think it has been realised that no one is going to fully
implement C99 so there is no point on building a new standard on top
of it.
What is needed is to sort of go back to C95 and move forward again
looking at what has actually been implemented and I think the comment
was "implemented by more than two mainstream compilers."
[...]
I'm not unsympathetic to the idea, but I foresee some serious
problems.
A link was posted recently to a list of several compilers that have
been certified as C99 compliant, including Sun's compiler. (I don't
have the URL; perhaps somebody else saved it.) If that list is
accurate, then the set of features "implemented by more than two
mainstream compilers" may well already be the full C99 language.
The next C++ standard is expected to incorporate a number of C99
features (see above). Is the C committee coordinating with the C++
committee on this issue? What happens if C++ requires support for
<ctgmath>, but C drops <tgmath.h>?
I know you've said before that you don't have any detailed information
on this. Please let us know when you have something more definite.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
In article <87************@kvetch.smov.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:
>In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.netwrites
>>>
Writing code that uses features that were new in C99 is
trickier. C99 added some features that improved C++ compatibility
(// comments, digraphs, <iso646.h>, and mixing statements with
declarations), but added many other new differences. That's
because the C++98 standard was completed a year before the C99
standard. Future versions of the C++ standard will incorporate
many of the features that were added to C in 1999.
We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.
There have been suggestions within ISO C to drop some features of C99
in C20** I think it has been realised that no one is going to fully
implement C99 so there is no point on building a new standard on top
of it.
What is needed is to sort of go back to C95 and move forward again
looking at what has actually been implemented and I think the comment
was "implemented by more than two mainstream compilers."
[...]
I'm not unsympathetic to the idea, but I foresee some serious
problems.
A link was posted recently to a list of several compilers that have
been certified as C99 compliant, including Sun's compiler. (I don't
have the URL; perhaps somebody else saved it.) If that list is
accurate, then the set of features "implemented by more than two
mainstream compilers" may well already be the full C99 language.
OK they probably mean widely used.... There are some features that were
added for specific areas that most don't use in practice. .
>The next C++ standard is expected to incorporate a number of C99
features (see above). Is the C committee coordinating with the C++
committee on this issue? What happens if C++ requires support for
<ctgmath>, but C drops <tgmath.h>?
God knows.
>I know you've said before that you don't have any detailed information
on this. Please let us know when you have something more definite.
OK.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills wrote:
>
.... snip ...
>
ISO C is going to have to move back to what the serious users are
actually doing i.e. real world C Which will screw all those here
who want only ISO C as described in all versions of ISO/ANSI C
and K&R but not as used in reality.
Where will the pedants here go if items are dropped from ISO C?
By the current definition of what C is from most of them it will
include C99 and therefore things that are no longer legal...
Already there. Try using implicit int typing in C99. This means
that compilers need to use the gcc technique of adopting the
appropriate standard at compile time. There are also things to do
with modulus and division. Probably more.
In general it will be hard drop things that cannot be implemented
in other legal ways.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
James Kuyper wrote:
>
.... snip ...
>
Writing code that uses features that were new in C99 is trickier.
C99 added some features that improved C++ compatibility (//
comments, digraphs, <iso646.h>, and mixing statements with
declarations), but added many other new differences. That's
because the C++98 standard was completed a year before the C99
standard. Future versions of the C++ standard will incorporate
many of the features that were added to C in 1999.
FYI <iso646.hwas added to C90 in 1995.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Randy Howard wrote:
>
.... snip ...
>
So it'll be another joke. Hint: All three programs in the world
that use gets() in a perfectly safe way can be modified in a
matter of minutes to work without it, and all the remainder are
broken already.
I maintain that all use of gets can be safely replaced with ggets
with minor source adjustments. ggets is written in standard C, and
is freely available at:
<http://cbfalconer.home.att.net/download/>
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
....
FYI <iso646.hwas added to C90 in 1995.
My apologies - I have a copy of the C99 standard, but I've never owned a
copy of C90, so I'm not as clear as I'd like to be about which features
were first introduced in C99. The C90 standard was too expensive when I
needed it, and no longer of interest to me by the time it's price
dropped into a range where I could afford it. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: adsheehan |
last post by:
Hi,
I am embedding Python into a multi-threaded C++ application runnig on
Solaris and need urgent clarification on the embedding architecture and
its correct usage (as I am experience weird...
|
by: Vibhajha |
last post by:
Hi friends,
My sister is in great problem , she has this exam of C++ and
she is stuck up with some questions, if friends like this group
provides some help to her, she will be very grateful....
|
by: Rob |
last post by:
I have a form - when you click the submit button, it appends a
variable to the URL (e.g. xyz.cgi?inputID=some_dynamic_variable)
It also opens a new page. Now, that some_dynamic_variable is...
|
by: Mike |
last post by:
Hello,
I have a few rather urgent questions that I hope someone can help with (I
need to figure this out prior to a meeting tomorrow.) First, a bit of
background: The company I work for is...
|
by: Max Power |
last post by:
Hi All
I am coding a small app in that swaps specific files between a client and
server. All files and locations are set at both sides.
I want my app to show a file list, based on the file...
|
by: Gurmeet |
last post by:
Hi All,
Does any one ever appeared for Brainbench
ceritification in C++? I need to know what kind of
question are there in C++. Now brainbench is paid. I
cant give or get sample or practice C++...
|
by: N. Spiker |
last post by:
I am attempting to receive a single TCP packet with some text ending with
carriage return and line feed characters. When the text is send and the
packet has the urgent flag set, the text read from...
|
by: TexCube |
last post by:
Hello everyone,
I have an urgent question. Can data be pulled from an access database table to create a directory that can be printed out and bound together?
I need to have each row of a...
|
by: rajesh.us.it.recruiter |
last post by:
Hi Guys/Partners,
We have a URGENT Requirement for Perl Programmer with H1 visa in
India/US for one of our prestigious Client. Location : New Jersey
Requirements :
Should be very strong in...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
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: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
