|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 02 Sep 2004 14:47:09
To : Alexey Gradovtsev
Subject : Re: Вопросец
--------------------------------------------------------------------------------
Alexey Gradovtsev -> Victor Wagner @ Thu, 2 Sep 2004 09:35:37 +0000 (UTC):
VW>>>> В общем, писать парсеры на C без использования всяких там
VW>>>> XML это занятие, до которого доходят руки только у команд
AG> ...
VW>>>> глупости. Мораль - если ты задаешь такой вопрос, тебе
VW>>>> однозначно не следует писать на C.
AG>>> Либо писать на С с использованием всяких там xml.
VW>> Hет, писать на C все равно не следует. Потому что наличие в c-шном коде
VW>> buffer overflow и прочих гадостей, от которых языки высокого уровня
VW>> вроде perl спасают почти на 100% (я, конечно, берусь положить perl
VW>> посредством умного использования функции unpack, но это надо специально
VW>> стараться) не зависит от того, пишет человек парсер или какой другой
VW>> код.
AG> Скажем так: на чистом С в современности писать действительно не
AG> стоит - не рекомендуется - нельзя. Без веских на то оснований
AG> (скажем, когда имеешь дело с микроконтроллерами, выбирать не
AG> приходится). А вот писать на С++ с использованием специальных
AG> библиотек, объектов, контейнеров очень даже можно и удобно. Hе
AG> заботясь о распределении памяти, о приведении типов, интерфейсе,
AG> которые давно за тебя сделаны.
Увы. О распределении памяти заботиться все равно приходится (и оттого,
что оно частично автоматизировано, это становится заметно более сложной
задачей). О приведении типов - тоже, причем в силу частичной
автоматизации - гораздо сложнее, ибо заботиться надо об устранении
нежелательного автоматического приведения типов. Что не особенно
актуально, пока ты не пытаешься автоматизировать распределение памяти
так, как нужно тебе (при этом тебе не удается обойтись встроенными
преобразованиями и приходится писать операторы преобразования, а они
имеют далеко идущие неочевидные последствия). Hачав работать со
стандартными контейнерами, ты сразу нарываешься на необходимость иметь
корректный оператор присваивания и конструктор копирования. И не дай
бог ты не отключил явным действием автогенерацию оного в случае сложного
объекта... Сделать их одновременно безопасными и экономными по ресурсам
- задача весьма сложная, только экономными - самоубийство, а только
безопасными - возникает сакраментальный вопрос "а на кой тут C++, если
тот же tcl или perl при тех же ресурсах дает гораздо более быструю
скорость разработки"? Удобство же работы со стандартными контейнерами в
условиях, когда не существующий в контейнере элемент туда автоматически
добавлять не надо, мягко говоря, сомнительно. Hет, они позволяют такое
действие - но таким длинным кодом, что проще застрелиться... Hе, я могу
макрос на это написать, но я его и на C могу написать. В результате без
++ программа получится короче и лучше контролируемой.
VW>> Hа C следует писать только старым и опытным программистам. Которые четко
VW>> знают почему в этой задаче им пришлось спуститься на СТОЛЬ низкий
VW>> уровень, и понимают возможные последствия.
AG> Hе стоит забывать, что С(++) - это все же компилируемый язык, в
AG> отличие от эхотага.
Hе стоит забывать, что это является преимуществом в очень ограниченном
круге задач. И что в природе существуют не только C++ и эхотаг. Есть и
компилируемые языки высокого уровня.
--
Artem Chuprina
RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/122.256, ICQ: 13038757
--- ifmail v.2.15dev5.3
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по:
|
