Мне помогла. В старом Ворде чёрт ногу сломит, в новом уже можно работать. Гораздо быстрее и приятнее.
При выборе между просто функциональной програмой и функциональной да ещё и красивой, я выберу красивую. Современный софт должен быть удобным, понятным, отзывчивым и приятным на вид. Это всё — юзабилити.
P. S. 5 лет работаю за деньги, с бессмысленным трудом не сталкивался. Приведите пример.
Продукт Майкрософт сделан на базе редактора от Гитхаба, написанного не пойми на чём? Это было бы странно, мне кажется.
P. S. Из Вики:
Visual Studio Code is based on Electron, a piece of software that is based on Chromium, which is used to deploy io.js applications for the desktop. Visual Studio Code uses the Blink layout engine to render the interface.
Наверное, это дело вкуса / привычки, но я изучал Verilog и VHDL примерно в одинаковом объёме, и для синтеза VHDL мне понравился намного больше. Мне кажется, что он проще, понятнее, предсказуемее и даёт меньше возможностей выстрелить себе в ногу. В Verilog большое несинтезируемое подмножество, и много синтаксического сахара. Много всяких нюансов надо держать в голове. Зато для верификации он, возможно, и проще (а есть ещё System Verilog для высокоуровневой верификации).
Я одно время много играл в LFS, и у меня нет ощущения, что это лучший симулятор. Физика там нормальная, но немного специфическая. Хотя в целом это действительно честный симулятор, и довольно неплохой. Только контента маловато.
Не-а, всегда пишу прединкремент. После проделанного вчера эксперимента (мой пост ниже) я понял, что дело всего-навсего было в том, что я не догадался предвычислить end() до начала цикла, а size() — догадался. Это единственный фактор, насколько я могу судить по результатам исследования.
А вот разницы между +it и it++ как раз и нет в этом конкретном тесте.
P. S. Я расстроен, что компилятор не умеет оптимизировать вызов const-метода std::vector::size (ну или end). Неужели это так сложно — определить, что на векторе после generate не вызываются никакие не-const методы? И почему бы в векторе не сделать размер переменной, чтоб его просто вернуть, а не вычислять каждый раз?
Тот же тест, винда, MSVC 2013 (toolset v120) x86, vector(200 * 1000 * 1000). Релиз + /O2 (дефолтные релизные настройки):
accumulate: 46 ms
for_each: 118 ms
for(int i: vec): 118 ms // Обидно, да?
for (auto i = vec.begin(); i != vec.end(); i++): 47 ms
for (auto i = vec.begin(); i != end; ++i): 46 ms
for (size_t i = 0; i < vec.size(); ++i) sum += vec[i];: 118 ms
for (size_t i = 0; i < size; ++i) sum += vec[i];: 47 ms // Ага, понятно, почему range-based for медленный: компилятор, как и в этом случае, не кэширует" vec.size() и вычисляет его каждый раз.
int *array = &vec[0]; for(size_t i = 0; i < size; ++i) sum += array[i];: 47 ms
auto end = &vec[vec.size() — 1]; for (int *i = &vec[0]; i != end; ++i) sum += *i;: 47 ms
register: 47 ms // Ч. т. д.
sum += array[i] + array[++i]: 65 ms // Интересно…
+1. Тема интересна, результаты бесполезны. Пожалуй, повторю эксперимент сам. Один раз столкнулся при оптимизации хотспота с тем, что обход вектора с помощью итератора заметно медленнее, чем по индексу (в релизе со вмеми оптимизациями).
Спасибо, погуглю векторные слои. Я догадываюсь, что в Фотошопе всё это можно делать, но не смог найти, как. Нарисовать банальный треугольник инструментом Shape — пытка, и я даже не смог отключить сглаживание краёв, например.
Правда, в моём случае ещё ситуация осложняется тем, что мне нужно рисовать отдельно на RGB каналах и отдельно — на альфе, но это, я думаю, решается рисованием в отдельных файлах и копированием-вставкой финального растрового изображения в нужное место.
Спасибо! Статья как будто специально для меня — надо иногда рисовать мелкую графику размером порядка 32х32 (не иконки, а контролы, но суть та же). Намучался уже в Фотошопе это делать! Никакого контроля.
Эх, классная клава, но зачем же они убрали встроенный экранчик :( Видать, буду и дальше сидеть на синей G15, пока не сломается окончательно. Альтернативы не вижу.
Я равнодушен к фетишу физических носителей (коробочек, обложек и т. д.), но у меня достаточно обширная аудиоколлекция (~600 GB, 90% — lossless), и я не вижу ей онлайн-альтернативы. Даже если не учитывать lossless, не меньше 10% коллекции в принципе отсутствует на Deezer.com и ещё нескольких крупных бесплатных сервисах, которые я изучал.
При выборе между просто функциональной програмой и функциональной да ещё и красивой, я выберу красивую. Современный софт должен быть удобным, понятным, отзывчивым и приятным на вид. Это всё — юзабилити.
P. S. 5 лет работаю за деньги, с бессмысленным трудом не сталкивался. Приведите пример.
P. S. Из Вики:
Visual Studio Code is based on Electron, a piece of software that is based on Chromium, which is used to deploy io.js applications for the desktop. Visual Studio Code uses the Blink layout engine to render the interface.
А вот разницы между +it и it++ как раз и нет в этом конкретном тесте.
accumulate: 46 ms
for_each: 118 ms
for(int i: vec): 118 ms // Обидно, да?
for (auto i = vec.begin(); i != vec.end(); i++): 47 ms
for (auto i = vec.begin(); i != end; ++i): 46 ms
for (size_t i = 0; i < vec.size(); ++i) sum += vec[i];: 118 ms
for (size_t i = 0; i < size; ++i) sum += vec[i];: 47 ms // Ага, понятно, почему range-based for медленный: компилятор, как и в этом случае, не кэширует" vec.size() и вычисляет его каждый раз.
int *array = &vec[0]; for(size_t i = 0; i < size; ++i) sum += array[i];: 47 ms
auto end = &vec[vec.size() — 1]; for (int *i = &vec[0]; i != end; ++i) sum += *i;: 47 ms
register: 47 ms // Ч. т. д.
sum += array[i] + array[++i]: 65 ms // Интересно…
Правда, в моём случае ещё ситуация осложняется тем, что мне нужно рисовать отдельно на RGB каналах и отдельно — на альфе, но это, я думаю, решается рисованием в отдельных файлах и копированием-вставкой финального растрового изображения в нужное место.
О, наконец-то я достоверно выяснил, что я ленив :)
Не понимаю, зачем они используют CMake вместо qmake…