Freetype + lunasvg, ImGui compilation error

[jokteur]

Version/Branch of Dear ImGui:

Dear ImGui 1.89.9 (18990)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=201703
define: __linux__
define: __GNUC__=11
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: imgui_impl_glfw
io.BackendRendererName: imgui_impl_opengl3
io.ConfigFlags: 0x00000440
 DockingEnable
 ViewportsEnable
io.ConfigViewportsNoDecoration
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigMemoryCompactTimer = 60.0
io.BackendFlags: 0x0000140E
 HasMouseCursors
 HasSetMousePos
 PlatformHasViewports
 RendererHasVtxOffset
 RendererHasViewports

My Issue/Question:

Hi,

I'm trying to make svg font work. I've followed the instruction here: https://github.com/ocornut/imgui/tree/master/misc/freetype. I have Freetype 2.13 installed on my system, and I've added the latest version of lunasvg (v.2.3.8) to my project.

If I define IMGUI_ENABLE_FREETYPE_LUNASVG, then I get the following compilation error (on gcc 11.3):

[build] imgui/misc/freetype/imgui_freetype.cpp:843:14:   required from here
[build] imgui/imgui.h:1875:56: error: ‘void*’ is not a pointer-to-object type
[build]  1875 | template<typename T> void IM_DELETE(T* p)   { if (p) { p->~T(); ImGui::MemFree(p); } }

If I look at the line in imgui_freetype.cpp, I see that:

static void ImGuiLunasvgPortFree(FT_Pointer* _state)
{
    IM_DELETE(*_state);
}

If I replace IM_DELETE by IM_FREE, the code compiles, because _state is not an object. However, I'm not so familiar with the imgui_freetype.cpp, so I'm not sure if this introduces a memory leak. Should I make a PR for the correction ?

[CoolFox29281819]

You'll need to move this to discussions if you want an answer.

[ocornut]

Looks like GCC introducing a new over-zealous warning with calling delete on a void* or something. Will investigate.

[ocornut]

The correct call would be IM_DELETE((LunasvgPortState*)*_state); here.
This caused indeed a small leak, and GCC warning was useful.
Pushed fix: d6360c1
Thank you!