Здравствуйте, Sergey J. A., Вы писали:

SJA>Здравствуйте, Трурль, Вы писали:

Т>>Я имел ввиду обычный Оберон, там файлы не блокируются.
SJA>Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
SJA>Или есть там какие-то подпорки и костыли ?

Да нет, Вы не правильно поняли. ОС Оберон вся целиком является объектно ориентированной и вся целиком обслуживается одним единственным сборщиком мусора — там, грубо говоря, никто из пользователей не может отличить открытый файл от закрытого. Он просто обращается к файлмэнеджеру, а тот ему возвращает запрошенный файл, но сколько еще других пользователей сейчас работают с этим файлом Вы не знаете, поэтому и закрывать файл не надо. А BlackBox ограничен тем, что вынужден обращаться к файлам через Windows со всеми вытекающими...

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Sergey J. A., Вы писали:

SJA>>Здравствуйте, Трурль, Вы писали:

Т>>>Я имел ввиду обычный Оберон, там файлы не блокируются.
SJA>>Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
SJA>>Или есть там какие-то подпорки и костыли ?

СГ>Да нет, Вы не правильно поняли. ОС Оберон вся целиком является объектно ориентированной и вся целиком обслуживается одним единственным сборщиком мусора — там, грубо говоря, никто из пользователей не может отличить открытый файл от закрытого. Он просто обращается к файлмэнеджеру, а тот ему возвращает запрошенный файл, но сколько еще других пользователей сейчас работают с этим файлом Вы не знаете, поэтому и закрывать файл не надо. А BlackBox ограничен тем, что вынужден обращаться к файлам через Windows со всеми вытекающими...

Ага, значит залочить файл в ОС Оберон мы изначально не сможем — супер, такие ОС суть светлое будущее!

Здравствуйте, Сергей Губанов, Вы писали:
СГ>Однако, мы тут обсуждали обобщенные контейнеры работающие с типом ANYPTR, то есть когда процедура написана так: PROCEDURE f(p: ANYPTR);
Однако, ваши обобщенные контейнеры почему-то в рантайме падают на всем, кроме CorrectPtr. Какая-то хреновая обобщенность получается.

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

К>Ага, значит залочить файл в ОС Оберон мы изначально не сможем — супер, такие ОС суть светлое будущее!

Именно это я и хотел сказать.

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


GZ>Borland C++ 2.0 у меня лежал купленный практически с момента выхода(а это произошло еще до того как я пришел на ту работу в 1992). Затем был куплен Visual C++ 1.0 и я попрощался с OWL. Был еще Watcom, но когда он появился уже не помню (где-то 93 кажется).

А чем вам OWL не понравился? Мне интересно, спрашиваю потому что у вас была возможность сравнить первые версии MFC и OWL

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да нет, Вы не правильно поняли. ОС Оберон вся целиком является объектно ориентированной и вся целиком обслуживается одним единственным сборщиком мусора — там, грубо говоря, никто из пользователей не может отличить открытый файл от закрытого. Он просто обращается к файлмэнеджеру, а тот ему возвращает запрошенный файл, но сколько еще других пользователей сейчас работают с этим файлом Вы не знаете, поэтому и закрывать файл не надо.
Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?

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

S>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Однако, мы тут обсуждали обобщенные контейнеры работающие с типом ANYPTR, то есть когда процедура написана так: PROCEDURE f(p: ANYPTR);
S>Однако, ваши обобщенные контейнеры почему-то в рантайме падают на всем, кроме CorrectPtr. Какая-то хреновая обобщенность получается.

Так и должно быть, при использовании конструкции WITH. См. описание языка Оберон-2.
Я использовал IF p IS CorrectPtr THEN insert(p) END, в той реализации ничего не "падало". Но и с оператором WITH "падать" не будет, если Вы добавите ELSE.
Надо отметить, что способы "падения" системно зависимы. Можем первать работу программы и выдать диагностическое сообщение, можем выбросить исключение, а можем и проигнорировать, если считаем, что такое поведение допустимо.
Видимо, BlackBox в данной среде прерывает работу программы, что эквивалентно использованию ASSERT(p IS CorrectPtr).
Но в данном случае это и есть самое разумное поведение.
Прошу Вас вспомнить, в каком контексте все эти WITH p: CorrectPtr возникли.
Павел Кузнецов сказал, что требуется длительная отладка, чтобы выявить ситуации неправильного использования такого обобщенного контейнера.
Я усомнился в этом, сказав, что в Обероне не удастся обойти контроль типа, все такие ситуации будут выявлены.
Вы подтвердили мое утверждение: у Вас ни один указатель кроме CorrectPtr не принимается.

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

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


GZ>>Borland C++ 2.0 у меня лежал купленный практически с момента выхода(а это произошло еще до того как я пришел на ту работу в 1992). Затем был куплен Visual C++ 1.0 и я попрощался с OWL. Был еще Watcom, но когда он появился уже не помню (где-то 93 кажется).

P>А чем вам OWL не понравился? Мне интересно, спрашиваю потому что у вас была возможность сравнить первые версии MFC и OWL

1. Мне очень понравился AppWizard и ClassWizard. Не надо было лазить в хелп, чтобы узнать как точно пишется то или иное сообщение.
2. При обучении программированию на Windows, я сначала изучал Windows API для С. Когда мне я увидел первый MFC, который можно было назвать Wrapperом на WinAPI, он мне значительно больше понравился. Для начальной работы с MFC, было достаточно основных знаний WinAPI.
3. Насколько я помню, средств MFC 1.0 предоставлял несколько больше чем OWL (версию, к сожалению, не помню). Кажется впечатлило наличие Toolbar'ов.
4. Глючность OWL была больше чем у MFC. Глючность OWL + Глючность Windows + Глючность BC компилятора давала интересные эффекты. Компилятор Microsoft хоть и был значительно тормозней, но зато был более надежен.

Пункты отсортированы по важности.

С уважением, Gleb.

Здравствуйте, AVC, Вы писали:
AVC>Прошу Вас вспомнить, в каком контексте все эти WITH p: CorrectPtr возникли.
Давайте вспомним.
AVC>Павел Кузнецов сказал, что требуется длительная отладка, чтобы выявить ситуации неправильного использования такого обобщенного контейнера.
Верно.
AVC>Я усомнился в этом, сказав, что в Обероне не удастся обойти контроль типа, все такие ситуации будут выявлены.
Нет там никакого контроля типа. Павел Кузнецов имел в виду проверку того, что мы достаем из контейнера то же, что и положили. В Обероне либо ты имеешь специализированный контейнер, куда можно положить только что-то одно и достать его же, либо абстрактный, куда можно положить все что угодно, а также и достать все что угодно.
И выявлено это будет только при даункасте достанного объекта. Во-первых, это в ран-тайме (что уже слишком поздно для исправления ошибки), во-вторых даже для рантайма это слишком поздно (т.к. теперь придется сканировать все исходники в поисках того, кто положил в контейнер каку).

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

S>Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?

Чую курение над этой ситуацией приведет к тому что под сию замечательную ОС вместо классической ФС нужно будет подкладывать что то вроде WinFS.

Sergey J. A.:

> ПК>Попробуй VC 7.1 + whole program optimization.
>
> Тэкс. Похоже для sort он не делает слияние, но методы самого вектора он мержит:
>

> #include <cstdio>
> #include <vector>
> #include <algorithm>
> 
> using namespace std;
> 
> int main()
> {
>  vector<int> vi(100);
>  vector<void *> vs(100);
> 
>  __asm {int 3}
> 
>  vi.size();   // Одна ф-ия
>  vs.size();
> 
>  vi.push_back(0x666); // Одна ф-ия
>  vs.push_back((void *)0x666);
> 
>  sort(vi.begin(), vi.end()); // Разные
>  sort(vs.begin(), vs.end());
> 
>  return 0;
> }
>

Оно и понятно. Сортировка подразумевает сравнение, и было бы странным ожидать одинакового кода для сравнения указателей и знаковых целых. Скорее повезет с unsigned int.

Здравствуйте, Sergey J. A., Вы писали:

Т>>Я имел ввиду обычный Оберон, там файлы не блокируются.
SJA>Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
SJA>Или есть там какие-то подпорки и костыли ?

Наверное, удобно писать операционные системы на языке, который сам уже выполняет все функции операционных систем?
Интересно, Вы сами можете привести пример языка, который открывает файлы (да еще и "эксклюзивно") в обход самой операционной системы?
Мне кажется, Вы запамятовали, что в Обероне (как и в большинстве других языков, включая Си++) работа с файлами в язык не встроена. Поддержка работы с файлами осуществляется на уровне системных компонентов (того же модуля Files, например).
Так что Оберон тут ни при чем. Проблема где-то в "переходнике" между BlackBox и Windows.

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

S>Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?
Ну в ОС Оберон (тфу, чуть опять не написал "в Обероне", угораздило же Вирта назвать ОС и язык одинаково) этой проблемы не существует, потому как однозадачная она. А бутылку я еще толком не смотрел.

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

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

S>>Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?
Т>Ну в ОС Оберон (тфу, чуть опять не написал "в Обероне", угораздило же Вирта назвать ОС и язык одинаково) этой проблемы не существует, потому как однозадачная она. А бутылку я еще толком не смотрел.

Каайф, однозадачность — это как раз то, что народу и надо

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

Т>>>>Замечу, однако, что закрывать файлы в Обероне нет необходимости.

К>>>Нутко, подробнее пжалста. Почему не нужно ?
К>>>А я попробую заглючить это дело....
Т>>Потому что они закрываются автоматически.

К>Детерминированный сборщик мусора ?

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

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

Т>>>Я имел ввиду обычный Оберон, там файлы не блокируются.
SJA>>Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
SJA>>Или есть там какие-то подпорки и костыли ?

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

работа с файлами в язык не встроена

? Значит в стандарте языка не прописаны стандартные средства для работы с файлами ? Так почитайте стандарт С++ — узнаете много нового.

AVC> Поддержка работы с файлами осуществляется на уровне системных компонентов (того же модуля Files, например).
AVC>Так что Оберон тут ни при чем. Проблема где-то в "переходнике" между BlackBox и Windows.

Да ну ? Трурль заявил, что Оберон такая система, где закрывать файлы не нужно. Затем поправился и сказал, "Я имел ввиду обычный Оберон, там файлы не блокируются". Так всё же — файлы нельзя блокировать или нельзя незакрывать ?

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

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

Извини, но это выглядит чушью. Файлы открываются в ОС и никаких средств автоматического закрытия кроме по средством сборки мусора я в Обероне не вижу. Стало быть файлы останутся заблокированными до сборки мусора или завершения приложения.

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

Т>Я имел ввиду обычный Оберон, там файлы не блокируются.

Что такое "обычный Оберон"? И как он умудряется разделять файлы без блокировок? А так же читать их без открытия в ОС?

В любом случае язык претендующий на

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

"А если" тут не катит. Всегда есть "а если" и эти если нужно решать.

Здравствуйте, Sergey J. A., Вы писали:

К>>Ага, значит залочить файл в ОС Оберон мы изначально не сможем — супер, такие ОС суть светлое будущее!

SJA>Именно это я и хотел сказать.

Думаю — это был стеб.

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

S>Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?

Да и вообще интересно как с инародными и раделяемыми ресурсами. Ну, например с теми же TCP-соеденениями с другими серверами.