Здравствуйте, MTD, Вы писали:
NB>>то есть подтверждения заявы о вранье тоже не будет?
MTD>Конечно будет, после того как на мой вопрос четко и без увиливаний ответишь или признаешь неправоту.
уже отвечал. четко и без увиливаний.
могу повторить:
// these objects are all used to indicate that a QObject was deleted
// plus QPointer, which keeps a separate list
QAtomicPointer<QtSharedPointer::ExternalRefCountData> sharedRefcount;
счетчик ссылок в QObject.
не нравится/не согласен -- твои трудности.
Здравствуйте, night beast, Вы писали:
NB>уже отвечал. четко и без увиливаний. NB>могу повторить: NB>
NB> // these objects are all used to indicate that a QObject was deleted
NB> // plus QPointer, which keeps a separate list
NB> QAtomicPointer<QtSharedPointer::ExternalRefCountData> sharedRefcount;
NB>счетчик ссылок в QObject.
Это не счетчик ссылок, это просто флажок жив или мертв объект, не знаю почему его так назвали, ну и временем жизни он не управляет, вообще.
Re[62]: Библиотека для создания графических интерфейсов поль
Здравствуйте, MTD, Вы писали:
NB>>счетчик ссылок в QObject.
MTD>Это не счетчик ссылок, это просто флажок жив или мертв объект, не знаю почему его так назвали, ну и временем жизни он не управляет, вообще.
вторую строку коммента не осилил?
а назвали так потому что раньше кроме вика им еще и шаред пользовался.
повторяю. согласен или нет -- твои проблемы.
теперь хотел бы услышать цитаты на заявление о вранье.
Re[63]: Библиотека для создания графических интерфейсов поль
Здравствуйте, night beast, Вы писали:
NB>повторяю. согласен или нет -- твои проблемы.
Не спеши пока что ты флажок показал, я его тебе и сам показывал в самом начале, ты еще не поверил, что вот так все просто. Теперь покажи где счетчик ссылок в QObject который управляет его временем жизни?
Re[64]: Библиотека для создания графических интерфейсов поль
Здравствуйте, MTD, Вы писали:
NB>>думаю, на этом и закончим.
MTD>Снова не смог ответить и слился, как предсказуемо.
да. научить тебя пользоваться булом для флажков выше моих силах
так что в десятый раз показывать как именно это поле используется пожалуй не буду.
считаешь что флажок -- на здоровье.
итак на $$$ много времени потратил.
Re[67]: Библиотека для создания графических интерфейсов поль
Здравствуйте, MTD, Вы писали:
NB>>так что в десятый раз показывать как именно это поле используется пожалуй не буду.
MTD>Так ты ничего и не показал.
NB>>итак на $$$ много времени потратил.
MTD>Бла-бла-бла. Зачем начинал? Чтобы снова слиться?
Здравствуйте, alex_public, Вы писали:
_>И что, медленно работает? Я сам то не пробовал на таких объёмах, но код очевидный (две строчки — итератор из filesystem и проверка по маске из regexp) и по идее там негде существенно тормозить.
Медленно. WinAPI до 1000 раз быстрее оказался при поиске по маске. Ибо не перебирает всё подряд. Но я не критикую filesystem, тут как с сокетами — если нужно быстродействие, то делаем отдельно под каждую платформу. Если нет — то boost asio или аналоги. Лично мне из filesystem достаточно класса path. Вот он действительно удобный.
Re[26]: Библиотека для создания графических интерфейсов поль
Здравствуйте, SaZ, Вы писали:
_>>И что, медленно работает? Я сам то не пробовал на таких объёмах, но код очевидный (две строчки — итератор из filesystem и проверка по маске из regexp) и по идее там негде существенно тормозить. SaZ>Медленно. WinAPI до 1000 раз быстрее оказался при поиске по маске. Ибо не перебирает всё подряд. Но я не критикую filesystem, тут как с сокетами — если нужно быстродействие, то делаем отдельно под каждую платформу. Если нет — то boost asio или аналоги. Лично мне из filesystem достаточно класса path. Вот он действительно удобный.
Запустил сейчас ради интереса вышеописанный код на Boost (3 строчки) для поиска *.h файлов в папке исходников Qt (207937 файлов и папок). И получил результат в 42790 файла за 2065 миллисекунды. Стандартный виндовый Проводник ищет заметно дольше (правда он при этом ещё и показывает список файлов), так что не знаю для каких таких задач тебе не хватало быстродействия варианта из Boost. Ну и кстати, в WinAPI нет прямого аналога данного кода, т.к. там надо руками вызывать функцию поиска для каждого подкаталога (FindFirstFile не умеет работать рекурсивно). Так что очень сомневаюсь, что оно могло быть "в 1000 раза быстрее" — похоже на чьи-то фантазии... )
Re[27]: Библиотека для создания графических интерфейсов поль
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, SaZ, Вы писали:
_>>>И что, медленно работает? Я сам то не пробовал на таких объёмах, но код очевидный (две строчки — итератор из filesystem и проверка по маске из regexp) и по идее там негде существенно тормозить. SaZ>>Медленно. WinAPI до 1000 раз быстрее оказался при поиске по маске. Ибо не перебирает всё подряд. Но я не критикую filesystem, тут как с сокетами — если нужно быстродействие, то делаем отдельно под каждую платформу. Если нет — то boost asio или аналоги. Лично мне из filesystem достаточно класса path. Вот он действительно удобный.
_>Запустил сейчас ради интереса вышеописанный код на Boost (3 строчки) для поиска *.h файлов в папке исходников Qt (207937 файлов и папок). И получил результат в 42790 файла за 2065 миллисекунды. Стандартный виндовый Проводник ищет заметно дольше (правда он при этом ещё и показывает список файлов), так что не знаю для каких таких задач тебе не хватало быстродействия варианта из Boost. Ну и кстати, в WinAPI нет прямого аналога данного кода, т.к. там надо руками вызывать функцию поиска для каждого подкаталога (FindFirstFile не умеет работать рекурсивно). Так что очень сомневаюсь, что оно могло быть "в 1000 раза быстрее" — похоже на чьи-то фантазии... )
Возможно что-то поменялось. Я пробовал std::experimental::filesystem из какой-то msvs. Давно.
Re[4]: Библиотека для создания графических интерфейсов пользователя
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, ollv, Вы писали:
O>> хотелось заметить, что велосипеды вроде КУт скоро отомрут за ненадобностью.
MTD>С 2008 года, как начал писать на Qt я это слышу, еще то же самое я про С++ слышал, только раньше. Все отмирают они, все отмирают, вот вот и все.
Так )) наличие скажем так непродуктивной мысли в кут это не отменяет. Мало ли кто, что говорит. Вот зачем их туповатыйпрепроцессор ?
Да и ты знаешь, что сейчас своими руками рефлекшин реализуется — в полпинка? Вариадикки decltype и т.д, облегчают жизнь многократно. Но
Заблуждение в том, что ты ориентируешь на кут, надо смотреть глубже — MFC, Cbuilder и прочая прочая прочая, оно практически отмирает с так скажем популярных средств гуи разрботки. смысл в том, что мир на месте не стоит, а именно мир С++ на месте не стоит, и то, что позволял делать препроцессор КУТ с генерациейй кучи моков, будет реализуемо в плюсах (впрочем уже, лично я сейчас на своем проекте вполне удачно релаизовал рефлекшин, РПЦ и прочее ... абстрактную сериализацию чего угоно в любой backend подставь JSON XML/ BIN все вольется в инфрасруктурно тайповом виде)
O>>адью, O>>лично кут, мне — долго подбирал слово — противен
MTD>Понятно, мнение фанатиков особенно ценно, спасибо.
причем тут фанатизм, исключительно практика
смотри — вот столкнулся я тем, что рекурсия шаблона не глубже 500, и в майкрософте это не починить — влекм рантайм. )) кут я просто не люблю, слищком много фотростепенного геморроя, впрочем я не исключаю того, что просто ресурсов на создание нормального с идеологически\филосовской точки зрения ГУИ не хватит, так и буудем пользоваться велосипедами аля КУТ. Хотя КУТ больше асоциируется у меня с objective C and JAVA ..но никак не с плюсами. Благо во всякие фреймворки (ейген, ААД, буст std) им таки ходу нет. И стд фанкшин вызывает у меня куда больше приятных эстетических ощущений, чем селекторы ..
Compiler can be as trained AI but can't compose music.
Antheil piano jazz sonata. Я болен ПГМ.
Re[5]: Библиотека для создания графических интерфейсов польз
Смотрю я на ваши посты и вижу, что это всё размышлизмы из области "если бы да кабы, да росли бы во рту грибы". Оно как бы теоретически типа да — на плюсах и рефлексия, и рпц, и orm, и т.д., а вот практически каждый столкнувшийся с этим решает — "да ну его на!#" и берёт C#/Java и радуется жизни. Потому что, то что есть — зашкаливает по неудобству и/или сложности в использовании.
Когда невозможно слезть с плюсов — то делают кодогенерацию — даже она в тысячу раз удобнее, чем различные современные варианты присобачивания рефлексии к плюсам.
Qt же очень элегантно решает проблему. То, что там moc работает — не вижу проблем, туда же лезть не надо. А волноваться из-за него — это всё равно, что волноваться что кроме компилятора там работает ещё препроцессор и линкер.
Qt в своей сути вообще очень элегантная библиотека. По сути пример как нужно подходить к разработке библиотек. Как противоположность можно взять вектор развития современного с++ — явно же свернули не туда: вместо продумывания единой архитектуры начали туда лепить всё в стиле boost — "раз работает, то и так сойдёт, и пофиг, что оно всё разношёрстное, малофункциональное и без единой архитектуры/цели".
А что вот-вот появится рефлексия (и модули) — так я даже не буду напоминать сколько лет это "вот вот" уже длится — и кроме пшика результата никакого нет. И далеко не факт, что в нормальном для практического использования виде оно успеет появится при нашей жизни.
Здравствуйте, push, Вы писали:
P>Смотрю я на ваши посты и вижу, что это всё размышлизмы из области "если бы да кабы, да росли бы во рту грибы". Оно как бы теоретически типа да — на плюсах и рефлексия, и рпц, и orm, и т.д., а вот практически каждый столкнувшийся с этим решает — "да ну его на!#" и берёт C#/Java и радуется жизни. Потому что, то что есть — зашкаливает по неудобству и/или сложности в использовании.
Не стоит проецировать свои (и других, кто тоже не осилил язык) ощущения на всех вокруг. )))
P>Когда невозможно слезть с плюсов — то делают кодогенерацию — даже она в тысячу раз удобнее, чем различные современные варианты присобачивания рефлексии к плюсам.
Рефлексии в современном C++ нет в принципе (и на мой взгляд это главный недостаток языка, который должен быть в приоритете у Комитета), так что любые костыли, заменяющие эту функциональность, априори являются вариациями на тему кодогенерации. Просто она может быть реализована как внешними инструментами, так и средствами самого языка (возможности метапрограммирования в современном C++ вполне позволяют это). Однако в любом случае это всё костыли, которые будут выкинуты на помойку после принятия нормальной статической интроспекции (по образцу языка D) в стандарт языка (сильно надеюсь, что уже в C++20 мы это увидим).
P>Qt же очень элегантно решает проблему. То, что там moc работает — не вижу проблем, туда же лезть не надо. А волноваться из-за него — это всё равно, что волноваться что кроме компилятора там работает ещё препроцессор и линкер.
Qt ничего там элегантно не решает, хотя бы потому, что от неё в первую очередь ждут решения проблемы качественного кроссплатформенного GUI, для которого никакие там рефлексии (и соответственно moc'и) и т.п. не требуются. А те области, в которых рефлексия полезна (типа сериализации, ORM и т.п.), имеют в мире C++ множество своих реализаций, на голову выше варианта из Qt.
P>Qt в своей сути вообще очень элегантная библиотека. По сути пример как нужно подходить к разработке библиотек. Как противоположность можно взять вектор развития современного с++ — явно же свернули не туда: вместо продумывания единой архитектуры начали туда лепить всё в стиле boost — "раз работает, то и так сойдёт, и пофиг, что оно всё разношёрстное, малофункциональное и без единой архитектуры/цели".
Это как раз Qt отстало от развития современного C++, оставшись где-то в 90-ых. Хотя понемногу они пытаются продвигаться ближе к современным тенденциям в программирование, но очень медленно...
P>А что вот-вот появится рефлексия (и модули) — так я даже не буду напоминать сколько лет это "вот вот" уже длится — и кроме пшика результата никакого нет. И далеко не факт, что в нормальном для практического использования виде оно успеет появится при нашей жизни.
Это не так. C++11 был важной вехой в мире C++ не только своими новшествами в языке, но и тем, что был введён достаточно строгий регламент дальнейшего его развития — новые версии каждый 3 года с вполне однозначными механизмами обсуждения новшеств и т.п. Да, в C++17 не успели принять (точнее договориться между всеми сторонами) много важного. Но главное, что вполне работающие реализации всех этих нужных вещей были уже представлены в Комитет, так что теперь при обсуждение следующей версии стандарта как раз с них и начнут. Причём уже не с ознакомления, а займутся доработкой до состояния, удовлетворяющего все стороны. Поэтому я на 100% уверен, что в следующем стандарте будут концепты, сопрограммы и диапазоны (как расширение STL на базе концептов). И с большой вероятностью модули, интроспекция, транзакции, работа с сетью (добавка boost.asio в стандартную библиотеку).
