A stringek sokféleségéről...
2009-07-16T14:40:22+02:00
2009-07-17T16:48:13+02:00
2022-07-25T12:42:39+02:00
  • szerintem Java-ban is úgy van mint C#-ban, ha van ilyened h

    string a = "alma";
    strinb b = "alma";

    akkor az a és a b az a memóriában ugynaz az az "alma", nem lesz két alma sosem. ha megnézitek a HashCode-ját akkor az ugyan az az objektum. vagy ha összehasonlítjátok Object-ként Equals-al.
    ha csinálsz egy olyat h b + "és körte" akkor létrehoz egy új string objektumot amiben az lesz hogy "alma és körte"
    ha nem lett volna a változónk csak b, akkor ezek után még a b-t el is takarítaná a szemétgyűjtő (vagyis ha csak ennyit csinál a program és már nem kell többé az "alma" stringünk)

    ezért is van pl String.Empty statikus mező, hogy ha üres stringet akarunk írni akkor azt ne úgy csináljuk, hogy beírjuk h "" hanem String.Empty, és így nem kell mindig új objektumot létrehoznunk ha üres sztringre van szükségünk.

    Mutasd a teljes hozzászólást!
  • Ketszer volt string valtas a borlandnal es ezzel az utobbival tobb a szivas, mint az elony szvsz.

    Az elso ugye az volt, amikor a 'string' string[255]-bol atalakult C-vel teljesen kompatibilis LongStringgé. Ezzel borult a binaris kompatibilitas, de innentol dolgozhattál akár 1GB nagysagu stringekkel is.

    A masodik 'string' atdefinialasnal pedig minden alapbol unicodestring lett, ami regen string volt, az meg ansistring lett.
    De ahogy elnézem, borland C++-ban nem csinaltak még meg default_unicodeossá a 'string'-et?

    Annyira jó lett az új 'string' és átnevezéssel el...ák azzal, hogy mindenki a DelphiAkarmi-ban irt programjait migrálgassa, mert itt még egy compiler option sincs arra, hogy UString compatibility, mint ahogy régen a string[255] es a longstring kozott volt. Szvsz korrektebb lett volna beken hagyni a regi string keywordot, majd a warning hegy alapjan szisztematikusan javitani, mert igy csak warning lenne, de nem accessviola es/vagy _minden 2. byte 0 szindróma_. :D

    A Java-s String es StringBuffer kozott sejtem, hogy mi a kulonbseg: A String-et azert nem modosithatod, mert akkor modositanad azt a memoriateruletet is, ahol az a String tarolodik. Szoval nincs benne beépített reference count, ami figyeli, hogy hányan hivatkoznak éppen az adott stringre. Ha egynél több a ref.count értéke, akkor modositasnal automatikusan lemasolodik a string es onnantol a sajat peldanyon dolgozol, az eredeti string pedig valtozatlan marad annál az ojjektumnál, amitől előtte egy pl. funkcióval lekérted.
    Mutasd a teljes hozzászólást!
  • a borlandos kavarás szerencsére még nem keresztezte az életutamat :D


    Akkor próbáld ki! Felejthetetlen élmény.
    Mutasd a teljes hozzászólást!
  • hát én C#-ról tudok nyilatkozni.
    Unicode-ban tárol mindig szal nem kell szenvedni a karakterkódolással meg ilyenek.
    a StringBulidert csak akkor kell használni ha több tízezerszer vagy mégtöbbször fűzöl a stringhez új stringeket. Tehát igen ritkán, csak speciális esetekben kell vele foglalkozni, elég ha tudod h létezik ilyen és majd ha kell használod. Keress rá gugliban, ilyen nagy iterációknál már több másodperc is lehet a spórolás, szal megéri. (a sebességnövekedés ugyebár abból adódik h nem hoz létre új objektumot minden hozzáfűzésnél hanem a régit módosítja)
    Az hogy objektumként kezeli a stringet az nagyon remek, van hozzá egy csomó jó kis metódusa csak meghívom rajta, és minden gyors és egyszerű.

    a borlandos kavarás szerencsére még nem keresztezte az életutamat :D
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Régen volt két féle string, a Pascal és a C típusú. Ezekkel nem is volt gond. Amikor Turbo C-ben dolgoztam, tudtam, hogy itt bizony egy karaktertömb utolsó eleme nulla, TP alatt pedig az első a méretet adja meg. Kicsit kényelmetlen volt C alatt az értékadás és az összehasonlítás, de voltak rá függvények.

    Aztán bejött a C++ a maga std::string osztályával. Ez nagyon kényelmes volt, C-stílusú stringről könnyen is ment a konvertálás oda-vissza, és tényleg sok nyűgöt levett a programozó válláról az, ha a C-stílusú stringet nem használ.

    Eddig minden tök jó és világos volt.

    Aztán (számomra, ugyanis a fenti az a sorrend, amiben én elsajátítottam a programozás lépéseit, kiemelve a stringekkel szívós részeket) jött a Java a maga String és StringBuffer osztályával. Alapvetően mindkettőnek szöveges adatok tárolása a feladata, de a String osztály tartalma nem módosítható, ellenben a StringBufferrel. Sőt, a két osztály egymással semmilyen kapcsolatban nincs. Én a magam részéről a String osztályt hagytam is volna a fenébe (egy olyan program, ami alapból futtatómotron fut, nem igazán lehet sebességkritikus), de az API a szöveges információkat rendre Stringben adja vissza, amin aztán ha a programozó valamilyen módosító műveletet akar végrehajtani, akkor aztán konvertálhat. Erre minek volt szükség? Ha annyira fontos az optimalizáció, miért nem tudja a fordító eldönteni, hogy melyikek azok a StringBufferek, amikben semmilyen módosítás nem történt, és azokat lecserélné stringekre? Minek ezt kézzel megcsinálni?

    Java után elkezdtem C++-ozni, először DevC++-ban, aztán Visual C++-ban, ahol sokat szívtam azzal, hogy a WinAPI függvények kétbájtos, C-stílusú stringeket adtak vissza (szakszóval széles karakter, ha jól emlékszem), aztán megtaláltam azt a kapcsolót, amivel normál ASCII stringet kérhetek, úgyhogy ez inkább az én lámaságom volt.

    Na de most a Borland C++Builderrel szenvedek, és már a fejem verem a falba, hogy kinek jutott eszébe az AnsiString és miért? Az összes komponens AnsiStringben kéri és adja vissza az adatait. Ez most miért jó? Mi baj volt az std::string osztállyal? Ráadásul az sem járható út, hogy String helyett AnsiStringet használok, mert egy csomó C++ osztály nem működik vele együtt (pl.: stringstream-ek). Ha már a borlandos fejlesztők mindenáron saját stringet akartak csinálni, miért nem csinálták kompatibilisre a kettő osztályt? Miért nekem kell konvertálgatnom a kettő között?

    Aki megmondja ennek a sokféleségnek az előnyét, azelőtt virtuálisan leborulok.
    Mutasd a teljes hozzászólást!
abcd