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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : LightElf
Subj : Может я не прав, но..
>> -------------
>> main()
>> {
>> int i;
>> int *p;
>> i = func(*p);
>> }
>>
>> int func(int x)
>> {
>> return x+1;
>> }
>> -------------
>
> сообщает об отсутствии прототипа функции.

У меня не сообщает. Ну да не важно.

>> и вот эта программка компилируется тоже без ошибок и предупреждений:
>> -------------
>> main()
>> {
>> int i;
>> int *p;
>> i = func(p);
>> }
>>
>> int func(int x)
>> {
>> return x+1;
>> }
>> -------------
>
> Не компилируется. Ошибка типизации. Указатель вместо int.

А у меня - компилируется. И ассемблерный листинг выдаёт, в котором видно, что программа делает именно то, что написано.

> Объясни друзьям, что функции нужно описывать. Это несложно.

Если компилятору недостаточно "int func(int x)", то откуда такая уверенность, что то же самое, написанное ещё раз, что-то изменит?
Нет, если инструмент допускает такое, то его место - где-то в дальнем углу.
(Кстати, в стандарте языка написано, что указатель не совместим с целым по присваиванию? А по подстановке параметров?)

>> - ни те ошибок при компиляции, ни хотя бы предупреждений. Потому как в полном соответствии с правилами языка. Хотя ни одного кастинга по-прежнему нет.
>
> Зависит от компилятора. CodeWarrior сообщает о возможной потере точности. OW 1.7 вроде как тоже правили на эту тему - надо будет посмотреть.

Вот и я в прошлый раз говорил, что язык, зависящий от компилятора, это не язык уже, а семейство.

>> "А мне пофиг, с какой стороны у тебя козырёк!" Если при пользовании средством можно столкнуться с проблемами, то я предпочту другое средство - с которым проблем нет. Мы ведь о надёжности говорим, а не о том, что можно "в принципе".
>
> "Главная часть любого оружия - голова его владельца".

Вот именно. И её, как главную часть, беречь надо, а не дуло этого же оружия к ней приставлять.

> Используй сишные битфилды. Очень удобно и код хороший получается.

Максимальный размер их? А почему я ни разу не видел их ни в чьих в исходниках? Народ удобств не хочет? Или тоже компиляторо-специфичное изобретение?

>> Не понял - а в чём проблема? Чем оно сложнее, чем аналогичный обработчик на Паскале или любом другом компилируемом языке.
>
> В стандарте Паскаля не аналога для сишного interrupt.

(А, ты, говоря о Паскале, имеешь в виду стандарт. Я думал - что тот язык, который борландовские компиляторы используют. Ладно, запомним это на будущее.)
А с чего ты решил, что этот аналог там нужен (в Модуле, например, без него прекрасно обходятся)? Если процедура, порождаемая компилятором, на выходе оставляет неизменными все регистры кроме тех, в которых возвращается результат, то interrupt становится не нужным (обработчик ведь результата не возвращает). Если же типовая процедура какие-то регистры гробит, то что мещает на входе в обработчик вызвать процедуру SaveState, а на выходе - RestoreState?
Ну, а если мы имеем дело с многозадачной ОС, то тут вообще задача сохранения и восстановления контекста решается самой операционкой.
Кстати, а в стандарте Си слово interrupt предусмотрено? А как на Си решить обратную задачу - написать участок кода, который прерывать нельзя? Так, чтобы оно гарантированно скомпилировалось любым компилятором.

>>> Как к фортрановской проге прикрутить паскалевскую библиотеку?
>>
>> А к сишной как?
>
> Описываешь calling convention для внешней функции и все.

_Как_ описываешь? Ключевым словом pascal? А кто гарантирует, что тот паскалевский компилятор, который эту библиотеку породил, использует точно такой же способ передачи параметров в процедуры? Ведь способ передачи параметров стандартом языка не регламентируется. В Си тоже, насколько я понимаю.

>> Этого ещё не хватало! Зачем уродовать неплохой, в принципе, язык? Функции с переменным числом параметров - один из важнейших элементов _ненадёжности_.
>
> Не иначе именно поэтому в том же самом стандарте Паскаля такие функции есть. Такой вот ненадежный стандарт.

Нет их там. Есть несколько операторов языка. А операторы - совсем не то же самое, что самодельные процедуры.

>> Но это всего лишь практика. Языком оно не навязывается.
>
> Если ты любишь, когда тебе чего-то навязывают - то оно конечно.

Но в данном случае навязывают именно тебе - правила раздачи имён функциям в библиотеках, при несоблюдении которых огребаешь проблемы (да и соблюдение не гарантирует - потому что соблюдать их должны все, а не только ты). А у меня в этом месте - полная свобода. Язык гарантирует.

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

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

>> Чему равно у после "y = ++x - ++x;" (скобки расставить по вкусу)?
>> Это пример из моих студенческих лет. Сейчас бы я спросил: что вернет mult(++x, --x), если функция mult() возвращает произведение своих аргументов? И чему будет равна переменная x после этого?
>
> Ну и кто тебе доктор, если ты такой код пишешь?

Ты на вопрос не ответил.

> Ты в сорцы lxlite посмотри. Прямо-таки образцовый пример абсолютно ублюдочного кода на паскале.

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

Mon 16 Jul 2007 12:34 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.