Форум для общения
Нам скоро 15 лет!

форум, общение

48/50

Форум "Delphi"


Паскаль, Делфи


 #0 Ketmar © 02.03.03 17:05:35 - 20.06.06 00:13:41

Статья про недостатки цпп (я убью тебя, лодочник, за 500 символов!)



Major flaws of C++
c 2002 by Stefan Metzeler, Jul-2002
Кривой перевод: Ketmar // Piranha
ПРЕДУПРЕЖДЕНИЕ: статья переведена с купюрами, некоторые места безбожно искажены. Претензии не принимаются. Всем недовольным советую пойти и почитать оригинал.
ПРЕДУПРЕЖДЕНИЕ: ошибки в тексте таковыми не считаются.

В отличие от Оберона, который является результатом настоящих исследований, проведённых групой хороших экспертов в области проектирования языков, C++ -- это просто п

Satanas Nobiscum!   02-Mar-XXXVIII A.S. Цитата

 #1 Ketmar © 02.03.03 17:06:38

это просто п.здец!

Satanas Nobiscum!   02-Mar-XXXVIII A.S.
 #2 Ketmar © 02.03.03 17:07:33

Major flaws of C++
c 2002 by Stefan Metzeler, Jul-2002
Кривой перевод: Ketmar // Piranha
ПРЕДУПРЕЖДЕНИЕ: статья переведена с купюрами, некоторые места безбожно искажены. Претензии не принимаются. Всем недовольным советую пойти и почитать оригинал.
ПРЕДУПРЕЖДЕНИЕ: ошибки в тексте таковыми не считаются.

В отличие от Оберона, который является результатом настоящих исследований, проведённых групой хороших экспертов в области проектирования языков, C++ -- это просто попытка добавить новые возможности в старый язык C (да так, чтобы не нарушить совместимость). Автор C++ (Страуструп, если кто не знает) никогда не делал исследований, могущих послужить доказательством необходимости и удобства тех "рюшечек", которые были добавлены в язык (о чём Страуструп, кстати, сам пишет в своей книге по C++: "Формальной спецификации языка никогда не было. Мы придумывали что-то, и сразу добавляли это в компилятор". Кулибины, блин. Ketmar). Страуструп включил в язык всё, что можно было: множественное наследование, Genericity (ну не знаю я, что это! Ketmar), перегрузку операторов... все те рюшечки, от которых так "балдеют" цисты.

В то же время Страуструп проигнорировал многие принципы дизайна языков программирования, даже такие, которые были признаны фундаментальными для современной технологии программирования. В основном потому, что был вынужден соблюдать совместимость с C. Глядя на популярность C++, некоторые удивляются, будут ли в нём устранены ошибки, как пришедшие из древнего C, так и новые, родные для C++. Тот факт, что есть "комитет по стандартам" не очень обнадёживает: комитеты обычно добавляют новые "рюшечки", вместо починки или исключения стрых (вот оригинальный текст: <Committees tend to include the kitchen sink - after removing the water tab, to make it "safe"> -- Комитеты обычно стремятся добавить кухонную раковину -- после того, как убрали водопроводный кран, чтобы сделать её "безопасной").

В любом случае, роль комитетов весьма ограничена. Они, в основном, могут только добавлять "рюшечки", поскольку практически невозможно что-нибудь убрать без "объявления военных действий" (т.е. без нарушения совместимости и прочих прелестей). Поэтому C++ всегда будет похожим на C, со всеми недостатками последнего. Таким образом, нижеследующий список будет актуален еще долго...

Пожалуйста, отметьте, что не все ошибки "ненамеренны". Любой недовольный работник, который ищет хороший способ "заставить босса платить" может внести тонкую и очень сложную для локализации (с последующим уничтожением) ошибку в исходный код приложения.


Проблема: Нет сборщика мусора
Описание:
Отсутствие сборщика мусора (GC) -- это заметный дефект, особенно для языка, позиционирующегося как объектно-ориентированный. Когда код становится достаточно сложным и изменяющимся, становится практически невозможно отследить все объекты, передающиеся туда и сюда. Приложение, которое хочет это сделать (на самом деле этого хотят программисты, ну да ладно. Ketmar), практически должно иметь собственный сборщик мусора. Но настоящий GC не может быть добавлен в C++, если не усечь язык до безопасного подмножества (примерно так, как сделано в Java). Но в таком случае это уже не будет C++, и, тем более, он не будет C-совместимым.

Редактор GUI -- типичный пример. Практически невозможно предсказать, как пользователь будет двигать и копировать объекты, и какие устанавливать между ними связи. Технология Drag''n''Drop позволяет делать практически непрогнозируемые переупорядочивания структур данных. При отсутствии сборщика мусора единственный путь, доступный программисту на C++ -- или потратить огромное количество времени (и написать кучу кода) для контроля каждого объекта, или просто ограничить возможности программы до более-менее упрявляемых.
Вывод:
Отстутсвие сборщика мусора очень серьезно ограничивает возможности программиста.
Итого: отсутствие важной возможности


Проблема: Отсутствие модулей
Описание:
Модули признаны фундаментальными строительными блоками для программ с конца восьмидесятых годов. Modula-2 -- важный (но, естественно, не единственный) член (извините... Ketmar) семьи модульных языков. Пакеты есть в Ada, нечто похожее имеется в Java и Eiffel. У C++ есть include-файлы. Так в чём тогда проблема?
* В C++ нет концепции "локальности". Все глобально. Когда вы объявляете глобальную переменную, процедуру или класс в вайле CPP, это потенциальный конфликт с любой переменной, имеющей то же имя и находящейся в другом CPP-файле, который будет прилинкован к программе (пусть перевод звучит так. Ketmar). Можули же предоставляют пространства имён "бесплатно".

Satanas Nobiscum!   02-Mar-XXXVIII A.S.
 #3 Ketmar © 02.03.03 17:08:23

* Модуль -- важный структурный элемент, который хорошо представляется в UML-диаграммах. Модуль -- это не просто файл, и класс чаще всего не заменитель модулю. Взаимоотношения между классами могут быть установлены внутри модуля, уничтожая необходимость в "дружественных" ("firend") отношениях. Зависимые классы могут быть расширены "снаружи", если они экспортированы, что невозможно для дочерних классов в C++.
* Использование классов для инкапсуляции и как заменителей модулям -- преступление в программировании. Это полностью уничтожает концепцию ООП, что ведёт к синтаксическим и семантическим проблемам. В процессе анализа становится невозможно отделить одни сущности от других. Но такой подход -- единственная возможность преодолеть недостаток C++ (отсутствие модулей). И подход этот создаёт кучу новых проблем.
* Модули -- единицы инкапсуляции, которые могут упрятывать или экспортировать константы, классы, переменные и процедуры.
* Модули -- полностью самостоятельные еденицы с автоматической инициализацией (и деинициализацией, если она необходима).
* Факт импортирования модуля не ведёт к автоматической видимости и доступности всех объектов, находящихся внутри модуля.
* Перенос объекта из одного модуля в другой имеет значение (важен), поскольку модуль не просто контейнер. Так как модуль -- это структурная еденица, и тот факт, что объект находится в модуле X или в модуле Y имеет логические последствия. В C/C++ вы можете хорошо использовать соглашения по именованию, но когда вы переносите класс DB_Table из файла DB.C в файл SQL.C, это не имеет никакого значения. Отсутствие последовательности не приведёт к ошибкам и не заставит поправить клиентские модули, которые могут быть "задеты" изменениями. (что-то мне в этом абзаце не нравится перевод... Ketmar)
* Каждый модуль Оберона, будучи скомпилированным, генерирует символьный файл (гы. компилятор это делает, а не модуль. Ketmar), который поставляется отдельно от кода модуля и даже внешнего заголовочного файла. Поэтому не требуется дополнительных усилий для сопровождения заголовочных файлов (или defintion module в случае Modula-2).
* Символьные файлы намного увеличивают скорость компиляции. Любая компиляция, импортирующая заголовочные файлы Windows будет "ползать" в C++, в то время как Оберон может прочесть 20 заголовочных файлов, включая полные заголовки для Windows API со скоростью, от которой захватывает дух.
Итого: отсутствие важной возможности


Проблема: Нет многомерных динамических массивов
Описание:
Современное программирование -- динамическое программирование. Вам обычно нужны не статические структуры с заранее определённым размером, вам нужны динамические структуры. Таблицы не всё время одномерны, часто они имеют 2 и даже больше измерений. Если каждое измерение в таблице само может быть динамическим (что часто и бывает), то у вас проблемы. Вы или должны делать всё при помощи других структур данных, что может быть достаточно сложно, или создавать специфический механизм доступа (такой, например, как перегруженые "[]"). Перегрузку мы рассмотрим позже, а пока просто представьте весь тот код, который вы должны таскать за собой просто для работы со столь простыми структурами. Принимая во внимание размер C++ несколько обескураживает то, что даже такие простые возможности толком не поддерживаются.
Итого: отсутствие важной возможности


Проблема: "Неквалифицированные" идентификаторы
Описание:
При использовании общего механизма #include невозможно определить, из какой секции кода (не говоря уже о том, из какого файла) пришёл данный идентификатор. Он может быть определён в том же самом файле, в заголовочном файле, в заголовочном файле, который используется в другом заголовочном вайле, и так далее... Вот почему программисты на C/C++ стремятся использовать огромные префиксы и неудобные имена для любых идентификаторов, которые описаны в заголовочных файлах. Эти префиксы, естественно, не определены жёстко раз и навсегда, они должны базироваться на каких-то соглашениях. Неправильно написанные или пропущенные префиксные строки не вызовут со стороны компилятора никаких нареканий.

Простанства имён только облегчают решение проблемы конфликтов имён, они не помогут вам распознать каждый идентификатор в отдельном данном куске кода. Обычное решение этой проблемы -- утилиты, наподобие базы данных идентификаторов, файлов помощи и планирования, и "grep"''а -- поиска идентификатора по всем файлам проекта.

Satanas Nobiscum!   02-Mar-XXXVIII A.S.
 #4 Ketmar © 02.03.03 17:08:44

Когда вы программируете на Обероне, подобная проблема кажется очень чужеродной. Вы смотрите на участок кода и мгновенно видите, какие идентификаторы локальны для модуля и какие имортированы. Вы также знаете, из какого модуля. Вам не надо ломать голову, строя предположения и проверяя догадки. Код сразу приобретает смысл. Одинаковые идентификаторы могут быть использованы в разных модулях. Таким образом, локальный код может быть очень компактным, с короткими идентификаторами, которые отлично вписываются в существующий контекст. Только когда вы покидаете локальный модуль, вам надо использовать послные идентификаторы.

Это особенно ценно при разработке больших библиотек общего пользования и использовании компонентов из разных источников. Это абсолютно необходимо также когда вы читаете код, над которым давно не работали. Вряд ли вы сразу вспомните, откуда пришёл каждый импортированый идентификатор и что он значит.
Итого: отсутствие важной возможности

Satanas Nobiscum!   02-Mar-XXXVIII A.S.
 #5 Ketmar © 02.03.03 17:09:48

так. форматирование и стили потерялись на .уй. версия перевода -- альфа, замечание принимаются.

  продолжение будет, как только я его сделаю (там ещё много).

Satanas Nobiscum!   02-Mar-XXXVIII A.S.
 #6  Shadow © 03.03.03 14:47:41

А нах уй вообще?
 #7  Anikul © 03.03.03 18:11:45

А в смысле при чём тут C++, если форум по Delphi
 #8 Ketmar © 03.03.03 18:21:09

при том, что в статье так ненавязциво хвалят Оберон. поскольку отдельного форума по Оберону нет -- кидаю сюда. доправлю -- кину еще Oberon-2 vs C++.

Satanas Nobiscum!   03-Mar-XXXVIII A.S.
 #9  Anikul © 03.03.03 18:54:07

> отдельного форума
> нет
> vs C++.
А форум по С++ не устраивает, и поэтому давай всё в Delphi пихать, да ещё тоннами, ДА?
 #10 Ketmar © 03.03.03 19:08:11

да. не нравится -- к модераторам по мылу.

Satanas Nobiscum!   03-Mar-XXXVIII A.S.
 #11  Anikul © 03.03.03 19:53:05

> Ketmar © 03.03.03 20:08
>
>  да. не нравится -- к модераторам по мылу.

Нафиг надо, просто пойми, хотел по Delph''ям посмотреть (пишу иногда) а там, как ты сказал? Оберон? Я и не знаю что енто такое, а тем более, нафиг оно нужно? Если нужно, не вопрос. Развлекайся...
 #12 Ketmar © 04.03.03 09:58:29

>Anikul © 03.03.03 20:53
  Оберон -- это предпоследнее произведение профессора Вирта. продвинутый Оберон называется Component Pascal, и является языком программирования системы BlackBox Component Builder. сама система -- среда визуально-компонентного программирования, инсталл занимает 5 мб. после дельфи нужно немного перенастраивать мозги, но когда въедешь в идеологию системы -- наступает полное просветление и ништяк.
  красть ящик (если охота посмотреть) здесь:
  вместе с ящиком идёт Component Pascal Report, также есть документ, где описываются отличия CP от простого Паскаля, еще -- неплохая книга по основам программирования в ящике, естественно -- документация по подсистемам.
  сам ящик умеет всё, что необходимо. в том числе и создавать CP-обёртки для typelibs (OLE и ActiveX''ов), имеет уже готовые средства для работы с MS Office Automation Servers, поддерживает работу с БД при помощи ODBC и ADO и так далее.

Satanas Nobiscum!   04-Mar-XXXVIII A.S.
 #13 deep © 04.03.03 11:38:08

Конечно, можно апоспорить в какой именно форум писать эту ветку - в этот, в си или в другие языки... НО, поскольку Оберон  - одна из веток Паскаля, то вполне приемлемо обсуждать его здесь. Только желательно узнавать не только - что это плохо в си, но и что другое хорошо в Обероне. Т.е. больше акцента нужно делать именно на Оберон.

 ИМХО, статья интересная. Жду продолжения.
 #14 Ketmar © 04.03.03 11:53:40

оберон -- не ветка паскаля. тут ты не прав. оберон -- это совершенно новый язык. и СОВСЕМ не паскаль. не обманывай народ. только то, что в нём присутствуют "begin" и "end" не делает его "веткой паскаля". об этом тоже будет подстатейка.

Satanas Nobiscum!   04-Mar-XXXVIII A.S.
 #15  Anikul © 04.03.03 19:34:29

Если совсем уж не сложно, спинь мне пож на мыло, а то у меня щас доступа полного в инет нет, а куда-то идти неохота!

 P.S. Заранее благодарен!
 #16 Ketmar © 05.03.03 09:58:45

>Anikul © 04.03.03 20:34
  хм. ЧТО на мыло? ящик?! сударь, мой мыльный сервер проклянёт меня и такие мои письма самыми мерзкими словами. вот мне больше нечего делать, только рубать архив на куски, ибо тебе лень ходить. проблемы негров и индейцев в данном случае шерифа никак не касаются.

Satanas Nobiscum!   05-Mar-XXXVIII A.S.
 #17  Victa 10.03.03 17:35:25

Чувствуется, что Кетмар неравнодушен к Оберону, но зачем разжигать священную войну?
Существует очень много кода, который написан на сях, от этого никуда не уйдешь, его нужно сопровождать. Некоторые заказчики хотят, чтобы проект писался на С, это тоже нужно принимать во внимание. Да и какая в принципе разница?
Кстати, как в Обероне решается конфликт имен?
 #18 Ketmar © 11.03.03 09:47:42

>Victa 10.03.03 18:35
>зачем разжигать священную войну?
  мне лично глубоко фиолетово. просто я просил у Дрёмыча форум по Оберону, на что от меня (достаточно резонно) попросили инфу о нём. самый простой вариант -- сравнить Оберон и цыпыпы. к тому же писать ничего не надо -- только перевести %-)

>Существует очень много кода, который написан на сях, от этого никуда не уйдешь, его нужно сопровождать
  а можно и переписать. что, в конце-концов, будет быстрее и дешевле, нежели сопровождать лапшу на цэ.

>Некоторые заказчики хотят, чтобы проект писался на С
  "некоторым заказчикам" глубоко по..й, на чём сделан проект. они визуально си от вб не отличат. им "рюшечка" нужна: "все пишут на си, си -- это круто, у нас тоже будет си!". в итоге писать можно на чём угодно, потом сообщить заказчикам, что всё на цэ. дел-то?

>как в Обероне решается конфликт имен?
  какой-такой "конфликт имён"? это у поклонников "единого и неделимого" (а так же паскаля, кстати) какие-то там конфликты имён наблюдаются, переполнения буферов и прочие прелести. у оберонщиков таких радостей нет. весь импорт -- КВАЛИФИЦИРОВАННЫЙ. модуль -- это не просто (и даже вовсе не) include.

Satanas Nobiscum!   11-Mar-XXXVIII A.S.
 #19 RED 19.06.06 22:50:58

кто нибудь знает проги которые открывают доступ к жосткому диску локального компа
 #20 Axis_of_Evil © 20.06.06 00:13:41

вопрос по Оберону (к Ketmar, надо думать) =
  поддерживаемый разработчиками компилятор оберона существует?
я натыкался на BlackBox, XDS, еще какие-то, но они заканчивались в
  2002-3 году.
Oberon вещь действительно хорошая (статьев немало прочитал),
  но вопрос в инструменте разработки



Написать ответ

Имя: Регистрация HTML?
smiles смайлики
Потом перейти в:    
паутина


  ©  webest.net, 2002-2017