Здравствуйте, MTD, Вы писали:

NB>>если ты не удалишь парента, твое дерево тебе ничем не поможет.

MTD>А ты возьми и удали.



NB>>а чтобы его удалить, тебе нужен SharedPointer, который, внезапно, использует счетчик ссылок (упомянутый ранее sharedRefcount)

MTD>Зачем ты упорно выдумываешь то, чего нет? Нет там никакого подсчета ссылок, код я тебе уже показал. А этот код из деструктора QObject как уживается с выдуманным тобой шаред поинтером?

ага. это я придумал его в исходники QT засунуть.

MTD>

MTD>    for (int i = 0; i < children.count(); ++i) {
MTD>        currentChildBeingDeleted = children.at(i);
MTD>        children[i] = 0;
MTD>        delete currentChildBeingDeleted;
MTD>    }
MTD>

повторю для одаренных.
этот поинтер не для удаления чайлдов.
он для управления жизнью объекта без парента.
доступно?

Здравствуйте, night beast, Вы писали:

MTD>>А ты возьми и удали.

NB>

Это С++, тебе нужна Ява? Иди и возьми.

MTD>>Зачем ты упорно выдумываешь то, чего нет? Нет там никакого подсчета ссылок, код я тебе уже показал. А этот код из деструктора QObject как уживается с выдуманным тобой шаред поинтером?

NB>ага. это я придумал его в исходники QT засунуть.

Его там нет. Покажи.

NB>повторю для одаренных.
NB>этот поинтер не для удаления чайлдов.
NB>он для управления жизнью объекта без парента.
NB>доступно?

Покажи пальцем или балабол.

Здравствуйте, MTD, Вы писали:

NB>>

MTD>Это С++, тебе нужна Ява? Иди и возьми.

мне не нужна ява, но и ручками за жизнью объекта следить сейчас не принято.

MTD>>>Зачем ты упорно выдумываешь то, чего нет? Нет там никакого подсчета ссылок, код я тебе уже показал. А этот код из деструктора QObject как уживается с выдуманным тобой шаред поинтером?

NB>>ага. это я придумал его в исходники QT засунуть.

MTD>Его там нет. Покажи.

показать что?

NB>>повторю для одаренных.
NB>>этот поинтер не для удаления чайлдов.
NB>>он для управления жизнью объекта без парента.
NB>>доступно?

MTD>Покажи пальцем или балабол.

QSharedPointer<QObject> obj1 = QSharedPointer<QObject>::create();
QSharedPointer<QObject> obj2 = obj1;

и смотри что в obj.data()->...->sharedRefcount лежит.
но. в 5 версии они это похерили, так что смотри в 4-й

конкретно присвоение идет в функции QtSharedPointer::ExternalRefCountData::setQObjectShared

для 5-й смотри здесь:

QObject* obj = new QObject();
QPointer<QObject> weak(obj;
delete obj;
assert(weak.isNull());

Здравствуйте, Vicul, Вы писали:

V>Интересует под MS VS2013. Кто какие использует?
V>О QT и шарпе я в курсе и гуглом пользоваться умею. Интересуют мнения тех, кто с таким библиотеками работал

Самое печальное, что высказанные в этой теме рекомендации (о безусловно первом месте Qt и возможности рассмотрения Sciter) действительно абсолютно справедливы. Печально это потому, что оба эти продукта являются крайне сомнительными с точки зрения архитектуры и C++. В то время как современный C++ позволяет писать очень красивые решения и они даже существуют в природе. Но если меня спросят совета, то я не назову их, а назову опять же какую-нибудь Qt. В силу её огромной проработанности, количества поддерживаемых платформ и инструмент, и ещё множества подобных "экстенсивных" аргументов. Это очень печальная ситуация, которая возникла в силу ряда исторических причин и теперь с ней уже мало что сделаешь.

Кстати, ещё забавно, что для остального мира (за пределами C++) эта библиотечка тоже является одним из лидеров — используется чуть ли не всеми другими языками и мало кто там представляет, насколько она не соответствует миру C++ (хотя вроде как получается одним из самым известных представителей).

Здравствуйте, alex_public, Вы писали:

_>Самое печальное...

Самое печальное это то что все mainstream UI библиотеки (MFC, Qt, wxWidgets) были сделаны во времена "OOP — наше все".
Все C++ книжки которые писали про концепцию virtual демонстрировали виртуальное наследование как правило на UI примерах. Ну там всякие

class Shape {
  virtual void draw(graphics* gfx) = 0; 
}

Тогда как практически весь современный UI (Web это 99.99% всего UI) крайне далек от той изначальной модели.
Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами.

Во многом functional и declarative programming. Проблема в том что UI имеет свою внутреннюю логику. Без GC получить динамический UI сложно.

Angular и React со товарищи рулят не просто так. Declarative code binding это не прихоть, а требование времени.
Мы перестали делать приложения "на всю жизнь". Время жизни UI решений теперь измеряется месяцами если не неделями.
Поэтому нужно уметь быстро подстраиваться под архитектуры OS и пр. Сколько жила Windows XP? А сколько Windows 7, а Windows 8.
Про Windows 10 я вообще молчу. Сейчас уже выходит Creators Update... Там некоторые UI принципы вообще другие...
Как пример сколько времени мы смотрели на кнопки в виде башни танка Тигр. А сколько в виде башни T64 (WinXP...Win7)? А сколько на современные плоские?
Сколько времени на цельнолитые windows? А сколько на современные blur behind (MacOS, Windows 8 и кульминация в Creators Update)...

Время когда мы делали UI и прибивали его к пиксельным сеткам ушло.
Соответственно вымерли visual designer динозавры как класс. Мы делаем приложения работающие на широком спектре экранов и input sensors

Для чистого С++ оптимальными UI задачами являются что-то типа Microsoft Word и Excel. Все остальное в UI крайне не подходит под C++.
Но верно и обратное. Google Docs лучше бы был написан на C++.

Т.е. C++ это эффективный rendering. Но UI composition, styling и event handling реально удобнее и надежнее делать в ... ну не буду повторяться.

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, alex_public, Вы писали:

CS>Т.е. C++ это эффективный rendering. Но styling

Т.к. в Qt тот же css или sciter пошел дальше обычного css и
и "запилил" современный css из мира web, являющийся чуть ли не отдельным
языком программирования на котором можно игры писать? Но вряд ли это можно считать плюсом.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Vicul, Вы писали:

V>>Интересует под MS VS2013. Кто какие использует?
V>>О QT и шарпе я в курсе и гуглом пользоваться умею. Интересуют мнения тех, кто с таким библиотеками работал

_>Самое печальное, что высказанные в этой теме рекомендации (о безусловно первом месте Qt и возможности рассмотрения Sciter) действительно абсолютно справедливы. Печально это потому, что оба эти продукта являются крайне сомнительными с точки зрения архитектуры и C++. В то время как современный C++ позволяет писать очень красивые решения и они даже существуют в природе.

И что же в нем сомнительного, а в современных решениях "красивого"?
Современный 'C++' все еще не позволяет сделать рефлексию: https://www.meetingcpp.com/blog/items/reflections-on-the-reflection-proposals.html

А костыли из шаблонов и макросов ничуть не лучше по "красоте", чем moc.

Здравствуйте, Zhendos, Вы писали:

Z>Здравствуйте, c-smile, Вы писали:

CS>>Здравствуйте, alex_public, Вы писали:

CS>>Т.е. C++ это эффективный rendering. Но styling

Z>Т.к. в Qt тот же css или sciter пошел дальше обычного css и
Z>и "запилил" современный css из мира web, являющийся чуть ли не отдельным
Z>языком программирования на котором можно игры писать? Но вряд ли это можно считать плюсом.

В Qt только малая часть от CSS. Задание шрифтов и цветов это конечно интересно, но очень далеко не все.

@media blur-behind=="dark" {
  :root {
    background-color: transparent;
  }
}

@media width < 1200px {
  :root {
    flow: horizontal;     
  }
}

Нужны layout managers... Да они появились в QtQuick, но это уже не CSS а как-то сбоку в стиле XUL от которого уже сама Mozilla как чёрт от ладана бежит.
И вообще если QtQuick то собственно почему уже не Sciter?

Гвоздями прибитый C++ код к QtQuick как-то вызывает архитектурное отторжение. Неправильно как-то. Script в QtQuick смотрится естественнее...

Ну и потом, практически в любом современном приложении нужен HTML и WYSIWYG редактирование. Т.е. приходится тащить весь зоопарк, Qt, QtQuick, QtWebKit — все делают примерно одно и то же только по разному.

Здравствуйте, night beast, Вы писали:

NB>мне не нужна ява, но и ручками за жизнью объекта следить сейчас не принято.

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

NB>показать что?

Покажи счетчик ссылок, который по твоим словам находится внутри каждого QObject и управляет его временем жизни.

MTD>>Покажи пальцем или балабол.

NB>

NB>QSharedPointer<QObject> obj1 = QSharedPointer<QObject>::create();
NB>QSharedPointer<QObject> obj2 = obj1;

Ожидаемо, ты счетчик ссылок в QObject показать не смог. Понятно кто ты?

NB>конкретно присвоение идет в функции QtSharedPointer::ExternalRefCountData::setQObjectShared

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

Здравствуйте, MTD, Вы писали:

NB>>мне не нужна ява, но и ручками за жизнью объекта следить сейчас не принято.

MTD>В Qt тоже не надо, но удаление объектов там происходит за счет того, что родитель удаляет дочерние объекты, а не за счет подсчета ссылок. Корневой объект, естественно удалить надо. Например, он может быть удален умным указателем.

для чего в qobject и лежит sharedRefcount
если напрягешься, и глянешь на тип eventFilters парой строк выше, то увидишь eventFilters -- список вик поинтеров, которые qobject не поддерживает

NB>>показать что?

MTD>Покажи счетчик ссылок, который по твоим словам находится внутри каждого QObject и управляет его временем жизни.

MTD>>>Покажи пальцем или балабол.

NB>>

NB>>QSharedPointer<QObject> obj1 = QSharedPointer<QObject>::create();
NB>>QSharedPointer<QObject> obj2 = obj1;

MTD>Ожидаемо, ты счетчик ссылок в QObject показать не смог. Понятно кто ты?

мда. sharedRefcount что по твоему?

NB>>конкретно присвоение идет в функции QtSharedPointer::ExternalRefCountData::setQObjectShared

MTD>Ты на шаред поинтер не съезжай, где счетчик ссылок в QObject?

здесь

Автор: night beast
Дата: 15.09.17

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

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

ps: в веб интерфейсе есть кнопка "редактировать". удалять не обязательно.

Здравствуйте, night beast, Вы писали:

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

NB>угу.
NB>уже и носом ткнули, и пример привели а он все не успокоится.

Носом пока что только тебя ткнули. Покажи конкретно в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни, покажи в каком случае этот счетчик увеличивается и уменьшается, покажи где там delete this, объясни как вообще этот счетчик может работать, если в Qt QObjectы везде передаются как голые указатели. Хотя о чем я? Сейчас будет очередная нелепая отмалзка приправленная бла-бла-бла.

Здравствуйте, MTD, Вы писали:

NB>>угу.
NB>>уже и носом ткнули, и пример привели а он все не успокоится.

MTD>Носом пока что только тебя ткнули. Покажи конкретно в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни, покажи в каком случае этот счетчик увеличивается и уменьшается, покажи где там delete this, объясни как вообще этот счетчик может работать, если в Qt QObjectы везде передаются как голые указатели. Хотя о чем я? Сейчас будет очередная нелепая отмалзка приправленная бла-бла-бла.

пока что бла-бла-бла исходит исключительно от тебя.
для тебя повторю:

QObject* obj = new QObject();
QPointer<QObject> weak(obj);
delete obj;
assert(weak.isNull());

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

если что, счетчик ссылок не занимается delete this
он тупо хранит количество ссылок (это я говорю на случай, если ты не в курсе)

Здравствуйте, night beast, Вы писали:

MTD>>Носом пока что только тебя ткнули. Покажи конкретно в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни, покажи в каком случае этот счетчик увеличивается и уменьшается, покажи где там delete this, объясни как вообще этот счетчик может работать, если в Qt QObjectы везде передаются как голые указатели. Хотя о чем я? Сейчас будет очередная нелепая отмалзка приправленная бла-бла-бла.

NB>отладчик в руки и смотри конкретные файлы и конкретные строки.

Ожидаемо слился.

Здравствуйте, c-smile, Вы писали:

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

CS>Самое печальное это то что все mainstream UI библиотеки (MFC, Qt, wxWidgets) были сделаны во времена "OOP — наше все".
CS>Все C++ книжки которые писали про концепцию virtual демонстрировали виртуальное наследование как правило на UI примерах. Ну там всякие
CS>

CS>class Shape {
CS>  virtual void draw(graphics* gfx) = 0; 
CS>}  
CS>

Да, всё верно, это классика ООП. И действительно во времена 90-ых это считали серебряной пулей, которую совали везде. Сейчас же более менее опомнились и применяют только по делу. Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным.

CS>Тогда как практически весь современный UI (Web это 99.99% всего UI) крайне далек от той изначальной модели.


Предлагаю тебе просто открыть исходники какого-нибудь там Webkit'a и посмотреть своими глазами на реализацию этого самого Web UI — ты там увидишь всё те же самые C++ классы в классической ООП схеме.

CS>Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами.

И это всё отлично ложится как раз на ООП модель.

CS>Во многом functional и declarative programming. Проблема в том что UI имеет свою внутреннюю логику.

Вот многие пишут в последнее время "декларативный GUI", говоря об этом как о каком-то невиданном новшестве. Смешно слушать такое — даже убогие rc файлы из самой древней винды уже были полностью декларативными. Более того, если мы откроем файлы визуальных дизайнеров Qt или wxWidgets, то увидим там ... XML — куда уж декларативнее то? ) Т.е. в этом смысле вся разница в реализации GUI на Qt или HTML заключается в том, в каком месте происходит конвертация декларативного описания контролов в соответствующие им вызовы классических ООП классов на C++. В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход. Кстати, а в wxWidgets работают сразу оба подхода на одном и том же XML формате (https://wiki.wxwidgets.org/Using_XML_Resources_with_XRC) — его можно как компилировать в C++ файлы, так и загружать динамически в рантайме.

CS>Без GC получить динамический UI сложно.

Полная ерунда и невладение C++.

CS>Angular и React со товарищи рулят не просто так. Declarative code binding это не прихоть, а требование времени.
CS>Мы перестали делать приложения "на всю жизнь". Время жизни UI решений теперь измеряется месяцами если не неделями.
CS>Поэтому нужно уметь быстро подстраиваться под архитектуры OS и пр. Сколько жила Windows XP? А сколько Windows 7, а Windows 8.
CS>Про Windows 10 я вообще молчу. Сейчас уже выходит Creators Update... Там некоторые UI принципы вообще другие...
CS>Как пример сколько времени мы смотрели на кнопки в виде башни танка Тигр. А сколько в виде башни T64 (WinXP...Win7)? А сколько на современные плоские?
CS>Сколько времени на цельнолитые windows? А сколько на современные blur behind (MacOS, Windows 8 и кульминация в Creators Update)...

Ужас какой. Ты действительно считаешь, что правильное GUI должно это всё задавать в себе? Вообще то у разных людей разные вкусы и разные ОС, которые они настраивают под эти вкусы. Так что правильное GUI в идеале должно полностью соответствовать локальным настройкам, а не навязывать свои (такие приложения выделяются в негативную сторону, и кстати обычно это как раз приложения с веб интерфейсом или написанные на Java).

CS>Время когда мы делали UI и прибивали его к пиксельным сеткам ушло.

Совершенно верно.

CS>Соответственно вымерли visual designer динозавры как класс.

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

CS>Мы делаем приложения работающие на широком спектре экранов и input sensors

Совершенно верно. Например у меня приложение работает на Android/Windows/iOS/OSX/Linux на всех экранах от телевизора до часов. И при этом GUI вполне себе рисуется в визуальном редакторе.

CS>Для чистого С++ оптимальными UI задачами являются что-то типа Microsoft Word и Excel. Все остальное в UI крайне не подходит под C++.
CS>Но верно и обратное. Google Docs лучше бы был написан на C++.

Что такое "остальное UI"? )

CS>Т.е. C++ это эффективный rendering. Но UI composition, styling и event handling реально удобнее и надежнее делать в ... ну не буду повторяться.

Опять же ерунда. Хотя на самом деле определённое преимущество в создание web интерфейсов действительно имеется — для их создания не требуется брать крутого (и дорогого) C++ программиста, а можно взять за копейки любого верстальщика из веб'а, которых кругом полно. Однако это преимущество относится не к техническим, а к бизнес вопросам, так что вряд ли его стоит обсуждать в данной теме.

Здравствуйте, MTD, Вы писали:

NB>>отладчик в руки и смотри конкретные файлы и конкретные строки.

MTD>Ожидаемо слился.


что, отладчик для тебя слишком сложно?
сочувствую...
но уровень фанатиков QT ты продемонстрировал, молодец.

Здравствуйте, Zhendos, Вы писали:

_>>Самое печальное, что высказанные в этой теме рекомендации (о безусловно первом месте Qt и возможности рассмотрения Sciter) действительно абсолютно справедливы. Печально это потому, что оба эти продукта являются крайне сомнительными с точки зрения архитектуры и C++. В то время как современный C++ позволяет писать очень красивые решения и они даже существуют в природе.
Z>И что же в нем сомнительного, а в современных решениях "красивого"?
Z>Современный 'C++' все еще не позволяет сделать рефлексию: https://www.meetingcpp.com/blog/items/reflections-on-the-reflection-proposals.html
Z>А костыли из шаблонов и макросов ничуть не лучше по "красоте", чем moc.

Отсутствие рефлексии (а точнее нормальной интроспекции времени компиляции, как реализовано в D) — это действительно самый большой (на мой взгляд) недостаток современного C++. Я об этом не раз уже писал на этом форуме. И я надеюсь что в C++20 он уж точно будет исправлен (собственно планировалось что будет уже в C++17, но не успели договориться), естественно нормальным путём статической интроспекции, а не тем убогим способом, что используется в Qt.

Однако разговор о рефлексии не имеет никакого отношения к данной теме, потому как для реализации GUI она не требуется — это инструмент для других целей (Qt же уже давно не только GUI библиотека). А для реализации GUI требуется в первую очередь какая-то вариация на тему системы signal/slot. Так вот подобные библиотеки красиво реализованы на C++ уже очень давно, причём без всяких убогих препроцессоров.

Здравствуйте, MTD, Вы писали:

MTD>На Qt представь себе тоже! Открой для себя http://doc.qt.io/qt-5/stylesheet-syntax.html, правда есть подозрение, что когда ты наконец перестанешь как многие тут расказывать байки про Qt и выучишь его, то расплачешься и выбросишь свое творение

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

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Zhendos, Вы писали:


_>Однако разговор о рефлексии не имеет никакого отношения к данной теме, потому как для реализации GUI она не требуется — это инструмент для других целей (Qt же уже давно не только GUI библиотека). А для реализации GUI требуется в первую очередь какая-то вариация на тему системы signal/slot. Так вот подобные библиотеки красиво реализованы на C++ уже очень давно, причём без всяких убогих препроцессоров.

Так сигналы/слоты давно нормально в Qt реализованы в стиле современного C++,
и проверка во время компиляции, и лямбды в connect можно положить и т.д.
и т.п., чего не хватает-то?

Здравствуйте, Zhendos, Вы писали:

_>>Однако разговор о рефлексии не имеет никакого отношения к данной теме, потому как для реализации GUI она не требуется — это инструмент для других целей (Qt же уже давно не только GUI библиотека). А для реализации GUI требуется в первую очередь какая-то вариация на тему системы signal/slot. Так вот подобные библиотеки красиво реализованы на C++ уже очень давно, причём без всяких убогих препроцессоров.

Z>Так сигналы/слоты давно нормально в Qt реализованы в стиле современного C++,
Z>и проверка во время компиляции, и лямбды в connect можно положить и т.д.
Z>и т.п., чего не хватает-то?

О, уже всё есть? И как это я пропустил то такие позитивные новости... ))) Т.е. я могу спокойно программировать GUI (сереализацию и т.п. вопросы не рассматриваем) на Qt без использования при сборке проекта их препроцессора? )

Здравствуйте, night beast, Вы писали:

NB>что, отладчик для тебя слишком сложно?

Зачем отладчик? В отладчике появится код которого нет в исходнике? Не пытайся надувать щеки, выглядит смешно — этакий напакостивший школьник.

А теперь еще раз повторю вопрос:

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

Нормальный, конкретный вопрос, на который ты мог ответить как взрослый человек "Ой, был не прав", но предпочел устроить клоунаду, за которой я с интересом теперь наблюдаю