Пришло время избавиться от структурки entvars_t. Ну это которая pev->
Эта зараза пронизывает всю серверную часть движка, поэтому процесс будет непростым.
XaeroX как вариант. Хотя что-то мне подсказывает, что Дядя Миша наврядли что-то использует из STL.
Добавлено 10-08-2019 в 17:53:
thambs string_t-то? Ну, в первую очередь, это рудимент от кваки, где виртуальная машина работала со строками довольно бедно и фактически лишь давала идентифактор. Может я тут где-то ошибаюсь.
Valve запихнули проблему ещё дальше, сделав из string_t просто разницу указателей. В итоге литералы у нас идут в MAKE_STRING, а генерируемые строки в ALLOC_STRING.
Навскидку: динамическая реаллокация, оверхед по памяти, лёгкость пессимизации при замене string_t, который привычно передаётся по значению, потенциальная непредсказуемость поведения из-за мути в стандарте (SOO, COW).
Добавлено 10-08-2019 в 22:00:
Цитата:
a1batross писал: Ну, в первую очередь, это рудимент от кваки
Один дурак сказал, и все начали повторять про рудимент...
Цитата:
a1batross писал: В итоге литералы у нас идут в MAKE_STRING, а генерируемые строки в ALLOC_STRING.
Тут пожалуй единственная проблема - неудачное название MAKE_STRING, оно нелогичное и запутывающее.
Кстати, ку3шный аллокатор строк умеет детектировать самые популярные литералы, например, и не аллокать для них память.
XaeroX ну черт его знает. В условиях отсутствия ВМ я не вижу смысла так работать со строками.
Я на самом деле и не против. Просто string_t должен быть явно помечен как платформозависимый и вообще не давать возможности разработчику записывать его в файл(о_О), передавать по сети(что только в воспаленное сознание не придёт), сравнивать его численное значение с другими, помимо равенства наверное, да и вообще не иметь доступа к нему именно как идентификатору.
Именно он был и есть самой большой проблемой при порте на 64-битные указатели.
a1batross писал: В условиях отсутствия ВМ я не вижу смысла так работать со строками.
Вообще-то стрингтабля идеально для игровых движков подходит, независимо от наличия в них какой-то пользовательской виртуальной машины. Потому что мы имеем дело с кучей константных строк, которые очень часто сравниваются друг с другом и имеют множество дубликатов. Т.е. идея поместить их в единый уникальный массив напрашивается сама-собой. Энтити постоянно запрашивают поиск по таргетнейму, класснейму, да мало ли почему. И всегда выгоднее сравнивать идентификатор строки, чем каждый раз запускать strcmp. И соответственно этот же массив передаётся на клиент, в том же порядке, чтобы строки были доступны и там. Аналогично, когда мы передаём пользовательскую мессагу, нам необязательно каждый раз слать настоящую строку - достаточно послать её идентификатор, а движок автоматически синхронизирует строки на клиентской части (если строка новая и уникальная).
Потихоньку переношу из entvars_t в CBaseEntity. Их там более ста штук, вот такая тупая работа и отымает чёртову уйму времени. Попутно жы еще пишу разные новые механизмы, типа парсера новых кейвалуев, поиска по строкам в DATAMAP и прочего. Ну и стараюсь убрать эту порочную практику, когда для новых энтить вовсю использовались переменные из entvars_t подходящие по типу, чтобы не возится с описанием IMPLEMENT_SAVERESTORE и прочей гадости. Помоему это Лаури первым придумал, этот фантазёр.