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

SaZ>Статическая сборка, Qt lite, UPX, и оппа, рантайм становится меньше 5 мегабайт.

Так это все равно в десятки раз больше, чем я имею сейчас, и чем если я сделаю свой UI практически с нуля. Если бы Qt был стандартным элементом винды хотя бы начиная с Win7, или устанавливался бы туда один раз, как .NET Framework, а затем использовался всеми приложениями сразу — я бы давно на него перешел. Но необходимость тащить с собой многократно избыточный объем кода в каждом приложении мне настолько неприятна, что пока ничего не могу с собой поделать.

SaZ>1) вы делаете что-то, чисто поиграться, без коммерческой ценности

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

SaZ>2) вы просто так решили что надо максимально уменьшить размер .exe. (Привет ассемблер, менуэт/колибри ОС).

Не "максимально", а разумно. Накладные расходы в 20-30%, даже в 50% можно потерпеть, но тысячи процентов — это уже перебор. И неважно, что большинство разработчиков давно потеряло (или вообще никогда не имело) способность соотносить функциональность с потребным объемом кода. У меня-то она еще сохранилась.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Да я-то с удовольствием, но оно ж все равно тащит в EXE/DLL кучу зависимостей, от которых не избавиться никак, ибо на них завязан сам фреймворк.

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

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

SaZ>>Опишите исходную решаемую задачу

ЕМ>Например, мне нужно сделать передачу в реальном времени нескольких звуковых потоков, чтобы свойства каждого потока отображались на экране по возможности компактно, но чтобы в любой момент их можно было развернуть в подробную картинку. Там нужно показывать и текстовые параметры (частоту дискретизации, разрядность отсчета, количество каналов и т.п.), и столбчатые индикаторы уровней сигнала, и графики задержек на буферизацию.

С реальным временем вы перегнули, я уверен что задержка в 16-50мс на отрисовку будет не очень критична для пользователя, поскольку он её не заметит
Хотите быстро рисовать — откажитесь от WinAPI/GDI и используйте ну хотя-бы OpenGL. Опять же, в Qt это можно в несколько строк кода сделать. А ещё лучше — сразу написать компонент QtQuick. Тем более там из коробки есть графики, правда под GPL либо платной лицензией.

ЕМ>Главная мотивация — простота реализации, но не ценой увеличения размера приложения в десятки раз (сейчас там всего 100-150 кило байт). Я понимаю, что на Qt это делается кратко и изящно, но Qt непременно тащит за собой всю машинерию по отрисовке, платформо-независимые обертки над системными функциями и прочее. Поэтому хочется иметь реализации типовых элементов (список, таблица, сворачиваемое дерево, масштабируемый график и т.п.) или в виде классов C++, или в виде процедур, которые можно легко обернуть в классы.

В очередной раз вопрос — почему у вас появилось ограничение в 150 килобайт вместо 20 мегабайт?

Если вам надо писать компактный и быстрый софт под специальное железо и у вас УЖЕ ЕСТЬ реальные проблемы с производительностью — переходите на ассемблер. Иначе — вы просто сами себе создаёте проблемы на пустом месте.
Я как-то раз выводил графики на аудио пульте под управлением Windows ME, но там был готовый АПИ .

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Не "максимально", а разумно. Накладные расходы в 20-30%, даже в 50% можно потерпеть, но тысячи процентов — это уже перебор. И неважно, что большинство разработчиков давно потеряло (или вообще никогда не имело) способность соотносить функциональность с потребным объемом кода. У меня-то она еще сохранилась.

Стоп, какие накладные расходы? Быстродействие приложения вообще не зависит от размера бинарника.

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

SaZ>Вам ничего не мешает собирать всё в один файл.

Какая разница, будет в составе один большой файл или несколько поменьше, если все они вместе будут десяти-двадцатикратно избыточны по коду?

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

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

SaZ>С реальным временем вы перегнули, я уверен что задержка в 16-50мс на отрисовку будет не очень критична для пользователя, поскольку он её не заметит

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

SaZ>В очередной раз вопрос — почему у вас появилось ограничение в 150 килобайт вместо 20 мегабайт?

Это не ограничение, а реальная оценка объема кода. Если у меня 100 кб кода логики, через WINAPI/GDI то, что мне нужно, реализуется еще в 50-100 кб, то 20 Мб будет аккурат в сто раз больше. Реальная проблема — не "20 Мб", а "объем в сто раз больше реально потребного".

SaZ>Если вам надо писать компактный и быстрый софт под специальное железо и у вас УЖЕ ЕСТЬ реальные проблемы с производительностью — переходите на ассемблер.

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

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

SaZ>какие накладные расходы? Быстродействие приложения вообще не зависит от размера бинарника.

Накладные — от слова "накладываться". Те расходы, что накладываются сверх реально потребных — хоть по объему, хоть по быстродействию, хоть по затратам на установку/сопровождение и т.п.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>То есть, в линуксе с более-менее разнообразным набором приложений уже есть разделяемые между этими приложениями .so, или же каждое приложение просто выставляет зависимости, по которым менеджер пакетов тупо выкачивает нужные библиотеки?
Да и да.

ЕМ>Если Вам предложат ординарный легковой автомобиль, потребляющий 30 л топлива на 100 км пробега — Вы тоже сочтете это нормальным? Даже если топливо будет стоить копейки, остаются еще двуокись углерода и токсичные примеси. Зачем гадить вокруг себя, если можно этого не делать?
Аналогия кривая. Гадить — это приложение на java или js которое воздух греет.

S>>В линухе в общем случае это не так. Но особо популярные приложения всеже тащат свои либы чтобы уменьшить вероятность проблем на стороне пользователя.
ЕМ>Они их тащат исключительно для себя, или другое подобное приложение тоже сможет использовать установленные экземпляры этих либ?
Для себя, но это исключение, а не правило.

ЕМ>А код Opera 9.5 под Windows Desktop (уже распакованный из дистрибутива) — ~4.5 метра. Полноценный браузер со всем своим GUI, HTML/CSS2 (местами и CSS3), работой с сетью, JavaScript-машиной, почтовиком и прочей требухой. И как после этого воспринимать Qt?
Да нормально воспринимать.

ЕМ>>>Так в этих случаях получается перевес объема кода UI над логикой в несколько раз минимум.
S>>Да и пофиг.
ЕМ>Когда всем пофиг — это деградация.
Никакой проблемы в соотношении GUI/логиака нет. GUI это тоже логика, только шаблонная и сделаная другими.

ЕМ>Я хочу не только контролировать поведение, но и исключить присутствие в моих EXE/DLL (а также рядом с ними) заметных объемов кода, заведомо не используемого в моих целях. Такое возможно с Qt при статической линковке? Какие там примерно получаются объемы при использовании только самых простых элементов UI, без украшений?
Я с украшениями ничего особого не делал, так что не знаю. Со статической линковкой лицензия нужна (упрощенно). Если есть лицензия — значит можно писать в техподдержку, уверен, у них есть рецепт на этот случай.

Здравствуйте, Евгений Музыченко, Вы писали:

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

SaZ>>Вам ничего не мешает собирать всё в один файл.
ЕМ>Какая разница, будет в составе один большой файл или несколько поменьше, если все они вместе будут десяти-двадцатикратно избыточны по коду?

Ещё раз, что значит "избыточны"? Не используйте никакие ОС, пишите машинными кодами под bare metal. Не создавайте проблему на пустом месте.

SaZ>>Вы опять же, описываете какие-то свои странные желания, уходя от того чтобы описать реальную проблему (которой, скорее всего нет).
ЕМ>Да, для тех, кто не считает мегабайты, проблемы действительно нет. А потом спрашивают, откуда берется bloatware.

-//-

SaZ>>С реальным временем вы перегнули, я уверен что задержка в 16-50мс на отрисовку будет не очень критична для пользователя, поскольку он её не заметит
ЕМ>На отрисовку — некритична, но большие расходы времени на отрисовку будут грузить процессор, а использование аппаратного ускорения нередко приводит к тому, что видеодрайвер надолго (по меркам ядра) зависает на повышенных приоритетах. Все это не идет на пользу стабильности звуковых потоков при коротких буферах.

Пруф будет? Такой софт как Virtual Dj мало того что рисует весь GUI через видеокарту, так они ещё используют GPU для создания звуковых эффектов в realtime.

SaZ>>В очередной раз вопрос — почему у вас появилось ограничение в 150 килобайт вместо 20 мегабайт?
ЕМ>Это не ограничение, а реальная оценка объема кода. Если у меня 100 кб кода логики, через WINAPI/GDI то, что мне нужно, реализуется еще в 50-100 кб, то 20 Мб будет аккурат в сто раз больше. Реальная проблема — не "20 Мб", а "объем в сто раз больше реально потребного".

Что вы понимаете под словом "потребного"? Повторюсь, почему вы не пишете машинными кодами под bare metal, а используете ОС и высокоуровневые языки?

Здравствуйте, Евгений Музыченко, Вы писали:

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

SaZ>>какие накладные расходы? Быстродействие приложения вообще не зависит от размера бинарника.

ЕМ>Накладные — от слова "накладываться". Те расходы, что накладываются сверх реально потребных — хоть по объему, хоть по быстродействию, хоть по затратам на установку/сопровождение и т.п.

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

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

ЕМ>>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?
bnk>Такое IMHO может сделать только сама Microsoft. Зачем кому-то еще такое делать.
За деньги.

bnk>Это же не будет ни интелисенса нормального, ни поддержки фреймворков, может быть будет использоваться 0.01% разработчиков.
Сейчас — да, а раньше был целый рынок контролов под винду.

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

ЕМ>>>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?
bnk>>Такое IMHO может сделать только сама Microsoft. Зачем кому-то еще такое делать.
BFE>За деньги.

Я про то что контролами же надо как-то пользоваться. Не вижу рынка у контролов, с которым можно общаться только на голом WinAPI через SendMessage
Даже микрософтовские контролы без оберток практически не используются.

IMHO, вот так слона не продать (ну может Евгению разве что)

    SET_HOUR_MINUTE_OPTS param = {};
    param.cb = sizeof(SOME_DATA);
    param.hour = 10;
    param.minute = 22;

    ::SendMessage(hwndTimeControl, MSG_SET_HOUR_MINUTE, 0, &param);

Вот так можно попробовать:

timeControl.Hour = 10;
timeControl.Minute = 22;

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

SaZ>Ещё раз, что значит "избыточны"?

Это значит, что содержат и/или требуют количества ресурсов, значительно превышающего объективно потребные.

24 колеса в городском автомобиле — избыточны. 567 клавиш на стандартной компьютерной клавиатуре — избыточны. Разрешение 13" экрана в 16000x10000 — избыточно. Всего этого не делают по единственной причине — это потребует заметно больше труда и создаст заметно больше проблем, нежели добавление нового шаблонного класса.

SaZ>Не используйте никакие ОС, пишите машинными кодами под bare metal.

По-Вашему, это единственный способ избавиться от многократной избыточности кода/данных?

SaZ>Не создавайте проблему на пустом месте.

Если разработчики 24-колесного городского автомобиля или 567-клавишной клавиатуры на Ваш вопрос "на хрена столько?" дадут Вам такой же ответ — чем станете крыть?

ЕМ>>большие расходы времени на отрисовку будут грузить процессор, а использование аппаратного ускорения нередко приводит к тому, что видеодрайвер надолго (по меркам ядра) зависает на повышенных приоритетах. Все это не идет на пользу стабильности звуковых потоков при коротких буферах.

SaZ>Пруф будет?

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

SaZ>Такой софт как Virtual Dj мало того что рисует весь GUI через видеокарту, так они ещё используют GPU для создания звуковых эффектов в realtime.

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

SaZ>Что вы понимаете под словом "потребного"?

Вам знакомо понятие "объективно"? Вот городскому автомобилю для уверенного передвижения потребны минимум три колеса, а четырех — достаточно. Добавление еще двух, десяти или двадцати колес не повышает устойчивости, надежности, комфорта и т.п., а даже снижает их. Это и есть объективная оценка потребного объема ресурсов.

SaZ>Повторюсь, почему вы не пишете машинными кодами под bare metal, а используете ОС и высокоуровневые языки?

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

Высокоуровневые языки я использую потому, что умею их готовить. Избыточность по сравнению с машинными кодами составляет 10-15% в самых узких местах, и 20-30% — в наименее критичных. А ресурсоемкость изготовления машинного кода той же функциональности была бы в разы выше. Вот такая простая арифметика.

А какими объективными факторами Вы можете оправдать избыточность кода/данных современного софта в десятки раз, кроме того, что "пипл хавает" и "не вижу проблемы"?

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

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

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

SaZ>В общем, конструктивных ответов на свои прямые вопросы я пока от вас не получил

Я от Вас вообще ничего конструктивного пока не получил...

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

bnk>Не вижу рынка у контролов, с которым можно общаться только на голом WinAPI через SendMessage

Что значит "только"? Сделать ООП-обертку для управления через SendMessage гораздо проще, чем написать весь код с нуля в том же ООП.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Что значит "только"? Сделать ООП-обертку для управления через SendMessage гораздо проще, чем написать весь код с нуля в том же ООП.

ЕМ>Мне не нужно, чтобы элементы непременно управлялись через SendMessage. Нехай будут в виде классов, лишь бы код одного элемента, компилирующийся, скажем, в 20 кб, не тащил за собой еще пару мегабайт требухи, которую я никогда не буду использовать.

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

— маппинг hwnd на объекты
— маппинг сообщений на обработчики
— поддержка тем винды при отрисовке

Вроде WTL например ничего другого и не добавляет в принципе
Оверхед самый что ни на есть минимальный. Все определения в хидерах, рантайма нет.

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

Насколько я помню размер измеряемый в килобайтах вполне реален.

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

даже хидер онли гуи по моему приводили в теме

но ему все не то, этакая принцесса несмеяна

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

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

R>зачем вы тратите время на Евгения ?
R>очевидно, если бы ему было нужно, он бы за пару часовой ресерчь в гугл/гитхаб нашел бы то то ему надо
R>даже хидер онли гуи по моему приводили в теме

Ну WTL был популярен довольно недолго, хотя да упоминали. Но может если сказать два раза, это будет иметь больший вес?
И в принципе оверхед таки небольшой, CMyApp вроде не требовался, если мне не изменяет память.

R>но ему все не то, этакая принцесса несмеяна

У меня похожее чувство, но кто сказал что это плохо? Должны же быть хранители?

R>а вообще я бы чуваков через 20 лет в ит программистами, за такие тупые вбросы, банил бы и опускал ниже полинтуса

Злой ты. А как же гласность и плюрализм?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

https://www.tecgraf.puc-rio.br/iup/
https://github.com/andlabs/libui

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

bnk>Вроде WTL например ничего другого и не добавляет в принципе Оверхед самый что ни на есть минимальный.

К WTL претензий нет — она действительно позволяет делать компактные приложения. Претензии к Qt, Sciter и подобным фреймворкам, в коде которых заложено множество возможностей, но почти все они намертво прибиты гвоздями, и затаскиваются в EXE/DLL практически безусловно.

bnk>Все определения в хидерах, рантайма нет.

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

bnk>Размер обычно увеличивается, потому что UI библиотека должна решать эту задачу также для встроенных контролов

Как раз эти объемы весьма скромны — десятки килобайт максимум.

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

bnk>Ну WTL был популярен довольно недолго, хотя да упоминали.

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

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

bnk>Я когда под винду писал, такие вещи на чем-то типа codeproject искались. Вот например PropertyGrid на чистом WinAPI
bnk>https://www.codeproject.com/Articles/77957/Win-SDK-PropertyGrid-Made-Easy
+100500
Да,www.codeproject.com — великолепный ресурс.
Я помню, когда работал над проектими с MFC и WinAPI — часто смотрел туда и брал некоторые интересные идеи и даже коды.