Ну ты же понимаешь что такое ужасный код, так тебе легче понять что такое красивый код. Так понятно?

Что в словосочетании «объективное определение» для вас не понятно?

Слушай, ты чё пристал, до тебя не доходит что такое красивый код, зачем мне тебе в подробностях обьяснять, время на тебя тратить? Но вот что напишу, мне нравиться инкапсуляция в c++, и я хотел бы видеть красоту, с помощью неё. В этой теме так никто и не написал красивый код. Пишут только какие то удобства. Я даже не все сообщения читал, потому как спорят там друг с другом.

Я пытался мягко вам намекнуть, что понятия «красивый», как и «ужасный» — это субъективные понятия. Зависят, во многом, как от умственных способностей вообще, так от опыта и знаний в частности. Поэтому кому-то кажется красивым код из Boost.Beast, а кому-то из libcurl.

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

Поэтому прямым текстом: красота у каждого своя.

Ну тогда каждый может сказать что другой пишет ужасный код. Так что не всегда красота у каждого своя.

Ну тогда каждый может сказать что другой пишет ужасный код.

Что значит «может»?!!!

Так все и говорят.

То есть получается, что все здесь говнокод приводили в пример?

Еще раз: красота у каждого своя. Кому-то нравится одно, кому-то другое.

А вот чужой код вообще в принципе мало кому нравится. Так что чужой код является говнокодом практически по определению ;)

Поэтому прямым текстом: красота у каждого своя.

Ну тогда каждый может сказать что другой пишет ужасный код. Так что не всегда красота у каждого своя.

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

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

Ну а если в буквальном смысле, то я тебе уже кидал 2 образца красивого кода: один выводит слово c++, а другой (без крестов) — Венеру Милосскую. Второй камент был удалён, но ты можешь увидеть его, нажав на кнопку «Показать удалённые комментарии».

P.S. Но сама по себе «красота», т. е. читабельность кода не может являться самоцелью, если она достигается за счёт неприемлемых накладных расходов. А вот какие расходы являются приемлемыми, а какие — нет, зависит от задачи. Если мы говорим о критичном модуле ядра, то это одно, если о прорисовке текста и изображений в браузере, то другое, а если говорим о выводе строки «Hello, World!» на питоне, то третье.

Да, судя по всему, у вас какие-то свои, уличные понятия об асинхронности и модели publish-subscribe. Давайте расскажите про них. Особенно про то, чем, по вашему publish-subscribe отличается от очереди сообщений.

Особенно про то, чем, по вашему publish-subscribe отличается от очереди сообщений.

Тем, что publish-subscribe, в том условии, которое я вам дал, означает наличие не одной, а нескольких очередей.

Соответственно, опубликованное сообщение должно оказаться в нескольких очередях. И удалено оно может быть только когда будет изъято из всех очередей.

А асинхронность добавляет сюда то, что из одной очереди сообщение может быть удалено еще до возврата из операции «publish», а в другой застрянет на несколько часов после возврата из «publish»-а.

Теперь давайте послушаем ваши представление и об асинхронности, и о модели publish-subscribe. Предвкушаю некое количество акуительных открытий.

А так же жду объяснения того, как же вы все-таки собираетесь обойтись без подсчета ссылок или полноценного сборщика мусора.

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

«Предвкушаю некое количество акуительных открытий.»

и вы не ошиблись

«А асинхронность добавляет сюда то, что из одной очереди сообщение может быть удалено еще до возврата из операции «publish», а в другой застрянет на несколько часов после возврата из «publish»-а.»

Под асинхронностью понимают следующее:

Asynchrony, in computer programming, refers to the occurrence of events independent of the main program flow and ways to deal with such events. These may be «outside» events such as the arrival of signals, or actions instigated by a program that take place concurrently with program execution, without the program blocking to wait for results.

https://en.wikipedia.org/wiki/Asynchrony_(computer_programming)

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

То о чём вы говорите - мягко говоря, нестандартное определение асинхронности. Ну пускай. По второму пункту особых вопросов нет - в Qt события в очереди могут жить неопределённое время. Но вот этот пункт: «из одной очереди сообщение может быть удалено еще до возврата из операции «publish»» - это какой-то бред. Сообщение либо поступает в очередь событий, либо выкидывает исключение и не поступает в очередь или очереди событий. Где вы нашли такое определение асинхронности, что неоформленное ещё сообщение обязано появиться в очереди ещё в процессе обычно атомарной операции? И вообще, это ваше требование попахивает багами.

и о модели publish-subscribe

«очередь сообщений» отличается «публициста-подписчика» тем, что очередь сообщений содержит, ВНЕЗАПНО, очередь собобщений. А публицист-подписчик: очередь событий.

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

Молодой человек, еще раз перечитайте определение, которое вы нашли в Wikipedia. В частности, вот этот фрагмент:

or actions instigated by a program that take place concurrently with program execution, without the program blocking to wait for results.

ключевые фрагменты я выделил.

А после этого сосредоточьтесь и таки найдите возможность ответить на вопросы, которые вам были давным давно озвучены. В частности:

Как раз в виду асинхронности самый интересный вопрос — это определение момента времени когда «QEvent будет обработан всеми зарегистрированными на него обработчиками». Вот и объясните, как это делается без подсчета ссылок или сборщика мусора.

Если не можете своими словами, то показывайте ссылки на соответствующие места в коде Qt.

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

ключевые фрагменты я выделил.
without the program blocking
that take place concurrently

Молодец. Очевидно, что когда сообщение отправляется в другой QThread,оно «concurrently» и тем более «without blocking».

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

Вопиющее непонимание темы демонстрируете вы.

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

Во-вторых, boost/stl shared_ptr как и вся stl появился исторически позже первых версий Qt. А Qt, в свою очередь, построен на системе событий изначально. Отсюда следует вывод, что shared_ptr не мог использоваться разработчиками Qt в системе событий при всём желании.

В-третьих, если бы вы читали то, что вам пишут, вы бы обратили внимание, что QEvent всегда передаётся голым указателем. shared_ptr так не работает, ему для автоматической работы внутреннего счётчика ссылок нужно исполнение конструктора/деструктора.

В-четвёртых, и главное, основная беда shared_ptr состоит в том, что он не может автоматически собирать циклические ссылки. Т.е. граф содержимого, с которым может (обратите внимание: автоматически) работать shared_ptr представляет собой дерево и математически полностью эквивалентен графу с которым может работать unique_ptr (выше по треду также было показано, что RAII в т.ч. на униках приводит к графу отношений в виде дерева).

Таким образом, чтобы как-то оправдать своё применение, shared_ptr-у необходим weak_ptr, который позволяет разруливать циклические зависимости вручную. Есс-но мимо такого пройти мимо невозможно, и Qt несомненно хоть где-нибудь да представлял возможность использования чего-нибудь вроде QWeakEvent или что-то вроде того, но его нет!

Более того, система событий Qt сложнее и «фичастее» чем ваш пример. И именно поэтому там быть не может shared_ptr: потому, что иначе (утрируя) вместо работы с системой событий, программисту приходилось бы ручками расписывать слабые указатели, борясь с утечками ресурсов.

Вот и объясните, как это делается без подсчета ссылок или сборщика мусора.

Объяснял уже, кидал уже цитаты из документации. Бесполезно.

Но на минуточку, вы забыли с чего мы начинали обсуждение? Вообще-то с ненужности shared_ptr.

Что это я вдруг должен доказывать это ваше «делается без подсчета ссылок»? На подсчёте ссылок можно много каких хороших вещей сделать. Например, какую-нибудь реализацию паттерна flyweight. В Qt например, для некоторых классов вроде QString используется «неявное совместное использование». Пожалуйста: вот вам подсчёт ссылок без необходимости ручного разруливания циклических зависимостей.

или сборщика мусора.

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

и сборщики мусора под плюсы типа Bohems используют mark-and-sweep или более сложные алгоритмы, а не подсчёт ссылок, характерный для shared_ptr

Объяснял уже,

Нет.

кидал уже цитаты из документации.

Цитаты были, но они вообще не показывали возможности получить от Qt реализацию publish-subscribe, о которой я вас просил. На просьбы описать механизм своими словами или хотя бы показать соответствующие фрагменты кода Qt вы, ожидаемо, не смогли отреагировать.

Но на минуточку, вы забыли с чего мы начинали обсуждение? Вообще-то с ненужности shared_ptr.

На минуточку, мы начали с того, что shared_ptr нужен там, где граф владения != графу порождения: www.linux.org.ru/add_comment.jsp?topic=14042354&replyto=14049165

И механизмы реализации publish-subscribe (если бы вы их понимали) как раз демонстрируют такую ситуацию. Сообщение порождает publisher-а, потом отдает владение операции publish, которая передает владение сообщением очередям subscriber-ов. Поскольку subscriber-ов N, то и очередей (в простейшем случае) N. Следовательно, будет N владельцев сообщением. И это только при начальном publish-е. Но, т.к. любой subscriber может сделать повторный publish этого же сообщение, то владельцев станет еще больше.

Я могу вам показать, как это решается без использования GC и подсчета ссылок. Но это неэффективная реализация. Поэтому применение shared_ptr в такой задаче — естественный вариант.

Вы утверждаете, что этого можно достичь без shared_ptr. Ok. Рассказывайте. Своими словами.

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

PS. Ну и да, меленькая мелочь: в нашем разговоре под shared_ptr понимается абстракция «умный указатель на базе подсчета ссылок». Реализаций этой абстракции может быть множество, вовсе необязательно, что это boost::shared_ptr или std::shared_ptr.

Цитаты были, но они вообще не показывали возможности получить от Qt реализацию publish-subscribe

показывали

1) Есть несколько очередей сообщения на каждый поток

2) Каждая очередь владеет объектом QEvent*

граф владения != графу порождения

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

Поскольку subscriber-ов N, то и очередей (в простейшем случае) N. Следовательно, будет N владельцев сообщением.

конечно же нет: это не эффективно

В Qt количество очередей сообщений равно числу запущенных QThread. Очередь отвечает за время жизни QEvent, а сама очередь жива до тех пор, пока жив поток исполнения.

В рамках 1-го потока обработка QEvent происходит строго последовательно, когда все обработчики его обработают или откажутся от обработки, QEvent будет удалён из очереди.

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

Всё это было написано в тех цитатах, которые я вам кидал.

2) Каждая очередь владеет объектом QEvent*

Простите мне мой французский, но что за хрень вы здесь пишете. Указатель — это не объект, а такой же скалярный тип, как int или double. Соответственно, во фразе «владеет объектом QEvent*» нет смысла. Очередь может хранить собственную копию указателя на QEvent, но к владению чего-либо это не имеет отношения.

Если нужно обработать один и тот же QEvent в разных потоках, его достаточно скопировать по значению в нужный поток.

А теперь расскажите, что делать в ситуации, когда копирование невозможно. Например, внутри QEvent-а лежит «тяжелый» объект на 1GiB. Или внутри QEvent-а лежит некопируемый коннекшен к БД.

под shared_ptr понимается абстракция «умный указатель на базе подсчета ссылок». Реализаций этой абстракции может быть множество, вовсе необязательно, что это boost::shared_ptr или std::shared_ptr.

принимается, но с оговорками: в qt начиная с 4-ки есть QShared - аналог std::shared_ptr и есть умный указатель для реализации неявного совместного использования.

первый можно понимать под shared_ptr, второй - нет

Очепятка: владеет QEvent, а передаёт подписчикам QEvent*, конечно же.

Например, внутри QEvent-а лежит «тяжелый» объект на 1GiB. Или внутри QEvent-а лежит некопируемый коннекшен к БД.

Это уже не событие будет, а сообщение. В qt такие вещи тоже достаточно элементарно делаются на базе системы событий работает система сигналов-слотов. Там можно уже получать указатель на передатчик через QObject::sender() и из него вытягивать какие пожелаете данные.

Послушайте, любезный, да засуньте вы свой Qt себе в задницу и начните разговаривать нормальным языком. Есть абстракция «умный указатель с подсчетом ссылок», наиболее известное имя для которой — это shared_ptr.

Что там есть в Qt, когда оно появилось и как называется, к разговору о применимости «умных указателей с подсчетом ссылок» не имеет вообще никакого отношения.

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

А вы способны в контексте разговора про publish-subscribe своими словами описать разницу между «сообщением» и «событием»?

И да, совет засунуть Qt в задницу, все еще актуален.

Есть абстракция «умный указатель с подсчетом ссылок», наиболее известное имя для которой — это shared_ptr.

Э-не-не. Разговор начинался с того, что:

lovesan

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

next_time

shared_ptr используют неосиляторы unique_ptr, ну или для случаев «куяк-и в продакшен»

То есть, есть, под «shared_ptr» я имел в виду ВНЕЗАПНО shared_ptr. И ваши фантазии по поводу того, что ещё считать shared_ptr-ом тут силы не имеют.

Называть любой умный указатель со счётчиком ссылок shared_ptr-ом безграмотно. Во-первых, применение умных указателей не ограничивается проблемами памяти: типичный пример - итераторы Во-вторых, счётчики ссылок в умных указателях тоже применяются для чего угодно, типичный пример: дедубликация памяти (QSharedDataPointer например, boost::flyweight).

Но самое главное здесь то, что «смартпойнтеры, типа shared_ptr, с такими же проблемами (и еще большими, в области блокировки шины памяти)» действительно приводят к описанным проблемам, однако это касается далеко не каждого умного указателя, и даже не каждого указателя на счётчиках ссылок.

Есть абстракция «умный указатель с подсчетом ссылок»,

в ваших фантазиях, т.к. умные указатели с подсчетом ссылок могут использоваться для чего угодно

А вы способны в контексте разговора про publish-subscribe своими словами описать разницу между «сообщением» и «событием»?

Да. Событие - короткое, вплоть до атомарности сообщение, которое не позволяет получить какую-либо информацию об отправителе получателю и наоборот.

Собственно, publish-subscribe - частный случай очереди сообщений и использование сообщений в форме событий и является его отличительной чертой.

И да, совет засунуть Qt в задницу, все еще актуален.

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

Если вы уж ничего не можете сказать по теме «граф владения != графу порождения» и пытаетесь съехать на то, с чего все началось, то с какого куя, вы взяли и сузили: «смартпойнтеры, типа shared_ptr» до исключительно shared_ptr-а?

Во-первых, применение умных указателей не ограничивается проблемами памяти: типичный пример - итераторы Во-вторых, счётчики ссылок в умных указателях тоже применяются для чего угодно, типичный пример: дедубликация памяти (QSharedDataPointer например, boost::flyweight).

А теперь, последовательный вы наш, объясните, каким образом приведенные вами примеры соотносятся с вашим же утверждением:

shared_ptr используют неосиляторы unique_ptr, ну или для случаев «куяк-и в продакшен»

Надо полагать, что это яркие примеры «неосиляторства unique_ptr» и подхода «куяк-и в продакшен». Отлично.

Да. Событие - короткое, вплоть до атомарности сообщение, которое не позволяет получить какую-либо информацию об отправителе получателю и наоборот.

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

Судя по адекватности ваших высказываний, это вы здесь пишете в состоянии хронического опьянения.

Я не зря расчитывал на акуительные открытия. «Событие - короткое, вплоть до атомарности сообщение» — это просто прекрасно. Можете еще чем-нибудь читателей порадовать?

Да!

https://en.wikipedia.org/wiki/Event_(computing)

https://en.wikipedia.org/wiki/Publish–subscribe_pattern

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

Вы хоть пытаетесь читать статьи из Wiki, на которые ссылаетесь? Поскольку в первом же предложении по ссылке https://en.wikipedia.org/wiki/Event_(computing) написано:

In computing, an event is an action or occurrence recognized by software, often originating asynchronously from the external environment, that may be handled by the software.

Прочитайте внимательно: «an event is an action». Событие — это действие. И это естественно, т.к. «сообщение» — это экземпляр данных с какой-то информацией. А поступление/прием/обработка «сообщения» — это уже действие, т.е. событие.

Тогда как у вас событие — это, цитирую: «Событие - короткое, вплоть до атомарности сообщение»

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

В кои-то веки поддержу eao197

Плюсовики, вы уже убедились, наконец, какое C++ говно?

А как вторая строчка поста проистекает из того, что говорил eao197?

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

На нем в принципе нельзя писать нормальный нетормозной код, что подтверждается, в принципе, словами eao197

Очень интересно было бы увидеть какие именно мои слова подтверждают, что на C++ нельзя писать:

a) нормальный код и

b) нетормозной код

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

ППКС.

Мимокрокодил

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

Можно подробности, что в них такого опасного?

Вопрос к тому, кто назвал их опасными - это был Kroz. Я сам исключения использую в роли растового panic.

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

1. Они «тормозят». Корни растут из тех времен, когда исключения еще только-только появились и их реализация была не zero-cost. Сейчас уже широко используются zero-cost реализация, в которой если исключения не бросаются, то это ничего не стоит (что не совсем так, т.к. некоторая стоимость все-таки есть — это специальные таблицы, на основании которых ищется затем обработчик для исключения). Однако, если исключения бросаются, то они стоят очень дорого (замедление по сравнению с кодами возврата в десятки раз).

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

3. Люди начинают использовать исключения не как средство информирования об ошибках, а для реализации «логики на исключениях». Что делает код непонятным, сложным в поддержке и развитии, непредсказуемым.

Впрочем, актуальность этих претензий зависит как от предметной области, в которой пытаются применять C++ (жесткое реальное время или суровый embedded — это одно, desktop-софт или высокопроизводительные вычисления — это другое), так и, в большей степени, от радиуса кривизны рук и степени умственной отсталости отдельных разработчиков. Ну, иногда, тяжким наследием прошлого, когда человека заставляли жить в рамках какого-то ограниченного подмножества C++ (например, так проявляются последствия «Qt головного мозга»).

Спасибо за развернутый ответ

+ Aswed

1. Они «тормозят».

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

2. ... нет никаких гарантий о том, какого типа исключение оттуда вылетит.

Это описано в любом мануале. Плюс есть возможность поймать все исключения: https://stackoverflow.com/questions/315948/c-catching-all-exceptions

3. Люди начинают использовать исключения не как средство информирования об ошибках, а для реализации «логики на исключениях».

Это уже ближе.

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

Чтобы писать с исключениями, нужно закладывать правильную логику.
Тема полностью раскрыта здесь, очень рекомендую к просмотру:
https://www.youtube.com/watch?v=W7fIy_54y-w
https://www.youtube.com/watch?v=b9xMIKb1jMk
https://www.youtube.com/watch?v=MiKxfdkMJW8

Немного проспойлю:
- Нельзя бросать исключения в деструкторах. Тут же возникает вопрос написания No-throw guarantee функций гарантирующих не-бросание исключений (даже если внутри них есть функции, которые таких гарантий не дают)
- Как бросать исключения (правильный ответ - по значению). Как ловить исключения (правильный ответ - по ссылкам).
- Вложенные исключения
- Multithreading, перемещение исключений между тредами, exception pointer
и т. п.

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

Смотря какая предметная область=)

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

Да и в конструкторах имхо не очень то желательно, ну или аккуратно дизайнить классы.

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

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

А потом, например, вот это для лучшего осознания:

https://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow

https://monoinfinito.wordpress.com/series/exception-handling-in-c/

Да и в конструкторах

Как раз исключения в конструкторах — это одна из тех вещей, ради которых исключения и стоит использовать.

Как раз исключения в конструкторах — это одна из тех вещей, ради которых исключения и стоит использовать.

Ну там придется накладывать ряд ограничений на архитектуру. Точнее скорее предирживаться опеределенной стилистики.

Ну там придется накладывать ряд ограничений на архитектуру. Точнее скорее предирживаться опеределенной стилистики.

Например?

То есть надо уметь кидать исключения из конструктора. А для этого надо понимать язык, иметь некий и иметь налаженные производственные процессы в команде(чтобы без случаев, когда каждый кодер «делает что хочет, законом не запрещено»).

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

http://coliru.stacked-crooked.com/a/016e64ab68fd3d0a

Как так? Не понятно, что вас смущает в этом случае.