![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Qt, обработка ошибок
Что-то в примерах и документации нигде не вижу как обрабатываются ошибки, типа "в функцию передали кривой параметр", "вызов нижележащей ОС сдох, потому что ее сгрызли черви", итд.
Функции типа qWarning,qFatal, итд, вижу, есть. Вроде и обработка исключений какая-то есть, класс вроде Exception. Но вроде ж try-catch религия не позволяет в C++ юзать или я чего-то уже путаю?
Т.е. вообще, как принято обрабатывать ошибки в Qt?
Функции типа qWarning,qFatal, итд, вижу, есть. Вроде и обработка исключений какая-то есть, класс вроде Exception. Но вроде ж try-catch религия не позволяет в C++ юзать или я чего-то уже путаю?
Т.е. вообще, как принято обрабатывать ошибки в Qt?
no subject
no subject
Соотношение трудозатраты/необходимость в данном случае сильно больше единицы.
И не надо забывать о embedded и компиляции на экзотических платформах.
gcc вездесущ - это его плюс, при прочих минусах. Он близок к стандарту - это тоже его плюс.
Плюсы кодогенератора студии убиваются наповал хреновой производительностью (средне-крупный проект распределённой сборкой собирается 15 минут, 15 * 20 = 5 часов, линкуется 20-35 минут), багами в STL, багами в шаблонах.
Маленький moc & uic на 95% решают свою задачу, и статически типизируемыми их сделать МОЖНО. Не делают по некоторым причинам.
Повторюсь, отсутствие статических проверок в moc & uic - большой, жирный минус. Но на мой взгляд статическая проверка должна быть по галочке, а то убьём совместимость с python как минимум.
no subject
Короче, это снова вопрос из серии спроса и предложения, готовности вкладывать в проект деньги или же работать за еду и идею, и т.п.
Холивар, короче :)
no subject
Нет, Вы не поняли, ВЫ ЛИЧНО писали компилятор? А слово legacy говорит о чём-нибудь?
no subject
Если бы занимался этой темой, то писал бы компиляторы :)
no subject
Каким образом движки на веб-сайтах связаны с компиляторами?
Далее - разработка компилятора языка уровня С++ - человеко-годы. Поддержка его на массе платформ, исправление ошибок, расширения - это всё человеко-десятилетия.
Продвижение его в массы, как и нового языка - многие миллионы баксов.
И как следствие - проблемы с интеграцией библиотеки в другие языки.
При таком раскладе уж проще написать библиотеку на популярном языке программирования, и портировать её API в другие языки. Что и сделал trolltech.
А вообще - могу я услышать аргументы в пользу "написания системы с нуля" а то может я не являюсь архитектором кучи продаваемых проектов, разве что одного, но мне непонятно, почему с нуля писать нужно.
Может я тупее ежа, лошади, и так далее - но Вы уж позвольте, объясните мне пожалуйста, глупому такому.
no subject
компилятор не понимает операции +, у тебя есть 2 варианта, или сделать это кучей сторонних приблуд, когда в итоге у тебя получится вызов типа function('2','2','add'). Если тебя это не пугает, то ок. Если пугает, то надо дорабатывать компилятор. Что тут непонятного? :)
Я понимаю совместимость и т.п. и в частности перед создателями QT вообще снимаю шапку. Но ситуация очень похожа на ту, когда паскаль переползал из DOS в Дельфи. Борланд, к примеру, увеличил количество ключевых слов и расшилил синтаксис в 2 раза. Я думаю, что и тут задача такого же уровня. Конечно, постоянно нужно ориентироваться что это должно быть совместимым по беблиотекам и т.п. со всем имеющимся зверинцем.
no subject
no subject
no subject
Объясните мне две вещи:
1) При чём тут обсуждаемая тема (event-driven реализация в Qt)?
2) Почему Вы думаете, что С++ не поддерживает event-driven?
boost.function / boost.singlas / boost.mpi
http://www.webtoolkit.info/
Ребята явно вдохновлялись Qt. Но они сделали компил-тайм-сейфети сигналы и слоты и у них нету препроцессора. Это ярко демонстрирует отсутствие нужды в стороннем компиляторе - языка С++ более чем достаточно.
Напоминаю - тема нашего обсуждения - компил-тайм-сейфети сигналов и слотов. Давайте от этой темы не уходить в пространные рассуждения о кораблях, бороздящих просторы наших вселенных.
Я вижу субъективное "похоже".
Ребята из борланда ПОМЕНЯЛИ ЯЗЫК.
А Qt - это БИБЛИОТЕКА.
Разница очевидна?
makefile'ы не считаются "сторонними утилитами", не так ли? А локализация?
no subject
no subject
Во вторых, А у Qt основной бизнес угодайте где? Правильно, embedded. Вам то конечно хочется, чтобы всё на блюдечке, но блюдечко не идеально.
В третьих, moc и uic, это не совсем Qt, это механимз интеграции Qt с C++. Слава богу Qt может работать с любым языком, http://qthaskell.berlios.de/ вот вам Haskell, наслаждайтесь.
no subject
no subject
no subject
Развивать, но не так, как это делается.
Новый вариант gcc_qt ж вполне может быть совметсимым со старым.
no subject
проблема connect может быть решена внешними интсрументами, или никак. Увы. Такова реальность.
no subject
на 21й, 22й, 23й века - все, в никс архитектуре РАЗВИТИЕ ОСТАНОВЛЕНО
Если мы принимаем такой ход мысли
"ничего нового нельзя писать, только менять старое"
Это же какая-то ИТ шиза, честно я скажу.
no subject
no subject
no subject