Primitív típusok tömbjeinek konvertálása

Java

Szevasztok!

A Sun oldalán talált dokumentáció szerint egy T1[] típusú objektum akkor konvertálható T2[] típusra, ha T1 és T2 egyaránt referencia-típusok és egymással kompatibilisek.

Nem találtam leírást arról, hogy primitív típusok tömbjei között lehet-e konverziókat végrehajtani, de kipróbáltam és sajnos nem engedte.

Akkor ezt gondolom sehogy sem lehet megcsinálni. Ha ez így van akkor nagyot csalódtam a Javában, mert C-ben ez probléma nélkül menne.

  • 1358 megtekintés

( atomheart v | 2010. 05. 01., szo – 15:12 )

Ha ez így van akkor nagyot csalódtam a Javában, mert C-ben ez probléma nélkül menne.

C-ben egy Foo*-ot atkonvertalhatsz Bar*-ra. Ha ez kell neked, maradj csak gyengen tipusos nyelveknel...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Na jó, azért nem fogok felhagyni a Java programozással, de nem látom be hogy miért kell ennek így lennie, miért ne lehetne a programozó kezébe adni ezt a lehetőséget. Értem én, hogy minden referencia lényegében egy mutató (vagyis szám), így minden referencia mérete megegyezik. De szerintem nem jelentene komoly gondot a konverzió olyan típusok tömbjei között sem, amelyek mérete különböző.

Bizonyos feladatokra nagyon hasznos lenne. Mondok egy példát, amivel éppen foglalkozom: bitmezők. A BitSet osztály nem megfelelő nekem, mert sehogy sem lehet ByteBuffer-be csomagolni. (Ráadásul belenézve a forrásba rájöttem, hogy alapból elég érthetetlen dolgokat csinál.) Nincs gond, nekiálltam a saját Bitfield osztályomnak. És itt jött a probléma: teljesítmény szempontjából inkább long tömbben szeretném tárolni a biteket, csakhogy mindenképpen szükséget van byte array exportra. Viszont ha lazán átpakolom a byte-okat egy teljesen új tömbbe, akkor teljhesítmény szempontjából megint gáz...

Viszont a long-bol byte-ba konvertalas mindenkeppen informacioveszteseggel jar, valoszinuleg ez az oka annak, hogy az erosen tipusos nyelvek nem engedik automatikusan konvertalni oket.

Ha megis nagyon ilyesmire vagysz, a teljesitmenykritikus reszeket megirhatod JNI-ben is, az C.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A long->byte konverzió biztosan információveszteséggel jár, de én nem is ilyen ilyen konverziót szeretnék csinálni, hanem ilyet: long[]->byte[]. Ez nem hiszem, hogy így információveszteséggel járna (fordítva már lehetséges). A JNI jó cucc, de hordozhatóság szempontjából nem biztos hogy előny a használata.

A bitsorozattal nincs is gond, barmilyen bitsorozat ertelmezheto byte-kent. A gond ott vna, hogy egy long egynel tobb bytebol all. Ugyanis itt fellep az, hogy egyik platform little-endian, a masik big-endian, megis a nyelv, amin a kodot akarna irni, platformfuggetlen. Valamint (igaz nem ismerem teljesen a JLS-t) nem is vagyok benne biztos, hogy a long[] elemei folytonosan vannak a memoriaban es el lehetne oket egy folytonos byte[]-kent erni. Itt nincs pointeraritmetika, ez nem C. Ne akarjunk motoros furesszel arkot asni, mert nem fog menni.

Ez mar elmeletben is problemat okoz, mert a byte[] korrekt kezelesehez mindenkepp at kell ertelmezni a long tombot. Szerintem a java nem C tipusokkal dolgozik, azaz egy long tombelem nem ugy nez ki, hogy rogton a bitek vannak benne, hanem van egy csomo extra metainfo is az egyes tombelemekhez, es ugy mar viszont a memoriaelhelyezkedes kritikus lehet

Ertsd meg, ez nem C, itt nem lehet a memoriaval ugy buveszkedni. Meg igy szerintem minel objektumorientaltabb valami, annal kevesbe van a kezedben a memoria direkt kezelese.

Egyebkent egy masolo ciklus pluszterhelese minimalis.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Igazából a java.nio osztályok használatával írnám/olvasnám a Bitfield-ben tárolt adatot, ami csak akkor lehetséges, ha valahogy ByteBuffer-be csomagolom. Viszont - bár méréseket nem végeztem - elméletileg két Bitfield objektumon ha bitműveleteket akarok vvégezni (or, xor, and), akkor teljesítmény szempontjából jobb lenne long[]-ban tárolni a biteket. Belenézve a java.util.BitSet osztály foráásába, ott is így van.

De végül is már megkaptam a választ arra, hogy ez így sajnos megvalósíthatatlan ahogy én elképzeltem.

( uid_15426 | 2010. 05. 31., h – 23:38 )

Guglizz ra a 'type covariance and contravariance' kifejezesre..

----------------------
while (!sleep) sheep++;