Чисто віртуальна чи абстрактна, що в назві?

Обговорюючи питання щодо віртуальних функцій на Stack Overflow, я задумався, чи існує офіційна назва для чистих (абстрактних) та нечистих віртуальних функцій.

Я завжди покладався на вікіпедію для своєї інформації, в якій говориться, що чисті та нечисті віртуальні функції - це загальний термін. На жаль, стаття не підкріплює її походженням або посиланнями.

Цитуючи відповідь Джона Скіта на мою відповідь про те, що чисто і нечисте - це загальний термін, що використовується:

@Steven: Хм ... можливо, але я коли-небудь бачив це в контексті C ++ раніше. Я підозрюю, що хтось про них говорить, швидше за все, має C ++ фон :)

Чи походять терміни від C ++, або вони були вперше визначені чи реалізовані на більш ранній мові, і чи є вони "офіційними" науковими термінами?

ОНОВЛЕННЯ:

Френк Ширар з користю надав посилання на опис основної мови SIMULA 67 (1970). Ця мова, здається, є першою мовою, яка запровадила ключові слова OO як клас , об’єкт , а також віртуальна як формальне поняття. Він не визначає чистого / нечистого або абстрактного , але він підтримує ці концепції .

Хто їх визначив?

Найґард і Дал вперше вжили цей термін в SIMULA 67 Common Base Language . Наприклад, подивіться, наприклад, розділ 2.1 та розділ 2.2.3. (Наскільки я можу сказати принаймні. Але, що стосується ООП, це, мабуть, перше використання цього терміна.)

Отже ... я робив невеликі дослідження. Далі йде невеликий урок історії для зацікавлених. :) Пропустіть до висновку внизу, якщо вас цікавить лише відповідь.

1967 :

SIMULA 67 , перша об'єктно-орієнтована мова програмування, визначає ключові слова як клас , об'єкт , виклик за посиланням , виклик за значенням та віртуальний .

Система успадкування SIMULA спочатку була відома іншою назвою, конкатенацією (а пізніше відомою як префіксація ), посилаючись на той факт, що код супертипів був скопійований і «з'єднаний» з кодом підтипів. Пізніше з'явилася інша форма системи успадкування - делегування , де виклики делегуються відповідно до правильного типу.

Віртуальна, швидше за все, відноситься до процесу, який потрібно виконати, щоб відправити виклик до правильної реалізації за допомогою віртуальної таблиці методів . Це віртуально порівняно з фіксованою / конкретною реалізацією.

1971 :

Ніклаус Вірт пише про концепцію, визначену як поетапне вдосконалення . В основному пояснюється, як розділити програму на часткові рішення, на які можна розширити.

1974 :

Це найбільш ранній документ я знайшов якісь монети терміна абстрактних типів даних від Лиска .

Абстрактний тип даних визначає клас абстрактних об'єктів, який повністю характеризується операціями, доступними для цих об'єктів. Це означає, що абстрактний тип можна визначити, визначивши характеризуючі операції для цього типу. Коли програміст використовує абстрактний об'єкт даних, він переймається лише поведінкою, яку демонструє цей об'єкт, але не будь-якими деталями того, як така поведінка досягається за допомогою реалізації.

У цьому документі також визначений кластер операцій, який, здається, визначає те, що ми зараз знаємо як інтерфейс .

Цікава наукова термінологія (стаття від 1996 р.):

Спадкування : механізм більш низького рівня, за допомогою якого об'єкти або класи можуть обмінюватися поведінкою або даними.

Підтипізація : виражає концептуальну спеціалізацію. Конкретна форма успадкування, яка також називається інтерфейс спадкування .

Принципи абстракції : Процес організації наших знань про область застосування в ієрархічному ранжируванні впорядкованих абстракцій, щоб отримати краще розуміння проблем, що стосуються.

Частково реалізовані абстракції : абстракції, визначення яких цілеспрямовано залишено неповними.

Анотаційні класи : Конкретний термін для частково реалізованого класу в об'єктно-орієнтованих системах.

Нестримне успадкування : дозволяє переглядати (або навіть видаляти) операції в підкласах.

Суворе успадкування : Послідовно сумісне спадкування.

Висновок :

Абстрактний клас - найзагальніший термін, що використовується в об'єктно-орієнтованих системах. Здається, чисті та нечисті віртуальні функції походять лише від C ++. Наприклад, це інтерв'ю зі «Струструпом» робить здається, що він вигадав умови. У наукових працях використовується більш загальна термінологія.

Віртуальний походить від SIMULA, що спричиняє широке поширення використання, але це не загальний термін. У ньому вже визначені деталі реалізації. Говорити з точки зору видів спадкування є більш доцільним. Невіртуальний за замовчуванням відповідає суворому успадкуванню за замовчуванням, тоді як віртуальному за замовчуванням відповідає нестримне успадкування .

Хтось зацікавлений у налаштуванні вікіпедії ? :)

У C ++ функції-учасники, які динамічно пов'язані, і, таким чином, можуть бути замінені підкласом, називаються "віртуальними". Віртуальні функції, які абсолютно повинні бути відмінені, називаються "чистими віртуальними". Зауважте, що у чистої віртуальної функції може бути тіло, хоча часто цього немає. Клас, який має принаймні одну чисту віртуальну функцію, називається "абстрактною" і не може бути ініційованим, лише походить від.

Я здогадуюсь, що причина, по якій віртуальні функції називаються віртуальною, полягає в тому, що невідомо, яка фактична функція буде викликана під час компіляції. У певному сенсі віртуальний виклик функції "не існує" під час компіляції.

Я також здогадуюсь, що причина, що термін "абстрактний" використовується для класу з чисто віртуальною функцією, полягає в тому, що ви не можете мати жодних об'єктів цього класу. У певному сенсі це абстрактне поняття, віддалене від конкретного світу предметів.

Редагувати: інші мови.

Щодо питання про те, наскільки загальним є термін "віртуальний", ось два мої центи. У Smalltalk всі функції використовують динамічне прив'язування, тому там усі вони є віртуальними, і немає необхідності в спеціальному терміні чи мовному ключовому слові. У Java, якщо я не помиляюсь, компілятор автоматично вирішує, чи потрібно використовувати динамічне прив'язування, так що для програміста немає відмінності, а отже, і немає «віртуального» ключового слова.

У C ++ необхідне розмежування між віртуальним та невіртуальним, оскільки програміст вирішує, коли потрібно використовувати динамічне прив'язування, щоб заощадити накладні витрати, коли це не потрібно.