RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> >> А у меня - компилируется. И ассемблерный листинг выдаёт, в котором видно, что программа делает именно то, что написано.
> > 
> > Компиляторы иногда имеют ошибки. Как и любые другие программы.
> 
> Только как так получается, что компилятор под OS/2, который я запускал вчера, имеет в точности те же "ошибки", что и совершенно _разные_ компиляторы под _разные_ ОС, с которыми мои друзья работали лет 10-15 назад?
> 
> >> Если компилятору недостаточно "int func(int x)", то откуда такая уверенность, что то же самое, написанное ещё раз, что-то изменит?
> >
> > Из стандарта. Если функция описана как имеющая параметр int, то указатель туда не пропустит компилятор.
> 
> Но ведь пропускает же. Разве что после его выхода стандарт поменялся.
> 
> >> Вот и я в прошлый раз говорил, что язык, зависящий от компилятора, это не язык уже, а семейство.
> > 
> > Язык от компилятора не зависит. Ошибки в реализации языка - да, зависят.
> 
> То есть язык, поддерживаемый, скажем, Watcom и язык, поддерживаемый VAC, друг от друга не отличаются? Тогда зачем в ваткомовских библиотеках торчат завязки в виде:
> #ifdef __IBMC__ (или __IBMCPP__)
> #else
> #endif
> ?
> А почему на одни и те же мои примеры ваши компиляторы ругались по разному (одни сообщали об ошибке, а другие - только предупреждение выдавали)? Как по мне - это говорит о самодеятельности их авторов, а не о стандарте.
> 
> >> Вот именно. И её, как главную часть, беречь надо, а не дуло этого же оружия к ней приставлять.
> > 
> > Если голова хочет это оружие к себе приставить - вольному воля.
> 
> Это если хочет. Но в данном случае мы имеем дело с конструкцией, в которой оно туда приставлено по умолчанию, а наличие предохранителя оставлено на усмотрение изготовителя.
> 
> > максимальный размер не ограничен, но использовать слишком длинные битфилды неудобно. Заимеешься имена битам давать.
> 
> А что, номера использовать нельзя? А какие операции с ними предусмотрены?
>  
> >>> В стандарте Паскаля не аналога для сишного interrupt.
> >> 
> >> (А, ты, говоря о Паскале, имеешь в виду стандарт. Я думал - что тот язык, который борландовские компиляторы используют. Ладно, запомним это на будущее.)
> > 
> > Если ты про interrupt в Turbo Pascal - да, есть такое.
> 
> Нет, я просто для себя уточнил, о каком языке ты говоришь.
> 
> > Но не портабельное. Ни дельфя, ни VP его не понимают. Бо слишком завязано на дос.
> 
> Если это ключевое слово языка, то на DOS оно завязано не более, чем это же самое слово в Си. Не так ли?
> 
> > Брр. Если процедура всегда сохраняет все регистры, то оно несколько неэффективно. Но в общем конечно тоже вариант.
> 
> Неэффективно, конечно. Но мы ведь ничего не знаем об особенностях абстрактного компилятора.
> 
> > А вот как шепнуть им, чтобы команду выхода правильную поставили?
> 
> А зачем? Из прерывания можно корректно вернуться и обычным RET-ом. Я, конечно, могу рассказать, как это сделать, но сначала сам попробуй догадаться.
> 
> > Дык вроде спич как раз об написании операционки?
> 
> Мне казалось, что здесь уже свернули на просто разговор о минимизации рисков при написании программ.
>  
> > слово interrupt предусмотрено. Насчет непрерываемого участка кода - уел. Нет такого. Слишком сие платформоспецифично.
> 
> Ничуть не более, чем указание, что процедура является обработчиком прерывания. Просто в язык добавляется ключевое слово noninterruptible. (Я ж говорил - Модулу придумывали специально для написания (многозадачной) операционной системы, поэтому там ещё и не такие приколы есть.)
>  
> >>> Описываешь calling convention для внешней функции и все.
> >>
> >> _Как_ описываешь? Ключевым словом pascal? А кто гарантирует, что тот паскалевский компилятор, который эту библиотеку породил, использует точно такой же способ передачи параметров в процедуры? Ведь способ передачи параметров стандартом языка не регламентируется. 
> >
> > Все виденные мной паскалевские компиляторы использовали один и тот же calling convention.
> 
> А сколько ты видел компиляторов Паскаля? Напоминаю - под Паскалем ты имеешь в виду стандартный Паскаль, а не его борландовского однофамильца со товарищи. Я, лично, для PC видел два - и у них были весьма отличающиеся способы передачи параметров и соглашения о том, какие регистры сохранять, а какие - нет.
> Кроме того, при вызове чужих процедур необходимо учитывать не только способ передачи параметров, но и способ представления в памяти переменных разных типов переменных - а он у разных компиляторов (и тем более языков) совпадать не обязан. Например, сколько слов pascal перед описанием функции не ставь, но у сишной строки, в неё передаваемой, счётчик длины не появится.
> Да, а само слово pascal в стандарте языка есть и подробно расписано? Или это просто имя некоего соглашения в рамках операционной системы, а уже ОС регламентирует, что и как оно делает?
> 
> > Среднестатистический программист, не знающий о внеязыковых соглашениях не напишет ничего, пригодного для использования другими людьми.
> 
> Позаглядывал в разные хранящиеся у меня сишные библиотеки (всякие там gettext-ncurses-zlib-...) - практически нигде никаких префиксов не наблюдается. VAC вспомнил да некогда весьма популярную борландовскую TurboVision - в них тоже ничего такого. А ведь всё это не среднестатистичекие программисты лепили.
>  
> > Я подумал, что он риторический :) Стандарт прямо и честно говорит, что результат такого действия не определен. Потому, что в зависит от процессора и компилятора.
> 
> Зависит - потому что стандарт это позволяет. Было бы в стандарте опредено чётко и однозначно - никакого разнобоя бы не было.
> 
> > Соответственно использующим такие конструкции прямая дорога к терапевту.
> 
> Не логичнее ли туда отправлять тех, кто такие стандарты придумывает?
> 
> > С другой стороны, сама по себе операция инкремента/декремента очень удобна и полезна. В частности - хорошо ложится на многие процессоры. 
> 
> Не спорю - конечно удобно и полезно. Просто в более других языках: операции эти же самые есть, а неоднозначности результата - нет.

_, _, _, _, _ _ _,_ (_ \| / \ \|\ \| \| \|_/ , ) \| , \ / \| \\| \| \| \ ~ ~~~ ~ ~ ~ ~ ~ ~