Просмотр полной версии : Объектно-ориентированные принципы на С
Давно меня мучали вопросы - как реализовать ООП на С.
И вот я, наконец, попробовал это сделать.
Пока есть несколько "классов":
окно (базовый класс, так как эта библиотека для интерфейса)
меню (потомок окна)
драйвер экрана (пока ZX обычный)
драйвера клавиатуры (PS2 и ZX)
Реализован событийный интерфейс. Стека окон пока что нет.
Демо окошек-менюшек тут: https://github.com/salextpuru/sdcc-noinit/blob/master/apps/test-libui/testui.c
Собственно, библиотека тут: https://github.com/salextpuru/sdcc-noinit/tree/master/libsrc/libui
Не пинайте ногами, что всё крайне медленно и неоптимально. Я проверял принципы. Хотя, для многих вещей это уже годится - утилиты разные и проч.
Общие принципы:
Один класс - один файл.
Области видимости разграничены на private (с помощью static функций и переменных) и public.
Думаю, перспектива есть. Было бы время:)
Error404
28.04.2018, 13:11
Как шутят в народе, "У дураков мысли сходятся". :)
Очень правильный подход к разработке, почему-то тут редко встречаемый. Делал похожее и тоже на С для CP/M (https://github.com/serge-404/AltairDOS/tree/master/App/source/fat) когда экспериментировал с 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. В котором немного описано что это и как рабоатет.
С то с чего "дерьмо"?
- - - Добавлено - - -
Я просто сейчас реализую все мысли, что приходят в соответствии с наличием времени. По-другому никак пока что:(
Error404
28.04.2018, 14:01
В смысле "не пойми на чем"? На SDCC. Другого для спека нет.
Не только SDCC. Большинство CP/M C компиляторов умеют выставлять базу(адрес) не только на 100h, но и на другие адреса, для Спека будут более высокие. Например тот же используемый мной Hitech C (который кстати нативный ANSII C Z80 компилятор, т.е. для компиляции не нужен PC с 100500 Gb ОЗУ, достаточно Z80 с его 64к :) )
Си полное дерьмо вообще.
Я всегда больше любил Паскаль. Но как говорится - жизнь диктует, для С несравнимо больше проектов в исходниках, которые можно портировать на Z80, притом написанных не маргиналами, а людьми с порядком в голове. Да и компиляторов Паскаля для Z80 пока что нормальных нет (сравнимых по мощности с тем же Hitech C). Вот я взял FatFS (по фукционалу на порядок лучше всех известных мне вариантов FAT32 на Z80) и за два вечера запустил. А возьми какой-нить вариант для ассемблера (других то нет) от тутошних умельцев в неповторимом стиле "сто мнемоник в строке", и что называется усрись в итоге брось не сделав.
ESP пока никак. Железка лежит.
Я с нового года в ауте. Только последнюю неделю время немного было - написал что получилось вот с окнами.
shurik-ua
28.04.2018, 17:19
Вот я взял FatFS (по фукционалу на порядок лучше всех известных мне вариантов FAT32 на Z80) и за два вечера запустил.
и сколько она занимает места, и сколько требует для работы ?
А ты не мог бы свою переделку фатфс в исходниках выложить?
Error404
28.04.2018, 20:43
и сколько она занимает места, и сколько требует для работы ?
В бинарнике сама FatFS (т.е. без учета stdio и интерфейса) в коде Z80 занимает что-то порядка 18 кб в максимальной RW версии если компилировать Hitech C (SDCC не пробовал). Максимальная - это с поддержкой даты и всех атрибутов файлов, дописыванием файлов, созданием всех объектов (каталогов/файлов), поддержкой партиций схемы MBR (т.е. совместимо с PC). Без длинных имен, я их не включал т.к. в CP/M куда я копирую поддерживаются только файлы с именами "8.3". На современных микроконтроллерах тот же код помещается в 4кб (если верить автору). Версия RO или без партиций будет занимать меньше. Главная причина большого размера кода - то что там 32-битная арифметика, которая на Z80 компактно не реализуема.
А ты не мог бы свою переделку фатфс в исходниках выложить?
Поскольку делалось все это в 2008-2010г.г., то там FatFS версии 0.4 как базовая (2008г) с патчами от 0.5 и 0.6 (до 2010г.). А сейчас у автора вроде уже 0.99 есть, но я более поздние патчи не имплементировал (т.к. приходится разбираться и кое-что править в типах), т.к. исправления серьезных ошибок там вроде не было, но автора уже там понесло в юникоды, длинные имена, навороченный разбор строк он зачем-то включил, в-общем лишние на мой взгляд вещи.
Все лежит тут в общей кучке и FatFS (модули FF.c, FFP.c) и те модули что я упоминал постом ранее где мои попытки на тему "псевдо-ООП":
https://github.com/serge-404/AltairDOS/tree/master/App/source/fat
Добавил свойства объектов (активный-неактивный и активируемый-неактивируемый).
Получилось вполне себе неплохо. Тормозно только. Но я предполагаю сделать стек окон и вывод на теневой экран. Тогда должно быть без подмаргиваний.
ТАПКА тут 65175
Исходник тут: https://github.com/salextpuru/sdcc-noinit/blob/master/apps/test-libui/multimenu.c
Русский язык - в KOI8-R. Это если у кого в исходнике ероглифы видны.
Пока разрабатывал - осуществил давно желаемую доработку:
Введена переменная LIBS в build.mk для программ.
Позволяет задавать индивидальный набор бибилиотек, используемый
программой. Если переменная LIBS не задана, используются ВСЕ библиотеки.
Очень удобно, если одновременно собираются программы с конфликтующими либами.
Ну и время линковки сокращается немного.
- - - Добавлено - - -
Вот такой интерфейсик получился.
Исходники тут как всегда: https://github.com/salextpuru/sdcc-noinit/tree/master/apps/test-libui
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot