Nix, ooc, libcello

https://github.com/eudoxia0/cmacro

Ты хочешь другой ЯП, а не препроцессор. Препроцессор обычно выглядит как m4

https://bitbucket.org/dfrank/ooc

Насколько хорошая идея использовать c + m4? Пока не вдавался в его синтаксис, но реально ли на нём запилить объявление структур с наследованием? В смысле макрос, который подменит собой нормальный struct и добавит функционала.

В современных языках (Swift, Go) наоборот наблюдается отказ от препроцессора.

А если очень хочется сладкого — то наверно Lisp ваш путь.

http://ldeniau.web.cern.ch/ldeniau/cos.html

Можно взять cfront (да, «компилятор» плюсов был раньше реализован как препроцессор в Си) http://www.softwarepreservation.org/projects/c_plus_plus/index.html#cfront

Насколько хорошая идея использовать c + m4 ... макрос, который подменит собой нормальный struct

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

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

Переходи на C--.

препроцессор

наследование структур. В идеале, конечно, классы с виртуальными методами

толстовато

vala умеет без glib

Насколько эффективный код получается после прохождения валой, а потом компилятором Си? Не отличается по эффективности от обычного сложного сишного кода (в более-менее сложных plain C проектах автор реализует недо-ООП с помощью структур и указателей на функции - см. ту же ChibiOS)?

Или вот например, если у нас 90% структур создаётся в compile time (типичная прошивка микроконтроллера) - для них же не будет добавляться код подсчёта ссылок и т. д.?

Выше уже написали https://github.com/eudoxia0/cmacro

vala умеет без glib

Сам не пробовал, но вроде можно указать в опциях профиль Dova или Posix. Ещё какой-то Aroop разрабатывается.

Насколько эффективный код получается после прохождения валой,

Достаточно эффективно, чтоб про это не думать, скажем так.

С другой стороны.

ибо хочется это использовать с микроконтроллерами.

Не совсем понятно, что тут за контроллеры имеются в виду. Если какие-нить STM, то код довольно жирный для них нагенерится. Если всякая микрокомпьютерная шелупонь, типа малины, то выше крыши.

PS: с валой дело имел года полтора назад и возможно много поменялось в плане оптимизаций и генерации.

Мне нравится концепция Vala. «Компилятор» этого языка по сути конвертирует ООП-код в plain C. Но, увы, он гвоздями прибит к glib, что очень плохо. Нет ли подобных проектов, но без привязки к каким-либо библиотекам?

Eiffel?

Насколько эффективный код получается после прохождения валой, а потом компилятором Си?

С vala нужно озадачиваться другим вопросом - а как долго будет поддерживаться генерация кода на Си. Это же отдельный язык и сделали промежуточную генерацию в Си из-за простоты такого подхода. Сейчас есть llvm с возможностью легко делать компиляторы под любой язык, может быть в gcc тоже появится аналогичный функционал. В определённый момент времени проект двинется дальше, станет сразу гененировать нативнвый код без промежуточного варианта на Си и все твои vala нараборки станут тыквой.

Чем не устраивает C++? Там есть наследование структур и классы с виртуальными методами. Исключения, множественное наследование, RTTI использовать никто не заставляет.

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

И да, почему именно си? Попробуй rust. Если под микрухами понимаешь всякие STM32, то есть zinc.rs, а если beaglebone/raspberry, т.е. с полноценным линём, то и этого не надо.

Или вот например, если у нас 90% структур создаётся в compile time (типичная прошивка микроконтроллера)

Так может и ООП тут нафиг не нужен?

Vala родился афаир исключительно как синтаксический сахар к GObject'у (который очень муторно готовить as-is), а он в свою очередь является GTK-world реализацией ООП для сишки. С тех пор конечно много времени прошло, но снятие сишки/гобъекта с поддержки имхо очень маловероятно. Разумеется, лучше всего спросить у авторов.

На самом деле vala писалась для гноморазрабов. Основная задача это генерация гогнокода для gtk с космической скоростью, поэтому использование vala для чего-то другого кроме гуя на этом тулките - весьма сомнительное занятие.

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

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

С тех пор конечно много времени прошло, но снятие сишки/гобъекта с поддержки имхо очень маловероятно.

Эти вещи не связаны между собой, можно выкинуть генерацию промежуточного кода в си и продолжать использовать gobject c gtk+.

Разумеется, лучше всего спросить у авторов.

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

А есть примеры проектов, использующих эту штуку?

* M4

* WEB Дональда Кнута: tangle/weave

* org-mode babel в Emacs

** программно генерировать обработанный текст через elisp, таблицы и «блоки данных» с выхлопом другого текста

ещё есть например проект диссера от Расса Кокса, вроде бы X++ (с расширяемым языком метапрограммирования)

Мои хотелки - некоторый уровень синтаксического сахара. Хотя бы наследование структур. В идеале, конечно, классы с виртуальными методами. Всяких исключений, множественного наследования, RTTI и т. д. не нужно.

посмотри на реализации языков, генерирующих на выходе Plain C, и компилирующихся через Cи:

* Eiffel

* Oberon-2

* ooc

* COS ООП модель для Plain C в духе CLOS (автор из CERN)

* не считая конечно, всяких лиспов, той же схемы

использовать с микроконтроллерами.

у схемы Gambit была реализация для PIC-контроллеров.

Nim ещё

и нагугли про «программу в 150 байт» на Nim.

макроязык в Nim вроде бы норм, хотя, конечно — не лисп.

http://nativesystems.inf.ethz.ch/pub/Main/WebHomeLecturesSystembau

лекции.pdf

(сейчас чего-то не гуглится, посмотри в archive.org)

курс про встроенные системы, системы реального времени на ARM, на основе ОС А2 + Oberon-2.

царя на тебя нет!

программирование без программистов: визуальные исполняемые спецификации, кодогенерация в си

* SWITCH-технология А. Шалыто (генерация конечных автоматов; читать книжку)

IDE: плагин к Eclipse. см. сайт кафедры Шалыто в ИТМО.

* FLProg: программирование Arduino из лестничных диаграмм (FDD)

кстати, написана одним человеком на SmallTalk

* ДРАКОН

например1, например2 (Drakon-Editor), например3 (обзор), например4 (ИС Дракон Тышова)

обсуждение на forum.easyelectronics.ru среды Тышова

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

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

в отличие от UML, в котором генерируются только заглушки. в Eiffel, правда, есть BON (Business Object Notation) — наподобие UML, но отношения наследования/агрегации и композиции/ассоциации и стереотипы ограничены всего лишь двумя: «класс является клиентом другого класса». в отличие от UML, BON обладает «обратимостью» (reversability) — обратная разработка, модели из кода всегда возможна, однозначна и поддерживается средой EiffelStudio.

впрочем, и что-то типа DRAKON/FLProg/SWITCH тоже сгодится.

!ъ

For a collection of useful macros, see the associated Magma project

не этот ooc, а этот

этот

язык Monkey

VSL: Don't call'em coders. Codemonkeys... (эпиграф)

паскаль-подобные

Oberon-2 (XDev (см. форум, и в конце реализации; также список реализаций), Mодула-3 и подробнее, Модула-2 и прочее.

XDev: философия интро Boulder Dash на обероне-2

сомневаюсь

Оберон — это «Спектрум» будущего!!!

для retard ^W retroкомпьютинга

кстати, у него тоже интересный проект: corvus

тот же вопрос: где-нибудь применяется ???

субстрат выглядит смачно.

он модульный?

вот это выглядит похоже на EuLisp, YouToo README, Eu2C

EuLisp FAQ

бенчмарки (весьма древние, но хоть что-то; хотя там FFI по идее и не нужен — компилируется через Eu2C)

тоже интересно померять, FFI например

отсюда

The next example shows an interface to C to measure run time of functions takl and gtakl imported from the module takl. You can see the special keyword c-import which imports the C-file timing.c contained in the currend release. The linking of the C-functions start_timer and timer was made with help of the form %declare-external-function. In this form the names of this function in EuLisp and in C and the types for the arguments and result in C are declared.

The file associated with the module test-takl has to have the name test-takl.em.

(defmodule test-takl
    (import (level-0
             (only (%void
                    %string)
                   tail)
             takl)
     syntax (level-0)
     c-import ("timing.h")      ;extension of module syntax
     )

  (defun listn (n)
    (if (= n 0)
        ()
      (cons n (listn (- n 1)))))

  (deflocal l24 (listn 24))
  (deflocal l18 (listn 18))
  (deflocal l12 (listn 12))
  (deflocal l6 (listn 6))

  ;;declaration of external functions called from EuLisp
  ;;to measure cpu consumption
  ;;start_timer sets the first time stamp
  ;;timer gets a char * string containing format directives
  ;;to print the values of elapsed user time system time and their sum
  ;;char* strings has to be  written as Tail-literals in the following
  ;;form: (%literal %string () "string")

  (%declare-external-function

    (start-timer %void)          ; the name of the function is start-timer,
    ; result of start-timer is void
    ()                           ; no args
    external-name |start_timer|  ; the name in C is start_timer
    language C)                  ; the used foreign language is C

  (%declare-external-function

    (timer %void)                ; the name of the function is timer
    ; result of timer is void
    ((string %string))           ; one arg string of type char *
    external-name |timer|        ; the name in C is timer
    language C)                  ; the used foreign language is C

  (deflocal result ())

  (start-timer)
  (setq result (takl l24 l12 l6))
  (timer (%literal %string () "\ntakl: %.2f sec (%.2f sec system)"))
  (format t "~%(takl l24 l12 l6) -> ~a~%" result)

;;;-----------------------------------------------------------------------------
  )
;;;-----------------------------------------------------------------------------

пара статей

1. лисп внутри твоего компилятора C/C++: картинки clang gcc

2. общие места в лиспах и C++11

картинки clang gcc

теперь представь, что вместо кодогенерации в Си на лиспе написан компилятор макрами в такое вот промежуточное представление (которое тоже лисп).

а потом C компиляторы его подхватили и поехали дальше.

в работе с микроконтроллерами ООП и всякое наследование точно никуда не упирается. и уж точно не годится для работы со специфическими компиляторами, которые запросто могут не поддерживать даже С99.

в работе с микроконтроллерами ООП и всякое наследование точно никуда не упирается.

Я сам под микроконтроллеры не пишу, но вот здесь человек, который пишет, высказывает противоположное мнение.