LINUX.ORG.RU

Сочетание различных библиотек C++

 , ,


1

5

Здравствуйте, ЛОРчане.

Из того, с чем я работаю и учусь работать, в повседневной жизни я часто сталкиваюсь с 3 библиотеками : STL, Qt, Boost. Так получается, что функциональность у них в некоторых вопросах пересекается, взять хотя бы те же потоки(boost.pthread, std::thread, QThread).

Так вот, чему отдавать предпочтение? То есть допустим, что так получается, что в проекте нужно использовать эти 3 либы(пусть предположим, что от буста возьмём Graph, от культи интерфейсы как мимнимум, да и много чего там вкусного есть, ну от STL я так думаю можно тоже чего-нибудь взять).

В своём проекте я часто сталкиваюсь с ситуацией, что надо что-то выбирать из STL или из Qt : std::string vs QString, std::vector vs QVector. Но я не могу выработать правильную стратегию, когда и что стоит применять? Стоит ли, если используешь Qt, стараться по максимуму её юзать? Или стоит писать на смеси STL и Qt? Это касается естественно не только этих либ, но и других.

Как правильно поступают в таких ситуациях?

★★

Последнее исправление: zamazan4ik (всего исправлений: 1)

Ответ на: комментарий от anonymous

Вкусовщина конечно, но:

но:

out << std::distance(v.begin(), lower_bound(v.begin(), v.end(), num) << endl;

всё-равно длиннее, но никто не запрещает писать и использовать собственные библиотеки:

auto index_of(auto v, auto x)
{
  auto ix = std::find_if(begin(v), end(v), x);
  return ix != end(v) ? std::distance(begin(v), ix) : -1;
}
Begemoth ★★★★★
()
Последнее исправление: Begemoth (всего исправлений: 1)
Ответ на: комментарий от anonymous

2) Зачем мне писать свою либу, если есть Qt?

А у вас с лицензией на Qt все нормально? Или вы только OpenSource пишете?

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Зачем мне писать свою либу, если есть Qt?

Так что там у Qt-шных контейнеров с типами без конструктора по-умолчанию и алокаторами? Всё так же не поддерживает? Тогда вопрос надо формулировать так: зачем кривые костыли из Qt есть есть нормальные средства стандартной библиотеки?

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

С типами без конструкторов по умолчанию как-то не сталкивался.

Аллокаторы нужны в очень редких случаях.

В остальных случаях лучше использовать удобные классы без создания своих велосипедов.

нормальные средства стандартной библиотеки

Средств там как раз и нет. На любой чих нужно тянуть сторонние либы, так почему бы сразу не использовать Qt?

http://doc.qt.io/qt-5/qtcore-module.html

Вот сколько вкусностей в QtCore. И они все на всех платформах работают одинаково, без хитрых нюансов платформ и компиляторов, как у std.

anonymous
()
Ответ на: комментарий от anonymous

1) ...
2) ...

хрень какая. Давай тогда все говно, которое любому школьнику в голову взбредет в контейнеры тащить. ну а чо? Давай функции, которые среднее арифметическое считают например, давай статистику к кадому контейнеру прикручивать. И всем будет зашибись

На любой чих нужно тянуть сторонние либы,
так почему бы сразу не использовать Qt?

молодца во взаимоисключающие параграфы умеешь. Учти еще весь тот хлам, который эта core с собой притащит.

anonymous
()
Ответ на: комментарий от anonymous

LGPL же.

Ну т.е. Qt автоматически отпадает, если нужно получить исполняемый файл, статически слинкованный с нужными ему библиотеками.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Не очень и нужно. Особенно обновления таких монстром производить очень круто.

PS: Qt 5 умеет в LGPLv3 где можно линковать статически.

anonymous
()
Ответ на: комментарий от anonymous

школьнику
Qt

Ну-ну, школьнички.

Если есть задача написать приложение - нет смысла изобретать свои контейнеры и классы на каждый чих. А если нужен очень тонкий контроль над работой проги и всех ее классов - то тут и std не нужен. Привет -nodefaultlibs и написание своих контейнеров.

anonymous
()
Ответ на: комментарий от anonymous

Qt 5 умеет в LGPLv3 где можно линковать статически.

И как это соотносится вот с таким требованием, описанным в FAQ-е Qt:

The user of your application has to be able to re-link your application against a different or modified version of the Qt library. With LGPLv3 it is also explicitly stated that the user needs to be able to run the re-linked binary on it’s intended target device. It is your obligation to provide the user with all necessary tools to enable this process. For embedded devices, this includes making the full toolchain used to compile the library available to users. For parts licensed under LGPLv3 you are obliged to provide full instructions on how to install the modified library on the target device (this is not clearly stated with LGPLv2.1, although running the application against the modified version of the library clearly is the stated intention of the license).

Каким образом вы предоставите возможность пользователю перелинковать ваше приложение с другой версией Qt, если вы слинковали его статически?

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Как-как, выдавать объектники по требованию.

Ну OK, пусть будет по требованию (хотя есть в этом сомнения). Является ли это достаточно веской причиной не использовать Qt в случаях, когда есть аналоги из std?

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

lower_bound

Мелкая придирка: lower_bound требует отсортированной последовательности, а indexOf, кажется, нет. То есть эквивалентный код будет с std::find. А вот «встроенного в QVector» аналога lower_bound нет. Есть отдельный qBinaryFind, который, кстати, предлагается заменить на стандартный вариант.

Ну и auto для итератора ты сознательно не использовал, чтобы многословность увеличить?

Итераторы во многих случаях эффективнее, но их использование просто ужасно.

Более-менее согласен, с поправкой, что не «ужасно», а «менее удобно». Опять же, плата за гибкость - алгоритмы можно делать внешними. Диапазоны (когда-нибудь) сделают ситуацию более приятной.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Так у std нет аналогов QtCore. Вектор, мап? Ну ок, кому-то может и нравиться. Больше ничего в std нет. Строк нет, io/fs нет, потоков нормальных нет, атомик кривой, работа со временем через одно место, какого-либо цикла событий нет, json/xml/ini нет (не критично, ок), возможностей запуска дочерних процессов нет вообще (ака QProcess), регулярки куцые, какого-либо аналога QVariant нет, возможности локализации нет.

anonymous
()
Ответ на: комментарий от anonymous

Вектор, мап?

+ deque, list, forward_list, set/multiset, multimap, unordered_map/multimap/set/multiset.

потоков нормальных нет

Какие проблемы с std::thread?

атомик кривой

Какие проблемы с std::atomic?

Все остальное есть в сторонних библиотеках. Под более простыми в использовании лицензиями.

eao197 ★★★★★
()
Ответ на: комментарий от DarkEld3r

А смысл, все равно криво и длинее:

out << distance(v.begin(), lower_bound(v.begin(), v.end(), num) << endl;
qDebug() << v.indexOf(num);

Я не спорю, что есть случаи, когда итераторы более гибкие, но общем случае это трудночитабельная мешанина.

Мелкая придирка

код стырил по первой ссылке на SO

anonymous
()
Ответ на: комментарий от anonymous

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

Зато видно «уровень» Qtшника

anonymous
()
Ответ на: комментарий от DarkEld3r

Какова вероятность, что код написанный под gcc запуститься без правок на msvs? Гугл забит этими проблемами. Очень много кода попадалось с #if defined(_MSC_VER) или, не дай бог, __BORLANDC__.

В том же gcc, до недавних пор, строки были реализованы не по стандарту, со счетчиком ссылок.

std::shared_ptr работает по разному, в зависимости от того, подключен pthread или нет.

Это только то, с чем я сталкивался лично.

anonymous
()
Ответ на: комментарий от XMs

Так icu и так почти везде кроме офтопика штатно установлена обычно.

Gorthauer ★★★★★
()
Ответ на: комментарий от anonymous

Ну да, куда мне до адептов. Ведь в любом приложении с вектором из 5-и элементов нужно использовать только самый эффективный, а не удобный для поддержания и понимая кода, метод.

anonymous
()
Ответ на: комментарий от Begemoth

А ежели в 17ом стандарте ещё и unified call syntax приделают, то этот index_of можно будет сделать «методом» любого контейнера.

Gorthauer ★★★★★
()
Ответ на: комментарий от anonymous

Какова вероятность, что код написанный под gcc запуститься без правок на msvs?

постоянно собираю. И не только gcc, но и clang и багленд (да, есть еще такие извращенцы, кто это пользует). И не только под венду, но и под arm и spark

Откуда вы такие сказочные проблемы ваще берете? Единственные грабли в студии - это либы. Например нельзя просто взять релизную x64 либу openssl и собрать в дебажный x64 проект, оно тупо валится на старте.

anonymous
()
Ответ на: комментарий от anonymous

И не только под венду, но и под arm и spark

Странно - собираешь под SPARC, а название архитектуры пишешь с ошибкой.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Ведь в любом приложении с вектором из 5-и элементов

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

anonymous
()
Ответ на: комментарий от anonymous

То-то сорцы Qt исписаны ifdef'ми под каждый компилятор и ОС.

anonymous
()
Ответ на: комментарий от anonymous

Аргументы кончились - переходим на личности? Все понятно с вашим уровнем.

Дооооо, поиск элемента в векторе - это невозможная задача. Сейчас еще окажется что и unicode не нужен и пойдёт и поедет.

anonymous
()
Ответ на: комментарий от anonymous

это невозможная задача.

это РЕДКАЯ задача. Такая же, как поиск среднего арифметического, например. Есть в Qt поиск среднего арифметического в векторе? а поиск средней длины слова? а подсчет статистики символов в строке? а есть в Core возможность парсить протобуфер? нет? так Qt же отстой, если этого там нет!

anonymous
()
Ответ на: комментарий от anonymous

Редкая для вас, но не для всех. Имхо, это самая распространенная задача.

QtCore содержит много лишнего, факт, но в нем есть минимальный функционал, который упрощает работу, а не усложняет ее, как std.

anonymous
()
Ответ на: комментарий от anonymous

поиск среднего арифметического в векторе
а поиск средней длины слова
а подсчет статистики символов в строке

Редкая для вас, но не для всех

В Qt нет — Qt - отстой, потому что усложняет решение этих задач.

клевая логика, чо.

anonymous
()
Ответ на: комментарий от anonymous

но общем случае это трудночитабельная мешанина.

Ну не настолько всё плохо всё-таки. Ну да ладно, мы вряд ли убедим друг друга.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Какова вероятность, что код написанный под gcc запуститься без правок на msvs?

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

И наоборот код с использованием STL будет работать нормально пока мы сами не начнём втыкать всякие #if defined(_MSC_VER).

В том же gcc, до недавних пор, строки были реализованы не по стандарту, со счетчиком ссылок.

Да, но если не делать «что-то особенное», то пользовательскому коду было без разницы.

std::shared_ptr работает по разному, в зависимости от того, подключен pthread или нет.

А какая разница в наблюдаемом поведении?

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

А какая разница в наблюдаемом поведении?

Атомарные операции медленнее.

писать на Qt с дефайнами никто не запрещает

Так там уже все костыли за меня сделали.

anonymous
()
Ответ на: комментарий от anonymous

Атомарные операции медленнее.

Не уверен, что это можно считать «работает по разному».

Так там уже все костыли за меня сделали.

Зависит от потребностей, но речь не об этом, а о том, что и на Qt и на stl можно писать как переносимо так и нет. То что у Qt «больше всего» не спорю.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Имхо, это самая распространенная задача.

Хм... в моей практике самая распространённая задача для векторов - это их обход. (:

DarkEld3r ★★★★★
()

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.