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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : LightElf
Subj : Может я не прав, но..
>> А у меня - компилируется. И ассемблерный листинг выдаёт, в котором видно, что программа делает именно то, что написано.
>
> Компиляторы иногда имеют ошибки. Как и любые другие программы.

Только как так получается, что компилятор под 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 - в них тоже ничего такого. А ведь всё это не среднестатистичекие программисты лепили.

> Я подумал, что он риторический :) Стандарт прямо и честно говорит, что результат такого действия не определен. Потому, что в зависит от процессора и компилятора.

Зависит - потому что стандарт это позволяет. Было бы в стандарте опредено чётко и однозначно - никакого разнобоя бы не было.

> Соответственно использующим такие конструкции прямая дорога к терапевту.

Не логичнее ли туда отправлять тех, кто такие стандарты придумывает?

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

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

Mon 16 Jul 2007 16:06 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.7.12) Gecko/2005



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.