Re[37]: Библиотека для создания графических интерфейсов поль - C/C++. Прикладные вопросы

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

_>Однако можно было без проблем кинуть кнопку на форму, нажать по ней правую кнопку мыши, выбрать пункт меню типа (сейчас уже естественно не помню) "Перейти к обработчику" и ты оказывался в коде обработчика (причём если его раньше не существовало, то он генерировался средой на ходу). И всё это работало без всяких внешних препроцессоров 20 лет назад.

Работало, но не кросс-платформенно. Для кросс-платформенной библиотеки надо делать очень толстый слой абстракции, который не всегда можно тривиально реализовать. У Qt же сейчас очень качественная архитектура, которая позволяет достаточно легко добавить поддержку новых платформ (и этой возможностью пользуются, как-то собеседовался на фирму, которая как раз свой порт Qt под какое-то железо делала).
Похоже, тут всё-таки вопрос вкуса. Гуглу для работы протобафа нужен кодогенератор, gsoap — аналогично, WinForms — тоже кодогенерация, пусть и средствами компилятора (хоть и .net). Уверен, что можно ещё много примеров найти.
Лично я тут проблемы не вижу. Для меня кодогенерация — намного более правильное решение, чем извращение со средствами языка.

_>В wxWidgets аналогично, но гораздо более продвинуто (с произвольными сообщениями и т.п.). И опять же без всяких внешних препроцессоров и кстати даже без макросов.

Ну удачи им с портированием на Android. Опять же — список поддерживаемых платформ у Qt на порядок длиннее. Тот же QNX.

_>Соответственно в Qt по сути всё тоже самое, только вот зачем-то понадобился внешний препроцессор.

Затем, что так проще.

_>Мне не нужна Qt. Мне нужна GUI библиотека, позволяющая делать качественные, нативно выглядящие интерфейсы для Android/Windows/iOS/OSX/Linux (естественно с одной кодовой базой). Если кто-то подскажет мне другой инструмент с такой функциональностью, то я с радостью выброшу этого жирного монстра (Qt) подальше — всё равно весь не GUI код у меня использует только нормальные библиотеки (стандартная библиотека языка, Boost и т.п.). Однако к большому сожалению ни одного сравнимого инструмента не видно, так что приходится пользоваться этим.

Да, и сделать такой инструмент с нуля ну очень тяжело. Майкрософт вон пытаются ксамарин впихнуть. Но опять же — это .net.
Не понимаю только, почему вы Qt называете жирным? QtLite + статическая линковка + UPX и размер приложения уже получается очень маленький. Опять же — это только если есть смысл заморачиваться по размеру. Мне только в одном проекте пришлось.

Ещё одно достоинство Qt, которое косвенно влияет на размер дистрибутива — с Qt не нужно тащить зоопарк 3rdparty и писать между ними адаптеры. Базы, сеть, потоки, веб, 2д3д графика, парсеры — всё использует общие типы данных и можно писать код в одном стиле.

SaZ>>И почему вам не нравится использование кодогенератора (который делает простой и легальный код) — я так и не услышал.
_>Вполне однозначный ответ уже был озвучен здесь http://rsdn.org/forum/cpp.applied/6907324.1.

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

_>Это если нужна рефлексия (которая для GUI вообще ни к чему). А если без неё, то можно было без препроцессора уже 20 лет назад.

Расскажите про GUI, который вы делаете?
Первый пример, который мне пришёл в голову — панель для редактирования свойств объектов. Без рефлексии там пришлось бы писать тонны кода на каждый новый класс. А с рефлекйсией — один раз написали и забыли.

SaZ>>И да, есть Verdigris который более-менее позволяет Qt без препроцессора.
_>Любопытно. Интересно, IDE нормально это понимает (чтобы не сломался описанный выше механизм работы) или нет? )

ReSharper — точно нормально, так же как и сгенерированный Qt код. Но всё это баловство, которое усложняет разработку. Вот если они доведут до ума свой проект по переделке moc на основе clang (пока там очень сырая альфа) — то будет круто.

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

SaZ>Лично я тут проблемы не вижу. Для меня кодогенерация — намного более правильное решение, чем извращение со средствами языка.

Для меня особенно показателен пример правильный с точки зрения фундаменталистов (все средствами языка), но совершенно абсурдный с точки зрения разума — Boost Spirit. Можно взять yacc или что-то подобное, встроить в сборку, компилировать за доли секунды, иметь нормальную диагностику ошибок и гибкость для модификации. А можно взять спирит, компилировать по 5-10 минут, получать сообщения об ошибки в 400 строк из которых ничего не понятно и боятся лишний раз тронуть написанное. Еще лично для меня забавно выглядят все наезды на препроцессор от пользователей языка, где препроцессинг вообще стадия компиляции.

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

MTD>И что? Никто на производительность не жаловался.

Я жалуюсь. Кутешный софт очень часто тормозное гавно

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

NB>ответ был дан в той ветке.

Ответа не было. Конкретно имя файла и номер строки где находится счетчик который управляет временем жизни QObject или балабол. Обоснование как может работать подсчет ссылок если гоняются голые указатели. Номер файла и номер строки где QObject себя удаляет когда счетчик ссылок стал равен нулю.

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

NB>>причем умудрившись при этом наехать на остальных, не разделяющих твоего мнения.

MTD>Хорошо, всем приношу свои извинения. Давай заканчивать препирательства, в принципе мы оба понимаем, что сейчас демонстрируем баранье упорство докапываясь до формулировок, по-существу все уже и так понятно. Мир, дружба

принято.
отрадно видеть что мои усилия были не напрасны

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

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

Я перешёл на Qt (с MFC) примерно полтора года назад.
Лично мне Qt очень понравился. Я бы даже сказал, что занимаясь на C++, Qt — это the best!
Если говорить точнее, то всё, о чём только я мог мечтать, занимаясь на MFC, реализовано — причём в очень хорошем качестве — в Qt.
Да, надо освоить ключевые понятия библиотеки Qt, и тогда ни о каких 'траханьях' речь не идёт.

Дополнительный бонус Qt — его кроссплатформенность!
Но даже если этот бонус не принимать во внимание, впечатление от Qt намного круче, чем от MFC.
Это даже с учётом того, что я при разработках на MFC активно применял пакет MFC Feature Pack (который был ранее известен как BCG Controls Gallery от BCGSoft).

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

NB>причем умудрившись при этом наехать на остальных, не разделяющих твоего мнения.

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

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

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

R>я выразил свое мнение: что на sciter мне лично было легче создать гуй, гораздо легче, соот. в сравнении с этим опытом я больше не хочу трахаца с qt для написания гуй. это мое личное мнение, я его никому не навязываю, не согласен ставь минус, согласен плюс.

Аргументов у тебя нет, то есть ты соврал? Ну ок.

MTD>>Чтобы понять насколько популярна технология не обязательно ее изучать, количество информации в гугле адекватная оценка для этого. Это непонятно или есть возражения? Как популярность предлагаешь оценить ты?

R>кол-во информации в гугле говорит всего лишь о доступности технологии

Как может быть популярной недоступная технология? А ты жжешь.

R>блин вроде это все логично

Нет.

R>почему я должен это разжевывать вам?!

Да, я понял, что с аргументацией у тебя туго — соврал и в кусты.

R>далее малое кол-во выбросов в гугле не говорит о том хуже она или нет. вы же пытаетесь натянуть сову на глобус.

Ты все время пытаешься съехать с темы и навязать мне то, чего я не говорил. Я сказал, что популярность у него мала — это факт.

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

R>там весь текст наполнен печалью и жалобой о несправедливости.

Цитату с жалобами ты не привел, стало быть ты трепло.

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

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

MTD>>Сейчас в виртуалке попробую, так стремно.

MTD>Запустил. Ну что сказать, по одежке как говорят встречают. Ты менеджеры компоновки не осилил что-ли? Почему оно все зарезалось? Я только запустил, ничего не трогал:

MTD>Image: crop.png

Да купи уже себе монитор побольше

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

CS>Забыл подписать сам инсталлер. Можешь попробовать еще раз, ну или из .zip запустить. Там notes.exe подписан.

Я не злой, и как человека, и как специалиста я тебя очень уважаю, то что ты делаешь очень круто, просто ты обычно забегаешь с шашкой наперевес — это сразу вызывает обратную реакцию. Лично я от перехода на Sciter сейчас профита не вижу вообще, меня Qt по большей части устраивает (аргументы про размер вообще не употребляй — смешно, честное слово), для кого-то же может быть будут сплошные плюсы — welcome.

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

M>Мне не до лампочки. Если каждая мелочь будет свой куте тянуть мои 3тб быстро закончаться

Я проведу для тебя бесплатный урок арифметики. Терабайт — это 10^12 байт, итого у тебя 3*10^12 байт. Мегабайт — это 10^6 байт. Qt, гулять так гулять пусть линкуется динамически со всеми модулями вааще — ~40*10^6 и каждый софт тянет полный комплект. Делим одно на другое, получаем 75000 приложений. Если же покончить с наркоманством и взять средний размер в статике — 7 мб, то получится под пол миллиона приложений. А вообще не все в мире неправильно устроено, очень хорошо, что на мнение людей жаждущих ось на одной дискете и офис на второй давно всем положить.

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

R>Дело не в производительности, а в том что dllimport предназначался для winapi, это слишком топорный инструмент чтобы отмаршалить скажем
R>

R> std::vector<COLORREF> GetPalettte(const std::wstring& name)
R>

R>не говоря уже о более сложных случаях (ну или я что-то не знаю)

То, о чём Вы пишите (работа с winapi через dllimport) именуется PInvoke (Platform Invocation Services):
https://en.wikipedia.org/wiki/Platform_Invocation_Services
http://www.pinvoke.net/default.aspx/ntdsapi.DsBind

Впрочем, это не мешает применять .NET аттрибут dllimport и для других (в т.ч. и самописных) DLL.

При этом, в аргументах методов/функций могут применяться не только POD типы:
https://msdn.microsoft.com/en-us/library/ef4c3t39.aspx
https://www.gamedev.net/forums/topic/556938-pinvoke---passing-an-array-of-structs
в том числе и строковые:
https://msdn.microsoft.com/en-us/library/s97shtze.aspx

Насчёт STL коллекций — думаю, что их потребуется передавать как простой массив (в стиле ANSI_C).

P.S. Что же касается производительности при выполнении кода, то здесь всё зависит от класса разрабатываемого приложения:
— если для бухгалтерии и документооборота на производительность можно и не обращать внимания;
— то для технических и научных приложений, для приложений моделирования — производительность НЕ ПУСТОЙ звук!
Вот и получается, что для определённогокласса приложений: нативный C++ видится как оптимальный выбор.

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

NB>>ну то есть объект нужен только для того чтобы проинициализировать в конструкторе, и удалить в деструкторе, и в промежутке между этим никак не используется и не изменяется?

MTD>Код почитай перед тем как задавать вопросы. Qt не использует счетчики ссылок, они используют связь parent-children, когда удаляется родитель он отписывается от всех сигналов и удаляет по списку своих детей. Самому таким образом ничего удалять не надо, создавать надо в куче.

и как использование связи parent-children отменяет использование счетчика ссылок?
насчет того что чего-то удалять не нужно попробуй создать на куче объект без парента и забудь удалить.

Здравствуйте, 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 реально удобнее и надежнее делать в ... ну не буду повторяться.

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

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

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

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

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

MTD>Не проблема, бери написанный на Sciter — все летать будет. Или тоже тормозить? Не знаю, расскажешь.

Спасибо но вариант не совсем подходит, есть еще?

Зачем сразу в "бутылку" лезть?

Ни первый ни второй я не использую. Я совершенно в другой области работаю.

Во вторых, наверяка кроме выбора библиотеки там еще некий чудак на букву М решил добавить дизайна. И эти все текстуры и прочие ненужные "красоты" хотелось бы выпилить.

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

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

Патологоанатом, закрашивает пятна и крапинки в однотонный цвет а не дорисовывает новые.

Если подскажешь как хоть как-то ускорить это дело, буду признателен. Чтобы простой плоский дизайн. Может настройкак какая "FumigateGayDesign=1" ?

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

_>Потому как Boost.Spirit — это как раз один из весьма ярких и известных примеров современного направления развития C++.

Это не то развитие которого ждет индустрия. С точки зрения ученого да, все классно, средствами языка можно все выразить, невероятная мощь, ребята умные, спору нет, вот только когда нужно просто дом построить им становится неинтересно, слишком приземленно. Нужен инженер, а у инженера интеллектуальные способности несколько иные и потребности отличаются. Инженеру же нужен простой, удобный и быстрый инструмент. Я пробовал использовать Boost.Spirit и в процессе мне постоянно приходилось думать как делать, а не о том, что мне нужно сделать, в то время как yacc прост как палка и понятен. С++ стал популярен, потому что на тот момент времен затачивался под инженеров, а буст в массе пилят ученые, поэтому многие библиотеки из него использует дай бог сотня людей во всем мире. Здесь показателен другой язык заточенный под решение практических задач, а потому неплохо выстрелившим, я о Go — недавно Мейл.ру проводил хайлоад кап, так первые строчки все были заняты Go уже через несколько дней, в то время как решения на плюсах появились только где-то к концу второй недели, при этом по быстродействию не сказать, что Go был порван. Вот тебе и соотношение скорость разработки на скорость выполнения.

_>Ну предложи своё решение данной задачки) Чтобы с такой же краткостью и быстродействием.

Установить локаль, читать из потока.

MTD>>Про время компиляции, диагностику ошибок и удобство в поддержке возражений нет? Ок.

_>Про удобство поддержки очевидно как раз всё наоборот — одна краткая строчка против целого нетривиального файла.

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

_>Время компиляции у меня например не минуты, а секунды (потому что любой профессионал в C++ работает только с помощью эффективных SSD).

Да SSD сейчас у всех, нашел чем удивить, вот только не панацея это. Реакция людей пересевших, например с С# на плюсы — компиляция подвисла, что делать.

_>Просто чтобы было понятно, что преимущество одновременно по всем параметрам (и лаконичность кода и удобство интеграции и итоговое быстродействие).

Я пока у Spirit не вижу вообще никаких преимуществ кроме идеологических.

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

MTD>>Человек не успел написать к финалу

S>Тезис о скорости разработки на Go оказывается несостоятельным.

Может он про чемпионат узнал за 2 дня до финала, так что мимо.

S>Предлагаете поверить вам на слово?

Я инженер и вопросами веры не занимаюсь, с этим к батюшке в церковь.

MTD>>Это ты сейчас подтасовкой и манипуляцией занимаешься сравнивая fasthttp с голым epoll на хаках. Или сравнивай топ С и топ Go или сравнивай fasthttp с Asio.

S>Повторю еще раз: написать на C++ так, чтобы было вровень с Go/fasthttp несложно, это не требует много времени и усилий.

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

S>Однако, если затем нужно выжать максимальную производительность, то в C++ это достигается, а в Go обнаруживается заметный разрыв.

Аж меньше 20%.

S>Т.е. не видно, где бы Go давал существенное сокращение времени разработки при сравнимой производительности решений.

Да на здоровье, отрицай дальше. Как я уже сказал, твои убеждения на объективную реальность никакого влияния не оказывают.

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

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

Да ты что? А как пел, как пел:

и как использование связи parent-children отменяет использование счетчика ссылок?
насчет того что чего-то удалять не нужно попробуй создать на куче объект без парента и забудь удалить.

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

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

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

NB>похоже, то самый случай когда медицина бессильна

Тебе видней, что тебе врач сказал.

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

S>>показывает производительность на уровне Go/fasthttp, в которые было вложено в несколько раз (а то и порядков) больше времени и усилий.

MTD>Доказательство будут, что в несколько раз (а то и порядков) больше времени и усилий или ты балабол?

https://github.com/valyala/fasthttp -- 972 коммита, 27 контрибуторов, первый коммит -- 19 октября 2015-го.

restinio на сегодняшний день -- 421 коммит, 3 контрибутора, первый коммит -- 5 апреля 2017-го.

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

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

MTD>>>Доказательство будут, что в несколько раз (а то и порядков) больше времени и усилий или ты балабол?

S>>https://github.com/valyala/fasthttp -- 972 коммита, 27 контрибуторов, первый коммит -- 19 октября 2015-го.

S>>restinio на сегодняшний день -- 421 коммит, 3 контрибутора, первый коммит -- 5 апреля 2017-го.

MTD>И что это должно показать, кроме того, что один проект начался 19 октября 2015, а другой 5 апреля 2017?

Видимо, отсутствие мозгов. Или способности их использовать.

Ибо даже дата первого коммита, как не сложно догадаться (при наличии мозгов, конечно же), вовсе не обязательно совпадает с датой начала проекта.

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

S>Видимо, отсутствие мозгов. Или способности их использовать.

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

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

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

M>>Qt — оно конечно модно и прогрессивно

MTD>Ты не в теме, модно и прогрессивно — Sciter.

M>>У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения.

MTD>Мир не стоит на месте. Фреймворк живет — это же не полумертвый wxWidgets на котором весь софт выглядит сделанным 15 лет назад и не Sciter который пилит один хоть и талантливый человек, а потому шаг влево, шаг вправо — Segmentation fault.

+1 Пришлось как-то пересобирать http://www.ecoscentric.com/devzone/configtool.shtml написанное на wxWidgets,
такой гемор, тогда когда я его использовал разные дистрибутивы linux поставляли wxWidget c/без unicode,
с gtk2 или 3 и т.д. и т.п., пришлось руками компилировать еще и wxWidgets и таскать вместе с пришложением
библиотеки. А если бы это была бы не внутренняя утилита, а ее заказчику поставляли, ее что для всех вариантов тестировать?
Умножая на количество дистрибутивов RedHat/Ubuntu/Suse это сколько же гемора?

M>>А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю.

MTD>Ой, да хорош сказки рассказывать (я конечно могу допустить, что такие проблемы быть могут, но ты же тогда сможешь о ним рассказать?). Я конечно третий не застал, начал с четвертого в 2008 году, потом когда переходил на пятый весь гемор был переписать сборочные скрипты, код скомпилировался и заработал.

Здесь согласен и не согласен.

Имел опыт перехода с Qt 2 -> Qt 3 -> Qt 4 -> Qt 5.
С Qt 2->3 помню не очень, но раз ничего не запомнил значит проблем особых не было.
Для перехода с Qt 3 на 4 была qt3support библиотека, т.е. по сути все что ни выкинули, можно было
вернуть этой библиотекой, а потом постепенно от нее избавляться. Поэтому портирование было элементарным.
с Qt 4 на 5 вообще не было проблем, правишь заголовочные файлы и все.

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

И в районе Qt 5.5 они сделали deprecated Script Engine, но QJSEngine идущий ему на смену не обладает всей
функциональностью ScriptEngine.

V>О QT и шарпе я в курсе и гуглом пользоваться умею.
Есть еще http://www.codejock.com/products/toolkitpro/?2yn6s14z=zsp, он плюсовый

V>Интересуют мнения тех, кто с таким библиотеками работал
мнение такое
— дотнетные библиотеки радикально превосходят все что есть на плюсах
— создание API на C++ CLI для разработки гуя на шарпе — проще чем кажется в начале

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

M>Мне не до лампочки. Если каждая мелочь будет свой куте тянуть мои 3тб быстро закончаться

У меня на одном проекте с динамической линковкой (со статикой было бы куда меньше) Qt с GUI+QtWebKit занимала 9 мегабайт.
А когда вопрос размера дистрибутива стал всё чаще подыматься — им занялись. И как результат получилось вот это. А ещё можно покрыть каким-либо UPX-ом.

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

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

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

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

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

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

R>>еще раз для особо понятливых — опыт кроссплатформенной разработки на Qt у меня есть, не такой большой как у Вас, но достаточен чтобы я мог сравнить с разработкой гуй на sciter.

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

я выразил свое мнение: что на sciter мне лично было легче создать гуй, гораздо легче, соот. в сравнении с этим опытом я больше не хочу трахаца с qt для написания гуй. это мое личное мнение, я его никому не навязываю, не согласен ставь минус, согласен плюс.

R>>Опыта в sciter у Вас нет, но Вас это не смущает, наоборот Вам он не нужен т.к. вам достаточно сравнить выброс гугл.

MTD>Чтобы понять насколько популярна технология не обязательно ее изучать, количество информации в гугле адекватная оценка для этого. Это непонятно или есть возражения? Как популярность предлагаешь оценить ты?

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

R>>Я помоему вспомнил Вас, Вы выкидывали свой код сюда и жаловались, что Вас куда-то там не взяли на с++ курсы.

MTD>Далеко не надо ходить, соседняя тема: http://rsdn.org/forum/cpp/6717561.1

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

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

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

MTD>>Из того, что еще хорошо знаю, Telegram на Qt написан: https://telegram.org/

V_>Ужасающе тормозит в RDP.

Не проблема, бери написанный на Sciter — все летать будет. Или тоже тормозить? Не знаю, расскажешь.

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

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

CS>>Дык я же вроде нигде тебя не призывал — бросить Qt и переходить на Sciter.

MTD>Вроде только этим и занимаешься, причем поливая дерьмом Qt, что выглядит не очень.

Где? Пальцем покажи...

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

Pzz>>С логикой-то нет проблемы. Мы, я полагаю, все же сейчас скорее про графику говорим.

CS>А с графикой что? Рисует в конце концов GPU. HTML это дерево DOM элементов + связанный набор объектов на стороне GPU которые и рисуются когда надо.
CS>Времена когда ты получаешь WM_PAINT и в нем исполняешь код по заливке пикселов (primitive rasterizing) уже ушли.
CS>300 dpi retina monitor и старый 96 dpi монитор это две большие разницы — внезапно пикселей в 9 раз больше стало. CPU рисование — ёк.

Мне начхать, кто рисует, GPU, CPU или водопроводный кран. Я говорю, что HTML — очень неудобный инструмент, чтобы описать красивую картинку. Не то, чтобы на нем невозможно было это сделать, но неудобно. Примерно, как трусы через голову надевать, ну может чуть попроще.

CS>Удобство это вещь сугубо субъективная. Что для тебя лично есть "удобно"?

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

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

Pzz>Мне начхать, кто рисует, GPU, CPU или водопроводный кран. Я говорю, что HTML — очень неудобный инструмент, чтобы описать красивую картинку. Не то, чтобы на нем невозможно было это сделать, но неудобно. Примерно, как трусы через голову надевать, ну может чуть попроще.

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

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

MTD>попробуй сейчас в интернете почтовый ящик завести без номера телефона, тебя ждет открытие.

На гмейле завел — телефон спрашивают но поле не обязательное — не вводил ничего

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

MTD>>Любопытно, что именно тебе таким показалось? Телеграм?

M>Сейчас не скажу, давно ничего кутешного не ставил.

Понятно, еще один любитель бла-бла-бла. Твое мнение очень, очень важно.

M>ЗЫ Телеграм? Что это?

Это еще круче виндовс 95, только на 1 дискете и памяти жрет меньше.

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

CS>Там больше проблемы не циклическим dispatching по существу (который тоже есть как проблема), а с ownership ибо QObject это refcounted штука.
CS>Т.е. замкнутая цепочка slot subscribers может быть неудаляемой обычным способом.

CS>Но это собственно не Qt проблема, а общая для refcounted систем.

А подробнее можно? Что такое замкнутая цепочка подписчиков? Типа объект А подписан на Б, Б подписан на А? С удалением таких вещей в Qt проблем нет.

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

S>Можно в этом месте по подробнее, а то я за много лет использования Qt первый раз слышу о каких-то таких проблемах.

Он Qt не знает, как и большинство отметившихся в теме, но мнение имеет. QObject не имеет счетчика ссылок.

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

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

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

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

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

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

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

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

У тех, кто на Sciter hello world заочно написал и уже уверовал в его богоизбранность? Похоже, что да.

P.S. Я хз почему Qt на ряд граждан так действует — как психиатр-любитель продолжаю наблюдения.

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

NB>это точно. ну да чего еще от фанакика ожидать

Ох, уже который раз переход на мою личность, вот только не делает это тебя правым. Кстати, почему ты упорно называешь меня фанатиком? Я просто указываю на то, что ты не прав как в Qt контролируется время жизни QObject.

MTD>>

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

NB>я тебе показал. если нужен конкретный файл и номер строки, то пожалуйста, мне не жалко

Ты снова показываешь не то. Вопрос звучал конкретно:

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

NB>хорошо, это не счетчик ссылок. тогда что, по твоему?

Там даже комментарий написали:

these objects are all used to indicate that a QObject was deleted

Также я с самого начала показал код как это используется: http://rsdn.org/forum/cpp.applied/6905071.1

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

MTD>>Тогда как может работать счетчик ссылок? Если используются голые указатели невозвожно отследить время жизни и корректно удалить, когда на объект не осталось ссылок.

NB>очевидно, по крайней мере мне, что он работает когда используются не голые указатели QSheredPointer, QWeekPointer, QPointer.

Так можно, например, std::vector положить в std::shared_ptr и утверждать, что std::vector использует счетчик ссылок.

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

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

_>>Оу, какие у нас тут специалисты подъехали... )))
MTD>По-существу обсуждать тебе видимо нечего, решил сразу на личность съехать?

Это не переход на личности (если что, у меня к тебе никакого негатива нет), а именно по делу. Потому как Boost.Spirit — это как раз один из весьма ярких и известных примеров современного направления развития C++. Который демонстрирует возможности, абсолютно недоступные ни в одном другом мейнстрим языке. Так что когда вроде как C++'ик пишет подобное про Spirit (я уже молчу про сравнение с yacc), то это вызывает вопросы...

_>>Ну т.е. тебя тогда не затруднит показать пример красивой реализации на yacc скажем простейшего кода загрузки в vector массива double чисел, хранящихся в большом текстовом файле (скажем в американском формате с точкой и разделённых между собой запятой)?
MTD>А зачем для этого нужен yacc или Spirit?

Ну предложи своё решение данной задачки) Чтобы с такой же краткостью и быстродействием.

MTD>Про время компиляции, диагностику ошибок и удобство в поддержке возражений нет? Ок.

Про удобство поддержки очевидно как раз всё наоборот — одна краткая строчка против целого нетривиального файла.

Что же касается времени компиляции и ошибок, то тут определённые недостатки есть, но они вполне себе исправляются. Время компиляции у меня например не минуты, а секунды (потому что любой профессионал в C++ работает только с помощью эффективных SSD). А для эффективной обработки ошибок в шаблонах в C++ как раз и вводят концепты. Да, в C++17 они не успели попасть (хотя в gcc уже давно работают), но в C++20 будут уже 100% и тогда все подобные библиотеки получат эффективный инструмент для нормальных сообщений об ошибках (сейчас в принципе тоже можно через enable_if, но уж слишком громоздкой — мало кто реализует полноценно).

_>>Ну а когда справишься с собственно написанием кода, то попробуем ещё померить получившуюся производительность...
MTD>Зачем? Я уверен у yacc производительность достаточно хорошая, а в экстремальных случаях можно навелосипедить с учетом знания входных данных и уделать любой универсальный генератор парсеров.

Просто чтобы было понятно, что преимущество одновременно по всем параметрам (и лаконичность кода и удобство интеграции и итоговое быстродействие).

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

S>>"Первые решения", это, наверное, парочка самых первых реализаций на C++

MTD>А то, что на Go это тоже были первые решения не считается? Чик-чик мы в домике.

Ну так о том и речь: если нужно быстро написать, но не нужно быстро работать, то Go "сияет".

S>>Если вообще, то примеры GUI-приложений на Go где-то можно посмотреть?

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

Ну когда перепишете ICQ на Go, тогда и расскажите про универсальный язык Go.

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

MTD>на практике в большинстве случаев даже быстрее C и C++

Из чего это видно? На том же highloadcup этого не видно. Других примеров этой теме еще не было.

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

Для того, чтобы выжать максимум, нужно писать на низком уровне. Тот же highloadcup показал, что спуститься на низкий уровень в C++ можно и это делают многие. На Go этого не сделали, как только производительности fasthttp перестало хватить, так все, стоп.

А написать вровень с fasthttp и на C++ не сложно, и ни на какой низкий уровень опускаться не нужно.

S>>Ну когда перепишете ICQ на Go, тогда и расскажите про универсальный язык Go.

MTD>Зачем? Пока ICQ на языке не напишешь, то языка как-бы и нет? Питона нет, Руби, Джавы и т.д.

Какая тонкая подмена темы. Речь шла об универсальности. Чтобы Go был универсальным, на нем хотелось бы видеть что-то кроме REST-овых back-end-ов и Docker-а. GUI, например. Очень характерный пример, между прочим.

MTD>Взрослый человек, а такую ахинею несешь.

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

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

O> хотелось заметить, что велосипеды вроде КУт скоро отомрут за ненадобностью.

С 2008 года, как начал писать на Qt я это слышу, еще то же самое я про С++ слышал, только раньше. Все отмирают они, все отмирают, вот вот и все.

O>адью,
O>лично кут, мне — долго подбирал слово — противен

Понятно, мнение фанатиков особенно ценно, спасибо.

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

NB>вижу, из предыдущего общения кое-кто так и не сделал правильных выводов

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

NB>жаль.

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

NB>тяжко тебе наверно по жизни с таким отношением к окружающим

Хорошо, тяжко-тяжко мне, тебе полегчало?

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

NB>>ответ был дан в той ветке.

MTD>Ответа не было. Конкретно имя файла и номер строки где находится счетчик который управляет временем жизни QObject или балабол. Обоснование как может работать подсчет ссылок если гоняются голые указатели. Номер файла и номер строки где QObject себя удаляет когда счетчик ссылок стал равен нулю.

ну вот, а я то надеялся сегодня услышать удивительных историй из жизни слабых ссылок. беда

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

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

MTD>Я кстати кажется понял от чего у тебя такая боль — objectizer так и не взлетел, стали пилить restinio, а оказывается, что и он в перспективе никому не нужен — есть язык простой как палка, со сборкой мусора, на котором программист с меньшей квалификацией может писать столь же производительные сервера тратя меньше времени. Сочувствую. Мне тоже с одной стороны жаль, что ниша языка на котором я пишу за деньги 10 лет все сокращается, но это нормальный процесс — каждый инструмент под свою задачу. За С++ останутся низкоуровневые вещи и огромные in memory db, я так представляю.

Хы, вообще то на C++ как раньше в серверном бэкенд писали только в компаниях типа Google или Yandex, так и будут продолжать только в них это делать (потому что только для подобных им масштабов это реально выгодно, а остальным проще взять Python/JS и чуть более мощное железо). А вне серверного бэкенда опять же никакого Go не видно (там скорее Java что-то пытается с древних времён, но опять же в исчезающих количествах). Так что странные у тебя выводы. В том смысле что Go в своей нише действительно не плох, но C++ как бы это вообще не касается (там скорее Java и C# должны беспокоиться — это их ниша "более менее быстрого не скриптового бэкенда").

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

NB>думаю, на этом и закончим.

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

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

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

CS>>FreeConferenceCall https://www.freeconferencecall.com/global/ca/features

MTD>Достаточно поделок на сегодня, спать плохо буду.

Ну спите спокойно дорогой товарищ, и пусть вам сняться эротические сны про slot и друга ея signal ...

Не бери в голову — всё вы делаете правильно — того динозавра давно надо было переписывать. В Qt так Qt, всё не в Электрон какой прости хоспидя.
Хотя судя по размеру дистрибуции вы туда WebKit все таки вынуждены были воткнуть. Без HTML никуда нынче, да.

Кстати, download icq setup, тех 46 mb у меня занял 4 минуты.

Мне как-то главный UX гай из софтверной конторы из топ 100 рассказывал что по их исследованиям пользователь принимает решение про использование продукта за первые 40 секунд начиная от click на download.

И первый экран что появится — критически важен.

У вас же 4 минуты скучного ожидания и в конце пустая форма "Введите свой номер телефона". Вообще без объяснений... И дальше не пускает. Снес нафиг эту наглость сразу. Зачем messemger'у мой номер телефона? Которого у меня лично кстати вообще нет.

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

MTD>Лично я от перехода на Sciter сейчас профита не вижу вообще

Дык я же вроде нигде тебя не призывал — бросить Qt и переходить на Sciter.

Просто зря меня не послушали год назад — реально быстрее бы получилось. Sciter конечно не идеален, но для данной задачи всяко лучше Qt представляется. HTML (ну или там подобие его richtext) всё равно нужно рисовать.

Вот пример "RnQ Маленькая аська

" от Mikanoshi Kimemoshito, русского японца как я понял.

Это Delphi и Sciter UI в нём:

MTD>(аргументы про размер вообще не употребляй — смешно, честное слово)

Мулечку про то что размер не важен я слышал...

На reddit любая тема про Electron или Atom...

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

MTD>Из того же highloadcup и видно. Первые решения на плюсах использовали Asio и прочие либы, при этом сливали Go с его fasthttp, потом начали оптизировать все и вся, выбрасывать либы, использовать голый epoll, душить аллокации и кое-как обогнали. Чисто для справки я в курсе, потому как сам там есть и прошел весь путь от и до. С++ с Asio сливает Go независимо от того нравится тебе это или нет.
MTD>Это не так. Ты пробовал написать? Если нет, то откуда такая уверенность?

Коллега писал. В финале на 41-ом месте, как раз перед оставшимися Go-шными решениями. Чистый Asio + родной http_parser из Node.js, никакого душения аллокаций. Даже никаких предварительно сформированных JSON-ов не было, генерация ответов через RapidJSON. Как-то это сильно противоречит вашим утверждениям о том, что C++ в большинстве случаев сливает Go. Даже в том, в чем Go "сияет".

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

V_>Чтобы хоть как-то не оттолкнуть старых клиентов, я бы оставил простой клиент (см. V 6).

Ты не поверишь, я сам за это топил, но развитие продукта определяют не программисты.

V_>Если подскажешь как хоть как-то ускорить это дело, буду признателен. Чтобы простой плоский дизайн. Может настройкак какая "FumigateGayDesign=1" ?

Увы, такой нет.

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

_>>И что, медленно работает? Я сам то не пробовал на таких объёмах, но код очевидный (две строчки — итератор из filesystem и проверка по маске из regexp) и по идее там негде существенно тормозить.
SaZ>Медленно. WinAPI до 1000 раз быстрее оказался при поиске по маске. Ибо не перебирает всё подряд. Но я не критикую filesystem, тут как с сокетами — если нужно быстродействие, то делаем отдельно под каждую платформу. Если нет — то boost asio или аналоги. Лично мне из filesystem достаточно класса path. Вот он действительно удобный.

Запустил сейчас ради интереса вышеописанный код на Boost (3 строчки) для поиска *.h файлов в папке исходников Qt (207937 файлов и папок). И получил результат в 42790 файла за 2065 миллисекунды. Стандартный виндовый Проводник ищет заметно дольше (правда он при этом ещё и показывает список файлов), так что не знаю для каких таких задач тебе не хватало быстродействия варианта из Boost. Ну и кстати, в WinAPI нет прямого аналога данного кода, т.к. там надо руками вызывать функцию поиска для каждого подкаталога (FindFirstFile не умеет работать рекурсивно). Так что очень сомневаюсь, что оно могло быть "в 1000 раза быстрее" — похоже на чьи-то фантазии... )

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

_>Ну вот я использую C++17, сигналы/слоты и не использую рефлексию. Можно мне получить версию Qt, которая будет нормально работать (включая все инструменты) без препроцессора? Ещё древняя MFC на древнем C++ это умела...

В древней MFC был зоопарк макросов (не говоря уже о всех костылях и сложностях в разработке кастомных контролов, которые приходилось использовать).

Ешё раз: если вам не нужна рефлексия, то зачем вам Qt?
И почему вам не нравится использование кодогенератора (который делает простой и легальный код) — я так и не услышал.

Qt — популярный инструмент, который предоставляет определённый backward compatibility. Когда будет Qt6, С++20 будет поддерживаться основными компиляторами, тогда можно будет и без препроцессора.
И да, есть Verdigris который более-менее позволяет Qt без препроцессора.

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

MTD>>А давай, чтобы понятно было какой у тебя опыт в разработке кроссплатформенного гуя на Qt ты покажешь свой проект?

R>т.е. чтобы встать вровень с Вами я должен сначала потрах..ся с Qt?

спасибо, как-нибудь без меня.

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

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

еще раз для особо понятливых — опыт кроссплатформенной разработки на Qt у меня есть, не такой большой как у Вас, но достаточен чтобы я мог сравнить с разработкой гуй на sciter. На основе чего я и делаю вывод. Опыта в sciter у Вас нет, но Вас это не смущает, наоборот Вам он не нужен т.к. вам достаточно сравнить выброс гугл. Двойные стандарты во всей красе. Я помоему вспомнил Вас, Вы выкидывали свой код сюда и жаловались, что Вас куда-то там не взяли на с++ курсы. Я и тогда заметил, что Вас немного передергивает из стороны в сторону. Надо будет Вас запомнить, чтобы не тратить своего времени больше.

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

R>>>я выразил свое мнение: что на sciter мне лично было легче создать гуй

Нет, твой тезис звучал иначе, в твое вранья я тебя уже ткнул.

R>куда мне до тебя, что-то там спиз..л, потом начал выкручитваться, не работал со sciter — не советуй ничего, просто напиши только про qtи все. я бы даже отвечать не стал.

Знатно у врунишки пригорает, какой поток сознания пошел, стул не прожги.

R>"Sciter, вроде, когда я смотрел его мне он категорически не понравился, судя по тому, что я не слышу чтобы его где-то широко использовали, то видимо мои ощущения были правильными."

R>это то что вы написали

И что не так? Sciter где-то широко используется?

R>я привел пример антивирусников: из наиболее популярных только kasper на qt, все остальные на sciter.

Антивирусники — капля в море. Sciter — совершенно не популярен.

MTD>Цитату с жалобами ты не привел, стало быть ты трепло.

R>я думаю ты можешь нажать на ссылку которую привел и прочесть, ведь это не сложно?

Зачем? От этого ты треплом быть не перестанешь.

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

SaZ>Если не секрет, почему повсеместно в коде аськи используется старый стиль использования QObject::connect?

Не повсеместно. Я не использовал старый стиль, за остальных отвечать, увы, не могу.

SaZ>И ещё, почему виджеты, а не QML? // В целом понимаю, что они плохо заточены под десктоп, но ведь гуёв там не особо много.

Исторически так, но если бы я начинал проект, я бы тоже не стал использовать QML — слишком много магии.

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

CS>А вот мой: http://notes.sciter.com/

У тебя хорошее приложение, но оно не работает:

Windows protected your PC
Windows Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.

App: 
notes.exe 
Publisher:  
Terra Informatica Software, Inc.

Сейчас в виртуалке попробую, так стремно.

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

CS>>То приложение что выше я написал за три месяца, а за сколько ты написал свое?

MTD>Ты хоть сам понимаешь какую чушь несешь? Напиши сначала аналог аськи, тогда и сравним время. На вскидку твое приложение я напишу за 2 недели, только как проверить, мне всякие поделки писать когда за них не платят лень.

Зачем аналог ?

ICQ от Mail.Ru использует Sciter. Или использовала — не знаю как сейчас.

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

Pzz>>Ну как-то, веб-бровсер с собой таскать (или зависеть от предустановленного, неизвестно какого и неизвестно, какой версии), это по-моему, круто очень.

R>зачем таскать?

А кто HTML-то будет отрисовывать?

Pzz>>И потом, HTMP+JS — не самый удобный инструмент, чтобы гуйню писать.

R>так вы логику гуя на плюсах и пишете, HTML только чтобы нарисовать картинку

По мне, так на HTML очень неудобно делать красивые формочки. Правда, оговорюсь, я не особый HTMLный спец.

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

CS>Спасибо за баг репорт.

Короче, падает твоя поделка постоянно:

notes: /home/andrew/Desktop/sciter.stable/engine/html/html-actions-stack.cpp:2238: bool html::behavior::do_apply_list(html::view&, html::behavior::editing_ctx*, html::behavior::action*, html::bookmark, html::bookmark, html::tag::symbol_t, const html::attribute_bag&): Assertion `list_items.size()' failed.
Aborted

Увы

Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий. / Козьма Прутков

CS>>Удобство это вещь сугубо субъективная. Что для тебя лично есть "удобно"?

Pzz>Когда не надо каждую загогулинку описывать кучей слов, размазанной по куче файлов.

А когда нужно поменять скажем базовый шрифт для всего UI ты как это делаешь?
Я — меняю одну строку. А ты?

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

CS>Дык я же вроде нигде тебя не призывал — бросить Qt и переходить на Sciter.

Вроде только этим и занимаешься, причем поливая дерьмом Qt, что выглядит не очень.

CS>Просто зря меня не послушали год назад — реально быстрее бы получилось. Sciter конечно не идеален, но для данной задачи всяко лучше Qt представляется.

Правильно сделали, от тех кто помнит твое поделие ничего хорошего не слышал. Извини, тебе наверное горько это слышать, но это так.

CS>Вот пример "RnQ Маленькая аська

" от Mikanoshi Kimemoshito, русского японца как я понял.

Собственно вот твоя аудитория, кроме антивирусов, конечно — фрики делающие непонятно что непонятно для кого в стиле 2004 год на дворе.

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

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

R>>почти все топовые антивирусы (кроме касперыча) используют sciter!
S>Обчычно у антивирусов ужасный интерфейс, ИМХО.

тут скорее все претензии к дизайнерам, а не к sciter, т.к. там тупо html+css — т.е. на что фантазия или мода их дизайнеров сподвигла, то они и нарисовали.

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

в последнее время в вэбе все ринулись к стилю — "меньше полезной инфы, зато большие кнопки и картинки", это не обошло и дизайнеров антивирусов, так что sciter тут не причем.

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

M>>Я жалуюсь. Кутешный софт очень часто тормозное гавно

MTD>Любопытно, что именно тебе таким показалось? Телеграм?

Сейчас не скажу, давно ничего кутешного не ставил.

ЗЫ Телеграм? Что это?

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

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

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

Z>>>Ну да, до Qt 5 нельзя было использовать компилятор для проверки соответствия signal/slot,
Z>>>даже я писал "проверяльщик": https://reviews.llvm.org/D14592 для этого.

CS>>Да пофиг на самом деле. Сначала создаем систему в которой можно соорудить циклические event dispatching графы, а потом код борьбы с этим.
CS>>Все при деле.

Z>Вообще-то я боролся не циклическими графами событий, а просто с проверкой сигнатур сигналов
Z>и слотов. Но вообще с каких пор в html/javascript нельзя создать зацикленный цепочки событий,
Z>в javascript/html можно посылать и принимать "custom event",
Z>в ващем framework нельзя создавать и подписывать на "пользовательские события"?

Там больше проблемы не циклическим dispatching по существу (который тоже есть как проблема), а с ownership ибо QObject это refcounted штука.
Т.е. замкнутая цепочка slot subscribers может быть неудаляемой обычным способом.

Но это собственно не Qt проблема, а общая для refcounted систем.

GC рулит в этом случае. Собственно поэтому я script и приделал к htmlayout в свое время (чтобы получить sciter).
code-behind-UI страдает беспорядочными ownership связями которые просчитать заранее очень сложно — возникают и пропадают в runtime и всё такое.

CS>>Вот зашибись. У тебя что юзеру запрещено файлы создавать в своём Documents фолдере? Закрыт он для записи?

Z>Пользователю конечно разрешена запись в $HOME, чему подтверждение файл $HOME/.config/sciter.notes.json,
Z>т.к. других программ на scriter я не запускал. Но директории $HOME/Documents действительно не существует,
Z>и никогда не существовало, а зачем она мне нужна? Это ведь не windows, никаких "My Documents" разработчики
Z>Linux не предусмотрели, только $HOME

Linux там не при чем. Это Gnome, Sciter использует результат стандартного вызова его функции:

g_get_user_special_dir (G_USER_DIRECTORY_DOCUMENTS);

Почему оно возвращает имя несуществующего folder мне знать не дано. Скорее всего у тебя какой-нить custom setup обрезанный по самое нихочу.

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

CS>Мне как-то главный UX гай из софтверной конторы из топ 100 рассказывал что по их исследованиям пользователь принимает решение про использование продукта за первые 40 секунд начиная от click на download.
CS>И первый экран что появится — критически важен.
Сегодня все эту задачу решают по другому: сначала скачивается минимальный установщик, который уже докачивает все необходимое по ходу дела.

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

NB>ну то есть объект нужен только для того чтобы проинициализировать в конструкторе, и удалить в деструкторе, и в промежутке между этим никак не используется и не изменяется?

Код почитай перед тем как задавать вопросы. Qt не использует счетчики ссылок, они используют связь parent-children, когда удаляется родитель он отписывается от всех сигналов и удаляет по списку своих детей. Самому таким образом ничего удалять не надо, создавать надо в куче.

XOO>есть еще Джус: https://www.juce.com
Джус заточен на музыкальную предметную область, отсюда и дизайн компонентов. Не для всех приложений это уместно.

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

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

CS>>Там больше проблемы не циклическим dispatching по существу (который тоже есть как проблема), а с ownership ибо QObject это refcounted штука.
CS>>Т.е. замкнутая цепочка slot subscribers может быть неудаляемой обычным способом.

CS>>Но это собственно не Qt проблема, а общая для refcounted систем.

SaZ>А подробнее можно? Что такое замкнутая цепочка подписчиков? Типа объект А подписан на Б, Б подписан на А? С удалением таких вещей в Qt проблем нет.

Помнится на заре моего использования Qt этот самый QObject использовал обычный refcount.
Сейчас ситуация явно изменилась как я увидел из этой ветки, спасибо всем отписавшимся — узнал что-то новое — и это здорово.

На самом деле вся инфраструктура QObject как оказалось еще более навороченна (тяжела?) чем представлялось.

У каждого QObject есть еще QObjectData. Т.е. дополнительная косвенность обращений.
А каждый QPointer содержит в себе QWeakPointer который уже есть refcounter штука

В то же самое время HTML DOM это direct parent-child tree:

class node : refcounted_resource {
  element* parent;
  uint     index; // in parent children collection
}

class element: node {
  vector<handle<node>> children;
}

Т.е. построено на прямых pointers — более легковесное.

Здравствуйте, 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 — все делают примерно одно и то же только по разному.

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

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

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

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

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

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

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

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

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

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

он поможет тебе за 5 мин понять, что конкретно происходит.
вместо мозго-ва, которым ты второй день занимаешься.

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

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

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

qobject_p.h
// указатель на счетчик
QAtomicPointer<QtSharedPointer::ExternalRefCountData> QObjectPrivate::sharedRefcount;

qsharedpointer_impl.h
// инициализация/инкремент sharedRefcount счетчика в объекте ptr
template <class X> inline QWeakPointer::QWeakPointer(X *ptr, bool) : d(ptr ? Data::getAndRef(ptr) : Q_NULLPTR), value(ptr) { }

// изменение счетчика
inline void QWeakPointer::internalSet(Data *o, T *actual) 

// версия 4 -- инициализация sharedRefcount счетчика в объекте ptr. в 5-й присваивание убрали
template <typename Deleter> inline QSharedPointer::QSharedPointer(T *ptr, Deleter deleter) : value(ptr) { internalConstruct(ptr, deleter); }

// изменение счетчика
inline void QSharedPointer::internalSet(Data *o, T *actual)

// изменение счетчика + удаление при необходимости
static void QSharedPointer::deref(Data *d) Q_DECL_NOTHROW

// инициализация/инкремент sharedRefcount счетчика в объекте p
inline QPointer::QPointer(T *p) : wp(p, true) { }

с тем что в QT везде передают голые указатели (QPointer тоже применяется, но редко) я не спорил, если ты не заметил
тебя ткнули носом в твое заблуждение насчет отсутствия счетчика ссылок в QObject
так доступно?
если нет, то я уже и не знаю что поможет

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

я ответил, просто кто-то не смог понять

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

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

M>Qt — оно конечно модно и прогрессивно

Ты не в теме, модно и прогрессивно — Sciter.

M>У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения.

Мир не стоит на месте. Фреймворк живет — это же не полумертвый wxWidgets на котором весь софт выглядит сделанным 15 лет назад и не Sciter который пилит один хоть и талантливый человек, а потому шаг влево, шаг вправо — Segmentation fault.

M>А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю.

Ой, да хорош сказки рассказывать (я конечно могу допустить, что такие проблемы быть могут, но ты же тогда сможешь о ним рассказать?). Я конечно третий не застал, начал с четвертого в 2008 году, потом когда переходил на пятый весь гемор был переписать сборочные скрипты, код скомпилировался и заработал.

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

NB>>он поможет тебе за 5 мин понять, что конкретно происходит.

MTD>В QObject нет счетчика ссылок управляющего его временем жизни, если бы он был ты бы не кривлялся а назвал файл и строчку.

NB>>вместо мозго-ва, которым ты второй день занимаешься.

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

это точно. ну да чего еще от фанакика ожидать

MTD>Я понимаю, тебе наверное больно, но ты попробуй понять написанное:

MTD>

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

я тебе показал. если нужен конкретный файл и номер строки, то пожалуйста, мне не жалко
qatomic_cxx11.h:141

return ++_q_value != 0;

qatomic_cxx11.h:147

return --_q_value != 0;

полегчало?

NB>>// указатель на счетчик
NB>>QAtomicPointer<QtSharedPointer::ExternalRefCountData> QObjectPrivate::sharedRefcount;

MTD>Конкретно это мы с тобой разбирали уже — это никакой не счетчик ссылок управляющий жизнью QObject.

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

NB>>с тем что в QT везде передают голые указатели (QPointer тоже применяется, но редко) я не спорил, если ты не заметил

MTD>Тогда как может работать счетчик ссылок? Если используются голые указатели невозвожно отследить время жизни и корректно удалить, когда на объект не осталось ссылок.

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

NB>>я ответил, просто кто-то не смог понять

MTD>Своим бла-бла смотри отладчик? Не катит.

да кто бы сомневался.

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

MTD>Зачем придумывать, в который раз тот-же самый вопрос:

ладно, я понял. случай безнадежный

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

MTD>Ох, уже который раз переход на мою личность, вот только не делает это тебя правым. Кстати, почему ты упорно называешь меня фанатиком? Я просто указываю на то, что ты не прав как в Qt контролируется время жизни QObject.

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

NB>>я тебе показал. если нужен конкретный файл и номер строки, то пожалуйста, мне не жалко

MTD>Ты снова показываешь не то. Вопрос звучал конкретно:

MTD>

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

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

NB>>хорошо, это не счетчик ссылок. тогда что, по твоему?

MTD>Там даже комментарий написали:

просто вопрос. что это такое?
на него ожидается простой ответ. это ...

MTD>>>Тогда как может работать счетчик ссылок? Если используются голые указатели невозвожно отследить время жизни и корректно удалить, когда на объект не осталось ссылок.

NB>>очевидно, по крайней мере мне, что он работает когда используются не голые указатели QSheredPointer, QWeekPointer, QPointer.

MTD>Так можно, например, std::vector положить в std::shared_ptr и утверждать, что std::vector использует счетчик ссылок.

вот есть у тебя сырой указатель на std::vector.
сможешь по нему получить std::weak_ptr?

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

CS>...

CS>У каждого QObject есть еще QObjectData. Т.е. дополнительная косвенность обращений.
Ну надо понимать, что это небольшие накладные расходы. И object data нужен больше для аккуратного кода. Да и вообще в Qt очень любят pimpl делать (изначально для бинарной совместимости).

CS>А каждый QPointer содержит в себе QWeakPointer который уже есть refcounter штука
Ну так надо понимать, что такое QPointer — это умный указатель, который автоматически зануляется, если уничтожить объект (который обязательно QObject) в другом месте. Я почему-то изначально думал, что это реализовано на сигналах/слотах, но через weak pointer действительно эффективнее.
По сути это и есть QWeakPoniter, для конструирования которого не нужно иметь экземпляр QSharedPointer.
Так что в этом случае использование подсчёта ссылок — общепринятый подход.

CS>В то же самое время HTML DOM это direct parent-child tree:

	Скрытый текст
	CS> `CS>class node : refcounted_resource { CS> element* parent; CS> uint index; // in parent children collection CS>} CS>class element: node { CS> vector<handle<node>> children; CS>} CS>`

CS>Т.е. построено на прямых pointers — более легковесное.

Повторюсь — использование QObject-а само по себе достаточно накладно при больших вычислениях. Например — делать каждый элемент графической сцены (типа entity в любом абстрактном игровом движке) нет смысла. Да и вообще нужно понимать, когда QObject нужен, а когда нет. QObject дорогой при создании, не копируемый по определению, но не имеет практически никакого оверхеда при использовании. Т.е. он является отличной базой для описания GUI объектов (их часто создавать не надо) — тут и обработка событий и сигналы/слоты (аля делегаты).

Поэтому лично я не вижу никакого плюса от заявленной вами легковесности для GUI.

-----
Вообще, если закрыть глаза на личностные выпады, то достаточно интересно читать этот топик. Получается классический холивар на тему Qt vs остальные. Кратко опишу своё мнение и свой опыт:
Я делал на Qt сервера (fastcgi, базы), делал достаточно сложный GUI (ланчеры для всяких игр с сильной кастомизацией, чаты, 3д редактор игровых уровней). wxWidgets — видел исключительно на уровне hello world. О sciter узнал только недавно, не щупал.

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

Qt vs HTML.

Сам я QML для гуёв пока не ковырял. Не могу пока найти нормальных тотуриалов по разработке многооконного/компонентного десктопного GUI на QtQuick.

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

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

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

Да, вы очень правильно говорите, что надо понимать, что и когда использовать.

Одна из фич QObject-а это возможность задать принадлежность к определённому потоку (при наличии у него event-loop). В этом потоке и будут вызываться слоты. Не более. QObject изначально не проектировался для того, чтобы быть потокобезопасным. А QPointer может применяться только к наследникам QObject. И удалять такой объект можно через deleteLater (очень удачный подход для сигнал/слотовой системы).
Делать на С++ потокобезопасный класс — это целиком ответственность программиста, а не фреймворка. К реализации QPointer это никакого отношения не имеет.
Если вы явно не контролируете время жизни объекта, то стоит использовать QSharedPointer/std::shared_ptr. Тогда не будет описанной вами проблемы. Во всех остальных случаях можно или std::unique_ptr/QScopedPointer, или использовать управление памятью через иерархию QObject-ов.

Где-то была заметка по поводу того, почему в Qt только один поток работает с GUI (в случае QtWidgets, а не QtQuick). Если кратко, то потому что профит от реализации многопоточности незначительный, а вот качество и раздутость кода очень сильно страдает. Вообще, мне очень нравится такой подход, если хочешь что-то сложное отобразить, то собираешь данные в отдельных потоках, строишь модель и потом, когда всё готово — кидаешь сигнал. При этом сохраняется полная отзывчивость интерфейса.

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

_>>Однако можно было без проблем кинуть кнопку на форму, нажать по ней правую кнопку мыши, выбрать пункт меню типа (сейчас уже естественно не помню) "Перейти к обработчику" и ты оказывался в коде обработчика (причём если его раньше не существовало, то он генерировался средой на ходу). И всё это работало без всяких внешних препроцессоров 20 лет назад.
SaZ>Работало, но не кросс-платформенно. Для кросс-платформенной библиотеки надо делать очень толстый слой абстракции, который не всегда можно тривиально реализовать. У Qt же сейчас очень качественная архитектура, которая позволяет достаточно легко добавить поддержку новых платформ (и этой возможностью пользуются, как-то собеседовался на фирму, которая как раз свой порт Qt под какое-то железо делала).

Ну во-первых данная "очень качественная архитектура" (даже смешно читать подобные эпитеты в отношение Qt в 2017-ом году) является просто стандартной реализацией одного из самых старых и известных паттернов проектирования. Который существовал задолго до рождения Qt и который применяется в большинстве кроссплатформенных библиотек.

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

SaZ>Похоже, тут всё-таки вопрос вкуса. Гуглу для работы протобафа нужен кодогенератор, gsoap — аналогично, WinForms — тоже кодогенерация, пусть и средствами компилятора (хоть и .net). Уверен, что можно ещё много примеров найти.
SaZ>Лично я тут проблемы не вижу. Для меня кодогенерация — намного более правильное решение, чем извращение со средствами языка.

Повторяю уже не первый раз: никаких извращений для поддержки реализации сигналов в C++ не требуется. Это должно бы очевидно каждому, даже после знакомства с языком на уровне статьи из Википедии. Просто потому что в C++ (да и даже в C) указатель на функцию является первоклассной сущностью. Более того, полно готовых (и совсем не новых) библиотек на эту тему (например http://www.boost.org/doc/libs/1_65_1/doc/html/signals2.html), оборачивающих эту базовую возможность языка в удобные ООП конструкции.

_>>Соответственно в Qt по сути всё тоже самое, только вот зачем-то понадобился внешний препроцессор.
SaZ>Затем, что так проще.

Кому проще то? Уж явно не пользователям их библиотеки...

_>>Мне не нужна Qt. Мне нужна GUI библиотека, позволяющая делать качественные, нативно выглядящие интерфейсы для Android/Windows/iOS/OSX/Linux (естественно с одной кодовой базой). Если кто-то подскажет мне другой инструмент с такой функциональностью, то я с радостью выброшу этого жирного монстра (Qt) подальше — всё равно весь не GUI код у меня использует только нормальные библиотеки (стандартная библиотека языка, Boost и т.п.). Однако к большому сожалению ни одного сравнимого инструмента не видно, так что приходится пользоваться этим.
SaZ>Да, и сделать такой инструмент с нуля ну очень тяжело. Майкрософт вон пытаются ксамарин впихнуть. Но опять же — это .net.
SaZ>Не понимаю только, почему вы Qt называете жирным? QtLite + статическая линковка + UPX и размер приложения уже получается очень маленький. Опять же — это только если есть смысл заморачиваться по размеру. Мне только в одном проекте пришлось.

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

SaZ>Ещё одно достоинство Qt, которое косвенно влияет на размер дистрибутива — с Qt не нужно тащить зоопарк 3rdparty и писать между ними адаптеры. Базы, сеть, потоки, веб, 2д3д графика, парсеры — всё использует общие типы данных и можно писать код в одном стиле.

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

SaZ>>>И почему вам не нравится использование кодогенератора (который делает простой и легальный код) — я так и не услышал.
_>>Вполне однозначный ответ уже был озвучен здесь http://rsdn.org/forum/cpp.applied/6907324.1.
SaZ>Не нашёл там вообще никакого ответа. Вы выхватили одну малую часть того, зачем в Qt есть кодогенерация и просто сказали, что можно и без неё.

Я вроде как ясно сказал, что мне от Qt только и нужна эта "малая часть" (GUI).

SaZ>В принципе можно, но нужны будут другие подходы, которые с С++14 усложнят программирование относительно того, что можно делать с кодогенерацией.

Не аргументированные сказки.

_>>Это если нужна рефлексия (которая для GUI вообще ни к чему). А если без неё, то можно было без препроцессора уже 20 лет назад.
SaZ>Расскажите про GUI, который вы делаете?
SaZ>Первый пример, который мне пришёл в голову — панель для редактирования свойств объектов. Без рефлексии там пришлось бы писать тонны кода на каждый новый класс. А с рефлекйсией — один раз написали и забыли.

unordered_map<string, unique_ptr<property_base>> dynamic_properties;

Ага, тонны кода. Ну да, ну да.

SaZ>>>И да, есть Verdigris который более-менее позволяет Qt без препроцессора.
_>>Любопытно. Интересно, IDE нормально это понимает (чтобы не сломался описанный выше механизм работы) или нет? )
SaZ>ReSharper — точно нормально, так же как и сгенерированный Qt код. Но всё это баловство, которое усложняет разработку. Вот если они доведут до ума свой проект по переделке moc на основе clang (пока там очень сырая альфа) — то будет круто.

Речь не про парсинг исходников (который кстати в современном QtCreator с включённой ClangModel стал лучше любых Решарперов), а про работу с дизйанером GUI, который работает с обработчиками для контролов как со слотами.

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

MTD>Это не то развитие которого ждет индустрия. С точки зрения ученого да, все классно, средствами языка можно все выразить, невероятная мощь, ребята умные, спору нет, вот только когда нужно просто дом построить им становится неинтересно, слишком приземленно. Нужен инженер, а у инженера интеллектуальные способности несколько иные и потребности отличаются. Инженеру же нужен простой, удобный и быстрый инструмент. Я пробовал использовать Boost.Spirit и в процессе мне постоянно приходилось думать как делать, а не о том, что мне нужно сделать, в то время как yacc прост как палка и понятен.

В случае Spirit'а дело совсем не в том, чтобы выразить всё средствами языка из принципа. Просто такой подход реально обеспечивает гораздо более удобную интеграцию и высокое быстродействие.

MTD>С++ стал популярен, потому что на тот момент времен затачивался под инженеров, а буст в массе пилят ученые, поэтому многие библиотеки из него использует дай бог сотня людей во всем мире.

У меня противоположное мнение. На мой взгляд Boost — это сейчас стандарт де-факто в мире C++. А программисты, использующие вместо него какие-то свои велосипеды, только лишь демонстрируют свою низкую квалификацию.

MTD>Здесь показателен другой язык заточенный под решение практических задач, а потому неплохо выстрелившим, я о Go — недавно Мейл.ру проводил хайлоад кап, так первые строчки все были заняты Go уже через несколько дней, в то время как решения на плюсах появились только где-то к концу второй недели, при этом по быстродействию не сказать, что Go был порван. Вот тебе и соотношение скорость разработки на скорость выполнения.

Ну вот когда рядом с nginx/iis/apache появится с процентами выше стат.погрешнсти какое-то решение на Go, то тогда и поговорим. ))) А так то скажем на PHP можно накидать страничку ещё быстрее, чем на Go, но это ни о чём не говорит.

_>>Ну предложи своё решение данной задачки) Чтобы с такой же краткостью и быстродействием.
MTD>Установить локаль, читать из потока.

Это ты про потоки из стандартной библиотеки языка? Они же дико тормозные — это уже даже на мегабайтах будет ощущаться. Да и даже если забыть о быстродействие, то всё равно подобный код будет намного более громоздким, чем одна короткая строчка на Spirit'е.

MTD>>>Про время компиляции, диагностику ошибок и удобство в поддержке возражений нет? Ок.
_>>Про удобство поддержки очевидно как раз всё наоборот — одна краткая строчка против целого нетривиального файла.
MTD>Что там нетривиального-то? Все просто как палка. А еще для отладки грамматик есть инструменты.

Нетривиально по сравнению с аналогичным решением на Spirit'е.

_>>Время компиляции у меня например не минуты, а секунды (потому что любой профессионал в C++ работает только с помощью эффективных SSD).
MTD>Да SSD сейчас у всех, нашел чем удивить, вот только не панацея это. Реакция людей пересевших, например с С# на плюсы — компиляция подвисла, что делать.

Кстати, это следствие совсем не шаблонов и метапрограммирования, а специфической "модульности" в C/C++. Теоретически это может быть решено после введения нормальных модулей в C++ (опять же ожидалось в C++17). Хотя лично мне решение от Microsoft не очень нравится — там надо дорабатывать.

_>>Просто чтобы было понятно, что преимущество одновременно по всем параметрам (и лаконичность кода и удобство интеграции и итоговое быстродействие).
MTD>Я пока у Spirit не вижу вообще никаких преимуществ кроме идеологических.

Ну похоже что ты просто его никогда не использовал по делу и всё. )))

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

_>У меня противоположное мнение. На мой взгляд Boost — это сейчас стандарт де-факто в мире C++. А программисты, использующие вместо него какие-то свои велосипеды, только лишь демонстрируют свою низкую квалификацию.

От буста, после того, как в стандарт перехала его часть можно и нужно отказываться. Есть конечно вполне ок либы, тот же Asio, но есть куча странных трехколесных велосипедов, типа Format, который использует непонятный синтаксис и при этом дико тормозной http://zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html

_>Ну вот когда рядом с nginx/iis/apache появится с процентами выше стат.погрешнсти какое-то решение на Go, то тогда и поговорим. ))) А так то скажем на PHP можно накидать страничку ещё быстрее, чем на Go, но это ни о чём не говорит.

Ты малость не в теме, конечно http сервер писать на go смысла нет (кстати, он пишется в 10 строк) так как уже есть отличные решения, тот же nginx, но сервера на нем пилят только так. В том же Мейл.ру часть старых проектов переписывают на нем, новые вообще по-моему все на нем начинаются. Вот, кстати, результат упомянутого чемпионата: https://highloadcup.ru/rating/ PHP в топе нет, а Go есть и нормально выглядит рядом с С++ и С.

_>Это ты про потоки из стандартной библиотеки языка? Они же дико тормозные

Ну вот как так? Такой язык мощный, продуманная библиотека и тормоза

_>Кстати, это следствие совсем не шаблонов и метапрограммирования, а специфической "модульности" в C/C++. Теоретически это может быть решено после введения нормальных модулей в C++ (опять же ожидалось в C++17). Хотя лично мне решение от Microsoft не очень нравится — там надо дорабатывать.

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

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

_>Ещё раз повторяю, кодогенерация в Qt не используется для поддержки старых компиляторов. Она используется для:

_>1. поддержки сигналов, что априори бредово, т.к. все необходимые для этого возможности компиляторы C++ имеют уже много десятилетий.
_>2. поддержки метаинформации, что наоборот не возможно пока ни в одном компиляторе C++, даже самого последнего стандарта (и это тоже плохо на мой вкус, т.к. является "выходом за пределы языка").

1. Это ничего не меняет. Можно и через кодогенерацию делать. В данном случае нет необходимости менять то, что работает. В Qt6 уже можно будет от этого уйти.
2. Это не выход за пределы языка ни разу. Просто кодогенератор делает за программиста работу — формирует описание структуры класса на С++. На выходе получается чистый С++.

_>Ну да, только у тебя тут для Boost'а полноценная компилируемая строчка со всеми идентификаторами, а для Qt некий упрощённый шаблон применения. Ты напиши полноценный аналог с теми же именами переменных/сигналов/слотов и тогда сравни. )

В Qt один метод — QObject::connect. Там в любом случае 5 или меньше аргументов. Причём никакие аргументы не нужно заворачивать ни в какие врапперы.

_>Она плоха тем, что заточена на использование своих убогих велосипедов, вместо общепринятых в языке подходов. Т.е. я не могу просто взять их GUI классы (нужные мне) и использовать в нормальном современном C++ окружение.

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

_>Современный C++ развивается сейчас в сторону функционального стиля, использования локальных переменных с типами-значениями (отсюда и семантика перемещения), активного использования обобщённого и мета программирования. А засилье ООП, сплошные new/delete и т.п. осталось в C++ далёких 90-ых. Ну и вот в Qt. Кстати, это видно даже по стандарту имён переменных — Qt соответствует классической Java нотации, а не C++. Да и вообще они этого не скрывают (см. например http://doc.qt.io/qt-5.9/containers.html#java-style-iterators).

Современный С++ как раз таки мультипарадигмный. И это его достоинство подчёркивается его разработчиками. К тому же Qt сами сказали, что с новым стандартом лучше использовать STL вместо собственных Qt-шных классов, где это возможно. И они по максимуму стали вводить поддержку STL. А раньше, вместо мув семантики у них была очень хорошая реализация COW для всех внутренних типов. new/delete уже никто не использует, всюду есть RAII. Стандарт имён переменных — дело каждого конкретного проекта. Лично мне нравится, что в Qt код выдержан в одном стиле. Причём мне не важно в каком. Под стиль подстраиваешься за пару месяцев работы над проектом.

_>Да ладно, из старого же есть очень удобная библиотечка SOCI, умеющая наверное все СУБД. А из нового можно глянуть на sqlpp11, которая имеет полноценную статическую (во время компиляции проекта) проверку синтаксиса SQL, т.е. по сути круче чем Linq (там часть работы в рантайме идёт). Правда последняя пока ещё в какой-то степени экспериментальная и поэтому имеет поддержку только нескольких СУБД.

Вот именно, экспериментальная. А в Qt это работает давно и хорошо, даже на С++03 компиляторах на слабом железе. Ещё раз — не нужно сравнивать Qt со свежими библиотеками, которые писались сразу под C++11. Придёт время и необходимость — они всё отрефакторят.

_>Вот смотрю я например на эту https://github.com/wjakob/nanogui библиотеку и думаю, что если бы ей добавить:
_>1. нормальную поддержку unicode.
_>2. дополнить коллекцию стандартных контролов до классического количества (ну как минимум tree и list то должны быть)
_>3. реализовать внутренние темы и сделать считывания всех соответствующих настроек оформления системы при старте приложения (данный тупой платформозависимый код можно напрямую взять из Qt) с формированием из них текущей темы для всех контролов.
_>4. (опционально) сделать визуальный редактор контролов.
_>То можно было бы спокойно выкидывать Qt на свалку.

Qt ещё долго на свалку не пойдёт. Вот когда их библиотека сможет без тормозов показывать списки на пару миллионов записей и когда там в пару строк кода можно будет писать кастомные контролы — тогда да, можно будет использовать.

SaZ>>Ну так я и говорю — дайте пример нормальных сигналов/слотов с многопоточностью под C++03.
_>Так а чем Boost::signal2 не подходит? )

При беглом гуглении не нашёл простой возможности сказать, в каком потоке выполнять слот. И не нашёл примеров цикла обработки сообщений.

_>Эм, зачем? Почему нельзя использовать напрямую данные из этой коллекции в этих самых классах? Тем более, что это позволит делать им реально динамические свойства, а не псевдо, как в Qt.

Потому что коллекцию надо сначала заполнить. Вы так и не объяснили, кто будет заполнять коллекцию свойств. В Qt это делается через рефлексию с интроспекцией.
В Qt тоже есть динамические свойства, которые можно создавать в рантайме.

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

_>>У меня противоположное мнение. На мой взгляд Boost — это сейчас стандарт де-факто в мире C++. А программисты, использующие вместо него какие-то свои велосипеды, только лишь демонстрируют свою низкую квалификацию.
MTD>От буста, после того, как в стандарт перехала его часть можно и нужно отказываться. Есть конечно вполне ок либы, тот же Asio, но есть куча странных трехколесных велосипедов, типа Format, который использует непонятный синтаксис и при этом дико тормозной http://zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html

Ну по поводу элементом переехавших из Boost в стандартную библиотеку, я естественно тоже сразу стал использовать только их. Но при этом там до сих пор осталось очень много разных вкусностей. И законченных решений глобальных "доменных" вещей типа Spirit, Asio, MSM, обёртки OpenCL и MPI, полноценной работы с юникодом, логирования, юнит-тестов, сереализации, интеграции с Python. И классных технологий, дорабатывающих язык, типа Coroutine/Fibers, Type Erasure, метапрограммирования (Metaparse, Hana, MPL, Fusion, Proto, плюс отдельно библиотеки поддержки стандартного препроцессора PP и VMD), Range (будет реально актуально после включения концептов во всех компиляторах). И просто множество готовых удобных реализаций небольших известных программистских задач: дополнительные алгоритмы и crc, различные контейнеры в стиле STL (включая lock-free, интрузивные, графы, пулы, многомерные и ещё куча всего — я даже не пробовал их все), различная математика (статистика, геометрия, кватернионы, числа произвольной точности, рациональные числа, линейная алгебра, диф.уравнения, размерности), кроссплатформенная поддержка IPC/динамических библиотек/процессов, стандартный разбор командной строки, хранение иерархических конфигов. И всё это качественный код, написанный в стиле современного C++!

Да, и по поводу твоей ссылки (кстати откуда ты её взял интересно? Просто я буквально на днях кидал её прямо на этом форуме)... А тебя не смущает, что там среди лидеров по быстродействию значится тот самый Spirit, на который ты "наезжал"? )))

_>>Ну вот когда рядом с nginx/iis/apache появится с процентами выше стат.погрешнсти какое-то решение на Go, то тогда и поговорим. ))) А так то скажем на PHP можно накидать страничку ещё быстрее, чем на Go, но это ни о чём не говорит.
MTD>Ты малость не в теме, конечно http сервер писать на go смысла нет (кстати, он пишется в 10 строк) так как уже есть отличные решения, тот же nginx, но сервера на нем пилят только так. В том же Мейл.ру часть старых проектов переписывают на нем, новые вообще по-моему все на нем начинаются. Вот, кстати, результат упомянутого чемпионата: https://highloadcup.ru/rating/ PHP в топе нет, а Go есть и нормально выглядит рядом с С++ и С.

Вот открываем твою же ссылку и видим там сплошное засилье C/C++. Одинокая Java на 12-ом месте и одинокий Go на 15-ом. Как-то странно это соотносится с твоими же словами. )))

_>>Это ты про потоки из стандартной библиотеки языка? Они же дико тормозные
MTD>Ну вот как так? Такой язык мощный, продуманная библиотека и тормоза

Ну для целей взаимодействия с пользователем в консоли они подходят отлично. ) А для всего остального лучше использовать более эффективные способы. )

_>>Кстати, это следствие совсем не шаблонов и метапрограммирования, а специфической "модульности" в C/C++. Теоретически это может быть решено после введения нормальных модулей в C++ (опять же ожидалось в C++17). Хотя лично мне решение от Microsoft не очень нравится — там надо дорабатывать.
MTD>Вот, хороший пример когда всякая чухня идет в стандарт, а действительно важные вещи (корутины, файловая система, модули) задвигается на потом. Об этом я и говорю — оторванные от реальности ученые рулят, а то что надо инженерам — на то положить.

Так файловую систему же приняли. Модули не приняли и я с этим согласен. В том смысле что они конечно нужны, но пока действительно хорошей системы не видно. А вот насчёт корутин поддерживаю — жаль не приняли (причём я бы предпочёл в начале получить stackfull решение, а не проталкиваемое MS не очень нужное решение из C#). Но они в принципе и сейчас работают (просто в виде библиотек), так что не проблема. А вот концепты и интроспекцию через библиотеки не реализуешь, так именно эти две вещи мне жаль больше всего. Ну будем надеяться что к C++20 всё же смогут договориться.

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

_>Хорошая либа — это ты про какую?

Про http://fmtlib.net/latest/index.html

MTD>>Так отрыв незначительный, зато скорость разработки раза в 2 выше, так что все ок.

_>Так откуда у тебя данные то про скорость разработки в 2 раза выше? )

Я уже приводил пример — решения на Go появились где-то на 3 день, на С и С++ решения стали появляться к концу второй недели. Ну и сам немного писал, многие вещи делаются очень просто.

_>И как ты себе это вообще представляешь на статическом языке, не поддерживающем обобщённое программирование? )

Ты в своей простоте прекрасен. На плюсах только инфраструктуру поднять сколько времени займет? Взять либы нужных версий, собрать их с нужными флагами, при этом от души покурить маны. Тут если кто-то мне будет рассказывать, что можно бинарники скачать или в Линуксе из репозитория поставить я просто посмеюсь, так как понятно, что человек вообще не в теме. На Go же go get и через 5 минут уже все готово. Как говорится пока в Виларибо все еще компилируют, в Вилабаджо уже половину написали. Потом, про обобщенное программирование вообще ржака в контексте скорости разработки, приведи хоть один адекватный пример когда оно сокращает время разработки, не абстрактного сферического коня, а чего-то практического. Во всех языках даже убогих проблему решили где кодогенерацией, где стиранием типов и программист просто берет готовое и использует. Сила языка прежде всего в стандартной библиотеке, то что для языка понаписали 100500 велосипедов разной степени глючности и кривости никак не в плюс, а вот библиотека позволяющая сразу из коробки перевести в нижний регистр utf8 текст или директорию обойти — вот это реально в плюс и жирный.

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

_>И как ты себе это вообще представляешь на статическом языке, не поддерживающем обобщённое программирование? )

Еще небольшое лирическое отступление (все совпадения с реальными людьми случайны) — любители порассуждать про "С++ проектировался чтобы работать на любых устройствах от стиральной машинки до суперкомпьютера", "работа с юникод — это свистелки и никому не надо, а вот без frexp жить нельзя", "файловой системы может и не быть, поэтому в стандарте это не надо" очень быстро сливаются, когда их с абстрактных высот, где они в облачках летают, приземляешь на грешную землю, вот как тут, например: http://rsdn.org/forum/cpp/6899816.1

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

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

V>>Интересует под MS VS2013. Кто какие использует?

MTD>Qt. Да, есть недостатки, но лучше ничего нет.
хотелось заметить, что велосипеды вроде КУт скоро отомрут за ненадобностью. с появлением компайлтаймрефлекшина в плюсах.
адью,
лично кут, мне — долго подбирал слово — противен, он искажает задумку плюсов. когда компайлтайм подменяется рантаймовыми извратами. нелюблю.

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

_>>Так откуда у тебя данные то про скорость разработки в 2 раза выше? )
MTD>Я уже приводил пример — решения на Go появились где-то на 3 день, на С и С++ решения стали появляться к концу второй недели. Ну и сам немного писал, многие вещи делаются очень просто.

Это вообще не аргумент (про 3-ий день и т.п.). Мало ли кто когда узнал, кто насколько занят и т.п. Достаточно просто одной ссылке на каком-нибудь профильном форуме, чтобы полностью исказить такую "статистику". )

_>>И как ты себе это вообще представляешь на статическом языке, не поддерживающем обобщённое программирование? )
MTD>Ты в своей простоте прекрасен. На плюсах только инфраструктуру поднять сколько времени займет? Взять либы нужных версий, собрать их с нужными флагами, при этом от души покурить маны. Тут если кто-то мне будет рассказывать, что можно бинарники скачать или в Линуксе из репозитория поставить я просто посмеюсь, так как понятно, что человек вообще не в теме. На Go же go get и через 5 минут уже все готово. Как говорится пока в Виларибо все еще компилируют, в Вилабаджо уже половину написали.

Безусловно инфраструктура Go настраивается гораздо быстрее, чем у C++. Но это касается только тех, кому надо её настраивать с нулям. Скажем мне (да и любому, профессионально работающему с C++) это абсолютно не нужно, т.к. уже всё развёрнуто — для меня время будет одинаковое (ну точнее даже больше для Go, т.к. его надо ещё скачивать и ставить, но такую мелочь не считаем).

MTD>Потом, про обобщенное программирование вообще ржака в контексте скорости разработки, приведи хоть один адекватный пример когда оно сокращает время разработки, не абстрактного сферического коня, а чего-то практического. Во всех языках даже убогих проблему решили где кодогенерацией, где стиранием типов и программист просто берет готовое и использует.

И почему-то во всех этих убогих языках со временем понимают, что так жить нельзя (см. пример Java, да и в том же Go это постоянно обсуждают), но добавление дженериков в следующих версиях языка приводит к необходимость переписывания огромного числа библиотек, в которых уже наговнокодили множество всяких неэффективных ObjectArray или же тонны IntXXXArray под каждый тип.

MTD>Сила языка прежде всего в стандартной библиотеке, то что для языка понаписали 100500 велосипедов разной степени глючности и кривости никак не в плюс, а вот библиотека позволяющая сразу из коробки перевести в нижний регистр utf8 текст или директорию обойти — вот это реально в плюс и жирный.

Хы, ну так это ты как раз Boost описываешь. ))) Он у C++ выступает как раз в роли "большой стандартной библиотеки". )

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

MTD>Тут я так понимаю твой коллега с 235 секундами? Тут да, fasthttp мы встречаем аж на 4 строчки ниже — 246 секунд,

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

Highloadcup наглядно показывает, что для получения производительности, сравнимой с fasthttp в Go, на C++ вообще не нужно использовать низкоуровневое программирование. О чем вам и было сказано выше.

MTD>Я кстати кажется понял от чего у тебя такая боль

В дискуссии на техническую тему домыслы по поводу ваших оппонентов не могут служить аргументами.

жаль.
тяжко тебе наверно по жизни с таким отношением к окружающим

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

MTD>Балабольство пока только с твоей стороны. Вот неопровержимый факт:

MTD>

MTD>И вот там есть fasthttp на 34 месте с 192 секундами, а твой коллега на 35 со 194 секундами. Так что обошел Go твоего коллегу, смирись. Смотреть можно синею таблицу здесь https://highloadcup.ru/rating/

MTD>Все желающие смогут пройти по ссылке и убедится. Ты же можешь и дальше отрицать объективную реальность, реальности твои верования пофиг.

Ну давайте, для объективности, дадим всем желающим еще одну ссылку: https://highloadcup.ru/rating/round/2/
С пояснением, что это результат финала, в котором и данных, и запросов было в разы больше, чем в "песочнице", на результаты которой вы указываете.

А так же приведем изначальный тезис, высказанный в дискуссии с вами:

А написать вровень с fasthttp и на C++ не сложно, и ни на какой низкий уровень опускаться не нужно.

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

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

S>>Ну тогда объясните, как же получается так, что в песочнице есть результат с GO/fasthttp на 34-ом месте, а в финале его нет?

MTD>Человек не успел написать к финалу

Тезис о скорости разработки на Go оказывается несостоятельным.

MTD>Мантры-мантры.

Предлагаете поверить вам на слово?

MTD>Это ты сейчас подтасовкой и манипуляцией занимаешься сравнивая fasthttp с голым epoll на хаках. Или сравнивай топ С и топ Go или сравнивай fasthttp с Asio.

Повторю еще раз: написать на C++ так, чтобы было вровень с Go/fasthttp несложно, это не требует много времени и усилий. Результаты получаются сравнимыми. Однако, если затем нужно выжать максимальную производительность, то в C++ это достигается, а в Go обнаруживается заметный разрыв. Количество усилий, которые нужно приложить для выжимания максимальной производительности, предположу, опять же окажутся сравнимыми.

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

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

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

MTD>Да ты что? А как пел, как пел:

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

ну и где здесь про удаление QObjecto'м себя?
здесь про управление жизнью умными указателями.
То что тролли в 5-м qt удалили связи для шареда не отменяет ее текущего использование для виков.
Если у кого то какие-то нездоровые фантазии насчет delete this, так мне то что с того.
Сегодня тебе delete this нужен, завтра еще чего понадобится.
Напоминаю, твой тезис был

QObject не имеет счетчика ссылок.

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

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

S>>Если бы вы сразу же сказали, что ваши оценки базируются на ~~радиусе кривизны ваших рук~~ вашем личном опыте

MTD>Руки у меня конечно кривые, но судя по тому что я выше твоего коллеги в рейтинге, то немножко как на плюсах писать я понимаю.

Одно с другим не связано. Мой коллега участвовал в конкурсе для того, чтобы проверить результаты restinio в независимом от нас бенчмарке. Результаты показывают, что претендующий на универсальность фреймворк, находящийся в альфа-версии, показывает производительность на уровне Go/fasthttp, в которые было вложено в несколько раз (а то и порядков) больше времени и усилий.

Ваши познания в плюсах здесь вообще ни при чем.

MTD>А еще я на Go писал, потому есть с чем сравнить.

Доказательство на основе личного опыта. Это уже понятно.

S>>не пытаясь сослаться на конкурс highloadcup

MTD>Результаты конкурса со сказанным мной отлично коррелируют

Результаты финала таковы, что:
— решения на Go находятся на 11-ом, 12-ом, 24-ом, 28-ом, 39-ом, 44-48-ом и 50-ом местах. Т.е. в ТОП-10 никого, в ТОП-30 всего 4;
— нет никакой объективной информации о сравнении сроков разработки решений на C++ и на Go.

Возможно, у вас это называется "отлично коррелируют". Возможно. Опять же личный опыт.

MTD>Не переживай, скоро начнут еще где-то кроме Интервейла использовать твои акторы и Go скоро все забудут и побегут на restinio все переписывать. Все будет хорошо.

Все будет хорошо. И акторы будут использовать, и restinio, и про Go никто не забудет. А вы переходили на личность место аргументации, так и продолжите.

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

NB>повторяю для одаренных.
NB>точную цитату мою.
NB>не надо снова своих измышлизмов.

Э нет дружок, это не игра в одни ворота, решил хамить и врать, получишь то же самое (хамство), в отличии от тебя я не врал. Я уже пошел тебе на встречу, подумал, что тяжко человеку, надо уступить, а ты это совсем не правильно понял. Так что иди и читай сначала ветки чего ты там наплел и как ты там выкручивался.

NB>общеизвестные же вещи излагаю.
NB>куда уж конкретнее.

Снова жалкое детское надувание щек. Было бы что сказать — дал бы конкретику.

NB>не мои проблемы.

Твои. Ты же балаболом себя выставил.

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

NB>то есть цитаты не будет?

Как не будут? Уже приводил, иди читай. Хотя ты же как нашкодивший ребенок не можешь вести себя как взрослый и признавать ошибки.

NB>про вранье тоже подтвердить не в состоянии?

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

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

NB>то есть подтверждения заявы о вранье тоже не будет?

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

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

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

MTD>Так ты ничего и не показал.

NB>>итак на $$$ много времени потратил.

MTD>Бла-бла-бла. Зачем начинал? Чтобы снова слиться?

Господа, завязывайте с мордобоем! На Лиговке Деда Мороза бьют!
https://youtu.be/YQT-jJGpf8c?t=262

Мир, дружба, жевачка.

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

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

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

R>>почти все топовые антивирусы (кроме касперыча) используют sciter!

MTD>4 одинаковых софтины (картинка фоном, гвоздями прибитые контролы) — это именно то о чем говорил, то есть около нулевая распространенность.
MTD>Из того, что еще хорошо знаю, Telegram на Qt написан: https://telegram.org/

не ленитесь прокрутите вниз, там есть список тех, кто пользуется sciter — "около нулевая распространенность"

R>>по моему шикарная вещь! особенно если действительно нужен кроссплатформенный гуй, а не потрах..ся с qt

MTD>А давай, чтобы понятно было какой у тебя опыт в разработке кроссплатформенного гуя на Qt ты покажешь свой проект?

т.е. чтобы встать вровень с Вами я должен сначала потрах..ся с Qt?

спасибо, как-нибудь без меня.

MTD>Вот мой: https://icq.com/

поздравляю, супер! icq мне никогда не нравился своим доисторическим интерфейсом, но я действительно рад за Вас! и я нисколько не сомневаюсь, что проггер Вашего калибра сделает гуй хоть на костылях, осталось только сравнить насколько быстрее то же самое Вы бы сделали (ну или проггер с меньшим опытом) используя что-то более пригодное для этого, например на sciter.

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

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

MTD>>>А давай, чтобы понятно было какой у тебя опыт в разработке кроссплатформенного гуя на Qt ты покажешь свой проект?

R>>т.е. чтобы встать вровень с Вами я должен сначала потрах..ся с Qt?

спасибо, как-нибудь без меня.

MTD>Ты выдал тезис — чтобы написать кроссплатформенный гуй с Qt придется мучиться. Это в корне расходиться с моим опытом, поэтому я решил уточнить у коллеги его опыт. Как было выяснено твое утверждение голословно.

оно настолько же голословно, как и первоначальное Ваше про sciter и про его "околонулевую распространенность" — все основывается на личном мнении человека и его желании чесать правое ухо левой ногой, у вас оно есть у меня нет, на этом и закончим припираться

MTD>Зачем ты вводишь людей в заблуждение?

расслабьтесь, там есть кнопка + или -, пусть остальные нас с Вами рассудят, нет времени на глупые споры с фаном qt

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

R>оно настолько же голословно, как и первоначальное Ваше про sciter и про его "околонулевую распространенность"

Мое утверждение подкреплено фактами — достаточно в гугле ввести how to <do something> in sciter|qt и сравнить выдачу, даже по wxwidgets информации в десятки раз больше!

R>все основывается на личном мнении человека

Не надо называть пустые фантазии личным мнением.

R>и его желании чесать правое ухо левой ногой, у вас оно есть у меня нет, на этом и закончим припираться

И снова пустые фантазии. Я показал, что делаю я, а вот что делаешь ты и как мы вообще не знаем.

MTD>>Зачем ты вводишь людей в заблуждение?

R>расслабьтесь

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

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

R>>расслабьтесь

MTD>Я и не напрягался. Ответь, зачем ты создаешь шум и вводишь людей в заблуждение?

Я и не создавал шум. Вы не имея опыта со sciter соизволили написать: "когда я смотрел его мне он категорически не понравился, судя по тому, что я не слышу чтобы его где-то широко использовали, то видимо мои ощущения были правильными". На что я указал ссылкой где описаны те, кто уже давно использует scitter.

Далее я выразил свое мнение полученное на личном опыте о легкости разработки используя sciter относительно Qt. Возможно оно ошибочно, но для этого есть копки +- над сообщением я думаю для этого они и сделаны. Где я мог поднять шум? Разве я начал мериться пиписьками? Разве я не имея опыта со sciter начал его ругать и вводить людей в заблуждение?

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

R>Я и не создавал шум.

Зачем врать? Все же в теме есть:

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

Позже выяснилось, что на Qt ты ничего кроссплатформенного не делал.

R>Вы не имея опыта со sciter соизволили написать: "когда я смотрел его мне он категорически не понравился, судя по тому, что я не слышу чтобы его где-то широко использовали, то видимо мои ощущения были правильными".

Зачем иметь опыт, чтобы бегло погуглить и понять, что инфы о нем очень мало, что говорит о его распространенности. Достаточно в гугле ввести how to <do something> in sciter и убедится в этом.

R>На что я указал ссылкой где описаны те, кто уже давно использует scitter.

Это просто крохи, на Qt такой список был бы в тысячи раз длиннее. Особенно всякие поделия а-ля студенческий курсовик, на заглавной доставляют:

R>Далее я выразил свое мнение полученное на личном опыте о легкости разработки используя sciter относительно Qt.

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

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

R>еще раз для особо понятливых — опыт кроссплатформенной разработки на Qt у меня есть, не такой большой как у Вас, но достаточен чтобы я мог сравнить с разработкой гуй на sciter.

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

R>Опыта в sciter у Вас нет, но Вас это не смущает, наоборот Вам он не нужен т.к. вам достаточно сравнить выброс гугл.

Чтобы понять насколько популярна технология не обязательно ее изучать, количество информации в гугле адекватная оценка для этого. Это непонятно или есть возражения? Как популярность предлагаешь оценить ты?

R>Я помоему вспомнил Вас, Вы выкидывали свой код сюда и жаловались, что Вас куда-то там не взяли на с++ курсы.

Далеко не надо ходить, соседняя тема: http://rsdn.org/forum/cpp/6717561.1

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

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

MTD>Вот мой: https://icq.com/

Если не секрет, почему повсеместно в коде аськи используется старый стиль использования QObject::connect?
И ещё, почему виджеты, а не QML? // В целом понимаю, что они плохо заточены под десктоп, но ведь гуёв там не особо много.

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

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

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

R>>я выразил свое мнение: что на sciter мне лично было легче создать гуй, гораздо легче, соот. в сравнении с этим опытом я больше не хочу трахаца с qt для написания гуй. это мое личное мнение, я его никому не навязываю, не согласен ставь минус, согласен плюс.

MTD>Аргументов у тебя нет, то есть ты соврал? Ну ок.

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

MTD>>>Чтобы понять насколько популярна технология не обязательно ее изучать, количество информации в гугле адекватная оценка для этого. Это непонятно или есть возражения? Как популярность предлагаешь оценить ты?

R>>кол-во информации в гугле говорит всего лишь о доступности технологии

MTD>Как может быть популярной недоступная технология? А ты жжешь.

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

R>>почему я должен это разжевывать вам?!

MTD>Да, я понял, что с аргументацией у тебя туго — соврал и в кусты.

куда мне до тебя, что-то там спиз..л, потом начал выкручитваться, не работал со sciter — не советуй ничего, просто напиши только про qtи все. я бы даже отвечать не стал.

R>>далее малое кол-во выбросов в гугле не говорит о том хуже она или нет. вы же пытаетесь натянуть сову на глобус.

MTD>Ты все время пытаешься съехать с темы и навязать мне то, чего я не говорил. Я сказал, что популярность у него мала — это факт.

"Sciter, вроде, когда я смотрел его мне он категорически не понравился, судя по тому, что я не слышу чтобы его где-то широко использовали, то видимо мои ощущения были правильными."

это то что вы написали, я привел пример антивирусников: из наиболее популярных только kasper на qt, все остальные на sciter.

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

R>>там весь текст наполнен печалью и жалобой о несправедливости.

MTD>Цитату с жалобами ты не привел, стало быть ты трепло.

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

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

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

Всем спасибо за информацию, буду разбираться.

О результатах отпишу.

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

R> мнение такое
R> — дотнетные библиотеки радикально превосходят все что есть на плюсах
Сразу определимся о чём "дотнетном" разговор:
a) Чистый WinForms;
b) Чистый WPF;
c) DeveloperExpress .NET библиотеки по WinForms;
d) DeveloperExpress .NET библиотеки по WPF.

Так вот на счёт пунктов a) и даже (частично) b) я бы всё-таки поспорил.
Я о том, что "из коробки" Qt5 способен обеспечить результаты по части GUI совсем не хуже, чем студия с WinForms и WPF.
Пишу — не спотолка, а по опыту применения вышеуказанных .NET продуктов.
Но, конечно же, платный DeveloperExpress окажется не хуже того же Qt.
Другое дело, что я сравниваю свободный Qt (без доп-библиотек).

R> — создание API на C++ CLI для разработки гуя на шарпе — проще чем кажется в начале
Зачем, если есть C#?
При работе с управлаемом C++ (C++ CLI) мне не нравится искусственно введенное в C++ понятие шарповской ссылки:
эта идея ИМХО протеворечит тем приёмам косвенной адресации (pointers & references), что имеются в C++

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

R>почти все топовые антивирусы (кроме касперыча) используют sciter! это видно хотя-бы если зайти на их сайт https://sciter.com/.
R>по моему шикарная вещь! особенно если действительно нужен кроссплатформенный гуй, а не потрах..ся с qt

Ну как-то, веб-бровсер с собой таскать (или зависеть от предустановленного, неизвестно какого и неизвестно, какой версии), это по-моему, круто очень. И потом, HTMP+JS — не самый удобный инструмент, чтобы гуйню писать.

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

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

R>>почти все топовые антивирусы (кроме касперыча) используют sciter! это видно хотя-бы если зайти на их сайт https://sciter.com/.
R>>по моему шикарная вещь! особенно если действительно нужен кроссплатформенный гуй, а не потрах..ся с qt

Pzz>Ну как-то, веб-бровсер с собой таскать (или зависеть от предустановленного, неизвестно какого и неизвестно, какой версии), это по-моему, круто очень.

зачем таскать?

Pzz>И потом, HTMP+JS — не самый удобный инструмент, чтобы гуйню писать.

так вы логику гуя на плюсах и пишете, HTML только чтобы нарисовать картинку

UPD. Sciter UI, application architecture

UPD.

Sciter(ранее HTMLayout) — встраиваемый браузерный движок, разработанный Terra Informatica. Основная задача движка — построение веб-интерфейса в десктопных приложениях. Поддерживает HTML, CSS, JavaScript-подобный язык TIScript и DOM с некоторыми добавлениями, не входящими в спецификации W3C, но полезными для построения UI[1].

Старый вариант библиотеки HTMLayout работал только под Windows. Sciter, это кроссплатформенная библиотека, доступная не только для Windows, но также для Linux и Mac OS X.

В качестве движка JavaScript эти продукты используют TIScript.

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

MTD>Сейчас в виртуалке попробую, так стремно.

Запустил. Ну что сказать, по одежке как говорят встречают. Ты менеджеры компоновки не осилил что-ли? Почему оно все зарезалось? Я только запустил, ничего не трогал:

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

MTD>>Сейчас в виртуалке попробую, так стремно.

Поресайзил:

Что оно обратно не восстановилось? ОМГ, косяк на косяке, и почему я не удивлен, что вот это не популярно вообще?

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

MTD>>>Сейчас в виртуалке попробую, так стремно.

Картинки из клипборда не вставляются, кликнул два раза по иконке <PRE> — оно упало: Segmentation fault

Друг, извини, но до продакшена тебе еще далеко.

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

CS>Да купи уже себе монитор побольше

Монитор у меня большой, в виртуалке поменьше было — 1440Х900, а оно вот так запустилось.

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

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

MTD>>>Сейчас в виртуалке попробую, так стремно.

MTD>Поресайзил:

MTD>Image: crop1.png

MTD>Что оно обратно не восстановилось? ОМГ, косяк на косяке, и почему я не удивлен, что вот это не популярно вообще?

Спасибо за баг репорт.

Есть еще проблемы, как же без них. Не ошибается только тот кто ничего не делает.

А к рукавам претензии есть? Ну там memory и CPU consumption, скорость запуска и прочую техническую муть что мы тут обсуждаем...

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

MTD>>Ты хоть сам понимаешь какую чушь несешь? Напиши сначала аналог аськи, тогда и сравним время. На вскидку твое приложение я напишу за 2 недели, только как проверить, мне всякие поделки писать когда за них не платят лень.

CS>Зачем аналог ?

Чтобы сравнивать похожее, а не задницу с пальцем, как ты предложил.

CS>ICQ от Mail.Ru использует Sciter. Или использовала — не знаю как сейчас.

Никогда не использовали — не осилили, попробовали, но слишком сырое и возможностей мало. Код аськи на гитхабе можешь смотреть, там Qt.

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

CS>А к рукавам претензии есть?

Segmentation fault считается? Есть такое.

CS>Ну там memory и CPU consumption, скорость запуска и прочую техническую муть что мы тут обсуждаем...

Я не обсуждал, какой смысл? По всем этим параметрам и на Qt нет жалоб.

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

MTD>Картинки из клипборда не вставляются, кликнул два раза по иконке <PRE> — оно упало: Segmentation fault

О, вот за это спасибо. WYSIWYG HTML editing это нетривиально, да. Багов там есть по определению.

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

V>Кто какие использует?

Помимо повсеместного няшного Qt и обсуждаемого Сцитера (только сегодня из этой темы о нем узнал), есть еще Джус: https://www.juce.com
Но он сыроват и, по сравнению с Qt, бедноват по возможностям.

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

CS>>ICQ от Mail.Ru использует Sciter. Или использовала — не знаю как сейчас.

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

Вот только басни мне не рассказывай. Начинали они еще с htmlayout там помнится. Потом на Sciter переходили.

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

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

CS>>Спасибо за баг репорт.

MTD>Короче, падает твоя поделка постоянно:

MTD>

MTD>notes: /home/andrew/Desktop/sciter.stable/engine/html/html-actions-stack.cpp:2238: bool html::behavior::do_apply_list(html::view&, html::behavior::editing_ctx*, html::behavior::action*, html::bookmark, html::bookmark, html::tag::symbol_t, const html::attribute_bag&): Assertion `list_items.size()' failed.
MTD>Aborted

MTD>Увы

Тоже спасибо. Это уже на Linux как я понимаю?

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

CS>Тоже спасибо. Это уже на Linux как я понимаю?

Я на винде не запускал — вин дефендер ругался, я перестраховался и не стал запускать, может там вирусня, а может еще что, запустил в виртуалке.

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

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

Pzz>>>Ну как-то, веб-бровсер с собой таскать (или зависеть от предустановленного, неизвестно какого и неизвестно, какой версии), это по-моему, круто очень.

R>>зачем таскать?

Pzz>А кто HTML-то будет отрисовывать?

Ну дык не сервер же HTML рисует?

В Windows есть такой тип ресурса как Dialog — это binary формат в котором описан layout.
Создание диалога это и есть исполнение этого layout. Твой code-behind-UI это C/С++.

Sciter в принципе то же самое — только в качестве layout дефиниций используется HTML/CSS.
А в качестве code-behind-UI или script (что удобнее) или C/C++ или оба на выбор — где что удобнее.

R>>так вы логику гуя на плюсах и пишете, HTML только чтобы нарисовать картинку

Pzz>По мне, так на HTML очень неудобно делать красивые формочки. Правда, оговорюсь, я не особый HTMLный спец.

Ну как бы если под UI понимать и Web в том числе то 99.99% UI это HTML/CSS/scipt

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

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

CS>>Тоже спасибо. Это уже на Linux как я понимаю?

MTD>Я на винде не запускал — вин дефендер ругался, я перестраховался и не стал запускать, может там вирусня, а может еще что, запустил в виртуалке.

Нету там "вирусни". У меня тут весь клиентский зоопарк мониторит: https://sciter.com/#customers

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

R>>>зачем таскать?

Pzz>>А кто HTML-то будет отрисовывать?

R>Sciter(ранее HTMLayout) — встраиваемый браузерный движок

То, что он встраиваемый, не означает, что его не приходится с собой таскать.

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

CS>Sciter в принципе то же самое — только в качестве layout дефиниций используется HTML/CSS.
CS>А в качестве code-behind-UI или script (что удобнее) или C/C++ или оба на выбор — где что удобнее.

R>>>так вы логику гуя на плюсах и пишете, HTML только чтобы нарисовать картинку

С логикой-то нет проблемы. Мы, я полагаю, все же сейчас скорее про графику говорим.

Pzz>>По мне, так на HTML очень неудобно делать красивые формочки. Правда, оговорюсь, я не особый HTMLный спец.

CS>Ну как бы если под UI понимать и Web в том числе то 99.99% UI это HTML/CSS/scipt

Что не делает его более удобным...

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

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

CS>>Sciter в принципе то же самое — только в качестве layout дефиниций используется HTML/CSS.
CS>>А в качестве code-behind-UI или script (что удобнее) или C/C++ или оба на выбор — где что удобнее.

R>>>>так вы логику гуя на плюсах и пишете, HTML только чтобы нарисовать картинку

Pzz>С логикой-то нет проблемы. Мы, я полагаю, все же сейчас скорее про графику говорим.

А с графикой что? Рисует в конце концов GPU. HTML это дерево DOM элементов + связанный набор объектов на стороне GPU которые и рисуются когда надо.
Времена когда ты получаешь WM_PAINT и в нем исполняешь код по заливке пикселов (primitive rasterizing) уже ушли.
300 dpi retina monitor и старый 96 dpi монитор это две большие разницы — внезапно пикселей в 9 раз больше стало. CPU рисование — ёк.

Pzz>>>По мне, так на HTML очень неудобно делать красивые формочки. Правда, оговорюсь, я не особый HTMLный спец.

CS>>Ну как бы если под UI понимать и Web в том числе то 99.99% UI это HTML/CSS/scipt

Pzz>Что не делает его более удобным...

Удобство это вещь сугубо субъективная. Что для тебя лично есть "удобно"?

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

CS>>То приложение что выше я написал за три месяца, а за сколько ты написал свое?

MTD>Ты хоть сам понимаешь какую чушь несешь? Напиши сначала аналог аськи, тогда и сравним время. На вскидку твое приложение я напишу за 2 недели, только как проверить, мне всякие поделки писать когда за них не платят лень.

По поводу аналога аськи:

FreeConferenceCall https://www.freeconferencecall.com/global/ca/features

Чисто Sciter UI, communicator, messaging, video, screen sharing: 6.6 Mb.

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

CS>Нету там "вирусни". У меня тут весь клиентский зоопарк мониторит: https://sciter.com/#customers

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

AG>a) Чистый WinForms;
AG>b) Чистый WPF;
AG>c) DeveloperExpress .NET библиотеки по WinForms;
AG>d) DeveloperExpress .NET библиотеки по WPF.
а и б — не рассматриваются в принципе
ц и д — как вариант. на девэкспрессе свет клином не сошелся, есть и другие

R>> — создание API на C++ CLI для разработки гуя на шарпе — проще чем кажется в начале
AG>Зачем, если есть C#?
затем что подразумевается существование достаточно большой кодовой базы на с++, переписывание которой на шарп — маразм с экономической точки зрения
И ее как-то надо связать с UI на шарпе. Из вариантов DllImport|ComInterop|C++ CLI. Последний, на мой взгляд, самый здравый

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

CS>FreeConferenceCall https://www.freeconferencecall.com/global/ca/features

Достаточно поделок на сегодня, спать плохо буду.

CS>Чисто Sciter UI, communicator, messaging, video, screen sharing: 6.6 Mb.

Ты походу застрял в 2004 году (по гую который ты делаешь, это кстати заметно) — всем до лампочки 6 или 106, я так понимаю это от того, что больше мериться нечем, все остальное в минус?

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

CS>Вот только басни мне не рассказывай. Начинали они еще с htmlayout там помнится. Потом на Sciter переходили.

Короче, выяснил у коллег, была какая-то древняя версия, потом переписали с нуля на Qt. Но зря ты об этом заговорил (хинт, зачем уходить с расчудесного фреймворка?).

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

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

R>>>>зачем таскать?

Pzz>>>А кто HTML-то будет отрисовывать?

R>>Sciter(ранее HTMLayout) — встраиваемый браузерный движок

Pzz>То, что он встраиваемый, не означает, что его не приходится с собой таскать.

там длл-ка пару мб — это как-бы и есть sciter

а ваше приложение как-бы и будет "веб-бровсер"

и не нужно "зависеть от предустановленного, неизвестно какого и неизвестно, какой версии"

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

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

CS>>Нету там "вирусни". У меня тут весь клиентский зоопарк мониторит: https://sciter.com/#customers

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

Давно я не занимался созданием дистрибуций, да.

Забыл подписать сам инсталлер. Можешь попробовать еще раз, ну или из .zip запустить. Там notes.exe подписан.

http://notes.sciter.com/downloads/

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

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

CS>>Вот только басни мне не рассказывай. Начинали они еще с htmlayout там помнится. Потом на Sciter переходили.

MTD>Короче, выяснил у коллег, была какая-то древняя версия, потом переписали с нуля на Qt. Но зря ты об этом заговорил (хинт, зачем уходить с расчудесного фреймворка?).

Там вот вспомнилось была у них проблема с интеграцией sciter как child window — архитектура была древней windowed изначально. Я же им предлагал убрать child окна вообще и сделать всё на sciter.
Не захотели переделывать. Но в результате все равно переделали на Qt + ея megabytes сверху. Но паровоз уже ушел — слишком поздно — много других за это время возникло.

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

CS>Ну спите спокойно дорогой товарищ, и пусть вам сняться эротические сны про slot и друга ея signal ...

А что за проблема со слотами и сигналами? Чисто любопытно, какая альтернатива? std::function?

CS>Хотя судя по размеру дистрибуции вы туда WebKit все таки вынуждены были воткнуть. Без HTML никуда нынче, да.

Нет, WebKit нет. Но всякого другого хватает, один ffmpeg с кодеками сколько весит.

CS>Кстати, download icq setup, тех 46 mb у меня занял 4 минуты.

Плохой у тебя интернет, у меня секунд 10 из дома. Твоя софтинка у меня качалась вдвое дольше, кстати.

CS>Мне как-то главный UX гай из софтверной конторы из топ 100 рассказывал что по их исследованиям пользователь принимает решение про использование продукта за первые 40 секунд начиная от click на download.

Там очень много тонкостей, по факту все самые популярные мессенджеры не маленькие — viber 80 mb, slack 60 mb, skype тоже около того, потому что реально много чего надо тянуть, да и повторюсь, интернет сейчас не тот, что 20 лет назад, никто не парится.

CS>И первый экран что появится — критически важен.

Да, но это уже к юзабилистам.

CS>У вас же 4 минуты скучного ожидания и в конце пустая форма "Введите свой номер телефона". Вообще без объяснений... И дальше не пускает. Снес нафиг эту наглость сразу. Зачем messemger'у мой номер телефона? Которого у меня лично кстати вообще нет.

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

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

R>а и б — не рассматриваются в принципе
+100500
R>ц и д — как вариант. на девэкспрессе свет клином не сошелся, есть и другие
DeveloperExpress — это одна из лучших доп-библиотек для .NET.
Есть также и ComponentOne, но он ИМХО слабее.

R>>> — создание API на C++ CLI для разработки гуя на шарпе — проще чем кажется в начале
AG>>Зачем, если есть C#?
R>затем что подразумевается существование достаточно большой кодовой базы на с++, переписывание которой на шарп — маразм с экономической точки зрения
R>И ее как-то надо связать с UI на шарпе. Из вариантов DllImport|ComInterop|C++ CLI. Последний, на мой взгляд, самый здравый
Кодовая база на C++ — именно на нативном C++ (корая идёт через DllImport|ComInterop) — обладает огромным приимуществом:
— работает нативный код, корый выполняется значительно быстрее. Так, на моём старом месте работы мы делали приложение на .NET (C#),
которое производило Фурье анализ для примерно пятисот гармоник оцифрованного сигнала. Один цикл анализа на .NET (C#) занимал около 200 ms.
Его переписывание на нативный C++ (в отдельной DLL — затем делаем DllImport) обеспечило цикл длительностью 4 ms (НА ТОМ ЖЕ оборудовании)!!!

Последний вариант (C++ CLI) — это объединение недостатков двух подходов:
1) Код на оборудовании выполняется медленно, так как работает CLR среда .NET системы.
2) Быстроты написания кода программистом, чем так славится C# (VB, Java), также достичь не удаётся (всё таки это C++).

P.S. Лично мне нравится выжимать из оборудования всё, на что оно способно, посему (несмотра на опыт C# разработки) я выбираю нативный C++

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

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

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

CS>>>FreeConferenceCall https://www.freeconferencecall.com/global/ca/features

MTD>>Достаточно поделок на сегодня, спать плохо буду.

CS>Ну спите спокойно дорогой товарищ, и пусть вам сняться эротические сны про slot и друга ея signal ...

Ну да, до Qt 5 нельзя было использовать компилятор для проверки соответствия signal/slot,
даже я писал "проверяльщик": https://reviews.llvm.org/D14592 для этого.
Но теперь да это работает в compile time, в то время как:

/tmp/bin.gtk $ ./notes 
Error: storage error:Failed to create database file
        at openDatabase (this://app/db/db.tis(18))
        at undefined (this://app/db/db.tis(43))


Error:  (undefined) has no method - getBookItemsCount
        at BooksView.attached (this://app/books-view.tis(5))


Error:  (undefined) has no method - selectTags
        at TagsTree.attached.eachRoot (this://app/tags-view.tis(37))
        at VirtualTree.reset (this://app/libs/vtree.tis(112))
        at VirtualTree (this://app/libs/vtree.tis(122))
        at TagsTree.attached (this://app/tags-view.tis(74))


Error:  (undefined) has no method - selectTags
        at TagsTree.attached.eachRoot (this://app/tags-view.tis(37))
        at VirtualTree.reset (this://app/libs/vtree.tis(112))
        at VirtualTree (this://app/libs/vtree.tis(122))
        at TagsTree.attached (this://app/tags-view.tis(74))

Error: Wrong type - undefined, expected instance of function
        at List.attached (this://app/notes-view.tis(15))


Error:  (undefined) has no method - getBooks
        at NoteView.populateBooks (this://app/note-view.tis(95))
        at NoteView.attached (this://app/note-view.tis(63))


Error: Variable not found - currentNote
        at NoteView.showNote (this://app/note-view.tis(84))
        at  (this://app/note-view.tis(29))


Error:  (null) has no method - indexOf
        at VirtualList.@493@34 (this://app/libs/vlist.tis(496))

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

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

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

CS>>Ну спите спокойно дорогой товарищ, и пусть вам сняться эротические сны про slot и друга ея signal ...

MTD>А что за проблема со слотами и сигналами? Чисто любопытно, какая альтернатива? std::function?

Альтернатив... их есть. Например sinking/bubbling event propagation schema в DOM : https://javascript.info/bubbling-and-capturing

При такой схеме slot/signal не нужны — контейнеры получают события своих children бесплатно. Т.е. без всякой дополнительной инфраструктуры.
Схема легкая и быстрая.

CS>>Хотя судя по размеру дистрибуции вы туда WebKit все таки вынуждены были воткнуть. Без HTML никуда нынче, да.

MTD>Нет, WebKit нет. Но всякого другого хватает, один ffmpeg с кодеками сколько весит.

А вот зачем мне ffmpeg для текстового чата? Обычно такие вещи загружают on demand.

CS>>Кстати, download icq setup, тех 46 mb у меня занял 4 минуты.
MTD>Плохой у тебя интернет, у меня секунд 10 из дома. Твоя софтинка у меня качалась вдвое дольше, кстати.

Если 50 mbit канал плохой то тогда он плохой у всей Канады. Тут реально всего два кабельных провайдера.
Т.е. для всей Канады icq вычеркиваем или как?

Это я к тому что размер он важен. Даже при mbit каналах.
Про игрушки мы не говорим — там люди ожидают что качаться будет много и про то что они хотят скачать они знают заранее.

CS>>И первый экран что появится — критически важен.

MTD>Да, но это уже к юзабилистам.

Это мое алаверды на твои замечания (которые справедливы).

CS>>У вас же 4 минуты скучного ожидания и в конце пустая форма "Введите свой номер телефона". Вообще без объяснений... И дальше не пускает. Снес нафиг эту наглость сразу. Зачем messemger'у мой номер телефона? Которого у меня лично кстати вообще нет.

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

Ну значит icq только для России. Это только в России номер телефона = человек. В Канаде, Австралии и в Европе это далеко не так. Есть в семье один emergency mobile и хватит.
В любом случае на том экране нужно объяснить зачем этому "программному комплексу" (если судить по размеру) нужен телефон человека при наличии канала в интернет.
У вас же не связь по телефону в конце концов? Черт-те что можно подумать ...

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

Z>Ну да, до Qt 5 нельзя было использовать компилятор для проверки соответствия signal/slot,
Z>даже я писал "проверяльщик": https://reviews.llvm.org/D14592 для этого.

Да пофиг на самом деле. Сначала создаем систему в которой можно соорудить циклические event dispatching графы, а потом код борьбы с этим.
Все при деле.

Z>

Z>/tmp/bin.gtk $ ./notes 
Z>Error: storage error:Failed to create database file
Z>        at openDatabase (this://app/db/db.tis(18))
Z>        at undefined (this://app/db/db.tis(43))
Z> ...
Z>

Вот зашибись. У тебя что юзеру запрещено файлы создавать в своём Documents фолдере? Закрыт он для записи?

Но реально конечно это я недоделал — надо такие случаи как-то обрабатывать и говорить юзеру словами про проблему.

В любом случае код отработал штатно и ничего у тебя на машине не поломал и по висящим ссылкам ничего не записал.

Z>Это лог программы notes, запустил и пару кнопок нажал.
Z>В ней вообще что-нибудь в процессе компиляции проверяется,
Z>наличие методов, сигналов, свойств?

Нет там сигналов. Но есть не выведенный в UI exception. Бум чинить.

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

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

V>>Кто какие использует?

XOO>Помимо повсеместного няшного Qt и обсуждаемого Сцитера (только сегодня из этой темы о нем узнал), есть еще Джус: https://www.juce.com
XOO>Но он сыроват и, по сравнению с Qt, бедноват по возможностям.

https://www.howtopronounce.com/sciter/

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

CS>Альтернатив... их есть. Например sinking/bubbling event propagation schema в DOM : https://javascript.info/bubbling-and-capturing

CS>При такой схеме slot/signal не нужны — контейнеры получают события своих children бесплатно. Т.е. без всякой дополнительной инфраструктуры.
CS>Схема легкая и быстрая.

Это один небольшой частный случай, а не альтернатива. У signal/slot нет никаких существенных недостатков кроме идеологических для некоторых фундаменталистов.

CS>А вот зачем мне ffmpeg для текстового чата? Обычно такие вещи загружают on demand.

Ты точно застрял в 2003 году. Сейчас все мессенджеры воспроизводят медиа контент — это базовый минимум. Кстати, есть специфика в арабских странах и Азии — там вообще текстом общаются мало, больше пересылают аудио и видео файлы.

CS>Если 50 mbit канал плохой то тогда он плохой у всей Канады. Тут реально всего два кабельных провайдера.
CS>Т.е. для всей Канады icq вычеркиваем или как?

Как только в Канаде станет достаточно пользователей, там тут же поставят сервер — это вопрос к тем кто стратегией занимается. А твой блокнотик вычеркиваем для России? Грузится то он у меня дольше аськи.

CS>Это я к тому что размер он важен. Даже при mbit каналах.

Не важен. У тебя устаревшие представления, как то, что мессенджер — это текстовый чат.

CS>Про игрушки мы не говорим — там люди ожидают что качаться будет много и про то что они хотят скачать они знают заранее.

Про игры ты тоже не прав. Покупаешь игру в стиме, качаешь 20 Гигов, запускаешь, а она говорит "есть обновление" и качает еще 10.

CS>Ну значит icq только для России. Это только в России номер телефона = человек. В Канаде, Австралии и в Европе это далеко не так. Есть в семье один emergency mobile и хватит.

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

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

CS>А когда нужно поменять скажем базовый шрифт для всего UI ты как это делаешь?
CS>Я — меняю одну строку. А ты?

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

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

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

Z>>Ну да, до Qt 5 нельзя было использовать компилятор для проверки соответствия signal/slot,
Z>>даже я писал "проверяльщик": https://reviews.llvm.org/D14592 для этого.

CS>Да пофиг на самом деле. Сначала создаем систему в которой можно соорудить циклические event dispatching графы, а потом код борьбы с этим.
CS>Все при деле.

Вообще-то я боролся не циклическими графами событий, а просто с проверкой сигнатур сигналов
и слотов. Но вообще с каких пор в html/javascript нельзя создать зацикленный цепочки событий,
в javascript/html можно посылать и принимать "custom event",
в ващем framework нельзя создавать и подписывать на "пользовательские события"?

Z>>

Z>>/tmp/bin.gtk $ ./notes 
Z>>Error: storage error:Failed to create database file
Z>>        at openDatabase (this://app/db/db.tis(18))
Z>>        at undefined (this://app/db/db.tis(43))
Z>> ...
Z>>

CS>Вот зашибись. У тебя что юзеру запрещено файлы создавать в своём Documents фолдере? Закрыт он для записи?

Пользователю конечно разрешена запись в $HOME, чему подтверждение файл $HOME/.config/sciter.notes.json,
т.к. других программ на scriter я не запускал. Но директории $HOME/Documents действительно не существует,
и никогда не существовало, а зачем она мне нужна? Это ведь не windows, никаких "My Documents" разработчики
Linux не предусмотрели, только $HOME

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

CS>>Чисто Sciter UI, communicator, messaging, video, screen sharing: 6.6 Mb.

MTD>Ты походу застрял в 2004 году (по гую который ты делаешь, это кстати заметно) — всем до лампочки 6 или 106, я так понимаю это от того, что больше мериться нечем, все остальное в минус?

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

Вот например я до сих пор использую ICQ и естественно не официальный клиент.
Для меня было бы killer фичей, заставившей поставить и попробовать новый офиц. клиент,
было бы заявление, от том, что ваша программа потребляет совсем мало ресурсов,
например 10М RSS (на сам размер дистрибутива пофиг).
Т.к. мне мои все мои 16ГБ оперативки нужны для работы, и чем меньше жрут
редко используемые, но висящие в памяти программы тем лучше.
Ведь времена файлов подкачки (SSD) и работающих от стационарного электро питания
компьютеров (ноутбуки) прошли.

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

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

Увы, таких очень мало, по сравнению с количеством новых пользователей которые про даже не знают — капля в море. Поэтому на них все забивают.

Z>Вот например я до сих пор использую ICQ и естественно не официальный клиент.
Z>Для меня было бы killer фичей, заставившей поставить и попробовать новый офиц. клиент,
Z>было бы заявление, от том, что ваша программа потребляет совсем мало ресурсов,
Z>например 10М RSS (на сам размер дистрибутива пофиг).

Для тебя точно не аська, там упор сделан на скорость работы с медиа — быстро показывать картинки, ролики, стикеры, то есть всякий развлекательный контент, а все это много весит.

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

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

CS>>А вот зачем мне ffmpeg для текстового чата? Обычно такие вещи загружают on demand.

MTD>Ты точно застрял в 2003 году. Сейчас все мессенджеры воспроизводят медиа контент — это базовый минимум. Кстати, есть специфика в арабских странах и Азии — там вообще текстом общаются мало, больше пересылают аудио и видео файлы.

Ты когда-нибудь в инет из самолета выходил? По всей видимости нет.
А в дороге вообще? Где-нибудь в Штатах в глубинке где 3G за счастье...

CS>>Если 50 mbit канал плохой то тогда он плохой у всей Канады. Тут реально всего два кабельных провайдера.
CS>>Т.е. для всей Канады icq вычеркиваем или как?

CS>>Ну значит icq только для России. Это только в России номер телефона = человек. В Канаде, Австралии и в Европе это далеко не так. Есть в семье один emergency mobile и хватит.

MTD>Телефоны даже у собак уже есть. Ты вообще какую-то дичь рассказываешь, попробуй сейчас в интернете почтовый ящик завести без номера телефона, тебя ждет открытие.

У меня на три члена семьи два телефонных номера. И так по всей Канаде. Сюда смотри: https://en.wikipedia.org/wiki/List_of_countries_by_number_of_mobile_phones_in_use , найди там Канаду или Австралию какую...
Оптимисты, итить... У меня по всему городу WiFi покрытие. Зачем мне телефон? И кстати знаешь что Apple до сих пор выпускает iPod'ы и они в Канаде продаются.

Привет передавай архитекторам что придумали идентификацию по номеру телефона.

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

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

CS>>А когда нужно поменять скажем базовый шрифт для всего UI ты как это делаешь?
CS>>Я — меняю одну строку. А ты?

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

Эй, calm down, я что-то про Qt говорил в этой ветке?

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

CS>Ты когда-нибудь в инет из самолета выходил? По всей видимости нет.

Я уже понял, что интернет не нужен, на дискетах надо инфу возить.

CS>А в дороге вообще? Где-нибудь в Штатах в глубинке где 3G за счастье...

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

CS>У меня на три члена семьи два телефонных номера. И так по всей Канаде. Сюда смотри:

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

CS>И кстати знаешь что Apple до сих пор выпускает iPod'ы и они в Канаде продаются.

ОМГ, какая глушь.

CS>Привет передавай архитекторам что придумали идентификацию по номеру телефона.

Дядя проспал 15 лет, проснулся, в мир его обижает, плохой, плохой мир. Смирись — это объективная реальность, ты можешь ее игнорировать, но скорее всего проигнорируют тебя.

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

CS>>Вот пример "RnQ Маленькая аська

" от Mikanoshi Kimemoshito, русского японца как я понял.

MTD>Собственно вот твоя аудитория, кроме антивирусов, конечно — фрики делающие непонятно что непонятно для кого в стиле 2004 год на дворе.

эм... а какая твоя аудитория?
ваша поделка XMPP поддерживает?

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

R>почти все топовые антивирусы (кроме касперыча) используют sciter!
Обчычно у антивирусов ужасный интерфейс, ИМХО.

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

CS>На reddit любая тема про Electron или Atom...
Да там больше про то, что они при своем размере и пожираемых ресурасах не могут открывать большие файлы. Про размер дистрибутивов жалобы чаще всего на студию/винду

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

Pzz>>Когда не надо каждую загогулинку описывать кучей слов, размазанной по куче файлов.

CS>А когда нужно поменять скажем базовый шрифт для всего UI ты как это делаешь?
CS>Я — меняю одну строку. А ты?

Удобство одной, весьма редкой, операции не означает удобства в целом.

AG>DeveloperExpress — это одна из лучших доп-библиотек для .NET.
AG>Есть также и ComponentOne, но он ИМХО слабее.
Чтобы утверждать такое нужно сидеть и сравнивать с1/дэвэкспресс/телерик/... лоб в лоб в куче сценариев, у меня нет такого опыта
по сайту они все смотрятся неплохо

AG>- работает нативный код, корый выполняется значительно быстрее. Так, на моём старом месте работы мы делали приложение на .NET (C#),
AG>которое производило Фурье анализ для примерно пятисот гармоник оцифрованного сигнала. Один цикл анализа на .NET (C#) занимал около 200 ms.
AG>Его переписывание на нативный C++ (в отдельной DLL — затем делаем DllImport) обеспечило цикл длительностью 4 ms (НА ТОМ ЖЕ оборудовании)!!!

Дело не в производительности, а в том что dllimport предназначался для winapi, это слишком топорный инструмент чтобы отмаршалить скажем

 std::vector<COLORREF> GetPalettte(const std::wstring& name)

не говоря уже о более сложных случаях (ну или я что-то не знаю)

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

M>Я жалуюсь. Кутешный софт очень часто тормозное гавно

Любопытно, что именно тебе таким показалось? Телеграм?

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

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

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

AG>С ностальгией вспоминаю VCL. Qt и WinForms так и не вышли на её уровень формошлёпства.

Тогда еще можно вспомнить про Visual Basic.

That horse is dead already. Does not even stink anymore.

Ну не работают visual designers в общем случае — требуется "резиновость" для разных размеров экрана и пр. стилистика ...

Типа вот скажем: http://kumailht.com/gridforms/example.html

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

AG>С ностальгией вспоминаю VCL. Qt и WinForms так и не вышли на её уровень формошлёпства.
Уровень формошлёпства...

Кстати, так как у VCL и WinForms одно авторство:
https://en.wikipedia.org/wiki/Anders_Hejlsberg
То ИМХО и уровень (в т.ч. и формошлепства) — примерно одинаковый

А если же говорить серьёзно, то уровень приложений ~~15-ти~~ 20-ти летней давности,
современный Qt5 перекрывает уже многократно.

Конечно же, в конце 1990-х уровень VCL выделялся весьма серьёзно — об этом никто и не спорит.
Замечу, что .NET тогда только проектировался, Qt существовал в ещё сыром виде...
VCL позволял легко (без 'мучений', характерных для MFC) создать приложение с графическим интерфейсом!
Посему народ и баловался Delphi да си-билдером, графическую основу которых и составляла эта самая VCL

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

AG>С ностальгией вспоминаю VCL. Qt и WinForms так и не вышли на её уровень формошлёпства.

Да вроде WinForms ничуть не хуже VCL. Компонентов нонечно на порядки меньше, но в некоторых мелочах WF даже чуть получше.

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

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

И как же у меня та самая аська до сих пор работает без этого номера? Уже лет 20, кстати. Правда, без хваленого новомодного клиента на Qt.

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

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

Pzz>>>Когда не надо каждую загогулинку описывать кучей слов, размазанной по куче файлов.

CS>>А когда нужно поменять скажем базовый шрифт для всего UI ты как это делаешь?
CS>>Я — меняю одну строку. А ты?

Pzz>Удобство одной, весьма редкой, операции не означает удобства в целом.

Ну хотя бы одну операцию привел.

Назови что-нибудь конкретное из "удобства в целом" — обсудим. Без этого — разговор с Привоза "сделай мине хорошо".

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

Ops>И как же у меня та самая аська до сих пор работает без этого номера? Уже лет 20, кстати. Правда, без хваленого новомодного клиента на Qt.

При чем тут Qt? За поддержку старых учеток отвечает сервер, то что тебя пока не вынудили апгрейднуть учетку, не значит что это не произойдет. Про 20 лет ты конечно не помнишь, за это время протоколы менялись несколько раз. Если твоя боль вызванная появлением непонятных для тебя слов (это же на слово Qt ты так возбудился, как и ряд забавных персонажей?) утихнет, можешь историю аськи прочитать, например, про AOL которая фактически убила аську и менявшая протоколы для борьбы с неофициальными клиентами.

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

R>>>почти все топовые антивирусы (кроме касперыча) используют sciter!
S>>Обчычно у антивирусов ужасный интерфейс, ИМХО.
N>А причём тут Sciter или Qt?
При том, что использование Sciter антивирусами не самый лучший аргумент в споре о выборе библиотеки для написания хорошего кросс-плотформенного интерфейса.

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

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

CS>Там больше проблемы не циклическим dispatching по существу (который тоже есть как проблема), а с ownership ибо QObject это refcounted штука. Т.е. замкнутая цепочка slot subscribers может быть неудаляемой обычным способом.
Можно в этом месте по подробнее, а то я за много лет использования Qt первый раз слышу о каких-то таких проблемах.

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

MTD>Он Qt не знает, как и большинство отметившихся в теме, но мнение имеет. QObject не имеет счетчика ссылок.
Ну я думал, может я что-то не понял... все таки авторитетный на кывт/сpp человек, а пишет что-то странное... а jazzer еще и плюсует...

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

S>>Можно в этом месте по подробнее, а то я за много лет использования Qt первый раз слышу о каких-то таких проблемах.

MTD>Он Qt не знает, как и большинство отметившихся в теме, но мнение имеет. QObject не имеет счетчика ссылок.

шо, совсем-совсем не имеет?
а это что:

QAtomicPointer<QtSharedPointer::ExternalRefCountData> QObjectPrivate::sharedRefcount;

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

NB>шо, совсем-совсем не имеет?
NB>а это что:
NB>

NB>QAtomicPointer<QtSharedPointer::ExternalRefCountData> QObjectPrivate::sharedRefcount;

Давай почитаем код?

Объявление:

    // these objects are all used to indicate that a QObject was deleted
    // plus QPointer, which keeps a separate list
    QAtomicPointer<QtSharedPointer::ExternalRefCountData> sharedRefcount;

Конструктор ExternalRefCountData:

        inline ExternalRefCountData(DestroyerFn d)
            : destroyer(d)
        {
            strongref.store(1);
            weakref.store(1);
        }

Используется только в деструкторе QObject:

    QtSharedPointer::ExternalRefCountData *sharedRefcount = d->sharedRefcount.load();
    if (sharedRefcount) {
        if (sharedRefcount->strongref.load() > 0) {
            qWarning("QObject: shared QObject was deleted directly. The program is malformed and may crash.");
            // but continue deleting, it's too late to stop anyway
        }

        // indicate to all QWeakPointers that this QObject has now been deleted
        sharedRefcount->strongref.store(0);
        if (!sharedRefcount->weakref.deref())
            delete sharedRefcount;
    }

Где здесь подсчет ссылок?

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

NB>>шо, совсем-совсем не имеет?
NB>>а это что:
NB>>

NB>>QAtomicPointer<QtSharedPointer::ExternalRefCountData> QObjectPrivate::sharedRefcount;

MTD>Давай почитаем код?

MTD>Где здесь подсчет ссылок?

ну то есть объект нужен только для того чтобы проинициализировать в конструкторе, и удалить в деструкторе, и в промежутке между этим никак не используется и не изменяется?

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

NB>и как использование связи parent-children отменяет использование счетчика ссылок?

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

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

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

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

NB>>и как использование связи parent-children отменяет использование счетчика ссылок?

MTD>Ты знаешь такую структуру данных — дерево? Если нет, советую ознакомится — одна из базовых структур. Там каждый узел знает о дочерних узлах и при удалении может удалить свои дочерние узлы, а те в свою очередь рекурсивно свои. Счетчик ссылок там избыточен и бесполезен.

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

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

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

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

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

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

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

NB>про чудеса лейаутов можешь не рассказывать,

Не понял, для тебя магия вызов чего-то вроде этого setParent(this)?

NB>славу богу с кутом больше 6 лет работаю.

Так значит работаешь

Здравствуйте, 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());

Здравствуйте, 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.

Здравствуйте, 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?

здесь

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

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

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

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

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

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

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

Здравствуйте, 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++ программиста, а можно взять за копейки любого верстальщика из веб'а, которых кругом полно. Однако это преимущество относится не к техническим, а к бизнес вопросам, так что вряд ли его стоит обсуждать в данной теме.

Здравствуйте, 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++ уже очень давно, причём без всяких убогих препроцессоров.

Здравствуйте, 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 без использования при сборке проекта их препроцессора? )

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

_>Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным.

Ты уже сам определись: или "исключительно функциональный стиль" или "ООП является вполне себе естественным и оптимальным".
Что из этого верно?

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

_>

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

Sciter тоже написан на C++ и использует классы и всё такое. Более того у меня используется динамическое наследование, см. мою дискуссию на SO. Здесь тоже обсуждалось. Так вот такие трюки это не совсем C++, а скорее C + VTBL руками сделанная.

Но суть в том что класс в смысле C++ там только один — namespace dom { class element; }. Т.е. снаружи такой системы UI это композиция однотипных элементов.
+ система event handlers которые уже и определяют как эти LEGO блоки себя ведут. Вот эти три <text>+<button>+<popup> собранные в одном месте есть COMBOBOX, а этот один <textarea> есть текстовый редактор.

Современная ситуация такова что базовых/классических элементов которые раньше использовались в UI в реальности не стало хватать с самого начала.
Появились всякие там OWNERDRAW и прочее попытки сделать это всё в ООП стиле... Ну кошмарно же получилось...

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

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

Я не отрицаю, но давай уточним что такое "ООП модель". Это модель внутреннего устройства (WebKit, Gecko, Trident, h-smile engine в Sciter)
или то что предлагается использовать юзерам твоей OOП (MFC,Qt,wxWidgets,etc.)?

Если внутреннего устройства то это никого не парит.
Важно как API этого GUI engine устроен и его гранулярность.

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

_>В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход.

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

Это вот

<body>hello world</body>

24 байта занимает. Предложи более компактный способ сериализации. И способ восстановления из того формата который существенно быстрее скажем этого вот моего парсера который я использую в sciter.
При все при том что координаты ты сериализовать не можешь — они не известны в общем случае (разные DPI и form factors target devices).

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).

Я не знаю что такое "локальные настройки" в современном мире.

Windows XP и Windows 10 — там не то что настройки там UI API разные. В одном есть HWND во втором — уже нет (UWP).
А Linux? Gnome и KDE и твое приложение с тем самым .ui файлом что должно использовать?
Эта мулечка уже протухла лет 10 тому как... Какие нафиг "локальные настройки" в Microsoft Office? А в Visual Studio?
А если сравнить Sublime Text UI и скажем какой Notepad++ — ну блин UI/UX disaster же...

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

_>>Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным.
CS>Ты уже сам определись: или "исключительно функциональный стиль" или "ООП является вполне себе естественным и оптимальным".
CS>Что из этого верно?

Вроде как вполне ясно написано "во многих местах". GUI очевидно к этим местам не относится. Ну разве что я обработчики иногда реализую через лямбды, но это вряд ли можно считать настоящим функциональным стилем. )))

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

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

CS>Но суть в том что класс в смысле C++ там только один — namespace dom { class element; }. Т.е. снаружи такой системы UI это композиция однотипных элементов.

Ну как бы в том же Qt у тебя каждый объект так же может быть проинтерпретирован как экземпляр класса QWidget. И что с того то? Как бы полиморфизм — это и есть базовая особенность ООП. Непонятно что ты этим хотел сказать.

CS>+ система event handlers которые уже и определяют как эти LEGO блоки себя ведут. Вот эти три <text>+<button>+<popup> собранные в одном месте есть COMBOBOX, а этот один <textarea> есть текстовый редактор.

Похоже что ты всё же не заглядывал в исходники современных браузеров, но при этом пишешь тут какие-то свои фантазии на эту тему. Загляни хотя бы в папку core/html вебкита и полюбуйся на представленные там файлы. Ты там увидишь и отдельно файлы HTMLSelectElement и отдельно HTMLTextAreaElement и т.д. — собственно все html контролы (да и не только контролы, а просто все тэги). И каждый из них имеет классическое наследование от HTMLElement (или кого-то из его наследников) с кучей методов, помеченных как override. Я даже не могу себе представить более классическую ООП схему. )))

CS>>>Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами.
_>>И это всё отлично ложится как раз на ООП модель.
CS>Я не отрицаю, но давай уточним что такое "ООП модель". Это модель внутреннего устройства (WebKit, Gecko, Trident, h-smile engine в Sciter)
CS>или то что предлагается использовать юзерам твоей OOП (MFC,Qt,wxWidgets,etc.)?
CS>Если внутреннего устройства то это никого не парит.
CS>Важно как API этого GUI engine устроен и его гранулярность.

API абсолютно одинаковый — набор видимых (контролов) или невидимых (менеджеров разметки и т.п.) объектов, которые можно складывать иерархически (получая некое итоговое дерево). А с учётом наличия компиляторов/интерпретаторов ui/xrc файлов (которые XML внутри), я вообще не вижу никакой разницы между html движками и Qt/wxWidget. Ну кроме того, что HTML движки не представляют возможности статической компиляции в C++.

_>>В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход.
CS>Всё остальное поскипал, но вот на том популярном заблуждении хотел бы остановится.
CS>Это вот
CS>

CS><body>hello world</body>
CS>

CS>24 байта занимает. Предложи более компактный способ сериализации. И способ восстановления из того формата который существенно быстрее скажем этого вот моего парсера который я использую в sciter.
CS>При все при том что координаты ты сериализовать не можешь — они не известны в общем случае (разные DPI и form factors target devices).

Какая ещё сериализация, ты вообще о чём? Мы тут обсуждаем GUI! Или у тебя приложение стартует, подгружает с сервера свой GUI и только потом его рендерит?

В приложение у тебя будет просто скомпилированная строка типа my_layout.addWidget(new QLabel("hello world")), которая априори эффективнее любого сочетания парсер+рендер.

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

Ты похоже осознал тенденцию 2000-ых, когда все переходили в веб, но как-то пропустил тенденцию 2010-ых, когда все переходили снова на приложения (только уже мобильные, а не десктопные). Сейчас у каждого приличного сайта по своему приложению в двух главных магазинах. И эти приложения на каждой из платформ выглядят нативно, что сразу заметно — стиль iOS существенно отличается от Android. Это уже не говоря о том, что они меняются от версии к версии.

CS>Windows XP и Windows 10 — там не то что настройки там UI API разные. В одном есть HWND во втором — уже нет (UWP).
CS>А Linux? Gnome и KDE и твое приложение с тем самым .ui файлом что должно использовать?

Вот именно, что всё разное. И если при этом инструмент позволяет разработчику забыть про всю эту разность (при этом корректно отображая на каждой платформе все нужные особенности), то это правильный инструмент для кроссплатформенной разработки.

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

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

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

https://wiki.qt.io/New_Signal_Slot_Syntax

В теории конечно да, т.е. чтобы подключить свою функцию к сигналу она больше не должна
быть объявлена в секции slot, т.е. в классе не обязателен Q_OBJECT и соотвественно
через moc объявление класса пропускать не нужно.

Вот если сигналы объявлять то нужен препроцессор,
т.к. это нужно чтобы и старый до C++11 и новый стиль работы одновременно
поддерживать, плюс для IDE, плюс наверное для JavaScrit движка.

Вот если бы была доступна "интроспекция" то можно было бы и не использовать moc для этого.

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

R>>>>я выразил свое мнение: что на sciter мне лично было легче создать гуй

MTD>Нет, твой тезис звучал иначе, в твое вранья я тебя уже ткнул.

Остыньте, горячие финские парни

Qt — оно конечно модно и прогрессивно, но имхо — так себе, я его откушал, спасибо, больше не хочется. Sciter — всё думаю попробовать, но кроме игры с демками — пока не сподобился. Для себя я выбрал wxWidgets и пока не пожалел.

У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения. А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю. И колбасит их постоянно из стороны в сторону. wxWidgets и Sciter — более консервативны, а wxWidgets еще и довольно похож на MFC, что довольно приятно. Я, правда, MFC не использовал плотно, плотно только с WTL было. А на wxWidgets проект десятилетней давности без проблем за пару дней адаптируется под новый wxWidgets, и это приятно. С КуТе это гемор на несколько месяцев обычно

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

MTD>При чем тут Qt? За поддержку старых учеток отвечает сервер, то что тебя пока не вынудили апгрейднуть учетку, не значит что это не произойдет. Про 20 лет ты конечно не помнишь, за это время протоколы менялись несколько раз. Если твоя боль вызванная появлением непонятных для тебя слов (это же на слово Qt ты так возбудился, как и ряд забавных персонажей?) утихнет, можешь историю аськи прочитать, например, про AOL которая фактически убила аську и менявшая протоколы для борьбы с неофициальными клиентами.

Про забавных персонажей — это ты в зеркало заглянул, что ли?

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

M>Qt — оно конечно модно и прогрессивно, но имхо — так себе, я его откушал, спасибо, больше не хочется. Sciter — всё думаю попробовать, но кроме игры с демками — пока не сподобился. Для себя я выбрал wxWidgets и пока не пожалел.
M>У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения. А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю. И колбасит их постоянно из стороны в сторону. wxWidgets и Sciter — более консервативны, а wxWidgets еще и довольно похож на MFC, что довольно приятно. Я, правда, MFC не использовал плотно, плотно только с WTL было. А на wxWidgets проект десятилетней давности без проблем за пару дней адаптируется под новый wxWidgets, и это приятно. С КуТе это гемор на несколько месяцев обычно

Главный минус wxWidgets в том, что она до сих пор не может (https://wiki.wxwidgets.org/WxAndroid/Status) Android — лидирующую ОС на планете в данный момент. В наше время заявлять "кроссплатформенность" без Андроида просто смешно.

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

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

_>Главный минус wxWidgets в том, что она до сих пор не может (https://wiki.wxwidgets.org/WxAndroid/Status) Android — лидирующую ОС на планете в данный момент. В наше время заявлять "кроссплатформенность" без Андроида просто смешно.

У них что-то двигается в эту сторону.
А ты КуТе щупал на эту тему? Я щупал. Даже с большим геморром на андроиде уродец получается. А если хочешь нормально, гуй под андроид всё равно надо переписывать с нуля

_>Ну а для исключительно десктопного ПО данная библиотека действительно является довольно не плохим решением.

И я о том.

А чтобы везде работало одинаково — для приложений с не слишком сложным UI — опять же sciter гораздо лучше, чем куте

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

_>>О, уже всё есть? И как это я пропустил то такие позитивные новости... ))) Т.е. я могу спокойно программировать GUI (сереализацию и т.п. вопросы не рассматриваем) на Qt без использования при сборке проекта их препроцессора? )
Z>https://wiki.qt.io/New_Signal_Slot_Syntax
Z>В теории конечно да, т.е. чтобы подключить свою функцию к сигналу она больше не должна
Z>быть объявлена в секции slot, т.е. в классе не обязателен Q_OBJECT и соотвественно
Z>через moc объявление класса пропускать не нужно.

Ну так человеческий вид вызова функции connect я давно знаю и только такой и использую. Речь не об этом, а о разделах signal/slot в классах.

Z>Вот если сигналы объявлять то нужен препроцессор,
Z>т.к. это нужно чтобы и старый до C++11 и новый стиль работы одновременно
Z>поддерживать, плюс для IDE, плюс наверное для JavaScrit движка.

Тут в первую очередь интересует нормальная работа их дизйанера (который по команде в нём автоматически вставляет нужные обработчики в исходники).

Z>Вот если бы была доступна "интроспекция" то можно было бы и не использовать moc для этого.

По нормальному для реализации обработчиков никакой интроспекции не надо. Оно спокойно работает во всех GUI библиотеках, включая самые древние. Потребность в этом у Qt происходит исключительно от кривой изначальной архитектуры. Которая кстати во многом такая — кругом в библиотеке виден "Java-стиль", который полностью расходится с тенденциями развития C++ последнего десятилетия. И самая печаль в том, что этот уродец является сейчас лучшим из существующих решений в данной области (причём не только в мире C++, а вообще среди любых GUI библиотек).

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

_>>Главный минус wxWidgets в том, что она до сих пор не может (https://wiki.wxwidgets.org/WxAndroid/Status) Android — лидирующую ОС на планете в данный момент. В наше время заявлять "кроссплатформенность" без Андроида просто смешно.
M>У них что-то двигается в эту сторону.

Там концептуальная проблема вследствие принципиально другой архитектуры. Qt рисует абсолютно всё сама, требуя от нижележащей платформы только поверхность для рисования и системные настройки стилей (если таковые есть — Qt умеет работать и без ОС вообще, на голом железе). wxWidgets же наоборот принципиально используется только системные контролы на всех платформах. В принципе лично мне подход wxWidgets нравится даже больше, т.к. он обеспечивает абсолютно родное поведение приложение (у Qt всё же бывают мелких огрехи в стилях или поведение контролов). Однако в случае Андроида именно этот подход наткнулся на концептуальную проблему — системные контролы там предоставляются только в виде Java API, а нативному коду предоставляется только та самая поверхность для рисования. Поэтому Qt портировалась на Андроид элементарно (собственно данная ОС для Qt практически ничем не отличается от других), а у wxWidgets серьёзные проблемы с осуществлением полноценного механизма (прокси) для вызова Java API из C++. Кстати, в Qt этот механизм тоже применяется, но только для нескольких важных системных функций, недоступных из нативного API. А wxWidget надо протаскивать через эту штуку по сути всю библиотеку — это огромный объём работы, который очевидно не под силу нескольким энтузиастам, развивающим wxWidgets.

M>А ты КуТе щупал на эту тему? Я щупал. Даже с большим геморром на андроиде уродец получается. А если хочешь нормально, гуй под андроид всё равно надо переписывать с нуля

Щупал и у меня всё отлично работает. Без всяких гемморов и получается совсем не уродец. Единственное, что это было не портирование существующего приложения, а изначальная разработка приложения, работающего сразу под всеми платформами (десктопными и мобильными). Так что оно с самых первых шагов тестировалось и корректировалось для всех ОС.

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

LS>кроме qt и sciter ничего приличного не существует.
LS>минус sciter в том, что он проприетарен.

Вообщето еще есть Xamarin.Forms https://visualstudiomagazine.com/articles/2017/08/01/xamarinforms3_0.aspx
https://xamdev.ru/xamarin-forms-3-0/

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

NB>он поможет тебе за 5 мин понять, что конкретно происходит.

В QObject нет счетчика ссылок управляющего его временем жизни, если бы он был ты бы не кривлялся а назвал файл и строчку.

NB>вместо мозго-ва, которым ты второй день занимаешься.

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

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

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

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

Я понимаю, тебе наверное больно, но ты попробуй понять написанное:

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

NB>// указатель на счетчик
NB>QAtomicPointer<QtSharedPointer::ExternalRefCountData> QObjectPrivate::sharedRefcount;

Конкретно это мы с тобой разбирали уже — это никакой не счетчик ссылок управляющий жизнью QObject.

NB>с тем что в QT везде передают голые указатели (QPointer тоже применяется, но редко) я не спорил, если ты не заметил

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

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

NB>я ответил, просто кто-то не смог понять

Своим бла-бла смотри отладчик? Не катит.

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

Зачем придумывать, в который раз тот-же самый вопрос:

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

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

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

Z>>Вот если сигналы объявлять то нужен препроцессор,
Z>>т.к. это нужно чтобы и старый до C++11 и новый стиль работы одновременно
Z>>поддерживать, плюс для IDE, плюс наверное для JavaScrit движка.

_>Тут в первую очередь интересует нормальная работа их дизйанера (который по команде в нём автоматически вставляет нужные обработчики в исходники).

_>По нормальному для реализации обработчиков никакой интроспекции не надо. Оно спокойно работает во всех GUI библиотеках, включая самые древние.

А можно подробности? Вот у вас есть разделяемая библиотека с виджетами.

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

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

_>>По нормальному для реализации обработчиков никакой интроспекции не надо. Оно спокойно работает во всех GUI библиотеках, включая самые древние.
Z>А можно подробности? Вот у вас есть разделяемая библиотека с виджетами.
Z>И по вашим словам интроспекции никакой не нужно, какими образом без всякой
Z>мета информации IDE может понять какие виджеты есть в этой библиотеке, и какие сигналы
Z>у этих виджетов есть? Не говорю уже о свойствах, которые мы по вашему предложению
Z>оставляем за скобками.

О чём вообще речь? Какую информацию IDE (кстати какая именно? А то многие вообще считают это ошибкой в коде) понимает о Qt благодаря сигналам/слотам? )))

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

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

_>>>По нормальному для реализации обработчиков никакой интроспекции не надо. Оно спокойно работает во всех GUI библиотеках, включая самые древние.
Z>>А можно подробности? Вот у вас есть разделяемая библиотека с виджетами.
Z>>И по вашим словам интроспекции никакой не нужно, какими образом без всякой
Z>>мета информации IDE может понять какие виджеты есть в этой библиотеке, и какие сигналы
Z>>у этих виджетов есть? Не говорю уже о свойствах, которые мы по вашему предложению
Z>>оставляем за скобками.

_>О чём вообще речь? Какую информацию IDE

>(кстати какая именно?

Любая создатели которой хотят чтобы в их IDE программировать GUI было удобно.

>А то многие вообще считают это ошибкой в коде)

Хм, ну тогда эти IDE абсолютно бесполезны для C++,
если они не могут расспарсить:

#define signals private

class Foo {
signals:
void f();
};

то нахрена нужны такие IDE?

> понимает о Qt благодаря сигналам/слотам? )))

Мы же только что это обсуждали:

> Тут в первую очередь интересует нормальная работа их дизйанера (который по команде в нём автоматически вставляет нужные обработчики в
+исходники).

В IDE подгружается плагин с виджетами, это могут виджеты из QtGui или реализованные вами,
и IDE должна позволить положить виджет на формочку, и кликнув на виджете сказать хочу
подписать на этот сигнал, как без аналога metaclass это сделать?

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

>>(кстати какая именно?
Z>Любая создатели которой хотят чтобы в их IDE программировать GUI было удобно.

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

>> понимает о Qt благодаря сигналам/слотам? )))
Z>Мы же только что это обсуждали:
>> Тут в первую очередь интересует нормальная работа их дизйанера (который по команде в нём автоматически вставляет нужные обработчики в
Z>+исходники).
Z>В IDE подгружается плагин с виджетами, это могут виджеты из QtGui или реализованные вами,
Z>и IDE должна позволить положить виджет на формочку, и кликнув на виджете сказать хочу
Z>подписать на этот сигнал, как без аналога metaclass это сделать?

А, ну т.е. речь не про IDE, а про визуальный редактор GUI. Это кстати отдельное приложение из встроенных инструментов библиотеки Qt. Так вот я что-то не помню, чтобы оно могло такое, без установки дополнительных плагинов. Т.е. вот допустим есть библиотечка компонентов Qwt для Qt и в неё входит специальный плагин, который надо добавить в визуальный редактор Qt, для поддержки этих новых компонент. Так что...

Ну а если говорить не о произвольных компонентах, а о фиксированном их наборе, то это действительно работает. Причём работает и в wxWidgets и даже в древней MFC. ))) Без всяких signal'ов и slot'ов. )))

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

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

CS>>На reddit любая тема про Electron или Atom...
S>Да там больше про то, что они при своем размере и пожираемых ресурасах не могут открывать большие файлы. Про размер дистрибутивов жалобы чаще всего на студию/винду

The fact that each application comes with its own version of Chromium (the 20 million LOC, ~30MB [packaged] Web runtime) is one of the most criticised aspects.

https://hackernoon.com/electron-the-bad-parts-2b710c491547#6891

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

MTD>А давай, чтобы понятно было какой у тебя опыт в разработке кроссплатформенного гуя на Qt ты покажешь свой проект? Вот мой: https://icq.com/
MTD>Из того, что еще хорошо знаю, Telegram на Qt написан: https://telegram.org/

Ужасающе тормозит в RDP.

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

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

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

MTD>>>Из того, что еще хорошо знаю, Telegram на Qt написан: https://telegram.org/

V_>>Ужасающе тормозит в RDP.

MTD>Не проблема, бери написанный на Sciter — все летать будет. Или тоже тормозить? Не знаю, расскажешь.

Да что-ж ты так реагируешь то болезненно.

К слову Sciter в RDP лучше работает потому как использует Direct2D про который Windows всё знает.
Qt рисует или в bitmap или в OpenGL что не сильно RDP friendly как сам понимаешь.

Но конечно RDP это не critical use case для messengers поэтому можно забить в общем-то.

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

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

А чем мешает препроцессор?
https://woboq.com/blog/moc-myths.html

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

CS>>А каждый QPointer содержит в себе QWeakPointer который уже есть refcounter штука
SaZ>Ну так надо понимать, что такое QPointer — это умный указатель, который автоматически зануляется, если уничтожить объект (который обязательно QObject) в другом месте. Я почему-то изначально думал, что это реализовано на сигналах/слотах, но через weak pointer действительно эффективнее.
SaZ>По сути это и есть QWeakPoniter, для конструирования которого не нужно иметь экземпляр QSharedPointer.
SaZ>Так что в этом случае использование подсчёта ссылок — общепринятый подход.

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

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

M>У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения.
API не меняется, обратная совместимость есть. Что еще надо?

M>А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю.
Это случается примерно раз в 15 лет.

M>И колбасит их постоянно из стороны в сторону. wxWidgets и Sciter — более консервативны, а wxWidgets еще и довольно похож на MFC, что довольно приятно.

M>Я, правда, MFC не использовал плотно, плотно только с WTL было. А на wxWidgets проект десятилетней давности без проблем за пару дней адаптируется под новый wxWidgets, и это приятно. С КуТе это гемор на несколько месяцев обычно
Зачем вам адоптировать старый проект под новую Qt? Ради новых фич? Так в wxWidgets этих фич нет вообще, так что сравнение не имеет смысла

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

Z>И в районе Qt 5.5 они сделали deprecated Script Engine, но QJSEngine идущий ему на смену не обладает всей
Z>функциональностью ScriptEngine.
ScriptEngine был помечен как deprecated уже лет 10, где-то с 4.8, но они его поставляли по просьбам пользователей.

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

NB>но тут надо понимать, что при использовании в разных потоках можно получить проблемы с обращением к удаленному объекту.
Обчно нет, так как обращение к наследникам QObject чаще всего не прямое, а через signal-slot.

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

SaZ>Qt vs HTML.
А тебе исходники того, что они там демонстрируют, не попадались? На картинке красиво, но хотелось бы потрогать...

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

NB>>но тут надо понимать, что при использовании в разных потоках можно получить проблемы с обращением к удаленному объекту.
S>Обчно нет, так как обращение к наследникам QObject чаще всего не прямое, а через signal-slot.

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

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

NB>QPointer никак с наследниками не связан. Просто обычно наследники работают в родительском потоке, поэтому конкурентного доступа к объекту нет.
NB>но если будет обращение к QPointer'у из другого потока, то можно нарваться на грабли (из слабого получаем сырой указатель, в этот момент происходит его разрушение и в итоге работаем с удаленным объектом)
NB>моловероятно, но возможно
Из других потоков обращение обычно идет через сигнал-слот и никаких проблем нет

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

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

SaZ>>Qt vs HTML.
S>А тебе исходники того, что они там демонстрируют, не попадались? На картинке красиво, но хотелось бы потрогать...

Увы нет, и уже нет контактов в Qt, чтобы спросить

. Я думаю, что можно попробовать написать напрямую на почту разрабам этого примера.

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

_>>О, уже всё есть? И как это я пропустил то такие позитивные новости... ))) Т.е. я могу спокойно программировать GUI (сереализацию и т.п. вопросы не рассматриваем) на Qt без использования при сборке проекта их препроцессора? )
SaZ>А чем мешает препроцессор?
SaZ>https://woboq.com/blog/moc-myths.html

Потому что для реализации в C++ системы типа signal/slot никакие препроцессоры не нужны — см. множество соответствующих библиотек. Про бритву Оккама помним? )

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

MTD>Ты не поверишь, я сам за это топил, но развитие продукта определяют не программисты.

Спасибо, я так и думал. Примерно всегда так и происходит. Одна из причин почему предпочитаю стартапы, без метастазов политики и маразма.

донесешь feedback от "реальных клиентов" ?

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

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

MTD>Увы, такой нет.

А вы в QApplication передаёте реальные параметры командной строки? Может туда какой Fusion + кастомный QSS можно подсунуть? Хотя из того что я помню по коду (смотрел давно и поверхностно), там не так уж и в лоб делается кастомизация.

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

_>Потому что для реализации в C++ системы типа signal/slot никакие препроцессоры не нужны — см. множество соответствующих библиотек. Про бритву Оккама помним? )

Ну вот вы явно не прочитали, про что там написано. Для сигналов/слотов — уже не нужно. А вот для рефлексии/удобных вариантов/интроспекции, с поддержкой С++03 (А в Qt4 и С++98), кодогенерация — очень удобное решение, чтобы не городить всякие макрошаблонные извращения.

З.Ы. помню как-то хотел ради сигналов/слотов, интроспекции и локализации прикрутить к проекту Qt. Но начальство упёрлось рогом, мол никаких 3rdparty. В результате — самописный event loop, самописная локализация, китайский CPGF (изврат ещё тот).

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

SaZ>Увы нет, и уже нет контактов в Qt, чтобы спросить

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

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

S>Вообще странно, что они это не выложили в исходниках, всю идею убили.

Они, как я понял, будут делать technology preview, чтобы показать, что QML можно свободно встроить в браузеры и использовать вместо классического html dom. При том, что с QML намного удобнее работать при практически тех же возможностях. Плюс — QML из коробки умеет javascript. Уже, кстати, были демки, где QtQuick приложения запускали через emscripten или через WebGL steam.

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

_>>Потому что для реализации в C++ системы типа signal/slot никакие препроцессоры не нужны — см. множество соответствующих библиотек. Про бритву Оккама помним? )
SaZ>Ну вот вы явно не прочитали, про что там написано. Для сигналов/слотов — уже не нужно. А вот для рефлексии/удобных вариантов/интроспекции, с поддержкой С++03 (А в Qt4 и С++98), кодогенерация — очень удобное решение, чтобы не городить всякие макрошаблонные извращения.

Ну вот я использую C++17, сигналы/слоты и не использую рефлексию. Можно мне получить версию Qt, которая будет нормально работать (включая все инструменты) без препроцессора? Ещё древняя MFC на древнем C++ это умела...

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

_>>Ну вот я использую C++17, сигналы/слоты и не использую рефлексию. Можно мне получить версию Qt, которая будет нормально работать (включая все инструменты) без препроцессора? Ещё древняя MFC на древнем C++ это умела...
SaZ>В древней MFC был зоопарк макросов (не говоря уже о всех костылях и сложностях в разработке кастомных контролов, которые приходилось использовать).

Однако можно было без проблем кинуть кнопку на форму, нажать по ней правую кнопку мыши, выбрать пункт меню типа (сейчас уже естественно не помню) "Перейти к обработчику" и ты оказывался в коде обработчика (причём если его раньше не существовало, то он генерировался средой на ходу). И всё это работало без всяких внешних препроцессоров 20 лет назад.

В wxWidgets аналогично, но гораздо более продвинуто (с произвольными сообщениями и т.п.). И опять же без всяких внешних препроцессоров и кстати даже без макросов.

Соответственно в Qt по сути всё тоже самое, только вот зачем-то понадобился внешний препроцессор.

SaZ>Ешё раз: если вам не нужна рефлексия, то зачем вам Qt?

Мне не нужна Qt. Мне нужна GUI библиотека, позволяющая делать качественные, нативно выглядящие интерфейсы для Android/Windows/iOS/OSX/Linux (естественно с одной кодовой базой). Если кто-то подскажет мне другой инструмент с такой функциональностью, то я с радостью выброшу этого жирного монстра (Qt) подальше — всё равно весь не GUI код у меня использует только нормальные библиотеки (стандартная библиотека языка, Boost и т.п.). Однако к большому сожалению ни одного сравнимого инструмента не видно, так что приходится пользоваться этим.

SaZ>И почему вам не нравится использование кодогенератора (который делает простой и легальный код) — я так и не услышал.

Вполне однозначный ответ уже был озвучен здесь http://rsdn.org/forum/cpp.applied/6907324.1.

SaZ>Qt — популярный инструмент, который предоставляет определённый backward compatibility. Когда будет Qt6, С++20 будет поддерживаться основными компиляторами, тогда можно будет и без препроцессора.

Это если нужна рефлексия (которая для GUI вообще ни к чему). А если без неё, то можно было без препроцессора уже 20 лет назад.

SaZ>И да, есть Verdigris который более-менее позволяет Qt без препроцессора.

Любопытно. Интересно, IDE нормально это понимает (чтобы не сломался описанный выше механизм работы) или нет? )

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

MTD>Для меня особенно показателен пример правильный с точки зрения фундаменталистов (все средствами языка), но совершенно абсурдный с точки зрения разума — Boost Spirit. Можно взять yacc или что-то подобное, встроить в сборку, компилировать за доли секунды, иметь нормальную диагностику ошибок и гибкость для модификации. А можно взять спирит, компилировать по 5-10 минут, получать сообщения об ошибки в 400 строк из которых ничего не понятно и боятся лишний раз тронуть написанное. Еще лично для меня забавно выглядят все наезды на препроцессор от пользователей языка, где препроцессинг вообще стадия компиляции.

Оу, какие у нас тут специалисты подъехали... )))

Ну т.е. тебя тогда не затруднит показать пример красивой реализации на yacc скажем простейшего кода загрузки в vector массива double чисел, хранящихся в большом текстовом файле (скажем в американском формате с точкой и разделённых между собой запятой)? На spirit'е это будет одна коротенькая строчка. Ну а когда справишься с собственно написанием кода, то попробуем ещё померить получившуюся производительность...

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

_>Оу, какие у нас тут специалисты подъехали... )))

По-существу обсуждать тебе видимо нечего, решил сразу на личность съехать?

_>Ну т.е. тебя тогда не затруднит показать пример красивой реализации на yacc скажем простейшего кода загрузки в vector массива double чисел, хранящихся в большом текстовом файле (скажем в американском формате с точкой и разделённых между собой запятой)?

А зачем для этого нужен yacc или Spirit? Про время компиляции, диагностику ошибок и удобство в поддержке возражений нет? Ок.

_>Ну а когда справишься с собственно написанием кода, то попробуем ещё померить получившуюся производительность...

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

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

_>Ну во-первых данная "очень качественная архитектура" (даже смешно читать подобные эпитеты в отношение Qt в 2017-ом году) является просто стандартной реализацией одного из самых старых и известных паттернов проектирования. Который существовал задолго до рождения Qt и который применяется в большинстве кроссплатформенных библиотек.

Я не говорю, что они изобрели новые паттерны. Просто они их удачно применили.

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

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

_>Повторяю уже не первый раз: никаких извращений для поддержки реализации сигналов в C++ не требуется. Это должно бы очевидно каждому, даже после знакомства с языком на уровне статьи из Википедии. Просто потому что в C++ (да и даже в C) указатель на функцию является первоклассной сущностью. Более того, полно готовых (и совсем не новых) библиотек на эту тему (например http://www.boost.org/doc/libs/1_65_1/doc/html/signals2.html), оборачивающих эту базовую возможность языка в удобные ООП конструкции.

Ну лично мне намного удобнее объявить
void clicked(); вместо boost::signals2::signal<void ()> clicked;
и
connect( источник, метод, приёмник, метод, [тип соединения] ); вместо (из примеров буста) deliverNews.connect(signal_type::slot_type(&NewsMessageArea::displayNews, newsMessageArea.get(), _1).track(newsMessageArea));

И да, про поддержку компиляторов — выше. Реальных недостатков препроцессора вы пока не написали. Только идеологические.

_>Кому проще то? Уж явно не пользователям их библиотеки...

У меня, как у активного пользователя Qt, не было проблем с подключением moc-а к сборке. Тот же CMake из коробки умеет.

_>Жирная не в смысле размера дистрибутива (хотя тут конечно тоже не всё хорошо, но по сравнению со всякими новомодными Электронами и т.п. можно считать что нормально), а в смысле устройства библиотеки.

Так чем плохое устройство? Понять принцип сигналов/слотов, который синтаксически проще, чем буст или аналоги. Понять что такое QObject, когда он нужен и модель управления временем жизни объекта (parent/child). Понять, что такое event loop (тоже не вижу проблем, если знаком с разработкой GUI). А остальное — уже по вкусу.

_>Угу, всё приложение в одном убогом Java-стиле. ))) Нет, спасибо, не надо такого "удовольствия". )))

А что такое Java стиль? Не понимаю о чём вы.

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

Ну так с базами на C++ в принципе плохо, особенно с универсальными провайдерами. Я кроме QxOrm и SQLAPI ничего внятного не видел. ODB с натяжкой, слишком интрузивный.

_>Я вроде как ясно сказал, что мне от Qt только и нужна эта "малая часть" (GUI).

Терпите. Весь мир утонул в необходимости backward compatibility

_>Не аргументированные сказки.

Ну так я и говорю — дайте пример нормальных сигналов/слотов с многопоточностью под C++03.

SaZ>>Первый пример, который мне пришёл в голову — панель для редактирования свойств объектов. Без рефлексии там пришлось бы писать тонны кода на каждый новый класс. А с рефлекйсией — один раз написали и забыли.
_>

_>unordered_map<string, unique_ptr<property_base>> dynamic_properties;
_>

_>Ага, тонны кода. Ну да, ну да.

Ни о чём код. Мы видимо о разном говорим. Про Spirit и его лаконичность тут где-то рядом уже всё написали.
Вопрос был, кто и при помощи каких данных заполнит эту мапу? Без рефлексии — придётся на каждый написанный класс писать ещё метод для заполнения этой мапы. При редактировании класса — чинить этот метод и т.д.

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

_>>А во-вторых этот вопрос вообще не имеет никакого отношения к нашей дискуссии, т.к. обсуждаемый нами препроцессор вообще никак не связан с упомянутыми особенностями архитектуры, а занят исключительно поддержкой кривой реализации системы сигналов и метаинформацией.
SaZ>Я ещё раз акцентирую мысль. Qt изначально выбрала необходимость кодогенерации. С этим ничего не поделаешь. Но это позволило обеспечить поддержку очень большого зоопарка компиляторов, ещё во времена, когда С++11 даже и не пахло. Я не утверждаю, что нельзя добиться того же поведения без препроцессора на современных стандартах языка. Просто не стоит оно того

Ещё раз повторяю, кодогенерация в Qt не используется для поддержки старых компиляторов. Она используется для:

1. поддержки сигналов, что априори бредово, т.к. все необходимые для этого возможности компиляторы C++ имеют уже много десятилетий.
2. поддержки метаинформации, что наоборот не возможно пока ни в одном компиляторе C++, даже самого последнего стандарта (и это тоже плохо на мой вкус, т.к. является "выходом за пределы языка").

_>>Повторяю уже не первый раз: никаких извращений для поддержки реализации сигналов в C++ не требуется. Это должно бы очевидно каждому, даже после знакомства с языком на уровне статьи из Википедии. Просто потому что в C++ (да и даже в C) указатель на функцию является первоклассной сущностью. Более того, полно готовых (и совсем не новых) библиотек на эту тему (например http://www.boost.org/doc/libs/1_65_1/doc/html/signals2.html), оборачивающих эту базовую возможность языка в удобные ООП конструкции.
SaZ>Ну лично мне намного удобнее объявить
SaZ>void clicked(); вместо boost::signals2::signal<void ()> clicked;

Я думаю всем очевидно, что при использование данной библиотеки никто не будет писать префикс "boost::signals2::". Соответственно особой разницу не видно и даже второй вариант однозначнее выглядит.

SaZ>и
SaZ>connect( источник, метод, приёмник, метод, [тип соединения] ); вместо (из примеров буста) deliverNews.connect(signal_type::slot_type(&NewsMessageArea::displayNews,SaZ> newsMessageArea.get(), _1).track(newsMessageArea));

Ну да, только у тебя тут для Boost'а полноценная компилируемая строчка со всеми идентификаторами, а для Qt некий упрощённый шаблон применения. Ты напиши полноценный аналог с теми же именами переменных/сигналов/слотов и тогда сравни. )

_>>Жирная не в смысле размера дистрибутива (хотя тут конечно тоже не всё хорошо, но по сравнению со всякими новомодными Электронами и т.п. можно считать что нормально), а в смысле устройства библиотеки.
SaZ>Так чем плохое устройство? Понять принцип сигналов/слотов, который синтаксически проще, чем буст или аналоги. Понять что такое QObject, когда он нужен и модель управления временем жизни объекта (parent/child). Понять, что такое event loop (тоже не вижу проблем, если знаком с разработкой GUI). А остальное — уже по вкусу.

Она плоха тем, что заточена на использование своих убогих велосипедов, вместо общепринятых в языке подходов. Т.е. я не могу просто взять их GUI классы (нужные мне) и использовать в нормальном современном C++ окружение.

_>>Угу, всё приложение в одном убогом Java-стиле. ))) Нет, спасибо, не надо такого "удовольствия". )))
SaZ>А что такое Java стиль? Не понимаю о чём вы.

Современный C++ развивается сейчас в сторону функционального стиля, использования локальных переменных с типами-значениями (отсюда и семантика перемещения), активного использования обобщённого и мета программирования. А засилье ООП, сплошные new/delete и т.п. осталось в C++ далёких 90-ых. Ну и вот в Qt. Кстати, это видно даже по стандарту имён переменных — Qt соответствует классической Java нотации, а не C++. Да и вообще они этого не скрывают (см. например http://doc.qt.io/qt-5.9/containers.html#java-style-iterators).

_>>Ну и кстати все эти не GUI модули (базы, сеть, потоки и т.п.) являются крайне жалкими по сравнению с нормальными современными C++ инструментами в соответствующих областях. Точнее и GUI часть в Qt точно такая же кривая, но у неё просто нет настолько же полнофункциональных аналогов. А вот во всех других областях такие аналоги есть и они на голову выше реализации в Qt.
SaZ>Ну так с базами на C++ в принципе плохо, особенно с универсальными провайдерами. Я кроме QxOrm и SQLAPI ничего внятного не видел. ODB с натяжкой, слишком интрузивный.

Да ладно, из старого же есть очень удобная библиотечка SOCI, умеющая наверное все СУБД. А из нового можно глянуть на sqlpp11, которая имеет полноценную статическую (во время компиляции проекта) проверку синтаксиса SQL, т.е. по сути круче чем Linq (там часть работы в рантайме идёт). Правда последняя пока ещё в какой-то степени экспериментальная и поэтому имеет поддержку только нескольких СУБД.

_>>Я вроде как ясно сказал, что мне от Qt только и нужна эта "малая часть" (GUI).
SaZ>Терпите. Весь мир утонул в необходимости backward compatibility

Вот смотрю я например на эту https://github.com/wjakob/nanogui библиотеку и думаю, что если бы ей добавить:
1. нормальную поддержку unicode.
2. дополнить коллекцию стандартных контролов до классического количества (ну как минимум tree и list то должны быть)
3. реализовать внутренние темы и сделать считывания всех соответствующих настроек оформления системы при старте приложения (данный тупой платформозависимый код можно напрямую взять из Qt) с формированием из них текущей темы для всех контролов.
4. (опционально) сделать визуальный редактор контролов.

То можно было бы спокойно выкидывать Qt на свалку.

_>>Не аргументированные сказки.
SaZ>Ну так я и говорю — дайте пример нормальных сигналов/слотов с многопоточностью под C++03.

Так а чем Boost::signal2 не подходит? )

SaZ>>>Первый пример, который мне пришёл в голову — панель для редактирования свойств объектов. Без рефлексии там пришлось бы писать тонны кода на каждый новый класс. А с рефлекйсией — один раз написали и забыли.
_>>

_>>unordered_map<string, unique_ptr<property_base>> dynamic_properties;
_>>

_>>Ага, тонны кода. Ну да, ну да.

SaZ>Ни о чём код. Мы видимо о разном говорим. Про Spirit и его лаконичность тут где-то рядом уже всё написали.
SaZ>Вопрос был, кто и при помощи каких данных заполнит эту мапу? Без рефлексии — придётся на каждый написанный класс писать ещё метод для заполнения этой мапы. При редактировании класса — чинить этот метод и т.д.

Эм, зачем? Почему нельзя использовать напрямую данные из этой коллекции в этих самых классах? Тем более, что это позволит делать им реально динамические свойства, а не псевдо, как в Qt.

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

_>>Современный C++ развивается сейчас в сторону функционального стиля, использования локальных переменных с типами-значениями (отсюда и семантика перемещения), активного использования обобщённого и мета программирования. А засилье ООП, сплошные new/delete и т.п. осталось в C++ далёких 90-ых. Ну и вот в Qt. Кстати, это видно даже по стандарту имён переменных — Qt соответствует классической Java нотации, а не C++. Да и вообще они этого не скрывают (см. например http://doc.qt.io/qt-5.9/containers.html#java-style-iterators).
SaZ>Современный С++ как раз таки мультипарадигмный. И это его достоинство подчёркивается его разработчиками. К тому же Qt сами сказали, что с новым стандартом лучше использовать STL вместо собственных Qt-шных классов, где это возможно. И они по максимуму стали вводить поддержку STL. А раньше, вместо мув семантики у них была очень хорошая реализация COW для всех внутренних типов. new/delete уже никто не использует, всюду есть RAII. Стандарт имён переменных — дело каждого конкретного проекта. Лично мне нравится, что в Qt код выдержан в одном стиле. Причём мне не важно в каком. Под стиль подстраиваешься за пару месяцев работы над проектом.

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

_>>Да ладно, из старого же есть очень удобная библиотечка SOCI, умеющая наверное все СУБД. А из нового можно глянуть на sqlpp11, которая имеет полноценную статическую (во время компиляции проекта) проверку синтаксиса SQL, т.е. по сути круче чем Linq (там часть работы в рантайме идёт). Правда последняя пока ещё в какой-то степени экспериментальная и поэтому имеет поддержку только нескольких СУБД.
SaZ>Вот именно, экспериментальная. А в Qt это работает давно и хорошо, даже на С++03 компиляторах на слабом железе. Ещё раз — не нужно сравнивать Qt со свежими библиотеками, которые писались сразу под C++11. Придёт время и необходимость — они всё отрефакторят.

Я же вроде как ясно всё написал. Хочешь под старый компилятор и не экспериментальную — бери SOCI.

_>>Вот смотрю я например на эту https://github.com/wjakob/nanogui библиотеку и думаю, что если бы ей добавить:
_>>1. нормальную поддержку unicode.
_>>2. дополнить коллекцию стандартных контролов до классического количества (ну как минимум tree и list то должны быть)
_>>3. реализовать внутренние темы и сделать считывания всех соответствующих настроек оформления системы при старте приложения (данный тупой платформозависимый код можно напрямую взять из Qt) с формированием из них текущей темы для всех контролов.
_>>4. (опционально) сделать визуальный редактор контролов.
_>>То можно было бы спокойно выкидывать Qt на свалку.
SaZ>Qt ещё долго на свалку не пойдёт. Вот когда их библиотека сможет без тормозов показывать списки на пару миллионов записей и когда там в пару строк кода можно будет писать кастомные контролы — тогда да, можно будет использовать.

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

SaZ>>>Ну так я и говорю — дайте пример нормальных сигналов/слотов с многопоточностью под C++03.
_>>Так а чем Boost::signal2 не подходит? )
SaZ>При беглом гуглении не нашёл простой возможности сказать, в каком потоке выполнять слот. И не нашёл примеров цикла обработки сообщений.

Интеграция циклов обработки сообщений и т.п. — это специфика или GUI библиотек или специализированных инструментов в этой области (типа Boost::Asio или libuv). Boost::signal2 безопасна для использования в многопоточном коде, а вот перекидывания потоков исполнения между потоками и циклами обработки сообщений — это уже задача отдельных инструментов (потому как там может быть не просто какой-то поток, а например асинхронная сопрограмма).

_>>Эм, зачем? Почему нельзя использовать напрямую данные из этой коллекции в этих самых классах? Тем более, что это позволит делать им реально динамические свойства, а не псевдо, как в Qt.
SaZ>Потому что коллекцию надо сначала заполнить. Вы так и не объяснили, кто будет заполнять коллекцию свойств. В Qt это делается через рефлексию с интроспекцией.
SaZ>В Qt тоже есть динамические свойства, которые можно создавать в рантайме.

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

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

_>Да, и по поводу твоей ссылки (кстати откуда ты её взял интересно? Просто я буквально на днях кидал её прямо на этом форуме)... А тебя не смущает, что там среди лидеров по быстродействию значится тот самый Spirit, на который ты "наезжал"? )))

Хорошая либа, пользуюсь, потому и ссылку дал, а к Spirit у меня претензии не из-за быстродействия, а из-за неудобства использования.

_>Вот открываем твою же ссылку и видим там сплошное засилье C/C++. Одинокая Java на 12-ом месте и одинокий Go на 15-ом. Как-то странно это соотносится с твоими же словами. )))

Так отрыв незначительный, зато скорость разработки раза в 2 выше, так что все ок.

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

_>...
_>Так файловую систему же приняли...

И что, ей реально интенсивно пользуются? Везде, где нужно интенсивно работать с файлами — пишутся собственные платформозависимые обвёртки. Уж очень много нет в filesystem.

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

_>>Да, и по поводу твоей ссылки (кстати откуда ты её взял интересно? Просто я буквально на днях кидал её прямо на этом форуме)... А тебя не смущает, что там среди лидеров по быстродействию значится тот самый Spirit, на который ты "наезжал"? )))
MTD>Хорошая либа, пользуюсь, потому и ссылку дал, а к Spirit у меня претензии не из-за быстродействия, а из-за неудобства использования.

Хорошая либа — это ты про какую?
Что касается неудобства Spirit'а, то я не вижу никакой принципиальной разницы между:

sprintf(s, "%i", i);

и вариантом из Spirit'а

generate(s, int_, i);

при том что последний ещё и гарантирует проверку соответствие формата компилятором. И оба эти варианта гораздо симпатичнее канонического:

stringstream ss;
ss<<i;
s=ss.str();

не говоря уже об убогом быстродействие такого кода.
Ну и конечно есть самый лаконичный (и не жутко тормозящий) вариант

s=to_string(i);

Но у него к сожалению нулевые возможности по форматированию.

_>>Вот открываем твою же ссылку и видим там сплошное засилье C/C++. Одинокая Java на 12-ом месте и одинокий Go на 15-ом. Как-то странно это соотносится с твоими же словами. )))
MTD>Так отрыв незначительный, зато скорость разработки раза в 2 выше, так что все ок.

Так откуда у тебя данные то про скорость разработки в 2 раза выше? ) И как ты себе это вообще представляешь на статическом языке, не поддерживающем обобщённое программирование? )

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

_>>Так файловую систему же приняли...
SaZ>И что, ей реально интенсивно пользуются? Везде, где нужно интенсивно работать с файлами — пишутся собственные платформозависимые обвёртки. Уж очень много нет в filesystem.

Я использовал ещё до переноса в стандарт языка (сейчас просто поменял boost на std), причём не для какой-то там "интенсивной работы" с файлами, а для самой обычной повседневной: задать путь удобным кроссплатформенным способом, проверить существование какого-то файла и т.п. рядовые мелочи.

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

_>Я использовал ещё до переноса в стандарт языка (сейчас просто поменял boost на std), причём не для какой-то там "интенсивной работы" с файлами, а для самой обычной повседневной: задать путь удобным кроссплатформенным способом, проверить существование какого-то файла и т.п. рядовые мелочи.

Ну вот а нам не хватило, когда есть 100к+ файлов и из них нужно быстро найти что-то по маске.

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

S>Не очень понятно, что из этого должно следовать.

Если что-то непонятно, можно спрашивать.

S>То, что если нужно быстро написать, но без особых требований к скорости работы, то Go выгоднее C++?

Написать не только можно значительно быстрей, но еще и работать будет быстрее, чем код на С и С++ — первые решения сливали решениям на Go, под конец чемпионата обогнали, но не значительно. Лично я сделал вывод такой: на Go разработка значительно быстрей, производительность кода на хорошем уровне, требуется большая квалификация чтобы на С или С++ обойти Go, скорее всего с учетом квалификации средней по палате, будет медленней.

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

S>>То, что если нужно быстро написать, но без особых требований к скорости работы, то Go выгоднее C++?

MTD>Написать не только можно значительно быстрей, но еще и работать будет быстрее, чем код на С и С++ — первые решения сливали решениям на Go, под конец чемпионата обогнали, но не значительно.

Ну вот сказки не нужно рассказывать. "Первые решения", это, наверное, парочка самых первых реализаций на C++, потом оказалось, что в финале из 50 решений только с десяток на Go, да и те далеко не в лидерах. Все остальное, практически, один C++.

MTD>Лично я сделал вывод такой: на Go разработка значительно быстрей, производительность кода на хорошем уровне, требуется большая квалификация чтобы на С или С++ обойти Go, скорее всего с учетом квалификации средней по палате, будет медленней.

Это по поводу задачи для highloadcup-а или вообще? Если вообще, то примеры GUI-приложений на Go где-то можно посмотреть? Или, например, математические расчеты на Go так же будут быстрее, аналоги того же Eigen-а в Go уже завезли?

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

S>Ну вот сказки не нужно рассказывать.

Сказки ты сюда пришел рассказывать.

S>"Первые решения", это, наверное, парочка самых первых реализаций на C++

А то, что на Go это тоже были первые решения не считается? Чик-чик мы в домике.

S>потом оказалось, что в финале из 50 решений только с десяток на Go, да и те далеко не в лидерах. Все остальное, практически, один C++.

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

S>Это по поводу задачи для highloadcup-а или вообще?

Вообще.

S>Если вообще, то примеры GUI-приложений на Go где-то можно посмотреть?

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

S>Или, например, математические расчеты на Go так же будут быстрее, аналоги того же Eigen-а в Go уже завезли?

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

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

_>>Я использовал ещё до переноса в стандарт языка (сейчас просто поменял boost на std), причём не для какой-то там "интенсивной работы" с файлами, а для самой обычной повседневной: задать путь удобным кроссплатформенным способом, проверить существование какого-то файла и т.п. рядовые мелочи.
SaZ>Ну вот а нам не хватило, когда есть 100к+ файлов и из них нужно быстро найти что-то по маске.

И что, медленно работает? Я сам то не пробовал на таких объёмах, но код очевидный (две строчки — итератор из filesystem и проверка по маске из regexp) и по идее там негде существенно тормозить.

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

MTD>>А то, что на Go это тоже были первые решения не считается? Чик-чик мы в домике.

S>Ну так о том и речь: если нужно быстро написать, но не нужно быстро работать, то Go "сияет".

Ты можешь и дальше отрицать факты, но есть факт — сервера на Go работают очень быстро, на практике в большинстве случаев даже быстрее C и C++, чтобы его обогнать надо писать на очень низком уровне и сильно заморачиваться.

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

S>Ну когда перепишете ICQ на Go, тогда и расскажите про универсальный язык Go.

Зачем? Пока ICQ на языке не напишешь, то языка как-бы и нет? Питона нет, Руби, Джавы и т.д. Взрослый человек, а такую ахинею несешь.

alex_public:

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

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

S>Из чего это видно? На том же highloadcup этого не видно. Других примеров этой теме еще не было.

Из того же highloadcup и видно. Первые решения на плюсах использовали Asio и прочие либы, при этом сливали Go с его fasthttp, потом начали оптизировать все и вся, выбрасывать либы, использовать голый epoll, душить аллокации и кое-как обогнали. Чисто для справки я в курсе, потому как сам там есть и прошел весь путь от и до. С++ с Asio сливает Go независимо от того нравится тебе это или нет.

S>Для того, чтобы выжать максимум, нужно писать на низком уровне. Тот же highloadcup показал, что спуститься на низкий уровень в C++ можно и это делают многие. На Go этого не сделали, как только производительности fasthttp перестало хватить, так все, стоп.

Тем не менее Go 145 секунд, топовое решение на С 121.8 аж на 19% быстрее, как-то разрыв не впечатляет.

S>А написать вровень с fasthttp и на C++ не сложно, и ни на какой низкий уровень опускаться не нужно.

Это не так. Ты пробовал написать? Если нет, то откуда такая уверенность?

MTD>>Зачем? Пока ICQ на языке не напишешь, то языка как-бы и нет? Питона нет, Руби, Джавы и т.д.

S>Какая тонкая подмена темы. Речь шла об универсальности. Чтобы Go был универсальным, на нем хотелось бы видеть что-то кроме REST-овых back-end-ов и Docker-а. GUI, например. Очень характерный пример, между прочим.

В гугле религия ввести golang gui framework не позволяет? Мне он несколько подсказал.

MTD>>Взрослый человек, а такую ахинею несешь.

S>Похоже, что вам не менее 30. А аргументы как-то в основном из разряда перехода на личности.

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

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

S>Коллега писал. В финале на 41-ом месте, как раз перед оставшимися Go-шными решениями.

Во-первых, я несколько выше твоего коллеги и наверное тоже немного в этом понимаю, начал я тоже с Asio и Rapid JSON. Во-вторых, 34 место Владимир Лукьянчиков (go fasthttp) 192.5 секунд, так что слил твой коллега с Asio Go с fasthttp.

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

MTD>Во-вторых, 34 место Владимир Лукьянчиков (go fasthttp) 192.5 секунд, так что слил твой коллега с Asio Go с fasthttp.

Интересно, это в каком рейтинге? Вот в этом, финальном (https://highloadcup.ru/rating/round/2/), на 34-ом месте Igor Kulakov (C++). Ну а go-шные решения с fasthttp в финале на 45-ом и 46-ом местах.

Владимир Лукьянчиков есть в рейтинге отборочного раунда (https://highloadcup.ru/rating/round/1/). А вот в финале организаторы в 10 раз увеличили объем данных и многие решения слились.

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

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

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

V>>>Интересует под MS VS2013. Кто какие использует?

MTD>>Есть еще разработка одного уважаемого участника форума — Sciter, вроде, когда я смотрел его мне он категорически не понравился, судя по тому, что я не слышу чтобы его где-то широко использовали, то видимо мои ощущения были правильными.

R>почти все топовые антивирусы
дальше не читал )) а что антивирь требует навороченного уай )) да любой аудитреккер, ии к примеру файнанса гуай .. требует такого )) что антивирю и не снилось

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

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

R>>почти все топовые антивирусы (кроме касперыча) используют sciter!

MTD>4 одинаковых софтины (картинка фоном, гвоздями прибитые контролы) — это именно то о чем говорил, то есть около нулевая распространенность.

R>>по моему шикарная вещь! особенно если действительно нужен кроссплатформенный гуй, а не потрах..ся с qt

MTD>А давай, чтобы понятно было какой у тебя опыт в разработке кроссплатформенного гуя на Qt ты покажешь свой проект? Вот мой: https://icq.com/
MTD>Из того, что еще хорошо знаю, Telegram на Qt написан: https://telegram.org/
И??? оно все жило до 14-х стандартов,

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

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

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

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

R>>>почти все топовые антивирусы (кроме касперыча) используют sciter!

MTD>>4 одинаковых софтины (картинка фоном, гвоздями прибитые контролы) — это именно то о чем говорил, то есть около нулевая распространенность.
MTD>>Из того, что еще хорошо знаю, Telegram на Qt написан: https://telegram.org/

R>не ленитесь прокрутите вниз, там есть список тех, кто пользуется sciter — "около нулевая распространенность"

реклама шоль ?? у вас там свой рефлекшин есть ? так, чтобы оп — и структура в окне ?? в компайлтайм проверяющая наличие правильной сигнатуры .. допустим JSON\XML ?
(вообще в последнем стандарте (реализованном) можно таки это все делать, но в ллвм )) можно больше, т.к. именно такм сейчас иде разработка компайл тайм рефлекшина, .. думаю, оно пото пойдет в стандарт, кстати непонятно, когда стандартизуют вынос АСТ на уровень девелопмента)

R>т.е. чтобы встать вровень с Вами я должен сначала потрах..ся с Qt?

спасибо, как-нибудь без меня.
динозавры — оба

MTD>>Вот мой: https://icq.com/

R>поздравляю, супер! icq мне никогда не нравился своим доисторическим интерфейсом, но я действительно рад за Вас! и я нисколько не сомневаюсь, что проггер Вашего калибра сделает гуй хоть на костылях, осталось только сравнить насколько быстрее то же самое Вы бы сделали (ну или проггер с меньшим опытом) используя что-то более пригодное для этого, например на sciter.
)) а вы вкурсе, что мегадизайн рулят джава скриптеры ??? Да, Да, Да оттуда и вертушки-карусели, и много чего. что они в следствии своего полу художестенного мышления сделают лучше любого девелопера .. ?

спасибо, как-нибудь без меня.

MTD>Ты выдал тезис — чтобы написать кроссплатформенный гуй с Qt придется мучиться. Это в корне расходиться с моим опытом, поэтому я решил уточнить у коллеги его опыт. Как было выяснено твое утверждение голословно. Зачем ты вводишь людей в заблуждение?
потому, что тф — динозавр, и не видел современного гуай ))

Здравствуйте, rumit7, Вы писали:
я не понимаю почему вы, вводите в заблуждение молодняк ???
на плюсах до сих пор не было никогда нормального уай, приспособленного до развития на уровне (джава)? дизайнеров (тому ще не було рефлекшина- ну это же факт, вспоминаем сибуилдер)
Но оно уже сейчас возможно )) вот инвестирует кто-то (причем я уверен, что уже, или ждут компайл тайм рефлекшин), и появится — чудо, )) где сойдутся воедино антивиры, парсеры, компиляторы, числоробилки файнанс мас .. архиваторы, ...да любая. да, оно совсем рядом, хватит чесать за ваши велосипеды.

Здравствуйте, Дрободан Фрилич, Вы писали:

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

В GTK я вижу два принципиальных недостатка. Во-первых программы на ней сразу выделяются (ну если конечно запущены не на Gnome'е) не родным оформлением. А во-вторых я что-то не помню наличия у неё версии под Android. Хотя ей это естественно проще сделать, чем wxWidgets, т.к. она рисует контролы сама (как и Qt). Но что-то никак официальных движений в эту сторону не видно. А без этого она даже хуже wxWidgets становится (та хоть нативно выглядит на тех платформах, на которых работает).

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

S>Интересно, это в каком рейтинге?

Рассказываю тем, кому интересно. Сначала было ~~слово~~ мало данных, вот на этой странице это серая табличка https://highloadcup.ru/rating/round/1/

Потом данных сделали в 10 раз больше, кто осилил попал в синею таблицу, кто нет остался в серой. Потом был финал https://highloadcup.ru/rating/round/2/

Тут я так понимаю твой коллега с 235 секундами? Тут да, fasthttp мы встречаем аж на 4 строчки ниже — 246 секунд, хотя конечно есть решения на go и выше в рейтинге, но используют они fasthttp или нет неизвестно, может и только стандартными средствами обошли, гадать не будем.

После финала открыли песочницу, где все как в финале (еще раз повторяю — условия абсолютно те же, что и в финале), чтобы кому интересно могли бы попробовать, ты тоже можешь. И вот там есть fasthttp на 34 месте с 192 секундами, а твой коллега на 35 со 194 секундами. Так что обошел Go твоего коллегу, смирись. Смотреть можно синею таблицу здесь https://highloadcup.ru/rating/

Я кстати кажется понял от чего у тебя такая боль — objectizer так и не взлетел, стали пилить restinio, а оказывается, что и он в перспективе никому не нужен — есть язык простой как палка, со сборкой мусора, на котором программист с меньшей квалификацией может писать столь же производительные сервера тратя меньше времени. Сочувствую. Мне тоже с одной стороны жаль, что ниша языка на котором я пишу за деньги 10 лет все сокращается, но это нормальный процесс — каждый инструмент под свою задачу. За С++ останутся низкоуровневые вещи и огромные in memory db, я так представляю.

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

O>сейчас свой рфлекшин поднять на вариадиках — полдня. и перевести даже эмэфсишную рисовалку на нее еще полдня (обобщенную, чтобы любой класс знал какой браш и борду использовать + евенты и прочая.)

Извини, но это балабольство. Во-первых, не переведешь, во-вторых, есть несколько платформ со своими глюками и отличиями, все это надо сгладить, в третьих, гуй — это не просто кнопку нарисовать, надо еще менеджеры компоновки написать, модели для списков и таблиц, сцены для графики и много много всего еще. Когда это все будет написано, поработает в бою, то есть получит кучу репортов с разных платформ, обрастет кодом который фиксит всякие нежданчики конкретно вот на такой версии ОС, получится что-то совсем не маленькое и простое. Будет оно лучше? Возможно, Qt имеет долгую историю, можно этот груз сбросить и сделать лучше.

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

S>Что автоматически приводит нас к тому, что ваши слова "работать будет быстрее, чем код на С и С++" все еще остаются бездоказательным форумным балабольством (в вашей же терминологии).

Балабольство пока только с твоей стороны. Вот неопровержимый факт:

И вот там есть fasthttp на 34 месте с 192 секундами, а твой коллега на 35 со 194 секундами. Так что обошел Go твоего коллегу, смирись. Смотреть можно синею таблицу здесь https://highloadcup.ru/rating/

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

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

NB>>вижу, из предыдущего общения кое-кто так и не сделал правильных выводов

MTD>Это там где ты слился так и не показав счетчик ссылок управляющий временем жизни QObject?

омг. давно таких не встречал

скажи мне, в коде

template <class T>
class QWeakPointer
{
    typedef QtSharedPointer::ExternalRefCountData Data;

    Data *d;
    T *value;
};

Data *d; это что?

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

S>Ну давайте, для объективности, дадим всем желающим еще одну ссылку: https://highloadcup.ru/rating/round/2/

Я ее уже дал, ты видимо так увлекся борьбой с Go, что моих сообщений не читаешь.

S>С пояснением, что это результат финала, в котором и данных, и запросов было в разы больше, чем в "песочнице", на результаты которой вы указываете.

Читай мои сообщения, я там 2 (два) раза написал, что в песочнице точно такие же условия как в финале. http://rsdn.org/forum/cpp.applied/6911855.1

S>А так же приведем изначальный тезис, высказанный в дискуссии с вами:
S>

А написать вровень с fasthttp и на C++ не сложно, и ни на какой низкий уровень опускаться не нужно.

S>Возможно, в вашем представлении, результаты в 192s и 194s -- это совсем не "вровень", но если уж вы апеллируете ко "всем желающим", то пускай все желающие сами решают -- разница в один с небольшим хвостиком процентов может считаться "вровень" или не может.

Я разве с этим спорил? Я и сам писал:

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

А вот чтобы обойти Go придется опускаться на низкий уровень, но отрыв все равно будет не больше 20% как показал чемпионат. Что выбрать для разработки нового сервера каждый решит сам, в пет проекте я выберу С++, потому как 10 лет пишу на нем и уже немного научился и мне нравится, а в коммерческом проекте я однозначно за Go.

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

NB>class QWeakPointer

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

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

NB>>class QWeakPointer

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

что, начинаешь о чем-то подозревать?
повторяю вопрос, что такое QWeakPointer::d?
да, раз уж пошли такие откровения, то заодно объясни, чем занимается вик поинтер...

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

NB>что, начинаешь о чем-то подозревать?

Я уверен, что ты не глупый и еще в тот раз понял, что сел в лужу, но как взрослый человек признать неправоту не в силах.

NB>повторяю вопрос

Ты еще на мой вопрос не ответил заданный еще там:

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

http://rsdn.org/forum/cpp.applied/6905632.1

Прошу.

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

NB>>что, начинаешь о чем-то подозревать?

MTD>Я уверен, что ты не глупый и еще в тот раз понял, что сел в лужу, но как взрослый человек признать неправоту не в силах.

NB>>повторяю вопрос

MTD>Ты еще на мой вопрос не ответил заданный еще там:

чтобы ответить, мне необходимо понять степень твоей адекватности

так что, ответ будет?

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

MTD>Я ее уже дал, ты видимо так увлекся борьбой с Go, что моих сообщений не читаешь.

Вы опять переходите на личность собеседника.

MTD>Читай мои сообщения, я там 2 (два) раза написал, что в песочнице точно такие же условия как в финале. http://rsdn.org/forum/cpp.applied/6911855.1

Ну тогда объясните, как же получается так, что в песочнице есть результат с GO/fasthttp на 34-ом месте, а в финале его нет?

MTD>

MTD>есть язык простой как палка, со сборкой мусора, на котором программист с меньшей квалификацией может писать столь же производительные сервера тратя меньше времени

Этот тезис ничем не подтвержден.

MTD>А вот чтобы обойти Go придется опускаться на низкий уровень, но отрыв все равно будет не больше 20% как показал чемпионат.

Манипуляция и подтасовка. Даже если брать результаты из песочницы: первое место -- 121s, вариант на Go/fasthttp -- 192s. Это разрыв отнюдь не на 20%. Если же вы сравниваете 121s с результатом 15-го места — 145s, то там и на Go используются низкоуровневые трюки.

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

MTD>>Ты еще на мой вопрос не ответил заданный еще там:

NB>так что, ответ будет?

Только после тебя, я первый спросил

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

http://rsdn.org/forum/cpp.applied/6905632.1

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

MTD>>Читай мои сообщения, я там 2 (два) раза написал, что в песочнице точно такие же условия как в финале. http://rsdn.org/forum/cpp.applied/6911855.1

S>Ну тогда объясните, как же получается так, что в песочнице есть результат с GO/fasthttp на 34-ом месте, а в финале его нет?

Человек не успел написать к финалу, но померится ему захотелось, после финала он запушил свое решение, теперь мы можем посмотреть результат. Вся инфраструктура еще работает, ты можешь тоже написать свое решение, запушить и посмотреть. Судя по тому, что твой коллега улучшил время, после финала он что-то допилил и запустил новый прогон, но Go с fasthttp обойти все равно не смог.

S>Этот тезис ничем не подтвержден.

Мантры-мантры.

S>Манипуляция и подтасовка. Даже если брать результаты из песочницы: первое место -- 121s, вариант на Go/fasthttp -- 192s. Это разрыв отнюдь не на 20%. Если же вы сравниваете 121s с результатом 15-го места — 145s, то там и на Go используются низкоуровневые трюки.

Это ты сейчас подтасовкой и манипуляцией занимаешься сравнивая fasthttp с голым epoll на хаках. Или сравнивай топ С и топ Go или сравнивай fasthttp с Asio.

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

S>Ну тогда объясните

Кстати, вот список известных решений https://github.com/proton/highloadcup17_solutions Можешь посмотреть, если интересно, даже можешь свой докер контейнер собрать и запустить посмотреть.

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

NB>>так что, ответ будет?

MTD>Только после тебя, я первый спросил

MTD>

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

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

ну и заодно расскажи про вик поинтеры.

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

S>>Тезис о скорости разработки на Go оказывается несостоятельным.

MTD>Может он про чемпионат узнал за 2 дня до финала, так что мимо.

Точно так же, как и ваш аргумент о том, что: "Я уже приводил пример — решения на Go появились где-то на 3 день, на С и С++ решения стали появляться к концу второй недели."

Посему еще раз: чем подтверждается более высокая скорость разработки на Go?

MTD>Я инженер и вопросами веры не занимаюсь, с этим к батюшке в церковь.
MTD>С этим никто я и не спорил, Go в данной области настолько же эффективен как и С++, но требует меньших усилий и не требует столь же высокой квалификации программиста.

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

S>>Однако, если затем нужно выжать максимальную производительность, то в C++ это достигается, а в Go обнаруживается заметный разрыв.

MTD>Аж меньше 20%.

По вашему разрыв в 19.25% -- это незаметно?

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

S>Точно так же, как и ваш аргумент о том, что: "Я уже приводил пример — решения на Go появились где-то на 3 день, на С и С++ решения стали появляться к концу второй недели."

Да, тем кто выбрал Go сообщили об этом на неделю раньше. Выборка была достаточная, чтобы проследить закономерность.

S>Посему еще раз: чем подтверждается более высокая скорость разработки на Go?

Личным опытом и опытом коллег. Горутины и каналы прекрасны. Писать будто пишешь синхронный код, но все работает чертовски быстро из-за асинхронности — это круто. И никакого колбек хела. Попробуй, тебе понравится.

S>Если вы инженер и вопросами веры не занимаетесь, то чем вы можете подтвердить "требует меньших усилий и не требует столь же высокой квалификации программиста"?

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

MTD>>Аж меньше 20%.

S>По вашему разрыв в 19.25% -- это незаметно?

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

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

S>>Точно так же, как и ваш аргумент о том, что: "Я уже приводил пример — решения на Go появились где-то на 3 день, на С и С++ решения стали появляться к концу второй недели."

MTD>Да, тем кто выбрал Go сообщили об этом на неделю раньше. Выборка была достаточная, чтобы проследить закономерность.

Поэтому вы ссылаетесь на решение, которое не успело попасть в конкурс. Объективно, да.

S>>Посему еще раз: чем подтверждается более высокая скорость разработки на Go?

MTD>Личным опытом и опытом коллег.

Ok.

MTD>Мое утверждение основано на личном опыте и опыте коллег из Мейл.ру использующих Go в продакшене.

Еще раз Ok.

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

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

S>Если бы вы сразу же сказали, что ваши оценки базируются на ~~радиусе кривизны ваших рук~~ вашем личном опыте

Руки у меня конечно кривые, но судя по тому что я выше твоего коллеги в рейтинге, то немножко как на плюсах писать я понимаю. А еще я на Go писал, потому есть с чем сравнить.

S>не пытаясь сослаться на конкурс highloadcup

Результаты конкурса со сказанным мной отлично коррелируют, то что тебе это не нравится в общем-то неважно.

S>это сильно сократило бы наш диалог.

Не переживай, скоро начнут еще где-то кроме Интервейла использовать твои акторы и Go скоро все забудут и побегут на restinio все переписывать. Все будет хорошо.

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

MTD>>Да ты что? А как пел, как пел:

NB>

Да, опозорился ты знатно.

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

NB>ну и где здесь про удаление QObjecto'м себя?

Что с глазками вдруг плохо стало? Я привел цитаты, можешь еще всю ветку заново прочитать, где ты как глист на сковороде крутился.

NB>здесь про управление жизнью умными указателями.

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

NB>Напоминаю, твой тезис был
NB>

NB>QObject не имеет счетчика ссылок.

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

NB>Тебя в него и ткнули носом.

Ткнул я только тебя в твое дерьмо и хорошо ткнул.

NB>Можешь и дальше выдумывать отмазки про то как счетчик ссылок должен бороздить просторы космоса, но от этого менее глупо выглядеть не перестанешь

Отмазки только ты выдумываешь, ведь как конкретный вопрос тебе задали так невнятное блеянье только и слышно.

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

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

NB>>ну и где здесь про удаление QObjecto'м себя?

MTD>Что с глазками вдруг плохо стало? Я привел цитаты, можешь еще всю ветку заново прочитать, где ты как глист на сковороде крутился.

давай точную цитату, где утверждается что QObject должен удалять себя. ну кроме твоих фантазий на эту тему.

NB>>здесь про управление жизнью умными указателями.

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

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

NB>>Напоминаю, твой тезис был
NB>>

NB>>QObject не имеет счетчика ссылок.

MTD>Да не имеет, я от тебя все пытаюсь добиться чтобы ты мне показал, где этот самый счетчик ссылок в QObject который его временем жизни управляет. После того как я тебя изрядно погонял все что ты сумел выдавить — это флажок, проверив который можно понять, что объект уже умер, но это никакой не счетчик ссылок, тем более управляющий временем жизни QObject.

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

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

ага. с примерами кода и подробными объяснениями.

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

NB>давай точную цитату, где утверждается что QObject должен удалять себя. ну кроме твоих фантазий на эту тему.

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

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

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

Очередная порция детских отмазок.

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

Чушь. Я несколько могу примеров привести, когда это не так. За деньги.

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

Снова жалкое детское надувание щек. Было бы что сказать — дал бы конкретику, а то только ко-ко-ко иди читай.

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

NB>ага. с примерами кода и подробными объяснениями.

Не видел.

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

NB>>давай точную цитату, где утверждается что QObject должен удалять себя. ну кроме твоих фантазий на эту тему.

MTD>Как и ожидалось очередная попытка отмазаться. Иди ветку читай, там в контексе твоих разглагольствований про утечки и счетчики все есть. Ну и то, что я тебя несколько раз спросил где счетчик управляющий жизнью QObject, а ты только мычал, а не сказал сразу, что ты этого не говорил тоже добавляет ясности в вопрос.

повторяю для одаренных.
точную цитату мою.
не надо снова своих измышлизмов.

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

MTD>Снова жалкое детское надувание щек. Было бы что сказать — дал бы конкретику, а то только ко-ко-ко иди читай.

общеизвестные же вещи излагаю.
куда уж конкретнее.

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

NB>>ага. с примерами кода и подробными объяснениями.

MTD>Не видел.

не мои проблемы.

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

MTD>Э нет дружок, это не игра в одни ворота, решил хамить и врать, получишь то же самое (хамство), в отличии от тебя я не врал. Я уже пошел тебе на встречу, подумал, что тяжко человеку, надо уступить, а ты это совсем не правильно понял. Так что иди и читай сначала ветки чего ты там наплел и как ты там выкручивался.

то есть цитаты не будет?
вот так неожиданность

про вранье тоже подтвердить не в состоянии?

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

S>показывает производительность на уровне Go/fasthttp, в которые было вложено в несколько раз (а то и порядков) больше времени и усилий.

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

S>Доказательство на основе личного опыта. Это уже понятно.

Ну у тебя и таких нет, только крепкая вера.

MTD>>Результаты конкурса со сказанным мной отлично коррелируют

S>- решения на Go находятся на 11-ом, 12-ом, 24-ом, 28-ом, 39-ом, 44-48-ом и 50-ом местах.

Ого, сколько решений они на С++ обошли, с учетом того на сколько больше разработчиков на С++, совсем у С++ дела плохи.

S>Т.е. в ТОП-10 никого, в ТОП-30 всего 4;

Так и тебя с твоим коллегой там нет.

S>- нет никакой объективной информации о сравнении сроков разработки решений на C++ и на Go.

Есть, но тебе ее больно видеть, веруй дальше.

S>Все будет хорошо. И акторы будут использовать, и restinio, и про Go никто не забудет.

Аминь.

S>А вы переходили на личность место аргументации, так и продолжите.

Сказал человек начавший дискуссию с троллинга и дешевой демагогии.

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

NB>>то есть цитаты не будет?
MTD>Как не будут? Уже приводил, иди читай. Хотя ты же как нашкодивший ребенок не можешь вести себя как взрослый и признавать ошибки.

уже прочитал и не увидел ничего про то что QObject должен себя удалять. еще попытки будут?

Хотя ты же как нашкодивший ребенок не можешь вести себя как взрослый и признавать ошибки.

NB>>про вранье тоже подтвердить не в состоянии?

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

повторяю вопрос.
точную цитату мою, где я врал.
или балабол.

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

NB>уже прочитал и не увидел ничего про то что QObject должен себя удалять. еще попытки будут?

Это понятно ты же как нашкодивший ребенок не можешь вести себя как взрослый и признавать ошибки.

NB>повторяю вопрос.

Нет, сначала ты на мой вопрос ответь или признай, что ты ошибался, что за время жизни QObject отвечает его счетчик ссылок:

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

http://rsdn.org/forum/cpp.applied/6905632.1

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

MTD>>Доказательство будут, что в несколько раз (а то и порядков) больше времени и усилий или ты балабол?

S>https://github.com/valyala/fasthttp -- 972 коммита, 27 контрибуторов, первый коммит -- 19 октября 2015-го.

S>restinio на сегодняшний день -- 421 коммит, 3 контрибутора, первый коммит -- 5 апреля 2017-го.

И что это должно показать, кроме того, что один проект начался 19 октября 2015, а другой 5 апреля 2017?

S>Но вы разговариваете с балаболом

Правда? Ну ладно.

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

NB>>повторяю вопрос.

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

то есть подтверждения заявы о вранье тоже не будет?
ок. понятно.

Здравствуйте, 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.

Это не счетчик ссылок, это просто флажок жив или мертв объект, не знаю почему его так назвали, ну и временем жизни он не управляет, вообще.

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

NB>>счетчик ссылок в QObject.

MTD>Это не счетчик ссылок, это просто флажок жив или мертв объект, не знаю почему его так назвали, ну и временем жизни он не управляет, вообще.

вторую строку коммента не осилил?
а назвали так потому что раньше кроме вика им еще и шаред пользовался.

повторяю. согласен или нет -- твои проблемы.
теперь хотел бы услышать цитаты на заявление о вранье.

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

NB>повторяю. согласен или нет -- твои проблемы.

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

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

NB>>повторяю. согласен или нет -- твои проблемы.

цитат не будет?
понял.
думаю, на этом и закончим.

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

NB>>думаю, на этом и закончим.

MTD>Снова не смог ответить и слился, как предсказуемо.

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

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

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

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

Так ты ничего и не показал.

NB>итак на $$$ много времени потратил.

Бла-бла-бла. Зачем начинал? Чтобы снова слиться?

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

_>И что, медленно работает? Я сам то не пробовал на таких объёмах, но код очевидный (две строчки — итератор из filesystem и проверка по маске из regexp) и по идее там негде существенно тормозить.

Медленно. WinAPI до 1000 раз быстрее оказался при поиске по маске. Ибо не перебирает всё подряд. Но я не критикую filesystem, тут как с сокетами — если нужно быстродействие, то делаем отдельно под каждую платформу. Если нет — то boost asio или аналоги. Лично мне из filesystem достаточно класса path. Вот он действительно удобный.

Здравствуйте, 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. Давно.

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

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

O>> хотелось заметить, что велосипеды вроде КУт скоро отомрут за ненадобностью.

MTD>С 2008 года, как начал писать на Qt я это слышу, еще то же самое я про С++ слышал, только раньше. Все отмирают они, все отмирают, вот вот и все.
Так )) наличие скажем так непродуктивной мысли в кут это не отменяет. Мало ли кто, что говорит. Вот зачем их туповатыйпрепроцессор ?
Да и ты знаешь, что сейчас своими руками рефлекшин реализуется — в полпинка? Вариадикки decltype и т.д, облегчают жизнь многократно. Но
Заблуждение в том, что ты ориентируешь на кут, надо смотреть глубже — MFC, Cbuilder и прочая прочая прочая, оно практически отмирает с так скажем популярных средств гуи разрботки. смысл в том, что мир на месте не стоит, а именно мир С++ на месте не стоит, и то, что позволял делать препроцессор КУТ с генерациейй кучи моков, будет реализуемо в плюсах (впрочем уже, лично я сейчас на своем проекте вполне удачно релаизовал рефлекшин, РПЦ и прочее ... абстрактную сериализацию чего угоно в любой backend подставь JSON XML/ BIN все вольется в инфрасруктурно тайповом виде)

O>>адью,
O>>лично кут, мне — долго подбирал слово — противен

MTD>Понятно, мнение фанатиков особенно ценно, спасибо.
причем тут фанатизм, исключительно практика
смотри — вот столкнулся я тем, что рекурсия шаблона не глубже 500, и в майкрософте это не починить — влекм рантайм. )) кут я просто не люблю, слищком много фотростепенного геморроя, впрочем я не исключаю того, что просто ресурсов на создание нормального с идеологически\филосовской точки зрения ГУИ не хватит, так и буудем пользоваться велосипедами аля КУТ. Хотя КУТ больше асоциируется у меня с objective C and JAVA ..но никак не с плюсами. Благо во всякие фреймворки (ейген, ААД, буст std) им таки ходу нет. И стд фанкшин вызывает у меня куда больше приятных эстетических ощущений, чем селекторы ..

Смотрю я на ваши посты и вижу, что это всё размышлизмы из области "если бы да кабы, да росли бы во рту грибы". Оно как бы теоретически типа да — на плюсах и рефлексия, и рпц, и 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 в стандартную библиотеку).

От:	MTD	https://github.com/mtrempoltsev
Дата:	13.09.17 07:05
Оценка:	1 (1) +6

	От:	Alexander G
	Дата:	14.09.17 08:23
	Оценка:	+5

От:	c-smile	http://terrainformatica.com
Дата:	13.09.17 14:57
Оценка:	20 (4) +4

От:	MTD	https://github.com/mtrempoltsev
Дата:	13.09.17 15:10
Оценка:	+1 -6

От:	MTD	https://github.com/mtrempoltsev
Дата:	13.09.17 07:35
Оценка:	8 (2) +1 -2

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	14.09.17 13:27
Оценка:	+4

	От:	night beast
	Дата:	17.09.17 13:24
	Оценка:	14 (2) +1

	От:	AlexGin
	Дата:	13.09.17 11:27
	Оценка:	7 (2) +1

От:	Vetal_ca	http://vetal.ca
Дата:	18.09.17 13:26
Оценка:	+1

От:	so5team	https://stiffstream.com
Дата:	23.09.17 15:37
Оценка:	+2

	От:	alex_public
	Дата:	16.09.17 01:50
	Оценка:	5 (1) +1

От:	Pzz	https://github.com/alexpevzner
Дата:	13.09.17 19:13
Оценка:

От:	ollv	https://youtu.be/DQDoYs6wHoo
Дата:	23.09.17 03:02
Оценка:	+1

От:	Nikolaz	www.nikeware.com
Дата:	15.09.17 10:18
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	17.09.17 08:32
Оценка:

	От:	Дрободан Фрилич
	Дата:	22.09.17 18:55
	Оценка: