Hi All
What is C99 Standard is all about. is it portable, i mean i saw
-std=C99 option in GCC
but there is no such thing in VC++.?
which one is better ANSI C / C99?
can i know the major difference between C99 & ANSI C standards?
Sep 27 '06
83  11515 
Richard Heathfield wrote:
jacob navia said:
[on C99]
>Microsoft doesn't implement it,
So it is effectively non-portable, since a great many C programmers are
required to use the compiler supplied by their employer, and for a great
many employers, Microsoft is the preferred supplier for Windows-based
development software.
Although your other comments are well taken, this one misses the mark.
Portability is not quite a non-issue on Microsoft platforms (there's still
some 16-bit and 64-bit code to worry about, and those funky CE platforms),
but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating non-Windows-specific
programs.
In short, whether Microsoft implements C99 may matter to Windows
programmers, but to the general issue it matters only slightly. The fact
that C99 is poorly supported between platforms with more exchange of code is
more important.
S.
boa said:
<snip>
Man, you're annoying when it comes to C99. ;-)
I do my humble best. :-)
What about the vendors on this list?
http://www.peren.com/pages/cvsa_isocvpl.htm
Interesting page - for those who can't be bothered to go look, it's a list
of vendors that have been awarded validation certs for C99 software. Here's
a brief summary:
Dinkumware's C99 library (no compiler, though) for Linux
Edison Design Group C99 compiler (no library) for Linux
(The two together make a conforming implementation.)
IBM XL C99 compiler (not clear whether a library is included) for Power PC
IBM Visual Age C99 compiler (library not clear) for Power PC
Lund C99 compiler (library not clear) for Linux/Power PC
Solaris: a couple of compilers, library status not clear, one for SPARCs and
the other for x86s running Solaris.
So the situation is improving. But I don't see any compilers there for
Win32, Win64, BSD, embedded systems, mainframes, or minicomputers. That's
quite a hole.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
jmcgill wrote:
jacob navia wrote:
>It is business talk.
If you write
This is 100% conforming you are liable if there is the
slightest bug. If you write "some" conformance, you are
not.
Oh really? You think the FSF is afraid of being sued?
No, but there's a quite different reason for that:
"This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
Never mind C99 conformance, they're not even claiming gcc is good for
anything. They've pretty much got that base covered.
S.
Skarmander wrote:
"This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE."
Never mind C99 conformance, they're not even claiming gcc is good for
anything. They've pretty much got that base covered.
Show me a software vendor that sells anything to the public that does
not make an equivalent disclaimer in the license.
jmcgill wrote:
Skarmander wrote:
>"This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE."
Never mind C99 conformance, they're not even claiming gcc is good for
anything. They've pretty much got that base covered.
Show me a software vendor that sells anything to the public that does
not make an equivalent disclaimer in the license.
From the Windows XP EULA: "Microsoft warrants that the Software will
perform substantially in accordance with the accompanying materials for a
period of ninety (90) days from the date of receipt."
Of course, this doesn't mean Microsoft promises you an OS that will work
well, and the EULA also takes great pains to distance itself from any
possible damages that could arise as a result of the use of the software,
but that's another issue.
S.
Skarmander said:
Richard Heathfield wrote:
>jacob navia said:
[on C99]
>>Microsoft doesn't implement it,
So it is effectively non-portable, since a great many C programmers are
required to use the compiler supplied by their employer, and for a great
many employers, Microsoft is the preferred supplier for Windows-based
development software.
Although your other comments are well taken, this one misses the mark.
Portability is not quite a non-issue on Microsoft platforms (there's still
some 16-bit and 64-bit code to worry about, and those funky CE platforms),
but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating
non-Windows-specific programs.
That is directly contrary to my own experience. Much of my career has been
spent writing code which was non-Windows[1]-specific but which nevertheless
had to be developed on Windows[1]. Typical scenario: the program is
intended to be run on a mainframe system but the mainframe people don't
want lots of hairy C programmers milling around their environment (and who
can blame them?); so they give you a Windows[1] box and Visual C[2] to get
the darn thing written and working *first*, and then they let you throw it
at the big iron for final testing.
One place I worked, though, they used Borland C 3.1 (despite the fact that
16-bit was ancient history by then). Weird. But a pleasant change.
(Curiously, I am fairly sure I got that particular contract purely because
I'd *heard* of "thunking". Blech!)
[1] Or, in earlier days, MS-DOS.
[2] Or, in earlier days, Microsoft C.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote:
Skarmander said:
>Richard Heathfield wrote:
>>jacob navia said:
[on C99]
>>>Microsoft doesn't implement it,
So it is effectively non-portable, since a great many C programmers are
required to use the compiler supplied by their employer, and for a great
many employers, Microsoft is the preferred supplier for Windows-based
development software.
Although your other comments are well taken, this one misses the mark.
Portability is not quite a non-issue on Microsoft platforms (there's still
some 16-bit and 64-bit code to worry about, and those funky CE platforms),
but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating
non-Windows-specific programs.
That is directly contrary to my own experience. Much of my career has been
spent writing code which was non-Windows[1]-specific but which nevertheless
had to be developed on Windows[1].
Back in the days when the only Microsoftese port of gcc was DJGPP, I take
it? You'd presumably be much better off using mingw these days.
Typical scenario: the program is intended to be run on a mainframe system
but the mainframe people don't want lots of hairy C programmers milling
around their environment (and who can blame them?); so they give you a
Windows[1] box and Visual C[2] to get the darn thing written and working
*first*, and then they let you throw it at the big iron for final
testing.
Ouch. In that case, I feel your pain. On the other hand, a good conforming
implementation (never mind C99) is even more to ask for in that case... and
I should hope that the scenario you sketch is either history, or no longer
forces VC(++) on the hapless programmers doing the cross-developing.
One place I worked, though, they used Borland C 3.1 (despite the fact that
16-bit was ancient history by then). Weird. But a pleasant change.
I had my share when I had to develop a Win 3.1/95 app with Visual C++ 1.42.
I fondly remember walking over to the tiny room that held nothing but the
printer and a spare computer, with a stack of Win 3.1 setup disks, to test
my latest creation...
Ah, the days of MFC and OWL. How I sorely don't miss them.
(Curiously, I am fairly sure I got that particular contract purely because
I'd *heard* of "thunking". Blech!)
[1] Or, in earlier days, MS-DOS.
[2] Or, in earlier days, Microsoft C.
S.
jmcgill said:
Skarmander wrote:
>"This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE."
Never mind C99 conformance, they're not even claiming gcc is good for
anything. They've pretty much got that base covered.
Show me a software vendor that sells anything to the public that does
not make an equivalent disclaimer in the license.
"This device is provided without warranty of any kind as to reliability,
accuracy, existence or otherwise or fitness for any particular purpose
and Bioalchemic Products specifically does not warrant, guarantee,
imply or make any representations as to its merchantability for any
particular purpose and furthermore shall have no liability for or
responsibility to you or any other person, entity or deity with respect
to any loss or damage whatsoever caused by this device or object or by
any attempts to destroy it by hammering it against a wall or dropping it
into a deep well or any other means whatsoever and moreover asserts
that you indicate your acceptance of this agreement or any other
agreement that may he substituted at any time by coming within
five miles of the product or observing it through large telescopes or
by any other means because you are such an easily cowed moron
who will happily accept arrogant and unilateral conditions on a piece
of highly priced garbage that you would not dream of accepting on a
bag of dog biscuits and is used solely at your own risk." - Terry Pratchett
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
* Richard Heathfield wrote, On 28.09.2006 21:57:
boa said:
<snip>
>Man, you're annoying when it comes to C99. ;-)
I do my humble best. :-)
>What about the vendors on this list?
http://www.peren.com/pages/cvsa_isocvpl.htm
Interesting page - for those who can't be bothered to go look, it's a list
of vendors that have been awarded validation certs for C99 software. Here's
a brief summary:
Dinkumware's C99 library (no compiler, though) for Linux
Edison Design Group C99 compiler (no library) for Linux
(The two together make a conforming implementation.)
IBM XL C99 compiler (not clear whether a library is included) for Power PC
IBM Visual Age C99 compiler (library not clear) for Power PC
Lund C99 compiler (library not clear) for Linux/Power PC
Solaris: a couple of compilers, library status not clear, one for SPARCs and
the other for x86s running Solaris.
So the situation is improving. But I don't see any compilers there for
Win32, Win64, BSD, embedded systems, mainframes, or minicomputers. That's
quite a hole.
What's a minicomputer? :-)
I didn't spend much time on this, but have a few comments which I
believe are more or less correct:
- The EDG compiler *front end* is used by (lots of ?) vendors of
embedded systems, so C99 support for embedded systems may be better than
we think.
- The Dinkumware C99 library claims to be portable. I was unable to find
a list of supported platforms, but assume that it is portable to more
platforms than the next version of Linux...
- The SUN compilers now support Linux, AFACT.
And as we all know, C99 support in gcc isn't perfect, but probably good
enough for many tasks/people/projects/whatever.
I can't spend more time on this, so I'll switch back to read-only mode
now.;-)
Boa
Richard Heathfield <in*****@invalid.invalidwrites:
Solaris: a couple of compilers, library status not clear,
The library seems to be there. Do you want I check anything in detail?
--
Jean-Marc
Jean-Marc Bourguet said:
Richard Heathfield <in*****@invalid.invalidwrites:
>Solaris: a couple of compilers, library status not clear,
The library seems to be there. Do you want I check anything in detail?
No, thanks. I'm not overly fussed about C99, as you probably realise. I
write my code to be valid in both C90 and C99, so when C99 becomes *widely*
implemented I'll be ready to start using its new features - if I live that
long.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield <in*****@invalid.invalidwrites:
Jean-Marc Bourguet said:
>Richard Heathfield <in*****@invalid.invalidwrites:
>>Solaris: a couple of compilers, library status not clear,
The library seems to be there. Do you want I check anything in detail?
No, thanks. I'm not overly fussed about C99, as you probably realise. I
write my code to be valid in both C90 and C99, so when C99 becomes *widely*
implemented I'll be ready to start using its new features - if I live that
long.
I've quite another approach: when one feature is usefull, I check to see if
it is supported on all the target platforms and if it is, I use it. There
is no need to wait for a full support on every platform of the universe.
New platforms comes rarely, and when they do we still have to validate and
adapt -- especially for library things, this is not difficult as we already
have in place a compatibility layer where adding missing things is easy
(excepted for things like <tgmath.hwhich needs compiler support, I'm more
conservative there). Due to other dependancies, they usually have already
all what we need. As a matter of fact, known dependancies are usually not
the problem at this stage, bugs -- both in our code and in the
implementation -- and unknown dependancies are the problems. This put also
a little more pressure on the vendor to support C99. Obviously, such kind
of decisions depends on the context, if you are a provider of libraries in
source form, you have quite other constraints than if you provide complete
systems, hardware and software combined.
Yours,
--
Jean-Marc
On Thu, 28 Sep 2006 22:55:13 +0200, in comp.lang.c , Skarmander
<in*****@dontmailme.comwrote:
>but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating non-Windows-specific
programs.
As a counterexample, we do a lot of development in Visual C++ because
the GUI is easy to use, and friendly. The final code is however
recompiled for Solaris and Linux. This forces a pretty strict rigour
on us, and boy does it sting when you do an overnight build and some
dork has used an MS specific extension.
>In short, whether Microsoft implements C99 may matter to Windows
programmers, but to the general issue it matters only slightly.
We have to recompile using various versions of gcc, and knowing that
all three platforms' compilers supported the same Standard woudl be
pretty useful.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
On Thu, 28 Sep 2006 23:14:32 +0200, in comp.lang.c , Skarmander
<in*****@dontmailme.comwrote:
>jmcgill wrote:
>Skarmander wrote:
>>"This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE."
Never mind C99 conformance, they're not even claiming gcc is good for
anything. They've pretty much got that base covered.
Show me a software vendor that sells anything to the public that does
not make an equivalent disclaimer in the license.
From the Windows XP EULA: "Microsoft warrants that the Software will
perform substantially in accordance with the accompanying materials for a
period of ninety (90) days from the date of receipt."
"substantially" and "from the date of receipt". Receiptby whom - the
retailer? The wholesaler? Who judges substantially? Microsoft? And
what accompanying materials? I got Win2K in a box with a CD, a
200-language guarantee card, the EULA and a wafer-thin installation
guide which took me through as far as booting from the CD.
Plus it dies after 90 days. Whoop de do. Just long enough to get it
installed.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
In article <1J********************@bt.com>, Richard Heathfield
<in*****@invalid.invalidwrites
>jacob navia said:
>Richard Heathfield wrote:
>>jacob navia said:
<snip>
>>>
lcc-win32
Given the maintainer's limited knowledge of C as evidenced in
comp.lang.c, I must say I entertain certain doubts about whether
lcc-win32 is C99-conforming in all respects.
Given the history of pedantic remarks you use,
it is obvious that you can't refrain.
But if you want it, you are right.
So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.
I think there are half a dozen fully conforming C99 compilers. Compared
to the 100 or so that aren't
Te problem is in real world engineering few really care if the compiler
is C99 conforming. If the industry did care then the compiler makers
would do it.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <7c******************************@telenor.com>, boa
<bo*****@gmail.comwrites
>* Richard Heathfield wrote, On 28.09.2006 21:57:
I didn't spend much time on this, but have a few comments which I
believe are more or less correct:
- The EDG compiler *front end* is used by (lots of ?) vendors of
embedded systems, so C99 support for embedded systems may be better
than we think.
None of the embedded compilers that use the EDG front end do a full
implementation of C99 the do C95+ a bit.
>- The Dinkumware C99 library claims to be portable. I was unable to
find a list of supported platforms, but assume that it is portable to
more platforms than the next version of Linux...
Several embedded compilers use this library.
Though there are components that are C99 it does not mean the compiler
suite they are used on is C99 compliant.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <11**********************@m73g2000cwd.googlegroups .com>,
sunny <su*******@gmail.comwrites
>Hi All
What is C99 Standard is all about. is it portable, i mean i saw
-std=C99 option in GCC
but there is no such thing in VC++.?
which one is better ANSI C / C99?
can i know the major difference between C99 & ANSI C standards?
197* K&R1 C book
1988 K&R 2 book }
1989 ANCI-C (C89) US standard ) All basically the
same.
1990 ISO C (C90) International Standard }
K&R were on the ANSI committee and their publisher was faster than the
ANSI system. ANSI is the local US standard and this was superseded by
ISO C 9899:1990 the ANSI and ISO standards are identical in content
for the most part.
1993/5/6 There were Amendment 1 and some TC's to the ISO Standard
this is where most compilers are now.
1999 ISO produced 9899:1999 the current ISO C standard. (There is are
ANSI, BSI, DIN etc versions)
Out of the many C compilers in use only a handful (6 I think) have full
C99 compliance. The other 95+% have implemented SOME C99 things. Gcc
is not different.
Interestingly Quite a few C95+ compilers actually use a fully C99
compliant front end but until their users actual demand C99 it is not
likely to happen their users are asking for other things ahead of C99
compliance.
So to answer your question ANSI C became superseded in 1990. You need
to ask which is better C90/95 or [close to] C99 for your use.
Regards
Chris
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Jean-Marc Bourguet said:
Richard Heathfield <in*****@invalid.invalidwrites:
>Jean-Marc Bourguet said:
>>Richard Heathfield <in*****@invalid.invalidwrites:
Solaris: a couple of compilers, library status not clear,
The library seems to be there. Do you want I check anything in detail?
No, thanks. I'm not overly fussed about C99, as you probably realise. I
write my code to be valid in both C90 and C99, so when C99 becomes
*widely* implemented I'll be ready to start using its new features - if I
live that long.
I've quite another approach: when one feature is usefull, I check to see
if
it is supported on all the target platforms and if it is, I use it.
That works for me, too, provided the list of target platforms is
sufficiently stable, and provided my client is prepared to meet the costs
of migrating to those new compilers (by no means all clients relish the
idea of changing to a new compiler just because one of their contract guys
tells them to - and rightly so).
Obviously, such kind
of decisions depends on the context, if you are a provider of libraries in
source form, you have quite other constraints than if you provide complete
systems, hardware and software combined.
You've hit the nail on the head.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Chris Hills said:
In article <1J********************@bt.com>, Richard Heathfield
<in*****@invalid.invalidwrites
>>
So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.
I think there are half a dozen fully conforming C99 compilers. Compared
to the 100 or so that aren't
Yes, I've now seen the list, the sheer dearthiness of which is awesome.
Te problem is in real world engineering few really care if the compiler
is C99 conforming. If the industry did care then the compiler makers
would do it.
Right. After all, it's not as if C99 has anything that is obviously "gimme
gimme gimme".
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Mark McIntyre wrote:
On Thu, 28 Sep 2006 22:55:13 +0200, in comp.lang.c , Skarmander
<in*****@dontmailme.comwrote:
>but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating non-Windows-specific
programs.
As a counterexample, we do a lot of development in Visual C++ because
the GUI is easy to use, and friendly.
Not so friendly that it could be used to invoke a different compiler? The
IDE and the compiler are still separate, despite appearances to the
contrary. (The latest incarnations feature tighter integration, a la Eclipse
-- but then, you could use Eclipse for that matter).
The final code is however recompiled for Solaris and Linux. This forces a
pretty strict rigour on us, and boy does it sting when you do an
overnight build and some dork has used an MS specific extension.
See, I don't get this. You actually let the GUI waste your time like that?
Setting up mingw with a separate IDE would be too much work? It might save
you a few overnight suprises. :-)
S.
Mark McIntyre wrote:
On Thu, 28 Sep 2006 22:55:13 +0200, in comp.lang.c , Skarmander
<in*****@dontmailme.comwrote:
>>but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating non-Windows-specific
programs.
As a counterexample, we do a lot of development in Visual C++ because
the GUI is easy to use, and friendly. The final code is however
recompiled for Solaris and Linux.
Both of which support parallel/distributed builds. I work the other
way, use the faster build and test environment on Solaris, recompile for
windows.
This forces a pretty strict rigour
on us, and boy does it sting when you do an overnight build and some
dork has used an MS specific extension.
Overnight build? What are you building?
--
Ian Collins.
Chris Hills <ch***@phaedsys.orgwrote:
>
K&R were on the ANSI committee
No, they were not. Not even one of them. Not even as observers.
Dennis came to exactly one meeting, very late in the process, to ensure
that the committee didn't make a stupid mistake, and my recollection is
that he didn't even speak since the committee had already recognized the
error of their ways.
-Larry Jones
No one can prove I did that!! -- Calvin
Ian Collins wrote:
Mark McIntyre wrote:
>>On Thu, 28 Sep 2006 22:55:13 +0200, in comp.lang.c , Skarmander
<in*****@dontmailme.comwrote:
>>>but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating non-Windows-specific
programs.
As a counterexample, we do a lot of development in Visual C++ because
the GUI is easy to use, and friendly. The final code is however
recompiled for Solaris and Linux.
Both of which support parallel/distributed builds. I work the other
way, use the faster build and test environment on Solaris, recompile for
windows.
Not that I recommend the "VC++ build first" strategy, but there
are add-ons like IncrediBuild which supports distributed building
and gives you a chance to have debug information if the limits of
VC6 are exhausted. Unfortunately, it does not work well with code
coverage tools.
Thus, your limit is the linking time (which is non-negligible for
sufficiently large applications/DLLs).
This forces a pretty strict rigour
I can imagine that :-)
>>on us, and boy does it sting when you do an overnight build and some
dork has used an MS specific extension.
Overnight build? What are you building?
I don't know what Mark is at.
Sometimes, you need overnight builds because you need "stable"
phases for reproducible configurations and test runs.
When breaking a DLL into several smaller DLLs, every design sin
of the last x years must be paid for in that you have DLL interfaces
affecting half the project (at least until you fixed that). This
necessitates times when nobody is checking in, so everyone can get
consistent sources.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Michael Mair wrote:
Ian Collins wrote:
>Mark McIntyre wrote:
>>>
As a counterexample, we do a lot of development in Visual C++ because
the GUI is easy to use, and friendly. The final code is however
recompiled for Solaris and Linux.
Both of which support parallel/distributed builds. I work the other
way, use the faster build and test environment on Solaris, recompile for
windows.
Not that I recommend the "VC++ build first" strategy, but there
are add-ons like IncrediBuild which supports distributed building
and gives you a chance to have debug information if the limits of
VC6 are exhausted. Unfortunately, it does not work well with code
coverage tools.
I'm not sure what the "VC++ build first" strategy is, care to explain?
--
Ian Collins.
jacob navia wrote:
sunny wrote:
>>
What is C99 Standard is all about.
It is the current C standard, as defined by ANSI/ISO. The old
standard (C89) is now obsolete.
Obsolete is not the best word here. Has been replaced by C99 is
probably more accurate.
>
> is it portable
Yes. There are compilers for it under linux, windows, and many
other operating systems and implementations. Microsoft doesn't
implement it, but you can find compilers like intel compiler
that implements it. Comeau C/C++ implements C99 also.
>, i mean i saw
-std=C99 option in GCC
but there is no such thing in VC++.?
VC++ doesn't care about C development and has abandonend
most C development to concentrate on C# C++ and other languages.
>>
which one is better ANSI C / C99?
C99 offers most of the all standard (including warts like gets())
and adds significant functionality.
>can i know the major difference between C99 & ANSI C standards?
http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html
This is a good post, IMO. The fact that most compiler vendors have
not yet implemented C99 is not really germane, and is probably our
(collective) fault, in that we have not insisted on compliance with
the current standard.
To all practical purposes the closest we can get to a C99
implementation is gcc. However that is hampered by the fact that
gcc depends on the libraries present on most systems, and this
prevents full compliance. As a simple example the usual printf
interpreter (in a library) can be expected to implement C90, but
probably not C99, because C99 did not exist when that interpreter
was written.
The fact is that programs written to the C99 standard are portable
to all compiler systems that comply with C99, while all programs
written to the C95 standard are portable to all compiler systems
that comply with C95, etc. for C90 and C89. C90 and C89 differ
only in the numbering of the standard sections. In general we can
expect later standards to handle programs written to earlier
standards.
--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>
Skarmander wrote:
Mark McIntyre wrote:
.... snip ...
>
>The final code is however recompiled for Solaris and Linux. This
forces a pretty strict rigour on us, and boy does it sting when
you do an overnight build and some dork has used an MS specific
extension.
See, I don't get this. You actually let the GUI waste your time
like that? Setting up mingw with a separate IDE would be too much
work? It might save you a few overnight suprises. :-)
No, you don't appreciate the actual situation. Some pointy haired
type has hired you as a consultant, and won't let you rampage
through his computer systems installing software. He won't even
let you develop on your own machinery and bring the result in on
some media or other. Thus you are limited to what he has been sold
by the evil empire.
--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>
Richard Heathfield wrote:
jacob navia said:
>Richard Heathfield wrote:
>>jacob navia said:
<snip>
>>>
lcc-win32
Given the maintainer's limited knowledge of C as evidenced in
comp.lang.c, I must say I entertain certain doubts about whether
lcc-win32 is C99-conforming in all respects.
Given the history of pedantic remarks you use,
it is obvious that you can't refrain.
But if you want it, you are right.
So far, then, we have exactly ZERO conforming implementations of
C99. So much for that.
Ah, but who can say whether we have any conforming implementations
of c90, or C95. In the absence of a generally available test
suite, which anyone reasonably competent can run, to verify
compliance we cannot really make any such statements. We know we
can find failings in all alleged "C99" implementations. At least
with gcc we have a document available spelling out the known
failings with regard to C99.
Quid custodes costodiens applies.
--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>
Ian Collins wrote:
Michael Mair wrote:
>>Ian Collins wrote:
>>>Mark McIntyre wrote:
As a counterexample, we do a lot of development in Visual C++ because
the GUI is easy to use, and friendly. The final code is however
recompiled for Solaris and Linux.
Both of which support parallel/distributed builds. I work the other
way, use the faster build and test environment on Solaris, recompile for
windows.
Not that I recommend the "VC++ build first" strategy, but there
are add-ons like IncrediBuild which supports distributed building
and gives you a chance to have debug information if the limits of
VC6 are exhausted. Unfortunately, it does not work well with code
coverage tools.
I'm not sure what the "VC++ build first" strategy is, care to explain?
Sorry, I meant the fact that they (Mark's department) develop under
VC++ and then try it out on their target implementation.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
CBFalconer said:
Richard Heathfield wrote:
>>
So far, then, we have exactly ZERO conforming implementations of
C99. So much for that.
Ah, but who can say whether we have any conforming implementations
of c90, or C95. In the absence of a generally available test
suite, which anyone reasonably competent can run, to verify
compliance we cannot really make any such statements. We know we
can find failings in all alleged "C99" implementations. At least
with gcc we have a document available spelling out the known
failings with regard to C99.
Quid custodes costodiens applies.
Do you mean "quis custodies ipsos custodes?" ("who guards the guards
themselves?")? No, it doesn't apply. But yes, you're right, we need to be
able to verify C90 conformance too - not so that we can jump on the
implementors, necessarily, but so that we can be careful about our own
code. For example, I am reasonably sure that Borland's handling of errno is
non-conforming. Because there is a significant chance that my code may be
compiled using Borland's compiler, therefore, I avoid errno like the plague
in my own code. I don't rant and rave about it - I just avoid using that
feature. Same with C99 features, really. I don't worry too much about
certification - I just use the features I know to be portable to all the
implementations on which my code is likely to be compiled.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
CBFalconer said:
Skarmander wrote:
>Mark McIntyre wrote:
... snip ...
>>
>>The final code is however recompiled for Solaris and Linux. This
forces a pretty strict rigour on us, and boy does it sting when
you do an overnight build and some dork has used an MS specific
extension.
See, I don't get this. You actually let the GUI waste your time
like that? Setting up mingw with a separate IDE would be too much
work? It might save you a few overnight suprises. :-)
No, you don't appreciate the actual situation. Some pointy haired
type has hired you as a consultant, and won't let you rampage
through his computer systems installing software. He won't even
let you develop on your own machinery and bring the result in on
some media or other. Thus you are limited to what he has been sold
by the evil empire.
No matter how often I try to explain this to people, they never seem to get
it. "Why don't you just use <foo>?" "Because even though I agree with you
that <foois an excellent solution, my chances of getting it through due
process are zero minus, that's why."
Same with compiler warnings. I like to initialise all my objects, to put
them into a known, deterministic state. It makes debugging much easier.
Others say "why not just ask your compiler to diagnose when you're trying
to use a value you haven't written to yet?" - and the answer, of course, is
that I can't guarantee that the implementation I am using /has/ such an
option. (The compiler is not /required/ to diagnose this solution.)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
In article <45***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>jacob navia wrote:
>sunny wrote:
>>>
What is C99 Standard is all about.
It is the current C standard, as defined by ANSI/ISO. The old
standard (C89) is now obsolete.
Obsolete is not the best word here. Has been replaced by C99 is
probably more accurate.
ANSI C 98 is OBSOLETE to use the correct standards term.
It was superseded by ISO 9899:1990 (C90) which was in turn superseded
by ISO 9899:1999
>To all practical purposes the closest we can get to a C99
implementation is gcc.
This is NOT correct. There are some, but not many, FULL C99
implementations with full C99 compliant libraries.
There are also quite a few compilers that are AFAIK as C99 compliant ac
Gcc.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills <ch***@phaedsys.orgwrites:
In article <45***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>>jacob navia wrote:
>>sunny wrote:
What is C99 Standard is all about.
It is the current C standard, as defined by ANSI/ISO. The old
standard (C89) is now obsolete.
Obsolete is not the best word here. Has been replaced by C99 is
probably more accurate.
ANSI C 98 is OBSOLETE to use the correct standards term.
It was superseded by ISO 9899:1990 (C90) which was in turn
superseded by ISO 9899:1999
Typo: you mean ANSI C 89, not 98.
The fact that the 1990 ISO standard superseded the 1989 ANSI standard
wasn't all that significant; both standards describe the same
language. The differences between C90 and C99 are much more
significant.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Richard Heathfield wrote:
CBFalconer said:
>Richard Heathfield wrote:
>>>
So far, then, we have exactly ZERO conforming implementations of
C99. So much for that.
Ah, but who can say whether we have any conforming implementations
of c90, or C95. In the absence of a generally available test
suite, which anyone reasonably competent can run, to verify
compliance we cannot really make any such statements. We know we
can find failings in all alleged "C99" implementations. At least
with gcc we have a document available spelling out the known
failings with regard to C99.
Quid custodes costodiens applies.
Do you mean "quis custodies ipsos custodes?" ("who guards the guards
themselves?")? No, it doesn't apply. But yes, you're right, we need to be
able to verify C90 conformance too - not so that we can jump on the
implementors, necessarily, but so that we can be careful about our own
code. For example, I am reasonably sure that Borland's handling of errno is
non-conforming. Because there is a significant chance that my code may be
compiled using Borland's compiler, therefore, I avoid errno like the plague
in my own code. I don't rant and rave about it - I just avoid using that
feature. Same with C99 features, really. I don't worry too much about
certification - I just use the features I know to be portable to all the
implementations on which my code is likely to be compiled.
I was suspicious of my memory :-) It is about 60 years since I
took my last Latin course, and flunked it miserably (partly
deliberate, so my parents would let me drop it for more maths and
physics). Now I wish I had paid more attention.
Why do you say doesn't apply? If a proper test suite is ever
developed, it needs to be open source so that everybody can poke
it. Otherwise you depend on the accuracy of the unknown designer.
The Pascal conformance test suite was an excellent example, except
the originators maintained copyright and the whole thing
disappeared. It was geared to the section numbering in the Pascal
standard. Something like t6p2p3-4.pas for test section 6.2.3
number 4. Just compile and execute. A master program could
extract the appropriate source from the suite, run the compiler,
and check results. Some tests needed compilation to fail, others
execution to output 'pass' or 'fail'. The initial letter could
govern those choices.
--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>
CBFalconer said:
Why do you say ["quis custodiet[1] ipsos custodes"] doesn't apply?
Because we are not dependent on third-party test suite implementors for
establishing the conformance or non-conformance of an implementation in
regard to a particular feature. We can, at least in principle, check it
ourselves easily enough. "Does <foocompile? Does it produce the expected
output?"
[1] Yes, I know - in my earlier reply, I got this wrong too.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously) This thread has been closed and replies have been disabled. Please start a new discussion. |
