Как узнать из скольких символов состоит число?

[Disinterpreter]

Ну тут уже сугубо дело каждого. Желаешь делать свою работу абы как - делай. Только потом не удивляйся, что и тебя обслуживают абы как где-нибудь в ЖКХ (им же за это тоже не доплачивают) :)

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

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

Естественно людям которые везде говнокодят прошивки для спутников писать не дадут, но сайты/коддлясампа клепать нормально. Если человеку это нравится, и выше сайтов он не прыгает то всё ок.

[DeimoS]

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

ЖКХ засовывает во временные рамки начальство. А ты всегда можешь сказать своему работодателю, что если тебе дать немного больше времени, то ты можешь всё продумать гораздо лучше, объяснив, что в перспективе он сэкономит за счёт этого. Было бы желание.
В любом случае, это уже оффтоп и не будем об этом.

[Disinterpreter]

ЖКХ засовывает во временные рамки начальство. А ты всегда можешь сказать своему работодателю, что если тебе дать немного больше времени, то ты можешь всё продумать гораздо лучше, объяснив, что в перспективе он сэкономит за счёт этого. Было бы желание.
В любом случае, это уже оффтоп и не будем об этом.

Пишешь хорошо одну программу, вторую, а потом понимаешь что макросекунды никто не ценит, зачем оно?

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

Думаешь на сервере $continue$ будет играть больше 50 человек? Сомневаюсь.

[DeimoS]

Пишешь хорошо одну программу, вторую, а потом понимаешь что макросекунды никто не ценит, зачем оно?

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

Думаешь на сервере $continue$ будет играть больше 50 человек? Сомневаюсь.

Та какая разница сколько и на чьём сервере будет играть человек? Это ведь твой проект и тебе потом работать с кодом: почему бы не вникнуть и не сделать всё качественно? Особенно в случае с кодом, написание которого займёт, от силы, пару минут. Эта пара минут впоследствии может избавить от пары десятка проблем и пары бессонных ночей, которые могут уйти на исправление "и так сойдёт"-кода.

 Тебя, тру-программист, написанное ниже тоже касается

Ты никак не поймешь суть...

1) Всегда имеет место быть другие варианты другой реализации.
2) Покажи, где я отрицал, что условия работают медленнее? Оно и понятно из чего.
3) Я очень сомневаюсь, что ты увидишь разницу работы условии и логарифма (О да, щас начнет втирать про PVM). Я молчу про оптимизацию компиляторов C/C++ (Работать же Pawn программистам ты не будешь, правильно? А то покажи мне компанию, где требуются Pawn - программисты? Все пытаешься втирать про офис)
4) Ты устроил холивар на пустом месте. Я нигде не отрицал, что условия медленнее, но в обратную сторону ты получаешь компактный код (опять щас про PVM начнет втирать). Тут, наверное можно отделаться одной фразой: "Каждый дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям.". А то ты мне про компактность втирал, что PVM, грубо говоря насрать на компактный код, а раз уж ты хочешь получить прирост, то почему ты не сделал сравнения через ASM? (#emit). #быстрей_же. Очень странная логика.

И да, холивар устроил ты, начав твердить о том, что никак не мог подкрепить фактами ;) Я лишь пытаюсь объяснить тем, кто наткнётся на твои сообщения, что твои идеи никак не работают в случае, описанном автором вопроса.
Собственно, и про emit я уже отвечал выше, что показывает как сильно ты вникаешь в этот диалог

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

[Disinterpreter]

Я вообще не понимаю почему у вас ещё и желание спорить возникает в этом случае. Это же не какая-то лютая оптимизация с использованием байт-кода или взломом ноосферы.

У меня просто личная неприязнь к байтодебилизму.

"Преждевременная оптимизация — корень всех зол." Д.Кнут

Люблю садиться за код где больше описано нормальными операторами чем высчитыванием байтов и прочими костылями.

[DeimoS]

У меня просто личная неприязнь к байтодебилизму.


Люблю садиться за код где больше описано нормальными операторами чем высчитыванием байтов и прочими костылями.

Так а где идёт речь о том, что нужно байтодебелизмом заниматься? Я сам ярый противник такого извращения во всех случаях, где это совсем не нужно. Но в данном случае никакого байтодебелизма нет ведь. Как раз наоборот, если учесть, что многие скриптеры в SA-MP ещё не начали проходить в школе логарифмы :D

Суть всего этого диалога в том, что некий $continue$ начал утверждать, мол лучше выбрать более медленный вариант реализации из двух предоставленных, ибо он компактнее. Я изначально утверждал, что заниматься извращениями, а-ля emit, где ни попадя - бред сивой кобылы. Я не призывал заниматься какими-либо извращениями с оптимизацией, переписывая всё, что только можно, в условия. Речь шла о конкретной ситуации с конкретным кодом. И в этой ситуации, как мне кажется, вариант с условиями очевиден для выбора, ибо это не тот код, который тебе придётся постоянно дорабатывать или хотя бы просто заглядывать в него. Так что не совсем понятно почему находятся защитники "компактного" варианта.

[$continue$]

Давай, расскажи какие проблемы могут быть с логарифмом?

Кроме как проверки на отрицательное число.

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

Так это проблема коммьюнити. Меня не сильно интересует это. Не знание, не освобождает о ответственности.

Как раз наоборот, если учесть, что многие скриптеры в SA-MP ещё не начали проходить в школе логарифмы :D

[DeimoS]

Давай, расскажи какие проблемы могут быть с логарифмом?

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

Так это проблема коммьюнити. Меня не сильно интересует это. Не знание, не освобождает о ответственности.

Так а твоя лень - это сугубо твоя проблема. Почему сервер и игроки должены от неё страдать?

Твоя проблема в том, что ты теоретик. При том, довольно слабый теоретик.

[$continue$]

Так это документированный баг и фиксится он билдом плагина (кстати, оно советуется и fixes.inc).

  Открыть/закрыть

А потом начинается отставание таймеров и всё остальное.

Не. Так давай переводить из C/C++ в ASM, тебе же не лень. Именно для этого и был придуман компилятор и другие языки программирования, чтобы избавить программиста от написание огромных строк кода. Ну ты все равно выбираешь метод - написать больше и получить в миллисекундах прирост производительности. Почему мало людей сейчас пишут на чистом ASM? Одна из причин не выгодно и затратно. На чистом ASM пишут какие нибудь загрузчики OS и ему подобное ПО, которое требует максимальной скорости. С Pawn такая же ситуация. Я знаю, что Pawn работает в single thread, но меня не останавливает использовать логарифм в своих проектах. Не знаю, почему тебя это пугает. Наверное ты и массивов избегаешь (оно удобней, но медленнее). Как часто бывает, что красивей выглядит - то помедленнее работает. И вообще такой вопрос (хотя ты уже давал на него ответ): часто ли ты используешь функцию для вычисления размера?

Вообще не критичная ситуация.

Так а твоя лень - это сугубо твоя проблема. Почему сервер и игроки должены от неё страдать

Я не был и не буду профессионалом в области Pawn/SA-MP. Я такое нигде не писал, а ты выдумал, что я какой то профик. Я не читал книги по Pawn Lang, как делал это ты (это может и ошибка, но это не останавливает меня писать код на этом языке). Хреновый теоретик? Я изначально вроде сказал, что оно будет медленнее условии, но выглядеть оно будет проще (зная свойство логарифма) и универсальнее. Если int будет > чем 2 ^ 32 - ещё пару условий (но в Pawn 2^31). Просто в данном случай меньше условий, но вообще это садомазахизм

Твоя проблема в том, что ты теоретик. При том, довольно слабый теоретик.

[DeimoS]

Так это документированный баг и фиксится он билдом плагина

Это не баг, а особенность однопоточности. Такая особенность есть и, например, в JavaScript. И отставания как раз случаются из-за другого кода, а не из-за самих таймеров. И чем меньше будет задержка из-за другого кода, тем меньше будет искажение у таймеров.

Не. Так давай переводить из C/C++ в ASM, тебе же не лень. *море ненужного текста*

А теперь бегом перечитывать все мои предыдущие сообщения, в которых я объяснял почему в данном случае эти миллисекунды важны.