# Taking the C++ hat off

**URL:** <https://forums.swift.org/t/taking-the-c-hat-off/74483>\
**Category:** Using Swift\
**Tags:** cplusplus\
**Created:** [September 10, 2024, 5:46am UTC](https://forums.swift.org/t/taking-the-c-hat-off/74483 "2024-09-10T05:46:52Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![ibex](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ibex/32/30439_2.png) [@ibex](https://forums.swift.org/u/ibex)\
**Post date:** [September 10, 2024, 5:46am UTC](https://forums.swift.org/t/taking-the-c-hat-off/74483/1 "2024-09-10T05:46:52Z")

</div>

I had been thinking that, coming from a `C++` background, I was the only one sometimes feeling perplexed until I saw this [post](https://forums.swift.org/t/overridden-method-not-called-on-class-where-expected/74399), which made me realize that I have to unlearn two important `C++` ways of doing things: `templates` and `polymorphism`.

Does anyone have other suggestions to make the transition smoother?

---

<div class="post-metadata">

**Author:** ![vanvoorden](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vanvoorden/32/33619_2.png) [@vanvoorden](https://forums.swift.org/u/vanvoorden)\
**Post date:** [September 10, 2024, 6:22am UTC](https://forums.swift.org/t/taking-the-c-hat-off/74483/2 "2024-09-10T06:22:34Z")

</div>

> [@ibex](#):
>
> Does anyone have other suggestions to make the transition smoother?

> **[Swift for C++ Practitioners, Part 1: Intro & Value Types | Doug's...](https://www.douggregor.net/posts/swift-for-cxx-practitioners-value-types/)**
>
> Swift for C++ Practitioners, Part 1: Intro & Value Types

---

<div class="post-metadata">

**Author:** ![ibex](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ibex/32/30439_2.png) [@ibex](https://forums.swift.org/u/ibex)\
**Post date:** [September 10, 2024, 6:53am UTC](https://forums.swift.org/t/taking-the-c-hat-off/74483/3 "2024-09-10T06:53:02Z")

</div>

Thank you, @vanvoorden.

I have been there before, but now I see that there are two new chapters. I am diving in. 🙂

---

<div class="post-metadata">

**Author:** ![crontab](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/crontab/32/7374_2.png) [@crontab](https://forums.swift.org/u/crontab)\
**Post date:** [September 10, 2024, 7:52am UTC](https://forums.swift.org/t/taking-the-c-hat-off/74483/4 "2024-09-10T07:52:49Z")

</div>

I'd add, using destructors for any meaningful non-trivial action should be minimized in Swift due to destruction being a bit less deterministic compared to C++, plus the problem of error handling. This has been discussed on this forum (can't find the thread at the moment).

After a few years of coding in Swift I found myself using `deinit` mainly for two purposes: (1) debug printing, for cheap memory leak diagnostics and (2) manual memory deallocation in wrappers around some older API's.

Automatically deallocating external resources that can potentially fail is problematic in Swift. You can't always ignore a failure in your `deinit`: think of closing a file, socket, database connection, or some other network or peripheral transaction; these things require explicit finalization and I don't see how Swift can help with automating these things.

---

<div class="post-metadata">

**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\
**Post date:** [September 10, 2024, 11:19pm UTC](https://forums.swift.org/t/taking-the-c-hat-off/74483/5 "2024-09-10T23:19:05Z")

</div>

Swift is polymorphic the same way that C++ is: subclasses have a subtype relationship to their superclasses. In other words, an instance of a subclass can be used everywhere any of its superclasses is used.

Swift has both virtual and static dispatch, but doesn’t use the `virtual` keyword to distinguish the cases. In C++ terms:

- Methods declared in a class’s main definition are implicitly `virtual`, and cannot be made non-virtual.
- Methods declared in class extensions are not, and cannot be made, `virtual`.
- When a subclass overrides a `virtual` method inherited from a superclass, Swift **requires** the `override` keyword. (Unless the method was originally defined in a protocol inherited by the superclass—see below.)
- Override methods can be declared within a subclass’s main body or within an extension.
- A subclass cannot declare a `virtual` method with the same name as a non-`virtual` method inherited from its superclass.
- An extension of a subclass can declare a non-`virtual` method with the same name as a non-`virtual` method inherited from a superclass. It cannot use the `override` keyword.

Swift classes can inherit from at most one non-abstract base class. Protocols are similar to abstract base classes in C++, with a few notes:

- Methods declared in the protocol’s main body are implicitly _pure_ `virtual`, and cannot be made non-`virtual`.
- Methods declared in the protocol’s main body can be made _non-pure_ `virtual` by providing a “default” implementation of that method in an extension of that protocol.
- Methods originally declared in protocol extensions are not, and cannot be made, `virtual`.
- If a class directly inherits from a protocol, it **must** implement all methods declared in the protocol.
- Implementations of methods inherited from a protocol do not use the `override` keyword, even if a superclass or the protocol itself has a (default) implementation of the method.
- Protocols can inherit from other protocols, but they cannot inherit from classes.
- An extension of a protocol can provide a default implementation for a method inherited from another protocol.
- A method implementation in a protocol extension that does not provide a default implementation declares a new, non-`virtual` method on that protocol.

---

<div class="post-metadata">

**Author:** ![ibex](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ibex/32/30439_2.png) [@ibex](https://forums.swift.org/u/ibex)\
**Post date:** [September 10, 2024, 11:35pm UTC](https://forums.swift.org/t/taking-the-c-hat-off/74483/6 "2024-09-10T23:35:04Z")

</div>

Thank you for the excellent summary, @ksluder.

> [@ksluder](#):
>
> A method implementation in a protocol extension that does not provide a default implementation declares a new, non-`virtual` method on that protocol.

To clarify, could you provide a concrete example?

---

<div class="post-metadata">

**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\
**Post date:** [September 10, 2024, 11:40pm UTC](https://forums.swift.org/t/taking-the-c-hat-off/74483/7 "2024-09-10T23:40:23Z")

</div>

```swift
protocol P { }
extension P {
  func foo() { print("P.foo()") }
}

protocol Q : P { } // Q inherits from P
extension Q {
  func foo() { print("Q.foo()") }
}

struct S : Q { }

(S() as P).foo() // prints "P.foo()"
(S() as Q).foo() // prints "Q.foo()"

```