Ответ на »сообщение 1455« (AVC)
___________________________

Ну и как, цель достигнута? Программировать на Си++ просто и приятно?

Думаю, для Страуструпа и его друзей-приятелей цель достигнута. C++ не настолько плохой язык, каким частенько представляют его недоброжелатели. Если бы его доля на рынке была бы сопоставима с нынешним положением Оберонов, то уровень упреков в адрес C++ заметно бы понизился. Плох не язык C++ сам по себе, а его повсеместное использование - где можно и где нельзя. Но это можно сказать и о любом другом языке, каким бы замечательным и идеальным он ни представлялся. В том числе и об Обероне.

Понятие "хорошей" программы, а также "простоты" и "приятности" программирования - относительны. Здесь почти бесполезно спорить. Без ясных общепринятых критериев все сведется к вкусовщине. Как в известной пословице: что русскому хорошо, то немцу - смерть.

Ответ на »сообщение 1454« (Снегурочка)
___________________________

Ответ на »сообщение 1445« (Jean)
___________________________

>>Это не язык, это "грамматический бред".

Cи создавался как язык системного программирования в качестве замены ассемблеру. Зависимость от архитектуры обусловлена целями языка. То, что его кто-то пытается "прикрутить" к своим задачам и по этому поводу сокрушается, не проблема языка, а проблемы соответствующего пользователя.

Итак, Си создавался как "язык системного программирования".
Хотелось бы получше разобраться в этом утверждении.
Действительно ли Си -- язык, особо подходящий для создания (операционных) систем?
Или это прежде всего язык сравнительно низкого уровня (с битовыми операциями и адресной арифметикой, без какой-либо RTS; то, что часто называется "высокоуровневым ассемблером")?
Я не придираюсь, просто что-то в этой типовой фразе о "языке системного программирования" меня смущает.
Си, бесспорно, сравнительно низкоуровневый (и в этом близкий ассемблеру) язык. Но операционная система -- прежде всего -- система (иногда довольно сложная), и не вполне ясно, как язык вроде Си может способствовать построению систем. Нет ни модульности, ни полноценного контроля типов. Или именно их отсутствие делает язык "системным"?
Если Си -- язык системного программирования, то он вполне может оказаться на одной площадке с Обероном. Ведь Оберон создавался именно как язык системного программирования (для создания ОС Оберон).
В таком случае эти языки вполне правомерно сравнивать.


Страуструп декларировал свою цель очень просто: "C++ проектировался преимущественно так, чтобы автору языка и его друзья не было бы нужды программировать на ассемблере, Си и различных современных языках высокого уровня. Основная цель C++ состояла в том, чтобы сделать написание хороших программ более простым и более приятным делом для отдельно взятого программиста".

Ну и как, цель достигнута? Программировать на Си++ просто и приятно?

Ответ на »сообщение 1445« (Jean)
___________________________

Это не язык, это "грамматический бред".

Cи создавался как язык системного программирования в качестве замены ассемблеру. Зависимость от архитектуры обусловлена целями языка. То, что его кто-то пытается "прикрутить" к своим задачам и по этому поводу сокрушается, не проблема языка, а проблемы соответствующего пользователя.

Думаю, что он понял концепции С++ (а, точнее, их отсутствие) не хуже, чем кто-либо другой.

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

Страуструп декларировал свою цель очень просто: "C++ проектировался преимущественно так, чтобы автору языка и его друзья не было бы нужды программировать на ассемблере, Си и различных современных языках высокого уровня. Основная цель C++ состояла в том, чтобы сделать написание хороших программ более простым и более приятным делом для отдельно взятого программиста".

Ответ на »сообщение 1445« (Jean)
___________________________

Коммерческий выпуск С++ состоялся в 1985 году.

Проект Oberon стартовал осенью 1985 г.

Язык "C with Classes" был переименован в C++ в декабре 1983 г. Но там от современного C++ были к осени 1985 г. одни "ошметки" (ни множественного наследования, ни абстрактных классов, ни обработки исключений, ни шаблонов). Разве что появились (примерно в 1984-1985 гг.) константы, ссылки, виртуальные функции, перегрузка операций. Почитайте B.Stroustrup "A History of C++".

Первое издание книги Страуструпа "The C++ Programming Language" вышло только в 1986 г. Далее вышли реализации языка Release 1.1 (июнь, 1986) и Release 1.2 (февраль, 1987), где были исправлены основные ошибки Cfront и неточности C++. Два года спустя (июнь, 1989) вышел Release 2.0, и в него было введено множественное наследование, а в сентябре 1991 г. был выпущен и Release 3.0 вместе с механизмом шаблонов, закрепленным в руководстве ARM (1990). http://www.osp.ru/pcworld/2003/01/164806/_p2.html

По всему миру к октябрю 1985 г. по словам Стауструпа насчитывалось аж 500 пользователей языка C++. Т.е. можно считать, что на горизонте перед стартом проекта Oberon он все-таки маячил.

Оберон-2 - 1992 г.

Для информации: язык Оберон-2 к проекту Oberon (его целям и задачам) не имел ни малейшего отношения.

Ответ на »сообщение 1451« (Max Belugin)
___________________________
Если писать в стиле "равиоли", то зачем объявления по месту? Правильно, рекомендуется вообще-то укладывать код одной функции на один экран, неужели так велико расстояние от секции VAR до точки объявления переменной? А вообще в Паскалях еще существуют вложенные процедуры, которые позволяют сформировать некоторый подконтекст для некоторых действий, со своими объявлениями "по месту".

Ответ на »сообщение 1449« (Alex)
___________________________

>>>3) Не такой дубовый синтаксис (объявление переменных по месту...
Сколько уж раз говорено, что нет ничего опаснее, чем эти "объявления по месту".


Что -  совсем совсем ничего?


Вот, к примеру, есть такой код.


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

По мне - так довольно опасен разыв между обявлением переменной и ее первым использованием:  я стараюсь чтобы область видимости переменной была как можно ближе к тому куску кода где её существование осмысленно - так меньше вероятности совершить ошибку.

А еще я пишу в стиле "равиоли" - много маленьких функций. Если код функции весь как на ладони, то совершить ошибку описанную вами практически невозможно.

Хороший материал по теме:
http://www.modulaware.com/mdlt28.htm

>>>3) Не такой дубовый синтаксис (объявление переменных по месту...
Сколько уж раз говорено, что нет ничего опаснее, чем эти "объявления по месту". И все, как "об стенку".
Вот, к примеру, есть такой код.
{
  int i;
  //...
  {
      int i;
      //...
      i = 13;
  }
}
А в этом варианте кода внутреннее объявление по ошибке не написали. Компилятор C/C++ не обратит на эту ошибку ни малейшего внимания. А смысл кода уже будет другим. "Случайно" пострадает "внешняя" переменная.
{
  int i;
  //...
  {
      //...
      i = 13;
  }
}
Чтобы не говорили защитники С/C++ - работа на этих языках похожа на езду через минные поля. Когда мы обсуждаем достоинства и недостатки Java и C#, это хоть можно понять. Но "достоинства" C++ - это просто смешно. "Жирный" и опасный язык, недостатки которого явно перевешивают все "достоинства".

Ответ на »сообщение 1446« (Илья Ермаков)
___________________________

По поводу CVS - для работы с исходниками Блэкбокса в русской команде поддержки среды успешно используется SVN (Subversion).

Кстати, книга о SVN содержит характерный эпиграф, связанный с Си:
“If C gives you enough rope to hang yourself, think of Subversion as a sort of rope storage facility.”Brian W. Fitzpatrick
:)

>>>По поводу пошаговой отладки - это не "современное средство", а уродливый
>>>костыль
Абсолютно согласен!
Я работаю в Блэкбоксе недолго, примерно 2 года, и ни разу не ощутил неудобства из-за отсутствия отладчика. "Коварные" ошибки Оберон почти не пропускает, а те, которые "выскакивают" в run-time легко "вычищаются" без всякого отладчика. А вот представить себе работу без отладчика в языках типа C++ не могу. Это будет "смертельный" номер.