OberonCore

Не то.


Не то


Мама дорогая.

Я бы ничего из этого не советовал бы использовать. Это как раз примеры скорее доказывающие, что Си - это не ООП язык, чем наоборот.

Машинный уровень платформозависим, как никак.

Что значит "не то"? Это примеры объектно-ориентированного программирования на Си, реализованные средствами языка. Зачем имитировать Оберонвэй в Си я не понимаю.

Дык, кто утверждает-то, что Си это ОО ЯП? Тем не менее, ООП-стиль можно реализовать, и можно реализовать ОО ОС. Например, старая добрая Винда относится к объектно-ориентированным ОС, хотя внутри там Си и Асм, как это реализовано можно посмотреть в SDK и в утекших исходниках или в Реактосе. Впрочем, по приведенным мной ссылкам, есть что-то подобное.

Я.

Потому что для использования ООП на Си:

1. Не нужно ничего реализовывать.
2. Есть поддержка со стороны языка в виде проверки типов.

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

Всё-таки есть разница между использованием и ролью. И потом, разве используя ООП в С не надо от каких-то его средств отказаться?

Эт ты зря, ибо сами отцы-основатели и апологеты сего чуда с тобой не согласны, поэтому и приходится заниматься такой занимательной вещью, как закат солнца вручную, и написание каркасов для имитации ООП. Впрочем, как и в Обероне-07.

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

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

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

Самые крутые по моему опыту — это Objective-C и SOM. Про второе можно почитать здесь. Если вратце, там есть движок, который активно принимает участие в создании структур полей и виртуальных таблиц, а программы и библиотеки работают при координации с этом движком. Движок SOM динамически генерирует и обновляет thunks, которые умеют вызывать методы класса. Если у класса нет потомков, можно сделать инструкцию прыжка по известному во время выполнения адресу. Если потомки есть, но нет ни одного такого, где бы этот класс добавлялся через непервый родительский класс, то можно сделать косвенный прыжок по известному смещению в таблице методов. Иначе сделать обычный поиск по таблице.

Это отличается от подхода, когда используются средства только языка C (или C++), и смещения полей дочерних классов зависят от статически вычисленных размеров родительских классов, что делает невозможным добавление полей и методов в родительские классы, не ломая зависимый код, который скомпилирован со старыми размерами.