class QPushButton вместо include <QPushButton>, class VS #include Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Стандартный Переключить на: Линейный

[dsp]

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

т.е.

#include <QPushButton>
#include <QLabel>

,

а пишутся так:

class QPushButton;
class QLabel;

и т.д.

с чем это связано? и что использовать?

[Алексей1153]

это форварды (предопределения) классов для возможности применить паттерн проектирования pimpl (pointer to implementation) . Правда, форварды и не только для этого используются.

А упомянутый паттерн имеет и плюсы, и минусы, поэтому совсем бездумно каждый раз повсюду применять не стоит )

Нормальную статью я с ходу не нашёл. Поищи в тырнете , почитай

[igor_bogomolov]

Это называется "предварительное объявление классов". Делается что бы снизить зависимость между файлами при компиляции и тем самым ускорить саму компиляцию.
Т.е. правило такое, везде где только можно используйте предварительное объявление.

В заголовочном файле (.h) часто ничего не нужно знать о классе, кроме того что он существует.
Поэтому делается предварительное объявление класса class QPushButton.
А вот в файле реализации (.cpp), уже подключаются подробности #include <QPushButton>

[Litkevich Yuriy]

Существенная оговорка.
Предварительное объявление годится только в случае, если в заголовочнике объявляется ссылка или указатель на некий класс. Тогда компилятору достаточно сказать "такой-то класс действительно существует". Т.к. и ссылка и указатель на данной конкретной платформе всегда одинаковое кол-во байт занимает.

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

Примеры, когда без инклюда нельзя

#include <SameClass>

class SubClass : public SameClass
{

...
}

#include <SameClass>

class MyClass
{
...
private:
SameClass var;
}

#include <SameClass>

class MyClass
{
...
public:
    SameClass func_1(); // возвращает значение
    
    func_2(SameClass var); // принимает значение
}

#include <SameClass>

class MyClass
{
...
public:
    SameClass func_1(SameClass *var)
    {
        var->method(); // обращение к члену класса
    }
}

[Алексей1153]

class VS #include

блин, я долго думал, при чём тут студия А "versus" пишется маленькими буквами

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

...но при суровой необходимости и это можно обойти

[Litkevich Yuriy]

.но при суровой необходимости и это можно обойти

как?

[Алексей1153]

Litkevich Yuriy,

например так
хотим класс QMyLineEdit:public QLineEdit

QMyLineEdit.h

class QMyLineEdit;

struct QMyLineEditWrapper
{
   QMyLineEdit* p;
   QMyLineEditWrapper(QWidget* parent=0);
};

QMyLineEdit.cpp

#include "QMyLineEdit.h"
#include <QLineEdit>

class QMyLineEdit:public QLineEdit
{
    Q_OBJECT
public:
    explicit QMyLineEdit(QWidget* parent=0):QLineEdit(parent)
    {
    }
    
    QString text() const;//"трамплин"
};

struct QMyLineEditWrapper
{
   QMyLineEdit* p;
   QMyLineEditWrapper(QWidget* parent):p(new QMyLineEdit(parent))
   {
   }
   
   ~QMyLineEditWrapper()
   {
       delete p;
   }
      
   QString text() const
   {
       return p->text();
   }
};

но тут есть один жёсткий минус - для всех нужных функций нужно будет делать эти трамплины

[kwisp]

как?

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

class CImpl;

class IFace
{
  CImpl* impl_;

public:
  IFace();
  ~IFace();

void one();
void two();
void three();

};

реализация

# include "iface.h"

class CImpl : public Anything
{
public:
void one();
void two();
void three();
};

void  IFace::one()
{
  return impl_->one();
}

void IFace::two()
{
  return impl_->two();
}

void IFace::three()
{
  return impl_->three();
}

[Rocky]

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

...но при суровой необходимости и это можно обойти

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

Может я жестко туплю конечно, либо придираюсь... А в чем приведенный код Алексей1153, kwisp, позволяет обойти то, о чем говорит Litkevich Yuriy? То что вы приводите, называется паттерн проектирования пимпл - ака идиома скрытой реализации. Мне кажется это не есть обход в том смысле в котором имеется ввиду.

Ведь можно не создавать объект на стеке в капсуле класса, а использовать указатель на него. Наследование можно опять-таки заменить через указатель (практически всегда). И тогда тоже не нужно будет подключать хидер с капсулой класса в своем хидере. Вопрос ведь какой, как сделать так, чтобы при наследовании или создании объекта класса на стеке не нужно было включать хидер класса. Держу пари что как-то можно. Но схоу не могу сообразить. Вероятно, тут будет что-то из жесткого хака (типа define private public)...

[Алексей1153]

Rocky,

хидер включать необходимо

да, но включать его надо уже только в файл реализации

А в чем приведенный код Алексей1153, kwisp, позволяет обойти

а обходить в данном случае не нужно. Это было сказано о случае СУРОВОЙ необходимости )) То есть - костыль

Наследование можно опять-таки заменить через указатель (практически всегда).

оу, расскажи, как ?. Особенное внимание удели конструктору, деструктору и виртуальным функциям

Сообщение отредактировал Алексей1153 - 10.2.2011, 11:34

[Rocky]

Цитата(Rocky @ 10.2.2011, 13:28) *
хидер включать необходимо

да, но включать его надо уже только в файл реализации

Алексей1153, ты вырываешь слова из контекста. Если есть класс В, который наследуется от класса А, то хидер класса А обязательно нужно включать в хидере класса В. То что пишешь ты - да. Но если ты будешь наследоваться от QMyLineEditWrapper - тебе опять-таки нужно будет включение хидера с этой структурой. От этого никуда не уйти. А как я понял твою задумку, то что ты сделал - это ответ на вопрос

Наследование можно опять-таки заменить через указатель (практически всегда).

оу, расскажи, как ?.

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

Если есть класс В, который наследуется от класса А, то хидер класса А обязательно нужно включать в хидере класса В

это обход наследования.

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

Хотя, вероятно я придираюсь к словам Фсё, больше не буду))

[Алексей1153]

Алексей1153, ты вырываешь слова из контекста

да нет, не вырываю. Ты , во-первых, сам их жирным выделил. Ну а включать надо - это факт вопрос в том - куда включать. Где хидер будет виден только локально, либо же торчать повсюду

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

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

ну, по затратам памяти и скорости (кхм) наследование абсолютно ничем не отличается от включения мембера с классом, какой был бы у класса-родителя. Но тут становится недоступен или труднодоступен полифорфизм

[igor_bogomolov]

to Алексей1153

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

class QMyLineEdit;
struct QMyLineEditWrapper 
{    
    QMyLineEdit* p;    
    QMyLineEditWrapper(QWidget* parent=0); 
};

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

to Алексей1153, to kwisp
Да в пимпл без предварительного объявления никуда, и поговорить про это интересно. Вот только ТС спрашивал не про это.
Тут скорее можно было написать, что в некоторых случаях без предварительного объявления не обойтись, и показать это на примере пимпла. А вот говорить что можно отнаследоваться от класса class QMyLineEdit:public QLineEdit не сделав в том же файле includ не правильно.

to Алексей1153

Цель пимпла: сделать содержимое хидера реально видимым только в файле реализации

Ты путаешь цели и средства достижения цели. То о чем ты говоришь - это средство/способ решения, а цели у пимпла другие.

[Rocky]

igor_bogomolov, спасибо, хоть ты понял что я пытался сказать

[Алексей1153]

igor_bogomolov, мы просто напросто в ненужные дебри полезли )) А в целом не всё так трагично, как ты воспринимаешь

[kwisp]

по-моему вы ребята уже предвзято к друг другу относитесь. это по градусу сообщения видно.
опять же по-моему ТС разницу между форвардами и инклюдами понял. цель достигнута. это хорошо.

П.С.
что касается моего ответа. Юрию, я наверное действительно не понял, что в точности он спрашивал, и в ответе написал как уйти от включения заголовочника в заголовочник....

[Алексей1153]

по-моему вы ребята уже предвзято к друг другу относитесь

ни грамма ))

[Litkevich Yuriy]

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