Cars are going to change a lot in the next few decades. Electricity on one hand and software on the other change what a car is, how it gets made and who might own one. They might also change the key players. As is often the case when an industry is going to be turned upside-down, there are actually a number of separate things happening, which feed into each other and accelerate the pace of change.
First, Swift interoperates with Objective-C and C, but it doesn’t work with C++ directly. Therefore, if you want to use Swift, being knowledgeable of Objective-C++ might actually help you, because it enables you to write a wrapper that wraps any third party library that might only exist in C++ with Objective-C.
[…]
This is not your grandmother’s C++. We have auto, which is type deduction. We have shared pointers, which is basically ARC. We have
weak, which is also something we have in the Objective-C run time. We have lambdas, which is just a fancier name for blocks, and we have move semantics, which is something I’ll explain later because it’s a little crazy.[…]
There are gotchas! One thing you’ll notice when you play with Objective-C++ is compile time. Depending on how much of it you start using, things will get slower, and they might take twice or three times as long. It’s still much faster than compiling Swift (at the moment), but it is noticeable and you should be mindful of not blindly renaming all your files to .mm because you can, only where it makes sense, and where you should.
[…]
The last thing we can do is write our own smart pointer that wraps
CGPathRefand knows how to deal with Core Foundation objects. Don’t think I’m crazy, this is actually what WebKit does internally, they deal with a lot of Core Foundation objects and they want to get it right. We use something that’sCFPointer, and it’s not really much code, maybe 100 lines if you want to have move semantics and all those nice little details.
Martin Thomson (via Pieter Hintjens):
Jon Postel’s famous statement in RFC 1122 of “Be liberal in what you accept, and conservative in what you send” - is a principle that has long guided the design of Internet protocols and implementations of those protocols. The posture this statement advocates might promote interoperability in the short term, but that short term advantage is outweighed by negative consequences that affect the long term maintenance of a protocol and its ecosystem.
[…]
An implementation that reacts to variations in the manner advised by Postel sets up a feedback cycle:
- Over time, implementations progressively add new code to constrain how data is transmitted, or to permit variations what is received.
- Errors in implementations, or confusion about semantics can thereby be masked.
- As a result, errors can become entrenched, forcing other implementations to be tolerant of those errors.
“Ok, let me see if I have this right,” says Sarah. “You want to be able to quickly exclude posts that a user has read, so that you don’t suggest those posts again. And a Bloom filter is a good fit for this problem, because it will never let through a post that the user has read, and even though it might exclude a post that they haven’t read, that’s ok because they’ll never know what they don’t see? And it’s very fast?”
In this post I take an unusual approach to explaining Bloom filters. We won’t begin with a full-blown explanation. Instead, I’ll gradually build up to the full data structure in stages. My goal is to tell a plausible story explaining how one could invent Bloom filters from scratch, with each step along the way more or less “obvious”. Of course, hindsight is 20-20, and such a story shouldn’t be taken too literally. Rather, the benefit of developing Bloom filters in this way is that it will deepen our understanding of why Bloom filters work in just the way they do.
[…]
In actual applications of Bloom filters, we won’t know S in advance, nor |S|. So the way we usually specify a Bloom filter is to specify the maximum size n of set that we’d like to be able to represent, and the maximal probability of error, p, that we’re willing to tolerate.
[…]
Bloom filters have been used to solve many different problems. Here’s just a few examples to give the flavour of how they can be used. An early idea was Manber and Wu’s 1994 proposal to use Bloom filters to store lists of weak passwords. Google’s BigTable storage system uses Bloom filters to speed up queries, by avoiding disk accesses for rows or columns that don’t exist. Google Chrome uses Bloom filters to do safe web browsing – the opening example in this post was quite real!
[…]
Instead, the
deleteoperation is implemented using an idea known as a counting Bloom filter. The basic idea is to take a standard Bloom filter, and replace each bit in the bit array by a bucket containing several bits (usually 3 or 4 bits).
After much work and testing – and then some more work and testing – we’re delighted to announce the release of CardDAV support in FastMail. With CardDAV, you can access your FastMail contacts on your mobile phone, tablet or smart watch, with any changes you make on any device kept in sync – just like IMAP works with your email.
Unlike Apple and Google, you cannot restore your contacts to a particular time.
