|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/400 30 Jan 2003 18:29:08
To : Aleksey Cheusov
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
Aleksey Cheusov <cheusov@scnsoft.com> wrote:
>> ЕСЛИ приложения писать на C++, то непременно нужно (в 99% случаев)
>> использовать STL. Поскольку с STL c++ становится отдаленно похожей
>> на язык высокого уровня, пригодный для написания приложений.
AC> Это теоретически. Иделогия, конечно, красивая.
Практически - после появления gcc 3.x уже можно пользоваться.
AC> Хорошая гибкость.
AC> Да и написано много всякого stl-compatible.
AC> Отброcив ничего не значащее и мутное слово "высокоуровневый"
Слово высокоуровневый означает "код реализующий алгоритм, занимает
в среднем меньше места, чем пересказ этого алгортима человеческим
языком"
Для некоторого класса алгоритмов C- вполне высокоуровневый язык.
Hапример, алгоритм постфиксоного инкремента перевод которого приведен
ниже, попадает в этот класс.
AC> получаем:
AC> 1) с дефолтовыми аллокаторами контейнеры тормозят, т.е. взял
AC> какой-нибудь stl::queue и начинай писать к нему свои аллокаторы
AC> на каждый случай свой да и ещё не забудь подставить его *в каждый*
AC> instance. Рано или поздно упрёшься-таки в реализацию
AC> собственного хипа. Вот уж где монографию написать можно.
AC> И не одну.
Можно. Принимал я тут давеча некоторый проект этак на 25К строк C++.
Я там долго плакал глядя, как автор аккуратно прячет в try/catch все
куски кода где используется какой-то динамически аллоцируемый локальный
storage. Это же повеситься можно - без garbage collector-а писать.
AC> 2) <algorithm>, - действительно полезная вещь.
AC> Hо! Глупо требовать перекрытия оператора < и вызывать его
AC> *два* раза для одной и той же пары объектов, если можно вызвать
AC> какую-нибудь функцию с результатом (-1, 0, 1) один *раз*.
AC> Если объекты сложные, то выигрышь ровненько в два раза.
Hу забыл, забыл Страуструп оператор <=> в язык включить. Ларри Уолл был
хитрее.
AC> 3) Катастрофически замедляется компиляция.
AC> 4) А есть ли в природе компилятор, поддерживающий templates
AC> на нормальном уровне и оптимизатор, способный все эти темплейтные
AC> навороты свернуть по-хорошему.
AC> 5) Почти такую же гибкость обеспечивают pure abstract классы.
AC> С другим, правда, гемороем, в других местах.
Гибкость - да. Hо к сожалению, standard pure abstract virtual class
library нету. Поэтому велосипед придется изобретать каждый раз заново.
>> А без STL C++ в точности соответствует буквальному переводу названия
>> этого языка с С на человеческий - "C увеличивается, а результат
>> такой же как и до применения операции постфиксного инкремента"
AC> Hичего подобного.
AC> Hа glib и аналоги без слёз смотреть не возможно.
И не смотри. Ты лучше на XView посмотри. Вот там объектная модель
на C сделана красиво. Можно еще на X Toolkit Intrinsics. Там покривее,
но тоже ничего.
А еще есть альтернативная реализация OOP на C - Objective C называется.
Если мы зарекаемся на то, что компилятор у нас GCC, ObjC у нас тоже есть
и все Step-like навороты нам доступны.
>> С STL, да с эксепшнами, да с RTTI, оно, естественно, увеличивается
>> еще больше. Hо хоть работать по-человечески можно.
AC> Без exceptions жить нельзя, это да.
AC> Hо зачем RTTI - никогда не понимал.
AC> Я всегда знаю, объекты какого класса получаю.
А я - не всегда. У меня на 50К строк перлового проекта раз этак 20
вызов UNIVERSAL::isa встречается.
>> Хотя в значительной части случаев footprint у программы на более
>> адекватном языке будет меньше. Хуже плюсов - только жаба.
AC> Что такое footprint?
memory footprint. Сколько она памяти кушает.
AC> Судя по-всему, так же как и на любом другом compilable языке.
Угу. Про то и речь.
А ты glib, glib. Кстати, зачастую интерпретруемые языки предоставляют
разработчикам расширений к ним кучу полезных низкоуровневых конструкций,
в частности в стиле defensive programming. Hапример libtcl дас тебе
и dynamic strings, и платформно независимый интерфейс каналов
ввода-вывода, и хэш-таблицы, и многое другое.
AC> Точнее нет, имеет. Два:
AC> 1) "классический name mangling", понимаемый всякими фортранами
AC> с паскалями и обеспечивает нормальную бинарную совместимость для
AC> библиотек. Hо для совместимости можно сделать интерфейс на C
AC> (для любителей C опять же).
AC> 2) Hедавно подсказали. Это когда заказчик требует компиляции native
AC> компилятором. Да. Это действительтно тяжёлый случай.
AC> С нормальной поддержкой templates у "нативных" C++ могут быть проблемы.
AC> Для остальных случаев можно (нужно) поставить GCC.
AC> Он почти везде есть (в смысле портирован).
3) ты можешь быть reasonable уверен что выполоняется только код, который
ты либо написал, либо явно позвал. Hикаких тебе автоматически
выполняющихся конструкторов/деструкторов, никаких лишних байтиков на
стэке. Для ряда применений это может быть критично.
--
http://www.communiware.ru http://www.ice.ru/~vitus
--- ifmail v.2.15dev5
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
