[devel] Re: alternatives

[Mikhail Zabaluev <mhz@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

Hello Alexey,

On Sun, Mar 30, 2003 at 11:44:31AM +0400, Alexey Voinov wrote:
>
> > > на glib2 (1207356) и

Без GObject и пр. имеем:

-rwxr-xr-x    1 root     root       435172 Фев  5 07:42 /usr/lib/libglib-2.0.so.0.200.1

Сам пакет большой, но в runtime это довольно компактная библиотека.

> > Нужно учесть ещё накладные расходы на порождение кода из шаблонов.
> > std::map<foo, bar> вряд ли даётся бесплатно.
> Всё решается во время компиляции.
> 
> Пример простого шаблона:
> template <int i>
> 	struct f { static const int r = i * f<i-1>::r; };
> 
> template <>
> 	struct f<0> { static const int r = 1; };
> 
> Так вот, f<5>::r при компиляции заменяется костантой 120, а
> f<10>::r --- 3628800. Где накладные расходы от шаблонов?
> Я не вижу.

Я говорил об std::map и других не вполне тривиальных классах.

> > > переходе на менее удобный (для того, кто это пишет)
> > > синтаксис? :)
> > Более удобно -- это там, где опасным и неинтуитивным образом
> > переопределяются операторы непонятно для чего? ;)
> Конкретный пример можно? Оператор [] у std::map переопределён
> неинтуитивно?

Класс Ing::FileSystem переопределяет * и ++ явно в целях
конспирации. Правильный operator++ должен возвращать отнюдь не bool.
Кстати, если уж переопределять ++, принято ещё и постфиксную форму
предоставлять.
Непонятно, почему вообще немудрёный итератор
по файловым деревьям назван FileSystem.
И почему у него семантика линейного итератора. Мне известны
как минимум два способа обхода дерева, см параметры утилиты
file. Файловые ссылки добавляют неопределённости.
Негибкий этот класс и в других отношениях: всегда делает fstat,
нужно это или нет (тем более что fts_* вроде бы предоставляют
и эти данные). В-общем, я не увидел здесь _полезного_
использования C++.

> > > В чём преимущество предложенного?
> > В том, что не надо думать, каким компилятором собраны
> > библиотека и приложение. У нас сейчас полно головной
> > боли из-за gcc 2.96 и gcc 3.2. А если кто-нибудь,
> > не дай бог, захочет использовать компилятор Intel?
> > Стандартный ABI уже есть, но он молод и недостаточно
> > отлажен, не говоря уж о реализациях.
> Не надо думать. У нас стандартный компилятор gcc3.2.

Разработчики GCC пока не дали гарантии, что C++ ABI версии 3.2
окончательный.

> Я скажу так: я начал делать свой вариант альтернатив на C (и без glib2),
> но потом решил, что продуктивнее будет слать патчи к тому, что уже есть.
> Постепенно это можно довести до очень неплохого состояния.

Да, вероятно.
Можно было бы постепенно сводить классы к их заменам на C.
В отсутствие наследования это будет нетрудно.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Sinners can repent, but stupid is forever.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]