You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A single copy of the original (for inserting '\0'-s), with "home-grown" index arrays (with a templated index type, 1-byte by default, just for the vibe :) ), even templated, with a fixed-size allocator (maybe even default?)...
(Obviously, with no string vector/map "all" results etc. But the rest should be fine. People could did it with C... ;) )
malloc, memcpy, perhaps memcmp still needed, so then string.h is already inevitable -- but that's still nowhere near the entire tanker ship of the STL (with tiny little single parts of it like <compare> secretly #including 53(! :-o ) others, at 500K total (4x the size of an entire UPXed gmake.exe :) ) with MSVC)...
Should be optimized for min. allocations and RAM usage in general. -- Albeit, if there's a heap anyway, allocophobia at args processing time is kinda funny... (Fragmentation's still a thing, though.)
And since option lookups are also used internally, in the loop, that should be kinda fast, too.
The text was updated successfully, but these errors were encountered:
A single copy of the original (for inserting '\0'-s), with "home-grown" index arrays (with a templated index type, 1-byte by default, just for the vibe :) ), even templated, with a fixed-size allocator (maybe even default?)...
(Obviously, with no string vector/map "all" results etc. But the rest should be fine. People could did it with C... ;) )
malloc
,memcpy
, perhapsmemcmp
still needed, so thenstring.h
is already inevitable -- but that's still nowhere near the entire tanker ship of the STL (with tiny little single parts of it like<compare>
secretly #including 53(! :-o ) others, at 500K total (4x the size of an entire UPXed gmake.exe :) ) with MSVC)...The text was updated successfully, but these errors were encountered: