pointer v c

Josef Štengl ok1ced na nagano.cz
Úterý Leden 6 21:26:49 CET 2015


Ano, typově ano. Problém je, že profesní neprogramátoři (motoráři, lidi od měničů, plošňáků,  akademici a tak podobně) 
mají tendence sčítat pointry a myslet, že pointer + 1 a adresa + 1 je jedno a to samé. Způsob který jsem použil je sic 
takový nehezký, ale je zcela jednoznačný (tedy, když se přečte správně :-). Překladači je to samozřejmě jedno.

Joj out-of-order vykonávání je taky docela hezká zábava, když se dělá s HW. To se pak člověk mlátí s berličkou volatile 
kolem sebe :-)

:-D

hezký den

ced


Dne 6.1.2015 v 21:05 Jaroslav Buchta napsal(a):
> Vsak se spis ptam, ten soucet je typove atd. taky OK, ne?
> Asi to mam radsi, ze to ma min znaku, taky mi ten zapis s & prijde trosku jako rovnak na ohejbak, prekladaci je asi forma
> zapisu fuk a prelozi to stejne...
> S optimalizacema jsem mel vzdycky problem jen diky knihovnam, nebo ze mi to poprehazovalo posloupnost nejakych prirazeni
> co se tykala HW registru...
>
> Dnes jsem ale pul dne resil problem s prenosem velkeho bufferu mezi C++ a C#, stale jsem resil, proc to spadne na pristup
> do pameti a v ktere velikosti muze byt chyba, studoval marshalling, unsafe, definoval pole staticky, alokoval ruzne az v
> C++,... a nakonec kdyz uz jsem do krokoval v assembleru jsem zjistil, ze jsem misto handle dal do uplne jineho parametru
> index zarizeni a ten byl nulovy, typ UINT32 a knihovna to klidne pouzila jako ukazatel. ;-) To jsem myslel, ze se
> odstrelim, takova blbost a prehlednuti...
>
> Dne 6. 1. 2015 v 20:50 Josef Štengl napsal(a):
>> Protože tak je to sémanticky, logicky a typově správně a je poznat co tím autor myslel. Zamezí se tak spoustě chybám.
>>
>> Dotaz byl jak by to mělo být naspáno správně a ne jak si to Jarda doma patlá. Do toho mi nic není. :-D
>>
>> Mimochodem není to přehlednější, na pro vás přehlednějším zápisu není mě zcela jasné co jste tím myslel. A u
>> složitějších konstrukcí je to náchylné k chybám typu „to je přece jasné, u mě to funguje“. Asi tak.
>>
>> Zítra mě čeká hrabání se v kódu, který by bylo dobré zrychlit. Jakmile se na něj spustí optimalizace vyšší než -O1, tak
>> přestane fungovat :-(. Tak třeba proto.
>>
>> Dne 6.1.2015 v 20:32 Jaroslav Buchta napsal(a):
>>> Tohle me vzdycky dostane, proc nenapsat radeji podle me prehlednejsi:
>>>
>>> pepromuk = DATA_EEPROM_START_ADDR + eprom_ofst;
>>>
>>> Dne 6. 1. 2015 v 20:03 Josef Štengl napsal(a):
>>>> /* takhle by to mělo být podle mě správně a až na jednu či dvě drobnosti snad projít i statickým analyzátorem.
>>>>    jen takový nástin, ten offset, jestli to je ofset, se mi jeví nějaký zbytečně dlouhý ... */
>>>>
>>>> #include <stdint.h>
>>>>
>>>> #define DATA_EEPROM_START_ADDR  (uint8_t *)0x08080000u //4Kb 16 X 256 BYTE
>>>> #define LEDErezim               (uint8_t *)0x080803E0u //L  0 led neblika 1 led blika
>>>>
>>>> void Reasetchar (uint32_t eprom_ofst)
>>>> {
>>>>   uint8_t  * pepromuk;
>>>>   uint8_t cis1;
>>>>
>>>>   pepromuk = &DATA_EEPROM_START_ADDR[eprom_ofst];
>>>>   cis1 = *pepromuk++;
>>>>   ...........
>>>>   ...........
>>>>   pepromuk = LEDErezim;
>>>>
>>>>   if (*ppp > 0)
>>>>   {
>>>>     cis1 |= 1;
>>>>   }
>>>> }
>>>>
>>>> Dne 6.1.2015 v 15:07 Fanda Kopriva napsal(a):
>>>>> Dobry den
>>>>> jen bych poprosil o  ujasneni.
>>>>>
>>>>>
>>>>> #define DATA_EEPROM_START_ADDR     0x08080000     //4Kb  16 X 256 BYTE
>>>>> #define  LEDErezim   0x080803E0    //L  0 led neblika 1 led blika
>>>>>
>>>>> void Reasetchar (unsigned long epromadr)
>>>>> {
>>>>> unsigned char *pepromuk;
>>>>> unsigned char cis1;
>>>>> pepromuk = DATA_EEPROM_START_ADDR + epromadr;
>>>>> cis1 = *pepromuk++;
>>>>> ...........
>>>>> ...........
>>>>> pepromuk = LEDErezim;
>>>>>   if (*ppp>0) cis1 |=1;
>>>>> }
>>>>>
>>>>> dela to co ma ,ale prekladac hlasi pro radky
>>>>>         pepromuk = DATA_EEPROM_START_ADDR + epromadr;
>>>>> a
>>>>>       pepromuk = LEDErezim;
>>>>> upozorneni
>>>>>                       Implicit conversion of int to ptr .
>>>>>
>>>>> Jak by to melo byt spravne.
>>>>>
>>>>> Dekuju Fanda
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> http://www.avast.com
>>>
>>> _______________________________________________
>>> 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
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> http://www.avast.com
>
> _______________________________________________
> 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