>>Милая, да выберите и пишите. Может, поймёте по дороге, почему же
>>для низкоуровневого системного софта как раз C и является ассемблером.
>>И не в нём тут проблема.
>
>Дело в том, что на C обычно пишется весь проект, а на
>ассемблере - маленькие куски кода (к тому же код, написанный вручную
>на ассемблере может быть быстрее кода на всеми так любимом C).Если _хорошо_ уметь программировать на ассемблере. Иначе - далеко не факт. А уметь программировать на асме хорошо - совсем не тоже, что просто уметь программировать. Я вот умею, но не хорошо. Поэтому напишу на C.
>Все-таки маленький кусок на низкоуровневом языке достаточно легко "вылизать", а большую
>часть проекта удобнее писать на высокоуровневых языках, т. к. это позволит
>значительно уменьшить число багов, а на производительность практически никак не повлияет.
Как бы это помягче сказать... Вы не правы, вот.
Во-первых, вместо багов логики (которые заметить относительно легко) начнут вылезать баги компиляторов (а вот их пойди ещё обнаружь). Или вы считаете компиляторы (особенно GCC) непогрешимыми?
C++ - ОЧЕНЬ сложный язык. На нём можно написать что угодно, но это вовсе не значит, что на нём стоит что угодно писать. Сам Страуструп говорил , что C++ реально нужен примерно 5 людям в мире (с учётом роста населения Земли и процента программистов среди оного, готов довести это число даже до 500 - суть не сильно изменится).
А D надо бы для начала самореализоваться, а уже потом на нём можно писать вещи, которые должны работать на бесчисленном числе конфигураций в самых разных условиях.
>Так что незначительное (а чаще незаметное) увеличение производительности, вызванное написанием ВСЕГО
>проекта на среднеуровневом C может быть "компенсировано" увеличением числа багов, уменьшением и
>скорости разработки и сложностью добавления новых возможностей.
Опыт показывает, что багов меньше там, где, во-первых, лучше квалификация работников, а во-вторых, где используются наиболее простые схемы. C++ - это НЕ просто. И ему не место в массовом X-сервере, кроме как (допускаю) в прикладных программах, типа xeyes.
> Так что я считаю
>оптимальным выбор C++ (или D) с небольшими ассемблерными вставками (места, которые
>нуждаются в оптимизации, могут быть выявлены при помощи профилировщика).
А я считаю, что Билл Гейтс должен мне кучу бабок. Уж простите за резкость, но книжки - это конечно, хорошо, но вы явно витаете в облаках.
> К тому
>же в C++ есть статические методы и функции вне классов, вызов
>которых должен по скорости должен быть эквивалентен вызову функции C.
Ну и чем в этих случаях будет C++ лучше C? Повторяю, C++ - это ОЧЕНЬ мощный язык, наверное, самый мощный из существующих. Но за эту мощность приходится платить. Я люблю C++, это мой второй любимый язык после C# - но одно дело язык, а другое дело его реализация.
Это не говоря о том, что чем проще средства, тем проще ими пользоваться - меньше ошибок.
> Иногда
>некоторые реализуют на C свою собственную объектную систему (наверное, самая известная
>- glib). Почему такие системы должны быть быстрее систем на C++
>- это я не понимаю. Кстати, слышала, что в Xorg тоже
>реализовано что-то похожее.
А кто вам сказал, что программирование - это гонка за скоростью?
Почему-то имеется расхожее (даже подразумеваемое) мнение, что язык, на котором писать проще, будет провоцировать написание более качественный код. Но это полная чушь. Язык, на котором писать проще, обеспечивает более быструю разработку, и только. Качество кода зависит от качества реализации языка и используемых библиотек и от качества мозгов того, кто собственно пишет код (а так же ставит задачи).
Лично я соглашусь, по крайней мере отчасти, с Михаилом: нынешняя схема организации X.org привела к бедламу, который излечить можно только сменой процесса разработки.
Как там нас учили? Низы хотят, верхи не могут, а теперь вот образуются и революционные настроения...
