Зачем в абстрактном базовом классе создавать конструктор?

Question

[sddvxd]

Здравствуйте!
В литературе что я читаю автор в АБК создает конструктор:

class ABC{
public:
    ABC(tralala &, trololo);
    ....
};

Производный класс:

class Test : public ABC{
public:
    Test(trololo, tututu &):ABC(tututu &, trololo);
};

Вопрос: зачем создавать явный конструктор для АБК, если его объект создать нельзя (при наличии чистой виртуальной функции конечно) и вопрос второй: что за странный вызов конструктора АБК в конструкторе производного класса? Спасибо

Comments

[Roman]

Что Вы читаете?

[sddvxd]

Роман, Стивен Прата

[Roman]

У Парты

// Абстрактный базовый класс 
class AcctABC 
{ 
private: 
std::string fullName; 
long acctNum; 
double balance; 
...

и т.д. у него есть закрытые члены, доступ к которым имеет только сам класс

Answer 1

[Mercury13]

Абстрактные классы делят на интерфейсы и частично реализованные. Грань между ними такова:
• Интерфейс не имеет данных.
• У интерфейса все неабстрактные виртуальные методы представляют собой или эталонное поведение, или самую частую реализацию. В обоих случаях, если что, их надо не расширять, а переписывать с нуля.

Так вот, для интерфейсов таких конструкторов, разумеется, не нужно.

Например, между абстрактным потоком и файлом Win32 может быть такая иерархия: Stream → HandleStream → File. Stream — интерфейс, даже если там есть что-то типа

// virtual
unsigned long long Stream::remainder() const { return size() - pos(); }

HandleStream содержит уже данные (дескриптор Win32), и это уже частично реализованный класс, который крутится вокруг этого дескриптора: в деструкторе вызов CloseHandle, конструктор может принимать дескриптор, полученный каким-то «левым» образом.

HandleStream::HandleStream(HANDLE aHandle) : fHandle(aHandle) {}
HandleStream::~HandleStream() { close(); }

void HandleStream::close()
{
  if (Handle != INVALID_HANDLE)  { // не помню, как там эта константа в Win32
    CloseHandle(fHandle);
    fHandle = INVALID_HANDLE;
  }
}

Вот в таких полуреализованных классах, разумеется, конструктор может инициализировать те данные, которые там есть.

Comments

[sddvxd]

т.е. вызов конструктора в списке инициализаторов это нечто иное как изменение базового объекта в иерархии наследования, просто вызывая конструктор абстрактного класса мы меняем поведение вызывающего объекта?(производного от абстрактного)

[Mercury13]

sddvxd, Нет, мы даём недореализованному классу корректно инициализировать те куцые данные, которыми он распоряжается.

[Mercury13]

sddvxd, Если HandleStream распоряжается дескриптором Win32 — пусть он будет инициализирован тем, что надо.

File::File(const wchar_t* aFname, OpenMode aMode) : HandleStream(INVALID_HANDLE)
{
  HANDLE newHandle = CreateFile(…);
  if () {
    open(newHandle);
  } else {
    // придумаем, что делать с ошибками
  }
}

[sddvxd]

Mercury13, под недореализованным классом вы предполагаете производный от базового класса класс?

[sddvxd]

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

[sddvxd]

Mercury13, сейчас тщательно перечитал ваш ответ и понял вот что:
- Для абстрактных интерфейсных классов не нужно делать вызов конструктора и производном классе из-за того, что в нем нет данных, а только функции
- Вызов конструктора родителя делается для изменения данных такового, в случае с File проверяем доступность дескриптора вызовом конструктора HandleStream

[Mercury13]

sddvxd, Недореализованный класс создаёт некий кусок функциональности, оставляя какие-то места конкретным потомкам.
Второй пример, из Delphi: TComponent реализует постановку на форму, загрузку и сохранение. TGraphicControl даёт компоненту графический вид, TWinControl — дескриптор окна Win32, TCustomControl — ещё кучу функций, позволяющих написать свой компонент с нуля.

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

[Mercury13]

sddvxd,

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

Верно. Только «интерфейсный класс» не говорят, и в данном случае интерфейс — это как «интерфейс RS-232», то есть стандартный метод взаимодействия. Никаким пользовательским интерфейсом тут и не пахнет.

Вызов конструктора родителя делается для изменения данных такового, в случае с File проверяем доступность дескриптора вызовом конструктора HandleStream

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

[Mercury13]

sddvxd,
Утилита.

void Stream::writeW(uint16_t x) {
  write(&x, 2);
}

Эталонная реализация — функция remainder из ответа.

Реализация, верная для большинства потомков,— ну, например.

void Stream::seek(uint64_t x) { throw std::logic_error("This stream cannot seek!"); }

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

[sddvxd]

Mercury13,

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

Насколько я знаю, имея такую иерархию наследования - Stream → HandleStream → File создаем объект File - вызываются конструкторы сверху вниз. От базового к текущему, чтобы создать данные из родителей. Получается, если мы делаем такую манипуляцию: File::File(...) : HandleStream(...) мы вызываем конструктор прошлого родителя, а значит порядок вызова конструкторов будет такой:
Stream → HandleStream → File - не изменился, поскольку конструктор не вызывается, пока не выполнится код со списком инициализаторов, а если мы сделаем так: File::File(...) : Stream(...), то порядок поменяется на такой:
Stream → HandleStream → Stream → File - я правильно понимаю?

[Mercury13]

sddvxd,

а если мы сделаем так: File::File(...) : Stream(...)

Не позволяет такого Си с крестами. Мы обязаны вызвать какой-то отцовский конструктор: хоть без параметров, но какой-то нужно.
Остальное верно.

[sddvxd]

Mercury13, спасибо большое за объяснение

[Mercury13]

sddvxd, Насчёт эталонной реализации remainder().
Бывают классы, не знающие ни размера, ни позиции, но знающие остаток (скажем, порт).
Бывают классы, для которых вызов размера и позиции — это расточительство (скажем, буфер памяти).
Но в целом такая эталонная реализация говорит, что такое remainder() и как его считать.

…Но это уже офтоп для нашей темы — недореализованного класса.