Ну а так, как пример из прошлого, помню, был у меня КПК (карманный персональный компьютер, дедушка современных смартфонов) — Dell x50v. Статья подсказывает, что это около 2004 года было. Конфигурация смешна по современным меркам — 1 ядро на 600Мгц, 64 ОЗУ.
Я на нем библиотеки книжек в FbReader читал, музыку слушал, инет серфал, в приличные игры играл, имел доступ к файловой системе, карты навигации стояли и т.д. DosBox у меня стоял с Maple 1987 года, в котором я считал всякие математические задачи.
Короче, все тоже самое, что и делаю сейчас. Да, навигация сейчас стала сильно лучше (а тормозит уже и на 8 ядрах и 6Гб), экраны приличнее, скорости быстрее, но не могу сказать, что я ощущаю какой-то прям качественный скачок в софте. Скорее, стало больше веба и сервисов, что сильно добавило функционала в оффлайн из онлайна (такси, доставки и т.д.), но основной набор софта на десктопе/мобиле у меня плюс-минус одинаковый десятилетиями.
Просто люди часто видят либо черное, либо белое. Но, а вокруг все, как правило, серое.
В статье бросается в глаза то, что автор рассуждает о том, что софт сейчас в целом пишут лучше, а примеры почему-то железные приводит: был модем, стал гигабитный изернет, было 16 метров памяти, стало 16 гигов и т.д. Но дело в том, что железки действительно стали на порядки мощнее железок 20 летней давности, утилизация этих железок пропорционально возросла, а вот качество, полезная функциональность и быстродействие софта на эти порядки, увы, не возросли.
Стали ли анимация, свистелки-перделки и общий вид приложений лучше – ну, скорее, стали. Стали ли эти приложения больше занимать памяти и места, жрать больше CPU – да, тоже стали. Можно ли сказать, что потребляемые ресурсы эквивалентны добавленным возможностям – увы, далеко не всегда.
Сейчас довольно популярна тема – ну жрет мой блокнот 1гб памяти, и пусть жрет, сейчас же на машинах их 16-32Гб. А по итогу получается, что открыл Firefox на 100 вкладок, 2-3 экземпляра IDE с большим проектом, какую-нибудь GUI для гита – опа, а у тебя уже -15Гб рамы, и в своп уже просится. Ну блин, как так, вроде топовый ноут был 2 года назад, вроде бы и ничего фундаментально не изменилось, а он уже – старые дрова, которые еле тащат разработку.
Разработчики современных фреймворков – они же тоже больше про «простоту вхождения», чем про оптимизации. Вот если фреймворк взлетел, тогда да, можно начать думать и про это.
Простота вхождения дает нам больше разработчиков, больше идей, больше продуктов, сервисов и фич – звучит хорошо. С другой стороны, низкая подготовка кадров может приносить много багов, глюков и прочего – это плохо. Но т.к. «пластмассовый мир победил», и бизнес научился впаривать продукты любого качества, то прибыль за количество новых внедренных фич перевешивает убытки от добавленных глюков, прожорвости и т.д., то бизнес будет и дальше идти по, пока еще, прибыльному пути.
Вообще, я бы сравнил «борцов за оптимизацию» с разумными экологами. Вторые говорят, что заводы – это все тоже важно, нужно и прогресс, но давайте все-таки при этом не уничтожать все в округе, иначе через сколько-то лет нам придется решать другие, более сложные задачи. Если сейчас совсем не смотреть на разбухающий софт, то рано или поздно 95% утилизации мощностей компов уйдет в поднятие локальных серверов на каждый калькулятор, и жить сильно лучше не станет.
Вредная сказка — для кого?
Дополнительные свободные день для человека могут привести к разным сложнопрогнозируемым профитам: он будет заниматься сторонними задачами, которые могут помочь решить какую-то задачу компании (вспоминаем про 20% времени для Гугл сотрудников), может запилить свою компанию (а это уже выгодно государству), может больше времени проводить с семьей (счастливые семьи), может больше заниматься собой (спорт, хобби). Ну а может бухать в подъезде. Тут надо смотреть на общий уровень жизни в стране, отрасль и т.д.
Ой, да легко. Берешь supermicro, берешь xeon, память под все это дело, покупаешь OEM корпус, вставляешь все туда, ставишь х5 относительно самого дорогого ценника на аналогичное оборудование от именитых производителей и поставляешь. Рецепт, который с годами становится только крепче.
Интересным оказалось то, что 18 лет назад, в казалось бы, «дремучие» времена, в принципе уже было все
Как раз в районе 2000-2007 я бегал сначала с КПК Toshiba e405, а потом с Dell x50v — заказывал с ebay, когда в России про зарубежные заказы-то слышали только краем уха. И когда вышел первый айфон, у меня просто разрывало шаблон, зачем он нужен, если ничего не умеет? Я на своих КПК мог читать, слушать музыку и смотреть кино, имел доступ к ФС, у меня стоял dosbox с математическим пакетом Maple года так 1989, но он и такой версии спокойно мог считать всякие пределы, строить графики и все такое. Надо сказать, что работало все это быстро, были вполне качественные игры с неплохой 3d графиков. Плюс часто в КПК были съемные аккумы, поэтому проблема энергопотребления просто решалась дополнительным акком в сумке. И всем это при полноценной многозадачности!
И вот каким-то образом Microsoft умудряется это платформу просрать сначала Apple, а потом и Google. Эпл по широте поддерживаемого функционала, пожалуй, так и не догнал виндовсмобайла тех лет, а Андройд все-таки взял вверх удобством, функционалом и ценой, но, на мой взгляд, хорошо работать он стал только лет 5 назад, когда в телефоны стали ставить по 8 ядер и по 3+Гб оперативы (в КПК тех лет стояло по 32-64мб оперативы).
Не знаю, как другие хабровчане, но я уже давно настороженно отношусь к новым продуктам Гугла. Открыть, распиарить, свернуть — участь почти всех попыток Гугла что-то выкинуть на рынок. Reader, Code, Wave, +, iGoogle, Picasa, Нangouts и т.д. Есть очень интересный ЯП Dart, но тоже есть ощущение, то гугл хочется его ко всему остальному отправить.
Go и kubernetes — да, взлетели, но больше из последнего ничего вспомнить не могу. Карма у компании уже такая, что на все новые продукты смотришь «а, ну через 2 года закроют».
С версии 5.5.
Не знаю, насколько эта штука юзабельная, потому что потыкать не было возможности, но кажется, что для всяких симуляций выглядит вполне себе подходящим инструментом. Ну и плюс Qt со всеми ништяками, удобно.
Qt3D это средство для создания трехмерных презентаций
Это вы со студией их, наверное, путаете. Сейчас Qt активно продвигает свой модуль для работы с 3d графикой. Описание.
Ogre
После того, как основатель и бессменный лидер проекта Steve Streeting ушел по состоянию здоровья, движок очень затормозил. Вроде бы сейчас его тоже пилят, но как-то все медленно, половина вики не работает, а большое русское комьюнити просто развалилось. Жаль, я в свое время активно использовал этот движок и тоже делал на нем различные симуляции, и он был отличным.
OSG гибче, не зря создатели OpenMW мигрировали с него с Ogre.
Я как-то тоже решил для пробы (один небольшой проект) взять OSG, и тоже могу сказать, что работать с ним приятнее и стабильнее, чем с Огром. Работает именно так, как ожидаешь, что не скажешь о последних версия Огра.
Ну и OSG тоже до сих пор пишет автор движка, уже очень много лет.
В Windows Ogre для рендера использует DirectX
В Ogre3D используются OpenGL и DirectX 9/11, рендер можно выбрать.
Ну я бы не был столь категоричен. В edba 143 коммита, последний был 2.5 года назад, cppdb дальше cppcms не забралась и, видимо, поэтому была заброшена.
У soci 2450 коммитов, последний был пару месяцев назад, сам проект уже черти когда назад начал писаться. На самом деле, продукт зрелый.
Еще в Qt4 это сделали. И надо сказать, что Qt4 появился аж в 2005 году, 13 лет назад. А это времена, когда никаких умных указателей и потоков в GCC не было, не говоря уж про msvc.
Qt3 — это 2001 год. К слову, первый интелловский двухядерный процессор Pentium D и амдешный Opteron появились только в 2005. И я не уверен, что там была отличная аппаратная поддержка атомарных операций (во всяком случае, компиляторы точно не умели правильно генерировать код). В тоже время, Qt3 имеет поддержку потоков (треды, мьютексы, conditional variable и прочее). И мне кажется, вы слишком много просите для того времени.
Но, как по мне, лучше бы перешли на стандартную строку.
Конечно, нет. Строки в стандарте — это ужас. Вернее, как мы уже обсудили выше, строк как таковых в стандарте нет вообще.
На сколько я знаю, QString не умеет нормально работать с комбинированными символами, состоящими из двух двухбайтовых слов
Опять же, Qt давно имеет эти классы, на них уже написано много кода, они хорошо, логично и удобно реализованы. Зачем ломать удобные классы, только лишь потому, что в стандарте недавно появилось аналогичное?
Я за то, чтобы заменить заведомо костыльные вещи на что-то новое и удобное. moc — замечательный костыль своего времени, но сейчас его можно реализовать элегантнее, не сломав старый код. Слоты в Qt5, благодаря лямбдам, стали намного удобнее и красивее. Вот я за такие изменения.
Кстати, на Qt чаще ругаются не когда они вводят что-то новое (за это наоборот все радуются), а когда они что-то удаляют. Как было, например, с перехода QtWebKit на QtWebEngine. Вот тут у людей были болезненные переходы.
И еще есть момент. Qt очень часто голым используется в embedded устройствах, прям минуя STL. Если памяти довольно мало, то практически всегда выгоднее тащить с собой QtCore с огромным функционалом из коробки, вместо довольно голого STL.
Еще раз: возвращается количество объектов QChar. В кодировке UTF-16 при значения больше 65535 используется 2 объекта QChar (ну потому что стандарт так говорит). Вполне логично, что на запрос размера мне возвращается количество QChar.
std::wstring
Ага, только wchar_t в винде занимает 2 байта, а в никсах — 4 байта. Со всеми вытекающими проблемами отсюда.
Практически в 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 очень приятно и производительно.
Я на нем библиотеки книжек в FbReader читал, музыку слушал, инет серфал, в приличные игры играл, имел доступ к файловой системе, карты навигации стояли и т.д. DosBox у меня стоял с Maple 1987 года, в котором я считал всякие математические задачи.
Короче, все тоже самое, что и делаю сейчас. Да, навигация сейчас стала сильно лучше (а тормозит уже и на 8 ядрах и 6Гб), экраны приличнее, скорости быстрее, но не могу сказать, что я ощущаю какой-то прям качественный скачок в софте. Скорее, стало больше веба и сервисов, что сильно добавило функционала в оффлайн из онлайна (такси, доставки и т.д.), но основной набор софта на десктопе/мобиле у меня плюс-минус одинаковый десятилетиями.
В статье бросается в глаза то, что автор рассуждает о том, что софт сейчас в целом пишут лучше, а примеры почему-то железные приводит: был модем, стал гигабитный изернет, было 16 метров памяти, стало 16 гигов и т.д. Но дело в том, что железки действительно стали на порядки мощнее железок 20 летней давности, утилизация этих железок пропорционально возросла, а вот качество, полезная функциональность и быстродействие софта на эти порядки, увы, не возросли.
Стали ли анимация, свистелки-перделки и общий вид приложений лучше – ну, скорее, стали. Стали ли эти приложения больше занимать памяти и места, жрать больше CPU – да, тоже стали. Можно ли сказать, что потребляемые ресурсы эквивалентны добавленным возможностям – увы, далеко не всегда.
Сейчас довольно популярна тема – ну жрет мой блокнот 1гб памяти, и пусть жрет, сейчас же на машинах их 16-32Гб. А по итогу получается, что открыл Firefox на 100 вкладок, 2-3 экземпляра IDE с большим проектом, какую-нибудь GUI для гита – опа, а у тебя уже -15Гб рамы, и в своп уже просится. Ну блин, как так, вроде топовый ноут был 2 года назад, вроде бы и ничего фундаментально не изменилось, а он уже – старые дрова, которые еле тащат разработку.
Разработчики современных фреймворков – они же тоже больше про «простоту вхождения», чем про оптимизации. Вот если фреймворк взлетел, тогда да, можно начать думать и про это.
Простота вхождения дает нам больше разработчиков, больше идей, больше продуктов, сервисов и фич – звучит хорошо. С другой стороны, низкая подготовка кадров может приносить много багов, глюков и прочего – это плохо. Но т.к. «пластмассовый мир победил», и бизнес научился впаривать продукты любого качества, то прибыль за количество новых внедренных фич перевешивает убытки от добавленных глюков, прожорвости и т.д., то бизнес будет и дальше идти по, пока еще, прибыльному пути.
Вообще, я бы сравнил «борцов за оптимизацию» с разумными экологами. Вторые говорят, что заводы – это все тоже важно, нужно и прогресс, но давайте все-таки при этом не уничтожать все в округе, иначе через сколько-то лет нам придется решать другие, более сложные задачи. Если сейчас совсем не смотреть на разбухающий софт, то рано или поздно 95% утилизации мощностей компов уйдет в поднятие локальных серверов на каждый калькулятор, и жить сильно лучше не станет.
Дополнительные свободные день для человека могут привести к разным сложнопрогнозируемым профитам: он будет заниматься сторонними задачами, которые могут помочь решить какую-то задачу компании (вспоминаем про 20% времени для Гугл сотрудников), может запилить свою компанию (а это уже выгодно государству), может больше времени проводить с семьей (счастливые семьи), может больше заниматься собой (спорт, хобби). Ну а может бухать в подъезде. Тут надо смотреть на общий уровень жизни в стране, отрасль и т.д.
Как раз в районе 2000-2007 я бегал сначала с КПК Toshiba e405, а потом с Dell x50v — заказывал с ebay, когда в России про зарубежные заказы-то слышали только краем уха. И когда вышел первый айфон, у меня просто разрывало шаблон, зачем он нужен, если ничего не умеет? Я на своих КПК мог читать, слушать музыку и смотреть кино, имел доступ к ФС, у меня стоял dosbox с математическим пакетом Maple года так 1989, но он и такой версии спокойно мог считать всякие пределы, строить графики и все такое. Надо сказать, что работало все это быстро, были вполне качественные игры с неплохой 3d графиков. Плюс часто в КПК были съемные аккумы, поэтому проблема энергопотребления просто решалась дополнительным акком в сумке. И всем это при полноценной многозадачности!
И вот каким-то образом Microsoft умудряется это платформу просрать сначала Apple, а потом и Google. Эпл по широте поддерживаемого функционала, пожалуй, так и не догнал виндовсмобайла тех лет, а Андройд все-таки взял вверх удобством, функционалом и ценой, но, на мой взгляд, хорошо работать он стал только лет 5 назад, когда в телефоны стали ставить по 8 ядер и по 3+Гб оперативы (в КПК тех лет стояло по 32-64мб оперативы).
В общем, старое — это не всегда плохо.
Go и kubernetes — да, взлетели, но больше из последнего ничего вспомнить не могу. Карма у компании уже такая, что на все новые продукты смотришь «а, ну через 2 года закроют».
С версии 5.5.
Не знаю, насколько эта штука юзабельная, потому что потыкать не было возможности, но кажется, что для всяких симуляций выглядит вполне себе подходящим инструментом. Ну и плюс Qt со всеми ништяками, удобно.
Это вы со студией их, наверное, путаете. Сейчас Qt активно продвигает свой модуль для работы с 3d графикой. Описание.
После того, как основатель и бессменный лидер проекта Steve Streeting ушел по состоянию здоровья, движок очень затормозил. Вроде бы сейчас его тоже пилят, но как-то все медленно, половина вики не работает, а большое русское комьюнити просто развалилось. Жаль, я в свое время активно использовал этот движок и тоже делал на нем различные симуляции, и он был отличным.
Я как-то тоже решил для пробы (один небольшой проект) взять OSG, и тоже могу сказать, что работать с ним приятнее и стабильнее, чем с Огром. Работает именно так, как ожидаешь, что не скажешь о последних версия Огра.
Ну и OSG тоже до сих пор пишет автор движка, уже очень много лет.
В Ogre3D используются OpenGL и DirectX 9/11, рендер можно выбрать.
Придется столкнуться с малым количеством комментариев, но это нынче нормальное явление на Хабре с техническими статьями. От этого они хуже становятся.
К слову, парни, которые пишут открытый Morrowind, в свое время перешли с Ogre3D на OSG и остались очень довольны.
У soci 2450 коммитов, последний был пару месяцев назад, сам проект уже черти когда назад начал писаться. На самом деле, продукт зрелый.
Еще в Qt4 это сделали. И надо сказать, что Qt4 появился аж в 2005 году, 13 лет назад. А это времена, когда никаких умных указателей и потоков в GCC не было, не говоря уж про msvc.
Qt3 — это 2001 год. К слову, первый интелловский двухядерный процессор Pentium D и амдешный Opteron появились только в 2005. И я не уверен, что там была отличная аппаратная поддержка атомарных операций (во всяком случае, компиляторы точно не умели правильно генерировать код). В тоже время, Qt3 имеет поддержку потоков (треды, мьютексы, conditional variable и прочее). И мне кажется, вы слишком много просите для того времени.
Конечно, нет. Строки в стандарте — это ужас. Вернее, как мы уже обсудили выше, строк как таковых в стандарте нет вообще.
QString::fromWCharArray
Опять же, Qt давно имеет эти классы, на них уже написано много кода, они хорошо, логично и удобно реализованы. Зачем ломать удобные классы, только лишь потому, что в стандарте недавно появилось аналогичное?
Я за то, чтобы заменить заведомо костыльные вещи на что-то новое и удобное. moc — замечательный костыль своего времени, но сейчас его можно реализовать элегантнее, не сломав старый код. Слоты в Qt5, благодаря лямбдам, стали намного удобнее и красивее. Вот я за такие изменения.
Кстати, на Qt чаще ругаются не когда они вводят что-то новое (за это наоборот все радуются), а когда они что-то удаляют. Как было, например, с перехода QtWebKit на QtWebEngine. Вот тут у людей были болезненные переходы.
И еще есть момент. Qt очень часто голым используется в embedded устройствах, прям минуя STL. Если памяти довольно мало, то практически всегда выгоднее тащить с собой QtCore с огромным функционалом из коробки, вместо довольно голого STL.
Ага, только wchar_t в винде занимает 2 байта, а в никсах — 4 байта. Со всеми вытекающими проблемами отсюда.
Все-таки внутри 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 позволяет такие вопросы решать из коробки очевидными способами.
А вот почему этого всего нет в стандарте — вопрос действительно хороший.
В первую очередь — из-за ограничений языка. Сейчас-то и moc уже не нужен, есть реализация от авторов оригинального moc'a чисто на шаблонной магии и новых стандартах. Я тоже надеюсь, что велосипеды будут потихоньку заменяться на стандарт, а новые фичи будут упрощать код. Но все же даже сегодня писать на Qt очень приятно и производительно.
Насчет UTF-16 — да, думаю, из-за винды. UTF-32 в винде почти нигде не используется, поэтому неудивительно, что выбрали средний вариант.