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 вряд ли даётся бесплатно. > Всё решается во время компиляции. > > Пример простого шаблона: > template > struct f { static const int r = i * f::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.