- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Yettel topik
- Honor 200 Pro - mobilportré
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
- Szerkesztett és makrofotók mobillal
- Motorola Edge 40 - jó bőr
- iPhone topik
- Milyen okostelefont vegyek?
- Xiaomi 15 - kicsi telefon nagy energiával
Új hozzászólás Aktív témák
-
#4725
WonderCSabo
félisten
Karma
#4721
-
#4715
WonderCSabo
félisten
modder
#4714
WonderCSabo
félisten
Értem, ez nem volt teljesen világos, nem csak én értettem félre akkor.
Igen, valóban sokszor irritáló a sok checked exception. Talán Robert C. Martin-tól olvastam a Clean Code-ban, hogy ő Javában runtime exceptionök használatát javasolja, ahol csak lehet.
Szerintem egy jól megtervezett libben is teljesen jogos lehet az IOExceptionök dobálása: vegyük pl. a JDOM-ot, az XML beolvasásakor dobhat IOExceptiont és JDOMExceptiont is, mindkettő ellenőrzött. Mivel ezekre mindenképpen illik reagálnia a kliens kódnak, és nem is jelentenek fatális hibát jellemzően, ezért teljesen jogos ellenőrzött kivételként dobni őket.
Egyébként az Effective Java a témában azt mondja, hogy ahol nem lehet helyrehozni a hibát, ott dobjál ellenőrizetlen kivételt.
-
#4713
WonderCSabo
félisten
Karma
#4712
-
#4711
WonderCSabo
félisten
modder
#4705
-
#4669
WonderCSabo
félisten
PandaMonium
#4668
WonderCSabo
félisten
válasz
PandaMonium
#4668
üzenetére
Háááát, a WindowBuilder után szinte kötelező.
Viccet félretéve, katasztrófa a kód amit csinál, és aztán abba beleírni még a logikát, vagy legalábbis az eseménykezelést, pff. -
#4637
WonderCSabo
félisten
RexpecT
#4636
WonderCSabo
félisten
válasz
RexpecT
#4636
üzenetére
Az én megoldásom ebben az esetben konkrétan nem gyorsabb, hiszen minden egyes beszúrásnál ki kell keresni, hogy van-e már elem, ez HashMap esetén konstans idejű, de lassabb mintha csak egy List-be szúrsz be, TreeMap esetén pedig logaritmikus. Továbbá az is lassítja, hogy ha még nem volt az adott kulccsal elem, akkor létre kell hozni neki a Listet. Cserébe kevesebb helyet foglal, mint a Te megoldásod, hiszen nem duplikálja a kulcsokat (persze List-ek plusz helyet foglalnak, de ezt az előző simán kompenzálja). Az enyém ott gyorsabb, ha kulcsonként kell lekérni az elemet, a tied lineáris ebben az esetben, enyém a hash esetén konstans, TreeMap esetén logaritmikus. De ebben a példában ez nincs kihasználva. A TreeMap sorrendben is tárolja a kulcsoakt megadott rendezés szerint (String esetén alapból ABC sorrend, a hash-es megoldás viszont random. Továbbá ez egy szebb megoldás, hiszen jobban leírja a feladatot, egy kulcs-hoz több elem tartozik, és csak standard könyvtárbeli elemeket használ. A Guava persze még jobb lenne, de teljesítmény szempontból ugyanazt tudja kb, mint az én megoldásom, csak szebb apit ad hozzá.
-
#4606
WonderCSabo
félisten
Oppenheimer
#4604
WonderCSabo
félisten
válasz
Oppenheimer
#4604
üzenetére
Az zsír akkor, bár a kérdésem nekem is az, mint M_AND_Ms-nek.
-
#4603
WonderCSabo
félisten
Oppenheimer
#4602
WonderCSabo
félisten
válasz
Oppenheimer
#4602
üzenetére
Azért sok oldalas, hivatkozás JavaDoc HTML-ből pdf-et csinálni nem triviális feladat. Akkor inkább a pdfdoclet.
-
#4467
WonderCSabo
félisten
kemkriszt98
#4466
WonderCSabo
félisten
válasz
kemkriszt98
#4466
üzenetére
Itt arról van szó, hogy x86-64 architektúrájú procid van, amit amd64-nek is hívnak, függetlenül a gyártótól. A hibaüzenet arról szól sztem, hogy 64 bites platform esetén a 64 bites programkönyvtár dll kell neki, nem a 32 bites. Próbáld letölteni a 64 bitest és azt használni.
-
#4458
WonderCSabo
félisten
kemkriszt98
#4457
WonderCSabo
félisten
válasz
kemkriszt98
#4457
üzenetére
Elméleti maximum korlátja nincs, csak implementációs, illetve elérhető memória függvénye. Mivel a BigInteger belül egy int-ekből álló tömböt használ, aminek max hossza Integer.MAX_VALUE lehet, ezért a BigInteger max értéke (2 ^ 32) ^ Integer.MAX_VALUE. Nem hiszem, hogy túl fogod lépni a saját programjaiddal.
-
#4455
WonderCSabo
félisten
kemkriszt98
#4453
WonderCSabo
félisten
válasz
kemkriszt98
#4453
üzenetére
BigInteger is van Javában.
-
#4438
WonderCSabo
félisten
trisztan94
#4437
WonderCSabo
félisten
válasz
trisztan94
#4437
üzenetére
Én erre el szoktam menteni valahova konstanstba a System.getProperty("line.separator") értékét, és azt használom. De a formatter szebb megoldás valóban.
-
#4354
WonderCSabo
félisten
pokerecske1
#4353
WonderCSabo
félisten
válasz
pokerecske1
#4353
üzenetére
Hmm, asszem lehet, hogy én olvastam félre a kérdést. Ha a cellák határát akarod dinamikusan változtatni, itt a megoldás.
-
#4352
WonderCSabo
félisten
pokerecske1
#4351
WonderCSabo
félisten
válasz
pokerecske1
#4351
üzenetére
Szia!
Itt a megoldás. Nyilván a függvényben egy elágazással rávizsgálhatsz az indexekre, és csak azt szinezed be amelyiket akarod.
-
#4319
WonderCSabo
félisten
SektorFlop
#4318
WonderCSabo
félisten
válasz
SektorFlop
#4318
üzenetére
Az ékezetesre megoldás:
Locale locale = ...; // lekered amit szeretnel, pl. new Locale("hu") vagy Locale.getDefault()
Collator stringComp = Collator.getInstance(locale);
Collections.sort(list, stringComp); -
#4317
WonderCSabo
félisten
SektorFlop
#4316
WonderCSabo
félisten
válasz
SektorFlop
#4316
üzenetére
Megnéztem a kódodat, a rendezés teljesen rendben van (attól eltekintve, hogy nem lokalizálható). A rendezés után adtad át a listát a GUI-nak?
-
#4289
WonderCSabo
félisten
trisztan94
#4288
WonderCSabo
félisten
válasz
trisztan94
#4288
üzenetére
Sztem rövid kifejezések esetén szebb a ternary, mint az if.
-
#4285
WonderCSabo
félisten
trisztan94
#4282
WonderCSabo
félisten
válasz
trisztan94
#4282
üzenetére
If (x >= xo && x <= xe && y >= yo && y <= ye)
return true;
else
return false;Mivel ez egyetlen logikai kifejezés, simán ennyi. De ezt így írni tökre nem szép. Egyébként sztem a "rövidített if" amire te gondolsz, az a ternary operator.
Látom megelőzek. Athlon64+, Te az eredeti választ adtad meg.
-
#4248
WonderCSabo
félisten
MrSealRD
#4245
WonderCSabo
félisten
válasz
MrSealRD
#4245
üzenetére
Tévedsz, Javában a string literálok nem úgy műkődnek, mint az egyéb sima objektumok. Ezek egy String poolba kerülnek. Amikor létrehozol egy új string literált, akkor a JVM megnézi, hogy benne van-e már az a string a poolban, és ha igen, akkor nem hoz létre új objektumot, hanem egyszerűen referál a már meglévőre. A garbage collector ezeket a stringeket nem is fogja bántani csak úgy, különben elveszik az újrafelhasználás lehetősége.
A StringBuildert pedig nem kell feltétlenül használni, mert egyrészt sokkal természetesebb a plusz operátor, másrészt úgyis StringBuilderre fordul a + operátor...
-
#4244
WonderCSabo
félisten
modder
#4243
WonderCSabo
félisten
StringBuffer a thread-safe, és pont ezért a fordító alapból concat() helyett mindig StringBuildert használ.
Egyébként jól mondod. Kizárólag cikluson belül érdemes StringBuilderrel játszadozni, a többi helyen úgy is helyesen elintézi helyetted a fordító. De nem azért mert nem ismeri fel. Vegyük a kövi kódot:
String s = "";
for (int i = 0; i < 100; ++i) {
s += Integer.toString(i);
}Ebből a következőt fogja generálni maga a fordító a bytecodeban:
String s = "";
for (int i = 0; i < 100; ++i) {
StringBuilder b = new StringBuilder(s);
b.append(Integer.toString(i));
s = b.toString();
}Látható, hogy rosszabbul járunk, mintha simán a concat()-ot használtuk volna.
-
#4204
WonderCSabo
félisten
RaPiDsHaRe
#4203
WonderCSabo
félisten
válasz
RaPiDsHaRe
#4203
üzenetére
Miért, panaszkodott, hogy nem találja? Mert ha nem, akkor nem kell bántani.
-
#4136
WonderCSabo
félisten
n00n
#4134
WonderCSabo
félisten
Ez attól függ, hogy mekkorák a fájlaid, amiket másolsz. Ha sok kicsi fájlod van, akkor kis buffert érdemes választani, ha nagyokat, akkor lehet nagyobbat is.
A Files.copy() metódusban 8K-s buffer van alapból, érdemes azt választani, valószínűleg a Java mérnökei hosszas tesztelés után választották azt a méretet. Ja és nem megy megás, hanem egy kilobájtos buffer van a Te kódodban.Na már megint megelőztek.
-
#4133
WonderCSabo
félisten
Karma
#4122
WonderCSabo
félisten
Legalábbis vannak ellentétes nézetek, amik szintén best practice-nek gondolják hogy a változódeklaráció a lehető legközelebbi scope-ban legyen a felhasználáshoz.
Sztem ma már ez az elterjedtebb, jómagam is ezt szoktam alkalmazni. Mellesleg jó pár nagyobb cég code design guideline-ja is kiemeli ezt (pl. Mozilla, Google).
-
#4115
WonderCSabo
félisten
TBG
#4113
WonderCSabo
félisten
Semmi vitám nincs veled, csak csodálkoztam, hogy mire gondolsz, és azért kötöttem bele mert érdekel ez az "altéma".
A bytebuffer tömböt tényleg ki lehetne szedni, az úgyis mindig felülíródik, felesleges mindig létrehozni.
A finally is teljesen jogos, de itt valszeg nem ez lesz a probléma, mindenesetre érdemes ezt a konvenciót követni. Vagy ha van Java 7-re lehetőség, akkor még jobb a try-with-resources blokk.Nem tudom mennyi fájlról van szó és mekkora méretről, érdemes kipróbálni másik OS-n is, egyébként érdekes a probléma, mert kvázi triviális dologról van szó, ami ráadásul rohadtul gyakori művelet is.
Ami még most eszembe jutott, hogy meg kéne próbálni NIO2 fájlmásolással, lehet, hogy segít rajta, és a kód is rohadtul leegyszerűsödik. Persze ez is csak Java 7-el.
-
#4110
WonderCSabo
félisten
TBG
#4109
-
#4097
WonderCSabo
félisten
n00n
#4093
WonderCSabo
félisten
Egyébként nekem az a tippem, hogy a szamlalo kisebb, mint 100, ezért annak az egész típusú osztásnak eredménye 0 lesz. Így a következő műveletben 0-val osztasz, és emiatt AritmethicException dobódik. Vagy esetleg a szamlalo eleve 0.
Superhun megelőzött, miközben a hszt írtam.
-
#4085
WonderCSabo
félisten
trisztan94
#4083
WonderCSabo
félisten
válasz
trisztan94
#4083
üzenetére
MySQL-hez JDBC-vel pl. A GSON-t pedig én is csak ajánlani tudom, zseniális library.
-
#3986
WonderCSabo
félisten
kemkriszt98
#3985
WonderCSabo
félisten
válasz
kemkriszt98
#3985
üzenetére
Az enumot így nem nagyon szoktuk használni.
-
#3977
WonderCSabo
félisten
ITmuki
#3972
WonderCSabo
félisten
Sztem a Programozás fórumban tedd fel ezt a kérdést. Egyébként engem is érdekelnének a válaszok, hasonló cipőben járok.
-
#3958
WonderCSabo
félisten
kemkriszt98
#3957
WonderCSabo
félisten
válasz
kemkriszt98
#3957
üzenetére
Először olvasd el hogy is kell alapvetően a String-eket Javában kezelni, aztán kérdezz.
-
#3894
WonderCSabo
félisten
kemkriszt98
#3893
WonderCSabo
félisten
válasz
kemkriszt98
#3893
üzenetére
Azért, mert a jar nem futtatható alapból. java -jar paranccsal lehet futtatni (már ha futtatható jart exportáltál)
-
#3807
WonderCSabo
félisten
TBG
#3805
WonderCSabo
félisten
Igen, valóban good practice, és általában én is így használom, de semmiképpen nem rossz az ellentettje sem. Pl, ha sima List-et használsz, és nem tudod a statikus típust, akkor olyan dolgokba futhatsz bele, mint pl. get(index) hívás, ami ArrayList-en konstans idejű, de LinkedList-en lineáris stb.
-
#3795
WonderCSabo
félisten
Taoharcos
#3794
-
#3520
WonderCSabo
félisten
Superhun
#3518
WonderCSabo
félisten
válasz
Superhun
#3518
üzenetére
Ez így van, és ezt írtam én is. Azért kérdeztem a láthatóságot, mert csodálkoztam, hátha vmi új történik.
TBG: Miért is? Mi van akkor, ha a gyerek metódusából akarok elérni egy másik metódust ami el van fedve/felüldefiniálva a gyerekben, vagy egy változót, ami el van fedve a gyerekben?
Egyébként igazad van, általában arra szoktuk, és arra egyértelmű használni, amire Te gondolsz. -
#3514
WonderCSabo
félisten
artiny
#3513
WonderCSabo
félisten
Először is javaslom, hogy tartsd be a java névkonvenciókat. Másodszor, ne használj publikus változókat, ez felrúgja az OOP egyik legfontosabb alapelvét, az enkapszulációt. Használj helyete private/protected változókat, és ha kell készíts hozzájuk publikus getter/setter metódusokat.
Kérdésedre válaszolva:
Az örökölt típusok alatt örökölt tagváltozókat értesz? A típus az egész mást jelent. Amennyiben public, package private, vagy protectedláthatósága van az ősben lévő változóknak, akkor simán eléred őket a gyerekben csak a nevük leírásával. Pl.public void methodInDerivedClass() {
System.out.println("inherited variable: " + inheritedVariable);
}Ahol ez a metódus a gyerek osztályban, az inheritedVariable pedig a szülő osztályban van.
Ez volt a kérdésed?
-
#3478
WonderCSabo
félisten
Peter Kiss
#3477
WonderCSabo
félisten
válasz
Peter Kiss
#3477
üzenetére
Nem értek egyet. Ez az osztály egy rendelést reprezentál. A rendeléseknek lehetnek itt fajtái, asszem itt az volt, hogy hegyi bicikli, vagy sima bicikli. Ennyiért sztem teljesen okés elgondolás, ha pl. egy enumot vagy int értéket tartalmaz az osztály, ezért külön osztályt létrehozni sztem felesleges. Főleg, hogy *kell* külön írni ehhez osztályt, az nagyon erős túlzás.
-
#3454
WonderCSabo
félisten
TommyX_
#3453
-
#3440
WonderCSabo
félisten
DopeBob
#3439
-
#3431
WonderCSabo
félisten
Scroll Lock
#3429
WonderCSabo
félisten
válasz
Scroll Lock
#3429
üzenetére
Csinálj egy új osztályt a varázslóval, és pipáld be, hogy csináljon main fv-t bele. Akkor tuti jó lesz.
-
#3428
WonderCSabo
félisten
Scroll Lock
#3426
WonderCSabo
félisten
válasz
Scroll Lock
#3426
üzenetére
A Run Configurationben egyébként direkt meg mondhatod neki, hogy melyik fv-t keresse.
Viccet félretéve, katasztrófa a kód amit csinál, és aztán abba beleírni még a logikát, vagy legalábbis az eseménykezelést, pff.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Iphone 16E 128GB Fekete Bontatlan 24 Hónap Garancia
- Asus TUF A15 FA507NU - 15.6"FHD IPS 144Hz - Ryzen 7 7735HS - 8GB - 512GB - RTX 4050 -2.5 év gari
- Csere-Beszámítás! Asus Tuf RTX 5070Ti 16GB GDDR7 Videokártya! Bemutató darab!
- Konica Bizhub C220 - A3 fénymásoló
- Csere-Beszámítás! Ryzen 9 9950X3D Processzor! 16Mag-32Szál!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged