ImVector question

[THE-FYP]

Since ImVector stuff was erased, how do we use void ImFontGlyphRangesBuilder_BuildRanges(ImFontGlyphRangesBuilder* self,ImVector_ImWchar* out_ranges) now?

[sonoro1234]

There is ImVector_ImWchar_create manual but I must also add ImVector_ImWchar_destroy in cimgui

[sonoro1234]

Now added.
This code can be used

local p_ranges = ig.lib.ImVector_ImWchar_create() --ig.ImVector_ImWchar()

local GRB = ig.ImFontGlyphRangesBuilder()
GRB:AddText("Hello world")
GRB:AddChar(0x7262);                               -- Add a specific character
--GRB:AddRanges(ig.GetIO().Fonts:GetGlyphRangesJapanese()); -- Add one of the default ranges
GRB:BuildRanges(p_ranges)
print(p_ranges,p_ranges[0],p_ranges[0].Size,p_ranges[0].Capacity)
local Data = p_ranges[0].Data --ffi.cast("ImWchar*",p_ranges[0].Data)
for i=0,p_ranges[0].Size-1 do
	print(Data[i])
end
ig.lib.ImVector_ImWchar_destroy(p_ranges)

[THE-FYP]

Okay. So we're back where we started when I added a metatype for this in #6.
ImVector-typed structure fields are still inconvenient to handle, especially modifying.
Maybe it's time to implement a full-featured ImVector in Lua? I think I could work on it. Right now looking through FFI Parameterized Types, it feels like this may help to create a generic ImVector.
We also have to somehow deal with these definitions and their usage: https://github.com/sonoro1234/LuaJIT-ImGui/blob/master/lua/imgui/cdefs.lua#L98

[sonoro1234]

How would you do this?
All ImVector types are necessary?
Perhaps in cimgui, only the create and destroy methods could be generated programatically.

[THE-FYP]

Something like this

local ImVector_mt = { -- Metatype metatable
    -- ...
}
local ImVector_types = {} -- Types storage. Without this a new structure will be created for the same type each time, these structs will not be compatible
local function ImVectorType(data_t)
    data_t = ffi.typeof(data_t)
    local data_t_str = tostring(data_t) -- ctype object cannot be used as a table key
    if ImVector_types[data_t_str] then
        return ImVector_types[data_t_str]
    end
    local t = ffi.typeof('struct { int Size; int Capacity; $* Data; }', data_t)
    ImVector_types[data_t_str] = t
    ffi.metatype(t, ImVector_mt)
    return t
end
M.ImVectorType = ImVectorType

local function ImVector(t, ...)
    return ImVectorType(t)(...)
end
M.ImVector = ImVector

-- This code will be generated. Must be executed between basic imgui typedef declarations and struct definitions
M.ImVector_int = ImVectorType('int')
ffi.cdef('typedef $ ImVector_int', M.ImVector_int)
M.ImVector_ImU32 = ImVectorType('ImU32')
ffi.cdef('typedef $ ImVector_ImU32', M.ImVector_ImU32)
M.ImVector_ImWchar = ImVectorType('ImWchar')
ffi.cdef('typedef $ ImVector_ImWchar', M.ImVector_ImWchar)
-- ...

-- Types are compatible (all the same)
local t1 = ffi.typeof(M.ImVector_int())
local t2 = ffi.typeof(M.ImVector('int'))
local t3 = ffi.typeof(ffi.new('ImVector_int'))
local t4 = ffi.typeof('ImVector_int')
assert(t1 == t2)
assert(t2 == t3)
assert(t3 == t4)

-- ImVector of any type can be created
local doubles = M.ImVector('double')

[THE-FYP]

• All ImVector methods and such will be written in Lua
• Memory of ImVector data is handled by imgui's MemAlloc and MemFree
• Functions ImVectorType and ImVector may stay unexposed and be used only for predefined types, so the type storage for ImVector will become unnecessary

[sonoro1234]

Using above code and doing:

local p_ranges = ig.ImVector("ImWchar")
local GRB = ig.ImFontGlyphRangesBuilder()
GRB:AddText("Hello world")
GRB:AddChar(0x7262);                               -- Add a specific character
GRB:BuildRanges(p_ranges)

errors with

 bad argument #1 to 'BuildRanges' (cannot
 convert 'struct 19572' to 'struct ImVector_ImWchar *')

[THE-FYP]

Because the new auto-generated typedefs code is necessary to be used instead of this: https://github.com/sonoro1234/LuaJIT-ImGui/blob/master/lua/imgui/cdefs.lua#L98-L114

-- This code will be generated. Must be executed between basic imgui typedef declarations and struct definitions
M.ImVector_int = ImVectorType('int')
ffi.cdef('typedef $ ImVector_int', M.ImVector_int)
M.ImVector_ImU32 = ImVectorType('ImU32')
ffi.cdef('typedef $ ImVector_ImU32', M.ImVector_ImU32)
M.ImVector_ImWchar = ImVectorType('ImWchar')
ffi.cdef('typedef $ ImVector_ImWchar', M.ImVector_ImWchar)
-- ...

[sonoro1234]

Because the new auto-generated typedefs code is necessary to be used instead of this: https://github.com/sonoro1234/LuaJIT-ImGui/blob/master/lua/imgui/cdefs.lua#L98-L114

Without doing that, this code works

local function ImVectorType(data_t)
	local imty = "ImVector_"..data_t.."[1]"
	 local t = ffi.typeof(imty)
    return t
end

Perhaps a full PR is needed to test if your proposal works!

[sonoro1234]

This is imgui ImVector destructor

inline ~ImVector()                                      { if (Data) IM_FREE(Data); }

so __gc ImVector_mt metamethod should call it to avoid memory leaks, but it is not callable if is not instanciated with a type.

For example the c interface for ImVector_ImWchar ImVector_ImWchar_destroy is

#define IM_FREE(_PTR)                       ImGui::MemFree(_PTR)
template<typename T> void IM_DELETE(T* p)   { if (p) { p->~T(); ImGui::MemFree(p); } }
CIMGUI_API void ImVector_ImWchar_destroy(ImVector_ImWchar* self)
{
    IM_DELETE(self);
}

So Imgui::MemFree should be wraped in a c function to be called from __gc metamethod to avoid memory leaking

[THE-FYP]

No need for any exports of ImVector-related stuff from cimgui, memory will be fully handled on the Lua side of ImVector implementation with FFI and ImGui::MemAlloc, ImGui::MemFree.
I'll do PR later.