Like many outside the US, I recognise the significance of these elections for the world as a whole, and I've been watching with interest.
I have a strong view on who I would prefer to be your next president, but I'll gloss over it since I don't think it's relevant to this post. What's scaring me the most is all these reports of queueing for hours to vote, not being able to vote for a valid candidate, thousands of votes being registered before the polls even opened, etc.
For reference, for a general election here in the UK (where we choose our MPs, and thus the party that will form the government) I go round the corner to a local church hall, vote by putting a cross in the correct box, and I'm home five minutes later. Even without all the dodgy voting machine antics, the very fact that you guys need to queue for hours just to cast your vote is incredible!
<Boggle/> If you used vector, why not use list as well? (I have no idea what that ustl thing is, but the standard library provides both in C++.) That way, the randomness involved in your manual memory allocation in one place will be replaced with a library that presumably uses some clever code behind both templates.
Slightly O/T, but for interest: there have been a couple of public reports recently from people who investigate CVs for potential employers here in the UK. Currently, they all put the proportion of CVs containing a seriously misleading (inflated) statement at around 1/3, and rising.
Red Hat users get their nails done and shop for purses.
Dammit, I just went to that OS quiz everyone's linking to, and it told me I'm a Red Hat user. This was the next post I saw, and I think it's confusing me with my girlfriends.
Database theory says you are wrong. The more times the same information is stored in the same or different databases the more errors there will be.*
*(Not to be confused with backups or error correcting redundancy like RAID).
The thing is, problems in practice such as the scenario I described are much more like the situations that require backups and so on. What you're describing is the scope for errors due to different parts of the database becoming out of sync, which is a fair point (except that the national ID card isn't going to replace all the other systems, at least not yet) but not the concern I'm highlighting.
My big concern here is that in the real world, mistakes happen, and the consequences of a mistaken change (or, for that matter, a malicious deliberate change) in the One True Database are far more serious than those in one minor database. If there are multiple, independent records, then the fact that the one you're complaining about is out of sync with all the other official data is good evidence that what you're saying is true, and only one thing is broken while you fix the error. If there's nothing to support your claim except a card in your hand, it's going to be much harder to fix mistakes when, inevitably, they do happen, and until you do, nothing works because it's all tied in together. At the very least, with a single source it's going to take personal visits to present the card (possibly halfway across the country) when a phone call would have done before.
Look at Hunting. They intend to use the Parliament act to force it through the Lords. Think about that for a moment. The Lords is a mechanism to prevent Parliament enacting bad law. The Parliament act is a way to overrule that check in an emergency - for example if the Lords is blocking a Finance act and so preventing the Govt doing anything. The hunting bill isn't an emergency. Regardless of it's merits either way, it's not an emergency. What it is, is politically necessary for Tony Blair to keep control of activists in his party. Not the same thing.
Sorry to continue the off-topic subthread, but I felt obliged to comment on this.
While I agree that the Parliament Act certainly should not be wielded as a blunt instrument according to the PM's will, I think this is a case that does justify it. The elected House of Commons overwhelmingly supports a ban. A ban was in the manifesto of the majority party when they were elected, and traditionally such measures are not opposed when they come up for legislation. In this case, the unelected House of Lords have repeatedly sought to block the measure, which given that many of them are in the very "elite" that hunts for sport makes their motives rather suspect.
This doesn't mean the arguments for and against hunting aren't more complicated than either side would like to admit. This doesn't mean the MPs have got it right; I'm not offering an opinion either way. But they have made a decision, and as a matter of principle, I think it is appropriate to invoke the Parliament Act in a case where there is a stand-off between the clear view of the elected house in support of a manifesto pledge and the view of the unelected and heavily biased second chamber.
[Confession: I haven't actually read that manifesto in its entirety; the above comments are based on multiple sources but all second-hand.]
Here's another point: what about the guy who just got jailed for providing information from the DVLA databases to terrorists?
Not as funny as the journalist who got a driving licence in David Blunkett's name. (For those who don't know, aside from being one of the most visible public figures in the UK, Mr Blunkett also happens to be blind.)
[Not using karma bonus as this is currently somewhat off-topic.]
What you are proposing is doing without something now, that has benefits now, just in case of some nightmare future scenario that probably won't happen, where doing without the thing wont help you much anyway.
I submitted the article. One of the reasons I feel strongly about this issue myself is that I was once left hundreds of pounds short in my pay cheque after someone in a government tax office mistyped a National Insurance number (similar to a SSN, for those who have them instead) and entered mine instead. I've mentioned this here before, but here are a few scary details in summary.
The first I knew about it was on pay day, when my pay cheque was short. No-one from either the tax office or my employer's accountant had questioned the change or asked me to confirm it.
It took three months to clear up, luckily just in time for the end of the tax year or it would have been much more complicated.
When I rang the tax office to report the problem, they would not talk to me because I couldn't confirm my current details as seen on their computer system. They had no record or my current or past employers showing, nor of my current or previous addresses, because the error had mixed up my records with someone else's. Without that information, they stonewalled me.
It was only when I mentioned the change in my tax code, which first caused the problem, that they realised what might have happened and looked deeper. It turns out that the new code I had been given is used automatically in cases where someone has two jobs, and obviously it combined with my story to trigger a mental alarm bell in the person I was talking to at the time.
The accumulated records of all the tax offices I eventually had to deal with put me living in two places on opposite sides of the country, working two full-time jobs simultaneously, one at each place. The system hadn't noticed this, and didn't even flag it for their operators to investigate.
The problem with this sort of database isn't just malicious use for things like identity theft or government interference. Good old user error is just as big a danger, and probably a lot more likely.
The kernel's use of objects is essentially to define interfaces and implement them. While there are generally provided defaults for many of the operations (so you don't have to write your own "return -ENOSYS;"), there isn't really inheritance.
OK, this is just a terminology gap then. Since terms like "object-oriented" and "v-table" were being used, I inferred the use of derived types and polymorphism via late binding of function calls. If that's not the case here -- I specifically ignored context, because I'm not a Linux kernel hacker -- then my argument isn't intended for this discussion.:-)
It just makes so much more sense to take care of errors immediately when you have a large project and the guy above you liek ly has no knowledge of your code.
Fair enough; I guess it depends on how well-structured the project is.
In my case, that first project I mentioned was very well designed, with clear levels of abstraction built on top of each other and good use of both functional decomposition and OO through those levels. If a hardware error was reported at the lowest levels, the action you wanted was frequently to abort the current operation, possibly with a quick tidy-up at low level to stop some hardware moving say, and then throw an error back up through the intermediate levels to the code handling the UI requests. If the hardware operation completed but the next level up decided the data was bad, it too would abort, and could do so using the same mechanism. This tends to happen quite naturally in code that has a clean, layered design. (Of course, not all large projects do, and maybe in other cases exceptions aren't as useful.)
And by the same token- an error code value corresponds to type of an exception. If you want multiple erros handled the same way, use the same block for multiple error codes.
If C++ had support for proper disjunctive types and pattern matching, I'd buy that. Since it doesn't, I just don't see how you can get the same degree of flexibility from a single return value of a fixed type.
As for boilerplate code- not really. YOu use throw() instead of return and catch instead of a conditional. Same amount of code.
If you're only throwing up one level, sure. One of my main points throughout this discussion has been that this isn't really a very good use of exceptions. Where they save is when you're throwing to five functions up the stack, and you don't have a constant stream of this sort of rubbish in every single function on the way:
SuccessCode result = DoSomething(); if (result == FAILURE) { return FAILURE; } else if (result == OTHER_FAILURE) { return OTHER_FAILURE; } else { DoSomethingElse(); }
IME, maintaining that sort of code in a large project is a recipe for disaster, but as always YMMV.
Because its so much better to have a random error pop up 3 levels above the thing that cause it with an error identifier mapping to an API the handler didn't even know existed. Thats sooooo much cleaner
The problem is exactly analogous to failing to forward a return code in a non-exception-based system, except that there's only one opportunity to forget with exceptions, it will usually be immediately obvious in testing if you do, and most decent debuggers can break immediately on an unhandled exception.
Say we have a linked list template. The code for just an int may take 12K (number pulled out of my ass). If you need to support a 64 bit int as well, it may now take 20K (some is reusbale). Adding in 16 bit is up to 28K. Using a void* for it all would stick with just the original 12K. On an embedded or OS, 8K is fucking huge.
OK, firstly you picked a bad example; it's routine in template code to use a void* based trick to avoid the overhead in that case. This is in chapter 1 of the newbie guide.
Secondly, I call bullshit on your claim that 8K is "fucking huge" in embedded developments. I've worked in mobile telecomms, instrument control for engineering hardware, and God knows how many other embedded/firmware-related projects in my time. Not much this side of 1990 cares about that sort of memory limit. I'm sure there are a few cases around where it really still matters, but it certainly isn't the norm today, and where it is, you certainly aren't using a compiler that can take 8K to hold the code for a trivial linked list anyway.
Take this for example:
class X{...}
func blah(X x){ X retval... return retval }
How many times is X's constructor called? Hint: it isn't 2. On some compilers its 3, on one I got 4. If that constructor calls malloc....
Leaving aside the fact that what you wrote doesn't make sense in any language I know, which constructor are you talking about? You potentially have a copy constructor call on the entry to the function (pass-by-value), a default constructor call on the first line (automatic variable) assuming you didn't pass it any parameters, and then a copy constructor on function exit (return-by-value). If you've got four, there's something you're not showing us or your compiler is broken.
It is perfectly acceptable to elide some of these where the effect of doing so is invisible, and indeed it is common practice to do so for efficiency reasons; look up the "named return value optimisation", for example. However, that won't matter unless either your class's semantics are blatantly broken: not matching any new in a constructor with a corresponding delete in the destructor, copy assignment that doesn't use copy-and-swap or some similarly safe idiom, etc. (Actually, it probably won't happen at all if there are memory management things in your constructor/destructor, unless your optimiser is very smart at working out that their effects will be invisible if the call is elided, which I don't think any today are.) The only other issue is performance if new is relatively slow, in which case you shouldn't be complaining that any decent compiler will optimise away some of these calls and their attendant memory management overhead.
Its the fact that its requesting memory at all. If the OS would need to walk the free page list to satisfy the request (or worse- page memory), thats a huge performance hit.
So write your new operator for the relevant class to use a memory pool you manage yourself like a grown up, and don't trouble the poor, under-powered operating system if it isn't fast enough. This is in chapter 2 of the newbie guide.
In theory its useful. In practice its annoying and more difficult to maintain.
That's what I used to think a long time ago. My mind started to change when I worked on my first million+ line project.
Exceptions are error codes passed as objects and with a wierd method of beign passed. They carry no less information than error codes.
I'm sorry, but that's staggeringly short-sighted. To give some obvious things you've ignored:
Exceptions are typed and multiple types can be thrown from the same block in different circumstances.
Exceptions can be constructed in a hierarchy, and derived exception types can be caught by base type.
These introduce far more precision and flexibility into the process than a simple return code can, even without the distributed nature and potentially enormous amounts of boilerplate code they do away with.
But what are the benefits? many parts of the kernel are already object-oriented, in the form of manually written vtable structs and object structs that have pointers to those vtables. I just don't see a reason for C++ in the kernel.
Looking at that statement in isolation and ignoring the kernel specifics for a moment, if you're doing something complicated by hand in one language, and you have available a similar language that can do the same thing as a language feature, using the latter will typically make your code simpler, less error-prone, and potentially more efficient, since the language feature provides more information for an optimiser to improve the output code.
The first argument is easy- exceptions are a Bad Idea. Error codes are much cleaner and more logical.
<sarcasm> Of course, because cluttering four layers of code between detecting the error and reacting to it with maintenance hazards like forwarded return codes is a much cleaner approach than the two lines required to throw and catch an exception. </sarcasm>
Even the few embedded projects I know that use C++ outlaw the use of exceptions in their code (generally templates as well, for emmory reasons).
You do know that the templates hogging memory thing is mostly a myth, right? This sort of talk is put around by critics either who have no idea what they're talking about or who haven't thought through the way they are used in practice. Clearly and objectively, there is no merit to the argument, and I don't care how many people you cite who've worked on embedded projects (or for that matter popular free OS kernels) and say differently.
C++ has hidden allocations all over. In C, its easy to find memory allocations. Grep for malloc (or kmalloc in the kernel).
Except that you forgot automatic variables and information on the stack due to function call/return overheads, for a start. If you don't think they matter, try working on a project with really large data sets and recursive algorithms (or rather, their iterative equivalents, since the simple act of making a function call can become a liability in such an environment).
In C++, you have temporary objects being instantiated all over the place, automatic constructors/destructors being called, etc.
Sure, and anyone competent to write a kernel in the first place is going to learn the rules for how that happens in no time. There's no magic. It's not done behind your back. The rules are clear. The allocations may not be explicit, but in most cases that's just one less thing for the programmer to worry about. (On the other hand, maybe garbage collection doesn't prevent bugs in the real world, high level languages should all do away with their logical models and provide hacky low-level interfaces instead, and manual memory management is really the key to bug free code after all.)
While this may be tolerated (although confusing) for an application, for a kernel its murder. Memory is tight, and mallocing will kill you performance wise if you need to grab a new free page.
Fortunately for us, none of the implicit allocations you dislike so much normally uses malloc, and they're typically very efficient. And of course, in C++ you can replace things like the new operator for specific types if, when you write those types, you can identify a superior memory model, all without troubling the allocating code.
There's generally a 5-10% performance hit just from having code that might possibly throw an exception, depending on your compiler's implementation.
FWIW, I believe modern compilers now approach the zero-overhead ideal for exceptions when they aren't thrown, and have done for a little time now. Several people directly involved have posted to this effect on the major C++ newsgroups in the past.
Sorry, but I think you're missing the point of exceptions. They are supposed to decouple generating the error from reacting to it, because in practice that's often useful.
Exceptions are a systematic way to return control multiple layers up the code, without cluttering the code in between passing information it doesn't need to know or care about. They are best used where the code that directly causes the error can't handle it because it doesn't know how, and the code that handles it doesn't care where it came from, because the code that was trying to run aborted anyway.
You could write at least a good length article on what exceptions are and aren't good for, but in short, if you ever throw exceptions exclusively at one level and catch them exclusively at the next level up, there's a good chance you're using the wrong tool for the wrong job.
For society to work, with freedom must come responsibility. As long as you can effectively send anonymous information via the Internet, there is no way to hold someone responsible for this sort of action. Even if the laws are there, without any effective way to enforce them, what does it matter?
<Comical Ali> I now inform you that there are no civil liberties issues here and your civil rights are completely unaffected by our legislation. </Comical Ali>
The sad thing is, when we heard this sort of spin during the Iraq invasion, you couldn't help but be amused, in a disturbed kind of way. When we hear it from a western world leader, far too many people just don't think about it and lap it up. Some of the mods of, and other replies to, your post are scary.
If you have 90+% of the market share, you define the industry standard. It may be de facto, but it's still far more important than anything on paper from someone else. When was the last time you saw a manager tell a web dev team to ignore IE compatibility because it didn't matter as long as they wrote standard HTML + CSS?
then you are locked in to Microsoft's product line. That means you have to pay the Upgrade Fee,
Fortunately, the upgrade cost of IE isn't a whole lot, and never has been.
and if you want to interoperate with another piece of software, you are forced to select Microsoft's offering, because it is the only one that is compatible.
Of course, because common plug-ins like Flash or PDF reading aren't available for the major alternative browsers due to Microsoft's monopoly, right?
Really, I use Firefox and I'm no great Microsoft fan, but the sort of out-of-context, evangelistic arguments that you're writing don't help with trying to shift the web world away from its current Microsoft-centric state.
I don't know what all the fuss is about. If you're talking about any PC kit, not necessarily new or state of the art, then loads of places sell very low-priced kit these days.
One of my colleagues just bought a pretty good Dell desktop including the monitor etc. for only 160 UKP, through an official Dell channel. He saved around 75% of list price because it was refurbished, but it was in full working order, and with guarantees etc. anyway. The spec was of a typical PC maybe 6 months - 1 year old. That easily matches the sort of systems most people are putting together here in price/performance, and it's off the shelf.
Enough already. If "I think any use of unordered lists in combination with floats currently leads to the bullet points off the left margin problem" isn't clear enough for you to try it out, you guys really aren't informed enough to be in this conversation. Still, just for you, here's a trivial example that obviously breaks in Firefox up to at least 0.9.2. Just add clutter to turn it into the standardised HTML version of your choice...
Slashdot Mirror
Like many outside the US, I recognise the significance of these elections for the world as a whole, and I've been watching with interest.
I have a strong view on who I would prefer to be your next president, but I'll gloss over it since I don't think it's relevant to this post. What's scaring me the most is all these reports of queueing for hours to vote, not being able to vote for a valid candidate, thousands of votes being registered before the polls even opened, etc.
For reference, for a general election here in the UK (where we choose our MPs, and thus the party that will form the government) I go round the corner to a local church hall, vote by putting a cross in the correct box, and I'm home five minutes later. Even without all the dodgy voting machine antics, the very fact that you guys need to queue for hours just to cast your vote is incredible!
<Boggle/> If you used vector, why not use list as well? (I have no idea what that ustl thing is, but the standard library provides both in C++.) That way, the randomness involved in your manual memory allocation in one place will be replaced with a library that presumably uses some clever code behind both templates.
8) I don't need a real girlfriend.
Nice boast. ;-)
Slightly O/T, but for interest: there have been a couple of public reports recently from people who investigate CVs for potential employers here in the UK. Currently, they all put the proportion of CVs containing a seriously misleading (inflated) statement at around 1/3, and rising.
Dammit, I just went to that OS quiz everyone's linking to, and it told me I'm a Red Hat user. This was the next post I saw, and I think it's confusing me with my girlfriends.
The thing is, problems in practice such as the scenario I described are much more like the situations that require backups and so on. What you're describing is the scope for errors due to different parts of the database becoming out of sync, which is a fair point (except that the national ID card isn't going to replace all the other systems, at least not yet) but not the concern I'm highlighting.
My big concern here is that in the real world, mistakes happen, and the consequences of a mistaken change (or, for that matter, a malicious deliberate change) in the One True Database are far more serious than those in one minor database. If there are multiple, independent records, then the fact that the one you're complaining about is out of sync with all the other official data is good evidence that what you're saying is true, and only one thing is broken while you fix the error. If there's nothing to support your claim except a card in your hand, it's going to be much harder to fix mistakes when, inevitably, they do happen, and until you do, nothing works because it's all tied in together. At the very least, with a single source it's going to take personal visits to present the card (possibly halfway across the country) when a phone call would have done before.
Sorry to continue the off-topic subthread, but I felt obliged to comment on this.
While I agree that the Parliament Act certainly should not be wielded as a blunt instrument according to the PM's will, I think this is a case that does justify it. The elected House of Commons overwhelmingly supports a ban. A ban was in the manifesto of the majority party when they were elected, and traditionally such measures are not opposed when they come up for legislation. In this case, the unelected House of Lords have repeatedly sought to block the measure, which given that many of them are in the very "elite" that hunts for sport makes their motives rather suspect.
This doesn't mean the arguments for and against hunting aren't more complicated than either side would like to admit. This doesn't mean the MPs have got it right; I'm not offering an opinion either way. But they have made a decision, and as a matter of principle, I think it is appropriate to invoke the Parliament Act in a case where there is a stand-off between the clear view of the elected house in support of a manifesto pledge and the view of the unelected and heavily biased second chamber.
[Confession: I haven't actually read that manifesto in its entirety; the above comments are based on multiple sources but all second-hand.]
Not as funny as the journalist who got a driving licence in David Blunkett's name. (For those who don't know, aside from being one of the most visible public figures in the UK, Mr Blunkett also happens to be blind.)
[Not using karma bonus as this is currently somewhat off-topic.]
I submitted the article. One of the reasons I feel strongly about this issue myself is that I was once left hundreds of pounds short in my pay cheque after someone in a government tax office mistyped a National Insurance number (similar to a SSN, for those who have them instead) and entered mine instead. I've mentioned this here before, but here are a few scary details in summary.
The problem with this sort of database isn't just malicious use for things like identity theft or government interference. Good old user error is just as big a danger, and probably a lot more likely.
OK, this is just a terminology gap then. Since terms like "object-oriented" and "v-table" were being used, I inferred the use of derived types and polymorphism via late binding of function calls. If that's not the case here -- I specifically ignored context, because I'm not a Linux kernel hacker -- then my argument isn't intended for this discussion. :-)
Fair enough; I guess it depends on how well-structured the project is.
In my case, that first project I mentioned was very well designed, with clear levels of abstraction built on top of each other and good use of both functional decomposition and OO through those levels. If a hardware error was reported at the lowest levels, the action you wanted was frequently to abort the current operation, possibly with a quick tidy-up at low level to stop some hardware moving say, and then throw an error back up through the intermediate levels to the code handling the UI requests. If the hardware operation completed but the next level up decided the data was bad, it too would abort, and could do so using the same mechanism. This tends to happen quite naturally in code that has a clean, layered design. (Of course, not all large projects do, and maybe in other cases exceptions aren't as useful.)
If C++ had support for proper disjunctive types and pattern matching, I'd buy that. Since it doesn't, I just don't see how you can get the same degree of flexibility from a single return value of a fixed type.
If you're only throwing up one level, sure. One of my main points throughout this discussion has been that this isn't really a very good use of exceptions. Where they save is when you're throwing to five functions up the stack, and you don't have a constant stream of this sort of rubbish in every single function on the way:
IME, maintaining that sort of code in a large project is a recipe for disaster, but as always YMMV.
The problem is exactly analogous to failing to forward a return code in a non-exception-based system, except that there's only one opportunity to forget with exceptions, it will usually be immediately obvious in testing if you do, and most decent debuggers can break immediately on an unhandled exception.
OK, firstly you picked a bad example; it's routine in template code to use a void* based trick to avoid the overhead in that case. This is in chapter 1 of the newbie guide.
Secondly, I call bullshit on your claim that 8K is "fucking huge" in embedded developments. I've worked in mobile telecomms, instrument control for engineering hardware, and God knows how many other embedded/firmware-related projects in my time. Not much this side of 1990 cares about that sort of memory limit. I'm sure there are a few cases around where it really still matters, but it certainly isn't the norm today, and where it is, you certainly aren't using a compiler that can take 8K to hold the code for a trivial linked list anyway.
Leaving aside the fact that what you wrote doesn't make sense in any language I know, which constructor are you talking about? You potentially have a copy constructor call on the entry to the function (pass-by-value), a default constructor call on the first line (automatic variable) assuming you didn't pass it any parameters, and then a copy constructor on function exit (return-by-value). If you've got four, there's something you're not showing us or your compiler is broken.
It is perfectly acceptable to elide some of these where the effect of doing so is invisible, and indeed it is common practice to do so for efficiency reasons; look up the "named return value optimisation", for example. However, that won't matter unless either your class's semantics are blatantly broken: not matching any new in a constructor with a corresponding delete in the destructor, copy assignment that doesn't use copy-and-swap or some similarly safe idiom, etc. (Actually, it probably won't happen at all if there are memory management things in your constructor/destructor, unless your optimiser is very smart at working out that their effects will be invisible if the call is elided, which I don't think any today are.) The only other issue is performance if new is relatively slow, in which case you shouldn't be complaining that any decent compiler will optimise away some of these calls and their attendant memory management overhead.
So write your new operator for the relevant class to use a memory pool you manage yourself like a grown up, and don't trouble the poor, under-powered operating system if it isn't fast enough. This is in chapter 2 of the newbie guide.
That's what I used to think a long time ago. My mind started to change when I worked on my first million+ line project.
I'm sorry, but that's staggeringly short-sighted. To give some obvious things you've ignored:
These introduce far more precision and flexibility into the process than a simple return code can, even without the distributed nature and potentially enormous amounts of boilerplate code they do away with.
Looking at that statement in isolation and ignoring the kernel specifics for a moment, if you're doing something complicated by hand in one language, and you have available a similar language that can do the same thing as a language feature, using the latter will typically make your code simpler, less error-prone, and potentially more efficient, since the language feature provides more information for an optimiser to improve the output code.
<sarcasm> Of course, because cluttering four layers of code between detecting the error and reacting to it with maintenance hazards like forwarded return codes is a much cleaner approach than the two lines required to throw and catch an exception. </sarcasm>
You do know that the templates hogging memory thing is mostly a myth, right? This sort of talk is put around by critics either who have no idea what they're talking about or who haven't thought through the way they are used in practice. Clearly and objectively, there is no merit to the argument, and I don't care how many people you cite who've worked on embedded projects (or for that matter popular free OS kernels) and say differently.
Except that you forgot automatic variables and information on the stack due to function call/return overheads, for a start. If you don't think they matter, try working on a project with really large data sets and recursive algorithms (or rather, their iterative equivalents, since the simple act of making a function call can become a liability in such an environment).
Sure, and anyone competent to write a kernel in the first place is going to learn the rules for how that happens in no time. There's no magic. It's not done behind your back. The rules are clear. The allocations may not be explicit, but in most cases that's just one less thing for the programmer to worry about. (On the other hand, maybe garbage collection doesn't prevent bugs in the real world, high level languages should all do away with their logical models and provide hacky low-level interfaces instead, and manual memory management is really the key to bug free code after all.)
Fortunately for us, none of the implicit allocations you dislike so much normally uses malloc, and they're typically very efficient. And of course, in C++ you can replace things like the new operator for specific types if, when you write those types, you can identify a superior memory model, all without troubling the allocating code.
FWIW, I believe modern compilers now approach the zero-overhead ideal for exceptions when they aren't thrown, and have done for a little time now. Several people directly involved have posted to this effect on the major C++ newsgroups in the past.
Sorry, but I think you're missing the point of exceptions. They are supposed to decouple generating the error from reacting to it, because in practice that's often useful.
Exceptions are a systematic way to return control multiple layers up the code, without cluttering the code in between passing information it doesn't need to know or care about. They are best used where the code that directly causes the error can't handle it because it doesn't know how, and the code that handles it doesn't care where it came from, because the code that was trying to run aborted anyway.
You could write at least a good length article on what exceptions are and aren't good for, but in short, if you ever throw exceptions exclusively at one level and catch them exclusively at the next level up, there's a good chance you're using the wrong tool for the wrong job.
For society to work, with freedom must come responsibility. As long as you can effectively send anonymous information via the Internet, there is no way to hold someone responsible for this sort of action. Even if the laws are there, without any effective way to enforce them, what does it matter?
The excuse not to bother RingTFA we've all been waiting for. Sorry, US friends, your days of getting f1rst p0st are over!
<Comical Ali> I now inform you that there are no civil liberties issues here and your civil rights are completely unaffected by our legislation. </Comical Ali>
The sad thing is, when we heard this sort of spin during the Iraq invasion, you couldn't help but be amused, in a disturbed kind of way. When we hear it from a western world leader, far too many people just don't think about it and lap it up. Some of the mods of, and other replies to, your post are scary.
If you have 90+% of the market share, you define the industry standard. It may be de facto, but it's still far more important than anything on paper from someone else. When was the last time you saw a manager tell a web dev team to ignore IE compatibility because it didn't matter as long as they wrote standard HTML + CSS?
Fortunately, the upgrade cost of IE isn't a whole lot, and never has been.
Of course, because common plug-ins like Flash or PDF reading aren't available for the major alternative browsers due to Microsoft's monopoly, right?
Really, I use Firefox and I'm no great Microsoft fan, but the sort of out-of-context, evangelistic arguments that you're writing don't help with trying to shift the web world away from its current Microsoft-centric state.
I don't know what all the fuss is about. If you're talking about any PC kit, not necessarily new or state of the art, then loads of places sell very low-priced kit these days.
One of my colleagues just bought a pretty good Dell desktop including the monitor etc. for only 160 UKP, through an official Dell channel. He saved around 75% of list price because it was refurbished, but it was in full working order, and with guarantees etc. anyway. The spec was of a typical PC maybe 6 months - 1 year old. That easily matches the sort of systems most people are putting together here in price/performance, and it's off the shelf.
As opposed to memorizing them without using your mind, presumably?
I give up. Here you go.
Enough already. If "I think any use of unordered lists in combination with floats currently leads to the bullet points off the left margin problem" isn't clear enough for you to try it out, you guys really aren't informed enough to be in this conversation. Still, just for you, here's a trivial example that obviously breaks in Firefox up to at least 0.9.2. Just add clutter to turn it into the standardised HTML version of your choice...
Rather embarrassingly, it also breaks Slashdot's <ECODE> tag. :-)