3 ms·

> One advantage, from the point of view of someone that likes using C++, is being a safer programming language. How so? Last I checked swift doesn't have garba

by duaneb 10y ago

> One advantage, from the point of view of someone that likes using C++, is being a safer programming language. How so? Last I checked swift doesn't have garbage collection (but does have refcounting, which is nearly as good, but still requires modifying algorithms with cycles), and only offer syntactic sugar over existing null pointer semantics (as opposed to the memory ownership guarantees provided by rust). Isn't this the exact same feature set offered by modern C++ with owned_ptr and shared_ptr? Go + rust both have guaranteed memory safety unless you go out of your way to disable safeguards. How hard is it to shoot yourself in the foot with swift, memory wise? Do you still have to fall back on autorelease pools for tight inner loops, like in objective-c?

seandougall 10y ago
It sounds like you're used to manual reference counting in ObjC, which genuinely is a pain. Swift (and modern ObjC) use automatic reference counting, which is much more robust and less dependent on autorelease pools. For one thing, class instances get released when they no longer have a strong reference -- so to answer your specific question, you can totally instantiate a class for just one iteration of a loop. Plus, Swift makes much better use of value types, so you're less reliant on heap allocations in the first place. I personally cringe whenever I have to go back to a GC and relinquish all control over object lifecycle.
- pjmlp 10y ago
  > I personally cringe whenever I have to go back to a GC and relinquish all control over object lifecycle. I think it is a matter of which language and which GC. A few do offer the possibility to control allocation, and sadly a few others that were good at it died in the late 90's.
pjmlp 10y ago
No, because in C++ they are optional. If you work in a team or use libraries, specially binary ones, you have zero guarantees that the code quality and how the memory is managed. In Swift, RC is compulsory and manually managing memory requires asking the compiler for permission all the time, so there are minimal set of guarantees how the memory will be managed. Modern C++ is great, and many in the community do push a lot for improving the quality, unfortunately I keep seeing the working enterprise developers just outputting C code compiled with a C++ compiler instead.

by duaneb 10y ago

seandougall 10y ago

It sounds like you're used to manual reference counting in ObjC, which genuinely is a pain. Swift (and modern ObjC) use automatic reference counting, which is much more robust and less dependent on autorelease pools. For one thing, class instances get released when they no longer have a strong reference -- so to answer your specific question, you can totally instantiate a class for just one iteration of a loop. Plus, Swift makes much better use of value types, so you're less reliant on heap allocations in the first place. I personally cringe whenever I have to go back to a GC and relinquish all control over object lifecycle.

pjmlp 10y ago
> I personally cringe whenever I have to go back to a GC and relinquish all control over object lifecycle. I think it is a matter of which language and which GC. A few do offer the possibility to control allocation, and sadly a few others that were good at it died in the late 90's.

pjmlp 10y ago

No, because in C++ they are optional. If you work in a team or use libraries, specially binary ones, you have zero guarantees that the code quality and how the memory is managed. In Swift, RC is compulsory and manually managing memory requires asking the compiler for permission all the time, so there are minimal set of guarantees how the memory will be managed. Modern C++ is great, and many in the community do push a lot for improving the quality, unfortunately I keep seeing the working enterprise developers just outputting C code compiled with a C++ compiler instead.