Russian Qt Forum

Добрый день

Хочу поддержать хорошую инициативу. Класс выглядит несколько странным, но без таких маленьких классов проект не живет нормально, все "слипается" в кучу. Обратите внимание что он не тащит ни одного #include. Ну const char * не есть аккуратно, по уму здесь надо template. Но не суть

C++ (Qt)
#ifndef MESHPROGRESS_H
#define MESHPROGRESS_H
 
struct CMeshProgress {
	CMeshProgress				( void );
	virtual ~CMeshProgress                  ( void );
 
	virtual bool _Update			( long cur );
	virtual void _SetIndicator	        ( const char * text, long maxNum );
 
	static bool Update			( long cur, long step );
	static void SetIndicator		( const char * text, long maxNum );
 
// data members
	static CMeshProgress * mInstance;
};
 
inline CMeshProgress::CMeshProgress( void )
{
	mInstance = this;
}
 
inline CMeshProgress::~CMeshProgress( void )	 
{ 
	mInstance = 0; 
}
 
inline bool CMeshProgress::_Update( long cur ) 
{ 
	return true; 
}
 
inline void CMeshProgress::_SetIndicator( const char *, long ) 
{
}
 
inline bool CMeshProgress::Update( long cur, long step )
{
	if (((cur + 1) % step) != 0) return true;
	return mInstance ? mInstance->_Update(cur) : true;
}
 
inline void CMeshProgress::SetIndicator( const char * text, long maxNum )
{
	if (mInstance)
		mInstance->_SetIndicator(text, maxNum);
}
#endif // MESHPROGRESS_H
 

Edit (2 дня спустя): по просьбе модератора добавляю описание.

Как известно, проект делится на части/модули. Одна из главных задач сделать модули как можно более независимыми друг от друга. Одно из самых простых требований: не раскидывать UI везде, не позволять UI проникать в расчетные части. Иначе когда появится очередной портинг (или потребуется версия с командной строкой) - придется пожалеть о содеянном.

Предлагаемый класс есть очень простой пример "развязки" UI и расчетов. Расчетам нужен UI индикатор, т.к. они могут длиться минуты. Но никаких QProgressDialog, сигналов - никаких подробностей реализации UI в расчетах быть не должно. Использование может выглядеть так:

C++ (Qt)
int CMeshCalculator::CalcNormals( void )
{
  CMeshProgress::SetIndicator("Calculating Normals", mNormals.size());
  ...
  for (size_t i = 0; i < count; ++i) {
   ..
   if (!CMeshProgress::Update(i, 100))
    return ERR_USER_CANCEL;
   ..
   Calc1Normal(..);
  }
}
 

Т.к. CMeshProgress по умолчанию ничего не делает, то его можно безболезненно долить во все расчеты. Перед началом расчетов др. модуль зарядит конкретное UI индикатора - это может быть QProgressDialog, а может и печатание точек в командной строке.

Признаться, я был удивлен что такая банальная вещь вызвала такие трудности с understand'ом  :)

Расскажите, пожалуйста, для чего нужен этот класс (с примером желательно) :)? И как проект не сможет жить без него нормально?

Полный ответ на этот вопрос занял бы много страниц - и все равно, вероятно, не был бы полным. Я не знаю как объяснить, я просто понял что надо так делать  :)

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


 фи... :`(

Igors пример использования давай

Я не собираюсь с кем-то спорить (не стоит оно того). Просто есть МЫСЛИ которые программист придумал сам. И есть тупенькое копирование учебного примера. Если сравнить технически - учебный пример гораздо более совершенен, свои мысли всегда содержат много ошибок и субъективный взгляд автора, это неизбежно. Но как ни старайся, а на учебном примере далеко не уедешь, в реальной работе очень быстро придется решать самому. А поэтому мысли важнее, пусть они в 100 раз менее совершенны.

Не следует подходить к этому разделу потребительски, как к документации Assistant. У "троллей" - да и у любой
нормальной компании есть своя "creative lab" мы видим только "выход" - в понятной, доступной форме. Но в рамках "creative lab" вопросы типа "а что я могу использовать/полагаться" неуместны, это не букварь. Здесь надо иметь свое мнение и (увы) - это многих раздражает  :)

Юра, не могу, это человек должен сам догнать  :)

Ну хотя бы написали переходник от чего к чему.
От нестатической функции к статической?

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

ваше дело конечно, на этот случай есть модераторы, но моё вам "фи"... ;(

Статические ф-ции здесь удобны/выгодны потому что они позволяют каким-то частям проекта использовать это класс без всяких дополнительных усилий. По этой же причине ф-ции не объявлены как pure virtual (= 0).

Дергаем статические функции. Если экземпляр класса создан, то статические функции будут дергать его члены. По вкусу можно отнаследоваться. Любопытно посмотреть применение. Вопрос: а почему даже assert не стоит в конструкторе. Начнет кто-то дорабатывать твою программу, создаст еще экземпляр класса и у первого (какой из них будет "первым" еще  вопрос) все перестанет работать.  Или я что-то не так понял?

Совсем не понял  :) Никакой "подкрутки" в классе нет - дело в функциональности

это конкурс "догадайся зачем это нужно" ?

Ну если в Вашем проекте таких проблем (пока) не возникло - незачем тратить время на догадки  :)

Особенно интересно будет послушать про использование этого класса в многопоточных программах  ;D

Ну здесь не амфитеатр и я не гладиатор чтобы сражаться со львами и тиграми  :)  Хотя класс вполне подходит для работы с 2 или более нитками. Нет никакого "подвоха", ничего "такого особенного" что нужно раскурить в манах и.т.п. Класс просто "рабочая лошадка"  без которой жить - ну можно. но хреново  :)

о даа) это в стиле "я знаю где в этой темной комнате гавна навалено, но если вы в него не вляпались - то и незачем вам знать как его обходить"  :D

Давайте лучше организуем отдельный раздел - "угадай задачу"?

Ну реально, я считаю что делать "вот вам код" - это невежливо как минимум. И вот хз насколько он необходим и нужен.

Это интернет, деточка. Здесь могут показать код и не сказать, что он делает! (Шутка)  ;D
А ежели по теме: так пущай висит, может кто любит головоломки. Я вот не справился. Совсем.

Похоже на Listener.

Поржал.....:D  ... если не ясно для чего это, то разбираться тем более не буду....

Я тоже  :)

ржачь по этому посту в конфе c_plus_plus@conference.jabber.ru

http://0xd34df00d.me/logs/chat/c_plus_plus@conference.jabber.ru/2010/09/08.html#11:15:53
 ;D

Igors, или добавь описание в первый пост, или удалю ветку.

Трудности.  :)
Я думаю многе ждали, когда же ты напишешь как ты "это" используешь, что бы сказать что так делать не нужно. Никогда.  :)
Что это "решение", имеет больше ограничений, чем делает полезных вещей.
Посмотри на досуге на "паттерны", там ты найдешь более красивые решения... Если сам ничего лучше придумать не смог. Без обид. ;)

гм... Igors есть адепт религия который не позволять мочь использовать сигнал-слотовый механизЪм ?
Igors не знает про существование сигнал-слотового механихзма? это на форуме QT предлагать такие решения?  ???
фи как грубо... ))))

Пожалуйста, критикуйте . Покажите как лучше - и я с удовольствием у Вас поучусь (было бы чему  :))

doublefacepalm

Пантер удаляй этот тред к ч..й бабушке

Посмотрим на функционал, о котором можно писать книги и все равно его не описать...  :)

C++ (Qt)
// Долгие вычисления чего-то там...
int Class::func1()
{
	CMeshTextIndicator indicator;
	CMeshProgress::SetIndicator( "Calculating ...", mList.size() );
	for( size_t i = 0; i < count; ++i )
	{
		...
		if ( !CMeshProgress::Update( i, 100 ) )
			return ERR_USER_CANCEL;
	}
}
 
// Очень долгие вычисления
int Class::func2()
{
	CMeshTextIndicator indicator;
	CMeshProgress::SetIndicator( "Big Calculating ...", mList.size() + mList2.size() );
	for( ... )
	{
	}
 
	func1();		// <<<<<< Вот после выхода из func1 индикатор определенный в func2 отключиться.
				// Так не надо было писать? Ну извините, я забыл про это ограничение. :)
 
	for( ... )
	{
	}
 
}
 
...
 
// Считаем...
obj->func2();
 

Сейчас мы "побороли" задачу индикации прогресса выполнения функции. Мы добавили этот код в разные классы и вроде все хорошо, но...
Теперь нам понадобилось вести статистику всех расчетов, что делать? Полезть во все функции и добавить аналогичную приблуду. А если потом понадобиться во время расчета отправлять результаты расчетов по сети, например :). Тоже полезем во все функции и добавим еще одну такую приблуду? А если это нужно будет опционально. А если нужно будет считать разные функции в разных потоках?

Хотели отвязаться от одних классов, а привязались к другим?

А если посмотреть на паттерн Observe (наблюдатель), то можно научить наш класс общаться с классом-наблюдателем и на его базе создать классы, объекты которых могут выводить информацию о прогрессе, вести статистику и делать хрен знает что еще... И при этом на не придется ничего изменять в нашем классе.
Это классический вариант.

C++ (Qt)
Statistica st;
 
...
 
CMeshCalculator calc;
calc.reg( new TextProgressIndicatorObserver );		// Регистрируем наблюдателя для вывода прогресса
if( useStatistica )
	calc.reg( ?st );								// Если нужно - регистрируем наблюдателя для ведения статистики
 

Так же можно посмотреть сигналы реализованные в boost или отдельной библиотеке sigc++. Получится аналогичное решение, только еще больше отвязанное от классов участников (можно обойтись от класса-наблюдателя).

Ололо, появилось описание!

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

Короче идея понятна, но реализация должна быть посложнее..

всё равно я нифига не понял. Например, зачем эта строка:

C++ (Qt)
CMeshProgress::SetIndicator("Calculating Normals", mNormals.size());

Где должен появится текст "Calculating Normals"?

Если CMeshProgress должен всякий раз наследоваться, то почему методы не истинно виртуальные? Если должен всякий раз допиливаться, то вообще глупо.

нет определённо тему в помойку. Или создать раздел "угадайки", по аналогии с программистскими задачами

Текст появится там где решит наследник CMeshProgress. Если такового нет - то нигде. Можно сделать методы и pure virtual, тогда надо объявить/иметь наследника - дело вкуса. Смысл не в переливании static-virtual а в том что расчетная часть изолирована от UI.

Это дело класса-индикатора организовать push-pop, клиент (расчетная часть) здесь ни при чем.

Я правильно понял что static ф-ция "приблуда" (все что не класс - плохо и.т.п) ?  :) Но так или иначе лезть в расчеты и добавлять придется, потому что только там известно какие операции выполняются.

Более мощный класс индикатора - дело хорошее. Но с чего Вы взяли что CMeshCalculator умеет делать reg и.т.п? Да CMeshCalculator может быть вообще не Ваш код. Его пишет Саша, для которого все UI начинается и заканчивается printf. Но предметную часть он знает прекрасно и алгоритмы кладет как надо. Я со своим простеньким классом скажу ему:
А Вы что скажете? Я показал простейший пример "развязки" и ничего не имею против более сложных. Важен принцип изоляции, а реализация всегда зависит от конкретики.

Интриги, скандалы, расследования!  ;D

Почитал я на досуге про патерн Observe  :) и это реально более изящное и правильное решение на мой взгляд.    
Используя этот патерн, Ваш пример с CMeshCalculator выглядел бы следующим образом:

C++ (Qt)
#ifndef CMESHCALCULATOR_H
#define CMESHCALCULATOR_H
 
#include <list>
 
class CMeshCalculator;
 
class IObserver {
public:
    virtual void handleEvent(const CMeshCalculator &) = 0;
};
 
class CMeshCalculator {
public:
    CMeshCalculator()
        :_someParam(0) {}
 
    int someParam() const { return _someParam; }
 
    void calculate() {
    // Possible here _someParam is changed.
    // for example: _someParam++;
        notify();
    // ...
    }
    void reg(IObserver &ref) {
        _observers.push_back(&ref);
    }
 
    void unreg(IObserver &ref) {
        _observers.remove(&ref);
    }
 
private:
    std::list<IObserver*> _observers;
    typedef std::list<IObserver*>::iterator _iterator;
 
    void notify() {
        for(_iterator it = _observers.begin(); it != _observers.end(); it++)
            (*it)->handleEvent(*this);
    }
 
    int _someParam;
};
 
#endif // CMESHCALCULATOR_H
 

Где мы сотворили чисто виртуальный класс IObserve. Функция calculate() - это то, где производятся громоздкие расчёты и т.п. И в ней мы вызываем notify(), которая перебирает список всех зарегистрированных наблюдателей и вызывает у каждого переопределённый метод handleEvent.

Теперь пример класса TextProgressIndicatorObserver:

C++ (Qt)
#ifndef TEXTPROGRESSINDICATOROBSERVER_H
#define TEXTPROGRESSINDICATOROBSERVER_H
 
#include <iostream>
#include "CMeshCalculator.h"
 
class TextProgressIndicatorObserver : public IObserver {
public:
    void handleEvent(const CMeshCalculator &calc) {
        std::cout << "processing..." << std::endl;
        std::cout << calc.someParam() << std::endl;
    }
};
 
#endif // TEXTPROGRESSINDICATOROBSERVER_H
 

 

Разумеется, информацию мы можем выводить не только в cout но в гуй и куда угодно. И это решение - как раз и отделяет интерфейсную часть от расчётной -> переходничок)

А используется это так:

C++ (Qt)
#include <iostream>
#include "CMeshCalculator.h"
#include "TextProgressIndicatorObserver.h"
 
using namespace std;
 
 
int main()
{
    TextProgressIndicatorObserver tpiObserver;
    CMeshCalculator calc;
    calc.reg(tpiObserver);
    calc.calculate();
 
    return 0;
}
 
 

Поправьте, если чего то не того написал))

References:
http://en.wikipedia.org/wiki/Observer_pattern

Я скажу:
Санек, прицепи этот хеадер, добавь к своему классу еще один базовый класс с именем Subject и повтыкай где надо одну функцию. Все!
Больше Саньку никуда лезть не понадобиться никогда, все остальное можно будет сделать не глядя в его код, и индикацию, и статистику, и все что понадобиться.  :)
В отличие от...

Все это достаточно весело. :(
Как правильно заметил Igors, один фиг необходимо делать вызовы в местах для подсчета. Этого никак не избежать.
А кого вызывать, это уже вторично: непосредственно метод некоторого объекта, обзервер, сигнал, ...
Все зависит от удобства, истории проекта, конкретной ситуации итд.
Надо поменьше битья себя кулаком в грудь - побольше дела.

Господа))))) что бы уж разобрать тему по косточкам - а информирование мира о прогрессе вычислений с помощью сигнал/слотов - это уже не модно или это рассматривается как частный случай одного из шаблонов?
Spectre конечно сказал что "надо вызывать в местах подсчета" - но , исхо он слегка не прав - что бы мы не делали, какую задачу мы бы не решали - всегда надо "все равно делать какой-либо вызов" , но шаблоны таки существуют - а значит разница есть.

Вопрос мой вот в чем. Почему не использовать станартный (читай реализованный) механизм QT (мы тут типа все-таки троллеводы здесь собрались? не?) , и не городить кучу классов самим? есть мысть сделать свое лучше чем тролли? гм.. тогда объясните "профит" - в чем и когда лучше....

Смысл в следующем...
Если использовать Qt систему сигнал-слот, то мы получаем полную зависимость от Qt, а это далеко не всегда нужно.
Например, очень не плохо написать ядро системы вообще не привязанное к какому либо GUI. Дальше мы можем писать frontend для этого ядра на Qt/GTK/WinAPI или сделать консольную версию программы.

Но помимо Qt сигналов, есть еще свои реализации в boost или отдельной библиотеке sigc++, их так же можно использовать и удобств это только прибавит (ну я выше это уже писал).

Все упирается в профит, который мы получим от этого самого вызова.

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

Сигнал/слот - зависимость от QObject, это не GUI и актуально для форума. Кутэ - это не только интерфейс, не нужно об этом забывать.

Да я не забываю, но Igors четко описал, что этот прием создавался что-бы разорвать зависимости от сторонних библиотек и дать возможность разработчику выбирать метод индикации (GUI/консоль/что-то еще).
Это и обсуждаем.  :)
А зависимость от QObject это автоматическая зависимость от Qt.  ;)

Это конечно верно. Но не только это. Я не вижу как удобно сделать с помощью слот/сигнал. Ну то есть сделать я могу, но мне не нравится  :) Чтобы разговаривать предметно, давайте конкретную реализацию на слот/сигнал, а я попробую объяснить почему.

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

А почему handleEvent осведомлен о классе CMeshCalculator вообще? Откуда handleEvent знает какой текст нужно написать и какой прогресс показать? И если у Вас 2 или более обсерверов, откуда они знают кому чего показать? Я так вижу что ресурсы-то уже тратятся (STL и.т.п) а хотя бы минимальной ф-циональности еще нет.

Форум должен быть углубленным изучением Assistant!  :) Увы, это во многом так и есть  :'(

А почему все классы типа CMeshCalculator и их методы должны знать про CMeshProgress?  :)
Потому, что нельзя заставить взаимодействовать два объекта, которые ничего не знают друг о друге (без дополнительных телодвижений).
Поэтому, все классы-наблюдатели знают о классе субъекте за которым они наблюдают, а вот класс-субъект ничего не знает о своих наблюдателях, кроме одной функции, которую он вызывает.
Разница в том, что CMeshProgress может делать только одну вещь (при попытке расширить функционал придется лезть в класс-субъект и добавлять код руками), а при использовании наблюдателей они могут делать совершенно разные действия и никаких изменений в классе-субъекте делать не придется.

Ну тут меня опередили (см. выше)

Igors, это уже жадность)) Что там такого тратиться? Не думаю, что кто то вообще почувствует разницу по съеданию ресурсов в этом месте.. Короче это смешно)

А по-поводу минимальной функциональности это Вы не правы. В данном конкретном примере, целью которого было лишь продемонстрировать идею этого патерна, реальной функциональности нет) Эт ж пример))
Но, если смотреть глубже то здесь большой потенциал, для Вашей задумки с переходником.
Причём реализуется он без лишних беспокойств Санька, (того, который так хорошо кладёт код)
   
Чем по функциональности приведённый пример с патерном уступает вашему переходнику? 

Набросал шаблон реализующий паттерн Observer:

C++ (Qt)
#include <list>
#include <cassert>
 
template<typename Subject, typename Observer, void (Observer::*func)( Subject & )>
class ObserverSubject
{
	typedef Observer* Pointer;
	typedef std::list<Pointer>	List;
 
public:
	void	regObserver( Pointer o )
	{
		assert( o );
		m_listObservers.push_back( o );
	}
 
	void	unregObserver( Pointer o )
	{
		assert( o );
		m_listObservers.remove( o );
	}
 
	void	notifyObserver()
	{
		for( typename List::iterator i = m_listObservers.begin(); i != m_listObservers.end(); ++i )
			((*i)->*func)( static_cast<Subject&>( *this ) );
	}
 
private:
	List		m_listObservers;
};
 

Использование:

C++ (Qt)
class CMeshCalculator;
 
// Определяем абстрактный базовый класс наблюдателей.
// Имя функции может быть любой (указывается в параметрах шаблона)
class Observer
{
public:
	virtual	void	update( CMeshCalculator &obj ) = 0;
};
 
// Добавляем к базовым классам ObserverSubject.
class CMeshCalculator : public ObserverSubject<CMeshCalculator, Observer, &Observer::update>
{
public:
	CMeshCalculator() : m_index( -1 ) {}
 
	void	func()
	{
		for( m_index = 0; m_index < 20; ++m_index )
		{
			// В точках, где необходимо позвать наблюдателей добавляем:
			notifyObserver();
		}
	}
 
	inline	int			index() const { return m_index; }
 
private:
	int			m_index;
};
 
// Описываем наблюдателя для индикации
class Indicator : public Observer
{
public:
	Indicator( int step = 10 ) : m_step( step ) {}
 
	void update( CMeshCalculator &obj )
	{
		if( !(obj.index() % m_step) )
			std::cout << "[Indicator] " << " progress: " << obj.index() << std::endl;
	}
 
private:
	int		m_step;
};
 
// Описываем наблюдателя для ведения лога
class Log : public Observer
{
public:
	void update( CMeshCalculator &obj )
	{
			std::cout << "[Log] " << " progress: " << obj.index() << std::endl;
	}
};
 
int main( int, char ** )
{
	Indicator i( 5 );	
	Log	l;
 
	CMeshCalculator calc;
	// Регистрируем нужных наблюдателей
	calc.regObserver( &i );
	calc.regObserver( &l );
 
	calc.func();
 
	return 0;
}
 

BRE, зря велосипед придумал. Есть версии обзервера и поинтересней. Например вместо хранения указателей на Observer можно и нужно хранить QWeakPointer/boost::weak_ptr/std::weak_ptr. Иначе будет крах из-за того, что объекту забыли сделать unreg до того как его удалили.

Опять же на Qt'шном форуме предлагать решения чисто для C++, которых в инете навалом - не правильно.

Мое ИМХО, в этом разделе должны быть решения написанные на Qt и для Qt.

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

Почему не правильно, основная масса читателей как раз и пишут на чистом C++.  :)

Что значит написано на Qt?
И чем решение на C++ не подходит для использования в программах использующих Qt. :)

Для этого есть раздел C/C++ (http://www.prog.org.ru/board_5_0.html)

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

А для чего? Что бы получить как можно большую зависимость от Qt?
Что-бы получилось решение, которое обязательно придется переделывать, если понадобится не использовать Qt?
Из-за чего такая "преданность" именно этой библиотеке? Она хороша, но все равно всего лишь одна из...  ;)

В таком случае этот раздел не должен находится именно в этой ветке, он должен быть общим для всего форума. И тогда сюда можно будет еще и для PHP решения писать...

Тоже самое можно сказать про использование boost'a и возможностей из C++0x. Что если понадобится их не использовать?

Приходя в раздел для Qt я ожидаю найти решения для этой библиотеки, а не сборник рецептов для языка C++.

Каждый решает сам. Для меня boost более приоритетный чем Qt, т.е. если есть возможность отказаться от Qt (ну не нужен программе GUI), спокойно от него отказываюсь. А вот от boost отказаться уже не особо получается.
Я всегда стараюсь минимизировать зависимости в своих программах.

Так а чем это решение то не подходит для "решения для этой библиотеки"?  :)

Сам же знаешь, что Qt - не только GUI, который является всего-лишь одним из модулей. Есть же модули, которые не зависят от гуя:

QtCore
QtNetwork
QtScript
QtSql
QtXml
QtXmlPatterns

Тем, что оно решает не проблемы Qt, а проблемы конкретной программы, где нужно извещать другие объекты о ходе прогресса. В Qt для этих целей используются сигналы или QEvent's, которые потоко-безопасны, в отличае от приведенных тут решений. Одно лечим - другое калечим.

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

Целью этой темы как раз было показать прием, позволяющий убрать дополнительные зависимости. Перечитай тему.
Его и обсуждаем.

гм... у QT хороший удобный кроссплатформенный набор не-гуевых классов. Имхо))))
Фреймвок, удобный, приятный) ляпотя ^_^
не хочу заморачиваться решением проблем портирования, даже не гуевых приложений)

Писать парсеры, сетевые сервера, ботов, эксплойты. Мало ли задач на свете, которые можно решить без GUI.

Это называется "давайте уберем зависимость от boost'a на форуме boost'a". Выглядит точно так же.

Полностью согласен, иначе бы не пользовался ей.  :)
Но, есть разные задачи. Например, есть только консоль - зачем иметь зависимость от Qt, а если на платформе не может быть установлена Qt?
Для чего жестко привязывать ядро своей системы к Qt? Понадобилось GUI ну сделай его на Qt/GTK/MFC, а понадобилась консольная версия используй ncurses/turbovision/...  :)

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

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

А специализированные решения могут быть более эффективны, да кроссплатформенны.  :)
Для чего мне тянуть с собой QtCore + QtXml, если мне нужна маленькая консольная утилитка простого парсинга xml? Я возьму малюсеньку библиотечку tinyxml.  :)

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

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

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

______________________
ладно, это выбор стратегии. на совести каждого выбирающего ))))
Тут кто-нибудь играет в Го (http://ru.wikipedia.org/wiki/%D0%93%D0%BE)? текущая нить обсуждения мне напоминает вопрос выбора между территорией и влиянием)))))

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

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

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

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

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

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

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

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

 

Все зависит от тех библиотек которые ему нужны. Но сумма зависимостей всей системы - часто удручает. Слишком разношЁрстно и генетически трудно совместимо.
А на сколько быстро вы сможете привести в единый строй ваш зоопарк ву стиле (QT+ncurces+pyton+...)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Та отож  :)

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

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