-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor in 1.64 (imgui_widgets.cpp) #2036
Comments
…functions from imgui.cpp to imgui_widgets.cpp (#2036)
… imgui.cpp to imgui_widgets.cpp (#2036)
…from imgui.cpp to imgui_widgets.cpp (#2036)
…functions from imgui.cpp to imgui_widgets.cpp (#2036)
… imgui.cpp to imgui_widgets.cpp (#2036)
…from imgui.cpp to imgui_widgets.cpp (#2036)
This might help: https://stackoverflow.com/a/8131212 |
I mean: template <>
extern IMGUI_API float RoundScalarWithFormat<float, float>(const char* format, ImGuiDataType data_type, float v);
Edit: this is probably bad advice |
This works with Clang/Mingw: .h
.cpp
in the .cpp file with C+11. VS2010 fails with:
In spite of https://msdn.microsoft.com/en-us/library/hh567368.aspx saying that Extern Template are supported in VS2010. VS2012 fails with:
Both VS2010/VS2012 errors because imgui_widgets.cpp both sees the extern and the instantiation.. If you add an ifdef block to avoid the extern declaration when compiled from imgui_widgets.cpp it works, but we'd mess up with unity builds? VS2015 compiles/links OK. |
Found a solution: imgui_internal.h
imgui_widgets.cpp template<typename TYPE, typename SIGNEDTYPE>
IMGUI_API inline TYPE RoundScalarWithFormat(const char* format, ImGuiDataType data_type, TYPE v)
{
const char* fmt_start = ImParseFormatFindStart(format);
if (fmt_start[0] != '%' || fmt_start[1] == '%') // Don't apply if the value is not visible in the format string
return v;
char v_str[64];
ImFormatString(v_str, IM_ARRAYSIZE(v_str), fmt_start, v);
const char* p = v_str;
while (*p == ' ')
p++;
if (data_type == ImGuiDataType_Float || data_type == ImGuiDataType_Double)
v = (TYPE)ImAtof(p);
else
ImAtoi(p, (SIGNEDTYPE*)&v);
return v;
}
// instantiations
template
IMGUI_API float RoundScalarWithFormat<float, float>(const char* format, ImGuiDataType data_type, float v); This should work. When |
With your solution (only adding VS2010 is OK Clang
(from every calls) Similar stuff from Mingw
|
Oh C++ templates... Keep jiggling it, it's going to work eventually... :) |
Could you try to remove instantiation from header?
VS swallowed that. |
Ok so you actually don't need any Minimal example
|
That's equivalent to my initial problem. Works with VS 10/12/15, Clang warns.
Minus the Explicit template instantiation (which is not strictly required in this case since there is an instantiation with the same type, but I'll leave it, better be explicit) - this is what my first/current version is doing, but Clang warns with -Weverything. The warning happens on the calling site, so we can't even easily disable them. Perhaps I'm missing something but at this point I don't have an ideal solution. The worry if that we have a weak point here that would trigger warning/error on esoteric compilers. To clarify a few points: (Clang)
Explicit instantiation seems to require knowing of the implementation in the compilation unit:
Explicit specialization requires a second implementation of the function:
CURRENT SOLUTION I FOUND Using
The problem is that this block cannot be included in imgui_internal.h, as it disable the instantiation of the template in imgui_widgets.cpp, so the function instance ends up missing when linking. Now if I also explicitly instantiate in the .cpp file the Clang is happy but not VS:
Which can be worked out with some define/ifdef but that could break the possibility of using unity builds? TL;DR; For now I can offer to declare the templates in imgui_internal.h. |
…matT, SliderCalcRatioFromValueT. (#2036) Renamed RoundScalarWithFormat -> RoundScalarWithFormatT. Renamed SliderBehaviorCalcRatioFromValue -> SliderCalcRatioFromValueT
@bkaradzic As stated above I have pushed changes to declare the template function in imgui_internal.h I also renamed them: Renamed Let me know if that solves your issue! |
Hmm if the warning comes from clang's Honestly template function are just like macros that the compiler will expand and implement depending on what type is used. If the function body is available, the compiler will compile the function in every translation unit where it is used. But if only the declaration is available, then it will issue a standard function call and stuff will be resolved at linking time. It's just like any other function, which do not need an available definition to be called properly. My recommendation: don't mess with
|
I agree but as stated I cannot ignore it as the warning happens on the call site, so it's up to @bkaradzic there. |
@ocornut it builds with GCC, still waiting other compilers to finish: |
GCC 5 linker only complains about
|
@bkaradzic I'm not sure I understand why, sorry. Copying your |
Ok it's wasn't GCC 5 specific (it happens with GCC 7 too), just in release build. I had to do this for now... Until I figure out why it's getting stripped: |
Yeah that looks strange to me (looking at bkaradzic/bgfx@350e5d4#diff-3307f41d1c9cdf8632e3d8fdb3fa320f) Closing this now, looks like it's solvable in user land with those declaration. |
Also I wouldn't mind if you implement that range slider as part of ImGui. :) |
Will do, #76 is still open :) |
…my, NewLine, Separator, etc.) (#2036)
…indow() function. Should appear as a small diff if whitespaces changes are ignored. (#2036)
…moving around and applied to all files. (#2036)
…extedit.h, and stb_rect_pack.h to imstb_rectpack.h. (#1718, #2036) If you were conveniently using the imgui copy of those STB headers in your project, you will have to update your include paths. The reason for this change is to avoid conflicts for projects that may also be importing their own copy of the STB libraries. Note that imgui's copy of stb_textedit.h is modified.
Here's an idea I have and I would happily get your feedback on it.
Aiming to release 1.63 shortly (maybe this week).
Immediately after I will release 1.64 which would ONLY consist in a shuffling code around.
Some of the code in imgui.cpp would be split into imgui_widgets.cpp. As you can guess imgui_widgets.cpp will contains all the widgets specific code, whereas imgui.cpp would contains the core.
In my preliminary tests, about 30-35% of imgui.cpp would move to imgui_widgets.cpp.
(I expect that % to grow as down the line I'd like to remove stb_textedit.h and re-implement a custom version, as much of our InputText() issues are tricky to solve with the current code)
Behavior shouldn't be affected but moving code around will break local forks and make them conflicts when merged. Making a clear documented transition between 1.63->1.64 will facilitate the update for people with non-trivial fork (they will be advised to first update to 1.63, isolate their diffs, then update to 1.64 and reapply).
This would be a change analogous to 1.44 when I extracted imgui_draw.cpp out of imgui.cpp.
This would obviously break the build for project which have an hardcoded list of file instead of
imgui*.cpp
but the fix should be trivial.I will also perform various performance tests (e.g. how do non-static functions in a same compilation unit affect optimizations, if any? does anyone has info to share about that for msvc/clang/gcc?) and depending on the result will aim at including the most touched low-level function calls called from widgets into imgui_widgets.cpp if it makes a difference.
While doing that shuffle I will take the occasion to probably re-order many functions in both imgui.cpp and imgui_widgets.cpp, and section some areas with comments. (exact sectioning/ordering criteria unknown, but I'll aim to make it easier for people to locate code. e.g. maybe one of the criteria for imgui_widgets.cpp might be that the function ordering matches the ordering in imgui.h?)
The text was updated successfully, but these errors were encountered: