В конструктор родителя передать имя объекта

[alexis031182]

Alex_C, Igors Вам дал очень дельный совет не наследовать CalcWindow (и др. подобные классы окон) от AbstractLogWindow. Это действительно в будущем, с увеличением размера приложения может привести (и наверняка приведёт) к необходимости добавления в код множества т.н. костылей. Разъедините оба класса, и пусть AbstractLogWindow принимает указатель на окна типа CalcWindow.

[Alex_C]

Чего то я пока ничего не понял - я то как раз хочу размер уменьшить - все в класс - потомок свести. Разве это не правильно??

[alexis031182]

На самом деле через наследование в данном случае Вы не уменьшаете размер. Ну посудите сами: при создании каждого объекта класса CalcWindow будет автоматом создаваться экземпляр класса AbstractLogWindow. То есть, имея, скажем, 30 объектов CalcWindow, Вы получаете по сути 30 объектов AbstractLogWindow. Судя по представленному Вами функционалу AbstractLogWindow в таковом наследовании нет необходимости. Вполне достаточно одного экземпляра AbstractLogWindow на сколь угодно большое количество CalcWindow.

[Alex_C]

Я понял о чем Вы говорите. Просто тот функционал, что я привел - для примера. В реальной программе все существенно сложнее получается, чем просто записывать данные в ini-файл. Конечно,  с Вами согласен - был бы разговор только о записи вида окна - городить огород из наследования - смысла бы не было.

[_OLEGator_]

Зачем хранить лишнее поле с именем.
Я бы сделал виртуальную функцию получения имени объекта, в потомках его переопределял, а в базовом классе при сохранении и загрузке можно в любом месте получить имя, вызвав эту функцию. Нет необходимости хранить это имя.

Можно воспользоваться функциональностью QObject:

Код

C++ (Qt)
QString	objectName () const
void	setObjectName ( const QString & name )

[Alex_C]

Зачем хранить лишнее поле с именем.
Я бы сделал виртуальную функцию получения имени объекта, в потомках его переопределял, а в базовом классе при сохранении и загрузке можно в любом месте получить имя, вызвав эту функцию. Нет необходимости хранить это имя.

А вот это наверное самое правильное решение! Так и сделаю!

[LisandreL]

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

В конструкторе/деструкторе родителя нельзя.
А сохранить данные перед выходом может захотеться именно там.
Ну это просто как напоминание.

[Alex_C]

Поторопился. Виртуальную ф-цию в конструкторе не получается использовать - LisandreL прав. 
Какие могут быть еще варианты?

[Alex_C]

Может конечно вообще не заморачиваться - просто название класса ручками прописывать. Но вроде как не по феншую...

[alexis031182]

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

[Igors]

Чего то я пока ничего не понял - я то как раз хочу размер уменьшить - все в класс - потомок свести. Разве это не правильно??

Чувствуется кладка дельфийца - давайте раздуем базовый класс "на все случаи жизни"
Посмотрим а что делает AbstractLogWindow. Разве сохранение/восстановление размеров/позиции окна как-то связано с CalcWindow или др именно Вашими классами окон? Вовсе нет, это можно делать для любого Qt окна/виджета. Отделаться "загрузкой в конструкторе" + "сохранением в деструкторе" все равно не удается. Напр пользователь нажал "Save" - и окна не закрываются но их расклад должен быть сохранен. Также интересно как Вы будете извиваться если потребуется окно что не зависит от QSettings.

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

[Alex_C]

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

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

[Alex_C]

Да кстати о наследии Дельфи - в дельфи унаследовать класс TForm было весьма не простым делом - там ведь ручками прийдется все компонеты на нем расставлять.  Тут же - лайоуты - красота Как раз поле для классов)))

[Igors]

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

Покрутите разные ситуации. Напр у меня есть "Reset Windows" - выстроить окна как они записаны в установках. Как будете делать если у Вас это жестко вбито в конструктор? Или пользователь выходит без сохранения - а у Вас в деструкторе установки окон зачем-то сохраняются. и.т.п. Быстро выясняется что не сам класс окна а какая-то "третья сторона" решает нужно ли загружать/сохранять. Значит надо иметь эти действия в виде ф-ций - и все.

Если "чисто теоретически" то можно объяснить так. Является ли сохранение/загрузка "неотъемлемым" свойством Ваших окон, без которого они не могут жить? Никак не является, очень может быть есть (или будут) окна которым это не нужно. Так чего это свойство вынесено в базовый класс?

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

Тут же - лайоуты - красота Как раз поле для классов)))

Заметьте что лайоут никак не входит в базовые свойства

[Alex_C]

Кстати, за всеми этими теоретическими выкладками заметил вот что: у меня положение окна восстанавливается, а его размер - нет. Что не так?

Код:

AbstractLogWindow::AbstractLogWindow(QString winName,
                                     QSettings *s,
                                     bool isModal,
                                     QWidget *parent) :
QWidget(parent)
{
    m_WinSet = s;
    m_WinName = winName;

    uint winState = (isModal? Qt::Dialog : Qt::Window);

    m_WinSet->beginGroup(m_WinName);
    setWindowFlags(Qt::WindowFlags(m_WinSet->value("WondowFlags", winState).toUInt()));
    setGeometry(m_WinSet->value("Geometry", geometry()).toRect());
    m_WinSet->endGroup();
}

AbstractLogWindow::~AbstractLogWindow()
{
    m_WinSet->beginGroup(m_WinName);
    m_WinSet->setValue("Geometry", geometry());
    m_WinSet->setValue("WondowFlags", uint(windowFlags()));
    m_WinSet->endGroup();
}

Смотрю ini-файл - все записывается правильно. Но размеры то почему не восстанавливаются? Т.е. положение - правильное, а размер - нет.