Я, вероятно, получу отказ за этот ответ, потому что это не совсем ответ, но есть законные причины, по которым STL можно было бы избежать. При работе в фиксированном окружении, где память или скорость являются премиальными, иногда трудно сказать, что происходит под капотом с STL. Да, вы можете написать свои собственные распределители памяти, и да, скорость, как правило, не является проблемой, но есть различия между реализациями STL на разных платформах, и эти различия могут быть тонкими и потенциально ошибочными. Память, пожалуй, самая большая проблема, когда я думаю об ее использовании. Я тоже работаю в игровой компании, и уже давно. Память драгоценна, и то, как мы ее используем, требует жесткого контроля. Если вы не пошли по этому пути, эта концепция может не иметь смысла, но это правда. Мы допускаем использование STL в инструментах (вне кода игры), но это запрещено внутри самой игры. Еще одна проблема связана с размером кода. Я немного не уверен, сколько STL может внести в размер исполняемого файла, но мы видели заметное увеличение размера кода при использовании STL. Даже если ваш исполняемый файл «всего» на 2М больше, это на 2М меньше оперативной памяти для чего-то другого для вашей игры.
STL это хорошо, конечно. Но этим могут злоупотреблять программисты, которые не знают, что делают. Это не преднамеренно, но может преподнести неприятные сюрпризы, когда вы не хотите их видеть (опять же, переполнение памяти и проблемы с производительностью)
Я уверен, что вы близки к вашему решению.
for ( i = 0; i < lastIndex; i++ ) {
if ( !strcmp(®isteredNames[i], name ) {
break; // name was found
}
}
if ( i == lastIndex ) {
// name was not found in the registeredNames list
registeredNames[lastIndex++] = strdup(name);
}
Возможно, вы не захотите использовать strdup. Это просто пример того, как хранить имя с учетом вашего примера. Возможно, вы захотите убедиться, что вы либо не хотите выделять пространство для нового имени самостоятельно, либо используете какую-то другую конструкцию памяти, которая уже может быть доступна в вашем приложении.
И, пожалуйста, не пишите строковый класс. Я рассматривал строковые классы как, возможно, худший пример того, как не перестраивать базовую конструкцию C в C ++. Да, класс string может скрыть от вас множество изящных подробностей, но его шаблоны использования памяти ужасны, и они плохо вписываются в консольную среду (например, ps3 или 360 и т. Д.). Около 8 лет назад мы сделали то же самое. 200000+ выделений памяти, прежде чем мы попадем в главное меню. Память была ужасно фрагментирована, и мы не смогли заставить остальную часть игры вписаться в фиксированную среду. Мы закончили с этим.
Дизайн класса отлично подходит для некоторых вещей, но это не одна из них. Это мнение, но оно основано на опыте реального мира.