[devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

16 ноября 2008 г. 19:50 пользователь Andrey Rahmatullin
<wrar на altlinux.ru> написал:
> On Sun, Nov 16, 2008 at 07:39:08PM +0300, Dmitriy M. Maslennikov wrote:
>> Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
>> конструктивную критику, а не заявления, типа, "плох и все".
> http://yosefk.com/c++fqa/ ? :)
Основные проблемы, я так понял по ссылке:
http://yosefk.com/c++fqa/defective.html
По пунктам:
- No compile time encapsulation
  Это верно и для С, и для всех компилируемых языков, которые я знаю. А где это
  есть? В С++ проблему обходят создавая для кождого класса foo класс fooPrivate,
  и помещая в основной ссылку на него.
- Outstandingly complicated grammar
 Проблема писателей компиляторов. Очень плохо, не спорю, но сейчас
 уже недостатка в качественных компиляторах С++ не ощущается.
- No way to locate definitions
 ИМХО, небольшая проблема, впрочем характерная и для С.
- No run time encapsulation
 Что ж для кого-то факт того, что С++ - unmanaged - проблема, для кого-то -
 достоинство. Впрочем, к С это так же относится.
- No binary implementation rules
 Так как у нас используется только один компилятор gcc-c++, то эта проблема
 несущественна. В случае использования нескольких компиляторов, да, мне
 это тоже не нравится.
- No reflection
 Ну что ж теперь. Нет, так нет) У С тоже reflection нет.
- Very complicated type system
 Да, С++ сложный язык, никто не спорит. Даже черезчур, согласен.
- Very complicated type-based binding rules
 Опять жалоба на то, что типов много, что при перегруженных функциях может
 породит несколько экранов ошибок. Ну что ж, за гибкость надо платить.
- Defective operator overloading
 По сути говорят, что переопределять операторы так сложно, что мы ошибаемся
 и у нас течет память и прочее. Что ж, не перегружайте).
- Defective exceptions
 Не совсем понял суть притензий к исключениям...
- Duplicate facilities
 На мой взгляд - не проблема. Проблема только на этапах обучения. Ну и
 нехорошо, конечно, что многие библиотеки создают собственные строки,
 списки и подобное. Впрочем в С это тоже делается для каждого проекта.
- No high-level built-in types
 Притензия к тому, что из-за того, что все высокоуровневые возможности не
 встроены в язык, а реализованы на нем, нельзя инициализировать списки в
 исходном коде коде, ну и как всегда: "компилятор выдает много ошибок".
 Не считаю проблемой.
- Manual memory management
 Извечный и очень спорный вопрос, впрочем в С тоже памятью управляют
 вручную.
- Defective metaprogramming facilities
 Ругают С макросы (именно ими метапрограммируется NSS :)) ). К счастью в
 С++ это убожество не используется. Метапрограммирование на шаблонах
 ругают так же. Если вспомнить историю, то создавались они не для этого, а
 для обобщенного программирования. Метапрограммирование -- побочный
 эффект, странно ожидать, что он случайно идеально впишется в систему.
 Впрочем, то, что оно есть -- это хорошо.
- Unhelpful standard library
 Будем считать, что boost -- стандартная библиотека С++. А, вообще, в
 случае создания довольно жирного десктопа (как в нашем случае)
 недостатка в библиотеках на С++ не ощущается. Кроме того, доступны все
 библиотеки для С.
- Defective inlining
 Ну некоторая придирка. Впрочем в С - тоже самое (если мы используем
 макросы как функции)
- Implicitly called & generated functions
 Опять не уловил сути. Устал читать, видимо. Впрочем, все придирки
 довольно стандартны.

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

Вопрос остается открытым: почему нельзя писать системные компоненты на С++?

-- 
Dmitriy M. Maslennikov
rlz на etersoft.ru
rlz на altlinux.org
maslennikovdm на gmail.com
master на armory.ru