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

[Led]

On Sunday, 16 November 2008 20:39:12 Evgeny Sinelnikov wrote:
> 16 ноября 2008 г. 20:46 пользователь Dmitriy M. Maslennikov
>
> <maslennikovdm на gmail.com> написал:
> > 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
> >  Опять не уловил сути. Устал читать, видимо. Впрочем, все придирки
> >  довольно стандартны.
> >
> > Вывод: С++ единственный язык полностью совместимый с С, но позволяющий
> > оперировать высокоуровневыми конструкциями. Поэтому он прочно занял
> > свою нишу, и я, таки, считаю, что он является прекрасной заменой С, в
> > случае, если умело им пользоваться. Но из-за своей сложности он
> > требует длительного изучения.
> >
> > Вопрос остается открытым: почему нельзя писать системные компоненты на
> > С++?
>
> После долго разговора в #altlinux, мне кажется, что я понял... :)
>
> Проблема вот в чём. GCC и GLIBC - это стандартные компоненты. Но GLIBC
> считается первичной, а GCC могут быть разными.
>
> Так вот линковка системного модуля с libstdc++ одного ABI, который при
> этом грузится динамически, потенциально может быть критична для тех
> приложений, которые слинкованы с libstdc++ другого ABI. Это, вероятно,
> может проявится и в случае со статической линковкой. Это можно и нужно
> проверять, но проблема вроде бы очевидна, хотя детали мне не ясны -
> буду смотреть... Не понятно тогда, а как же обходятся пропиетарные
> приложения, линкуясь со старыми версиями GLIBC - ведь работают же :)
>
> В этой потенциальной проблеме, как я понял, и состоит конструктиваня
> критика технических аспектов реализации.
>
> В общем, вопрос ставится так: "Крайне не желательно писать NSS-модули
> на C++". Это связано в особенностями архитекутры NSS. Мне теперь надо
> обдумать этот вопрос...
>
> Я крайне разочарован тем, что вместо такого простого объяснения, мы
> два дня препирались о применимости C++, как системного языка. К
> сожалению, как мне кажется, призывая понять проблему, нас скорее
> провоцировали, чем указывали на неё...

ИМХО "препирались" здесь только вы. Теперь вы обвиняете ВСЕХ (кроме вас), что  
до вас так туго доходит.

-- 
Led