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

[SABROG]

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

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

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

[BRE]

BRE, зря велосипед придумал.

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

[BRE]

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

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

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

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

[SABROG]

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

Для этого есть раздел C/C++

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

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

[BRE]

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

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

[SABROG]

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

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

Что-бы получилось решение, которое обязательно придется переделывать, если понадобится не использовать Qt?

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

Из-за чего такая "преданность" именно этой библиотеке? Она хороша, но все равно всего лишь одна из... 

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

[BRE]

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

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

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

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

[SABROG]

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

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

QtCore
QtNetwork
QtScript
QtSql
QtXml
QtXmlPatterns

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

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

[BRE]

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

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

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

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

[Denjs]

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

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

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

[SABROG]

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

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

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

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

[BRE]

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

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

[BRE]

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

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

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

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

[BRE]

не хочу заморачиваться решением проблем портирования, даже не гуевых приложений)

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

[Denjs]

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

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

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

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

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

______________________
ладно, это выбор стратегии. на совести каждого выбирающего ))))
Тут кто-нибудь играет в Го? текущая нить обсуждения мне напоминает вопрос выбора между территорией и влиянием)))))