Why do you need a machine to vote? Why not just pencil in an X next to the candidate's name like they do in other countries?
Because in a land of cable TV, you need the results *NOW!*. If you have to wait a few hours for bits of paper to be counted people will have forgotten there was even an election.
Smart car safety is slightly overrated. If you're in a head-on collision with another car you'll take two or three times the hit as the other car because it weighs two or three times less.
OTOH most accidents aren't head-ons so it's not all bad news.
(And just to balance things... statistics show that SUVs are *less* safe then normal cars in non-head-on collisions because they almost always flip over)
You can't keep long-lived pointers to elements inside a vector - they might move somewhere else if the vector grows. Apart from that it works just like an array.
Not only that, but we need to write standard code that will compile in multiple platforms, so we can't use the secure form of strcpy. I personally find it unacceptable that a compiler would throw warnings recommending the use of a non-standard function, and thus I tend to hate microsoft's C support (plus they still haven't gotten around to implementing C99 support). I'm in support of such a secure copy function making it into the C standard, though.
STILL Not an excuse for using strcpy() - you can easily implement your own safe copy using the standard function then do:
No, no, GOD NO. Use vectors when you need resizing functionality. If your array will remain the same size for the lifetime of the array, then you use a goddamned array.
Why? I've looked at the assembly output for both versions and its the same. OTOH with arrays:
You have to know the size of the array and pass it around to functions. You can't use iterators or algorithms.
With vector your code is neater, safer and more flexible.
Yep, we get loads of commercial props around here. The Dash-8s hold about 40 passengers so they use them on routes where they can't fill Airbuses. I've been on quite a few of them, they fly pretty good and aren't noisy when you're inside them. Only problem is the top speed which is less than a jet.
You forgot one thing: If you cut too many corners then you might find your passengers vote for your competitor (with their wallets).
The real problem with the TSA is that even a child can see they're not actually increasing security. Mostly they're just making scanner manufacturers/shareholders rich and keeping unemployment figures down. All at taxpayer expense and passenger inconvenience.
The only way everyone is going to truly safe from terrorists on planes/trains/buses is if all passengers spend the entire ride naked and handcuffed to their seats.
Nope. One (easy) way to get explosives past the TSA is inside a body cavity.
Terrorists don't have to get past airport security. They can wheel in a huge bomb on an airport-provided trolley and blow up the queue for the scanner.
If there's no terrorist attacks in the USA it's not because of the TSA, it's because there aren't any terrorists who can be bothered to do it.
If you don't believe me I've got a magic tiger-repelling stone I'd like to sell you.
That's what all the protests in Spain (and Greece) are about: We've only got two choices and they're both completely crap. All they seem interested in is diverting taxpayer money into their own personal retirement funds.
Microsoft's Visual C++ compiler will throw a huge number of warnings for things like strcpy, telling you to use strncpy_s or something like that.
You shouldn't even be using strcpy(). std::string has been around for more than ten years now.
Similarly arrays: Don't use them, use std::vector instead. Visual C++ vector even does range checking by default so this throws an exception instead of corrupting memory:
std::vector foo(10); foo[11] = 123;// Will throw an exception in VC++...
A few basic changes in programming style can make C++ as safe as Java (but with none of the drawbacks). If you're still writing C code with your C++ compiler you're Doing It Wrong.
Still it's all to common to see people doing something like: string query = "SELECT * FROM table WHERE Id = " + id;
Thing is... this could be safe:
safe_string query = "SELECT * FROM table WHERE Id = " + id;
All you need is a "safe_string" object with suitable operator overloads and all the sanitization will be done by the compiler. It's impossible to not sanitize the input.
Problem is: It needs a proper programming language, not kiddiescript 2.6.
I forgot the obligatory link: This article is usually held up as a shining example of how to do it right, I've seen it quoted hundreds of times on programming forums.
As Mythbusters would say: "There's your problem..."
SanitizedString s = UserInput; or doSQL(SanitizedString(UserInput));
If you allow implicit constructors then this: SQLfunc(UserInput); will pass a secretly sanitized version of the string to the SQL function.
Point is: If you stick to using the provided SQL library then it's impossible to pass unsanitized strings to it, the program won't even compile. This sort of thing should really be the default by now except language designers are too busy figuring out ways to let programming noobs multiply strings by fractions.
Stop using toy languages. A strongly typed language that only accepts type "SanitizedString" as an SQL function parameter will end this problem forever.
A lot of people in London and a lot of English, don't want their city going up and up and up in height. A lot less natural light, and more people. They don't want London turning into Singapore which is the way that it would go if the developers had their way.
So the developers are willing, but not able (people won't let them). It's what I said.
Slashdot Mirror
Why do you need a machine to vote? Why not just pencil in an X next to the candidate's name like they do in other countries?
Because in a land of cable TV, you need the results *NOW!*. If you have to wait a few hours for bits of paper to be counted people will have forgotten there was even an election.
Smart car safety is slightly overrated. If you're in a head-on collision with another car you'll take two or three times the hit as the other car because it weighs two or three times less.
OTOH most accidents aren't head-ons so it's not all bad news.
(And just to balance things ... statistics show that SUVs are *less* safe then normal cars in non-head-on collisions because they almost always flip over)
The army has its own laws, civilian laws don't apply to him.
You can't keep long-lived pointers to elements inside a vector - they might move somewhere else if the vector grows. Apart from that it works just like an array.
Not only that, but we need to write standard code that will compile in multiple platforms, so we can't use the secure form of strcpy. I personally find it unacceptable that a compiler would throw warnings recommending the use of a non-standard function, and thus I tend to hate microsoft's C support (plus they still haven't gotten around to implementing C99 support). I'm in support of such a secure copy function making it into the C standard, though.
STILL Not an excuse for using strcpy() - you can easily implement your own safe copy using the standard function then do:
#define strcpy you_shouldn't_be_using_this_use_safe_strcpy_instead;
(or whatever)
No, no, GOD NO. Use vectors when you need resizing functionality. If your array will remain the same size for the lifetime of the array, then you use a goddamned array.
Why? I've looked at the assembly output for both versions and its the same. OTOH with arrays:
You have to know the size of the array and pass it around to functions.
You can't use iterators or algorithms.
With vector your code is neater, safer and more flexible.
However most files I download reach 1.5 within the hour.
Ah, you're one of those with massive upload bandwidth who keeps his ratio huge and makes it impossible for normal people to seed.
A buck per track...?
Yep, we get loads of commercial props around here. The Dash-8s hold about 40 passengers so they use them on routes where they can't fill Airbuses. I've been on quite a few of them, they fly pretty good and aren't noisy when you're inside them. Only problem is the top speed which is less than a jet.
You forgot one thing: If you cut too many corners then you might find your passengers vote for your competitor (with their wallets).
The real problem with the TSA is that even a child can see they're not actually increasing security. Mostly they're just making scanner manufacturers/shareholders rich and keeping unemployment figures down. All at taxpayer expense and passenger inconvenience.
The only way everyone is going to truly safe from terrorists on planes/trains/buses is if all passengers spend the entire ride naked and handcuffed to their seats.
Nope. One (easy) way to get explosives past the TSA is inside a body cavity.
Terrorists don't have to get past airport security. They can wheel in a huge bomb on an airport-provided trolley and blow up the queue for the scanner.
If there's no terrorist attacks in the USA it's not because of the TSA, it's because there aren't any terrorists who can be bothered to do it.
If you don't believe me I've got a magic tiger-repelling stone I'd like to sell you.
That's what all the protests in Spain (and Greece) are about: We've only got two choices and they're both completely crap. All they seem interested in is diverting taxpayer money into their own personal retirement funds.
Thing is: NOBODY voted for the TSA.
My compiler warns me about this if I forget...
Microsoft's Visual C++ compiler will throw a huge number of warnings for things like strcpy, telling you to use strncpy_s or something like that.
You shouldn't even be using strcpy(). std::string has been around for more than ten years now.
Similarly arrays: Don't use them, use std::vector instead. Visual C++ vector even does range checking by default so this throws an exception instead of corrupting memory:
std::vector foo(10); // Will throw an exception in VC++...
foo[11] = 123;
A few basic changes in programming style can make C++ as safe as Java (but with none of the drawbacks). If you're still writing C code with your C++ compiler you're Doing It Wrong.
Still it's all to common to see people doing something like: string query = "SELECT * FROM table WHERE Id = " + id;
Thing is ... this could be safe:
safe_string query = "SELECT * FROM table WHERE Id = " + id;
All you need is a "safe_string" object with suitable operator overloads and all the sanitization will be done by the compiler. It's impossible to not sanitize the input.
Problem is: It needs a proper programming language, not kiddiescript 2.6.
I forgot the obligatory link: This article is usually held up as a shining example of how to do it right, I've seen it quoted hundreds of times on programming forums.
As Mythbusters would say: "There's your problem..."
how do you generate a SanitizedString?
Via the object constructor.
SanitizedString s = UserInput; or doSQL(SanitizedString(UserInput));
If you allow implicit constructors then this: SQLfunc(UserInput); will pass a secretly sanitized version of the string to the SQL function.
Point is: If you stick to using the provided SQL library then it's impossible to pass unsanitized strings to it, the program won't even compile. This sort of thing should really be the default by now except language designers are too busy figuring out ways to let programming noobs multiply strings by fractions.
Dear Web Developers,
Stop using toy languages. A strongly typed language that only accepts type "SanitizedString" as an SQL function parameter will end this problem forever.
A lot of people in London and a lot of English, don't want their city going up and up and up in height. A lot less natural light, and more people. They don't want London turning into Singapore which is the way that it would go if the developers had their way.
So the developers are willing, but not able (people won't let them). It's what I said.
Maybe they're willing but not able....
Luckily the EU is investigating this and will impose rate caps on everybody.
Under the new scheme those same 40Gb of data will only cost as much as a Ford Mondeo.
I find their optical interconnects give a much warmer bass sound and more detailed mids.
(Actually saw a reviewer say this in a HiFi magazine...)
I thought USB 3,0 already solved that...
... laugh at the morons calling Firewire dead and obsolete. It's still alive and kicking in the pro A/V world, you idiots.
So is Betamax...