Объектно-ориентированные принципы на С

Давно меня мучали вопросы - как реализовать ООП на С.
И вот я, наконец, попробовал это сделать.

Пока есть несколько "классов":

окно (базовый класс, так как эта библиотека для интерфейса)
меню (потомок окна)

драйвер экрана (пока ZX обычный)
драйвера клавиатуры (PS2 и ZX)

Реализован событийный интерфейс. Стека окон пока что нет.

Демо окошек-менюшек тут: https://github.com/salextpuru/sdcc-n...libui/testui.c
Собственно, библиотека тут: https://github.com/salextpuru/sdcc-n...r/libsrc/libui

Не пинайте ногами, что всё крайне медленно и неоптимально. Я проверял принципы. Хотя, для многих вещей это уже годится - утилиты разные и проч.

Общие принципы:
Один класс - один файл.
Области видимости разграничены на private (с помощью static функций и переменных) и public.

Думаю, перспектива есть. Было бы время:)

Как шутят в народе, "У дураков мысли сходятся". :)

Очень правильный подход к разработке, почему-то тут редко встречаемый. Делал похожее и тоже на С для CP/M когда экспериментировал с IDE/FAT:
- экран VT52 с собственной текстовой буферизацией чтобы организовывать буфер окон без лазания в видео-ОЗУ или в какие-то расширенные свойства VT-52 (использую только базовые искейпы VT - вывод символа, основные очистки экрана/строк и позиционирование курсора) отчего программа нормально отображается даже в Hyperterm Windows если заломиться им с Винды в CPM Ориона по RS-232 (модуль screen.c)
- псевдообъектное программирование на структурах и адресах процедур (типа методы), "наследование" - расширением родительской структуры новыми членами и обращение к методам через typecast.
- "объекты" оконные (стек окон есть) и не оконные (типа TStrings), оконным можно рассылать сообщения (messages) а-ля как у Борланда в VCL было сделано и эти сообщения обрабатывать в тех "классах" (windows.h, controls.h), основной цикл оконного приложения выглядит прям как в VCL CBuilder

Код:

---

void ApplicationLoop()
{
  short Msg;
  short Param;
  while (GetMessage(&Msg, &Param)) {
    SendMessage(ActiveWindow(), Msg, Param);    /* DispatchMessage(&Msg); */
  }
}

---

- сделал несколько оконных объектов (Окна модальные и немодальные, листбокc, кнопка) - минимум для двухпанельного коммандера, и сам коммандер - оболочку над популярной FatFS от ELM Chan - моего порта под CP/M (menu2.c, menu1.c). Очень понравилась получившаяся организация труда: вместо намолачивания функционала "по месту", заранее пишешь объекты со свойствами, а далее в командере назначаешь их связи, и любое изменение (например количество столбцов в панели=листбоксе - full/brief, или количество кнопок на форме) уже элементарно: присвоил свойству значение, вызвал Object.Update() и всё заверте....

ЗЫ. Как там наш :) ESP-адаптер?

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

Цитата:

---

Сообщение от Шынни

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

---

В смысле "не пойми на чем"? На SDCC. Другого для спека нет.
И там же есть pdf в каталоге doc. В котором немного описано что это и как рабоатет.

С то с чего "дерьмо"?

- - - Добавлено - - -

Я просто сейчас реализую все мысли, что приходят в соответствии с наличием времени. По-другому никак пока что:(

Цитата:

---

Сообщение от SfS

В смысле "не пойми на чем"? На SDCC. Другого для спека нет.

---

Не только SDCC. Большинство CP/M C компиляторов умеют выставлять базу(адрес) не только на 100h, но и на другие адреса, для Спека будут более высокие. Например тот же используемый мной Hitech C (который кстати нативный ANSII C Z80 компилятор, т.е. для компиляции не нужен PC с 100500 Gb ОЗУ, достаточно Z80 с его 64к :) )

Цитата:

---

Сообщение от Шынни

Си полное дерьмо вообще.

---

Я всегда больше любил Паскаль. Но как говорится - жизнь диктует, для С несравнимо больше проектов в исходниках, которые можно портировать на Z80, притом написанных не маргиналами, а людьми с порядком в голове. Да и компиляторов Паскаля для Z80 пока что нормальных нет (сравнимых по мощности с тем же Hitech C). Вот я взял FatFS (по фукционалу на порядок лучше всех известных мне вариантов FAT32 на Z80) и за два вечера запустил. А возьми какой-нить вариант для ассемблера (других то нет) от тутошних умельцев в неповторимом стиле "сто мнемоник в строке", и что называется усрись в итоге брось не сделав.

ESP пока никак. Железка лежит.
Я с нового года в ауте. Только последнюю неделю время немного было - написал что получилось вот с окнами.

Цитата:

---

Сообщение от Error404

Вот я взял FatFS (по фукционалу на порядок лучше всех известных мне вариантов FAT32 на Z80) и за два вечера запустил.

---

и сколько она занимает места, и сколько требует для работы ?

А ты не мог бы свою переделку фатфс в исходниках выложить?

Цитата:

---

Сообщение от shurik-ua

и сколько она занимает места, и сколько требует для работы ?

---

В бинарнике сама FatFS (т.е. без учета stdio и интерфейса) в коде Z80 занимает что-то порядка 18 кб в максимальной RW версии если компилировать Hitech C (SDCC не пробовал). Максимальная - это с поддержкой даты и всех атрибутов файлов, дописыванием файлов, созданием всех объектов (каталогов/файлов), поддержкой партиций схемы MBR (т.е. совместимо с PC). Без длинных имен, я их не включал т.к. в CP/M куда я копирую поддерживаются только файлы с именами "8.3". На современных микроконтроллерах тот же код помещается в 4кб (если верить автору). Версия RO или без партиций будет занимать меньше. Главная причина большого размера кода - то что там 32-битная арифметика, которая на Z80 компактно не реализуема.

Цитата:

---

Сообщение от SfS

А ты не мог бы свою переделку фатфс в исходниках выложить?

---

Поскольку делалось все это в 2008-2010г.г., то там FatFS версии 0.4 как базовая (2008г) с патчами от 0.5 и 0.6 (до 2010г.). А сейчас у автора вроде уже 0.99 есть, но я более поздние патчи не имплементировал (т.к. приходится разбираться и кое-что править в типах), т.к. исправления серьезных ошибок там вроде не было, но автора уже там понесло в юникоды, длинные имена, навороченный разбор строк он зачем-то включил, в-общем лишние на мой взгляд вещи.
Все лежит тут в общей кучке и FatFS (модули FF.c, FFP.c) и те модули что я упоминал постом ранее где мои попытки на тему "псевдо-ООП":
https://github.com/serge-404/AltairD...App/source/fat

Добавил свойства объектов (активный-неактивный и активируемый-неактивируемый).

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

ТАПКА тут Вложение 65175

Исходник тут: https://github.com/salextpuru/sdcc-n...ui/multimenu.c
Русский язык - в KOI8-R. Это если у кого в исходнике ероглифы видны.

Пока разрабатывал - осуществил давно желаемую доработку:

Введена переменная LIBS в build.mk для программ.
Позволяет задавать индивидальный набор бибилиотек, используемый
программой. Если переменная LIBS не задана, используются ВСЕ библиотеки.

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

- - - Добавлено - - -

Вот такой интерфейсик получился.

Исходники тут как всегда: https://github.com/salextpuru/sdcc-n...pps/test-libui