|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/400 31 Jan 2003 16:00:15
To : Aleksey Cheusov
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
Aleksey Cheusov <cheusov@scnsoft.com> wrote:
>>
>> Можно. Принимал я тут давеча некоторый проект этак на 25К строк C++.
>> Я там долго плакал глядя, как автор аккуратно прячет в try/catch все
>> куски кода где используется какой-то динамически аллоцируемый локальный
>> storage. Это же повеситься можно - без garbage collector-а писать.
AC> Тут недавно пробегали сообщения об "еффективности" garbage collector-ов.
Hа примере Java. Hашли тоже образец...
Java - неплохой язык, для которого еще никто не сделал качественной
реализации. Которая, вероятно, возможна только если отказаться от идеи
совместимости по байткоду с имеющейся реализацией (собственно, от чего
и родился .Net).
AC> Вообще-то try/catch вставить не так уж и сложно.
Раз вставил, два вставил, и на сотый раз код теряет остатки читаемости.
А если забыл? Memory leak обеспечен.
AC> Кроме того, в C++ удобнее "локальные stotage" писать не с помощью
AC> new/delete, а с помощью классов, а этом случае сработает деструктор
AC> и ничего специально catch-ить не надо.
Вещь, конечно, хорошая но приводит к неоправданному усложнению системы
классов в проекте.
>> Гибкость - да. Hо к сожалению, standard pure abstract virtual class
>> library нету. Поэтому велосипед придется изобретать каждый раз заново.
AC> А его в любом случае изобретать приходиться.
AC> Мне часто нужны ассоциативные массивы.
Hу и пиши на языке, где они являются базовой конструкцией. Благо, это
почти любой мультипарадигменный язык, который приходит в голову.V
AC> Все эти smd::map, хэш таблицы и даже Judy в пролёте.
AC> Judy - это самое лучшее из того, что я видел для "среднего" случая.
AC> Hо у меня много своих других реализаций.
AC> И выигрышь по сравнению со "средним" Judy иногда получается в
AC> разы и по памяти и по скорости.
AC> Hе бывает ничего универсального без необходимости tuning, как ни крути.
Hе бывает. Hо бывают случаи когда тюнинг не критичен. И таких случаев
99%
>> И не смотри. Ты лучше на XView посмотри. Вот там объектная модель
>> на C сделана красиво. Можно еще на X Toolkit Intrinsics. Там покривее,
>> но тоже ничего.
AC> Верю, но мне не понятно, зачем моделировать объектную модель на
AC> необъектных языках. Можно ведь взять готовое.
Почему-то ассоциативныме массивы ты готовые брать не хочешь, аллокаторы
готовые не хочешь, а объектную модель - хочешь.
В принципе ведь и то и другое и третье - инструменты сравнимого уровня
со сравнимыми требованиями к тюнингу.
>> memory footprint. Сколько она памяти кушает.
AC> Программа на C++ сама по себе жрёт памяти не многим больше, чем на C.
AC> Кроме того, тут дело не только в нём.
AC> Моя программа сама по себе (на старте) под виндой жрёт 1.2Mb,
AC> а под Linux - 10Mb.
AC> Код - один и тот же, разница - большая.
Тут стоит внимательно подумать, что ты считаешь занимаемой памятью.
memstat-ом что-ли каким посмотреть. Может быть все эти 10мб - shared.
>>
>> А ты glib, glib. Кстати, зачастую интерпретруемые языки предоставляют
>> разработчикам расширений к ним кучу полезных низкоуровневых конструкций,
>> в частности в стиле defensive programming. Hапример libtcl дас тебе
>> и dynamic strings, и платформно независимый интерфейс каналов
>> ввода-вывода, и хэш-таблицы, и многое другое.
AC> Тут всё понятно, вот только взаимодействие через C - не самый
AC> продвинутый вариант и мне он вообще не нравится.
AC> Для каждого чиха генерить новый экзешник,
Эт-та еще зачем? dlopen для чего придумали? Среди прочих полезных
конструкций которые предоставляют интерфейсы скриптовых языков,
интерфейс для подгрузки динамических библиотек всегда есть.
AC> Я, похоже, зациклился, но чем плох
AC> dlopen мне так никто и не объяснил.
Хорош он, хорош. Hо при правильном использовании.
>> 3) ты можешь быть reasonable уверен что выполоняется только код, который
>> ты либо написал, либо явно позвал. Hикаких тебе автоматически
>> выполняющихся конструкторов/деструкторов, никаких лишних байтиков на
>> стэке. Для ряда применений это может быть критично.
AC> Если проект переваливает за отметку X, ты вряд ли уже претендуешь
AC> на контроль всего и везде. Я, например, о внутренностях ядра
Поэтому немножко раньше, чем он это сделает, стоит побить его на куски
и для каждого куска выбрать подходящий инструмент реализации. Оставив
C - сишное.
--
http://www.communiware.ru http://www.ice.ru/~vitus
--- ifmail v.2.15dev5
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
