Переходничок

[SABROG]

Вот-вот, для чего там Qt?

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

Поэтому, когда люди используют тот же boost::shared_ptr в своем коде для Qt, вместо QSharedPointer это вызывает смешанные эмоции. С одной стороны вопрос "нафига, если всё есть в одном месте?", а с другой "отвязаться от конкретной  библиотеки - правильно".

Для чего мне тянуть с собой QtCore + QtXml, если мне нужна маленькая консольная утилитка простого парсинга xml? Я возьму малюсеньку библиотечку tinyxml.

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

извините, в половине случаев у меня не хватало настойчивости для таких утилит выкачать из сети все что им требуется по всем их зависимостям...  
Я не хочу создавать такой софт))) я хочу в 3 шага. скачал (1 дистрибутив) - распаковал - собрал.

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

Это не ко мне, это к ТС.

Судя по другим постам автора, этот - очередной пост, где Qt - нежелательный гость.

[BRE]

Потому что гуй - на QT, ядро - зависит от turbovision, в качестве скриптового языка - мы тянем питон (за каким-то популярным фигом, причем не последнюю версию, а за конкретным номером, потому что не совсем совместимы)...

Ядро должно зависеть только от тех библиотек, которые ему нужны. Также как и GUI.
А насколько быстро ты сможешь переделать свою программу и сколько кода придется переписать, если вдруг условия изменяться и нужно будет отказаться от Qt? 100%?

Я не хочу создавать такой софт))) я хочу в 3 шага. скачал (1 дистрибутив) - распаковал - собрал.

Вот и объясни зачем мне загружать Qt, его собирать, что бы запустить небольшой парсер xml-файлов. 
И это при том, что из всей Qt будет использоваться 0,001% ее возможностей.

[m_ax]

Как узнать имея итератор, что указатель на объект занулён?

 

[Denjs]

Цитата: Denjs от Сегодня в 12:35

Потому что гуй - на QT, ядро - зависит от turbovision, в качестве скриптового языка - мы тянем питон (за каким-то популярным фигом, причем не последнюю версию, а за конкретным номером, потому что не совсем совместимы)...

Ядро должно зависеть только от тех библиотек, которые ему нужны. Также как и GUI.

Все зависит от тех библиотек которые ему нужны. Но сумма зависимостей всей системы - часто удручает. Слишком разношЁрстно и генетически трудно совместимо.

А насколько быстро ты сможешь переделать свою программу и сколько кода придется переписать, если вдруг условия изменяться и нужно будет отказаться от Qt? 100%?

А на сколько быстро вы сможете привести в единый строй ваш зоопарк ву стиле (QT+ncurces+pyton+...)

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

Вот и объясни зачем мне загружать Qt, его собирать, что бы запустить небольшой парсер xml-файлов.  
И это при том, что из всей Qt будет использоваться 0,001% ее возможностей.

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

Все должно быть обосновано). Иногда надо потерять в меньшем, что бы выиграть в большем. только и всего. У каждого решения есть плюсы.

[BRE]

Все должно быть обосновано). Иногда надо потерять в меньшем, что бы выиграть в большем. только и всего. У каждого решения есть плюсы.

Золотые слова. 

[SABROG]

А насколько быстро ты сможешь переделать свою программу и сколько кода придется переписать, если вдруг условия изменяться и нужно будет отказаться от Qt? 100%?

С учетом того, что в стандартном языке C++ пока нет возможностей для работы с XML,SQL,Сетью и т.д., то этот вопрос будет стоять всегда в том числе и для BOOST'a. Ждем стандарт C++0x. Там хотя бы гарантируют то, что контейнеры станут потоко-безопасными?

Вот и объясни зачем мне загружать Qt, его собирать, что бы запустить небольшой парсер xml-файлов. 
И это при том, что из всей Qt будет использоваться 0,001% ее возможностей.

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

[BRE]

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

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

[BRE]

С учетом того, что в стандартном языке C++ пока нет возможностей для работы с XML,SQL,Сетью и т.д., то этот вопрос будет стоять всегда в том числе и для BOOST'a.

А зачем изначально создавать решения (код) привязанные к какой-то конкретной библиотеке, если можно просто использовать STL?
К тому же этот код можно будет использовать повторно в любом другом проекте.

[SABROG]

А зачем изначально создавать решения (код) привязанные к какой-то конкретной библиотеке, если можно просто использовать STL?
К тому же этот код можно будет использовать повторно в любом другом проекте.

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

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

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

[Igors]

Ну вот, стоило отлучиться и уже тему зафлудили    

По поводу уместно/неуместно: раздел называется "кладовая готовых решений" (а совсем не "кладовая Qt решений"). Так что пока модераторы не перерешают - к месту. Более того, я вчера предлагал обсудить с точки зрения слот/сигнал, не моя вина что желающих не нашлось.

Возвращаясь к теме: мне кажется что паттерн обсервер здесь не подходит. Он предполагает что именно обсервер принимает решение, для этого ему и дается ссылка на объект (full control). Здесь же ситуевина  другая: расчетная часть все решила, сформировала данные, от индикатора требуется их отобразить и проверить cancel. Какой же из него обсервер? Понятно что "уговорить" можно, но ведь получается длинно и мутно:

- метод index() сделали (хотя куда удобнее подавать его как параметр а не заводить член класса), ладно. А где текст который должен отображаться? Еще один член класса, еще один метод-аксессор. И где проверка на cancel?

- многие методы расчетных классов константы. Из-за того что теперь меняется m_index, надо как-то извращаться с const_cast или volatile. Не хотелось бы

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

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

[BRE]

А на сколько быстро вы сможете привести в единый строй ваш зоопарк ву стиле (QT+ncurces+pyton+...)

Что считать зоопарком?
Для примера возьмем примитивный аудиоплеер.
Его ядро зависит от boost + mpg321. Собран он может быть как консольная программа (может запускаться вообще без GUI) или как библиотека. Клиенты получают готовый интерфейс для его управления.
Есть "морды" (клиенты) для этого плеера, их можно написать 100 разных от текстовых до графических. На чем они будут писаться не важно, хочешь на Qt, хочешь MFC.
Их взаимодействие описывается каким то протоколом.

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

Да почему она маленькая?  Она очень большая, просто не зависит от Qt.
В чем трудность интеграции? При проектировании системы сразу разрабатывается интерфейс взаимодействия ее участников. Придерживайся его.

[BRE]

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

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

[Igors]

А что считать задачей? Только вывести индикатор о выполнении?

Да. "Этажерку" - по желанию

Тогда еще раз вопрос, а что делать если понадобиться сделать еще что нибудь?

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

Разумеется, это мое личное мнение которое я никому не навязываю

[BRE]

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

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

Если нужно только выводить индикатор о выполнении, то наверно решение с Observer избыточно.

А как ты пробовал использовать сигналы и что тебя не устроило?

[Igors]

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

По жизни получается наоборот. Прекрасно понимаю что "повторить" = западло, но получается намного дешевле

Если нужно только выводить индикатор о выполнении, то наверно решение с Observer избыточно.

Та отож 

А как ты пробовал использовать сигналы и что тебя не устроило?

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

P.S.  а здОрово Вы закрутили с подачей ф-ции-члена в template! Почти интерпретатор
Сейчас надо бежать, увидимся завтра