Because VC6 generates poor code for today's CPU's. Numerous issues which are generally only known to assembly language geeks or compiler writers cause the code to not work as efficiently as possible. Our rendering code under VC2005 executes on average in about 2/3 the time that it does under VC6. How much is a CPU/system upgrade going to cost you to get that kind of performance gain???;)
No, there's another way around that. Set the compiler to ignore those warnings. I don't have VS2005 available right now, but I just did it last night on a newly converted project.
There's nothing wrong with that code, although I personally would try to avoid writing like that too. But there _IS_ a thing called "scope" in C/C++ which allows it. Older M$ compilers didn't understand scope properly though, and this caused big problems. There is an option in VS2005 to enable/disable scope enforcement though (sorry - don't have VS2005 available in front of me to check out where it's located at).
Our company's main product currently has around 1.9 million lines of code. I've been running the beta compiler for months, and have found excellent performance gains over our normal builds which are created with VC6. Generally, I'm seeing execution times of around 2/3 of what they were before. This is on P4's, Athlons, and AMD-64's.
I had no trouble converting my projects from VC7 to the Beta, and I presume the VC6 to Beta would work well too. There will be a ton of warnings at first about deprecated functions like strcpy, but you can easily tell the compiler to ignore those (or use the new M$ functions if that's your style).
There are tons of new features that I haven't had a chance to use yet, but am looking forward to trying (like OpenMP).
And yes, this endorsement even comes from someone who in general is VERY anti-M$.
> A little math tells us that americans spent about 24 million man-hours.. That corresponds to about 1 million man-days, or around 2740 man-years!
> Panama Canal: 20 million man-hours (a mere 26 days of Solitaire), Apollo project: 15.5 billion man-hours (or a mere 52 years of Solitaire) Think about it!"
Yes, please think about it. The comparisons are way off.
One of the joys of the Apple ][ was the fact that you could easily build your own software OR hardware for it, and it seemed to encourage innovation. I'm amazed that a large number of people these days can't even imagine a different way to do things on their computers than the way they're accustomed to. I once heard the comment that the Japanese invented room temperature semiconductors because they hadn't been told that it was impossible:) So, being a teacher, what should change hardware & software wise to allow free thinking?
One of the joys of the Apple ][ was the fact that you could easily build your own software OR hardware for it, and it seemed to incourage innovation. I'm amazed that a large number of people these days can't even imagine a different way to do things on their computers than the way they're accustomed to. I once heard the comment that the Japanese invented room temperature semiconductors because they hadn't been told that it was impossible:) So, being a teacher, what should change hardware & software wise to allow free thinking?
I'd suggest a large room with a very large PC (relative to the penguins) being tinkered on "under the hood". Some penguins would be in the room looking at long computer printouts, other penguins would be standing next to penguins connected to the internet, some penguins would be changing ROM's. etc. Basically a large group activity showing collaboration, R&D, and overhaul.
Those strings could be decoded with a handy program called Guru2u (?). Their actual definitions were in a header anyways (alert.h?) which you'd get with your C compiler or could find in the RKM. When they were truly useful, they'd tell you which library & what the specific problem was.
LOTS of RAM? But the Amiga's OS footprints have always been very minimal and the libraries very efficient so the PC type of RAM requirements have never been an issue. I could multitask 25 programs easily in 10M, while on my PC 3 or 4 brings my 64M machine to it's knees.
Slashdot Mirror
Because VC6 generates poor code for today's CPU's. Numerous issues which are generally only known to assembly language geeks or compiler writers cause the code to not work as efficiently as possible. Our rendering code under VC2005 executes on average in about 2/3 the time that it does under VC6. How much is a CPU/system upgrade going to cost you to get that kind of performance gain??? ;)
No, there's another way around that. Set the compiler to ignore those warnings. I don't have VS2005 available right now, but I just did it last night on a newly converted project.
There's nothing wrong with that code, although I personally would try to avoid writing like that too. But there _IS_ a thing called "scope" in C/C++ which allows it. Older M$ compilers didn't understand scope properly though, and this caused big problems. There is an option in VS2005 to enable/disable scope enforcement though (sorry - don't have VS2005 available in front of me to check out where it's located at).
Our company's main product currently has around 1.9 million lines of code. I've been running the beta compiler for months, and have found excellent performance gains over our normal builds which are created with VC6. Generally, I'm seeing execution times of around 2/3 of what they were before. This is on P4's, Athlons, and AMD-64's.
I had no trouble converting my projects from VC7 to the Beta, and I presume the VC6 to Beta would work well too. There will be a ton of warnings at first about deprecated functions like strcpy, but you can easily tell the compiler to ignore those (or use the new M$ functions if that's your style).
There are tons of new features that I haven't had a chance to use yet, but am looking forward to trying (like OpenMP).
And yes, this endorsement even comes from someone who in general is VERY anti-M$.
> A little math tells us that americans spent about 24 million man-hours .. That corresponds to about 1 million man-days, or around 2740 man-years!
> Panama Canal: 20 million man-hours (a mere 26 days of Solitaire), Apollo project: 15.5 billion man-hours (or a mere 52 years of Solitaire) Think about it!"
Yes, please think about it. The comparisons are way off.
One of the joys of the Apple ][ was the fact that you could easily build your own software OR hardware for it, and it seemed to encourage innovation. I'm amazed that a large number of people these days can't even imagine a different way to do things on their computers than the way they're accustomed to. I once heard the comment that the Japanese invented room temperature semiconductors because they hadn't been told that it was impossible :) So, being a teacher, what should change hardware & software wise to allow free thinking?
One of the joys of the Apple ][ was the fact that you could easily build your own software OR hardware for it, and it seemed to incourage innovation. I'm amazed that a large number of people these days can't even imagine a different way to do things on their computers than the way they're accustomed to. I once heard the comment that the Japanese invented room temperature semiconductors because they hadn't been told that it was impossible :) So, being a teacher, what should change hardware & software wise to allow free thinking?
I'd suggest a large room with a very large PC (relative to the penguins) being tinkered on "under the hood". Some penguins would be in the room looking at long computer printouts, other penguins would be standing next to penguins connected to the internet, some penguins would be changing ROM's. etc. Basically a large group activity showing collaboration, R&D, and overhaul.
Have you tried decoding the CIA's sculpture, and have you made any further progress than the rest of the world on it?
Those strings could be decoded with a handy program called Guru2u (?). Their actual definitions were in a header anyways (alert.h?) which you'd get with your C compiler or could find in the RKM. When they were truly useful, they'd tell you which library & what the specific problem was.
LOTS of RAM? But the Amiga's OS footprints have always been very minimal and the libraries very efficient so the PC type of RAM requirements have never been an issue. I could multitask 25 programs easily in 10M, while on my PC 3 or 4 brings my 64M machine to it's knees.