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

AVC>Здравствуйте, Павел Кузнецов, Вы писали:

>>> Шаблонов тоже нет. А для чего, кстати, они используются? Для реализации обобщенных (параметризованных) контейнеров и алгоритмов.
>>> Можно ли реализовать их без шаблонов? Можно. Всякий помнит функции qsort и bsearch из стандартной библиотеки языка Си <...>

ПК>>Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?

AVC>Такая проверка в Обероне не только возможна, но обязательна. Компилятор Оберона просто не позволит Вам обойти такую проверку, и его не обманешь "приведением типов".
AVC>Для этого используюся такие средства языка как type test (конструкция IS) и type guard (конструкция WITH).

В таком случае это что-то вроде dynamic_cast в C++, который является не статической проверкой типов, а динамической.

>>> Какой основной аргумент выдвигается в пользу того, что без шаблонов «жить нельзя»? Их выразительность. Допустим. (Хотя для меня еще выразительнее неспособность компилятора Си++ выдать мало-мальски читабельное диагностическое сообщение о синтаксической ошибке при разборе шаблонов.)

ПК>>Это не является следствием определения языка, а является следствием реализации соответствующих компиляторов. Тот же EDG, на мой взгляд, выдает вполне внятные сообщения об ошибках при инстанцировании шаблонов.

AVC>IMHO, тот факт, что компиляторы (пусть не все) даже очень крупных производителей (например, MSVC) не могут дать внятного сообщения об ошибке, говорит о том, что язык слишком усложнен.

Пора уже выбросить на свалку MSVC 6. 7'я версия уже нормально читабельные сообщения выдает.

>>> Но употребление шаблонов ведет к двум неприятным последствиям.
>>> Во-первых, многократное дублирование кода, т.к. шаблоны каждый раз компилируются в отдельный код.

ПК>>Это тоже далеко не обязательно: некоторые компиляторы умеют "сливать" идентичные специализации, плюс есть техники, как добиваться, чтобы код не "пух", даже если компилятор этого делать не умеет.

AVC>Да, существуют такие техники. Самый простой пример: использование косвенных контейнеров с inline функциями приведения void* к конкретному типу указателя.

Кстати сливает реализации не компилятор а линкер. Майкрософтовский линкер делает это на ура. Поэтому и любой компилятор, который создает объектные файлы совместимые с форматом, понимаемым этим линкером, автоматически получает такую возможность. А реализации контейнеров через void* были актуальны разве что десять лет назад.

Разбухание кода при использовании шаблонов является одним из "мифов" C++. Кто-то тут старается развенчать одни мифы, насаждая при этом плефору других мифов.

AVC>Но во многих случаях такие техники еще не изобретены.

В каких именно случаях?

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

ПК>>>Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?

AVC>>Такая проверка в Обероне не только возможна, но обязательна. Компилятор Оберона просто не позволит Вам обойти такую проверку, и его не обманешь "приведением типов".
AVC>>Для этого используюся такие средства языка как type test (конструкция IS) и type guard (конструкция WITH).

A>В таком случае это что-то вроде dynamic_cast в C++, который является не статической проверкой типов, а динамической.

Совершенно верно. Я допустил неточность. Хорошо, что Вы ее обнаружили.
Конструкция WITH по существу и есть dynamic_cast.
Я сосредоточился на основной мысли ПК: использование qsort небезопасно, компилятор не может гарантировать корректную работу qsort. Вот я и поспешил его "утешить": в Обероне это безопасно. И потому, к сожалению, слово "статическая" оставил без внимания.
Впрочем, основная мысль о безопасности подобных конструкций в Обероне остается в силе.

AVC>>IMHO, тот факт, что компиляторы (пусть не все) даже очень крупных производителей (например, MSVC) не могут дать внятного сообщения об ошибке, говорит о том, что язык слишком усложнен.

A>Пора уже выбросить на свалку MSVC 6. 7'я версия уже нормально читабельные сообщения выдает.

По ряду причин, я давно "переполз" на GNU C++.
Если MSVC стал лучше, я только рад, т.к. страдания программистской братии уменьшатся.
Но мое утверждение об усложненности Си++ остается в силе. Чем еще объяснить, что читабельные сообщения об ошибках появились только в 7-й версии? Не злым же умыслом разработчиков компилятора.

A>Кстати сливает реализации не компилятор а линкер. Майкрософтовский линкер делает это на ура. Поэтому и любой компилятор, который создает объектные файлы совместимые с форматом, понимаемым этим линкером, автоматически получает такую возможность. А реализации контейнеров через void* были актуальны разве что десять лет назад.

Говоря о линкере, Вы, наверное, хотели сказать, что во скольких бы файлах проекта не использовался, скажем vector<int>, его код войдет в программу лишь однажды.
Я с этим и не спорю.
Но, скажем, vector<double> уже приведет к генерации дополнительного кода (насколько большого зависит от реализации STL).
В еще большей степени это относится к шаблонным функциям, ведь, в отличие от классов, общую часть их реализации не поместишь в скрытых предках.

A>Разбухание кода при использовании шаблонов является одним из "мифов" C++. Кто-то тут старается развенчать одни мифы, насаждая при этом плефору других мифов.

Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.
P.S. А что такое плефора?

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

AVC>Говоря о линкере, Вы, наверное, хотели сказать, что во скольких бы файлах проекта не использовался, скажем vector<int>, его код войдет в программу лишь однажды.
AVC>Я с этим и не спорю.
AVC>Но, скажем, vector<double> уже приведет к генерации дополнительного кода (насколько большого зависит от реализации STL).
AVC>В еще большей степени это относится к шаблонным функциям, ведь, в отличие от классов, общую часть их реализации не поместишь в скрытых предках.

Кода будет ни на копейку не больше, чем если бы ты сам, ручками, написал отдельный класс массива интов, и отдельный класс массива даблов.
Я не прав?

Если прав — то по сравнению с чем разбухание?

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

ПК>Имхо, как раз очень даже хороший аргумент. AVC, насколько я его понял, не говорит о том, что Оберон "лучше", чем C#, а вполне наглядно иллюстрирует важный момент, затрудняющий "серьезное" сравнение данных языков: у них разная область применения.

Да нет у Оберона области применения. Есть только попытки продемонстрировать что его можно использовать. Написать ОС на чистом Обероне невозможно. Все равно загрузчик прийдется написать на языке порождающем нэйтив-коды. А так нет проблем и на Васике ОС написать. Было бы зачем.

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

AVC>Зачем тогда вообще постить, если он это уже высказал раз двести, употребляя выражения вроде "Оберон — это ЛАЖА"?

Могу высказать это еще раз. Хочешь?

AVC,

> ПК>>>Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?

> <...>

> Я сосредоточился на основной мысли ПК: использование qsort небезопасно, компилятор не может гарантировать корректную работу qsort. Вот я и поспешил его "утешить": в Обероне это безопасно. И потому, к сожалению, слово "статическая" оставил без внимания.

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

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

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

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

VD>Да нет у Оберона области применения. Есть только попытки продемонстрировать что его можно использовать. Написать ОС на чистом Обероне невозможно. Все равно загрузчик прийдется написать на языке порождающем нэйтив-коды. А так нет проблем и на Васике ОС написать. Было бы зачем.

Господи, и вот эти люди навязывают всем свое мнение об Обероне?!
Ну ведь хоть что-нибудь знал об Обероне! Я о многом не прошу, господи, но пусть Vlad2 хотя бы поинтересуется, что такое Оберон, где и как он применяется, прежде чем выносить свое "компетентное" суждение!
Для особо "одаренных" напоминаю: Оберон и был разработан для создания как операционной системы, так и всего програмного обеспечения рабочей станции Ceres. Там все программные компоненты, в т.ч. драйвера устройств и обработчики прерываний, написаны на Обероне.

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

AVC>>Зачем тогда вообще постить, если он это уже высказал раз двести, употребляя выражения вроде "Оберон — это ЛАЖА"?

VD>Могу высказать это еще раз. Хочешь?

Да ради Бога!
Только цена этому мнению — копейка в базарный день: см. предыдущий пост.

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

VD>>Да нет у Оберона области применения. Есть только попытки продемонстрировать что его можно использовать. Написать ОС на чистом Обероне невозможно. Все равно загрузчик прийдется написать на языке порождающем нэйтив-коды. А так нет проблем и на Васике ОС написать. Было бы зачем.

AVC>Господи, и вот эти люди навязывают всем свое мнение об Обероне?!
AVC>Ну ведь хоть что-нибудь знал об Обероне! Я о многом не прошу, господи, но пусть Vlad2 хотя бы поинтересуется, что такое Оберон, где и как он применяется, прежде чем выносить свое "компетентное" суждение!
AVC>Для особо "одаренных" напоминаю: Оберон и был разработан для создания как операционной системы,

Выпендривайся меньше. Одаренный, блин.

AVC> так и всего програмного обеспечения рабочей станции Ceres. Там все программные компоненты, в т.ч. драйвера устройств и обработчики прерываний, написаны на Обероне.

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

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

AVC>Да ради Бога!
AVC>Только цена этому мнению — копейка в базарный день: см. предыдущий пост.

Ошибашся. Это вот вашей рекламе этого убожетсва грош цена. Не удевлюсь если скоро сообщения об Обероне начнут сразу идти в девнал. Пользы от них 0. А задолбали они тут уже всех не нашутку.

Я плякаль. Предлагаю двинуть это в Юмор.

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

СГ>Например, блок try ... finally ... end нужен именно для того чтобы "прибрать за собой если вдруг нагадил". В то время как в языке со сборщиком мусора прибирать за собой не нужно.

Господи, какой бред? Ты файлы когда нибудь открывал? А на 0 делить у тебя никогда не приходилось?

ПК>> Мне интересно, а как предполагается сообщать об ошибках в Обероне, кодами возврата/модификацией глобальных переменных?

СГ>1) О каких еще ошибках?



СГ>2) Кому сообщать?



Ты вообще код то писал?

СГ>Ели об ошибках в алгоритме программы, то сообщать надо программисту — для этого есть ASSERT() и HALT().

Да чо уж там. Сделать метод DestroyComputerAndKillAllProgrammers().

PS

Мужики, у меня жувот не резиновй. Ну, столько бреда на квадратный милиметр выдавать просто опасно. Работа же в России остановится.

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

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

Нда. Блеск знаний! Ну, так может "гуру" покажет проблемы с типами в C#?

Или расскажет в чем его не устраивает диагностика дженериков?

А вообще, забавная прослеживается тенденция. Говоришь ему "Почему не сравниваешь своей убогий Оберон с современными языками вроде C#?", а в ответ "В С+...". Типа конструктивный разговор. Узнал что в С++ с типобезопасностью фигово и давай на это давить.

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

AVC>Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.
AVC>P.S. А что такое плефора?

А это когда человек пишет на языке на 5 лет дольше автора языка.

А вот занятно, что любимый VladD2 COCO/R был написан как раз на Обероне.

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

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

AVC>>Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.
AVC>>P.S. А что такое плефора?

VD>А это когда человек пишет на языке на 5 лет дольше автора языка.
Занятно, я пишу уже 15 лет на С++, однако автором себя не считаю!
Что-то случилось в датском королевстве!!!

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

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

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

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

AVC>>>Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.
AVC>>>P.S. А что такое плефора?

VD>>А это когда человек пишет на языке на 5 лет дольше автора языка.
GZ>Занятно, я пишу уже 15 лет на С++, однако автором себя не считаю!
GZ>Что-то случилось в датском королевстве!!!

Sorry не 15, обсчитался, 11 лет. Но языку С значительно больше времени, столько не живут.

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

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


AVC>> так и всего програмного обеспечения рабочей станции Ceres. Там все программные компоненты, в т.ч. драйвера устройств и обработчики прерываний, написаны на Обероне.

VD>Драйверы и обработчки можно на чем хочешь писать. Вопрос в том, что если среда поддерживает джит, то должен быть фиксированный код который запустит джит-компилятор. Насколько я понял Оберон предпологал наличие джит-компиляции.

C# тоже может писать unmanaged код, поэтому это не концептуальная проблема.

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

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

VD>Драйверы и обработчки можно на чем хочешь писать. Вопрос в том, что если среда поддерживает джит, то должен быть фиксированный код который запустит джит-компилятор. Насколько я понял Оберон предпологал наличие джит-компиляции.

Сначала ты заверял, что когда-то пытался программировать на Обероне и одновременно заявил что в нем нет инструкции RETURN.

Сейчас ты утверждаешь что насколько ты понял в Обероне есть JIT компилятор.

Я даже не могу сказать что все что ты знаешь об Обероне равно НУЛЮ. Нет не нулю, а это вообще либо отрицательное число, либо мнимая единица.

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

VD>Здравствуйте, Павел Кузнецов, Вы писали:

ПК>>Имхо, как раз очень даже хороший аргумент. AVC, насколько я его понял, не говорит о том, что Оберон "лучше", чем C#, а вполне наглядно иллюстрирует важный момент, затрудняющий "серьезное" сравнение данных языков: у них разная область применения.

VD>Да нет у Оберона области применения. Есть только попытки продемонстрировать что его можно использовать. Написать ОС на чистом Обероне невозможно. Все равно загрузчик прийдется написать на языке порождающем нэйтив-коды. А так нет проблем и на Васике ОС написать. Было бы зачем.

Вот, почитай как возник первый Оберон:
http://www.uni-vologda.ac.ru/oberon/infoart/proj0.htm

ПОСТРОЕНИЕ ВНУТРЕННЕГО ЯДРА
Внутреннее ядро (Inner Core) системы Oberon состоит из файловой системы, загрузчика модулей и средств распределения памяти. Его пять модулей связываются воедино в так называемый файл загрузки (boot file). Здесь мы опишем те шаги, которые позволили сформировать внутренее ядро.

Вряд ли можно поспорить с тем, что началом всех начал для любого программного обеспечения на «голой» машине является начальный загрузчик (boot loader). Поскольку он размещается в ROM-памяти и не может изменяться, он должен быть как можно более компактным. Добиться этого не столь сложно, ведь цель загрузчика проста и хорошо определена. Файл загрузки рабочей станции Ceres состоит из последовательности блоков данных, каждому из которых предшествует его размер и адрес, по которому он должен быть размещен. Формат файла в нотации EBNF выглядит следующим образом:

файл_загрузки = {блок} ноль стартовый_адрес.
блок = размер адрес {байт}.

Начальный загрузчик инициализирует регистры компьютера, очищает память и считывает файл загрузки. Наша первая версия осуществляла считывание через последовательный интерфейс RS-232 и состояла менее, чем из 200 байтов кода. Она была запрограммирована с помощью техники кросс-ассемблирования на компьютере Lilith. Более поздние версии позволяли уже выбирать источник загрузки: винчестер, флоппи-диск или же последовательный канал. Сам файл загрузки создавался загрузочным компоновщиком (boot linker), который также работал на Lilith.