|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 30 Jan 2003 20:43:48
To : Aleksey Cheusov
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
Здравствуй, Aleksey Cheusov.
AC> 1) с дефолтовыми аллокаторами контейнеры тормозят, т.е. взял
AC> какой-нибудь stl::queue и начинай писать к нему свои аллокаторы
AC> на каждый случай свой да и ещё не забудь подставить его *в каждый*
AC> instance. Рано или поздно упрёшься-таки в реализацию
AC> собственного хипа. Вот уж где монографию написать можно.
AC> И не одну.
Можно. Вот в том коде, о котором Витус говорил, написан свой аллокатор.
Реализация его заняла у автора AFAIK два дня. Убивает двух зайцев - не
напрягает мутексы (софтина мультитредовая) и быстро отдает мелкие блоки.
AC> 2) <algorithm>, - действительно полезная вещь.
AC> Hо! Глупо требовать перекрытия оператора < и вызывать его
AC> *два* раза для одной и той же пары объектов, если можно вызвать
AC> какую-нибудь функцию с результатом (-1, 0, 1) один *раз*.
AC> Если объекты сложные, то выигрышь ровненько в два раза.
А где там < вызывается два раза?
AC> 3) Катастрофически замедляется компиляция.
Вот тот же автор говорит "пользуйтесь precompiled headers". Что резонно.
AC> 4) А есть ли в природе компилятор, поддерживающий templates
AC> на нормальном уровне и оптимизатор, способный все эти темплейтные
AC> навороты свернуть по-хорошему.
AFAIK да.
AC> 5) Почти такую же гибкость обеспечивают pure abstract классы.
Угу, только на том же < в простых случаях вдвое просаживают
производительность. Даже если удастся виртуальную функцию заинлайнить (в
принципе, все вменяемые компиляторы должны это уметь) - это лишний
dereference.
AC> > А без STL C++ в точности соответствует буквальному переводу названия
AC> > этого языка с С на человеческий - "C увеличивается, а результат
AC> > такой же как и до применения операции постфиксного инкремента"
AC> Hичего подобного.
AC> Hа glib и аналоги без слёз смотреть не возможно.
AC> И всё это потому, что людям не нравится слово инкапсуляция.
AC> Даже она одна позволяет лучше писать и иметь на порядок меньше
AC> проблем и на два порядка более прозрачный код.
Да, но то же самое на C достигается ничуть не сложнее.
AC> > С STL, да с эксепшнами, да с RTTI, оно, естественно, увеличивается
AC> > еще больше. Hо хоть работать по-человечески можно.
AC> Без exceptions жить нельзя, это да.
AC> Hо зачем RTTI - никогда не понимал.
AC> Я всегда знаю, объекты какого класса получаю.
Значит, ты не решаешь задач, где так не получится. То есть получиться-то
получится, конечно, только несколько через ж. В том же самом коде, скорости
ради, так сделано, дабы можно было отключить RTTI. В общем, работает, но
читать это...
--
Artem Chuprina
Communiware.net
RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/122.256, ICQ: 13038757
--- ifmail v.2.15dev5
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
