To view parent comment, click here.
To read all comments associated with this story, please click here.
The mentality of C++ is you only use what you are willing to pay for, you only pay for what you use. There is an associated cost (processing time) with the features your talking about. They are "hacks" because not everyone wants the same features so why should everyone pay for them.
You don't pay for the features you don't use, so there's no harm in implementing the features the right way for those who wish to use them.
For example, D provides a boat-load of features, but if you want to write straight C, you can. You don't have to pay the price of garbage collection, bounds checking, and so forth if you don't want to.
The C++ mentality means that there's a much greater penalty for using advanced features. Not only a penalty in performance, but also usability and maintainability. No wonder developers are scared to use it as anything beyond C with Classes.
As already said, blame the programmer, not the tool.
o.Lock();
// stuff
o.unLock();
The fact that you need to invoke the unLock() method explicitely, which is prone to error and is the reason for using the macro in the first place.
Why not?
Placing the closing bracket of your for loop is prone to error, and if you leave it out completely, I imagine the resulting compiler error being non-trivial to track down. Coverity is useful for verifying arbitrary locking conventions.
Why make the bounds-checked array the default array? Because you very rarely want to reference outside the bounds of an array, and you very rarely care enough about the minimal overhead to warrant the risk of bugs and vulnerabilities. For those times where you want to linearly traverse a 2D array or where you need to squeeze everything out of that inner loop, you can opt for the simple array.







Member since:
2005-07-08
Well, I admit, you can't decapitate a for loop with an inline function. But you also can't do this:
#define BAD_MACRO(x) if(x) cout << "Are macros bad?" << endl;
if(true) BAD_MACRO(might_be_zero);
else cout << "Macros are bad!" << endl;
Macros can change the way we think about truth.
Use inline functions in place of macros. If you need to inline something that isn't a function, you're doing something wrong. What's so bad about this?:
o.Lock();
// stuff
o.unLock();
That's the way C++ works, plus you avoid the unnecessary isLocked() call. Should C++ have multithreading primitives? Probably, but that's another issue.
Yes, I know you can extend C++ in all sorts of ways. But a lot of these hacks are workarounds for missing language features. You shouldn't need a special class to have a bounds-checked array. This should be an opt-out feature.
Edited 2007-08-13 22:08