Как стать автором
Обновить
0
0
Alex Zakharenko @Fahrenheit

Пользователь

Отправить сообщение
Мне кажется, что в случае AWS стоило использовать для сравнения стоимость reserved instances, раз уж мы говорим про долгоживующие приложения. Хотя, конечно, автоматическая скидка у GCE — хорошая идея.
Да, обычно по переводу (даже не точному) можно догадаться, что же было в оригинале, но здесь что-то совсем несуразное
Ну, у меня в семье учет и планирование постарался организовать похожим образом. Правда, именно сейчас расслабились в связи с другими жизненными изменениями, но в ближайшие месяцы, думаю, сможем вернуться к нормальной организации и планированию.
Пара комментариев:
1) Для начала — откладывать какой-то фиксированный % — это уже само по себе хорошая идея, правда, расчитывать эти деньги приумножить — с этим все хуже (см. ниже)
2) Момент, который в статье не раскрыт (хотя почему-то я сразу подумал о нем, когда речь зашла о банке) — это возможность самому себя кредитовать (тут я говорю о семье, не лично о себе). За небольшой % :) Плюс очевидный — этот % идет обратно в фонд, а не банку, у которого бы эти деньги пришлось брать. На начальном этапе можно говорить про замену всяких кредитных карт для экстренных и внеплановых трат — именно там самый большой %
3) Я сам из Украины. У меня вначале тоже был похожий список альтернативных вложений. К сожалению, большинство из них в наших реалиях сложнореализуемы. Пример — огромный спред между покупкой и продажей физических металлов, абсолютно не развитый рынок акций (больше напоминает песочницу). Думаю, в России с этим лучше, но не намного.

Как для себя решил проблему из п. 3? Перебрался в другую страну (это именно те перемены, про которые упомянул в начале) — в Украине создавать бизнес принципиально не хотелось.
Спасибо за статью, однако стоило бы поподробнее раскрыть вот этот упомянутый момент: «Или хранить внутри одного объекта “нечто” произвольного типа с единственным ограничением — наличием оператора “()” у хранимого “нечто”. Не понимаю, как приведенная реализация поможет в решении этой проблемы.
Мне кажется, any::operator() достаточно тривиально реализуется через виртуальный holder::operator(). Заодно получим проверку того, что переданный тип T подходит на этапе компиляции.
Было бы интересно, если бы смогли подробнее остановиться на тех проблемах, которые решались после разработки изначального прототипа.
Спасибо, очень интересно, давно думал, как же реализованы подобные сервисы.
Остался вопрос — как решается проблема с несколькими похожими треками (например, живая версия, исполненная очень близко к студийной) — ведь в изначальной постановке задачи требуется вернуть только один ответ.
Пробовал пересесть на FastStone по рекомендации, но одой принципиальной фичи не хватило — возможности запуска нескольких экземпляров (например, пока идет массовая обработка фоток в одной папке хочется походить по другой). Пришлось остаться на IrfanView
Это два отдельных момента. Первый — unit-тесты для нетривиальных математических функций. Когда-то этому была посвящена отличная статья тут, на Хабре.
Ну и второй — пытаться что-то рефакторить, не понимая до конца (не пожелав разобраться, на самом деле), это один из самых больших грехов разработчика (на мой вкус, конечно).
Это заметил уже пару версий назад, так что не новое
Спасибо за статью. Думаю, в статью стоит добавить, что именно попадает в эти самые 5% ситуаций, когда mini-ICU даст косяки
Спасибо. Только не совсем понятен первый пункт — какой именно парсер? В статьях упоминания про него не нашел.
Три раза в статье повторено, что нужно использовать только UTF-8. А можно пояснить — почему так?
Дабы тут не повторяться, рекомендую почитать статью на CodeProject, ссылка на которую в моей комментарии ниже. Там человек измерял реальную производительность списка по сравнению с вектором для некоторых (типовых для списка!) задач.
Я говорил не о произвольном доступе к элементам списка. Я говорил о произвольном доступе к памяти даже при последовательном доступе к элементам списка (для каждого выделен свой блок динамической памяти).

Ну а на счет вставки в середину вектора — в реальной жизни сдвиг половины элементов вектора может быть дешевле набора операций, которые необходимы для вставки элемента в середину:
1) Поиск этой самой середины
2) Выделение памяти для элемента списка
3) Ну и самое дешевое — поменять указатели, чтобы вставить элемент.

Не все же векторы имею размеры в миллионы элементов, правда?
Важно. Я ниже в комментариях приводил ссылку на статью, в которой сравнивали производительность вектора и списка, и результат совсем не в пользу списка. Очень рекомендую почитать.
Если вкратце — то алгоритмическая сложность не учитывает особенности конкретной платформы. А в данном случае их, как минимум, две — медленный произвольный доступ к памяти играет против списка (у него элементы могут быть разбросаны, у вектора — все в одном месте), медленные операции по выделению памяти — при добавлении элемента в вектор не обязательно происходит выделение \ перевыделение памяти. И это все может нивелировать копирование.
Простите, ссылка не вставилась
Прошу прощения, ссылка на codeproject не вставилась
Смотря что вставляем. А если еще учесть время на аллокацию каждого узла списка — вообще получим страшные вещи.
Так что совет использовать std::vector по-умолчанию (пока в конкретном алгоритме он не станет узким местом) — очень удачный.
Это не говоря о том, что при хранении мелких элементов в списке занимаемый объем памяти будет в разы больше, чем у вектора.
См. мои прикидки тут:
Вообще беда с этим std::list. Если говорим о хранении простых типов (не берем тяжелые в копировании и перемещении объекты), то сложно придумать алгоритм, который будет с ним более эффективен, чем простой vector (даже без учета заполнения!).
Хорошая статья на codeproject на эту тему:
Руслан, а есть еще какие-то дополнительные идеи по окупанию проекта? Когда заходил первый раз на сайт (после публикации на Хабре), даже не понял, что он donation-ware, честно говоря

Информация

В рейтинге
Не участвует
Откуда
Mercer Island, Washington, США
Зарегистрирован
Активность