Instead of a generic OnScopeExit having classes like WinInit and EarlyInit would be cleaner me thinks. The comment in profilerShutdown "// Shut down profiler initialised by EarlyInit" is a hint that this design isn't that clean after all.

In D5154#219238, @sera wrote:

Instead of a generic OnScopeExit having classes like WinInit and EarlyInit would be cleaner me thinks. The comment in profilerShutdown "// Shut down profiler initialised by EarlyInit" is a hint that this design isn't that clean after all.

I agree that something like:

Profiler2::LivetimeGuard guard;

is better then

g_Profiler2.Initialise();
OnScopeExit profilerShutdown{[]
		{
			// Shut down profiler initialised by EarlyInit
			g_Profiler2.Shutdown();
		}};

But I would have to rip EarlyInit appart. Same for Init, InitGraphics and InitNonVisual.
I'm not sure if the gain is worth the trouble.

In D5154#219247, @phosit wrote:

I agree that something like:

Profiler2::LivetimeGuard guard;

is better

pulling out profiler init out of earlyinit doesn't seem an issue, right?

But I would have to rip EarlyInit appart. Same for Init, InitGraphics and InitNonVisual.
I'm not sure if the gain is worth the trouble.

I haven't really dug into it but maybe a base class init and instantiating a derived init based on type might work.

I don't feel this helper to be a legitimate pattern, at least I've never seen it before, and if it were common I guess there should be such a helper in stl or at least boost or similar. The hole setup of the app is done in C manner, so reshuffling / unraveling / reorganizing might be a bit of work but might lead to a much better result.

I'm not saying what you do is wrong but it doesn't feel quite right either.

In D5154#219276, @sera wrote:

I don't feel this helper to be a legitimate pattern, at least I've never seen it before, and if it were common I guess there should be such a helper in stl or at least boost or similar.

JFYI There is an experimental one: https://en.cppreference.com/w/cpp/experimental/scope_exit

so reshuffling / unraveling / reorganizing might be a bit of work but might lead to a much better result.
I'm not saying what you do is wrong but it doesn't feel quite right either.

I agree that's not wrong and indeed refactoring the code to have proper lifetimes is preferable (though it's not a priority, since the code is pretty simple and straight forward even if it's not cleanest one).

In D5154#219285, @vladislavbelov wrote:

In D5154#219276, @sera wrote:

I don't feel this helper to be a legitimate pattern, at least I've never seen it before, and if it were common I guess there should be such a helper in stl or at least boost or similar.

JFYI There is an experimental one: https://en.cppreference.com/w/cpp/experimental/scope_exit

There is also an implementation in boost: https://www.boost.org/doc/libs/1_83_0/libs/scope_exit/doc/html/index.html
Some libraries call such a class finally: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Re-finally

so reshuffling / unraveling / reorganizing might be a bit of work but might lead to a much better result.
I'm not saying what you do is wrong but it doesn't feel quite right either.

I agree that's not wrong and indeed refactoring the code to have proper lifetimes is preferable (though it's not a priority, since the code is pretty simple and straight forward even if it's not cleanest one).

That doesn't tell much... Should I do it like this or should i write multiple propper RAII types?

In D5154#219286, @phosit wrote:

Some libraries call such a class finally: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Re-finally

Now I know where the feeling of this being odd came from - finally.

Maybe instead of thinking in terms of init or setup it should be a case of instantiating different "apps", like VisualGame, NonVisualGame, ArchiveBuilder, Atlas, ...

In D5154#219286, @phosit wrote:

Some libraries call such a class finally: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Re-finally

I agree with the node from the guidelines:

That doesn't tell much... Should I do it like this or should i write multiple propper RAII types?

Honestly I'd prefer to redesign the main.cpp and related stuff. To have something like CApplication/CMainLoop to avoid globals and implicit lifetimes.

In D5154#219398, @vladislavbelov wrote:

In D5154#219286, @phosit wrote:

That doesn't tell much... Should I do it like this or should i write multiple propper RAII types?

Honestly I'd prefer to redesign the main.cpp and related stuff. To have something like CApplication/CMainLoop to avoid globals and implicit lifetimes.

:D I had the same discussion with elexis yesterday.
Adding a class doesn't help much: we will still have to refactor code to be able to remove globals.

In D5154#219403, @phosit wrote:

Adding a class doesn't help much: we will still have to refactor code to be able to remove globals.

The main idea is to not make everything clean at once, but move towards by small steps. All polishing refactorings might be done afterwards. You might take a look my GL -> abstract API refactoring history. It took me more than a year (and it's still far from perfect). But it allowed me to add Vulkan support and make players life more comfortable in some cases (especially on macOS).