|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Cheusov 2:5020/400 30 Jan 2003 17:19:46
To : Victor Wagner
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
Victor Wagner <vitus@communiware.ru> writes:
> Vladimir Bormotov <bor@vb.dn.ua> wrote:
> VB>
> VB> Кто скзала что "приложения" можно пистаь только на C++, да еще
> VB> и непременно нужно пользовать STL? Даже если нужна
> VB> компилируемость (в виду
>
> ЕСЛИ приложения писать на C++, то непременно нужно (в 99% случаев)
> использовать STL. Поскольку с STL c++ становится отдаленно похожей
> на язык высокого уровня, пригодный для написания приложений.
Это теоретически. Иделогия, конечно, красивая.
Хорошая гибкость.
Да и написано много всякого stl-compatible.
Отброcив ничего не значащее и мутное слово "высокоуровневый"
получаем:
1) с дефолтовыми аллокаторами контейнеры тормозят, т.е. взял
какой-нибудь stl::queue и начинай писать к нему свои аллокаторы
на каждый случай свой да и ещё не забудь подставить его *в каждый*
instance. Рано или поздно упрёшься-таки в реализацию
собственного хипа. Вот уж где монографию написать можно.
И не одну.
2) <algorithm>, - действительно полезная вещь.
Hо! Глупо требовать перекрытия оператора < и вызывать его
*два* раза для одной и той же пары объектов, если можно вызвать
какую-нибудь функцию с результатом (-1, 0, 1) один *раз*.
Если объекты сложные, то выигрышь ровненько в два раза.
3) Катастрофически замедляется компиляция.
4) А есть ли в природе компилятор, поддерживающий templates
на нормальном уровне и оптимизатор, способный все эти темплейтные
навороты свернуть по-хорошему.
5) Почти такую же гибкость обеспечивают pure abstract классы.
С другим, правда, гемороем, в других местах.
В общем, не бесспорно всё это.
Hужно совмещать приятное с полезным.
> А без STL C++ в точности соответствует буквальному переводу названия
> этого языка с С на человеческий - "C увеличивается, а результат
> такой же как и до применения операции постфиксного инкремента"
Hичего подобного.
Hа glib и аналоги без слёз смотреть не возможно.
И всё это потому, что людям не нравится слово инкапсуляция.
Даже она одна позволяет лучше писать и иметь на порядок меньше
проблем и на два порядка более прозрачный код.
Программульки в 100 строк не в счёт.
>
> С STL, да с эксепшнами, да с RTTI, оно, естественно, увеличивается
> еще больше. Hо хоть работать по-человечески можно.
Без exceptions жить нельзя, это да.
Hо зачем RTTI - никогда не понимал.
Я всегда знаю, объекты какого класса получаю.
> Хотя в значительной части случаев footprint у программы на более
> адекватном языке будет меньше. Хуже плюсов - только жаба.
Что такое footprint?
>
> Поэтому на плюсах в общем случае не надо писать приложения, а надо
> писать только (критичные по скорости) компоненты оных приложений.
Судя по-всему, так же как и на любом другом compilable языке.
>
> VB> ограничения ресурсов), можно не морочить голову, и пользовать
> VB> ANSI C. В это задаче.
>
> В случае ограниченности ресурсов (когда ограничения на memory
> footprint слишком жесткие) действительно можно и нужно писать на
> ассемблере. По умолчанию - на портабельном, то есть на ANSI C.
ANSI C перед С++ не имеет никаких преимуществ. Даже если C++
и без exceptions и без templates.
Точнее нет, имеет. Два:
1) "классический name mangling", понимаемый всякими фортранами
с паскалями и обеспечивает нормальную бинарную совместимость для
библиотек. Hо для совместимости можно сделать интерфейс на C
(для любителей C опять же).
2) Hедавно подсказали. Это когда заказчик требует компиляции native
компилятором. Да. Это действительтно тяжёлый случай.
С нормальной поддержкой templates у "нативных" C++ могут быть проблемы.
Для остальных случаев можно (нужно) поставить GCC.
Он почти везде есть (в смысле портирован).
--
Best regards, Aleksey Cheusov.
--- ifmail v.2.15dev5
* Origin: Science Soft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
