hmmm, no C99

[Serve La]

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more

We feel that C++ addresses this space
sufficiently. In general we have no plans to add any C99 features that
duplicate functionality in C++ or conflict with it.

That also matches the feedback we have gotten from customers. In fact the
non interest in C99 is the clearest feedback I have seen of any issue. The
ratio of customers who don't want us to prioritize C99 features versus those
who do is definitely higher than 100:1.


They have planned "restrict" BTW, the one feature I like the least.

 

[Irrwahn Grausewitz]

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more

We feel that C++ addresses this space
sufficiently. In general we have no plans to add any C99 features that
duplicate functionality in C++ or conflict with it.

That also matches the feedback we have gotten from customers. In fact the
non interest in C99 is the clearest feedback I have seen of any issue. The
ratio of customers who don't want us to prioritize C99 features versus those
who do is definitely higher than 100:1.


They have planned "restrict" BTW, the one feature I like the least.

Surprised, anyone? This is not to start flame war, but IMHO people
using braindead M$VC for compiling C code are, err..., well..., nah,
I'm not going to insult someone for using a specific product.

Irrwahn

( using gcc, yet another product of the Sirius Cybernetics Corp. ;] )

 

[jacob navia]

This is great news.

At least there *is* a market niche within windows that is not occupied by Microsoft!

The lcc-win32 compiler implements most of C99. A full C99 compliant release is
some months away, but most features are implemented.

http://www.cs.virginia.edu/~lcc-win32

 

[Richard Heathfield]

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more

Or vote with your feet.

They have planned "restrict" BTW, the one feature I like the least.

C'est la vie. You don't /have/ to use Visual C, though. There are other
compilers for the Windows platform.

 

[John Tsiombikas (Nuclear / the Lab)]

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more

Hmmm not really, whine as much as you like but I couldn't give a damn since I
don't use the MSVC/C++ compiler
GCC just rulez

-- Nuclear / the Lab --

 

[Allin Cottrell]

Surprised, anyone? This is not to start flame war, but IMHO people
using braindead M$VC for compiling C code are, err..., well..., nah,
I'm not going to insult someone for using a specific product.

Irrwahn

( using gcc, yet another product of the Sirius Cybernetics Corp. ;] )

Yes, well, gcc is not in any hurry to comply with C99 either. I'm
as ready as the next person to blast MS, but in this case the target
seems wrong. Rather, it seems that the C standards group came up
with something that just has not caught on. To date (4 years after
the standard was promulgated), the only C compiler vendors claiming
full C99 compliance are (no offence intended) marginal to the
market. Why should MS devote a lot of expense to something that
few programmers really seem to want? Why should the gcc authors?

 

[Fao, Sean]

Yes, well, gcc is not in any hurry to comply with C99 either. I'm
as ready as the next person to blast MS, but in this case the target
seems wrong. Rather, it seems that the C standards group came up
with something that just has not caught on. To date (4 years after
the standard was promulgated), the only C compiler vendors claiming
full C99 compliance are (no offence intended) marginal to the
market. Why should MS devote a lot of expense to something that
few programmers really seem to want? Why should the gcc authors?

I have read very little of the standard but from what I have read, C99 looks
like it has some great improvements over past standards. I'm just curious
why people would be so uninterested. From what I have gathered about this
group, the majority seem to be pro C99; but, suggest not to use it *yet*
(Again I want to stress that this is only based on simple observation, I
could be entirely wrong about what you all _honestly_ think of the
standard). If somebody is compiling code that will *never* be ported to
another platform, I see no reason not to use the new standard, so long as a
compiler exists for the platform you're developing on. What's the verdict
here?

Sean

 

[Allin Cottrell]

I have read very little of the standard but from what I have read, C99 looks
like it has some great improvements over past standards. I'm just curious
why people would be so uninterested. From what I have gathered about this
group, the majority seem to be pro C99; but, suggest not to use it *yet*

I'm not going to claim great expertise, but I've found Dan Pop's postings
on this topic quite persuasive. He points out that C99 includes several
features present in GNU C, but with slightly different semantics. This
would make it awkward for gcc (for one) to move to full C99 compliance.

 

[Jack Klein]

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more

We feel that C++ addresses this space
sufficiently. In general we have no plans to add any C99 features that
duplicate functionality in C++ or conflict with it.

That also matches the feedback we have gotten from customers. In fact the
non interest in C99 is the clearest feedback I have seen of any issue. The
ratio of customers who don't want us to prioritize C99 features versus those
who do is definitely higher than 100:1.


They have planned "restrict" BTW, the one feature I like the least.

Despite what some other responses in this thread claim, MSVC++, at
least through version 6, is quite a good C95 implementation.

In addition to lcc-win32's steady progress toward full C99 conformance
(thank you very sincerely, Jacob, I am one of your biggest fans), and
Comeau's front end for various back ends, there does seem to be some
promise from a major Windows compiler vendor, namely Borland.

Their recently announced cross-platform C++ BuilderX is supposed to
eventually come with a brand new optimizing compiler with top priority
given to full ISO C++ and C99 conformance, although the C99 is far
less mentioned on their web site than C++.

The real issue, as Microsoft puts it, is putting their priority, and
development effort, on what the majority of their customers want.
There are very few "small" Windows applications anymore, and C is not
the primary language of choice for large GUI applications in desktop
environments these days.

The major stronghold of C today is in embedded systems, where in the
last 10 to 15 years it has totally outstripped hand coded assembly
language.

The vast majority of embedded systems coded in C are implemented with
smaller 8 or 16 bit microprocessors and microcontrollers. These
people do not want or need many of the new C99 features, such as
variable length arrays or the long long data type. In fact although
all of these compilers call themselves "ANSI C", it usually means that
they allow function prototypes. Many don't implement floating point
at all or provide nothing wider than a 32-bit IEEE single precision
type, so they are not even conforming free-standing implementations.

There is some hope on the higher end 32-bit systems. Several
compilers were adding C99 features. Although I am a few versions and
a few years behind the latest, CodeWarrior and ARM's compilers were
adding C99 features steadily with each release the last time I looked.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Ben Pfaff]

I asked if MS has any plans to support C99 in the next VisualC.

I had the regrettable need to use MSVC, briefly, today. One line
of code evoked this error, or something to the same effect:
x.c:200: conversion from `unsigned long long' to `double'
not implemented (use `long long' instead)
Sheesh. Talk about half-efforts.

 

[Randy Howard]

Surprised, anyone? This is not to start flame war, but IMHO people
using braindead M$VC for compiling C code are, err..., well..., nah,
I'm not going to insult someone for using a specific product.

Irrwahn

( using gcc, yet another product of the Sirius Cybernetics Corp. ;] )

Anyone read the latest DDJ, particularly the article on C and C++ compiler
performance? gcc gets it's proverbial butt handed to it in terms of
compile time, run-time performance and code size as compared to 8 or 9
other compilers, including that evil one from MS.

I'm not saying it's not a great product if you're really into writing code
for a ton of obscure platforms (as I seem to be doing more and more
lately), but ...

 

[LibraryUser]

.... snip ...

Yes, well, gcc is not in any hurry to comply with C99 either. I'm
as ready as the next person to blast MS, but in this case the target
seems wrong. Rather, it seems that the C standards group came up
with something that just has not caught on. To date (4 years after
the standard was promulgated), the only C compiler vendors claiming
full C99 compliance are (no offence intended) marginal to the
market. Why should MS devote a lot of expense to something that
few programmers really seem to want? Why should the gcc authors?

However gcc is making steady progress towards C99 compliance.
This is definitely an aim. The salary levels for gcc programmers
may have a negative effect on the rapidity of that progress,
inasmuch as volunteerism is not usually as financially rewarding
as heading Enron, WorldCom, the NYSE, or having pals in that
white house.

 

[jacob navia]

Yes, this bug is since quite a long time.

The problem is that to do this conversion you cannot use the x86, since the
only 64 bit integer conversion in the x86 is signed. Unsigned long long means
that a quite long sequence of machine instructions must be emitted.

 

[Serve Laurijssen]

Their recently announced cross-platform C++ BuilderX is supposed to
eventually come with a brand new optimizing compiler with top priority
given to full ISO C++ and C99 conformance, although the C99 is far
less mentioned on their web site than C++.

Yes, what's up with BuilderX? I've read the marketing story, but I'm still
not sure whether they've included a compiler. It seems to me it's a cross
platform IDE in which you can plug other compilers/debuggers. So they will
be including a newer C++/C99 compiler in the future?

 

[Dan Pop]

However gcc is making steady progress towards C99 compliance.

What "steady progress" are you talking about? I haven't noticed any
changes in http://gcc.gnu.org/c99status.html for the last couple of
years...

Dan

 

[Mike Wahler]

Yes, this bug is since quite a long time.

The problem is that to do this conversion you cannot use the x86, since the
only 64 bit integer conversion in the x86 is signed. Unsigned long long means
that a quite long sequence of machine instructions must be emitted.

In which case I'd have gone ahead and emitted them,
and given a performance warning.

-Mike

 

[Serve La]

Or vote with your feet.



C'est la vie. You don't /have/ to use Visual C, though. There are other
compilers for the Windows platform.

First, I wish I had the luxury of choosing a compiler.
Second, when somebody writes void main everybody starts shouting that it's
not portable. Following this logic, when some compiler refuses to implement
C99 it makes all those C99 features not portable. Isn't that a bit strange?

 

[Richard Heathfield]

Serve La wrote:

Second, when somebody writes void main everybody starts shouting that it's
not portable. Following this logic, when some compiler refuses to
implement C99 it makes all those C99 features not portable. Isn't that a
bit strange?

Strictly conforming code written to C99 rules is portable to all conforming
C99 compilers, of which the number appears (slowly) to be increasing. The
same cannot be said for void main.

 

[Severian]

Yes, this bug is since quite a long time.

The problem is that to do this conversion you cannot use the x86, since the
only 64 bit integer conversion in the x86 is signed. Unsigned long long means
that a quite long sequence of machine instructions must be emitted.

On the x86, doesn't a long long have more digits of precision than a
double? If so, doesn't this do the trick, at least on the X86?

unsigned long long v;
double d;

if (v <= LONGLONG_MAX)
d = (double)(long long)v;
else if (v < ULONGLONG_MAX)
d = ((double)(long long)((v+1)>>1)) * 2.0;
else
d = 18446744073709551615.0; /* X86 64-bit ULL */
}

(I don't know about the _MAX constants; I left my copy of the standard
at home today.)

Does this really require "a lot" of X86 instructions? It seems to me
that the first condition will be true in most circumstances, so the
performance penalty wouldn't be that great regardless.

- Sev

 

[Default User]

Second, when somebody writes void main everybody starts shouting that it's
not portable. Following this logic, when some compiler refuses to implement
C99 it makes all those C99 features not portable. Isn't that a bit strange?

Please explain your reasoning. There are compilers that didn't implement
the previous standard either, are you saying that was nonportable?


You are missing the point that extensions, by their very nature, are
outside of the standard. There is no requirement for compilers that do
implement the standard to include them, so they are nonportable.




Brian Rodenborn