Как правильно использовать стек

[punkochel]

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

stock OtherFunction() {     if(1 == 1)        return 1;     new string[];    else if(1 != 2) {         format(string, sizeof(string), "", );        SendClientMessage(0, -1, string);    }     else if(1 < 0) {         format(string, sizeof(string), "", );        SendClientMessage(0, -1, string);    }    return 0;}

Или ты хочешь сказать что будет более разборчивее создавать массив в теле условия?

[DeimoS]

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

stock OtherFunction() {     if(1 == 1)        return 1;     new string[];    else if(1 != 2) {         format(string, sizeof(string), "", );        SendClientMessage(0, -1, string);    }     else if(1 < 0) {         format(string, sizeof(string), "", );        SendClientMessage(0, -1, string);    }    return 0;}

Или ты хочешь сказать что будет более разборчивее создавать массив в теле условия?

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

[punkochel]

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

[Shaolinka]

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

Пвары экономят память? Тыкай

[DeimoS]

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

Ну так pVar и правда хорошо использовать в случае, когда тебе нужно хранить какую-то информацию временно. Например, можно пароль игрока при входе загружать в pVar, а при авторизации удалять pVar. Или же, например, в ситуации, когда у тебя есть несколько диалогов, в которые игрок вводит те или иные данные (например, ID игрока и цену при продаже дома) - эти данные тоже выгоднее хранить в pVar, которые будут удалены после того, как данные больше не будут нужны.

Пвары экономят память? Тыкай

Статья полезная, ибо объясняет как работают pVar, но основное утверждение в ней неверное. Экономия памяти за счёт pVar заключается в том, что, если их использовать для хранения временных данных и всегда вовремя удалять, то один и тот же блок памяти будет использоваться для разных данных, для которых, в ином случае, пришлось бы выделять отдельные переменные. Тот же самый эффект можно было бы получить, создав какой-нибудь массив на MAX_PLAYERS ячеек и уже записывать данные в него, но там бы и читаемость пострадала, и пришлось бы постоянно контролировать, хранятся ли в массиве какие-либо данные, прежде чем записывать в него что-то новое.
В общем, да, за счёт pVar экономить память можно. Просто не так, как Daniel Cortez ожидает в своей статье. И даже скажу больше: не использовать их странно, с учётом того, что память под них выделяется в любом случае. А ситуаций, при которых относительная медлительность pVar будет не критична, достаточно много можно придумать. Хотя если просто не забывать, что можно создать локальную переменную, скопировать в неё значение pVar и уже использовать её в коде, то даже в каких-нибудь циклах и таймерах использование pVar не будет сильно тормозить код.

[punkochel]

Ну так pVar и правда хорошо использовать в случае, когда тебе нужно хранить какую-то информацию временно. Например, можно пароль игрока при входе загружать в pVar, а при авторизации удалять pVar. Или же, например, в ситуации, когда у тебя есть несколько диалогов, в которые игрок вводит те или иные данные (например, ID игрока и цену при продаже дома) - эти данные тоже выгоднее хранить в pVar, которые будут удалены после того, как данные больше не будут нужны.

Согласен, именно в таких случаях и использую их. Про пароль кстати хороший пример. У PVar, если я не ошибаюсь имеется линейная зависимость? То есть, чем больше действующих PVar создано для игрока, тем дольше будут осуществляться операции с ними.
Кстати, как можно узнать сколько памяти зарезервировано под них? И если этот лимит достигнут, то откуда будет выделяться память, стек?

[Shaolinka]

Согласен, именно в таких случаях и использую их. Про пароль кстати хороший пример. У PVar, если я не ошибаюсь имеется линейная зависимость? То есть, чем больше действующих PVar создано для игрока, тем дольше будут осуществляться операции с ними.
Кстати, как можно узнать сколько памяти зарезервировано под них? И если этот лимит достигнут, то откуда будет выделяться память, стек?

Когда ты пытаешься получить значение пвара, ну или установить, то цикл на 800 итераций(max colvo pvar'ov) так или иначе запуститься(Это касаемо линейной зависимости, если что-то не в том роде написал, sorry).

[Pa4enka]

Эмм, зачем кого-то отключать от сервера? Сервер сам всё это сделает, если рестарт будет производиться заложенными в это средствами - через команды "gmx" или "exit". Если же ты убиваешь серверный процесс на стороне хостинга, то твой код в любом случае не будет вызываться, так как сервер и не поймёт, что его собираются перезагружать.

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

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

[punkochel]

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

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

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

Именно по такому-же пониманию я и решил задаться таким вопросом) Как оказалось, это не очень хорошо. Теперь я понимаю почему это так, но все же не вижу ничего критичного. Может быть это было актуально, когда сервера работали на "калькуляторах". Подобное актуально только для pawn, т.к. в других ЯП (большинстве), стек работает быстрее и там есть что оптимизировать.

Когда ты пытаешься получить значение пвара, ну или установить, то цикл на 800 итераций(max colvo pvar'ov) так или иначе запуститься(Это касаемо линейной зависимости, если что-то не в том роде написал, sorry).

Откуда эта информация? Может быть цикл и запуститься, но получение информации из PVar будет происходить быстрее если он один, нежели их будет 800. Именно это я имею ввиду под "линейной зависимости".
UPD: Вот же блин вся инфа (https://wiki.pro-pawn.ru/wiki/SetPVarInt)

[DeimoS]

Кстати, как можно узнать сколько памяти зарезервировано под них? И если этот лимит достигнут, то откуда будет выделяться память, стек?

В той же статье всё описано. Для чисел память выделяется в любом случае. Для строк память выделяется при создании pVar и высвобождается при удалении pVar.

Может быть цикл и запуститься, но получение информации из PVar будет происходить быстрее если он один, нежели их будет 800. Именно это я имею ввиду под "линейной зависимости".

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

Именно по такому-же пониманию я и решил задаться таким вопросом) Как оказалось, это не очень хорошо. Теперь я понимаю почему это так, но все же не вижу ничего критичного. Может быть это было актуально, когда сервера работали на "калькуляторах". Подобное актуально только для pawn, т.к. в других ЯП (большинстве), стек работает быстрее и там есть что оптимизировать.

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

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

То есть, ты сначала используешь команду, которая не предназначена для рестарта, а потом удивляешься тому, что у тебя что-то не сохраняется и придумываешь костыли, чтоб исправить это? Отличный план

Поэтому, лично я лучше пожертвую памятью, производительностью, напрягу mysql, но все же сохраню весь сервер перед рестартом.

А можно просто сохранять все изменения по ходу работы сервера и не бояться ничего потерять.

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

Это те самые разработчики, работы которых мы можем в паблике видеть? Если да, то аргумент слабый. А даже если нет (в чём я сомневаюсь, с учётом того, каков процент говномодов и говноскриптов имеется в паблике относительно действительно качественных скриптов без багов) - тоже аргумент слабоватый. Если кто-то прыгает с крыши, то это не значит, что и тебе нужно уподобляться этому.
Впрочем, если кто-то хочет говнокодить и создавать себе проблемы из воздуха (как с тем же "exit") - ваше право.

P.S. И меня удивляет то, как у многих людей срабатывает триггер на дискуссии при виде каких-то длинных обсуждений. В каком месте ты тут дискуссию увидел - загадка. На протяжении всей темы автор задаёт вопросы, а я на них отвечаю. Всё.