pointer v c

[Martin Persich]

Prikaz #define je vlastne jen textove makro, kdy se nejaky text ve zdrojovem kodu nahradi jinym textem jeste pred zahajenim samotneho prekladu.
Obecne lze pouzit temer kdykoli cokoliv, protoze vzdy lze pouzit pretypovani. V uvedenem pripade asi velky rozdil neni, ale slozitejsi je to tehdy, pokud prikazem #define rovnou definujete ukazatel na vicebytovy objekt (napr.: uint16_t*). Pricteni jednicky k takovemu ukazateli neznamena zvetseni adresy o "1", ale zvetseni ukazatele na dalsi objekt daneho typu, tzn. v uvedenem pripade se zvetsi adresa o "2", obecneji o "sizeof(uint16_t)". A to je potreba opravdu dusledne hlidat. Proto tady byl doporucovan zapis "&XX[yy]", tam je to (mozna) jasnejsi. Ale priznavam, ja osobne take  pouzivam radeji scitani konstant (ukazatelu) nez zapis pomoci indexu - "[yy]". Programatori "dospelych" programu mne urcite budou chtit take rovnou ukamenovat, ale mam pocit, ze pro lidi, kteri pisi programy pro mikrokontrolery a porad se prehrabuji v "adresach" je to takove logictejsi. Aritmetika ukazatelu ma sice mnoho nastrah, ale z meho pohledu jsou i horsi veci - to kdyz mikrokontroler neumi nacist 16-ti bitove cislo z liche adresy. A tady zadne kontroly v kompilatoru nepomohou - zvlaste, kdyz clovek zpracovava data nejakych komunikacnich protokolu, nejakou dobu to jede, pak "prijde" neco jineho a je z toho pad programu.
Ja naopak mam problem - pokud to mam zapsat jako index - musim si to nejdrive v hlave prevest. A mam dokonce pocit, ze ve slozitejsich pripadech delam daleko vice chyb v pouziti indexu nez pri prostem scitani ukazatelu. Na druhe strane me programy prekypuji (mnohdy nadbytecnymi) pretypovanimi a rozhodne nesetrim zavorkami! Davam je casto i tam, kde byt nemusi, ale nikdo se pak nemuze stezovat, ze nevi, co tim autor sledoval. Ale pocitam se spice mezi "prilezitoste" programatory, prestoze "C" pouzivam snad uz 25 let, tak prakticky vyhradne pro mikrokontrolery a neni to dohromady vic nez 1/3 pracovni doby. A priznavam na rovinu - po nekolika tydnech "pustu" casto znovu zvazuji prioritu nekterych operatoru. Tak radeji "zavorkuji" ...
A jak zde obsas zahlednu prispevky na tema "C" nekterych "nejmenovanych" clenu konference :-), tak mi pada celist a mam pocit, ze bych se mel jit hrozne rychle stydet nekde do tmaveho kouta ...
Martin. persich na transcon.cz




----- Original Message ----- 
  From: Fanda Kopriva 
  To: hwkonference 
  Sent: Wednesday, January 07, 2015 5:16 PM
  Subject: Re: pointer v c


  Dik za odpovedi
  nebyl mi tam jasny rozdil mezi ukazatelem na promnennou 
  a ukazatelem na cislo (define) coz asi neni obsah promnenne ,ale cislo samo o sobe.

  Predpokladam ,ze druhy zapis je obecnejsi protoze muzu pouzit stejnou adresu pro ruzne
  typy dat?

  #define DATA_EEPROM_START_ADDR     ((unsigned char *)0x08080000)

  pepromuk = (unsigned char*)(DATA_EEPROM_START_ADDR + epromadr);

    Fanda



  -------- Původní zpráva -------- Předmět:  pointer v c 
        Datum:  Tue, 06 Jan 2015 15:07:03 +0100 
        Od:  Fanda Kopriva <info na elektronikavyvoj.cz> 
        Komu:  hwkonference <hw-list na list.hw.cz> 



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
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20150107/fc7746fd/attachment.html>