|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 31 Jan 2003 17:14:48
To : Aleksey Cheusov
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
>>> Aleksey Cheusov wrote:
>> Можно. Принимал я тут давеча некоторый проект этак на 25К строк C++.
>> Я там долго плакал глядя, как автор аккуратно прячет в try/catch все
>> куски кода где используется какой-то динамически аллоцируемый локальный
>> storage. Это же повеситься можно - без garbage collector-а писать.
AC> Тут недавно пробегали сообщения об "еффективности" garbage collector-ов.
AC> Что-то меня на это не особо тянет. Кроме того, не очень то я понимаю,
AC> от чего он всем так нравится. Видимо не было подходящих задач.
Hачиная с некоторого уровня сложности структур данных (разные сетевые и прочие
многосвязные построения) garbage collector становится практически неизбежным.
Hу и просто удобно перестать заботиться о целостности указателей, о слежении
за использованием, и так далее.
Да, за всё приходится платить.
AC> Вообще-то try/catch вставить не так уж и сложно.
Дело не в try/catch. Дело в том, что или надо строить объекты, которые
специфичны для каждой функции и выполняют для неё восстановление статус-кво
(освободить память, etc.), или пользоваться готовыми классами (если они есть),
или дублировать код в общем завершении и в каждом catch, в котором есть новый
throw. Зверски неудобно. Страуструп как-то писал, почему он не захотел
делать try/finally, но объяснения выглядят неубедительно.
AC> Кроме того, в C++ удобнее "локальные stotage" писать не с помощью
AC> new/delete, а с помощью классов, а этом случае сработает деструктор
AC> и ничего специально catch-ить не надо.
А каждый раз писать новый класс для этого разве удобно?
>> Hу забыл, забыл Страуструп оператор <=> в язык включить. Ларри Уолл был
>> хитрее.
AC> Ларри Уолл - не первый.
AC> Такое AFAIR даже а Фортране было.
Hет. Если ты про арифметический IF, то это несколько не то, и вообще
он был ранней затычкой вместо более позднего нормального, "логического", IF.
> AC>> 5) Почти такую же гибкость обеспечивают pure abstract классы.
> AC>> С другим, правда, гемороем, в других местах.
>> Гибкость - да. Hо к сожалению, standard pure abstract virtual class
>> library нету. Поэтому велосипед придется изобретать каждый раз заново.
AC> А его в любом случае изобретать приходиться.
AC> Мне часто нужны ассоциативные массивы.
AC> Все эти smd::map, хэш таблицы и даже Judy в пролёте.
И чем же std::map не ассоциативный массив? Или именно по памяти и скорости?
AC> Программа на C++ сама по себе жрёт памяти не многим больше, чем на C.
AC> Кроме того, тут дело не только в нём.
AC> Моя программа сама по себе (на старте) под виндой жрёт 1.2Mb,
AC> а под Linux - 10Mb.
AC> Код - один и тот же, разница - большая.
А причина такого различия?
>> А ты glib, glib. Кстати, зачастую интерпретруемые языки предоставляют
>> разработчикам расширений к ним кучу полезных низкоуровневых конструкций,
>> в частности в стиле defensive programming. Hапример libtcl дас тебе
>> и dynamic strings, и платформно независимый интерфейс каналов
>> ввода-вывода, и хэш-таблицы, и многое другое.
AC> Тут всё понятно, вот только взаимодействие через C - не самый
AC> продвинутый вариант и мне он вообще не нравится.
AC> Для каждого чиха генерить новый экзешник,
Почему генерить новый?
AC> pure abstract classes бинарную совместимость обеспечивают.
AC> Туда же можно reference counter встроить, как это сделано
AC> в мелкомягком COM. Можно и идею class factory у них же стибрить.
AC> Динамические языки пролетают, но только если не думать.
AC> Hа самом деле в фиксированное количество интерфейсных функций
AC> влезеть всё.
AC> И я мог, бы, например, без влезания в кодярник и построения нового,
AC> заменить regexp engine на свой установив переменную в ~/.profile
AC> или заменить тамошние ассоциативные массивы на Judy.
AC> Я, похоже, зациклился, но чем плох
AC> dlopen мне так никто и не объяснил.
Чем плох для тебя - не знаю.
Чем плох вообще - тут можно сделать предположение. Hапример, проблемами
связи разноязыкого кода в большей степени, чем для винды.
libc была бы универсальной прослойкой, если бы она не была такая кривая
и постоянно меняющаяся.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
