Во-первых, невозможно STL-ем создавать десктопные приложения с GUI. Во-вторых, Qt генерирует не дублирующийся код для мета-информации, и только если вы создаете типы с мета-информацией. В-третьих, накладные расходы Qt, это плата за управление памятью за вас (я не хочу тратить время на тривиальные решения по управлению памятью, хоть это и даст мне 10-15% производительности, а в нагрузку еще дополнительное времени на отладку и сопровождение этих решений). STL «раздувает» код там где это совершенно не обязательно — если у вас много типов одинакового размера, вся информация о типах пропадает после компиляции, и код контейнеров не будет различаться даже размерами смещений. Или если один и тот же шаблон в разных исполняемых файлах и/или динамических библиотеках, то это просто дублирование одинакового кода. Я не говорю что это так для всех реализаций STL, существуют реализации где есть не-шаблонная основа (подобно Qt), но сколько компиляторов, столько и реализаций (это кстати тоже было минусом, когда разные реализации стандартной библиотеке были разной степени «стандартности»).
Забыть скопировать строку можно если она не передана по const&, а сидит в структуре данных по указателю. А как вы работаете со сложными структурами данных без указателей? Пересоздаете всю структуру если нужно заменить один объект на который она ссылается? Нет, можно писать программы и без указателей и даже без единого побочного эффекта, но зачем для этого использовать C++?
Тут проблем несколько, если у вас не один исполняемый файл, а много и/или динамические библиотеки, то тут избежать дублирования невозможно. Во вторых если у вас много типов одинакового размера, то результирующий машинный код по-сути будет различаться только константами размеров и смещений, тут тоже даже в одной единице компиляции будет по сути одинаковый код. Это проблема всех header-only шаблонов. Тот же QVector отличается от std::vector тем что в QVector есть не-шаблонная основа, работающая с void-указателями и байтовыми размерами, а сам QVector — это шаблонная обёртка дающая безопасность типов. И при развертывании от нее остаются только размеры типов и смещения. Но QVector «тяжелее» std::vector в том что он добавляет еще механизм copy-on-write и ведет себя как объект, которое можно передавать по значению без фактического копирования содержимого, хотя на самом деле копирование просто откладывается до первой модификации содержимого.
Код, которому нужны потоки использует реализацию многопоточности, неужели это вас удивляет? Если вам не нужен функционал Qt, вы вообще не используете Qt, в чем проблема? Qt поддерживает ститическую компоновку (как и любая библиотека C++), это если вас смущает необходимость тащить всю DLL. Любая релизация стандартной библиотеки C++ (та что не header-only) ровно также ломается если приложение собиралось с другой версией. Это общая проблема бинарной совместимости вообще любой библиотеки C++. Любое приложение на C++ под Windows поставляется вместе с msvcrt, потому что 99% функционала завязано на стандартной библиотеке.
Как защитная плита может защитить двигатель межзвездного корабля? Например, сама являясь частью двигателя. В проекте «Орион», двигатель состоял из массивной плиты принимающей ядерный взрывы от минизарядов. Если эти минизаряды выпускать не по курсу, а под углом, то защищенность на встречном курсе будет максимальной. Более того можно сделать по двигателю с обеих концов корабля и не разворачиваться при торможении, ведь двигатель — это по сути массивная плита с системой доставки ядерных минизарядов. При разгоне заряды доставляются на корму, при торможении — на нос, а плиты двигателей служат одновременно и защитным экраном.
Как наличие, условно, 25 виджетов вместо 10, может навредить? Или поддержка этими виджетами многопоточности? Или интегрированная с этими виджетами библиотека мультимедиа? Извините, я вас не понимаю.
А как же разворачивание шаблонов? STL генерирует много дублирующего кода. Его оптимизация нигде не стандартизирована, а в случае с динамическими библиотеками — невозможна. Использовать стандартные контейнеры без указателей на них возможно только в примерах. На практике, вы будете заворачивать их в смарт-указатели («вот здесь накладные расходы на счетчик ссылок») либо управлять памятью вручную (огромный привет отладчику). Это уже — "+1 уровень индирекции". Там где строку надо копировать для изменения, это очень не факт что вы не забудете ее скопировать, ошибка «алиасинга» данных не просто так одна из самых распространенных в программировании. Если придерживаться правил (не изменять контейнеры в цикле вне итераторов, не разыменовывать нулевые указатели и т.п.) и следовать шаблонам использования Qt, сложностей не возникает. Опять же, следуя правилам и шаблонам у вас не возникнет ситуации с нарушением гарантии алгоритмической сложности операций. Но да, в некоторых случаях в STL меньше накладных расходов чем в Qt, хотя упрощение процесса разработки сильно перевешивает, по крайней мере, для меня. STL не избавляет вас от ручного управления памятью, так что платить вы будете в итоге столько же если не больше, чем в Qt. Qt здесь «срезает углы», беря не себя больше управления памятью чем STL, для меня это плюс. Если для вас это минус, возможно вы просто мало кода на С++ писали.
Каким образом фраза «а теперь возьмите напишите библиотеку на Qt и попробуйте её распространить...» соотносится с моим утверждением, что «Qt это единственная библиотека GUI на С++ имеющая полный набор необходимых возможностей»? Я не понял что вы хотели сказать.
Библиотека стала бы меньше, а создаваемый код — больше, именно из-за того что STL-контейнеры — это header-only, что ведет к «распуханию» скомпилированного кода (особенно в больших проектах не сводящихся к одному исполняемому файлу). Мне нравится в контейнерах Qt то что у них есть не-шаблонная основа, которая не будет каждый раз разворачиваться вместе с шаблоном. И, да, интерфейсы конечно же упростились бы на пару строк. Но, на практике, чаще нужен интерфейс с библиотекой С, а не С++. А, извиняюсь, где вы в Qt засилье сырых указателей увидели? Одним из плюсов Qt, в плане разработки, как раз и является избавление от большей части ручного управления памятью. Как пример, тот же std::string, рано или поздно вам придется передавать его по указателю чтобы избавится от копирования данных, ссылок (даже с учетом новой семантики перемещения) надолго не хватит. QString, с другой стороны, является по сути указателем семантики COW (copy-on-write) на строку, завернутым в класс, и передача его по значению грозит только накладными расходами на счетчик ссылок (который у вас тоже появится, если вы все же откажетесь от ручного управления std::string* и перейдете на std::shared_ptr).
Ну как я писал — «либо шашечки, либо ехать». Практическая ценность Qt пока очень сильно перевешивает «академическую правильность» стандартной библиотеки, в области десктопных приложений :-).
Есть две библиотеки, одна — исключения бросает, вторая — коды ошибок возвращает. Вам они нужны. Но они бинарно несовместимы. Помните, «если вы это не используете, вы за это не платите»? Поэтому «адаптер» вам не поможет, там все не так просто. Здесь вовлечены такие вещи как «отвинчивание» стека и деструкторы. Вам придется копировать данные между этими библиотеками вручную, а если там еще и обратные вызовы нужны… Короче, вам придется целую третью библиотеку для этого написать и на месяц «загулять» в отладке.
Надо кстати рассмотреть этот вариант :-) Но для Python есть привязки огромного числа библиотек, которые легко использовать. Для меня очень удобна простота Python, можно быстро писать прототипы приложений, различные утилиты под конкретную задачу.
Этот оператор присваивания очень бы пригодился в объявлениях переменных. Создаем переменную с помощью ":=", а далее меняем ей значения обычным "=", т.е. если вы опечатались в инструкции "=", это не создаст новую переменную, а вызовет ошибку.
А в C++ у вас не получится «по науке». Либо шашечки, либо ехать. Там есть такой принцип — «если вы это не используете, вы за это не платите». Это значит, что если ваша библиотека не использует, к примеру исключения, то объединить ее с другой, использующей их, будет почти невозможно и обязательно это будет получаться только через жо.. это самое. Нет, можно конечно учесть «все пожелания», но на выходе получится трудноуправляемый монстр с кучей параметров конфигурации, обмазанный макросами и шаблонами до полного FUBAR'a.
А может и не выполнятся за линейное время; так себе аргумент. Qt это единственная библиотека GUI на C++ имеющая полный набор необходимый возможностей. То что она не использует контейнеры STL, трудно назвать недостатком. Ну допустим применялась бы в Qt стандартная библиотека. Это бы хоть-как то помогло с интеграцией ее с другой сторонней библиотекой, также использующей стандартную библиотеку C++? Практика показывает что нет. А семантика перемещения, это свойство самого языка и контейнеры Qt тоже смогут ее применять; некоторые методы ее уже используют.
Извините, но Вы живете в мире розовых единорогов и с реальной разработкой на C++ лично не знакомы? Какое «брать реализации необходимых компонент и комбинировать их» на C++? Это не всегда возможно даже в таких языках как C# и Java, которые проектировались с этой парадигмой. А в C++, «задачей языка — предоставлять для этого возможность» изначально не было (да и сейчас с этим — очень, не очень). Разработками своими собственными уникальными и неповторимыми решениями уже решенных задач весь Гитхаб забит (на всех языках). Извините, но вы реально витаете где-то в облаках «идеального мира программирования». Trolltech уже много лет никакого отношения к Qt не имеет, значит и о Qt вы знаете только понаслышке.
Почему это QVector ненужный велосипед, а не std::vector? В QVector, к примеру, можно настроить копирование POD элементов через системный intrinsic, а в std::vector это делается только через стандартные конструкторы копирования. И морочить голову с передачей std::vector туда-обратно не нужно, все методы уже есть в QVector, с самого его появления. Кроме того, в отличие от std::vector, QVector это не header-only класс, а значит его использование не приводит к «распуханию» результирующего кода, что актуально в больших проектах (потому как контейнеры — это базовые «кирпичики» и применяются на всех уровнях).
Нет не выходит, ну вот никак. Вы используете Qt для графического интерфейса и вам нужна базовая многопоточность, тогда за каким… извиняюсь, вам тянуть специализированную библиотеку, и жаловаться что «оно кривое», если ваше изначальное решение использовать для «базовой» многопоточности «специализированну» библиотеку — кривое. Если же вам нужна «не-базовая» многопоточность, то тут уже что Qt, что не Qt, а интегрировать сторонню графическую библиотеку со сторонней библиотекой многопоточности придется (если этого за вас уже не сделал кто-то другой, а в случае библиотек C++ — можете быть почти уверенны что нет).
Информация о символах есть всегда. В тех же объектных файлах, или как вы себе представляете работу компоновщика? То что сам язык об этом не знает, это большой минус языка. С другой стороны, если язык ограничен в ресурсах, а C был системным языком для ограниченных в ресурсах платформ, то поэтому делегирование такого знания компоновщику было элегантным решением. Но для C++ это — тяжелое наследие детства с «игрушками прибитыми к полу» минимальной рудиментарной системой модулей (те же объектные файлы и т.н. «библиотеки» — архивы объектных файлов).
Эти слова-синонимы tolerate из вебстеровского словаря заменяют этот-самый tolerate именно в значении «допускать», «терпеть». Особенно suffer, здесь не просто страдать, а именно что «терпеть» (в «страдательном» смысле). То есть, tolerate — это таки полный семантический эквивалент «терпеть». В русском синонимом «терпеть» является другое русское слово — «выносить», а отсюда ноги растут в этих 20% endure (в физическом смысле) google-переводчика, который является «машинным» переводчиком. (что это значит объяснять на этом ресурсе не нужно же?)
Я, помню, читал об этом эксперименте на одном «развлекательном» ресурсе, там, кстати, было очень доходчиво объяснено. В этом эксперименте была еще одна важная, не упомянутая вами, деталь — в момент когда шест находился внутри, сарай запирался с обеих концов одновременно. Но эта одновременность только с точки зрения стороннего наблюдателя, как и релятивистское сокращение длины шеста. То есть сторонний наблюдатель (покоящийся относительно всего этого цирка с шестом и сараем :-) видит что шест (летящий с околосветовой скоростью) сократился в длине и поместился в сарай двери которого одновременно мгновенно закрылись, и тут же мгновенно открылись, а шест полетел дальше. Но вот с точки зрения шеста, он не сократился, а сократилась длина сарая, но двери сарая не закрылись одновременно, а сначала закрылась (и тут же открылась) дальняя дверь когда передний конец шеста зашел в сарай и шест пролетел дальше без препятствий, а затем закрылась (и тут же открылась) задняя дверь сарая когда задний конец шеста зашел в сарай. Этот момент наглядно иллюстрирует связь пространства со временем и почему пространство-временной континуум называется именно пространственно-временным. То есть одно и то же явление — это и релятивистское сокращение длины, и изменение течения времени, в зависимости от точки отсчета.
Что это за зверь такой «открытая внешняя компоновка»? C++ единственный язык который до сих пор не имеет концепции модулей, которая даже старше ООП и появилась с изобретением процедурного и структурного программирования. Чтобы использовать библиотеки в C++ нужно как в С лезть на низкий уровень и заниматься флагами компилятора, служебными макросами (#ifdef/#endif), включением исходных файлов (в C это оправдано, поскольку язык предназначен для системного программирования и прекрасно для этого подходит). Еще «лучше», т.н. header-only библиотеки, которые часто используют еще и шаблоны что приводит к непомерному дублированию кода, ведь полная оптимизация возможно только в полностью функциональном языке, но никак не в императивном.
Забыть скопировать строку можно если она не передана по const&, а сидит в структуре данных по указателю. А как вы работаете со сложными структурами данных без указателей? Пересоздаете всю структуру если нужно заменить один объект на который она ссылается? Нет, можно писать программы и без указателей и даже без единого побочного эффекта, но зачем для этого использовать C++?
жо..это самое. Нет, можно конечно учесть «все пожелания», но на выходе получится трудноуправляемый монстр с кучей параметров конфигурации, обмазанный макросами и шаблонами до полного FUBAR'a.Почему это QVector ненужный велосипед, а не std::vector? В QVector, к примеру, можно настроить копирование POD элементов через системный intrinsic, а в std::vector это делается только через стандартные конструкторы копирования. И морочить голову с передачей std::vector туда-обратно не нужно, все методы уже есть в QVector, с самого его появления. Кроме того, в отличие от std::vector, QVector это не header-only класс, а значит его использование не приводит к «распуханию» результирующего кода, что актуально в больших проектах (потому как контейнеры — это базовые «кирпичики» и применяются на всех уровнях).
«игрушками прибитыми к полу»минимальной рудиментарной системой модулей (те же объектные файлы и т.н. «библиотеки» — архивы объектных файлов).