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

Д>>Язык — он такой, какой есть. Не очень то кроссплатформенный

GN>А если захотели мы кросплатформенность получить? (java)

А ты попробуй j2ee приложение на j2me платформе запустить.

И Java и C++ -- кроссплатформенные языки. А вот отдельные программы на них совершенно не переносимы. И в C++ посредством директивы asm есть возможность такую программу при необходимости сделать.

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

E>И Java и C++ -- кроссплатформенные языки. А вот отдельные программы на них совершенно не переносимы. И в C++ посредством директивы asm есть возможность такую программу при необходимости сделать.

Ты конечно прав. Но есть еще разница в том, насколько легко получить такую непереносимую программу на данном языке
В С++ есть намного больше таких способов, чем в Java. Из них asm — еще самый безобидный, поскольку найти куски на асме можно простым текстовым поиском. Найти непереносимые фокусы с приведением типов, доступом к памяти, нарушения стандарта и т.п. — куда сложнее.

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

E>>И Java и C++ -- кроссплатформенные языки. А вот отдельные программы на них совершенно не переносимы. И в C++ посредством директивы asm есть возможность такую программу при необходимости сделать.

Д>Ты конечно прав. Но есть еще разница в том, насколько легко получить такую непереносимую программу на данном языке
Д>В С++ есть намного больше таких способов, чем в Java. Из них asm — еще самый безобидный, поскольку найти куски на асме можно простым текстовым поиском. Найти непереносимые фокусы с приведением типов, доступом к памяти, нарушения стандарта и т.п. — куда сложнее.

Подавляющее большинство этих проблем связано с тем, что программам на C++ приходилось напрямую работать с нативным API, который еще для C был расчитан. Были бы библиотеки типа ACE и Boost в C++ сразу (как JDK в Java), глядишь, и проблем с переносимостью C++ было бы на несколько порядков меньше.

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

E>Подавляющее большинство этих проблем связано с тем, что программам на C++ приходилось напрямую работать с нативным API, который еще для C был расчитан. Были бы библиотеки типа ACE и Boost в C++ сразу (как JDK в Java), глядишь, и проблем с переносимостью C++ было бы на несколько порядков меньше.

Кому-нибудь придет в голову сериализовать объекты, приводя указатель к void* и записывая блок памяти на диск — и всё, приплыли. Забудь про переносимость
Или кто-нибудь напишет очередной загиб на шаблонах, который просто не откомпилируется на другом компиляторе.

Хотя "толстая" стандартная библиотека и правда уменьшила бы количество проблем на порядок. Эх, мечты.....

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

Д>Кому-нибудь придет в голову сериализовать объекты, приводя указатель к void* и записывая блок памяти на диск — и всё, приплыли. Забудь про переносимость

Ну это опять к вопросу полноты стандартной библиотеки

Д>Или кто-нибудь напишет очередной загиб на шаблонах, который просто не откомпилируется на другом компиляторе.

А вот это не корректно. Код для Java 1.5 на Java 1.4 не скопилируется. Так же, как и C# 2.0 и C# 1.0. Просто пока Java и C# настолько молоды и развиваются централизовано, что не появилось множества их независимых реализаций. Как только появятся (если появятся, конечно), так те же самые проблемы и возникнут.

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

E>А вот это не корректно. Код для Java 1.5 на Java 1.4 не скопилируется. Так же, как и C# 2.0 и C# 1.0. Просто пока Java и C# настолько молоды и развиваются централизовано, что не появилось множества их независимых реализаций. Как только появятся (если появятся, конечно), так те же самые проблемы и возникнут.

Ну не совсем так. У С++ проблема не в версиях стандартов, а в ее сложности — большинство компиляторов не полностью соотвествуют стандартам. У Явы и C# намного меньше всяких тонкостей и "особых случае", поэтому и объем спецификации намного меньше -> на порядок меньше проблем совместимости компиляторов.

Меня позабавила цитата:

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

http://alexcheremkhin.boom.ru/oberon.htm

sch wrote:

> Меня позабавила цитата:
>
>Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.
>
> http://alexcheremkhin.boom.ru/oberon.htm

А главный недостаток — в ламерах, которые в С++е не разбираются

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

Чем?

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

C>AVC wrote:

>> C>В той реализации Оберона, которую я смотрел, нет полностью точного
>> C>сборщика GC. Он там "mostly precise" — куча собирается точно, но стек
>> C>рассматривается консервативно. Boehm GC так тоже умеет.
>> Действительно, кандидаты из стека выбираются "консервативно" (по
>> крайней мере, в Компонентном Паскале).
>> По-видимому, это реализационный компромисс.

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

Компиляторы Оберона (кроме версий,расчитанных на JVM и .NET) порождают нативный код.
В принципе, чтобы обеспечить точную сборку мусора для стека, язык менять не нужно.
Вот первое, что приходит в голову.
Компилятор Оберона обнуляет указатели (и процедурные переменные) при входе в процедуру.
Значит, знает их адреса.
Можно заодно его "попросить" заносить адреса указателей в специальную структуру (устроеную по принципу стека).
При выходе из процедуры — просто сокращать этот второй стек.
Тогда в любой момент будут точно известны все локальные указатели, и сборку можно будет проводить точно, а не консервативно.
Скорее всего, просто в этом нет необходимости.
Удельная масса "корней" в стеке сравнительно невелика (по сравнению с числом нелокальных "корней").

C>Вообще, сейчас только в C++/CLI нормально продумана интеграция GC и
C>нативного кода.

Компилятор Оберона порождает нативный код. Так что его интеграция с GC — a priori.
Возможно, я просто недопонял последнее утверждение?

>> Не сомневаюсь, что Boehm умеет работать "консервативно" со стеком.
>> Но вряд ли Boehm умеет "прецизно" работать с сегментом данных.

C>Умеет, умеет. Ему лишь надо указать формат объектов (то есть где в них
C>искать указатели) — этим успешно пользуются в Mono. С С++ это немного
C>неудобно, но тоже возможно.

Но чревато ошибками, как всякая ручная работа (и особенно — в Си++ ).
В Обероне же это делает компилятор.

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

sch>Меня позабавила цитата:
sch>

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

sch>http://alexcheremkhin.boom.ru/oberon.htm


???

AVC wrote:

> Компиляторы Оберона (кроме версий,расчитанных на JVM и .NET) порождают
> нативный код.
> В принципе, чтобы обеспечить точную сборку мусора для стека, язык
> менять не нужно.
> Вот первое, что приходит в голову.
> Компилятор Оберона обнуляет указатели (и процедурные переменные) при
> входе в процедуру.
> Значит, знает их адреса.

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

> Можно заодно его "попросить" заносить адреса указателей в специальную
> структуру (устроеную по принципу стека).
> При выходе из процедуры — просто сокращать этот второй стек.

Есть такой метод, вот тут он хорошо описан:
http://citeseer.ist.psu.edu/henderson02accurate.html

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

Тут немного другие проблемы — сборка мусора в многотредовом приложении
может возникнуть в любой момент исполнения функции. Но это не всегда
безопасно.

Например, представим такой сценарий:

создать_новый_объект
pop ax ; В ax будет адрес нового объекта
<-- И тут врубается полный цикл GC, запущеный из другого потока
mov var_1,ax ;Запишем ax в переменную

В этом случае GC не увидит только что созданый объект, лежащий в регистре.

Или другой вариант:

;В ax лежит адрес объекта
push ax ;Кладем его в стек
push some_parameter
<-- Приходит пушной зверек GC
call SomeFunction
...

Тут GC не увидит положенную в стек переменную.

Если используется передвигающий GC (moving GC), то такие ошибки будут
фатальны для программы.

Поэтому делают GC возможным только в специальных GC safepoint'ах (их
обычно расставляют в началах циклов, длинных ветвлений и т.п.) — для
каждого safepoint'а сохранена в виде таблиц точная информация о
состоянии стека и регистров в нем (stackmaps, register maps). Сразу
появляются проблемы: как заставить потоки остановиться в safepoint'ах,
как построить stackmap'ы с минимальным оверхедом и т.п. Поэтому точная
сборка стека — это и есть хвостик, тянущий за собой слона.

> C>Вообще, сейчас только в C++/CLI нормально продумана интеграция GC и
> C>нативного кода.
> Компилятор Оберона порождает нативный код. Так что его интеграция с GC
> — a priori.
> Возможно, я просто недопонял последнее утверждение?

Да, я другое имел в виду. Почитайте, хотя бы:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vclrf__pin.asp
и http://www.codeproject.com/dotnet/pointers.asp

> C>Умеет, умеет. Ему лишь надо указать формат объектов (то есть где в них
> C>искать указатели) — этим успешно пользуются в Mono. С С++ это немного
> C>неудобно, но тоже возможно.
> Но чревато ошибками, как всякая ручная работа (и особенно — в Си++ ).

Естественно.

> В Обероне же это делает компилятор.

Для GCC есть расширение, которые автоматически генерирует object map'ы.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

Д>Оказывается, Ява — это испорченный Оберон. Чем дальше, тем лохмаче

Причем испорченый сишным синтаксисом. А все беды в мире от "х = у".

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

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

Д>>Оказывается, Ява — это испорченный Оберон. Чем дальше, тем лохмаче

AVC>Есть возражения по существу?

Ага.

AVC>Hint: отвлекитесь от разницы Си-подобного и Паскале-подобного синтаксиса и сопоставьте конструкции языков.

Ты читал то внимательно? Напомню "Ява это Оберон испорченный С-шным синтаксисом". То есть основная проблема в синтаксисе!


AVC>Попробуйте указать другой язык-предшественник, с которым у Явы были бы такие большие совпадения.

Легко:
1. С/С++ — синтаксис.
2. Смолток — заимствование джит-компиляции, сборщика мусора, виртуальной машины.
3. Паскаль/Ада — заимствование идей безопастного программирования.

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

AVC>Лично я это проделал, у меня больших сомнений насчет Явы нет.

Да Вирт с Губавновым вобще сомневаются в том, что нужны какие-то языки кроме Оберона и Зенона. Ну, и что? Ты будешь третьим.

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

AVC> Си++ Java Oberon
AVC>Модульность и раздельная компиляция Нет Да Да

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

AVC>Шаблоны Да Нет Нет

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

AVC>Сборка мусора Нет Да Да

Ой, а Смолток то ты куда подевал?

AVC>Деструкторы Да Нет Нет

Ой, и в С небыло.

AVC>Объединения (union) Да Нет Нет

Да, юнионы в С были. Но в ассемблере небыло.

AVC>Многомерные открытые массивы Нет Да Да

Погоди. В яве нет многомерных массивов. Кстати, как и в ассемблере.

AVC>Наследование Мн. Од. Од.

В Смолтоке тоже одиночное вроде.

AVC>Оператор goto Да Нет Нет

Ой, а в C# есть. Ну. слава богу хоть он доказано не от Явы или не дай бог Оберона произошел. И то радость.

AVC>ИМХО, Си++ и близко не ночевал здесь.

А Оберон ночевал? Сопаденй столько скольк с ассемблером.

Яву проектировали анализируя целую кучу языков. Оберон был одним из них. Причем тем одним который не привнес ни одной конструкции или подхода которые не были бы известны до этого из других языков.

Твои аргументы просто смешны. Это чистая притягивание за уши.

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

AVC>Разумеется, здесь перечислено далеко не все.
AVC>Например, в Java (как и в Обероне) нет адресной арифметики — "краеугольного камня" Си/Си++.

А в C# есть адресная арифметика, хотя она и не является краеуголным камнем. А ведь многие считают Шарп клоном Явы. Забавно, правда?

AVC>(Впрочем, в Java вообще нет указателей. )

Ой. Несовпаденице. Теория рушится.

AVC>И т.д. и т.п.

Ага. Самому то не смешно?

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

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

А ты не задумывался, что различия с одной сущностью не доказывает схожести с другой?
Знашь как называется "логика" которую ты применяешь?

AVC>Возьмем, к примеру, отсутствие в Обероне и Java вариантных записей (union).

Класс! Эдак мы докажем, что у Явы и Эйфелевой башней много общего. Например, у них о обоих нет крыльев и хвоста.

AVC>Во-первых, такие записи могут использоваться (и используются) для скрытого приведения типов, что в корне противоречит концепции безпасности типов. Си++ это заботит мало (по-моему, ему на все наплевать ), а вот Оберон и Java — сильно "привязаны" к безопасности типов.

Интересно, а вот в ОКамле есть нечто вроде юнионов, но по строгости типизации по сравнению с ним Ява и даже Оберон отдыхают по полной. И что?

AVC>Во-вторых, здесь есть прямая связь с реализацией сборки мусора.

Зашибись. В ОКамле есть сборка мусора и есть юнионы. Твоя теори разрушена. Идем дальше.

AVC> Дескриптор типа в Обероне включает не только адреса методов (type-bound procedures), но и смещения указателей в записи. Если бы во время исполнения программы по этому смещению могли находиться как указатель, так и переменная неуказательного типа, то механизм сборки мусора сильно бы усложнился, а то и вовсе стал бы труднореализуемым. Т.к. Вирт уже добавил в язык расширение типа ( =наследование), то потребность в вариантных записях, порождающих эти проблемы, отпала сама собой.

Проблемы реализации в обсуждении схожести языков? Прэлесно!

AVC>Но возникла другая проблема: а как эффективно определить динамический тип записи?

Да. Тут ты прав. Первые реализации Явы думали именно о эффективности. От того они наверно были интерпретаторами и делали все методы по умолчанию виртуальными. Просто полная аналогия с Обероном.

AVC>(Напомню, что факт принадлежности переменной к тому или иному динамическому типу требует всего одного сравнения.)

Это как-то следует из спецификации языка?

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

Извини за прямоту, но притягиванием за уши она смотрится. Болше ничем (это если в мягких выражениях).

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

СГ>Нельзя сказать что в Oberon совсем нет reflection. Иногда есть, и зависит это от реализации конкретной Оберон-системы. Например, в BlackBox оно доступно посредством модуля Meta.

Его нет в спецификации языка. В том время как в спецификациях C#, Явы и Смолтока рефлексия есть.

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

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

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

Я тоже так хочу.

Итак ассемблер:
1. Модульный потому как я так хочу. Смотри это

Автор: VladD2
Дата: 03.10.05

сообщение.
2. Сборка мусора в нем возможна так как на на оссемблере можно все, и еще см. вот это

Автор: VladD2
Дата: 03.10.05

.
3. Многомерные массивы на ассемблере возможны, так как на нем можно все.

Теперь о сходствах Оберона и ассеблера:
1. И у ассемблера, и у Оберона нет множественного наследования.
2. И у ассемблера, и у Оберона нет юнионов.
3. И у ассемблера, и у Оберона нет оперторов select.
4. И у ассемблера, и у Оберона нет обработки исключений.
5. И у ассемблера, и у Оберона нет... короче много чего нет.

Думаю этого достаточно чтобы сделать вывод, что Оберон является клонм ассемблера?

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

AVC>Это скорее старая добрая независимая компиляция.
AVC>Разве есть в DLL контроль типов?

Ну, длл это конечно за уши притянуто. Правда у тебя вообще все за уши притянуто, и тебя это не смушает.

AVK>>Начиная с 1.5 в Java средства обобщеного программирования присутствуют

AVC>И вызывают большие нарекания.
AVC>В любом случае, это не шаблоны.

А ничего, что в Обероне нет даже дженериков, и что Вирт всячески от них открещивается? Хорошее такое сходство.

AVC>Эта идея в Java действительно новая и, похоже, неплохая.

Хм. А не из С++ ли она повзаимствована? Там вроде бы и МН было, и интерфейсы вроде как эмулировались очень давно. Ком появился в 93-ем, и в нем уже были интерфейсы эмулируемые на С++.