Re[44]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 09.02.05 16:39
Оценка: -1
Здравствуйте, Кодт, Вы писали:

К>В Quick/Visual Basic тоже

К>Кстати, а это именно прямоугольник, или массив с рваным краем (jagged array) ?

Это именно прямоугольник.

К>Кстати. То, что в С++ это делается не на уровне языка, а с помощью библиотек (в Фортране, кстати, тоже; без библиотек Фортран был бы нищ, как полковник Кудасов), — содержит большое достоинство.


То, что в Си++ это можно делать не на уровне языка — достоинство.
Но не новое, и свойственное многим языкам.
Разница только в том, что Си++ перегружает оператор индексации. Т.е. можно использовать квадратные скобки, а в других языках используются круглые. Мне кажется, что это не принципиально.
А вот то, что в Си++ это не сделано на уровне языка — явный недостаток.
Не городить же всякий раз огород из-за ерунды.

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


Просто доведите это свое утверждение до логического конца.
Вы придете к языку ассемблера.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[45]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 09.02.05 16:46
Оценка:
AVC пишет:

> То, что в Си++ это можно делать не на уровне языка — достоинство.

> Но не новое, и свойственное многим языкам.
> Разница только в том, что Си++ перегружает оператор индексации. Т.е.
> можно использовать квадратные скобки, а в других языках используются
> круглые. Мне кажется, что это не принципиально.
> А вот то, что в Си++ это *не* сделано на уровне языка — явный недостаток.

А зачем это на уровне языка? И почему на уровне языка должны быть именно
прямоугольные массивы, а не разреженные матрицы в виде мультисписков?
Чем прямоугольники лучше?

> К>А если какое-то представление оказалось зашито в язык, то оно ставит

> остальные в неравные условия перед разработчиком алгоритмов.
> Просто доведите это свое утверждение до логического конца.
> Вы придете к языку ассемблера.

Ну так C и создавался как низкоуровневый язык, ближайшая замена
ассемблеру. На а С++ унаследовал (частично) дух С.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[46]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 09.02.05 17:03
Оценка: :))
Здравствуйте, Cyberax, Вы писали:

>> А вот то, что в Си++ это *не* сделано на уровне языка — явный недостаток.

C>А зачем это на уровне языка? И почему на уровне языка должны быть именно
C>прямоугольные массивы, а не разреженные матрицы в виде мультисписков?
C>Чем прямоугольники лучше?

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

>> К>А если какое-то представление оказалось зашито в язык, то оно ставит

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

Об этом я и говорю.
А то некоторые утверждают, что Си++ — сильно типизированный язык.
Тогда как отовсюду "торчит" Си.
Только Си — простой, маленький и честный язык.
А Си++ пытается усидеть на всех стульях сразу.
Он и седалище себе соответствующее отрастил.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[47]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 09.02.05 17:15
Оценка:
AVC пишет:

>>> А вот то, что в Си++ это *не* сделано на уровне языка — явный

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

Я, например, не считаю прямоугольный многомерный массив базовой
конструкцией. Одномерный массив — это действительно база (дальше уже
некуда).

> А есть сложные динамические структуры, которые из них строятся.

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

Просто многомерный массив не входит в число базовых вещей, так как есть
несколько вариантов его реализации с разными преимуществами и недостатками.

> Об этом я и говорю.

> А то некоторые утверждают, что Си++ — сильно типизированный язык.

Он сильно типизирован, просто предусмотрены варианты обхода типизации

> Тогда как отовсюду "торчит" Си.

> Только Си — простой, маленький и честный язык.
> А Си++ пытается усидеть на всех стульях сразу.

И у него это получается. Не идеально, конечно, но получается.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[48]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 09.02.05 17:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я, например, не считаю прямоугольный многомерный массив базовой

C>конструкцией. Одномерный массив — это действительно база (дальше уже
C>некуда).

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

>> Об этом я и говорю.

>> А то некоторые утверждают, что Си++ — сильно типизированный язык.
C>Он сильно типизирован, просто предусмотрены варианты обхода типизации

Если есть обход, то это не сильная типизация.
Но это мы уже обсуждали.

>> Тогда как отовсюду "торчит" Си.

>> Только Си — простой, маленький и честный язык.
>> А Си++ пытается усидеть на всех стульях сразу.
C>И у него это получается. Не идеально, конечно, но получается.

Пока.
А когда выйдет новый стандарт?

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[30]: Нужна ли Оберон-ОС защита памяти?
От: Astaroth Россия  
Дата: 09.02.05 18:05
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ну в 50Кб кода я тоже не верю А вот дискета-другая — вполне реально.


Ну, floppy-based дистрибутивов того же пингвина — как грязи.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
http://livejournal.com/users/breqwas
Re[33]: Нужна ли Оберон-ОС защита памяти?
От: Astaroth Россия  
Дата: 09.02.05 18:05
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>>>В принципе, Си++ — язык для детской песочницы.

WH>>Такое себе даже фанаты C# не позволяют.
AVC>Зато позволяют себе правительства Канады и Великобритании.

Тогда прошу предъявить мне либо ссылку, где правительства Канады и Великобритании заявляют, что "Си++ — язык для детской песочницы", либо доказательства того, что AVC является правительством Канади и Великобритании
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
http://livejournal.com/users/breqwas
Re[49]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 09.02.05 18:30
Оценка:
AVC пишет:

> C>Я, например, не считаю прямоугольный многомерный массив базовой

> C>конструкцией. Одномерный массив — это действительно база (дальше уже
> C>некуда).
> И я так думаю.
> Одномерный (гибкий) массив — базовая конструкция.
> А теперь я хочу получить массив массивов.

А _КАКОЙ_ массив массивов? Их несколько вариантов может быть, причем для
разных условий лучше подходят разные варианты.

> Т.к. массив — базовая конструкция, то язык должен это позволять.

> А Си++ — не позволяет.

boost::multi_array, и ваши волосы будут мягкими и шелковистыми...

А вот сделать разреженную матрицу на Обероне красиво не получится.
Вместо оператора индекса будет всякие функции типа GetElement().

>>> Об этом я и говорю.

>>> А то некоторые утверждают, что Си++ — сильно типизированный язык.
> C>Он сильно типизирован, просто предусмотрены варианты обхода типизации
> Если есть обход, то это не сильная типизация.

Она сильная, но отключаемая

>>> Только Си — простой, маленький и честный язык.

>>> А Си++ пытается усидеть на всех стульях сразу.
> C>И у него это получается. Не идеально, конечно, но получается.
> *Пока*.
> А когда выйдет новый стандарт?

Недавно, кажется вышел. Добавили стандартный ABI.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[34]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 09.02.05 20:53
Оценка: 17 (1)
Здравствуйте, Astaroth, Вы писали:

AVC>>>>В принципе, Си++ — язык для детской песочницы.

WH>>>Такое себе даже фанаты C# не позволяют.
AVC>>Зато позволяют себе правительства Канады и Великобритании.
A>Тогда прошу предъявить мне либо ссылку, где правительства Канады и Великобритании заявляют, что "Си++ — язык для детской песочницы", либо доказательства того, что AVC является правительством Канади и Великобритании


Пожалуйста:

That is where we learned that Canada and the UK (and probably other countries as well) strictly prohibit the use of C and C++ for developments related to any nuclear application.

Там же можно отыскать такую любопытную цитату:

At this conference, Dr. Clemens Szyperski also gave a memorable speech about the relationship between the tools and programming languages used and the quality and reliability of the code produced.

A famous quote (from memory): "It is a matter of disbelieve that so many people insist on using a fundamentally flawed tool for the most complex jobs that humanity ever had to face."

Надеюсь, Клеменса Шиперски представлять не нужно?
http://www.amadeus-3.com/main_files/space.html
Были и другие источники, да только память у меня девичья.
В данном случае источник информации — Стефан Метцелер, субъект весьма интересный.
С ним можно не соглашаться, но почитать его опусы стоит (imho).
Хотя бы потому, что его программистская производительность на порядок превосходит уровень "продвинутого" С++нутого программиста.
Лично мне наиболее интересной кажется статейка
http://www.amadeus-3.com/main_files/FlawsOfCPP.php
но можно почитать и
http://www.amadeus-3.com/main_files/oberon2vsCPP.php

Что же касается Си++, то на практике я отношусь к нему вполне лояльно.
В большинстве своих проектов я использовал именно этот язык, и знаю его достаточно хорошо (конечно, не как Павел Кузнецов ).
Так что моя "критика" — совсем не вопли злобного "аутсайдера".
Но именно поэтому я не могу не чувствовать внутреннего напряжения, нарастающего в языке.
Стали заметны нестыковки, ограничения (explicit), ограничения ограничений (mutuable), "подпружные арки и контрфорсы".
Главное: инструмент перестал умещаться в руке.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[50]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 09.02.05 23:18
Оценка: 57 (2) +1 :)))
Здравствуйте, Cyberax, Вы писали:

>> И я так думаю.

>> Одномерный (гибкий) массив — базовая конструкция.
>> А теперь я хочу получить массив массивов.
C>А _КАКОЙ_ массив массивов? Их несколько вариантов может быть, причем для
C>разных условий лучше подходят разные варианты.

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

>> Т.к. массив — базовая конструкция, то язык должен это позволять.

>> А Си++ — не позволяет.
C>boost::multi_array, и ваши волосы будут мягкими и шелковистыми...

Ах, увы... впрочем, что это я?
А что, массива — просто мас-си-ва — сегодня в продаже нет?

C>А вот сделать разреженную матрицу на Обероне красиво не получится.

C>Вместо оператора индекса будет всякие функции типа GetElement().

Да, блин, что-то некрасиво получается.
GetElement(), уродство какое-то...

>>>> Об этом я и говорю.

>>>> А то некоторые утверждают, что Си++ — сильно типизированный язык.
>> C>Он сильно типизирован, просто предусмотрены варианты обхода типизации
>> Если есть обход, то это не сильная типизация.
C>Она сильная, но отключаемая

Что-то мне это напоминает ежика:

Сильный-то я сильный. Но легкий.

А процесс кодирования на Си++ (с "отключаемой сильной типизацией") напоминает еще одного ежика:

"Я не пукну. Я не пукну."
Пук!
"Это не я. Это не я."



>>> Только Си — простой, маленький и честный язык.

>>> А Си++ пытается усидеть на всех стульях сразу.
> C>И у него это получается. Не идеально, конечно, но получается.
>> *Пока*.
>> А когда выйдет новый стандарт?
C>Недавно, кажется вышел. Добавили стандартный ABI.

Тут я "зарапортовался". Получилась двусмысленность. Как будто я с нетерпением ожидаю еще одного стандарта Си++, от которого мои "шелковистые волосы" прорастут уж в совсем неожиданных местах.
Я хотел сказать, что пока еще Си++ удается усидеть на нескольких стульях.
Но вот он еще прибавит в весе, и стулья его уже не выдержат, как в фильме "Любовь зла..."
Страуструп еще полон сил и очередных творческих планов. Твердо обещает GC для плюсов и мать Кузьмы их противникам.
Нет, ну как нарочно! Такое чувство, что человек решил жизнь положить, чтобы доказать, что все можно делать через задницу. Сначала непреклонная борьба за совместимость с Си, указатели, имеющие видимость типа лишь до первого его приведения, и священную адресную арифметику. А теперь распухшие от богатства идей компиляторы Си++ будут бегать (наверное, в оздоровительных целях) по всему коду и собирать эти указатели сачком?!
Живо представляю себе шутки GC в плюсах (да еще при совместимости с Си):

Вот Вася проснется, а голова-то в тумбочке!

Не знаю, что и сказать. То ли "верной дорогой...", то ли "туда и дорога..."

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[35]: Нужна ли Оберон-ОС защита памяти?
От: Privalov  
Дата: 10.02.05 06:40
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>В данном случае источник информации — Стефан Метцелер, субъект весьма интересный.

AVC>С ним можно не соглашаться, но почитать его опусы стоит (imho).
AVC>Хотя бы потому, что его программистская производительность на порядок превосходит уровень "продвинутого" С++нутого программиста.
AVC>Лично мне наиболее интересной кажется статейка
AVC>http://www.amadeus-3.com/main_files/FlawsOfCPP.php
AVC>но можно почитать и
AVC>http://www.amadeus-3.com/main_files/oberon2vsCPP.php

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

Без всякой иронии — как измерялась производительность этого парня? Вопрос об измерении производительности программиста поднимается не реже, чем Oberon vs. C++, поэтому интересно знать, какие критерии использовались в данном случае.

AVC>Так что моя "критика" — совсем не вопли злобного "аутсайдера". :)

AVC>Но именно поэтому я не могу не чувствовать внутреннего напряжения, нарастающего в языке.
AVC>Стали заметны нестыковки, ограничения (explicit), ограничения ограничений (mutuable), "подпружные арки и контрфорсы". :)

А может, все недостатки C++ происходят оттого, что проектировался он не в академической организации, а в коммерческой структуре? Подход к разработке в коммерческих и академических организациях сильно различается. В исследовательской лаборатории можно одним махом выбросить старую платформу и перейти на новую. Вирт не раз так делал. Например, он призывал всех отказаться от Паскаля в пользу Модулы-2. Но в жизни, в жестких условиях временных, бюджетных и прочих ограничений, подобное, как правило, невозможно. Отсюда требование — сохранить совместимость со старым работающим софтом. А дальше так: ввели в язык, например, перегрузку, и появилось ключевое слово overload. И сохранялось оно в C++ годы. Потому что кто-то где-то его использовал. Так что проблема избавления от анахронизмов — гораздо более сложная, чем изобретение новых возможностей.

AVC>Главное: инструмент перестал умещаться в руке.


Согласен. Есть, впрочем, надежда, что C++ не повторит путь PL/1.
Re[45]: Нужна ли Оберон-ОС защита памяти?
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.02.05 07:34
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:
СГ>В Обероне, в отличие от Java и от C#, массивы есть всякие.
Неверно. Сам .Net поддерживает N-мерные массивы, в том числе и не 0-based. Т.е. можно использовать массив типа int[1..5, -3..8]. В C# на уровне синтаксиса поддерживаются только 0-based размерности.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 10.02.05 08:04
Оценка:
Здравствуйте, AVC, Вы писали:

СГ>>>Вывод — чтобы изничтожить неугодный активный объект достаточно убрать его из очереди за процессорным временем.

К>>Во-первых, вылететь из очереди планировщика можно тремя способами:
К>>- из running в waiting
К>>- из running в suspended
К>>- из ready в suspended

AVC>ИМХО, это зависит от ОС.

AVC>Может быть три способа, а может быть тридцать три.

Интересно, это какие же тридцать три, если всего есть 5 принципиально разных состояний (выполняется, готов, усыплён, ждёт, завершён).

К>>Для вытесняющей многозадачности переход running->ready может случиться по внешним причинам (например, по прерыванию).

К>>Это означает, что какой-то инвариант может быть нарушен. Естественно, после возврата в running инвариант объект восстановит инвариант; кроме того, программист всегда может установить, какие качества системы зависят от подвисания объекта, а какие не зависят и могут безопасно использоваться. Но сборка мусора — знает ли она об этом?

AVC>Для обеспечения сохранности инвариантов существуют мониторы. (Или другие средства синхронизации.)

AVC>Если система поддерживает мониторы, то неясно, почему могут быть нарушены (системные) инварианты.

Монитор, я так понимаю, не предполагает исключительное и непрерываемое исполнение программы? Или предполагает?!

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

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


AVC>Здесь нет ничего специфичного для ОС Оберон.

AVC>На что, кстати, уже обращалось внимание.

А я и не говорю про Оберон. Просто в системах, где потоки — это низкий уровень, команду kill или TerminateThread применяют только от безысходности или по разгильдяйству. А если система сама будет решать, когда ей прибивать якобы заторможенный активный объект — будет много увлекательных приключений.

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


AVC>Откуда?

AVC>Вопрос неясен.

Откуда: из очереди к ресурсу.

К>>В третьих, алгоритм работы объекта-демона принципиально состоит в бесконечном цикле (точнее, он выходит из цикла, получив сигнал остановки). А значит, он может что-нибудь зацепить...


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


Так ведь удаления-то не произойдёт! Объект всё время активен (молотит цикл ожидания)...

К>>Обнаружив факт полного выжирания памяти, сборщик мусора должен выяснить: какие демоны можно перезапустить. Как он это сделает, в условиях единого адресного пространства?


AVC>А как он это сделает в условиях нескольких адресных пространств?


Процесс, выжравший свою квоту (или все ресурсы, если квота бесконечна), получит звоночек. Если звоночек не обработан, то процесс уничтожается, освобождая ресурсы. Остальные процессы при этом не страдают.
Перекуём баги на фичи!
Re[51]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 10.02.05 08:12
Оценка:
Здравствуйте, AVC, Вы писали:

>>> Одномерный (гибкий) массив — базовая конструкция.

>>> А теперь я хочу получить массив массивов.
C>>А _КАКОЙ_ массив массивов? Их несколько вариантов может быть, причем для
C>>разных условий лучше подходят разные варианты.

AVC>Я не против других вариантов.

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

>>> Т.к. массив — базовая конструкция, то язык должен это позволять.

>>> А Си++ — не позволяет.
C>>boost::multi_array, и ваши волосы будут мягкими и шелковистыми...

AVC>Ах, увы... впрочем, что это я?

AVC>А что, массива — просто мас-си-ва — сегодня в продаже нет?

Ты сам лукавишь. Есть массив массивов в продаже. Есть!!! С учётом того, что указатель на одиночный элемент и указатель на массив в С++ неразличимы, то
Element square[X][Y];

Element* jagged[X];
jagged[0] = new Element[Y1];
jagged[1] = new Element[Y2]; ...

square[1][2] = Element(123);
jagged[1][2] = Element(456);

Для тех, кому не нравится смешивать одиночные элементы и массивы — см. boost::array и т.п.
Для тех, кому хочется динамики — см. std::vector.
Перекуём баги на фичи!
Re[52]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.02.05 08:48
Оценка:
Здравствуйте, Кодт, Вы писали:

К> Есть массив массивов в продаже. Есть!!! С учётом того, что указатель на одиночный элемент и указатель на массив в С++ неразличимы, то

К>
К>Element square[X][Y];

К>Element* jagged[X];
К>jagged[0] = new Element[Y1];
К>jagged[1] = new Element[Y2]; ...

К>square[1][2] = Element(123);
К>jagged[1][2] = Element(456);
К>

К>Для тех, кому не нравится смешивать одиночные элементы и массивы — см. boost::array и т.п.
К>Для тех, кому хочется динамики — см. std::vector.

Да как же? Не вижу я чего-то массива массивов.

Ваш square[X][Y] — это двумерный массив.
Ваш *jagged[X] — это массив указателей.

В то время как массив массивов вот какой: ARRAY OF ARRAY OF Element.

"ARRAY OF", и "ARRAY N OF" — это базовые типы. Комбинируя их в сочетании с другим базовым типом "POINTER TO" можем получить очень много разных комбинаций (почувствуйте разницу):
TYPE
  A1 = ARRAY dim0, dim1 OF Element;
  A2 = ARRAY OF ARRAY OF Element;
  A3 = POINTER TO ARRAY dim0, dim1 OF Element;
  A4 = POINTER TO ARRAY OF ARRAY OF Element;
  A5 = ARRAY OF POINTER TO ARRAY OF Element;
  A6 = ARRAY dim0 OF POINTER TO ARRAY OF Element;
  A7 = POINTER TO ARRAY OF POINTER TO ARRAY OF Element;
  A8 = POINTER TO ARRAY OF POINTER TO ARRAY dim1 OF Element;
  A9 = POINTER TO ARRAY dim0 OF POINTER TO ARRAY dim1 OF Element;
  A10 = POINTER TO ARRAY dim0 OF POINTER TO ARRAY OF Element;
  ...
  и так далее - разных вариантов превеликое множество....

Так что, извините, но самого обычного массива массивов в Си/Си++ нет.
MODULE  Test;

    PROCEDURE P1 (VAR array: ARRAY OF REAL);
        VAR i: INTEGER;
    BEGIN
        FOR i := 0 TO LEN(array)-1 DO
            array[i] := 0.0
        END
    END P1;

    PROCEDURE Calculate (VAR mat: ARRAY OF ARRAY OF REAL);
        VAR dim0, dim1, i, j: INTEGER;
    BEGIN
        dim0 := LEN(mat, 0);
        dim1 := LEN(mat, 1);
        FOR i := 0 TO dim0-1 DO
            FOR j := 0 TO dim1-1 DO
                mat[i, j] := 0.0;
            END
        END
    END Calculate;

    PROCEDURE Test (  );
        VAR a: ARRAY 192, 256 OF REAL;
        b: POINTER TO ARRAY 4096, 1024 OF REAL;
        c: POINTER TO ARRAY OF ARRAY OF REAL;
    BEGIN
        Calculate(a);
        P1(a[2]);
        
        NEW(b);
        Calculate(b);
        P1(b[3]);
        
        NEW(c, 8128, 512);
        Calculate(c);
        P1(c[4]);
        
    END Test;
    

END  Test.
Re[53]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 10.02.05 09:03
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да как же? Не вижу я чего-то массива массивов.


СГ>Ваш square[X][Y] — это двумерный массив.

СГ>Ваш *jagged[X] — это массив указателей.

СГ>В то время как массив массивов вот какой: ARRAY OF ARRAY OF Element.


Ещё раз для тех, кто в Обероне: указатель на массив и указатель на одиночный элемент в С/С++ неразличимы.

СГ>"ARRAY OF", и "ARRAY N OF" — это базовые типы. Комбинируя их в сочетании с другим базовым типом "POINTER TO" можем получить очень много разных комбинаций (почувствуйте разницу):


Библиотека STL — тоже базовая. Можешь поэкспериментировать с разнообразными комбинациями векторов и обычных массивов.
typedef int five_ints[5];
five_ints a[3]; // массив 3*5
five_ints b[] = { {0}, {0}, {0}, {0} }; // 4*5
vector<five_ints> c(n); // n*5, где n - переменная

ну и указатели туда же, и т.д. и т.п.

СГ>Так что, извините, но самого обычного массива массивов в Си/Си++ нет.


Беспочвенный шовинизм.
Перекуём баги на фичи!
Re[6]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.02.05 09:22
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>Например, в MFC можно сделать "активный объекты", наследуя их от

C>CAppThread

Разумется нельзя! Активные объекты подразумевают особый планировщик параллельного исполнения активностей. В то время как планировщик процессов/потоков работает совершенно по другому принципу.


Прежде чем реализовывать активный объект, обратите внимание на самый обыкновенный пассивный объект:
MODULE BoundedBuffers;
  TYPE
    Item* = OBJECT; (* generic object *)

    Buffer* = OBJECT
      VAR h, n: INTEGER; 
      B: ARRAY * OF Item;

    PROCEDURE Get*(): Item;
      VAR x: Item;
    BEGIN {EXCLUSIVE}
      AWAIT(n # 0); (* buffer not empty *)
      x := B[h]; h := (h+1) MOD LEN(B); DEC(n);
      RETURN x
    END Get;

    PROCEDURE Put*(x: Item);
    BEGIN {EXCLUSIVE}
      AWAIT(n # LEN(B)); (* buffer not full *)
      B[(h+n) MOD LEN(B)] := x; INC(n)
    END Put;

    PROCEDURE &Init(max: INTEGER);
    BEGIN (* initializer *)
      NEW(B, max); h := 0; n := 0
    END Init;

  END Buffer;

END BoundedBuffers.

Как Вы в MFC реализуете AWAIT? А никак, разьве только бесконечным циклом который будет есть процессорное время постоянно проверяя условие истинности!!! Кстати, не забудьте, что EXCLUSIVE — это метка блока исполняющегося целиком, как одна элементарная (атомарная) инструкция. И внутри этой атомарной элементарной инструкции Вы должны будете запустить бесконечный цикл проверки условия AWAT(condition)...




Подсказка.
В рантайм системе Aos инструкция AWAIT просто ставит активность (активный объект) в очередь ожидания выполнения условия, так что лишнее процессорное время не расходуется. Активных объектов одновременно может быть десятки тысяч! Представьте что будет (в случае MFC), кода 50'000 потоков будут каждый в своем бесконечном цикле AWAIT дожидаться чего-нибудь. Вроде ничего не происходит, все просто чего-то ждут, а процессор загружен на 100%.
Re[6]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.02.05 09:39
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Интересно, это какие же тридцать три, если всего есть 5 принципиально разных состояний (выполняется, готов, усыплён, ждёт, завершён).


В Aos они другие и их больше:

http://e-collection.ethbib.ethz.ch/cgi-bin/show.pl?type=diss&amp;nr=14755

5.9.1 Process States

A process can be in one of several states, and with every state (except
Terminated) is associated a data structure which stores descriptors of
processes in that state. It follows that a process can only be in one of
these data structures at any time — when it switches state it is also
moved from one data structure to another. The states and all possible
transitions between them are shown in figure 5.6 and described below:

Ready This is the initial state of a process. It is ready to run and
waiting for a processor to be assigned to it, at which time it will
move to the Running state.

Running A process is in this state when it is running on one of the
available processors. It leaves this state when it terminates, is
preempted, or starts waiting for a lock, condition or interrupt.

AwaitingLock A process is in this state when it is waiting to acquire
an object lock that is held by another process. When it eventually
acquires the lock, it moves back to the Ready state.

AwaitingCondition A process is in this state when it is waiting for
a condition to be made true by some other process. When the
condition is eventually found to be true by the runtime system,
the process moves back to the Ready state.

AwaitingInterrupt A process (typically a device driver) is in this
state when it is waiting for a specific interrupt to occur. This
is similar to the previous state, except that the process will be
enabled to run by an interrupt, and not the actions of another
process (cf. 4.3.3). When it is enabled, it moves back to the Ready
state.

Terminated This is the final state, which is entered when a process terminates.
Terminated process descriptors are not in any programdefined
data structure, but remain in the heap until they are
cleaned up by the garbage collector.

Re[7]: Нужна ли Оберон-ОС защита памяти?
От: Sergey Россия  
Дата: 10.02.05 09:58
Оценка:
Hello, Сергей!
You wrote on Thu, 10 Feb 2005 09:22:19 GMT:

СГ> Как Вы в MFC реализуете AWAIT? А никак, разьве только бесконечным

СГ> циклом который будет есть процессорное время постоянно проверяя условие
СГ> истинности!!! Кстати, не забудьте, что EXCLUSIVE — это метка блока
СГ> исполняющегося целиком, как одна элементарная (атомарная) инструкция. И
СГ> внутри этой атомарной элементарной инструкции Вы должны будете
СГ> запустить бесконечный цикл проверки условия AWAT(condition)...

Сказки только не надо рассказывать — это делается элементарно без всяких
оберонов. EnterCriticalSection/LeaveCriticalSection (или, по вкусу —
boost::mutex/boost::mutex::scoped_lock) на замену EXCLUSIVE подойдут вполне.
А AWAIT может быть реализован хоть на бесконечном цикле со Sleep(0) внутри,
хоть на WaitForSingleObject, хоть на любом другом удобном для конкретного
случая примитиве.

СГ>

СГ> Подсказка.
СГ> В рантайм системе Aos инструкция AWAIT просто ставит активность
СГ> (активный объект) в очередь ожидания выполнения условия, так что лишнее
СГ> процессорное время не расходуется. Активных объектов одновременно может
СГ> быть десятки тысяч! Представьте что будет (в случае MFC), кода 50'000
СГ> потоков будут каждый в своем бесконечном цикле AWAIT дожидаться
СГ> чего-нибудь. Вроде ничего не происходит, все просто чего-то ждут, а
СГ> процессор загружен на 100%.

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

With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[54]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 10.02.05 10:26
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Ещё раз для тех, кто в Обероне: указатель на массив и указатель на одиночный элемент в С/С++ неразличимы.


Для тех, кто в Си++. (Хотя пока и вынужденно кратко.)
1) Помедитируйте над Вашим утверждением в свете планов Страуструпа о введении GC в Си++.
"Шелковистые волосы" на голове не шевелятся?
2) Слава Богу, оно не на 100% соответствует действительности.
Сравним две конструкции:
delete p;

и
delete [] p;

Как всегда — "повешено" на программиста.
3) Все это вообще не имеет отношения к делу.
ARRAY OF ARRAY OF REAL (например) — это не массив указателей, а именно массив массивов.
Т.е., наверное, то, что Privalov называет "одним массивом".
Т.к. в Си++ нельзя написать
void foo(float a[][]);


то массива массивов (по крайней мере, в этом смысле) в Си++ нет.

СГ>>Так что, извините, но самого обычного массива массивов в Си/Си++ нет.

К>Беспочвенный шовинизм.

С чьей стороны?

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.