И что, вы реально ни нашли ни один параметр, по которому были бы хуже конкурентов?
Интересно, как вы объясняете тот факт, что у них до сих пор есть пользователи, раз уж вы такие замечательные.
Ну так прочитайте статью, там же немного.
Добытую руду еще нужно превратить в сталь, для чего активно используется атмосферный воздух, загрязнения из которого переходят в конечный продукт. Когда производили сталь, которая сейчас лежит на дне моря, атмосфера была почище, отсюда и разница.
А разделение на две процедуры породило бы дублирование кода в обе процедуры, что грозит ошибками в случае его модификации.
Я не очень понимаю, что мешает пойти чуть дальше и нарезать эти две процедурки на несколько мелких (которые всё равно заинлайнятся), используемых по необходимости.
Здесь же по факту одна функция делает две вещи: считает размер и копирует данные. Прямое нарушение single responsibility principle, которое еще и наглядно затрудняет понимание происходящего.
Ошибки нет, но качественным кодом я бы это не назвал.
Неужели нельзя было порезать эти два раунда на две отдельные процедурки, раз уж количество раундов заранее известно?
Ну почему же совсем не значат. Это действительно некая приблизительная оценка сверху, но далеко не обязательно максимальная планка.
Производители могли бы публиковать цифру, которую действительно могут гарантировать — ёмкость батареи в ампер-часах, но технические подробности же никого не интересуют, всем подавай гарантированное время работы в неизвестном режиме.
По поводу достаточности этих 18 часов: я долгое время ходил с ipod nano 6 на запястье. У него заявленная циферка вообще 10 часов, и как-то хватало.
А, ну то есть, «в сети Wi-Fi» – это значит, подключить к сети и телефон больше не трогать? Ещё лучше, да.
Где вы такое прочитали? Вы прикидываетесь, или реально не в курсе, что скайп — общеизвестный пожиратель батареи, и запустив его, рассчитывать хоть на сколько-нибудь продолжительное время жизни телефона не стоит?
Все остальные рассуждения о времени жизни еще не вышедшего девайса — пустое сотрясение байт, время покажет.
Вы не видите разницы между «в сети Wi-Fi» и «с запущенным скайпом»? Она есть.
По факту будет не 18, а 12-14-16 в обычных пользовательских режимах (заявление одного уровня обоснованности с вашим). Естественно, умельцы угробить батарейку за час-полтора всегда найдутся.
Неясно только, почему в неадекватном энергопотреблении скайпа оказался виноват телефон.
Вы бы еще майнер биткойнов в фоне запустили и удивлялись, куда заряд девается.
Я смартфон для того и покупаю, чтоб пользоваться скайпами и играть в тяжёлые игры, помимо того, чтоб звонить…
Окей, хорошо. Но только «почти не использую» и перманентно запущенный скайп, знаменитый своим энергопотреблением, — вещи, как видите, существенно разные. Во втором случае кончающаяся за полдня батарейка — это нормально.
Settings -> General -> Usage -> Battery Usage
Там будет видно, кто сколько жрет. С большой вероятностью это какой-нибудь скайп.
Мне хватает на двое суток «почти не использования» и на день прослушивания музыки в bluetooth-гарнитуру.
Использовать линейную величину в качестве диаметра кружочка — обман, если не сказать хуже.
Перерисуйте кружочки так, чтобы количество побед было их площадью, и картинка внезапно станет чуть менее драматичной.
При использовании вот такого singleton-а у метода getInstance() может быть побочный эффект: при первом его вызове будет вызван конструктор. Поэтому формально ругаться на вызов getInstance() без присвоения как на RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT неправильно. С другой стороны, необходимость в ленивом синглтоне в этом случае (при том, что мы явно просим его инициализироваться в определенный момент), конечно, под вопросом.
Интересно, как вы объясняете тот факт, что у них до сих пор есть пользователи, раз уж вы такие замечательные.
Похоже, небольшие значения seed не просто генеренные.
Кстати, там еще есть кросс-ссылки в разделе Our Clients.
Добытую руду еще нужно превратить в сталь, для чего активно используется атмосферный воздух, загрязнения из которого переходят в конечный продукт. Когда производили сталь, которая сейчас лежит на дне моря, атмосфера была почище, отсюда и разница.
Здесь же по факту одна функция делает две вещи: считает размер и копирует данные. Прямое нарушение single responsibility principle, которое еще и наглядно затрудняет понимание происходящего.
Неужели нельзя было порезать эти два раунда на две отдельные процедурки, раз уж количество раундов заранее известно?
Производители могли бы публиковать цифру, которую действительно могут гарантировать — ёмкость батареи в ампер-часах, но технические подробности же никого не интересуют, всем подавай гарантированное время работы в неизвестном режиме.
По поводу достаточности этих 18 часов: я долгое время ходил с ipod nano 6 на запястье. У него заявленная циферка вообще 10 часов, и как-то хватало.
Все остальные рассуждения о времени жизни еще не вышедшего девайса — пустое сотрясение байт, время покажет.
По факту будет не 18, а 12-14-16 в обычных пользовательских режимах (заявление одного уровня обоснованности с вашим). Естественно, умельцы угробить батарейку за час-полтора всегда найдутся.
Вы бы еще майнер биткойнов в фоне запустили и удивлялись, куда заряд девается.
Там будет видно, кто сколько жрет. С большой вероятностью это какой-нибудь скайп.
Мне хватает на двое суток «почти не использования» и на день прослушивания музыки в bluetooth-гарнитуру.
Перерисуйте кружочки так, чтобы количество побед было их площадью, и картинка внезапно станет чуть менее драматичной.
Как-то так: pastebin.com/XEp6xjE6
У нас я порешал проблему удалением принудительной инициализации, но не факт, что всем это подойдет.
При использовании вот такого singleton-а у метода getInstance() может быть побочный эффект: при первом его вызове будет вызван конструктор. Поэтому формально ругаться на вызов getInstance() без присвоения как на RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT неправильно. С другой стороны, необходимость в ленивом синглтоне в этом случае (при том, что мы явно просим его инициализироваться в определенный момент), конечно, под вопросом.