Ваши +-20% могут быть важны для «фиксированной железки», но ведь не весь же мир вокруг вашей задачи крутится. Преимущества от RTTI вполне могут перевешивать 20% проседание производительности.
У меня есть свои биндинги LLVM к .NET, генерятся автоматически с помощью XML-вывода Clang. Они используются в моем компиляторе Си, я про него сегодня собирался пост писать.
Я говорю о вызове функций, скомпилированных JIT-ом LLVM из .NET (инструкция Calli, очевидно у вас так же) и вызове статических методов .NET из кода, сгенеренного LLVM (по указателям, полученным инструкцией Ldftn). Почему-то у меня Cdecl не работает.
Кстати, интересный момент есть — взаимодействие LLVM с .NET.
Я обнаружил, что подходящий для вызова .NET-методов calling convention — это LLVMX86FastcallCallConv, для вызовов в обратную сторону — System.Runtime.InteropServices.CallingConvention.Winapi.
Не понятно только, насколько это универсально, и гарантировано ли будет работать в будущем.
Вы зачем обманываете? Не парсите вы это с листа, вы не телепат. Это нельзя распарсить, не имея в памяти информации о том, что является типом, а что идентификатором. И чем больше разнообразных определений у вас в контексте, тем сложнее распарсить код на C++, тем больше нерелевантной информации нужно держать в голове только для того, чтобы всего лишь понять, что там написано.
Повторю еще раз — пользователь C++ обязан знать все то же самое, что знает компилятор C++.
Вы не очень честно (и, скорее всего, преднамеренно) передергиваете, сопоставляя это с автомобилем или с пользовательским приложением с простым и понятным интерфейсом.
Интерфейс C++ — это весь язык, целиком, со всей его невообразимой сложностью.
Понятие о сложности, которым пользуется всё цивилизованное человечество, тесно связано с очень формальным представлением о количестве информации. Вам знакомы такие имена, как Шеннон, Колмогоров, Чейтин?
Язык C++ содержит в себе очень, очень много информации. Работа с этим языком требует от программиста переработки гораздо больших объёмов информации в каждый момент времени, чем практически любой другой язык. Это и называется «сложностью». Ну, знаете, большая буква O, и всё такое.
Синтаксис C++ намного сложнее и перегруженее чем даже синтаксис большинства производных от Си. Например, у Java синтаксис однозначный, разбирается банальным LL-парсером, легко читается с любого места. В результате и программист очень легко читает Java с листа, без перескоков по куче заголовочных файлов с целью узнать, что же такое у нас сегодня, в этом вот месте, оператор "()", и какие там неявные конструкторы копирования вызываются. И IDE получаются очень умными и продвинутыми — легко читая Java-код с любого места, они правильные подсказки программисту дают. Всё это следствие разницы в сложности синтаксиса.
А что вы считаете Лисп сложным — так это ваше субъективное мнение. Мне не интересны субъективные взгляды. Объективно Лисп намного проще чем даже plain C, в нем конструкций меньше, а синтаксиса так мало, что он практически отсутствует. И, да, что Пролог что Лисп — языки намного проще чем C++. Я говорю о некотором собирательном Лиспе, конечно же, а не о толстом монстре Common Lisp, спецификация которого может поспорить по объёму со стандартом C++.
И DSL, и общего назначения. DSL тоже бывают объемными. Работал я с одним DSL, к счастью, не мной сделанным, где одних только ключевых слов три тысячи было.
Для водителя автомобиль — это руль, коробка передач и три педали. А язык для программиста — это абсолютно все его конструкции, все особенности его семантики. В языке нет ничего, что можно спрятать под капот, всё торчит наружу. Так что, то, что сложно для компилятора — то сложно и для программиста. Они должны знать про язык одно и то же.
И еще — все то, что должен знать о C++ компилятор, должен знать и программист, пишущий на C++. Все эти более тысячи страниц спецификации. То есть, это однозначно сложный язык. Для того, чтобы программировать на простом языке, надо знать и помнить намного меньше. Никаких неявных правил преобразования типов, никаких правил порядка вызова конструкторов, ничего лишнего. Голова у программиста должна быть забита концепциями предметной области, должна прикладные задачи решать, а не помнить многочисленные особенности «простого и элегантного» языка.
Уж даже не знаю, что на это ответить. У вас, похоже, какое-то своё определение сложности, которое ничего общего не имеет с тем определением, которым оперирует всё остальное человечество.
Язык со сложным синтаксисом не может называться «простым». Язык с перегруженным и неоднозначным синтаксисом не может называться «элегантным». Язык с семантикой, которую надо описывать на 1000 страниц текста, не может быть ни простым ни элегантным.
Скажите — вы видели хотя бы один отличный от C++ язык? Например, Схему в версии R5RS? Вот это — простой и элегантный язык. А C++ — сложный язык. Не на какой-то там абсолютной шкале сложности (сомневаюсь, что такую можно определить), а относительно действительно простых и действительно элегантных языков.
Я говорю о вызове функций, скомпилированных JIT-ом LLVM из .NET (инструкция Calli, очевидно у вас так же) и вызове статических методов .NET из кода, сгенеренного LLVM (по указателям, полученным инструкцией Ldftn). Почему-то у меня Cdecl не работает.
Я обнаружил, что подходящий для вызова .NET-методов calling convention — это LLVMX86FastcallCallConv, для вызовов в обратную сторону — System.Runtime.InteropServices.CallingConvention.Winapi.
Не понятно только, насколько это универсально, и гарантировано ли будет работать в будущем.
Смотрите выше мой ответ про сложность.
Вы не очень честно (и, скорее всего, преднамеренно) передергиваете, сопоставляя это с автомобилем или с пользовательским приложением с простым и понятным интерфейсом.
Интерфейс C++ — это весь язык, целиком, со всей его невообразимой сложностью.
Язык C++ содержит в себе очень, очень много информации. Работа с этим языком требует от программиста переработки гораздо больших объёмов информации в каждый момент времени, чем практически любой другой язык. Это и называется «сложностью». Ну, знаете, большая буква O, и всё такое.
Синтаксис C++ намного сложнее и перегруженее чем даже синтаксис большинства производных от Си. Например, у Java синтаксис однозначный, разбирается банальным LL-парсером, легко читается с любого места. В результате и программист очень легко читает Java с листа, без перескоков по куче заголовочных файлов с целью узнать, что же такое у нас сегодня, в этом вот месте, оператор "()", и какие там неявные конструкторы копирования вызываются. И IDE получаются очень умными и продвинутыми — легко читая Java-код с любого места, они правильные подсказки программисту дают. Всё это следствие разницы в сложности синтаксиса.
А что вы считаете Лисп сложным — так это ваше субъективное мнение. Мне не интересны субъективные взгляды. Объективно Лисп намного проще чем даже plain C, в нем конструкций меньше, а синтаксиса так мало, что он практически отсутствует. И, да, что Пролог что Лисп — языки намного проще чем C++. Я говорю о некотором собирательном Лиспе, конечно же, а не о толстом монстре Common Lisp, спецификация которого может поспорить по объёму со стандартом C++.
Язык со сложным синтаксисом не может называться «простым». Язык с перегруженным и неоднозначным синтаксисом не может называться «элегантным». Язык с семантикой, которую надо описывать на 1000 страниц текста, не может быть ни простым ни элегантным.
Скажите — вы видели хотя бы один отличный от C++ язык? Например, Схему в версии R5RS? Вот это — простой и элегантный язык. А C++ — сложный язык. Не на какой-то там абсолютной шкале сложности (сомневаюсь, что такую можно определить), а относительно действительно простых и действительно элегантных языков.