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

[Alexander Bokovoy]

2008/11/16 Dmitriy M. Maslennikov <maslennikovdm на gmail.com>:
> 16 ноября 2008 г. 18:54 пользователь Alexander Bokovoy
> <ab на altlinux.org> написал:
>> Посмотрите на Vala как на пример высокоуровневого языка, использующего
>> для выражения средства glib2. Vala написана на самой себе, так что
>> качестве примера довольно выразительна.
> Я не спорю, что вокруг glib2 можно построить высокоуровневую систему.
> Но это уже не С. Я полагаю, что вы не предлагаете нам написать модул
> на vala?
Нет, не предлагаю. А на Vala посмотрите. И с точки зрения "не C", и с
точки зрения высокоуровневости. Для понимания проблематики стоит также
посмотреть, например, на http://live.gnome.org/IteratorsAPI.

>> У меня тоже есть пожелание к переезду libstdc++ в /lib.
>>
>> Впрочем, от необдуманного написания кода это не спасает и "легче
>> выражаются языковыми конструкциями" вряди может служить в качестве
>> обоснования при написании низкоуровневых компонент, критичность
>> которых довольно высока.
> Легче выражается -> меньше шансов допустить ошибку.
Главная ошибка уже допущена: для решения задачи выбрано средство,
которое не соответствует уровню абстракции, на котором должен работать
модуль.

> По-моему инструмент надо выбирать не минимально достаточный для
> выполнения задачи, а наиболее удобный. Разве не так?
Нет. Должен выбираться соответствующий области применения инструмент.
В данном случае есть целый ряд требований к интерфейсу и побочным
эффектам от уже существующих приложений. Этот "монастырь" со своими
правилами, которые надо соблюдать, существует уже очень давно и выбор
средств тут ограничен именно требованиями совместимости. Не важно,
удобно лично Вам это средство или нет, важно, чтобы оно производило
результат, который удовлетворяет требованиям к таким модулям.

Надо отметить, что не все из этих требований нормально описаны в
письменной форме, но тем не менее они существуют.

> Я утверждаю, что так как С++ поддерживает практически все конструкции
> С, но добавляет много новых, то он практически всегда удобнее.
> Единственный недостаток - шаблоны раздувают код, поэтому он может не
> подходить для встраиваемых систем. Для написания приложений для
> толстого desktop он практически всюду лучше С.
Не путайте Ваши приложения для десктопа и низкоуровневые компоненты
операционной системы.

>> Я не говорю уже про втягивание pthreads во
>> все приложения, которые могут быть и не готовы к этому. Один такой
>> пример плохой реализации внутри glibc мы уже видели
>> (http://samba.org/~tridge/junkcode/aio_uid.c).
> Да, на втягивании pthread в модуль (другой) мы уже наступали. В старом
> тулчейне gettext переставал работать)
Вот видите. Но тем не менее, тянете его за собой.

>> Главное, что я хотел продемонстрировать в этом обсуждении и что вы с
>> Дмитрием так пока и не поняли, что архитектурные и дизайнерские
>> решения не всегда принимаются на основании личных предпочтений. Прежде
>> всего необходимо думать о тех, кто использует разработанное. В случае
>> компонент ОС это прежде всего другие приложения и принцип "не навреди"
>> здесь играет главенствующую роль.
> Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
> конструктивную критику, а не заявления, типа, "плох и все".
В данном конкретном случае C++ не является средством, которое
используется для написания низкоуровневых компонент, динамически
загружаемых во все приложения в системе из-за невозможности
проконтролировать все побочные эффекты, которые возникают при загрузке
и использовании такого сложного кода, как C++ stdlib.

-- 
/ Alexander Bokovoy