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

[Evgeny Sinelnikov]

16 ноября 2008 г. 20:46 пользователь Dmitriy M. Maslennikov
<maslennikovdm at gmail.com> написал:
> 16 ноября 2008 г. 19:50 пользователь Andrey Rahmatullin
> <wrar at 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
>  Опять не уловил сути. Устал читать, видимо. Впрочем, все придирки
>  довольно стандартны.
>
> Вывод: С++ единственный язык полностью совместимый с С, но позволяющий
> оперировать высокоуровневыми конструкциями. Поэтому он прочно занял
> свою нишу, и я, таки, считаю, что он является прекрасной заменой С, в
> случае, если умело им пользоваться. Но из-за своей сложности он
> требует длительного изучения.
>
> Вопрос остается открытым: почему нельзя писать системные компоненты на С++?
>

После долго разговора в #altlinux, мне кажется, что я понял... :)

Проблема вот в чём. GCC и GLIBC - это стандартные компоненты. Но GLIBC
считается первичной, а GCC могут быть разными.

Так вот линковка системного модуля с libstdc++ одного ABI, который при
этом грузится динамически, потенциально может быть критична для тех
приложений, которые слинкованы с libstdc++ другого ABI. Это, вероятно,
может проявится и в случае со статической линковкой. Это можно и нужно
проверять, но проблема вроде бы очевидна, хотя детали мне не ясны -
буду смотреть... Не понятно тогда, а как же обходятся пропиетарные
приложения, линкуясь со старыми версиями GLIBC - ведь работают же :)

В этой потенциальной проблеме, как я понял, и состоит конструктиваня
критика технических аспектов реализации.

В общем, вопрос ставится так: "Крайне не желательно писать NSS-модули
на C++". Это связано в особенностями архитекутры NSS. Мне теперь надо
обдумать этот вопрос...

Я крайне разочарован тем, что вместо такого простого объяснения, мы
два дня препирались о применимости C++, как системного языка. К
сожалению, как мне кажется, призывая понять проблему, нас скорее
провоцировали, чем указывали на неё...

-- 
Sin (Sinelnikov Evgeny)