Az adattípusok mérete a java - stack túlcsordulása orosz nyelven
P. Nouton, G. Schildt "Java 2. A legteljesebb útmutató" című könyvében a következőket mondják az adattípusok méretéről:
Máshol ez a könyv azt mondja:
Úgy tűnhet, hogy a rövid vagy byte memóriát takarít meg, de nincs garancia arra, hogy a Java nem lesz belsőleg egyébként bővíteni az ilyen típusú int. Ne feledje, hogy a típus meghatározza a viselkedést, nem pedig a méretét. (Az egyetlen kivétel - tömbök, ahol a byte típus biztosítja, hogy csak egy byte-ot tömb elemet, míg a rövid lesz két bájt, és int - négy bájt).
A fentiekkel kapcsolatban kérdésem volt: mit jelent az egész típusú változók szó viselkedése, és igaz-e, hogy a változók nem deklaráltak tömbként, a méret nem definiált?
előre beállítva: 13.1.13: 16:58
Azt hiszem, ebben az esetben adja meg az örök konfliktus: szeretnénk gondolni a fajta viselkedés (szinten a logika), de a súlyosan korlátozott erőforrások gondolnunk kell arról is, az összeg a lefoglalt memória. Ennek eredményeként született kompromisszumok és kompromisszumokat kell gondolni őket.
Például a C időtartamaiban a szabványnak megfelelően csak a short int típusúak voltak <= int <= long int, все остальное являлось спецификой конкретной платформы. Это весьма шаткое положение вещей, которое было учтено в дизайне Java.
A Java Nyelv specifikáció szabvány egyértelműen meghatározza a szélső értékeket a típusokhoz, vagyis a fizikai szinten a legkisebb bit-sebességet. Például a hosszúnak 64 bites értékekkel kell működnie, még akkor is, ha az alapul szolgáló hardver platform nem.
Bárki írhatja a JVM vagy a Java nyelv saját "megvalósítását", de ha az eredmény nem felel meg a specifikációnak, akkor a "Java" már nem lehetséges, a specifikációban a technológia lényege. Az ilyen "megvalósításokkal" problémákat is fontolóra vehet, de fontos, hogy távolodjon el tőlük, mivel ezek nem a Java platform problémái, hanem valamilyen külső megoldás problémái.
Valamilyen módon használható ez a valódi vas teljesítmény meghatározására? Például egy 32 bites gép hosszú, viszonylag szerény, fizikailag képviseli két intami, hogy együttműködik hosszú kód lassabb lesz. Másrészt, a átmenet a 64-bites rendszer program önmagában lassan indul (legfeljebb 20% SPARC, 0-15% AMD64 és EM64T) legalább, mert a megnövekedett 4-8 bájt mutató mérete. Más szóval, minden bonyolult.
Egyszerű esetben célszerűbb szem előtt tartani, hogy egy primitív típus mérete viselkedés (az értéktartományok garanciája és az a tény, hogy a velük való munka logikája nem szétesik a platformok között). De ne felejtsük el, hogy végső soron ez a mérnöki kompromisszum, amely a standardon belül van, és amely különösen nehéz esetekben valamit meg kell tennie.
válaszolt a február 2-án, 15: 15-kor
A második kérdést illetően: tudnia kell, hogy a különböző vállalatok többféle implementációja létezik (más néven rövidített JVM). Tehát a különböző JVM-ben a kód végrehajtásakor:
az i változó lehet 4 vagy 8 bájt. És ez a JVM végrehajtásától függ.
Az IMHO és a tapasztalataim azt sugallják, hogy miközben nem írsz olyan programokat, amelyek millió rekordokkal dolgoznak, nem szabad ezzel foglalkoznod. Jobb a programozás elsajátítása a java egészében. Amikor megközelíti a sorokat, ahol a programok nagyok, akkor már tudni fogja, hogy mit kell csinálni vele és hogyan kell kódolni a kódot.
válaszolt 4 Jan '13, 7:14 am