LPC2xxx - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
LPC2xxx
Fri Nov 11 2005 20:47, Evgeny Kotsuba wrote to Yuriy K:

 EK>>>   if( pbb->c )

 YK>> Отправлять таких программистов улицы подметать, ибо для большее сложных
 YK>> работ они все равно не пригодны...

 EK> И  так тогда что делать с ордами дворников из MS, IBM и Intel ?
 EK> ;-)

Зачем _тебе_ с ними что-то делать? _Ты_ менеджер в MS, IBM or Intel? :-)))

А своих программистов я приучил писать U8, U16 and U32.
Кстати, они и не сопротивлялись. :-)

WBR, Yuriy.


LPC2xxx
Привет, Yuriy !


 11 Nov 05 , 23:12  Yuriy K писал к Evgeny Kotsuba:

YK> А своих программистов я приучил писать U8, U16 and U32.
YK> Кстати, они и не сопротивлялись. :-)

Да хоть uint32_t. если это ввести как стандарт и если все это будут делать
одностандартно - то нэт проблем.

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... юркие е-стеренки и i-стероиды

LPC2xxx
Sat Nov 12 2005 00:07, Nickita A Startcev wrote to Yuriy K:


 YK>> А своих программистов я приучил писать U8, U16 and U32.

 Слишком громко. У нас принято u8/s8 и пр.

 NAS> Да хоть uint32_t.

 Отвратительно. Кто мог такое придумать?

 Hа самом деле хорошо бы было ввести в стандарт обязательное требование
 поддержки компилером общепринятых 8-16-32-64-битных типов независимо
 от их наличия на данной платформе. Прямое отображение машинных типов
 на типы переменных языка - пережиток ассемблера.

 VLV

 "Зачем стадам дары свободы? Их надо резать или стричь"  (Пушкин)


LPC2xxx
Sat Nov 12 2005 01:59, Vladimir Vassilevsky wrote to Nickita A Startcev:

 VV>  Hа самом деле хорошо бы было ввести в стандарт обязательное требование
 VV>  поддержки компилером общепринятых 8-16-32-64-битных типов независимо
 VV>  от их наличия на данной платформе. Прямое отображение машинных типов
 VV>  на типы переменных языка - пережиток ассемблера.

Вроде же в с99 такая попытка сделана

wbr, Andy (2:5080/76.6)


LPC2xxx
Sat Nov 12 2005 09:57, Andy Mozzhevilov wrote to Vladimir Vassilevsky:

 
 VV>>  Hа самом деле хорошо бы было ввести в стандарт обязательное требование
 VV>>  поддержки компилером общепринятых 8-16-32-64-битных типов независимо
 VV>>  от их наличия на данной платформе. Прямое отображение машинных типов
 VV>>  на типы переменных языка - пережиток ассемблера.

 AM> Вроде же в с99 такая попытка сделана

 Там сделано с точностью до наоборот: все эти uint8_t и прочее определены
 как typedefы через стандартные типы.

 VLV

 "При хорошей амуниции наплевать на конституции"  (Козьма Прутков)


LPC2xxx
Hello Vladimir.

Sun Nov 13 2005 02:28, Vladimir Vassilevsky wrote to Andy Mozzhevilov:

 AM>> Вроде же в с99 такая попытка сделана

 VV>  Там сделано с точностью до наоборот: все эти uint8_t и прочее определены
 VV>  как typedefы через стандартные типы.

А какая разница?  Главное, чтоб обозначение соответствовало содержанию. :)


Dimmy.


LPC2xxx
Привет, Vladimir !


 12 Nov 05 , 02:59  Vladimir Vassilevsky писал к Nickita A Startcev:

YK>>> А своих программистов я приучил писать U8, U16 and U32.
VV>  Слишком громко. У нас принято u8/s8 и пр.
NAS>> Да хоть uint32_t.
VV>  Отвратительно. Кто мог такое придумать?

#include <stdtypes.h>, если не ошибаюсь.

VV>  Hа самом деле хорошо бы было ввести в стандарт обязательное
VV> требование поддержки компилером общепринятых 8-16-32-64-битных типов
VV> независимо от их наличия на данной платформе. Прямое отображение
VV> машинных типов на типы переменных языка - пережиток ассемблера.

ну, соответствующий платформе инклюдник вроде бы у всех компиляторов в
комплекте есть. или не?

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... Didn't I meet You in some other halluci-nation?

LPC2xxx
Sat Nov 12 2005 20:36, Nickita A Startcev wrote to Vladimir Vassilevsky:

 
 NAS>>> Да хоть uint32_t.
 VV>>  Отвратительно. Кто мог такое придумать?
 NAS> #include <stdtypes.h>, если не ошибаюсь.

 Hу уродство же.

 VV>>  Hа самом деле хорошо бы было ввести в стандарт обязательное
 VV>> требование поддержки компилером общепринятых 8-16-32-64-битных типов
 VV>> независимо от их наличия на данной платформе. Прямое отображение
 VV>> машинных типов на типы переменных языка - пережиток ассемблера.
 NAS> ну, соответствующий платформе инклюдник вроде бы у всех компиляторов в
 NAS> комплекте есть. или не?

 То, что есть - это по#$бка. Загляни в <stdtypes> и увидишь там
 нечто вроде typedef unsigned int uint32_t. В том-то и дело, что
 основные типы char, int и пр. - машинные. И все через них определено.

 VLV

 "При хорошей амуниции наплевать на конституции"  (Козьма Прутков)


LPC2xxx
Привет, Vladimir !


 13 Nov 05 , 02:26  Vladimir Vassilevsky писал к Nickita A Startcev:

NAS>>>> Да хоть uint32_t.
VV>>>  Отвратительно. Кто мог такое придумать?
NAS>> #include <stdtypes.h>, если не ошибаюсь.

VV>  Hу уродство же.

VV>  То, что есть - это по#$бка. Загляни в <stdtypes> и увидишь там
VV>  нечто вроде typedef unsigned int uint32_t. В том-то и дело, что
VV>  основные типы char, int и пр. - машинные. И все через них определено.

я в курсе. А снаружи - очень прилично выглядело.

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... GLint wine

LPC2xxx
Sun, 13 Nov 2005 02:26:35 +0300 Vladimir Vassilevsky wrote to Nickita A
Startcev:

VV>  То, что есть - это по#$бка. Загляни в <stdtypes> и увидишь там
VV>  нечто вроде typedef unsigned int uint32_t. В том-то и дело, что
VV>  основные типы char, int и пр. - машинные. И все через них определено.

    Что тебе так не нравится? Для тебя (для пользователя) тип uint32_t - имеет
совершенно однозначный смысл. Как он там внутри сделано - это внутренне дело
реализации. Возможно, в другой реализации (или в следующей версии этой) тип
uint32_t будет прямо встроенным. От этого ничего не меняется ни в коде, ни в
результате его работы.

--
H.Z.





Re: LPC2xxx

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


Понедельник Hоябрь 14 2005 19:03, Vladimir Vassilevsky wrote to Harry Zhurov:

 HZ>> Для тебя (для пользователя) тип uint32_t -
 HZ>> имеет совершенно однозначный смысл.
 VV>  Hет, неоднозначный.
 VV>  Пример: TMS55xx.
 VV>  typedef char uint_8t;
 VV>  Притом что на самом деле char там 16-битный.
 VV>  В результате куча программ, неявно подразумевающих восьмибитность
 VV>  для типа uint_8t,  не работают.

 Руки за такую реализацию "восьмибитного" типа отрывать :-/


                                                   Георгий


Re: LPC2xxx
Mon Nov 14 2005 18:03, Vladimir Vassilevsky wrote to Harry Zhurov:


 VV> Mon Nov 14 2005 08:08, Harry Zhurov wrote to Vladimir Vassilevsky:

 VV>  

 VV>>>  То, что есть - это по#$бка. Загляни в <stdtypes> и увидишь там
 VV>>>  нечто вроде typedef unsigned int uint32_t. В том-то и дело, что
 VV>>>  основные типы char, int и пр. - машинные. И все через них определено.

 HZ>> Что тебе так не нравится?

 VV>  Мне не нравится что наличие 8/16/32/64 битных типов вообще
 VV>  не гарантировано на уровне языка.

 HZ>> Для тебя (для пользователя) тип uint32_t -
 HZ>> имеет совершенно однозначный смысл.

 VV>  Hет, неоднозначный.

 VV>  Пример: TMS55xx.

 VV>  typedef char uint_8t;

 VV>  Притом что на самом деле char там 16-битный.
 VV>  В результате куча программ, неявно подразумевающих восьмибитность
 VV>  для типа uint_8t,  не работают.
 VV>  

а вот нефиг неявно подразумевать.  За это надо отстреливать, что под TMS, что
под PC.

SY,
EK


LPC2xxx
Mon Nov 14 2005 21:42, Evgeny Kotsuba wrote to Vladimir Vassilevsky:

 
 VV>>  В результате куча программ, неявно подразумевающих восьмибитность
 VV>>  для типа uint_8t,  не работают.
 
 EK> а вот нефиг неявно подразумевать.

 Hа кой тогда вообще нужен тип uint_8t, если всегда нужно помнить,
 что он может быть не восьмибитным?

 EK> За это надо отстреливать, что под TMS,
 EK> что под PC.

 Застрелись.
 Ибо мне не верится, что в своих программах ты не где-то не заложился
 на размеры типов.

 VLV

 "При хорошей амуниции наплевать на конституции"  (Козьма Прутков)


LPC2xxx
Hi Vladimir, hope you are having a nice day!


14 Hоя 05, Vladimir Vassilevsky wrote to Evgeny Kotsuba:

 VV>>> восьмибитность  для типа uint_8t,  не работают.
 EK>> а вот нефиг неявно подразумевать.

 VV>  Hа кой тогда вообще нужен тип uint_8t, если всегда нужно помнить,
 VV>  что он может быть не восьмибитным?

IMHO, баг в реализации. Если тип заданной ширины не поддерживается
компилятором, то в stdint.h _его не должно быть
объявлено_. Компилятор должен выдать ошибку с сообщением о неизвестном типе
(или просто синтаксическо ошибке) и
прервать компиляцию.

WBR,
    AVB


LPC2xxx
Привет, Evgeny !


 14 Nov 05 , 22:42  Evgeny Kotsuba писал к Vladimir Vassilevsky:

VV>>  В результате куча программ, неявно подразумевающих
VV>> восьмибитность  для типа uint_8t,  не работают.

EK> а вот нефиг неявно подразумевать.  За это надо отстреливать, что под
EK> TMS, что под PC.

Что нефиг? А разве (u)int8_t не для того, чтоб _знать_, что это _ровно_ восемь
бит?

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... умножаться делением

LPC2xxx
Fri Nov 11 2005 18:01, Evgeny Kotsuba wrote to Andy Mozzhevilov:

 EK>>> фига,
 EK>>> представить структуру в виде линейного буфера из байтов можно и без
 EK>>> union'а,

 AM>> как?

 EK> struct blabla0
 EK> {  char bla[1];
 EK> };

 EK> struct blabla
 EK> {  char a[11];
 EK>    blabla0 b;
 EK>    short int c;
 EK>    char d[3];
 EK>    long int e;
 EK>    char buf[1];
 EK> };

 EK> struct blabla  bb;

 EK> *(((char *)&bb)+i) = ...

Hу можно, но чем это принципиально отличается юниона?
сделано все руками, да и только.

 EK>>> Кстати да - неиспользование #pagma pack или аналогов или неявное
 EK>>> использование - это 100% повторяемый глюк при портировании.

 AM>> о чем и спич

 EK> дык пользуй #pagma pack  явно и будет тебе щастье

использовать или нет, вопрос не в этом.
#pragma pack не обязан поддерживаться в рамках ANSI C, это
накладывает ограничение на переносимость. Поэтому если нужен переносимый
код, нужно разбирать линейный буфер явно, побайтно. Если хочется
оптимальности, то можно пользовать конкретные фишки конкретного
компилятора для конкретной платформы с конкретным размером
слова и конкретными индейцами. Можно достичь большей оптимальности,
положив на переносимость. Оба подхода имеют право быть в зависимость от
того, какая цель преследуется.

wbr, Andy (2:5080/76.6)


LPC2xxx
Fri Nov 11 2005 19:28, Andy Mozzhevilov wrote to Evgeny Kotsuba:

 AM>>> о чем и спич

 EK>> дык пользуй #pagma pack  явно и будет тебе щастье

 AM> использовать или нет, вопрос не в этом.
 AM> #pragma pack не обязан поддерживаться в рамках ANSI C, это
 AM> накладывает ограничение на переносимость. Поэтому если нужен переносимый
 AM> код, нужно разбирать линейный буфер явно, побайтно. Если хочется
 AM> оптимальности, то можно пользовать конкретные фишки конкретного
 AM> компилятора для конкретной платформы с конкретным размером
 AM> слова и конкретными индейцами. Можно достичь большей оптимальности,
 AM> положив на переносимость. Оба подхода имеют право быть в зависимость от
 AM> того, какая цель преследуется.

ну не знаю - в писикизмах/униксизмах, где я несколько лучше ориентируюсь,
вроде бы #pagma pack везде совершенно спокойно используется, и до " нужно
разбирать линейный буфер явно, побайтно" дело не доходит.  

Может быть, лучше написать/потребовать/вставить авторам компилятора, чтоб они
делали как все нормальные люди, вместо того, чтоб так уродоваться ?


SY,
EK


LPC2xxx
Fri Nov 11 2005 20:54, Evgeny Kotsuba wrote to Andy Mozzhevilov:

 EK> ну не знаю - в писикизмах/униксизмах, где я несколько лучше ориентируюсь,

 EK> вроде бы #pagma pack везде совершенно спокойно используется, и до " нужно
 EK> разбирать линейный буфер явно, побайтно" дело не доходит.  

Когда дело касается кроссплатформенности, логично закладываться на описанные
в стандарте средства языка.

 EK> Может быть, лучше написать/потребовать/вставить авторам компилятора, чтоб
 EK> они делали как все нормальные люди, вместо того, чтоб так уродоваться ?

Да, и до кучи чтобы в стандарте реализовали типы
uint16_be, uint16_le и т.п., чтобы не уродоваться с большими и маленькими
индейцами.

wbr, Andy (2:5080/76.6)


LPC2xxx
Sat Nov 12 2005 09:55, Andy Mozzhevilov wrote to Evgeny Kotsuba:


 AM> Fri Nov 11 2005 20:54, Evgeny Kotsuba wrote to Andy Mozzhevilov:

 EK>> ну не знаю - в писикизмах/униксизмах, где я несколько лучше
 EK>> ориентируюсь,

 EK>> вроде бы #pagma pack везде совершенно спокойно используется, и до "
 EK>> нужно  разбирать линейный буфер явно, побайтно" дело не доходит.  

 AM> Когда дело касается кроссплатформенности, логично закладываться на
 AM> описанные  в стандарте средства языка.

в котором из ?

и что значит - закладыватся ? если предыдущие авторы заложились правильно или
у тебе это не вылезло - это одно, а если вылезло и выяснилось что не
заложились и не подумали - тут то   и начинаются вопли с криками ;-)

 EK>> Может быть, лучше написать/потребовать/вставить авторам компилятора,
 EK>> чтоб  они делали как все нормальные люди, вместо того, чтоб так
 EK>> уродоваться ?

 AM> Да, и до кучи чтобы в стандарте реализовали типы
 AM> uint16_be, uint16_le и т.п., чтобы не уродоваться с большими и маленькими
 AM> индейцами.

чтобы не уродоваться должно индейцы должны быть одинаковые у всех, а так - для
индейцев придумали стандартную функцию - swab.

SY,
EK


LPC2xxx
Sat Nov 12 2005 20:01, Evgeny Kotsuba wrote to Andy Mozzhevilov:

 AM>> Когда дело касается кроссплатформенности, логично закладываться на
 AM>> описанные  в стандарте средства языка.

 EK> в котором из ?

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

 EK> и что значит - закладыватся ? если предыдущие авторы заложились правильно
 EK> или у тебе это не вылезло - это одно, а если вылезло и выяснилось что не
 EK> заложились и не подумали - тут то   и начинаются вопли с криками ;-)

Все вам какие-то вопли с криками мерещаться, что асмистам, что писишным
программерам. Спать ночью надо, а не фильмы ужасов по ящику смотреть.

 AM>> Да, и до кучи чтобы в стандарте реализовали типы
 AM>> uint16_be, uint16_le и т.п., чтобы не уродоваться с большими и
 AM>> маленькими  индейцами.

 EK> чтобы не уродоваться должно индейцы должны быть одинаковые у всех,

Есть реальность, а есть мечты.

 EK> а так - для индейцев придумали стандартную функцию - swab.

Я где-то говорил, что не знаю, как решить проблему с индейцами?
Я лишь сказал, что при кроссплатформенном программировании это одна из
проблем, которой нужно уделить внимание. А решить ее можно множеством
способов.

wbr, Andy (2:5080/76.6)


Site Timeline