Тут уже проблема в том, как ты опишешь название, а не в диалоге.
Вид для печати
Говоря о солидарности с Ziggi, я говорил о варианте его кода без const. И я говорил о общей мании того, что если подобный массив объявить без const, то данные в нём обязательно попортят.
Хотя ладно, я изначально начал говорить не о том и признаю, нёс бред. Я пытался лишь озвучить своё мнение по поводу формулировки подачи информации вами и не более, поэтому действительно не стоит продолжать.
Почему все забили на вариант с кликабельными текстдравами? :с Никто не переходил по ссылке? Такой вариантгораздо удобнее всех диалогов будет же
Чем? Я разницы с диалогом не вижу, также неудобно. Как по мне, самым удобным вариантом является зайти на подобный сайт и посмотреть все интерьеры сразу со скриншотами.
В случае с диалогами трудно показывать большое число интерьеров одновременно. И если показать, например, 40 диалогов, из которых только 20 видны изначально (до остальных нужно список пролистывать), и теллепортироваться, например, в 39-ый, повторный показ диалога приведёт к тому, что пролистывание собьётся (список диалогов опять будет показан сначала).
В случае с кликабельными текстдравами такое не произойдёт и ты спокойно можешь хоть подряд каждый смотреть, наводя на названия мышкой (а с диалогами придётся каждый раз этот самый диалог закрывать).
В общем, посмотрите тот скрипт, который я кинул, и увидите о чём я говорю. Еслли реализовывать подобную систему через игру, имхо, лучше текстдравов ничего не найти
Мои слова относятся к этому случаю в том плане, что в нём и оптимизировать-то особо нечего. То, что ты сделал, обычно называют "преждевременной оптимизацией". Ну откажешься ты от использования sscanf, в лучшем случае выиграешь пару-тройку микросекунд, общей картины это не изменит. Хотя можно было просто использовать sscanf2 и сэкономленное время потратить с куда большей пользой на оптимизацию того, что действительно нуждается в оптимизации.
Ты не видишь меры в том, что стоит оптимизировать, а что нет, да ещё и меняешь логику работы кода, чтобы достичь ещё большей "оптимизации", я лишь констатирую этот (очевидный) факт. О каком преувеличении здесь может идти речь?
Для паблика так тоже можно: если используешь что-то нестандартное, просто снабди комментарием, чтобы другим было понятно. Но, опять же, в меру.
В качестве примера приведу пару своих работ:
http://pro-pawn.ru/showthread.php?3243
Здесь в функции используется #emit для того, чтобы вместо двух операций деления с одинаковыми операндами оставить лишь одну и тем самым повысить производительность алгоритма.
В комментарии указан оригинальный код на Pawn и причина, по которой был использован тот трюк с #emit.
http://pro-pawn.ru/showthread.php?12837
Здесь тоже используется #emit, и не один раз. Это обусловлено тем, что куй объявил функцию SetPVarString без спецификатора const для параметра "varname", из-за чего просто невозможно перехватить BanEx без #emit, не нарушив совместимости.
Собственно, всё это так же можно найти в комментариях.
Так я и не говорил, что следует абсолютно всегда придерживаться шаблонных методов.
Для экспериментов можно делать отдельные небольшие работы, чтобы обкатывать новые техники программирования. В случае, если допустишь какую-то значительную ошибку или эта техника просто не оправдает себя, тебе не придётся тратить время на поиск и откат изменений в основном проекте.
Нужно уметь отличать какой-либо свой проект от "испытательного полигона". В крайнем случае, эксперименты можно проводить, реализуя с нуля отдельные модули проекта, но не в уже готовом и проверенном коде.
Отказ от sscanf идёт не во благо оптимизации, а во благо логики. Когда это стало нормальным использовать функции не по их предназначению? Или sscanf стала функцией проверки, записано ли в массив число или записан текст?
Опять же, ответ дан выше. Как, вроде, ты сам не так давно отвечал, оптимизация не только бывает в сторону скорости.
Только вот практически во всех случаях, когда я предлагаю мыслить нестандартно (с MAX_PLAYERS тем же), ты сразу пытаешься поставить контраргументом то, что так делать не принято и есть общепринятые нормы.
Хочется начать с того, что для меня Pawn и так является отдельным и небольшим "проектом", которым я занимаюсь чисто ради удовольствия.
Продолжить хочется тем, что когда дело доходит до какой-либо серьёзной работы или написания какой-либо статьи, я не использую какие-либо "новые техники".
"Новые техники" я использую лишь там, где это уместно. И, в том числе, в комментариях на форуме.
Хотя я бы не назвал новой техникой попытку сделать код более логически верным.
И да, раз уж всем тут плевать на логику, давайте и от forward откажемся, а будем просто дублировать public. Суть-то одна. Какая разница, логично это выглядит или нет?
Добавление багов в алгоритм как-то слабо пересекается с логикой.
Вообще-то это и есть то, что делает sscanf2: проверяет синтаксис параметров и считывает их.
Не совсем понял, о чём ты.
Да, потому что ты преподносишь порочные практики так, как будто это обычное дело, не поясняя перед этим, к чему они могут привести.
И мы же вроде уже разобрались по поводу того случая с MAX_PLAYERS(+1), нет?
Т.е. ты предлагаешь другим то, в чём сам не до конца разбираешься?
Ну если добавление неоднозначных ситуаций в алгоритм прокатило, то... почему бы и нет?!