[Вопрос] Пак вопросов. [Архив] - Pro Pawn - Портал о PAWN-скриптинге

Просмотр полной версии : [Вопрос] Пак вопросов.

Betta

08.09.2017, 13:02

Приветствую. Вопросы будут из разряда "что лучше".

1. Создавать итераторы для фракций, работ, каких либо функций, где могут принимать участие не один игрок или достаточно будет создать один итератор для всех игроков на сервере. Да, когда будет онлайн 100 человек - и второй вариант сгодится. А если онлайн 1000? Ведь во фракции может быть 3 человека, еще 3 на работе, еще 3 на гонках и так далее. Но я плохо разбираюсь в потреблении памяти, значимости кучи таких переменных и т. д. Если создавать итераторы, то лично у меня в моде их будет от 50/100. Как лучше и почему?

2. Стринги внутри функций. К пример в командах, в каких либо ячейках DialogResponse, отдельных пабликах. Видел как то статью, где описывалось, что стринги внутри таких функций после использования удаляются, или память очищается - не помню. Но в другой статье я видел, что в павно нельзя выгружать память и когда мы создаем стринг, то после его использования он остается в памяти навсегда. Так собственно вопрос. Может создать один глобальный стринг для таких операций? Либо же в этих местах, к которым идет частое обращение прописать static string вместо new, чтобы не создавать его а использовать как в примере с глобальным, но лишь в определенном месте? Как лучше и почему? И желательно расписать или скинуть ссылки на информацию по данным вопросам.

3. Есть ли разница в проверках:
if(!(0 << level << 10))
и
if(level < 0 || level > 10)
в чем их отличия, какую лучше использовать или есть ли вообще хоть какая-то разница?

4. По поводу стоков. К примеру у меня есть диалог с какой-либо информацией, довольно большой. Возможно занимает 600 символов.
А вызываю я этот диалог допустим в 10-ти различных местах. Как мне будет лучше, сделать сток с данным диалогом и вызывать его, либо прописать во всех 10-ти местах этот диалог? Форматирование я в этом примере не использую. Как и почему?

5. Вопрос о MySQL. Я могу создать сток, в который буду передавать название столбца данных в базе и то, что в него нужно записать при каждом изменении. Либо могу сохранять раз в час весь сервер. Имеется какая либо нагрузка при частых запросах, если они не крупные? То есть затрагивается один столбец конкретного аккаунта, к примеру. Если я буду пользоваться первым способом - будет ли разница в том, чтобы вызывать данный сток раза по 4 при продаже дома (к примеру) или лучше делать эти запросы полностью в том-же месте, где находится функция продажи этого дома. Ведь там уже и готовый стринг, который отображает информацию игрокам. И запросов к БД будет меньше. Или это не имеет никого значения? И обращение к стоку не занимает значительного времени?

6. По поводу Enum. Если мне нужно для различных целей создавать переменные, которые я не хочу запихивать в данные аккаунта. Передача всё того-же дома, транспорта, какие либо еще действия - мне лучше создавать под них enum с пунктами или же несколько переменных типа new [MAX_PLAYERS]? Читал когда-то, что к enum обращение выполняется дольше, чем к обычной переменной - так ли это? Так-же. Существует ли какое либо ограничение на разумное использование enum'a? То есть я могу записывать туда хоть 300 пунктов (name, level, cash, и т. д.) или можно всего 50 - к примеру? Будет ли разница в работе при использовании 300 пунктов и 50? Если да - какая?

7. Вопрос схож с 6, но про static const. К примеру у меня есть static const Float:Race_Vehicle_Pos[RACE_MAX_PLAYERS][8][4] - куда я записываю 40 столбцов, по 8 пунктов, по 4 координаты. Выглядит это так:

{{0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}},
{{0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}},

Вопрос исключительно по работоспособности данной реализации. Есть ли какие либо минусы? Возможно скорость, потребление памяти или что либо еще. По поводу читабельности кода - меня это не смущает.

8. Стример и объекты. Насколько я знаю, стример создает объекты там, где есть игроки. За счёт этого обходит ограничение. Но тут что-то не складывается. Существует проект аризона, на котором используются примерно 40 тысяч объектов, хотя в стримере ограничение 10 тысяч. На форумах частые вопросы касательно того, что из-за большого количества объектов не прогружаются какие-либо места. Почему такой проблемы нет у аризоны? Стример у них не особенный, не модифицированный.

Пока хватит)

DeimoS

08.09.2017, 14:14

1. Создавать итераторы для фракций, работ, каких либо функций, где могут принимать участие не один игрок или достаточно будет создать один итератор для всех игроков на сервере. Да, когда будет онлайн 100 человек - и второй вариант сгодится. А если онлайн 1000? Ведь во фракции может быть 3 человека, еще 3 на работе, еще 3 на гонках и так далее. Но я плохо разбираюсь в потреблении памяти, значимости кучи таких переменных и т. д. Если создавать итераторы, то лично у меня в моде их будет от 50/100. Как лучше и почему?

Однозначно итераторы. Памяти достаточно много, в отличии от процессорного времени.

2. Стринги внутри функций. К пример в командах, в каких либо ячейках DialogResponse, отдельных пабликах. Видел как то статью, где описывалось, что стринги внутри таких функций после использования удаляются, или память очищается - не помню. Но в другой статье я видел, что в павно нельзя выгружать память и когда мы создаем стринг, то после его использования он остается в памяти навсегда. Так собственно вопрос. Может создать один глобальный стринг для таких операций? Либо же в этих местах, к которым идет частое обращение прописать static string вместо new, чтобы не создавать его а использовать как в примере с глобальным, но лишь в определенном месте? Как лучше и почему? И желательно расписать или скинуть ссылки на информацию по данным вопросам.

Когда ты создаёшь локальные переменные, ты работаешь с УЖЕ ВЫДЕЛЕННОЙ памятью - стэком. Этими самыми переменными ты лишь "помечаешь" определённые куски стэка, дабы далее иже обращаться именно к ним. Никакой новой памяти ты не выделяешь, если создаёшь локальные переменные.
Собственно, когда блок кода, в котором была создана переменная, обрабатывается, все данные из стэка, которые относились к этому блоку, удаляются, дабы на их месте можно было записать другие данные.
Всё это можно в официальной документации прочесть. А конкретно информацию о стэке и сегменте данных. В Pawn принципы работы этих блоков памяти немного извращены в угоду упрощения работы с той самой памятью (для этого Pawn и создавался изначально), так что если решишь почитать информацию просто из гугла, то можешь наткнуться на не совсем достоверную информацию, так как она будет относиться к какому-нибудь С++. Хотя и общего будет много.
В общем, лучше официальную документацию изучи и уже гугли только конкретные определения, которые тебе будут непонятны.

3. Есть ли разница в проверках:
if(!(0 << level << 10))
и
if(level < 0 || level > 10)
в чем их отличия, какую лучше использовать или есть ли вообще хоть какая-то разница?

Ты, видимо, имел ввиду

if(!(0 < level < 10))
А не то, что у тебя написано, ибо в твоём первом варианте уже указан побитовый сдвиг влево (https://ziggi.org/pawn-pobitovye-operatory/), а не оператор сравнения.

Теперь касаемо вопроса. Разницы никакой нет. Это же чистейшая математика начальных классов. Просто подставь вместо "level" любое число (например, 5) и сразу код станет понятнее:

if(5 < 0 || 5 > 10)//Если 5 меньше нуля или 5 больше 10...
и

if(!(0 < 5 < 10))//Если 5 НЕ больше нуля и НЕ меньше 10...
Собственно, как по комментарию видно, второй пример является точной копией первого, просто условие поставлено от обратного

4. По поводу стоков. К примеру у меня есть диалог с какой-либо информацией, довольно большой. Возможно занимает 600 символов.
А вызываю я этот диалог допустим в 10-ти различных местах. Как мне будет лучше, сделать сток с данным диалогом и вызывать его, либо прописать во всех 10-ти местах этот диалог? Форматирование я в этом примере не использую. Как и почему?

Естественно создать функцию и уже её вызывать в разных местах.
Тут как бы чисто логически можно понять, что:
1) Гораздо проще прописать вызов функции, чем каждый раз код диалога.
2) В случае, если ты решишь изменить содержимое диалогов, тебе не придётся вручную выискивать каждый из них и менять, а достаточно лишь найти функцию и произвести в ней изменения. Так же и в случае, если ты решишь добавить код к диалогу.

Это относится не только к диалогам с большим количеством символов, но и вообще к любым диалогам, которые вызываются в нескольких местах с одним и тем же текстом.

Ко всему этому так же относится и экономия памяти, ибо если ты создашь 10 одинаковых диалогов, текст из всех 10 диалогов займёт своё место в памяти, хоть он и будет совершенно одинаков (Pawn, увы, не способен оптимизировать подобные вещи, поэтому нужно делать это самостоятельно, хотя это и не критично).

5. Вопрос о MySQL. Я могу создать сток, в который буду передавать название столбца данных в базе и то, что в него нужно записать при каждом изменении. Либо могу сохранять раз в час весь сервер. Имеется какая либо нагрузка при частых запросах, если они не крупные? То есть затрагивается один столбец конкретного аккаунта, к примеру. Если я буду пользоваться первым способом - будет ли разница в том, чтобы вызывать данный сток раза по 4 при продаже дома (к примеру) или лучше делать эти запросы полностью в том-же месте, где находится функция продажи этого дома. Ведь там уже и готовый стринг, который отображает информацию игрокам. И запросов к БД будет меньше. Или это не имеет никого значения? И обращение к стоку не занимает значительного времени?

Естественно нагрузка будет. Что в первом, что во втором случае. Да даже от того, что ты запустил сервер, уже будет нагрузка. Мой тебе совет, прекращай искать проблему там, где её ещё нет и не бойся писать код лишь от того, что он даст нагрузку на сервер. Сервер для того и создан, чтоб держать на себе нагрузку от твоего кода. Но это так, лирическое отступление.

Касаемо твоего вопроса. Вариант, в котором ты сохраняешь конкретный столбец (а там, где нужно сохранять несколько столбцов, собирать их в один запрос), естественно будет лучше, нежели ты будешь каждый раз собирать огромный запрос и отправлять его.

Для MySQL не будет особой разницы ни от первого варианта, ни от второго, ибо она создана для того, чтоб работать с большими объёмами информации в короткие сроки (нужно лишь правильно работать с таблицами, но это уже к вопросу не относится).
К сведению: MySQL, например, способна в одном запросе работать одновременно с 61-ой таблицей :) Хотя это данные, вроде, для старой версии и сейчас горизонты, скорее всего, расширены ещё больше.

В общем, лучше обновлять лишь те данные, которые действительно нужно обновить. И, при этом, не лениться вручную собирать запросы там, где обновляется несколько столбцов сразу, а не обновлять каждый столбец отдельным запросом.

6. По поводу Enum. Если мне нужно для различных целей создавать переменные, которые я не хочу запихивать в данные аккаунта. Передача всё того-же дома, транспорта, какие либо еще действия - мне лучше создавать под них enum с пунктами или же несколько переменных типа new [MAX_PLAYERS]?

Сугубо как тебе удобнее или как лучше для реализации твоей идеи. Я же тебе уже объяснял, что прописывая массив с использованием enum, на выходе получается всё тот же массив и не более того.

Читал когда-то, что к enum обращение выполняется дольше, чем к обычной переменной - так ли это?

Да. Как и обращение к массиву выполняется дольше, нежели к обычной переменной. Но разница во времени там ровна считанным долям миллисекунд и она нивелируется теми удобствами, которые даёт enum/массив.
А ту мысль, благодаря которой ты придумал этот вопрос, гони прочь. Китайский код (http://lurkmore.to/%D0%98%D0%BD%D0%B4%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9_%D0%BA%D0%BE%D0%B4#K.D0.B8.D1.82.D0.B0.D0.B9.D1.81.D0.BA.D0.B8.D0.B9_.D0.BA.D0.BE.D0.B4) до добра не доводит.

Так-же. Существует ли какое либо ограничение на разумное использование enum'a? То есть я могу записывать туда хоть 300 пунктов (name, level, cash, и т. д.) или можно всего 50 - к примеру? Будет ли разница в работе при использовании 300 пунктов и 50? Если да - какая?

Нет, ограничений нет. Только и пихать в один enum всё, что можно, тоже не стоит, как минимум, по соображениям читаемости кода.

7. Вопрос схож с 6, но про static const. К примеру у меня есть static const Float:Race_Vehicle_Pos[RACE_MAX_PLAYERS][8][4] - куда я записываю 40 столбцов, по 8 пунктов, по 4 координаты. Выглядит это так:

{{0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}},
{{0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}, {0.0,0.0,0.0,0.0}},

Вопрос исключительно по работоспособности данной реализации. Есть ли какие либо минусы? Возможно скорость, потребление памяти или что
либо еще. По поводу читабельности кода - меня это не смущает.

Если минусы и есть, то они точно не стоят того, чтоб ради них переписывать код, ибо ты больше потеряешь времени, чем даже в перспективе его выиграешь за счёт изменений.
Но вообще вот тут (http://pro-pawn.ru/showthread.php?12821) частично описаны "минусы" массивов. Хотя в твоём случае массив нужен

8. Стример и объекты. Насколько я знаю, стример создает объекты там, где есть игроки. За счёт этого обходит ограничение. Но тут что-то не складывается. Существует проект аризона, на котором используются примерно 40 тысяч объектов, хотя в стримере ограничение 10 тысяч. На форумах частые вопросы касательно того, что из-за большого количества объектов не прогружаются какие-либо места. Почему такой проблемы нет у аризоны? Стример у них не особенный, не модифицированный.

Откуда вы вообще взяли ограничение в 10 тысяч объектов? У стримера есть единственное ограничение - количество объектов в зоне стрима игрока, которое, в новых версиях, обычно равно 500-ам объектов, а максимально можно увеличить до лимитов сампа - 1000 объектов (с учётом того, что нет CreateObject).
Больше никаких лимитов на количество объектов нет. Хоть миллион создай - без разницы. Главное, чтоб вокруг игрока их было не больше лимита.

Вот простой пример:

new objectid;

for(new i; i < 1_000_000; i++)
{
objectid = CreateDynamicObject(2587, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0);
switch(i)
{
case 0, 100, 1_000, 10_000, 100_000, 500_000, 999_999:
printf("%d", objectid);
}
}
printf("Всего объектов создано: %d", CountDynamicObjects());

Максимум, что может страдать при большом количестве объектов (особенно если ещё они разделены на виртуальные миры/интерьеры) - скорость их прогрузки (не исчезновение объектов вдали, как это бывает у всяких уникумов, что лепят кучу объектов рядом, а именно время прогрузки отдельного объекта). Но и тут существенных лагов добиться трудно, если специально не постараться.

Betta

08.09.2017, 14:28

DeimoS

08.09.2017, 14:38

По всем ответам, кроме последнего вопросов нет. Большое спасибо.
А по стримеру. Очень на многих порталах пишут про то, что в стримере ограничение на объекты в 10000 тысяч. Так-же в модах с пабликов можно встретить дефайны вроде MAX_OBJECT 10000 и проверку на создание объекта, который если превышает 10-чный то не создается. Отсюда и появился вопрос. Хотя это тоже не вопрос, скорее разъяснение. Спасибо!

На форумах так же пишут, что функции, созданные через stock, работают быстрее функций, созданных через public, а так же, что "return true" лучше "return 1". Только пишут это, в большинстве своём, люди, которые либо это сами где-то услышали, либо кто это придумал то ли от глупости своей, то ли забавы ради. Сообщество в SA-MP на 100% состоит из самоучек, большинство из которых, в лучшем случае, лишь раз открывали официальную документацию, а всё остальное изучали по секретным архивам КГБ, благодаря чему и всплывают подобные "невероятные" факты.
Любую информацию, которую ты получаешь от других людей (всю?), следует перепроверять либо гуглежом, либо личным опытом. Тем более если речь идёт о сампе.

А ограничение, вполне возможно, было в каких-то старых версиях или в каком-то другом стримере/форке стримера от инкогнито. Или же подразумевается, что тебе просто физически хватит ограничения в 10000 объектов, дабы обставить всю карту. Но для стримера все твои объекты являются лишь набором циферок, что записаны в его памяти, которые он в нужный момент выгружает по особым алгоритмам и передаёт в функцию CreatePlayerObject. Тут если и будет ограничение, то только со стороны твоего хостинга, в виде ограничения памяти.

Betta

08.09.2017, 14:55

На форумах так же пишут, что функции, созданные через stock, работают быстрее функций, созданных через public, а так же, что "return true" лучше "return 1". Только пишут это, в большинстве своём, люди, которые либо это сами где-то услышали, либо кто это придумал то ли от глупости своей, то ли забавы ради. Сообщество в SA-MP на 100% состоит из самоучек, большинство из которых, в лучшем случае, лишь раз открывали официальную документацию, а всё остальное изучали по секретным архивам КГБ, благодаря чему и всплывают подобные "невероятные" факты.
Любую информацию, которую ты получаешь от других людей (всю?), следует перепроверять либо гуглежом, либо личным опытом. Тем более если речь идёт о сампе.

Я это понимаю, потому и задаюсь половиной вопросов. А вторая половина возникает как предосторожность по мере реализации чего либо.

- - - Добавлено - - -

Появился еще вопрос. Касательно китайского кода. При запуске сервере я обнуляю все переменные игроков - я могу этого не делать дописав к объявлению переменной = {-1}; чтобы получилось id_[MAX_PLAYERS] = {-1};? И еще. Это работает с отдельными столбцами в enum?

DeimoS

08.09.2017, 15:21

я могу этого не делать дописав к объявлению переменной = {-1}; чтобы получилось id_[MAX_PLAYERS] = {-1};?

Нет, так ты обнулишь лишь нулевую ячейку. Для обнуления всего массива нужно указать, что заполнить нужно весь массив. Делается это так:

new id_[MAX_PLAYERS] = {-1, ...};

Но учти, что если тебе нужно присваивать значение "-1" для каждого входящего игрока, то после выхода одного из игроков, переменной опять придётся присваивать нужное значение.

Это работает с отдельными столбцами в enum?

enum можно заполнять так:

#define MAX_PLAYER_PASSWORD 20
enum e_PLAYER_INFO
{
account_id,
player_name[MAX_PLAYER_NAME+1],
player_password[MAX_PLAYER_PASSWORD+1],
Float:player_pos_x,
Float:player_pos_y,
Float:player_pos_z,
player_clothes[5]
};
new pInfo[MAX_PLAYERS][e_PLAYER_INFO];//Основной массив

new NULL_pInfo[e_PLAYER_INFO] = //Дополнительный массив, который будет хранить значения по умолчанию
{
0, // account_id
"\0", // player_name
"\0", // password
0.0, // Float:player_pos_x
0.0, // Float:player_pos_y
0.0, // Float:player_pos_z
{0, 0, 0, 0, 0} // player_clothes
};

И когда тебе нужно присвоить всем данным конкретного игрока значения по умолчанию, просто прописываешь такой код:

pInfo[playerid] = NULL_pInfo;

Betta

08.09.2017, 15:24

Нет, так ты обнулишь лишь нулевую ячейку. Для обнуления всего массива нужно указать, что заполнить нужно весь массив. Делается это так:

new id_[MAX_PLAYERS] = {-1, ...};

Но учти, что если тебе нужно присваивать значение "-1" для каждого входящего игрока, то после выхода одного из игроков, переменной опять придётся присваивать нужное значение.

enum можно заполнять так:

#define MAX_PLAYER_PASSWORD 20
enum e_PLAYER_INFO
{
account_id,
player_name[MAX_PLAYER_NAME+1],
player_password[MAX_PLAYER_PASSWORD+1],
Float:player_pos_x,
Float:player_pos_y,
Float:player_pos_z,
player_clothes[5]
};
new pInfo[MAX_PLAYERS][e_PLAYER_INFO];//Основной массив

new NULL_pInfo[e_PLAYER_INFO] = //Дополнительный массив, который будет хранить значения по умолчанию
{
0, // account_id
"\0", // player_name
"\0", // password
0.0, // Float:player_pos_x
0.0, // Float:player_pos_y
0.0, // Float:player_pos_z
{0, 0, 0, 0, 0} // player_clothes
};

И когда тебе нужно присвоить всем данным конкретного игрока значения по умолчанию, просто прописываешь такой код:

pInfo[playerid] = NULL_pInfo;

Весьма удобный и очень полезный способ. Очередное, но не сколь не меньшее по значимости спасибо.

- - - Добавлено - - -

Но учти, что если тебе нужно присваивать значение "-1" для каждого входящего игрока, то после выхода одного из игроков, переменной опять придётся присваивать нужное значение.

Немного проясню. То есть, если массив в 20 ячеек, и зашел / вышел игрок под id 10, то 10 ячейка не будет -1, но все остальные останутся при своём и мне нужно будет в onplayerdisconnect именно эту ячейку обновить?

Batya_Montes

08.09.2017, 16:24

зачем так сложно ?
1 раз в коннект игрока добавить

static const ResetEnums[enum_name];
NewName[p_id] = ResetEnums;
таким образом весь массив у тебя очистится, ибо переменная автоматически инициализируется и заполнится 0

DeimoS

08.09.2017, 16:33

Немного проясню. То есть, если массив в 20 ячеек, и зашел / вышел игрок под id 10, то 10 ячейка не будет -1, но все остальные останутся при своём и мне нужно будет в onplayerdisconnect именно эту ячейку обновить?

Ну если в твоей системе это важно - да, нужно обновить. Вообще проще это делать, например, при авторизации, если до авторизации эта переменная никак не используется (если используется, то при входе на сервер).
Переменные никак не привязаны к игрокам на стороне кода, если ты сам их не привяжешь подобными обнулениями и прочими проверками.

зачем так сложно ?
1 раз в коннект игрока добавить

static const ResetEnums[enum_name];
NewName[p_id] = ResetEnums;
таким образом весь массив у тебя очистится, ибо переменная автоматически инициализируется и заполнится 0

В чём заключается сложность? В том, что я объяснил как указывать значения по умолчанию, а нули указал лишь в качестве примера? Ведь не всегда ячейку нужно приравнивать именно к нулю.

Batya_Montes

08.09.2017, 16:45

но ведь проще очистить все на 0, а дальше отдельные участки не нулями, чем каждое значение

Betta

08.09.2017, 17:02

но ведь проще очистить все на 0, а дальше отдельные участки не нулями, чем каждое значение

Не думаю, что для машины это имеет значение.

DeimoS

08.09.2017, 17:03

но ведь проще очистить все на 0, а дальше отдельные участки не нулями, чем каждое значение

В чём проще? Для кого?
Проще для сервера? Нет. Ему сначала нужно всё нулями заполнить, а потом ещё раз заполнить уже нужными значениями.
Проще для скриптера? Тоже не вижу никаких преимуществ, ибо придётся ещё больше символов печатать, прописывая нужные имена членов перечисления. А в случае с хранением строк, ещё и придётся обращаться к дополнительным функциям, типа strcat или format.

Да и у тебя что, кнопки "CTRL", "C" и "V" вырвали из клавиатуры, что ты не можешь раз прописать "0,", а после вставить его нужное количество раз?

Batya_Montes

08.09.2017, 18:46

В чём проще? Для кого?
Проще для сервера? Нет. Ему сначала нужно всё нулями заполнить, а потом ещё раз заполнить уже нужными значениями.
Проще для скриптера? Тоже не вижу никаких преимуществ, ибо придётся ещё больше символов печатать, прописывая нужные имена членов перечисления. А в случае с хранением строк, ещё и придётся обращаться к дополнительным функциям, типа strcat или format.

Да и у тебя что, кнопки "CTRL", "C" и "V" вырвали из клавиатуры, что ты не можешь раз прописать "0,", а после вставить его нужное количество раз?

Окей. Представим ситуацию. У тебя енам с 1 лямом элементов. Тебе нужно все их заполнить 0. Ты будешь сидеть и 1 лям строк копировать ? Или ты напишешь 2 строки и машина сделает все за тебя? Да и машине проще, ибо переменная типа const и ей не нужно будет каждый раз создаваться, тем самым мы поулчаем профит с двух сторон.

(допустим еще 2 из 1 ляма нужно заполнить единицами и все это должно быть для каждого игрока, при коннекте)
с моим способом - тебе придется добавить все те же 2 строки на нужные элементы (либо 1 с .. = .. = 1), а не писать лям строк 0, а из них 2 с 1)

DeimoS

08.09.2017, 19:22

Окей. Представим ситуацию. У тебя енам с 1 лямом элементов.

Собственно, дальше можно не читать. Если у тебя перечисление содержит 1 миллион членов, то твоя реализация - дерьмо, ибо в этом enum будет намешано куча разных систем, что не есть хорошо, как минимум, из-за той ситуации, что перечислил ты. И в том, что ты столкнёшься с подобной ситуацией, виноват не мой подход к решению вопроса, а твоя реализация enum. Достаточно уметь в оформление кода и никаких проблем не будет.

Сейчас твой аргумент выглядит как: "Вот если я начну говнокодить по страшному, твой вариант будет уже неудобен".

Хотя вот это утверждение меня удивило:

Да и машине проще, ибо переменная типа const и ей не нужно будет каждый раз создаваться, тем самым мы поулчаем профит с двух сторон.

А мой глобальный массив будет несколько раз создаваться?
http://vsekidki.ru/uploads/posts/2016-06/1467132416_-z-jh0mvqa.jpg

Batya_Montes

09.09.2017, 09:43

Собственно, дальше можно не читать. Если у тебя перечисление содержит 1 миллион членов, то твоя реализация - дерьмо, ибо в этом enum будет намешано куча разных систем, что не есть хорошо, как минимум, из-за той ситуации, что перечислил ты. И в том, что ты столкнёшься с подобной ситуацией, виноват не мой подход к решению вопроса, а твоя реализация enum. Достаточно уметь в оформление кода и никаких проблем не будет.

Сейчас твой аргумент выглядит как: "Вот если я начну говнокодить по страшному, твой вариант будет уже неудобен".

Хотя вот это утверждение меня удивило:

А мой глобальный массив будет несколько раз создаваться?
http://vsekidki.ru/uploads/posts/2016-06/1467132416_-z-jh0mvqa.jpg

Кто сказал что я буду делать лям элементов в енам ? Это пример, не больше, в котором твой вариант - убог и не быстр, в отличии от моего.

DeimoS

09.09.2017, 12:34

Кто сказал что я буду делать лям элементов в енам ? Это пример, не больше, в котором твой вариант - убог и не быстр, в отличии от моего.

Так а смысл приводить примеры с неправильной реализацией? Можно сказать, что и нож ничего не сможет разрезать, если резать ручкой, а не лезвием -_- Перечисления не должны хранить овермного членов, дабы не усложнять работу с ним. Это и читаемость убивает (ну если в одном enum будут константы и для игрока, и для домов, и для автомобилей, и для кучи других систем, поиск нужной константы, особенно если ты не помнишь её имени, может занять приличное время), и к подобным ситуациям приводит.
В общем, естественно, если криво пользоваться инструментарием, который заложен в язык, то и трудностей всплывёт при этом куча. Это вполне закономерно.

С таким же успехом можно, например, сказать, что использование баз данных - это неудобно, ибо когда в одной таблице миллион столбцов, работать с ней становится убого и не быстро.
Твой способ имеет место быть, но лично я бы не стал из-за собственной лени перекладывать на сервер лишние действия, тратя процессорное время впустую. Из-за такой вот добровольной пессимизации люди потом и кричат повсюду, что у них лагают сервра, ибо эти самые доли миллисекунд, которые теряются в твоей реализации, имеют особенность накапливаться, появляясь и в других участках кода. Но, как говориться: стрелять в свою собственную ногу - дело добровольное