Support custom numeric types

[pthom]

This PR adds support for a custom list of supported types.

There are actually two commits. If required, the second could become a second PR.

• 47909c04: implot_items.cpp: support types customization adds full types customization via -DIMPLOT_CUSTOM_NUMERIC_TYPES="(float)(double)" for example
• 874437f9: CI: link example app, with null backend Github's CI will now compile ImGui, compile ImPlot, link and run an example application (with no backend). This serves as a proof that specific templates instantiations are actually compiled, and that link succeeds.

[pthom]

@epezent : this PR is now ready for review IMHO.

[epezent]

Sounds good! I'll give this a thorough reveiew this evening.

How much additional time did adding ImGui and linking to the CI jobs add?

[pthom]

How much additional time did adding ImGui and linking to the CI jobs add?

Almost none:

vs

[epezent]

Everything looks good to me. Merged.

FYI @ocornut

[ocornut]

My two cents:

• given full configurability (looks great!) i would suggest not adding “ IMPLOT_INSTANTIATE_ALL_NUMERIC_TYPES”, especially as it may be tempting for users and we don’t know what long double would carry in term of math runtimes. For those rare types it seems reasonable to simply let the user express their needs explicitly.
• I haven’t poked in internals but wondered if small types <32 or <64 could somehow attempt to reuse larger types functions, with special adapters? Intuitively it seems like u8 u16 could use the code for u64. This is implying that generated code size and link size could be reduced. With custom type list this is now perhaps a little harder to setup, so perhaps it would need an hardcoded proof of concept because getting it to work with custom type lists.

[pthom]

@ocornut , @epezent : I agree that IMPLOT_INSTANTIATE_ALL_NUMERIC_TYPES could be removed, since it is quite likely that nobody had the time to use it.

See related PR

[ocornut]

I noticed in my projects that adding implot largely output size and linking time. Exe/object size frankly I don't think matters much, but linking time especially in "Release mode" gets pretty meaningful (talking +5..10 seconds range of increase with some settings). Link time of optimized game builds are often quite a problem.

This is probably mostly due to those instantiation. While I don't have solution right now, there's a nice tool to inspect .obj contents: https://github.com/aras-p/sizer

GIves you output such as:

Object files by code size (kilobytes, min 2.00):
 1317.61: implot_items.obj
  313.66: imgui.obj
  242.60: imgui_widgets.obj
  190.59: implot.obj
  161.03: imgui_draw.obj
  139.46: imgui_demo.obj
   80.43: imgui_tables.obj
   79.28: implot_demo.obj

Object files by data size (kilobytes, min 2.00):
  263.65: implot_items.obj [0.91 with symbols]
   91.09: imgui_demo.obj [17.91 with symbols]
   75.13: imgui.obj [3.00 with symbols]
   48.35: imgui_draw.obj [26.08 with symbols]
   44.52: imgui_widgets.obj [0.61 with symbols]
   44.27: implot.obj [1.71 with symbols]
   25.59: implot_demo.obj [3.04 with symbols]
   13.58: imgui_tables.obj [0.04 with symbols]

(this is the per-file output but the tool gives more details)

Where at a glance, we can see that the output of implot is larger than imgui. If we assume some correlation between code/data size and linking time I'd say it'd be interesting to investigate. Some factors at play:

• usage of IMPLOT_INLINE especially on large functions
• overall use of templates