- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
/**
* returns file size in bytes/Kb/Mb/Gb
- *
- * @param bytes
+ *
+ * @param bytes
*/
public static function formatFileSize(bytes: uint): String
{
if (bytes < 1024)
- return bytes + " bytes";
+ {
+ return bytes + SPACE_STRING + "bytes";
+ }
else
{
bytes /= 1024;
if (bytes < 1024)
- return bytes + " Kb";
+ {
+ return bytes + SPACE_STRING + "Kb";
+ }
else
{
bytes /= 1024;
if (bytes < 1024)
- return bytes + " Mb";
+ {
+ return bytes + SPACE_STRING + "Mb";
+ }
else
{
bytes /= 1024;
if (bytes < 1024)
- return bytes + " Gb";
+ {
+ return bytes + SPACE_STRING + "Gb";
+ }
}
}
}
return String(bytes);
}
Follow us!
Единственное, что смущает - это петабайты. 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 нет целочисленного деления, и все деления происходят с флоатами. Место под флоаты выделяется в куче. Так что несколько раз их поделить может внезапно оказаться дороже одного вызова логарифма. И вообще, в управляемой среде пытаться оптимизировать ламповыми байтоебскими способами - обычно получается только хуже, т.как среда изначально затачивается под людей, которые такими оптимизациями заниматься не будут.
Тут соврешенно верно. Байтоёбствовать там можно, но надо очень тонко понимать как работает среда. С изменениями версий (даже одной и той же виртуальной машины) подобные знания могут устаревать, а оптимизации становиться обузой.
>уже была тема про это, с детальным обсуждением предсказателя переходов и тем, как можно заоптимизировать вычисление логарифмов и т.п. байтоебством.
Была. В итоге приходили к тому что самые простые способы не так уж и плохи. И читабельность важнее.