Free Microsoft Visual C++ Toolkit 2003

[P.J. Plauger]

.....

I thought they had got a lot better with C99 compliance of late? As they
have the TR on the C library I thought they were doing something in C.

They're doing *things* in C, but not C99. Microsoft is very blunt about
responding to user needs first and foremost. There was a loud hue and
cry over security, thanks to all the viruses out there, but next to no
call for C99 features.

Secure, safer, safe, bounded... Any bets on the final name?


I thought the people involved were also closely involved with MS? I also
recall being present when MS gave a presentation on the Secure C (as it
was then) library proposal. I have been looking for a copy of that
presentation recently. It was either at Reading or Oxford.

Yes, the secure/bounded/whatever TR was propsed by Microsoft and gets
plenty of attention/support from them. That's the *only* project in
the C committee where they're at all active.

Maybe not C but I refer you to the arguments on C++/CLI and C++ that are
currently raging all over. Lets not get into that one. I have seen the
many hundreds of column inches on that debate.

Okay, but it's worth observing that C++/CLI is *not* Standard C++, and it
*is* highly compatible with Standard C++. Most of the noise reflects
fears that C++/CLI will first be mistaken for Standard C++, then displace
it. But there's no way it can *change* Standard C++, not without the
agreement of WG21.

That with MS having a major role in ECMA and the standards mentioned
above being fasted tracked though ISO along with the C and C++ library
TR's that MS was "bending the standards to fit MS." which would not
help people on other platforms or not using MS tools.

Let me try again. Microsoft is involved in *no* C++ library TRs. It is
involved in *one* C TR that is still in the works, and it is
non-normative. None of the ECMA standards, fast tracked or otherwise,
alter Standard C or Standard C++ in any way.

This can not be disputed. It think the worry is that ISO standards are
describing particular commercial products rather than a generic
standard.

That's true enough. And I won't bother to pay lip service to the feeble
attempts to generate open source equivalents to .NET and C#. Even so,
Microsoft deserves some credit for doing what Sun couldn't bring itself
to do with Java -- cede nominal control of the official definition (and
future) to an independent body.

IE it gives MS & Windows an advantage over everyone else. You know well
there are lots of arguments about that all over the place. However.....


BTW I joined the BSI C panel in late 99 AFTER it was Issued so it ain't
my fault

It's not entirely mine either, in the case of both C99 and C++. OTOH,
I know that I could have done more to mitigate the damage.

Good point.

In another place we have discussed the fact that there are MANY far
better standards, methods and languages that were used once or twice and
are now rotting in some University completely unused and forgotten save
as papers at a conference long ago because they just did not run in
industry.

Better in what sense? If a standard doesn't unite an industry it's a
failure, however well crafted. By that metric, Fortran and Cobol each
have a couple of real successes, and C89 is arguably the most successful
programming language standard in history. C95, C99, and C++ are less so,
but far from complete failures.

The question is do you go for technical/academic perfection or add
exotic new features that someone thinks are "essential" (or sexy) rather
than something that is actually going to be used in industry? This is a
difficult debate. I favour incremental improvements on current
industrial practice. Usually by looking at what the majority are
implementing. IE the industry will innovate then ISO can standardise it.

That's my favorite modus operandi as well.

I think the fear is that this is what ONE compiler vendor is
implementing not what most are implementing.

Again, if you're talking about the ECMA standards originated by Microsoft,
and even the secure/bounded/whatever TR in C, then you have a legitimate
gripe. But you keep spreading that fear to Standard C and C++, which so
far are well defended against takeover attempts by any single constituency.

As for who is the Good Citizen.... MS can not qualify as it is well
known to be the Spawn of Satan and Controlling The World on behalf of
the Freemasons, Jews, Jesuits, Catholics and David Ike's Lizards from
Mars etc.

Smiley notwithstanding, I will always counter such a kneejerk reaction.
Microsoft has certainly committed sins in the past, but in the standards
arena they have been on pretty good behavior the last several years.
It stifles rational debate not to notice and acknowledge the fact.

As it is I think the OP was fine to post on c.l.c that a commercial
C/C++ compiler that is a market leader in now available for free.

Indeed. And it comes with a pretty good library...

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Al Balmer]

Really? What about the 1999 ISO C standard? Is this 2003 compiler
complient?

No. In fact, MS has said that they have no intention of trying to make
the C compiler C99 compliant. OTOH, the C++ compiler is pretty much up
to current standards, as I understand it.

 

[Keith Thompson]

You must be confusing C and C++ here. Microsoft has offered reasonably
good compliance to C95 for over a decade, but they have done very little
to pursue C99 compliance. OTOH, the past few years have seen great
improvement in C++ (1999) compliance, first with VC++ V7.1 and now with
V8.0. The major missing feature is separate compilation of templates,
which so far is provided only by Edison Design Group.

<OT><QUIBBLE>
My copy of the C++ standard is dated 1998, not 1999.
</QUIBBLE></OT>

 

[Malcolm]

Better in what sense? If a standard doesn't unite an industry it's a
failure, however well crafted. By that metric, Fortran and Cobol each
have a couple of real successes, and C89 is arguably the most successful
programming language standard in history. C95, C99, and C++ are less so,
but far from complete failures.

C99 was a disaster.
The problem is that when a standard fails, it also damages the standard that
it supercedes. So the situation is that we currently don't have a standard
for C, and the best that can be done is to write conservative C89 in the
knowledge that it is unlikely to break.

There are some real weaknesses in C89. One is "BOOL breaks libraries" - all
you need is for some idiot to put declarations like typedef int BOOL; in a
header and code that uses the library either has to use its conventions
throughout, or be reduced to an unmaintainable mess.

I've lost count of the number of times I've had to edit perfectly good 3D
graphics code just because there is no standard definition of points and
vectors. A standard library would take all of five minutes to implement.

Indeed. And it comes with a pretty good library...

Was that a subtle ad?

 

[Richard Bos]

People with normal emotional adjustment (and people interested in maximizing
productivity) prefer GUI interfaces.

Bollocks. People interested in real productivity prefer being able to
choose their own editor or editing environment, not being locked into an
MS-designed one.

Richard

 

[Michael O'Keeffe]

Get the current version. Then you don't have to suffer a command line
interface.

Actually, there are very good reasons why command-line, or at least
using a very simple editor, is superior:

http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

 

[Flash Gordon]

Bollocks. People interested in real productivity prefer being able to
choose their own editor or editing environment, not being locked into an
MS-designed one.

This is almost certainly a completely pointless argument. I've yet to
find a major GUI based IDE that did not provide a mechanism for invoking
the compiler from the command line. So use MS VC++ if you want, and use
it as a command line compiler or a full IDE depending on your
preferences and requirements.

I used to use Turbo Pascal as an IDE for debugging and invoke it from
batch files for formal builds of the same software.

This is all also somewhat off topic for comp.lang.c since the arguments
are the same whatever language you are using.