Evils of M$ and C++ability

[Malcolm McLean]

My expensive MS VC++ has been broken my Microsoft, obliging me to go the
cheap and cheerful freebie Express route, at least until a native Vista
compiler comes out.
Anyway it has a thing called .net managed code. When you try to add a C file
it complains about security vioations. Change the file to a C++ file, add an
#include "stdafx.h" and, hey presto, running code.

The moral is, you never know when you might have to cast your mallocs().
All the interesting parts of my next program will be in ANSI C, except the
bits that shall run on a Lisp intepreter written in C, but I will need to
hook it up to various windowing systems, of which Windows will be one.

 

[user923005]

My expensive MS VC++ has been broken my Microsoft, obliging me to go the
cheap and cheerful freebie Express route, at least until a native Vista
compiler comes out.
Anyway it has a thing called .net managed code. When you try to add a C file
it complains about security vioations. Change the file to a C++ file, add an
#include "stdafx.h" and, hey presto, running code.

Just change the project type.

The moral is, you never know when you might have to cast your mallocs().
All the interesting parts of my next program will be in ANSI C, except the
bits that shall run on a Lisp intepreter written in C, but I will need to
hook it up to various windowing systems, of which Windows will be one.

<OT-ASIDE>
I will admit that the warning errors (unless you suppress warning
4996) about things like "fopen() has been deprecated! fread() has been
deprecated!" are truly annoying, though.

The eventual aim of managed code is a good thing overall. It aims to
make C a much safer language. And if you don't want to use it, you
can use unmanaged code.
</OT-ASIDE>

 

[Flash Gordon]

user923005 wrote, On 07/04/07 08:20:

Just change the project type.

And make sure all the other options are set correctly.

<snip>

No, the moral is learn how to drive your tools properly.

 

[Richard Heathfield]

Malcolm McLean said:

My expensive MS VC++ has been broken my Microsoft, obliging me to go
the cheap and cheerful freebie Express route, at least until a native
Vista compiler comes out.
Anyway it has a thing called .net managed code. When you try to add a
C file it complains about security vioations. Change the file to a C++
file, add an
#include "stdafx.h" and, hey presto, running code.

That's the wrong solution. The right solution is to discard the broken
implementation and find something that works.

The moral is, you never know when you might have to cast your
mallocs().

When hell freezes over.

 

[klaushuotari]

On Apr 6, 4:08 pm, "Malcolm McLean" <[email protected]> wrote:

<OT-ASIDE>
I will admit that the warning errors (unless you suppress warning
4996) about things like "fopen() has been deprecated! fread() has been
deprecated!" are truly annoying, though.

The eventual aim of managed code is a good thing overall. It aims to
make C a much safer language. And if you don't want to use it, you
can use unmanaged code.
</OT-ASIDE>

Why is fopen() and fread been deprecated? That's just crazy.

 

[Richard Heathfield]

(e-mail address removed) said:

Why is fopen() and fread been deprecated?

They haven't been.

That's just crazy.

Don't believe all you read.

 

[Keith Thompson]

(e-mail address removed) said:

They haven't been.


Don't believe all you read.

I think Microsoft has decided to treat a lot of standard C functions
as deprecated, in favor of functions from their own "safer" C library.
For more details, ask in a Microsoft-specific forum. As far as
standard C is concerned, fopen() and fread() have certainly not been
deprecated.

 

[Richard Heathfield]

Keith Thompson said:

I think Microsoft has decided to treat a lot of standard C functions
as deprecated,

So? Here we discuss C, not Microsoft's in-house coding rules.

in favor of functions from their own "safer" C library.

Never have quotation marks been sacrificed in so valiant a cause!

 

[Malcolm McLean]

I think Microsoft has decided to treat a lot of standard C functions
as deprecated, in favor of functions from their own "safer" C library.
For more details, ask in a Microsoft-specific forum. As far as
standard C is concerned, fopen() and fread() have certainly not been
deprecated.

As far as I can tell they have deprecated C. Relabelling a C file as dot cpp
makes it safe enough to be included in dot net, apparently.

Learning new languages, tools, and interfaces is a constant situation for
anyone involved in computing, and it wastes oceans of time. I spent a whole
morning getting a "hello world" dot net program to compile, because the
drawing routines had been so wrapped up in stupid interfaces. Then I spent a
whole day trying to get GNU Common Lisp to produce an executable. Eventually
I managed to coax an object file out of it, but the linker would only link
with library files in one directory. Basically Vista had screwed the paths
so badly that I couldn't undo things.

 

[Keith Thompson]

Keith Thompson said:



So? Here we discuss C, not Microsoft's in-house coding rules.

Um, yes, I know that. A poster asked why fopen() and fread() have
been deprecated. Obviously they haven't, but it seemed relevant to
explain why it might seem that they have. You snipped the question
and my clarification:

| For more details, ask in a Microsoft-specific forum. As far as
| standard C is concerned, fopen() and fread() have certainly not been
| deprecated.

A sufficiently careless reader, seeing your followup but not mine,
might think that I was endorsing Microsoft's decision. Which I'm sure
wasn't your intent.

(Incidentally, I don't really know enough about what Microsoft has
done to say anything definitive on it; what I've written about it here
is inferred from what others have written about it here.)

[...]

 

[Richard Heathfield]

Keith Thompson said:

A sufficiently careless reader, seeing your followup but not mine,
might think that I was endorsing Microsoft's decision. Which I'm sure
wasn't your intent.

Indeed it wasn't. I should add that my articles are intended only to be
read by insufficiently careless readers.

 

[Malcolm McLean]

I have compiled a lot of ansi c programs without any problems using
the Microsoft compiler. You can have an "anti-microsoft" attitude
but the compiler is not a reason for that, in my opinion.

There's no problem compiling ANSI C programs. But I didn't buy a flashy new
dual core PC with a 2 billion dollar windowing system to run command-line
apps. I want nice graphics.

 

[jacob navia]

Malcolm McLean a écrit :

My expensive MS VC++ has been broken my Microsoft, obliging me to go the
cheap and cheerful freebie Express route, at least until a native Vista
compiler comes out.
Anyway it has a thing called .net managed code. When you try to add a C
file it complains about security vioations. Change the file to a C++
file, add an #include "stdafx.h" and, hey presto, running code.

The moral is, you never know when you might have to cast your mallocs().
All the interesting parts of my next program will be in ANSI C, except
the bits that shall run on a Lisp intepreter written in C, but I will
need to hook it up to various windowing systems, of which Windows will
be one.

If you examine the documentation more carefully, you will see that
there is a #define that you can add to your environment (with the -D
option) to avoid all those warnings.

I have compiled a lot of ansi c programs without any problems using
the Microsoft compiler. You can have an "anti-microsoft" attitude
but the compiler is not a reason for that, in my opinion.

jacob

 

[jacob navia]

Malcolm McLean a écrit :

There's no problem compiling ANSI C programs. But I didn't buy a flashy
new dual core PC with a 2 billion dollar windowing system to run
command-line apps. I want nice graphics.

I do not understand you.

I use ANSI C to build GUI programs like an IDE, a windowed
debugger, and many other GUI programs, for instance a graphical
resource editor.

Ansi C can be used to make GUI applications without any problems.

A further advantage of C is that the API is stable and it hasn't changed
since windows 3.1 (c.a. 1991). You can still run old windows
programs in the new environment.

This is not the case with the new fads like C#.

jacob

 

[Richard Heathfield]

Malcolm McLean said:

There's no problem compiling ANSI C programs.

So what's your problem?

But I didn't buy a
flashy new dual core PC with a 2 billion dollar windowing system to
run command-line apps. I want nice graphics.

If you can't have them, either the tool is broken, or it's the wrong
tool, or you're using it wrong. Any of these is possible, and all of
them are off-topic here, but you may well get a good answer in
<

 

[Kenneth Brody]

(e-mail address removed) said:


They haven't been.

Not by C. They have been by MS, however. (At least when using .net,
AFAIK.)

Don't believe all you read.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Kenneth Brody]

jacob navia wrote:
[...]

A further advantage of C is that the API is stable and it hasn't changed
since windows 3.1 (c.a. 1991). You can still run old windows
programs in the new environment.

[...]

And I can still run my 1983 DOS programs on Vista. (I verified this
while doing some preliminary testing on Vista with the 2007 Windows
version of the program.) It seems every time a new version of
Windows comes out, the old "it won't run DOS apps" discussions
start up again.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Richard Heathfield]

Kenneth Brody said:

Not by C.
Indeed.

They have been by MS, however.

Perhaps. Nevertheless, this is of no relevance to the C language.

 

[Mark McIntyre]

And I can still run my 1983 DOS programs on Vista. (I verified this
while doing some preliminary testing on Vista with the 2007 Windows
version of the program.) It seems every time a new version of
Windows comes out, the old "it won't run DOS apps" discussions
start up again.

To be fair, DOS apps that relied on direct hardware access may
struggle. My copy of Lemmings won't run on XP, though I could just
about compel it to work on 2K provided I didn't mind rebooting the PC
afterwards....
--
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

 

[Richard Bos]

Why is fopen() and fread been deprecated?

Because M$ weren't getting enough return from their embrace-and-extend
spiel anymore.

That's just crazy.

No. It's rational. But it _is_ dishonest.

Richard