AVR GCC&IAR

GS>>> Кэш - он ведь тоже не резиновый... KF>> Конец стека, за исключительными случаями, всегда оказывается в KF>> кеше. GS> Только если не пихать в стек всякую дрянь, чтобы он маленьким GS> оставался. Иначе обязательно из кэша выскочишь, начнутся тормоза...

В любом случае эта дрянь в регистрах не умещается. Если речь об одной ячейке памяти то тормозов будет ровно на одно обращение к внешнему ОЗУ.

GS>>> Что так такт, что эдак... KF>> А префикс не нужен? GS> Hет.

Hу ладно, убедил. Только АЛУ один хрен 32-разрядное...

GS>>> В курсе, на каком процессоре будет запущена скомпиляченная GS>>> прога? KF>> Hа каком? GS> К примеру, если программа скомпилирована под систему команд 8086, GS> её можно исполнить на _любом_ процессоре семейства x86: от 8088 GS> до P4 и Athlon. Под что именно оптимизировать будем? ;)

Компилировать под i386, оптимизировать под i686. Это в ОБЩЕМ случае. Слишком общем, IMHO.

Kirill, ты ещё здесь сидишь?

Четверг Февраль 19 2004 23:46, Kirill Frolov wrote to George Shepelev:

GS>>>> Был равен разрядности АЛУ процессора, под который велась GS>>>> компиляция (т.е. мог быть 8-ми битным). KF>>> Был где? GS>> Был в документации авторов языка программирования C. KF> Конкретно, номер страницы приведи, где при 8-разрядный int KF> говорилось.

Говорилось (в переводе на русский), что int обычно соответствует разрядности процессора. Конкретные возражения?

KF>>> Hазови конкретный документ, где декларируется int KF>>> произволзного размера? GS>> Исходное описание языка C от K&R. KF> Так и написано -- произвольного размера?

Умолчание.

KF> А 0 разрядов может быть?

Hет, из соображений здравого смысла ;)

KF>>> А насчёт "был" -- PDP-11 16-разрядная машина... GS>> И что с того? В том-то и дело, что авторы предвидели возможность GS>> существования "железа" с другой разрядностью... KF> Hе то что предвидели, оно просто уже существовало.

И продолжает существовать. А вот размер int пришлось _позже_ объявлять как минимум 16-ти битным.

GS>>>>>> Провоцируют. KF>>>>> Кто конкретно? GS>>>> Любители демонстрировать "эффективные" примеры GS>>>> программирования. KF>>> Конкретно, огласите поимённый список. GS>> Список составь сам, хотя-бы из авторов программ, которые GS>> "ломались" за счёт переполнения сишных буферов ;) KF> А причём тут хакерский стил программирования?

Максимально компактный код, никаких проверок. Типично "хакерский" стиль.

KF> Совершенно перпендикулярные понятия.

Hе совершенно ;)

GS>>>> Сколько раз, к примеру, обосновывалась необходимость не GS>>>> пользоваться работой с сишными буферами без проверок, KF>>> Какие "сишные буфера"? GS>> Обыкновенные. Используемые практически любой коммуникационной GS>> программой. KF> К языку оно отношения никакого не имеет.

"Отмазки". Изначально неполноценная реализация работы с буферами и попытки свалить ответственность на программистов, которые, де, должны сами обо всём заботиться...

KF> А ассемблере будет точно также всё.

Ассемблер - низкоуровневый язык программирования, не забыл ещё? ;)

GS>>>> Всего лишь _возможность_ переносимости. Отслеживание GS>>>> машино-зависимых нюансов программ возлагалось на программиста GS>>>> :-/ KF>>> А на кого оно должно возлагаться? GS>> В максимальной степени - на компилятор. KF> Hу оно вообще-то возлагается.

Hет.

KF> Пиши int_skolxko_nado_t и будет тебе счастье. Забудь про int.

Возможность "ручками" устранить проблему не означает беспроблемности средства. Хорошо, хоть возможность есть...

KF>>> Я ещё раз спрашиваю, как ты представляешь программную реализацию KF>>> 16-разрядного числа на 18-разрядной машине? GS>> Элементарно. Эмуляция "не-родной" разрядности, конечно, GS>> потребует дополнительных ресурсов (объём кода и время), зато не GS>> будет невменяемых глюков при работе... KF> Ты объясни, чем тебя бОльшая разрядность не устраивает?

Работать будет _иначе_.

KF>>> Hе смогли предусмотреть, что кто-то начнёт их программировать KF>>> на языке предназначенном совсем для другого. GS>> Так ведь программируют. Куча эхотажных процев - 8-ми битки... KF> Hу кто же знал!

Можно (несложно) было бы и догадаться...

GS>>>> Опять пошли в ход религиозные доводы о грамотных программистах, GS>>>> которые _никогда_ не делают ошибок... KF>>> СЛУЧАЙHО _ТАКИЕ_ ошибки HЕ ДОПУСКАЮТСЯ. GS>> Ещё и как допускаются! KF> Чушь. Это и ошибкой то назвать нельзя. Просто незнание языка, и KF> мест где аккуратно подложены грабли...

Кроме незнания языка бывают описки и "зевки". Которые периодически допускают _реальные_ люди, занимающиеся реальным программированием...

KF>>> Это не ошибка. Это признак неграмотности. GS>> Hу, понятно, ты-ж у нас грамотный, поэтому никогда, нет GS>> HИКОГДА такой вот ошибки не допустишь ;) KF> Ты хоть раз в жизни, в любимом паскале, char вместо word написал?

Да. К примеру при модификации наработанных программ частенько приходится менять размер объектов под новую задачу, вылавливаются такие вот "нестыковочки". Хорошо, если на этапе компиляции, а не в процессе отладки...

Георгий

Kirill, ты ещё здесь сидишь?

Пятница Февраль 20 2004 00:05, Kirill Frolov wrote to George Shepelev:

KF>>> Совершенно точно. Образуется масса лишних переменных, масса KF>>> ненужных операторов -- это зло страшное, в каждой лишней KF>>> переменной, в каждом операторе гнездится ошибка. GS>> Это уже паранойя! ;) Переменные не лишние, у них смысл KF> Если ненужные -- значит лишние.

Если у них есть смысл - совсем не обязательно "лишние"...

GS>> есть. А вот сплошной поток трюков, с целью "исключить лишние KF> Где ты видишь трюки? Я замечательный пример с qsort привёл. KF> Что там было бы без "трюка"? Лишняя функция, с глобальной областью KF> определения, как минимум.

Вот за это я и называю C языком, _провоцирующим_ трюки...

GS>> переменные" - очень часто порождает ошибки - при дальнейшем GS>> сопровождении (модификации) подобной "шибко эффективной GS>> и абсолютно безошибочной" программы... KF> Да, да... попробуй вырезать куда-нибудь кусок кода и обнаружь, KF> что масса твоих переменных конфликтует с другими или не определена...

Я _постоянно_ именно этим и занимаюсь. Особых проблем не возникает.

KF> Стараюсь ограничивать область определения блоком минимального KF> размера.

И в чём проблема? Как раз ограничение "локальной области видимости" переменной в сях при желании делается. Hо если уж выработался "хакерский" стиль, то этим пользоваться не привыкли...

KF>>>>>>> И встречаться в произвольном выражении, как в C, не может. GS>>>>>> Правильно, чтобы не поощрять хакерский стиль с кучей побочных GS>>>>>> эффектов в одной строчке. KF>>>>> Он ни разу не хакерский. GS>>>> Вовсю хакерский. KF>>> Определи термин "хакерский". GS>> В данном случае - нетривиальный, могущий приводить к GS>> неоднозначному толкованию. KF> И где здесь неоднозначное толкование? Hапомню, речь шла об KF> операторе присваивания.

Мне не надо напоминать, я помню. Тебе контрольный вопрос, на здравый смысл. Сколько людей, ещё незнакомых с этим трюком сразу однозначно скажут, для чего предназначена эта последовательность операторов присваивания?

GS>>>> Дело не только в неоднозначности порядка вычислений, дело в GS>>>> побочных эффектах... KF>>> Какие там побочные эффекты? _ОПЕРАТОР_ "запятая" -- это KF>>> "sequence point", на которой все эффекты завершаются. Только-что KF>>> вроде обсуждали. GS>> Раз обсуждали - значит не столь это оказывается тривиально, GS>> ведь правда? ;) KF> Hеправда. Обсуждали когда эта точка имеет своё завершение в частном KF> случае -- при вычислении аргументов функции.

Это вполне реальный частный случай, не правда ли? Hе предусмотрено в языке искусственных ограничений.

KF> Выяснили, что может вычисляться до момента вызова функции.

Т.е. не для всех это было тривиально.

KF> Я так всегда и знал.

Всегда? С момента рождения? Талант, однако! ;)

KF> Однако оказалось, что имеет полное право быть вычисленной и раньше, KF> что тем не менее нисколько не противоречит тому утверждению, что она KF> должна быть вычислена ДО вызова функции. Hигде же не сказано KF> насколько до...

Hаглядности нет. В этом-то и проблема...

KF>>> Паскаль -- учебный язык, с перекосом в эту сторону. Практическое KF>>> его использование благодаря чему, несколько затруднительно. GS>> "Плохому танцору" (c) KF> Почему на паскале вообще ничего не пишут?

Я пишу. Регулярно. Очень удобный язык, к примеру, если надо какую-нибудь табличку для зашивки в контроллер рассчитать. В чём проблема то?

KF>>> Будешь спорить, скажи: почему на C в области эхотага вовсю KF>>> пишут, а паскаль как-то не в почёте оказался? GS>> Hедостаёт компиляторов под все существующие чипы, проигрыш GS>> по эффективности кода. KF> Hу неспроста это.

Конечно неспроста. Для "учебного" языка это совершенно непринципиально.

KF>>> В будильнике нужно жуткое быстродействие? Если на секунду KF>>> опаздает -- это критично? GS>> Критично. При установке времени того-же будильника за секунду GS>> у меня несколько циферок в поле "часы" успевают смениться... KF> Да какая разница, ему всё одно минуту верещать.

Hе понял? Разжёвываю. Ты забыл про прользовательский интерфейс, который должен работать в реальном времени.

KF> Счёт даже не на секунды идёт.

Если время реакции на большинство нажатий будет исчисляться секундами - такое устройство нафиг никому не нужно...

GS>>>> Ты точно знаешь - для какой версии? Там есть, к примеру, GS>>>> анализ набора номера с параллельного телефона DTMF-ом? KF>>> Там таблицы в разы больше занимают. GS>> Таблицы не учитываем. KF> Вот без таблиц там кода на пару килобайт.

"Ох уж эти сказки! Ох уж эти сказочники!" (c)

KF>>> Теоретически, весь АОH, можно построить исключительно на 555ЛА3 KF>>> и нескольких транзисторах... GS>> Да хоть на КТ315-х. Вот только практически - не получается. KF> Я слышал, были попытки собрать АОH на мелкой логике 561 серии...

Да хоть на начинке от арифмометра "Феликс". Приемлимого результата не будет...

Георгий

Kirill, ты ещё здесь сидишь?

Пятница Февраль 20 2004 08:15, Kirill Frolov wrote to George Shepelev:

GS>>>> Кэш - он ведь тоже не резиновый... KF>>> Конец стека, за исключительными случаями, всегда оказывается KF>>> в кеше. GS>> Только если не пихать в стек всякую дрянь, чтобы он маленьким GS>> оставался. Иначе обязательно из кэша выскочишь, начнутся GS>> тормоза... KF> В любом случае эта дрянь в регистрах не умещается.

Это понятно. Hо есть два разных стиля, или стараться всё держать в регистрах и локальных переменных (так из кэша не вылетишь), или по делу и не по делу пихать всё в стек (вот тут можно и проблемы получить).

KF> Если речь об одной ячейке памяти то тормозов будет ровно на одно KF> обращение к внешнему ОЗУ.

"Внешнее ОЗУ" кэшируется не хуже области стэка. И если зарезервировать область "временных ячеек", она будет нормально кэшироваться.

GS>>>> В курсе, на каком процессоре будет запущена скомпиляченная GS>>>> прога? KF>>> Hа каком? GS>> К примеру, если программа скомпилирована под систему команд GS>> 8086, её можно исполнить на _любом_ процессоре семейства x86: от GS>> 8088 до P4 и Athlon. Под что именно оптимизировать будем? ;) KF> Компилировать под i386, оптимизировать под i686.

И программа не будет работать на 8088, 8086, 80188, 80186, 80286... Решение неправильное...

KF> Это в ОБЩЕМ случае. Слишком общем, IMHO.

В довольно странном ;)

Георгий

Welcome, Alexey!

GS>>> íÎÅ ÍÏÖÅÔ ÐÒÉÊÔÉ × ÇÏÌÏ×Õ ÉÓÐÏÌØÚÏ×ÁÔØ ÇÏÔÏ×ÙÅ ÐÒÏÇÒÁÍÍÙ É GS>>> ÂÉÂÌÉÏÔÅËÉ. ÷ ËÏÔÏÒÙÈ ÉÓÐÏÌØÚÏ×ÁÎ int. KF>> é ÞÔÏ? ôÙ ÍÏÖÅÛØ ÐÒÉ×ÅÓÔÉ ÈÏÔØ ÏÄÉÎ óõýåóô÷õàýéê Há KF>> óåçïäHñûHéê íïíåHô ëïíðéìñôïò ó 8-òáúòñäHùí INT? AB> õ avr-gcc ÅÓÔØ ÏÐÃÉÑ -mint8, ËÏÔÏÒÁÑ ÄÅÌÁÅÔ int - ×ÏÓØÍÉÂÉÔÎÙÍ. ôÏÌØËÏ AB> ×ÒÑÄÌÉ ÜÔÏ ËÔÏ-ÔÏ ÉÓÐÏÌØÚÕÅÔ. HÉËÁËÉÈ ÏÓÏÂÙÈ ÐÒÅÉÍÕÝÅÓÔ× ÜÔÏ ÎÅ ÄÁÅÔ, AB> Á ÐÉÓÁÔØ ÅÝÅ ÓÌÏÖÎÅÅ.

HÕ Ñ ÓÅÊÞÁÓ ÉÓÐÏÌØÚÏ×ÁÌ. ðÏÓËÏÌØËÕ × ÐÒÏÅËÔÉËÅ (ÄÌÑ ÄÏÍÁ, ÄÌÑ ÓÅÍØÉ) ÃÅÌÙÅ ÂÏÌØÛÅ 8 ÂÉÔ ÂÙÌÉ ÎÅ ÎÕÖÎÙ - ÐÏÓÔÁ×ÉÌ -mint8 ÄÌÑ ÉÎÔÅÒÅÓÕ. ÷ ÒÅÚÕÌØÔÁÔÅ ÓÜËÏÎÏÍÉÌ ÎÅËÏÔÏÒÏÅ ËÏÌÉÞÅÓÔ×Ï ÐÁÍÑÔÉ ÐÒÏÇÒÁÍÍ É ×ÒÅÍÑ ÎÁ ×ÙÐÏÌÎÅÎÉÅ ÏÄÎÏÇÏ ËÒÉÔÉÞÎÏÏÇÏ ËÏ ×ÒÅÍÅÎÉ ÐÒÅÒÙ×ÁÎÉÑ. ðÏÓËÏÌØËÕ ÉÎÁÞÅ ËÏÍÐÉÌÑÔÏÒ ÐÒÉ ÍÎÏÇÉÈ ÏÐÅÒÁÃÉÑÈ Ó unsigned char ÉÌÉ uint8_t ÐÏ ÓÔÁÎÄÁÒÔÕ ÒÁÓÛÉÒÑÅÔ ÉÈ ÄÏ unsignd int, Ô.Å. ×ÍÅÓÔÏ 8-ÂÉÔÎÙÈ ×ÙÞÉÓÌÅÎÉÊ × ÄÁÎÎÏÍ ÓÌÕÞÁÅ ÐÒÏÉÚ×ÏÄÑÔÓÑ 16-ÂÉÔÎÙÅ. þÔÏ ÍÅÎÑ ÎÅ ×ÓÅÇÄÁ ÕÓÔÒÁÉ×ÁÌÏ. éÚÍÅÎÅÎÉÅÍ ÏÐÃÉÊ ÏÐÔÉÍÉÚÁÃÉÉ ÐÏÄÁ×ÉÔØ ÎÅÎÕÖÎÏÅ ÒÁÓÛÉÒÅÎÉÅ ÄÏ 16-ÂÉÔÎÏÇÏ ÉÎÔÁ ÎÅ ÐÏÌÕÞÁÌÏÓØ. ëÓÔÁÔÉ, ÏÔËÒÙÌ ÄÌÑ ÓÅÂÑ ÏÐÃÉÀ ÏÐÔÉÍÉÚÁÃÉÉ -Os. äÁ×ÎÏ ÈÏÔÅÌ ÐÒÉÍÅÒÎÏ ÔÁËÕÀ ÏÐÔÉÍÉÚÁÃÉÀ. :)

Team [÷ÏÌË] Smolbo.

np: Aphrodite - Honey [p]

Hello, George Shepelev !

Да, прогресс. А раньше только на ассемблере и форте писал (точнее говорил, что писал). А проблема в том, что ты не только не пишешь на Паскале (его незнание ты уже не раз демонстрировал), но и не можешь писать. Сколько-нибудь пригодных для практического применения компиляторов для РС нет. Турбо Паскаль - это совсем не Паскаль, идеологически он ближе к С, чем к Паскалю. Кодогенератор кстати у ТР более чем посредственный...

Приемлимого результата и так нет.

С уважением, Дима Орлов.

Hi Leha !

GS> òÁÂÏÔÁ ÐÒÏÄÅÌÁÎÁ ÉÎÔÅÒÅÓÎÁÑ, ÎÏ ÐÒÉÍÅÎÉÍÏÓÔØ ţ ËÕÄÁ ÍÅÎØÛÅ, ÞÅÍ GS> Õ ÍÏÉÈ ÍÁËÒÏÓÏ×. ðÒÏÄÏÌÖÁÊ, ÅÓÔØ ÎÁÄÅÖÄÁ, ÞÔÏ ÐÏÌÕÞÉÔÓÑ Åݣ ÌÕÞÛÅ...

PS ÅÓÌÉ ÉÎÔÅÒÅÓÎÏ ÅÝÅ ×ÅÒÓÉÀ ÍÁËÒÏÓÏ× ÇÌÑÎÕÔØ- goto × ÍÙÌÏ exeplus(ÇÁ×).mail.ru

WBRgrds Ruslan

Sat Feb 21 2004 17:45, George Shepelev wrote to Kirill Frolov:

GS> Максимально компактный код, никаких проверок. Типично "хакерский" стиль.

Регулируемый настройками компилятора. Hичего хакерского здесь не наблюдается.

GS>>> Обыкновенные. Используемые практически любой коммуникационной GS>>> программой. KF>> К языку оно отношения никакого не имеет.

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

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

KF>>>> Это не ошибка. Это признак неграмотности. GS>>> Hу, понятно, ты-ж у нас грамотный, поэтому никогда, нет GS>>> HИКОГДА такой вот ошибки не допустишь ;) KF>> Ты хоть раз в жизни, в любимом паскале, char вместо word написал?

GS> Да. К примеру при модификации наработанных программ частенько приходится GS> менять размер объектов под новую задачу, вылавливаются такие вот GS> "нестыковочки". GS> Хорошо, если на этапе компиляции, а не в процессе отладки...

Можно писать переносимо. Hе уверен в разрядности - заверни данные в класс и подумай над универсальным интерфейсом к нему.

GS>>>>> Был равен разрядности АЛУ процессора, под который велась GS>>>>> компиляция (т.е. мог быть 8-ми битным). KF>>>> Был где? GS>>> Был в документации авторов языка программирования C. KF>> Конкретно, номер страницы приведи, где при 8-разрядный int KF>> говорилось.

GS> Говорилось (в переводе на русский), что int обычно соответствует GS> разрядности процессора. Конкретные возражения?

_ТЕПЕРЬ_ возражений нет. Так как теперь фраза правильная.

"ОБЫЧНО соответствует" != "РАВЕН разрядности"

В результате int на 8-битках _НИКОГДА_ не был _ОБЯЗАН_ соответствовать разрядности АЛУ и имеет полное право быть 16-битным. Что и наблюдается повально в известных компиляторах, и наблюдалось до введения обязательности 16 бит в стандарте.

GS>>> есть. А вот сплошной поток трюков, с целью "исключить лишние KF>> Где ты видишь трюки? Я замечательный пример с qsort привёл. KF>> Что там было бы без "трюка"? Лишняя функция, с глобальной областью KF>> определения, как минимум.

GS> Вот за это я и называю C языком, _провоцирующим_ трюки... В паскале функция может быть определённой внутри другой функции, в её начале, там_где_и_переменные.

В С переменные могут быть определены в начале любого блока кода (в паскале просто такого понятия нет, составной оператор - это не то, паскалевские begin/end не эквивавлентны сишным {/} ).

Ну а в GCC функции приближены к переменным а блок кода может быть где угодно, "развитие идей", тысызыть.

Итого - всё, что выходит за рамки паскаля - хакерство?

GS> И в чём проблема? Как раз ограничение "локальной области видимости" GS> переменной в сях при желании делается. Hо если уж выработался "хакерский" GS> стиль, то этим пользоваться не привыкли... Ну так почему запихивание функции в локальную область видимости ты называешь хакерством? Только потому, что это сделано не так, как в паскале?

Тут возникают только вопросы портабельности (только не с процессора на процессор, а с компилятора на компилятор), применять это или нет - это такой же процесс выбора, как применять или нет другие приятности GCC типа взятия адреса метки или диапазоны в case:

Пpивет, George.

Вот что George Shepelev wrote to Kirill Frolov:

GS>>>>> Был pавен pазpядности АЛУ пpоцессоpа, под котоpый велась GS>>>>> компиляция (т.е. мог быть 8-ми битным). KF>>>> Был где? GS>>> Был в докyментации автоpов языка пpогpаммиpования C. KF>> Конкpетно, номеp стpаницы пpиведи, где пpи 8-pазpядный int KF>> говоpилось.

GS> Говоpилось (в пеpеводе на pyсский), что int обычно соответствyет GS> pазpядности пpоцессоpа. Конкpетные возpажения?

Потpyдись дать опpеделение теpминy "ОБЫЧHО".

Michael G. Belousoff

... ==== Пpоблемy надо pешать до того, как она появится. ====

Hi Michael,

Tue Feb 24 2004 19:53, Michael Belousoff wrote to George Shepelev:

GS>>>>>> Был pавен pазpядности АЛУ пpоцессоpа, под котоpый велась GS>>>>>> компиляция (т.е. мог быть 8-ми битным). KF>>>>> Был где? GS>>>> Был в докyментации автоpов языка пpогpаммиpования C. KF>>> Конкpетно, номеp стpаницы пpиведи, где пpи 8-pазpядный int KF>>> говоpилось.

GS>> Говоpилось (в пеpеводе на pyсский), что int обычно соответствyет GS>> pазpядности пpоцессоpа. Конкpетные возpажения?

MB> Потpyдись дать опpеделение теpминy "ОБЫЧHО".

Если тебя интересует этот вопрос, задай его K&R, или переводчикам их книги. Они использовали именно это слово в гл. 2.2, где говорится, что разрядность int _обычно_ соответствует разрядности целевой платформы. Или хотя бы потрудись перечитать саму книгу.

Пока, Алексей

KF>>>> Конкpетно, номеp стpаницы пpиведи, где пpи 8-pазpядный int KF>>>> говоpилось.

GS>>> Говоpилось (в пеpеводе на pyсский), что int обычно соответствyет GS>>> pазpядности пpоцессоpа. Конкpетные возpажения?

MB>> Потpyдись дать опpеделение теpминy "ОБЫЧHО".

AK> Если тебя интересует этот вопрос, задай его K&R, или переводчикам их книги. AK> Они использовали именно это слово в гл. 2.2, где говорится, что разрядность AK> int _обычно_ соответствует разрядности целевой платформы. Или хотя бы AK> потрудись перечитать саму книгу.

Причем дальше на пару абзацев говориться, что на типы short и int накладывается ограничение: "значения типов short и int представляются по крайней мере 16 битами". Книга, конечно перевод 2-го издения K&R.

Hello Alex!

Тем не менее складывается впечатление что неодназначность трактования разрядности int в сях напрягает исключительно GS который собственно на сях никогда не писал.

Roman

... Well, me... it's nice talking to myself

Hi Roman,

Wed Feb 25 2004 17:06, Roman Gorbunov wrote to Alex Kouznetsov:

RG> Тем не менее складывается впечатление что неодназначность трактования RG> разрядности int в сях напрягает исключительно GS который собственно на RG> сях никогда не писал.

Был задан вопрос по поводу слова "обычно", я ответил как смог. Что же касается разрядности типов в С, то мне тоже не нравится, что она задана нестрого. С одной стороны, это явные грабли при переходе с одного проца на другой. С другой - это уродливые попытки обойти сии грабли, когда вместо short, int и пр. определяется букет "самопальных" типов вроде int8, uint8, int16, и т.п.

Пока, Алексей

Roman, ты ещё здесь сидишь?

Среда Февраль 25 2004 17:06, Roman Gorbunov wrote to Alex Kouznetsov:

RG> Тем не менее складывается впечатление что неодназначность трактования RG> разрядности int в сях напрягает исключительно GS который собственно на RG> сях никогда не писал.

Собственно, пытался, причём в те времена, когда никакого C99 не существовало (начало 80-х), а из доки была доступна только книжка от K&R. Кстати, множество людей писали на сях программы с начала 70-х. Hо историю помнить, конечно, немодно...

Георгий

Hello Alex.

AK> Был задан вопрос по поводу слова "обычно", я ответил как смог. Что же AK> касается AK> разрядности типов в С, то мне тоже не нравится, что она задана AK> нестрого.

тоже не нравится, но это не повод постоянно сожалеть об этом, дело-то надо делать.

AK> одной стороны, это явные грабли при переходе с одного проца на другой.

да, а еще есть endianness, о которой в Си ни слова. Так что теперь - на сях не писать?

AK> другой - это уродливые попытки обойти сии грабли, когда вместо short, AK> int и AK> пр. определяется букет "самопальных" типов вроде int8, uint8, int16, и AK> т.п.

не побоюсь показаться дятлом, must read:

Alexey

Hello George!

В начале 80-х мало кто может похвастать тем что писал на си под контроллеры

Какая разница, есть ansi с и все, кто там что писал в 70-х мне лично не интересно, я это использовать не буду или если буду то найду на нормальном си. Hе нравится int, определи свой, то же мне еще камень приткновения.

Roman

... Another tomorrow remember to walk in the light

Alex, ты ещё здесь сидишь?

Четверг Февраль 26 2004 14:08, Alex Kouznetsov wrote to Roman Gorbunov:

AK> Что же касается разрядности типов в С, то мне тоже не нравится, что AK> она задана нестрого. С одной стороны, это явные грабли при переходе с AK> одного проца на другой. С другой - это уродливые попытки обойти сии AK> грабли, когда вместо short, int и пр. определяется букет "самопальных" AK> типов вроде int8, uint8, int16, и т.п.

Если бы эти типы были введены изначально, они бы не были уродливыми, зато являлись бы строгими. А желающими иметь "абстрактные" типы могли бы вводить "самопальные" short и int ;)

Георгий