*****SPAM***** RE: C _ jak rozepsat řádek
Jaroslav Buchta
jaroslav.buchta na hascomp.cz
Sobota Duben 27 20:55:49 CEST 2013
Tak snad je jasne, co mam na mysli - 8, 16, 32b
A uz jsem do ruznych projektu vkladal spustu zdrojaku z ruznych
platforem a nikdy s tim nebyl vetsi problem, pokud to bylo rozumne
napsano. Zvolit ENDIAN, zarovnani byva taky nejak preddefinovano,
naklonec ja uz beru za standard GCC, protoze v tom prekladam uz
prakticky pro vsechny MCU. Ve win uz radsi C#, proc si komplikovat zivot ;-)
Dne 27. 4. 2013 19:31, Josef Štengl napsal(a):
> Ne, je.
>
> BYTE, WORD, DWORD - nevím co tím myslíte. Takové typy C nezná. A já
> vždycky nevím, kolik bitů ten word je. Někdy 16, někdy 32, záleží na
> šířce registrů nebo sběrnice a s kým se bavíte. Tyto typy nejsou
> obecně specifikovány.
>
> Makra align jako takové v C neexistují, pokud si je nevytvoříte a
> pokud máte na mysli atributy či pragmy, tak ty jsou silně závislé na
> překladačích. Pokud programuje na více cílových platforem a pro více
> překladačů, je to kraj zapovězený a vstoupit to něj smí jen lidé znalí
> a jen když je to nezbytně nutné.
>
> Nejde o to jestli je to implementováno víceméně stejně, jde o to že to
> není standardizováno a je to implementováno víceméně stejně.
>
> Zrovna bitová pole jsou závislá na endianitě. S tím LSB máte pravdu,
> ale problém je, že to LSB je pokaždé na jiné straně, což se může být
> problém v komunikaci s perifériemi, které jsou většinou v malých
> indiánech a převádí se podle nastavení procesoru. Pokud píšete
> ovladače na konkrétní zařízení, je možná pouze jedna endianita a
> nemusí mít SIL nebo ASIL tak to vem čert, ale pokud máte procesor
> biendian a nevíte jestli se to bude překládat pro malé nebo velké
> indiány, tak jste a) v jednom případě v průseru b) obklíčen #ifdefy a
> stejně máte možný skrytý problém s jiným překladačem.
>
> Obecně výskyt union je známkou špatné programovací techniky. Až na
> vyjímky a ty poznáte, jsou to většinou nádherné a účelově vymyšlené
> konstrukce.
>
>
> ced
>
> Dne 27.4.2013 18:53, Jaroslav Buchta napsal(a):
>> Nevim jak s bitovymi poli ale union pro pristyp BYTE, WORD, DWORD... se
>> vidi celkem bezne, da se to osetrit ruznumi makry ALIGN.... xxxENDIAN...
>> aby to bylo univerzalne prenositelne a je to OK. Zas takovy bordel v
>> ruznych implementacich neni a funguje to celkem stabilne (bitova pole by
>> se taky mela postupne umistovat do standardniho typu (int) od LSB ve
>> vsech implementacich, ne? )
>>
>> Dne 27. 4. 2013 18:48, Miroslav Draxal napsal(a):
>>>
>>> Díky, tohle funguje,
>>>
>>> Na štábní kultuře zapracuji, v tomto projektu již nechám sprasenou.
>>>
>>> S těmi ukazateli mam vždy problém, že nějak neumím najít systém, odkud
>>> ten řádek mám začít číst. I za 10 let v tom budu plavat.
>>>
>>> *From:*hw-list-bounces na list.hw.cz [mailto:hw-list-bounces na list.hw.cz]
>>> *On Behalf Of *Josef Štengl
>>> *Sent:* Saturday, April 27, 2013 2:26 PM
>>> *To:* HW-news
>>> *Subject:* Re: C _ jak rozepsat řádek
>>>
>>> On v nich trošku plave skoro každý :-)
>>>
>>> To jak máte napsáno „// tohle je OK“, tak to je v pořádku protože
>>> pracujete s ukazatelem na strukturu, kterou derefenrecujete a
>>> přistupujete k ní jako ke struktuře resp. přímo k položce struktury.
>>> Ten
>>> typ položky je důležitý, protože položky nazvané Bit[0-7] jsou položky
>>> bitového pole, a položka bitového pole nemá adresu, takže na něj nelze
>>> vytvořit ukazatel. Viz pozn. 106 dokumentu n1256: (C99 draft)
>>>
>>> The unary & (address-of) operator cannot be applied to a bit-field
>>> object; thus, there are no pointers to or arrays of bit-field objects.
>>>
>>> Takže se pak přes ukazatel snažíte získat adresu položky pole, která je
>>> ovšem položka bitového pole a ten nemá adresu a skončí to chybou.
>>>
>>> Dále jen poznámky pod čarou. Pokud vás rozčílí, tak si jich nevšímejte:
>>>
>>> Název unionu začíná podtržítkem, což má jazyk C rezervovaný pro budoucí
>>> použití. Podtržítka na začátku čehokoliv v aplikačních programech
>>> nepoužívat!
>>>
>>> Zvážil bych použití bitového pole ve stylu
>>>
>>> http://c-faq.com/misc/bitsets.html
>>>
>>> Jen k tomu mám poznámku, že char by měl být unsigned char, protože
>>> by se
>>> neměly provádět bitové operace na znaménkových typech. Ve velmi
>>> speciálních případech dostáváme zajímavě nesprávné výsledky.
>>>
>>> Vypadá to, že se snažíte mít různý přístup k jednomu místu v paměti s
>>> využitím typu union. To je z hlediska specifikace C chybně, protože jak
>>> se ukládají data v položce union je jen a pouze záležitost překladače a
>>> jinde by to nemuselo fungovat správně (dobrá, to že jsem se s tím ještě
>>> nesetkal, neznamená že se to prohlásí za standard. Aby to pak nedopadlo
>>> jak s tím raketoplánem co vybouchl :-)
>>>
>>> Pro mě je to příklad toho jak by se to psát nemělo. Jestli mi do toho
>>> nic není, tak si toho nevšímejte :-D.
>>>
>>> Hmm než jsem to dopsal, tak toto od pana Augustýna by mohlo fungovat.
>>>
>>> (*pProgEEpr).EndProgram = 1;
>>>
>>> Protože se nejprve provede dereference ukazatele na strukturu a pak se
>>> přistupuje k položce.
>>>
>>> Hezký den.
>>>
>>>
>>> Dne 27.4.2013 12:18, Miroslav Draxal napsal(a):
>>> > Dobrý den
>>> >
>>> > Mějme
>>> >
>>> > char MenuPolozkaSet;
>>> >
>>> > typedef union {
>>> >
>>> > char value;
>>> >
>>> > struct {
>>> >
>>> > unsigned Bit0 : 1;
>>> >
>>> > unsigned Bit1 : 1;
>>> >
>>> > unsigned Bit2 : 1;
>>> >
>>> > unsigned Bit3 : 1;
>>> >
>>> > unsigned Bit4 : 1;
>>> >
>>> > unsigned Bit5 : 1;
>>> >
>>> > unsigned Bit6 : 1;
>>> >
>>> > unsigned Bit7 : 1;
>>> >
>>> > } Bits;
>>> >
>>> > struct {
>>> >
>>> > unsigned val : 7;
>>> >
>>> > unsigned bit_ : 1;
>>> >
>>> > } ProlnutiPauza;
>>> >
>>> > struct {
>>> >
>>> > unsigned Mesic : 5;
>>> >
>>> > unsigned AutoOnOff : 1;
>>> >
>>> > unsigned EndProgram : 1;
>>> >
>>> > };
>>> >
>>> > } _ProgramEEprom;
>>> >
>>> > (*((_ProgramEEprom*) & MenuPolozkaSet)).EndProgram = 1; // tohle
>>> je OK
>>> >
>>> > Pokud bych to chtěl rozepsat přes fyzický ukazatel
>>> >
>>> > _ProgramEEprom *pProgEEpr = (_ProgramEEprom*) &MenuPolozkaSet;
>>> >
>>> > *pProgEEpr.EndProgram = 1;
>>> >
>>> > To hází chybu
>>> >
>>> > MenuKey.c:261: error: struct/union required
>>> >
>>> > MenuKey.c:261: error: illegal conversion between types
>>> >
>>> > Což asi chápu, ale jak to napsat. Snažím se tomu přijít na kloub.
>>> V těch
>>> > pointerech plavu.
>>> >
>>> >
>>> >
>>> > __________ Informace od ESET NOD32 Antivirus, verze databaze 8272
>>> > (20130426) __________
>>> >
>>> > Tuto zpravu proveril ESET NOD32 Antivirus.
>>> >
>>> > http://www.eset.cz
>>> >
>>> >
>>> > _______________________________________________
>>> > HW-list mailing list - sponsored by www.HW.cz <http://www.HW.cz>
>>> > Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>> > http://list.hw.cz/mailman/listinfo/hw-list
>>> _______________________________________________
>>> HW-list mailing list - sponsored by www.HW.cz <http://www.HW.cz>
>>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>>
>>>
>>> __________ Informace od ESET NOD32 Antivirus, verze databaze 8272
>>> (20130426) __________
>>>
>>> Tuto zpravu proveril ESET NOD32 Antivirus.
>>>
>>> http://www.eset.cz
>>>
>>>
>>>
>>> __________ Informace od ESET NOD32 Antivirus, verze databaze 8272
>>> (20130426) __________
>>>
>>> Tuto zpravu proveril ESET NOD32 Antivirus.
>>>
>>> http://www.eset.cz
>>>
>>>
>>> _______________________________________________
>>> HW-list mailing list - sponsored bywww.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>>
>>
>> _______________________________________________
>> HW-list mailing list - sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
Další informace o konferenci Hw-list