Igors, это ты? :)

[ssoft]

у них дизайн одинаковый.

простой вопрос:
в чем принципиальное различие между стилями программирования:
"асинхронным однопоточным" и "синхронным многопоточным"?

простой ответ:
принципиальной разницы не существует.

меня удивляет, что находятся персонажи, которые этого не догоняют.
и начинают нести всякий бред про "асинхронку в одном потоке, и epoll, который пинает евент луп"

учитывая, что система, о боже! однопоточная, эвент луп у них, наверное,
в сферическом вакууме крутиццо.

А меня удивляют персонажи которые не догоняют разницу).

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

[Igors]

А меня удивляют персонажи ...

Ну если уж все свалилось в треп, то предлагаю такую темку

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

- ну конечно, Qt. Не считая мелких "жестов вежливости" позиция разработчиков ясна "чтобы духу тут std-шного не было!". Даже контейнеры свои (и с успехом)

- GStreamer - ну тут до std дело просто не нашло, суровый "С" (статУя вообще без плюсов)

- FBX  (фактически стандарт обмена данными между 3D приложениями). API никакого std не использует

Вспоминая предыдущие 5 лет - то же самое. Ну да, одна либа юзала std::string и std::vector, другая - только std::vector (впрочем и то в примерах). И это ВСЕ. Может я мало юзаю всякие либы (по мне чем меньше - тем лучше). Ну может и так. А может все проще - эта функторная срань никому не нужна? Может все хотят писать нормально, естественно, а не захлебываться итераторными соплями?

[ssoft]

Ну если уж все свалилось в треп, то предлагаю такую темку
...
Вспоминая предыдущие 5 лет - то же самое. Ну да, одна либа юзала std::string и std::vector, другая - только std::vector (впрочем и то в примерах). И это ВСЕ. Может я мало юзаю всякие либы (по мне чем меньше - тем лучше). Ну может и так. А может все проще - эта функторная срань никому не нужна? Может все хотят писать нормально, естественно, а не захлебываться итераторными соплями?

Когда я был маленький ... )))

Изначально (до C++11) конструкций std было недостаточно, чтобы покрыть большУю часть задач.
Не было atomic, thread, function, mutex, unordered_map, turple и др. Не говоря уже о самом языке (rvalue, variadic template, thread-safe static и т.п.).
Приходилось писать много чего самостоятельно. Сколько всяких велосипедов изъезжено  . Зато сколько опыта и знаний получено!

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

Тем не менее sdt C++ стал заметно богаче и кое-где эффективнее, чем раньше.
В своих проектах потихоньку переползаю на std, оставляя Qt только для GUI.

[ViTech]

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

- ну конечно, Qt. Не считая мелких "жестов вежливости" позиция разработчиков ясна "чтобы духу тут std-шного не было!". Даже контейнеры свои (и с успехом)

Так трудно использовать то, чего нет . До С++11 в std особо ничего и не было, вот все свои велосипеды и писали. Теперь может кутешники и рады бы на контейнеры std перейти, да кто за такой рефакторинг возьмётся? Обратная совместимость опять же. Есть ли проекты на С++, рождённые после 2015г., которые бы свои контейнеры изобретали или std принципиально не использовали? И, на всякий случай, много ли их по с равнению с теми, что std используют .

А может все проще - эта функторная срань никому не нужна? Может все хотят писать нормально, естественно, а не захлебываться итераторными соплями?

Лично мне вот нужна. И судя по тому, что это появляется в стандарте, то это ещё кому-то нужно (вряд ли такие нововведения только ради меня одного ). Мне с каждым новым стандартом писать становится всё нормальнее и естественнее. Выходило бы это только всё побыстрее и в компиляторах поддерживалось. Но обкатка временем тоже нужна, придётся смириться.

[Авварон]

А может все проще - эта функторная срань никому не нужна? Может все хотят писать нормально, естественно, а не захлебываться итераторными соплями?

Ну например, из недавнего. Раньше было:

Код:

void Wrapper::callMethod(QString foo, QString bar)
{
    QMetaObject::invokeMethod(worker, "method", Q_ARG(QString, foo), Q_ARG(QString, bar));
}

Стало

Код:

void Wrapper::callMethod(QString foo, QString bar)
{
    auto methodFunc = [this, foo, bar]()
    {
        worker->method(foo, bar);
    };
    QMetaObject::invokeMethod(worker, methodFunc);
}

Убрались богомерзкие Q_ARG, теперь findUsages находит method в лямбде, а раньше не находил, ибо но был строкой.

[ViTech]

Код:

void Wrapper::callMethod(QString foo, QString bar)
{
    auto methodFunc = [this, foo, bar]()
    {
        worker->method(foo, bar);
    };
    QMetaObject::invokeMethod(worker, methodFunc);
}

О, кто-то ещё invokeMethod использует . На такой баг не попадали? А то складывается впечатление, что через invokeMethod никто ничего уникального(некопируемого) не передаёт. Или всем пофиг .

[Авварон]

ViTech
Пффф, юник_птр в QVector не положишь, а тут инвок вы хотите. Ишь чего!

[Igors]

Так трудно использовать то, чего нет . До С++11 в std особо ничего и не было, вот все свои велосипеды и писали.

А по-моему все (немногое) хорошее в std было уже лет 20 назад. Тот же вектор, мап, сет, лист и десятка 2 по-настоящему хороших ф-ций (как напр lower_bound, nth_element и др). Основа любого проекта - такие простые данные, без них-то никак не обойтись. Ну конечно что "абсолютно необходимо" - всегда спорно. Напр может шаред органически не хватало, рисовать ++refCount приходилось частенько.

Ах, да это же ну очень простые, да чего там - примитивные вещи! Нам (эстетам) нужно намного больше! Не верю. Какой-нибудь задроченый тупл никогда не сделает  "погоды" в проекте. Может быть он поможет лучше (компактнее, проще и.т.п.) что-то решить, но это было и останется мелкой технической деталью - forever. Ну а если уж так необходимо - то кто хотел давно нашел (в Qt, boost и.т.п).

Общие вещи никогда не будут "в единственном числе", альтернатива всегда найдется. И сравнение совсем не в пользу std. Тот же std::thread - он же QThread в подметки не годится. И появился всего-то  лет через 15 (?) существования std. Дошло наконец что кросс-платформенное создание нитки все-таки нужно. Ну и слава богу, "лучше поздно чем никогда"

Есть ли проекты на С++, рождённые после 2015г., которые бы свои контейнеры изобретали или std принципиально не использовали? И, на всякий случай, много ли их по с равнению с теми, что std используют .

Человек весьма уверен что он "на правильном пути" Я никогда не увлекался либами и использую только когда "ну вот совсем никак без нее" (жизнь заставляет). Тем не менее я привел 3 либы широко известные и доказавшие свою эффективность. Могу привести еще десяток, хотя никакой я не эрудит. А можно услышать хотя бы об одной написанной на std? Или оно больше для любительского программирования (начитаться и поумничать) ?  Или все еще идет "процесс обкатки" (ну да, понимаю, дело не быстрое)

Ну например, из недавнего. Раньше было:

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

[ViTech]

Пффф, юник_птр в QVector не положишь, а тут инвок вы хотите. Ишь чего!

Поэтому я на быстрый фикс и не надеялся. Хотя в QVector это родовая травма, которая не лечится, а invokeMethod вроде достаточно в некоторых местах по цепочке std::move добавить.

Общие вещи никогда не будут "в единственном числе", альтернатива всегда найдется. И сравнение совсем не в пользу std. Тот же std::thread - он же QThread в подметки не годится. И появился всего-то  лет через 15 (?) существования std. Дошло наконец что кросс-платформенное создание нитки все-таки нужно. Ну и слава богу, "лучше поздно чем никогда"

Вроде никто не отрицает, что в определённый момент времени развитие C++ и std затормозилось. Лет 10 проспали (2000-2010), имхо. За это время все кучу своих велосипедов и понаизобретали, с которых теперь не слезть.В Qt тоже много всего понаписали, и я бы не сказал, что это венец творения. Да, лучше чем ничего, но хуже, чем могло бы быть. А по поводу "чтобы духу тут std-шного не было!", в последних версиях Qt сделайте поиск по "std::" в исходниках, и потом расскажите, много там такого духу или мало.

Человек весьма уверен что он "на правильном пути" Я никогда не увлекался либами и использую только когда "ну вот совсем никак без нее" (жизнь заставляет). Тем не менее я привел 3 либы широко известные и доказавшие свою эффективность. Могу привести еще десяток, хотя никакой я не эрудит.

Вы за мою уверенность не переживайте . Весьма уверен. И судя по последним вестям с полей, не я один. Но ежели кому нравится в лаптях ходить, так это дело личное . И я говорил о проектах 2015г. и позже, когда С++11 устаканился в С++14, и компиляторы таки начали эти стандарты нормально поддерживать. А не о либах начала 2000, ясное дело, никто их переписывать не будет.

А можно услышать хотя бы об одной написанной на std? Или оно больше для любительского программирования (начитаться и поумничать) ?  Или все еще идет "процесс обкатки" (ну да, понимаю, дело не быстрое)

Что значит "написанной на std"? Например, Catch достаточно на std написана?

[Igors]

В Qt тоже много всего понаписали, и я бы не сказал, что это венец творения. Да, лучше чем ничего, но хуже, чем могло бы быть.

Ну абсолютно любая вещь может быть лучше, а уж за европейскую зарплату - тем более Но перед тем как "снисходительно судить" - может применить это к себе? "А я чего понаписал? И как оно "могло быть лучше"? Попробуйте, очень полезная процедура

Вы за мою уверенность не переживайте . Весьма уверен. И судя по последним вестям с полей, не я один.

Не навязываю своего мнения, но считаю такое вложение сил непродуктивным. У приличных людей 3/4 работы не связано с собсно "реализацией". Это может быть чтение статей/диссеров (а лучше тезисов к ним), анализ open-sources (если имеются), поиск алгоритма, разработка архитектуры классов и.т.п. А собсно "написание кода" - скорее легкая и приятная часть. Поэтому если человек сильно носится с какими-то чисто техническими подробностями - ну значит "молодой ишшо"  Их-то как раз блестяще знать совсем необязательно.

Однако вернемся к теме

Но ежели кому нравится в лаптях ходить, так это дело личное . И я говорил о проектах 2015г. и позже, когда С++11 устаканился в С++14, и компиляторы таки начали эти стандарты нормально поддерживать. А не о либах начала 2000, ясное дело, никто их переписывать не будет.

Типа "и вот открывается перед нами большая и светлая дорога"    Не вижу (ну может туповат). Что такого уж хорошего "дают" что, дескать, "был застой", а теперь вот "процесс пошел"? Какие-то улучшения там и сям - ну спасибо конечно, да и, как уже говорил, сам факт радует. Но не переоцениваете ли Вы их значимость?

[Old]

Вот говорят, std то, std се, это, мол, "основа основ" которую совершенно необходимо изучать, и чем больше - тем лучше.

У меня другой вопрос: что там в std можно изучать, тем более "чем больше - тем лучше"?
Итераторы? Вы уже много раз писали, что не можете с ними разобраться. Ну так и не трогайте их. Но это совсем не означает, что итераторы надо изучать, и их кто-то изучает - это слишком примитивная конструкция.
Вектор вы вроде освоили. Адресацию по индексу тоже. Что там еще в std осталось непостижимого для вас, что требует изучения?

[ViTech]

Ну абсолютно любая вещь может быть лучше, а уж за европейскую зарплату - тем более Но перед тем как "снисходительно судить" - может применить это к себе? "А я чего понаписал? И как оно "могло быть лучше"? Попробуйте, очень полезная процедура

Ни разу так не делал, надо попробовать. Спасибо, что подсказали .

Не навязываю своего мнения, но считаю такое вложение сил непродуктивным. У приличных людей 3/4 работы не связано с собсно "реализацией". Это может быть чтение статей/диссеров (а лучше тезисов к ним), анализ open-sources (если имеются), поиск алгоритма, разработка архитектуры классов и.т.п. А собсно "написание кода" - скорее легкая и приятная часть. Поэтому если человек сильно носится с какими-то чисто техническими подробностями - ну значит "молодой ишшо"  Их-то как раз блестяще знать совсем необязательно.

Если потом не приходится отвечать на вопросы типа: "Почему так тормозит и гигабайты отжирает?", то да, блестяще знать не обязательно.

Типа "и вот открывается перед нами большая и светлая дорога"    Не вижу (ну может туповат). Что такого уж хорошего "дают" что, дескать, "был застой", а теперь вот "процесс пошел"? Какие-то улучшения там и сям - ну спасибо конечно, да и, как уже говорил, сам факт радует. Но не переоцениваете ли Вы их значимость?

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

А Вам какие улучшения в std нужны, чтоб вот сразу всё попёрло и не надо было возиться с техническими подробностями?

[Igors]

Если потом не приходится отвечать на вопросы типа: "Почему так тормозит и гигабайты отжирает?", то да, блестяще знать не обязательно.

Ну вот зачем, мягко говоря, "кривить душой"? Да, велосипедист иной раз и перегнет палку с оптимизацией, но это грех простительный. А вот std-шнику на тормоза и ресурсы наплевать. Ведь его цель - взять готовое "и не париться". Поэтому все сосредоточено на тупеньком запоминании "что делает тот или иной вызов". Ага, подходит std::find - ну и хорошо, а то что это "брута форса" - понятия нет. А как Вы давеча залепили N вставок вместо одной? И ничего, ведь главное сделано - нужный вызов std найден! Да еще и "с итераторами" - красота! Нужно с мапой работать по индексу (!?) - так вот же std::distance/advance! (наблюдал на этом форуме)

А Вам какие улучшения в std нужны, чтоб вот сразу всё попёрло и не надо было возиться с техническими подробностями?

Ну я не в комитете (и слава богу). Конечно сама идея стандартной библиотеки прекрасна, насколько мне известно, языки помоложе (шарпы всякие) с этого и начинают. Задолбали эти "игры в обобщение", хотелось бы побольше капитальных "сущностей", а то пока аж 2 (unique и shared) - не разогнаться. И может необязательно все сводить к "вумным указателям", без оператора -> я проживу.

[ViTech]

Ну вот зачем, мягко говоря, "кривить душой"? Да, велосипедист иной раз и перегнет палку с оптимизацией, но это грех простительный. А вот std-шнику на тормоза и ресурсы наплевать. Ведь его цель - взять готовое "и не париться". Поэтому все сосредоточено на тупеньком запоминании "что делает тот или иной вызов". Ага, подходит std::find - ну и хорошо, а то что это "брута форса" - понятия нет. А как Вы давеча залепили N вставок вместо одной? И ничего, ведь главное сделано - нужный вызов std найден! Да еще и "с итераторами" - красота! Нужно с мапой работать по индексу (!?) - так вот же std::distance/advance! (наблюдал на этом форуме)

Вон оно чо . Оказывается реализацию std дураки пишут, в лоб. И Вы бы всяко лучше написали обобщенные алгоритмы поиска в контейнерах разного типа и вставки диапазона элементов за одно действие (кусок vector в list и наоборот). В кутешных QList/QVector поиск не брутфорсом делается? И, опять же, можно поискать "std::find" в исходниках Qt. Ещё кутешники подло поступили с Вами и не добавили вставку диапазона элементов в QList (и в QLinkedList заодно). За что они так с Вами? И если таки понадобится вставить кусок QVector в QList, то как вставлять будете?

Есть такая штука - QtAlgorithms. Что мы там видим:

Historically, Qt used to provide functions which were direct equivalents of many STL algorithmic functions. Starting with Qt 5.0, you are instead encouraged to use directly the implementations available in the STL; most of the Qt ones have been deprecated (although they are still available to keep the old code compiling).

Чего это они под std прогнулись? Даже в свои хорошие контейнеры пришлось добавлять методы для совместимости с богомерзким std.

Ну я не в комитете (и слава богу).

Тут бог действительно оберегает сообщество. Славься!

Конечно сама идея стандартной библиотеки прекрасна, насколько мне известно, языки помоложе (шарпы всякие) с этого и начинают. Задолбали эти "игры в обобщение", хотелось бы побольше капитальных "сущностей", а то пока аж 2 (unique и shared) - не разогнаться. И может необязательно все сводить к "вумным указателям", без оператора -> я проживу.

Так какие "сущности" нужны? Особенно интересно в разрезе умных указателей. А то мне некоторые недавно на пальцах объясняли, что "shared_ptr хватит всем".

[Igors]

(и в QLinkedList заодно)

Хотя список (QLinkedList или std::list, не путать с QList) и не очень популярен, это интереснейший контейнер. Быстрая (практически бесплатная) вставка у него по определению. Вот с ним ота песня с итераторами вполне уместна.

И если таки понадобится вставить кусок QVector в QList, то как вставлять будете?

Не знаю, наверное руками. Увеличу размер QList и расчищу в нем место для новых эл-тов сместив "хвост" (заодно будет возможность подучить конструктор перемещения). Потом скопирую. Возможно оформлю темплейтом.

Тут бог действительно оберегает сообщество. Славься!

Не злитесь 

Так какие "сущности" нужны? Особенно интересно в разрезе умных указателей. А то мне некоторые недавно на пальцах объясняли, что "shared_ptr хватит всем".

Ну я точно не был одним из объяснявших  Вот пример что нужно (я уже его приводил)

Код

C++ (Qt)
struct SomeClient {
...
  SomeObject * m_Object;
...
};

Типовая ситуевина - клиент не владеет m_Object, не отвечает за его создание/удаление, т.е. клиент его просто использует - и все. В принципе все вполне норм (именно вследствие своей простоты/примитивности), если бы не одно "но" - если m_Object удален, то придется бегать и обнулять его во всех клиентах. И нужно как-то сохранить SomeObject для undo, причем честно (m_Object грохнут), а не так как в Qt. Напрашивающееся решение:

Код

C++ (Qt)
QWeakPointer<SomeObject> m_Object;

Но это вынуждает владельца объявлять его шаред, а это головняк, надо все время смотреть не зашарился ли он где еще. И почему-то автоматом предполагается "продление жизни". Чего это? Я ничего продлевать не просил. Поэтому несколько лучше смотрится

Код

C++ (Qt)
QPointer<SomeObject> m_Object;

Но эта радость только для QObject, общности нет.
И в любом случае проблем undo это не решает - все равно надо "бегать по всем клиентам".

Как же так? Случай простейший ("элементарный" и.т.п.) - всего-навсего член-указатель, а никаких средств не видать, приходится городить велики (а шо делать?)