Remove support for IMPLOT_INSTANTIATE_ALL_NUMERIC_TYPES #402
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I do agree, and this PR removes them.
That is an interesting question! I made a quick study, and my findings are:
float
anddouble
can be as high as 20% (and the result do depend on the arch and compiler)double
andlong double
have the same size (8 bytes),long double
is 20% to 30% slower (except on apple M1 processor)sizeof(long double) = 16
vssizeof(double) = 8
, long double can be 10 to 30 times slower (this depends on the compiler and platform)There is perhaps a solution, but I suspect it would be very likely be "platform / compiler / arch / type" specific and maybe difficult to maintain.
In the case of unsigned integers, a possible solution would be to:
u64 value = 0;
, then fill the right portion ofvalue
's bytes with the bytes from the arrayHowever, based on my observations, the memory layout for a 64 bits int (on a Mac M1) is a mix of:
And I suspect that this is very much platform dependent.
Example, if I set
int64_t v64 = 0x123456789ABCDE00;
and examine the memory at &v64, it looks like this on my Mac: