Shame on me - Microsoft fooled me again... 
Author Message
 Shame on me - Microsoft fooled me again...

I read all the reviews on how Microsoft claimed that VC 7.0 is a vast improvement towards supporting both C and C++ standards (C98 and C99 specifically).  So, I bought it - hook line and sinker.  Boy, was I surprised to discover that after buying VS.NET that they didn't even include 'stdint.h' and 'cstdint'.  These are mere header files that required no additional compiler changes.  Man, they must have been burning the midnight oil to get all those *standards* in there.

For those who need it ... See attached.

PS: In the tradition of Microsoft, I included a few Windows specific definitions in addition to what's called out in the standards.

Please peer review - Comments are welcome!

One improvement might be to define int32_t and uint32_t to be based on "long" instead of "int".  This way they would be compatible with DWORD and its variants.

  stdint.h
7K Download

  cstdint
1K Download


Sun, 04 Dec 2005 10:15:35 GMT  
 Shame on me - Microsoft fooled me again...
<stdint.h> is a C99 header, while <cstdint> is neither C89 nor C99 nor
C++98.  The claimed (and delivered) much improved standards conformance in
VC7.1 (and to a lesser extent VC7) is with the C++98 standard, not the C99
standard.

-cd


I read all the reviews on how Microsoft claimed that VC 7.0 is a vast
improvement towards supporting both C and C++ standards (C98 and C99
specifically).  So, I bought it - hook line and sinker.  Boy, was I
surprised to discover that after buying VS.NET that they didn't even include
'stdint.h' and 'cstdint'.  These are mere header files that required no
additional compiler changes.  Man, they must have been burning the midnight
oil to get all those *standards* in there.

For those who need it ... See attached.

PS: In the tradition of Microsoft, I included a few Windows specific
definitions in addition to what's called out in the standards.

Please peer review - Comments are welcome!

One improvement might be to define int32_t and uint32_t to be based on
"long" instead of "int".  This way they would be compatible with DWORD and
its variants.



Sun, 04 Dec 2005 12:22:21 GMT  
 Shame on me - Microsoft fooled me again...
Fine.  I'll give you that.  So what about C99?



Quote:
> <stdint.h> is a C99 header, while <cstdint> is neither C89 nor C99 nor
> C++98.  The claimed (and delivered) much improved standards conformance in
> VC7.1 (and to a lesser extent VC7) is with the C++98 standard, not the C99
> standard.

> -cd



> I read all the reviews on how Microsoft claimed that VC 7.0 is a vast
> improvement towards supporting both C and C++ standards (C98 and C99
> specifically).  So, I bought it - hook line and sinker.  Boy, was I
> surprised to discover that after buying VS.NET that they didn't even
include
> 'stdint.h' and 'cstdint'.  These are mere header files that required no
> additional compiler changes.  Man, they must have been burning the
midnight
> oil to get all those *standards* in there.

> For those who need it ... See attached.

> PS: In the tradition of Microsoft, I included a few Windows specific
> definitions in addition to what's called out in the standards.

> Please peer review - Comments are welcome!

> One improvement might be to define int32_t and uint32_t to be based on
> "long" instead of "int".  This way they would be compatible with DWORD and
> its variants.



Mon, 05 Dec 2005 07:51:21 GMT  
 Shame on me - Microsoft fooled me again...
C99 is very much a non investment area for us based on _extremely_ strong
customer feedback. In almost all venues we asked for prioritizing C99
support against other features it came out dead last. In general our
customer are very interested in us following the C++ standards, but consider
C standards a dead track.

Of course nothing is static and input and decision can change, but in all my
experiences in getting customer input on prioritizing features this one has
probably been the one where we got the most clear and unambiguous feedback.

Ronald Laeremans
Visual C++ team


Quote:
> Fine.  I'll give you that.  So what about C99?



> > <stdint.h> is a C99 header, while <cstdint> is neither C89 nor C99 nor
> > C++98.  The claimed (and delivered) much improved standards conformance
in
> > VC7.1 (and to a lesser extent VC7) is with the C++98 standard, not the
C99
> > standard.

> > -cd



> > I read all the reviews on how Microsoft claimed that VC 7.0 is a vast
> > improvement towards supporting both C and C++ standards (C98 and C99
> > specifically).  So, I bought it - hook line and sinker.  Boy, was I
> > surprised to discover that after buying VS.NET that they didn't even
> include
> > 'stdint.h' and 'cstdint'.  These are mere header files that required no
> > additional compiler changes.  Man, they must have been burning the
> midnight
> > oil to get all those *standards* in there.

> > For those who need it ... See attached.

> > PS: In the tradition of Microsoft, I included a few Windows specific
> > definitions in addition to what's called out in the standards.

> > Please peer review - Comments are welcome!

> > One improvement might be to define int32_t and uint32_t to be based on
> > "long" instead of "int".  This way they would be compatible with DWORD
and
> > its variants.



Mon, 05 Dec 2005 11:01:06 GMT  
 Shame on me - Microsoft fooled me again...
Ronald,

Had you made that claim in 1999 when there was a high demand for C99
conformance, we wouldn't have believed your customer feedback.  Today, your
claim would only make sense if you _were_ C99 conformant and customer
feedback indicated that they no longer wanted you to continue down the C0x
track (in favor of C++0x).  However, since C++0x will likely merge C99 and
C++98, why would C99 conformance (in spirit at least) no longer be in
demand?

Here's my point: VC.Net is neither C99 nor C++98 conformant.  Being
partially conformant does not count.  The original statement I made stands
(accepting the correction made by Carl).  I'm one of three partners in a
consulting firm that ports Linux/UNIX applications to Windows.  We've been
doing this since 1994.

Recently, we accepted a bid that reqired us to use "the most recent GA of
Microsoft C/C++ compilers and tools" which is VC.NET.  We welcomed this
requirement because we thought this would make the job easier - we believed
that the _conformance_ short comings in VC6.0 had been resolved.  Why?
Because Microsoft boasted their conformance in 7.0 pre-release spin and had
commited themselves to being conformant following an earlier CUJ compiler
conformance challenge two years earlier.

We began the project by converting make files to .vcproj's and adding our
port paths (as we always do).  We shot for a build to see where we stood.
Well, guess what - "stdint.h" was not there (a C99 short coming) and certain
template specializations were broke (a C++98 short coming)!  Other things
(i.e. "unistd.h", IPCs and async-I/O) we had worked out long ago.

Needless to say, this was an unexpected (and unnecessary) delay.  Having to
make _standard_ headers and fixing template definitions were not
anticipated.  We did expect a mild learning curve with the new IDE (which is
way cool by the way ;-).  We really felt sucker punched (again).  Then to
top it all off, we browsed the *new* documentation to find answers but what
did we find?  Well, lets just say there sure is a hell of alot of VB and C#
matter to navigate around.

We need Microsoft tools, but we don't always prefer them.  Most of our
gripes seem to be over the lack of standards conformance!  I came here to
vent and share the header files with other poor saps who also might need
them.  We'd all like a _serious_ commitment to standard conformance in word
and in deed ("your actions speak so loudly that I can't here you" comes to
mind).  I mean, for Pete's sake - Microsoft just spent billions on making
four new programming languages C++.NET, VB.NET, C#.NET and ASP.NET.  A few
tens of millions more could have been spent within your [VC++] department on
standard conformance.  Right?  What's up with that anyway?   Is Bill
allocating all the resources and spending mroe money on C# and .NET?  Is
Microsoft even going to have a *real* C/C++ compiler in the future?

-MerkX Zyban



Quote:
> C99 is very much a non investment area for us based on _extremely_ strong
> customer feedback. In almost all venues we asked for prioritizing C99
> support against other features it came out dead last. In general our
> customer are very interested in us following the C++ standards, but
consider
> C standards a dead track.

> Of course nothing is static and input and decision can change, but in all
my
> experiences in getting customer input on prioritizing features this one
has
> probably been the one where we got the most clear and unambiguous
feedback.

> Ronald Laeremans
> Visual C++ team



> > Fine.  I'll give you that.  So what about C99?



> > > <stdint.h> is a C99 header, while <cstdint> is neither C89 nor C99 nor
> > > C++98.  The claimed (and delivered) much improved standards
conformance
> in
> > > VC7.1 (and to a lesser extent VC7) is with the C++98 standard, not the
> C99
> > > standard.

> > > -cd



> > > I read all the reviews on how Microsoft claimed that VC 7.0 is a vast
> > > improvement towards supporting both C and C++ standards (C98 and C99
> > > specifically).  So, I bought it - hook line and sinker.  Boy, was I
> > > surprised to discover that after buying VS.NET that they didn't even
> > include
> > > 'stdint.h' and 'cstdint'.  These are mere header files that required
no
> > > additional compiler changes.  Man, they must have been burning the
> > midnight
> > > oil to get all those *standards* in there.

> > > For those who need it ... See attached.

> > > PS: In the tradition of Microsoft, I included a few Windows specific
> > > definitions in addition to what's called out in the standards.

> > > Please peer review - Comments are welcome!

> > > One improvement might be to define int32_t and uint32_t to be based on
> > > "long" instead of "int".  This way they would be compatible with DWORD
> and
> > > its variants.



Mon, 05 Dec 2005 14:08:31 GMT  
 Shame on me - Microsoft fooled me again...
Use the 7.1 compiler and not the 7.0 compiler. It is very much in the
conformance ballpark with the top 2-3 other most conformant compilers. 7.0
isn't.

Note that unlike C there hasn't been a single compiler validated against the
C++ standard. I know that there was one organization that had said they were
willing and able to do validation, but as far as I know no compiler has ever
been submitted and I don't even know whether that company still offers
validation services.

If C++0x merges in C99 than we will treat these features as high priority as
other C++0x features. Note however that this is extremely far from a done
deal and that there are almost certainly huge features that will not be
re-integrated. I am going on Bjarne's position paper and further discussion
in the committee for that.

Ronald


Quote:
> Ronald,

> Had you made that claim in 1999 when there was a high demand for C99
> conformance, we wouldn't have believed your customer feedback.  Today,
your
> claim would only make sense if you _were_ C99 conformant and customer
> feedback indicated that they no longer wanted you to continue down the C0x
> track (in favor of C++0x).  However, since C++0x will likely merge C99 and
> C++98, why would C99 conformance (in spirit at least) no longer be in
> demand?

> Here's my point: VC.NET is neither C99 nor C++98 conformant.  Being
> partially conformant does not count.  The original statement I made stands
> (accepting the correction made by Carl).  I'm one of three partners in a
> consulting firm that ports Linux/UNIX applications to Windows.  We've been
> doing this since 1994.

> Recently, we accepted a bid that reqired us to use "the most recent GA of
> Microsoft C/C++ compilers and tools" which is VC.NET.  We welcomed this
> requirement because we thought this would make the job easier - we
believed
> that the _conformance_ short comings in VC6.0 had been resolved.  Why?
> Because Microsoft boasted their conformance in 7.0 pre-release spin and
had
> commited themselves to being conformant following an earlier CUJ compiler
> conformance challenge two years earlier.

> We began the project by converting make files to .vcproj's and adding our
> port paths (as we always do).  We shot for a build to see where we stood.
> Well, guess what - "stdint.h" was not there (a C99 short coming) and
certain
> template specializations were broke (a C++98 short coming)!  Other things
> (i.e. "unistd.h", IPCs and async-I/O) we had worked out long ago.

> Needless to say, this was an unexpected (and unnecessary) delay.  Having
to
> make _standard_ headers and fixing template definitions were not
> anticipated.  We did expect a mild learning curve with the new IDE (which
is
> way cool by the way ;-).  We really felt sucker punched (again).  Then to
> top it all off, we browsed the *new* documentation to find answers but
what
> did we find?  Well, lets just say there sure is a hell of alot of VB and
C#
> matter to navigate around.

> We need Microsoft tools, but we don't always prefer them.  Most of our
> gripes seem to be over the lack of standards conformance!  I came here to
> vent and share the header files with other poor saps who also might need
> them.  We'd all like a _serious_ commitment to standard conformance in
word
> and in deed ("your actions speak so loudly that I can't here you" comes to
> mind).  I mean, for Pete's sake - Microsoft just spent billions on making
> four new programming languages C++.NET, VB.NET, C#.NET and ASP.NET.  A few
> tens of millions more could have been spent within your [VC++] department
on
> standard conformance.  Right?  What's up with that anyway?   Is Bill
> allocating all the resources and spending mroe money on C# and .NET?  Is
> Microsoft even going to have a *real* C/C++ compiler in the future?

> -MerkX Zyban



> > C99 is very much a non investment area for us based on _extremely_
strong
> > customer feedback. In almost all venues we asked for prioritizing C99
> > support against other features it came out dead last. In general our
> > customer are very interested in us following the C++ standards, but
> consider
> > C standards a dead track.

> > Of course nothing is static and input and decision can change, but in
all
> my
> > experiences in getting customer input on prioritizing features this one
> has
> > probably been the one where we got the most clear and unambiguous
> feedback.

> > Ronald Laeremans
> > Visual C++ team



> > > Fine.  I'll give you that.  So what about C99?



> > > > <stdint.h> is a C99 header, while <cstdint> is neither C89 nor C99
nor
> > > > C++98.  The claimed (and delivered) much improved standards
> conformance
> > in
> > > > VC7.1 (and to a lesser extent VC7) is with the C++98 standard, not
the
> > C99
> > > > standard.

> > > > -cd



> > > > I read all the reviews on how Microsoft claimed that VC 7.0 is a
vast
> > > > improvement towards supporting both C and C++ standards (C98 and C99
> > > > specifically).  So, I bought it - hook line and sinker.  Boy, was I
> > > > surprised to discover that after buying VS.NET that they didn't even
> > > include
> > > > 'stdint.h' and 'cstdint'.  These are mere header files that required
> no
> > > > additional compiler changes.  Man, they must have been burning the
> > > midnight
> > > > oil to get all those *standards* in there.

> > > > For those who need it ... See attached.

> > > > PS: In the tradition of Microsoft, I included a few Windows specific
> > > > definitions in addition to what's called out in the standards.

> > > > Please peer review - Comments are welcome!

> > > > One improvement might be to define int32_t and uint32_t to be based
on
> > > > "long" instead of "int".  This way they would be compatible with
DWORD
> > and
> > > > its variants.



Tue, 06 Dec 2005 02:44:45 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. SQL XML Microsoft poor samples again!

2. MicroSoft vs Borland Again / PC-Week article

3. Borland vs Microsoft...again

4. Seems Like A Shame

5. Shame on me....

6. Fooling gcc why and how

7. To all the FOOLS on this newsgroup...

8. A little humor to wrap up April Fool's day

9. FAST CASH - NO FOOLING - LEGAL

10. MFC and the April Fools 2001 bug

11. K & R April Fool wanted please

12. followup to fooling with pi

 

 
Powered by phpBB® Forum Software