STL arrays are allocated on the heap, and that's a quite slower and more wasteful allocation form than on the stack.

Actually, STL arrays (as in std::array) can be allocated on the stack. They have no overhead.

It seems you're referring to STL vectors (as in std::vector), which is an implementation of a dynamically-sized container, so, yes, it uses the heap—as does every other dynamic container I know of. That neither makes it significantly slower nor more wasteful.

Sure, you can use C arrays, but guess what: out go type safety and STL algorithms and C++ idioms.

False on all counts. C arrays can be used with type safety, with STL algorithms, and with C++ idioms.

"Disabling exceptions" is a non-standard extension to the language. If you disable exceptions, you're technically not using C++ but a nonstandard dialect.

What does it even mean to disable exceptions? I'll assume it makes new behave like new(std::nothrow), but is your STL implemented in a way to deal with that? It probably expects a failed allocation to throw. If it also has to check for nullptr, then there's another code path that's probably not well tested. What should std::vector::at do when faced with an out-of-bounds index? The standard says that it shall throw an exception.

Disabling exceptions is different than simply not using a feature you don't want to use. If you don't want to write a template, that's fine. If you don't take advantage of dynamic_cast, that's OK, too. If you choose not to use STL and avoid the standard new operator and don't use RAII, then I suppose you can reasonably ignore exceptions. But STL and new and RAII constructors that fail will throw exceptions. You can choose not to catch any of those, but that doesn't mean that exceptions don't exist.

In particular, exceptions and RTTI are absolutely verboten.

Ignoring RTTI is fine, but forbidding exceptions requires a dangerous sort of doublethink. The language itself, as well as the STL, is defined to generate and use exceptions. By ignoring their existence, you banish yourself to a nonstandard purgatory.

For example, every new now must become new(std::nothrow). For every STL container type, you have to provide a custom allocator that doesn't throw. That's a bit unwieldy.

By denying exceptions, you force everyone to use error-prone idioms. For example, the only way a constructor can signal a failure is to throw an exception. If you forbid exceptions, then all constructors must always be failure-proof. And then you have to provide an extra initializer method to do the real initialization that can fail. Every user of the class must reliably call the init method after construction, which gets cumbersome when classes are nested or when you're putting instances into an STL container. It also means that objects can have a zombie state--that period of time between construction and initialization. Zombie states add complexity and create an explosion in the number of test cases. Separate initialization means you can't always use const when you should.

Exceptions are necessary to the C++ promise that your object will be fully constructed and later destructed, or it will not be constructed at all. This is the basis of the RAII pattern, which just happens to be the best pattern yet devised for resource management. Without RAII, you will almost certainly have leaks. Worse, you won't be able to write exception-safe code, so you are essentially closing the door to ever using exceptions.

In response, FDA told Threatpost that it is developing tools to disassemble and test medical device software and locate security problems and weak design.

Why would the FDA have to disassemble the code in the devices? The FDA approval process requires giving the FDA examiners access to the source code, along with design docs, schematics, etc. Why would they need to reverse-engineer a device? Something's not right here.

Fourteen years sounds like a long time to support a software product. Yet I find it interesting to point out that, in the U.S., any "inventions" that debuted with the release of Windows XP will still have 6 years of patent protection, and the code itself will have another 75 years of copyright protection. This is for a product that's already been unavailable commercially for a while and will be completely dead in two more years.

Overly long IP lifetimes hurt security, technological progress, innovation, and culture.

There were several Maskelynes. I believe the one mentioned in the summary was a stage magician not a musician.

The problem is when the debt collector is not after you but after someone else who lied and gave out your cell phone number. Debt collectors robocall, don't believe you when you tell them they have the wrong number, fill your voice mail inbox (denial of service attack), and cost you money (in the form of minutes and text messages). These are some of the reasons I gave up on cell phones.

"People can't multitask very well, and when people say they can, they're deluding themselves," said neuroscientist Earl Miller. And, he said, "The brain is very good at deluding itself."

My brain is so good at deluding itself that it can delude itself while I do three other things at the same time.

This idea is similar to applying a force to the sun and dragging the entire solar system. The author of that piece incorporated the idea into his novel C.U.S.P.

True, but publishers have been giving authors less and less editorial support as the continue to cut costs. The theory is that the slush pile is so deep that, if they dig enough, they can find a manuscript that doesn't need significant editing. Or they wait until a new author has some proven success before investing in editorial assistance to take him or her to the next level.

Possibly true. Most contracts I've seen say that the writer is ultimately responsible. Even so, in fiction (which is what Barry Eisler writes), there really aren't that many suits. Independent authors can incorporate to shield their personal finances from their professional writing liabilities.

For fiction, this is extremely rare and of limited impact. If you're a big seller, then you might get some co-op promotion (placement in end caps and feature tables in the bookstores). Publishers will sometimes circulate advance reading copies to generate reviews. Most new and mid-list authors have to do a ton of self promotion, mostly at their own expense.

It seems everything you've claimed about the publishing industry could also be said about the music labels. What's the difference you're trying to highlight?

Photopia by Adam Cadre.