Здравствуйте, AVC, Вы писали:

СГ>>>Что каксается оберон-вирусов, то, думаю, это уже совсем другой вопрос.
RRM>>Вот этот вопрос принципиальный, если там все так просто с вирусами, то эту систему нельзя использовать там, где неквалифицированный (в хорошем смысле слова) пользователь запускает программы полученные на стороне. На атомной станции (вы писали, что там вроде оберон применяется) там понятно дело левых программ нет, их долго тестируют, проверяют и т.п. можно и на обероне писать.

AVC>На Обероне можно отследить использование низкоуровневых конструкций.
AVC>Даже просто не разрешить загрузку модулей, использующих такие конструкции, если так критична будет защита.
AVC>Как и в Модуле, низкоуровневые конструкции требуют специального импорта (SYSTEM), который нельзя скрыть. (В отличие от использования низкоуровневых конструкций в Си. Хотя, впрочем, в Си почти все конструкции низкоуровневые. )

Может быть я не очень удачно изложил свою мысль в одном предыдущих постов, попытаюсь повторить

Oberon язык компилируемый (если ошибся извините). Значит в скомпилированном модуле находятся машинные коды х86. Кто мешает мне вписать туда код на встроенном ассемблере? Для этого нужно испортирование какого-то модуля?
MOV BX,<левый адрес>
MOV [BX],<всякий мусор>
Проехались по чужой памяти.

Я готов предположить, что просто так (без импорта каких либо модулей или дополнительных привилегий) нельзя писать код на встроенном ассемблере, но я ведь могу немного модифицировать уже скомпилированный двоичный файл и вписать туда приведенный код, ну или изменить адрес. Как такую ситуацию обработает ран-тайм? Эта пара интсрукций не является привеллегированной и в общем случае нельзя сказать, она допустима или нет.

Такая ситуация повалит всю систему, в системе с разделением памяти погибнет только один процесс.

Здравствуйте, RailRoadMan, Вы писали:

RRM>С точки зрения embedded программирования для устройсвт с небольшой производительностью оберон плохо применим. Ему ран-тайм нужен в обязательном порядке (тлт можно без него? хотя сомнеаваюсь). А если на не нужны ни активный объекты, ни сборщики мусора (для большого количества встроенных приложения можно вообще статически данные выделять), то зачем платить памятью и производительностью за этот ран-тайм. А минимальной ядро для организации параллельных вычислений и синхронизации можно втиснуть в несколько сотен байт или пару килобайт

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

Здравствуйте, Serginio1, Вы писали:

AVC>>Думаю, Вы правы — эту проблему можно решить экспортом "констрейтов".
S> А почему не ВЫ?????

Ну и я то же.
На самом деле, до самого последнего времени я имел очень смутное представление о .NET (пока занимаюсь задачами, далекими от этого), и только сейчас понемногу "наверстываю упущенное".
Весьма вероятно, иногда я "изобретаю велосипед".

S> На самом деле дженерики это очень хороший подход. Впринципе давно существует понятие универсальный промежуточный язык, с последующей компиляцией в натив. MSIL как раз такой язык полностью типизированный и с метатаданными. Дженерики тоже хранятся в MSIL и легко типизируются.
S> Из этой длинющей ветки понял, что оберон по своей сути мало отличается от манагед сред, правда со своими особенностями.
S> Джнерики только появились пока в бетта версиях Net и Java и развиваются и появятся они наверняка и в Обероне
S> Так или иначе все наработки так и на голом месте ничего не вырастает.
S> Опять же если смотреть на Net то есть как обычный фреймворк так и компакт фреймворк для КПК. Наверняка найдется и область применения и для Оберон систем более широкое. И это прекрасно, что прогресс двигают не только промышленные монстры, которые правда больше заимствуют чем изобретают. И для совершенства нет предела.

В принципе, со всем согласен.
Мне очень нравится Оберон, я уже успел полюбить этот язык (хотя знаком с ним сравнительно недавно), но я не "фанат" Оберона, моя "приязнь" к нему вполне рациональна (как мне кажется ).
И конечно, совершенству предела нет, есть много хороших идей (а сколько еще будет!).

Здравствуйте, AVC, Вы писали:

AVC>Здравствуйте, Serginio1, Вы писали:

AVC>>>Думаю, Вы правы — эту проблему можно решить экспортом "констрейтов".
S>> А почему не ВЫ?????
ЭНе много описался правильно читать А почему не ВЫ?????


AVC>Мне очень нравится Оберон, я уже успел полюбить этот язык (хотя знаком с ним сравнительно недавно), но я не "фанат" Оберона, моя "приязнь" к нему вполне рациональна (как мне кажется ).
Чувствуется. Для себя подчерпнул много нового.

Здравствуйте, Cyberax, Вы писали:

>> Модула-2 используется в космической промышленности (кстати, в том
>> числе в нашей стране), в авиапромышленности, в ПО для атомной энергетики.
>> Оберон-2 используется, например, в NASA.
C>Кем? Можете сказать в каких аппаратах был использован Оберон?

Информация такая (по памяти, немного спешу):
Модула-2 используется в наших спутниках связи;
конкретно в каких аппаратах NASA был применен Оберон сейчас сказать не могу.
Могу сказать, какие изменения были внесены в стандарт Оберона по просьбе NASA.

>> Идеи, примененные в языке и ОС Оберон, давно уже признаны индустрией.
C>Они появились в Обероне далеко не впервые.

Вполне возможно, хотя их применение в комплексе (в каком они и представляют силу) до Оберона мне неизвестно.
Правда, я не вполне понял Вашу мысль — какие идеи именно Вы имели в виду?

Здравствуйте, AVC, Вы писали:


AVC>В принципе, сам "рантайм" может быть написан на Обероне.

Нет, сам рантайм может быть написан только на Обероне с применением встроенного ассемблера, в доказательство я уже приводил фрагменты кода ГолубойБутылки, т.е. протсто скомпилировать рантайм для нового железа нельзя, нужно его ПОРТИРОВАТЬ

AVC>Он нужен для поддержки определенных свойств системы. Например, для поддержки сборки мусора.
AVC>Если такие свойства не требуются, то можно обойтись и без него (в значительной мере или полностью — в зависимости от обстоятельств).

Это как? Если я правильно понял, то объекты можно создавать только в куче управляемой сборщиком мусораю Если это не оспользовать, то где будут объекты, на стеке или глобальные? И что это будет за Оберон, это уже совсем другой язык (подрезанный С++)

AVC>Действительно, многозадачность можно организовать очень простыми средствами, гораздо проще, чем делается обычно в операционках.
AVC>Для любых приложений (встроенные — не исключение, разве что совсем тривиальные) существенна надежность системы типов. В Обероне она есть, в Си — нет.

Вы решили, что ее нет, потому что можно приводить типы? Это средство которое нужно правильно использовать. Лучше пусть будет что-то чте не всегдя следует использовать, чем не иметь совсем.

AVC>Мой интерес к этой теме и возник из наблюдений за написанием и отладкой встроенного ПО. Для поддержки этого благородного дела я пишу компиляторы (Си), ассемблеры, отладчики и т.д. (Если честно, дело не слишком хитрое.)
AVC>И все равно, остаются большие трудности. В силу того факта, что указатели в Си имеют слишком неопределенную природу (массив — указатель, malloc — указатель, выходной параметр — указатель), трудно организовать поддержку процесса отладки. (А когда дело доходит до отладки "по железу", то нервотрепка обеспечена.)

А можно поподробнее про трудности (хотя чего может быть сложного в указателе )? Я имею некоторый опыт общения с втроенным ПО и основные трудности были связаны со всем чем угодно, но только не с использованием С. Кстати массив не указатель, правильнее сказать, что имя массива приводится к типу указателя на элемент массива, самого указателя не существует, только массив.


AVC>В результате меня "заела совесть", и я стал искать другие подходы. Так и наткнулся на Оберон. (Хотя обязательно рассматриваю и другие возможности. Например, ребята подкинули ссылки по "надежному Си".)
AVC>С Вашим выводом о неприменимости Оберона во встроенных устройствах я не согласен.

Это было исключительно мое ИМХО

AVC>Я даже рассматриваю его как язык-кандидат именно для этой цели.

Подумайте еще раз о С в том контексте, что компиляторы языка С, существую практически для любых платформ

Здравствуйте, Serginio1, Вы писали:

AVC>>Мне очень нравится Оберон, я уже успел полюбить этот язык (хотя знаком с ним сравнительно недавно), но я не "фанат" Оберона, моя "приязнь" к нему вполне рациональна (как мне кажется ).
S> Чувствуется. Для себя подчерпнул много нового.

Здравствуйте, RailRoadMan, Вы писали:

RRM>Oberon язык компилируемый (если ошибся извините). Значит в скомпилированном модуле находятся машинные коды х86. Кто мешает мне вписать туда код на встроенном ассемблере? Для этого нужно испортирование какого-то модуля?
RRM>MOV BX,<левый адрес>
RRM>MOV [BX],<всякий мусор>
RRM>Проехались по чужой памяти.

В принципе, Оберон, конечно — язык компилируемый, хотя возможна и докомпиляция на стадии загрузки модуля. В Обероне изначально был способ переносить код между разными Оберон-системами (OMI), который впоследствии стал известен как JIT.

RRM>Я готов предположить, что просто так (без импорта каких либо модулей или дополнительных привилегий) нельзя писать код на встроенном ассемблере, но я ведь могу немного модифицировать уже скомпилированный двоичный файл и вписать туда приведенный код, ну или изменить адрес. Как такую ситуацию обработает ран-тайм? Эта пара интсрукций не является привеллегированной и в общем случае нельзя сказать, она допустима или нет.
RRM>Такая ситуация повалит всю систему, в системе с разделением памяти погибнет только один процесс.

Вопрос понятен и совершенно разумен.
Я и правда сначала не понял, на чем Вы делаете акцент.
Надо подумать...
В принципе, когда-то у меня возникал подобный вопрос, но я тогда решил, что в системах, критичных с точки зрения безопасности, никто не даст редактировать исполняемые файлы. (Система может это запрещать?)
А можно попробовать и другой способ. Например, проверять контрольную сумму на этапе загрузки, или еще что-нибудь.
Главное, согласен — такую возможность нельзя упускать из виду.

Здравствуйте, RailRoadMan, Вы писали:

RRM>Здравствуйте, AVC, Вы писали:


AVC>>В принципе, сам "рантайм" может быть написан на Обероне.
RRM>Нет, сам рантайм может быть написан только на Обероне с применением встроенного ассемблера, в доказательство я уже приводил фрагменты кода ГолубойБутылки, т.е. протсто скомпилировать рантайм для нового железа нельзя, нужно его ПОРТИРОВАТЬ

Вы привели частный случай — это еще не доказательство.
В действительности, я (на основании описания языка Оберон и его стандарта Oakwood guidelines) могу дать Вам слово (как де Лопиталь ), что рантайм может быть написан на самом Обероне. Все необходимые средства есть.

AVC>>Если такие свойства не требуются, то можно обойтись и без него (в значительной мере или полностью — в зависимости от обстоятельств).
RRM>Это как? Если я правильно понял, то объекты можно создавать только в куче управляемой сборщиком мусораю Если это не оспользовать, то где будут объекты, на стеке или глобальные? И что это будет за Оберон, это уже совсем другой язык (подрезанный С++).

Хотя Оберон безусловно тяготеет к созданию объектов в куче, их можно создавать и статически, и на стеке.
Поэтому в языке и существуют явные указатели (в отличие от Java).

Пока все, труба (т.е. начальство) зовет!

Здравствуйте, AVC, Вы писали:

AVC>Вы привели частный случай — это еще не доказательство.
AVC>В действительности, я (на основании описания языка Оберон и его стандарта Oakwood guidelines) могу дать Вам слово (как де Лопиталь ), что рантайм может быть написан на самом Обероне. Все необходимые средства есть.

Давайте для дальнейшей беседы четко определимся что значит "на самом Обероне". В это понятие вкладывается "Оберон и встроенный ассемблер" или "только Оберон без встроенного ассемблера"
Дальше, мы обсуждаем ран-тайм который работает на голом железе? Или например под Виндой тоже. Давайте обсуждать случай работы на голом железе, если я правильно понял он интересен нам обоим

AVC>Хотя Оберон безусловно тяготеет к созданию объектов в куче, их можно создавать и статически, и на стеке.
AVC>Поэтому в языке и существуют явные указатели (в отличие от Java).

С обероном сильно не знаком, но что-то мне подсказывает, что объекты на стеке это не оттуда. Сразу возникает пролема возврата указателей на временный объект и т.п. Тут писали, что объект можно создавать с помощью
NEW(P)
где P -указатель на создаваемый объект или как-то так, хотя надо еще где-то указать тип

А как создать объект на стеке?

P.S. Про трудности с указателями мне все еще интересно

Здравствуйте, RailRoadMan, Вы писали:

RRM> А как создать объект на стеке?

Очевидно, что Вы и AVC сейчас немного о разных Оберонах разговариваете.
Вы говорите об объектах имея в виду OBJECT из Active Oberon, которые действительно есть reference type и на стеке их быть не может. В это же самое время, AVC говорит об объектах имея в виду RECORD из просто Modula, Oberon, Oberon-2, Component Pascal... — там объекты можно размещать как на стеке так и в куче.

Еще AVC, очевидно, говоря о том что написать рантайм оберона можно на самом обероне не используя ассемблера имеет в виду псевдомодуль SYSTEM, который предоставляет такие возможности. Например для ETH Oberon псевдомодуль SYSTEM такой: http://www.oberon.ethz.ch/SYSTEM.html Таким образом для переноса оберона на другую платформу нужно будет перенести всего лишь этот один маленький псевдомодуль, а все остальное просто перекомпилировать с этим новым псевдомодулем.

Здравствуйте, AVC, Вы писали:

К>>>>Во-первых, вылететь из очереди планировщика можно тремя способами:
К>>>>- из running в waiting
К>>>>- из running в suspended
К>>>>- из ready в suspended
AVC>>>ИМХО, это зависит от ОС.
AVC>>>Может быть три способа, а может быть тридцать три.
К>>Интересно, это какие же тридцать три, если всего есть 5 принципиально разных состояний (выполняется, готов, усыплён, ждёт, завершён).

AVC>Так это какими абстракциями пользоваться.
AVC>Я, например, вижу только три состояния:
AVC>1) текущий процесс (running по Вашему);
AVC>2) процесс в очереди исполнения (ready);
AVC>3) ждущий какого-нибудь внешнего события (waiting).
AVC>Конечно, для последнего варианта можно насчитать множество разновидностей.
AVC>Но процесс все равно находится в состоянии ожидания того светлого времени, когда его "разбудит" диспетчер.

4) suspended (временно не планируемый) — но, как показывает практика, это зачастую опасно, да и не нужно (можно грамотно заменить на ожидание).

AVC>>>Для обеспечения сохранности инвариантов существуют мониторы. (Или другие средства синхронизации.)
AVC>>>Если система поддерживает мониторы, то неясно, почему могут быть нарушены (системные) инварианты.
К>>Монитор, я так понимаю, не предполагает исключительное и непрерываемое исполнение программы? Или предполагает?!

AVC>Монитор предполагает, что доступ к разделяемой переменной в любой момент времени может иметь не более одного процесса.

Доступ — это явление, растянутое во времени. В минимальном объёме — это атомарное чтение/модификация. Но монитор обеспечивает атомарность всей транзакции, которая может быть довольно долгой (хотя, если она слишком долгая, то это баг).

К>>- сборщик мусора знает о мониторе и честно ждёт (или просто обходит стороной) заблокированные данные; достаточно теперь зависнуть в мониторе (например, на взаимоблокировке или банальном бесконечном цикле) — и привет

AVC>Если мониторы, связанные с управлением памятью, входят в состав ядра ОС, то зависание такого монитора равносильно зависанию ядра.
AVC>А уж если ядро зависло — ничего не попишешь...

Вот пример пользовательского монитора.

class World { ... };

synchronized class Hello
{
  private World world;
  public Hello() {}
  public void longlive()
  {
    while(rand() != 12345)
      world = new World(); // занимаемся фигнёй, постоянно трогая переменную
  }
};

Спрашивается, что сделает GC, когда наступит пора проверить граф зависимостей объекта класса Hello?
Либо ждать (до посинения), либо плюнуть.

Конечно, в виртуальной машине Java все операции присваивания атомарны, поэтому сборщик может с чистой совестью обойти блокировку. Но в native коде это уже может быть не так...
Впрочем, есть 3 простых способа
— jit-компилятор пихает всюду хардверные блокировки (x86-инструкции LOCK, CLI/STI и т.п.)
— он же расставляет в коде вызовы некой функции yield(), обеспечивая кооперативную многозадачность
— кооперативность обеспечена в native-коде всех системных функций; предполагается, что в них будут заходить достаточно часто (примерно так это сделано в Windows 3.1)

К>>- сборщик мусора не знает о мониторах и нагло копается в заблокированных данных, в том числе — на полудохлых

AVC>Только, если существует единственный процесс.

То есть?

К>>- все операции, влияющие на граф зависимостей (инициализация и присваивание указателей) атомарны — это достигается или кооперативной многозадачностью, или накладными расходами; сборщик мусора имеет право убивать заблокированный монитор.

AVC>Зачастую вполне приемлимый вариант.
AVC>Пара лишних операций на присваивание указателей все же эффективнее переключения контекста.

К>>>>Во-вторых, вне зависимости от этого, сохраняется вопрос о легальности уничтожения ждущего объекта.
AVC>>>Здесь нет ничего специфичного для ОС Оберон.
AVC>>>На что, кстати, уже обращалось внимание.
К>>А я и не говорю про Оберон. Просто в системах, где потоки — это низкий уровень, команду kill или TerminateThread применяют только от безысходности или по разгильдяйству. А если система сама будет решать, когда ей прибивать якобы заторможенный активный объект — будет много увлекательных приключений.

AVC>О, искусственный интеллект!

Вот и я про то же. Система априори решает "а ну их нафиг!" Пусть программер обеспечивает завершимость потоков.
И если программер ошибётся... никакие красивые слова про GC, безопасный язык и т.п. не помогут.

Хотя это интересная тема для исследований. Прибираться в пространстве (адресном) уже научились, нужно подумать о том, как прибираться во времени.

К>>>>То ли этот объект зацеплен за очередь к ресурсу, то ли его оттуда можно смело выдёргивать.
AVC>>>Откуда?
AVC>>>Вопрос неясен.
К>>Откуда: из очереди к ресурсу.

AVC>Тогда объект все же зацеплен за очередь к ресурсу.
AVC>В чем дилемма?

В том, что ресурсу от ждущего объекта ничего не надо. Одним в очереди больше, одним меньше — какая разница. Фактически, это ресурс зацеплен за объекта, а не объект — за ресурс.

Поэтому, если объект встал в ожидание, то его можно (с оговорками, разумеется) изъять и уничтожить, как если бы он был висячим.
Но если очередь ожидания унифицирована с другими очередями — то формально объект не висит, на него есть ссылки извне.

AVC>>>А как он это сделает в условиях нескольких адресных пространств?
К>>Процесс, выжравший свою квоту (или все ресурсы, если квота бесконечна), получит звоночек. Если звоночек не обработан, то процесс уничтожается, освобождая ресурсы. Остальные процессы при этом не страдают.

AVC>То же самое, ИМХО, возможно и при едином адресном пространстве.

... пока процессы не начнут расшаривать память.
Да, можно сказать: ты лазишь сюда, ты вот сюда, тефтели с рисом, меняться нельзя. Просто в условиях раздельных АП эту конвенцию легче соблюсти, все шары учитываются системой.

Здравствуйте, RailRoadMan, Вы писали:

RRM>Давайте для дальнейшей беседы четко определимся что значит "на самом Обероне". В это понятие вкладывается "Оберон и встроенный ассемблер" или "только Оберон без встроенного ассемблера"
RRM>Дальше, мы обсуждаем ран-тайм который работает на голом железе? Или например под Виндой тоже. Давайте обсуждать случай работы на голом железе, если я правильно понял он интересен нам обоим

Я имею в виду именно сам Оберон, без встроенного ассемблера, но с использованием псевдомодуля SYSTEM.
И меня интересует работа по голому железу. (Предположим, нет ничего, написанного не на Обероне. Хотя, например, даже для компилятора Си я предоставляю встроенный ассемблер, чтобы использовать некоторые возможности аппаратуры, не поддерживаемые напрямую языком. Например, сумматор MAC.)

AVC>>Хотя Оберон безусловно тяготеет к созданию объектов в куче, их можно создавать и статически, и на стеке.
AVC>>Поэтому в языке и существуют явные указатели (в отличие от Java).
RRM>С обероном сильно не знаком, но что-то мне подсказывает, что объекты на стеке это не оттуда. Сразу возникает пролема возврата указателей на временный объект и т.п. Тут писали, что объект можно создавать с помощью
RRM>NEW(P)
RRM>где P -указатель на создаваемый объект или как-то так, хотя надо еще где-то указать тип
RRM>А как создать объект на стеке?

Это просто запись.

TYPE Object: RECORD ... END;
VAR staticObject: Object;
PROCEDURE foo;
VAR objectOnStack: Object;
  p: POINTER TO Object;
BEGIN
  NEW(p); (* объект в куче *)
END foo;

RRM>P.S. Про трудности с указателями мне все еще интересно

OK!
Сейчас я, увы, не смогу ответить (должен уйти).
Но при первой возможности (правда, может быть, не сегодня) отвечу.

Здравствуйте, Кодт,

я отвечу позднее. Сегодня не успеваю.

Здравствуйте, AVC, Вы писали:

AVC>я отвечу позднее. Сегодня не успеваю.

окей.

Здравствуйте, AVC, Вы писали:

AVC>Модула-2 используется в космической промышленности (кстати, в том числе в нашей стране), в авиапромышленности, в ПО для атомной энергетики.
AVC>Оберон-2 используется, например, в NASA.

Точные ссылки и данные — в студию! Хватит уже фраз в духе "говорят, в Москве кур доЯт".

AVC>Беспилотные вертолеты по-прежнему летают. (Кстати, OLGA означает Oberon language goes airborne.)

Да, летают. Вероятно, только благодаря Оберону.

AVC>Хотя эта сфера развивается очень быстро, и я допускаю, что ПО, написанное лично Виртом, в новых образцах уже не используется.

Может быть, и Оберон там давно уже не используется?

AVC>Идеи, примененные в языке и ОС Оберон, давно уже признаны индустрией.
AVC>Вы можете найти их и в языках Java и C#, и в JVM и в .NET.

здесь не хватает только одного слова, чтобы меня убедить. это слово — "впервые" после слова "идеи"

AVC>Что касается учебной сферы, то по книгам, языкам и системам Вирта учатся во всем мире. (В частности, ETH Oberon System 3 изучается в ряде западных учебных программ.

роль его работ для обучения я и не оспариваю

AVC>Я уж не говорю о том, как изучали ее код в Sun в начале 90-х годов. Очень творчески. )

Про С++ это часто говорят, да и сходство явно наблюдается. Про Смоллток — говорят. Про Оберон — нет.
Тебе единственному про это рассказали, или ты сам в этом процессе участвовал?

AVC>Хочу отметить (как личное), что именно в книгах Вирта я впервые встретил примеры построения целых программ от начала до конца, а не общие рассуждения в стиле Буча.

Придет время — и до книг Буча ты тоже дорастешь.

AVC>Так что небезполезную жизнь прожил Вирт, как бы Вам, видимо, не хотелось доказать обратное.

Если мне этого захочется — я прямо так и скажу. Не надо заниматься измышлениями.

Здравствуйте, AVC, Вы писали:

AVC>Здравствуйте, Privalov, Вы писали:

P>>Те, кто меня учили, утверждали, что главная часть любого инструмента — голова его владельца. Лишний раз подтверждается их правота.

AVC>Т.е. если надо долбить стену... ;)

... то нужно для этого выбрать подходящий инструмент.

AVC>Шутка. :)

Смеюсь...

P>>Как утверждает здесь сам Страуструп, компилятор C++ реализован им самим. Думаю, что это достаточно серьезный проект.

AVC>Кажется, Страуструп создал Cfront.
AVC>Возможно, впоследствии написал компилятор для ранней версии Си++.
AVC>Но вряд ли Вы будете утверждать, что какой-нибудь из современных компиляторов Си++ написан лично Страуструпом.

Разумеется, не буду.

AVC>Думаю, полезно было бы, если бы автор языка самолично писал (и переписывал, если в язык внесены изменения) его компилятор.
AVC>Уверен, что качество языков повысилось бы. :)

Не обязательно хороший архитектор должен быть хорошим каменщиком.
В программировании — то же самое. Кстати, в проекте, в котором я сейчас работаю, если бы его главный архитектор не садился сам за реализацию своих идей, нашей команде было бы гораздо легче жить.


AVC>Вирт стремится создать надежный (а не идеальный) язык программирования.
AVC>Одна из причин такого его желания изложена здесь:
AVC>http://www.inr.ac.ru/~info21/info/wirth_avia.htm
AVC>Кроме языков и операционок Вирт проектировал компьютеры, писал САПР, встроенное ПО беспилотного вертолета (OLGA) и т.д. и т.п.
AVC>Все рассуждения об "академизме" Вирта высосаны из единственного факта, что он имел несчастье быть еще и профессором.
AVC>Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.

Вирт, создавая очередной язык программирования, выбрасывает в мусор все, сделанное ранее. Кроме своих идей, разумеется. Не он ли призывал всех бросить Паскаль и перейти на Модулу-2? Он нигогда не спрашивал, сколько стоит такой переход.

AVC>Ну, назовите что-нибудь, созданное Страуструпом, помимо Си++.
AVC>Да и тот давно уже создается огромным комитетом...

А Вы сравните страницу Вирта и страницу Страуструпа. У Вирта описаны полтора десятка проектов, каждый одним абзацем. О дальнейшей судьбе этих проектов на странице ничего не говорится.

У Страуструпа речь идет только о С++. Но посмотрите, какой объем информации. Можно проследить все основные направления развития как самого языка, так и проектов, на нем реализуемых.

AVC>Да не прагматизм (который у Страуструпа, конечно, вольный; свои взгляды он изланает в книге об "Дизайн и эволюция Си++"), а поддержка Bell Labs.

А на чем эта поддержка основана? Разве Bell Labs когда-нибудь была благотворительной конторой? Поддержка со стороны Bell Labs означает, что наряду с внедрением новых идей и методов программирования остается возможность использования старого, проверенного временем и пользователями, матобеспечения. То есть, сохранение капиталовложений. ("Старого" не означает "устаревшего", разумеется. Матобесбечение вряд ли может считаться устаревшим, если оно удовлетворяет требованиям заказчика.)


P. S.
И, кстати, совершенно случайно нашел я "Астрономию на персональном компьютере", и даже успел ее просмотреть.
Здесь

Автор: AVC
Дата: 07.02.05

Вы цитировали абзац оттуда:

Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.

Вы, видимо, не слишком внимательно прочли предыдущий абзац, в котором авторы объясняют, почему они все-таки выбрали C++, и несколько последующих. Мог бы процитировать, но этот самый предыдущий абзац раза в 4 длиннее, не говоря уже о последующих. К тому же сейчас этой книги нет под рукой, а цитировать по памяти — неблагодарное занятие.

А книжка действительно интересная, спасибо еще раз за название.

Здравствуйте, Privalov, Вы писали:

AVC>>Здравствуйте, Privalov, Вы писали:
P>>>Те, кто меня учили, утверждали, что главная часть любого инструмента — голова его владельца. Лишний раз подтверждается их правота.
AVC>>Т.е. если надо долбить стену...
P>... то нужно для этого выбрать подходящий инструмент.
AVC>>Шутка.
P>Смеюсь...

Согласен, шутка неудачная.
Я согласен, что хорошая голова — главное в любом деле.
Но не согласен с подтекстом Вашего утверждения, что если голова хорошая, то и любой инструмент сойдет.
Есть у Сутеева такая сказка — "Палочка-выручалочка". (Прошу прощения за детские ассоциации. Моему младшему — три, вот и штудируем "классиков". )
Там в самом конце высказывается мысль, родственная Вашей: главное — умная голова и доброе сердце. Это, бесспорно, — главное. Но как бы ежик без этой палки зайца из болота вытянул и от волка спас?

AVC>>Думаю, полезно было бы, если бы автор языка самолично писал (и переписывал, если в язык внесены изменения) его компилятор.
AVC>>Уверен, что качество языков повысилось бы.
P>Не обязательно хороший архитектор должен быть хорошим каменщиком.
P>В программировании — то же самое. Кстати, в проекте, в котором я сейчас работаю, если бы его главный архитектор не садился сам за реализацию своих идей, нашей команде было бы гораздо легче жить.

Не уверен, что метафора об архитекторе и каменщике применима к области ПО.

AVC>>Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.
P>Вирт, создавая очередной язык программирования, выбрасывает в мусор все, сделанное ранее. Кроме своих идей, разумеется. Не он ли призывал всех бросить Паскаль и перейти на Модулу-2? Он нигогда не спрашивал, сколько стоит такой переход.

А сколько, интересно, стоит такой переход?
Вот что я вижу: для каждого приличного языка существует (библиотечная) поддержка практически всех известных алгоритмов. И возникает такая поддержка очень быстро.
Кроме того, существует множество конверторов с языка на язык.
(Некоторое исключение из этого правила составлял, пожалуй, лишь Фортран.)

AVC>>Ну, назовите что-нибудь, созданное Страуструпом, помимо Си++.
AVC>>Да и тот давно уже создается огромным комитетом...
P>А Вы сравните страницу Вирта и страницу Страуструпа. У Вирта описаны полтора десятка проектов, каждый одним абзацем. О дальнейшей судьбе этих проектов на странице ничего не говорится.
P>У Страуструпа речь идет только о С++. Но посмотрите, какой объем информации. Можно проследить все основные направления развития как самого языка, так и проектов, на нем реализуемых.

Я так понимаю, Вы затрудняетесь похвастаться успехами Страуструпа в практическом программировании.
Количество проектов отражает популярность языка, его поддержку заинтересованными организациями. Но отражает ли качество языка?

AVC>>Да не прагматизм (который у Страуструпа, конечно, вольный; свои взгляды он изланает в книге об "Дизайн и эволюция Си++"), а поддержка Bell Labs.
P>А на чем эта поддержка основана? Разве Bell Labs когда-нибудь была благотворительной конторой? Поддержка со стороны Bell Labs означает, что наряду с внедрением новых идей и методов программирования остается возможность использования старого, проверенного временем и пользователями, матобеспечения. То есть, сохранение капиталовложений. ("Старого" не означает "устаревшего", разумеется. Матобесбечение вряд ли может считаться устаревшим, если оно удовлетворяет требованиям заказчика.)

Вообще-то, ИМХО, со стороны Bell Labs против Вирта велась "необъявленная война".
Вспоминаю впечатляющую статью Кернигана "Why Pascal is not my favorite programming language". Явно статья отражает негативные эмоции Кернигана о переписывании на Паскале ряда алгоритмов (для совместной книги с Плоджером). А скрыто — тот факт, что еще за два года до его статьи появился компилятор Модулы-2, языка, в котором все существенные недостатки Паскаля были Виртом уже устранены.
Такой язык был уже опасен для Си. Именно с этого момента представители Bell Labs начали "педалировать" недостатки Паскаля, умалчивая о Модуле (хороший психологический прием). Например, Пайк в интересной статье о стиле программирования на Си дважды упоминает Паскаль. Оба раза — в словосочетании "tyranny of Pascal".
Т.е. всячески внушалась мысль, что Вирт не может создать практического языка программирования.
Какова же ценность этой критики?
Рассмотрим один из пунктов кернигановской критики. Керниган пишет, что крупным недостатком Паскаля является то, что размерность входит в тип массива.
Уже в это время в Модуле это было не так.
Но идем дальше. В Обероне есть многомерные гибкие массивы. А что же в современном ему Си++ (хотя Си++ до сих пор не может прекратить экстенсивного роста)?
Все как раньше в Си: размерности всех измерений, кроме первого, входят в тип массива.

P>P. S.
P>И, кстати, совершенно случайно нашел я "Астрономию на персональном компьютере", и даже успел ее просмотреть.
P>Здесь

Автор: AVC
Дата: 07.02.05

Вы цитировали абзац оттуда:
P>

P>Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.

P>Вы, видимо, не слишком внимательно прочли предыдущий абзац, в котором авторы объясняют, почему они все-таки выбрали C++, и несколько последующих. Мог бы процитировать, но этот самый предыдущий абзац раза в 4 длиннее, не говоря уже о последующих. К тому же сейчас этой книги нет под рукой, а цитировать по памяти — неблагодарное занятие.

Книги под рукой прямо сейчас нет.
Читал я, однако, достаточно внимательно.
Так что помню, говорилось о "гибкости и мощности" языка, а главное — о доступности компиляторов. (Хотя ко времени выхода книги еще не существовало компиляторов Си++, соответствующих стандарту. Это по оценкам знатоков Си++.)
А потом — процитированный мной абзац, делающий бессмысленными (ИМХО) все предыдущие славословия.

P>А книжка действительно интересная, спасибо еще раз за название.

Welcome!

Здравствуйте, AVC, Вы писали:

AVC>Рассмотрим один из пунктов кернигановской критики. Керниган пишет, что крупным недостатком Паскаля является то, что размерность входит в тип массива.
AVC>Уже в это время в Модуле это было не так.

Я выразился неудачно.
Конечно, массив в Модуле-2 имеет размерность.
Но массивы, в качестве аргументов функции, могут быть гибкими, что позволяет решить обе проблемы: надежности (индекс массива контролируется) и обобщенности (процедуры могут принимать в качестве параметров массивы разных размерностей).
Обращаю внимание на то, что в Си (и в Си++) первая проблема никак не решалась.
(Сейчас есть интересные попытки, вроде "надежного Си".)

AVC>Здравствуйте, RailRoadMan, Вы писали:

RRM>>P.S. Про трудности с указателями мне все еще интересно

Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?

void foo(int *p)
{
    p[4] = 21; /* как узнать - массив p или нет? */
    p++;
}

или

void foo(int *p)
{
    free(p); /* указывет p на объект кучи, или это адрес переменной в стеке или сегменте данных? */
}