objective-c

[Sixteen]

даёш динамическиы ци!
пусть в его стандартный рантайм войдет компилятор для функциы, который будит возвращать поинтер на откомпилированую функцию.
а вызов будет делаться с помощью функции инвоук, которая будет принимать в качестве аргументов поинтер и еще массив аргументов.

[Sixteen]

bi efreid! bi veri efreid!

[crazy-mike]

даёш динамическиы ци!

Есть. Не меньше четырёх реализаций под Linux.
tcc ( Tiny C++ ) и ещё несколько. Я этой хреновиной даже пользовался когда-то давно.
Мелькал ещё Object REXX - но это уже больше на "динамический PL/1" было похоже.

[Alex_3112]

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

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

[реднек]

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

To же самое, файл и строку.

[crazy-mike]

To же самое, файл и строку.

Только с одной большой разницей - в "динамическом" указывает на то , что в самом деле выполнялось. А в статическом указывает на то , что могло бы выполняться. ( сгенерированый код отладочной версии не совпадает с рабочим. И если уже совсем точно - то "код для отладчика" часто является p-кодом (u-кодом , o-кодом и т.д. Особенно меня в этом контексте "улыбает" Java ) , который является и "динамическим" , и "интепретируемым". ).

[Alex_3112]

To же самое, файл и строку.

А если код, где произошла ошибка, сгенерирован динамически?

[Alex_3112]

сгенерированый код отладочной версии не совпадает с рабочим.

Очень экзотические случаи, по моему опыту. Только если что-то неоткомпилировалось.

А указания на то, что действительно выполнялось, в случае динамического кода напоминают мне анекдот:

- Где Африка?
- Там!
- А где "там"?
- Можно только один вопрос задавать!

[реднек]

А если код, где произошла ошибка, сгенерирован динамически?

Зависит от того как был сгенерен динамический код. Если динамически были подгружены модули с методами и вставлены в объект или класс, и ошибка в одном из таких методов, то покажет на фаил со строкой где этот метод содержиться. Если же это динамическое интерпретирование строки содержащей код (а ля eval), то покажет на место где строка генерится (это не очень приятно, да). Есть еще способы, как берется метод переназывается, на его месте создается новый который вызывает старый и еще чего то там делает, там то же все видно в каком месте произошло. Возможно функцию проэвалюировать в контексте объекта или класса, там тоже все видно, т.к. тело функции явно прописано. Самый противный случай это вышеупомянутый eval строки, но в него редко попадаешь. Кстати, не приходилось смотреть ошибку в плюсах в коде сгенерированом директивами препроцессора? Стэк препроцессора не показывается ведь, еще похуже eval, будет. Ну как инстанциируются шаблоны в замечательном статическом C++, еще можно отследить, но лучше иметь сразу 30 дюймовый монитор, что бы поместилось сообщение об ошибки компиляции.

[реднек]

Alex, я кажется понял твое предубеждение к динамическим языкам. Динамический, это не значит, что код сгенерирован и непонятно откуда ноги растут. Нет. Динамический это означает что объекты и классы могут обретать новые методы по ходу жизни, или меняется механизм поиска существующих. При этом телеса этих методов доступны и будут показаны в трейсе. eval(строка) пользуется редко, я никогда не пользую его, и вообще это рассматривается как bad practice. А то что цепочка поиска метода меняется - это не страшно. Сравни например с построенной цепочкой декораторов в статическом языке - они сами имеют четкие типы, но то как выстроена цепочка зависит полностью от runtime.