“Программируйте с использованием языка, а не на языке” vs быдлокодерские и небыдлокодерские языки

просто valid_pointer<A -> B> который под нормальным набором операций никак испортиться не сможет.

я не нашёл в стандарте этому подтверждения.

Ну и в C++ можно сделать свою шаблонную function которая будет вести себя совсем правильно.

шаблоны бывают только во время компиляции, в рантайме нет никаких шаблонов.

Изначально код лежит в сегменте кода, а не в «памяти данных». Но это условности - всегда можно сделать mmap с MAP_ANONYMOUS / PROT_EXEC очередной страницы или изменить права существующей страницы с помощью mprotect

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

Не факт, интерпретатору достаточно интерпретировать свои выражения, производить побочные эффекты и возвращать значения

не факт, согласен, но допилить функционал eval'а не составит труда.

В сишечке невозможно

Возможно.

может и возможно. Только такого никто не делал - JIT'а прямо в код arch. И это будет уже не сишечка, её надо расширить как-то так:

char str[] = "int f(){return printf(\"Hello world!\n\");}";
func_ptr buf[9001];// выделяем место под функцию в 9001 символов
buf = eval(str);// заполняем массив
buf();// выполняем созданную функцию

Байткод зарулит JIT и вообще обгонит процессор?

легко! Вот пруф:

байткод 0xAF, который рисует окно с двумя кнопками в чистом X11 вполне себе заруливает (в разы!) браузер с JIT компиляцией того же окошка на JavaScript.

я не нашёл в стандарте этому подтверждения.

Подтверждение нужно искать не этому, а существованию UB которое ты подозревал, то есть тому, что можно испортить указатель на функцию без кастов и 0-указателей, то есть как-то сделать так, чтобы он стал указывать на память по которой никакого полезного и правильного кода нет. Если ты найдёшь в стандарте описание такой возможности и соответствующее определение семантики как UB, тогда да. Иначе говоря, доказывать, что всё (∀) хорошо не нужно, нужно доказывать что не может быть плохо (¬∃, это одно и то же, но чтобы доказать первое нужно доказывать второе, то есть доказать отсутствие прецедента). Я вот не верю в существование такого прецедента (с определёнными допущениями про касты и т.п.), поэтому не вижу смысла искать в стандарте то чего там нет.

С другой стороны, во всяком JIT для C/C++ обязательно будут сильные касты, но это уже вопрос отсутствия багов (которые могут дать UB) в таком JIT и в коде его использующем.

шаблоны бывают только во время компиляции, в рантайме нет никаких шаблонов.

В статически типизированном языке то что существует во время компиляции как раз направлено на предотвращение нехороших вещей в рантайме. Например:

template <typename R, typename... A>
class function {
    typedef R(*FP)(A...);
    typedef R(&FR)(A...);
    FP fn;
  public:
    explicit function(FR fn_) : fn(fn_) {}
    R operator()(A... x) { return fn(x...); }
    void operator=(FR fn_) { fn = fn_; }
};

доступ к сегменту кода можно только через непереносимые костыли

Решаем задачу на Linux с mmap и всё у нас хорошо. Понадобилось переносимость на Windows? Пишем зависимую часть для неё и тоже решаем задачу, оставляя общим интерфейс. Например, JIT LLVM работает везде и имеет общий интерфейс.

допилить функционал eval'а не составит труда.

Ну а при наличии родного ассемблера и компилятора «не составит труда» допилить JIT. Титиретически :)

Только такого никто не делал - JIT'а прямо в код arch.

Ты про си и плюсы, да? Тогда ещё раз повторю про libJIT (это в arch из DSL на си), LLVM (это в arch из любого llvm кода), Clang (это из си и плюсов в llvm код) и загружаемые разделяемые библиотеки.

Вот пруф

Я вижу proposition, но не вижу proof. Но это не важно - речь же про реализацию _одного_ языка как байткода для VM и как JIT в машкод для CPU, а не «что угодно» vs «что угодно».

сишечка не из первородного вакуума , a C+ UNIX|OtherOS

в стандартной библиотеке есть функции создания/записи_в файла , запуска/обращения к ОС для выполнения процесса (выполнение компилятора) - так что UNIX is IDE

зы. tcc более прямой(похожий на твой) позволяет

Подтверждение нужно искать не этому, а существованию UB которое ты подозревал, то есть тому, что можно испортить указатель на функцию без кастов и 0-указателей, то есть как-то сделать так, чтобы он стал указывать на память по которой никакого полезного и правильного кода нет.

можно-ли прибавлять к указателю на функцию какое-то число? Нет. Это UB. Причина в том, что не существует понятия «размер функции». По этой причине, ты можешь прибавить к указателю на int целое число, и получить следующий int. Но к указателю на функцию ничего прибавить нельзя. Можно только присвоить указатель на другую функцию(или NULL). У тебя есть ещё какие-то способы изменения указателей?

Я вижу proposition, но не вижу proof. Но это не важно - речь же про реализацию _одного_ языка как байткода для VM и как JIT в машкод для CPU, а не «что угодно» vs «что угодно».

твой JIT это тоже далеко не «всё что угодно», а реализация для вполне конкретного CPU.

У тебя есть ещё какие-то способы изменения указателей?

Я об этом и говорил - указатели на функции не портятся без кастов. Ссылки на функции - тем более, то есть не портятся nullptr-ами.

твой JIT это тоже далеко не «всё что угодно», а реализация для вполне конкретного CPU.

То есть JIT для конкретного языка под конкретные CPU будет производительней интерпретации байткода для этого же языка (допустим, рантайм уже разогрелся и JIT прошёл - выполнение машкода явно производительней интерпретации байткода).

У тебя есть ещё какие-то способы изменения указателей?

Я об этом и говорил - указатели на функции не портятся без кастов. Ссылки на функции - тем более, то есть не портятся nullptr-ами.

именно потому, можно считать указатели на функции - константами, известными во время компиляции. Т.е. в рамках C++ невозможно написать изменяемую функцию, возможно только написать набор функций. Что в принципе эквивалентно switch/case.

твой JIT это тоже далеко не «всё что угодно», а реализация для вполне конкретного CPU.

То есть JIT для конкретного языка под конкретные CPU будет производительней интерпретации байткода для этого же языка (допустим, рантайм уже разогрелся и JIT прошёл - выполнение машкода явно производительней интерпретации байткода).

конечно. Однако я не о том, а о том, что _существующий_ JIT (например JS) намного менее производительный, чем специализированный байт-код. Например:

байткод 0xAF, который рисует окно с двумя кнопками в чистом X11 вполне себе заруливает (в разы!) браузер с JIT компиляцией того же окошка на JavaScript.

Напомню, что речь шла об этом:

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

буду. и тормозить она не будет, потому-что мой байткод будет на решение задачи «ЗАЧЕМ?», а твой готовый - для парсинга яваскрипта на быдлоконтакте.

повторюсь: готовый JIT под сферически-вакуумную VM в данном случае - худшее решение.

И в итоге, главный вопрос

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

мне стали доступны вакансии C#-программиста и Python-программиста

Если выбор или-или, то бери шарп. Работы на нем достаточно много, синтаксис ближе к крестам и яве, чем у питона (есть перспектива соскочить на них).

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

В мейнстримовых языках снижают порог вхождения. Их делают простыми

Кто сказал тебе такую чушь?