Portál AbcLinuxu, 7. listopadu 2025 12:46
Zajímalo by mě proč je kontrukce
public class Trida {
private long nativniData; // v nativniData je nějaký Cčkový ukazatel
}
špatně. V rámci metody disposeNative() se pak nativniData korektně uvolní z paměti.
Stejně tak nerozumím tomu, proč by metoda finalize neměla být nativní? S předpokladem, že nativní finalize volá finalize předka ve svém závěru.
Předem díky za vysvětlení.
V rámci metody disposeNative() se pak nativniData korektně uvolní z paměti.Jde o principiání nekorektnost. Ukazatale jsou a vždy budou jen 64bitové, že tam dáváte long? To kolem finalize bych považoval za best practice. Jde spíš o praktičnost. Pokud by bylo finalize nativní a vy byste potřeboval najednou uzavírat nějaký soubor, tak byste to musel udělat přidáním volání close() do nativního kódu (což je zbytečně složité). Tak je lepší si to rovnou oddělit.
Už rozumím. Jde o to, že není nikde definováno, že sizeof(void*) < sizeof(long).
Já bych se asi místo vytváření mapy (= výkonostní zabiják) spíše přikláněl,k využití nativní třídy CPointer, která má pointer peer deklarovaný jako
public abstract class CPointer {
protected long peer;
...
}
A kruci, zase long. 
Hledání ve vhodně udělané mapě je v čase log_2(n). Při 10 tisísích takto spravovaných objektů je pro dohledání ukazatele nutné projít jen cca 13 prvků z mapy, než je nalezen ten správný. To není vůbec zlé.
Jinak ty odkazované stuby jsou taková znouzecnost, neboli jak emulovat C v Javě. (Normálně by se na tohle použilo JNA a člověk by si tyhle věci psát nemusel.) Je možné, že ukazatel nebude nikdy delší než javovský long. Ale takových předpokladů se už ve světě počítačů udělalo tolik a kolik škody to taky napáchalo... Mapa mě hřeje na srdci víc
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.