Нужен компилятор ANSI C, который не умирает

libtcc

tcc, вроде там можно было даже заюзать даже

#!/usr/bin/tcc

Не прверял, но должно работать и

#!/usr/bin/gcc -x c -

http://stackoverflow.com/questions/2482348/run-c-or-c-file-as-a-script

Хотя нет, ну да и пох.

libgccjit?

cling

8cc

Моя твоя не понимать. Если ты не хочешь скриптоты, то нафига заморачиваться с компиляцией, делай обычные плагины с dlopen.

Ну внутри оно так и будет. Другое дело, что когда пишешь скриптоту, то часто используешь принцип «написал - попробовал», т.е. в одном окошке пишешь код, в соседнем получаешь результат. Особенно когда код занимается отрисовкой чего-то. И вот я хочу, скажем, поправить одну циферку, после чего в соседнем окне увидеть как изменился результат. Быстро.

clang/llvm умеют ровно это (компилять будучи библиотекой). Инициализации, как таковой, нет. Для быстрой компиляции можно сделать магию с выведением всех инклюдов в precompiled header и перекомпиляцией их по необходимости, будет работать реактивно.

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

Хахаха :-) Лол :-)

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

Хороший JIT-компилятор для скриптоты уделает твою сишечку на раз

Другое дело, что когда пишешь скриптоту, то часто используешь принцип «написал - попробовал», т.е. в одном окошке пишешь код, в соседнем получаешь результат. Особенно когда код занимается отрисовкой чего-то. И вот я хочу, скажем, поправить одну циферку, после чего в соседнем окне увидеть как изменился результат. Быстро.

В одном окне код, в другом

gcc -O2 -o plugin.so plugin.c && cp ./plugin.so /target/path/plugins/ && killall -SIGUSR1 your_app

cp ./plugin.so

cp может тут обломаться, надо install

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

Lua то пробовал? Остальная петушня даже рядом не стоит.

Создай файл .c состоящий из инклудов всех файлов, которые тебе надо скомпилить, и компиль его:

#include "1.c"
#include "2.c"
...

А пруфов не будет?

Сишечку никогда не уделать, ведь все ведет к ней. Другое дело, что можно проссать высокоуровневый алгоритм, который из скриптоты можно было бы эффективно оптимизировать, а в сишечке - нет.

Плохо, очень плохо

gcc -O2 -o plugin.so plugin.c

Это как раз не быстро. Компилятор умирает и каждый раз начинает все заново.

cp ./plugin.so /target/path/plugins/

Это еще хуже, теперь у нас будут тысячи временных файлов. Еще медленней и менее безопаснее.

killall -SIGUSR1 your_app

Если редактор уже внутри приложения - не нужно

Для DSP?

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

tcc уже советовали? Попробуй. Но не рассчитывай на интенсивное применение. Оно не реентерабельно и не потоко-безопасно. Сам для себя давно ищу что-то подобное(и для подобных целей). Эти идиоты используют глобальные переменные внутри, а мне нужно параллельное компилирование. А привести в порядок введя state не хватает терпения.Да и толку если разрабы пилят матчасть, при этом плевать хотели на читаемость кода, я потом не смержусь вовсе.

Оно умеет компилять в память? Ибо компилять в .so-шку вопрос не стоял бы вообще.

Сишечку никогда не уделать, ведь все ведет к ней. Другое дело, что можно проссать высокоуровневый алгоритм, который из скриптоты можно было бы эффективно оптимизировать, а в сишечке - нет.

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

Ой, к чему это я? Ах, да, компилятор тебе тогда не нужен :D

Это как раз не быстро. Компилятор умирает и каждый раз начинает все заново.

Что по-твоему компилятор начинает заново, что можно было бы не начинать?

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

Для DSP?

Ты на DSP собираешься запускать компилятор Си?

Да, активно смотрю на него, особенно на libtcc, однако вот такая пляска со стейтом пугает. Пока не разобрался, можно ли сделать инкрементальную компиляцию.

Что касаемо разрабов, то это ты зря, на главной проекта запись, что последний релиз был 3 года назад, а ныне автор ничего не девелопит больше. Есть ссылка на форк, но там еще более ломающие откровения и новый форк, который, как я понимаю, еще даже не пилится. Так что можешь форкать и считать себя лидером проекта

Что по-твоему компилятор начинает заново, что можно было бы не начинать?

Перечитывает все иклюды, ведет полный разбор всех файлов и только потом, когда оно знает что и зачем - оно компилируется. Вот это вот все хотелось бы держать в памяти. Потом линковка (я правда не очень понимаю, что в моем случае с ней делать), мы опять перечитываем кучу всего. Представь, что мы линкуемся с чем-то большим вроде ffmpeg, выхлоп бинарника на выходе - 100+ метров, а то и сильно больше, в зависимости от условий сборки.

А теперь представь, что ты поменял одну цифру в исходнике и хочешь посмотреть чем это закончится. Или условие. Если бы просто цифры менять, то можно было бы компилить с magic numbers и патчить самого себя.

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

LUA, LuaJIT.

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

Вот тут в голосину. Как там борщ? Вкусный?

Если бы был борщ, то был бы Хаскель

Использование ANSI C там, где самое время подключить lua или что-то подобное с уже написанным хорошим JIT, ничем не лучше использования haskell не по назначению.

Если ты не хочешь скриптоты, то нафига заморачиваться с компиляцией, делай обычные плагины с dlopen.

Удваиваю.

Особенно когда код занимается отрисовкой чего-то. И вот я хочу, скажем, поправить одну циферку, после чего в соседнем окне увидеть как изменился результат. Быстро.

Мне кажется, это достигается просто грамотной настройкой твоей IDE. Чтобы при запуске твоего плагина запускалась хост-программа и подхватывала плагин.

А то, что это не моментально - увы, это как раз из-за неидеальности Си, в котором в 2016 году до сих пор не завезли нормальных модулей. В Object Pascal, кстати, они есть, и он собирается гораздо быстрее. :) Другое дело, что у паскаля свои недостатки.

Проблема в том, что я этот хост и пишу, при этом слабо понимаю, как обеспечить такую интеграцию. Затащить с собой компилятор - вроде неплохая идея. Конечно, не будет работать на АРМах, слабо представляю как это будет линковаться под маком или форточкой, но это не критично, девелопить можно будет уже хоть как-то. В итоге получается какой-то монстр в виде встроенной IDE. Хотя изначально планировался простой текстовый редактор и кнопка «применить».

Могу ли я c LuaJit ворошить мегабайты байтиков? Скажем, сделать размытие Гаусса, при этом так, что скорость будет не совсем убийственна? Я понимаю, что чудес не бывает и даже с сишкой реалтайм не получить, но не хотелось бы получить 0.0001 fps вместо 1fps

Затащить с собой компилятор - вроде неплохая идея.

Затащить dlopen явно проще :)

http://lua-users.org/lists/lua-l/2011-02/msg01425.html Почитай этот старый пост про то как luajit уделывает gcc/gsl на численном интегрировании.

Для таких целей можно взять OpenCL, если ограничения по железу устраивают.

размытие Гаусса [...] даже с сишкой реалтайм не получить

На каком железе?

Оно умеет компилять в память? Ибо компилять в .so-шку вопрос не стоял бы вообще.

Let me google it for you: https://github.com/llvm-mirror/clang/tree/master/examples/clang-interpreter