[Megoldva] C - Fuggvenynek pointer vagy ertek?

 ( Tomi87 | 2013. március 25., hétfő - 12:02 )

Ha valtozik a valtozo erteke, akkor nyilvan pointer. De ha nem, ha csak felhasznalja valamilyen szamitashoz akkor mindket esetben ugyanaz az eredmeny. Na most egyreszt, elvileg kerulni kell a pointereket ha lehet, plusz esetleg kevesebb lesz a kodban a "szintaktikus zaj", masreszt viszont, minek ketszer eltarolni ugyanazt a memoriaban, ha nem muszaj. Szoval szolnak ervek mindket megoldas mellett.

Ez izles kerdese? Vagy van valamilyen konvencio, best practice amit erdemes kovetni? (ill. ha van, mi all mogotte?)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

osszetett tipust pointerrel szoktak, ha nem valtozik akkor const pointerrel (nyilvan a lassu masolas elkerulese miatt)
intet nyilvan ertelmetlen pointerkent atadni, foleg nem azert, hogy (minek ketszer tarolni), foleg mivel a pointer ugyanannyit foglal

best practice pl az, hogy ha lehet irjunk pure functiont, de ha ez nem praktikus, akkor is minimalizaljuk a free variable-k szamat (ez hogy van magyarul?),
tehat minel tobb valtozonak legyen jol meghatarozott erteke es ne valami kintrol jovo katyvasz legyen, ami akar a fv futasa kozben is megvaltozhat

ilyesmik :-)

--
NetBSD - Simplicity is prerequisite for reliability

Kicsit off:

const C-ben nincs, csak C++ban, igaz? (Mert ha nem akkor gyoker a tutorom :) )

Akkor egy szep magyarazat a const/pointer viszonyokrol es lehetseges tipusairol:
http://www.thegeekstuff.com/2012/06/c-constant-pointers/

Legalábbis nagyon sok évvel ezelőtt így volt.

C99-ben van

--
NetBSD - Simplicity is prerequisite for reliability

"best practice pl az, hogy ha lehet irjunk pure functiont, de ha ez nem praktikus, akkor is minimalizaljuk a free variable-k szamat (ez hogy van magyarul?),
tehat minel tobb valtozonak legyen jol meghatarozott erteke es ne valami kintrol jovo katyvasz legyen, ami akar a fv futasa kozben is megvaltozhat"

A pure function nem ezt jelenti. A pure function azt jelenti, hogy nincs mellékhatása, és csak a paramétereitől függ (és nem a globális állapottól). Ez többnyire csak úgy közelíthető, ha sok a paraméter.
----
India delenda est.
Hülye pelikán

igaz, nem ezt jelenti, de ezt is :-)

--
NetBSD - Simplicity is prerequisite for reliability

Legyen minnél szebb és egyszerűbb a kód.
Ne optimalizáld, ami nem lassu, azt, hogy mi lesz lassú (szűk keresztmetszet), azt meg úgysem fogod tudni előre megtippelni, legalábbis ritkán. Ha valamiről kiderül, hogy lassú (profiling!), akkor majd utólag optimalizálsz.

Igen, elsősorban érthető kódot kell írni, a sebességbe szerintem nem kell kezdetben túl sok energiát fektetni.

Mondom annak ellenére, hogy C-ben kizárólag 16 MHz-es "tetű" mikrokontrollereket programozok.

Először a kód menjen, utána ráérsz gondolkozni a sebességen is. A sebesség ellenőrzése MCU alatt elég szivatós, mert a lefordított kódot nézegetheted.

Nyilván ha véletlen uint8_t helyett intet használsz (16 bites), akkor az itt elő fog jönni. Persze sajnos az avr-gcc időnként művel nyakatekert baromságokat (pl. 4-es osztás barmolással számolva shift helyett). Ilyenkor megpróbálsz egy olyan megoldást találni (jelen esetben >> 2), amit a fordító ökörködés helyett egyszerűen kiszámol.

Assembly-t még AVR alatt sem használok, csak ha elkerülhetetlen. Akkor is #ifdef matyóhímzések között és tiszta C-s megoldást is írok, ha a felhasználónak nem tetszene.

Én mondjuk egy 4 magos 3.2GHz-es PC-n csesznék a sebességre (max. ésszel választok algoritmust). Nagyon kevés olyan feladatot tudok elképzelni, ahol ez számít.

Amikor meglattam a topik cimet, mar tudtam, ki a kerdezo :)

Alapelv, hogy "premature optimization is the root of all evil".

Addig ne akarj teljesitmenyproblemakat elore megoldani, amig nem lesznek teljesitmenyproblemaid ("masreszt viszont, minek ketszer eltarolni ugyanazt a memoriaban").

Az a kod, ami konnyen olvashato marad neked, de nem eppen optimalis memoriat hasznal, meg mindig tobbet er, mint az optimalis, de szamodra nehezen olvashato, modosithato kod.

Kiegészíteném egy másik idézettel:
,,First make it run, then make it run fast.'' (forrás: itt)

Az én olvasatombam: előbb működjön bizonyíthatóan helyesen a program, optimalizálni azután is ráérsz.

Az optimalizálás nem teszi jobban működővé az egyébként hibás programot vagy algoritmust...

G.
============================================
"Share what you know. Learn what you don't."

Elhiszem, egyreszt a cim formatuma jellemzo kezd lenni ram, masreszt mivel most ezzel foglalkozom, feltettem mar par kerdest a temaval kapcsolatban :)

Én értem félre a kérdést?

Függvénynek való paraméterátadásról van szó, ugye?
Ha igen, akkor hol van itt a kettős tárolás? Akarom mondani, nyilván van, AMÍG a függvény befejeződik, és eltűnik a stackből, ami a paraméterként oda bekerült... de a stack pont erre való, és akkor is ott van, ha önsorsrontóan nem használjuk.

Nyilván az az AZ MÁS kategória, ha a következő NASA-produkcióhoz írjuk a kódot - de akkor beszt prektiszként kerüljük a komoly munka és a fronthatással súlyosbított hétfők találkozását!

Nem is a tárolást érzem itt problémának, hanem ha elkezdünk nagy adatstruktúrákat másolgatni a stackre, és meghívjuk a függvényt sokszor, az már a cpu használatra is mérhető hatással lesz.

Premature optimization is the root of all evil.

Illetve: a holnap problémáit holnap kell megoldani.
Akkor legyen ez gond, ha már mérhető a CPU-terhelés.

Ezzel egyetértek. Csak azt akartam jelezni, hogy a kérdező is talán inkább erre gondolhatott. :)

Nó offensz, de nem vagyok arról meggyőződve, hogy a kérdezőben tudatosodott, hogy az a specifikáció szerinti értékmásolódás a függvényhívás során ilyen illékony dolog.

Egyébként a nagy adatokra és a best practice fogalomra visszatérve: manapság, amikor minden valamirevaló program minden sarkon felkínálja a cancel/undo opciót, nem hogy nem triviális a nagy adatok pointeres átadása, de ahol nincs más módszer, még ott is megtörténik a mutatott terület klónozása a hívás előtt/után.

Mindezt úgy írom, hogy elsőként ismerem el, hogy a kódolásom sebességét tekintve - nyelvfüggetlenül - kontraproduktív a mániákus spórolás az erőforrásokkal.

Én pl. sosem adnék át egy struktúrát érték szerint, de nem ezért szólok hozzá, hanem egy 'mellékhatás' miatt: nevezetesen, hogy ha egy függvény túl nagyra nő, és elkezdünk belőle részeket kiszervezni, akkor az újonnan született részekben a struktúra hivatkozásokat meg kell haxolni 'valami.mező'-ről 'pvalami->mező'-re. Ez persze egy 'csak arra jó, hogy elrontsuk' jellegű művelet, amit adott esetben úgy cselezhetünk ki, hogy már a fő függvényben (ahol a 'valami' struktúra lokális változó) is pointerrel dolgozunk:

típus valami, *pvalami= &valami;
memset (pvalami, 0, sizeof (*pvalami));
pvalami->mező= 1;
childfunction (pvalami);
...

C-ben a referencia szerinti atadas is ertek szerinti atadast jelent, csak ebben az esetben egy pointer erteket adsz at a fuggvenynek. Ha belegondolsz, ez egyben azt is jelenti, hogy egyszeru adattipusoknal, amelyek merete nem nagyobb, mint maga a pointer, a referencia szerinti atadassal nem jarsz jobban, sot, alapvetoen rosszabbul jarsz a plusz kod miatt, amit a dereferencia jelent. Ird meg mondjuk a ket verziojat egy egyszeru fuggvenynek, ami visszaadja 3 integer szam osszeget es vess egy pillantast a generalt assembler kodra (pl. objdump -d). Latni fogod a kulonbseget.

Ami az osszetett adattipusokat illeti, hasznalj const pointert, hacsak valamilyen okbol nem akarsz tenyleg egy masolatot. Itt nem csak a masolas miatt elvesztegetett processzor ido problemas, hanem a stack veges volta is.

Az előzőekben már többen leírták: egyszerű adattal (int, float, double) ilyenkor nem érdemes szöszölni, tehát menjen át érték szerint, mert egy 64 bites rendszeren egy pointer is 8 bájt, ami nem kisebb, mint az egyszerű adatok mérete. Viszont a kód is áttekinthetőbb és szerintem a fordítóprogram is jobban tud optimalizálni, ha nincs megzavarva a pointerezéssel.

Ha érték szerint adsz át paramétereket egy nem túl sok kódsorból álló függvénynek, akkor jó eséllyel az optimalizáló beinlineolja (micsoda szó!) a függvényt, így a végtermékben még a stacket se fogja babrálni a kód, hanem a függvénytörzs kódja beépül a hívó rutinba és semmi adatmozgatás nem történik. Ennél gyorsabb megoldást nem lelsz, és ráadásul ez lesz az áttekinthető kód is.

Egy hosszú struktúránál már más lehet a helyzet, azt érdemes lehet mutatóval átadni. Ámbár ha a függvényed nem túl hosszú és a fordítóprogi beinlineolja, akkor igaziból nem is történik másolás.

Tehát: hacsak nem egy brutál méretű struct-od van, mindenképp érték szerint add át, mert ez az áttekinthető és egyáltalán nem biztos, hogy nyersz a pointerezéssel.

(Nekem az a tapasztalatom, hogy a mai fordítóprogramok elég fejlettek, így sokszor amit kézzel optimákolok, az rosszabbul sül el, mintha a C legkézenfekvőbb eszközeit használnám és rábíznám az optimalizációt a "-O3", "-finline-functions", stb-re. 15-20 éve nem így volt, akkor még egy Turbo-C vagy Borland C 3.0 esetén a kézi ügyeskedés sokszor vezetett jobb eredményre, mintha a fordítóra bíztam volna a dolgot.)

hacsak nem egy brutál méretű struct-od van, mindenképp érték szerint add át
Ez nem egy jo tanacs. Ezt eleg konnyu belatni, ha a masolasra gondolsz, ami mind CPU ido, mind stack meret szempontjabol problemas. Ez csak meg rosszabb lehet C++ eseten, ahol egy user-defined copy constructor meg koltsegesebbe teheti a masolast, nem veletlen hat, hogy read-only adatok atadasara a konstans referenciak (ill. pointerek) a hasznalatosak.

Csak nagyon kis meretu (es ez raadasul architektura fuggo) osszetett adattipusoknal nyerhetsz valamit ertek szerinti atadassal, pl. valami ilyesminel:

struct kicsi_vagyok { 
    u8 kicsi_vagyok;
    u8 ha_meg_novok;
    u8 beled_rugok;
};

Es ezt akar komolyan is veheted, mert az evek mulasaval biztosan jon majd valaki, aki ezt tovabb akarja "dudolni" es maris az effektiv ertek szerinti atadasbol egy processzor ido es stack zabalo folosleges masolas lesz, foleg mert ha a fuggvenyed mar 1000 helyen ertek szerinti atadassal van hivva, senki nem akarja majd egy kis "bovites" miatt, az osszes hivast pointer atadassa valtoztatni, sot valoszinuleg nem is fognak ra gondolni, hogy kellene. Meg rosszabb, ha ez nem egy belso fuggvenyecske, hanem mondjuk egy API resze. Megeri?

Az inline temahoz annyit, hogy ott alapvetoen nem a parameter atadas az egyetlen, amin az ember sporolni akar, megcsak nem is a legfontosabb, hanem onmagaban a fuggvenyhivas ara (stack frame letrehozasa, regiszterek mentese/helyreallitasa stb.). Ebbol kifolyolag arra a kerdesre, hogy mi a jobb, a referencia vagy ertek szerinti atadas, nem az inline fuggvenyek hasznalata a valasz, azok hasznalata inkabb csak ertelmetlenne teszik a kerdest.

Ja, a -O3 melle nem kell hasznalnod a -finline-functions kapcsolot is, az mar benne van. Bar ez nem fontos.

Nem feltétlenül jó tanács, de amit te tolsz az premature optimization. Nem nyerő, főleg kezdőknél. A profik sem tudják megtippelni jó hatásfokkal, mi lesz a lassú, hát még a kezdők. És a másolás nem feltétlenül lesz lassabb, sőt: ha minden adat egy helyen van (a stack adott részén), akkor kevesebb lesz a cache miss, nincs dereferálás stb. Nem olyan egyszerű kérdés ez, mint ahogy lefested.
----
India delenda est.
Hülye pelikán

Ertem mester. En ugyan nem vagom, mi az optimalizalas abban, hogy osszetett adattipusok eseten konstans pointerekel dolgozol ertek szerinti atadas helyett, de valoszinuleg megint a vilag csinalja rosszul, mert en nem ismerek olyan C/C++ API-t, ahol a te megoldasodat prefereljak. Ez vajon miert lehet? Na mindegy.

Lehet gunyoroskodni, meg lehet gondolkodni. Te az előbbit választottad, légy boldog.
----
India delenda est.
Hülye pelikán

De ez meg veletlenul sem jelenti azt, hogy te az utobbit. Miattam egyebkent nem kell folytatnod, en mar latom, hogy lovesed nincs, csak akkor miert kell megint tudalekosan bofogni? Meg azert varok a peldakra, ahol az altalad javasolt megoldas a nyero, ne fogd vissza magad, nekem van turelmem olvasni... de ne is miattam csinald, hanem, hogy a kerdezo tanulhasson belole. Ugye nem akarod, hogy ketsegek kozott orlodjon es zavaraban esetleg a rossz megoldast valassza?

Hinnye de míves nagy paraszt vagy te, szinte ijesztő :O

Akkor idézzünk, hogy te is rájöjj, mekkora balfasz vagy:
>En ugyan nem vagom, mi az optimalizalas abban, hogy osszetett adattipusok eseten konstans pointerekel dolgozol ertek szerinti atadas helyett,
Na, NA vajon mi? Ugyan mi lehet abban az optimalizálás, hogy másolás helyett csak a címét passzolgatom tovább egy nagyobb adatszerkezetnek? Nem is értem, de majd "tanult" kollégám idézete rávilágít: "Ezt eleg konnyu belatni, ha a masolasra gondolsz, ami mind CPU ido, mind stack meret szempontjabol problemas."

>de valoszinuleg megint a vilag csinalja rosszul, mert en nem ismerek olyan C/C++ API-t, ahol a te megoldasodat prefereljak. Ez vajon miert lehet? Na mindegy.
Az APIk nem indulhatnak ki abból, hogy olcsó lesz a másolás. A kérdező nem API-t ír, csak egy egyszerű tanuló, akinél sokkal többet számít az olvasható kód, mint az űberhatékonyság (amit fentebb kifejtettem, nem is feltétlenül a nem-másolás fog elhozni).

Valami oskolát elvégezhetnél azért, a "hogy csináljunk magunkből hülyét" diplomád után. Már ha folytatni akarod a szakmai témában okosítást.
----
India delenda est.
Hülye pelikán

Szoval csak folytattad. Na nem baj, most mar nem csak azt tudja a vilag, hogy C/C++ programozashoz nem ertesz, hanem szoftverfejleszteshez altalaban nem. Ugyanis amin te itt porogsz, abban bizvan, hogy picinyke agyacskadban fellobbant valami langocska, aminek termeket vegre hadba kuldheted a konstans pointerekkel feldiszitett zaszlojat eloreszegezve adazan radtamado technokrata vilag ellen, szoval az nem optimalizalas, meg veletlenul sem az. Az nem optimalizalas, hogy valamit megcsinalsz szarul es aztan megcsinalod ugy, ahogy a vilagon barki mas megcsinalna, aki eljutott legalabb a K&R konyv feleig, amit elolvasni es a benne foglaltakat elsajatitani osszesen kb. egy het. Kellemetlen, de neked nem sikerult.

Azt is valoszinuleg csak te erted, hogy ugyan miert okozna gondot egy kezdonek a pointeres parameteratadas olvasasa, hiszen ezt ugyis meg kell tanulnia, ha a fuggvenye nem csak read-only adatokkal dolgozik. Vagy egy kezdo ne akarjon osszetett adattipusokon valtoztatgatni, igaz? ROFL. De akkor minek egy kezdot egyaltalan holmi fuggvenyekkel osszezavarni? Ott van a main(), aztan csokolom. Minek mas, csak belebolondul szegeny. Az a helyes, ha eloszor megtanulja szarul, utana meg vagy megtanulja rendesen, vagy nem. Igaz?

Ami a mondanivalod, ha egyaltalan volt olyan, utolso sorait illeti. En megertem a frusztraltsagod, tenyleg. Szar lehet, hogy allandoan megakasztja valaki aldasos tevekenysegedet, amivel gorcsosen probalod az agyadban uralkodo sotetseggel a kulvilagot beboritani, de hat ez van, "az elet nem habostorta". Egyebkent ha rajtam akarsz fogast keresni, ettol azert egy picit tobb kell, Mester! ;)

ui: nezd ma' Mester, mit talaltam, mikozben eppen drivert irok!

struct sk_buff *skb_copy(const struct sk_buff *skb, gfp_t gfp_mask)

Ha' ki csinal ilyent? He', hat ez meg az Alan Cox! Tyuazanyjat neki, ez se figyelt miko' a parameter atadast tanitottad neki! Mester!

Folytasd kérlek. Zseniális, hogy mennyire fogalmad sincs, miről szól a beszélgetés, magadnak mondasz ellent három hozzászólásodon belül, aztán még halál irreleváns példákkal is előhozakodsz, bízva az autoritás hatalmában.
Halál jól példázod, miért nem szabad egy begyöpösödött C kóder véleményére hallgatni nagyjából semmiben, és miért fontos a végzettség szemben az autizmussal (ejtsd: lelkesedéssel és megszállottsággal kódolás, teljesen autodidakta módon, minden best practicet figyelmen kívül hagyva merénjobbantudom, dogmatikus balfasz módjára bálványozva néhány kiemelt szabályt).
De írd csak a drivered nyugodtan. Biztos jó lesz.
----
India delenda est.
Hülye pelikán

miért fontos a végzettség szemben az autizmussal
Az valoban fontos, Mester. Mint ahogy az is, hogy az ember a megfelelo szavakat hasznalja, ha mar mondani akar valamit. Egyebkent annyira jo, hogy tisztaban vagy vele, milyen kvalifikaciokkal "birok". Ilyen egy igaz Mester, koveti tanitvanyai utjat! Viszont az egy kicsit hervaszto, hogy nem nezel ki belolem tobbet :(

De írd csak a drivered nyugodtan. Biztos jó lesz.
Jo szokott, maskulonben nemigen utalnanak havonta otjegyu euro osszegeket a szamlamra egy ilyen mezogazdasagi orszagban, mint ez itt. Es ezt mar 15 eve. rofl.

Igen, jól jellemzi a szakmát, hogy nem a rátermettség számít elsősorban, hanem hogy ki mekkora pofával tudja eladni magát. Ez meg neked láthatóan jól megy.
----
India delenda est.
Hülye pelikán

Szoval neked nem sikerult, kedves Mester, vegzettseged ellenere sem. Sajnalom, de lehet hogy jobban kellett volna figyelni az iskolapadban ... Azt nem tudom, hogy otthon mi a helyzet jelenleg, de itt nem a pofa a lenyeg, meg veletlenul sem. Egyebkent vegtelenul vicces, bar mar inkabb szanalmas, ahogy eloadod itt a szakit, mikozben egy db. szakmai tartalmu mondatot sem sikerult felbofognod, amibol a kerdezo tanulna. horvatha elmondta a velemenyet a temahoz, en meg normalisan es szemelyeskedes nelkul elmondtam, hogy azzal _szerintem_ mi a baj. De nem kell megfogadni a tanacsot, neked vegkepp nem, te ettol meg szemlatomast tavol vagy. Az egeszben az a jo, hogy meg csak nem is egyedul voltam a velemenyemmel, de persze teged ez sem gyozott meg, Mester! Igy is van jol, az ember legyen kovetkezetes. Vagy csak egyszeruen ostoba ;)

nem szabad egy begyöpösödött C kóder véleményére hallgatni nagyjából semmiben

Ez a kedvencem. Valoban felhaborito, hogy C koderek rohangalnak szabadon egy C/C++ temaju forumon! Hallatlan, botranyos! Te, nem lehet hogy eltevedtel? Mondjuk ez a hozzaszolasaidat megmagyarazna. Sajnalom, hogy elpasszoltad az openlog()-os partit a napokban, ott is lubickolhattal volna. rofl

Most viszont mar nincs tobb idom rad Mester, mert meg kell egy kis prototypingot csinalnom, ha esetleg lenne Python kerdesed, dobj batran egy pm-et! ;)

Tkp. mi a problémád?

Nagyjából azt a javaslatot kritizálod itt, hogy "csak akkor használj pointert átadásra, ha muszáj... aztán majd alakul".

Mi ezzel a gondod? Hogy nem tanulja meg azonnal a dolgot úgy, mint ahogyan most te tudod? Lehet.
Majd ráerősít azzal, hogy direkt változók helyett is pointereket használ mindenre, hogy aztán majd 10 év múlva lecseszhessen valakit azért, mert az nem úgy csinálja.

Szerintem felreertettel valamit. En ezt kritizaltam, mint okolszabalyt:
hacsak nem egy brutál méretű struct-od van, mindenképp érték szerint add át
Ez nem jo.

""hacsak nem egy brutál méretű struct-od van, mindenképp érték szerint add át""
"Ez nem egy jo tanacs...."

Egy része tényleg kérdéses. Azzal Te is egyetértesz, hogy float-ot vagy int-et nem érdemes mutatóval átadni, ha nem akarjuk módosítani. Az egyetlen különbség a Te és az én véleményem közt a nem túl nagy méretű struct-ok esetén van. Ha ilyet érték szerint adunk át, gyorsabb kódunk lehet, ezt el is ismerted. Én pedig a kérdésnek megfelelően csak erre koncentráltam. Úgy értettem a kérdést, hogy a kérdezőnek extrém fontos a kimeneti kód sebessége, és ennek megfelelően válaszoltam.

A program fejlesztése szempontjából persze hogy a mutatós megoldás a jó struct esetén, és én magam is (bár hajlamos vagyok az agyonoptimalizálásra) mindig pointerrel adom át a structot, hacsak nem igen kifejezetten tudom, hogy ez később is kisméretű marad (pl. egy kétdimenziós float vektor esetén). Tehát lényegében ugyanazt mondjuk, csak a kérdés hangsúlyát értettük máshogy.

Azaz a korrigált tanulság: ha nem akarod megváltoztatni az értékét, akkor float, int, double, char stb. érték szerint adandó át. struct-nál a kód fejlesztése szempontjából mindenképp a mutatós átadás a célszerű. Ha extrém fontos a kimeneti kód sebessége és lehet tudni, hogy a struktúra nem fog bővülni, akkor a kisméretű struct-ok esetén az érték szerinti átadás a javasolt.

(Továbbá: Nyilvánvaló, hogy az inlineolás nemcsak a paraméterátadás miatt gyorsít, hanem amiket írsz és még ráadásul a beinlineolt kóddal könnyebben kezd valamit az optimalizáló, ha nem kell a pointerekkel szórakoznia, amikor pointerrel adod át a paramétert.)

(És ha már precízkedünk: nem ajánlottam együtt a "-O3"-at és a "-finline-functions"-t. Külön idézőjelben voltak.)

Korrekt. Jo, hogy van valaki, aki erti is amit ir, es azt is, amit mas ir. Ez lenne a lenyege egy forumnak :)

Örülök, hogy legalább egy délutánra sikerült feldobnom a kedved, lehet kevesebb hiba lesz egy driverben, ki tudja. Érdemi fejlődést nem fogok tudni elérni nálad, az nyílvánvaló, dehát kellenek a viszonyítási pontok is, maradj csak stabilan értetlenkedő :)
----
India delenda est.
Hülye pelikán

"Azaz a korrigált tanulság: ha nem akarod megváltoztatni az értékét, akkor float, int, double, char stb. érték szerint adandó át. struct-nál a kód fejlesztése szempontjából mindenképp a mutatós átadás a célszerű. Ha extrém fontos a kimeneti kód sebessége és lehet tudni, hogy a struktúra nem fog bővülni, akkor a kisméretű struct-ok esetén az érték szerinti átadás a javasolt."

Szep osszefoglalasa a topicnak. En is ugyanezeket a tanulsagokat szurtem le a valaszokbol. (Btw nem volt extrem fontos a seesseg, egy altalanossagban helyes valaszt szerettem volna kapni a kerdesemre, ami meg is tortent.)

Egy valamin atsiklottam korabban, na igen, a zarojelek atka ;) Az inline temahoz meg annyit tennek hozza igy utolag, hogy az optimalizalas szempontjabol az esetek nagyreszeben mindegy, melyik modszert valasztod a parameteratadasra, ugyanaz a kod lesz a vegeredmeny. Kulonbseg akkor lehet pl. ha a parameterkent atadott strukturad tomboket tartalmaz, ebben az esetben viszont inkabb a pointeres megoldas fele billen a merleg nyelve. De hat a puding probaja az eves, es ez mar tenyleg nem ehhez a topikhoz tartozik, viszont ha megkeritek az autizmust sajatosan ertelmezo tanult, pardon, vegzett mesteremet, tetrat, bizonyara ir egy kulon bejegyzest az optimalizacio temakoreben. O szakertoje a temanak, hiszen a leveset is eloszor villaval kezdi el enni, aztan amikor az mar kihult, optimalizal es a kanalert nyul ;) Na, most mar tenyleg nincs tobb idom erre, ugyhogy ennyi.

Nincs több időd rá két driver fejlesztése közben, de még mindig ezen pörögsz. Hiteles vagy nekem te tibor.
----
India delenda est.
Hülye pelikán

Tibor??? En elhiszem, hogy szakmai kielegitettlenseged okozta frusztracio kivetul a maganeletedre is, de szerintem nem tul szerencses, ha mindenkiben viszonzatlan tinedzserkori szerelmed targyat veled felfedezni, Mester! ;) De ne izgulj, rad mindig lesz par percem. De most inkabb dolgozom ... helyetted is, te csak szakerts itt tovabb! lol

Ez egyre gyengébb, Tibor. Feljebb még azt mondom, egy laikus, jóhiszemű hobbiinformatikust még meg tudtál téveszteni, de ez már nagyon izomszagú vergődés.
----
India delenda est.
Hülye pelikán

Koszonom a valaszokat, tanulsagos volt olvasni oket.

Majdnem minden tiszta, egyedul a struct-oknal van nemi egyet nem ertes a valaszokban. Bar a konzisztencia megtartasa erdekeben elonyosnek ereznem, hogy azokat is ertekkent adjam at, legalabbis addig, amig nincs mukodo kod, ugy gondolom, hogy meretuktol fuggetlenul a pointeres megoldast valasztom.

- Egyreszt, ahogy latom, teljesitmenybeli problemak pont nagy struct-oknal jonnenek elo valoszinuleg
- NevemTeve hozzaszolasa, valoszinuleg struct-ok eseteben igy marad a legolvashatobb a kod
- kezdem amugy is megszokni, hogy struct-hoz jarjon egy typedef struct x* XPtr es vegig az XPtr->y format hasznalom mindenhol, ami eleg szimpatikus es olvashato megoldas egyben*

Ha ezeket a meglatasokat illetoen van velemeny, vagy kritika, szivesen olvasom, egy ideig meg nem cimkezem fel megoldottkent a topicot.

(Bocs, hogy csak most irok, a topic-ot kozvetlenul elalvas elott nyitottam reggel, delutani ebredesem ota pedig nem tul sok idot toltottem a gep elott.)

*Szerk.: vagyis jelenleg ezt csinalom, mert linked list-tel dolgozom es jol jon, de ezt altalanossagban igy megoldani nagyon rosz otlet? Mert bar "logikai" szinten bonyolitja a dolgot, a kodot olvashatobba es egysegesebbe teszi szamomra

> kezdem amugy is megszokni, hogy struct-hoz jarjon egy typedef struct x* XPtr

Ez csak addig hasznos, míg meg nem szokod, hogy a '*' pont azt jelenti, mint a 'Ptr'... egyébként a MS is csinálja ezt, ha mondjuk definál egy RECT típust, rögtön csinál hozzá egy PRECT pointert is. Nincs előnye, de nem hiba.

Annyi előnye van, hogy ha építesz egy tömböt ezekből a pointerekből, és azt akarod átadni, akkor annyi *-ot írsz ki, ahány dimenziós a tömb. Vagyis nem keveredik a * szerepe.

+1, sok csillagos dolgoknál (és ez nem feltétlen a minőségi jelző:D) hasznos az ilyen:)

(Azért azt megnézném (talán egy másik topikban inkább), hogy egy 'sometype [4][6][8]' hogyan lesz kompatibilis egy 'sometype ***'-gal... szerintem sehogy)

Ha már előkerült a téma, lenne egy hasonló kérdésem: C++-ban ha már cím szerint akarunk átadni, akkor referencia vagy pointer?

Referencia előnye, hogy közvetlenül át lehet neki adni objektumot, tetszőleges cím átadásához trükközni kell (bár nem lehetetlen), a metóduson belül nem kell dereferencia ha pl. overloaded operátort kell meghívni. Ezen kívül sok helyen úgysem lehet megúszni a referenciát (pl. copy konstruktor), így egységesebb lesz az api.
Ugyanakkor a pointer használata sem úszható meg, pl. STL containerekbe nem lehet referenciákat rakni. Továbbá ha a paraméter opcionális, könnyebb egy NULL-t átadni vagy beállítani default értéknek. Mivel szintaktikailag is máshogy kell kezelni, ezért egyértelmű, hogy nem egy másolatot kapunk az objektumról (azaz ha a másolatára van szükségünk, nem fogjuk elfelejteni lemásolni).

C++-ban csak egyféle paraméterátadás van (ahogy C-ben is csak egy, az érték szerinti): az inicializálás szerinti.
A kérdésedre pedig az a válasz, hogy ha lehet értelmetlen a paraméter, akkor pointer, minden más esetben referencia. A referencia nagy előnye, hogy nem lehet "átállítani".
----
India delenda est.
Hülye pelikán

1) Érték szerinti paraméterátadás: A program az adatból csinál egy másolatot, és a másolatot a stackre teszi. A másolat készítése különféle esetekben különféle módon történhet (pontosan úgy, mint egy síma értékadásnál): Elemi adatoknál triviális, struktúráknál sekély (!) másolat, objektumoknál copy konstruktor (ami akármilyen bonyolult lehet).

2) Cím szerinti paraméterátadás: Nem készül másolat az adatból, hanem az adat címe kerül a stackre.

3) A C++ specialitása a referencia. Ugyanaz, mint a cím szerinti paraméterátadás, kivéve, hogy a hívott programban a derefelés automatikus.

Meg kell gondolni, hogy mikor mi kell, mi fog változni, melyik változás honnan látszik, honnan nem. Néha elemi adatot is cím szerint adunk át, ha a hívott program módosítani akarja az eredeti adatot. Ha egy összetett adatot cím szerint adunk át, akkor a hívott program módosíthatja a struktúra tartalmát/belsejét. Ez ellen nem véd a const pointer, mert a hívott program castolhat síma pointerre. Ezért értelme lehet egész struktúrák stackre pakkolásának is. Gyakorlásképpen ezeket ki kell próbálni kis példaprogramokon, tipikus módszer: printf a konstruktorból.

--
ulysses.co.hu

Ez egy technikai megközelítése a referenciának, és pont azért használunk magasabb szintű nyelvet, hogy ne kelljen technikailag megközelíteni. A referencia egy névbinding, nevet rendelsz egy más létező objektumhoz (ugye nem minden objektumnak van pl neve). Jobb így gondolni rá.
----
India delenda est.
Hülye pelikán

>> 1) [..] a stackre teszi.
>> 2) [..] címe kerül a stackre.

illetve mondjuk regiszterbe (architektúra- / hívási konvenció- / típus- / paraméterszám-függő)