A világ legdrágább egybájtos informatikai baklövése
2011-08-03T13:45:56+02:00
2015-09-27T19:43:37+02:00
2022-07-22T05:13:19+02:00
  • Butaságokat beszélsz, nyuszika;)
    Egyébként meg nincs benne olyan, hogy ://, hanem olyan van, hogy séma: és olyan, hogy //authority vagy kifejtve //[userinfo@]host[:port] namostan ez a rész hiányozhat is, pl: mailto:user@somewhere, file:/etc/motd
    Mutasd a teljes hozzászólást!
  • Szerintem a :// igen hasznos. Ránézek, és rögtön az jut eszembe, hogy bal oldalán protokoll, jobb oldalon elérési út. A :/ -ról (pláne a : -ról) egész más jut eszembe (c:/temp, :ext:server:/cvs). Amúgy olyanok is vannak, hogy

    ftp://
    rtsp://
    mms://
    sőt dvd://

    is, nem csak http és https
    Mutasd a teljes hozzászólást!
  • Na itt kezdődik az, hogy te is kezdesz másról beszélni, meg én is.
    Te leírod, hogy ez hogyan működik most, olyan előzményekkel, ahogy indult.
    Eredetileg meg arról volt szó, feleslegesen erőszakolták bele a plusz /-t a szabvány("szabvány"?)ba.
    Mindegy, sohasem fogjuk megérteni egymást...
    Mutasd a teljes hozzászólást!
  • Persze, mert a böngésződ kiegészíti.
    Mutasd a teljes hozzászólást!
  • És ez miben különbözne a
    <a href="/google.com/">katt</a>
    változattól, amennyiben nincs kötelezővé téve a dupla /?

    Attól, hogy ez hoszt-relatív cím. Pl. ha ebben a topikban szerepelne egy "<a href="/google.com/">" hivatkozás, az kifejtve a "http://prog.hu/google.com/" címre mutatna. Ezzel szemben az "<a href="//google.com/">" hivatkozás a "http://google.com/" címet jelenti kifejtve. A "<a href="google.com">" pedig kifejtve a "http://prog.hu/tarsalgo/138263/google.com" abszolút url-nek felelne meg. Mindegyik cím az url egy-egy másik komponenséhez képest relatív, és a perjel ill. a duplaperjel pont azt jelöli ki, hogy melyikhez képest. Ha nem duplaperjellel lenne bevezetve a protokoll-azonosító után része az url-eknek, nem tudnál a protokollhoz képest relatív címet megadni, mert nem lenne olyan bevezető szekvencia, amely az url-nek csakis abban a részében fordulhat elő érvényesen.

    Mit veszítesz azzal, ha a hivatkozás gyökerét egy perrel, a relatív hivatkozást / nélkül adod meg?

    Szerintem te nem érted ezt az url-esdi dolgot, és azt, hogy egy hivatkozás az url több komponenséhez képest is lehet relatív. Amik közül mindegyik nagyon gyakran ki van használva, csak ez a protokoll-relatív hivatkozás nem nagyon. Ennek (mármint a relatív url-eknek, és hogy mihez képest lehetnek relatívak) kellene utánanézed.

    A relatív formák:
    1. protokoll-relatív: "//..."
    2. hoszt-relatív: "/..."
    3. könyvtár-relatív: "..."
    4. path-relatív: "?..."
    5. query-relatív: "#..."

    Mindegyik esetben az egyben az adott fragment elválasztóját is képező karakter ill. szekvencia (ill. a könytár-relatív hivatkozások esetén annak hiánya) határozza meg és jelöli ki teljesen egyértelműen, hogy az url mely részéhez képest relatív az adott cím. Ha a protokoll-t nem "//" hanem csak "/" választaná el a hosztnévtől, akkor ez nem lenne lehetséges. A ":/" pedig azért nem lehetne jó szelektor, mert ez az url-ek path részében is teljesen érvényes szekvencia, így önmagában lehetne érvényes relatív hivatkozás is (miközben a "//" nem, mert az nem érvényes szekvencia az url-nek a path részében).
    Mutasd a teljes hozzászólást!
  • Szerintem ez szintaktikus hiba, de próbáljuk ki: //google.hu
    Szerkesztés: És működik!
    Mutasd a teljes hozzászólást!
  • És ez miben különbözne a
    <a href="/google.com/">katt</a>
    változattól, amennyiben nincs kötelezővé téve a dupla /?
    Az <a href...> eleve megmondja, hogy ez egy hivatkozás.
    Mit veszítesz azzal, ha a hivatkozás gyökerét egy perrel, a relatív hivatkozást / nélkül adod meg?
    Mutasd a teljes hozzászólást!
  • Ezt a protokoll-relatív szerver-domaint tudnád példával szemléltetni?

    Nem "protokoll-relatív szerver-domain", hanem protokoll-relatív hivatkozás vagy url. Amúgy meg persze:

    <a href="//google.hu/">Katt ide a google.hu megnyitásához</a>

    Megjegyzés: .html fájlba lementve és kattintással megnyitva ne próbáld ki, mert nem fogja a várt eredményt produkálni, ekkor ugyanis a böngésződ file:// protokollon keresztül fogja próbálni megnyitni a google.hu-t (lévén a befoglaló dokumentumot is azon keresztül érte el, és az url ahhoz képest relatív, ugye), ami nem fog menni; de ha http-n keresztül egy akár lokális webszerveren megnyitott oldalba ágyazod be a fenti kódot, akkor simán fog működni. ha az oldal pedig pl. https-en lett megnyitva, akkor a fenti hivatkozás a google.hu-t is https://google.hu/-n keresztül próbálja majd elérni.


    A dolognak - ahogy korábban is írtam - elsősorban olyan rendszerek esetében lehetett jelentősége, ahol fizikailag ugyanaz az egy (de több szerverre/tartományra szétszórt) dokumentumhalmaz több alternatív protokollon is elérhető volt. Ekkora a protokoll-relatív url-ekkel úgy lehetett univerzális linkeket építeni a dokumentumhalmazon belül, hogy a linkek sosem kényszerítették protokollváltásra a klienst, mégis több protokollon keresztül is elérhetők voltak.

    Manapság nagyon már nincs ilyen; maximum az lehet, hogy ugyanaz az oldal http-n és https-en is elérhető. Ilyen esetekben ha az adott dokumentum a stíluslapjait, szkriptjeit, stb. egy CDN hálózaton keresztül terjeszti és tárolja, akkor az azok eléréséhez használt protokollt mindig a a lap megnyitásához használt protokollhoz kell igazítani - egyébként ugyanis "mixed content" figyelmeztetést kap az ember (ti. ha egy https lapból http protokollon keresztül elért assetre hivatkozik, vagy fordítva). Na, maximum itt jöhet jól manapság ez a lehetőség - bár valószínűleg 1000 oldalból 999 nem fog élni vele, hanem egyszerűen csak a használt protokoll függvényében formázott teljesen abszolút url-ekkel hivatkozik majd rájuk.
    Mutasd a teljes hozzászólást!
  • Ezt a protokoll-relatív szerver-domaint tudnád példával szemléltetni?
    Mutasd a teljes hozzászólást!
  • Legyen a : és az első :-ig számítson a protokol neve

    Legyen minden protokol 4 betű és akkor az se kell.
    Mutasd a teljes hozzászólást!
  • Nem, mert ahhoz, hogy ez működhessen a ":"-t is speciális, kódolandó karakterként kellene kezelni - hiszen csak ekkor lenne garantálható, hogy az url elérési út részében nem szerepelhet sose a ":/" szekvencia, és így nem lehetne érvényes relatív hivatkozás is ":/"-vel kezdődő.

    Ezzel szemben a jelenlegi formátum esetében csakis a "/"-t kell speciális karakterként kezelni és kódolni (%2f) ahhoz, hogy egyértelmű maradjon minden körülmények között, hogy egy "/"-rel, "//"-rel vagy akár ":/"-rel kezdődő hivatkozás relatív -e, és ha igen mihez képest.
    Mutasd a teljes hozzászólást!
  • akkor módositok: legyen a :/ a protokol elválasztó és ezt a kombinációt nemlehetne használni az elérési utakban :)
    Mutasd a teljes hozzászólást!
  • "pont a dupla perjel teszi lehetővé a protokoll-relatív címek megkülönböztetését a szerver/domain-relatívektől"
    gondolom erre a kettőspont + 1 darab per jel elég lenne. a második per jel már fölösleges.

    Nem, mert a ":/" érvényes szekvencia az elérési út részeként is, így egy ezzel kezdődő hivatkozás lehet bázisrelatív hivatkozás is (sőt, definíció szerint az). Ezzel szemben a "//" nem érvényes szekvencia az elérési utakban (mert nincs is értelme ugye, hiszen üres nevű könyvtár, algyűjtő, stb. nincs), hanem csak az elérési út elemeinek részeként szerepelhet, ahol viszont ilyenkor kódolva kell lennie (%2f%2f). Így ha "//"-vel kezdődik egy hivatkozás, akkor egyértelmű, hogy protokollrelatív, míg a ":/" alapján nem lehetne eldönteni, hogy mihez képest szánták relatívnak a címet.
    Mutasd a teljes hozzászólást!
  • Egy másik: van pár standard függvény (pl. qsort, bsearch), amelyik callback-függvényt használ, de a callback-hez nem adhatunk meg úgynevezett 'felhasználói paramétert'... ilyenkor vagy globális változókon keresztül kell kommunikálnunk a callback-kel (béna, pl multi-threadnél meg különösen), vagy több callback-et kell definiálnunk, amelyek esetleg csak a kívánatos memcmp hosszában különböznek egymástól.
    Mutasd a teljes hozzászólást!
  • Valószínűleg ugyanaz volt a kitaláló(k) fejében, mint az összes többi tervezési döntésnél ( c string akár): "akkor jó ötletnek tűnt"
    Mutasd a teljes hozzászólást!
  • Azért ne felejtsük el, hogy a C filozófiája nem az, hogy a programozót áldott tudatlanságban tartsuk az implementáció részleteiről: C-ben OS-kernelek és adatbázismotorok készülnek, fájlokon és socketeken keresztül kommunikálunk más gépeken futó és más nyelven írt programokkal, RFC-ket implementálunk, itt nem megy az, hogy 'á biztos ábrázolja valahogy a stringeket (számokat, stb), kit érdekelnek a részletek'

    Például, egy C programozó tudja (vagy legalábbis tudnia kellene), hogy ha 's' egy string s nem üres, akkor s+1 szintén egy string, tartalma 's' vége... ez néha hasznos, és a hossztényezős módszer erre tényleg nem képes. De ha (hossz, cím) párokat tárolunk, akkor sokkal de sokkal flexibilisebbek lehetünk, pl (hossz-1, cím+1) a string végét jelenti, (hossz-1, cím) a string elejét.
    Mutasd a teljes hozzászólást!
  • (Szvsz mind a két perjel felesleges az URL-ben... talán arra gondolt a derék feltaláló, hogy pl a ftp://user:jelszo@szerver.hu -szerű URL jobban elemezhető, mint a ftp:user:jelszo@szerver.hu... nem látom be, miért lenne így)
    Mutasd a teljes hozzászólást!
  • "
    Egyet kell értsek veled: a fától nem látott erdő tipikus példája, és a dobozon kívüli gondolkodás képtelenségéből adódnak az ilyen dolgok. Mint pl. az az ötlet ill. probléma is, hogy "de hát akkor akkor az első hányadik karakteren tároljuk a hosszot".
    "
    értem én a "cinikus" megjegyzésed, de ezek szerint nem érted azt amit leírtam, vagy csak nem akarod érteni... vagy csak tényleg én nem értem, hogy most kötekedni akarsz-e vagy csak...

    "
    Innentől kezdve különösen visszás, hogy a sztring esetében viszont - ami ráadásul valahol átmenet az elemi és az összetett típusok között - pontosan rögzíteni próbálja a "nyelv", hogy az hogyan van ábrázolva a memóriában;
    "
    ugyanannyira rögzítette, mint az összes többit: x bit egymás mögött a memóriában, semmi mást nem mond róla, legfeljebb annyit, hogy egy literál esetén a végére "odarak" még egy '\0'-t a következő helyre...

    "
    Mindezt úgy, hogy közben ezt semelyik másik elemi vagy összetett típusa esetén nem teszi (pl. struct-ok esetében sem rögzített hogy pontosan hogyan is kell azok elemeinek illeszkedniük egymáshoz).
    "
    a struct-nál is ugyanaz az elv: x bit egymás után, az elemek illeszkedése meg programozói szempontból valójában miért számítana? pont az lényeg, hogy az optimalizálva legyen az adott környezethez, arról hozzon döntést az adott fordítóprogram írója,

    "
    Na persze, az alapprobléma ugye az, hogy a sztring, mint elemi vagy összetett típus nem is létezik a C-ben. Egyszerűen csak a standard könyvtár révén képes a kezelésükre;"

    igen, mint típus nem létezik, miért is kellene léteznie? jah, mert most már elvárnánk?

    "
    kvázi az egész sztringkezelés csak mint egy afterthought lett belehekkelve a nyelbe...

    ezt honnan tudod/veszed, beszéltél dmr-rel, vagy milyen publikus információd van az "afterthought"-ot illetően?

    "
    legkésőbb a mikrogépek korában ki kellett volna halnia, amelyek BASIC-je fejlettebb volt már nála.
    "
    nem akarok hasonlítgatásokba belemenni, de miért lenne fejlettebb egy olyan nyelv, amelyik mentes a szükséges változódeklarációtól ("ismerem" a "legtöbb" HC Basic-et, tudom, hogy "lehetségesen" van...)

    "
    De ha a C valóban ismerte volna a sztring, mint elemi típus koncepcióját, teljesen irreleváns lett volna az, hogy hogyan, hol és milyen hosszon tárolja annak hosszát.
    "
    nem ismerte, mert nem is akarta, mint önálló/valódi típust implementálni, ugyanúgy, ahogy halmazt/vermet/sort/fát/gráfot/... sem,

    "
    Ami biztos: "nem az első n char-on" tárolta volna - és így nem lett volna kérdés ill. probléma, hogy n értéke mennyi is legyen, hogy elég rugalmas, de mégis elég takarékos legyen. ... Amely hibába az esik, aki nem tud a C - a fent kifejtett módon ezeket a koncepciókat valóban teljesen tévesen és hibásan erősen összemosó - paradigmáin kívül gondolkodni.
    "
    abban igazat adok neked, hogy egy adott programnyelv használójának nem sok köze kell, hogy legyen az adott nyelv elemi adattípusainak ábrázolásához, de itt pont nem (csak) ezen megy a "gumicsont" rágása, hanem ez a vonzata is van: ha nem jó a '\0', akkor mi lett volna a jobb, hogyan lett volna célszerűbb implementálni,


    olyat kértek számon egy programnyelven, annak alkotóján, ami nem is volt célja a tervezőnek, szerintem egyszerűen nem arról szól, amit belegondoltok; nem akarlak bántani titeket, de biztos vagyok benne, hogy mindegyik "kifogásoló" valamilyen "absztraktabb" nyelvvel találkozott elsőre, olyannal amelyikben volt sztring "típus", ezért képtelen megérteni a C filozófiáját,

    tényleg nem értelek titeket: a C egy "szikár" nyelv, pont az a szép benne, hogy mentes mindenféle sallangtól, kivételtől, szerintem ennek is köszönheti a sikerét, én pld. ezért "szeretem", az ilyen elvek miatt,
    Mutasd a teljes hozzászólást!
  • OFF

    Egy másik problémás rész szerintem az 'errno'...

    van: handle= open(name,mode); if (handle<0)...
    lehetne: err= open(&handle,name,mode); if (err)...


    Szerintem meg a legszebb* így lenne:
    handle, err = open(name, mode);
    csak hát van a C-ben egy önkényes megkötés, hogy egy függvénynek legfeljebb egy visszatérési értéke lehet.

    *legszebb, ha nem tudunk/akarunk kivételeket használni. A kivételek olyan overhead-et jelentenek, amit nem célszerű mindenkire rákényszeríteni.
    Mutasd a teljes hozzászólást!
  • Ez a dupla perjel az szerintem is sok problémát okoz, de nem számítástechnikában.

    pl. egy kamion oldalán
    http://www

    Ez elég sok felesleges festéket igényel.
    És persze minden nyomtatványon...

    Egy kicsit fúra ez a topic.
    Már az hogy elmélkedünk egy forumon az a bekapcsolt gépek, szerverek, hálózatok révén esőerdőkbe kerül.
    Vagyis pazarlóan beszélünk ki valamit ami egy idióta szerint pazarló...

    Mutasd a teljes hozzászólást!
  • pont a dupla perjel teszi lehetővé a protokoll-relatív címek megkülönböztetését a szerver/domain-relatívektől


    gondolom erre a kettőspont + 1 darab per jel elég lenne. a második per jel már fölösleges.
    Mutasd a teljes hozzászólást!
  • Azt kiszámolta már valaki, hogy az URL-ben használt dupla per mennyivel került többe a világnak, mintha szimpla per lett volna? Arra emlékszem, hogy a kitalálója elismerte: felesleges a duplázás...

    Ezt nem hiszem, hogy így lenne (mármint, hogy értelmetlen lenne), mert hogy pont a dupla perjel teszi lehetővé a protokoll-relatív címek megkülönböztetését a szerver/domain-relatívektől. Ezen keresztül lehetőséged van olyan URL-ek megadására is, amelyek bár más szervereken lévő erőforrásokra hivatkoznak, mégis a protkollt nem jelölik ki explicit, hanem azt mondják, hogy a böngésző használja ugyanazt, amivel a befoglaló dokumentum is megnyitásra került.

    A dolog gyakorlati jelentősége manapság kicsi (mivel kizárólag HTTP-n keresztül érünk el mindent a böngészőben, így maximum a http/https megkülönböztetés jöhet szóba), de el tudom képzelni, hogy anno, a web kitalálásakor, amikor még más hypertext protokollok is dívtak (mint pl. a gopher) komolyan haszna lehetett a dolognak, mert pl. lehetővé tehette, hogy az akár több protokollon keresztül is elérhető, de külső forrásokra is hivatkozó dokumentumok ugyanazon egy példányból kerülhessenek kiszolgálásra, a protokoll-agnosztikus url-ek révén.
    Mutasd a teljes hozzászólást!
  • Azért azt nem kéne elfelejteni, hogy egy olyan, ősi maradványról vitatkoztok, aminek a születésekor kilobyte-okban számolták a memóriát (és megabyte-okban a diszket), a programnyelveket meg akkoriban kezdték kitalálni.
    Egyébként nekem még úgy tanította valamelyik C-ben jártas kollégám, hogy C-ben se számítsak arra, hogy a string végét egy null karakter terminálja. Használjam a C beépített függvényeit, mert ez a null bármikor eltűnhet.
    Mutasd a teljes hozzászólást!
  • Egyet kell értsek veled: a fától nem látott erdő tipikus példája, és a dobozon kívüli gondolkodás képtelenségéből adódnak az ilyen dolgok. Mint pl. az az ötlet ill. probléma is, hogy "de hát akkor akkor az első hányadik karakteren tároljuk a hosszot".

    Mert hogy a dolog nem erről szól. Egy változó, adatterület, adatszerkezet memóriabeli reprezentációja fordító ill. futtatókörnyezet szintű, implementációs, nem pedig nyelvi szintű koncepcionális kérdés. Az, hogy hol és hogyan tároljuk (vagy tároljuk -e egyáltalán) egy sztring hosszát teljesen irreleváns - ill. irrelevánsnak kell lennie - mindaddig amíg a nyelv keretei között maradunk. Egyszerűen csak azt kell tudnunk ill. definiálnunk, hogy a sztring hosszát hogyan (milyen nyelvi szerkezettel) lehet lekérdezni. És itt tök mindegy, hogy pl. egy strlen() függvényhívással (C, PHP, stb.), a sztring úgymond nulladik indexének kiolvasásával (pl. Pascal, Delphi), vagy a sztring length jellemzőjének lekérdezésével (pl. C#, JavaScript) tudjuk a hosszot lekérdezni - mint ahogy az is, hogy valójában ez a lefordított kódokban milyen műveletsort valósít meg. A lényeg, hogy megkapjuk a sztring hosszát és kész. Az, hogy hol és miként ill. hogy tárolja -e egyáltalán a sztring hosszát, a fordító ill. a vele 0sszedrótozott RTL dolga - semmi közünk hozzá.

    Ha végiggondolod, ez más típusok esetében is így van, még a C-ben is. Hiszen még - ahogy magad is megjegyezted - az elemi egészeknek sincs a memóriabeli tárolási módja rögzítve, definiálva a nyelv szintjén; nem csak a hossz, de a bájtsorrend vonatkozásában sem. Innentől kezdve különösen visszás, hogy a sztring esetében viszont - ami ráadásul valahol átmenet az elemi és az összetett típusok között - pontosan rögzíteni próbálja a "nyelv", hogy az hogyan van ábrázolva a memóriában; sőt, a memóriabeli reprezentáció határozza meg kvázi a sztringek kezelését, ami nem függetleníthető attól. Mindezt úgy, hogy közben ezt semelyik másik elemi vagy összetett típusa esetén nem teszi (pl. struct-ok esetében sem rögzített hogy pontosan hogyan is kell azok elemeinek illeszkedniük egymáshoz).

    Na persze, az alapprobléma ugye az, hogy a sztring, mint elemi vagy összetett típus nem is létezik a C-ben. Egyszerűen csak a standard könyvtár révén képes a kezelésükre; kvázi az egész sztringkezelés csak mint egy afterthought lett belehekkelve a nyelbe - és ez okozza az összes ekörüli galibát. (Ez egy óriási probléma, és már önmagában emiatt nem szabadott volna soha elterjedt nyelvvé válnia ill. megmaradnia, és legkésőbb a mikrogépek korában ki kellett volna halnia, amelyek BASIC-je fejlettebb volt már nála.) De ha a C valóban ismerte volna a sztring, mint elemi típus koncepcióját, teljesen irreleváns lett volna az, hogy hogyan, hol és milyen hosszon tárolja annak hosszát.

    Ami biztos: "nem az első n char-on" tárolta volna - és így nem lett volna kérdés ill. probléma, hogy n értéke mennyi is legyen, hogy elég rugalmas, de mégis elég takarékos legyen. Ez a problémafelvetés csak a sztring, mint logikai koncepció és elemi adatszerkezet, valamint a fizikai adatábrázolás közti különbség teljes meg nem értéséből ill. összemosásából adódó felvetés. Amely hibába az esik, aki nem tud a C - a fent kifejtett módon ezeket a koncepciókat valóban teljesen tévesen és hibásan erősen összemosó - paradigmáin kívül gondolkodni.
    Mutasd a teljes hozzászólást!
  • Azt kiszámolta már valaki, hogy az URL-ben használt dupla per mennyivel került többe a világnak, mintha szimpla per lett volna?
    Arra emlékszem, hogy a kitalálója elismerte: felesleges a duplázás...
    (igaz, ez valamivel ritkább, mint a 0 terminált stringek, amiket COBOL, IBM/360 Assembly és minimális Pascal előélettel kicsit nehéz volt megemészteni )
    Mutasd a teljes hozzászólást!
  • Ezt nevezzük csúsztatásnak;)
    Igaz, hogy a C bevált és elterjedt. Igaz, hogy a pointerek kezelése flexibilis és elegáns. Mindebből egyáltalán nem következik, hogy a null-terminált string jó ötlet lenne.
    Egy másik problémás rész szerintem az 'errno'...

    van: handle= open(name,mode); if (handle<0)...
    lehetne: err= open(&handle,name,mode); if (err)...
    Mutasd a teljes hozzászólást!
  • ha már így újra szóba került...

    szerintem nagyon helyesen az "extremális elem" filozófiáját követték,

    aki ezek alapján megkérdőjelezi a döntés helyességét, annak ezek szerint a legtöbb programozási nyelvvel problémája van, csak nem látja a "fától az erdőt", szinte az összes ma elterjedt népszerű nyelvben használnak extremális elemet, csak legfeljebb nem "String" "környezetben", azokkal mi van, azok miért nem bántják a kritikusok szemét?

    egyébként meg az első x biten tároljuk a hosszat miért lenne jó egy általános programnyelv esetén? egyből kérdezhetnénk, hogy mennyi biten is? direkt bitet írok és nem byte-ot, mert a 70-es évek elején még simán léteztek 7 bites gépek is, stb., én is dolgoztam igaz még/már a kilencvenes években 7 bites gépen...

    szerkesztve: persze mondhatja valaki azt, hogy ne lovagoljak az x biten, hiszen a char, int, ... méretekre sincs explicit kikötés, de akkor is, szerintem az első n char-on tároljuk a hosszat rosszabb választás lett volna,
    Mutasd a teljes hozzászólást!
  • Vagyis ha egy mágnesszalagon kiírtál egy stringet és a végére tettél egy záró markert ez a fizikai megvalósítással pariban van, míg visszatekerni, hogy az elejére beszúrjuk a hosszot, az már nonszensz volt!

    Ez az érvelés két okból is téves. Egyrészt, mert a memóriában és egy adott karakterisztikákkal rendelkező háttértárolón nem feltétlenül ugyanaz az adatformátum használata célszerű (sőt!) - tehát az, hogy a szalag szempontjából mi praktikus és mi nem, önmagában nem lehet minden más megfontolást lemosó érv annak meghatározásában, hogy az operatív memóriában hogyan érdemes ugyanazokat az adatokat reprezentálni. Másrészt olyan nincs, hogy ki akarok írni egy elemi adatot (egy sztringet), de amikor elkezdem még nem tudom mekkora lesz. Ilyesmire csak akkor lehetne szükség, ha olyan nagy adathalmazt kérünk be, ami nem fér el az operatív memóriában, vagy ha az adatok nem folyamatosan, hanem időben elszórva érkeznek, de azonnal tárolandók - de még ekkor is megoldható (sőt, célszerű) az akár fix, akár változó hosszúságú blokkokra bontott tárolás. Amely esetben már az egyes blokkok hossza előre tudható.

    A zérus-terminált adattárolás azért sem jó, mert az ilyen elemi adatnak a beolvasása is problémás. Hiszen ha beolvasáskor sem tudom előre pontosan mekkora terület kell majd az adatnak, akkor vagy eleve a maximális hossznak (ha van egyáltalán ilyen) megfelelő területet vagyok kénytelen lefoglalni neki, vagy folyamatosan újra kell foglalni az adat tárolására használt memóriablokkot. Amikkel csak az a baj, hogy mindkét dolog pont szembemegy azzal a spórolási törekvéssel, ami az egyetlen érv lehetne a zérusterminált sztringek mellett (hogy ti. bizonyos esetekben egy ici-picit kevesebb memóriát/tárterületet esznek, mint a hossztárolt). Hisz mind a maximális hossznak (ha egyáltalán van) megfelelő blokk lefoglalása, mind a folyamatos újraallokálás pazarló - utóbbi ráadásul igen durva módon, hiszen halom-alapú memóriakezelés esetén extrém memóriafragmentációhoz és rengeteg kihasználatlan, kvázi elveszett memóriablokkhoz vezet.

    Szóval bocs, de a szalagos tárolás sem igazán igazolja a zérusterminált sztringek használatát.

    A zérus-terminált sztringek bevezetése általános célú használatra egyszerűen egy hibás döntés. Akkor is az volt, amikor a mainál jóval szerényebb kapacitásokkal dolgoztunk. Sőt, akkor még inkább az volt, mert amíg ma nem feltétlenül lassít észrevehetően és számottevően a legtöbb programon ha minden egyes sztringhossz-lekérdezés újból és újból végigszalad egy átlag 50-150 bájtos sztringen ahelyett, hogy egy - a hosszt tároló - bájtot, szót, vagy duplaszót kiolvasna, addig a mainak egytízezred, meg egyszázezred sebességével működő gépeken anno ez bizony komolyan lassította a feldolgozást. Vagy kényszerítette a programozót a hossz esetleg redundáns kezelésére, ami nem mellesleg számtalan hibához, sőt, biztonsági problémához vezethetett.
    Mutasd a teljes hozzászólást!
  • Ja még egy dolog eszembe jutott.
    Abban a korban, amikor a domináns adattárolás inkább a lyukszalag/kártya és a mágnesszalag volt, mint a diszk, akkor egy szekvenciában feldolgozható AsciiZ lényegesen jobb választás, mint egy bevezető hossz. Ugyanis nagyon problémás volt olykor a "visszatekerés", a memória meg igen drága jószágnak számított.

    Vagyis ha egy mágnesszalagon kiírtál egy stringet és a végére tettél egy záró markert ez a fizikai megvalósítással pariban van, míg visszatekerni, hogy az elejére beszúrjuk a hosszot, az már nonszensz volt!

    Mindig mindent a helyén kell kezelni!
    Ebből az egészből ez jön le csupán.
    Mutasd a teljes hozzászólást!
  • Született erről a témáról néhány könyv. Lerágott csont.
    Az egyik nívósabb pl. amit annó olvastam: "C++?? : A Critique of C++"

    Azt nem viselem jól, ha egy 40(!) éves nyelven számonkérik a jelenlegi architekturákat.
    Az AsciiZ szövegek feldolgozására készült egy olyan korra, amikor a legnagyobb gépek is csak 64K memóriákat használtak. Nagy szövegfeldolgozási problémák nem voltak, még a hosszabb stringek hossza is inkább csak tizenekben volt mérhető, mint százasokban.
    Ráadásul a feladatok töredék része volt még a szövegfeldolgozás, leginkább csak a felhasználói kommunikáció (console) szólt a szövegekről, ami leginkább karakterfolyam beolvasás és kiiratás... vagyis tipikusan hossz nélküli AsciiZ-vel jól kezelhető. Senkinek nem jutott akkor még eszébe akkora blődség, hogy XML-el kommunikáljon adatszerkezetek helyett. Nem volt realitás!

    Ráadásul ahogy valaki említette, a C egy teljesen nyitott nyelv, pont az a lényege, hogy úgy oldja meg mindenki a problémáit (pl string kezelés), ahogy az a legalkalmasabb az adott projectben.
    Ez a hatalmas előnye (ami miatt a legsikeresebb(!) nyelvé nőtte ki magát), meg ez a hátránya is, ami a C++ hatalmas hátránya is, a szerteágazó, ezerféle megoldáscsomag a problémákra.

    Én még emlékszem amikor megcsapott a pointer aritmetika zseniális egyszerűsége és nagyszerűsége. Szoros kapcsolatban a Unix cső technikájával kaptam a képembe: egy megvilágosodás volt az IBM/ESZR és a Z80 megoldásokkal összevetve.
    Mutasd a teljes hozzászólást!
abcd