Russian Qt Forum

Как правильно реализовать сабж?
Настройки должны отображаться в окне настроек, их используют разные модули программы. Singletone? MVC?

Вариант с синглтоном мне нравится больше. Что за MVC - Model Viewer Controller? а как он здесь связан? Второй вариант через наблюдателя. Но тогда надо все классы наследовать от наблюдателя и определять соответствующие методы.

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

Делаешь класс на базе QObject с сигналом changed(), с сохранением в реестр/ini по методу commit(). Далее, зависит от архитектуры твоего приложения, или делаешь синглтоном объект этого класса или раздаешь указатель на него всем заинтересованным окнам, объектам.

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

Чёоо :o
В библиотеках нельзя использовать синглтоны? Или объявлять?

Сделать переменные настроек глобальными, меню настройки пусть их меняет, а разные модули программы только читают. В чём проблема?  ;D

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

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

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

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

Это приводит к тому, что библиотека будет пользоваться ТОЛЬКО так, как и задумывалось.
Что с одной стороны правильно - неправильно её использовать будет почти невозможно :D
С другой стороны - приложение, её использующее должно соответствовать определённым требованиям.

Правильный синглтон не обращает внимание на такие мелочи как "многопоточность". Но это уже заслуга его автора и продуманности архитектуры :D

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

Так значит все-таки объявлять...
Аргументы либо притянуты, либо далеки от контектста:
> Плохой дизайн
  если только неграмотная реализация синглтона...
> в многопоточной среде
  настройки в отдельном потоке? оно надо?
> Синглтон накладывает серьезное ограничение на способ использования
  так ведь в этом его предназначение. Одиночка она и в приложении и в библиотеке одиночка

ЗЫ. Ой, Верес опередил.

Ну давайте копнем, что ли (а то много общих слов  :)). Корректна ли такая реализация ?

C++ (Qt)
MySingle * MySingle::mInstance = 0;
 
MySingle * MySingle::Instance( void )
{
 static QMutex mutex;
 if (!mInstance) {
  QMutexlocker lock(&mutex);
  mInstance = new MySingle;
 }
 return mInstance;
}

Хм, я бы поставил QMutexLocker перед if. А так, подозрений не вызывает)

++ убрать перед if. На первый взгляд нормальная архитектурка.

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

А если так?

А про стандарт с++11 кто-нить вообще слышал?  ;)

нет, реализация некорректна.

Приводите аргументы, вместо недоказанных утверждений, пожалуйста :)

Замечу - фриз будет если вызывать instance раз 200-300 без перерыва. А на хорошей архитектуре он будет вызываться 1 раз при создании объекта.

update: Да. Некорректная реализация именно из-за блокировки после условия. Там вполне возможна аварийная ситуация при захвате и ожидании мутексов. Создадутся N копий синглтона. Но вынос блокировки наверх решает эту проблему :D

QMutex - это не POD, делать статик не-POD нельзя. Что будет, если 2 потока начнут инициализировать мьютекс? Можно заменить на QBasicMutex.

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

 Какими короткими стали Ваши ответы, куда же девалась обычная словоохотливость ?  :)

Ну если объявлять его глобально (до main) - то и никакие scoped не нужны. Но такое объявление не всегда выгодно/возможно

А без нового стандарта чего-то можем? Или тогда в дуст полезем?  :)

Синглтон НЕ ДОЛЖЕН зваться часто. Он инициализироваться должен 1 (ОДИН) раз.
1 раз для каждой подгружаемой сущности. В результате количество вызовов синглтона должно быть равным количеству сущностей.

Фризов НЕ БУДЕТ.

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

Ибо даже если самую простейщую операцию вызывать нонстоп - заглохнет всё.

PS вот тут и возникает ситуация о которой я писал - синглтон зависим от архитектуры. И вменяемости программиста.

update: Словоохотливость вкл.
Рассуждения о "трудоёмкости", "фризах" и прочем - это мифы. Те, кто утверждают что "синглтон будет вызываться часто" - видимо имеют случай "голова не знает что руки делают".

to Max: приведите пример синглтона с новым стандартом пожалуйста. Мне интересно.

to Аварон: настолько глубоко я мутексы и статик не знал, спасибо за пояснение.
Словоохотливость выкл.

Есть опция "statics are thread-safe" культурно защищает инициализацию спыннером. Но вообще да, лучше не искать приключений и вынести mutex за тело ф-ции.

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

Как обычно, Igors свёл рассуждение о синглтоне к поиску ошибок в куске левого кода :)

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

Ладно, чтобы "сердце успокоилось" исправляем

C++ (Qt)
MySingle * MySingle::mInstance = 0;
static QMutex mutex;
 
MySingle * MySingle::Instance( void )
{
 if (!mInstance) {
  QMutexlocker lock(&mutex);
  mInstance = new MySingle;
 }
 return mInstance;
}

Теперь верно ?

Ну, можно еще так, с двойной проверкой для двойного успокоения сердца

начали за здравие...

для "синглтонов" в Qt можно использовать Q_GLOBAL_STATIC

хорошее описание синглтонов есть в книге Александреску

Не "можно", а обязательно так. Но, к сожалению, это все-таки неверно (по крайней мере для всех компиляторов)

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

Ххы. Самый смак в том, что вашего идеального решения не существует, увы. А малодушное решение работать будет.

http://habrahabr.ru/post/150276/

Если в двух словах - gcc ставит мутекс на каждый вызов :D

еще можно воспользоваться GCD (https://ru.wikipedia.org/wiki/Grand_Central_Dispatch) и создавать синглтон в dispatch_once()

C++ (Qt)
template <class T>
T & singleton()
{
    static T instance;
    return instance;
}
 

И что с того?
[off]Давно заметил что "тыц ссылкой" - совсем не признак ума :)[/off]

А если в какой-то момент я захочу заменить instance, а потом вернуть старый ? (типа push/pop)

Ммм... Т.е. стандарт разруливает все мутексы и прочую фигню? :)

Ссылка от Vizir.vs говорит и показывает, что не все компиляторы по-честному поддерживают эту тему, так что чего-то сомнительно  ;D

Это тонкий намек, что от мьютексов не убежать?  ;D

Это тонкий намёк на натуру Igors - поставить задачу, а потом менять условие, не считаясь ни с какими доводами :D

Не хотел бы я, чтоб он был заказчиком :)

Хм, что же это, все операции для чтения-установки значений в классе настроек таком тоже придется защищать мьютексами?  ;D

новый стандарт делает просто - на каждый вызов по мутексу :D Видимо не тормозит :D

B снова неверно. Порядок инициализации не определён. Может статься, что вы при вызове Instance(), QMutex еще не создан.

Блин, читайте Александреску.

ЗЫ: а dlopen является thread-safe?

в этом случае QMutex сразу будет создан по причине своей статичности и нахождении в теле класса, разве нет?

Никто не утверждал что синглтон нельзя менять, и это может быть небезопасно если он используется неск нитками. Так что эти заботы никто не отменял. Только вот чего это я обязан объявлять static экземпляр? Как всегда указатель гибче.

Подлянка в операторе new (см. статью кстати очень неплохую). В 2 словах

C++ (Qt)
mInstance = new MySingle; 

Стандарт во всяком случае не запрещает установку возвращаемого значения mInstance ДО ТОГО как код конструктора полностью выполнится.

Ну так это легко обходится если чуть-чуть подумать. Но увы - желания думать нету. Пошла барахолка типа "где бы чего достать" под трескотню Верес'а  :'(

Я даже знаю из какой (глупейшей) статьи Вы это почерпнули :) Не верьте всему прочитанному

Предоставьте мне желательно другой способ безопасного многопоточного вызова любого метода без использования мутекса :D

Закавыка в том, что вы предлагаете найти то, что уже нашли вы. Это мало того, что бессмысленно - мутексы проще и гибче, да ещё и попахивает "профессионалом".
Типа я додумался, но никому не скажу, пусть мучаются. Но блин кому надо искать что-то, что нашли вы, когда на полке лежат прекрасно разобранные мутексы?
Они имеют свои ограничения, но эти ограничения уже давно описаны и понятны. 

Я бы назвал глобальные переменные настроек NASTROYKA_!!!READONLY!!!_X21 и не парился.

Или я чего то не понимаю, или вы слишком много требуете от простого синглтона..

Это же Igors.
У него сначала велосипед едет на треугольных колёсах, спрямляем - поехал быстрее.
У велосипеда оказывается были лопасти из картона и он должен был летать, заменили картон на пластик - полетели меееедленно.
Оказывается всё это происходит в коронной области солнца и велосипед должен быть герметичен - со стонами мастерим систему охлаждения, работающую на научных парадоксах и герметизируем с помощью строительной пены.
Ан нет, мы неправы. Потому что забыли систему защиты от злобных пришельцев на трёхколёсных велосипедах :D

То есть вы утверждаете, что если один синглтон обращаются конструктора к другому, то проблем не будет? :facepalm:

Пример

C++ (Qt)
// глобальные переменные
QList <int> theGlobalList;
MyClass theGlobalClass(theGlobalList);
const MyClass2 theGlobalClass2(theGlobalClass);
 

Какие здесь проблемы с инициализацией? Никаких, любая "нелокальная" (в терминах стандарта) переменная может использовать объявленные ранее. Порядок не определен для переменных объявленных в разных единицах трансляции - ну так об этом здесь речь не идет (см ниже).

Если Вы хотели показать себя "опытным практиком", то у Вас была прекрасная возможность. Практик не заморачивался бы с никакими блокировками, а написал бы так

C++ (Qt)
MySingle * MySingle::Instance( void )
{
 if (!mInstance) 
  mInstance = new MySingle;
 return mInstance; 
}

Да, это "небезопасно", но достаточно вызвать MySingle::Instance один раз (напр на старте) - и проблемы нет. Или обеспечить вызов перед перед запуском использующих его ниток. Затрудняюсь привести пример когда это невозможно. А часто (пусть и не всегда) можно тупо объявить его глобальной переменной которая гарантировано будет инициализироваться только в главной нитке до main. Однако вместо этого Вы несете такую пургу
что даже неудобно слушать  :)

Вы указываете что в новом стандарте проблема инициализации глобальных переменных решена. Это бесспорно, но речь шла о создании синглтона в куче, резоны найдутся. Выходит объявить "безопасную" глобальную переменную могу, а указатель нет. Или как?

Ваш способ не безопасен. С таким же успехом я могу использовать указатель-глобальную переменную. Но синглтон в не знает кто и когда его вызовет, что накладывает ограничение.
Самое простой пример - использование dll с синглтоном. И никто-никогда не узнает до вызова instance - есть ли в приложении синглтон или нет :)

Как обычно по сути дела ничего. Уже и приплели "достаточно вызвать 1 раз". Такое чувство не читали тему - на первых страницах приводили вариант вызова из длл.

Для указателей можно использовать std::call_once http://en.cppreference.com/w/cpp/thread/call_once (http://en.cppreference.com/w/cpp/thread/call_once)

Есть и примеры синглетонов с её использованием..   

Собственно в продолжении темы: как обращаться из программы к настройкам? Удобно пользоваться автодополнением, но когда настройки хранятся в виде QMap<QString,QVariant> при обращении к настройками писать строковый ключ неудробно - нужно его помнить и можно ошибиться, автодополнение - структуры городить.

Не совсем понял. У тебя в программе есть окно, в котором ты начинаешь вводить название параметра и у тебя должны выпадать возможные варианты продолжения?

Я в коде хочу прочитать что то из настроек, если писать строчку то можно ошибиться.

enum тебе в помощь.