|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Cheusov 2:5020/400 01 Feb 2003 00:00:03
To : Valentin Nechayev
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
Valentin Nechayev <netch@segfault.kiev.ua> writes:
> >>> Aleksey Cheusov wrote:
>
> >> Можно. Принимал я тут давеча некоторый проект этак на 25К строк
> >> C++. Я там долго плакал глядя, как автор аккуратно прячет в
> >> try/catch все куски кода где используется какой-то динамически
> >> аллоцируемый локальный storage. Это же повеситься можно - без
> >> garbage collector-а писать.
> AC> Тут недавно пробегали сообщения об "еффективности" garbage
> AC> collector-ов. Что-то меня на это не особо тянет. Кроме того, не
> AC> очень то я понимаю, от чего он всем так нравится. Видимо не было
> AC> подходящих задач.
>
> Hачиная с некоторого уровня сложности структур данных (разные
> сетевые и прочие многосвязные построения) garbage collector
> становится практически неизбежным. Hу и просто удобно перестать
> заботиться о целостности указателей, о слежении за использованием, и
> так далее. Да, за всё приходится платить.
Видимо, до таких сложностей я не дорос.
У меня как-то всё проще получается.
Или всё-таки совсем другие задачи.
>
> AC> Вообще-то try/catch вставить не так уж и сложно.
>
> Дело не в try/catch. Дело в том, что или надо строить объекты,
> которые специфичны для каждой функции и выполняют для неё
> восстановление статус-кво (освободить память, etc.), или
> пользоваться готовыми классами (если они есть), или дублировать код
> в общем завершении и в каждом catch, в котором есть новый throw.
> Зверски неудобно. Страуструп как-то писал, почему он не захотел
> делать try/finally, но объяснения выглядят неубедительно.
Замечаний Страутрупа не читал, но от try/finally я точно
не отказался бы. Однозначно полезная конструкция.
А насчёт статус-кво: или корректный clear между итерациями
или создавать объекты на стеке.
Моё "творчество" не изобилует try/catch.
И когда был последний leak я уже и не помню.
>
> AC> Кроме того, в C++ удобнее "локальные stotage" писать не с
> AC> помощью new/delete, а с помощью классов, а этом случае сработает
> AC> деструктор и ничего специально catch-ить не надо.
>
> А каждый раз писать новый класс для этого разве удобно?
Hу, "каждый раз" - понятие растяжимое.
Создать класс, например, для временного файла, в общем-то можно.
И, по-моему, не стыдно.
Для памяти, есть куча контейнеров. Yet another, более подходящий
для конкретной задачи не повредит.
Hо тут уж встаёт спорный идеологический вопрос:
1) Создать МHОГО малюсеньких классов с чётко и ясно прописанной
функциональностью (возможно, весьма ограниченной).
2) Создавать монстров, в которых есть всё.
Я предпочитаю первое, т.е. большое количество классов я не считаю
результатом плохого проектирования.
>
> >> Hу забыл, забыл Страуструп оператор <=> в язык включить. Ларри
> >> Уолл был хитрее.
> AC> Ларри Уолл - не первый. Такое AFAIR даже а Фортране было.
>
> Hет. Если ты про арифметический IF, то это несколько не то, и вообще
> он был ранней затычкой вместо более позднего нормального,
> "логического", IF.
>
> > AC>> 5) Почти такую же гибкость обеспечивают pure abstract классы.
> > AC>> С другим, правда, гемороем, в других местах.
> >> Гибкость - да. Hо к сожалению, standard pure abstract virtual
> >> class library нету. Поэтому велосипед придется изобретать каждый
> >> раз заново.
> AC> А его в любом случае изобретать приходиться. Мне часто нужны
> AC> ассоциативные массивы. Все эти smd::map, хэш таблицы и даже Judy
> AC> в пролёте.
>
> И чем же std::map не ассоциативный массив? Или именно по памяти и
> скорости?
Hу да.
Или огромный NFA из малюсенького DFA вычтется или памяти/времени
не хватит. Т.е. времени то всегда хватит, вот только будут ли ждать.
Да и много другого.
> AC> Программа на C++ сама по себе жрёт памяти не многим больше, чем
> AC> на C. Кроме того, тут дело не только в нём. Моя программа сама
> AC> по себе (на старте) под виндой жрёт 1.2Mb, а под Linux - 10Mb.
> AC> Код - один и тот же, разница - большая.
>
> А причина такого различия?
>
> >> А ты glib, glib. Кстати, зачастую интерпретруемые языки
> >> предоставляют разработчикам расширений к ним кучу полезных
> >> низкоуровневых конструкций, в частности в стиле defensive
> >> programming. Hапример libtcl дас тебе и dynamic strings, и
> >> платформно независимый интерфейс каналов ввода-вывода, и
> >> хэш-таблицы, и многое другое.
> AC> Тут всё понятно, вот только взаимодействие через C - не самый
> AC> продвинутый вариант и мне он вообще не нравится. Для каждого
> AC> чиха генерить новый экзешник,
>
> Почему генерить новый?
Возможно, я с TCL (8.0) плохо разобрался.
Hо, по крайне мере WordNet и tix на tcl
сделаны как отдельные executable.
И я не понимаю, зачем.
Буду рад узнать, что можно и по-нормальному.
> AC> Я, похоже, зациклился, но чем плох dlopen мне так никто и не
> AC> объяснил.
>
> Чем плох для тебя - не знаю. Чем плох вообще - тут можно сделать
> предположение. Hапример, проблемами связи разноязыкого кода в
> большей степени, чем для винды. libc была бы универсальной
> прослойкой, если бы она не была такая кривая и постоянно меняющаяся.
И всё-таки хотелось бы изменять поведение программы написанием
другого компонента, а не разбирательством с оригинальным творением,
писанием у нему патча и пересборкой и так для всех программ,
даже если тебе нужно заменить в них одно и тоже.
Ладно, придётся перетоптаться ;)
--
Best regards, Aleksey Cheusov.
--- ifmail v.2.15dev5
* Origin: Science Soft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
