Follow Slashdot stories on Twitter


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Epicycles (Score 1) 174

I'm no Java fan, but at least everything is a reference, so you don't have copy-by-accident ooga booga.

That's true, but Java doesn't really have an equivalent of the C++11 move idiom. If you want Java-like semantics from C++, just alias your pointers (ideally wrapping them in something like std::shared_ptr first). The term move is actually a little bit misleading: you're copying the object, but you're transferring ownership of the expensive contents of the object. For example, when you move a string you're creating a new string object, but you're not copying all of the string data, you're just transferring ownership of the underlying buffer. This is even more important for collection types, where you really don't want to do a deep copy and delete.

You can implement the same thing in Java by splitting your objects into cheap wrappers that have a reference to an expensive object and then adding a move() method that transfers ownership of the expensive object to the new wrapper, but it's not integrated into the language. The language integration isn't actually essential in C++ either: people have implemented the same thing using a special Move<> template, which could be used as an argument to an overloaded constructor, which would do the move operation. The nice thing about having it in the standard library and with language support is that tooling understands it. Your compiler / static analyser can warn you if you move an object and then try to anything with the old version.

If copying is so bad (which apparently it is because you'll definitely get reamed during a code review if you do), force a copy action via clone(), ike Java

Saying 'copying is bad' is just as wrong as most other 'X is always wrong' rules. Copying for small types is fine. A std::pair of an integer and a float is a couple of instructions to copy and move semantics would make no sense for it. clone() in Java is also problematic because the standard library doesn't distinguish between a deep and shallow clone.

Comment Re:More features. (Score 1) 174

For embedded systems, you really don't want exceptions. The runtime for RTTI and exceptions is bigger than the flash on most systems (I wrote the one that ships on FreeBSD, the PS4, and a few other places - it's not a huge amount of code in the context of a desktop OS, but it's 100KB of object code for the C++ bits, plus the generic stack unwinder - you don't want to burn 150-200KB of space on an embedded system for this) and stack unwinding performance is very hard to reason about in anything realtime. The reason that the Embedded C++ subset excluded templates was that they make it very hard to reason about code size. A small amount of source code can easily become 10-100KB of object code if you instantiate templates with too many different types. Writing foo<Bar>() is now not a simple case of set up the call stack and jump, it's either that simple if someone else has instantiated the same template function, or it's creating an entirely new copy of foo and all other templates that it refers to using the template parameters. This makes it very difficult to work out what changes were responsible for pushing the size above the available space. Actually, it's even worse, because the specialised function might now be simple enough to inline everywhere and give an overall space saving, but reasoning about exactly where that balance is becomes very hard. It's not that C++ generates bigger code than C, it's that object code size in C++ has far less of a direct correspondence with source code size than C.

Comment Re:More features. (Score 1) 174

Really? Prior to 1998, there was no standard library, though the Standard Template Library from SGI was pretty much treated as the standard library. When C++ was standardised in 1998, most of the STL was incorporated into the C++ standard library, so almost everything that you'd learned from the STL would still be relevant. The next bump to the standard was in 2011. Lots of stuff was added to the standard library, but very few things were changed in incompatible ways (auto_ptr was deprecated, because in 13 years no one had figured out how to use it without introducing more problems than it solved) and almost all C++98 code compiles without problems against a C++11 library. C++14 and C++17 have both added a lot more useful things but removed or made incompatible changes to very few things.

Let's look at a commonly used class, std::vector. The only incompatible changes in the last 18 years have been subtle changes to how two of the types that are accessible after template instantiation are defined. Code using these types will still work (because the changes are not on the public side of the interface), but the chain for defining them is more explicit (e.g. the type of elements is now the type of elements, not the type of things allocated by the thing that allocates references - code would fail to compile if these weren't the same type). The changes in std::map are the same.

That said, you do need to learn new things. Modern C++ shouldn't use bare pointers anywhere and should create objects with std::make_shared or std::make_unique. The addition of std::variant, std::optional, and std::any in C++17 clean up a lot of code.

Comment Re: A new fad? (Score 1) 174

Yes, except with compile-time specialisation instead of run-time specialisation. One of the big problems that I have with C++ is that it has entirely separate mechanisms and syntax for implementing the same thing with compile-time and run-time specialisation and they don't always compose well. Languages such as Java sidestep this by providing only run-time specialisation and expecting the JIT compiler to generate the equivalent of compile-time specialisation.

With an abstract class in C++, you'd require that every method be called via a vtable, which makes inlining hard (though modern compiler can do devirtualisation to some extent). This often doesn't matter, but when it's something like an array access, which is 1-2 instructions, the cost of the method call adds up. In contrast, if you use a template then the compiler knows exactly which method implementation is called and will inline any trivial methods (at the cost of now having one version of each templated function for every data type, which can blow away your instruction cache if you're not careful). The down side of the template approach is that you have no (simple) way of saying 'this template argument must be a thing on which these operations are defined' and the error message when you get it wrong is often dozens of layers of template instantiation later and totally incomprehensible without a tool such as Templight.

Comment Re:C# vs Swift (Score 2) 21

I'm not convinced by Chris' argument here. GC is an abstract policy (objects go away after they become unreachable), ARC is a policy (GC for acyclic data structures, deterministic destruction when the object is no longer reachable) combined with a mechanism (per object refcounts, refcount manipulation on every update). There is a huge design space for mechanisms that implement the GC policy and they all trade throughput and latency in different ways. It would be entirely possible to implement the C# GC requirements using ARC combined with either a cycle detector or a full mark-and-sweep-like mechanism for collecting cycles. If you used a programming style without cyclic data structures then you'd end up with almost identical performance for both.

Most mainstream GC implementations favour throughput over latency. In ARC, you're doing (at least) an atomic op for every heap pointer assignment. In parallel code, this leads to false sharing (two threads updating references to point to the same object will contend on the reference count, even if they're only reading the object and could otherwise have it in the shared state in their caches). There is a small cost with each operation, but it's deterministic and it doesn't add much to latency (until you're in a bit of code that removes the last reference to a huge object graph and then has to pause while they're all collected - one of the key innovations of OpenStep was the autorelease pool, which meant that this kind of deallocation almost always happens in between runloop iteration). A number of other GC mechanisms are tuned for latency, to the extent that they can be used in hard realtime systems with a few constraints on data structure design (but fewer than if you're doing manual memory management).

This is, unfortunately, a common misconception regarding GC: that it implies a specific implementation choice. The first GC papers were published almost 60 years ago and it's been an active research area ever since, filling up the design space with vastly different approaches.

Comment Re:Because people can travel? (Score 1) 187

This would require massive amounts of additional DRM to insure the software was running in the correct region. Think of DVD players, and the reason I stopped buying DVDs.

For software this would be catastrophic. For anyone who travels software that works on one country and not another will be useless.

Comment Re:Stick with iOS (Score 1) 146

The trouble is that, while that's a good question; it applies all to readily to using custom ROMs or using stock ones.

Should you trust some random dude on the internet who totally got AOSP+CM tweaks working on a newer kernel by aggregating blobs from 4 different devices? No, probably not. He may well be acting in good faith; but you have zero assurance of that; or much reason to trust that he hasn't made some potentially serious error in the process of making it work.

Should you trust your handset vendor/(and telco, if it's a phone that they've had a hand in)/Google? No, very probably not. The vendors do seem to care slightly more about bugs that might cause customer support calls or returns; and a lot less about security patches or providing vaguely recent versions of anything; but aside from those somewhat different technical priorities they aren't markedly more trustworthy than some random person on the XDA forums.

Comment Not good enough! (Score 3, Funny) 174

I want him to roll in the additions from Cilk++, Aspect-Oriented C++ and FeatureC++, the mobility and personalisation capabilities of Occam Pi, the networking extensions provided by rtnet and GridRPC, full encryption and error correction code facilities, everything in Boost, and a pointless subset of features from PL/1.

If you're going to do it all, might as well do it in style.

Seriously, though, Aspects would be nice.

Comment Re:Why not an x86 board? (Score 1) 108

They don't appear to have abandoned the product line; but it's been ages since I've seen a VIA x86 in the wild. HP used to build thin clients around them, after Transmeta died horribly; and prior to Atoms they showed up reasonably frequently on embedded boards(slow; but markedly cheaper than a Pentium M and markedly smaller and cooler than P4); but they don't seem to have done well recently. They were always pretty slow, and ran pretty warm unless clocked quite low, plus their GPU offering is a descendant of the old S3 'Chrome' designs which is...not good...when it comes to software support.

Between Atoms and the AMD G-series SoCs, it was a bit of a slaughter.

Comment Re:Security expert? (Score 1) 310

It probably helps that the techniques for neutralizing locks and cameras, while typically not legal if used during a burglary, aren't all that interesting to a potential jury; while the techniques for neutralizing dogs are either rather unreliable or deeply unsympathetic. Some dogs will roll right over for a charm offensive and a treat; but you can't rely on that; and if you kill a dog you've probably made yourself less popular than at least half of the actual murders on the docket, which isn't a good plan for a relatively petty property crime.

Comment Re:Why not an x86 board? (Score 2) 108

Intel has parts that would work(albeit a bit light on GPIO); I've got a dreadful little tablet here based on the Z3735G, and they packed that CPU, a gig of RAM, 16GB of flash, a 1024x600 touchscreen, some sort of BT and wifi, and a battery together for under $50.

If they hadn't also burdened the device with some of the more agonizing firmware I've had the pleasure of dealing with(AMI's dysfunctional take on 32-bit UEFI, no compatibility support module, on a 64-bit platform? Sign me up!); it'd actually be a decent little Linux toy, since that Atom is supported by intel GPU drivers, not the freaky PowerVR stuff.

As best I can tell, though, the Z-series Atoms didn't attract all that much interest(they are comparable to ARM devices aimed as similar price performance niches; but not particularly superior); and vendors weren't exactly clamoring to buy the chips; and Intel doesn't really like selling parts that cheap. They'd much rather try to sell you on a Core M or the like.

There isn't a whole lot of reason to do it; or apparent interest; but it could be done.

Comment Re:He's missing the point. (Score 4, Insightful) 139

It would be nice if people could learn to think in terms of threats that fell somewhere between "safe to ignore" and "extinction level event". Or could distinguish between "extreme and expensive" responses and "effective" ones.

9/11 could have been prevented by simple, conservative and inexpensive countermeasures. After 9/11 politicians droned on about how "9/11 changed everything," but the cold sober fact was that it in fact changed nothing. It just showed that some of the things sensible people had already been telling us to do (like reinforcing cockpit doors or getting agencies to work together despite institutional rivalries) really did need to be done. Instead "9/11 changed everything" became the rallying cry for every pet scheme that had heretofore been correctly dismissed as too expensive, hare-brained, or just plain dumb.

Which doesn't change the fact that something needed to be done. Here's the lesson I think we should take into this infrastructure debate: we should take sensible and conservative steps to secure infrastructure against terrorism now, before events put foolish ones on the table.

Slashdot Top Deals

1 Mole = 007 Secret Agents