Vita:PChar (adattípus)

A Programozás Wiki wikiből

Nem írnék elavultat. Számos jól működő C programot használnak ma is, amiben előfordul a char * típus. És nagy előnye, hogy rendkívül hatékonyan másolható, plusz a bejáráshoz nem kell minden betűt külön indexelni.

A C programos dolog nem érv, attól még elavult típus - C-ben is csak azért használják, mert csak azt ismeri. A String a rugalmasabb, architektúrafüggetlen, gyorsabban kezelhető, stb. Egyébként meg szerinted mennyivel másolható hatékonyabban a PChar, mint a String? Meg mi az, hogy a bejárásához nem kell indexelni minden betűt? Hogyan járod be ha nem mész végig minden indexen? Vagy azt gondolod a String elemeinek elérése bonyolultabb, mint a PChar-é? (Nem az). Sting 2010. augusztus 3., 14:52 (UTC)

Hát most ... azon felül hogy csak azt ismeri, én meglockáztatom, hogy gyorsan lehet néhány olyan C-ben írt programot találni, amiben több helyen használják (még ha készíthetők is string-sruct kezelő függvények C-ben). Én elavultnak azt hívom, amit már nem használnak, mert kiváltotta egy másik módszer. Gondoljunk csak a Win32 API-ra, azt még nem hívnám halottnak. Dehogy kezelhető gyorsabban a string, illetve esetleg bizonyos dolgokban. Ráadásul nem is programnyelv-független. Ha van egy programozási könyvtárad, és függvényargumentumként tudsz a rendszerben mutatókat átadni, stringet egyáltalán nem biztos, hogy át fogsz tudsz adni, de PChar-t biztosan. Hát azért másolható hatékonyabban, mert átmásolod a mutatót és kész vagy. Több nyelvben a string referencia-számolt, lehet fizikailag másolt, akármilyen. Egyik másolása sem nagyon lehet gyorsabb. Hát pointerrel járod be. A ciklusban a pointert növeled, vagyis amikor a betűt hivatkozod, csak egy dereference van, nincs külön ciklusváltozód, amit növelned kell. (Wide stringeknél meg szoroznod is). (Doi 2010.08.04)

Huh, itt súlyos ismereti hiányosságok vannak. Persze, hogy gyorsabban kezelhető. Összekevered az érték és a cím szerinti átadást - és PChar-nál utóbbi, String-nél meg előbbi sajátosságait emlegeted. Stringet cím szerint ugyanúgy lehet átadni és akkor az csak egy pointer átadása. Sőt, a referencia-számolt sztringek eleve csakis pointer formában léteznek (hiszen érték szerint semmi értelme nem lenne másolni a sztringet és részeként a referenciaszámlálót sem). De nem ez ami gyorsabb, hanem pl. egyszerűen a karakterfüzér hosszának megállapítása, amire számtalanszor lehet szükség futás közben, és ami PChar esetén egy potenciálisan többezer vagy tízezer órajelciklusos művelet (hiszen meg kell keresni a 0-t a füzér végén), míg String esetén egyetlen bájt vagy szó olvasása. Ezen kívül komoly korlát az is, hogy a PChar-ban pont emiatt nem tárolható ASCII 0 karakter, amely korlát String esetén nem létezik. Pontosan ezek miatt elavult - függetlenül attól, hogy mi épül még rá. Mellesleg pont emiatt kell sok helyen a WinAPI-ban hosszt is átadni a PChar mellé - tehát végső soron még abban és ott sem PChar került átadása, hanem gyakorlatilag egy pointer+hossz, ami végső soron pont egy String. A nyelvfüggetlenséggel kapcsolatos megjegyzésednek megint nem sok teteje van, hiszen pl. Pascal-nak ugyanannyira nem natív típusa a PChar, mint amennyire a C-nek nem az a String; tehát egyikben sem különösen egyszerű a másikat kezelni; ugyanakkor nem is rendkívül bonyolult, és nem bonyolultabb, mint akármilyen másik struktúrát kezelni, amik szintén részét képezhetik egy platformok közötti API-nak. A bejárás kapcsán szintén tévedsz, hiszen a String ugyanúgy bejárható pointerrel, mint a PChar (hiszen elemei a memóriában ugyanúgy szekvenciálisan helyezkednek el); de ráadásul a pointeres bejárás semmivel sem gyorsabb, mint a báziscímhez képesti indexelés; plusz ez implementációs részletkérdés, hogy a fordító által generált kód hogyan csinálja. Ugyanakkor ha hozzáadod, hogy PChar esetén közben keresni kell a záró ASCII 0-t is, míg String esetén előre megállapítható lépésszámú a ciklus, akkor kiderül, hogy utóbbi (String) bejárása még gyorsabb is. A WideStringes megállapításod szintén teljesen téves - ugyanis nem kell szorozni, hanem egyszerűen kettesével kell léptetni az offszetet/pointert; ráadásul teljsen nyilvánvaló, hogy ez PWideChar esetén ugyanígy, ugyanebben a formában igaz, tehát megint nem szól a String ellen. Sting 2010. augusztus 4., 14:02 (UTC)

Átnevezési javaslat[szerkesztés]

Hmm, miért PChar ennek a szócikknek a neve? Ennek az adatszerkezetnek a becses neve null-terminált sztring. Különben is Delphiben a PChar ugyanaz mint C-ben a char*, vagyis mutat egy karakterre, de nem mond semmit a karakter utáni memóriaterületről. A másik dolog, hogy nem kellene összemosni magát az adatszerkezetet a rá hivatkozó mutatóval. Null-terminált sztring lehet mondjuk fájlban vagy hálózati kommunikációban, tehát olyan helyen, ahol nem mutatón keresztül érjük el, és mégis ugyanaz az adatszerkezet.

Sőt, továbbmegyek, ezt a cikket be kellene olvasztani a String (adatszerkezet) cikkbe. A sztring mint adatszerkezet karakterek folytonos sorozata, és az már inkább implementációs kérdés, hogy hogyan tárolod a hosszát. Másképp mondva, a null-terminált sztring csak egy variánsa a sztringnek, nem más adatszerkezet.Csaboka2 2010. augusztus 7., 09:45 (UTC)

Senki sem beszélt a string ellen, sőt akkor ünnepélyesen beismerem, hogy én is stringet használok, amikor csak tudok. De. Lehet, hogy sokszor szükség van a karakterfüzér hosszára természetesen a számlálás plusz költség, de az is előfordulhat, hogy egyes szakaszokban nincs rá szükség. A 0 speciális szerepe valóban komoly hátrány lehet, sőt, a legkomolyabb hátrány a buffer overflow, ez annyira fontos, hogy a szócikkbe is be kellene írnunk, minjdárt bele is írom. Referenciaszámlálót természetesen minden értékadásnál, blokkból kilépéskor növelgetni/csökkentgetni kell, függetlenül attól, hogy programozóként ezt nem látod. Természetesen a mai Pascalokban van Char-ra mutató pointer. Ez a báziscímhez képesti indexelés remekül hangzik, de szerintem erősen fordítófüggő, hogy tényleg lesz-e ilyesmi egy indexváltozót módosító ciklusból. Ja igen. Ugye létezhet widestring, shortstring, ansistring, utf8string, java String, c++ string, ki tudja még milyen string. Általában sem a reprezentációt nem tudod, sem a műveletek pontos költségét. (valahol arról volt szó, hogy még hulladákgyűjtés is mehet a háttérben) Úgyhogy én az összevonás ellen vagyok, szerintem van string, és van pchar, és mindkettő nagyon hasznos a saját területén. Doi 2010.08.09

OK, látom te a Delphi irányából közelíted a dolgokat, és talán még egy kis fogalmi zavarban is szenvedsz. A PChar nem más, mint a ^char rövidítése, azaz karakterre hivatkozó mutató. Általában egy null-terminált sztringre mutatnak vele, de ettől még a PChar nem egyenlő a null-terminált sztringgel, mint típussal. Még ha el is fogadnánk a null-terminált sztring szinonimájának, akkor is elég zavaró lenne egy C-ben szokásos adattípust a delphis nevével hivatkozni. Kérlek, attól is szakadj el kicsit, hogy a sztring az az a Delphiben szokásos string típus. Nem attól lesz valami sztring, hogy le van tárolva a hossza, hanem attól, hogy folytonosan tárolódnak a karakterei. Ez a közös a C sztringben, wide stringben, Java sztringben, stb. A hossz tárolása ehhez képest már mellékes kérdés.Csaboka2 2010. augusztus 9., 18:01 (UTC)