5-Feb-04 18:23 George Shepelev wrote to Oleksandr Redchuk:
GS>>> Вот только старые компиляторы об этом не знают, OR>> А где их взять-то? OR>> AVOCET C51 95 года вполне всё знает.
GS> Сколько unix-овских исходников написаны для компиляторов, поддерживающих GS> стандарт 72-го года? И, в отличие от многих ламерских поделок, unix-подобными GS> операционками продолжают пользоваться, а в них задействована часть кода, GS> пришедшая ещё из тех, далёких, 70-х годов прошлого века... GS> Помедитируй над этим... Посмотри _новый_ софт, который для этих операционок дописывается. И помедитируй над ним.
GS>>> Когда берётся исходник, в котором утверждается, что GS>>> он написан на си, подразумевается соответствие первоначальному GS>>> стандарту, OR>> А почему при разговоре о паскале ты вдруг TP вспомнил - ведь OR>> в нём сполшные улучшения по сравнению с "первоначальным стандартом"?
GS> Тебе известна другая общедоступная стандартная реализация Паскаля для GS> PC? Кто тебе сказал, что она _стандартная_? Самая распространённая, да. Причём именно на PC. На паскале я писал немного для 8-битки на Z80, поэтому PC-шными просто не интересовался. Поэтому Top Speed себе не ставил, а когда мимо пробегал Stone Brook (могу ошибиться в написании), то даже не возникло желания её себе оставить. Позже можно было найти VP.
Понятие "общедоступная" очень растяжимо, так как под лежачий камень вода не течёт. Можно сидеть, нифига не делать и плакать про "недоступность".
GS>>> а не неизвестно каким дальшейшим "улучшениям и дополнениям"... OR>> Как только у меня появилсяь возможность пользоваться нормальными OR>> прототипами функций вместо
GS> Есть тексты, написанные для "старого" компилятора. Hа "новом" могут GS> компилироваться неправильно. _ТЫ_ пробовал? Я свои исходники под K&R с ДВК, с RT-11 - компилировал на "Нейроне" при помощи TurboC 2.0. Всё работало сразу. Думаю, они бы и gcc в 32-битном режиме компилировались. Да, ты сказал "могут", а не "будут". Ну так и на TP для DOS16 можно было бы так написать, что в 32-битном режиме оно бы уже и не работало бы правильно. Всё зависит от программиста.
GS> Программами, скомпилёнными по этим текстам, GS> активно пользуются. И приходится искать ошибки, добавлять "фичи"... Ты так говоришь, будто с утра до вечер аэтим занимаешься.
OR>>>> Так что или признай, что ты трепло, GS>>> Признаю, что ты хамишь. OR>> По концентрации - ничуть не больше, чем ты трепешься. По суммарному OR>> объёму -- гораздо меньше.
GS> Иметь свою точку зрения и высказывать её - не возбраняется. Хамить GS> в приличном обществе не принято и противоречит положениям правил этой GS> сети. Вот моя точка зрения - ты трепешься. Ни матом, ни не нравящимися тебе личноименами я тебя не покрывал. Всё зависит от общества. Каждое "приличное общество" именно себя считает приличным. Один из вариантов - хамством считается уверенный трёп на темы, в которых плавваешь, а _не_ сказать об этом в лицо "трёп" считается признаком малодушия.
OR>>>> ни разу не видевшее стандарта на C, GS>>> Я изучал си (уже довольно давно) по стандарту от _авторов_ этого GS>>> языка. OR>> От авторов стандарта не было.
GS> Был. Подробная толстая книжка. Пожалуйста, год и номер _стандарта_. От тех же авторов была и ещё одна книга, где они старый свой текст полностью переработали в соответствии со стандартом.
GS> И этот стандарт был реализован в компиляторе, GS> на котором создавался unix. Человечество было "создано" в пещерах, при питании корнями и сырым мясом. Надо бы вернуться к "первоначальному стандарту".
GS> В введении в качестве стандарта типов с "абстрактной" размерностью. GS> Что, якобы, повышало эффективность. Это действительно её повышает.
OR>> В исходной концепции есть typedef для заведения своих типов. OR>> Я этим пользуюсь. "Что я делаю не так"?
GS> "Hе так" то, что этим не обязаны пользоваться. И многие - не пользуются. ССЗБ. "многие" (и даже "все") для меня не было аргументом даже в первом классе. И женщина, ведущая продлёнку, на следующий день была удивлена, когда оказалось, что это весь остальной класс неправильно решил задачу.
OR>>>> И что это возможно не только в Аде, но и в С. И если раньше в C с OR>>>> этим делом было "кто в лес, кто по дрова" с опорной точкой в виде OR>>>> limits.h, то сейчас вещи типа int16_t, int_least16_t и OR>>>> int_fast16_t должны сидеть в stdint.h. И только облом мне мешает GS> ^^^^^^^^^^^^^^^^^^^^^^^^^ GS>>> Так кто из нас "нормальный"? У меня всё строго определяется, GS>>> ты по-прежнему надеешься "на авось". OR>> Где ты видишь "авось"?
GS> Выше подчёркнуто. Нужные _мне_ часто используемые типы у меня _строго_определяются_ в моём файле compatib.h, который существует отдельно для AVR (iar C и gcc, тут они совместимы) Keil C51 (раньше AVOCET C51) и для BorlandC/win32. Используемые в одном проекте - сидят в его основном .h Эти файлы "живут", в них добавляются при необходимости новые типы. Облом заключается в том, что я их не переименовываю в stdint.h и не добавляю сразу все, описанные в стандарте, типы. До тех пор, пока они не понадобятся.
OR>> Почитай письмо Овсиенко о его опыте переноса прошивки со 186-го OR>> процессора (больше 100K прошивка) на мегу128. С-шная часть (всё, OR>> кроме низкоуровневого IO) заработала за 1 день.
GS> Почему бы и нет? Иногда может и повезти. А иногда придётся до-олго Почему когда что-то выходит у тебя - это результат глубины мысли, а у кого-то другого - элемент везения?
OR>> 2) про int изначально никто не обещал одинаковости размера
GS> Это и есть изначальный дефект концепции, о котором я в который раз GS> говорил. GS> Hа что находится только один аргумент, мол, можно им не пользоваться. GS> Можно, GS> но зачем создавать базовые концепции, которыми лучше бы не пользоваться?.. Мождно им не пользоваться, ЕСЛИ ОН НЕ УСТРАИВАЕТ. В подавляющем большинстве случаев он устраивает.
OR>> Одни и те же (_физически_) исходники avreal компилируются bcc OR>> для DOS/16бит, bcc32 для win32 и gcc для линукса. OR>> "Что я делаю не так"?
GS> Исходник хороший. Повезло тебе. Ну вот. опять "повезло" :-) Для тебя настолько мучительна мысль, что я мог думать прежде чем писать?
OR>> Hикакой самый лучший компилятор не даст человеку не сделать глупость.
GS> Hо он может на вопиющую глупость выдать ошибку. Чтобы человек внимательнее GS> подумал... if ( requested_buffer_size >= available_buffer_size ) { CopyDataToBuffer(); }
Какой компилятор какого языка выловит элементарную описку >= вместо <=
GS> "Используй то, что под рукою, и не ищи себе другое" (c) :-) Так вот как раз сейчас под рукою нормальные C-компиляторы, а поддерживающие только K&R надо ещё поискать.
OR>> Помнится мне, что года так с 94-95-го в mpasm-е уже точно можно было OR>> писать movf F,w и movf F,f, и даже movfw F и tstf F.
GS> Для меня это нисколько не повышает наглядность. Тю. То, что w значит W а f значит FILE это не более наглядно, чем ,0 ,1 ?
OR>> Так что ,0 ,1 можно было писать только из приверженности "самым OR>> ранним стандартам".
GS> Да, делалось на основе раннего стандарта, для максимальной совместимости. GS> Какие будут возражения? Возражений быть не может, твоё право. Если твой код был специально рассчитан под глюки старого компилятора и тебе надо было продолжать им пользоваться - всегда пожалуйста. Но смысла писать новый код в старом стиле я не вижу.
OR>> А просто объединить decfsz с goto -- было бы чем хвастаться. OR>> Это не более, чем костыли под систему команд.
GS> Да. А тебя не удивляет, что костыли выпускаются и пользуются GS> постоянным спросом? Только никто не хвастается, что ими пользуются. Наоборот - иногда ими пользуются исключительно для того, чтобы вызвать жалость и выпросить больше милостыни.