When you're writing C++, don't write it as if it were Python or D or Java. Those are fundamentally different languages with different idioms.
When we are talking about inline functions in C++, we have to distinguish two related but distinct concepts:
inline functions in a header. Function definitions within a class declaration are implicitly
inline. Templates are usually inline.
inline function (or variable) effectively disables the one-definition rule (ODR): If the linker sees multiple conflicting definitions for the same function in different compilation units the linker would usually show an error. But with
inline functions, you are promising that all definitions are identical. Additionally, an inline function can only be called from the same compilation unit where it was defined.
inlining as a compiler optimization. The semantics of an
inline function make inlining possible, but the
inline keyword does not imply that a function will be inlined. For example, a member function that was defined inline cannot be inlined through indirect calls, such as virtual calls.
You can make inlining of non-
inline functions possible by giving them internal linkage, either through the
static keyword for free functions/variables (but not members!) or through the use of an anonymous namespace.
You can use compiler-specific attributes. For example,
__attribute__ ((always_inline)) in GCC.
It is not advisable to define all your functions inline in a header.
This slows down compile times. By using multiple compilation units you can benefit from incremental compilation. This makes work on any but the most trivial C++ projects more enjoyable. But if you put unnecessary code into the header, it has to be parsed, compiled and optimized in its entirety every time. Because templates generally imply inline definitions in a header, these compile times are a reason why some projects try to limit the use of templates.
It leads to namespace pollution and a lack of encapsulation. Quite a lot of code tends to need some private helpers. In Python I'd add a underscore-function to the module, in C++ a static function or some code in an anonymous namespace so that they are restricted to the current compilation unit. But when everything is in the headers you only have a single compilation unit. All those helpers will be visible to all your code, and you effectively have no internal structure . This might also lead to name clashes.
Additionally, consider how you include headers. In the normal header–implementation split, headers that are only needed internally but not for the module's public interface can be included in the .cpp file. This limits the effects of that header, for example with any macros or global functions. This is especially important when interfacing with C libraries. This will also allow you to bridge between libraries that provide conflicting names. Not so when all your code is in the header. All included definitions will also be visible in all compilation units where your header is included.
Inline definitions only work when your dependencies can be linearized, but e.g. not for circular or recursive dependencies (such as a class that represents a tree node). Even if you put your code into a header, it might be necessary to use forward declarations or to define a method outside of the class declaration. If that method doesn't have to be
inline, then you gain nothing from defining it in the header.
If you dislike having to switch between headers and implementation files often, I suggest you look into using an IDE that lets you jump between declarations and corresponding definitions more easily.
Yes, C/C++ can be super annoying languages with all their historic cruft. And yes, Java code tends to be nicer to read.
But you will not get any benefits from trying to write C++ as if it were Java. You'd just be giving up the benefits that C++ can offer. Similarly, modern C++ avoids creating objects with
new as that effectively gives up RAII.