Hozzászólások
-
Bejegyzés
-
Hm… volna 1 érdekes ötletem… lesz Hacktivity majd szeptember 17-18.-án…
Nem lenne esetleg ésszerûbb picit Ltolni az idõpontot, és ott találkozni, majd vmelyik program alatt lelépni, és sörözni? 🙂
Mert szombaton pl. 17:30-tól zárásig szerzõi jogokkal kapcsolatos beszélgetés engem pl. hidegen hagy, vagy ha mégis érdekel, akkor vasárnap 18:00-tól vége a mûsornak, és ott 2-3 órán keresztül lehetne sörözni, meg megbeszélni az ott látottakat.Persze ez csak 1 ötlet, de várom a véleményeket ezzel kapcsolatban!
kl223
(ui: mellesleg így szvsz nagyobb lenne az érdeklõdés is)
(uui: kiemelem a témát, elvégre sokakat érdekel)hm.
Nem tudom már hol olvastam, de állítólag az ntfs kísértetiesen hasonlít az IBM fájlrendszerére. Van róla egy elég pontos leírás, de nem emlékszem…Akit érdekel, keresgélhet…
[align=right][snapback]145190[/snapback][/align]hm. Mármint az IBM fájlrendszere alatt mit értesz? a JFS-t? Mert én úgy tudtam, hogy a hpfs és az ntfs fejlesztõk között volt elég nagy az átfedés… 🙂
Hi!
Próbáltam énis beizzítani egy icecast szervert. A gond ott van, hogy ennyit ír ki:
Changed groupid to 65533.
Changed userid to 65534.Szerintem nem kell neked itt származtatgatnod az ostream-bõl 🙂
A c++ engedi a különbözõ operátorok túlterhelését, így a << operátort is, ami azért valljuk be, elég hasznos tud lenni ( Javában ezt nagyon hiányolom :-( ). Viszont ha nem tudod a szignatúráját, akkor célravezetõbb lenne egy sima "log" mûveletet írni a szükséges objektumokra.
[align=right][snapback]144948[/snapback][/align]Naigen. Nade hogy néz ez ki? 😉
Bár mind1, valszeg úgy lesz megoldva, meg singletonnal…
csak majd picit felfejlesztem. (pl loggolás több helyre, etc)Javában az operátorok felüldefiniálása hiányzik naon, bár ha az ember megszokja ezeket az isEquals meg charAt, meg hasonló mûveleteket, utána nem oan zavaró. Az 1 dolog, hogy így elsõ ránézésre is érti az emberfia, mit is csinálok…
kl223
az a baj, hogy nem, hanem stringekkel oldja meg és mindig új objektumokat kell létrehoznia, mivel string imutable és így O(n^2), stringbufferrel meg lineáris, mondjuk két string összefûzésénél mind1, de for(int i=0;i<1000;i++) s+="a"; nem ideális 🙂
[align=right][snapback]144849[/snapback][/align]hm….
The Java language provides special support for the string concatenation operator ( + ), and for conversion of other objects to strings. String concatenation is implemented through the StringBuilder(or StringBuffer) class and its append method.
Erre mondtam, hogy StringBufferekkel oldja meg a háttérben azt az összefûzést. A gond ott van, hogy a ciklus minden egyes iterációjában így újabb StringBuffert hoz létre. Ami nem egészséges a memóriára nézve. Ezért érdemes explicit módon az egész for ciklushoz egyetlen StringBuffert használni.
üdv!
kl223Jelenleg én nem vok megtalálható, mivel az ip6 tunnelem kinyiffant idõlegesen.
Majd leszek késõbb… 😉
(cateye: tudom, ne is mondd… szinte hallom, mit mondanál: „ip6.hu sux…” 😉 )kl223
Hát ez hihetetlen! Még ez is mûködik: string += „hello”;… Tudom egy újszülötnek minden új, de eszembe nem jutott volna kipróbálni, de most praktikus lett volna, úgyhogy legfeljebb mondom „hûjének” néz a fordító – erre megcsinálta.
Tudom nem tartozik ide, de muszáj volt leírnom :)))
[align=right][snapback]144731[/snapback][/align]hehe 🙂 igen, mûxik, de a háttérben valójában StringBufferekkel oldja meg a rendszer az ien mûveleteket.
Ezért ha olyasmit csinálsz, hogy egy stringhez adnál hozzá egyenként karaktereket/szavakat, (pl. vmilyen ciklusban, etc) akkor érdemes StringBuffert explicit módon használni, és utána Stringet csinálni, mikor minden benne van, aminek benne kell lennie… 😉kl223
„Szvsz elég kellemetlen. Kérdésem a következõ: van rá vmi mód, hogy érzékeljük, ha egy változó még inicializálatlan?”
Ez nem jó út mert az inicializálatlan változó nem más mint egy lyuk a programban:
0000:ugras a 00FF cimre00FF:program_tovabbi_resz
Közötte meg a változó. Ami jó esetben 0-val van feltöltve (de még ez sem biztos…ha dinamikus).
[align=right][snapback]142408[/snapback][/align]hja, ezt tudtam. erre épülnek a buffer overflow-típusú exploitok.
kl223
Copykonstruktorod van? Sztem azzal kiküszöbölhetõ lenne a probléma …
[align=right][snapback]143004[/snapback][/align]Hm. Nem annyira vok jártas cppben. Hogy is néz ez ki?
Mert egy ienre:Code:class akarmi {
public:
akarmi( akarmi _src );
};azt írja, hogy szabálytalan, és szerinte inkább ezt akartam írni:
Code:akarmi( akarmi &_src );ez utóbbi viszont nem hajtódik végre mint copy konstruktor vagy mifene… nemtom… volt ott mindig pár error. Nyilván, ez ugye az cím szerinti átadás, nem ugyanaz.
Vélemény?
1-2 észrevétel:
-a dispose nem szünteti meg az objektumot, csak a natív erõforrsáokat szabadítja felígy van!
-a gc nem „köteles” csinálni semmit amíg van memóra
elv ha meghívjük explicit módon (System.gc()) akkor összetakarít mindent, amit csak lehet:
SUN Java System.gc() referencia: „When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.”-a finalize hívása nem jelent semmit (vagyis az hajtódik végre amit a finalize metódusba írtál, de más nem történik != C destruktor!!! )
Hm. ezt nem is tudtam… mindenesetre eddig nem volt rá szükség, hogy a finalize-t explicit módon hívjam. Felmerül azonban a kérdés ekkor, hogy egy objektum belülrõl tudja-e törölni saját magát?
Mert gondolom a this=null; nem fog menni… 🙂
Mert más módot nem látok arra, hogy az objektum referenciáját átállítsuk nullra. Ill ezt se, mert ez se hiszem, hogy megy… 🙂-a null -ra állítás akkor kell, ha referencia marad rá, de már nem használod (jó példa a stack tömbbel megvalósítása, ugye a stack pointer alatti(vagy fölötti) tömbelemek már nem használtak de a tömbben a ref megmarad amíg felül nem írod, itt jól jöhet a nullázás)
esetleg (bár ebben az esetben nem látom konkrétan értelmét, de talán active_frame lehetne) weakrefernce használata
[align=right][snapback]144647[/snapback][/align]hát elv mi is a gyenge referencia? Ha jól tudom épp az a lényege, hogy azt a gc nem veszi figyelembe… de ez nem biztos, csak vmi rémlik…
kl223
legutóbbi hsz