Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Смысл в бесполезном изменении, но если уж на то пошло, то:
1. В килобайте тысяча байтов (а не 1024).
2. Килобайты обозначаются kB или KB, но точно не Kb.
3. Все это можно было бы сделать в цикле, а не писать одно и то же три раза. (Можно и напрямую рассчитать, но это выглядело бы неестсственно сложно).
4. Константа SPACE_STRING впринципе бесполезна, как таковая, безотносительно этого кода.
5. А, да, и последний return не нужен, даже при оригинальной логике, else ветки не нужны.
Судя по названиям остальных переменных:
1. Если будет два пробела, автор переименует (или создаст дополнительную) константу SPACE_SPACE_STRING.
2. Если это будет неразрывный пробел, то аналогично, автор переименует в NON_BREAKABLE_SPACE_STRING.
Там даже другие варианты не предусмотрены.
ну поставленная задача решается не лучше, чем и оригинальном ГК.
Не указан тип size. Подразумевается что там будет 32-битовое беззнаковое? Во всем мире размеры байт уже давно 64 битные. Для веб это конечно не так критично, но если уж делать, так делать сразу нормально?
Про касты и милибайты уже написали.
Если уж на то пошло, то между 2GB и 3GB есть очень уж большая разница, поэтому хотелось видеть бы например 2.7GB, как это выводит 'ls -lh'
Комментарий не читай @ сразу отвечай. Написано же, что писалось в ж.скрипт консоли в браузере. Во всем мире 64 бита в инте? А в Яве, ж.скрипте и АС - 32. Оппа.
Дык речь не об инте, а о размере файлов. Если инт на данной платформе слишком мал - значит надо брать больший тип. А то потом рождаются программы-уродцы, которые в 2015 году не могут нормально показать размер трёх-четырёхгигового файла.
Его во Флеше неоткуда взять. У FileStream и ByteArray и т.п. свойство lenth - 32 бита, при чем часто еще и знаковые. Так что не важно сколько там было изначально, Флеш об этом все равно в принципе узнать не сможет.
Кстати, а какое вообще отношение размер файлов имеет к размерности инта в данном коде? Вы о чем вообще? Тут к инту приводится показатель степени за основанием 1024, или вы думаете, что для этого тоже нужно больше 32 битов? У вас где-то завалялась запасная вселенная где вы эти файлы хранить будете?
В ГК ветки if'ов. А здесь использование функций.
Вопрос: При каком количестве if'ов быстродействие обоих процедур будет одинаковым? Ах, ну да. Это же AS
Это прямо такой жизненно важный вопрос для этой задачи потому что опросить файловую систему стоит на столько дешевле, чем выполнить код на АС, что прям обязательно нужно развернуть это вычисление.
На самом деле уже была тема про это, с детальным обсуждением предсказателя переходов и тем, как можно заоптимизировать вычисление логарифмов и т.п. байтоебством. Но в данном случае гораздо более важной оптимизацией является экономия строчек кода, и в меньшей, но не несуществующей - объем сгенерированого байткода.
Что до ифов: в АС3 нет целочисленного деления, и все деления происходят с флоатами. Место под флоаты выделяется в куче. Так что несколько раз их поделить может внезапно оказаться дороже одного вызова логарифма. И вообще, в управляемой среде пытаться оптимизировать ламповыми байтоебскими способами - обычно получается только хуже, т.как среда изначально затачивается под людей, которые такими оптимизациями заниматься не будут.
>И вообще, в управляемой среде пытаться оптимизировать ламповыми байтоебскими способами - обычно получается только хуже
Тут соврешенно верно. Байтоёбствовать там можно, но надо очень тонко понимать как работает среда. С изменениями версий (даже одной и той же виртуальной машины) подобные знания могут устаревать, а оптимизации становиться обузой.
>уже была тема про это, с детальным обсуждением предсказателя переходов и тем, как можно заоптимизировать вычисление логарифмов и т.п. байтоебством.
Была. В итоге приходили к тому что самые простые способы не так уж и плохи. И читабельность важнее.
Байтойобствствовать в виртуальной машине где тебе ничего не гарантируют и Джит тебя перехитрит это кал. Байтойобить можно пиша на плейнсях под арм. Да и то, зная как у него микро архитектура,а не только иса, реализована
Единственное, что смущает - это петабайты. uint, кстати, какого размера в AS?
1. В килобайте тысяча байтов (а не 1024).
2. Килобайты обозначаются kB или KB, но точно не Kb.
3. Все это можно было бы сделать в цикле, а не писать одно и то же три раза. (Можно и напрямую рассчитать, но это выглядело бы неестсственно сложно).
4. Константа SPACE_STRING впринципе бесполезна, как таковая, безотносительно этого кода.
5. А, да, и последний return не нужен, даже при оригинальной логике, else ветки не нужны.
Возможно, автор имел в виду KiB'ы? Раз уж b маленькую написал, то мог и про i не знать.
Как и последний if. Один хуй петабайты не пролезут в uint (он же 32 бита в AS?).
P.S. Поэтому стоило бы заменить uint на что-нибудь 64-битное, файлы то нынче большие стали, 4 гига уже не редкость...
1. Если будет два пробела, автор переименует (или создаст дополнительную) константу SPACE_SPACE_STRING.
2. Если это будет неразрывный пробел, то аналогично, автор переименует в NON_BREAKABLE_SPACE_STRING.
Там даже другие варианты не предусмотрены.
Пример прямого рассчета.
Блин, я бы тут скобки поставил. Никогда не любил арифметику и логику в одном флаконе без скобок.
Байты, килобайты, миллибайты, хрензнаетчёзабайты?
Говнобайты, во!
Не указан тип size. Подразумевается что там будет 32-битовое беззнаковое? Во всем мире размеры байт уже давно 64 битные. Для веб это конечно не так критично, но если уж делать, так делать сразу нормально?
Про касты и милибайты уже написали.
Если уж на то пошло, то между 2GB и 3GB есть очень уж большая разница, поэтому хотелось видеть бы например 2.7GB, как это выводит 'ls -lh'
Кстати, а какое вообще отношение размер файлов имеет к размерности инта в данном коде? Вы о чем вообще? Тут к инту приводится показатель степени за основанием 1024, или вы думаете, что для этого тоже нужно больше 32 битов? У вас где-то завалялась запасная вселенная где вы эти файлы хранить будете?
Какой пиздец... В 2015 году...
> Вы о чем вообще?
>> Не указан тип size.
О входном параметре size. i само-собой очень маленькое.
Не указан - так в чем проблема тогда? Я уж было подумал, что я где-то размер случайно привел к инту.
Вопрос: При каком количестве if'ов быстродействие обоих процедур будет одинаковым?
Ах, ну да. Это же AS
На самом деле уже была тема про это, с детальным обсуждением предсказателя переходов и тем, как можно заоптимизировать вычисление логарифмов и т.п. байтоебством. Но в данном случае гораздо более важной оптимизацией является экономия строчек кода, и в меньшей, но не несуществующей - объем сгенерированого байткода.
Что до ифов: в АС3 нет целочисленного деления, и все деления происходят с флоатами. Место под флоаты выделяется в куче. Так что несколько раз их поделить может внезапно оказаться дороже одного вызова логарифма. И вообще, в управляемой среде пытаться оптимизировать ламповыми байтоебскими способами - обычно получается только хуже, т.как среда изначально затачивается под людей, которые такими оптимизациями заниматься не будут.
Тут соврешенно верно. Байтоёбствовать там можно, но надо очень тонко понимать как работает среда. С изменениями версий (даже одной и той же виртуальной машины) подобные знания могут устаревать, а оптимизации становиться обузой.
>уже была тема про это, с детальным обсуждением предсказателя переходов и тем, как можно заоптимизировать вычисление логарифмов и т.п. байтоебством.
Была. В итоге приходили к тому что самые простые способы не так уж и плохи. И читабельность важнее.