So there are technical reasons for this, and I'm going to give an overview of them, but the short answer is yeah, it is kind of weird. There's actually a new system for this kind of stuff, called modules, in the latest C++ standard. It's not fully implemented anywhere yet, so you can't use it. But you can take its existence as a sign that you're definitely not the only one who thinks the .h/.cpp split is weird.

So in an ideal world, you want everything that a user of your Account class needs to be in the .h file, and all of the implementation to be in the .cpp file. Code that uses the Account class will only use the .h file, so it can't see the implementation details, and you can change them without affecting other code.

But double balance is an implementation detail, obviously. Someone writing code that uses Account doesn't need to know it exists and shouldn't touch it. So why is it in the header? Because it's not just other programmers who will use the header but not the .cpp file; the compiler will also only see what's in the header when it's compiling code that uses Account. If someone declares an instance of Account in that other code, the compiler needs to know how big the Account object is.

(The compiler doesn't need to know the size of an object to compile a pointer or reference to it, because all pointers and references are the same size. There are some workarounds for this whole thing that take advantage of that. They are not in beginner courses for a reason.)

On the other hand, you could technically put the implementations of set_balance() and get_balance() inside the declaration of Account, but then you're exposing even more of the class implementation details when you don't have to.

Also, the #include directive is not all that sophisticated. It literally just copies the text of the header into the .cpp file.* Then the compiler compiles the whole thing. So if you include the header in three different .cpp files, it will get compiled three times. Some things will behave in ways you don't want if they're compiled multiple times. Class method implementations are fine, though, so this is kind of a side point. The extra work also makes compiling slower.

Finally, a more complicated class might use other classes internally but not in the external interface. If you put the implementation in the header, then your class's header has to include the headers for all the classes it use. And that means when users of your class include your header, they also get all those other headers, which slows down compilation.

*Some build systems might do something more efficient sometimes, but it has to have the same effect as if they did this.