But if you think about ownership you can spot the bug in a proper code-review.
Smart pointers are about ownership, where a unique_ptr has unique (one owner) ownership.
If you create a second owner, which happens in fun1, then that second owner is cleaning up before (at the end of scope -> RAII), it is cleaned up in by its first owner (resulting in a double free)
A guideline which is often used, is:
pass by reference -> not transferring ownership
pass by raw pointer -> transferring ownership
So having a function with a raw pointer argument flags transfer of ownership, but isn't necessarily so. The transfer really happens on line 44.
A unique_ptr actually guards you from that, because it is move only (cannot be copied). Using a std::unique_ptr on the interface of fun1 would have caught the problem at compile time, because an explicit move would have been needed to tranfer ownership, which would have put the original object in an valid but unspecified state. This would result in the original owner not cleaning up the resource, and therefore not resulting in a double free.
By using the get function on the unique pointer you actually remove the guards of having one owner.
There are a lot of things wrong with this code, which after being solved I don't see how you would need a pointer at all.
Otherwise, you need to know about the guidelines of using smart pointers.
So my conclusion after reading this code is:
This looks like C code with some C++ features sprinkled in. If you want to write C++ you need to know a lot about the language and its guidelines.
Thinking about ownership is hard but necessary in any language. Having the ownership correct would have made it easy to add smart pointers. If the ownership is not clear, using raw pointers will not save you.
What is the most important data (or strava features) you want to keep?
I was actually looking into this myself, and a few parts of strava are not that hard.
For me the overview of my rides (including avg speed and distance is important), I quickly implemented a webpage with javascript and leaflet (map viewer), and I could present that data pretty quickly using geojson. I had an offline program which converted gpx traces to geojson, but I'm pretty sure I'm able to read gpx in javascript directly.
The harder part is generating the gpx trace (which I used komoot app for), as this involves matching your trace (gps positions) on a map instead of using the data as is.
Until we solve all "problems", we need software.
At least in some of the solutions, part of the solution will require software. The whole no-code thing is BS in my opinion, because it is just another layer of abstraction.
Maybe we make "making software" easier and more people can do it, but solving a problem will not go away.
If you rely on global state, this global state is also mangled to a different symbol, this might be undesirable.
For example, if you use a logger which relies on a extern defined variable. Your singleton is duplicated.
Also all your code is duplicated.
I agree that how rust does it is a very nice solution.
I also would like to drop backwards compatibility in favor for a clean simple language, because I happen to write completely new functionality.
If you ask yourself the question: "Do I want to break backwards compatibility in 2020?", then that same question could have been asked in 2003. Which would mean that the language lost traction (at least that is my opinion), because I could not recompile my old code and therefore I keep using the old before C++2003 compiler. So, the reason that it is popular, _is_ because it takes care of installed base and does not break existing code (or at least minimizes breakage).
I agree that c++ is complex, but remember that while trying to update the language the standard committee is trying not to do breaking changes.
If you can do a greenfield implementation like rust, you don't have the baggage of an installed base, yet.
If you compare c++ to a language that is also around for more that 25 years it starts to make more sense why it is complex. Add to that, that it started as an extension to c, which is the reason why it became popular in the beginning.
Also, zero-cost run-time abstractions.
It is whatever you give priority design-wise, and if you look at what is important in c++ (zero-cost runtime abstractions, control of the resulting code), then ending up with something as complex as the c++ language is hard to prevent.
But if you think about ownership you can spot the bug in a proper code-review. Smart pointers are about ownership, where a unique_ptr has unique (one owner) ownership. If you create a second owner, which happens in fun1, then that second owner is cleaning up before (at the end of scope -> RAII), it is cleaned up in by its first owner (resulting in a double free)
A guideline which is often used, is:
pass by reference -> not transferring ownership
pass by raw pointer -> transferring ownership
So having a function with a raw pointer argument flags transfer of ownership, but isn't necessarily so. The transfer really happens on line 44.
A unique_ptr actually guards you from that, because it is move only (cannot be copied). Using a std::unique_ptr on the interface of fun1 would have caught the problem at compile time, because an explicit move would have been needed to tranfer ownership, which would have put the original object in an valid but unspecified state. This would result in the original owner not cleaning up the resource, and therefore not resulting in a double free.
By using the get function on the unique pointer you actually remove the guards of having one owner.
There are a lot of things wrong with this code, which after being solved I don't see how you would need a pointer at all. Otherwise, you need to know about the guidelines of using smart pointers.
So my conclusion after reading this code is: This looks like C code with some C++ features sprinkled in. If you want to write C++ you need to know a lot about the language and its guidelines. Thinking about ownership is hard but necessary in any language. Having the ownership correct would have made it easy to add smart pointers. If the ownership is not clear, using raw pointers will not save you.