• Почему четырёхдневная рабочая неделя — это вредная сказка
    +16
    Вредная сказка — для кого?
    Дополнительные свободные день для человека могут привести к разным сложнопрогнозируемым профитам: он будет заниматься сторонними задачами, которые могут помочь решить какую-то задачу компании (вспоминаем про 20% времени для Гугл сотрудников), может запилить свою компанию (а это уже выгодно государству), может больше времени проводить с семьей (счастливые семьи), может больше заниматься собой (спорт, хобби). Ну а может бухать в подъезде. Тут надо смотреть на общий уровень жизни в стране, отрасль и т.д.
  • Поставщик «железа» для «закона Яровой» раскрыл данные о своей выручке
    +9
    Ой, да легко. Берешь supermicro, берешь xeon, память под все это дело, покупаешь OEM корпус, вставляешь все туда, ставишь х5 относительно самого дорогого ценника на аналогичное оборудование от именитых производителей и поставляешь. Рецепт, который с годами становится только крепче.
  • В чем набрать и чем собрать C++ проект
    0
    Никак. Если нужно собрать что-то серьезнее хеллоуворлда, то без cmake это все рано или поздно превратиться в боль и страдания.
  • Аналитика из-под ковра: обзор «новинок» 18-летней давности
    +9
    Интересным оказалось то, что 18 лет назад, в казалось бы, «дремучие» времена, в принципе уже было все

    Как раз в районе 2000-2007 я бегал сначала с КПК Toshiba e405, а потом с Dell x50v — заказывал с ebay, когда в России про зарубежные заказы-то слышали только краем уха. И когда вышел первый айфон, у меня просто разрывало шаблон, зачем он нужен, если ничего не умеет? Я на своих КПК мог читать, слушать музыку и смотреть кино, имел доступ к ФС, у меня стоял dosbox с математическим пакетом Maple года так 1989, но он и такой версии спокойно мог считать всякие пределы, строить графики и все такое. Надо сказать, что работало все это быстро, были вполне качественные игры с неплохой 3d графиков. Плюс часто в КПК были съемные аккумы, поэтому проблема энергопотребления просто решалась дополнительным акком в сумке. И всем это при полноценной многозадачности!

    И вот каким-то образом Microsoft умудряется это платформу просрать сначала Apple, а потом и Google. Эпл по широте поддерживаемого функционала, пожалуй, так и не догнал виндовсмобайла тех лет, а Андройд все-таки взял вверх удобством, функционалом и ценой, но, на мой взгляд, хорошо работать он стал только лет 5 назад, когда в телефоны стали ставить по 8 ядер и по 3+Гб оперативы (в КПК тех лет стояло по 32-64мб оперативы).

    В общем, старое — это не всегда плохо.
  • Героям III — 20 лет
    +5
    До сих пор в нее играю. Некросы, Галтран, скелетоны и магия земли (в идеале — с воздухом) — мой топчик.
  • Google+. Sic transit gloria mundi…
    +1
    Не знаю, как другие хабровчане, но я уже давно настороженно отношусь к новым продуктам Гугла. Открыть, распиарить, свернуть — участь почти всех попыток Гугла что-то выкинуть на рынок. Reader, Code, Wave, +, iGoogle, Picasa, Нangouts и т.д. Есть очень интересный ЯП Dart, но тоже есть ощущение, то гугл хочется его ко всему остальному отправить.
    Go и kubernetes — да, взлетели, но больше из последнего ничего вспомнить не могу. Карма у компании уже такая, что на все новые продукты смотришь «а, ну через 2 года закроют».
  • Трехмерная визуализация в тренажерах подвижного состава на базе движка OpenSceneGraph
    0
    С какой версии Qt появилась эта возможность?

    С версии 5.5.
    Не знаю, насколько эта штука юзабельная, потому что потыкать не было возможности, но кажется, что для всяких симуляций выглядит вполне себе подходящим инструментом. Ну и плюс Qt со всеми ништяками, удобно.
  • Трехмерная визуализация в тренажерах подвижного состава на базе движка OpenSceneGraph
    0
    Qt3D это средство для создания трехмерных презентаций

    Это вы со студией их, наверное, путаете. Сейчас Qt активно продвигает свой модуль для работы с 3d графикой. Описание.

    Ogre

    После того, как основатель и бессменный лидер проекта Steve Streeting ушел по состоянию здоровья, движок очень затормозил. Вроде бы сейчас его тоже пилят, но как-то все медленно, половина вики не работает, а большое русское комьюнити просто развалилось. Жаль, я в свое время активно использовал этот движок и тоже делал на нем различные симуляции, и он был отличным.

    OSG гибче, не зря создатели OpenMW мигрировали с него с Ogre.

    Я как-то тоже решил для пробы (один небольшой проект) взять OSG, и тоже могу сказать, что работать с ним приятнее и стабильнее, чем с Огром. Работает именно так, как ожидаешь, что не скажешь о последних версия Огра.
    Ну и OSG тоже до сих пор пишет автор движка, уже очень много лет.

    В Windows Ogre для рендера использует DirectX

    В Ogre3D используются OpenGL и DirectX 9/11, рендер можно выбрать.
  • Трехмерная визуализация в тренажерах подвижного состава на базе движка OpenSceneGraph
    0
    А выбор сразу такой сделали насчет движка? Ogre3d рассматривали? Qt3D появился с версии 5.5 — его не рассматривали?
  • OpenSceneGraph: Групповые узлы, узлы трансформации и узлы-переключатели
    0
    Круто! Это будут, пожалуй, единственные уроки в рунете.

    Придется столкнуться с малым количеством комментариев, но это нынче нормальное явление на Хабре с техническими статьями. От этого они хуже становятся.
  • OpenSceneGraph: Групповые узлы, узлы трансформации и узлы-переключатели
    0
    Не, Ogre3D имеет рендеры и OpenGL, и DirectX. На винде можно использовать любой.
  • OpenSceneGraph: Групповые узлы, узлы трансформации и узлы-переключатели
    +1
    Это же графический движок, его к чему угодно можно прикрутить.

    К слову, парни, которые пишут открытый Morrowind, в свое время перешли с Ogre3D на OSG и остались очень довольны.
  • JsonWriterSax — библиотека для создания JSON
    0
    Выглядит хорошо, спасибо!
  • Знакомство с SOCI — C++ библиотекой доступа к базам данных
    +1
    Ну я бы не был столь категоричен. В edba 143 коммита, последний был 2.5 года назад, cppdb дальше cppcms не забралась и, видимо, поэтому была заброшена.

    У soci 2450 коммитов, последний был пару месяцев назад, сам проект уже черти когда назад начал писаться. На самом деле, продукт зрелый.
  • Портируем код с Qt 1.0 на Qt 5.11
    0
    большой плюс qt5 по сравнению с qt3

    Еще в Qt4 это сделали. И надо сказать, что Qt4 появился аж в 2005 году, 13 лет назад. А это времена, когда никаких умных указателей и потоков в GCC не было, не говоря уж про msvc.
    Qt3 — это 2001 год. К слову, первый интелловский двухядерный процессор Pentium D и амдешный Opteron появились только в 2005. И я не уверен, что там была отличная аппаратная поддержка атомарных операций (во всяком случае, компиляторы точно не умели правильно генерировать код). В тоже время, Qt3 имеет поддержку потоков (треды, мьютексы, conditional variable и прочее). И мне кажется, вы слишком много просите для того времени.

    Но, как по мне, лучше бы перешли на стандартную строку.

    Конечно, нет. Строки в стандарте — это ужас. Вернее, как мы уже обсудили выше, строк как таковых в стандарте нет вообще.

    На сколько я знаю, QString не умеет нормально работать с комбинированными символами, состоящими из двух двухбайтовых слов

    QString::fromWCharArray

    Регулярки, потоки и т.д.

    Опять же, Qt давно имеет эти классы, на них уже написано много кода, они хорошо, логично и удобно реализованы. Зачем ломать удобные классы, только лишь потому, что в стандарте недавно появилось аналогичное?
    Я за то, чтобы заменить заведомо костыльные вещи на что-то новое и удобное. moc — замечательный костыль своего времени, но сейчас его можно реализовать элегантнее, не сломав старый код. Слоты в Qt5, благодаря лямбдам, стали намного удобнее и красивее. Вот я за такие изменения.

    Кстати, на Qt чаще ругаются не когда они вводят что-то новое (за это наоборот все радуются), а когда они что-то удаляют. Как было, например, с перехода QtWebKit на QtWebEngine. Вот тут у людей были болезненные переходы.

    И еще есть момент. Qt очень часто голым используется в embedded устройствах, прям минуя STL. Если памяти довольно мало, то практически всегда выгоднее тащить с собой QtCore с огромным функционалом из коробки, вместо довольно голого STL.
  • Портируем код с Qt 1.0 на Qt 5.11
    0
    Еще раз: возвращается количество объектов QChar. В кодировке UTF-16 при значения больше 65535 используется 2 объекта QChar (ну потому что стандарт так говорит). Вполне логично, что на запрос размера мне возвращается количество QChar.

    std::wstring

    Ага, только wchar_t в винде занимает 2 байта, а в никсах — 4 байта. Со всеми вытекающими проблемами отсюда.
  • Портируем код с Qt 1.0 на Qt 5.11
    +1
    Практически в qt5 реализация QString вынуждена использовать блокировки

    Все-таки внутри QString (да и вообще всех классов Qt, использующих implicit sharing) используются атомарные счетчики, а не стандартные блокирующие примитивы. Как только мы копируем объект, счетчик ссылок увеличивается на один, и мы получаем легкую копию (shallow copy). Если мы хотим изменить объект, вызывается detach и мы получаем глубокую копию (deep copy).

    Так вот, если мы делаем копию строку в другом потоке, сначала получаем shallow копию, увеличиваем счетчик и работаем с shared данными. Как только мы начинаем изменять объект, мы получаем отвязанную локальную копию нашей строки, которая уже не ссылается на данные в других потоках. Ее изменение происходит локально, ничего нигде не сломается.

    Совсем другое дело, если наша строка являются общей для разных поток, и они ее пытаются изменить. Да, тут нужны традиционные блокировки аля mutex, но это ровно также нужно и со всеми другими типами данных (то есть, аналогично нам нужно было бы сделать и с std::string). QString является реентерабельной функцией, не потокобезопасной.

    Вообще, для решения такой проблемы (совместное изменение общих данных) разработчики рекомендуют использовать сигналы-слоты.

    С чем я соглашусь:
    1) Действительно, с приходом move-семантики implicit sharing уже не выглядит так вкусно. Единственным аргументом в использовании implicit sharing сейчас является разве что его хорошая производительность из коробки, тогда как про move-семантику нужно всегда помнить и писать код соответствующе (к сожалению, до сих пор многие этим пренебрегают).
    2) Действительно, я проверил, в qt3 не было атомарных операций при implicit sharing, что ломало счетчик в разных потоках. Только с Qt4 все стало нормально.
    Но я не очень понял, как так получилось, что раньше так код работал, а потом, когда стало все нормально — перестал.

    На самом деле обе реализации хранят внутри себя байты

    Естественно. Только QString имеет представление о том, что она хранит, а std::string — нет.

    Если же есть необходимость работать с отдельными символами юникода

    Перегнать что-то из одной кодировки в другую — на самом деле, не такая уж и редкая проблема. Да, в мире, где казалось бы, уже везде используется UTF-8, все равно встречаются системы с какой-нибудь KOI8-R, и никто ничего переделывать не будет. Вот Qt позволяет такие вопросы решать из коробки очевидными способами.
    А вот почему этого всего нет в стандарте — вопрос действительно хороший.

    Вообще, отступая от темы, Qt исторически был вынужден изобретать велосипеды для каких-то ограниченных платформ

    В первую очередь — из-за ограничений языка. Сейчас-то и moc уже не нужен, есть реализация от авторов оригинального moc'a чисто на шаблонной магии и новых стандартах. Я тоже надеюсь, что велосипеды будут потихоньку заменяться на стандарт, а новые фичи будут упрощать код. Но все же даже сегодня писать на Qt очень приятно и производительно.

  • Портируем код с Qt 1.0 на Qt 5.11
    0
    Верное замечание, спасибо. Тем не менее, такой результат — это более логичное поведение для строки.

    Насчет UTF-16 — да, думаю, из-за винды. UTF-32 в винде почти нигде не используется, поэтому неудивительно, что выбрали средний вариант.
  • Портируем код с Qt 1.0 на Qt 5.11
    0
    Вопрос не только в собирается / не собирается, а в поддержке кода. Старый код на старом добром C++ (а чаще — на C с классами) может и собирается, но разобраться в нем зачастую боль и страдание.

    только одна небезопасная реализация QString для потоков

    Что значит эта фраза? QString реализует принцип CoW (Copy-On-Write), что, в общем-то, является одной из киллер-фич фреймворка, и позволяет практически безболезненно быстро гонять данные между потоками.

    При этом, вместо того чтобы просто выкинуть QString в qt5, его продолжают тянуть в новые версии.

    Кхм… у меня есть подозрения, что вы все-таки не очень разобрались с фреймворком. QString хранит внутри себя Unicode символы, а std::string — байты. В итоге QString знает, сколько хранит внутри себя символов, умеет гонять данные между разными кодировками, а также имеет удобное API, а std::string — не знает и не умеет. В итоге тот же lenght на UTF-8 данных вернет не количество символов, а размер в байтах.
    Вообще, std::string корректнее сравнивать с QByteArray.
  • Портируем код с Qt 1.0 на Qt 5.11
    +3
    Не на всех платформах есть такое счастье, поэтому по умолчанию и отключено.

    Насчет выкидывания Qt и переписывания на чистые плюсы и буст — если проект долгоиграющий, то это вам может аукнуться в будущем. Qt очень большой, слаженный, с отличным коммьюнити, огромным количеством примеров, понятным и логичным API. Неподготовленный пользователь может быстро стартануть с Qt.

    А вот boost — уже для куда более подготовленных плюсовиков. И, к сожалению, не всегда такие есть под рукой.
  • Портируем код с Qt 1.0 на Qt 5.11
    0
    Подтверждаю, тоже портировали с Qt 4.8 на тогда еще Qt 5.3 большой проект (~0.5 млн строк + библиотеки) — заняло пару дней. Исправления были минимальные, ничего не переписывали.
  • Нил Стивенсон: голод инноваций, большие проекты и научная фантастика
    +1
    А экономика в первую очередь — скучное «чтобы было что кушать сегодня, завтра и послезавтра». Сливать деньги в никуда нетрудно, а в итоге добиться какого-то результата — финансового ли, научного — сложно.


    «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь.» ©

    Много исследований и денег идет на то, чтобы, например, сделать телефон более тонким, более быстрым, более легким, красивым и прочее, и прочее. Этот рынок живет, растет, пользуется спросом и приносит производителям много денег. В общем-то, это в какой-то степени хорошо. Но больше это не революция, телефоны плюс-минус все одинаковые, ими все пользуются, и можно довольно легко предугадать, что с ними будет через год, два, пять, десять лет — чуть быстрее, чуть тоньше, чуть дольше работать и т.д.

    А речь о том, что реального R&D в новых областях очень мало. Бизнес не хочет (и часто — не может) рисковать. Для этого должно работать в том числе государство, выстраивать новую технологическую политику, политику в образовании, в работе. Международные связи и разработки (типа того же CERN). Происходит ровно обратное, замыкание на себя — это особо остро сейчас в России, но и более технологических странах такое тоже всплывает (США — Китай, например).

    Потому что принципиально новое — это электромобиль. А ДВС со механической (да ещё и автоматической нередко теперь) трансмиссией — это больной с рождения выродок.

    Я бы не был такой резок относительно ДВС, но опять же, нежелание слезать с золотой бочки крупных производителей авто привело к тому, что замена ДВС вот только-только начинает вырисовываться.

    Ага, только опять же — поддерживать стек технологий атомной энергетики очень дорого.

    В первую очередь им не занимаются, потому что сейчас это непопулярно. Политик, который захочет поставить в своем регионе АЭС — обречен.
    Атомная энергетика дорога на старте — сложно строить, нужны специалисты, инфраструктура и т.д. В перспективе атомная энергетика оказывается дешевле и проще в обслуживании.
    Одно из самых проблемных мест всяких ветряков — коэффициент используемой установленной мощности. АЭС всегда выдают расчетную мощность, ветряк — нет. В итоге мы приходим к тому, что ее где-то нужно накапливать, чтобы обеспечивать работу в утренние и вечерник пики, а это также дополнительная стройка, затраты, обслуживание и т.д.
  • Нил Стивенсон: голод инноваций, большие проекты и научная фантастика
    +1
    Проблема в том, что сейчас R&D — это в первую очередь эффективное управление деньгам инвесторов, а не исследования новых, возможно, ложных путей развития, а от того более рискованных и дорогих.

    Ваши примеры, кстати, отличное тому подтверждение. Автомобильный рынок сейчас — это большая беда. Все пытаются вставить в автомобиль всевозможные попограйки и вентиляции, а с такими важными узлами, как двигатель и коробка передач сейчас у каждого второго производителя проблемы. И только единицы компании пытаются построить что-то принципиально новое.

    Ветроэнергетика по эффективности ни в какое сравнение с атомной не идет. Популяризации атомной энергетики нет, ее стали все боятся, политикам стало ее не выгодно поддерживать, вот мы и строим «ветряные мельницы». На самом деле, это очень дорого в строительстве и обслуживании и, на удивление многих людей, куда более деструктивно опасно для окружающей среды, чем АЭС.
  • Классические алгоритмы и структуры данных на JavaScript
    +2
    Я хоть и особо не работаю с js, но вы все отлично оформили, приятно глазу посмотреть!

    Глазу зацепилась таблица со сложностью для Hash Table. Все-таки среднее время поиска/вставки/удаления у нее будет константным, и только в худшем случае, если подобрана совсем неудачная хеш-функция, сложность будет линейная.
  • «Мегафон» заказал комплекс СХД «Купол» для хранения трафика по закону Яровой
    0
    А надо-то было всего лишь слово «занавес» на «купол» заменить!
  • Процесс найма глазами разработчиков: результаты опроса «Моего круга»
    0
    Ну дык я и написал, что на технической части обычно понятно, человек умеет решать задачи и просто боится бумагу, либо совсем мимо. Не в бумаге дело же.
  • Окна на чистом WinAPI. Или просто о сложном
    0
    Говном можно и золото измазать, ну.
    Стабильность, огромный деплой, баги, глюки — это все не от прямых рук.
  • Окна на чистом WinAPI. Или просто о сложном
    0
    Ну если есть какие-то проблемы с деплоем, зачем тащить с собой QtQuick, когда для классических форм вполне достаточно старых ламповых виджетов?
  • Окна на чистом WinAPI. Или просто о сложном
    0
    Этого недостаточно. Посмотри (и проверь на чистой системе) размер полного деплоя, особенно для Qt5.

    Я последний раз что-то на Винде разворачивал еще во времена активной жизни Qt4, и не припомню, чтобы размеры как-то впечатляли. Если открыть официальный мануал, то речь идет о 15-20мб (или +27, если с ICU) для mingw. Если msvc собрать, меньше будет.

    Если мы говорим о никсах, то все нужные либки Qt, как правило, есть в системе, поэтому о размере вообще думать не приходится.

    А шаблоны несущественно раздувают код.

    Еще как раздувают. Какая-нибудь жирная либа на шаблонах типа CGAL сделает прогу уровня хеллоуворлд в несколько мегабайт на старте.

    В целом, Кьют сравнимо с дНЕТ и вполне терпимо на сегодняшний день.

    Ну, если мы деплоим на винду, то там, как правило, весь рантайм и либы (для минимального приложения) лежат в системе, поэтому бинарники весят очень мало. Зато на никсы деплоить дотнет — тот еще геморрой.
  • Окна на чистом WinAPI. Или просто о сложном
    +2
    Ну так вы С++ с Qt не путайте с другими решениями (Delphi, Java и прочее).
    Посмотрел, две базовые библиотеки Qt для окошек на моих никсах весят 4.5Мб (QtCore) и 6.5 (QtWidgets). Этого достаточно, чтобы быстро, надежно и без геморроя написать приложение с окошками.

    Потом, Qt — не шаблонная библиотека, она не раздувает код. А также не тащит с собой виртуальные машины, райтаймы и т.д. Вот прям сейчас под рукой простенькое приложение на 10 окошек с сетью и БД занимает 300кБ в релизе. Размер смешной, чтобы его считать хоть сколько-то значимым.
  • Легковесное ядро конечного автомата с автогенератором дерева для embedded проектов
    0
    Тут нужно правильно поставить приоритеты, что от чего идет. Если у нас уже есть UML схема, в которой, помимо прочего, есть конечные автоматы — да, проще и быстрее сгенерировать ее из того, что есть. Такое бывает, если система сначала проектируется, а потом создается (то есть в мире единорогов :) ).

    Если же мы создаем какую-то систему, и нам нужен конечный автомат, то решение с SCXML будет более правильным. Лучше поддержка, есть множество готовых инструментов (как компиляторов, так и GUI-софтин). Ну и XML в наше время стандарт для многих систем, поддерживается всюду и везде.
  • Легковесное ядро конечного автомата с автогенератором дерева для embedded проектов
    +1
    Для описания конечного автомата есть стандарт SCXML. Для того, чтобы перегнать конечный автомат из этого формата в C++ код есть scxmlcc.

    Также, в упомянутом вами Qt появился модуль Qt SCXML, который:
    1) имеет компилятор qscxmlc;
    2) позволят работать с SCXML прям в коде (грузить, сохранять, etc);
    3) модуль для Qt Creator, который позволяет с помощью GUI рисовать свои конечные автоматы.

    Чем эти решения хуже/лучше вашего?
  • Кто убил джуниора?
    0
    Не знаю, как там в штатах, но в России в default city ситуация простоя — есть много людей, которые вообще не написали ни строчки кода, но хотят устроиться джуниором за, условно, 100к/мес. При этом обучение такого «джуниора» — это, считай, наполнять чистый лист знаниями в течении нескольких лет. А результат не факт, что приведет к положительному эффекту.

    Дело в том, что сейчас программирование — это хайп. Родители отдают своих детей «учиться программировать», не разбираясь, нравится это им или нет, есть ли у них талан и предрасположенность. В итоге получаем армию как бы выученных на разработку ПО людей, но по факту — притянутых за уши. Им это не интересно, они этим не особо хотят заниматься, но понимают, что за это платят деньги, поэтому что-то делать надо.

    В итоге, когда приходят на собеседования студенты или совсем свежие выпускники, довольно быстро можно понять, стоит ли вообще тратить время на такого джуниора. Вот общаешься и понимаешь, что просто самый-самый потолок для этого человека, есть он будет что-то делать — middle. Он выучит это, это и вот это, но если шаг в сторону — «это не в моей компетенции, это я не знаю как, это я делать не буду». Я знаю, о чем говорю, такого много. Ну и зачастую нет смысла тратить время на такого джуна, если сколько-либо серьезных задач в будущем он все равно зарешать не сможет.

    По моей статистике, только 1 из 10 джунов достойны внимания. То есть таких джунов, которым надо просто дорогу показывать, а дальше они сами все откопают, спросят, напишут. Они быстро станут мидлами, а потом, если их будет дальше переть, и сеньорами. Остальных надо тянуть за уши и вытирать за ними сопли без каких-либо перспектив получить качественный кадр.

  • Интересное наблюдение по запуску Falcon Heavy
    +1
    Вообще при условий, что классических заправок на Марсе нет, Тесла-кары какой-нибудь повышенной проходимости — вполне себе вариант транспорта для красной планеты. Вероятно, это даже как-то в планах учтено.
  • О том, как я переизобретал медиацентр
    0
    Сразу появляется ряд удобных кейсов, о которых раньше и не задумывался:
    1) показывать фото и видео с телефона на телеке
    2) аналогично с фотиком
    3) открытый ролик с youtube на телефоне можно в один клик отправить на телек

    Потом, поднимать на никсах сервер самбы только для шаринга видеофайлов как-то не православно. NFS можно, но я даже не задумывался, поддерживает ли ее телек. С DLNA все просто и из коробки, работает стабильно, настроил и забыл.

    Так как роль плеера отводилась устройству, аналогичному тому, что собирал топикстартер.

    Тут, кстати, есть нюансы. Например, есть в телеке есть функция аля TrueMotion, то нужно внимательно настраивать свой проигрыватель.
    Да и вообще, субъективно, телек встроенными средствами выдает более приятную глазу картинку, чем, скажем, комп с VLC. Вероятно, это уже особенности конкретного телевизора (у меня Sony XE8096).
  • О том, как я переизобретал медиацентр
    0
    У данного решения будет одна явная проблема — не потянет 4k фильмы. Если телек не умеет такое крутить, то пофиг, иначе — лишать себя очень качественной картинки.

    Насчет AndroidTV на телеке я тоже сначала скептически относился, а когда купил — был приятно удивлен. Плюс DLNA решает проблему по проигрыванию контента с компа/NAS.
  • СберШифт: пять раз нажимай и в систему попадай
    +1
    Ну дык и сейчас XP стоит, судя по видео.
  • Релиз CLion 2017.3: существенные улучшения поддержки C++, интеграция с Valgrind Memcheck и Boost.Test и многое другое
    0
    Интеграция с Valgrind Memcheck

    Не прошло и 3.5 лет :)

    Полезных улучшений много, вы молодцы!
  • Повторное использование кода — как это бывает на практике
    0
    Даже по вашей таблице разница может достигать 4 раза. Это, мягко говоря, очень много.

    На самом деле, виртуальные функции — это только половина беды. Основная проблема — код обрастает большим количеством крайне медленных dynamic_cast, мы теряет возможность грамотно оптимизировать код (потому что компилятор не знает, что нам прилетит в рантайме), в большинстве случаев теряем inline'овые функции (хотя final немного выправляет этот пункт) и т.д. и т.п.
  • Интуитивная разработка алгоритмов
    +2
    Несмотря на то, что статья мотивационная, и, в целом, автор говорит правильные вещи (код все-таки нужно уметь писать самому), его пример — как раз тот самый случай, когда задачу надо очень хорошо гуглить.

    Геометрические задачи тяжело решаются на компе. Написать robust алгоритм для общего случая чаще всего очень сложно. Автор вскользь написал, что существуют сложные многоугольники (они же самопересекающиеся), но задачу начал решать для простых. А вот я бы как раз посмотрел, как бы он эту задачу с помощью бумаги и карандаша решал применительно к сложным многоугольникам. Интересующиеся могут пойти в гугл с запросом «repair complex polygon» и убедиться, что это тема для многих научных работ и диссертаций, большинство решений которых ненадежны в общем случае. И задача эта очень важная и часто встречающаяся, потому что существует и в картографическом мире, и в полигональных моделях.

    Поэтому, лично мое мнение, что начинать задачу нужно в первую очередь с понимания предметной области, а уже потом брать карандаш и писать свои велосипеды.