From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 30 Mar 2003 15:35:40 +0400 From: Mikhail Zabaluev To: devel@altlinux.ru Cc: Alexey Voinov Message-ID: <20030330113540.GA1430@mhz.mikhail.zabaluev.name> Mail-Followup-To: Mikhail Zabaluev , devel@altlinux.ru, Alexey Voinov References: <20030329131157.GA27610@mhz.mikhail.zabaluev.name> <20030329194129.GB2015@voins.local> <20030329212709.GA29260@mhz.mikhail.zabaluev.name> <20030330074431.GA2006@voins.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20030330074431.GA2006@voins.local> User-Agent: Mutt/1.4.1i Subject: [devel] Re: alternatives Sender: devel-admin@altlinux.ru Errors-To: devel-admin@altlinux.ru X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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. --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+htaMTKqCuNPJlLgRAsG7AJ4p6CUVXHjmU5yrWzIBGfJPM0x6UgCfYwfG VhBSwmC1u3RNUjnJ7sWTsIo= =1W77 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO--