some compilers allow you to call main recursively, but it is not allowed in standard c++.
it is probably, at the very least, confusing to your OS. The os expects a program to return an error code (zero is no error) upon termination and most recursion requires using returns to control the recursion, so doing this is likely to respond to the OS with odd answers under some conditions. The OS does not care that much (if there is an error code, it tells you and forgets about it) but this is just one of the ways it can mess with the way of doing things.
an early compiler I used let me make double main, void main, and others. Some compilers are rather lax unless you put in a stricter flag to ensure standard compatible code. g++ will accept a great many illegal things if not flagged for strict.
As jonnin said, it is not allowed in standard C++. Specifically, it's undefined behavior.
A loop is, in many cases, easier to understand than recursion anyway.
There are, regrettably, many things you can do in C++ that you should not do.
By which you mean "only today, somebody on this forum told me it's forbidden" ;)
but it works
As jonnin says, if it works, then it's because your compiler allows it as an extension. It's not legal as per the C++ standard, but whoever wrote that compiler decided to allow it anyway. Although even then, it may be undefined behaviour; you should check your compiler documentation to find out.
Running as fast as you can while carrying a large glass jar of nitroglycerin is probably a violation of the way you have to handle extremely volatile explosives. Do not test whether it "works".
I'm on my mobile ATM, so I'm not going g to find links for you, but calling main () is something that has caused significant t failure in the past. Main () is not a normal function; it should never be called by the user program.
Being the weird cult following it has gained from newbies 5hat want to do just that over the years, the C++ standard has taken effort to explicitly say don't do that! , ut main is also perfectly acceptable to implementation - defined overloads.
BTW, in .most cases main () is not directly called by the OS, but by the application init code, which calls main (). Only very old compilers on very old systems had a direct link. Further, calling main () from user code does not involve the OS in any way, so it isn't OS confusion that. A uses failures: it is the application doing potentially uncouth things that cause failures.
In any cas, it has always been one of those things that the programmer knew better than doing, until the mass explosion of the Hoi Poloi using C without understanding what is going on underneath. Granted, that is no longer a reasonable expectation, but the age of the language makes it a tripping point.
As I recall, amongst other things, the compiler is allowed to assume that you won't be calling main. Modern compilers do a lot of optimisation based on the assumption that the programmer won't be doing anything forbidden or undefined. As such, it can take advantage of this.
For example, I'm sure I saw a compiler once put various global constructors at the start of main. Calling main again would cause those global constructors to be called again. This is bad news, and the programmer would see strange behaviour in their code that would be effectively impossible to diagnose without looking at the assembly.