ig prefix poll

[sonoro1234]

Hello,

In #175 it was raised the possibility of using c prefix for all functions without a namespace and cImGui_ prefix for all functions that belong to ImGui namespace.

I would like to know which would be the implications for the several use cases of cimgui: As a bridge to other languages or as a C library per se.

[Maurogik]

In my opinion (as a user of the C library), switching to a new namespace prefix would be a good thing. I always found the ig prefix a bit awkward.
I'd prefer having a direct mapping from the imgui class/namespace to the c namespace prefix (that would be ImGui_Begin() ), as it would be more consistent with the existing naming of ImRect_AddVec2(...) and other c++ object methods.
I can't think of any free-floating (namespace-less) functions in ImGui, but cSomeNamespaceLessFunction() doesn't carry across the fact that it's coming from the cimgui library. I'd rather have something more obvious like cimgui_SomeNamespaceLessFunction().

It's common practice to have functions/types exposed by a c library starting with libname_ (see, stb, nuklear, microui and more). cimgui would have more prefixes (as the c++ library exposes some additional types) but they all start with Im... so that's not really an issue.

I wouldn't object to doing a bit of search and replace to change existing code I have, but I suppose some people might, so having an optional compatibility header would be good (or some macros in cimgui.h, but toggleable with a #define).

[duarm]

i prefer cim_ and im_. I would also vouch for a different naming convention, since we're using c. e.g. cim_some_namespace_less_function(), im_rect_add_vec2(). Take a look at cglm.

[shinymerlyn]

whatever the default decision ends up, may also want to let the prefix be a define as well