The balance might not be so easy. Exploring parallelism is a hard issue for many problems.
For instance, most of my time I'm compiling C++ code. Usually I just need to compile one file (the one I changed and want to test), and this is not a parallel process. In this scenario I'd be better off with 2 highly advanced cores.
As you mentioned the hybrid option might be the best. But remember that there are apps that cannot be "converted".
Let me point my finger and blame something too:)
The real problem with C/C++ are the standard libraries and string (char *) type! If the standard C string type and functions had length control/check, most of the buffer overflow problems would have been avoided.
Of course, there are some resource/speed costs in this solution, but the default should be having everything checked automagically. Let the few that need the extra speed spend extra time programming/using external libraries.
C++ string is quite safe in regard to buffer overflow, but many still use C libraries -- at least the C string libraries should be made unavailable by default for C++ programs. Damn, I can't even do in g++: string str("foo.bar"); ifstream file( str ); -- I have to convert str to char *!
As many pointed out, buffer overflows are not the only security problem out there.
ps.: have you ever checked the return code of a printf ?
Slashdot Mirror
The balance might not be so easy. Exploring parallelism is a hard issue for many problems. For instance, most of my time I'm compiling C++ code. Usually I just need to compile one file (the one I changed and want to test), and this is not a parallel process. In this scenario I'd be better off with 2 highly advanced cores. As you mentioned the hybrid option might be the best. But remember that there are apps that cannot be "converted".
Yes, but after reducing transistor to a single molecule we (as in humanity) will probably have a hard time keeping up to moore's law ...
ironic that, as far as I know, Akamai servers used to be mostly linux ...
Let me point my finger and blame something too :)
The real problem with C/C++ are the standard libraries and string (char *) type! If the standard C string type and functions had length control/check, most of the buffer overflow problems would have been avoided.
Of course, there are some resource/speed costs in this solution, but the default should be having everything checked automagically. Let the few that need the extra speed spend extra time programming/using external libraries.
C++ string is quite safe in regard to buffer overflow, but many still use C libraries -- at least the C string libraries should be made unavailable by default for C++ programs. Damn, I can't even do in g++: string str("foo.bar"); ifstream file( str ); -- I have to convert str to char *!
As many pointed out, buffer overflows are not the only security problem out there.
ps.: have you ever checked the return code of a printf ?
If there are no roads, I can only imagine how the people are going to the theater: hanging on vines !?