Сообщение Re[14]: Библиотека для создания графических интерфейсов поль от 21.09.2017 8:47
Изменено 21.09.2017 12:31 SaZ
Re[14]: Библиотека для создания графических интерфейсов поль
Здравствуйте, 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>>Первый пример, который мне пришёл в голову — панель для редактирования свойств объектов. Без рефлексии там пришлось бы писать тонны кода на каждый новый класс. А с рефлекйсией — один раз написали и забыли.
_>
_>Ага, тонны кода. Ну да, ну да.
Ни о чём код. Мы видимо о разном говорим. Про Spirit и его лаконичность тут где-то рядом уже всё написали.
_>Ну во-первых данная "очень качественная архитектура" (даже смешно читать подобные эпитеты в отношение 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 и его лаконичность тут где-то рядом уже всё написали.
Re[14]: Библиотека для создания графических интерфейсов поль
Здравствуйте, 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>>Первый пример, который мне пришёл в голову — панель для редактирования свойств объектов. Без рефлексии там пришлось бы писать тонны кода на каждый новый класс. А с рефлекйсией — один раз написали и забыли.
_>
_>Ага, тонны кода. Ну да, ну да.
Ни о чём код. Мы видимо о разном говорим. Про Spirit и его лаконичность тут где-то рядом уже всё написали.
Вопрос был, кто и при помощи каких данных заполнит эту мапу? Без рефлексии — придётся на каждый написанный класс писать ещё метод для заполнения этой мапы. При редактировании класса — чинить этот метод и т.д.
_>Ну во-первых данная "очень качественная архитектура" (даже смешно читать подобные эпитеты в отношение 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 и его лаконичность тут где-то рядом уже всё написали.
Вопрос был, кто и при помощи каких данных заполнит эту мапу? Без рефлексии — придётся на каждый написанный класс писать ещё метод для заполнения этой мапы. При редактировании класса — чинить этот метод и т.д.