Расширение языка C поверх C89/99

Objective C?
Вполне себе Си с классами.
Да и что тебе мешает писать на Си++, но не использовать возможности, которые тебе не нравятся? Всё лучше чем noname велосипед.

Какой-то язык, расширенная версия Си, с поддержкой классов и многого другого.

Cello?

Нене, точно был проект, то ли cecil назывался, но я посмотрел это отсылка к Mono, а для Си почему то нет. Был какой-то даже более прокачанный расширятор языка Си, по типу прекомпилятора

Дадада, оно! Вспомнил! https://github.com/orangeduck/Cello

А то ищу cecil, название похожее да не то

Для некоторых вещей можно использовать «библиотеки» stb — для базовых контейнеров, например, есть stb_ds.

Но вообще, Qt — это такой мегакомбайн, что единой замены не найти, придётся объединять кучу разных библиотек, как ни крути.

И вопрос,

Может есть еще хорошие классы для работы с памятью и массивами, но не STL, а что то ближе к Qt?

Что в данном случае имеется в виду, и чем не устраивает STL?

Cello это библиотека, и не для C89/99 а для GNU99 или GNU11, насколько я помню.

Если чё можешь смело Даниэлю контрибутить, писать на почту и гитхаб с вопросами. Он отзывчивый и если вопросы не поверхностные то помогает и отвечает. Только заранее скажу, на вопросы. А как работает вот эта функция или типа того будет игнор, так как подразумевается что если чё тебе в исходники заглянуть не в падлу =)

Библиотека да, но по ощущениям от использования это надстройка над языком, хотя по сути это оно и есть ибо макрос макросом погоняет. Ну и типизационный хак который он наверное во все свои проекты засунул тоже как надстройка выглядит. Понятное дело что это просто по ощущениям, но, ну ты понял =)

Cello игрушка бесполезная, там ужасные контейнеры, строки, неюзабельно в общем.

Графику заменю на Nuklear

Файловый диалоги можешь сделать на базе filebrowser.c из примеров. В метапроге так и будет кстати.

а вот чем заменить базовые классы Core, типа контейнеров?

Лучше статикой обойтись. Вообще хорошо бы подошел glib.. %) Есть такое.

• https://habr.com/ru/post/324210/
• https://troydhanson.github.io/uthash/

Вообще есть chicken lisp который «компилируется» в С. Из него так же удобно юзать сишные либы. И под него уже есть либа для nuklear.

https://github.com/wasamasa/nuklear

Еще есть Nim, его тоже можешь попробовать.

Не начал ещё «пилить свой форк Cello»? Назвать можешь Ollec, или что-то вроде того.

https://github.com/orangeduck/Cello

Так это игрушка. Годится только как PoC, и просто для фана.

Старый C++ все равно будет вменяемей.

чем заменить базовые классы Core, типа контейнеров

Контейнеры в Qt отстойные, используй STL

Так это игрушка. Годится только как PoC, и просто для фана. Старый C++ все равно будет вменяемей

Да, соглашусь лучше старый но проверенный плюс, почитал и там реально джастфофан в этом cello

А еще интересует, чем бы заменить Qt?

<troll>rust</troll>

На самом деле не на что. Ибо C++ std убога.

А Vala можно? Оно требует Glib, а на целевой системе его нет. Вижу протухший Vala-posix profile, без Glib, но оно протухло и https://github.com/radare/posixvala тоже

Vala намертво прибита к Gnome и Glib или всё таки есть вариант работать с этой штукой без Glib?

Или же, просто формировать файлы на Linux где всё это есть, но потом компилировать на таргете.

Ладно, тема решена. Нашел что искал, cello лишь исследовательский проект, а vala-posix тоже померло

Есть ещё язык Cyclone.

Зачем? \O_o/

P.S. Хотя сарказм я понял, слишком часто я говорил что бла бла бла мой форк Corange бла бла бла. Хотя это было из хороших побуждений, мне казалось что будет правильно уточнять что то над чем я пыхчу не чисто мой проект. Но постоянно упоминать это наверное не стоит всё же =)

Так а что нашел-то?

Vala намертво прибита к Gnome и Glib или всё таки есть вариант работать с этой штукой без Glib?

К GLib да, это синтаксический сахар поверх объектной системы GLib, по сути. К GNOME это какое отношение имеет (кроме того, что GNOME использует и GLib, и Vala)?

https://github.com/Qqwy/raii_with/ такие вот костыли есть для RAII

Несерьезный проект Cello, и Vala с брошенной поддержкой posix-only варианта...

А еще интересует, чем бы заменить Qt? Нет возможности там Qt 5 использовать

А Qt4? :)

Если тебе нужна гуйня, пиши на пхытоне. И не парься. Все равно гуйня — нафиг не нужная шняга. Она может свистеть и пердеть, лишь бы нижний уровень нормально работал.

У него старая QNX на работе, поэтому такой странный выбор.

Посмотри Python, Gravity, Wren, Lua. Можно легко прикрутить графику как во всяких LÖVE

И как ему nuklear юзать из этих язычков? Это важная вещь ж.

Он на сишке хочет писать, так? Так и юзать. Все эти языки на Си написаны. Берёшь и дёргаешь из си кода рантайм этих языков + твой nuklear, не пробовал так?

Проще повеситься чем писать либу для дерганья nuklear, там же не просто функции, а enum, define, макросы... Бесполезная работа, когда можно просто взять C и начать писать, или взять язык который компилируется в С и позволяет вставки сделать например. Хотя мне кажется он меня заблочил ваще, и не увидит этот разговор.

Ну хз, можно как ты хочешь, просто прокинуть свой стейт и юи в эти языки (типа wren), и из них рулить скриптами, не всем, а всякой байдой, которую часто переписываешь типа UI/дёрганья http либ.

Ой, спасибо за ссылку. Какой классный чувак. Посмотрел, у него занятная книжка есть «build your own lisp».

Чем-то «zen style programming» напоминает, тока ещё для более чайников. Будет чем коротать вечера.

Пробовал написать рендер Nuklear для Photon? Я по развлекался с PtRaw. В принципе работает, но есть проблемы.

P.S. Где работаешь?

Какой кошмар. Пойду почитаю Boost.Spirit, авось полегчает.

Хрен редьки не слаще

Пробовал написать рендер Nuklear для Photon?

Только на Qt на Linux для тестов, работой завалили и не попробовать

Я по развлекался с PtRaw

Где про него почитать?

В принципе работает, но есть проблемы

Какие? :)

Где работаешь?

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

Еще хотю это помацать https://littlevgl.com

Навскидку: https://github.com/stetre/moonnuklear

Правда, оно завязано на другие либы из семейства, но тем не менее. Для nuklear всё равно понадобится какой–нибудь бэкенд, так что как не крути придётся пихать либо glfw, либо SDL, либо самому костылить.

…почитал и там реально джастфофан в этом cello

Так в чём проблема–то? Только в том что в ридмишке так написано? Устриц не ел, но осуждаю?

Или реально взял, попробовал, и что–то не устраивает, ломается, не компилится?

Попиливал в свободное время. PtRaw это Canvas, на котором можно рисовать. Читать в доках на qnx

http://www.mikecramer.com/qnx/qnx_4.25_docs/photon114/prog_guide/draw.html.

Нужен double buffer, иначе всё будет мигать. Проблему решает PtDBContainer, в который нужно поместить PtRaw. Но, PtDBContainer умеет только в 16 бит цвет. Второе решение: использовать Memory Context, но до этого я не добрался пока.

Я перерисовываю графен только в случае обновления Input'a. Если тащить курсором окно созданное в nuklear, курсор начинает дичайше мерцать, что бесит.

Ввод с клавы я не реализовал пока, т.к. какого-то хрена, коллбэки, которые вешаешь на PtWindow нифига не вызываются. Зато как только закроешь окно, они все вылетают со свистом и приложение закрывается >_<. С этим пока не разбирался.

https://imgur.com/a/xkmuoNU

То, что вспомнил сходу вечером после работы.

Привет! Пытаюсь повторить твой успех. Позапускал Nuklear Cross, накатал простую прогу на PtRaw (без PhAB). Рисует простые вещи, но не могу заставить его принимать события клик мыши с координатами, без этого Nuklear работать не станет.

Как сделать реакцию на мышь у PtRaw?

int raw_click(PtWidget_t *w, void *data, PtCallbackInfo_t *cbinfo)
{
	printf("raw_click r= %d, st= %d\n", cbinfo->reason, cbinfo->reason_subtype);
	return(Pt_CONTINUE);
}

	PtCallback_t raw_cb[] = {{raw_click, NULL}};

	PtArg_t argt[5];
	PhPoint_t raw_pos;
	PhDim_t raw_dim;

	raw_pos.x = 25;
	raw_pos.y = 25;
	raw_dim.w = 320;
	raw_dim.h = 240;
	PtSetParentWidget(window);
	PtSetArg(&argt[0], Pt_ARG_DIM, &raw_dim, 0);
	PtSetArg(&argt[1], Pt_ARG_POS, &raw_pos, 0);
	PtSetArg(&argt[2], Pt_ARG_RAW_DRAW_F, &raw_draw, 1);
	PtSetArg(&argt[3], Pt_CB_ARM, raw_cb, sizeof(raw_cb) / sizeof(raw_cb[0]));
	PtCreateWidget(PtRaw, Pt_DEFAULT_PARENT, 4, &argt[0]);

Нужно навесить обработчик при помощи функции PtAddEventHandler на виджет PtRaw. Чуть ппж приведу пример. По поводу PtRaw, как выяснилось, рисовать на нем идея не очень. Как только кладешь его в PtDBContainer, чтобы обеспечить double buffer, отрисовка начинает дичайше тормозить. Лучше юзать Memory Context, который будет рисовать в PtImage_t. Сам PtImage_t привязать к PtLabel. Отрисовка продолжает жрать овердохера цпу, но уже значительно быстрее (потому перерисовкой я занимаюсь исключительно при обновлении инпута). К nuklear я это пока не прикрутил, просто велосипежу одну допотопную игрушку.

Я подсмотрел отрисовку в PtDoom (порт первого дума под куникс)

Привязка обработчика:

PtAddEventHandler(ph_glob_gui->raw, Ph_EV_BUT_PRESS | Ph_EV_BUT_RELEASE | Ph_EV_PTR_MOTION_BUTTON | Ph_EV_PTR_MOTION_NOBUTTON, mouse_callback, NULL);

Обработчик:

int mouse_callback(PtWidget_t *widget, void *data, PtCallbackInfo_t *info) {
	PhPointerEvent_t *	pointer;
	PhRect_t *		pos;
	short	     		mouse_x, mouse_y;

	pointer = PhGetData(info->event);
	pos	= PhGetRects(info->event);

	mouse_x = pos->ul.x;
	mouse_y = pos->ul.y;

	nk_input_begin(ph_glob_gui->ctx);
	
	if (info->event->type & Ph_EV_BUT_PRESS) {
		printf("press mouse\n");
		if (pointer->buttons & Ph_BUTTON_SELECT) {
			nk_input_button(ph_glob_gui->ctx, NK_BUTTON_LEFT, mouse_x, mouse_y, 1);
		}

		if ( pointer->buttons & Ph_BUTTON_MENU ) {
			nk_input_button(ph_glob_gui->ctx, NK_BUTTON_RIGHT, mouse_x, mouse_y, 1);
		}
	} else if ( info ->event->type & Ph_EV_BUT_RELEASE && info->event->subtype == Ph_EV_RELEASE_REAL) {
		printf("release mouse\n");

		if (pointer->buttons & Ph_BUTTON_SELECT) {
			nk_input_button(ph_glob_gui->ctx, NK_BUTTON_LEFT, mouse_x, mouse_y, 0);
		}

		if ( pointer->buttons & Ph_BUTTON_MENU ) {
			nk_input_button(ph_glob_gui->ctx, NK_BUTTON_RIGHT, mouse_x, mouse_y, 0);
		}
	}
	
	nk_input_motion(ph_glob_gui->ctx, mouse_x, mouse_y);
	nk_input_end(ph_glob_gui->ctx);	
	
	return Pt_CONTINUE;
}

В обработчике я возможно сделал что-то неверно) В процессе постановки экспериментов для выяснения как этот высер дьявола работает, много чего было наворочено, потому я оставил только то, что касается непосредственно ввода.

Обработка клавы:

Обработчик нужно вешать на window

PtAddEventHandler(window, Ph_EV_KEY, &keyboard_callback, NULL);

Обработчик:

static int Game::keyboard_callback(PtWidget_t *widget, void *data, PtCallbackInfo_t *info) {
	if (info->event->type == Ph_EV_KEY) {
		PhKeyEvent_t *	ke		= (PhKeyEvent_t *) PhGetData(info->event);
...
		if (PkIsFirstDown(ke->key_flags)) {
			//Нажатие
			game->key_process(ke->key_cap);
		} else if (PkIsReleased(ke->key_flags)) {
			//Отпускание
		} else {
			//Repeat
			game->key_process(ke->key_cap);
		}
	}
	return Pt_CONTINUE;
}

Макрос PkIsReleased:

#define PkIsReleased(f) ((f & (Pk_KF_Key_Down|Pk_KF_Key_Repeat)) == 0)

В key_cap коды клавиш фотона Pk_Up, Pk_Down, Pk_q, Pk_w, Pk_e, Pk_r, Pk_t, Pk_y и т.д.

Да, ещё, есть функция, которая увеличивает буфер отрисовки - PgSetDrawBufferSize. Я особой разницы не заметил, но мало ли.

Нужно ли противодействовать зловредному ПО? Как вы это делаете? (комментарий)

На QNX4.25 это просто нереально будет портировать в хоть сколько-нибудь разуменые сроки (если работать в соло).

Разумные*

Люто бешено спасибирую!!! Это сэкономило мне наверное сто тысяч секунд! Всё работает, сделал наподобие и реагирует на мышь клаву, получает коды и координаты! Спасибо!

Есть задумка сделать некий шаблон программы для коллег, чтобы потом развивать один и тот же софт на Linux, QNX4, QNX6 и заодно Windows, а там может и Emscripten дойдет. А глубокую отладку и тестирование можно на Linux организовать.