>Милая, да выберите и пишите. Может, поймёте по дороге, почему же >для низкоуровневого системного софта как раз C и является ассемблером. >И не в нём тут проблема. Дело в том, что на C обычно пишется весь проект, а на ассемблере - маленькие куски кода (к тому же код, написанный вручную на ассемблере может быть быстрее кода на всеми так любимом C). Все-таки маленький кусок на низкоуровневом языке достаточно легко "вылизать", а большую часть проекта удобнее писать на высокоуровневых языках, т. к. это позволит значительно уменьшить число багов, а на производительность практически никак не повлияет. Так что незначительное (а чаще незаметное) увеличение производительности, вызванное написанием ВСЕГО проекта на среднеуровневом C может быть "компенсировано" увеличением числа багов, уменьшением скорости разработки и сложностью добавления новых возможностей. Так что я считаю оптимальным выбор C++ (или D) с небольшими ассемблерными вставками (места, которые нуждаются в оптимизации, могут быть выявлены при помощи профилировщика). К тому же в C++ есть статические методы и функции вне классов, вызов которых должен по скорости должен быть эквивалентен вызову функции C. Иногда некоторые реализуют на C свою собственную объектную систему (наверное, самая известная - glib). Почему такие системы должны быть быстрее систем на C++ - это я не понимаю. Кстати, слышала, что в Xorg тоже реализовано что-то похожее.
|