Не хотите постоянно проверять обновления моих скриптов?
Подключите его последним, после всех остальных
Nexius's Update Checker
Не хотите постоянно проверять обновления моих скриптов?
Подключите его последним, после всех остальных
Nexius's Update Checker
А для подсчёта символов в строке достаточно использовать нормальный редактор (то бишь, практически всё, кроме Pawno), в котором вшита функция подсчёта выделенных символов. От полученного значения отнять спецификаторы и получится размер строки без спецификаторов. На деле это будет быстрее, чем прописывать все эти "static const" и "sizeof(...)".
Вариант от Кортеза хорош в очень длинных строках, которые, к тому же, часто изменяются. Хотя и в том случае это может вызвать ряд сложностей, например, при попытке изменить порядок спецификаторов (очень легко изменить не тот спецификатор/переменную, которую нужно было изменить, так как текст сообщения со спецификаторами и переменные будут находится в разных частях кода)
Последний раз редактировалось DeimoS; 18.05.2018 в 18:11.
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
Знаю, что немного поздно, но всё же спрошу: каким образом вышесказанное относится именно к моему методу подсчёта (насколько знаю, такому классу ошибок подвержены все известные ныне методы)? Не говоря уже о скромном замалчивании того факта, что при ручном подсчёте точно так же можно неправильно "сосчитать" размер не только спецификаторов, но и самой форматной строки - например, редактор кода показал "48", но ты случайно записал "46" (просто опечатка или показалось не то число - неважно). К слову, именно от этого типа ошибок и перестраховывает использование sizeof.
P.S.: Ни в коем случае не пытаюсь добиться признания неправильным того или иного подхода к подсчёту размера строк - понятное дело, что однозначно правильного способа нет и всё зависит от индивидуального выбора каждым компромисса между скоростью написания кода и надёжностью. Тем не менее, хотелось бы видеть справедливое обсуждение всех плюсов и минусов, а не только доводы против одного метода и в пользу другого.
Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).
Стол заказов:
Мои работы:
Я уже в одной из тем (вроде, как раз в теме с описанием твоего метода) приводил пример этих слов, но ладно, приведу ещё раз.
Речь идёт про такой вариант реализации:
Очень часто встречал такие реализации при использовании метода подсчёта с sizeof и если появится нужда изменить порядок спецификаторов, придётся совершать, как минимум, лишние движения глазами вверх/вниз (что, согласись, гораздо больше сбивает, чем если бы текст и спецификаторы были на одной строке).PHP код:
static const fmt_str[] = "[A] Администратор %s отказал в запросе о помощи";
new string[sizeof(fmt_str) + (-2 + MAX_PLAYER_NAME)];
// Тут какой-либо другой код (например, определение максимального размера для массива, если мы имеем несколько static const, а не один)
// Тут какой-либо другой код (то бишь, часто код очень нужный конкретно в данном месте, а не до/после массива/форматирования)
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
format(string, sizeof(string), fmt_str, /* Имя администратора */);
При этом, даже без какого-либо кода между массивом и форматированием, читаемость такого варианта на порядок ниже, ибо когда ты смотришь на format, тебе придётся каждый раз отделять переменные от массива для заполнения и массива с текстом
В отличии от простого варианта, где всё подсвечивается редактором:PHP код:
static const fmt_str[] = "[A] Администратор %s отказал в запросе о помощи";
new string[sizeof(fmt_str) + (-2 + MAX_PLAYER_NAME)];
format(string, sizeof(string), fmt_str, name); // Ты так сразу не увидишь, что в строку записывается всего 1 переменная, так как всё будет сливаться
И к этому никак не привыкнуть, ибо практически в каждом случае форматирования у переменных будут уникальные имена разной длины, из-за чего нельзя просто "на автомате" пропустить несколько первых переменных.PHP код:
new string[45+ (-2 + MAX_PLAYER_NAME)];
format(string, sizeof(string), "[A] Администратор %s отказал в запросе о помощи", name); // Тут уже сразу видно где находятся переменные, ибо они отделяются текстом от массива для заполнения
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
Последний раз редактировалось Geebrox; 30.05.2018 в 02:45.
Вручную? Точнее, при помощи редактора, выделяя текст каждой строки
Хотя, думаю, если поискать, можно найти готовый плагин для ST, который позволяет подсчитывать размер текста сразу для нескольких строк, а не только для одной. Меня просто и такой вариант вполне устраивает. Я просто копирую текст таких сообщений в отдельную вкладку и удаляю все переносы, дабы получилось что-то типа такого:
На деле такой вариант всё равно будет быстрее, чем прописывание static const и sizeof (хотя и вариант с выделением каждой строки в отдельности будет быстр, если у тебя всё хорошо с математикой).PHP код:
SELECT id,HEX(password_hash) as hash,HEX(password_salt) as salt FROM "ACCOUNT_DATA_BASE_TABLE" WHERE "name='%q'
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
Да брось, пресчитывать каждую строчку потом в голове ещё сумировать всё это, убирать лишние или делители пробелы между строками, если есть ещё и константы то посомтреть содержимое константы и потом её длину тоже добалять ко всему полученному в голове и т. д. и т. п. Серьезно думаешь, что это быстрее, чем просто прописать sizeof? Это все действии не учитывая ещё и изменение в будущем. Например ты понял, что не правильно написал 1 букву в запросе после того как всё это ели просчитал, и....
Последний раз редактировалось Geebrox; 31.05.2018 в 03:39.
Именно, это будет быстрее. Ты забываешь, что прописать нужно не только sizeof, но ещё и static const + составить формулу со всеми вычетами заполнителей (когда я это могу сделать прямо в момент выделения текста, пропуская лишнее) + прописать в format вызов массива static const. К тому же, размер контакнт нужно будет смотреть и в случае использования static const.
Да и с чего ты решил, что обязательно всё нужно считать в уме? Как я сказал, можно легко найти плагин на любой вкус. Вот, например, поставил первый попавшийся (называется "Word Count"), который считает весь выделенный текст
И это при том, что изначально плагин заточен не на подсчёт символов, а на автоматический подсчёт слов. Так что я уверен, что, при желании, можно найти плагин, который позволит гораздо удобнее рассчитывать размер сразу для всего выделенного текста, раз тебе так сложно в голове складывать, в большинстве своём, простые числа.
Вариант со static const будет лидировать только в том случае, когда сама строка оформлена крайне ужасно. А-ля:
Вот в таких случаях действительно может быть быстрее прописать static const (если формула окажется не очень запутанной и не придётся тратить дополнительное время на перепроверку того, правильные ли ты значения прописал для того или иного заполнителя. То бишь, как раз тут в силу вступает та ситуация, которую я описал пару постов назад для Кортеза). В остальных случаях "ручной" подсчёт будет в разы быстрее и, в итоге, позволит коду остаться читабельнее/компактнее (хотя даже в этом случае можно придумать варианты быстрого перерасчёта размера в случае изменения строки. Было бы желание).PHP код:
static const query_content[] =
"SELECT "
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"HEX(password_salt) as salt "
"FROM "ACCOUNT_DATA_BASE_TABLE" "
"WHERE "
"name='%q'";
И, видимо, стоит напомнить про ситуации, когда у нас имеется несколько разных строк, которые нужно записать в массив. Сам Кортез в своей статье предлагает воротить здоровенную конструкцию из препроцессорных условий, что, опять же, раздувает код и отнимает кучу времени (именно поэтому, к слову, многие просто создают несколько массивов, в итоге, записывая строки по-отдельности, потребляя тем самым ещё больше памяти), когда я просто могу выделить каждую из строк, определить наибольшую и составить для неё формулу.
В общем, не стоит думать, что я тут просто так говорю обо всём этом. Я пытался пользоваться вариантом от Кортеза и даже работал с ним несколько месяцев. Но опыт показал, что в большинстве случаев такой вариант лишь отнимает кучу времени и бессмысленно раздувает код, не принося, при этом, пользы, ибо строка, в итоге, и не меняется никогда больше. А все твои "вот если строку изменить!...." - это обычное надумывание положительных моментов, для которых я так же могу придумать десяток отрицательных
Последний раз редактировалось DeimoS; 31.05.2018 в 09:21.
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)