pthom / hello_imgui

Hello, Dear ImGui: unleash your creativity in app development and prototyping
https://pthom.github.io/hello_imgui
MIT License
606 stars 91 forks source link

Exception (and thread) safety/awareness of hello_imgui question #17

Closed MichaelKv closed 3 years ago

MichaelKv commented 3 years ago

Hello. Imgui itself is not exception safe or exceptions aware but I know how to deal with this mainly C code. What is about hello_imgui? I consider it as a kind of window management system for Imgui that hides some its mechanics so I must be sure I may or may not use exceptions with hello_imgui. Sorry for the noob question but it is a blocker for me so I want to be sure about the facts, approaches and plans. Thank you.

P.S. It would be worth to mention about thread safety/awareness too.

pthom commented 3 years ago

Hello,

hello_imgui does not use exceptions and does not make any assumptions about them being present or not. So I guess you can do whatever you like.

I consider it as a kind of window management system for Imgui that hides some its mechanics

Yes.

P.S. It would be worth to mention about thread safety/awareness too.

hello_imgui does not launch any thread at all.

MichaelKv commented 3 years ago

Thanks. To be able to use exceptions (and C++ does use them by default itself) or threads I must be sure the environment allows it. Imgui is almost a plane C library that does nothing about such support but it allows access to all the internals and do not have (or do not have many) callbacks that may throw. But as far as hello_imgui hides some internals and is built around the users’ callbacks (as I see from hello_world example) it shall provide exception safe guarantees or be aware about exceptions (allow a user somehow handle them and make hello_imgui intact). The same is valid about thread safeness – you are either thread safe or aware about threads (i.e. you provide some synchronization primitives that your clients may use). I do have to wrap some Imgui code with my own thread/exception safe wrappers and this is OK though it means Imgui may not be used in real-life applications as is. But hello_imgui is a kind of wrapper itself and to have a wrapper around a wrapper…

hello_imgui does not launch any thread at all.

I do understand it. But the real applications inevitably do and your clients must know what to expect and how use hello_imgui in multi-threaded environment with exceptions. In other words, your clients have to decide whether to use hello_imgui or write their own window management system (as I believe all them do for pure Imgui). I am not an expert in GUI applications and it is hard for me to estimate such cases myself so I rely on documentation heavily.

pthom commented 3 years ago

If you look at the API overview, you will see these callbacks:

image

And these functions:

image

What HelloImGui::Run() will do is simply:

The wording "callback" is thus perhaps not quite appropriate, but be assured that these callbacks are synchronous.

So in summary,

MichaelKv commented 3 years ago

Ok, thank you. I see that in case of an error I have to invent some program behavior that would not crash the program. I cannot just throw an exception and stop thinking about the broken frame anymore. I can wrap the Imgui’s begin/end C-style paradigm with my own exception safe helpers but hello_imgui looks different and I am not sure I could use it the same way. I wonder if there is a window manager for Imgui for C++ (the full-featured C++ with exceptions, threads, co-routines in the future, etc.)

pthom commented 3 years ago

I cannot just throw an exception and stop thinking about the broken frame

Well, the callbacks that you provide are supposed to be consisting of mainly only GUI code (I.e ImGui calls). The business code should belong elsewhere, as for any program where the GUI is separated from the rest. You could plug signals and slots between callbacks and your business code for example (using Qt or boost::signal)