Классы

поищи хорошенко, оно есть

ок.

и какаго цвета не существующий дракон?

есть некоторая неточность в обьяснении ооп в вузах которая приводит к ...

ооп не про классификацию (хоть и наследование и приводит к иерархии)

ооп про взаимодействие сущьностей дающий результат.

заострение на наследовании в «учебных(читай неправильно подобраных)» ....

кстати и С++ сильнее чем в динамических проблема разрушения иерархии . так как по мере переписывания поля мигрируют к родителям в результате страх и ужас.

Согласен по поводу закрытости, в C будет так

struct A
{
  /* considered to be private */
  int _a;
}
static inline int
geta ()
{
  return _a:
}

Можешь показать? Например, унаследуй свой ромб ещё и от IDisposable.

Я уже сказал, что множественное наследование не знаю как делать и, по-моему, множественное наследование - есть костыль, решающий неоднозначности наследования типа тех, что в предыдущем сообщении с трапецией и параллелограммом.
Поясню свою мысль. Если рассматривать классы как сочетание данных и интерфейсов, то различия между между данными родителя и потомка могут содержать больше информации, нежели сам потомок или, в общем случае, наследник содержит информацию, которой мог бы не содержать.
Пример. Есть #стол какого-то там @цвета, являющийся потомком #мебели. А есть его потомок, - #стол_поломанный с тремя отломанными ножками и крышкой. Если #стол имеет сто ножек, то ничего страшного нет. А если #стол имеет 4 ножки и #поломанных_столов много, то более 75% памяти расходуется впустую. Ежели #стол имеет 3 ножки, а #стол_поломанный наследует данные ещё и от #стол_бесцветный, то имеется 100%-4байта впустую занимаемой памяти. Это удобно для программиста, так как не нужно думать, но не удобно для машины. Поэтому ООП требует начального проектирования, так как элементы этого дерева не являются независимыми.

Вряд ли, если есть множественные интерфейсы. У тебя есть? )

Нету, как и множественного наследования)

Тогда нельзя говорить, что у тебя есть наследование - типы у тебя не наследуют поведение.

Они его не наследуют неявно. Всё, что должно наследоваться, записано явно в виде функций-оболочек.

В C++ проблем будет гораздо меньше: виртуальные таблицы будут заполнены правильно, и компилятор предупредит обо всех теперь невалидных приведениях типов.

А я ничего не имею против C++, наследование или правильнее назвать «костыль» мне понадобился лишь в одном месте программы, где, сохранив читаемый интерфейс получилось реализовать различную обработку структур данных и иметь возможность выделить каждый такой обработчик в отдельный модуль, потом это должны быть библиотеки, добавляемые к проекту без его пересборки. Возможно ли так было сделать в C++ пока не разбирался.

Я сразу сказал, что не нужно делать ООП на C, просто при решении конкретной задачи, при необходимости можно использовать некоторые его механизмы, но желательно так, чтобы никто снаружи не увидел.) Код для решения сингулярных уравнений выглядит не менее трудночитаемым на любом ЯП, так что, применение таких методов/костылей в малых количествах и внутри закрытых модулей, по-моему, не так и страшно.

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

Вообще я не спорю, что в C возможно ООП - сам люблю этим заниматься. Просто хотел показать, что не всё можно сделать в C, что можно в C++.

Плюс, знания всяких таких костылей могут пригодится на встраиваемых системах и там, где не доступен C++.

Всё, у меня начался ооп мозга...)

struct A
{
  /* considered to be private */
  int _a;
};

static inline int
geta (const struct A* a)
{
  return a->_a:
}

И чем второй пример отличается от первого?

В способе использования - ничем, с точностью до того, что в си объект передаётся аргументом, а в С++ он слева dot operator (в С++ всё равно нет мультиметодов). Основное отличие в сигнатурах функций и методов - в си это func(type*, ...), а в C++ - meth(...) или type::meth(...), явной передачи type* нет, так как метод уже принадлежит классу содержащему нужные поля. Нет и доступа к полям с помощью (->), есть непосредственное использование полей. То есть то что в си независимо, в С++ зависимо - это, во-первых, задаёт более жесткое поведение, и, во-вторых, связность методов и данных позволяет образовывать подтипы к которым применимы методы предка.

Вот тот же пример в CLOS:

(defstruct monster
  name
  health)

(defgeneric hit (object diff))

(defmethod hit ((object monster) diff)
  (decf (monster-health object) diff))

(defun test-1 ()
  (let ((ogr (make-monster :name 'ogr :health 100)))
    (format t "~S~%" ogr)
    (hit ogr 10)
    (format t "~S~%" ogr)))

;; > (test-1)
;; #S(MONSTER :NAME OGR :HEALTH 100)
;; #S(MONSTER :NAME OGR :HEALTH 90)
;; NIL

(defgeneric move (object x y))

(defun test-2 ()
  (let ((ogr (make-monster :name 'ogr :health 100)))
    (format t "~S~%" ogr)
    (move ogr 10 20)
    (format t "~S~%" ogr)))

тут ближе к си - методы и классы независимы. С другой стороны, test-2 компилируется без всяких предупреждений, хотя метод move для класса monster не специфицирован.

Другие отличия - возможность перегрузки методов, возможность написать clean-up код в деструкторе, что-то ещё?

Это еще хорошо когда хоть так рассказывают... В моем вузе на ООП 2 семестра показывали как в делфи менюшки на формочку таскать

В Си будет не так. В Си в .h'нике будет только struct A; поэтому пользователь кода вообще не увидит содержимого.

Тогда инлайна не будет.

Вот у меня в рогалике на данный момент нет ни одно класса

Зато куча switch'ей. И чтобы добавить новый тип юнита, ты обходишь все switch'и и добавляешь в них код. Угадал?

нет, свитчей тоже нет. Но теперь появились классы.

Таким образом, всё сводится к различному синтаксису - в методы this неявно передаётся и неявно используется. Тогда из твоего примера можно сделать вывод, что классы - это только синтаксический сахар для более краткой записи (ибо других отличий нет). Мне же было интересно, что есть принципиально нового.

возможность перегрузки методов

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

возможность написать clean-up код в деструкторе

В си аналогов нет, но, допустим, в GNU C есть атрибут cleanup, работающий с переменной любого типа. И наоборот, в классах явы такой возможности нет. То есть классы как бы ни при чём.

ООП в сторогом его понимании и было изобретено как раз в 18 веке

позже. много позже. не раньше Эмми Нётер уж точно

ЯП которые бы поддержали некую запись axiom \a, b -> a + b == b + a

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

можно обойтись методами

что такое метод?

class test{ void metod(); };

но вообще у меня были не методы, а функции.

Таки не нужны.

Отрепортил за спам.

Отрепортил за спам.

Здравствуйте. Как ваше ничего ваши отношения с клубом-2?

Хватит спамит на лоре.

Хватит спамит на лоре.

Почему?

Набивать посты тоже не стоит.

Набивать посты тоже не стоит.

Тогда выходи в jabber xmpp.