Item |
Danger or benefit? |
In Swift |
1: View C++ as a federation of languages |
Probably a benefit? |
Applies the same |
2: Prefer consts, enums and inlines to defines |
Pre-processor dangerous! |
No preprocessor! No reflection or lisp-style macros either tho. |
3: Use const whenever possible |
Benefit |
let and mutating are there, but they only go so far. |
4: Make sure that objects are initialized before they’re used |
Danger |
Fully locked down, you have to initialize variables properly. |
5: Know what functions C++ silently writes and calls |
Bit of both |
Swift writes some init methods automatically, though it’s nowhere near as potentially confusing as C++ |
6: Explicitly disallow the use of compiler-generated functions you do not want |
Benefit |
Doesn’t really apply to Swift |
7: Declare destrutors virtual in polymorphic base classes |
Danger |
Not an issue, every method is virtual in Swift classes. |
8: Prevent exceptions from leaving destructors |
Danger |
No exceptions in Swift! |
9: Never call virtual functions during construction or destruction |
Danger |
Swift’s enforcement of initializing the super and all member variables helps prevent this problem |
10: Have assignment operators return a reference to *this |
More of a convention |
No assignment (or copy constructors) in Swift |
11: Handle assignment to self in operator= |
Danger |
No assignment (or copy constructors) in Swift |
12: Copy all parts of an object |
Danger |
Still dangerous, but without as good tools to fix it (no copy constructors on structs!) |
13: Use objects to manage resources |
Benefit |
ARC + deinit = same benefit! So long as you’re careful about variable capture. |
14: Think carefully about copying behavior in resource-managing classes |
Good advice |
Good advice applies, take it |
15: Provide access to raw resources in resource-managing classes |
Good advice |
Good advice applies, take it |
16: Use the same form in corresponding uses of new and delete |
Bit of both |
No need for explicit memory management in Swift. That’s good, right? |
17: Store newer objects in smart pointers in standalone statements |
Bit of both |
ARC means every pointer in Swift is a smart pointer, so all good. |
18: Make interfaces easy to use correctly and hard to use incorrectly |
Good advice |
Good advice applies, take it |
19: Treat class design as type design |
Good advice |
Good advice applies, take it |
20: Prefer pass-by-reference-to-const to pass-by-value |
Bit of both |
Doesn’t really apply to Swift, though I wish it had proper const support. |
21: Don’t try to return a reference when you must return an object. |
Danger |
ARC means every pointer in Swift is a smart pointer, so all good. |
22: Declare data members private |
Benefit |
No public/private in Swift – yet. It’s coming apparently. |
23: Prefer non-member non-friend functions to member functions |
Bit of both |
Seems to apply the same to Swift. |
24: Declare non-member functions when type conversions should apply to all parameters |
Bit of both |
Type conversion in Swift is very different, and rarely implicit, so this doesn’t really apply. |
25: Consider support for a non-throwing swap |
Bit of both |
No exceptions in Swift, so your swap will definitely be non-throwing. |
26: Postpone variable definitions as long as possible |
Good advice |
Good advice applies, take it |
27: Minimize casting |
Danger |
Swift type casting is a lot safer/saner/more powerful than C++. |
28: Avoid returning “handles” to object internals. |
Good advice |
Good advice applies, take it |
29: Strive for exception-safe code |
Danger |
Swift code is definitely exception-safe. |
30: Understand the ins and outs of inlining |
Danger |
If compilers aren’t better at humans at inlining these days, something has gone wrong. |
31: Minimize compilation dependencies between files |
Danger |
No more headers! |
32: Make sure public inheritance models “is-a” |
Good advice |
Good advice applies, take it |
33: Avoid hiding inherited names |
Danger |
Swift mandates you override a method if it has the same signature as a parent class version |
34: Differentiate between inheritance of interface and inheritance of implementation |
Good advice |
Good advice (mostly) applies, take it |
35: Consider alternatives to virtual functions |
Good advice |
I need to research this one… It probably applies. |
36: Never redefine an inherited non-virtual function |
Danger |
No non-virtual functions in Swift |
37: Never redefine a function’s inherited default parameter value |
Danger |
Swift behaves the same right now but this has been declared a bug in the compiler |
38: Model “has-a” or “is-implemented-in-terms-of” through composition. |
Good advice |
Good advice applies, take it |
39: Use private inheritance judiciously |
Danger |
Private inheritance is a weird C++ thing, don’t sweat it. |
40: Use multiple inheritance judiciously. |
Danger |
No multiple implementation inheritance in Swift. Most people think this is the right idea. |
41: Understand implicit interfaces and compile-time polymorphism |
Benefit |
Swift has compile-time polymorphism through generics much like C++ templates but they differ a lot (C++ templates are crazy powerful crazy complicated) |
42: Understand the two meanings of typename |
Confusing, if not dangerous |
You know how I said C++ templates got crazy complicated? This is part of that. |
Item 43: Know how to access names in templatized base classes |
Confusing, if not dangerous |
I need to research this one… probably doesn’t apply. |
Item 44: Factor parameter-independent code out of templates |
Danger |
Is it possible Swift generics use could result in code bloat? Would really need some serious LLVM digging to find out. |
Item 45: Use member function templates to accept “all compatible types.” |
Benefit |
Swift generics provide much of the same features. Needs a bit more research. |
Item 46: Define non-member functions inside templates when type conversions are desired |
Benefit |
Swift is not very implicit type-conversion friendly (opinion probably divided on whether this is a good or bad… I think bad, most probably think good) |
Item 47: Use traits classes for information about types |
Benefit |
I need to research this one… Associated types and type constrains in Swift seem related to this. |
Item 48: Be aware of template metaprogramming |
A bizarre C++ rabbit hole |
Probably best not to think about it. |
Items 49-52: New and delete |
Various |
Swift does have UnsafePointer and malloc so maybe these are kind of topics are not as much of a non-issue as you might think at first. |
53: Pay attention to compiler warnings |
Good advice |
Good advice applies, take it |
Item 54: Familiarize yourself with the standard library, including TR1 |
Benefit |
Objective-C, like C++, has a huge library behind it, all of which can be used from Swift. Question is, how much will be ported to a more Swift-like form? Time will tell |
Item 55: Familiarize yourself with Boost |
Beneft |
Boost is fantastic. But early indications are, there’s a huge community of Swift developers looking to do similar things. |