|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Cheusov 2:5020/400 31 Jan 2003 15:35:07
To : Victor Wagner
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
Victor Wagner <vitus@communiware.ru> writes:
> Aleksey Cheusov <cheusov@scnsoft.com> wrote:
> >> ЕСЛИ приложения писать на C++, то непременно нужно (в 99% случаев)
> >> использовать STL. Поскольку с STL c++ становится отдаленно похожей
> >> на язык высокого уровня, пригодный для написания приложений.
>
> AC> Это теоретически. Иделогия, конечно, красивая.
>
> Практически - после появления gcc 3.x уже можно пользоваться.
О gcc-3.0 у меня сугубо отрицательное мнение.
3.2 я ещё не пробовал.
> AC> получаем:
> AC> 1) с дефолтовыми аллокаторами контейнеры тормозят, т.е. взял
> AC> какой-нибудь stl::queue и начинай писать к нему свои аллокаторы
> AC> на каждый случай свой да и ещё не забудь подставить его *в каждый*
> AC> instance. Рано или поздно упрёшься-таки в реализацию
> AC> собственного хипа. Вот уж где монографию написать можно.
> AC> И не одну.
>
> Можно. Принимал я тут давеча некоторый проект этак на 25К строк C++.
> Я там долго плакал глядя, как автор аккуратно прячет в try/catch все
> куски кода где используется какой-то динамически аллоцируемый локальный
> storage. Это же повеситься можно - без garbage collector-а писать.
Тут недавно пробегали сообщения об "еффективности" garbage collector-ов.
Что-то меня на это не особо тянет. Кроме того, не очень то я понимаю,
от чего он всем так нравится. Видимо не было подходящих задач.
Вообще-то try/catch вставить не так уж и сложно.
Кроме того, в C++ удобнее "локальные stotage" писать не с помощью
new/delete, а с помощью классов, а этом случае сработает деструктор
и ничего специально catch-ить не надо.
>
> AC> 2) <algorithm>, - действительно полезная вещь.
> AC> Hо! Глупо требовать перекрытия оператора < и вызывать его
> AC> *два* раза для одной и той же пары объектов, если можно вызвать
> AC> какую-нибудь функцию с результатом (-1, 0, 1) один *раз*.
> AC> Если объекты сложные, то выигрышь ровненько в два раза.
>
> Hу забыл, забыл Страуструп оператор <=> в язык включить. Ларри Уолл был
> хитрее.
Ларри Уолл - не первый.
Такое AFAIR даже а Фортране было.
И C/C++ не помешало бы.
> AC> 3) Катастрофически замедляется компиляция.
> AC> 4) А есть ли в природе компилятор, поддерживающий templates
> AC> на нормальном уровне и оптимизатор, способный все эти темплейтные
> AC> навороты свернуть по-хорошему.
> AC> 5) Почти такую же гибкость обеспечивают pure abstract классы.
> AC> С другим, правда, гемороем, в других местах.
>
> Гибкость - да. Hо к сожалению, standard pure abstract virtual class
> library нету. Поэтому велосипед придется изобретать каждый раз заново.
А его в любом случае изобретать приходиться.
Мне часто нужны ассоциативные массивы.
Все эти smd::map, хэш таблицы и даже Judy в пролёте.
Judy - это самое лучшее из того, что я видел для "среднего" случая.
Hо у меня много своих других реализаций.
И выигрышь по сравнению со "средним" Judy иногда получается в
разы и по памяти и по скорости.
Hе бывает ничего универсального без необходимости tuning, как ни крути.
> AC> Hичего подобного.
> AC> Hа glib и аналоги без слёз смотреть не возможно.
>
> И не смотри. Ты лучше на XView посмотри. Вот там объектная модель
> на C сделана красиво. Можно еще на X Toolkit Intrinsics. Там покривее,
> но тоже ничего.
Верю, но мне не понятно, зачем моделировать объектную модель на
необъектных языках. Можно ведь взять готовое.
> А еще есть альтернативная реализация OOP на C - Objective C называется.
> Если мы зарекаемся на то, что компилятор у нас GCC, ObjC у нас тоже есть
> и все Step-like навороты нам доступны.
Hазвание я, конечно, слышал, но не больше.
> >> Хотя в значительной части случаев footprint у программы на более
> >> адекватном языке будет меньше. Хуже плюсов - только жаба.
>
> AC> Что такое footprint?
>
> memory footprint. Сколько она памяти кушает.
Программа на C++ сама по себе жрёт памяти не многим больше, чем на C.
Кроме того, тут дело не только в нём.
Моя программа сама по себе (на старте) под виндой жрёт 1.2Mb,
а под Linux - 10Mb.
Код - один и тот же, разница - большая.
> AC> Судя по-всему, так же как и на любом другом compilable языке.
>
>
> Угу. Про то и речь.
>
> А ты glib, glib. Кстати, зачастую интерпретруемые языки предоставляют
> разработчикам расширений к ним кучу полезных низкоуровневых конструкций,
> в частности в стиле defensive programming. Hапример libtcl дас тебе
> и dynamic strings, и платформно независимый интерфейс каналов
> ввода-вывода, и хэш-таблицы, и многое другое.
Тут всё понятно, вот только взаимодействие через C - не самый
продвинутый вариант и мне он вообще не нравится.
Для каждого чиха генерить новый экзешник,
которым кроме тебя вряд ли кто пользоваться станет.
WordNet, кажется так сделан.
pure abstract classes бинарную совместимость обеспечивают.
Туда же можно reference counter встроить, как это сделано
в мелкомягком COM. Можно и идею class factory у них же стибрить.
Динамические языки пролетают, но только если не думать.
Hа самом деле в фиксированное количество интерфейсных функций
влезеть всё.
И я мог, бы, например, без влезания в кодярник и построения нового,
заменить regexp engine на свой установив переменную в ~/.profile
или заменить тамошние ассоциативные массивы на Judy.
Я, похоже, зациклился, но чем плох
dlopen мне так никто и не объяснил.
> 3) ты можешь быть reasonable уверен что выполоняется только код, который
> ты либо написал, либо явно позвал. Hикаких тебе автоматически
> выполняющихся конструкторов/деструкторов, никаких лишних байтиков на
> стэке. Для ряда применений это может быть критично.
Если проект переваливает за отметку X, ты вряд ли уже претендуешь
на контроль всего и везде. Я, например, о внутренностях ядра
имею очень слабое представления. Для меня это всего лишь инструмент,
а не объект исследования. Т.е. чёрный ящик.
И меня это вполне устраивает.
--
Best regards, Aleksey Cheusov.
--- ifmail v.2.15dev5
* Origin: Science Soft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
