/id с темы по sscanf'у.

[Тузик]

Думаю различие в оптимизации мало, а может вовсе нет, но при использовании уже данного значения разве нужно ли подсчитывать, когда на это уходит хотя бы 0.0001 ms? :)

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

Согласен, поправил.

Как я понял strins вы использовали как преобразователь в красивую цветовую гамму? xD

(Да, был прав. Не проверял до этого.) Однако могу вам сообщить, что имея имя Tuzyk и при поиске Tuzykss (к примеру) высвечивает без вашего цвета имя Tuzyk :)

[ziggi]

И чем это лучше? Тем, что обманываете GetPlayerName с размером string?

Если я правильно прочитал исходники amx/samp, то меньше символов будет копироваться.

UPD: Макрос COMMAND_ID_MAX_MATCHES следует убрать (#undef) либо после выражения со sscanf, либо в конце функции, чтобы не было конфликтов при аналогичном использовании этого макроса в других функциях.

Поправил.

[Daniel_Cortez]

Если я правильно прочитал исходники amx/samp, то меньше символов будет копироваться.

Т.е., по твоему, если указать размер буфера больше MAX_PLAYER_NAME (например, 30), то кроме никнейма скопируется ещё несколько следующих байт памяти? Как ты это вообще представляешь? Нет, я знаю, что в SA-MP до сих пор много багов, но не настолько же, чтобы была криво сделана каждая N-я операция копирования.

Указание размера буфера в строковых функциях - как стандартных, так и из SA-MP - нужно только чтобы избежать записи за его пределы. Если указать размер буфера отличный от фактического, никакой оптимизации из этого не будет - только побочные эффекты: неполное копирование строки или выход за пределы буфера.

[ziggi]

Т.е., по твоему, если указать размер буфера больше MAX_PLAYER_NAME (например, 30), то кроме никнейма скопируется ещё несколько следующих байт памяти? Как ты это вообще представляешь? Нет, я знаю, что в SA-MP до сих пор много багов, но не настолько же, чтобы была криво сделана каждая N-я операция копирования.

Указание размера буфера в строковых функциях - как стандартных, так и из SA-MP - нужно только чтобы избежать записи за его пределы. Если указать размер буфера отличный от фактического, никакой оптимизации из этого не будет - только побочные эффекты: неполное копирование строки или выход за пределы буфера.

И правда, я неправильно прочитал это:

while (max--&&*source)
  *dest++=(cell)*source++;  

[Тузик]

Т.е., по твоему, если указать размер буфера больше MAX_PLAYER_NAME (например, 30), то кроме никнейма скопируется ещё несколько следующих байт памяти? Как ты это вообще представляешь? Нет, я знаю, что в SA-MP до сих пор много багов, но не настолько же, чтобы была криво сделана каждая N-я операция копирования.

Указание размера буфера в строковых функциях - как стандартных, так и из SA-MP - нужно только чтобы избежать записи за его пределы. Если указать размер буфера отличный от фактического, никакой оптимизации из этого не будет - только побочные эффекты: неполное копирование строки или выход за пределы буфера.

То есть, по-вашему, в этом случае лучше использовать подсчет строк, нежели заведомо неизменяемое (константу)?

[Daniel_Cortez]

То есть, по-вашему, в этом случае лучше использовать подсчет строк, нежели заведомо неизменяемое (константу)?

"Поодсчёт строк"? О чём вы?

[DeimoS]

То есть, по-вашему, в этом случае лучше использовать подсчет строк, нежели заведомо неизменяемое (константу)?

Он имеет ввиду то, что если ты в GetPlayerName (да и любой другой функции, где есть параметр длинны входящей строки) вместо "sizeof(string)", которая равна, например, 200, укажешь "MAX_PLAYER_NAME", которая равна 24-рём, ничего существенного не измениться, ибо в GetPlayerName всё так же попадёт массив string, размером в 200 ячеек.
А вот если указать MAX_PLAYER_NAME, а массив потом, например, на 15 ячеек изменить, то можно схлопотать обращение к несуществующей ячейке с такой "оптимизацией"

[Тузик]

"Поодсчёт строк"? О чём вы?

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