1
0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-06-25 22:18:30 +02:00
VVVVVV/desktop_version/src/UtilityClass.cpp

338 lines
5.5 KiB
C++
Raw Normal View History

#define HELP_DEFINITION
2020-01-01 21:29:24 +01:00
#include "UtilityClass.h"
#include <SDL.h>
2020-01-01 21:29:24 +01:00
#include <sstream>
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
#include "Maths.h"
static const char* GCChar(const SDL_GameControllerButton button)
2020-01-01 21:29:24 +01:00
{
switch (button)
2020-01-01 21:29:24 +01:00
{
case SDL_CONTROLLER_BUTTON_A:
2020-01-01 21:29:24 +01:00
return "A";
case SDL_CONTROLLER_BUTTON_B:
2020-01-01 21:29:24 +01:00
return "B";
case SDL_CONTROLLER_BUTTON_X:
2020-01-01 21:29:24 +01:00
return "X";
case SDL_CONTROLLER_BUTTON_Y:
2020-01-01 21:29:24 +01:00
return "Y";
case SDL_CONTROLLER_BUTTON_BACK:
2020-01-01 21:29:24 +01:00
return "BACK";
case SDL_CONTROLLER_BUTTON_GUIDE:
2020-01-01 21:29:24 +01:00
return "GUIDE";
case SDL_CONTROLLER_BUTTON_START:
2020-01-01 21:29:24 +01:00
return "START";
case SDL_CONTROLLER_BUTTON_LEFTSTICK:
2020-01-01 21:29:24 +01:00
return "L3";
case SDL_CONTROLLER_BUTTON_RIGHTSTICK:
2020-01-01 21:29:24 +01:00
return "R3";
case SDL_CONTROLLER_BUTTON_LEFTSHOULDER:
2020-01-01 21:29:24 +01:00
return "LB";
case SDL_CONTROLLER_BUTTON_RIGHTSHOULDER:
2020-01-01 21:29:24 +01:00
return "RB";
default:
SDL_assert(0 && "Unhandled button!");
return NULL;
2020-01-01 21:29:24 +01:00
}
}
int ss_toi(const std::string& str)
2020-01-01 21:29:24 +01:00
{
int retval = 0;
bool negative = false;
static const int radix = 10;
for (size_t i = 0; i < str.size(); ++i)
{
const char chr = str[i];
if (i == 0 && chr == '-')
{
negative = true;
continue;
}
if (SDL_isdigit(chr))
{
retval *= radix;
retval += chr - '0';
}
else
{
break;
}
}
if (negative)
{
return -retval;
}
return retval;
2020-01-01 21:29:24 +01:00
}
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
bool next_split(
size_t* start,
size_t* len,
const char* str,
const char delim
) {
size_t idx = 0;
*len = 0;
if (str[idx] == '\0')
2020-01-01 21:29:24 +01:00
{
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
return false;
}
while (true)
{
if (str[idx] == delim)
{
*start += 1;
return true;
}
else if (str[idx] == '\0')
{
return true;
}
idx += 1;
*start += 1;
*len += 1;
2020-01-01 21:29:24 +01:00
}
}
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
bool next_split_s(
char buffer[],
const size_t buffer_size,
size_t* start,
const char* str,
const char delim
) {
size_t len = 0;
const size_t prev_start = *start;
const bool retval = next_split(start, &len, &str[*start], delim);
if (retval)
{
/* Using SDL_strlcpy() here results in calling SDL_strlen() */
/* on the whole string, which results in a visible freeze */
/* if it's a very large string */
const size_t length = VVV_min(buffer_size - 1, len);
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
SDL_memcpy(buffer, &str[prev_start], length);
buffer[length] = '\0';
}
return retval;
2020-01-01 21:29:24 +01:00
}
UtilityClass::UtilityClass(void) :
2020-01-01 21:29:24 +01:00
glow(0),
glowdir(0)
{
for (size_t i = 0; i < SDL_arraysize(splitseconds); i++)
2020-01-01 21:29:24 +01:00
{
splitseconds[i] = (i * 100) / 30;
2020-01-01 21:29:24 +01:00
}
slowsine = 0;
}
std::string UtilityClass::String( int _v )
{
std::ostringstream os;
os << _v;
return(os.str());
}
int UtilityClass::Int(const char* str, int fallback /*= 0*/)
{
if (!is_number(str))
{
return fallback;
}
return (int) SDL_strtol(str, NULL, 0);
}
std::string UtilityClass::GCString(const std::vector<SDL_GameControllerButton>& buttons)
2020-01-01 21:29:24 +01:00
{
std::string retval = "";
for (size_t i = 0; i < buttons.size(); i += 1)
{
retval += GCChar(buttons[i]);
if ((i + 1) < buttons.size())
{
retval += ",";
}
}
return retval;
}
std::string UtilityClass::twodigits( int t )
{
if (t < 10)
{
return "0" + String(t);
}
if (t >= 100)
{
return "??";
}
return String(t);
}
std::string UtilityClass::timestring( int t )
{
//given a time t in frames, return a time in seconds
std::string tempstring = "";
int temp = (t - (t % 30)) / 30;
2020-01-01 21:29:24 +01:00
if (temp < 60) //less than one minute
{
t = t % 30;
tempstring = String(temp) + ":" + twodigits(splitseconds[t]);
}
else
{
int temp2 = (temp - (temp % 60)) / 60;
2020-01-01 21:29:24 +01:00
temp = temp % 60;
t = t % 30;
tempstring = String(temp2) + ":" + twodigits(temp) + ":" + twodigits(splitseconds[t]);
}
return tempstring;
}
std::string UtilityClass::number( int _t )
{
static const std::string ones_place[] = {"One", "Two", "Three", "Four", "Five", "Six", "Seven", "Eight", "Nine"};
static const std::string tens_place[] = {"Ten", "Twenty", "Thirty", "Forty", "Fifty", "Sixty", "Seventy", "Eighty", "Ninety"};
static const std::string teens[] = {"Eleven", "Twelve", "Thirteen", "Fourteen", "Fifteen", "Sixteen", "Seventeen", "Eighteen", "Nineteen"};
if (_t < 0)
{
return "???";
}
else if (_t > 100)
{
return "Lots";
}
else if (_t == 0)
{
return "Zero";
}
else if (_t == 100)
{
return "One Hundred";
}
else if (_t >= 1 && _t <= 9)
{
return ones_place[_t-1];
}
else if (_t >= 11 && _t <= 19)
{
return teens[_t-11];
}
else if (_t % 10 == 0)
{
return tens_place[(_t/10)-1];
}
else
{
return tens_place[(_t/10)-1] + " " + ones_place[(_t%10)-1];
}
2020-01-01 21:29:24 +01:00
}
bool UtilityClass::intersects( SDL_Rect A, SDL_Rect B )
{
return (SDL_HasIntersection(&A, &B) == SDL_TRUE);
2020-01-01 21:29:24 +01:00
}
void UtilityClass::updateglow(void)
2020-01-01 21:29:24 +01:00
{
slowsine++;
if (slowsine >= 64) slowsine = 0;
if (glowdir == 0) {
glow+=2;
if (glow >= 62) glowdir = 1;
}else {
glow-=2;
if (glow < 2) glowdir = 0;
}
}
bool is_number(const char* str)
{
if (!SDL_isdigit(str[0]) && str[0] != '-')
{
return false;
}
if (str[0] == '-' && str[1] == '\0')
{
return false;
}
for (size_t i = 1; str[i] != '\0'; ++i)
{
if (!SDL_isdigit(str[i]))
{
return false;
}
}
return true;
}
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
static bool VVV_isxdigit(const unsigned char digit)
{
return (digit >= 'a' && digit <= 'f')
|| (digit >= 'A' && digit <= 'F')
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
|| SDL_isdigit(digit);
}
bool is_positive_num(const char* str, const bool hex)
{
if (str[0] == '\0')
{
return false;
}
for (size_t i = 0; str[i] != '\0'; ++i)
{
2020-06-16 02:31:54 +02:00
if (hex)
{
if (!VVV_isxdigit(str[i]))
2020-06-16 02:31:54 +02:00
{
return false;
}
}
else
{
if (!SDL_isdigit(str[i]))
2020-06-16 02:31:54 +02:00
{
return false;
}
}
}
return true;
}
bool endsWith(const std::string& str, const std::string& suffix)
{
if (str.size() < suffix.size())
{
return false;
}
return str.compare(
str.size() - suffix.size(),
suffix.size(),
suffix
) == 0;
}