Комментарии 89
Спасибо. С каждым разом все больше вовлекаюсь в QT и Python :)
НЛО прилетело и опубликовало эту надпись здесь
А зачем? Исключение вызывается внутри exec(), там же оно и обрабатывается. Если бы функция вызывала исключение, то каждый раз пришлось бы писать обработчик самому, иначе бы необработанное исключение ушло бы к операционной системе, которая просто бы прибила программу.
НЛО прилетело и опубликовало эту надпись здесь
Сравните:
if (!query.exec("...")) {
//сообщение об ошибке и все что нашей душе угодно
…
}
if (!query.exec("...")) {
//сообщение об ошибке и все что нашей душе угодно
…
}
НЛО прилетело и опубликовало эту надпись здесь
Никто не мешает вам написать в Qt Software письмо о том, что вы не довольны их реализацией работы с базами данных :)
А мне очень нравится, что кутэшники везде применяют самый простой метод. Никаких шаблонов, почти нет исключений… красота, очень сложно после qt3-4 изучать запутанные библиотеки типа boost.
Дык это ж ООП, никто не мешает из result == false сделать throw exception ;), если надо.
В Qt не принято использования исключений для обработки ошибок. Так повелось.
НЛО прилетело и опубликовало эту надпись здесь
а аргументировать?
или вы считаете что d-поинтеры, которые являются частью внутрикорпоративного стандарта QtSoftware и KDE тоже пипец?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Очень просто не интерперабельно. Не для всех платформ где есть Qt это поддерживалось, на многих платформах компилатор С++ — это С с класами и примитивной поддержкой шаблонов, для реализации контейнеров.
Это не «пипец», а стиль, вырабатываемый годами. На прикладном уровне в Qt никто исключений не использует и все живут счастливо. Кроме того, в некоторых ситуациях это повышает производительность и упрощает портирование на разные платформы.
ну вот, опять перевод ассистанта;( оно конечно полезно, но даже не поставлено что это перевод;(
да и хочется то читать не переводы оф документации, а что-то свое с объяснениям каких-нить подводных камней
Это не точный перевод, в нем многое изменено, поэтому ставить что это перевод бессмысленно
хм, ну каждую строку не сравнивал, но общие черты текста и примеры те же что в ассистанте… ну да не спорю, выкинуто примерно треть статьи ассистанта. Причем надо заметить выкинута достаточно вкусная часть
В заключении про самую вкусную часть написано… Статья и так получилась не маленькая.
зато нигде не написано самого первого подводного камня работы с БД, на который натыкаются все кто плохо читает ассистант… я про использование одного подключения из нескольких потоков…
Если вы на этот подводный камень уже наткнулись, то я предлагаю написать данную статью вам
я просто пытаюсь повернуть вашу творческую деятельность из направления «смотрим что есть в ассистанте, переводим это, делаем некоторые правки, выпускаем в свет» в направление «берем некую проблему, пишем по ней статью, смотрим что есть в ассистанте на данную тему, дополняем инфой из ассистанта, выпускаем в свет»
QSqlQuery query;
query.exec(«SELECT name, salary FROM employee WHERE salary > 50000»);
QSqlQuery может выполнять любые SQL выражения, кроме SELECT.
тогда где логика примера?
query.exec(«SELECT name, salary FROM employee WHERE salary > 50000»);
QSqlQuery может выполнять любые SQL выражения, кроме SELECT.
тогда где логика примера?
Статья конечно хорошая, но мне кажется интереснее было бы поговорить о работе с БД в реальных задачах.
Например экспорт и импорт больших объектов, способы автоматизации генерации DML и т.д.
Сам недавно столкнулся с этим и достаточно долго искал пути решения.
Если найду время, то обязательно расскажу.
Например экспорт и импорт больших объектов, способы автоматизации генерации DML и т.д.
Сам недавно столкнулся с этим и достаточно долго искал пути решения.
Если найду время, то обязательно расскажу.
Спасибо за копипаст.
Пожалуйста. (Takeji aka Kagami)
спасибо.
хотелось бы почитать еще про то, как писать многопоточные приложения с Qt.
хотелось бы почитать еще про то, как писать многопоточные приложения с Qt.
Эта статья убедила меня никогда не использовать Qt для работы с СУБД.
Спасибо.
Спасибо.
Почему же? Мне кажется такие комментарии необходимо как-то аргументировать.
Начнем по порядку.
C++, с его прямым доступом к памяти и ручным же управлением ей не подходит для разработки глобально-надежных пользовательских приложений. (Разумеется, возможно написать надежное приложение на Си++, но это очень сложно: неужели, если у Вас есть возможность использовать другой, более надежный язык, Вы возьмете Си++?)
Несмотря на всю внешнюю причесанность Qt (наверное, и внутреннюю тоже — я туда не заглядывал), костыли прямо прут из всех щелей. Какой-то MOC*, какой-то QtScript, какой-то свой собственный, лисапедный database connectivity. А меня, например, это решение не устраивает, и что теперь, прикручивать/прибивать гвоздями сбоку другую библиотеку?
Qt вообще поражает зацикленностью на себя. Зачем там это все? Qt блины, часом, не готовит?
К тому же, тот же HDBC поддерживает многопоточную обработку, а тут — на тебе, низзя. Нехорошо, товарищи.
PS школота минусов наставила, just as planned.
* языковых средств Си++ не хватает, по всей видимости, для реализации настоящего, тру-метаобъектного протокола. Хотя в том же Лиспе это есть уже 50 лет. Тьюринг-полные шаблоны, ау?
C++, с его прямым доступом к памяти и ручным же управлением ей не подходит для разработки глобально-надежных пользовательских приложений. (Разумеется, возможно написать надежное приложение на Си++, но это очень сложно: неужели, если у Вас есть возможность использовать другой, более надежный язык, Вы возьмете Си++?)
Несмотря на всю внешнюю причесанность Qt (наверное, и внутреннюю тоже — я туда не заглядывал), костыли прямо прут из всех щелей. Какой-то MOC*, какой-то QtScript, какой-то свой собственный, лисапедный database connectivity. А меня, например, это решение не устраивает, и что теперь, прикручивать/прибивать гвоздями сбоку другую библиотеку?
Qt вообще поражает зацикленностью на себя. Зачем там это все? Qt блины, часом, не готовит?
К тому же, тот же HDBC поддерживает многопоточную обработку, а тут — на тебе, низзя. Нехорошо, товарищи.
PS школота минусов наставила, just as planned.
* языковых средств Си++ не хватает, по всей видимости, для реализации настоящего, тру-метаобъектного протокола. Хотя в том же Лиспе это есть уже 50 лет. Тьюринг-полные шаблоны, ау?
Для примерно 2/3 задач (например для написания обычного пользовательского приложения с некоторым количеством математики/многопоточности/чего-нить еще) я предпочту С++.
Чем вас не устраивает МОК?
Что вам не нравится в возможности написать без излишних проблем приложение с возможностью его модернизирования скриптами, без вмешательства в код?
Чем вас не устраивает работа с БД?
Если вас не устраивает такая работа с БД, никто не мешает прилинковать свою либу, забыть про QtSql и спокойно пейсать.
Если вы не помните, то Qt — фреймворк, следовательно он должен включать максимально охватывающий функционал. Например в 4.6 будет стейт машина и либа для простого управления анимацией (Кинетик). Чем это плохо?
Многопоточная обработка возможна если вы хотя бы немножко вникните в суть написания приложений на Куте, то поймете что многопоточная работа с одним подключением к БД делается несложно и в рамках общих стандартов программироваия на Куте.
Чем вас не устраивает МОК?
Что вам не нравится в возможности написать без излишних проблем приложение с возможностью его модернизирования скриптами, без вмешательства в код?
Чем вас не устраивает работа с БД?
Если вас не устраивает такая работа с БД, никто не мешает прилинковать свою либу, забыть про QtSql и спокойно пейсать.
Если вы не помните, то Qt — фреймворк, следовательно он должен включать максимально охватывающий функционал. Например в 4.6 будет стейт машина и либа для простого управления анимацией (Кинетик). Чем это плохо?
Многопоточная обработка возможна если вы хотя бы немножко вникните в суть написания приложений на Куте, то поймете что многопоточная работа с одним подключением к БД делается несложно и в рамках общих стандартов программироваия на Куте.
> Для примерно 2/3 задач (например для написания обычного пользовательского приложения с некоторым количеством математики/многопоточности/чего-нить еще) я предпочту С++.
Это смотря для каких задач. Си++ годится только для performance-critical кода (ладно, вероятно, 10-15 лет назад это было не так). То, что на нем залабали такую нехилую штуку как Qt, называется abuse.
> Чем вас не устраивает МОК?
Usability нулевой. Как-то не хочется вставлять «этот макрос сюды, тот макрос туды, иначе не заработает».
> Что вам не нравится в возможности написать без излишних проблем приложение с возможностью его модернизирования скриптами, без вмешательства в код?
Я бы скорее написал основу приложения на скрипте, нашел bottleneck'и профилировщиком, и медленные функции вынес в Си++. Так оно кошернее.
> Чем вас не устраивает работа с БД?
Слабенькие гарантии дает. Ну это, в принципе, почти у всех так. Слава Б-гу, что хоть в том же .NET осилили LINQ (хотя сама идея стара как мир).
> Если вы не помните, то Qt — фреймворк, следовательно он должен включать максимально охватывающий функционал.
Если он будет готовить мне кофе (во время компиляции исходников), то я, пожалуй, возьму два. :)
> Например в 4.6 будет стейт машина и либа для простого управления анимацией (Кинетик). Чем это плохо?
Это feature creep. Ну хоть кто-нибудь может определить границы применимости этого фреймворка? Какие задачи он решает? Какие не решает? (это не менее важный вопрос)
> Многопоточная обработка возможна если вы хотя бы немножко вникните в суть написания приложений на Куте, то поймете что многопоточная работа с одним подключением к БД делается несложно
А я хочу юзать STM. Это возможно в Qt?
> и в рамках общих стандартов программироваия на Куте.
Опять стандарты, господи…
Это смотря для каких задач. Си++ годится только для performance-critical кода (ладно, вероятно, 10-15 лет назад это было не так). То, что на нем залабали такую нехилую штуку как Qt, называется abuse.
> Чем вас не устраивает МОК?
Usability нулевой. Как-то не хочется вставлять «этот макрос сюды, тот макрос туды, иначе не заработает».
> Что вам не нравится в возможности написать без излишних проблем приложение с возможностью его модернизирования скриптами, без вмешательства в код?
Я бы скорее написал основу приложения на скрипте, нашел bottleneck'и профилировщиком, и медленные функции вынес в Си++. Так оно кошернее.
> Чем вас не устраивает работа с БД?
Слабенькие гарантии дает. Ну это, в принципе, почти у всех так. Слава Б-гу, что хоть в том же .NET осилили LINQ (хотя сама идея стара как мир).
> Если вы не помните, то Qt — фреймворк, следовательно он должен включать максимально охватывающий функционал.
Если он будет готовить мне кофе (во время компиляции исходников), то я, пожалуй, возьму два. :)
> Например в 4.6 будет стейт машина и либа для простого управления анимацией (Кинетик). Чем это плохо?
Это feature creep. Ну хоть кто-нибудь может определить границы применимости этого фреймворка? Какие задачи он решает? Какие не решает? (это не менее важный вопрос)
> Многопоточная обработка возможна если вы хотя бы немножко вникните в суть написания приложений на Куте, то поймете что многопоточная работа с одним подключением к БД делается несложно
А я хочу юзать STM. Это возможно в Qt?
> и в рамках общих стандартов программироваия на Куте.
Опять стандарты, господи…
вам может и годится для критикал кода, а по мне так для всего годится…
«Usability нулевой. Как-то не хочется вставлять «этот макрос сюды, тот макрос туды, иначе не заработает».»
ну эм… как бы сказать… а что должно все везде включено? тогда это будет нехилый оверхед…
«Я бы скорее написал основу приложения на скрипте, нашел bottleneck'и профилировщиком, и медленные функции вынес в Си++. Так оно кошернее.»
Вы видимо не поняли… вот я написал некое ПО… а уже пользователи спокойно могут писать дополнения к нему с помощью QtScript'а… не лезя в исходники самого ПО…
покажите мне фреймворк который варит кофе;) ну или хотя бы воду кипятит;)
«Ну хоть кто-нибудь может определить границы применимости этого фреймворка? Какие задачи он решает? Какие не решает? (это не менее важный вопрос)»
Основная направленность — прикладное кросс-платформенное ПО. Или вам по пунктам подробно? ну тогда сами, ибо это мартышкин труд
«А я хочу юзать STM. Это возможно в Qt?»
Что вы имеете в виду под STM?
«Опять стандарты, господи…»
Вы таки против стандартов? совсем против стандартов?
«Usability нулевой. Как-то не хочется вставлять «этот макрос сюды, тот макрос туды, иначе не заработает».»
ну эм… как бы сказать… а что должно все везде включено? тогда это будет нехилый оверхед…
«Я бы скорее написал основу приложения на скрипте, нашел bottleneck'и профилировщиком, и медленные функции вынес в Си++. Так оно кошернее.»
Вы видимо не поняли… вот я написал некое ПО… а уже пользователи спокойно могут писать дополнения к нему с помощью QtScript'а… не лезя в исходники самого ПО…
покажите мне фреймворк который варит кофе;) ну или хотя бы воду кипятит;)
«Ну хоть кто-нибудь может определить границы применимости этого фреймворка? Какие задачи он решает? Какие не решает? (это не менее важный вопрос)»
Основная направленность — прикладное кросс-платформенное ПО. Или вам по пунктам подробно? ну тогда сами, ибо это мартышкин труд
«А я хочу юзать STM. Это возможно в Qt?»
Что вы имеете в виду под STM?
«Опять стандарты, господи…»
Вы таки против стандартов? совсем против стандартов?
> ну эм… как бы сказать… а что должно все везде включено? тогда это будет нехилый оверхед…
[irony]Какой оверхед, у нас же самый шустрый ЯП в мире!1[/irony] Если честно, то при выборе правильной абстракции от оверхеда можно избавиться, так все нормальные люди делают. Яркий пример: Фортран.
> Вы видимо не поняли… вот я написал некое ПО… а уже пользователи спокойно могут писать дополнения к нему с помощью QtScript'а… не лезя в исходники самого ПО…
А в чем прикол писать приложение на Си++, затем приколачивать скрипт сбоку, если можно сразу взять скрипт? :)
> покажите мне фреймворк который варит кофе;) ну или хотя бы воду кипятит;)
Qt! %)
> Основная направленность — прикладное кросс-платформенное ПО.
Слишком размытая формулировка.
> Что вы имеете в виду под STM?
Software transactional memory же. Читайте «Composable memory transactions» (Tim Harris et al.)
> Вы таки против стандартов? совсем против стандартов?
Да, я против стандартов. Их пишут умалишенные идиоты. Есть, конечно, исключения — это когда один человек все придумывает, а не комитет (вот такие стандарты нужны, но их мало).
[irony]Какой оверхед, у нас же самый шустрый ЯП в мире!1[/irony] Если честно, то при выборе правильной абстракции от оверхеда можно избавиться, так все нормальные люди делают. Яркий пример: Фортран.
> Вы видимо не поняли… вот я написал некое ПО… а уже пользователи спокойно могут писать дополнения к нему с помощью QtScript'а… не лезя в исходники самого ПО…
А в чем прикол писать приложение на Си++, затем приколачивать скрипт сбоку, если можно сразу взять скрипт? :)
> покажите мне фреймворк который варит кофе;) ну или хотя бы воду кипятит;)
Qt! %)
> Основная направленность — прикладное кросс-платформенное ПО.
Слишком размытая формулировка.
> Что вы имеете в виду под STM?
Software transactional memory же. Читайте «Composable memory transactions» (Tim Harris et al.)
> Вы таки против стандартов? совсем против стандартов?
Да, я против стандартов. Их пишут умалишенные идиоты. Есть, конечно, исключения — это когда один человек все придумывает, а не комитет (вот такие стандарты нужны, но их мало).
«Если честно, то при выборе правильной абстракции от оверхеда можно избавиться, так все нормальные люди делают.»
Ну приведите пример чтоле.
«А в чем прикол писать приложение на Си++, затем приколачивать скрипт сбоку, если можно сразу взять скрипт? :)»
вы читаете через слово или как? основной тезис — модульность… какая к чертям собачьим разница компилируемый язык или интерпретируемый у изначальной проги? КутеСкрипт облегчает реализацию функционала модульности.
«Слишком размытая формулировка.»
Какой вопрос такой и ответ. Какая направленность у того же дотНета? каких-то конкретных фраз тут не напишешь, только в общем виде.
«Software transactional memory же.»
Судя по википедии есть немало сишных либ… кто мешает их прилинковать и использовать? или же вы хотите чтобы при этом были бнз каких-то проблем доступны все вкусности Куте? ну тогда Куте не для вас… как собственно и любой другой фреймворк…
«Да, я против стандартов. Их пишут умалишенные идиоты. Есть, конечно, исключения — это когда один человек все придумывает, а не комитет (вот такие стандарты нужны, но их мало).»
То есть когда один человек пишет стандарт то это зашибись, а когда он проходит несколько стадий проверок неким количеством людей то это отстой? я не вижу логики
Ну приведите пример чтоле.
«А в чем прикол писать приложение на Си++, затем приколачивать скрипт сбоку, если можно сразу взять скрипт? :)»
вы читаете через слово или как? основной тезис — модульность… какая к чертям собачьим разница компилируемый язык или интерпретируемый у изначальной проги? КутеСкрипт облегчает реализацию функционала модульности.
«Слишком размытая формулировка.»
Какой вопрос такой и ответ. Какая направленность у того же дотНета? каких-то конкретных фраз тут не напишешь, только в общем виде.
«Software transactional memory же.»
Судя по википедии есть немало сишных либ… кто мешает их прилинковать и использовать? или же вы хотите чтобы при этом были бнз каких-то проблем доступны все вкусности Куте? ну тогда Куте не для вас… как собственно и любой другой фреймворк…
«Да, я против стандартов. Их пишут умалишенные идиоты. Есть, конечно, исключения — это когда один человек все придумывает, а не комитет (вот такие стандарты нужны, но их мало).»
То есть когда один человек пишет стандарт то это зашибись, а когда он проходит несколько стадий проверок неким количеством людей то это отстой? я не вижу логики
>> Если честно, то при выборе правильной абстракции от оверхеда можно избавиться, так все нормальные люди делают.
> Ну приведите пример чтоле.
Fortran. Уже первый его компилятор генерировал код, сопоставимый по качеству ассемблеру (написанному вручную). Таких примеров вагон и тележка, токо вот зашоренные Цппшники их в упор не замечают.
>основной тезис — модульность… какая к чертям собачьим разница компилируемый язык или интерпретируемый у изначальной проги?
В принципе, без разницы, но известно, что динамическая типизация способствует loose coupling. Подгрузка кода в райнтайме у статически типизированных языков обычно плачевная (бывают и исключения: советую посмотреть hs-plugins, dynamics у Clean, AliceML).
> Какой вопрос такой и ответ. Какая направленность у того же дотНета? каких-то конкретных фраз тут не напишешь, только в общем виде.
У .NET'а нет направленности, он не решает каких-то проблем, только создает новые. Это маркетоидная муть.
> Судя по википедии есть немало сишных либ… кто мешает их прилинковать и использовать?
Они не дают важных гарантий.
> или же вы хотите чтобы при этом были бнз каких-то проблем доступны все вкусности Куте?
Да.
> ну тогда Куте не для вас… как собственно и любой другой фреймворк…
Это неправильно, не находите? :)
> То есть когда один человек пишет стандарт то это зашибись, а когда он проходит несколько стадий проверок неким количеством людей то это отстой?
Да, так оно и есть. Здесь на хабре simonsays писал как раз об этом явлении.
> я не вижу логики
Принимать решения должен один человек. Да, он может посоветоваться с другими, но окончательное решение все равно принимает он и только он.
> Ну приведите пример чтоле.
Fortran. Уже первый его компилятор генерировал код, сопоставимый по качеству ассемблеру (написанному вручную). Таких примеров вагон и тележка, токо вот зашоренные Цппшники их в упор не замечают.
>основной тезис — модульность… какая к чертям собачьим разница компилируемый язык или интерпретируемый у изначальной проги?
В принципе, без разницы, но известно, что динамическая типизация способствует loose coupling. Подгрузка кода в райнтайме у статически типизированных языков обычно плачевная (бывают и исключения: советую посмотреть hs-plugins, dynamics у Clean, AliceML).
> Какой вопрос такой и ответ. Какая направленность у того же дотНета? каких-то конкретных фраз тут не напишешь, только в общем виде.
У .NET'а нет направленности, он не решает каких-то проблем, только создает новые. Это маркетоидная муть.
> Судя по википедии есть немало сишных либ… кто мешает их прилинковать и использовать?
Они не дают важных гарантий.
> или же вы хотите чтобы при этом были бнз каких-то проблем доступны все вкусности Куте?
Да.
> ну тогда Куте не для вас… как собственно и любой другой фреймворк…
Это неправильно, не находите? :)
> То есть когда один человек пишет стандарт то это зашибись, а когда он проходит несколько стадий проверок неким количеством людей то это отстой?
Да, так оно и есть. Здесь на хабре simonsays писал как раз об этом явлении.
> я не вижу логики
Принимать решения должен один человек. Да, он может посоветоваться с другими, но окончательное решение все равно принимает он и только он.
Ну а текущие компиляторы сей генерят код, лучше которого фиг напишешь на асме (только если действительно очень хорошо рубишь в асме). И чо?
«Подгрузка кода в райнтайме у статически типизированных языков обычно плачевная „
Причем здесь подгрузка кода? QtScript не подгружается а интерпретируется…
“Это неправильно, не находите? :)»
Нет не нахожу… точно также как не нахожу что линукс должен подходить даже для домохозяйки… у каждого продукта есть своя аудитория и если ее пытаться расширить, то будет кака…
«Принимать решения должен один человек. Да, он может посоветоваться с другими, но окончательное решение все равно принимает он и только он.»
Обычно в комиссиях по стандартам есть некое лицо, которое является главным и по сути принимает решение именно он, остальные являются помощниками
«Подгрузка кода в райнтайме у статически типизированных языков обычно плачевная „
Причем здесь подгрузка кода? QtScript не подгружается а интерпретируется…
“Это неправильно, не находите? :)»
Нет не нахожу… точно также как не нахожу что линукс должен подходить даже для домохозяйки… у каждого продукта есть своя аудитория и если ее пытаться расширить, то будет кака…
«Принимать решения должен один человек. Да, он может посоветоваться с другими, но окончательное решение все равно принимает он и только он.»
Обычно в комиссиях по стандартам есть некое лицо, которое является главным и по сути принимает решение именно он, остальные являются помощниками
> Ну а текущие компиляторы сей генерят код, лучше которого фиг напишешь на асме (только если действительно очень хорошо рубишь в асме).
FUD. Быстренько бежим сравнивать скорость исполнения какого-нибудь DSL vs C. Hints: CDuce vs ???, SISAL vs ???, etc. В прынцыпе, тот же Лисп вполне может обогнать Си на символьных вычислениях, скажем.
> Причем здесь подгрузка кода? QtScript не подгружается а интерпретируется…
Вопрос: как обеспечить расширяемость программы? Ответ: дать возможность загружать новый код во время выполнения программы. Какая разница, интерпретируется ли этот код потом в VM или на железе? :)
> Нет не нахожу… точно также как не нахожу что линукс должен подходить даже для домохозяйки… у каждого продукта есть своя аудитория и если ее пытаться расширить, то будет кака…
Продолжая мысль, понимаем, что Куте токо для зашоренных Цппшников. Ну явный же бред.
> Обычно в комиссиях по стандартам есть некое лицо, которое является главным и по сути принимает решение именно он, остальные являются помощниками
Значит там действительно умалишенные идиоты сидят. Фейлов от W3C уже достаточно. Чего стоит тот же DOM. ;)
FUD. Быстренько бежим сравнивать скорость исполнения какого-нибудь DSL vs C. Hints: CDuce vs ???, SISAL vs ???, etc. В прынцыпе, тот же Лисп вполне может обогнать Си на символьных вычислениях, скажем.
> Причем здесь подгрузка кода? QtScript не подгружается а интерпретируется…
Вопрос: как обеспечить расширяемость программы? Ответ: дать возможность загружать новый код во время выполнения программы. Какая разница, интерпретируется ли этот код потом в VM или на железе? :)
> Нет не нахожу… точно также как не нахожу что линукс должен подходить даже для домохозяйки… у каждого продукта есть своя аудитория и если ее пытаться расширить, то будет кака…
Продолжая мысль, понимаем, что Куте токо для зашоренных Цппшников. Ну явный же бред.
> Обычно в комиссиях по стандартам есть некое лицо, которое является главным и по сути принимает решение именно он, остальные являются помощниками
Значит там действительно умалишенные идиоты сидят. Фейлов от W3C уже достаточно. Чего стоит тот же DOM. ;)
про компилер я ответил на ваше непонятное заявление о фортране…
«Вопрос: как обеспечить расширяемость программы? Ответ: дать возможность загружать новый код во время выполнения программы. Какая разница, интерпретируется ли этот код потом в VM или на железе? :)»
большая… если мы делаем ПО на том же руби без поддержки неокторого скриптового языка для модулей, то единственная возможность расширить функционал это переписывание исходников… следовательно совместить мое расширение и расширение дяди Пети будет ой как не просто…
если мы делаем ПО без разницы на чем, но с поддержкой скриптового языка для модулей, то мы просто подгружаем мой модуль и модуль дяди Пети и все зашибись…
«Продолжая мысль, понимаем, что Куте токо для зашоренных Цппшников. Ну явный же бред.»
Нет. Куте для тех, кто понимает зачем ему оно нужно… все остальные могут идти лесом…
«Значит там действительно умалишенные идиоты сидят. Фейлов от W3C уже достаточно. Чего стоит тот же DOM. ;) „
Чем вам ДОМ не угодил я не понимаю… вполне себе нормальная модель
«Вопрос: как обеспечить расширяемость программы? Ответ: дать возможность загружать новый код во время выполнения программы. Какая разница, интерпретируется ли этот код потом в VM или на железе? :)»
большая… если мы делаем ПО на том же руби без поддержки неокторого скриптового языка для модулей, то единственная возможность расширить функционал это переписывание исходников… следовательно совместить мое расширение и расширение дяди Пети будет ой как не просто…
если мы делаем ПО без разницы на чем, но с поддержкой скриптового языка для модулей, то мы просто подгружаем мой модуль и модуль дяди Пети и все зашибись…
«Продолжая мысль, понимаем, что Куте токо для зашоренных Цппшников. Ну явный же бред.»
Нет. Куте для тех, кто понимает зачем ему оно нужно… все остальные могут идти лесом…
«Значит там действительно умалишенные идиоты сидят. Фейлов от W3C уже достаточно. Чего стоит тот же DOM. ;) „
Чем вам ДОМ не угодил я не понимаю… вполне себе нормальная модель
> большая… если мы делаем ПО на том же руби без поддержки неокторого скриптового языка для модулей, то единственная возможность расширить функционал это переписывание исходников…
На руби вполне можно eval'ить код. Попробуйте, может, понравится. :) (Неужели написание и расширение программы на одном языке не укладывается в голову?)
> Нет. Куте для тех, кто понимает зачем ему оно нужно… все остальные могут идти лесом…
Ыыыы. :)
> Чем вам ДОМ не угодил я не понимаю… вполне себе нормальная модель
Если бы DOM был и вправду хорош, его бы так часто не оборачивали. И дело тут не только в кроссбраузерности, но и в абсолютной неюзабельности DOM.
Вот реально, неужели Вам нравится, например, обходить дерево документа средствами DOM? :)
На руби вполне можно eval'ить код. Попробуйте, может, понравится. :) (Неужели написание и расширение программы на одном языке не укладывается в голову?)
> Нет. Куте для тех, кто понимает зачем ему оно нужно… все остальные могут идти лесом…
Ыыыы. :)
> Чем вам ДОМ не угодил я не понимаю… вполне себе нормальная модель
Если бы DOM был и вправду хорош, его бы так часто не оборачивали. И дело тут не только в кроссбраузерности, но и в абсолютной неюзабельности DOM.
Вот реально, неужели Вам нравится, например, обходить дерево документа средствами DOM? :)
«На руби вполне можно eval'ить код. Попробуйте, может, понравится. :) (Неужели написание и расширение программы на одном языке не укладывается в голову?)»
ага и тут мы начисто забываем о безопасности… аффигеть
«Вот реально, неужели Вам нравится, например, обходить дерево документа средствами DOM? :) „
меня вполне устраивает ДОМ-модель
ага и тут мы начисто забываем о безопасности… аффигеть
«Вот реально, неужели Вам нравится, например, обходить дерево документа средствами DOM? :) „
меня вполне устраивает ДОМ-модель
> ага и тут мы начисто забываем о безопасности… аффигеть
Безопасность тут вопрос касательный. Вполне можно обеспечить sandbox для кода. Кстати, в случае со связкой Цпп + скрипт безопасность это такая же точно проблема.
> меня вполне устраивает ДОМ-модель
Это ни в коем случае не отменяет ее кривизны. :)
Безопасность тут вопрос касательный. Вполне можно обеспечить sandbox для кода. Кстати, в случае со связкой Цпп + скрипт безопасность это такая же точно проблема.
> меня вполне устраивает ДОМ-модель
Это ни в коем случае не отменяет ее кривизны. :)
в случае QtScript'а программист сам решает что скрипт сможет а что нет…
а сендбокс ведь надо еще делать… а тут все уже готовое… где же ваш хваленый код реюз?;)
а сендбокс ведь надо еще делать… а тут все уже готовое… где же ваш хваленый код реюз?;)
> а сендбокс ведь надо еще делать… а тут все уже готовое… где же ваш хваленый код реюз?;)
Это Вы привели в пример Ruby. Сами с ним теперь разбирайтесь. :)
ЗЫ слив засчитан.
Это Вы привели в пример Ruby. Сами с ним теперь разбирайтесь. :)
ЗЫ слив засчитан.
ок, а где не надо делать сендбокс и при этом легко сделать модульность?
слив незасчитан, потому что вы конкретного ничего не сказали… все ваши высказывания сводятся к:
1. куте отстой
2. цпп отстой
3. скриптовые языки рулят
но ничего более конкретного нету
слив незасчитан, потому что вы конкретного ничего не сказали… все ваши высказывания сводятся к:
1. куте отстой
2. цпп отстой
3. скриптовые языки рулят
но ничего более конкретного нету
> ок, а где не надо делать сендбокс и при этом легко сделать модульность?
Те же D, Haskell.
> 1. куте отстой
Qt это пример неправильного выбора языка и у него есть свои минусы. То, что Qt отстой я нигде не говорил.
> 2. цпп отстой
Увы, да. Точнее будет сказать, что Цпп плохо справляется и с низкоуровневыми, и с высокоуровневыми задачами. В первом случае сливает Си и Форту, во втором сливает скриптовым и некоторым компилируемым ЯП.
> 3. скриптовые языки рулят
Где я такое говорил?
> но ничего более конкретного нету
Учитесь мыслить абстрактно. Это тяжело, я знаю.
Кстати, а Вы ждали, что я начну кидаться кусками кода? :)
Те же D, Haskell.
> 1. куте отстой
Qt это пример неправильного выбора языка и у него есть свои минусы. То, что Qt отстой я нигде не говорил.
> 2. цпп отстой
Увы, да. Точнее будет сказать, что Цпп плохо справляется и с низкоуровневыми, и с высокоуровневыми задачами. В первом случае сливает Си и Форту, во втором сливает скриптовым и некоторым компилируемым ЯП.
> 3. скриптовые языки рулят
Где я такое говорил?
> но ничего более конкретного нету
Учитесь мыслить абстрактно. Это тяжело, я знаю.
Кстати, а Вы ждали, что я начну кидаться кусками кода? :)
Немного конкретики по sandbox'ам.
У D есть SafeD, в Haskell никто не мешает сконструировать свой собственный, ограниченный вариант IO-монады.
У D есть SafeD, в Haskell никто не мешает сконструировать свой собственный, ограниченный вариант IO-монады.
мда, я забыл сказать что языки хотелось бы услышать уж если не мейнстрим, то широко-распространенные…
«Qt это пример неправильного выбора языка и у него есть свои минусы. То, что Qt отстой я нигде не говорил.»
куте есть не только на цпп
«Увы, да. Точнее будет сказать, что Цпп плохо справляется и с низкоуровневыми, и с высокоуровневыми задачами. В первом случае сливает Си и Форту, во втором сливает скриптовым и некоторым компилируемым ЯП.»
это ваше имхо? если да, то не стоит его говорить как божье откровение
если нет, то аргментируйте
«Учитесь мыслить абстрактно. Это тяжело, я знаю.»
вы просили от меня конкретики, я вам ее дал… почему же вы не можете дать конкретику?
«Qt это пример неправильного выбора языка и у него есть свои минусы. То, что Qt отстой я нигде не говорил.»
куте есть не только на цпп
«Увы, да. Точнее будет сказать, что Цпп плохо справляется и с низкоуровневыми, и с высокоуровневыми задачами. В первом случае сливает Си и Форту, во втором сливает скриптовым и некоторым компилируемым ЯП.»
это ваше имхо? если да, то не стоит его говорить как божье откровение
если нет, то аргментируйте
«Учитесь мыслить абстрактно. Это тяжело, я знаю.»
вы просили от меня конкретики, я вам ее дал… почему же вы не можете дать конкретику?
> куте есть не только на цпп
Qt реализован на Си++, биндинги есть и на другие ЯП, да.
> это ваше имхо? если да, то не стоит его говорить как божье откровение. если нет, то аргментируйте
Поизучайте другие языки, и Вам это тоже станет ясно. Пока Вы сами не поймете этого, никто Вам это объяснить не сможет. Синдром Блаба называется (http://www.paulgraham.com/avg.html).
Qt реализован на Си++, биндинги есть и на другие ЯП, да.
> это ваше имхо? если да, то не стоит его говорить как божье откровение. если нет, то аргментируйте
Поизучайте другие языки, и Вам это тоже станет ясно. Пока Вы сами не поймете этого, никто Вам это объяснить не сможет. Синдром Блаба называется (http://www.paulgraham.com/avg.html).
ну скажем так… мне хватает тех языков что я знаю… и сталкивался я не только с императивными языками…
и знаете что мне еще не понятно…
а зачем вы пришли в статью о том как что-то делается в некоем фреймворке написанном на так нелюбимом и неприменяемом вами языке, чтобы покричать какое тут все отстой и что декларативка рулит? ну тогда советую для этого завести отдельную тему…
и знаете что мне еще не понятно…
а зачем вы пришли в статью о том как что-то делается в некоем фреймворке написанном на так нелюбимом и неприменяемом вами языке, чтобы покричать какое тут все отстой и что декларативка рулит? ну тогда советую для этого завести отдельную тему…
Давайте еще на личности перейдем.
> и знаете что мне еще не понятно… а зачем вы пришли в статью о том как что-то делается в некоем фреймворке написанном на так нелюбимом и неприменяемом вами языке, чтобы покричать какое тут все отстой и что декларативка рулит?
Спасать утопающих. Иногда хочется для людей полезное что-нить сделать. Рассказать, что не С++ом единым, etc.
А в этой статье много «как» и мало «что». А вот это самое «что» должно быть в первую очередь.
PS сим удостоверяю, что все мои посты — это ИМХО. :)
> и знаете что мне еще не понятно… а зачем вы пришли в статью о том как что-то делается в некоем фреймворке написанном на так нелюбимом и неприменяемом вами языке, чтобы покричать какое тут все отстой и что декларативка рулит?
Спасать утопающих. Иногда хочется для людей полезное что-нить сделать. Рассказать, что не С++ом единым, etc.
А в этой статье много «как» и мало «что». А вот это самое «что» должно быть в первую очередь.
PS сим удостоверяю, что все мои посты — это ИМХО. :)
PS ололо, школота опять минусует!1
Кстати про многопоточность, в том же 4.6 будет официально включен QtConcurrent — более простой реализации многопоточности я ещё не видел.
MOC — это всего лишь прероцессор и ничего более. На выходе из него получаем всё тот же C++ код, который потом передаётся компилятору. Создан он исключительно для удобства.
Кстати у Qt одна из лучших систем документации, причем не только из C++ проектов.
А прикручивать что-то стороннее здесь не сложнее чем в любой другой C++ библиотеки, да и вообще в любом другом ЯП.
P.S. а по поводу «школоты» вы совсем погорячились.
MOC — это всего лишь прероцессор и ничего более. На выходе из него получаем всё тот же C++ код, который потом передаётся компилятору. Создан он исключительно для удобства.
Кстати у Qt одна из лучших систем документации, причем не только из C++ проектов.
А прикручивать что-то стороннее здесь не сложнее чем в любой другой C++ библиотеки, да и вообще в любом другом ЯП.
P.S. а по поводу «школоты» вы совсем погорячились.
Конкуррент уже в 4.4 как бе есть
и еще по поводу конкуррента… он удобен только для распараллеливания мат. алгоритмов или каких-то шаблонных задач… а например для действительно мнгопоточного приложения (где каждый поток является достаточно серьезным и самодостаточным), либо для приложения с фабрикой потоков все таки лучше остаться на QThread
Полностью с вами согласен. По поводу версии оговорился.
QtConcurrent это подобие MapReduce, годится не для всех алгоритмов.
QtThread это платформонезависимая обертка над системными потоками. (Сужу по документации.) Таких оберток целая куча, зачем в Qt изобрели еще одну, мне непонятно.
> MOC — это всего лишь прероцессор и ничего более. На выходе из него получаем всё тот же C++ код, который потом передаётся компилятору. Создан он исключительно для удобства.
Я надеюсь, это хотя бы не макроподстановщик Си? :)
> Кстати у Qt одна из лучших систем документации, причем не только из C++ проектов.
Да, заметил. Нет, правда, мне нравится. :)
> а по поводу «школоты» вы совсем погорячились.
Ну прям. Это же очевидный факт: большей частью Хабранаселения являются школьники.
QtThread это платформонезависимая обертка над системными потоками. (Сужу по документации.) Таких оберток целая куча, зачем в Qt изобрели еще одну, мне непонятно.
> MOC — это всего лишь прероцессор и ничего более. На выходе из него получаем всё тот же C++ код, который потом передаётся компилятору. Создан он исключительно для удобства.
Я надеюсь, это хотя бы не макроподстановщик Си? :)
> Кстати у Qt одна из лучших систем документации, причем не только из C++ проектов.
Да, заметил. Нет, правда, мне нравится. :)
> а по поводу «школоты» вы совсем погорячились.
Ну прям. Это же очевидный факт: большей частью Хабранаселения являются школьники.
«QtThread это платформонезависимая обертка над системными потоками. (Сужу по документации.) Таких оберток целая куча, зачем в Qt изобрели еще одну, мне непонятно.»
А зачем в каждом фреймворке есть своя либа для многопоточности? очевидно для лучшей совместимости и интеграции
А зачем в каждом фреймворке есть своя либа для многопоточности? очевидно для лучшей совместимости и интеграции
> А зачем в каждом фреймворке есть своя либа для многопоточности? очевидно для лучшей совместимости и интеграции
[trolling]Интеграции с кем? С самим фреймворком? Ну это же на грани. Авторы сами с собой договориться не могут?[/trolling]
Еще раз повторяю: code reuse это не пустой звук. Как жаль, что до программистов на мейнстримовых языках это еще не дошло.
[trolling]Интеграции с кем? С самим фреймворком? Ну это же на грани. Авторы сами с собой договориться не могут?[/trolling]
Еще раз повторяю: code reuse это не пустой звук. Как жаль, что до программистов на мейнстримовых языках это еще не дошло.
ну на троллинг я отвечать не буду;) ибо троллинг;)
«Еще раз повторяю: code reuse это не пустой звук. Как жаль, что до программистов на мейнстримовых языках это еще не дошло.»
А никто и не говорит что это пустой звук… просто излишний код реюз и хватание того что уже кем-то реализовано без оглядки на всю систему это извините бред
«Еще раз повторяю: code reuse это не пустой звук. Как жаль, что до программистов на мейнстримовых языках это еще не дошло.»
А никто и не говорит что это пустой звук… просто излишний код реюз и хватание того что уже кем-то реализовано без оглядки на всю систему это извините бред
> просто излишний код реюз и хватание того что уже кем-то реализовано без оглядки на всю систему это извините бред
Ну а NIH, это, извините, щастие?
Кстати, если уж «бред», то огласите весь список причин не использовать хорошо отлаженный, работающий как часы чужой код.
Ну а NIH, это, извините, щастие?
Кстати, если уж «бред», то огласите весь список причин не использовать хорошо отлаженный, работающий как часы чужой код.
причина одна… то что он чужой, следовательно его нужно либо пилить под себя, либо пилить свою систему под него
Да, конечно, текущее положение вещей в мейнстримов языках таково.
С другой стороны, это неправильно. Я надеюсь, что натолкнул Вас на мысль, что код нужно писать так, чтобы его легко можно было комбинировать с другим кодом.
С другой стороны, это неправильно. Я надеюсь, что натолкнул Вас на мысль, что код нужно писать так, чтобы его легко можно было комбинировать с другим кодом.
Отличная и очень полезная статья!
Без вопросов в избранное и на выходных пробовать, пробовать, пробовать.
Без вопросов в избранное и на выходных пробовать, пробовать, пробовать.
Здравствуйте, Уважаемые хабралюди и знатоки Qt.
Не так давно начал изучение Qt.
Всё очень нравится, но!
Работа с базами реализована хорошо, но возникла проблема при работе с QOCI.
QSqlTableModel никак не хочет работать, хоть что хочешь делай! Пишет что ошибок нет, а результат пустой.
QSqlQueryModel — превосходно работает, т.е. сиквел выполняется, но хотелось использовать QSqlTableModel, со всеми его вкусностями.
Подскажите куда копать…
P.S. Сервер Oracle 9i, Qt 4.4.3 qt-win-commercial-vs2008
Не так давно начал изучение Qt.
Всё очень нравится, но!
Работа с базами реализована хорошо, но возникла проблема при работе с QOCI.
QSqlTableModel никак не хочет работать, хоть что хочешь делай! Пишет что ошибок нет, а результат пустой.
QSqlQueryModel — превосходно работает, т.е. сиквел выполняется, но хотелось использовать QSqlTableModel, со всеми его вкусностями.
Подскажите куда копать…
P.S. Сервер Oracle 9i, Qt 4.4.3 qt-win-commercial-vs2008
Так сказать очень сложно, надо на исходники взглянуть. Могу лишь посоветовать начать писать небольшую программу с QSqlTableModel с нуля, постепенно ее усложняя. Это лучший способ разобраться
Спасибо за совет.
Разобрался. Оказалось, что когда использую тригеры, то не работает, убрал тригер, всё заработало.
Вот тригер, может дело в нём?
create or replace trigger district_type_bi before insert on district_type referencing new as new old as old for each row
begin
if :new.id is null then select seq_district_type.nextval into :new.id from dual; end if;
:new.log:=new log_type(user,sysdate);
end;
/
Разобрался. Оказалось, что когда использую тригеры, то не работает, убрал тригер, всё заработало.
Вот тригер, может дело в нём?
create or replace trigger district_type_bi before insert on district_type referencing new as new old as old for each row
begin
if :new.id is null then select seq_district_type.nextval into :new.id from dual; end if;
:new.log:=new log_type(user,sysdate);
end;
/
Просмотрел кучу сайтов, никто так и не написал про инклуды
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с базами данных в Qt