Ukazatele jako parametry funkcí v jazyce C

10.11.2010 12:02 | Přečteno: 4225× | programování v C

Chápu, že třeba ukazatel na znak je proměnná, která neobsahuje přímo určitý znak, nýbrž obsahuje adresu, na které ten určitý znak leží. Může také třeba obsahovat adresu prvního člena pole znaků.

Dokonce ještě (snad) chápu ukazatele na ukazatele na celé číslo (znak apod.). Používá se třeba v případě dvourozměrných dynamických polí.

Co ale nemůžu pochopit -- to jsou funkce, jejichž parametrem (parametry) je (jsou) ukazatel (ukazatele). Hlavně by mě velmi zajímalo, jaký je rozdíl mezi těmito konstrukcemi:

int funkce1(char *ret)
{
  /* Tuhle funkci snad chápu dobře. Když ji zavolám s určitým
     parametrem, tak se vytvoří nový ukazatel, jehož obsahem
     bude stejná adresa na znak jako byla u parametru. */

  /* Můžu si tedy dovolit toto: */
  *ret = 'A';
  
  /* Když budu vědět, že se jedná o pole, tak můžu třeba i toto: */
  *(ret + 1) = 'B';

  /* Pokud to chápu úplně dobře, měl by to jít i takhle: */
  ret[0] = 'A';
  ret[1] = 'B';

  /* Jelikož se v C předává pouze hodnotou, tak tímto
     ztratíme adresu, kterou jsme pouze převzali z parametru,
     parametr to nijak neovlivní: */
  ret = NULL;
}

int funkce2(char **ret)
{
  /* Tak toto nemůžu pochopit. Jedná se o ukazatel na ukazatel na znak
     Tzn. že se bude předávat adresa na ukazatel na znak. */
}

Byl by někdo hodný a poradil mi, jaký je rozdíl mezi funkcemi funkce1() a funkce2()? Tedy hlavně rozdíl mezi "*ret" a "**ret". Předem děkuju.

       

Komentáře

[Luboš Doležel (Doli)]

char** je ukazatel na char*, takže pokud chcete z char** dostat char, musíte dělat * dvakrát. Ale smyslem char** je změnit někde adresu ukazatele. Typicky jde tedy o výstupní argument, který tam třeba zapíše nově vytvořený buffer.

[Begleiter]

smyslem char** je změnit někde adresu ukazatele

Pokud chceme, aby se změna obsahu ukzatele (tedy kam ukazuje) projevila i vně funkce (tedy jakoby se předávalo odkazem), tak pracujeme s "**ret" (v hlavičce funkce). Díky!

[Josef Kufner]

A nebo se předává do funkce pole řetězců.

[Luboš Doležel (Doli)]

Jo, typická ukázka: funkce main

[qiRzT]

Zamysli se nad tím, co do té druhé funkce předáváš - nějakou adresu v paměti. Co je na té adrese? Zase nějaká adresa a na téhle adrese je nějaký char.

typ     char **     char *     char
adresa: 2008        2004       2000
data:   2004    ->  2000    ->  'A'

Rozdíl mezi těma funkcema ve volání může být třeba takový:

char c = 'A';
char * cp = &c; /*cp == 2000*/
char ** cpp  = &cp; /* cpp == 2004*/

/*volani se stejnym vysledkem*/
funkce1(&c);
funkce1(cp);

/*volani se stejnym vysledkem*/
funkce2(&cp);
funkce2(cpp);

pokud navíc:

int funkce2(char **ret)
{
 return funkce1(*ret);
}

Tak se to všechno bude chovat stejně.

[Roger]

char c = 'A';
char * cp = &c; /*cp == 2000*/

Ty Cckove komentare tomu zrovna nepomahaji :)

[qiRzT]

Hmm, měl jsem tam dát apoň mezery. Takle s C++ komentáři to snad je jasné:

char c = 'A';
char * cp = &c;        // cp  == 2000
char ** cpp  = &cp;    // cpp == 2004

[Begleiter]

Děkuju moc. Už to chápu.

[____]

Nějak nechápu, co na tom chceš ještě vysvětlit. Připadá mi, že v tom hledáš nějakou magii, která v tom není.

První funkce přebírá ukazatel na znak, druhá funkce přebírá ukazatel na ukazatel na znak. Možná ti pomůže vysvětlení na anglické Wikipedii. A nebo si to zkus načrtnout na papír.

Ukazatele se dají obecně indexovat jako pole (dokonce i do mínusu), takže *ret ve funkci1 je skutečně to samé jako ret[0] v téže funkci (jak se tu řešilo nedávno, ret[0] a 0[ret], je defakto *((ret) + (0)), což je zas ekvivalentní k *ret). Rozdíl mezi ukazatelem a polem se ukáže v momentě, kdy se pokusíš zjistit jejich velikost.

A teď jsem tě možná pomátl dočista. :)

[Begleiter]

Díky!

[CET]

Ano, jazyk C je zrovna jazyk na rozmezi mezi assemblerem/strojakem a vyssim jazykem bez ukazatelu (resp. nahrazenych jinymi konstrukcemi).

Pokud bys nekdy delal v assembleru, tak bys zjistil, ze je uplne jedno, kolik to ma v C hvezdicek, ale ze je dulezite, jak to interpretujes.

Prakticky jsou ty hvezdicky jakesi kontroly, co ta promenna obsahuje, takze pokud to blbe pouzijes, tak te bude treba kompiler u prace s char **a varovat, ze s obsahem ukazatele (coz je zase ukazatel) chces pracovat jako s char. Ale fakticky ti to dovoli, stejne jako v assembleru muzes obsah pameti bud vypsat jako znak, nebo to vzit jako adresu a cist neco z te adresy.

Ve vyssich jazycich pak uz te nezajima, ze "a" ve string a; je vlastne taky ukazatel na znaky (ala char *a), ale pracujes s tim, jakoby sama promenna "a" byla ten string.

Cili funkce1 bere ukazatel na pole charu, cili na adresu, od ktere zacinaji chary.

char *a je tedy

a[1000] -> 'A','B','C','D'...'\0'

Druha funkce2 bere ukazatel na ukazatele na chary, cili od adresy ret mas seznam cisel, ktere udavaji adresy, kde zacinaji jednotlive chary.

Tady je ale char **a

a[3000] -> 1000,1200,1400,1600

1000 -> 'a','a','a','a',...'\0'
1200 -> 'e','e','e','e',...'\0'
1400 -> 'c','c','c','c',...'\0'

nebo se pletu?

[Begleiter]

Super! Moc děkuju.

[deda.jabko]

int funkce1(char *ret)
{
  /* Můžu si tedy dovolit toto: */
  *ret = 'A';
}

ne tak uplne. treba volani funkce1("Foobar"); ti neprojde, protoze retezec je s nejvetsi pravdepodobnosti v casti pameti, ktera se neda menit.

[kralyk z abclinuxu]

Tam vypíše warning, protože "Foobar" je, afaik, const char*.
Nicméně přeloži to a pak vzniká rizoto SIGSEGV.

[rADOn]

C prekladac to dovoli, protoze se nemeni ukazatel ale pamet na kterou ukazuje. C++ to nedovoli.

[kralyk z abclinuxu]

Mně to přeložil i g++... ale nevim...

[pavlix]

C prekladac to dovoli, protoze se nemeni ukazatel ale pamet na kterou ukazuje. C++ to nedovoli.

Takhle použitý const právě naopak znamená, že se *nesmí měnit obsah té paměti.

* Mnohé překladače pouze varují.

[Radek Hladik]

Upřímně řečeno, tohle je v C jeden z nejdůležitějších momentů (a pro mně i jeden z největších důvodů, proč C nesnáším). Při programování v C se budete velmi často setkávat s konstrukcemi typu adresa pointeru na pointer a pod. A především i s přetypováváním pointerů, tedy funknce může dostat pointer buď na char nebo int (dejme tomu). Pak má jako parametr pointer na void (netypový pointer) a podle potřeby si pointer přetypuje. A pro jistotu se předává ne pointer na void, ale pointer na pointer na void, aby to šlo změnit.

Ještě lepší je, když se posílá pointer na pointer na void, ten se přetypuje na nějakou uživatelskou struct, tam se očekává polovina věcí už vyplněná, zbytek se nějak v rámcí funkce dopočítá a vše se vrátí jako nový pointer A přidáme si do toho makra, která sice mohou být úžasná, ale zároveň i megaultrahumusná a vznikne dobrý chaos... Například práce s ASN.1 v OpenSSL je naprosto "úžasná". Zavoláte jedno makro (od kterého není pořádný popis v dokumentaci) a ono to udělá asi milión volání funkcí, přetypovávání a já nevím čeho všeho. Definice makra není pořádně k dispozici, protože je nějaká hromadná, či jak se to jmenuje atd...

Nu, to jsem se ale nechal trochu unést, v principu jsem chtěl říct jen to, že tahle práce s pointery je v C alfou a omegou všeho a je potřeba jí perfektně ovládát... Až pak budete luštit/tvořit konstrukce typu (sc_path_t *) &(env->file_ref), budete to sakra potřebovat...

[kralyk z abclinuxu]

Ne všichni píší pod gtk
(a freetype2 a libavcodec a ... a ... )

[Grunt]

No jo, ale vem si, že i přes to, že mplayer polovinu času nedělá nic jiného než že někde přesouvá pointery z libav*, ffmpegu, a jiných obalovacích vrstev jak je rychlý. Dovedeš si představit ho napsaný v něčem jiném? (krom komplet Assembleru…i tak ho tam už není málo). Např. stack některých C++ aplikací, to je fakt dílo. Proti nim je i debugovaní kernelu slabé máslo.

[kralyk z abclinuxu]

Jo, to je pravda, mplayer je hodně rychlý.
Ale třeba takové VLC je taky (z většiny) v C a přitom je děsně pomalý...

[Grunt]

Tam je totiž těch obalových vrstev ještě jednou tolik.

[Luboš Doležel (Doli)]

Pomalý v čem?

[kralyk z abclinuxu]

V přehrávání.
Na notebooku s omezeným výpočetním výkonem se to pozná; VLC má o dost níž strop HD videí, které je schopno plynule přehrát...

[David Watzke]

To není pravda obecně, třeba na Intelu když používám VA API, tak mi VLC přijde lepší. Problém MPlayeru je hlavně postupný (mírný) rozjíždění A/V.

[kralyk z abclinuxu]

Tím Intelem myslíš grafárnu? Tam už funguje aj h264 Vím že dřív šlo jen mpeg2...

[mirec]

Taký ffmpeg je tiež v C a patrí medzi pomerne pomalé dekódery. MPEG4 AVC prehráva o dosť pomalšie než CoreAVC.

[Begleiter]

Děkuju za názor.

[qiRzT]

A tos ještě zapoměl na pointery na funkce. S těma makrama jsi mi připoměl moje první setkání s tím, jak jsou v Linuxu (tedy kernelu) řešeny objekty, polymorfismus apod. V tom se vyznat, je taky (aspoň zpočátku) pěkná fuška

[Rezza]

A GLib!

[Grunt]

Na to mám jednoduchý trik. Zapnu GDB a mlátím do TABu (umí to něco jako BASH completion) tak dlouho dokuď se tečkama přes struktury a pointery neprobiju až na požadovanou proměnnou. A jako bonus to zahlásí, když je některá proměnná typu void a nejde dereferencovat. Stallman budiž blahořečen.

[tom]

Krome *(ret + 1) = 'A' a ret[1] = 'A' muzete psat i 1[ret] = 'A' ;) scitani je totiz komutativni

[Michal Kubeček]

To je sice hezké, ale je to - kromě znepřehlednění programu - k něčemu dobré?

[Gilhad]

Připravuje nás to psychicky na použití Perlu :)

(A možná se jednou za čas někde vyskytne nějaká složitější konstrukce, která se tak dá zapsat lépe. A taky má určitý půvab "úplnost" - nevylučovat předem věci, které jsou zdarma, jen pro ně nemám použití zrovna tady a teď, zvláště pokud by to vyloučení něco stálo.)