The baseline for Windows XP was around 'zero' (remember all popup those message windows anybody in the entire world could make appear on your original Windows XP machine?). It's not hard to improve from there.
The biggest problem will always be between the keyboard and the chair but I don't think there's less 'critical' patches lately than at any other point in Windows history ('critical' exploits are those that can propagate to other machines without any user intervention).
Any sudden increase in housing prices is a bubble, guaranteed - average people only have so much money to spend on rent/mortgage. They can't possibly pay more than ($wages - ($food+$bills)) per month.
Won't work. Pretty much anybody with any brains knew the housing thing was a bubble but nobody wants to pull out of a bubble before it peaks. Imagine if you pull out and have to sit and watch everybody else make money if the bubble lasts another year.
Bubbles last as long as no big players get too nervous and I'd like to know how software can predict that effect.
Something which could earn money not being exploited? Hah!
PS: Yeah, the Efficient Market Hypothesis rules. No system can ever beat the stock market even if we ignore the random events which can totally destroy any system (eg. wars, accidents, BP oil spills, etc.)
The SSD is a cache, caches don't do "sequential read"
e.g. Let's read the whole of RAM sequentially see how well your CPU cache performs. Oh, noes! We found a "performance problem"!!!
If all you do switch on, read email, switch off, you'll see a massive boost the next time you do it. Still, better not risk having that because there's an article somewhere on the Internet!
Is all I can say to that. I was programming z80s and 6502s in hexadecimal before all you whippersnappers were born.
When I started writing C++ I was as suspicious as anybody but after a few months of looking at disassembly of the code produced from STL functions I managed to get over it.
Clue: The people who make C++ compilers aren't stupid. They actually look at, and care about, the code produced by their compiler.
| "object-oriented programming is a paradigm, not a language feature"
True enough, but language features can make it MUCH easier to use.
| "You can even do OOP in assembler "
True again, but if I decide to make a function virtual in C++ I just type "virtual" and let the compiler figure it out. In assembler I have to go through and find all the references the the function and change them to do double-indirection. The assembler isn't going to help me by printing any warnings about the ones I missed, and they're going to bomb.
In all the years this has been debated (at least 15), I've yet to see a concrete example where C is faster than C++.
Not one.
If C++ was really slower or more bloated you'd think it would be easy to demonstrate, but nooooo. All you ever find is that the person on the other end doesn't know C++.
I thought compilers would chop the incoming text up into lots of little strings and put them in an array of tokens, to me that says std::string and dynamically growing containers - much more robust than malloc and strcpy.
The expression evaluator will need a stack along with typed data items (int, float, double, etc). C++ can make that sort of thing much neater.
If you dig into it, I'm sure there's many places where C++ would remove a lot of lines of code from a compiler.
Especially when they start sending the 200Mb attachments...
You can't go downwind faster then the wind but you can certainly go crosswind much faster. Sailing boats have been doing it for hundreds of years.
Yep, 2k is hardly a "minor purchase". How many taxpayers do you suppose it takes to pay for that (plus your wages)?
Presumably that purchase order goes into some sort of computer system even now, the amount spent and a code for type of purchase.
Once it's in there the rest can be automated, no need for a 'layer of junior civil servants' to re-type the data.
If I was paranoid I might suspect there will be another layer of people censoring it and fiddling with it to look good, but that's another story...
they don't really compete in the over $250 desktop arena.
Maybe they don't really want to.
Under $250 is by far the biggest market. Competing with the high end Intel chips would probably lose money.
AMD designed/implemented the 64bit instruction that will be running our desktop PCs for decades to come.
Intel was the one scrambling to catch up on that.
Um, yeah, it was designed that way. The padded cushions aren't an accident....
The baseline for Windows XP was around 'zero' (remember all popup those message windows anybody in the entire world could make appear on your original Windows XP machine?). It's not hard to improve from there.
The biggest problem will always be between the keyboard and the chair but I don't think there's less 'critical' patches lately than at any other point in Windows history ('critical' exploits are those that can propagate to other machines without any user intervention).
Any sudden increase in housing prices is a bubble, guaranteed - average people only have so much money to spend on rent/mortgage. They can't possibly pay more than ($wages - ($food+$bills)) per month.
Won't work. Pretty much anybody with any brains knew the housing thing was a bubble but nobody wants to pull out of a bubble before it peaks. Imagine if you pull out and have to sit and watch everybody else make money if the bubble lasts another year.
Bubbles last as long as no big players get too nervous and I'd like to know how software can predict that effect.
Something which could earn money not being exploited? Hah!
PS: Yeah, the Efficient Market Hypothesis rules. No system can ever beat the stock market even if we ignore the random events which can totally destroy any system (eg. wars, accidents, BP oil spills, etc.)
Really??
The cache only served up each piece of data once! After that it was discarded...what a terrible waste!
It's distilled ... you can make it as strong as you like, no magic needed.
Ummmm .... in the second sentence of the summary it says 'freeze distilled'. It's not like you actually had to go and read an article or anything.
The SSD is a cache, caches don't do "sequential read"
e.g. Let's read the whole of RAM sequentially see how well your CPU cache performs. Oh, noes! We found a "performance problem"!!!
If all you do switch on, read email, switch off, you'll see a massive boost the next time you do it. Still, better not risk having that because there's an article somewhere on the Internet!
LOL!
Is all I can say to that. I was programming z80s and 6502s in hexadecimal before all you whippersnappers were born.
When I started writing C++ I was as suspicious as anybody but after a few months of looking at disassembly of the code produced from STL functions I managed to get over it.
Clue: The people who make C++ compilers aren't stupid. They actually look at, and care about, the code produced by their compiler.
OK, we'll get off your lawn and leave you to it...
C++ allows you to work at a MUCH higher level of abstraction than C.
Sure, it doesn't force you, but if that's your only argument then you're missing the point.
| "object-oriented programming is a paradigm, not a language feature"
True enough, but language features can make it MUCH easier to use.
| "You can even do OOP in assembler "
True again, but if I decide to make a function virtual in C++ I just type "virtual" and let the compiler figure it out. In assembler I have to go through and find all the references the the function and change them to do double-indirection. The assembler isn't going to help me by printing any warnings about the ones I missed, and they're going to bomb.
| "performance can be 4x SLOWER with the stl than by using c99"
I'd like to see you back that claim up with real code...
This assuming there'll actually be a performance problem.
In my experience the "C++ is slower then C" crowd can never manage to put their money where their mouth is.
All those constructs were added to C++ for a reason.
C programmers usually end up reinventing them, badly.
In all the years this has been debated (at least 15), I've yet to see a concrete example where C is faster than C++.
Not one.
If C++ was really slower or more bloated you'd think it would be easy to demonstrate, but nooooo. All you ever find is that the person on the other end doesn't know C++.
I thought compilers would chop the incoming text up into lots of little strings and put them in an array of tokens, to me that says std::string and dynamically growing containers - much more robust than malloc and strcpy.
The expression evaluator will need a stack along with typed data items (int, float, double, etc). C++ can make that sort of thing much neater.
If you dig into it, I'm sure there's many places where C++ would remove a lot of lines of code from a compiler.