If you think every caller should have logic which reacts to errors, why do you need automatic stack unwinding? Just use error codes.
Not being thorough is bad always engineering.
But catching exceptions—only to re-throw them—is not "being thorough". It is boilerplate. If the caller is not exception-safe then you should consider a more transactional paradigm, so that you don't need to catch and re-throw. If you want to force callers to handle errors immediately, then stop using exceptions and start using "checked error codes" (i.e. lightweight objects which represent error codes and verify that the caller has acknowledged the error state).
Any external resource (not inside the application like an object), can throw an exception/error while closing it.
You are expected to enforce a no-throw destructor regardless of the work that happens within it. Yes, you are expected to suppress errors if it is possible for resource-closing to throw. It sounds weird I know, but it works just fine. If the API users care about failure, they will call close() first.
First, you can throw anything. String, int, object, etc. That means that you can't use a catch-all and do anything useful.
Yeah, it's a bit silly at first, but it's not a surprise when you consider that std::exception is not a language construct, and is instead a Very Important language idiom. If a peer developer programs "outside of the box" in this regard, they are deserving of a hefty smack.
Second, you are losing the stack trace, which means debugging is pain.
I have to agree with you on this one. I wish __cxa_throw would snapshot the backtrace by default. Since that is horribly implementation-specific, it would be sufficient if a standard API was created which intercepted exception throwing, so I could call backtrace on my own.
Third, you can't throw an exception in the dtor, which means you can't use RAII. What if an exception is occurring while you close a resource? For example, disk is full; the socket is gone; memory full; disk is broken; the user removed the USB stick, etc.
This is absurd. If you want to provide visibility to errors when closing a resource, provide a close() member or similar which can throw. Destructors exist to release resources while unwinding the stack. Since you don't know the state of the program (other than "this lexical scope is going away"), there's no reason to report errors. Again, enforcing no-throw destructors is a Very Important language idiom. Do not break it.
1. you have to be careful not to throw across COM calls, Windows message handlers, thread handlers, etc. otherwise you are going to get hard to diagnose crashes;
On the Linux side, there are also restrictions for throwing/catching across shared object (library or program) boundaries. AFAIK both shared objects must reference the same RTTI "database", which means for GCC users that both must be dynamically linked with libgcc_s. This rules out purely-static executables. While most developers don't care about this limitation, there is a very small set of developers for whom this makes a significant difference.
The standard case is trying to open a file that doesn't exist. This isn't an "exception", or even really an error. Many times, it's a test to see if the file exists to allow an overwrite warning.
Truly exceptional things are like running of disk space, having the disk removed/fail/whatever. In other words, if the problem has to be solved outside the program that is catching the exception, then that is a good use of an exception.
Well now you end up with a file API which returns error enumerations in one situation (open or fopen) and throws exceptions in another situation (read,write or fflush,fclose). That will definitely throw developers for a loop. I'd rather have the API pick one or the other and stick with it. I'm actually rather fond of POSIX C's approach to this (int fd and FILE * with thread-local errno) because it provides minimal-overhead building blocks for application-specific file abstractions. It requires an encapsulation layer for C++ applications, but it means I can cater the encapsulation layer's behavior to my exact needs. Configuration files, cache files, log files, temporary work files, saved-state files all have very different needs and should respond to faulty scenarios differently.
but by the time the character is level 20? We'll have to ensure that he has accrued the correct number of effects from the CTE effects table....
Can't you repair that sort of damage with a 4th-level clerical spell? Your meat-shield should be fine unless you're playing in a gritty, low-magic setting.
But if someone sets up BT on 80, how do you verify the protocol without looking at the payload? Even then, there are "tricks" where P2P protocols can use HTTP GET and PUT in the payload to be able to manipulate inspection.
Ugh. I had to do some research on SOAP as a part of an internship at an "Enterprisey" software shop. Many SOAP software stacks advertised themselves as firewall-friendly because they would "punch through the firewall on port 80". That is, the SOAP service was encapsulated in HTTP, with the implication that this was superior to getting permission from your network admins. Of course, these same service providers also provided "SOAP firewalls" so they could profit off of your company's internal dysfunction. What a pile of garbage, all of it.
Anyhow, I can see why BT would want to encapsulate itself in HTTP, but it stinks of an arms race.
... the fix is to use an active queue management algorithm like CoDel to control that excessive delay caused by the routers and switches.
I just read the Wikipedia page, and I am familiar with bufferbloat. Since you're advocating the implementation of CoDel as a mechanism for QoS, maybe you can answer these questions:
CoDel is cited as "parameterless", but I see right away that there is a parameter of 5ms for the desired latency. Isn't "5ms" a parameter to the algorithm? It seems that a QoS algorithm which lacks parameters is either perfect (unlikely) or overfitted to a specific scenario. How does the algorithm scale across link latency? F.e. very low latency (10G Ethernet, e.g. data center) vs. very high latency (satellite link)?
CoDel ignores "good queues". What happens when all queues are "good", but a transient spike exceeds outbound bandwidth? Does it just kill the last packets to arrive, after 5ms? If I adopted CoDel in my home WAP/router, it would have to deal with this situation regularly.
What prevents CoDel from working in tandem with DPI for traffic shaping? Maybe the "5ms" parameter could be a function of the packet stream class. Maybe leniency on "good" vs. "bad" flows could be adjusted to favor discards on stream classes which are known to be non-real-time.
Because unwanted, unskippable commercials are exactly like a pause before the video starts equal to the number of seconds the commercial plays.
Worse... they're loud with superficial friendliness that says, "my friend, I have a wonderful offer for you..." Ugh, I'd take a throbber any day over pre-video ads.
Then why can I trade on the London Stock Exchange? It is not a US regulated market. Is it that we consider UK regulated markets as US regulated markets?
First, the CFTC only regulates derivatives trading, which does not include any stock market. The SEC regulates US stock markets; I don't know any European regulatory organizations off the top of my head. Presumably your LSE trading is authorized by some agreement between the SEC and the EU regulators. Second, if you want to trade derivatives in the EU as a US citizen you are limited to CFTC-approved contracts.
The futures market is not just a gambling forum... they are actually trading contracts for goods.
The presence of cash-settled futures contracts is a clear counterexample to "trading contracts for goods". Cash-settled contracts are still fundamentally useful for managing risk, but I think most people would still view that as "gambling" and not "goods".
Are we going to start defining every non-everyday term in a summary?
Why not? I don't see the harm in <span title="Transmission Control Protocol">TCP</span> Ok, spans are semantically void so there's probably a better tag, but it's the attribute which matters. HTML titles are quite appropriate for unobtrusive expansion of TLAs. Your example is intentionally absurd, but it would be fine if applied only to acronyms and "initialisms".
Good point. But the user can always run on a 64-bit kernel which will support both 32- and 64-bit applications. The presence of 32-bit kernels should not stop application developers from developing and testing 64-bit code.
Just as I can buy Puff's-brand "kleenex", I can tell someone to "Just Fucking Google It" and not be surprised when they pull up any other search engine. Your complaint is specious because many brands are popular or useful while not being "household names".
16 GB ECC memory should be standard now, with RAM prices as low as they are.
You can buy all of the RAM in the world and you'll just find yourself bottlenecked by the cache. Not that I'm arguing against x86_64, but you must consider the effect of bloat on the entire memory hierarchy.
going 64 bit has a significant memory cost -- for typical C++ code, around 33% extra.
It also supports twice the number of registers, the "basic" calling convention allows passing more parameters via registers, and no register is required to store the frame pointer (for debugging). In C++ code which it sounds like you consider "typical" (read: object-oriented), passing this around sounds a lot better on x86_64, even if they use twice the bits.
What happens is the hot oil sears the skin, trapping the juices inside.
I've heard this for steaks, and I've also seen the experimental rebuttal from (IIRC) the Cook's Illustrated/Test Kitchen people which showed additional moisture loss from searing. In fact, many cooks advocate exactly the opposite: slow-cooking a steak before searing in order to minimize overcooking and produce a juicier steak.
I've also heard that deep frying is the most efficient (heat transfer/loss) cooking method. Perhaps the faster cooking is what counteracts the moisture loss?
I particularly love to hate the recent "OMFG! NOW YOU CAN START A CAR WITH A BUTTON INTEAD OF HAVING TO TUUURN THE KEEEEY AAAAALL THE WAAAAAAY!". It's an absurd feature in its meaninglessness.
My "anti-favorite" is the push for touch-screens in the console, blindly following the smartphone and tablet movement. Never mind that real buttons provide haptic feedback, allowing drivers to divert less of their focus. I only see touch screens increasing risk due to distracted driving.
What is needed is a happy mix: developers who will evaluate new tech and adopt given experience, and who will also keep past tech that still has the right punch.
Couldn't we just get one type of developer and program them all with some sort of multi-armed bandit ruleset? We might even be able to prove the optimality of their seemingly-random tech choices!
In the absence of having to make an insurance claim, why should you report it?
Crime reports are a tool to schedule and provision police officers on the street. By reporting a crime you are implicitly requesting additional surveillance. If that's what you want, then you should report the crime regardless of insurance claims.
I agree about Sagan's less-than-rigorous analysis of up/down, but I believe it is in line with Occam's Razor: Storms happen, and prey must be hunted... but if you spend most of your life in trees, the risk of falling is omnipresent. Also, consider the Moro reflex, which Sagan also discusses and which suggests a genetically-learned fear of falling.
Slashdot Mirror
If you think every caller should have logic which reacts to errors, why do you need automatic stack unwinding? Just use error codes.
But catching exceptions—only to re-throw them—is not "being thorough". It is boilerplate. If the caller is not exception-safe then you should consider a more transactional paradigm, so that you don't need to catch and re-throw. If you want to force callers to handle errors immediately, then stop using exceptions and start using "checked error codes" (i.e. lightweight objects which represent error codes and verify that the caller has acknowledged the error state).
You are expected to enforce a no-throw destructor regardless of the work that happens within it. Yes, you are expected to suppress errors if it is possible for resource-closing to throw. It sounds weird I know, but it works just fine. If the API users care about failure, they will call close() first.
Yeah, it's a bit silly at first, but it's not a surprise when you consider that std::exception is not a language construct, and is instead a Very Important language idiom. If a peer developer programs "outside of the box" in this regard, they are deserving of a hefty smack.
I have to agree with you on this one. I wish __cxa_throw would snapshot the backtrace by default. Since that is horribly implementation-specific, it would be sufficient if a standard API was created which intercepted exception throwing, so I could call backtrace on my own.
This is absurd. If you want to provide visibility to errors when closing a resource, provide a close() member or similar which can throw. Destructors exist to release resources while unwinding the stack. Since you don't know the state of the program (other than "this lexical scope is going away"), there's no reason to report errors. Again, enforcing no-throw destructors is a Very Important language idiom. Do not break it.
On the Linux side, there are also restrictions for throwing/catching across shared object (library or program) boundaries. AFAIK both shared objects must reference the same RTTI "database", which means for GCC users that both must be dynamically linked with libgcc_s. This rules out purely-static executables. While most developers don't care about this limitation, there is a very small set of developers for whom this makes a significant difference.
Well now you end up with a file API which returns error enumerations in one situation (open or fopen) and throws exceptions in another situation (read,write or fflush,fclose). That will definitely throw developers for a loop. I'd rather have the API pick one or the other and stick with it. I'm actually rather fond of POSIX C's approach to this (int fd and FILE * with thread-local errno) because it provides minimal-overhead building blocks for application-specific file abstractions. It requires an encapsulation layer for C++ applications, but it means I can cater the encapsulation layer's behavior to my exact needs. Configuration files, cache files, log files, temporary work files, saved-state files all have very different needs and should respond to faulty scenarios differently.
Is that like cow tipping but with linebackers?
Can't you repair that sort of damage with a 4th-level clerical spell? Your meat-shield should be fine unless you're playing in a gritty, low-magic setting.
Ugh. I had to do some research on SOAP as a part of an internship at an "Enterprisey" software shop. Many SOAP software stacks advertised themselves as firewall-friendly because they would "punch through the firewall on port 80". That is, the SOAP service was encapsulated in HTTP, with the implication that this was superior to getting permission from your network admins. Of course, these same service providers also provided "SOAP firewalls" so they could profit off of your company's internal dysfunction. What a pile of garbage, all of it.
Anyhow, I can see why BT would want to encapsulate itself in HTTP, but it stinks of an arms race.
I just read the Wikipedia page, and I am familiar with bufferbloat. Since you're advocating the implementation of CoDel as a mechanism for QoS, maybe you can answer these questions:
I'd have to agree with you. I've never seen an irishman drink a pint glass of vodka* with dinner, like it was water.
* substitute your favorite 70+-proof spirit
Worse... they're loud with superficial friendliness that says, "my friend, I have a wonderful offer for you..." Ugh, I'd take a throbber any day over pre-video ads.
No
First, the CFTC only regulates derivatives trading, which does not include any stock market. The SEC regulates US stock markets; I don't know any European regulatory organizations off the top of my head. Presumably your LSE trading is authorized by some agreement between the SEC and the EU regulators. Second, if you want to trade derivatives in the EU as a US citizen you are limited to CFTC-approved contracts.
The presence of cash-settled futures contracts is a clear counterexample to "trading contracts for goods". Cash-settled contracts are still fundamentally useful for managing risk, but I think most people would still view that as "gambling" and not "goods".
Why not? I don't see the harm in <span title="Transmission Control Protocol">TCP</span> Ok, spans are semantically void so there's probably a better tag, but it's the attribute which matters. HTML titles are quite appropriate for unobtrusive expansion of TLAs. Your example is intentionally absurd, but it would be fine if applied only to acronyms and "initialisms".
Good point. But the user can always run on a 64-bit kernel which will support both 32- and 64-bit applications. The presence of 32-bit kernels should not stop application developers from developing and testing 64-bit code.
You can buy all of the RAM in the world and you'll just find yourself bottlenecked by the cache. Not that I'm arguing against x86_64, but you must consider the effect of bloat on the entire memory hierarchy.
It also supports twice the number of registers, the "basic" calling convention allows passing more parameters via registers, and no register is required to store the frame pointer (for debugging). In C++ code which it sounds like you consider "typical" (read: object-oriented), passing this around sounds a lot better on x86_64, even if they use twice the bits.
I've heard this for steaks, and I've also seen the experimental rebuttal from (IIRC) the Cook's Illustrated/Test Kitchen people which showed additional moisture loss from searing. In fact, many cooks advocate exactly the opposite: slow-cooking a steak before searing in order to minimize overcooking and produce a juicier steak.
I've also heard that deep frying is the most efficient (heat transfer/loss) cooking method. Perhaps the faster cooking is what counteracts the moisture loss?
My "anti-favorite" is the push for touch-screens in the console, blindly following the smartphone and tablet movement. Never mind that real buttons provide haptic feedback, allowing drivers to divert less of their focus. I only see touch screens increasing risk due to distracted driving.
Honestly, that's so insulting to the profession. Can't we just call them "assholes" or "douchebags" like every other profession?
Couldn't we just get one type of developer and program them all with some sort of multi-armed bandit ruleset? We might even be able to prove the optimality of their seemingly-random tech choices!
Crime reports are a tool to schedule and provision police officers on the street. By reporting a crime you are implicitly requesting additional surveillance. If that's what you want, then you should report the crime regardless of insurance claims.
I agree about Sagan's less-than-rigorous analysis of up/down, but I believe it is in line with Occam's Razor: Storms happen, and prey must be hunted... but if you spend most of your life in trees, the risk of falling is omnipresent. Also, consider the Moro reflex, which Sagan also discusses and which suggests a genetically-learned fear of falling.