[quote:9c0c8f42f5="bocs"]ajánlott irodalom: Knuth
nincs olyan hogy "a" legggyorsabb. minden a feladat részleteitől függ.
általában a quicksort gyorsabb.
Ah, elsőre nekem is a Knuth könyv jutott az eszembe, fel is ütöttem, de nekem egy magyar nyelvű van, amiben az algoritmusok nevei is magyarok. A mergesort melyik? Nem volt időm még este az egészet átnyálazni, csak láttam, hogy (cserélve) összefésülő, ilyesmik vannak. Vagy ez a mergesort is egy "család", sokféle megvalósítással?
Update: közben végigolvastam a thread végét is, és már nem aktuális a kérdésem :)
[quote:8f6b3e38b9="KisKresz"]
Mert megteheti. És a programozó olyan állatfajta, hogy előbb-utóbb meg is teszi.
Azért ennyire ne kanyarodjunk el a témától. :)
A téma nem az hogy melyik programozó milyen rossz programot készít. A téma az hogy melyik nyelv (c++ vs java) milyen eszközöket ad a kód megírásához.
[quote:8f6b3e38b9="KisKresz"]
Onnantól kezdve vagy bízol benne, vagy - és én inkább ezt csinálnám - utánanézel a dokumentációban, mi is történik. (Ugye VAN dokumentáció?)
Amikor az iskolában a tanárbácsi feladott egy ilyen példát
3 + 5
akkor Te mire gondoltál?
Arra hogy a gonosz tanárbácsi biztos jól ki akar baxni veled és nem összeadatni akarja a két számot hanem valami mást akar???...
QuickSort: a c++ 1.5-szer gyorsabban fut le 13468/8.703.
Erre lehet azt mondani, hogy elmegy.
Ha azonban egy icike picikét életszagúbb a feladat, ahol nem int-eket kell rendezni, hanem egy primitív struktúrát:
[code:1:82bf54d96c]class ArrayItem
{
public int Key;
public double Val1;
public double Val2;
Itt már érdekesebb a dolog: a sebességkülönbség itt több mint 5-szörös (9781/1812 tized annyi, vagyis 5M elemre).
Közben csúnyán szór a sebessége, néha 25%-kal lassabb. Mivel gyanítom, hogy ez a GC miatt van, 350MB-ra
felveszem a memóriáját. Ekkor elzabál 370MB memóriát az oprencertõl, de legalább a futásidõ fluktuáció megszûnik.
Struktúrát rendezni tehát én biztosan nem akarnék Java-ban.
De menjünk tovább. Az az ötletünk támad, hogy stringet is kellene tenni a rekordba.
A Val2 adattagot double helyett String-re cseréljük, amibe egy többnyire 7 jegyû számot teszünk.
String mûveletet ezzel ezután nem végzünk, csak rekord másolás van ide-oda.
Direkt memóriaigény: 5M * (4+8+7) = 95MB lenne.
Veszedelmes jószág a string, ugyanis ekkor 250 MB-nyi heap space kevés lesz a Java-nak, 350MB is, de 450 MB-ba már belefér.
Ezek szerint kb 4-5-ször annyi memóriát zabált a JVM, mint kellett volna.
A sebesség benchmark-hoz így levettem az 5M rekordot, 1M db-ra.
A sebesség mindössze kb 10-20%-kal vol gyengéb, mint c++ esetben, de memória használat 45MB vs. 180MB.
Következtetés: ha olyan feladataim vannak, ami feszegeti a futtató gép határait (cpu, memória), akkor
nem célszerû Java-t választani.
[quote:a63a3e87ba="syntern"]Az egész azt bizonyítja, hogy a Java nem rosszabb, mint a C++ :). Sokaknak már ez is sok, bele sem merek gondolni abba, mit szólnak hogyha az jön ki, hogy nemcsak hogy nem rosszabb, hanem jobb is :)
Nem. Az egész azt bizonyítja, az általad elkészített teszt (ami akár lehet hibás is, hiszen még nem láttuk) egy bizonyos implementációban/környezetben jobb értékeket produkált java környezetben, mint C++-os környezetben. Ez semmiképp nem jelenti azt, hogy a Java nem rosszabb, sőt jobb mint a C++.
Elméletileg egy java program nem futhat gyorsabban mint egy C++-os, mivel azt a byte-kódot futási időben kell lefordítani. A gyakorlatban persze előfordulhat ennek a fordítottja is, de ezt én inkább "implementációs hibának" tartom.
Ez persze nem jelenti azt, hogy a java rosszabb lenne a C++-nál.
[quote:77f6ed903d="lokoto"]Az a köze, hogy kiderült, hogy nem is ismered a Javat.
Mikor állítottam én azt hogy profi vagyok java-bol???????
Pont az ellenkezőjét állítottam! Azért kérdeztem meg itt azokat az embereket akik JÓL ismerik a java-t hogy felvilágosítást kapjak!
A kialakult helyzetre megpróbálok egy történettel válaszolni:
Egy vevő bemegy egy boltba és megkérdezi az eladót hogy az X termék tudja-e azt amit a másik boltban kapható Y. Az eladó megvizsgálja a kérdést és arra jut hogy az X tényleg nem tudja. Megpróbálja bebizonyítani a vevőnek, hogy de mégis... persze sikertelenül. Ekkor az eladó feldühödik és elzavarja a vevőt a francba azzal az indokkal hogy a vevő nem ismeri elég jól az X-et.
Költői kérdés: az eladó helyesen járt el?
[quote:77f6ed903d="lokoto"]
Ha elolvastad volna, hogy mire írom, akkor tudnád. Az "encapsulation"/"hidding" nem arra való, hogy szemellenzőt vegyünk, hanem arra, hogy egyszerűbb legyen az életünk, illetve ne tudjunk belenyúlni abba, amihez nincs közünk.
Részben... hozzátenném még azt is hogy jótékonyan elrejtse az objektum működését a felsőbb absztrakziós réteg elől.
[quote:77f6ed903d="lokoto"]
Ettől függetlenül számos esetben illik ismerni egy osztály működését.
Miért? Mit érdekel engem hogy pl. két mátrix objektum összeadásakor hogyan működik az összeadó algoritmus?
Amikor összeadsz két int típusú értéket akkor foglalkozol azzal hogy pl. a processzor milyen regisztereket használ a művelet során?... ugye hogy nem... csak az érdekel hogy az eredmény helyes legyen. És ez így van jól.
[quote:77f6ed903d="lokoto"]
Például ha üres, alapértelmezett konstruktorral létrehozott listába pakolsz egymást után 500000 elemet, a háttér tömböt többször is meg kell növelni, majd az elemeket áttenni, ami nyilván nem az elérhető teljesítmény.
Engem nem érdekel hogy a lista objektum hogyan oldja meg a problémáit. Az legyen a lista osztályt megíró programozó feladata.
[quote:77f6ed903d="lokoto"]
Itt nem érvekről van szó, hanem arról, hogy durva kijelenteni az operator overloading hiánya miatt a Javáról, hogy rosszabb a filozófiája, mint a C++-é.
Az operator overloading egy olyan eszköz ami egyszerűsíti / megkönnyíti a program írást. A java nem tudja mert az alap koncepciója (filozófiája) az hogy csak a gyárilag megírt operátorokat lehet használni, szemben a c++ filozófiájával ami támogatja a saját operátorokat. Ezek után én azt mondom hogy a java filozófiája rosszabb mint a c++ filozófiája.... ez így érthető volt? Ennél egyszerűbben már nem tudom leírni.
[quote:77f6ed903d="lokoto"]
Ha nem ismered a Javát, kétlem, hogy ismernéd a filozófiáját, ergo mi alapján teszed a kijelentéseket?
Fentebb már megválaszoltam... nem ismétlem magam.
[quote:77f6ed903d="lokoto"]
Ez komoly emberre vall?
Mindenképen... én személyeskedés nélkül kérdezek / érvelek.
[quote:77f6ed903d="lokoto"]
Abból, hogy + jelet rakhatsz két objektum közé még a hatékonyság sem nő egyértelműen (nyilván kérdéses, hogy milyen hatékonyságot nézünk).
Rendben... akkor próbálj úgy programozni hogy a + jel helyett használd ezt... szigorúan java stílusban :)
[quote:77f6ed903d="lokoto"]
A hatékonyság más megközelítésből: írjál egy komplex üzleti logika alapján működő webalkalmazást.
Parancs, értettem... :)
[quote:77f6ed903d="lokoto"]
Rugalmasság: dinamikus osztály betöltés/létrehozás, proxy, reflection. Ilyeneket tud a C++? De akár a memóriakezelést is idevehetjük, mert a kód rugalmassabban módosítható a GC-nek köszönhetően, mert a felszabadításokra kevésbé kell odafigyelni. De a rugalmasság kategóriába lehetne azt is sorolni, hogy ahol van JVM, ott a java programok általában azért elfutkosnak, mindenféle fordítgatás nélkül. És még biztosan hosszan lehetne sorolni, vica versa.
[quote:2356c99071="maszili"][quote:2356c99071="KisKresz"]
Mert megteheti. És a programozó olyan állatfajta, hogy előbb-utóbb meg is teszi.
Azért ennyire ne kanyarodjunk el a témától. :)
A téma nem az hogy melyik programozó milyen rossz programot készít. A téma az hogy melyik nyelv (c++ vs java) milyen eszközöket ad a kód megírásához.
[quote:2356c99071="KisKresz"]
Onnantól kezdve vagy bízol benne, vagy - és én inkább ezt csinálnám - utánanézel a dokumentációban, mi is történik. (Ugye VAN dokumentáció?)
Amikor az iskolában a tanárbácsi feladott egy ilyen példát
3 + 5
akkor Te mire gondoltál?
Arra hogy a gonosz tanárbácsi biztos jól ki akar baxni veled és nem összeadatni akarja a két számot hanem valami mást akar???...
Nem, de annyit tudunk, hogy
a = b;
Nem volt szó pl. arról, hogy a és b típusa azonos (ugye, abból indultunk ki, hogy nem tudjuk a típusukat). Ebből levezetni, hogy ez mélymásolás...
[quote:6326daa089="Exit"]
Még konkrétabban? Mi volt az a gyakorlati probléma, amit csak egyetlen módon lehetett megoldani a Java-val és az a GC miatt nem volt jó?
Ha példa kell..:))
Menj föl a chat.hu-ra és lépj be.. akkor ugye elindul egy Java-s chat.
Használd és közben figyeld meg, hogy zabálja fel szép lassan a memórát,
(pl. KDE System Guard) azaz hogy foglal le egy kicsit, majd még egy kcisit..
Na most ezt szorozd be 10-el, mert egy adatbázis kezelő alkalmazás objektumok
százait (inkább ezreit) hozza létre egy sima lekérdezéskor is.
Szóval konkrétan:
- nekem a java-val az a bajom, hogy nincs a memoria kezelés a kezemben
(a System.gc() ugye sokra nem jó, a java parameterezése, mondjuk más
collector beinditása, vagy a heap birizgálása sem jár sok eredménnyel)
- a garbage collector sz*r, mert "ismeretlen" mikor ad vissza memóriát az OS-nek
(én még nem tapasztaltam ilyet)
Én mindennapos munkám során használok java-t és bizony vannak pillanatok, mikor nem nagyon szeretem.
Alapvetően xml-t szeretnék használni, de sajnos (ellentétben az msxml-es használattal) kényelmetlen, lassú és memóriaigényes.
Van pl egy lépés, amikor egy üzleti definíciót (mely egy 20 MB-os xml-ben van) kell XSLT-vel kitranszformálni (ant task), itt a javas xslt processzor rendszerint out of memoryval elszáll, és cammoghatok vissza a jó öreg msxml-hez, amely tutira megcsinálja, ráadásul fele annyi idő alatt.
Amúgy a PIKE-ra szavaznék, mert ha teljesítményre van szükség, akkor leprogramozom c-ben a "durva" részeket, ha pedig produktivitásra, akkor megírom pike-ban. Látott már valaki rajtam kívül PIKE-ot (http://pike.ida.liu.se/)??? :-D
[quote:186c997e3e="popacsek"][quote:186c997e3e="syntern"]Az egész azt bizonyítja, hogy a Java nem rosszabb, mint a C++ :). Sokaknak már ez is sok, bele sem merek gondolni abba, mit szólnak hogyha az jön ki, hogy nemcsak hogy nem rosszabb, hanem jobb is :)
Nem. Az egész azt bizonyítja, az általad elkészített teszt (ami akár lehet hibás is, hiszen még nem láttuk) egy bizonyos implementációban/környezetben jobb értékeket produkált java környezetben, mint C++-os környezetben. Ez semmiképp nem jelenti azt, hogy a Java nem rosszabb, sőt jobb mint a C++.
Elméletileg egy java program nem futhat gyorsabban mint egy C++-os, mivel azt a byte-kódot futási időben kell lefordítani. A gyakorlatban persze előfordulhat ennek a fordítottja is, de ezt én inkább "implementációs hibának" tartom.
Ez persze nem jelenti azt, hogy a java rosszabb lenne a C++-nál.
Lapozz vissza, bemásoltam az egyik példakódot. Kb. a 14. lap környéke. Ha nem hiszed, mérd ki magad. És de, futhat gyorsabban :)
[quote:cabad5397c="maszili"]
Arra hogy a gonosz tanárbácsi biztos jól ki akar baxni veled és nem összeadatni akarja a két számot hanem valami mást akar???...
Hmm, amikor Számításelmélet szigorlaton valamelyik véges testen, vagy gyűrűn értelmezett műveletnél kérdez a tanár egy ilyet... akkor valószinűleg elgondolkozom.
De most komolyan, mondjuk ket Bankszamla peldany eseten pontosan mire is alkalmaznad a + operatort? Es a melletted ulo programozo?
Ezt a linket meg nem kuldtem be:)
http://jazillian.com/reasons.html
Ah, yes, operator overloading. The previous developer was so cute to have written:
x = person1 + person2;
The problem is, you don't know what it means to "add two people together". Are you adding their ages? Are they getting married or something perhaps more intimate? In fact, now that you think about it, does "+" really mean much of anything except to add two numbers? OK, ok, let's assume it means to concatenate two Strings together, but that's it. No operator overloading. Just say:
[quote:699e9e12aa="Frimen"][quote:699e9e12aa="ssikiss"]
Sorolnád, hogy mire *****?
Pl.:
- totál alkalmatlan olyan alkalmazáshoz, ami nagytömegű
dinamikusan változo adattal dolgozik (adatbázis), mert a
garbage collector működése enyhén szolva "késéges" és
kaotikus. (Jellemzően mit javasolnak a sun forumon: tegyél
a gépbe több memóriát, ne használd az alkalmazásod terminál
szerveren.. stb..)
Ami a legjobban tetszett: biztos memory leak van a progiban..:)
Erre kicsit bedühödtem és körülnéztem:
http://www.herongyang.com/jvm/
Szóval akárki akármit mond, a Java-ban a legnagyobb szivás a
garbage collector.
Fri
[quote:5086026d29="Frimen"]
Ugyanis ha összetett mintát álmondsz meg, amiben "külső" osztályok
is szerepet kapnak, akkor lehet Te is jól megtervezted.. lehet ők is.. csak épp
a kettő együtt nem müködik..:) Lásd a listeneres példát..
Lously coupling:) De tenyleg. Legyen a modell egy facade es a valodi modellel kommunikaljon rmi-n, corba-n, soap-on keresztul (mondjuk fast infoset-tel). Nem hiszek abban, hogy ket kulon fejlesztogarda kozotti interfeszeket szorosan kellene csatolni.
Bovitsem ki a "tervezesi hiba" kategoriat "projektszervezesi" alkategoriaval?:)
[quote:29b0c63fbf="KisKresz"]
Nem, de annyit tudunk, hogy
a = b;
Nem volt szó pl. arról, hogy a és b típusa azonos ...
Ha nem azonos akkor szintaktikus hiba... fordítási időben...
[quote:29b0c63fbf="KisKresz"]
... (ugye, abból indultunk ki, hogy nem tudjuk a típusukat)....
De a fordító tudja...
[quote:29b0c63fbf="KisKresz"]
Ebből levezetni, hogy ez mélymásolás...
A c++ -ban csak egyféle értékadás van! Mivel az egész nyelv érték szerinti átadással mőködik, egyértelmű hogy az a = b átmásolja az adatokat. Ha ettől el kívánok térni (mutatókkal akarok dolgozni) akkor azt jeleznem kell... de akkor az látszik a kifejezésen.
Ez igaz is meg nem is..
.. igaz, mert mindkettő csak specifikáció..
.. nem igaz, mert a java jvm nélkül sokra nem jó, kirakod a kodot a
falra és gyönyörködsz benne?:)
.. nem igaz, mert foglalj már le légyszives "kézzel" memóriát java-ból,
majd szabadisd fel (ez a jvm "feladata)
Fri
Meg még vagy 1234 nyelv, amiből minimum 123 előrébb tart a virtuális rangsorban, mint Wirth bácsi hátulgombólósoknak írt (lásd "Az igazi programozó" c. irományban) pacalja :-P
[quote:b4ab53c6f4="maszili"]Azért ennyire ne kanyarodjunk el a témától. :)
A téma nem az hogy melyik programozó milyen rossz programot készít. A téma az hogy melyik nyelv (c++ vs java) milyen eszközöket ad a kód megírásához.
Egyébként én nem ebben a témában írogatok. A C++ rengeteg eszközt ad nyelvi szinten (template, operator overloading, stb.). Itt azonban elhangzottak olyan dolgok, mint hogy az operator= miatt a C++ jobban OO, mint a Java, meg hogy az baj, hogy Javaban az a = b nem egyértelmű (a típus ismerete nélkül), míg C++-ban bezzeg... én csak ezekhez kapcsolódóan írom le a véleményemet.
[quote:55cdfc5f0f="feledhetetlen"]
melyik a leggyorsabb nyelv?
ami amugy eleg butuska kerdes is,
megis egyre szuletnek valaszok ra
Maximalisan igazad van, csak ez a hup. Itt en masfel eve majdnem kaptam egy ingyen "b@lf@sz" feliratu tomcat polot, csak mert azt mertem mondani egy cikkre reagalva, hogy az 5 kilences rendelkezesre allas nem az, aminek a cikkiro gondolta. Ha szakmai melysegekre vagyom, marad az angol szakirodalom. Hol vannak mar a 80-as, 90-es evek elejenek jo minosegu, kozertheto publikacioi es folyoiratai, amiket ha visszanezek mindig rajovok, hogy 1-1 kiemelkedoen tehetseges es lelkes embernek voltak koszonhetoek... Nomindegy.
[quote:7e6bbbd3e5="Csab"]Sok tekintetben jobb, más tekintetben rosszabb.
Én sok helyen java-t használok, más helyeken C++-t.
Kicsit megpróbálom tömöríteni amit mondtál: ha sebesség kell, hardveres gyorsítást használsz, és jelenleg azt C++-ból könyebben eléred.
Az összes többi kb. az, hogy megvan-e a runtime (JVM / megfelelő libek) vagy sem. Linuxra is van olyan, hogy nincs meg a lib, külön kell felrakni, ugyanez van Javaval is, nem látok lényeges különbséget, azon kívül, hogy a leggyakoribbak ott csücsülnek a Linux disztribben.
A hardver-gyorsítás Javaból is elérhető, a Java3D is ugyanúgy OpenGL-t használ mint egy C++ grafikus program. Persze, lehet mondani, hogy az XYZ hardverre nincs Java alapú hardveres gyorsítás, ez tény, ezt sohasem mondtam, hogy minden van. Én mindeddig csak azt állítom, hogy nem rosszabb Javaban programozni, mint C++-ban :)
[quote:2296392eba="feledhetetlen"]
Azt gondolom elhanyagolhatoan kicsi a kozos resze annak a ket halmaznak amit te tudsz a javarol, es annak amit en nem tudok
Én meg azt gondolom, hogy a nagyképűség az nagyképűség bármilyen szépen is
fogalmaz az ember, ha meg valaki olyan dedós szintre sűllyed mint az "én tudok
többet bibibi".. hát azt csak sajnálni tudom.
Fri
[quote:b2b78c5e61="zeller"][quote:b2b78c5e61="hop1"]És kimaradt a pascal :(
Meg még vagy 1234 nyelv, amiből minimum 123 előrébb tart a virtuális rangsorban, mint Wirth bácsi hátulgombólósoknak írt (lásd "Az igazi programozó" c. irományban) pacalja :-P
Gondolom neked is sikerult a thread elolvasasa nelkul obegatni. Koszi nekedis, tenyleg. Az erzes kolcsonos, ebben biztos lehetsz. 8)
[quote:22305b48a4="Andrei"]Felhivnam a figyelmedet, hogy ilyen kornyezetben a GC is borzaszto rosszul teljesit. A korkoros hivatkozasokkal pl. nemigen tud mit kezdeni, vagy erosen leromlik a teljesitmenye....
A mark and sweep vagy a stop and copy algoritmusra gondolsz? Azzal azert ugye tisztaban vagy, hogy hogyan is mukodik a gc a modern jvm-ekben? Hogy mikor es hogyan kerul egy objektum a young generation-bol a tulelo oregek koze, es ez gc-ileg pontosan mit is jelent: melyik generation-nel milyen algoritmusokat hasznal a jvm es ezt hogyan tudod te valtoztatni. Milyen statisztikai eloszlasa van az objektumoknak az eletidejuket tekintve, es erre vonatkozoan hogyan probalnak optimalizalni gc-ileg a virtualis gepek...
[quote:576683589b="popacsek"]...
Elméletileg egy java program nem futhat gyorsabban mint egy C++-os, mivel azt a byte-kódot futási időben kell lefordítani.
...
toltesi idoben
vagy eppen barmikor, peldaul install time
nem lehet ezen tullepni ? a bytecode szukseges dolog
igy lehet kornyezet optimalizalni
a csuma-koppra-szevasz optimalizalt c++ kod a foditasi platformra van optimalizalva (vagy cross compilalva egy kornyezetre)
mi van ha a cel kornyezeten, mondjuk a memoria muveletek xxxlassuak de cpu gyors, vagy forditva
nekem ugytunik, hogy itt mindenki compiler optimizer szakerto, szoval talan csak be lehet azt latni, hogy a nativ kod generalasi lepesnek a cel kornyezet toltesi idejeben van eloszor jogsultsaga
amugy, a sebesseg NEM SZAMIT !!!
rule #1: do not optimize
rule #2: (experts only) do not optimize yet
Ah, yes, operator overloading. The previous developer was so cute to have written:
x = person1 + person2;
The problem is, you don't know what it means to "add two people together". Are you adding their ages? Are they getting married or something perhaps more intimate? In fact, now that you think about it, does "+" really mean much of anything except to add two numbers? OK, ok, let's assume it means to concatenate two Strings together, but that's it. No operator overloading. Just say:
"person1.marry(person2)"
...using an appropriate method name.
Ennek olyan megmagyarázom a bizonyítvány szaga van.
Amikor leírod, hogy
a == b
tulajdonképpet mit akarsz?
Összehasonlítani a-t b-vel, vagy összehasonlítani a és b címét?
Az esetek döntő többségében eldönthető, mit csinál a plusz operátor.
person1.add( person2 )
Mi a fenét csinál? Csoportot, vagy házasságot?
A helyzet az, hogy rossz nevet adtak a függvénynek. Ez pedig nem az operator overloading hibája.
[quote:53c01cc256="handler"]
Felhivnam a figyelmedet, hogy ilyen kornyezetben a GC is borzaszto rosszul teljesit. A korkoros hivatkozasokkal pl. nemigen tud mit kezdeni, vagy erosen leromlik a teljesitmenye....
A legyegyszerubb refcount alapu gc nem tud mit kezdeni a korkoros hivatkozasokkal. Ez a legelso tema, amit gc tervezesenel felvetnek. Egesz jo RT GC megoldasok vannak mar.
Ettol fuggetlenul a GC *sem* univerzalis. Foleg ha van olyan ismereted, amit a GC nem tud kihasznalni.
[quote:39c7816d50="maszili"][quote:39c7816d50="KisKresz"]
Nem, de annyit tudunk, hogy
a = b;
Nem volt szó pl. arról, hogy a és b típusa azonos ...
Ha nem azonos akkor szintaktikus hiba... fordítási időben...
[quote:39c7816d50="KisKresz"]
... (ugye, abból indultunk ki, hogy nem tudjuk a típusukat)....
De a fordító tudja...
[quote:39c7816d50="KisKresz"]
Ebből levezetni, hogy ez mélymásolás...
A c++ -ban csak egyféle értékadás van! Mivel az egész nyelv érték szerinti átadással mőködik, egyértelmű hogy az a = b átmásolja az adatokat. Ha ettől el kívánok térni (mutatókkal akarok dolgozni) akkor azt jeleznem kell... de akkor az látszik a kifejezésen.
Aha...
[code:1:39c7816d50]
class BlaBla {
public:
BlaBla& operator=( const int i ) {
this->a = i;
return *this;
}
private:
int a;
};
[/code:1:39c7816d50]
[quote:bc92be6204="Frimen"]Sajnos nem tudom kiprobálni, mert a procim nem birja, a kernel "beszologat", hogy kurblival állítgaja a frekvenciát.. igy hamis képet kapnék.. de hétvégén nézek, valami szervert és azon megnézem..
Amugy.. bár tény nem értek sokat a c-hez én ugy tudom, hogy a 4-es gcc nem épp a legjobban sikerült dolog.
Én függetlenül a tesztedtől, meg mindentől amit "olvastam" ismerve a java-t,
kevésbé a c-t, de a tapasztalataimat figyelembe véve, a c tenném a dobogóra a java-val szemben.
Fri
Persze, barmit tehetsz a dobogora, figyelmen kivul hagyhatod a tenyeket, hivatkozhatsz a csillagok egyuttallasara, meg arra, hogy a legfrissebb verzio igazabol joval rosszabb. Csak egyet kerek: ne hivatkozz a jovoben arra, hogy a Java lassu, amikor akar ki is merheted, hogy nem az, vagy ha nagyon kotozkodni akarsz es -O3-at hasznalsz, akkor nem lenyegesen lassu. Kosz.
[quote:315934cad1="maszili"]
Ezzel bonyolítva az értékadás műveletét... mert így többféle értékadásról beszélünk attól függően hogy az operandusok mik is valójában...
pl. ha csak ennyit látsz a kódból
a = b ;
akkor meg tudod mondani hogy az egyenlőség mit csinál?
Valószínüleg nem mert nem tudod hogy az a és b micsoda is tulajdonképen. Most átmásolja a tartalmát vagy csak a címét???... :)
Mivel a java erősen típusos nyelv, illik tudni a változók típusát. Ha tudod a változók típusát, meg tudni mondani, hogy mi történik.
No de mi a helyzet C++ esetén? Ott még ennyit sem lehet megmondani, de a kérdés inkább az, hogy van-e ennek a kérdésnek önmagában értelme?
Nincs, mert 'a' mást jelent Java és C++ esetén, így a műveletek is másként értelmezendők.
[quote:315934cad1="maszili"]
[quote:315934cad1="lokoto"]
Nyilván az ==-et is felül lehetne definiálni, de lássuk be, hogy az egyik kolléga által felvázolt szemethalmazt kapjuk nagyon rövid idő alatt, mert senki nem fogja tudni, hogy mi micsoda.
Ez nem igaz...
Az == (összehasonlító) operátor MINDÍG azt jelenti hogy valamilyen szempontból a két operandus "egyenlő" vagy sem. Az eredménye mindíg egy igaz / hamis logikai érték lesz.
Egyrészt a "mindig" mindig rövid i-vel van akár "MINDIG", akár "mindig", akár valamilyen egyéb kis- / nagybetű kombináció.
Másrészt nem állítottam, hogy nem logikai értéket ad vissza, hanem azt, hogy Neked kell megírnod az összehasonlítást ahhoz, hogy el tud dönteni igaz vagy hamis a vizsgálat. (feltételezve, hogy Javaban felül tudod definiálni a =-t, azaz látszik, hogy egy ilyen apróságnak, mint operátor felüldefiniálásnak milyen következményei vannak/lennének, ha egyáltalán az általad hiányolt lehetőségnek lenne értelme Javában)
Nézd, én semmiről nem akarlak meggyőzni, csak fogadd el azt, hogy amit egy Sun kaliberű cég létrehozott, majd amit egy Microsoft kaliberű cég lemásolt (vagy nem, de nem is ez a lényeg, hanem az, hogy hasonlót alkotott), nagyon sokan elfogadnak, annak a hátterében lehet valami.
Nem állítom, hogy a java mindenre jó vagy legjobb, de azért rosszabbnak minősíteni a C++-nál és leszólni, mert az = nem lehet klónozás és nincs benne pointer, meglehetősen korlátolt agyjárásra vall, ugyanis attól, hogy a szintaktikájuk hasonló (sőt, bizonyos részletekben azonos), a szemantikájuk *más*.
Az eltérő szemantika pedig a háttér rendszer/elképzelés következménye/velejárója/....
[quote:0d522db1c2="syntern"]
Küldj egy címet és elküldöm a konkrét kódokat. De hogy megnyugtatóbb legyen: ugyanúgy programozta le mindkét nyelvben pl. a mátrix-hatványozást, vagy a quicksortot (ugyanolyan induló tömbértékekre), ill. a prímszámkeresést. Nem nagy dolgok, de memóriazabáló (fusson a GC) és procizabáló (legyen idő mérni) feladatokat kerestünk. Direkt úgy készítettük elő a mérést, hogy semmi zavaró tényező ne legyen benne, tisztán a sebesség legyen mérhető, semmi mellébeszélés.
Na igen.. ezek azok a tipikus semmire nem jó idióta
tesztek, amiket jópáran alakalmaznak az ámitástechnikában.:)
Elég ha a Linux - Win$ összehasonlitásra gondolni..:)
Amiről itt szóvan az akárhogy is nézzük hamis képet ad.
Elhiszem.. lehet, hogy isztán tudományos számításoknál megállja
a helyét ez a "teszt", tényleg eléri a C-s teljesítményt a java, de könyörgöm,
a szoftverek 90 százaléka nem erről szól!!
Ott van felhasználó, a maga eseményeivel, általában grafikus felületet a
szolver,, lehetnek "nyulványai" (adatbázis, rmi, stb..) egy szoftvernek, amiket
kezelnie kell.. szóval ez egy idióta teszt sok szempontbol.
Fri
[quote:45b9de954f="kr304"][quote:45b9de954f="Exit"]Azoknak meg, akik azt mondják, hogy Java-ban a hülyék programoznak: :lol:
Én szeretem a C-t és a C++-t, de azért egy Java... Az osztálykönyvtára, meg a platformfüggetlensége meg az, hogy fél óra alatt összehozok egy J2EE webservice-t, hozzá egy webes, egy J2SE-s és egy mobilos klienst... Ekkora produktivitást mikor kapok én a C++-tól?
Hallottál már a GSoap-ról?
A leggyakrabban használt funkciók megvannak a C++ világban is, ez nem annyira nagy dolog, ahogyan megvannak a .NET világban is a megfelelő libek. De ha a könnyebbséget vizsgálod (ami erősen relatív és függ a múltbéli tapasztalatoktól), akkor valószínűleg ki fog jönni, hogy nem feltétlen a C++ a legkönnyebben kezelhető eszköz, a hosszú távú kódkarbantartásra és a platformok közötti hordozásra (főleg mikor már érint grafikus részeket is) biztosan nem.
Én például nagyon kedvelem azt, hogy Linux / Windows / Solaris alatt ugyanabban a fejlesztői környezetben, ugyanúgy lehet fejlesztenem, ami ugyanúgy néz ki eredményben mindenhol. Elméletileg a C++ is képes erre, a gyakorlatban elég nehéz kivitelezni (vagy nekem nem ment, mindenesetre nem próbáltam sokáig, hamar rátértem Javara).
[quote:d8703b8dc4="Csab"]Teljesen már szemszögből szemléljük a világot.
Én mobiltelefonokkal foglalkozom. Plusz néhány megabyte tudod mit jelent mobil telefonoknál?
A Security nekem azért fájó pont, mert sajnos "felsőbb döntésre" security-t is kellett implementálnom. No most valami hihetetlen értelmetlen dolgokkal kellett foglalkoznom ezalatt.
Pl. az összes:
AccessController.check( perm );
hívást le kellett cserélnem
SecurityManager sm = System.getSecurityManager();
if( sm != null )
sm.check( perm );
-re, minthogy az AccessController.check nem működik helyesen minden esetben. Szóval leimplementáltam a security-t, fogalmam sincs, hogy mi miért úgy megy ahogy, a tesztek végig futottak, többet nem akarom látni.
Sajnos nagyon mély vízbe dobtak legutóbb, mert a security mellett ClassLoader-t is kellett írnom, reflection-özni és a ProtectionDomain átizélgetése után eljutottam odáig, hogy elegem van a java-ból.
az erdekelne hogyan csinaltal mobil telefonra ClassLoader-t
de tenyleg
de mar az is jo lenne ha megmondanad, mit jelent ez bárhol a kódban: [code:1:d8703b8dc4]synchronized (this) {}[/code:1:d8703b8dc4]
Egy valami tűnt fel az első forrásban: SUB AX,AX. Ez is egy órajel idejű művelet volt, mint a XOR AX,AX? (nincs már meg a 386-os utasításainak órajeltáblázata, pedig...)
Amennyire gány volt az x86 asm, én annyira szerettem használni... régi szép idők...
[quote:03cbac0f11="maszili"][quote:03cbac0f11="KisKresz"]
Valójában halvány fogalmad sincs, mit csinál.
Pontosítsunk!
Valójában halvány fogalmad sincs, hogyan csinálja.
Ez így helyes.
Mivel OO -rol beszélünk nincs rá szükségem és nem is érdekel... nekem pont elég egy absztakciós szinttel feljebb lévő problémával foglalkozni.
Mókás :-)
Újabb egyszerű feladat: egy java.util.ArrayListbe tedd bele az egész számokat 1-től 500000-ig.
[quote:910a1b3f88="syntern"]valószínűleg ki fog jönni, hogy nem feltétlen a C++ a legkönnyebben kezelhető eszköz, a hosszú távú kódkarbantartásra és a platformok közötti hordozásra (főleg mikor már érint grafikus részeket is) biztosan nem.
hmmm
QT?
"kissé" gyorsabban válaszol desktopon, mint egy javas felület.
persze megy unixokon, win-en, PDA-n stb.
[quote:97a675355e="Csab"]
A helyzet az, hogy rossz nevet adtak a függvénynek. Ez pedig nem az operator overloading hibája.
A helyzet az, hogy OO szemponból a mai napig a smalltalkot tartom a legjobbnak, még ha a szintaktikáját valószinűleg egy évtized alatt sem bírnám megszokni (too seventies). Az a nyelv például operátorok nélkül is teljesen jól megvan.
A helyzet tovább az, hogy az operátorok matematikai szimbólumok. Így matematikai objektumok esetén lenne értelme a felülbírálatuknak. Ha Java-ban lehetőség lenne a java.lang.Number-ből származtatott osztályoknál operator overloading-ra, annak valószinűleg látnám értelmét. Általános, üzleti objektumok esetén operátorokat definiálgatni metódushívások helyett azonban szerintem a legnagyobb bűn, amit ember a munkatársai vagy az utódja ellen elkövethet.
Úgy látom egy dologban konszenzus van: a C alapvető szerepét nem
kérdőjelezi meg senki. Ennek nagyon örülök. Én erre voksoltam, de csak
azért mert már vagy 5 éve nem használok assemblyt PC-n.
Egy valami tűnt fel az első forrásban: SUB AX,AX. Ez is egy órajel idejű művelet volt, mint a XOR AX,AX? (nincs már meg a 386-os utasításainak órajeltáblázata, pedig...)
Amennyire gány volt az x86 asm, én annyira szerettem használni... régi szép idők...
xor reg,reg 001100dw
88/86 3
286 2
386 2
sub reg,reg 001010dw
88/86 3
286 2
386 2
a sub ax,ax kifejezobb szerintem, es nullaza a auxiliary carry-t is
ami xor ax,ax utan hatarozatlan allapotban van
[quote:9dbc355912="maszili"]
Ez a példa azt a véleményemet támasztja alá, hogy futásidőben történő hibajavításról van szó. Ami szugségtelen megfelelő odafigyelés/tervezés esetén.
Lehet. De akkor az autómban az ABS, a kipörgésgátló és a menetstabilizátor is ugyanilyen felesleges hibajavítás. Ami szükségtelen megfelelő odafigyelés/vezetés esetén. Mégis életet/anyagiakat menthet.
Bár nem akarok ismét beszállni a java vs c vitába, mert korábban leírtam a véleményem, de van még egy valószínűleg javában írt játék: IL-2 nevű rep szimulátor, a legjobb amit láttam...
Be van ágyazva (úgy mint a chrome-ba) a java futási környezet. És elég szép...
[quote:51210f6da3="handler"][quote:51210f6da3="lzrd"]
Tudnál jogszabályra hivatkozni?
Nekem laikusként úgy tűnik, nincs igazad. Gondolok pölö a "Magas feszültség! Életveszély!" táblára. Gondolom ezzel analóg módon, ha a programod forrásába/dokumentációjába, első megjelenő felhasználói interfészébe beleírod, hogy nem vállalsz felelősséget, akkor csak nem verhetik el a port rajtad, nem?
PTK/A kártérítés általános szabályai:
342. § (1) Semmis valamely szerződésnek az a kikötése, amely a szándékos vagy súlyos gondatlanságból eredő károkozásért, az életben, a testi épségben, az egészségben okozott károsodásért, továbbá bűncselekmény következményeiért való felelősséget előre korlátozza vagy kizárja.
Ezexerint nincs igazad, hála a magasságosnak, de azért köszi! :)
Szal nem verhetik el a port a programozón, ha nem súlyosan és nem szándékosan gondatlan...
[quote:2439693bd5="Frimen"]Na igen.. ezek azok a tipikus semmire nem jó idióta
tesztek, amiket jópáran alakalmaznak az ámitástechnikában.:)
Elég ha a Linux - Win$ összehasonlitásra gondolni..:)
Amiről itt szóvan az akárhogy is nézzük hamis képet ad.
Elhiszem.. lehet, hogy isztán tudományos számításoknál megállja
a helyét ez a "teszt", tényleg eléri a C-s teljesítményt a java, de könyörgöm,
a szoftverek 90 százaléka nem erről szól!!
Ott van felhasználó, a maga eseményeivel, általában grafikus felületet a
szolver,, lehetnek "nyulványai" (adatbázis, rmi, stb..) egy szoftvernek, amiket
kezelnie kell.. szóval ez egy idióta teszt sok szempontbol.
Fri
Bizonyára Te is belátod, hogy egy ilyen teljesítménymérő tesznek nem az a célja, hogy az adatbázis sebességét mérje, mivel az pl. mind C++-ból, mint Javaból nagy valószínűséggel ugyanannyi lesz. Hasonlóképpen vonatkozik ez diskműveletekre, hálózatra, mert itt is az overhead nem a nyelv és a managelt környezet, hanem dominánsan a TCP stack, a vas, a kábel. Szóval ha tudsz mondani olyan tesztet, ami tisztán a Java managelt környezetet hasonlítja össze a C++ natív futásával, és nem ez a "tipikusan buta" teszt, akkor szeretettel várom és kimérem. De amíg csak azt tudod mondani egy neked nem tetsző eredményre, hogy ez butaság, addig ne haragudj, de nem tudom komolyan venni amit írsz.
Kihagytam a felhasználói felületet. A tesztünk kifejezetten elkerült mindent ami a felhasználói felülettel jár, mivel az csak és kizárólag szubjektív mérés lehet. A szépség fogalmának mérése leginkább a megszokottságéval korrellál, a sebességet mérni pedig még nem sikerült kitalálnom, hogyan lenne célszerű és pontos.
Szóval ha van elképzelés, hogy hogyan máshogy lehetne összehasonlítani a C++-t a Javaval, akkor szeretettel várom, addig pedig csak azt tudom mondani, hogy a C++ semmilyen előnyt nem nyújt az alkalmazások nagy részében a Javahoz képest, amivel szemben a Java azért tud előnyt biztosítani.
[quote:cccc5bae8b="_Joel"][quote:cccc5bae8b="Frimen"] a nagyképűség az nagyképűség bármilyen szépen is
fogalmaz az ember
Frimen. Vedd észre, hogy kivel vitatkozol. Szerintem nem nagyképűség volt, csupán puszta tény.
1. Arra akarsz célozni, hogy essem hasra az előtt, aki valahol oktat, tanit
programozást, java-t, vagy mert 9 éve foglalkozik java-val mig én csak 5
éve? Hmm.. elég érdekes gondolat.. ilyesmi távol áll tölem.
2. Egy tény is lehet nagyképűség, nem zárja ki egyik a másikat.
MIndemellett nem vitatom, nyilván sokkal többet tud nálam a programozásról,
csak nekem tényleg kicsit fanatikus+"ekkora m ellényem" tipusnak tünik a fickója.
Szerintem ez a java & C sebesség kérdésében igen csak megmutatkozik.
Amugy érdekes.. azt vártam valaki reagálni fog itt a c-s példára, de nem..
Valószinű nem ez a legjobb forum ilyesmire..
Fri
QuickSort: a c++ 1.5-szer gyorsabban fut le 13468/8.703.
Erre lehet azt mondani, hogy elmegy.
Kérlek mérd ki a Java-t -server kapcsolóval. Ha megfigyelted a példáimat, akkor kijön, hogy a -server kapcsoló lényegesen jobb. Valamint nagyon érdekelne a struktúrás programkód, hogy mennyire sikerült ugyanazt megvalósítani a két nyelvben. A memória-számolási értékek is gyanúsak. A Java 16 biten tárolja belül a Stringet, köszönhetően az Unicode-nak, bár nem ismerem az MSC++-t, hogy az hogyan, gyanítom ez is benne van.
Szóval amit leírtál, az nagyon gyanús, hogy valami nem ugyanolyan. El tudnád küldeni a kódokat?
Alapvetően xml-t szeretnék használni, de sajnos (ellentétben az msxml-es használattal) kényelmetlen, lassú és memóriaigényes.
Van pl egy lépés, amikor egy üzleti definíciót (mely egy 20 MB-os xml-ben van) kell XSLT-vel kitranszformálni (ant task), itt a javas xslt processzor rendszerint out of memoryval elszáll, és cammoghatok vissza a jó öreg msxml-hez, amely tutira megcsinálja, ráadásul fele annyi idő alatt.
Hát nem tudom. Én tudok legfeljebb 4-6 sorban XSLT-t transzformálni, és ebben a validálás is benne van. Az out-of-memory-ra pedig tessék megtanulni a -Xmx kapcsolót. Egy 20MB-os XML beolvasva 40MB (Unicode), innen indul a feldolgozás... A teljesítményre meg ott a -server kapcsoló :) (Be lehet állítani alapértelmezettnek is)
[quote:18e561dc66="ssikiss"]Úgy néz ki, meg kell barátkozni a gondolattal, hogy egy pascal nem fér bele az első 10 választási lehetőségbe (mondjuk annyi szavazatot kapott volna, mint a lisp valszeg).
Allok elebe, hogy a Lisp/C#/Assembly/Ruby negyesbol barmelyiket lenyomna, ha lenne Pascal lehetoseg. De persze nincs, mert az hatulgombolosoknak valo, nem l33t f4c3z h4x0roknak biztos. Foleg figyelembe veve h. min. 2 embert tudok, aki pl. assembly-re szavazott mert nem volt Pascal, ami jelen allas szerint az asm-ra leadott vote-ok tobb mint 10%-a...
szerintem nem mind1
ez egy jo forum
azt szeretnem hinni, hogy barmennyire is azok latszanak minositeni egy forumot akik irnak bele, megis az olvasas miatt van a forum
senki nem irna, ha nem olvasnak
mindig arra gondolok, biztos vannak akik csak olvassak
es lehet tobben vannak mint azok akik triggerelik a:
"ha hallgattam volna, bolcs maradtal volna" kenyszert masokban
naiv post-jaikkal
megis ertelme van igy is: nyitottsagot eredmenyezhet
attol tartok sem az oktatas, sem a kiscsoportos fejlesztes,
nem ad tul sok lehetoseget arra, hogy kilassunk a tankonyvbol,
vagy eppen a kovetkezo (mar megint kesunk) milestone nyomasa alol
szoval szerintem, nyugodtan irjon mindenki akinek van kedvence
irja le miert az
ennek a nalunk is honos porosz oktatasi rendszernek az a legsulyosabb nyuge, hogy megtanit "nem tevedni"
pedig a tevedes, a probalkozas, ezek az alkoto megismeres iranyjelzoi
szoval azt gondolom szabad tevedni, szabad lelkesedni
szabad azt mondani az XP thread schedulererol, hogy jo
szabad a solaris rendszer konfiguralasara azt mondani, hogy ertheto
es szabad erre valaszolni
[quote:15ad25d839="Chain-Q"]Allok elebe, hogy a Lisp/C#/Assembly/Ruby negyesbol barmelyiket lenyomna, ha lenne Pascal lehetoseg.
igen, a HUP olvasoi kozott, ahol a kedvenc nyelv a php, biztosan kedveltebb lenne ezeknel.
de ha egy kicsit elvonatkoztatunk ettol a szavazastol, melyek lennenek az (object) pascal -mint nyelv, mert azokrol beszelunk- azon featurejei, amikkel lebeszelnel arrol a fixa ideamrol, hogy a c# -az osszes featurejevel- superior a mezonyben (ismet: mint nyelv, mert azokrol beszelnuk)?
[quote:e67f58a0e8="_Joel"]Lehet. De akkor az autómban az ABS, a kipörgésgátló és a menetstabilizátor is ugyanilyen felesleges hibajavítás. Ami szükségtelen megfelelő odafigyelés/vezetés esetén. Mégis életet/anyagiakat menthet.
[quote:d068f01560="lokoto"]
Mivel a java erősen típusos nyelv, illik tudni a változók típusát. Ha tudod a változók típusát, meg tudni mondani, hogy mi történik.
Ha ez így működik akkor szerintem a nyelv a programozóra hárít egy feladatot... mert a programozónak kell fejben tartania az osszes általa használt objektum típusát és megfontolni hogy pl. egy értékadás esetén hogyan is működik az értekadás...
[quote:d068f01560="lokoto"]
Egyrészt a "mindig" mindig rövid i-vel van akár "MINDIG", akár "mindig", akár valamilyen egyéb kis- / nagybetű kombináció.
Mivan?... már nincs mibe belekötni????... :-D
Ok. Ezek után rövid i-vel írom.
[quote:d068f01560="lokoto"]
... Neked kell megírnod az összehasonlítást ahhoz, hogy el tud dönteni igaz vagy hamis a vizsgálat.
Pontosan! És ez így van jól. Én találtam ki azt a típust csak én lehetek az aki meg tudja mondani hogy miként kell összehasonlítani. De ha már megmondtam / megírtam akkor az osztályomat felhasználóknak már nem kell törődni vele a felhasználás során. Egyszerűen használhatja az összehasonlító operátort mint ahogy korábban, más adatípusok esetében.
[quote:d068f01560="lokoto"]
Nézd, én semmiről nem akarlak meggyőzni, csak fogadd el azt, hogy amit egy Sun kaliberű cég létrehozott, majd amit egy Microsoft kaliberű cég lemásolt (vagy nem, de nem is ez a lényeg, hanem az, hogy hasonlót alkotott), nagyon sokan elfogadnak, annak a hátterében lehet valami.
Engem nem érdekel az hogy egy nagy cég hozta létre... attól még nem biztos hogy jobb valami ha egy nagy cég készítette.
Porkoláb Zoltán (elte) mondta annakidején az előadáson hogy az ada-t egy bizottság készítette a c-t meg egy zseni. :)
[quote:d068f01560="lokoto"]
...de azért rosszabbnak minősíteni a C++-nál és leszólni, mert az = nem lehet klónozás és nincs benne pointer, meglehetősen korlátolt agyjárásra vall,...
Kérem mellőzni a személyeskedést! :evil:
Több oldalon keresztül próbálom megvilágítani példákkal hogy szerintrem miért nem jo a java...
[quote:d068f01560="lokoto"]
... ugyanis attól, hogy a szintaktikájuk hasonló (sőt, bizonyos részletekben azonos), a szemantikájuk *más*.
Az eltérő szemantika pedig a háttér rendszer/elképzelés következménye/velejárója/....
Itt alapvető filozófiai eltérésekről van szó, nem szintaktikai / szemantikai eltérésekről.
[quote:3a1049ca90="sz"][quote:3a1049ca90="feledhetetlen"]amugy, a sebesseg NEM SZAMIT !!!
Szerintem inkább maradjunk annyiban, h vannak esetek, amikor a sebesség nem számít.
igazad van 'altalaban' de itt...
idezem magam:
[quote:3a1049ca90="feledhetetlen"] melyik a leggyorsabb nyelv?
ami amugy eleg butuska kerdes is,
megis egyre szuletnek valaszok ra
szoval erre gondoltam, persze szamit a sebesseg
de a sebesseg nem egy nyelv tulajdonsaga
vegyel egy 10*gyorsabb gepet, oszt gyorsabb ami lassu...
vagy hasznalj dedikalt IO processort..
megkerdeznem, hogy egy IBM370 hany megahertzen 'hasit'?
tenyleg, erre en is kivancsi lennek, marmint h miert lesz "jobb" egy nyelv a masiknal? en pl. C-t hasznalok csak, ha programozok, de ez azert van, mert ezt tanitottak (persze nem a tanarok, hanem a temavezetoim). Miert kellene megfontolnom, h megprobalkozom massal is?
Teljesen elegedett vagyok a C-vel (oke, neha bosszantoan maceras, de altalaban csak sajat amatorsegemnek tudom be, lasd pl. tomb muveleteknel folyton ket for ciklust kiirni), de kivancsi is vagyok, mit rejt a tobbi nyelv.
[quote:7d495f9375="syntern"]
Kihagytam a felhasználói felületet. A tesztünk kifejezetten elkerült mindent ami a felhasználói felülettel jár, mivel az csak és kizárólag szubjektív mérés lehet. A szépség fogalmának mérése leginkább a megszokottságéval korrellál, a sebességet mérni pedig még nem sikerült kitalálnom, hogyan lenne célszerű és pontos.
Ha publikus a dolog akkor én is nagyon szívesen megnézném azt a programkódot... van rá mód?
A tartalmaz referenciát B-re, B tartalmaz referenciát A-ra.
Egyik osztály sem lesz felszabadítva amikor elengeded, hanem elleakelődik. Ezeket a referenciákat kellett null-al felülírni, hogy ne zabálja szét a memóriát.
Persze én csak a 4 évvel ezelőtti java-t mondom, a mostani nem tudom, hogy hogyan viselkedik.
A tapasztalatom az, hogy java-ban real-time alkalmazásokat nem érdemes írni. A gyors és időigényes műveleteket sosem java-ban írtuk meg, hanem natív C-ben.
A java-t és a C++-t a JNI-vel lehetett összekapcsolni. A JNI-ről annyit érdemes mondani, hogy az assembly logikusabb és áttekinthetőbb...
Szerintem a java webes alkalmazásokra való, meg egyszerűbb játékokra, de komolyabbakra semmiképpen.
- Sosem fogsz 2D / 3D motort írni java alatt
- Nem fogsz videót, DVD-t nézni java alatt
- Nem fogsz tudni megírni mondjuk egy TCP/IP stacket java-ban a misztikus késleltetések miatt (pl. Garbage Collection).
- A kriptográfiai erőforrás zabáló algoritmusokról nem is beszélve
A java csak akkor használható ilyen dolgokra, ha az időigényes szálak natívban futnak.
Azaz lehet JNI-ben gányolni, a JNI pedig nem hordozható binárisan és nem sokkal kényelmesebb, mint egy hexeditor.
[quote:c565eac7ff="feledhetetlen"][quote:c565eac7ff="popacsek"]...
Elméletileg egy java program nem futhat gyorsabban mint egy C++-os, mivel azt a byte-kódot futási időben kell lefordítani.
...
toltesi idoben
vagy eppen barmikor, peldaul install time
nem lehet ezen tullepni ? a bytecode szukseges dolog
igy lehet kornyezet optimalizalni
a csuma-koppra-szevasz optimalizalt c++ kod a foditasi platformra van optimalizalva (vagy cross compilalva egy kornyezetre)
mi van ha a cel kornyezeten, mondjuk a memoria muveletek xxxlassuak de cpu gyors, vagy forditva
nekem ugytunik, hogy itt mindenki compiler optimizer szakerto, szoval talan csak be lehet azt latni, hogy a nativ kod generalasi lepesnek a cel kornyezet toltesi idejeben van eloszor jogsultsaga
amugy, a sebesseg NEM SZAMIT !!!
rule #1: do not optimize
rule #2: (experts only) do not optimize yet
Te is a körülményekre és környezetre hivatkozol. Nem tudtok ettől elvonatkoztatni?
Én továbbra is állítom amit az előbb:
Adott egy JIT fordító, és egy C++ compiler. TFH egy adott forráskódból ugyanazt a bináris kódot generálják. Csakhogy míg a JIT fordító runtime fordítja, így összességében lassabban fog lefutni a JIT-es esetben a kód. Pont.
java -version
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_05-b05, mixed mode)
javac QuickSort.java
java -server -Xmx250m QuickSort
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
java -server -Xmx350m QuickSort
8707
8556
8552
8553
8553
Mellesleg a java-s QuickSort futása közben kevesebb free memória volt vmiért ...
Azért fordítottam -march=k8-al, mert nálam ezzel fordult az egész rendszer. Kipróbáltam anélkül is:
g++ -O2 -o qs QuickSort.cpp
./qs
5372
5172
5172
5172
mutasson mar nekem valaki egy olyan c++ nyelv szabvanyt
ami van olyan atfogo mint a JLS
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
amiben le van irva a futasi kornyezet, a nativ ki/bejarat,
es nincsen kod tobbertelmuseg
szoval az is eleg, ha csak a java.lang.* szintig, nem a tobbi csingilingi
csak ennyi, egy ilyen szabvanyt c++ ra
emlexem a borland-nal kulon osztaly volt a c++ compiler csoporton belul
akik dirket a c++ tobbertelmusegeket kerestek
nem, nem azert hogy megoldjak, azert hogy maskent oldjak meg mint a msc/watcom c++ ban
ha valamire akkor az ilyen szemet kis vendorlocking-ra a c++ kivalo
es ha a sun (helyesen) nem kemenyit be a microsoft language "extension"-jei ellen akkor ezt az 'aldast' tovabb elvezhetnenk
a c++ kivalo tovabba titkosirasra, a torekeny baseclass-ok miatt 6 oras forditasokra egy sor valtoztatas miatt...
[quote:4577167f6c="_Joel"]Lehet. De akkor az autómban az ABS, a kipörgésgátló és a menetstabilizátor is ugyanilyen felesleges hibajavítás. Ami szükségtelen megfelelő odafigyelés/vezetés esetén. Mégis életet/anyagiakat menthet.
Rossz példa...
Ezek az eszközök nem az autógyártás / tervezés során elkövetett hibákat javítják hanem a felhasználás során elkövetetteket.
Ha fordítási időben történő hibajavítás ellen semmi kifogásom nincs, mert akkor a programozó legalább megtanulja hogy nem jól csinált valamit. De így abban a tévhitben él hogy jó kódot írt ... csak éppen kétnaponta újra kell indítani az alkalmazást / szervert és erősebb vasat kell venni alá hogy elbírja...
Így szépen kinevelődnek a hanyag / nem megfelelő tudással rendelkező programozók és nő a vacak programok száma.
[quote:c3e595890b="bocs"][quote:c3e595890b="syntern"]valószínűleg ki fog jönni, hogy nem feltétlen a C++ a legkönnyebben kezelhető eszköz, a hosszú távú kódkarbantartásra és a platformok közötti hordozásra (főleg mikor már érint grafikus részeket is) biztosan nem.
hmmm QT? "kissé" gyorsabban válaszol desktopon, mint egy javas felület.
persze megy unixokon, win-en, PDA-n stb.
Hát nem tudom, valószínűleg igazad lehet, bár fejlesztettem már KDE alá, és az akkor nem győzött meg, mert külön vacakolni kellett a Windowsos portolással. Mindenesetre egy gráfkezelő és szerkesztő környezet (jung.sf.net) integrálása nem volt nehéz Java alatt, megy Linuxon, Windowson, különösebb strapa és újrafordítás nélkül. Nekem ez jobban bejön, mint a vacakolás :)
ennek a nalunk is honos porosz oktatasi rendszernek az a legsulyosabb nyuge, hogy megtanit "nem tevedni"
pedig a tevedes, a probalkozas, ezek az alkoto megismeres iranyjelzoi
nyenyec blogján (nyenyec.freeblog.hu) olvastam egy jót erről és maximálisan egyet tudok vele érteni:
(...) De a lényeg nem a sör volt, hanem hogy kommunikáltunk végre mindenféle dolgokról a projektekkel kapcsolatban. Ez a csapatunk egyik gyengéje és most jutottam el arra a következtetésre, hogy ebben szerepe van, szerepe lehet a kultúrális különbségeknek. Egyszerűen, mi, magyarok nem vagyunk annyira nyitottak, nem kommunikálunk annyira könnyen, mint az amerikaiak.
Az amcsiknál nem néznek hülyének, ha kérdezel, vagy valami rosszat mondasz. Mernek hülyeséget mondani (emiatt sokszor mi hülyének nézzük őket, pedig mi gyakran sem tudunk többet, csak többet kussolunk). Sokat gondolkoztam ezen, főleg, miután interjúztatni kellett az új mérnököket és diákokat. Egyszerűen nem ismerek senki magyart, aki annyira laza bírt volna lenni egy ilyen (fontos!) felvételi interjú kapcsán, mint az a főiskolát végző diák, akit mi kérdezgettünk. Sokkal kevesebb gátlás van bennük ezen a téren.
Mindegy, most eszméltem rá hosszú évek után, hogy ez a projektekben is okozhat problémákat. Kissé sarkítva: én azt várom, hogy nekem a főnök megmondja, amit tudnom kell, ő meg azt várja, hogy én kérdezzem, amit szerintem tudnom kell.
Amúgy van neki egy a témába vágó megjegyzése is:
A Python már eleve annyira lassú, hogy senkinek nem jut eszébe optimalizálgatni, vagy azon gondolkodni, hogy milyen a teljesítmény. Ez óriási szabadságot jelent, sokkal tisztább kódot lehet írni. A Java-s API-knak görcsölni kell azon, hogy milyen a teljesítmény, hogy kellően minimalisztikus legyen a design, hogy ne legyen redundáns, stb.
Ezért nem lesz a Javaban olyan hívás, hogy File.readLines() ami sorokra darabolva visszaadja a file tartalmát, vagy nem lehet olyat mondani, hogy urlopen("akarmi").read() ami beolvassa a cuccot egybe es visszaad egy stringet.
Persze nehány sorban megírhatóak ezek Javaban is és aztán valaki összegyűjtheti őket egy JARfileba, de úgy tűnik, nem teszik. Szerintem azért, mert lélekben valahol még mindig a C/C++-szal akar versenyezni a Java.
[quote:1f96a2e57d="snq-"]de ha egy kicsit elvonatkoztatunk ettol a szavazastol, melyek lennenek az (object) pascal -mint nyelv, mert azokrol beszelunk- azon featurejei, amikkel lebeszelnel arrol a fixa ideamrol, hogy a c# -az osszes featurejevel- superior a mezonyben (ismet: mint nyelv, mert azokrol beszelnuk)?
Mivel igyekszem tavoltartani magam mindentol amihez az M$-nek koze van mint fejleszto, ezert a C#-t sem ismerem annyira, hogy a fenti kerdesre erdemben valaszoljak. Igen, fajgyulolo vagyok, es eloiteleteim vannak. Beismerem. Ez van.
[quote:bd63633b0c="handler"]
PTK/A kártérítés általános szabályai:
342. § (1) Semmis valamely szerződésnek az a kikötése, amely a szándékos vagy súlyos gondatlanságból eredő károkozásért, az életben, a testi épségben, az egészségben okozott károsodásért, továbbá bűncselekmény következményeiért való felelősséget előre korlátozza vagy kizárja.
[quote:bd63633b0c="lzrd"]
Ezexerint nincs igazad, hála a magasságosnak, de azért köszi! :)
Szal nem verhetik el a port a programozón, ha nem súlyosan és nem szándékosan gondatlan...
Meglehetosen furcsa kovetkeztetest tudsz levonni. Te allitottal valamit (egy tablaval ki lehet zarni minden felelosseget). En *egy* peldaval cafoltam. Ebbol egyaltalan nem kovetkezik, hogy az allitasnak csak egy cafolata lehetseges.
[quote:163c82ab8f="Frimen"]
...
Szerintem ez a java & C sebesség kérdésében igen csak megmutatkozik.
Amugy érdekes.. azt vártam valaki reagálni fog itt a c-s példára, de nem..
Valószinű nem ez a legjobb forum ilyesmire..
Fri
nem az execution time az igazi elteres a C es a java kozott
hanem a runtime sebesseg optimalizalas lehetosegenek megorzese/elvesztese
A normalis C forditok is mind pseudo koddal dolgoznak, csak a forditas
soran az utolso lepesben 'bevasaljak' a platform specifikus targykodot.
A javaban az utolso compiler pass el van halasztva a toltesi (sot a futasi) idore.
A Java annyi elonnyel indul, hogy a Compiler (java terminologiaban a Compiler a just in time Compiler) megkapja az eselyt extensive optimalizaciora. Illetve a bytecode megorzi ezt az eselyt.
Ez lehetoseget ad akar az elhalasztott profiled runtime optimalizaciora is mint azt a HotSpot teszi.
Arra szeretnek csak ramutatni, hogy a leforditott java kodban megmarad a gyorsitas lehetosege, mig a C targykod 'doglott' ebbol a szempontbol.
[quote:e61da76f74="_Joel"]
Hmm, amikor Számításelmélet szigorlaton valamelyik véges testen, vagy gyűrűn értelmezett műveletnél kérdez a tanár egy ilyet... akkor valószinűleg elgondolkozom.
De most komolyan, mondjuk ket Bankszamla peldany eseten pontosan mire is alkalmaznad a + operatort? Es a melletted ulo programozo?
Én nem azt mondtam hogy pl. a + operátort minden esetben lehet használni. Nyílván olyan esetekben ahol egyértelmű mert olyan a művelet amit a + jellel szokás jelölni.
pl.
[quote:99b104bbfc="blau"]Miert kellene megfontolnom, h megprobalkozom massal is?
nem kell, de lehetnek olyan featureok, nyelvi elemek, amik segithetetnek abban, hogy a fejlesztesi ido nagy reszeben a megoldando problemara koncentralj, vagy karbantarthatobb kodot irj, valoban ujrafelhasznalhato osszetevokkel.
csodafegyver persze nincs, egy gyors-hack adatkoverzionak perllel vagy pythonnal, eszkozcsatolonak c-ben allnek neki. c# meg mehet minden masra:)
[quote:49ee333aab="snq-"][quote:49ee333aab="blau"]Miert kellene megfontolnom, h megprobalkozom massal is?
nem kell, de lehetnek olyan featureok, nyelvi elemek, amik segithetetnek abban, hogy a fejlesztesi ido nagy reszeben a megoldando problemara koncentralj, vagy karbantarthatobb kodot irj, valoban ujrafelhasznalhato osszetevokkel.
csodafegyver persze nincs, egy gyors-hack adatkoverzionak perllel vagy pythonnal, eszkozcsatolonak c-ben allnek neki. c# meg mehet minden masra:)
ertem. nem provokacio akart lenni, tenyleg kivancsi vagyok, hogy milyen megkozelitesek leteznek egy programozo szamara (nem vagyok, es valszeg nem is leszek az).
Hehe, alapvetően nem érti a Pascalt. Ott blokkok vannak, amik begin-el kezdődnek és end-el végződnek. Ez mindig így van. És ha meg akarja az ember jelölni az end-et, mert sok egymásba ágyazott blokk van, akkor egyszerűen megjegyzéssel utánateszi, hogy { if }
[quote:c2441c2ff1="Csab"]Mindig mosolygok a java-s mátrix implementációkon.
java
Matrix result = (((a.add( b )).multiple( c )).divide( 23. )).inv();
c++
Matrix result = ~(((a+b)*c)/23);
mi a baj a java valtozattal, el lehet olvasni?
amugy meg nem ertem, miert inv, es miert divide, miert nem div, es invert ?
nekem egyszer, egy F-15 Strike Eagle nevu programot kellett atirnom
a jatek egy azota kihalt Forth nevu nyelv egy idiomaja volt
azt kell mondanom hogy ott hosszu idore el ment a kedvem attol, hogy ilyen titkosiras kifejezeseket irjak at olvashatora
ha valaki meg emlexik a Forth-ra, vagy esetleg magara a Microprose-os Sid Meier fele sid nyelvre, kerem erositsen meg...
[quote:a9a4dbfc88="trey"]A 2005-ös év kedvenc programozási nyelve.
Idén tetszett a FLORA-2 (XSB, ~ Prolog alapokon). Egész kellemes a logikája, valamint az objektumkezelése.
Szavazatom azonban a Java-é lett. (Azonban érdekelne, hogy hányan használják napi szinten a Prologot, vagy valamely leszármazottját. Remélem jövőre nem felejtem el ajánlani.:))
[quote:2b01257234="maszili"]
Mikor állítottam én azt hogy profi vagyok java-bol???????
Pont az ellenkezőjét állítottam! Azért kérdeztem meg itt azokat az embereket akik JÓL ismerik a java-t hogy felvilágosítást kapjak!
Szerintem senki nem állította azt, hogy azt állítod profi vagy Javából. Itt azzal az egy aprósággal van gond, hogy nem érted meg azt, hogyha nem ismersz valamit kellőképpen, akkor elég nehéz róla érdemben nyilatkozni, minősíteni.
[quote:2b01257234="maszili"]
A kialakult helyzetre megpróbálok egy történettel válaszolni:
Egy vevő bemegy egy boltba és megkérdezi az eladót hogy az X termék tudja-e azt amit a másik boltban kapható Y. Az eladó megvizsgálja a kérdést és arra jut hogy az X tényleg nem tudja. Megpróbálja bebizonyítani a vevőnek, hogy de mégis... persze sikertelenül. Ekkor az eladó feldühödik és elzavarja a vevőt a francba azzal az indokkal hogy a vevő nem ismeri elég jól az X-et.
Költői kérdés: az eladó helyesen járt el?
Tudod egyáltalán, hogy miről irogatsz?
Ha már ennél a nem túl frappáns példánál tartunk: jelen társalgás arról szól, hogy attól, hogy X nem tud egy olyan dolgot, amit Y, attól még X lehet egy jó termék.
Kicsit még konkrétabban - bár ez a példa sem tökéletes: tfh, egy terepjáróban vannak terepfokozatok, egy forma1-es kocsiban nincsenek. A terepjáró jobb autó (ennyi információ alapján)?
[quote:2b01257234="maszili"]
[quote:2b01257234="lokoto"]
Például ha üres, alapértelmezett konstruktorral létrehozott listába pakolsz egymást után 500000 elemet, a háttér tömböt többször is meg kell növelni, majd az elemeket áttenni, ami nyilván nem az elérhető teljesítmény.
Engem nem érdekel hogy a lista objektum hogyan oldja meg a problémáit. Az legyen a lista osztályt megíró programozó feladata.
Na látod, itt a probléma. 500000 Integer esetén majdnem 100%-os a sebességnövekedést lehet elérni azzal, hogy tudod miként működik. Jelen esetben csak egy konstruktor hívásnyi különbség van (vagy egy metódus hívásnyi kicsit más környezetben, lényegen nem változtat).
int cnt = 500000;
java.util.ArrayList l = new java.util.ArrayList();
for (int i = 0; i < cnt; i++)
l.add(new Integer(i));
int cnt = 500000;
java.util.ArrayList l = new java.util.ArrayList(cnt);
for (int i = 0; i < cnt; i++)
l.add(new Integer(i));
Jól sejtem, hogy ez nem Java specifikus?
[quote:2b01257234="maszili"]
Az operator overloading egy olyan eszköz ami egyszerűsíti / megkönnyíti a program írást. A java nem tudja mert az alap koncepciója (filozófiája) az hogy csak a gyárilag megírt operátorokat lehet használni, szemben a c++ filozófiájával ami támogatja a saját operátorokat. Ezek után én azt mondom hogy a java filozófiája rosszabb mint a c++ filozófiája.... ez így érthető volt? Ennél egyszerűbben már nem tudom leírni.
Teljesen érthető, hogy mit akarsz mondani, konkrétan azt, hogy hiányolod a Javából az operator overloadingot, és Neked emiatt jobban tetszik a C++. (de ettől még nem rosszabb a Java filozófiája - a két értékelésnek enyhén szólva más a dimenziója)
Fordítsunk a helyzeten (kérem a szöveget nem kiragadni a környezetéből):
- a C++ filozófiája rosszabb, mint a Javáé, mert nincs benne reflection
- a C++ filozófiája rosszabb, mert nincs benne GC
- a C++ filozófiája rosszabb, mert nincsenek benne csomagok
[quote:2b01257234="maszili"]
Mindenképen... én személyeskedés nélkül kérdezek / érvelek.
Ha én értelek félre, elnézést, de szerintem Te egy nem Tőlem származó hozzászólást tulajdonítasz nekem.
(amúgy amire gondolsz, az egy egyszerű megállapítás volt vki részéről, amin szerintem nem felháborodni és megsértődni kellene, hanem elgondokodni rajta)
[quote:2b01257234="maszili"]
Rendben... akkor próbálj úgy programozni hogy a + jel helyett használd ezt... szigorúan java stílusban :)
[quote:da8c33cf52="maszili"]
Így szépen kinevelődnek a hanyag / nem megfelelő tudással rendelkező programozók és nő a vacak programok száma.
Egy program vacaksága nincs összefüggésben a felhasznált progamnyelvvel.
Ajánlom figyelmebe ezeket a linkeket:
http://blogs.sun.com/roller/page/alanc?entry=solaris_desktop_summit_performance_day
http://blogs.sun.com/roller/page/jmr#solaris_desktop_summit_performance_day1
Most megy egy desktop performance summit Solaris és Gnome fejlesztők részvételével (Sun-on belül). Hihetetlen milyen gány kódokat találnak:
" * bmc noticed a lot of time being spent in the close() system call, which seemed strange. Tracking this down to the stack trace involved, yippi saw it was socket closes in the gdmlogin configuration calls. When gdmlogin needs to get a configuration value from the parent gdm daemon it opens a socket, checks the version, asks for the value it needs, then tears down the socket. Over and over again it does this, instead of simply caching the socket and reusing it for future calls, so yippi is looking into seeing if we can convert it to do so.
* bmc also noticed a lot of stat() system calls, and found two big causes:
o gdm has a list of possible supported locales and stats the locale directories for each ones to see which are installed. We thought of two ways to reduce the cost of these. First, instead of having gdmlogin do this every time, having the parent do it and pass the list to the children could reduce the time on systems with multiple login screens, such as multiseat systems, including Sun Ray. That shouldn't make much difference on single user system though, but the second idea, to change the scan to instead read the parent directory containing all the locales and use the list of it's subdirs instead of a huge list of all possible subdirs could greatly cut down the number of system calls on systems with only a few locales installed.
o gdm was also scanning lots of directories to find the icons for the gtk theme, including stat'ing the same directory over and over again. Another group is looking into gtk performance and will be looking into this more."
[quote:d93fe408b7="syntern"]
Bizonyára Te is belátod, hogy egy ilyen teljesítménymérő tesznek nem az a célja, hogy az adatbázis sebességét mérje, mivel az pl. mind C++-ból, mint Javaból nagy valószínűséggel ugyanannyi lesz. Hasonlóképpen vonatkozik ez diskműveletekre, hálózatra, mert itt is az overhead nem a nyelv és a managelt környezet, hanem dominánsan a TCP stack, a vas, a kábel.
Szerintem ebben nincs igazad.
Itt nem TCP-ről van szó, és nem is az alkalmazás szintű protokollrol, hanem arról,
hogy egy "driver", legyen az java estében jdbc, rmi milyen teljesitmenyre képes,
mennyit "tud".
[quote:d93fe408b7="syntern"]
Szóval ha tudsz mondani olyan tesztet, ami tisztán a Java managelt környezetet hasonlítja össze a C++ natív futásával, és nem ez a "tipikusan buta" teszt, akkor szeretettel várom és kimérem. De amíg csak azt tudod mondani egy neked nem tetsző eredményre, hogy ez butaság, addig ne haragudj, de nem tudom komolyan venni amit írsz.
Kihagytam a felhasználói felületet. A tesztünk kifejezetten elkerült mindent ami a felhasználói felülettel jár, mivel az csak és kizárólag szubjektív mérés lehet. A szépség fogalmának mérése leginkább a megszokottságéval korrellál, a sebességet mérni pedig még nem sikerült kitalálnom, hogyan lenne célszerű és pontos.
A komolyan nem vevés kölcsönös.:)
Nem foglalkoztam soha azzal, hogy teljesitmény teszteket kutassak fel.:)
Amugy.. lehet, hogy szubjektiv egy felhasználói felület, de mivel a programok több
mint 50 százaléka guis felülettel dolgozik addig nem lehet félresöpörni.. mondom továbbra is (ezért) idióta teljesitménytesztekkel. A másik.. hogy egy szervert bővithetsz, egy munkállomás bővithetsz, egy felhasználót meg, bármely szubjektiv is a véleménye nem lehet kihagyni a valós tesztekből, mert az, hogy mennyire megelégeded a
szoftverrel, döntő tényező.
[quote:d93fe408b7="syntern"]
Szóval ha van elképzelés, hogy hogyan máshogy lehetne összehasonlítani a C++-t a Javaval, akkor szeretettel várom, addig pedig csak azt tudom mondani, hogy a C++ semmilyen előnyt nem nyújt az alkalmazások nagy részében a Javahoz képest, amivel szemben a Java azért tud előnyt biztosítani.
Nincs érteleme.. ezt bizonyitja több tucatnyi program.
Egy C-ben irt GUI-s program sokszor nagyságrendekkel gyorsabb mint egy java-ban
irt program.
Mielőtt azt mondod C-s bérenc vagyok, magam is Javazom, és bevallom magamban
sül a pofám amkor látom, hogy egy c-s program hogy dobálja fel az ablakokat..
szemben a java csiga lassuságával.
Fri
[quote:8f8990ebde="syntern"]különösebb strapa és újrafordítás nélkül. Nekem ez jobban bejön, mint a vacakolás :)
jaja, virágozzon száz virág.
mások a preferenciáink. nekem fizikai fájdalmat okoz, ha a processzoridő felét, kétharmadát kidobom az ablakon egy kis "vacakolás" kedvéért, és cserébe általában kapok egy meglehetősen lassú érzetet keltő desktop alkalmazást.
/de nem akarok itt már túl sokat szájat tépni, csak nem szeretném, hogy valakiben az a kép alakuljon ki, hogy a Java mindennél jobban alkalmas bármilyen feladatra/
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
Mivel a java erősen típusos nyelv, illik tudni a változók típusát. Ha tudod a változók típusát, meg tudni mondani, hogy mi történik.
Ha ez így működik akkor szerintem a nyelv a programozóra hárít egy feladatot... mert a programozónak kell fejben tartania az osszes általa használt objektum típusát és megfontolni hogy pl. egy értékadás esetén hogyan is működik az értekadás...
Nem értelek. Javában ponthogy baromira egyszerű:
primitív típus esetén (boolean, int, long, double, ...)
a = b; // a felveszi b értékét
egyéb esetben:
a = b; // a ugyanarra az objektumra lesz referencia, mint b (máshogy fogalmazva: mindkét változón uazt az objektumot lehessen elérni)
Nem elég egyszerű és egyértelmű?
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
Egyrészt a "mindig" mindig rövid i-vel van akár "MINDIG", akár "mindig", akár valamilyen egyéb kis- / nagybetű kombináció.
Mivan?... már nincs mibe belekötni????... :-D
Ok. Ezek után rövid i-vel írom.
Nem belekötök a dolgokba, csak leírom a véleményet, a "mindíg" pedig kifejezetten zavar. Köszi.
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
... Neked kell megírnod az összehasonlítást ahhoz, hogy el tud dönteni igaz vagy hamis a vizsgálat.
Pontosan! És ez így van jól. Én találtam ki azt a típust csak én lehetek az aki meg tudja mondani hogy miként kell összehasonlítani. De ha már megmondtam / megírtam akkor az osztályomat felhasználóknak már nem kell törődni vele a felhasználás során. Egyszerűen használhatja az összehasonlító operátort mint ahogy korábban, más adatípusok esetében.
Ez mind rendben van, uezt javában is meg tudod írni, de:
primitívek esetén:
a == b: true, ha ugyanaz az értékük, false egyébként
egyéb esetben:
a == b: true, ha uarra az objektumra mutatnak
Ez a definíció (tudtommal, ha nem is pontosan így fogalmazva). A Java így gondolkodik, legalábbis jelenleg. Lehet, hogy Java8-ban felüldefiniálhatod pl a +-t, de jelenleg nem lehet, elképzelhető, hogy ez kényelmetlen némely esetben, de egy ilyen miatt rosszabbnak minősíteni a Javát, az húzós.
Örülnék, ha csak ennyi lenne összeségében a probléma - bármilyen nyelvvel, környezettel.
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
Nézd, én semmiről nem akarlak meggyőzni, csak fogadd el azt, hogy amit egy Sun kaliberű cég létrehozott, majd amit egy Microsoft kaliberű cég lemásolt (vagy nem, de nem is ez a lényeg, hanem az, hogy hasonlót alkotott), nagyon sokan elfogadnak, annak a hátterében lehet valami.
Engem nem érdekel az hogy egy nagy cég hozta létre... attól még nem biztos hogy jobb valami ha egy nagy cég készítette.
Porkoláb Zoltán (elte) mondta annakidején az előadáson hogy az ada-t egy bizottság készítette a c-t meg egy zseni. :)
Mindennél van jobb, nem is vitatom, de jelenleg úgy tűnik, hogy elég sok igényt kielégít, elég nagy piaca van (ez a tény nem igazolja, hogy a Java jó, csak azt mutatja, hogy valamire azért mégiscsak lehet használni, költeni kevésbé szeretnek a cégek, mint osztalékot fizetni)
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
...de azért rosszabbnak minősíteni a C++-nál és leszólni, mert az = nem lehet klónozás és nincs benne pointer, meglehetősen korlátolt agyjárásra vall,...
Kérem mellőzni a személyeskedést! :evil:
Több oldalon keresztül próbálom megvilágítani példákkal hogy szerintrem miért nem jo a java...
nyugodtan, vannak hátrányai, de meglátásom szerint elég gyenge érv az, hogy azért nem jó a java, mert:
a.equals(b) helyett nem írhatsz a == b kifejezést, vagy a = b.clone() helyett nem írhatsz a = b kifejezést.
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
... ugyanis attól, hogy a szintaktikájuk hasonló (sőt, bizonyos részletekben azonos), a szemantikájuk *más*.
Az eltérő szemantika pedig a háttér rendszer/elképzelés következménye/velejárója/....
Itt alapvető filozófiai eltérésekről van szó, nem szintaktikai / szemantikai eltérésekről.
A szintaktikának kicsit kevesebb köze van a filozófiához, de alapvetően egyetértünk.
És meg is érkeztünk: egy filozófia nem lehet rossz vagy jó, egy filozófia van, esetleg a benne megfogalmazott állításokat valamilyen értékrend szerint lehet értékelni, de abszolút minősíteni nem, mert abszolút igazság nincs (legalábbis így rémlik...).
Ilyen "apró" szintaktikai jellemzők alapján minősíteni lehet egy nyelvet, de egyéb jellemzőkkel nem biztos, hogy arányban áll a jelentősége.
(szerintem ez nem olyan téma, hogy egy autó akkor jó, ha piros, egyébként legyen az bármilyen is, de tuti rossz, vagy rosszabb, mint egy piros autó)
[quote:479805c9af="popacsek"]Adott egy JIT fordító, és egy C++ compiler. TFH egy adott forráskódból ugyanazt a bináris kódot generálják. Csakhogy míg a JIT fordító runtime fordítja, így összességében lassabban fog lefutni a JIT-es esetben a kód. Pont.
Kivéve ha nem JIT fordító, hanem runtime profiler. A Java HotSpot egy runtime profiler, hosszú távú optimalizációra berendezkedve.
És végre az első alternatív mérések :)
[quote:479805c9af="popacsek"]g++ -O2 -march=k8 -o qs QuickSort.cpp
./qs
5371
5173
5173
5173
Valahogy ebből nekem az jön le, hogy a C++ kód sebessége ugyanúgy runtime környezet függő, mint ahogy a Java függ a JVM képességeitől. (Próbáld ki pl. alap Ubuntu telepítéssel.) Ennek két következménye van:
1. Van még mit fejlődnie a JVM-nek, és gyanítom, hogy fog fejlődni. (Érdemes lenne kimérni JRockit-tal, van erre is kapacitásod?)
2. Az emberek látják a te 60-70%-os tesztedet, de nem fogják tapasztalni, hanem azt tapasztalják amit én, azaz +-10%-ot. Gentoo (és egyéb fordítsd le az összes forrást) kivételével nincs olyan szoftver-disztrib, amelyik teljes egészében speciálisan processzor-optimalizált lenne, beleértve ebbe nem csak az oprendszereket, hanem az egyes dobozos szoftvereket is.
Azaz megintcsak arról van szó, hogy menj mindenben a hardver közelébe, és akkor gyors leszel. Igaz ez a Javara is. Vagy maradj meg általánosnak (C++ is) és akkor hasonló teljesítményt produkálsz (Java is). Ellenvélemény?
[quote:7a3561da7b="feledhetetlen"]
ha valaki meg emlexik a Forth-ra, vagy esetleg magara a Microprose-os Sid Meier fele sid nyelvre, kerem erositsen meg...
Én emlékszem a Forth-ra, jó kis veremalapú nyelv volt... :-)
(Igazán soha nem használtam, csak érdekes volt a felépítése.)
Egyébként volt egy nyelv, talán APL volt a neve, ahol egy csomó (nem betű és nem szám) ASCII karakter volt mindenféle operátor, pl. beépített mátrixműveletei voltak.
hello,
[quote:d96d03b256="Nickname"]Filozófiailag mitől kedvenc egy programnyelv ?
...
csak úgy kérdem, mert olyan kiváncsi vok.
pl: egy feladatot relatíve könnyen, és gyorsan meg tudsz oldani; bonyolult feladatot meg tudsz vele oldani; a kettőt tudod ötvözni :)
ezek alapján az assembly szerintem egyértelműen kiesik, bár semmi bajom vele, de lássuk be: elég lassan lehet benne fejleszteni (csak példa volt).
A C egy fokkal jobb, bár én kimondottan szeretek C-ben progamozni, imho a Pythonban történő fejlesztés lényegesen gyorsabb. :) Ezen kívül elég sok platformon megvan, a Linuxok többségében alapból benne van, egyszerre töb verzió fenn lehet, kicsi... mi kell még? :)
[quote:e2bcfb2262="popacsek"]
Mellesleg a java-s QuickSort futása közben kevesebb free memória volt vmiért ...
hogy oszinten legyek utalom az osszes ilyen 'nem eleg gyors' uzekedest
ez hajszolta bele a sun-t abba a kapitalis baromsagba, hogy a JLS-t athagva intel fpu kodokat forditson az 1.1-ben
mert nem volt eleg 'gyors'
az lett az eredmenye, hogy ma a hotspot compiler az x86 platformon tud olyat produkalni, hogy egy futtatasi session-on belul egy double szorzas ugyanazokkal a szamokkal 2 fele eredmenyt produkal, persze kozel azonosat :)
felemelo lenne, ha java sebessegrol az irna ezutan aki meg tudja mondani hogyan tortenhet ez meg...
[quote:9dc0ee8393="waiter"]
Nem tudom, mi a "programozási nyelv" pontos definíciója, de IMHO egy programozási nyelvnek általános érvényű (és nem egy specializált) eszköznek kellene lennie, legyen szó bármilyen szoftverfejlesztési feladat megoldásáról.
- waiter -
"pontos definíciót" már adtak, szerintem ha egy nyelvben megvannak az elemi programok megvalósításához szükséges nyelvi elemek (értékadás, elágazás, ciklus, etc...), akkor azt nyugodtan hívhatjuk programnyelvnek.
Elméletileg assemblyben is írhatsz CGI-t, de a gyakorlatban PHP-ban kicsit hamarabb végzel vele, és könnyebben fogod bővíteni, meg ilyenek... :))
[quote:396447198c="feledhetetlen"]az lett az eredmenye, hogy ma a hotspot compiler az x86 platformon tud olyat produkalni, hogy egy futtatasi session-on belul egy double szorzas ugyanazokkal a szamokkal 2 fele eredmenyt produkal, persze kozel azonosat :)
felemelo lenne, ha java sebessegrol az irna ezutan aki meg tudja mondani hogyan tortenhet ez meg...
Annyira elmerültetek a részletekben, hogy az elképesztő!
Szerintem érdemesebb megnézni, hogy a két nyelven (C++ vs. Java) mennyi idő és erőfeszítés révén lehet ugyanazt elérni.
Engem eléggé meggyőzött korábban a Java sebessége itt a topic-on beírt példákban (én is kipróbáltam a qsort példát). Ezért aztán megnéztem, hogyan lehet Swing-gel dolgozni, ha az ember egy grafikus progit akar összehozni. Őszintén szólva teljesen elborzadtam a rengeteg származtatás meg osztály láttán. Még az eseménykezelés is egy katasztrófa.
Szerintem Javában legalább 3-szor akkora munka felületet programozni, mint egy jó C++-os toolkittel.
Itt egy példa, ahol a Java kód forrása közel 7-szer (hétszer!!!) akkora, mint a teljesen ugyanazt végző C++ kód:
[quote:7c5b1e982a="lokoto"]
Nem értelek. Javában ponthogy baromira egyszerű:
primitív típus esetén (boolean, int, long, double, ...)
a = b; // a felveszi b értékét
egyéb esetben:
a = b; // a ugyanarra az objektumra lesz referencia, mint b (máshogy fogalmazva: mindkét változón uazt az objektumot lehessen elérni)
Nem elég egyszerű és egyértelmű?
Korábban írtam hogy nem... miért kell ugyannak az operátornak kétféleképen működni? Mégy szerencse hogy csak kétféle működése van... mi lenne ha több lenne? :)
[quote:7c5b1e982a="lokoto"]
Ez mind rendben van, uezt javában is meg tudod írni, de:
primitívek esetén:
a == b: true, ha ugyanaz az értékük, false egyébként
egyéb esetben:
a == b: true, ha uarra az objektumra mutatnak
Erre pont ugyanazt tudom válaszolni mint az előbb.
[quote:7c5b1e982a="lokoto"]
Mindennél van jobb, nem is vitatom, de jelenleg úgy tűnik, hogy elég sok igényt kielégít, elég nagy piaca van (ez a tény nem igazolja, hogy a Java jó, csak azt mutatja, hogy valamire azért mégiscsak lehet használni, költeni kevésbé szeretnek a cégek, mint osztalékot fizetni)
Én egy szóval sem állítottam hogy a java nem jó semmire. Ennek a topic-nak az a címe hogy Kedvenc programozási nyelvem. Na ennek keretén belül mondtam el a véleményemet: Szerintem a c++ jobb mint a java.
[quote:7c5b1e982a="lokoto"]
nyugodtan, vannak hátrányai, de meglátásom szerint elég gyenge érv az, hogy azért nem jó a java, mert:
a.equals(b) helyett nem írhatsz a == b kifejezést, vagy a = b.clone() helyett nem írhatsz a = b kifejezést.
Ha végigolvastad a korábbi hozzászólásokat és ezek után sem érted hogy mit próbálok magyarázni akkor kész... ennél jobban már nem tudom elmondani. Sajnos nem tudok olyan könyvet ajánlani amiben ezek a filozófiai kérdések le lennének írva. Be kell ülni valamelyik egyetemre egy jó tanár előadására. :)
[quote:7c5b1e982a="lokoto"]
És meg is érkeztünk: egy filozófia nem lehet rossz vagy jó, egy filozófia van, esetleg a benne megfogalmazott állításokat valamilyen értékrend szerint lehet értékelni, de abszolút minősíteni nem, mert abszolút igazság nincs (legalábbis így rémlik...).
Szerintem meg lehet jó vagy rossz egy filozófia, mert azt az adott környezetben az adott feladat megoldása során vizsgáljuk. Ha nem így lenne akkor elég lenne a strukturált programozás és nem lenne szükség az OO-ra.
[quote:c6358494b1="_Joel"][quote:c6358494b1="Andrei"]Felhivnam a figyelmedet, hogy ilyen kornyezetben a GC is borzaszto rosszul teljesit. A korkoros hivatkozasokkal pl. nemigen tud mit kezdeni, vagy erosen leromlik a teljesitmenye....
A mark and sweep vagy a stop and copy algoritmusra gondolsz? Azzal azert ugye tisztaban vagy, hogy hogyan is mukodik a gc a modern jvm-ekben? Hogy mikor es hogyan kerul egy objektum a young generation-bol a tulelo oregek koze, es ez gc-ileg pontosan mit is jelent: melyik generation-nel milyen algoritmusokat hasznal a jvm es ezt hogyan tudod te valtoztatni. Milyen statisztikai eloszlasa van az objektumoknak az eletidejuket tekintve, es erre vonatkozoan hogyan probalnak optimalizalni gc-ileg a virtualis gepek...
En csak annyit tudok, hogy hiaba erolkodunk egyszeruen nem eleg gyors a GC egy csomo feladatra. Mondom, ide kell cibalni azokat a real world powerappokat, amivel igazolni tudod, hogy ez az egesz szisztema megallja a helyet egy hasonlo hagyomanyos C++ alkalmazassal szemben. Mert ezeknek hiszek, de amig a csavokam egy feloldalas kodon probalja demonstralni a technologia felsobbrenduseget, addig nemigen tudom komolyan venni. Na hallod, feloldalas algoritmust minden nyelven elegansan es hatekonyan lehet lekodolni.
Az egyik program, amivel dolgunk van az az ArchiCAD (epiteszeti tervezoszoftver). Ez az alkalmazas 6 millio sor C++ kod. Jocskan megizzadna a JVM, mire beizzit egy ilyen meretu cuccot. Es ha meg menne is akkor uj ertelmet nyernenek a Sun Fire 20-25k gepek, mert ez egy mezei workstationon nagyon hurka lenne.
Azt meg egyszeruen keptelen vagyok elfogadni, hogy a GC-t, mint a programtervezest konnyito eszkozt kelljen elkonyvelni. A programozast konnyiti. Bizonyos feladatokat, amiket eddig a programozonak explicit kellett elvegezni, a runtime kornyezet megteszi helyetted, de ez nem jelenti azt, hogy nem kell a tervezes soran vegiggondolni az objektumok elettartamat. Szar kodot barmiben tudsz irni es talan Java-ban meg konnyebb is, mint mas nyelven.
Csak konnyebb idomitott programozok 1000 fos hordajat ertelmes munkara szoritani, mert szegenykem kevesebb dolgot tud elrontani Java-val... Javaban vigan kodolnak az indiai outsource rabszolgak, mikozben keptelenek lennenek C++-ban egy normalis konstruktort megirni, vagy egy kicsit is komplikaltabb kifejezes mukodeset precizen elkepzelni.
[quote:e29d52615c="Csab"]Volt szerencsém sokat szívni java-val. Legyen két osztály: A és B. A tartalmaz referenciát B-re, B tartalmaz referenciát A-ra.
Egyik osztály sem lesz felszabadítva amikor elengeded, hanem elleakelődik. Ezeket a referenciákat kellett null-al felülírni, hogy ne zabálja szét a memóriát.
Persze én csak a 4 évvel ezelőtti java-t mondom, a mostani nem tudom, hogy hogyan viselkedik.
Nem tudom, hogy 4 éve hogyan működött (bár emlékeim szerint mindig futó threadekből elérhető objektum-referenciákkal dolgozott, azaz sohasem fordult elő a fenti eset), de hogy ma nem így működik, az biztos.
[quote:e29d52615c="Csab"] A tapasztalatom az, hogy java-ban real-time alkalmazásokat nem érdemes írni. A gyors és időigényes műveleteket sosem java-ban írtuk meg, hanem natív C-ben.
Ez persze nem biztos, hogy azért történt, mert a Java lassú lenne :). Mindenesetre most már nyomulnak a Real Time JavaVM-el is, ha valakit ez a része érdekel.
[quote:e29d52615c="Csab"]A java-t és a C++-t a JNI-vel lehetett összekapcsolni. A JNI-ről annyit érdemes mondani, hogy az assembly logikusabb és áttekinthetőbb...
Ízlések és pofonok. Én emlékeim szerint először és utoljára papíron, egy vizsgán írtam JNI-s programot, de legalábbis ott kérdeztek valami JNI-t, és nem volt semmi gondom vele. Arról nem is beszélve, hogy CORBA-n is össze lehet kapcsolni a kettőt. Meg még 100+1 módon...
[quote:e29d52615c="Csab"]Szerintem a java webes alkalmazásokra való, meg egyszerűbb játékokra, de komolyabbakra semmiképpen.
- Sosem fogsz 2D / 3D motort írni java alatt
Semmivel sem rosszabb, mint egy C++ 3D engine, mivel mindkettő hardver szinten OpenGL-t fog kezelni. Lásd: Java3D API. Láttam már simán futó fps-t Javaban írva.
[quote:e29d52615c="Csab"]- Nem fogsz videót, DVD-t nézni java alatt
Ez még sohasem merült fel bennem :)
[quote:e29d52615c="Csab"]- Nem fogsz tudni megírni mondjuk egy TCP/IP stacket java-ban a misztikus késleltetések miatt (pl. Garbage Collection).
A TCP/IP stack véletlenül nem az operációs rendszer feladata?
A "misztikus késleltetések" ellen (ha már mindenképpen ez a szűk keresztmetszet) pedig vannak bevált módszerek: pl. oda lehet figyelni a program objektumaira, nem összevissza használni, lehet poolokat definiálni, stb. Tessék kihasználni a GC filozófiáját: nem fut addig, amíg nem kell futnia.
[quote:e29d52615c="Csab"]- A kriptográfiai erőforrás zabáló algoritmusokról nem is beszélve
Mire gondolsz? Mi az, ami lassabb lenne, mint ugyanaz C++-ban implementálva?
[quote:e29d52615c="Csab"]A java csak akkor használható ilyen dolgokra, ha az időigényes szálak natívban futnak. Azaz lehet JNI-ben gányolni, a JNI pedig nem hordozható binárisan és nem sokkal kényelmesebb, mint egy hexeditor.
A korábban már idézett mérésen kb. azt hivatott egy egyszerű példával bizonyítani, hogy ez így nem igaz. Persze állíthatunk bármit, de én most tettem számokat is mögé, és rövidesen egy kisebb cikkben is bemutatjuk a teljes mérési eredményeket.
[quote:d644abd0f0="zsolt"]Annyira elmerültetek a részletekben, hogy az elképesztő!
Szerintem érdemesebb megnézni, hogy a két nyelven (C++ vs. Java) mennyi idő és erőfeszítés révén lehet ugyanazt elérni.
Engem eléggé meggyőzött korábban a Java sebessége itt a topic-on beírt példákban (én is kipróbáltam a qsort példát). Ezért aztán megnéztem, hogyan lehet Swing-gel dolgozni, ha az ember egy grafikus progit akar összehozni. Őszintén szólva teljesen elborzadtam a rengeteg származtatás meg osztály láttán. Még az eseménykezelés is egy katasztrófa.
Szerintem Javában legalább 3-szor akkora munka felületet programozni, mint egy jó C++-os toolkittel.
Itt egy példa, ahol a Java kód forrása közel 7-szer (hétszer!!!) akkora, mint a teljesen ugyanazt végző C++ kód:
Úgyhogy a Java az én szememben továbbra is maradt egy nagy nulla...
Az eszkoz nem megfelelo ismerete nem elegseges indok a leszolasra. Peldual probald mar ki a Netbeans 5.0 (beta2)-ben levo Matisse felulet-epitot. Csak probald ki, es hasonlitsd ezutan ossze egyeb eszkozokkel. En vegigprobaltam a legtobb Visual *-ot, egy idoben Delphiztem is, lattam mar glide-ot, es ezek mellett azt mondom, hogy a Netbeans 5 felulet-epitese eleg power eszkoz.
Hogy kinek mennyire nem jon be a Swing filozofiaja, az megint mas kerdes. Egyszeruen masfajta logikat kovet, mas problemat cimez meg a megoldasaival, mint pl. a Visual * eszkozok. Eltart egy darabig, mig valaki ezt megismeri, viszont eddig csak olyan embert ismerek, akik a Swing mely megismerese es alkalmazasa utan egyszeruen benanak nezik a tobbi ablakozo rendszert, hogy az meg arra sem kepes. De ezt ugysem hiszik el a jelen levok, talan ha egyszer kiprobaljak...
[quote:272934b1be="handler"]
Meglehetosen furcsa kovetkeztetest tudsz levonni. Te allitottal valamit (egy tablaval ki lehet zarni minden felelosseget). En *egy* peldaval cafoltam. Ebbol egyaltalan nem kovetkezik, hogy az allitasnak csak egy cafolata lehetseges.
Nem is olyan urcsa az! A szándékos gondatlanságból eredő károk felelősségét nem zárhatod ki SZERZŐDÉSBEN. Ez könnyen emészthető. Nyilván, aki ártó kódot készít előre megfontotlt szándékkal, az ne mentesülhessen a számonkérés alól akkor se, ha a felhasználó elfogadja is a szerződést a neki előnytelen feltételekkel.
A másik kitétel, a SÚLYOS gondatlanságról szól. Érted? Súlyos gondatlanság. Ha az általában elvárható gondossággal építed fel a programodat ártó szándék nélkül, akkor szerződésben is kizárhatod a felelősségedet. Sajnos ez van. Szal igen is beleteheted a szerződésbe, hogy nem vagy felelős a program használatából eredő károkért. Hiszen úgy jártál el -a program elkészítésekor-, ahogyan az általában elvárható. Ez bizony cáfolat arra, hogy bele ne írhasd a szerződésbe a felelősséged kizárását. Szerintem. Ha netán ez se győzne meg és úgy éreznéd, hogy neked van igazad, akkor inkább elismerem, hogy én tévedtem.
[quote:7dcb0603bb="Andrei"]
Azt meg egyszeruen keptelen vagyok elfogadni, hogy a GC-t, mint a programtervezest konnyito eszkozt kelljen elkonyvelni.
Hopsz, ilyet nem akartam mondani. En csak azt mondtam, hogy Javaban a memory leak jellegu hibak altalaban tervezesi hibara eredeztethetoek vissza, mig C/C++-ban inkabb programozoi hibakra.
Ami az indiai rabszolgakat illeti, abban egyetertunk. A szoghez kalapacs, csavarhoz csavarkulcs elv alapjan gondolom abban is, hogy minden nyelvnek es kornyezetnek megvan a maga helye.
Amugy netbeans nem tudom hanymillio sor, de eleg szepen megy 512M memoriaval is. Modularis, dinamikus alkalmazasok irasara nem rossz a Java, akar meg desktop oldalon sem, bar az teny, hogy foleg szerveroldalon eli meg mindig a reneszanszat (csak eleg megnezni a web frameworkok szamat, es az egyre ujabb buzzwordoket (2-3 eve ugye az AOP volt a nagy szam, mostanaban a dependency injection es tarsai... kivancsi vagyok mi jon jovore:)
[quote:6641df635d="syntern"][quote:6641df635d="feledhetetlen"]az lett az eredmenye, hogy ma a hotspot compiler az x86 platformon tud olyat produkalni, hogy egy futtatasi session-on belul egy double szorzas ugyanazokkal a szamokkal 2 fele eredmenyt produkal, persze kozel azonosat :)
felemelo lenne, ha java sebessegrol az irna ezutan aki meg tudja mondani hogyan tortenhet ez meg...
Tudnád demonstrálni a kódot?
nekem egy zart fizikai szimulacio erdemenyekent jelent meg
az elosztott szamitasimodelben, gyakran kaptam eltero eredmenyeket ugyanarra a szimulaciora
szinte hihetetlen volt...
aztan kiderult, hogy a 'rossz' eredmenyek mindig x86, java > 1.3 rendszerekbol jonnek
aztan lokalisan is tudtam reprodukalni, ha x86-on futtot a kod
sparc, motorola, powerpc rendben volt...
nem preparaltam ki a hibat a szimulaci core meg
lines:103804
files:923
szoval kicsit tullepi a post meret korlatait
ha senkinek nincs otlete (es nem talalja a guglival se) akkor holnap megirom
[quote:5162fcd164="maszili"][quote:5162fcd164="lokoto"]
Nem értelek. Javában ponthogy baromira egyszerű:
primitív típus esetén (boolean, int, long, double, ...)
a = b; // a felveszi b értékét
egyéb esetben:
a = b; // a ugyanarra az objektumra lesz referencia, mint b (máshogy fogalmazva: mindkét változón uazt az objektumot lehessen elérni)
Nem elég egyszerű és egyértelmű?
Korábban írtam hogy nem... miért kell ugyannak az operátornak kétféleképen működni? Mégy szerencse hogy csak kétféle működése van... mi lenne ha több lenne? :)
Egy kicsit mar tulragjatok ezt a csontot. Egyreszt azert, mert a C++ operator mogott barmi lehet, masreszt mert az operator overloading tenyleg csak macro abban az ertelemben, hogy a vegso binarisban szepen atfordul a megfelelo metodushivasra. Innentol kezdve megint lehet vitatkozni a nyelv szintaktikajan, ami felesleges, mert egyreszt adottsag es nem most talaljuk ki, masreszt osszehasonlitjatok az almat a kortevel, es nem veszitek eszre, hogy mas a celjuk. A celokat mar ossze lehet hasonlitani, de ez ugyben erdemes eloszedni a ket nyelv specifikaciojat (ha jol tudom, akkor a C++-nak is van olyan, csak eppen penzert adjak...)
"'ll start by considering memory leaks: what they are, how to find them in code, and how to get rid of them.
I'll supply background information on the generational approach to garbage collection used in the JVM, information I'll need in order to decide how to tweak the collectors.
I'll describe several techniques for reducing collector pause time, by experimenting with two examples: JumpingJack (the side-scroller from chapter 12) and FPShooter3D (the first-person shooter from chapter 24). The basic approach is to supply options to the JVM; no changes are needed to the application code.
I'll graphically display the copious amounts of performance information generated by the JVM. Garbage collections statistics will be visualized with HPjtune, and profiling details rendered with HPjmeter. Both are freeware tools that work with a wide range of JVMs.
I'll finish by describing techniques for gathering heap-related statistics by adding code to Java applications."
Remelem el is olvassatok, de szoljatok ha hiaba irogatom a linkeket:)
[quote:579816c7fd="_Joel"]
Egy program vacaksága nincs összefüggésben a felhasznált progamnyelvvel.
Közvetlen összefüggésben nincs mert a programozó a meghatározó tényező... DE közvetetten van.
A programnyelv egy eszköz amivel a programozó a programot készíti. Ha az adott programnyelv ad megfelelő eszközöket (korábbi hozzászólásomban felsoroltam párat) hogy jó programot készítsen a programozó, sőt rákényszeríti (pl. erősen típusos nyelvek) a helyes kód megírására, akkor közvetetten van összefüggés a program minősége és a programnyelv között.
Másrészről véleményem szerint a java eleve azt tételezi fel a programozóról hogy hülye mert nem tud jól működő programot írni... ezért rakták bele ezeket a futás időben történő, programhibákból adódó anomáliák kijavítására készült hibajavító kódokat.
És így valóban hülyék (is) fognak programokat írni java-ban.
Persze a hülye itt most átvitt értelemben szerepel és nem akarok megbántani senkit.
Ez valami csodálatos újdonság , mert végre implementálták az automatikus kasztolást az int és Integer meg egyéb primitív típusok között. Eleve így kellett volna megírni. A felsorolási enum típus is végre megjelent: nem tudom hogy működik, de remélem helyettesíteni fogja a 100 db-os 'public final static int' matyóhímzéseket.
Java10:
Remélhetőleg meghozza a várva várt java destruktorokat
Java20:
Kivágják a java-s security-t oda ahova való, leülnek, újra megtervezik, úgy hogy érthető és logikus legyen. Lássuk a tényeket: a java programozók 90%-ának fogalma sincs, hogy megy a ProtectionDomain, SecurityManager, AccessController, PrivilegedAction, doPrivileged, Permission, implies,...
Nos ezeknek a programozóknak kell security-t implementálni. Ez ugye vicces. Kb. úgy hangzik, mintha egyszerű kőműveseknek kellene a villámvédelmet megcsinálni. Valami lesz ugyan belőle, de hogy valóban védeni fog-e?
Java30:
Megjelenik a többszörös öröklés és nem kell többé implements varázslással és külön interfészekkel megoldani ezt a hihetetlenül bonyolult problémát.
Java40:
Elkezdik végre alkalmazni a signal/slot kezelést. A KutyaFüleListener, KecskeBékaListener,... interfészek eltűnnek a süllyesztőben és egyszerű connect signal-lal megoldható lesz az egész. Nem értem, miért nem került ez eleve bele a javaba. C++-ban csinálták meg először, pedig java-ban sokkal könnyebb lenne implementálni. Egy hétvége alatt Reflection-nel meg tudnám csinálni.
----------------
Nos, java40 után fogom először azt mondani, hogy a java jól átgondolt, használható programnyelv. Egyenlőre az a véleményem, hogy fejlődésben van.
Itt egy példa, ahol a Java kód forrása közel 7-szer (hétszer!!!) akkora, mint a teljesen ugyanazt végző C++ kód:
Ezt pro és kontra el lehet mondani. Ha arra használod a nyelvet, amire való, kevés sort kell írnod. Ha másra, sokat.
A java alapvetően arra lett kitalálva, hogy egyszerű internetes appleteket lehessen írni, amik szépen mutatnak egy weboldalon. Erre tökéletesen meg is felel. A fontos az volt, hogy egyszerű legyen és hordozható.
A Sun persze rájött, hogy a java képességei azért túlmennek az appleteken és elindult az alkalmazásfejlesztés irányába. Ez több, kevesebb sikerrel járt. Sok kényelmetlen dolgot hordoz magában, amit idővel majd kijavítanak.
Mindenesetre jó, ha van a java-nak konkurense, mert akkor rá van kényszerítve, hogy fejlesszen. Meddig kellett várni míg az enum megjelent!
[quote:b7f62d428b="maszili"]
A programnyelv egy eszköz amivel a programozó a programot készíti. Ha az adott programnyelv ad megfelelő eszközöket (korábbi hozzászólásomban felsoroltam párat) hogy jó programot készítsen a programozó, sőt rákényszeríti (pl. erősen típusos nyelvek) a helyes kód megírására, akkor közvetetten van összefüggés a program minősége és a programnyelv között.
Láttál már Java-t, vagy csak irogatsz róla?
objektum orientáltság - pipa
polimorfizmus - pipa
template-ek, generikus programozás - generics csak 1.5 ota es kicsit mas, mint a C++-ban, de azert hasznalhato... legyen pipa
erősen típusosság - pipa
többszörös öröklődés - helyett interfészek használata... ezen elvitatkozhatunk
ezen túl automatikus memóriamenedzsment ... Még C++-hoz is VAN! :)
Elfogadod, hogy a Java is ad annyi programnyelvi eszközt a programozó kezébe, mint a C++? Mert ha igen, akkor sok mást is el kell ismerj.
Másrészről véleményem szerint a java eleve azt tételezi fel a programozóról hogy hülye mert nem tud jól működő programot írni... ezért rakták bele ezeket a futás időben történő, programhibákból adódó anomáliák kijavítására készült hibajavító kódokat.
És így valóban hülyék (is) fognak programokat írni java-ban.
Persze a hülye itt most átvitt értelemben szerepel és nem akarok megbántani senkit.
Pedig megbántasz, cirka 4 millió fejlesztőt világszerte. Mert mondhatnád, hogy C++-ba meg azért raktak referenciákat, mert feltételezték, hogy a programozó hülye és nem tud pointerekkel operálni. Meg, hogy a C-be azért raktak struktúrákat, mert a programozó hülye és nem bírja fejben kiszámítani az egyes struktúratagok címzési eltolását. Meg, hogy az assemblyben azért ilyen idióta betűszavakat használnak, mert a programozó hülye, és nem bírja megjegyezni a hexadecimális kódját egy relatív ugrásnak. És akkor már vissza is érkeztünk a lyukkártyás programozókhoz, akik szidják a terminálon dolgozókat. Hogy az a vaskalap nem bír elrozsdásodni...
Még egyszer: GC akkor van, ha elfogy a memória. Fogja és végignézni mi a szemét és eltakarítja. Ha úgy írod meg a programot, jól méretezed a heap-et, a young és az old generation-t, akkor a programod akár úgy is futhat, hogy az indulását követő első 5-6 másodpercen túl SOHA NEM AKTIVIZÁLÓDIK A GARBAGE COLLECTION (legalábbis az old generation-re ezt elég könnyű elérni, a young-nál meg nem is annyira érdekes, mert optimális esetben a gc által elvett erőforrás kevesebb, mint amennyibe C/C++ esetén a malloc/free, new/delete kerül heap objektumok esetén)! Persze ehhez az kell, hogy ne szemetelj a memóriába, minden objektumod "éljen", de pl J2ME esetén vannak játékok amiket arra optimalizálnak, hogy GC nélkül fusson a telefonon. Mert lehet, csak ismerni kell a rendszer működését, és nem érdemi információ hiányában, a nagy általános elgondolások és tévhitek ismeretében nyilatkozni dolgokról.
[quote:47ec7893ae="Csab"]Lássuk a tényeket: a java programozók 90%-ának fogalma sincs, hogy megy a ProtectionDomain, SecurityManager, AccessController, PrivilegedAction, doPrivileged, Permission, implies,...
Nos ezeknek a programozóknak kell security-t implementálni.
ezt eleg meredek a java hibajakent felroni
[quote:47ec7893ae="Csab"]nem kell többé implements varázslással és külön interfészekkel megoldani
ez izles es megszokas kerdesen kivul miert erdekes?
[quote:f7edb3b01d="ssikiss"]Azért azt kicsit dúrvának tartom, hogy valaki az érték szerinti paraméterátadás lehetőségét tervezési hibának tartja. :roll:
Egy másik téma, hogy mintha némelyek fejében kicsit pontatlan kép élne a C++-ról.
A C++-t olyan általános programozási nyelvnek tervezték ami az oo tervezést, fejlesztést _is_ jól támogatja, de nem kötelező használni az oo eszközeit, és nem az alapjaitól oo, ellentétben a jávával.
mondanam, hogy a c++ mint precompiler jelent meg, nem mint nyelv
Sot tobb precompiler, amit aztan nagy nehezen ugyahogy osszemasziroztak.
ugyhogy ezt a folyamatot inkabb ne nevezzuk tervezesnek...
[quote:dad7d52f18="gee"][quote:dad7d52f18="Andrei"][quote:dad7d52f18="gee"]en UML modellezesre Umbrello-t hasznalok, es tetszik. Ja, ez QT, nem swing.
Ugy alapjaban veve tetszett volna, de nekem Windowsos valtozat is kellene.
Megjegyzem, QT van Windowsra. De nem tudom, maga az Umbrello megy-e.
Te megnezted, es nincs w32 valtozat?
No, megneztem, csak X11 es KDE ala irja. Szoval Win kilove.
Viszont en meg akarnam nezni ezt a MagicDraw-t. De latom am, hogy penzes, ha jol latom, a community edition letoltheto ingyen, de abban meg a diagramok jo reszere azt mondja, limited. :-(
[quote:f957de6f00="feledhetetlen"]
mondanam, hogy a c++ mint precompiler jelent meg, nem mint nyelv
Nem lehet, hogy attól függetlenül, hogy az első megvalósítása precompiler volt, azért azt még programozási nyelvnek találta ki BS? A programozási nyelv egy elméleti ajánlás, szabvány, vagy valami ilyesmi, a megvalósítás pedig ennek egy megjelenési formája. Ez így túl elrugaszkodott kijelentés?
[quote:4888e16805="feledhetetlen"]aztan lokalisan is tudtam reprodukalni, ha x86-on futtot a kod sparc, motorola, powerpc rendben volt...
nem preparaltam ki a hibat a szimulaci core meg
lines:103804
files:923
szoval kicsit tullepi a post meret korlatait
Jó lenne ez a megírás, igencsak érdekelne. Főleg akkor, ha lokális gépen reprodukálható, és nem hálózati átvitel hibája.
Én is hiányoltam, pedig annak is van free megvalósítása. Így az assembly-re szavaztam. Bár ritkán használom (itt nem is az volt a kérdés), de frankó kicsi és gyors progikat lehet vele fejleszteni. Hm, a "modern" GUI-szel felszerelt alkalmazásokhoz képest szinte nincs is méretük... (sóhaj)
[quote:c96f5ab6cf="Csab"]A java alapvetően arra lett kitalálva, hogy egyszerű internetes appleteket lehessen írni, amik szépen mutatnak egy weboldalon. Erre tökéletesen meg is felel. A fontos az volt, hogy egyszerű legyen és hordozható.
A Sun persze rájött, hogy a java képességei azért túlmennek az appleteken és elindult az alkalmazásfejlesztés irányába. Ez több, kevesebb sikerrel járt. Sok kényelmetlen dolgot hordoz magában, amit idővel majd kijavítanak.
Amennyit en ennek utanaolvastam, elobb volt cel a hordozhatosag es az egyszeruseg (1990 kornyeke) (pontosabban a C++ felrehasznalasi lehetosegeinek lehetoseg szerinti csokkentese), es csak joval kesobb jott kepbe az applet (1994)... Mindenesetre az applet volt az elso igazi nagy alkalmazasa, hala a Microsoftnak kikopott a mainstreambol...
[quote:c96f5ab6cf="Csab"]Mindenesetre jó, ha van a java-nak konkurense, mert akkor rá van kényszerítve, hogy fejlesszen. Meddig kellett várni míg az enum megjelent!
Az enum nem a versenytarsak miatt jelent meg, hanem kozossegi nyomasra, meghozza az aktiv Java fejlesztok nyomasara (ertsd: nem az a cel, hogy C++-t csinaljanak, hanem hogy tenyleg igenyelt dolgok keruljenek a nyelvbe). Viszont a versenytarsak mindig jok. Meg lehet nezni, hogy mennyire fejlodik vagy sem az MS C++ forditoja, es meg lehet nezni a Java elmult ot eves fejlodeset. A .NET-et csak kicsit sorolom ide versenytarsnak, mert a Java tapasztalatokbol sokat atvett (ami teljesen egeszseges viselkedes, nem ertem, hogy ki miert fuj erre), es kesz versenypalyan kezdett. Ugyanakkor technologiai lehetosegekben a Java tobb, uzleti szempontbol pedig nem csak egy ceg all mogotte.
[quote:a3f6a068af="syntern"]
Jó lenne ez a megírás, igencsak érdekelne. Főleg akkor, ha lokális gépen reprodukálható, és nem hálózati átvitel hibája.
nem a halozati atvital hibaja... :)
szoval megmondom:
az a helyzet eleg nagy szamitasi kod kell, hogy a hotspot elhalassza a forditasi lepest a profile utanra
mindenfele quicksort-os gyerek kodokat egybol lenyel megemeszt kikop es fut mint nativ
nalam a targykod 800k es be is huzza magat mielott el kezd szamolni
ilyenkor class inicializerek static{...} persze lefutnak
limiteket szamolnak, konstansokat a szamitasi pontossagtol fuggoen
Pi, e etc...
szoval a hotspot ezeket a szamitasokat interpretalja, hogy a futasi meresek utan tudjon optimalizalni
az interpretalas a nyelvszabvany koveto stilusban IEEE float muveletek hajt vegre
aztan a kod persze fut tovabb (8-10 perc egy 700Mhz PIII-on)
ekkor fogja magat a hotspot es nativ forditja a szamitasokat
ezek a szamitasok persze mar intel FPU muveletekke valnak
ezek eredmenya nem egyezik az IEEE szabvannyal leven nehany bittel pontosabb...
szoval ez nem titok regen kiderult mar ahogy megjelent a hotspot
az elso szepsegtapasz volt a strict_fp method classifier
ez azt eredmenyezte hogy az eljaras kodjaban nem fordul le platform nativra az fp muvelet
ez persze a kod, nem vegrehajtasi szal, vagyis ahogy kilep pl egy Math.sin-re azon megint elcsuszhat
erre kiadtak a StrictMath osztalyt amiben a szamitasi muveletek IEEE konformok maradtak
szoval az 1.1-ben kerult bele a bomba, mert akkor nem tunt problematikusnak, kicsit kesobb robbant...
de igy legalabb gyorsabb volt :(
[quote:2e84a8b9f4="hanischz"][quote:2e84a8b9f4="fdavid"][quote:2e84a8b9f4="hanischz"]Még pár év és több giga memória lesz a gépekben illetve még erősebb proci. Ilyen gépen remekül fognak futni a progik.
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
A masik, hogy enyhen szuklatokuruseg a dolgok jelen allapotaban a szoftverfejlesztest kizarolag PC-s (ertsd: szemelyi szamitogepes) kornyezetre vonatkoztatni. Ugyanis meglehetosen nagy szamu beagyazott eszkoz van korulottunk, amiket mar joreszt szinten magasszintu nyelveken (nagytobbsegeben C-ben) programoznak.
Hmmm, azt kell látni (legalábbis szerintem) hogy manapság nem a CPU és a memória mennyiség a szűk keresztmetszet. Hanem a programhibák tömkelege!
Ezt nem teljesen ertem, hogy hogyan vetheto ossze a programhiba a gep teljesitmenyevel. Ha azt akarod mondani, hogy egy bizonyos feladat nem hajthato vegre jol mukodo program hianyaban, akkor ez trivialis, es nem ujkeletu problema.
1. Ugyanakkor tovabbra is fenntartom, hogy korul kell nezni a bagyazott rendszerek kornyeken. Nagyon komoly teljesitmenymegszoritasok mellett kell fejleszteni.
Ugyanis kicsit kellemetelen lenne, ha pl. egy mosogep, vagy egy ABS vezerloegyseg, vagy egy mobiltelefon, stb. mai PC szintu teljesitmenyt igenyelne, a hozza tartozo meretekkel, hutessel, es arral.
2. De nezhetjuk a szemelyi szamitogepeket is. A teljesitmeny novekedesenek felhasznalasa jo, ha annak konkret celja van, es nem ugyanannak a funkcionalitasnak a gyengebb es eroforrasigenyes megvalositasa okan kell otthon dragabb szamitogepet tartsak.
3. A szuperszamitogepek eseteben pedig a bekerulesi es uzemeltetesi koltsegek okan meglehetosen nagy luxus lenne az eroforrasokat nem a szamitasi cel erdekeben hasznositani.
Ezen kivul lehet arrol beszelni, hogy a programozo ideje vagy a gep kerul-e tobbe. Egy beagyazott rendszernel vagy a szperszamitogepek eseten mar nem olyan egyertelmu, hogy vegyel bele tobb RAM-ot, az olcsobb.
[quote:2e84a8b9f4="hanischz"]Nézd meg a mobil telefonod! Nem fagy néha? Talán C-ben írták :) Vagy egy csomó más progi pc-n. Linux vagy win alatt.. mindegy. Apache nevű webszerver c mivolta miatt (buffer túlcsordulás) törhetnek be internetről stb.
Volt alkalmam mobiltelefonba is fejleszteni, koszoni szepen - amit en irtam - nem fagy le. Es mas programjaim sem. Szoval nem a nyelven mulik, hogy egy program jo-e vagy sem. Raadasul a mobiltelefonokban is egyre tobb a Javas resz, es azokkal legalabb annyi hibajavitas es egyeb problema van, mint a C-s reszekkel. Ugyanis nem ezen mulik. A nyereseg ott van, ha egy nyelvben kenyelmesen es hatekonyan lehet dolgozni, es ezzel idot lehet nyerni. Ilyen szempontbol a Java sokkal jobb, mint a C vagy C++, de sajnos teljesitmeny okoknal fogva a Java nem uberkiraly. Bar az lenne. De ott van a D nyelv (http://www.digitalmars.com/d/), ami azt hiszem, hogy igencsak eltalalt holmi.
A masik, hogy C++-hoz is van GC, vagy pl. ott a QT, amivel alom dolgozni. Masik oldalrol sok olyan programozasi kornyezet van, ahol nincs meg debugger, coverage, profiling tool sem, pedig ugye ezek C-hez letezo dolgok. Na persze.
Szoval ismet csak peldak arra, hogy a nyelv onmagaban meg kozel sem donto.
[quote:2e84a8b9f4="hanischz"]Egy általános programnál a megrendelő nem azt várja h egy 386-oson is elmenjen a progid, hanem hogy hamar! készen legyen és ne legyen benne hiba!
Tapasztalat!
Nem biztos. Lehet, hogy azt varja el, hogy biztonsaggal, es _idoben_ kinyiljon a legzsak. Ja es szarnak a managelt kodra.
[quote:2e84a8b9f4="hanischz"]Hanem azt mondom h a mostani "válságra" (azaz hiba hiba hátán egy programban, pc, mobil telefon egyremegy, és kijavítanak egy hibát kettő új lesz), a megoldás a menedzselt kód.
Nem! A managelt kod csak toredeket oldaj meg a problemaknak, es raadasul ujakat hoz be, a hibas szemlelettel.
A megoldas a minsoegbiztositas. Tisztesseges folyamatdefiniciok, modszerek, eszkozok, human eroforras osszhangaja, tervezes, dokumentalas, es atfogo teszt.
[quote:2e84a8b9f4="hanischz"]Persze a teljesítményt követelő területeken minden csepp proci erőre szükség lesz, ott c vagy asm a megoldás egyelőre.
Ez sem feltetlenul igaz. Assemblert nagyon keves helyen hasznalnak, es gyakran nem C-ben, hanem magasabb szintu kornyezetben fejlesztenek, es csak generaljak a C kodot. Ja es Pascal is elofordul meg itt-ott, persze nem uj projektekeben.
[quote:e70fce1124="_Joel"]
Még egyszer: GC akkor van, ha elfogy a memória. Fogja és végignézni mi a szemét és eltakarítja. Ha úgy írod meg a programot, jól méretezed a heap-et, a young és az old generation-t, akkor a programod akár úgy is futhat, ... stb.
Joel.. látom Te Java fanatikus vagy és GC hivő..:))
Én a maga részéről azt mondom a GC-re, hogy egy sz*r szemét.
De, hogy ne csak a levegőbe beszéljek:
- környezet: NetBeans 4.1 + Profiler, 1.5.0_05 jdk
A teszt program a hozzászólás végén.
A lényeg a következő:
- a kod letrehoz egy fő-frame-t, 1 darab button-nal
- ha raklikkelsz a gombra, akkor letrejon egy ablak x darab button-nal
- a letrejott ablakot be kell zarni a ablak bezaras ikonjaval
A lényeg:
- két actionlistener megvalositast hoztam letre (Megvalositas 1, 2.)
- a kulonbsegek:
a. Az elso helyi valtozokban "tarolja el" a letrehozott ablak es panel referenciáját,
tehet mikor bezarod a letrejott ablakot az "nem szabadul fel", ha viszont masodszor
is raboksz a gombra null-azza a ket referenciat.
b. ebben az esetben nem hasznalja a helyi referenciat.
Kicsit bonyolult igy leirva, nezd meg a kodot.. pár sor.
Mi a lényeg?
1. Mindkettő megoldás szabályos (javits ki, ha nincs igazam)
2. A különbség mégis "látványos" ha a profiler-el nézed a JButton class-t
A magam részéről ezért mondom, hogy sz*r a gc.
Az, hogy "relative" két helyes, hellyel közzel ugyanaz a megvalósitás két különböző
eredményt ad.. katasztrófális szerintem.
Az egyik esetben ott a memory leak.. a másiknál nincs ott.
Nos?
Vélemény?
Fri
package leak;
import java.awt.event.*;
import javax.swing.*;
public class Main extends JFrame implements ActionListener {
JPanel panel = null;
JFrame frame = null;
public Main() {
setTitle("frame1");
setLocation(0, 0);
setSize(100, 160);
JButton button = new JButton("Letrehoz..");
button.addActionListener(this);
getContentPane().add(button);
setVisible(true);
}
public static void main(String[] args) {
Main main = new Main();
}
// Megvalositas 1
/*
public void actionPerformed(ActionEvent ev) {
if (frame == null) {
frame = new JFrame("frame");
frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
frame.setSize(360, 260);
panel = new JPanel();
for (int i = 0; i < 50; i++) {
panel.add(new JButton(Integer.toString(i)));
}
frame.getContentPane().add(panel);
frame.setVisible(true);
} else {
// panel.removeAll();
// frame.getContentPane().removeAll();
panel = null;
frame = null;
}
}*/
// Megvalositas 2
public void actionPerformed(ActionEvent ev) {
JFrame frame = new JFrame("frame");
frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
frame.setSize(360, 260);
JPanel panel = new JPanel();
for (int i = 0; i < 50; i++) {
panel.add(new JButton(Integer.toString(i)));
}
frame.getContentPane().add(panel);
frame.setVisible(true);
}
}
[quote:800cab5ece="feledhetetlen"]szoval az 1.1-ben kerult bele a bomba, mert akkor nem tunt problematikusnak, kicsit kesobb robbant...
de igy legalabb gyorsabb volt :(
Ez jó, köszi hogy leírtad, mindig tanul újat az ember :)
[quote:1f6f5fbd03="feledhetetlen"]
Arra szeretnek csak ramutatni, hogy a leforditott java kodban megmarad a gyorsitas lehetosege, mig a C targykod 'doglott' ebbol a szempontbol.
elmélet, elmélet, elmélet....
a gyakorlat meg a fenti freewebs.com-os linken olvasható: a c++ sokszor 2x gyorsabb, néha 4x.
ennyi.
[quote:3fde236eef="feledhetetlen"]
de igy legalabb gyorsabb volt :(
Emlekszem, olvastam errol sun internal anyagokat 2-3 eve... ott mintha az Intelt szidtak volna a mernokok amiert nem kepes IEEE-t hasznalo FPU-t tervezni es hasznalni.
[quote:c1975476d6="maszili"]
Szerintem meg lehet jó vagy rossz egy filozófia, mert azt az adott környezetben az adott feladat megoldása során vizsgáljuk. Ha nem így lenne akkor elég lenne a strukturált programozás és nem lenne szükség az OO-ra.
Az egyetlen probléma, hogy jelen esetben nincs "adott környezet", sem "adott feladat", hanem ezt állítod:
[quote:c1975476d6="maszili"]
Itt érkeztünk el ahhoz a ponthoz hogy saját magad mondod ki azt, hogy a java filozófiája rosszabb mint a c++. :)
Fölösleges megkötésekkel gátat szab saját maga kifejező erejének...
Azaz ebből az esetből (op overloading) megállapítod, hogy a Java filozófiája rosszabb. Holott ez csak egyetlen kérdés a sok közül egy nyelv/platform esetén.
Ez alapján lehetetlen egyik filozófiáját a másikénál rosszabbnak nyilvánítani, mert pl egy ügyviteli rendszer esetén (egy korábbi példával élve) valószínűleg nehezen értelmezhető két bankszámla összeadása (és viszonylag ritkán van szükség egyéb OpOL-ra).
Mielőtt meköveztek hogy "erre" a memory leak-k szót használtam..
.. azrét tettem, mert a nem épp optimális esetben, csak csupán pár
objektum jön létre, egy komolyabb alkalmazás esetén ezrekről, tizezrekről
beszélhetünk.. és ott már nagyon nem mindegy, mennyire is hatékony a
memoria kezelés.
Fri
Ha lesz egy kis szabadidom jobban atgondolom, hogy a multi core-multi thread CPU-k hasznalata eseten egy konkurrens GC algoritmus (ahol kulon, a programmal parhuzasmosan futo GC szal vegzi a takaritast) pontosan milyen hatranyokkal es elonyokkel jar, egyaltalan meg kell-e akasztani barhol is a fo program mukodeset, es vesztunk vagy nyerunk-e ezzel a mukodesi semaval...
[quote:733448482c="syntern"][quote:733448482c="Csab"]Mindenesetre amíg a JRE-t és java compilert C, C++-ban írják, addig nem érdemes a C++ ellen pampogni.
Mar megint az almat hasonlitod a kortevel. :)
javac C-ben van irva? de tenyleg???
elmondod, hogyan jutottal erre a kovetkeztetesre?
jre/lib nalam 89M total ebbol nativ 31M a nativ (feltetelezzuk C)
akkor ez miben van irva?
[quote:94114348e3="lokoto"]Fordítsunk a helyzeten (kérem a szöveget nem kiragadni a környezetéből):
- a C++ filozófiája rosszabb, mint a Javáé, mert nincs benne reflection
- a C++ filozófiája rosszabb, mert nincs benne GC
- a C++ filozófiája rosszabb, mert nincsenek benne csomagok
csak azért válaszolok erre a hülyeségre, nehogy valaki azt gondolja, hogy így igaz, ahogy leírod.
reflection, GC megírható c++-ban, amit írtál? igen. C++ GC-re példa linket is adtam.
A c++ nyelv a power usereknek, ami szinte korlátlanul bővíthető, ha hozzáértő áll neki.
Ezzel szemben a Java: azt eszed amit eléd raknak... legfeljebb majd néhány év múlva mást is eléd raknak.
eszed, nem eszed, nem kapsz mást.
Valaki azt mondta pár hozzászólással régebben hogy ez az egész GC (és a szemlélet) egy olyan törzsfejlődés a programozás terén mint az OO a struktúrált programozáshoz képest. Akkor kérdezem én, hogy van-e lehetőség arra hogy egy tetszőleges objektumom számára definiáljak pl. értékadó operátort.
c++ -ban pofon egyszerűen megoldható és így valóban teljesűl az OO szemlélet és még a kód is egyszerű és átlátható.
pl. legyen X és Y egy tetszőlegesen bonyolult adatszerkezettel megvalósított objektum, ekkor felírható így az értékadás...
X = Y ;
Nincsenek pionterek, referenciák, nincsen memory leak, stb... nem kell tudnom semmit az objektumok működéséről (OO).
[quote:4ff6979a11="syntern"]Van még mit fejlődnie a JVM-nek, és gyanítom, hogy fog fejlődni. (Érdemes lenne kimérni JRockit-tal, van erre is kapacitásod?)
Később szerkesztettem a hozzászólást, ott leírtam, hogy szimpla -O2-es optimalizációval (-march=k8 nélkül) is nagyjából ugyanazt az eredményt hozta.
JRockit-tel nincs kedvem most szórakozni, de IBM jdk-val megnéztem, mert az van fenn.
export JAVA_HOME=/opt/IBMJava2-amd64-142
$JAVA_HOME/bin/java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 2.2)
IBM J9SE VM (build 2.2, J2RE 1.4.2 IBM J9 2.2 Linux amd64-64 j9xa64142-20050929 (JIT enabled)
J9VM - 20050915_1103_LHdSMr
JIT - r7_level20050909_1801)
Elég érdekes eredményeket adott:
$JAVA_HOME/bin/java -Xmx300M QuickSort
21188
6686
6683
Számomra az a konklúzió, hogy
1. A java bár nagyon "ott" van, de nem éri el a C++ programok sebességét (és memóriafoglalása is nagyobb, és valjuk be lassabban is töltődnek be a java programok).
Ha "el akarjuk adni" a java-t, ne a sebességet említsük első helyen. Vannak a java-nak más olyan tulajdonságai, amelyek értékes programozási nyelvvé teszik.
2. A 4-es g++ -ban vmit nagyon el*******. (Én 3.4.3-assal fordítottam,
úgy jött ki az 5173-as eredmény.)
3. Szerintem az IBM jdk-ja a legjobb teljesítmény szempontjából.
Régebben próbáltam egy-két benchmark teszt erejéig a JRockit-et, de nem volt elég meggyőző.
Bár nem sok értelmét látom a sebességet hajkurászni "kedvenc" címszó alatt (lásd az előző postomat), kérnék minden benchmar huszárt, ha már -O1 -O2 -O3, stb kapcsolókkal varázsol C oldalról, legyen szíves a javac mögé bepöttyinteni egy -O -g:none-t. Esetleg egy -server talán egy -b bónuszkapcslót (a -Xnoclassgc vagy a -Xincgc csak perverzeknek) a java után.
[quote:bdfcfec52e="snq-"][quote:bdfcfec52e="Csab"]Lássuk a tényeket: a java programozók 90%-ának fogalma sincs, hogy megy a ProtectionDomain, SecurityManager, AccessController, PrivilegedAction, doPrivileged, Permission, implies,...
Nos ezeknek a programozóknak kell security-t implementálni.
ezt eleg meredek a java hibajakent felroni
Úgy kell megírni, hogy érthető legyen.
[quote:bdfcfec52e="snq-"][quote:bdfcfec52e="Csab"]nem kell többé implements varázslással és külön interfészekkel megoldani
ez izles es megszokas kerdesen kivul miert erdekes?
Eggyel kevesebb interfész osztályt kell definiálni. Jelenleg 2 osztályt csinálsz, egy megvalósító osztályt és egy interfészt. Dupla munka, dupla karbantartás.
Bár a C++ header, source is dupla munka, csak másképp.
[quote:03b0d3b700="bocs"][quote:03b0d3b700="lokoto"]Fordítsunk a helyzeten (kérem a szöveget nem kiragadni a környezetéből):
- a C++ filozófiája rosszabb, mint a Javáé, mert nincs benne reflection
- a C++ filozófiája rosszabb, mert nincs benne GC
- a C++ filozófiája rosszabb, mert nincsenek benne csomagok
csak azért válaszolok erre a hülyeségre, nehogy valaki azt gondolja, hogy így igaz, ahogy leírod.
reflection, GC megírható c++-ban, amit írtál? igen. C++ GC-re példa linket is adtam.
A c++ nyelv a power usereknek, ami szinte korlátlanul bővíthető, ha hozzáértő áll neki.
Ezzel szemben a Java: azt eszed amit eléd raknak... legfeljebb majd néhány év múlva mást is eléd raknak.
eszed, nem eszed, nem kapsz mást.
"csak azért válaszolok erre a hülyeségre, nehogy valaki azt gondolja, hogy így igaz, ahogy leírod." :)
Kíváncsian várom a C++ reflectionre vonatkozó linket. Ahogyan kíváncsian várom a C++ többgenerációs (= nem referencia counter) GC-re is a linket. Valamint arra is kíváncsian várom a választ, hogy a Java miért nem szinte korlátlanul bővíthető, és hogy a C++-ban miért nem csak azt eszed, amit eléd raknak :) (a vége komolytalannak tűnhet, de teljesen komolyan: milyen pontokon látsz korlátozásokat? A szintaktikai dolgoktól szerintem eltekinthetünk, mert szerintem lényegtelen, hogy operátorhoz írsz metódust, vagy metódust írsz)
A JNI-ről annyit, hogy debugolni tökéletesen lehetetlen és ha nagy programot írsz, az teljesen áttekinthetetlen lesz. Néha misztikus fagyások. Szóval senkinek sem ajánlom.
Persze mindenre lehet java-t használni, csak nem mindenre érdemes.
Láttam már szervert, amit java-ban írtak és irgalmatlan erős gépeken úgy ment, mint egy beteg tetű.
Mivel több éves fejlesztés volt, így nem lehetett újra kezdeni és nulláról megírni. Menedzsment hiba volt, hogy java-ra rakták az egészet. Érdemes megemlíteni a JVM hibákat is. Mit csinálsz, ha fagy a JVM? Egy szerver nem fagyhat csak úgy ki. C-ben még lehet bütykölni, nade ha a JVM fagy? Szóval a titokzatos memory leak-ek, JVM fagyások,... miatt késett a szerver projekt fél évet. A Java a Sun kezében van és igencsak kell könyörögni ahhoz, hogy egy JVM hibát kijavítsanak.
Szerver alkalmazást sosem írtam volna java-ban. Az értelmes megoldás szeritem az, hogy szervert C és C++-ban ír az ember, a kezelőfelületét pedig java-ban.
Ha hardver specifikus dolgokat akarunk csinálni, akkor C++.
Ha hordozható szoftvert akarunk, akkor java.
Ha kell hardver specifikus és hordozható is:
- a hardver specifikus részek C, C++
- a többi java
Nyilván mobiltelefonon könnyebb jó java-t implementálni, mint PC-n.
Igazán jó hardver gyorsítást lehet a mobil processzorba tenni, ennek megfelelően veri a PC-s JVM-eket.
A Sun már készített olyan processzort, amelynek java a nyelve. Nyilván ilyen processzoron a C,C++ lassabb, mint a java.
A 80x86-os processzorok C-re lettek optimalizálva. Akkor még nem volt java, épp ezért veri a C mindenütt a java-t. Megfelelő hardverrel fordított állás is elérhető.
[quote:9e1e9ad733="Chain-Q"]jon valaki okostojas, es kozli h. szerencse h. kimaradt a Pascal, es persze nem mulasztja el bepastelni a hatulgombolosozos dumat. De hat ez mar nem engem minosit.
Sajnos téged minősít. "szerencsére" - ezt én írtam, a másikat meg nem.
Egyszerűen nem tetszik és kész, egyébként: az ada logikus, pascal idétlen. Miért nem lehet lezárni rendesen az if-eket (end if), és miért nem lehet az end elé pontos veszsőt tenni (üres utasítás a pontosvessző, ahelyt, hogy egy null-t kellene odaírni, stb).
Itt egy példa, ahol a Java kód forrása közel 7-szer (hétszer!!!) akkora, mint a teljesen ugyanazt végző C++ kód:
Ezt pro és kontra el lehet mondani. Ha arra használod a nyelvet, amire való, kevés sort kell írnod. Ha másra, sokat.
A java alapvetően arra lett kitalálva, hogy egyszerű internetes appleteket lehessen írni, amik szépen mutatnak egy weboldalon. Erre tökéletesen meg is felel. A fontos az volt, hogy egyszerű legyen és hordozható.
A Sun persze rájött, hogy a java képességei azért túlmennek az appleteken és elindult az alkalmazásfejlesztés irányába. Ez több, kevesebb sikerrel járt. Sok kényelmetlen dolgot hordoz magában, amit idővel majd kijavítanak.
Mindenesetre jó, ha van a java-nak konkurense, mert akkor rá van kényszerítve, hogy fejlesszen. Meddig kellett várni míg az enum megjelent!
a java megrendelesre keszult, egy settopbox-okat gyarto konzorcium rendelte meg a sun-tol
a konzorcium felbomlott a nyelv (akkor meg Oak) viszont joreszt elkeszult
bar ezt en olvastam, de szerintem igaz lehet
sajnos az 1.0 megjelenese elsietett volt
az applet abszolut csak egy zsenialis marketing huzas volt
az applet szerintem inkabb hasznalt mint artott
a fejlesztes nem csak azert lassu, mert Bill, James es meg Guy is elfelejtette megerdeklodni nalad mi kellene bele, hogy te is hasznald
inkabb azert mert a szabvannyal NAGYON ovatosan kell banni,
ugyanis ami 'tapad az ragad'
biztos tudod milyen sulyos konfliktus szarmazott az NFS tul gyors szabvanyositasabol
vagy NetBIOS 'mindentbele ami tetszik' szabvanybol
szoval nekem inkabb az tetszik ha megfontoltan de biztosan halad a Java
akar az is tetszik, hogy az uj JavaBeans specifikacio visszater a POJO modelhez
az enum nem azert nem kerult be mert a tervezok kifelejtettek:
az enum tipusos kellett legyen
a generics csak tervben volt mikor ki kellett adni a javat
logikailag a generics megjelenese utan kerulhetett bele
utana bele is kerult
szeretnem azert ha kicsit osszehasonlitanad a c++ enumot a java enum-mal... szerintem 'not the same ballpark'
talan azert mert jol meg lett tervezve?
az generics az enum tobszoros visszateresi ertek az eredeti tervben is benne voltak
ezt nem olvastam: az 5 evvel ezelotti JavaOne-on halottam James Gosling-tol, hajlamos vagyok hinni neki...
[quote:d8e874d5bd="Panther"]
Egyszerűen nem tetszik és kész, egyébként: az ada logikus, pascal idétlen. Miért nem lehet lezárni rendesen az if-eket (end if), és miért nem lehet az end elé pontos veszsőt tenni (üres utasítás a pontosvessző, ahelyt, hogy egy null-t kellene odaírni, stb).
Nem értem a hozzászólásod! Nem logikus, Miért?
BLOKK = BEGIN utasítás;[utasítás;]... END; vagy utasítás;
Minek kell ezt feszegetni... C/C++/Java:
BLOKK = {utasítás;[utasítás;]...} v. utasítás;
Mennyivel jobbak ezek?
Nem véletlenül használják a Pascalt az oktatásban, egyszerű, logikus. Ezt nem lehet megkérdőjelezni.
Fejlődik és gyorsan lehet vele fejleszteni.
Hogy "Nem tetszik".... :-) jó hagyjuk... Én ISMEREM és szeretem
Chain-Q-nek ajánlom, bár tudom hogy a Kylix-et nem szereti :-)
- az FPC jól halad,
- a Lazarus fejlődik...
- a ZeOS DBO is elindul a Lazarusz alatt, bár nálam még a DBGrid dob egy hátast, de jó lesz
Van jövője a nyelvnek a többiekkel meg nem kell foglalkozni!
[quote:a4a4db7463="popacsek"]Később szerkesztettem a hozzászólást, ott leírtam, hogy szimpla -O2-es optimalizációval (-march=k8 nélkül) is nagyjából ugyanazt az eredményt hozta.
Olvastam, és ppont emiatt írtam, hogy szerintem a C++-nál sem a compiler, hanem a runtime (azaz, hogy mire van fordítva a minden más) határozza meg a teljesítményt.
[quote:a4a4db7463="popacsek"]1. A java bár nagyon "ott" van, de nem éri el a C++ programok sebességét (és memóriafoglalása is nagyobb, és valjuk be lassabban is töltődnek be a java programok).
Ha "el akarjuk adni" a java-t, ne a sebességet említsük első helyen. Vannak a java-nak más olyan tulajdonságai, amelyek értékes programozási nyelvvé teszik.
Egyetértek, de másképpen fogalmazok: minden más dologban jobban el lehet adni a Javat, és most már a sebességre sem lehet azt mondani, hogy lassú lenne.
[quote:438b478c50="maszili"]hogy van-e lehetőség arra hogy egy tetszőleges objektumom számára definiáljak pl. értékadó operátort.
Nincs éspedig szándékosan nincs operator overloading. Ez egyike volt a "Java legyen egyszerubb, mint a C++" tervezesi elgondolasnak. Ez a vita időnként periodikusan előjön különféle helyeken, pl itt:
[quote:e807702a70="Csab"]
Egy hétvége alatt Reflection-nel meg tudnám csinálni.
Ugy, mint a referenciaszamlalasos automatikus memkezelest? :twisted:
Lassunk nehany alapveto problemat C++-bol?
- Nincs override kulcsszo? (Elarulom: valszeg elfelejtettek anno)
- Miert kell ujraforditani egy osztaly fuggeseit, ha privat mezot adsz hozza az osztalydefiniciohoz? Nekem ez kulonosen kinos, mert olyan programon is dolgozunk, aminek az ujraforditasa 6-8 ora egy eleg jo gepen.
- Az altalad felsorolt security feature-eket nem lelem a C++-ban sem. Ha a Java programozok nem ismerik az ilyen dolgokat, azt tenyleg nem kenheted a nyelvre.
- Siralmas a szabvanyos osztalykonyvtar. 2005-ben a legmagasabb absztrakcios szint a map, meg a szoveges konzol lenne?
- Zerus tamogatas a halozatkezelesre, grafikara, szalkezelesre, oprendszer szolgaltatasok eleresere.
- Rettenetesen elbarmolt szintaktika. Soha senki nem gondolta at. A klasszikus kerdes az UHH-bol: a=b/*p; kifejezes vajon mi? Komment kezdete, vagy osztas egy pointer altal mutatott ertekkel.
- A XXI. szazadban jarunk, de a programozasi nyelvunk meg mindig nagyon kemenyen tamaszkodik a preprocesszor szolgaltatasaira. Miert is nincs benne egy unit szisztema? Object Pascal-ban, Java-ban, C#-ban van, es maris elfeledkezhetunk a header-guide-okrol, es a forditoprogram szepen megoldja a dolgokat.
- Nincs szabvanyos ABI, a forditoprogram irok pedig legtobb rajuk bizott reszletet kepesek kulonbozokeppen megvalositani. Kapj mar el legyszives egy Watcom alol dobott kivetelt Borland C++-ban, Visual C++-ban, GCC-ben! Nem fog menni. Sot ami a megalol: altalaban meg az osztalyokat sem vagy kepes felhasznalni. Miert kell legalabb haromfele name mangling? Miert kell legalabb haromfele fuggvenyhivasi elv?
- Allitolag nem valami egyszeru a nyelvtan. Allitolag meg csak nem is kornyezetfuggetlen...
En birom a C++-t, meg naprol-napra abban programozok a munkamban, de ra kellett jonnom, hogy egyvalamit tamogat igazan es az onmagad tokonszurasa. :)
Ha lesz egy kis szabadidom jobban atgondolom, hogy a multi core-multi thread CPU-k hasznalata eseten egy konkurrens GC algoritmus (ahol kulon, a programmal parhuzasmosan futo GC szal vegzi a takaritast) pontosan milyen hatranyokkal es elonyokkel jar, egyaltalan meg kell-e akasztani barhol is a fo program mukodeset, es vesztunk vagy nyerunk-e ezzel a mukodesi semaval...
Elso blikkre meg lesz kotve a kezed nehany helyen.
pl. nezd ezt a kifejezest
A::A()
{
parent=new B();
}
Itt ugyebar eleg komoly problemat jelentene egy GC futas a new utan, de az egyenlosegjel utasitas vegrehajtasa elott. Nem ertek a Java-hoz, elkepzelheto, hogy a fenti sor eleve atomi muvelet. Minden bizonnyal lehetne olyan kodot fabrikalni, ahol tutira problemat jelentene egy masik szalon futo GC.
Szinten problematikusnak erzem a destruktorok (gondolom Javaban is vannak) futasat. Egy kicsit aggalyos, hogy a konstruktor a programszalban fut , a destruktor viszont a GC szalban. Onmagaban nem problema (bar nem szep megoldas), de vannak olyan nem a Java altal kezelt eroforrasok, amik nem viselik jol, hogy masik szalbol probaljak felszabaditani oket, mint, amiben lefoglaltak.
En ugy erzem, hogy kell valamilyen szinkronizacio a programszallal.
Aztan jon a slusszpoen! Mi van, ha a programod eleve tobbszalu? Egyreszt mindegyikkel szinkronizalnod kell a GC-t, ami nem a jo skalazodas biztositeka.
[quote:83b5cdc7c8="popacsek"]Abban reménykedek, hogy a fenntebb említett JDK-k licensze nem tartalmazott tiltásokat benchmark eredmények közzétételére ...
Emlékeim szerint csak a .NET-nek vannak ilyen félelmei :)
[quote:06c7ee9960="syntern"]...
Az enum nem a versenytarsak miatt jelent meg, hanem kozossegi nyomasra, meghozza az aktiv Java fejlesztok nyomasara (ertsd: nem az a cel, hogy C++-t csinaljanak, hanem hogy tenyleg igenyelt dolgok keruljenek a nyelvbe). ...
ezzel nem ertek 1et
csak ez kis ad hoc forum hany olyan igenyt felvetett amivel siman c++ szintre lehetne szegregalni a java-t
a nyelvbe az keruljon amit az ehhez (computer languages) erto emberek abba jonak latnak
ugyanugy a fordito iro emberek nem tudjak, hogyan kell alkalmazast fejleszteni
az igazi elmeleti szakember egy button se tud rendes helyre rakni egy dialogba,
van olyan kivalo programozo kollegam aki 2 ev windows-on valo fejlesztes utna sem tudott felrakni egy winzip-et a gepere..
ez igy van rendjen, a nyelv szakember csinaljon nyelvet
az alkalmazas programozo csinaljon alkalmazast
[quote:579c8a740e="Csab"]
Eggyel kevesebb interfész osztályt kell definiálni. Jelenleg 2 osztályt csinálsz, egy megvalósító osztályt és egy interfészt. Dupla munka, dupla karbantartás.
Amit minden rendes IDE el tud rejteni előled (felveszed az új metódust az interfészbe, mire feldob egy ablakot, hogy az azt implementáló osztályokba akkor ő most létrehozza ezt a metódust és belerak egy //TODO remarkot is, hogy a TODO listában is megjelenjen az újonnan implementálandó kód, mint feladat...)
[quote:e0ce78bbbb="bocs"][quote:e0ce78bbbb="lokoto"]Fordítsunk a helyzeten (kérem a szöveget nem kiragadni a környezetéből):
- a C++ filozófiája rosszabb, mint a Javáé, mert nincs benne reflection
- a C++ filozófiája rosszabb, mert nincs benne GC
- a C++ filozófiája rosszabb, mert nincsenek benne csomagok
csak azért válaszolok erre a hülyeségre, nehogy valaki azt gondolja, hogy így igaz, ahogy leírod.
reflection, GC megírható c++-ban, amit írtál? igen. C++ GC-re példa linket is adtam.
A c++ nyelv a power usereknek, ami szinte korlátlanul bővíthető, ha hozzáértő áll neki.
Ezzel szemben a Java: azt eszed amit eléd raknak... legfeljebb majd néhány év múlva mást is eléd raknak.
eszed, nem eszed, nem kapsz mást.
Igen, csak az már nem az alapnyelv / alaprendszer által nyújtott reflection, ergo elmondható, hogy a C++ filozófiája alapból nem támogatja. Ugyanez igaz a GC-re, és a csomagok elvére is (ez utóbbira gyanítom, hogy nem is fejleszthető semmi pótlás).
Tudtommal dinamikusan nem lehet osztályt betölteni C++ alatt, és még biztos sok más példát fel lehetne hozni, de nem látom értelmét, úgy tűnik nem fogtad fel a lista lényegét (tipp: el kellene olvasni, mi volt előtte).
Csodálom, hogy a Prologos kollégának még nem estetek neki, hogy a Prologban mi minden nincs és így milyen rossz ...
Vagy csak nem hallottatok még róla, nemhogy csináltatok is alatta valamit? :twisted:
Izomból biztos jobb programozni (lásd ArrayList példa...), mert bizonyos úgymond programozói fogásokat szerintem még egy JIT sem tud kioptimalizálni...
[quote:3aacc184cd="_Joel"]
Nincs éspedig szándékosan nincs operator overloading. Ez egyike volt a "Java legyen egyszerubb, mint a C++" tervezesi elgondolasnak. Ez a vita időnként periodikusan előjön különféle helyeken, pl itt:
Hát ez az... pont azért kérdeztem hogy hogyan néz ki java-ban a dolog. Mert az X=Y -nál mi lehet egyszerűbb?... az ilyen dolgok (+ GC és társai) miatt is mondom én hogy nem komálom a java-t és a c++ -t jobbank tartom.
Khm, C++ is 64 bites kódot fordított (elsősorban pointerek hosszára gondolok)? Csak mert nem mindegy, CPU cache, meg egyéb hasonló low level szempontból sem...
A véleményem szerint a jövő mindenképpen a menedzselt programozási nyelveké (mármint általános feladatra).
Azon egyszerű oknál fogva h jóval biztonságosabb mint a régebbi nyelvek. Márpedig az internetes betörések jórésze buffer túlcsordulásos hiba miatt következik be.
Még pár év és több giga memória lesz a gépekben illetve még erősebb proci. Ilyen gépen remekül fognak futni a progik.
Nemrég írtam egy nagyobb lélegzetvételű progit. Javában. Nem bántam meg. Régebbi nyelvek valamelyikét használva a tesztelési és hibajavítási szakasz sokkal sokkal tovább tartott volna.
Volt olyan h visual c-ben web szervert írtam. Csak azért mert egy változót elfelejtettem lenullázni, 1 hétig szenvedtem mert a progi kiszámítatlanul fagyott.
Javában ill C#-ban ilyen nem lett volna.
A kedvelem a C#-ot (és a nyílt mono-t), de még fiatalka ,a javában sokkal több mindent megvalósítottak, így a java-ra szavaztam.
[quote:2abd22e7c2="lokoto"]Csodálom, hogy a Prologos kollégának még nem estetek neki, hogy a Prologban mi minden nincs és így milyen rossz ...
Vagy csak nem hallottatok még róla, nemhogy csináltatok is alatta valamit?
Prologból írtam a diplomamunkám, azzal foglalkoztam előtte 1-2 évig.
Konklúzióm: nagy hűhó semmiért.
Tudományos szempontból biztos érdekes, mérnöki szempontból katasztrófa.
De a személyeskedő hozzászólásokat nyugodtan elhagyhatod, mert könnyen be lehet bukni velük.
[quote:d0f62537c9="Frimen"]Itt nem TCP-ről van szó, és nem is az alkalmazás szintű protokollrol, hanem arról, hogy egy "driver", legyen az java estében jdbc, rmi milyen teljesitmenyre képes, mennyit "tud".
Szerintem ket kulon dologrol beszelunk. Egy JDBC driver az valami gyartofuggo dolog. Irhatok en MySQL-hez JDBC drivert es hasznalhatom az oaltaluk keszitett drivert, ket kulonbozo meresi eredmenyt kapok, mivel az implementaciom kulonbozo. Egy Javas DB drivert szinten csak ugy van ertelme osszehasonlitani egy C++-os driverrel, hogyha ugyanolyan az implementacio, maskeppen nem tudsz korrekt sebessegadatot merni. Almat az almaval, kortet a kortevel, de ne keverjuk oket.
Ugyanez vonatkozik pl. az RMI-re. Ha implementalsz RMI-t C++-ban, akkor ossze lehet hasonlitani a ket implementacio sebesseget, de az meg mindig nem a Java C++ osszehasonlitas, hanem egy adott dolog ket nyelven torteno implementaciojanak osszehasonlitasa. Es meg veletlenul se mondjuk azt, hogy a Java es a C rmi ugyanaz, mert utobbi ha jol tudom nem hozza at az exceptionoket.
[quote:d0f62537c9="Frimen"]Nem foglalkoztam soha azzal, hogy teljesitmény teszteket kutassak fel.:)
Nem is kertelek erre, csupan arra, hogy olyan osszehasonlitasi modot mondj, ami tenyleg realisan a platformokat meri, es nem alma-korte implementaciokat. Ha mondasz ilyent, mi implementaljuk, kimerjuk, elmondjuk az eredmenyeket.
[quote:d0f62537c9="Frimen"]Nincs érteleme.. ezt bizonyitja több tucatnyi program.
Egy C-ben irt GUI-s program sokszor nagyságrendekkel gyorsabb mint egy java-ban irt program.
Ugy erted, hogy "jajj gyorsabb a nativ program mint a Swing sajat komponensei"? Mert ebben igazad van, de lehet Javaban is nativ komponensekbol epitekezni: AWT. Hozzateszem, hogy a 6-os Javaban mar a Swing is nativ komponensekbol rajzolodik ki.
[quote:68a351ebf3="maszili"]c++ -ban pofon egyszerűen megoldható és így valóban teljesűl az OO szemlélet és még a kód is egyszerű és átlátható.
Na, kicsit durva kijelenteni a C++-ról, hogy valóban teljesíti az OO szemléletet, amikor a többalakúság csak mutatókon keresztül érhető el, a függvényeknél meg meg kell mondani, hogy virtuálisak-e... gyakorlatilag hatékonysági megfontolásokból egy csomó öszvér megoldás van benne.
[quote:68a351ebf3="maszili"]X = Y ;
Nincsenek pionterek, referenciák, nincsen memory leak, stb... nem kell tudnom semmit az objektumok működéséről (OO).
Nincs memory leak, HA jól írták meg... és ránézésre nem látszik, hogy milyen kód fut le... ez is csak egy lehetőség, amit a nyelv biztosít, de ésszel kell használni.
a nyelv szakember csinaljon nyelvet
az alkalmazas programozo csinaljon alkalmazast
Ismerős dolog. A menedzsment mindig jobban tudja, hogy mi a jó, mint a programozók. Volt szerencsém hozzá. A Telelogic kifejlesztett egy SDL nyelvet, amely kiválóan alkalmas volt protokollok megvalósítására (legalábbis a marketing szöveg szerint).
Mi programozók az első kanyarban mondtuk, hogy C++, mert as SDL-lel eszméletlen sok szívás lesz. A válasz az volt, hogy azért mondjuk ezt, mert nem ismerjük az SDL-t. Szóval fele akkora fejlesztési sebességgel SDL-ben írtuk meg a protokollt. Az SDL egyébként C++ kódot generált, de ez igazi generált kód volt ám, a zb435349857frbdc234 egy tipikus változónév volt.
Aztán eljött az igazság órája. Az SDL-t nem lehetett karban tartani és hihetetlen sok misztikus hiba volt benne. Ígyhát olyan döntés született, hogy átírhatom végre C++-ba.
A fél éves munkát 1 hét alatt átírtam, még 1 hét tesztelés, aztán jött egy teljesítmény mérés. A Telelogic csoda kihajítása megháromszorozta a protokoll teljesítményét.
Szerintem a programozó jobban tudja, mint a nyelvész zseni...
[quote:0120c56b39="KisKresz"]gyakorlatilag hatékonysági megfontolásokból egy csomó öszvér megoldás van benneKisKresz
hálisten
ezért zabál közel annyi memóriát mint elvárható
ezért egy 2x méretű adatstruktúra másolása jól bevcsülhetően 2x annyi ideig tart, nem pedi 5x annyi ideig ki tudja miért stb
power tool for power users
aminek persze egyenes következménye, hogy könnyebb magad tökön bökni vele. de amikor ki kell facsarni a teljesítményt a gépből - igen, ilyen is van ;) akkor ez kell.
[quote:336ef6dd9a="syntern"]Kíváncsian várom a C++ reflectionre vonatkozó linket.
próbáltad már a google-t? írd be "c++ reflection"
[quote:336ef6dd9a="syntern"]Ahogyan kíváncsian várom a C++ többgenerációs (= nem referencia counter) GC-re is a linket.
bocsánat, lehet írni ilyet c++-ban? Bármilyet lehet, ami a programozónak tetszik. semmi akadályát nem látom - feltételezem a JVM-beli sem java-ban írták.
[quote:336ef6dd9a="syntern"]Valamint arra is kíváncsian várom a választ, hogy a Java miért nem szinte korlátlanul bővíthető.
feladathoz illesztett, saját kódolású template-es konténerek, amelyek minden típusnál optimális gépi kódra lesznek fordítva, szemben a Java gyakorlatilag parasztvakítás szintű Generics/template támogatásával ? /hiszen maga a SUN írja le, hogy a Java Generics-ből fordítás után eltűnik a típus információ... :(/
egyébként a fórumban írtam már kérdést egybefüggő memóriaterület feldarabolására Java-ban. Ez egyszerűen megoldhatatlan, mert kifelejtették a _nyelvből_ a reallocot. Nincs, nem lesz, nem tudod megvalósítani, mert a sun mérnökei így döntöttek.
Na ilyen nincs a c++-ban: ha a feladat megoldható, meg tudod benne oldani.
Érdekes, hogy a PHP scripting language, mint "programozási nyelv" van jelen és az is érdekes, hogy most (2005. nov. 21. 0:20) vezet a többi konvencionális programozási nyelvhez képest...
IMHO, tekinthető a PHP programozási nyelvnek abból a szempontból, hogy algoritmusokat lehet vele leírni és ezeket (egy interpreteren keresztül) futtatni. Ugyanakkor az is igaz, hogy a PHP egy script nyelv és kizárólag a dinamikus webes tartalmak megjelenítéséhez fejlesztették, ennélfogva a programozói feladatoknak csak egy leszűkített halmaza oldható meg vele. Pl. C, C++ vagy Java nyelvekkel lehet készíteni interaktív és hardvereszközökkel is kommunikáló, GUI frontendet is és dinamikusan generált webes felületet is, de PHP-vel csak ez utóbbit.
Nem tudom, mi a "programozási nyelv" pontos definíciója, de IMHO egy programozási nyelvnek általános érvényű (és nem egy specializált) eszköznek kellene lennie, legyen szó bármilyen szoftverfejlesztési feladat megoldásáról.
[quote:260fb4293f="drojid"]Hát nálam tökugyanaz az eredmény mindkét módszerrel, Eclipse és JProfiler-rel néztem.
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)
Badarság azt gondolni, hogy azért, mert nem volt szükség a helyre, de ha kell, akkor jön a GC és megeszi a szemetet?
Akkor pasz.. a t*k*m ki van a java-val kliens oldalon.
Most akkor mit higgyen az ember? Nekem Netbeans + Profiler az első esetben
"azonnali takaritás" van, a másik esetben meg szemét marad ott.. igy értettem a különbséget.
Passz.. ez a Sun rosszabb mint a M$.
Fri
[quote:088b38d6e2="bocs"]elmélet, elmélet, elmélet....
a gyakorlat meg a fenti freewebs.com-os linken olvasható: a c++ sokszor 2x gyorsabb, néha 4x. ennyi.
En is nagyon szeretem a gyakorlatot. Pont azert mertuk ki. Kivancsian varom, hogy mas architekturan, mas kornyezetben milyen meresi adatokat kaptok.
[quote:c84d063619="aperger"]Nem értem a hozzászólásod! Nem logikus, Miért?
Számomra nem az. Úgysem tudom precízen megfogalmazni, viszont nem díjazom, ha olyat állítanak, hogy én mondtam vmit, amikor más.
C#-ot sem szeretem, pedig abban tényleg tudok programozni gond nélkül (feltéve ha az osztály- és függvényneveket ismerem :)). Ízlések és pofonok.
[quote:ca847ad0c8="handler"]Optimalis gepi kod ;-))) Hat persze! Szerinted ha minden tipushoz van tipusspecifikus kod, akkor optimalis lesz? Ki kell abranditsalak.
megmagyaráznád, mi lehet optimálisabb egy optimalizált tároló, hozzá optimalizált típus párosnál?
[quote:47aefab881="syntern"]
Szerintem ket kulon dologrol beszelunk.
..
Nem is kertelek erre, csupan arra, hogy olyan osszehasonlitasi modot mondj, ami tenyleg realisan a platformokat meri, es nem alma-korte implementaciokat. Ha mondasz ilyent, mi implementaljuk, kimerjuk, elmondjuk az eredmenyeket.
Ebben egyetértünk, mert nem tudom miről beszélsz.
Implementációk, utópisztikus összehasonlitási "elvekről".. ez mind mind kamu,
mellébeszélés.
Összehasonlitást Te is ki tudsz találni.. nem kell hozzá sok ész: fogsz x java-s, x c-s programozot, kitalasz egy egyszerű feladatot: adatkihozás adatbázisbol, kiirás fájlba.
Erre megint mondhatod: "hát de igy meg ugy implementáció".. erre én meg azt mondanám: ki nem tesz rá magasról.. a "felhasználó" ha valós helyzetről van szó
magasról tesz az implementációra.
Ez hasonlit arra, mikor a nomrál formákat tanitják ami szép elmélet, valóságban
azonban az embernek igazodnia kell és a cél érdekében tenni az "elvekre", ha kell.
[quote:47aefab881="syntern"]
Ugy erted, hogy "jajj gyorsabb a nativ program mint a Swing sajat komponensei"? Mert ebben igazad van, de lehet Javaban is nativ komponensekbol epitekezni: AWT. Hozzateszem, hogy a 6-os Javaban mar a Swing is nativ komponensekbol rajzolodik ki.
AWT: Javits ki ha tevedek, de meg nem a standard sun-os java része még, valamint
nem fut el minden.
6-os Java: persze.. majd.. egyszer.. ha kijön, de hol van az még!:)
Fri
[quote:4b513bf37f="bocs"][quote:4b513bf37f="syntern"]Kíváncsian várom a C++ reflectionre vonatkozó linket.
próbáltad már a google-t? írd be "c++ reflection"
Kipróbáltam. Nem találtam olyan linket, ahol egy általam írt és fordított C++ libraryt valaki más csak úgy reflection-nel fel tudott volna deríteni, anélkül, hogy erre én előre felkészülnék. (Tfh, hogy én csak egy objektum-mutatót adok át paraméternek valahova.) Nagyon okosan bevezetik a Javahoz nagyon hasonló osztály-hierarchiát, mindenki örököljön csak az Objectből, de innentől kezdve a másik félnek is ismernie és kezelnie kell ezt az Objectet.
Azaz ami nincs: nem befolyásolt forrásból származó kód reflection kezelése.
[quote:4b513bf37f="syntern"]Ahogyan kíváncsian várom a C++ többgenerációs (= nem referencia counter) GC-re is a linket.
bocsánat, lehet írni ilyet c++-ban? Bármilyet lehet, ami a programozónak tetszik. semmi akadályát nem látom - feltételezem a JVM-beli sem java-ban írták.
Továbbra is ami hiányzik: nem befolyásolt forrásból származó kód GC kezelése. Ha minden kódod memóriáját te kezeled, akkor persze, megoldható, de rögtön borul az egész, ha nem csak a saját kódodért felelsz.
[quote:4b513bf37f="syntern"]Valamint arra is kíváncsian várom a választ, hogy a Java miért nem szinte korlátlanul bővíthető.
feladathoz illesztett, saját kódolású template-es konténerek, amelyek minden típusnál optimális gépi kódra lesznek fordítva, szemben a Java gyakorlatilag parasztvakítás szintű Generics/template támogatásával ? /hiszen maga a SUN írja le, hogy a Java Generics-ből fordítás után eltűnik a típus információ... :(/
Ez most bővíthetőségi vagy optimalizációs kérdés? Logikailag megoldod ugyanúgy a feladatot, és mindkét esetben a környezetre bízod az implementációt.
egyébként a fórumban írtam már kérdést egybefüggő memóriaterület feldarabolására Java-ban. Ez egyszerűen megoldhatatlan, mert kifelejtették a _nyelvből_ a reallocot. Nincs, nem lesz, nem tudod megvalósítani, mert a sun mérnökei így döntöttek. Na ilyen nincs a c++-ban: ha a feladat megoldható, meg tudod benne oldani.
:) Ez jó. Meg tudod oldani azt C++-ban, hogy egy feldarabolt memóriaterületet összenyomj, hogy a sok kis memória összesen egy nagyot tegyen ki? Persze, elméletileg megoldható lehet (pedig nem, lásd: nem befolyásolt forrásból származó kód), a Java meg is oldja.
Nálam mindkét esetben egyformán működik, vagy azonnal takarít, vagy nem, amikor kedve van. (Illetve gondolom ennél kézzelfoghatóbb a működése, de nem látok bele, mi alapján dönt.)
Én nem temetném azért a Java-t, bár én csak SE-t és ME-t használok, EE-t nem, de szeretem. Kézre áll, könnyű vele haladni, az ésszel kódolást pedig semmi nem váltja ki.
Nem akartam eddig beleszólni, mert nem vagyok nagy szoftverfejlesztő guru. Azt el szeretném mégis mondani, hogy a szemléletem asm és c alapokon, beágyazott rendszereken cseperedett, szeretni szoktam a kicsi és gyors programokat. Régebben csőlátással tekintettem erre a kérdésre, például adatbáziskezelőt írtam assemblyben, ezt ma már bevallani is csak pironkodva merem :) Én azt látom, hogy azokra a feladatokra, amikkel találkoztam mostanában, a java nagyon jó kis eszköz desktopon. Nekem az is jó, ha számlázót írok linuxon, és az pont ugyanúgy működik és ugyanúgy néz ki vindóz alatt is, bár ez ma a MS tulajdonképpeni egyeduralma miatt még nem olyan óriási jelentőségű.
Szívesen írnék MCU-ra is java VM-et, meg alkalmazást, de azt már csak azért, mert érdekes, mókás feladat. Ha valami RT alkalmazás kell rá, akkor nyilván nem Javaznék rajta, hanem eldobnám a szoftveres CNC-met és elővenném a szoftvervésőm és szoftverreszelőm, és asm-c-ben csinálnám, mert oda az a jobb.
És még valami: akár überkirály a java, akár nem, divatos, sok helyen erőltetik, a Sun is nő, meg kell tanulni, ismerni kell, és kész. (Ráadásul még szeretem is :) )
[quote:5e89921048="hanischz"]Volt olyan h visual c-ben web szervert írtam. Csak azért mert egy változót elfelejtettem lenullázni, 1 hétig szenvedtem mert a progi kiszámítatlanul fagyott.
Javában ill C#-ban ilyen nem lett volna.
Szerintem akármelyik programnyelvről is legyen szó, programozni tudni kell.
[quote:df5ffc146b="maszili"][quote:df5ffc146b="_Joel"]
Nincs éspedig szándékosan nincs operator overloading. Ez egyike volt a "Java legyen egyszerubb, mint a C++" tervezesi elgondolasnak. Ez a vita időnként periodikusan előjön különféle helyeken, pl itt:
Hát ez az... pont azért kérdeztem hogy hogyan néz ki java-ban a dolog. Mert az X=Y -nál mi lehet egyszerűbb?... az ilyen dolgok (+ GC és társai) miatt is mondom én hogy nem komálom a java-t és a c++ -t jobbank tartom.
a getc() is egyszerunek tunik
egeszen addig amig egyszer meg nem nezed a windows.h-ban mi is az valojaban
az X=Y es tarsaik olyan makrok amiket a programozok is megirhatnak
vagyis mikor olvasod, fogalmad nincs rola, hogy mi tortenik valojaban,
csak ha megnezed a X assigment operator kodot
Javaban is vannak makrok, pl:
String a = "first "+"letter";
DE! ezek pontosan (megtanulhatoan) le vannak irva a nyelvszabvanyba, hogy mire kell forditani.
Ha ezt:
[code:1:df5ffc146b]String a = "first "+"letter";[/code:1:df5ffc146b]
latom egy Java kodban, tudom mi tortenik.
Az X=Y eseten max akkor, ha en irtam es meg emlexem is ra.
Ezzel viszajutunk ahhoz:
A Javat azert szeretjuk, mert tudjuk mi az: 1 (egy) nyelv szabvany.
Igenis a logikus epitkezeshez aximomak kellenek!
Ellentmodasmentes, egyertelmu stb...
[quote:487c671973="Frimen"]6-os Java: persze.. majd.. egyszer.. ha kijön, de hol van az még!:)
Én nemrég próbáltam Mustang-ot, tök jó, bár van egy halom (szerintem) felesleges fícsör benne. Inkább az a baj, hogy most is nehéz azt mondani a juzernek, hogy de igenis tessék 5.0-t telepíteni, ha használni akarod a programomat, mert desktopon szerintem még most is jóval több 1.4 jre van, mint 5.0...
[quote:21c46f8cf6="Frimen"]Implementációk, utópisztikus összehasonlitási "elvekről".. ez mind mind kamu, mellébeszélés. Összehasonlitást Te is ki tudsz találni.. nem kell hozzá sok ész: fogsz x java-s, x c-s programozot, kitalasz egy egyszerű feladatot: adatkihozás adatbázisbol, kiirás fájlba. Erre megint mondhatod: "hát de igy meg ugy implementáció".. erre én meg azt mondanám: ki nem tesz rá magasról.. a "felhasználó" ha valós helyzetről van szó magasról tesz az implementációra. Ez hasonlit arra, mikor a nomrál formákat tanitják ami szép elmélet, valóságban azonban az embernek igazodnia kell és a cél érdekében tenni az "elvekre", ha kell.
Adj szabad kezet tetszoleges feladat implementaciojara, mondj egy eredmenyt, amit latni szeretnel, es kihozom. Nem veletlen a sok pl. Linux-Windows osszehasonlitasban kijovo eszmeletlen kulonbseg: ha akarom, tudom ugy alakitani, tudom ugy implementalni. hogy a C++ lassabb legyen. Ennyit a kamuzasrol.
[quote:21c46f8cf6="Frimen"][quote:21c46f8cf6="syntern"]Ugy erted, hogy "jajj gyorsabb a nativ program mint a Swing sajat komponensei"? Mert ebben igazad van, de lehet Javaban is nativ komponensekbol epitekezni: AWT. Hozzateszem, hogy a 6-os Javaban mar a Swing is nativ komponensekbol rajzolodik ki.
AWT: Javits ki ha tevedek, de meg nem a standard sun-os java része még, valamint nem fut el minden.
Kijavitalak: Te az SWT-re gondoltal, en meg a Java eleg regota alkalmazott awt-jere: http://java.sun.com/developer/onlineTraining/awt/contents.html
[quote:21c46f8cf6="Frimen"]6-os Java: persze.. majd.. egyszer.. ha kijön, de hol van az még!:)
Felfoghatod ugy is, hogy kijott. Mi mar kiprobaltuk, mertuk, gyorsabb, mint az 5-os :)
Tudom, hogy hiper advanced java guru vagy, de azért ne hidd azt, hogy a világon mindent te tudsz a legjobban...
Andrei tudtommal nem Java guru, csak egy értelmes ember (legalábbis az itteni meg a hwsw-s megnyilvánulásai alapján:).
[quote:eb5a15569f="Maszili"]
Hát ez az... pont azért kérdeztem hogy hogyan néz ki java-ban a dolog.
[code:1:eb5a15569f]
Integer x = 5;
Integer y;
y = x;
[/code:1:eb5a15569f]
x és y referenciák, nem önálló objektumok. Ami értékadásnak látszik, az referencia szerinti értékadás, vagyis a memóriában egyetlen Integer objektumod lesz, amire két referencia is mutat (ha egy másik objektumot akarsz másolva létrehozni az az y = x.clone(); művelet lenne).
[quote:52f41fd394="feledhetetlen"]az interpretalas a nyelvszabvany koveto stilusban IEEE float muveletek hajt vegre
aztan a kod persze fut tovabb (8-10 perc egy 700Mhz PIII-on)
ekkor fogja magat a hotspot es nativ forditja a szamitasokat
ezek a szamitasok persze mar intel FPU muveletekke valnak
ezek eredmenya nem egyezik az IEEE szabvannyal leven nehany bittel pontosabb...(
nekünk volt hasonló eredményünk c++-ra, az többnyire azért volt, mert a fordító jól optimalizált.
Ekkor a kód nem vette ki a küzbülső számítási eredményt a 10 byte-os long double-s FPU stack-ből, és töltötte be ideiglenesen 8 byte-os double változóba, majd azt vissza az FPU-ba, hanem az FPU stack-en hagyott értékkel azonnal tovább számolt.
ja +1 érv a c++ mellett: hardverig le tudod debuggolni (tudom, a javas nem debuggol, hanem elolvassa a szabványt... ;) ).
Valaki meg bankokkal. Elárulom, hogy tapasztalataim szerint egyetlen egy olyan hazai szektor van, ami az államigazgatás informatikai sötétségével összemérhető gányolásokat alkot: a bankszektor. Néhol látszanak kivételek, de az összkép lesújtó. Telco-ban határozottan jó dolgozni, ott valahogy normálisabb a technológiai légkör.
(tessék megnézni java lista archívumát: pont múlt héten volt egy jsp-s kérdés, aholis a bank előírta, hogy minden kódnak a jsp-ben kell lennie... erre szokás azt mondani, hogy clueless).
Joel ne legyel write-only! Azt irtam, hogy az ertelmesebb hi-tech szektorok fele a Java jelentosege egyre csokken (mig a bankargyerek a 32 procis Sun vason szive szerint meg az oprendszert is jsp-ben kepzelne el). Tudom, hogy a Marsjarokban fut egy nagy rakas Java kod, de ez is lehet az egyik ok, amiert annyira sok problema van veluk. Javaslom attanulmanyozasra a Voyager 1-2 szondak technikai bravurjait es ra kell jonni, hogy azok is kepesek ezen a szinten mukodni (Fortran + Assembly kodokkal).
De meg senki nem volt konstruktiv, es nem mutatott nekem eddig egy frappans, hatekony, jol hasznalhato desktop Java alkalmazast (Matlab nem er :) ), ami bizonyitana szamomra, hogy mennyivel tobbet ad ez a nyelv es ez a platform (bocsanat ez a Nyelv es ez a Platform), mint barmi mas.
[quote:28b8e80983="KisKresz"]Na, kicsit durva kijelenteni a C++-ról, hogy valóban teljesíti az OO szemléletet, amikor a többalakúság csak mutatókon keresztül érhető el, a függvényeknél meg meg kell mondani, hogy virtuálisak-e... gyakorlatilag hatékonysági megfontolásokból egy csomó öszvér megoldás van benne.
A c++ már csak ilyen... sok helyen használatosak a mutatók...
[quote:28b8e80983="KisKresz"]
Nincs memory leak, HA jól írták meg... és ránézésre nem látszik, hogy milyen kód fut le...
Pont ez a lényege az OO-nak. Nem tudom hogy hogyan működik és nem is kell tudnom hogy hogyan működik.
Azért pl. a STL-t valószínüleg jól írták meg :)
[quote:28b8e80983="KisKresz"]
ez is csak egy lehetőség, amit a nyelv biztosít, de ésszel kell használni.
Ezt nem értem... milyen lehetőség?
Egyébként meg pont arról folyik a beszélgetés hogy a két nyelv a java és c++ milyen lehetőségeket ad a helyes kód megírásához.
Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
GC C++ alatt ügyben innen érdemes indulni. Egy érdekes idézet valamelyik lapról:
In C/C++ Garbage Collection is not a standard feature and hence allocating and freeing storage explicitly is difficult, complicated and is error-prone. The Garbage Collection (GC) is not part of the C++ standard because there are just so many ways how one could implement it; there are many GC techniques, and deciding to use a particular one would not be good for certain programs. Computer scientists had designed many GC algorithms, each one of them catering to a particular problem domain. There is no one single generic GC which will tackle all the problem domains. As a consequence, GC is not part of C++ standard, they just left it out.
Tehát a C++-ban rád bízzák, hogy mit csinálsz. Ez lehet előny és hátrány is. :)
[quote:f4bc7e87a7="syntern"]Kiemelem a dupla heap méretet, mert a többi már korábban meg lett cáfolva
ezért volt ott a "vagy" - hogy milyen plusz erőforrást igényel, az a GC collection algoritmustól függ.
Értem én, hogy elméletileg nincs szükség nagyobb heap-re ;), ezzel szemben meg ott van a fórumban az általam végzett mérés, ahol a ténylegesen szükségesnél 3x-4x több memória kellett a Javas példaprogramnak. A memóriazabálás teljesen általános tapasztalat. Van ahol ez kizárja a Java-t, például az én munkakörömben is.
A SUN oldalain is úgy írják: a GC tipikusan +15% prociidőt jelent. A memóriafoglalási többletet nem is merik odaírni.
A GC ismertetésénél pedig a Sun oldalain is így írják: "mindenhol jó, kivéve a most demanding alkalmazásokat".
Erről beszéltem, én pl ilyenekkel dolgozom, tehát néhol a GC prohibitív.
Néha ugyan lehet, hogy csakis GC-vel célszerű megoldani a dolgot.
[quote:a238181100="feledhetetlen"]
...az X=Y es tarsaik olyan makrok amiket a programozok is megirhatnak...
Szerintem itt valami félreértés van... én nem makrókról beszélek hanem rendes értékadó operátor megírásáról. Az nem makró hanem az osztály része.
[quote:a238181100="feledhetetlen"]
vagyis mikor olvasod, fogalmad nincs rola, hogy mi tortenik valojaban,
csak ha megnezed a X assigment operator kodot
Ezt hívják OO-nak... :) nem érdekel hogy belül hogyan működik...
Ja megvalami. A Java uberalles dolgait nem biztos, hogy a Sun oldalairol idecibalt tanulmanyokkal kellene megerositeni. A mosoporrol sem ugy vitatkoznank, hogy idelinkeljuk a reklamot, amiben kiviszi a porkoltszaftos fufoltot. :) :)
[quote:289e2b45dc="Csab"]- Sosem fogsz 2D / 3D motort írni java alatt
Ezt már linkelték előttem, de van több is.
[quote:289e2b45dc="Csab"]- Nem fogsz videót, DVD-t nézni java alatt
Java to be Used in Blu-ray DVD Players
Mellesleg azért ez marhára érdekelne, hogy írhatunk e majd Java progit pl.: PS3-ra? :o
[quote:289e2b45dc="Csab"]- Nem fogsz tudni megírni mondjuk egy TCP/IP stacket java-ban a misztikus késleltetések miatt (pl. Garbage Collection).
A JNode-ban azért már lehet, hogy megpróbálták.
[quote:289e2b45dc="Csab"]- A kriptográfiai erőforrás zabáló algoritmusokról nem is beszélve
java.security, javax.crypto standard csomagok. A legtöbbhöz még stream támogatás is van.
Ezt ugye viccnek szántad? :)
Én olyan objektumokról beszélek amelyek NEM elemi adatszerkezetek, hanem azoknál sokkal bonyolultabb, sokkal összetettebb a programozó által kitalált (esetleg más bonyolult és elemi adatszerkezetekból felépített) adatstuktúra. Ami ráadásul zárt (OO) és fogalmam sincs hogy mi van benne...
Na akkor hogy néz ki pl. az értékadás?
[quote:d9f39bf062="Andrei"]
De meg senki nem volt konstruktiv, es nem mutatott nekem eddig egy frappans, hatekony, jol hasznalhato desktop Java alkalmazast (Matlab nem er :) ), ami bizonyitana szamomra, hogy mennyivel tobbet ad ez a nyelv es ez a platform (bocsanat ez a Nyelv es ez a Platform), mint barmi mas.
Nem akartam write only lenni (bar a kollega "hibajavitas" felkialtasa a garbage collection-re kisse kihoz a sodrombol - miert kell egy masfajta paradigmat egybol lekezeloen, alsobbrendunek tekinteni, holott komoly tudomanyos kutatasok, publikaciok bizonyitjak a hasznossagat es hatekonysagat marginalisnak nem tekintheto esetkben is - tudom, a kutatas elefantcsoronytornya is nagyon messze van a gyakorlati alkalmazasoktol).
Azt meg foleg nem akarom az egeszbol kihozni, hogy a Nyelv és Platform tobbet erne, mint barmi mas. Csak azt probalom bizonygatni, hogy er ugyanannyit. Igen, a Java programok memoriaigenye nagyobb, mint a C++ programoke, amiknek meg megintcsak nagyobb a memoriaigenye, mint a C programoke, amiknek meg nagyobb a memoriaigenye, mint az assembly programoke. Igen, a jelenlegi stabil (1.5)-os JVM nem teljesen desktop friendly. A Mustang build-eket ha kiprobalja valaki, latni fogja, hogy ez eroteljesen valtozoban van.
A referencia számlálós memóriakezelés működne.
Sajnos neked nincs fogalmad sem a java működéséről.
Az i++, i-- szerinted mit csinál multi threades környezetben?
Tökéletesen viselkedik, ugyanis a primitív típusok automatikusan szinkronizálva vannak java-ban. Ezt jó tudni.
jo tudni:
a long, double tipusok irasa (a nyelvszabvany szerint) elvegezheto 2 (ketto) elemi lepesben:
Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32 bit values. For efficiency's sake, this behavior is implementation specific; Java virtual machines are free to perform writes to long and double values atomically or in two parts.
a nyelv szakember csinaljon nyelvet
az alkalmazas programozo csinaljon alkalmazast
Ismerős dolog. A menedzsment mindig jobban tudja, hogy mi a jó, mint a programozók. Volt szerencsém hozzá. A Telelogic kifejlesztett egy SDL nyelvet, amely kiválóan alkalmas volt protokollok megvalósítására (legalábbis a marketing szöveg szerint).
Mi programozók ....
...
Szerintem a programozó jobban tudja, mint a nyelvész zseni...
szerintem meg fele ekkora onbizalommal egy jobbankepzett hentes mar veheti is torakotomias talcat..
[quote:bf7ff18c4a="Andrei"]Ja megvalami. A Java uberalles dolgait nem biztos, hogy a Sun oldalairol idecibalt tanulmanyokkal kellene megerositeni. A mosoporrol sem ugy vitatkoznank, hogy idelinkeljuk a reklamot, amiben kiviszi a porkoltszaftos fufoltot. :) :)
Sun-nak semmi köze nem volt ahhoz, hogy a NASA java-ban irta meg a vezerloszoftvert. Utolag felkaptak a marketingesek.
Ezt lattad: http://javapathfinder.sourceforge.net/ ?
"What is Java PathFinder
The answer used to be simple: "JPF is an explicit state software model checker for Java bytecode". Today, JPF is a swiss army knife for all sort of runtime based verification purposes.
If you are not familiar with formal methods, this basically means JPF is a Java virtual machine that executes your program not just once (like a normal VM), but theoretically in all possible ways, checking for property violations like deadlocks or unhandled exceptions along all potential execution paths. If it finds an error, JPF reports the whole execution that leads to it. Unlike a normal debugger, JPF keeps track of every step how it got to the defect.
JPF is a pure Java application that can be run either as a standalone command line tool, or embedded into systems like development environments. It was mostly developed - and is still used - at the NASA Ames Research Center. Started in 1999 as a feasibility study for software model checking, JPF has found its way into academia and industry, and has even helped detect defects in real spacecraft."
Jaj most itt rossz színben tűnök fel, pedig én is a java-t szeretem és Mustang van fent. Bár most meg a C++ oldal utál, szal mexívtam így is, úgy is :-)
A lovassal pedig csak arra céloztam, hogy írhatunk bármit, linkelhetünk projecteket, írhatunk konkrét mérési eredményeket, hogy a java igenis jó, mindig lesz valami, ami miatt fújhatnak rá, hogy márpedig akkor sem az... :-)
[quote:6da3561daf="maszili"]
Na akkor hogy néz ki pl. az értékadás?
Két azonos típusú objektum között ugyanígy. Új objektum esetén meg a megfelelő konstruktorral.
[code:1:6da3561daf]
Person p = new Person("Gipsz", "Jakab", 32, "programozó");
Person q;
q = p;
q.setLastName("Józsi");
assert p.getLastName == "Józsi";
q = p.clone();
q.setLastName("Jakab");
assert p.getLastName == "Józsi";
[/code:1:6da3561daf]
Az = Java-ban referenciát másol. Teccik érteni?
Mondjuk a clone() jó működéséhez (property osztályokat ne csak másolja, hanem új példányokat hozzon létre azokból is) a clone()-t felül kell definiálnod ezekben az összetett adattípusokban, de C++-ban is neked kell megírni a másolást végző kódot.
[quote:494b9e30f3="hanischz"]Még pár év és több giga memória lesz a gépekben illetve még erősebb proci. Ilyen gépen remekül fognak futni a progik.
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
A masik, hogy enyhen szuklatokuruseg a dolgok jelen allapotaban a szoftverfejlesztest kizarolag PC-s (ertsd: szemelyi szamitogepes) kornyezetre vonatkoztatni. Ugyanis meglehetosen nagy szamu beagyazott eszkoz van korulottunk, amiket mar joreszt szinten magasszintu nyelveken (nagytobbsegeben C-ben) programoznak.
[quote:cdfbca5ffc="maszili"][quote:cdfbca5ffc="feledhetetlen"]
...az X=Y es tarsaik olyan makrok amiket a programozok is megirhatnak...
Szerintem itt valami félreértés van... én nem makrókról beszélek hanem rendes értékadó operátor megírásáról. Az nem makró hanem az osztály része.
[quote:cdfbca5ffc="feledhetetlen"]
vagyis mikor olvasod, fogalmad nincs rola, hogy mi tortenik valojaban,
csak ha megnezed a X assigment operator kodot
Ezt hívják OO-nak... :) nem érdekel hogy belül hogyan működik...
ha az OO indulatszo, akkor valoban annak hivjak
ha az ObjectOriented-re utalsz akkor annak az implementation hiding csak egy icipici resze
amugy igazad van, valoban felreertettem, nem a beepitett
copyonassigment-re gondoltam
a copyon parameteratadas, es ertekadas amugy szerintem rossz gyakorlatot sugall, igy kerulhetnek a stack-be 50ks objektumok...
... az igazi programozó csak egyféle paraméterátadási módot használ, mégpedig a cim szerintit ...
[quote:9721dcec52="bocs"]
amugy meg mindig varok az 'en nagyonis ertem a java-t es elmondom miert gyenge' csoportbol a valaszt arra kerdesre mit csinal a
[code:1:9721dcec52]synchronized( this ) { }[/code:1:9721dcec52]
a 'hat semmit' valasz eseten arra,
hogy miert nem szedi ki a fordito ?
ha javap-pal megnezed benne kell lennie...
Ez egy "feledhetetlen" feladat triviális megoldással 8)
[quote:6ecefdfa47="Andrei"]De meg senki nem volt konstruktiv, es nem mutatott nekem eddig egy frappans, hatekony, jol hasznalhato desktop Java alkalmazast (Matlab nem er :) ), ami bizonyitana szamomra, hogy mennyivel tobbet ad ez a nyelv es ez a platform (bocsanat ez a Nyelv es ez a Platform), mint barmi mas.
_szerintem_ azert van ez igy, mert az elobbi (az alkalmazas frappanssaga, hatekonysaga, jol hasznalhatosaga) a Felhasznalo szemszogebol itelheto meg - az utobbi ( nyelv/platform superiorsaga) pedig ettol fuggetlenul, a Fejleszto szemszogebol. (== nehez egy kinyomtatott szovegrol megmondani, hogy a billentyuzet, amin irtak kenyelmes/jo-e)
legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
aztán ezekre a képekre ráengedjek mondjuk egyszerű, primitív bilineáris szűrőt, ami pixelenként többfajta lebegőpontos műveletet végez.
semmi flame, csak találós kérdés: vajon milyen nyelven programozom, Java-ban vagy C++ -ban?
naugye.
hát rettenetesen fáznék attól, ha teljesítménygyilkos nyelven kellene dolgoznom, mert egyszer csak kiderülne, hogy a feladat a nyelv választás miatt megoldhatatlan... ez pedig az általam választott nyelvről még soha nem derült ki.
[quote:8a380672e5="Csab"]Persze mindenre lehet java-t használni, csak nem mindenre érdemes. Láttam már szervert, amit java-ban írtak és irgalmatlan erős gépeken úgy ment, mint egy beteg tetű.
Én is. De ez nem biztos, hogy a Java hibája, ugye? :) C++-ban is tudok rossz programot írni, ha nagyon akarok :)
Jónéhány éve java programozásból élek, ezért írtam, hogy triviális.
Vhogy úgy vagyok a java-val, hogy szép, és jó, és igazi oo nyelv, de azért a C++ -ra szavaztam.
Frimen:
Az, hogy nem takarít nem csoda, mert mint azt már mondottam: GC akkor van, ha elfogy a memória. Magyarul olyan, mint a lusta kollégista: csak akkor kezd el takarítani, ha már meg sem bír mozdulni a szeméttől. Amúgy valóban mindkét esetben beragasztod a fránya actionlistener-en keresztül a komponenseidet, dehát nemhiába szoktak cégek GUI-s munkákra úgy Java fejlesztőt keresni, hogy "x év Swing tapasztalat".
6-os java pedig tényleg kint van, ráadásul a forráskód is teljes egészében elérhető (sőt, még hibajavításokat és patch-eket is lehet küldeni hozzá), kb összevethető stabilitással, mint a Linux kernel, vagy a PHP 5.akárhány (folyamatos development). A Java konferencián Tim úgy vetített Netbeans-ről, hogy Mustang futott alatta - mondjuk banki rendszer alá még nem tenném.
[quote:0f60aa2c8c="popacsek"]Jónéhány éve java programozásból élek, ezért írtam, hogy triviális.
...
ok, trivialis, de irdd mar le mi is az a trivialis valasz?
csak azert erolkodom, mert azt gondolom nem az
szamit, hogy mennyi ideje, meg hol, meg mennyire
hivatasszeruen programozol javaban:
inkabb ez: erted-e az alapokat, vagy se
aki tudja erre az egyszeru kerdesre a valaszt az erti
aki nem, az csak dumal
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
Nevetségesnek ezt a szemléletet tartom, és csodálkozom, hogy az életből még nem vetted észre, hogy ez butaság. Egy bankot nem az fogja érdekelni, hogy na jó, venni kell még +X gépet, azért, hogy gyorsabb legyen a cucc. Az fogja érdekelni, hogy mennyire stabil a program, milyen gyorsan van kész, tudja-e kifogástalanul azokat a feature-öket, amiket kért.
Te verheted a melled, hogy kézzel csinálod a memória-menedzsmentet, de ezzel max. a 20e forintos c/c++ könyvelőprogramodat tudod majd reklámozni, hogy szerezz plussz 1-2 vevőt.
Nyilván megvan a területe a c/c++-nak is, de emiatt sz@rozni a java programokat - ehhez nagy pofa kell. Kb annyi, mint amit a 20e forintos példával írtam.
Van egy feladat, meg kell oldani. Lehet hozzá ezt is, azt is használni. Van, ahol a java lesz a jobb megoldás.
"The Java™ platform has a stigma of being a poor performer and has often been shunned as an environment for developing speech engines. We decided to better understand this stigma by writing a speech synthesis engine entirely in the Java programming language.
Remarkably, we were able to get better performance from our engine than one using similar algorithms written in C. Our team, composed of three engineers with significant backgrounds in the C and Java programming languages, also found it easier to make algorithm modifications using the Java programming language than using C. "
én éppen akkor nem
mellettem a másik asztalnál éppen adatgyűjtést, motor vezérlést stb raknak össze, ugyancsak c++ -ban, sok-sok konkurrens szállal, csilivili grafikus felülettel
---
más: privát munkámban nemlineáris illesztéseket, mátrix műveleteket csináltam. vajon ennek célszerű lett volna java-ban nekiállni?
erősen kétlem.
[quote:6bb92c1308="feledhetetlen"]
ha az OO indulatszo, akkor valoban annak hivjak
ha az ObjectOriented-re utalsz akkor annak az implementation hiding csak egy icipici resze
Nem indulatszó... Az enkapszuláció (szerintem) az egyik legfontosabb része az OO-nak... mert általa (is) lehet egy magasabb absztrakciós szintre lépni, így egyszerűsítve (bezárva) a problémákat.
[quote:6bb92c1308="feledhetetlen"]
amugy igazad van, valoban felreertettem, nem a beepitett
copyonassigment-re gondoltam
a copyon parameteratadas, es ertekadas amugy szerintem rossz gyakorlatot sugall, igy kerulhetnek a stack-be 50ks objektumok...
Vegyük azt a példát amikor egy függvény egy változó tartalmával végez műveleteket. Ha érték szerint megy az átadás akkor a függvénynek van egy saját példánya amit nyugodtan megváltoztathat a munkája során anélkül hogy az eredetit elrontaná... De a programozó megteheti hogy a változó értéke helyett egy mutatót ad át... a programozó DÖNT!
[quote:6bb92c1308="feledhetetlen"]
... az igazi programozó csak egyféle paraméterátadási módot használ, mégpedig a cim szerintit ...
[quote:cf9d10aa02="waiter"] Pl. C, C++ vagy Java nyelvekkel lehet készíteni interaktív és hardvereszközökkel is kommunikáló, GUI frontendet is és dinamikusan generált webes felületet is, de PHP-vel csak ez utóbbit.
A következő idézet erről az oldalról származik:
http://www.php.net/manual/hu/intro-whatcando.php
Ablakozós alkalmazások írása. A PHP valószínűleg nem a legjobb nyelv grafikus felületű asztali alkalmazások írásához, de ha nagyon jól ismered a PHP-t, és szeretnél néhány fejlett PHP szolgáltatást használni a kliens-oldali programjaidban, a PHP-GTK-t is használhatod ilyen programok írásához. Ezt használva lehetőséged van operációs rendszerfüggetlen programok írására is. A PHP-GTK a PHP egy kiterjesztése, nem érhető el a hivatalos PHP csomagban. Ha további információkra van szükséged látogsd meg a PHP-GTK webhelyet!
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
Nevetségesnek ezt a szemléletet tartom, és csodálkozom, hogy az életből még nem vetted észre, hogy ez butaság. Egy bankot nem az fogja érdekelni, hogy na jó, venni kell még +X gépet, azért, hogy gyorsabb legyen a cucc. Az fogja érdekelni, hogy mennyire stabil a program, milyen gyorsan van kész, tudja-e kifogástalanul azokat a feature-öket, amiket kért.
Te verheted a melled, hogy kézzel csinálod a memória-menedzsmentet, de ezzel max. a 20e forintos c/c++ könyvelőprogramodat tudod majd reklámozni, hogy szerezz plussz 1-2 vevőt.
Nyilván megvan a területe a c/c++-nak is, de emiatt sz@rozni a java programokat - ehhez nagy pofa kell. Kb annyi, mint amit a 20e forintos példával írtam.
Van egy feladat, meg kell oldani. Lehet hozzá ezt is, azt is használni. Van, ahol a java lesz a jobb megoldás.
Igen csak akkor nem a Java-t kell nagy garral hype-olni, hogy igy hi-tech, meg ugy cutting edge, meg uberalles.
Egyebkent a bankok tipikusan nagyon konzervativak es unalmasak, amikor a technologiai fejlettseget nezzuk. Az infrastrukturajukhoz kepest a szolgaltatasaik elkepesztoen szegenyesek es elmaradottak.
Es akkor erdemes megnezni mi tortenik a Java-val, ahogy haladunk erdekesebb szektorok fele (ipari alkalmazasok, ur-tenger-legkor-gyogyszer-asvanykincs kutatas vagy ugy egyaltalan HPC-supercomputing). Egyre kevesebb orajelnyi idot eszik meg a JVM az ilyen szektorokban es egyre tobbszor van jelen a C/C++/Fortran meg a mindenfele specialis nyelvek. Sot az igazan high-end-ben mar kerek 0 kornyeken mozoghat a Java jelentosege/haszna/ertelme. Es hidd el ezek nem a 20e forintos szamlazoprogramok.
Hozzateszem: a minap kerestem egy egyszeru UML rajzolo tool-t nehany diagram elkeszitesehez. Talaltam egy csomo Java-s progit, tapasztalat:
- Lassuak (ugy nez ki, hogy az 1.8-as Dothan proci 2 mega L2-vel szar)
- Zabaltak a memoriat (sorry csak 1 giga ram van a notebookomban)
- Rondak (tudom, hogy ez szubjektiv, de a baratnom is elegge csunyanak tartotta) :lol:
- Volt nehany, ami rendesen szetszallt (pl. ArgoUML, amire epul kereskedelmi termek is).
Namost ehhez a "minoseghez" nem kell java. Es mindig ez van. Mutasson mar nekem valaki egy szep, gyors, hatekony Java programot! Nemigen van.
De tudjatok mit? Hasznaljunk Fortran77-et! Abban nincs dinamikus memoriakezeles. Igy nincsenek memory leak-ek sem. Viszont csereben pokolian gyors kodot general a forditoprogram. Hmmm?
[quote:4736c2a252="maszili"][quote:4736c2a252="KisKresz"]Na, kicsit durva kijelenteni a C++-ról, hogy valóban teljesíti az OO szemléletet, amikor a többalakúság csak mutatókon keresztül érhető el, a függvényeknél meg meg kell mondani, hogy virtuálisak-e... gyakorlatilag hatékonysági megfontolásokból egy csomó öszvér megoldás van benne.
A c++ már csak ilyen... sok helyen használatosak a mutatók...
Ezt nem értem mire írtad. De egyébként igazad van. :-)
[quote:4736c2a252="maszili"]
[quote:4736c2a252="KisKresz"]
Nincs memory leak, HA jól írták meg... és ránézésre nem látszik, hogy milyen kód fut le...
Pont ez a lényege az OO-nak. Nem tudom hogy hogyan működik és nem is kell tudnom hogy hogyan működik.
Azért pl. a STL-t valószínüleg jól írták meg :)
Az STL hogy jön ide?
Egyébként igaz, amit írtál, de ha C++-ban ilyet látsz:
A a;
A b;
...
A = B;
Nem csak azt nem tudod, hogyan csinálja, de azt se, hogy mit, egészen addig, amíg bele nem másztál vagy az A dokumentációjába vagy magába az implementációjába. Vagy bízol az A programozójában, hogy nem rakott valami elvetemült funkciót az értékadásba.
[quote:4736c2a252="maszili"]
[quote:4736c2a252="KisKresz"]
ez is csak egy lehetőség, amit a nyelv biztosít, de ésszel kell használni.
Ezt nem értem... milyen lehetőség?
Egyébként meg pont arról folyik a beszélgetés hogy a két nyelv a java és c++ milyen lehetőségeket ad a helyes kód megírásához.
Lehetőségen az operator overloading-ot értettem. Egyébként, ha már az OO és a C++ és az = kapcsolatáról van szó, érdemes áttanulmányozni ezt a weblapot, miért is ütik egymást:
Induljunk el a kályhától.
Most vonatkoztassunk el mindenféle számítógéptől és prog. nyelvtől gondolkodjunk tisztán matematikusként. Amikor az ember leír egy olyan algebrai kifejezést hogy a = b
akkor ezzel azt szeretné mondani hogy bé értéke legyen benne á-ban. És emmi egyébről szó nincs... mindenki természetesnek veszi hogy a és b egymástól független változók, csak az értékük egyforma. Ezt ugye nem vitatja senki... legalább is remélem.
Akkor most térjünk vissza a prog. nyelvekhez.
[quote:ada789ceb4="feledhetetlen"]
...a copyon parameteratadas, es ertekadas amugy szerintem rossz gyakorlatot sugall...
Az előbbi példámra hivatkozva szeretnék rámutatni arra hogy az érték szerinti átadás a természetes. Ezt szoktuk meg a matematikában. Korábban még példát (a függvényes) is írtam hogy a programozás során gyakorlati haszna van.
Ezek után nézzük az operátorokat.
Megkérdeztem hogy hogyan néz ki java-ban egy értékadás ha nem elemi adattípusokról van szó.
Hát én pont erről beszéltem. Egy egy szerű a = b helyett mindenféle varázs tagfüggvényeket kell hívogatni...
És mindez miért van?
[quote:ada789ceb4="_Joel"]
Nincs éspedig szándékosan nincs operator overloading. Ez egyike volt a "Java legyen egyszerubb, mint a C++" tervezesi elgondolasnak.
Na most ettől egyszerűbb lett a nyelv? Hogy az algebra megszületése óta használt egyenlőség jel helyett / mellett varázsfüggvényeket kell hívogatni?...
Miért nem ad eszközt a java arra hogy a saját magam kreált objektumhoz megírhassam a saját operátorait, hogy úgy használhassam mintha elemi adattípusok lennének? Nem ez valósítaná meg az egyszerű, átlátható OO szemléletet?
Nyílvánvalóan a nyelv nem készülhet fel minden adatszerkezetre amit a programozó kitalálhat... de adhat eszközt arra hogy a programozó elkészítse a saját maga kitalált adatszerkezetén működő operátorokat. Ezzel elfedve a művelet során fellépő problémákat.
Ezek után nekem ne mondja senki hogy a java egy egyszerűbb, jobb, nagyobb kifejező erejű nyelv mint a c++ mert nem hiszem el... :)
[quote:b9fa9c23a0="bocs"]
Prologból írtam a diplomamunkám, azzal foglalkoztam előtte 1-2 évig.
Konklúzióm: nagy hűhó semmiért.
Tudományos szempontból biztos érdekes, mérnöki szempontból katasztrófa.
A referencia számlálós memóriakezelés működne.
Sajnos neked nincs fogalmad sem a java működéséről.
Az i++, i-- szerinted mit csinál multi threades környezetben?
Tökéletesen viselkedik, ugyanis a primitív típusok automatikusan szinkronizálva vannak java-ban. Ezt jó tudni.
Ha egy mezei i++ nem jelent komoly problémát skálázási szempontból, a referencia számlálás sem lesz problémás.
Tudom, hogy hiper advanced java guru vagy, de azért ne hidd azt, hogy a világon mindent te tudsz a legjobban...
Ahogy en is leirtam, meg Joel is leirta: en nem vagyok Java guru, sot. Soha eletemben nem irtam Java programot.
Gyerunk tovabb a szakmai tevedeseidre (ehhez nem kell Java gurunak lenni, csak mondjuk az egyetem elso ket eveben egy kicsit jobban odafigyelni)!
Nem az volt a baj, hogy nem lehet szinkronizalt modon novelni vagy csokkenteni egy valtozo erteket, hanem az, hogy a szinkronizacio szukseges minden ilyen muvelet eseten. Ettol a problematol nem szabadulsz meg sem akkor ha azt kell irnod, hogy:
i++;
vagy valami ilyesmit, hogy
lock(i)
{
i++;
}
Elhiszem en neked, hogy a Java az elso valtozattal is helyesen mukodik, de a budos eletben nem fogod tudni kikerulni azt a problemat, hogy szinkronizalni KELL (legfeljebb mas teszi meg helyetted). Raadasul a referenciaszamlalasnal minden egyes ertekadasnal el kell vegezni ezt a muveletet, mig a GC on-demand mukodtetheto. Hatalmas kulonbseg!
Es a tul gyakori szinronizacio nagyon problemas SMP kornyezetben. Hiaba veszel szep sokprocis gepet, nem kapsz szamottevo teljesitmenynovekedest.
Az mar csak hab a tortan, hogy ezt a problemat nem is en vetettem fel, hanem _Joel (bevallom oszinten en nem gondoltam vegig ezt a vonalat, en az algoritmikus problemakra koncentraltam).
[quote:25e2adae49="bocs"]unkámban nemlineáris illesztéseket, mátrix műveleteket csináltam. vajon ennek célszerű lett volna java-ban nekiállni?
erősen kétlem.
Ez a reflection kicsit túl van lihegve nem?
Én ha tehetem nem használom a reflection-t java-ban, nemcsak azért mert nagyon lassú, hanem azért is mert - szerintem - nem szép megoldás, kerülendő technika. Szinte minden esetben kiváltható szebb, gyorsabb, átláthatóbb megoldással.
Alaposabban belegondolva én nem a nyelv miatt szavaztam a C++-ra a java ellenében, hanem a megvalósítás miatt. Amit én már régen beletettem volna a java-ba az az, hogy amit egyszer lefordít bytekódról, akkor azt ne kelljen megint lefordítani, hanem tegye le file-ba, vagy ilyesmi. Különösen igaz ez a JRE osztályokra. Azokat eleve le kellene fordítani telepítéskor, vagy eleve olyan csomagokat kellene csinálniuk, amiben le van fordítva. És a swing-en is üthetnének vmit ...
[quote:c5c2e438f1="maszili"]Vegyük azt a példát amikor egy függvény egy változó tartalmával végez műveleteket. Ha érték szerint megy az átadás akkor a függvénynek van egy saját példánya amit nyugodtan megváltoztathat a munkája során anélkül hogy az eredetit elrontaná... De a programozó megteheti hogy a változó értéke helyett egy mutatót ad át... a programozó DÖNT!
Igen, de C++-ban az érték szerinti paraméterátadás elég veszélyes is lehet, gondolok itt a kivágásra (object slicing).
[quote:52ec6adfd9="Csab"]Sok tekintetben jobb, más tekintetben rosszabb.
Én sok helyen java-t használok, más helyeken C++-t.
Vegyünk egy példát: a KDE C++-ban van írva.
Ha grafikus felület alatt fish-et akarok használni, a KDE fish protokolját fogom elérni és nem szórakozom JAVA varázslással.
Nyilván linux alatt grafikus felületet nem véletlenül nem programozik senki JAVA-ban. Vagy GNOME, vagy KDE. Rengeteg linuxos programot használok, de egyik sem java-s felületű az Eclipse kivételéve.
Jegyezzük meg: egy C++ progit lefordítasz, azonos platformon jó eséllyel menni fog. Ez java-ra nem igaz. Ha nincs java telepítve, megszívtad. Márpedig alapból sem windowson, sem bizonyos linux disztribúciókon nincs java. Ha nem vagy rendszergazdi, megszívtad. Bár unixok alatt nagyon ritka, hogy ne lenne java.
Ha 5-ös java-t fordítasz és kihasználod az új API-t, az nagy valószínűséggel nem fog menni 1.4.2 és korábbi java-kon. Rengeteg szívás volt amiatt, hogy ahol a programot futtatták régebbi java volt.
Ha 2D / 3D alkalmazást akarok írni, ami több platformon is elfut, SDL-t választok, nem java-t. PC-n még nem láttam olyan java-s játékot, ahol rendesen lehetne scrollozni sebesség miatt.
A mobiltelefonos java kb. 20-szor olyan gyorsan scrolloz, mint a mezei PC-s referencia implementáció, pusztán azért, natív és kemény hardver gyorsítással megy.
Aki foglalkozott már 2D grafikával tudja, hogy mindenegyes ciklus fontos. Egyáltalán nem mindegy az a 60% sebességkülönbség. Egy 1000*1000 pontos felületen 1 Millió pontot kell újra rajzolni szükség esetén.
Jelentheti azt is, hogy a programod 1 GHz-en már nem fut el, csak 2 GHz-en. A jelenlegi gépek felét ugye kizártad.
Hmmm, írtam java scrollozós progit: Egy k nagy bitmap-ban (memóriában) írtam szöveget, majd ezt mozgattam a képernyőn. Win alatt 500Fps!!!! felett jött ki. Linux alatt kevesebb 100fps, bár 3d gyorsítás nem volt bekapcsolva (lehet h számít a 2d képek rajzolásánál...).
3d motor beépítve, ami autómatikusan használja az opengl, directx-et.
Játékok: Chrome, IL-2.
Az sem probléma h nincs telepítve a java futtató környezet: én bemásoltam a progimat a jre-be és így írtam ki cd-re. Tökéletesen fut..
Igazából az az igazi előnye a javának h nem kell mindenféle platformra átültetni és átírni a progidat. Én sokat szívtam h Win98 alatt máshogy működött a C++ progik mint a NT alatt!
Pl 32000 pixelnél nagyobb (szélességű, magasságú) képet NEM tudsz létrehozni Win 98 alatt.
Másik szívás Visual Studio (200x verziójú), fájlmegnyitó ablakot, ami tökéletesen futott XP alatt. DE, Win98 alatt meg sem jelent! Hát én nem akarok ilyenekkel szívni. Ezért ha nem sebességkritikus atommag szimulációkat vagy Doom5-öt írom :) (tehát csak egy általános interaktív progit), akkor java-t választom. Ha sebesség kritikus, akkor megvizsgálom, vajon java alatt mennyivel lassabb... és eldöntöm.
[quote:07f97ac373="bocs"]legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
Maximálisan teljesíthető Java-ban, akár néhány száz sorban: http://access1.sun.com/techarticles/ImagingApps/JImage.html
http://java.sun.com/developer/technicalArticles/Media/AdvancedImage/index.html
Néhány Success story:
http://java.sun.com/products/java-media/jai/success/
Különösen a biomedical rész lehet számodra érdekes:
Biomedical Imaging
* Apteryx S.A.R.L. - Factor analysis of medical image sequences
* DECODON GmbH - Analysis of 2D gel electrophoresis images
* Millenium Technology Inc. - Magnetic resonance(MR) imaging systems
* National Center for Microscopy and Imaging Research - Mosaicking, Tomography, and Telemicroscopy
* Neologica - Web-based DICOM medical image viewing component
[quote:07f97ac373="bocs"]
konklúzió lemaradt: a Java használata ezeken a helyeken kizárt.
A java-val nekem rengeteg bajom volt. Lehet, hogy a sortolós algoritmus gyorsan működik, de a teszt nem volt helyes.
- Egyrészt: mivel a memória méretét felnövelted 256 MByte-re, ezzel gyakorlatilag kikapcsoltad a java Garbage Collection nevű förmedvényét.
- A GC-t már Commodore 64 alatt is utáltam.
A GC lényege, hogy mindig akkor kapcsol be, amikor nem kellene.
Szóval java-ban a GC-nek köszönhetően sosem fogsz pl. video / DVD lejátszó szoftvert írni.
Nyilván, ha a tesztet a GC-vel mérnéd más eredményt adna.
Másodszor a java a GC-nek köszönhetően eszméletlen sok memóriát zabál fel. Rengeteg cirkuláris referenciát tartalmazó objektumot meg fel sem szabadít. Elnyeli. Nem egyszerű feladat egy java programban memory leakage-et javítani.
A C++ konstruktor / destruktor függvényei igencsak hiányoznak a java-ból. A többszörös öröklés is.
[quote:8d9fe256b4="Csab"]Amikor ez a referencia nullára csökken, azaz senki nem használja, meghívjuk a destruktort és fölszabadítjuk az objektumot.
És ez vezet el a már említett körkörös referencia zavarokhoz, amik miatt egyik gc sem úgy működik ahogy leírtad. Itt le is van írva:
http://www.memorymanagement.org/faq.html#gc.ref
Bővebb infóért:
http://www.memorymanagement.org/
Ajánlom az Articles szekció Beginner's Guide cikkét.
[quote:4f14dea05b="zsolt"][quote:4f14dea05b="syntern"] A Java teljesítménye (-server kapcsoló) a legtöbb esetben megközelíti ugyanazt a kódot megvalósító C++ programot a Hotspotnak köszönhetően, valamint az erősen rekurzív esetekben jócskán meg is előzi. (5-ös Java, gcc, -O1, 2, 3-mal is mérve, a -O3 már majdnem olyan jól teljesített mint a Java) A mérések kizárólag memória-kezelést és algoritmus végrehajtást mértek, ugyanaz a C++ kód és Java kód futott, feladatonkénti mérési idő 30-45 mp, hogy ne legyen nagy hiba az óra pontatlanságából. Sok esetben gyanítjuk, hogy a Hotspot optimalizálása alig kezdett el működni.
Azért kíváncsi lennék arra a C++ és Java kódra. Saját tapasztalatom, hogy C++-ban is lehet eszméletlenül lassú kódot írni, nem mindegy ugyanis, hogy mennyi tapasztalata van a programozónak.
Küldj egy címet és elküldöm a konkrét kódokat. De hogy megnyugtatóbb legyen: ugyanúgy programozta le mindkét nyelvben pl. a mátrix-hatványozást, vagy a quicksortot (ugyanolyan induló tömbértékekre), ill. a prímszámkeresést. Nem nagy dolgok, de memóriazabáló (fusson a GC) és procizabáló (legyen idő mérni) feladatokat kerestünk. Direkt úgy készítettük elő a mérést, hogy semmi zavaró tényező ne legyen benne, tisztán a sebesség legyen mérhető, semmi mellébeszélés.
[quote:62a506aa4e="Csab"]A java-val nekem rengeteg bajom volt. Lehet, hogy a sortolós algoritmus gyorsan működik, de a teszt nem volt helyes.
- Egyrészt: mivel a memória méretét felnövelted 256 MByte-re, ezzel gyakorlatilag kikapcsoltad a java Garbage Collection nevű förmedvényét.
- A GC-t már Commodore 64 alatt is utáltam.
Másodszor a java a GC-nek köszönhetően eszméletlen sok memóriát zabál fel. Rengeteg cirkuláris referenciát tartalmazó objektumot meg fel sem szabadít. Elnyeli. Nem egyszerű feladat egy java programban memory leakage-et javítani.
Nem tudom, hogy mennyire tűnt fel, de egy 50.000.000 elemű integer tömbön fut a quicksort mindkét esetben. Mivel mind a Java, mind a C++ 4 bájton tárol egy intet, ezért minimum 200 MB-ot eszik mindkettő. Én a Java esetében a parancssori kapcsolóval a maximális memóriafoglalást állítottam 250 MB-ra, a minimálisról és a menet közbeniről nem mondtam semmit. Kliens esetében -Xmx207 is elegendő lett volna, -server esetében 215 kellett neki. Arról nem is beszélve, hogy menet közben nincs változás az igényelt memória méretében. De hogy pontosabb kép legyen:
A C++ kód a top szerint 191M-et foglal, a Java kód 201M-et (-server kapcsolóval 202M-et). A 10MB különbség az, ami a teljes optimalizálási környezetet adja. Szerintem annyit megér.
Azaz még egyszer: ebben a tesztben meg sem hívódik a GC, de nem azért, mert túl sok memória van szabadon, hanem mert az algoritmus menet közben nem igényel és nem szabadít fel memóriát. Várom a következő belekötést :)
[quote:02d54d8786="bocs"]legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
aztán ezekre a képekre ráengedjek mondjuk egyszerű, primitív bilineáris szűrőt, ami pixelenként többfajta lebegőpontos műveletet végez.
semmi flame, csak találós kérdés: vajon milyen nyelven programozom, Java-ban vagy C++ -ban?
Mondok masikat: wikipedia-t letoltottem, es a linkek menten graffa alakitom. Azt tudni kell, hogy az angol wikipedia 800.000+ bejegyzest tartalmaz, a letoltott angol dump XML formatumu, kicsomagolva 5 GB. Van hozza XSD sema, es en szeretek idohatekonyan fejleszteni, ugyhogy egybol az XML-t objektumos formaban beolvasva kezelni.
Szerinted miben irtam meg a programot? :) Nana hogy Javaban, es mit ne mondjak buszke vagyok arra, hogy nagyon egyszeru volt vegigparsolni az 5GB XML-t, csak ismerni kellett hozza a megfelelo eszkozoket. Bizonyara C-ben is ment volna, de nem hiszem, hogy minden eszkoz rendelkezesre all, es nem hiszem, hogy egy nap alatt vegeztem volna vele. Ezzel csak azt akarom mondani, hogy a memoriahatekony programozas nem nyelvi csoda, ismerni kell az eszkozt amit hasznalsz, es meg lehet csinalni streaming modban is mindent.
A programozási nyelv egy eszköz, és felesleges azon vitatkozni melyik a jobb. Szerintem. Nekem amire néhanapján kell jó a pascal, ezt tanultam, ezt "tudom" használni. Azokról pedig akik úgy mondanak valamiről véleményt, hogy nem is ismerik, meg van a véleményem :) Épp ezért a többi nyelvről nem is beszélek.
[quote:621cb9c01c="handler"]
N ugyfel meg azt mondja neked X ido utan, hogy a programod rossz, a szamitasok nem helyesek es emiatt neki Y millio forintos kara keletkezett, es legyel szives minden kart es javitassal felmerulo koltseget megteriteni. :D
Ugye tesztelési, átvételi stb. jegyzőkönyvről még nem is hallottál?:)
A szerződések kitételeiről a felelősség kérdésében nem is beszélve..:)
[quote:621cb9c01c="handler"]
A fenti bytecode hozzaszolasodbol nem igy tunik. Osztott eroforrast hogy kezelsz? Refcount ? :D Memory leak (es memory corruption) nelkui kodot pedig aligha fogsz a fenti feltetel teljesulese nelkul csinalni...
Osztott erőforrást.. fogok egy erőforrást és felvágom kis darabokra oszt szétosztom.:)
Pontosan melyik feltételről is van szó?
Fri
[quote:eb9dbbe9fd="Csab"]
- Egyrészt: mivel a memória méretét felnövelted 256 MByte-re, ezzel gyakorlatilag kikapcsoltad a java Garbage Collection nevű förmedvényét.
Szerinted 50 millio int-hez megis mekkorara kellene meretezni a heap-et? :)) 200 MB-ra biztosan szukseg van. Gondolom azert adott meg 256 MB-ot syn, mert gyakran szoktak ennyit megadni az emberek.
Garbage Collection-t nem az -Xmx iktatja ki, hanem maganak a tesztnek az a jellege, hogy alapvetoen nem jar memoria allokacios muveletekkel: egy mar kesz tombot sortol az algoritmus. Nem allokal, nem peldanyosit, nem bazguralja a memoriaallokaciot. Egyvalamit mer: mennyire jo a Java bytecode-bol az adott platform gepi kodjat generalo optimalizacio es forditas.
- A GC-t már Commodore 64 alatt is utáltam.
Ezt most bővebben ki kéne fejteni, nem látom az összefüggést.
A GC lényege, hogy mindig akkor kapcsol be, amikor nem kellene.
Szóval java-ban a GC-nek köszönhetően sosem fogsz pl. video / DVD lejátszó szoftvert írni.
Ajánlom figyelmedbe ezt a whitepapert:
http://java.sun.com/docs/hotspot/gc5.0/ergo5.html
"The maximum pause time goal is specified with the command line flag
-XX:MaxGCPauseMillis=<nnn>"
" -XX:GCTimeRatio=<nnn>
The ratio of garbage collection time to application time is
1 / (1 + <nnn>)
For example -XX:GCTimeRatio=19 sets a goal of 1/20th or 5% of the total time for garbage collection."
A GC lényegében akkor kapcsol be, amikor valamelyik generációban elfogy az allokálható hely.
Nyilván, ha a tesztet a GC-vel mérnéd más eredményt adna.
Nyilván lehet olyan tesztet csinálni, ami sok objektum létrejöttével jár (pl meg van adva, hogy 64MB memóriát használhat a program és le kell allokálni összesen 500 MB-nyi memóriát miközben C++-ban dispose-olsz, Javaban meg eldobálsz referenciákat). Kérdés, hogy ez mire jó, és milyen valós alkalmazáshoz hasonlít, hogy relevanciája is legyen a mérésnek.
Másodszor a java a GC-nek köszönhetően eszméletlen sok memóriát zabál fel. Rengeteg cirkuláris referenciát tartalmazó objektumot meg fel sem szabadít. Elnyeli. Nem egyszerű feladat egy java programban memory leakage-et javítani.
De egyszerű feladat, egy csomó profiling eszköz van, amivel egy kis hozzáértéssel egész gyorsan meg lehet találni, hogy hol és mi a baj. A cirkuláris referencia pedig nem okoz gondot. Csak olvass utána hogyan is működik a GC, és rájössz te is. Nem kell hozzá egyetemi diploma.
A C++ konstruktor / destruktor függvényei igencsak hiányoznak a java-ból. A többszörös öröklés is.
Hát persze, minden C++ programozónak. De csak egy ideig, utána megtanulják használni az interfészeket és megtanulnak bízni a GC-ben, illetve megtanulják a tuningolását.
Jó, lehet, hogy negatív irányban vagyok elfogult a java-val szemben.
A munkahelyemen is állandóan java-ban kell programozni és visszasírom a régi jó C++, C-s időket.
Mindenesetre ha lehet választani java és .net között, a java-nak drukkolok.
Persze a java-nak egyre több konkurense lesz. A mobiltelefonos iparban a Macromedia Flash, Python, PHP,... még szóbajöhet, mint alternatíva. Gyorsabb és olcsóbb megoldások. A Sun dollármilliókat kaszál a telefonokot futó java implementációkból.
Szóval az alap java az egész jó.
A Sun, aki viszont mögötte van, már nem a legjobb választás. Nehéz vele együttműködni.
[quote:ea5d873baf="_Joel"]
.. bar az teny, hogy foleg szerveroldalon eli meg mindig a reneszanszat (csak eleg megnezni a web frameworkok szamat, es az egyre ujabb buzzwordoket (2-3 eve ugye az AOP volt a nagy szam, mostanaban a dependency injection es tarsai... kivancsi vagyok mi jon jovore:)
Ezzel egyet kell, hogy értsek.
Szerver oldalon nem sok gondom volt még a java-val.. ott "általában" van elég erőforrás.
Cliens oldalon.. viszont már megingott a hitem a Java-ban..
Lássuk Joel mit tudsz..:
mitől lehet szerinted az, hogy 2 ellenőrző is azt mutatja, hogy már nincs leak: a heap
rendben: az objektumok föltámadnak, majd porba hullnak.. a foglalt/free/össz heap
nem nő.. mégis azt látom, hogy a memóri felhasználás folyamatosan nő.
A poén, hogy linux alatt nem nő a memória felhasználás.. M$ 2003 alatt nő..
most boot-olok át M$ XP-re, hogy lássam ott mi van.
Te mit használsz (fejlesztő eszköz, checkelő)?
Fri
[quote:ca0b3614c6="Csab"]Másodszor a java a GC-nek köszönhetően eszméletlen sok memóriát zabál fel. Rengeteg cirkuláris referenciát tartalmazó objektumot meg fel sem szabadít. Elnyeli. Nem egyszerű feladat egy java programban memory leakage-et javítani.
Először is csak C++-ban van olyan, hogy a cirkuláris referenciák elnyelődhetnek, a Javaban ez nem létezik. A Java kidobja azokat az objektumokat, amelyekre futó szálból nincs referencia (ez finomhangolható, el lehet érni tudatos beállításokkal azt, hogy csak egyszerű referencia-számláló fusson, de minek).
Másodszor nem értem, hogy a GC-nek köszönhetően miért zabálna sok memóriát? A GC elsősorban prociidőt eszik akkor, amikor éppen nincs elég szabad memória, és az új igénylés már nem szolgálható ki. Azaz nem olyankor, amikor éppen kedve tartja, hanem akkor, amikor szükséges. C++-ban is akkor szabadítod fel az objektumot (ha nem felejted el), amikor szükséges, a különbség az, hogy Java esetében:
1. nincs memória-töredezettség (azaz ha kis apró szabad szeletek vannak, akkor a többit összenyomja, és nagyobb hely lesz - szintén csak akkor, ha ez szükséges)
2. ha tényleg nincs referenciád az adott objektumra, akkor kidobja. Felejtsük el a körkörös referenciát, thread szinten indul a GC.
Egy Java programban akkor van memory leak, ha a fejlesztő nem szüntet meg referenciát a megfelelő objektumra. De ez már inkább az, hogy a Javaban programozás nem azt jelenti, hogy ismerem a nyelv szintaktikáját, hanem azt, hogy ismerem a nyelv működését.
std::string a1("first" ), a2( "last" );
std::string result = a1+a2;
A probléma az, hogy a string kezelés nem egységes. Az STL string kezelő (std::string) túl gagyi ahhoz, hogy közös legyen, rossz a dokumentációja, így minden könyvtár úgy implementálja, ahogy akarja.
A javadoc-kal ugyanez a helyzet. Mialatt java alatt egységes, C++-ban legalább 3-4 féle javadoc szerű szabvány létezik.
Kár, hogy a java-ból az operator overloading kimaradt. C++ alatt ez baromi áttekinthető kódot eredményez.
[quote:ef681df25d="Frimen"]
Ez igaz is meg nem is..
.. igaz, mert mindkettő csak specifikáció..
.. nem igaz, mert a java jvm nélkül sokra nem jó, kirakod a kodot a
falra és gyönyörködsz benne?:)
.. nem igaz, mert foglalj már le légyszives "kézzel" memóriát java-ból,
majd szabadisd fel (ez a jvm "feladata)
Fri
- a java bytecode jvm nelkul hasznosabb mint gondolnad, ugyanis bizonyithato a helyessege, vagy hogy megfelel a specifikacionak...
- ez a foglaljunk kezzel memoriat nalad valami fetis? Miert nem veszed at a forditotol a memoriakezeles problemajat (c, c++ eseten) ha mar olyan jol kezeled a memoriat, elvegre Te is kioszthatod mikor melyik regiszterhalmazt hasznalja...
[quote:5393cac61d="Frimen"]mégis azt látom, hogy a memóri felhasználás folyamatosan nő.
A poén, hogy linux alatt nem nő a memória felhasználás.. M$ 2003 alatt nő..
Ennek alapjan ez bugnak tunik. Van valami platformfuggo a kodban (pl SWT)?
Te mit használsz (fejlesztő eszköz, checkelő)?
Az a baj, hogy olyan szinten amilyenen szeretnék, semmit. "Hivatalból" netbeans-szel játszom időnként újra és újra (including netbeans profiler), eclipse-t neha nezegetem de nem hasznalom. H meg veletlenul XML Schemat kell szerkeszteni akkor szerzek egy JDevelopert:) Sajnos egyre jobban tavolodom a fejlesztestol ebben a munkakorben, es ez nem tulsagosan tolt el sok eletorommel.
Hamár felmerült a "garbage collector/erőforrás gazdálkodás/memory leak" ...
Feltennék egy kérdést.
Nem logikusabb olyan kódot írni ami jól működik? Mert akkor nem szükséges a futásidőben történő erőforáspocsékló hibajavításokkal terhelni a rendszert... Vagy rosszúl látom? :)
Előrebocsájtom hogy a JAVA-t nem ismerem (a C++ -t igen) behatóan és nem fikázás akart lenni a kérdésem, csupán érdeklődöm.
[quote:726a48257c="fdavid"]Volt alkalmam mobiltelefonba is fejleszteni, koszoni szepen - amit en irtam - nem fagy le. Es mas programjaim sem. Szoval nem a nyelven mulik, hogy egy program jo-e vagy sem.
En ugy vettem eszre aktiv Symbian fejlesztő ismerőseimen, hogy egyre cifrábbakat tudnak káromkodni a nyelv és a platform kényelmetlenségén .net és javahoz képest. Persze lehet, hogy nekik nem olyan fejlesztési feladatuk volt, mindenesetre az egyik szoftverükkel a nokia középvezetője példázódott valami konferencián... (symella, ha mond valamit és jól írom...)
[quote:726a48257c="fdavid"]De ott van a D nyelv (http://www.digitalmars.com/d/), ami azt hiszem, hogy igencsak eltalalt holmi.
Én évekkel ezelőtt nagyon néztem a D nyelvet, programokat is írtam rajta. Egészen addig, míg egy alkalmazásnál azt mondta az üzemeltető, hogy vagy C++ vagy Java, ismeretlen marhaságokat ne akarjak futtatni. (erőgépen, felügyelt környezetben sok-sok procival)
[quote:726a48257c="fdavid"]A masik, hogy C++-hoz is van GC, vagy pl. ott a QT, amivel alom dolgozni.
Persze, de azt ugye tudod, hogy a C++-os memória-felszabadítás után az üres memória-terület töredezetté válik, míg Javaban a fogalom is ismeretlen? Azaz előfordulhat olyan C++ eset, amikor a GC takarít, de az allokáció sikertelen, mert a memória-terület nincs összenyomva, pedig egyébként a darab összessége elég lenne.
Erről a Tanú jut eszembe, meg a narancs...
[quote:726a48257c="fdavid"]Nem! A managelt kod csak toredeket oldaj meg a problemaknak, es raadasul ujakat hoz be, a hibas szemlelettel. A megoldas a minsoegbiztositas. Tisztesseges folyamatdefiniciok, modszerek, eszkozok, human eroforras osszhangaja, tervezes, dokumentalas, es atfogo teszt.
Aha, ezek megoldások, de ha a szemlélet hibás, akkor ezek sem érnek semmit sem. Azaz mindegy milyen szinten, de tisztában kell lenni a szemlélettel, ha helyen akarod alkalmazni a technológiát.
[quote:726a48257c="fdavid"]Ez sem feltetlenul igaz. Assemblert nagyon keves helyen hasznalnak, es gyakran nem C-ben, hanem magasabb szintu kornyezetben fejlesztenek, es csak generaljak a C kodot. Ja es Pascal is elofordul meg itt-ott, persze nem uj projektekeben.
Persze, és a generáció során szépen generálják a memóriakezelést és a managelt környezet összes funkcionalitását, ahelyett, hogy a managelt környezetben futtatnák. Megint csak arról van szó, hogy van egy kitalált, működő rendszer, szeretnénk egy hasonlót, barkácsolunk magunknak, mert mi jobban értünk hozzá. Bejöhet, de általában nem fog.
Nyilván, ha a tesztet a GC-vel mérnéd más eredményt adna.
Nyilván lehet olyan tesztet csinálni, ami sok objektum létrejöttével jár (pl meg van adva, hogy 64MB memóriát használhat a program és le kell allokálni összesen 500 MB-nyi memóriát miközben C++-ban dispose-olsz, Javaban meg eldobálsz referenciákat). Kérdés, hogy ez mire jó, és milyen valós alkalmazáshoz hasonlít, hogy relevanciája is legyen a mérésnek.
[quote:c1d30efc97="popacsek"]Ez a reflection kicsit túl van lihegve nem?
Én ha tehetem nem használom a reflection-t java-ban, nemcsak azért mert nagyon lassú, hanem azért is mert - szerintem - nem szép megoldás, kerülendő technika. Szinte minden esetben kiváltható szebb, gyorsabb, átláthatóbb megoldással.
A Config es a Commander osztalyokra hivatkoznek:
http://javasite.bme.hu/~lazlo/src/telenio/Main.java.html
ez nem a reflection legfontosabb hasznalat, de a parancsminta igy sokkal karbantarthatobb mint a switch block-ban megvalositott trivialis valtozat.
[quote:c1d30efc97="popacsek"]
Alaposabban belegondolva én nem a nyelv miatt szavaztam a C++-ra a java ellenében, hanem a megvalósítás miatt. Amit én már régen beletettem volna a java-ba az az, hogy amit egyszer lefordít bytekódról, akkor azt ne kelljen megint lefordítani, hanem tegye le file-ba, vagy ilyesmi. Különösen igaz ez a JRE osztályokra. Azokat eleve le kellene fordítani telepítéskor, vagy eleve olyan csomagokat kellene csinálniuk, amiben le van fordítva. És a swing-en is üthetnének vmit ...
Feltalaltad amit a microsoft java (jview.exe) vm-ben is feltalaltak.
Ott volt erre egy nagy adatbazis a windows home alatti dzsuvaban.
Ettol 'gyorsabb' volt a vm inditas.
Az update pedig a class hash-re alapult.
(Errol mar irtam)
Elegge biztos vagyok, hogy minimum 40 patentet jegyzett be a microsoft 20ezer jogasza erre. Neha ez is szamit...
[quote:9451d949c7="Andrei"]De meg senki nem volt konstruktiv, es nem mutatott nekem eddig egy frappans, hatekony, jol hasznalhato desktop Java alkalmazast (Matlab nem er :) ), ami bizonyitana szamomra, hogy mennyivel tobbet ad ez a nyelv es ez a platform (bocsanat ez a Nyelv es ez a Platform), mint barmi mas.Andrei
Volt itt aki UML modellezőt keresett. Nekem a MagicDraw nevű eszköz nagyon bejött, próbáld ki. Nem azért, mert versenyez bármilyen csilivilli és megszokott alkalmazáshoz, hanem mert minden Java platform alatt ugyanúgy néz ki (Swing) és a Swing ellenére is meg tudták írni gyorsra, elegánsra.
Jah igen: láttam hogy mennyire egyszerű plugint fejleszteni hozzá, ami macerálja a modellt és kommunikál egy J2EE szerverrel, lekéri a J2EE szerver memóriában lévő EJB beanjeit és azokat majdnem on-the-fly kirajzolja, a módosításokat pedig visszaírja az appszerverbe. Nem biztos, hogy egy 3D kóder ettől hasraesik, mindenesetre elegáns és szép megoldás volt egy hülye problémára.
[quote:79d253eeaf="syntern"]
Adj szabad kezet tetszoleges feladat implementaciojara, mondj egy eredmenyt, amit latni szeretnel, es kihozom. Nem veletlen a sok pl. Linux-Windows osszehasonlitasban kijovo eszmeletlen kulonbseg: ha akarom, tudom ugy alakitani, tudom ugy implementalni. hogy a C++ lassabb legyen. Ennyit a kamuzasrol.
Ha Neked szabad kezed van és a másiknak is.. de még ha meg is álapodtok észerű elvekben, akkor is lepipálja a java-s programodat egy c-ben megirt.:)
Bevallom ennyire fanatikussal még nem találkoztam mint Te vagy.:))
[quote:79d253eeaf="syntern"]
Kijavitalak: Te az SWT-re gondoltal, en meg a Java eleg regota alkalmazott awt-jere:
Megkövetlek.. néha már jajong a fejem ettől a sok röviditéstől, 10 percenként
kitalálnak egyet.:)
AWT.. nem ettem meszet, hogy egy elavult technologiával irjak meg egy mai programot.
Az awt elavult.. a swing elcseszett.. a kettő között lenne az igazság.. szerintem.
Felfoghatod ugy is, hogy kijott. Mi mar kiprobaltuk, mertuk, gyorsabb, mint az 5-os :)
Tyja.. ha a gyorsaság a fontos.. érdekes modón még mindig sokan használnak 1.4-es
javat, föleg kritikus környezetben.. szeirnted ez véletlen?
Fri
[quote:5248b3a9af="Csab"]
A GC lényege, hogy mindig akkor kapcsol be, amikor nem kellene.
Szóval java-ban a GC-nek köszönhetően sosem fogsz pl. video / DVD lejátszó szoftvert írni.
A gc addig nem fut amig nem tudja az ossze nem-realtime thread-et leloni.
Nem tudja leloni, ha a thread eppen nativ reszeben tartozkodik a programnak.
Ergo: a video bitblt, illetve nativ decoder dll alatt sem fog GC futni...
Nem hiszem, hogy a gc logikaja akadalyozna barkit, hogy dvd lejatszo szoftvert irjon.
Másodszor a java a GC-nek köszönhetően eszméletlen sok memóriát zabál fel. Rengeteg cirkuláris referenciát tartalmazó objektumot meg fel sem szabadít. Elnyeli. Nem egyszerű feladat egy java programban memory leakage-et javítani.
a legelso gc implementacio is felismerte a hurkokat a fuggosegi grafban, nem tudom hol talaltal olyan felreimplementalt vm-et amiben ez nem igy van... (kaffe?)
a nyelvdefinico puszta meglete teszi igazan egyedive a javat
fontos meg megjegyezni, hogy a nativ kijarat/bejarat resze a nyelvdefinicionak
es ezt egyetlen mas nyelven sincs igy
a "hogyan jon le egy objektum/thread a nativ szintre",
es "hogyan megy vissza" altalaban nem nyelv szinten meghatarozottak
maximum library, de az is implementor/library fugges inkabb
a gc kenyelmes de azt is latni kell, hogy a gc nem a kenyelem miatt kell:
a gc alapja dgc-nek
dgc pedig alapja az elosztott szamitasi modelnek
ezek az eredmenyek/tulajdonsagok (rmi+dgc) puszta meglete is olyan
fontos feltetel ami mellett a sebesseg csak a sokadik szempont
[quote:e0e2018394="Frimen"]
Bevallom ennyire fanatikussal még nem találkoztam mint Te vagy.:))
Hmm, 2000 óta ismerem Syntern-t (bár azt hiszem abban a gólyatáborban nem voltam, amiben ő volt gólya - de már elsőévesként egyiket volt az InfoSite-ot összerakó srácoknak), de fanatikusnak nem nevezném. Bár ha azt nézzük, hogy az Automatizálási tanszéken Java-val foglalkozva doktoranduszkodik, J2EE labort és tárgyat tart... (syn, bocs hogy lebuktatlak)
[quote:6c08739028="feledhetetlen"]Kedves frimen:
a legeslegelso amit a a swingrol tudni kell:
CSAK CSAK CSAK a swing thread-rol vegezz swing muvelteket
vagyis aki a main thread-bol csinal setVisible vagy akarmi mas muveletet az magara vessen...
a java helyett pedig nincsen mas:
ezt be kell latni
az idezett kod hibas, csak okulasul legyen itt...
Bocs, már látom, mire gondoltál.. igazad van és egyetértek.. nem onnan
szoktam.:)
Látszik, hogy nem szoktam igy "nyersen" dolgozni..:)
De ez a problémán nem változtat.. nekem akkor eltérés van a két
megvalósitás memoria használata között.
Fri
Pneumatikus oszlop szabályozási feladata.
Tudod, témavezetőm egy egész üzemet élesben vezérlő programot írt Prologban... de az a nyelv egyszerűen nem erre való, nem jó eszköz ilyen feladatra. Tapasztalat.
Sok helyen hasznos lehet, de van ahol nem jó választás. A c++ -al viszont nehéz befürödni, csak nagyon ritkán derül ki a projekt végén, hogy mégsem ezzel kellett volna.
Egyébként a Prologra ugyanaz vonatkozik, mint a Java-ra: mindenki használja nyugodtan, csak az ellen a beteges szemlélet ellen fújok, hogy "Java-n kívül más nyelv nincs", amint az explicite itt el is hangzott a fórumon.
[quote:397b8064b9="_Joel"]Frimen:
Az, hogy nem takarít nem csoda, mert mint azt már mondottam: GC akkor van, ha elfogy a memória. Magyarul olyan, mint a lusta kollégista: csak akkor kezd el takarítani, ha már meg sem bír mozdulni a szeméttől. Amúgy valóban mindkét esetben beragasztod a fránya actionlistener-en keresztül a komponenseidet, dehát nemhiába szoktak cégek GUI-s munkákra úgy Java fejlesztőt keresni, hogy "x év Swing tapasztalat".
1. Az egyik esetben nálam azonnal takarit (minden esetben) a másik esetben nem.
2. Azért érdekelne szerinted hol ragad be és mitől az actionlistenerben az objektum?
Ugyanis mint láthatod, az első esetben szándékosan "ragasztom be" az objektumokat,
ha megnézed a második klickre nullázom fel a referenciákat.
Szóval Joel, előbb tanulj meg kodot értelmezni, utána gere nekem ekkora mellénnyel.
Fri
[quote:7f84f3f05d="hanischz"]Igazából az az igazi előnye a javának h nem kell mindenféle platformra átültetni és átírni a progidat. Én sokat szívtam h Win98 alatt máshogy működött a C++ progik mint a NT alatt!
Pl 32000 pixelnél nagyobb (szélességű, magasságú) képet NEM tudsz létrehozni Win 98 alatt.
Másik szívás Visual Studio (200x verziójú), fájlmegnyitó ablakot, ami tökéletesen futott XP alatt. DE, Win98 alatt meg sem jelent! Hát én nem akarok ilyenekkel szívni.
Operációs rendszerek közti különbségekbe ütköztél, ez nem a C++ hibája. Ha valami egységes elemkészletet használtál volna, amelyik win98 és nt alatt is megy, vagy utánanézel, hogy az általad használt operációs rendszer specifikus elemek a korábbi verziókban is benne voltak-e, akkor ez nem fordult volna elő. C++-ban is lehet (majdnem) platformfüggetlenül programozni, ha akarsz. :)
[quote:dd98059aa3="ssikiss"]Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
Hát, az én elképzeléseimben a dll egy bináris, amin belül lehet bármi, és ha nekem nem mondják meg, hogy mi van benne, meggebedhetek, akkor sem fogom tudni kitalálni a belső osztályszerkezetet, amennyiben véletlen C++-ról fordult az a dll, és nem pl. C-ről. Ennek ellenkezőjéről egy példával már meg is lehet győzni :)
[quote:57c559ab08="_Joel"]Frimen:
Az, hogy nem takarít nem csoda, mert mint azt már mondottam: GC akkor van, ha elfogy a memória. Magyarul olyan, mint a lusta kollégista: csak akkor kezd el takarítani, ha már meg sem bír mozdulni a szeméttől. Amúgy valóban mindkét esetben beragasztod a fránya actionlistener-en keresztül a komponenseidet, dehát nemhiába szoktak cégek GUI-s munkákra úgy Java fejlesztőt keresni, hogy "x év Swing tapasztalat".
1. Az egyik esetben nálam azonnal takarit (minden esetben) a másik esetben nem.
2. Azért érdekelne szerinted hol ragad be és mitől az actionlistenerben az objektum?
Ugyanis mint láthatod, az első esetben szándékosan "ragasztom be" az objektumokat,
ha megnézed a második klickre nullázom fel a referenciákat.
Szóval Joel, előbb tanulj meg kodot értelmezni, utána gyere nekem ekkora mellénnyel.
Fri
Szeritem általános esetben nem számít h a c++ vagy akármilyen nyelv 10-50%-al gyorsabb kódot generál mint a java. Mert többet szívhatsz az utólagos memória kezelési és egyéb hibákkal és a különböző platformra való átírással.
Régebben Builderben írtam a progikat (amiket eladtam). Nagyon jó kis API-t hoztak létre. Késöbb áttértem a visual C-re, de 1-2év programozás után elegem lett abból h a Windows api még csak nem is objektum orientált! (Legalábbis nem teljesen. Hanem egy része esemény vezérelt. Egy beviteli mező háttérszínét közvetlenül nem lehet béállítani hanem csak eseményt kiváltó kóddal elég tré módon).
Másik gond az említett inkompatibilitás a különböző Windows-ok között. Nagyon sokat szívtam h kis "apróságokban" és a dokumentációkban nem említve különböznek a Win-ek.
Harmadik h a megrendelő tegnap előttre kéri a programot és nem volt időm lassan, nyugodtan , minden részét megtervezve és letesztelve megírnom a programokat.
Ezért sokat kellett hibát javítanom utólag és ezt men szerettem. Akkor figyeltem fel a menedzselt kódú környezetekre. Java vagy C#. Az utóbbi szerintem kényelmesebb (legalábbis nekem, mert C++os voltam), De a java azért sokkal több api-t tartalmaz mint a .Net. (Egyelőre.)
Mondjuk a QT könyvtárakat nem ismerem, nem tudom milyen plussz funkciókat tartalmaz... de lehet h jót tenne a linuxnak h mondjuk a grafikus programokat mono-ra átírnák. Poén lenne ha a köv MS Office simán menne linux alatt. :)
ui.: A c++ fájlkezelés sokkal lassabb mint a sima c alatt. Lemértem. (amikor még adatbázis motort akartam írni. 1 év fejlesztés után rájöttem h k sok munka... inkább hazsnálom a meglévőket.)
Személy szerint a héj-programozást hiányolom! Grafikai alkalmazásokon kívül nagyon ügyesen meg lehet egy kég shell-scriptel oldani mindent. (Holott a "grafikát" sokszor generáltam már úgy, hogy shell-script írt html-t :) )
[quote:355fa2c7e3="maszili"]Nem logikusabb olyan kódot írni ami jól működik? Mert akkor nem szükséges a futásidőben történő erőforáspocsékló hibajavításokkal terhelni a rendszert...
Logikusnak biztosan logikus, de jelenleg még emberek kódolnak, nem logikai automaták. C és C++ memory leak tekintetében jóval veszélyesebb műfaj, mint a Java. Egy JVM-ben elvileg csak egy elszabadult thread miatt lehetnek memory leak-jeid (vagy mondjuk akkor ha ugy programozol JDBC-t, hogy nem olvastal utana annak, hogy mit is csinalsz es elfelejted close-olni a statementedet meg a tobbit), hiszen a garbage collection garantalja neked, hogy az olyan objektumok amikre nem hivatkozik elo thread objektumbol elerheto uton masik objektum, azok periodikusan fel fognak szabadulni valamelyik gc utemben. Amit Java-ban elveszitesz C++-hoz kepest az a stack-en letrehozott objektumok lehetosege.
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
Nevetségesnek ezt a szemléletet tartom, és csodálkozom, hogy az életből még nem vetted észre, hogy ez butaság. Egy bankot nem az fogja érdekelni, hogy na jó, venni kell még +X gépet, azért, hogy gyorsabb legyen a cucc. Az fogja érdekelni, hogy mennyire stabil a program, milyen gyorsan van kész, tudja-e kifogástalanul azokat a feature-öket, amiket kért.
Te verheted a melled, hogy kézzel csinálod a memória-menedzsmentet, de ezzel max. a 20e forintos c/c++ könyvelőprogramodat tudod majd reklámozni, hogy szerezz plussz 1-2 vevőt.
Nyilván megvan a területe a c/c++-nak is, de emiatt sz@rozni a java programokat - ehhez nagy pofa kell. Kb annyi, mint amit a 20e forintos példával írtam.
Van egy feladat, meg kell oldani. Lehet hozzá ezt is, azt is használni. Van, ahol a java lesz a jobb megoldás.
Nem tudom, hogy te milyen alapon szemelyeskedsz, de ha mar megszolittattam, akkor valaszolok:
1. ne irjal f@szsagokat, kulonosen ne ugy, hogy azt ugy allitod be, hogy en irtam
2. a baromsagaidbol ne vonjal le a szemelymre vonatkozo kovetkezteteseket
Konkretan:
1. az elet != bank, igy aztan a szuklatokoruseg nem ereny
2. sehol nem allitottam, hogy kezzel csinalom a memoria managementet (bar tortenetesen minden olyan nyelvebn, ahol erre szukseg van, ott igen)
3. egy program nem a GC-tol lesz stabil
4. eletemben nem irtam konyveloprogramot
5. nem szaroztam a javat, mindemellett nem vagyok rola egyertelmuen jo velemennyel, de emlekeim szerint az en postjaimban a java szoba sem kerult
A hozzaszolasomhoz nehezen kapcsolhato, minden szakami alapot nelkulozo, durva szemelyes tamadast a kovetkezokben mar nem fogom ennyire baratsagosna kezelni.
[quote:e150dbde09="Csab"]Valaki fel tudna világosítani, hogy miért van szükség GC-re?
Minden objektumnak van egy referenciája.
Amikor ez a referencia nullára csökken, azaz senki nem használja, meghívjuk a destruktort és fölszabadítjuk az objektumot.
:D
Igen. Miert van szukseg programozasi nyelvekre. Megirjuk a programot gepi kodban aztan fut a gepen....
Amirol te nagyvonaluan megfeledkeztel az az, hogy hol taroljuk azt a bizonyos "referenciat"? Pl. a GC-nek ez az egyik legfontosabb feladata, hogy nyilvantartsa a hivatkozasokat az objektumokra.
Amit felvazoltal, alapjaiban igaz, de vannak vele problemak. Es ez a kenyes resze a GC-nek.
- Problema1: Mikor szabaditsuk fel a memoriat? Rogton azutan, hogy eldobjuk az objektumot, vagy varjunk vele, hatha lehet okosabban is csinalni. Elarulom lehet okosabban is csinalni...
- Problema2: A te bombamegoldasod semmit nem tud kezdeni azzal, ha a konkret peldanyok korbehivatkozzak egymast. Merugye az objektumok hivatkozasi grafjaban nem azt a peldanyt lehet eldobni, amire nincs referencia, hanem azt, ami nem erheto el a root objectekbol. Ez kicsivel osszetettebb kerdes...
Na ezert kell GC.
A Java procirol csak annyit, hogy nem jarsz jobban akkor sem ha a JVM-et letolod a szilicium szintjere. Osszetett aramkoroket igenyel egy bonyolult utasitaskeszlet megvalositasa. Az eredmeny altalaban az, hogy csak alacsony orajelen kepes futni a proci.
[quote:002a007d3b="ssikiss"][quote:002a007d3b="hanischz"]Igazából az az igazi előnye a javának h nem kell mindenféle platformra átültetni és átírni a progidat. Én sokat szívtam h Win98 alatt máshogy működött a C++ progik mint a NT alatt!
Pl 32000 pixelnél nagyobb (szélességű, magasságú) képet NEM tudsz létrehozni Win 98 alatt.
Másik szívás Visual Studio (200x verziójú), fájlmegnyitó ablakot, ami tökéletesen futott XP alatt. DE, Win98 alatt meg sem jelent! Hát én nem akarok ilyenekkel szívni.
Operációs rendszerek közti különbségekbe ütköztél, ez nem a C++ hibája. Ha valami egységes elemkészletet használtál volna, amelyik win98 és nt alatt is megy, vagy utánanézel, hogy az általad használt operációs rendszer specifikus elemek a korábbi verziókban is benne voltak-e, akkor ez nem fordult volna elő. C++-ban is lehet (majdnem) platformfüggetlenül programozni, ha akarsz. :)
A C++ "hibája" az h nem elég platformfüggetlen. Azaz inkább a tudása megkopott. Nem tud Bitmap-at kezelni, vagy szálakat egységesen pl. Mikor megcsinálták az api-t akkor még nem kellett ilyen sok mindent tudni mint manapság.
Kellett egy új, a mai elvárásoknak megfelelő api és ezt csak egy újratervezett környezettel lehet megoldani.
Különben nagyon sok specifikus dolgot kell bele tenni.
[quote:aad6ee61e6="dacas"][quote:aad6ee61e6="hop1"]És kimaradt a pascal :(
Én is hiányoltam, pedig annak is van free megvalósítása. Így az assembly-re szavaztam.
En is igy tettem, bar en meg kulon kertem is a Pascalt (meg tavaly is), de latom magasrol le vagyunk szarva. A tema feletti okoskodasrol csak annyit, hogy meg jo, hogy miutan az ember nyilt forrasu Pascal forditot fejleszt a szabadidejeben, 2-3 fele processzorra (esetemben pl. 68k, x86, powerpc) meg vagy 4-5 fele OS-re, jon valaki okostojas, es kozli h. szerencse h. kimaradt a Pascal, es persze nem mulasztja el bepastelni a hatulgombolosozos dumat. De hat ez mar nem engem minosit.
Udv,
Chain-Q (A Free Pascal Compiler csapat tagja)
Ps: Egyebkent ha mar az assemblynel tartunk, akkor nagyon nem mindegy, hogy x86, powerpc, vagy milyen assembly ugye. :) Ilyen alapon a C meg a Pascal is ugyanaz a nyelv, mert hasonlo kategoriaba esnek. :P
[quote:3eddc4ab53="Frimen"][quote:3eddc4ab53="feledhetetlen"]Kedves frimen:
a legeslegelso amit a a swingrol tudni kell:
CSAK CSAK CSAK a swing thread-rol vegezz swing muvelteket
vagyis aki a main thread-bol csinal setVisible vagy akarmi mas muveletet az magara vessen...
a java helyett pedig nincsen mas:
ezt be kell latni
az idezett kod hibas, csak okulasul legyen itt...
Talán ha el is magyaráznád, és meg is mutatnád Te hogy csinálnád elfogadnám.. igy okoskodás.
Szóval?
Fri
[quote:ce40a84cad="syntern"][quote:ce40a84cad="ssikiss"]Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
Hát, az én elképzeléseimben a dll egy bináris, amin belül lehet bármi, és ha nekem nem mondják meg, hogy mi van benne, meggebedhetek, akkor sem fogom tudni kitalálni a belső osztályszerkezetet, amennyiben véletlen C++-ról fordult az a dll, és nem pl. C-ről. Ennek ellenkezőjéről egy példával már meg is lehet győzni :)
Csatlakoznek +
Udvos lenne, ha neha forrassal is szemleltetnek a ezeket a "C++ is megvan" dolgokat az ahhoz ertok.
Olyasmivel ami minden rpm-aptget-portege-install-library-magic nelkul is lefordul mondjuk "gcc tutti.cxx" modon.
Peldaul a fent emlitett reflection..
csak azert mert ugye a nyelvrol beszelunk, es nem arrol, hogy "melyik nyelvhez van a legtobb library hozzatakolva"
[quote:6d5caebb96="bocs"]
Sok helyen hasznos lehet, de van ahol nem jó választás. A c++ -al viszont nehéz befürödni, csak nagyon ritkán derül ki a projekt végén, hogy mégsem ezzel kellett volna.
Egyébként a Prologra ugyanaz vonatkozik, mint a Java-ra: mindenki használja nyugodtan, csak az ellen a beteges szemlélet ellen fújok, hogy "Java-n kívül más nyelv nincs", amint az explicite itt el is hangzott a fórumon.
Szerintem alapvetően egyetértünk, beleértve, hogy ugyanez igaz a C++-ra is. Vannak dolgok, amiket nem C++-ban hatékonyabb megcsinálni, hanem Javában, Prologban, vagy másban.
Lehet, hogy rosszul látom, de a hozzászólások között alapvetően inkább a C++ pártiak részéről jött elő, hogy a "C++ az isten", a Java pedig csökevény. Fordított szerintem nem nagyon volt.
A Java pártiak megpróbáltak bizonyos tévhiteket eloszlatni, illetve kidomborítani olyan Java tulajdonságokat, amik könnyebben kezelhetővé teszik a Javát a C++-szal szemben bizonyos esetekben, hogy a C++ pártiak belássák: bizony van létjogosultsága a Javának illetve a benne megfogalmazott elveknek.
Ha annyira jó lenne a C++, mint ahogyan itt többen is állítják, valószínűleg nem terjedt volna el annyira és olyan területekre a Java (lásd EE, ami elég messze van az applettől, aminek kezdeti népszerűségét köszönheti), mint ahol most van, ezenkívül valószínűleg a Microsoft sem jött volna elő hasonló elvekkel leváltani a C++-t (és ne hozzátok elő, hogy C#-ban bezzeg van operator overloading, mert ez részletkérdés).
Nyilván kiderült, hogy én is Java párti vagyok, az ok eléggé egyszerű: amiket csinálok, ahhoz teljesen megfelel a Java, ha nem Java lenne, akkor 3 másik platformot/környezetet kellene ismernem, és közel sem biztos, hogy jobb sülne ki belőle, ráadásul az energiát 3 platform/környezet megismerésére kellene fordítani, ami nyilván nem annyira hatékony. Ezenkívül bizonyos szintig hordozhatóságra is szükségem van, amit a Java teljes kényelemmel nyújt az általam igényelt esetekben.
Na aki az assembly-t X-elte be mint kedvenc, es erdekelne melo a kozeli/tavoli jovoben az dobjon egy mailt arpi kukac mplayerhq.hu
(x86+mmx, ppc vagy arm kod iras, optimalizalas)
OO ugyben az a helyzet, hogy a C++ kiveri a biztositekot very1st OO szabalynal: minden objektum
a tobbi mar nem is erdekes...
persze be lehet tartani a szabalyokat C++ban is, sot Cben is, akar el is lehet nevezni egy ilyen szabalyrendszert ObjectiveC-nek, de az attol meg patkolas
egy makro preprocessor-bol (aminek a C++ keszult) nem lesz jobb nyelv
Csakis egy JLS szintu alapra lehet varat epiteni http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
[quote:0f9176f81e="maszili"]
Vegyük azt a példát amikor egy függvény egy változó tartalmával végez műveleteket. Ha érték szerint megy az átadás akkor a függvénynek van egy saját példánya amit nyugodtan megváltoztathat a munkája során anélkül hogy az eredetit elrontaná... De a programozó megteheti hogy a változó értéke helyett egy mutatót ad át... a programozó DÖNT!
sajnos az alapertelmezes szerint erteket ad at, pedig imho az a ritkabb
szoval ha a programozo az alapesetet koveti, altalaban rosszul dont...
[quote:54fccd0193="syntern"]:) Ez jó. Meg tudod oldani azt C++-ban, hogy egy feldarabolt memóriaterületet összenyomj, hogy a sok kis memória összesen egy nagyot tegyen ki? Persze, elméletileg megoldható lehet (pedig nem, lásd: nem befolyásolt forrásból származó kód), a Java meg is oldja.
nem tudom, ez nálad valami fixa idea lehet, hogy a c++ malloc az nem képes a felszabadított blokkok utólagos egyesítésére.
Természetesen, mivel ez c++, saját new handlert is írhatsz, ami saját különbejáratú algoritmus alapján kezeli a heap-et... ugye ez c++, ahol a nyelv feltételezi, hogy a programozó tudja, mit is akar ;)
[quote:20610057c3="syntern"]Volt itt aki UML modellezőt keresett. Nekem a MagicDraw nevű eszköz nagyon bejött, próbáld ki. Nem azért, mert versenyez bármilyen csilivilli és megszokott alkalmazáshoz, hanem mert minden Java platform alatt ugyanúgy néz ki (Swing) és a Swing ellenére is meg tudták írni gyorsra, elegánsra.
Nem olvastam vegig, mert sok az oldal, es keves az ido, de en UML modellezesre Umbrello-t hasznalok, es tetszik. Vannak dolgok, amik mas, penzes rendszerekben jobbak, de ez eddig a legjobb, amit lattam, es ingyenes. Ja, ez QT, nem swing.
Beolvasni azt hiszem, csak C++-t tud, Java bean-eket szerintem nem.
Visszairni se csak ugy, csak kodot generalni tud.
Nekem manapsag nincs idom sokat szopni kodolassal, igy pythont hasznalok, ezert java-val egyuttmukodesrol nem tudok reszleteket.
Megnéztem.. mégsem az volt a hiba ezek szerint, hogy nem main-ba
tettem be a setVisible-t? Mert utolag megnézve, tény azt rossz helyre tettem,
bár meg van ennek is az oka.
Átnezve a kodot.. látom a különbséget, sőt létrehoztam egy osztály-t a 4.1-es netbeans-el majd a 3.6-ossal:
- 4.1
public static void main(String args[]) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new proba().setVisible(true);
}
});
}
- 3.6
public static void main(String args[]) {
new Proba().show();
}
Erre meg én azt mondom bocs, b*ssz* meg a sun a java-jat!
Fri
[quote:f2c7498fcb="hanischz"]
Régebben Builderben írtam a progikat (amiket eladtam). Nagyon jó kis API-t hoztak létre. Késöbb áttértem a visual C-re,
Itt adsz saját magad magyarázatot a problémára. Builder és visual C. Mind a kettő saját függvény / osztály könyvtárat készített valószínüleg úgy hogy nem egyeztették egymással (bárkivel) hogy ki mit és hogyan valósít meg. Ebből következik hogy inkompatibilisek egymással (mindenkivel) és megkérdőjeleződik a hordozhatóság is.
Visszatérve a GC-re felmerült bennem egy kérdés.
Korábban azt írta valaki hogy a GC csak akkor lép működésbe ha elfogy a memória. Ha ez így van akkor a GC működése miatt a java-vm minden más programot kiszorít a memóriából, fölöslegesen pazarolva az erőforrásokat? Pusztán azért hogy a programozó élhessen azzal a "kényelemmel", hogy összedobálhatja a kódot, nemtörődve az erőforrások kezelésével?
[quote:e7fbdbbb6a="Csab"]Persze a java-nak egyre több konkurense lesz. A mobiltelefonos iparban a Macromedia Flash, Python, PHP,... még szóbajöhet, mint alternatíva. Gyorsabb és olcsóbb megoldások.
A Flashnél nagyobb vendor lock-int csak a Microsoft produkál. Ha valaki nézte már a Flash bináris specifikációt, az szerintem hamar belátja. Egyszerűen nincs értelmes eszköz, amivel el lehet kezdeni foglalkozni vele. Úgy indítod, hogy 7-es verzió alatt nincs Unicode kezelés, azaz ha normális alkalmazást akarsz írni, akkor a régebbi eszközök kiesnek. Az egyetlen használható az OpenLaszlo, de a Macromedia Flexhez képest csak gyerekjáték (igaz nem is kerül 10.000$/2CPU-ba :) ). Nagyon látványosak a demói, cserébe nagyon nehéz kezdeni vele valamit.
A többit nem nevezném alternatívának, valahogy nem egy pályán mozognak.
[quote:2a349f22c9="syntern"][quote:2a349f22c9="ssikiss"]Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
Hát, az én elképzeléseimben a dll egy bináris, amin belül lehet bármi, és ha nekem nem mondják meg, hogy mi van benne, meggebedhetek, akkor sem fogom tudni kitalálni a belső osztályszerkezetet, amennyiben véletlen C++-ról fordult az a dll, és nem pl. C-ről. Ennek ellenkezőjéről egy példával már meg is lehet győzni :)
Ez teljesen így van, csak mifelénk szokás mellé egy-két header-t meg interfész libet, meg doksit is adni, ha azt akarod, hogy tudjanak vele fejleszteni. :D
Jávában is illik doksit adni nem (sokra mész a jarban látható osztályszerkezettel)?
[quote:a5d434fe1c="_Joel"]C és C++ memory leak tekintetében jóval veszélyesebb műfaj, mint a Java.
Ezzel egyetértek... a c/c++ nem próbál a programozó helyett gondolkodni. A programozóé a felelőség hogy miként oldja meg a problémát.
De ad eszközöket arra hogy jól működő kódot írjon a programozó. Elég ha csak arra gondolunk hogy egy osztálynak vannak konstruktorai, destruktorai. Ott a programozó saját maga elintézheti az erőforrások (ami bármi lehet) lefoglalását, felszabadítását.
Tehát ha a programozó használja a c++ által nyújtott eszközöket akkor szerintem fölösleges egy külső alkalmazás használata ami azt figyeli hogy milyen memória területet nem használ már senki... amit aztán felszabadíthat.
És mi a helyzet az egyéb erőforrásokkal? Amik nem egy lefoglalt memóriaterületet jelentenek hanem valami mást? Arra hogy működik a JAVA hibajavítása?
[quote:a5d434fe1c="_Joel"]
A GC nem hibajavitas, hanem memoriamenedzsment.
Direkt hibajavítást írtam mert továbbra is fenntartom azt a véleményemet, hogy a nem kívánt memóriahasználat megszüntetését végző program egy hibajavító program.
[quote:f551fe4916="ssikiss"][quote:f551fe4916="feledhetetlen"]inkabb ez: erted-e az alapokat, vagy se
aki tudja erre az egyszeru kerdesre a valaszt az erti
aki nem, az csak dumal
Na most akkor lassan már elárulhatnátok, hogy mit kell azon az egy soron látni, hogy más is okuljon a java "szépségeiből".
:?:
El kell ismerni, hogy ez az egyszeru, trivialisan szep pelda tenyleg alaposan megizzaszthatja a C++-t hasznalo, a Javat feluletesen ismero embereket :). Hozzunk egy alternativat, hogy ne csak a Java-ra fujjatok, itt a .NET-es analogiaja:
lock (this) { }
Tenyleg csak azon mulik, hogy valodi OO szemlelet van, vagy csak szintaktikailag kezeled az OO-t....
"Java-n kívül más nyelv nincs", amint az explicite itt el is hangzott a fórumon.
Hányadik hozzászólásban volt ez?
en biztos irtam ilyet, mert amugy igy gondolom :)
kicsit olyan ez mint a szergej esete a lampagyarban:
szergej a zsebeben lopkodta az alkatreszeket a lampagyarbol
de sohasem lett lampaja, mert mindig geppisztoly lett belole mire osszerakta
analogous:
ha egy olyan nyelvet akar valaki osszerakni ami tudja az activation-t
annak olyan darabjai leszenek mint a java darabjai
ha sikerul osszerakni java lesz, akkor is ha masnak nevezik
a lenyeg az, hogy a top level kontrol, a barmilyen nyelven megirt komponensek vezerlese, ma java-ban a legegyszerubb
es nemcsak sebesseg miatt nem erdemes mindent javaban irni,
inkabb azert mert sokminden mar meg van irva, tesztelt, mukodik...
Filozófiailag mitől kedvenc egy programnyelv ?
1. emlékek, tanulmányok, első sikerek otthon éjjel vörös szemmel ? :-D
2. olcsó ? (mármint bene fejleszteni, bár a legtöbbhöz elég egy texteditor, de akkor is debugolni,tesztelni azért már lehet drágább is)
3. hatékony ? (fejlesztési időben,futási időben,modularitásban,stb)
4. olvasható = könnyen tanulható ?
5. ismert (elakadok, találok a "házban" havert, aki tud segíteni)
6. "platform független" már ha létezhet ilyen... nem kell újralinkelni,fordítani, stb
[quote:b340e2a21f="gee"]Nem olvastam vegig, mert sok az oldal, es keves az ido, de en UML modellezesre Umbrello-t hasznalok, es tetszik. Vannak dolgok, amik mas, penzes rendszerekben jobbak, de ez eddig a legjobb, amit lattam, es ingyenes. Ja, ez QT, nem swing.
MagicDrawnak van community edition változata, amikor utoljára néztem tudott mindent, amit úgy általában az ingyenes eszközök tudtak. Ez mondjuk régebben (= másfél éve) volt, azóta nem követtem a fejlődést.
Megmondom őszintén, hogy nem olvastam végig a fórumot, de néhány téma a Java/C#/Php/C kapcsán megragadott. Nem akarom ragozni a különböző funkcionalitást, ilyen-olyan vallási vitákat, csak azt írom le, amit az egyik hallgatóm kimért több gépen is:
A Java teljesítménye (-server kapcsoló) a legtöbb esetben megközelíti ugyanazt a kódot megvalósító C++ programot a Hotspotnak köszönhetően, valamint az erősen rekurzív esetekben jócskán meg is előzi. (5-ös Java, gcc, -O1, 2, 3-mal is mérve, a -O3 már majdnem olyan jól teljesített mint a Java) A mérések kizárólag memória-kezelést és algoritmus végrehajtást mértek, ugyanaz a C++ kód és Java kód futott, feladatonkénti mérési idő 30-45 mp, hogy ne legyen nagy hiba az óra pontatlanságából. Sok esetben gyanítjuk, hogy a Hotspot optimalizálása alig kezdett el működni.
Ezek után ha valaki azt mondja, hogy neki a PHP gyorsabb mint a Java, nem hiszem el :), valamint azt sem fogadom el, hogy mindig megéri C++-t erőltetni és a Java-t lassúnak titulálni. Aztán ezekhez már csak hozzá kell tenni az eszközöket, a kész és elérhető libraryket, a J2EE-ről nem is beszélve, és magyarázni sem érdemes tovább, miért jó a Java :)
[quote:b1866488e6="gee"][quote:b1866488e6="syntern"]Volt itt aki UML modellezőt keresett. Nekem a MagicDraw nevű eszköz nagyon bejött, próbáld ki. Nem azért, mert versenyez bármilyen csilivilli és megszokott alkalmazáshoz, hanem mert minden Java platform alatt ugyanúgy néz ki (Swing) és a Swing ellenére is meg tudták írni gyorsra, elegánsra.
Nem olvastam vegig, mert sok az oldal, es keves az ido, de en UML modellezesre Umbrello-t hasznalok, es tetszik. Vannak dolgok, amik mas, penzes rendszerekben jobbak, de ez eddig a legjobb, amit lattam, es ingyenes. Ja, ez QT, nem swing.
Beolvasni azt hiszem, csak C++-t tud, Java bean-eket szerintem nem.
Visszairni se csak ugy, csak kodot generalni tud.
Nekem manapsag nincs idom sokat szopni kodolassal, igy pythont hasznalok, ezert java-val egyuttmukodesrol nem tudok reszleteket.
Ugy alapjaban veve tetszett volna, de nekem Windowsos valtozat is kellene.
A visszairas, kodgeneralas nem kell, csak tudjak diagramot rajzolni, menteni, nyomtatni. Nem vagyok az a fajta, aki UML diagram nelkul mar a billentyuzetet sem tudja megtalalni. Na offtopic over...
[quote:0d5924af6b="Frimen"]
Ha Neked szabad kezed van és a másiknak is.. de még ha meg is álapodtok észerű elvekben, akkor is lepipálja a java-s programodat egy c-ben megirt.:)
Bevallom ennyire fanatikussal még nem találkoztam mint Te vagy.:))
Nna, akkor eljutottunk arra a pontra, amit megceloztunk a meressel: irj egy QuickSort programot C-ben, en is irok egyet javaban. Adjuk oda nekik ugyanazt az adathalmazt es merjuk meg a sebesseget, ki pipal le kit. Segitsegul megirtuk elore a QuickSort programot C-ben es Javaban egyarant, sorrol sorra ugyanaz, es je, a Java gyorsabb. Lehet hogy fanatizmus, de engem ez meggyozott arrol, hogy az "akkor is lepipalja" nem mindig all fenn, ha tetszik, ha nem.
[quote:0d5924af6b="Frimen"]Tyja.. ha a gyorsaság a fontos.. érdekes modón még mindig sokan használnak 1.4-es javat, föleg kritikus környezetben.. szeirnted ez véletlen?
Szerintem ez marketing hiba :), valamint elsosorban azert hasznalnak 1.4-et (ertsd azert nem cserelik le akkor sem, ha le tudnak), mert az XY appserver 1.4-re van certifikalva, es nincs az a donteshozo, aki el meri vesziteni a licenct egy ilyen csere miatt.
[quote:7c50044192="maszili"]
Korábban azt írta valaki hogy a GC csak akkor lép működésbe ha elfogy a memória. Ha ez így van akkor a GC működése miatt a java-vm minden más programot kiszorít a memóriából, fölöslegesen pazarolva az erőforrásokat? Pusztán azért hogy a programozó élhessen azzal a "kényelemmel", hogy összedobálhatja a kódot, nemtörődve az erőforrások kezelésével?
Ezért van -Xms és -Xmx opció. -client jvm alapból max 64MB heap-et allokál, ezt lehet -Xmx-szel emelni nagyobbra.
Amúgy meg GC-ileg öntsünk tiszta vizet a pohárba, mert látom linkeket senki nem olvas. Java-ban ugyanis generációnkénti GC van, ami azt jelenti, hogy másként keressük a szemetet a friss és a régebben létrejött objektumok között.
Java-ban a heap-et a memory management feloszti több szeletre. Van a young generation, a tenured generation es a permanent generation. Young-ban vannak a frissen letrehozott objektumok, tenured-ben a tulelo (hosszabb eletciklusu) objektumok, a permanent-ben pedig a class-ok, metodusok metaadatait reprezentalo objektumok elnek (ezzel nem nagyon kell foglalkozni).
Amikor a young generation tele lesz, akkor minor szemetgyujtes tortenik, ami eleg gyors. Egyreszt azert, mert a young generation merete toredeke az osszes felhasznalt memorianak, masreszt az algoritmus arra optimalizal, hogy keves a tulelok szama (sok a holt objektum). Ez altalaban statisztikailag igazolhato is. Minor szemetgyujtes eseten nehany tulelo objektumot atpakol a JVM a tenured generacioba (ez is befolyasolhato)
Ha a tenured generacio telik be, akkor ott tortenik egy teljes (major) szemetgyujtes, ami viszont joval lassabb (akar tizedmasorperces megallast is okozhat a JVM-ben). Adott tehat a feladat: ugy meretezni a young es a tenured generation-t, hogy minel kevesebb major collection kovetkezzen be. Errol lehet jokat olvasni itt:
[quote:0e758c4767="maszili"] A programozóé a felelőség hogy miként oldja meg a problémát.
A project manageré meg az a felelősség, hogy a projekt megadott időre, a megrendelő igényei szerint, minél kevesebb hibával kész legyen. Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
De ad eszközöket arra hogy jól működő kódot írjon a programozó. Elég ha csak arra gondolunk hogy egy osztálynak vannak konstruktorai, destruktorai. Ott a programozó saját maga elintézheti az erőforrások (ami bármi lehet) lefoglalását, felszabadítását.
A programozó ugyanúgy el is felejtheti odatenni azt a dispose-t, vagy free()-t, mint ahogy gyakran el is felejti. Tudom, van rengeteg eszköz, amivel ezeket figyelni lehet és a jobb programozók használják is őket memory leak-ek felkutatására. Csak éppen emiatt ugyanannak az üzleti logikának a lekódolása 2x-3x annyi időbe kerül és 2x-3x annyi rizikóval járhat.
Tehát ha a programozó használja a c++ által nyújtott eszközöket akkor szerintem fölösleges egy külső alkalmazás használata ami azt figyeli hogy milyen memória területet nem használ már senki... amit aztán felszabadíthat.
Nem külső alkalmazás. Egy JVM-en belüli folyamat, amiről a programozónak nem is kell tudnia (persze ha jó programozó akkor ismeri és tudja, hogy mi a különbség a fiatal meg az öreg generáció között, tudja hogyan működik a mark & sweep algoritmus, mikor érdemes olyan paraméterrel indítani a JVM-et ami bekapcsolja a párhuzamos vagy a megállásmentes gc-t... stb stb stb).
Egyébként C++-hoz is vannak GC-t alkalmazó megoldások, smart pointerek. Ha olyan rossz ez az ötlet, akkor miért alkalmazzák mégis sokan?
Direkt hibajavítást írtam mert továbbra is fenntartom azt a véleményemet, hogy a nem kívánt memóriahasználat megszüntetését végző program egy hibajavító program.
[quote:2789de7771="_Joel"]
Ennek alapjan ez bugnak tunik. Van valami platformfuggo a kodban (pl SWT)?
[quote:2789de7771="_Joel"]
Az a baj, hogy olyan szinten amilyenen szeretnék, semmit. "Hivatalból" netbeans-szel játszom időnként újra és újra (including netbeans profiler), eclipse-t neha nezegetem de nem hasznalom. H meg veletlenul XML Schemat kell szerkeszteni akkor szerzek egy JDevelopert:) Sajnos egyre jobban tavolodom a fejlesztestol ebben a munkakorben, es ez nem tulsagosan tolt el sok eletorommel.
Nem semmi olyat nem használok a kódban..
Viszont megtaláltam a különbséget.. csak még.. nem értem.
Az van, hogy ha Netbeans-ből (4.1) futtatom az alkalmazást.. akkor jól müködik,
stabilan tartja a erőforrás felhasználást (profiler), látom is a OS-ben is, viszont
ha "normál" futtatom, akkor felzabálja a memóriát.
Vesszek meg ha értem..
Fri
[quote:d2863c6c3a="_Joel"][quote:d2863c6c3a="Frimen"]
Bevallom ennyire fanatikussal még nem találkoztam mint Te vagy.:))
Hmm, 2000 óta ismerem Syntern-t (bár azt hiszem abban a gólyatáborban nem voltam, amiben ő volt gólya - de már elsőévesként egyiket volt az InfoSite-ot összerakó srácoknak), de fanatikusnak nem nevezném. Bár ha azt nézzük, hogy az Automatizálási tanszéken Java-val foglalkozva doktoranduszkodik, J2EE labort és tárgyat tart... (syn, bocs hogy lebuktatlak)
Aki nem ismerne a tanszeket: amikor en szakiranyra mentem, akkor ezt a tanszeket mindenki MicroSoft tanszekkent emlegette :).
Mas: bevallom oszenten azota harapok ilyen erosen a Java teljesitmeny kerdesre, amiota kiderult, hogy egyik TDK-zo hallgatom valoszinuleg azert nem kapott elso dijat, csak masodikat, mert a biraloja es a szekcioelnoke is abban a kozel 10 evvel ezelotti allapotban elt, hogy a Java lassu. Szomoru egy ilyent atelni.
1. kitalálsz valamit
2. a JCP-n megpróbálod keresztülvinni
3. a JCP teljesen mást akar, egyezkedni kell konkurens cégekkel
4. a konkurens cégek hátráltatnak
5. sikerült szabványt létrehozni
6. kiadod a telefonodat
7. megveszik a vásárlók
Ez ugye 2 év legalább. A JCP késlelteti benne a legtöbbet. Pláne akkor, mikor a konkurens cégeknek még nincs kész terméke. Húzzák az időt. hogy neked se legyen...
Tudod, hogy 2 év alatt a Macromedia mennyit fejlődik?
Az örök kérdés az, hogy érdemes-e a JCP-vel szüttyögni, amikor jóval egyszerűbb megoldások is vannak, persze java nélkül.
[quote:9e987acea0="syntern"]El kell ismerni, hogy ez az egyszeru, trivialisan szep pelda tenyleg alaposan megizzaszthatja a C++-t hasznalo, a Javat feluletesen ismero embereket :). Hozzunk egy alternativat, hogy ne csak a Java-ra fujjatok, itt a .NET-es analogiaja:
lock (this) { }
Tenyleg csak azon mulik, hogy valodi OO szemlelet van, vagy csak szintaktikailag kezeled az OO-t....
Még mindíg arra lennék kíváncsi szájbarágósan, hogy mit csinál a fenti sor.
:?
[quote:6ec659d16f="syntern"]
Nna, akkor eljutottunk arra a pontra, amit megceloztunk a meressel: irj egy QuickSort programot C-ben, en is irok egyet javaban. Adjuk oda nekik ugyanazt az adathalmazt es merjuk meg a sebesseget, ki pipal le kit. Segitsegul megirtuk elore a QuickSort programot C-ben es Javaban egyarant, sorrol sorra ugyanaz, es je, a Java gyorsabb. Lehet hogy fanatizmus, de engem ez meggyozott arrol, hogy az "akkor is lepipalja" nem mindig all fenn, ha tetszik, ha nem.
Nem látom sehol a két kodot..:))
Én legalább beirtam a sajátom "üssetek agyon, ha.." alapon, de Te eddig csak a levegőbe beszéltél.
Amugy nekem már az a sorrol sorra ugyanaz enyhén szolva röhelyes..:-)
Szerintem van itt egy két C-s programozo, aki szivesen vetne pár pillantást arra a kodra.. én meg a java-s oldalára.
[quote:6ec659d16f="syntern"]
Szerintem ez marketing hiba :), valamint elsosorban azert hasznalnak 1.4-et (ertsd azert nem cserelik le akkor sem, ha le tudnak), mert az XY appserver 1.4-re van certifikalva, es nincs az a donteshozo, aki el meri vesziteni a licenct egy ilyen csere miatt.
Igenis meg nem is.
Én az előbb csodálkoztam rá, hogy ugymond a frame.setVisible már nem aktuális.. szálbol ajánlott inditani.. többektöl hallottam már és tapasztaltam is, hogy mekkorákat
szivtak a javaban azzal, hogy egy függvény elavult lesz, már "nem elég" jó.. vagy megváltozik ez meg az.. már én is bánom, hogy váltottam 1.5-ösre.. de azt is tudom egyszer ugyis váltani kellett volna.
Szerintem pár java verzió és a public static void main(String args[]) is deprecated lesz.:))
Fri
[quote:df1f5f763d="waiter"]Érdekes, hogy a PHP scripting language, mint "programozási nyelv" van jelen és az is érdekes, hogy most (2005. nov. 21. 0:20) vezet a többi konvencionális programozási nyelvhez képest...
IMHO, tekinthető a PHP programozási nyelvnek abból a szempontból, hogy algoritmusokat lehet vele leírni és ezeket (egy interpreteren keresztül) futtatni. Ugyanakkor az is igaz, hogy a PHP egy script nyelv és kizárólag a dinamikus webes tartalmak megjelenítéséhez fejlesztették, ennélfogva a programozói feladatoknak csak egy leszűkített halmaza oldható meg vele. Pl. C, C++ vagy Java nyelvekkel lehet készíteni interaktív és hardvereszközökkel is kommunikáló, GUI frontendet is és dinamikusan generált webes felületet is, de PHP-vel csak ez utóbbit.
Nem tudom, mi a "programozási nyelv" pontos definíciója, de IMHO egy programozási nyelvnek általános érvényű (és nem egy specializált) eszköznek kellene lennie, legyen szó bármilyen szoftverfejlesztési feladat megoldásáról.
- waiter -
Wikipediabol:
A programozási nyelv a számítástechnikában használt olyan, az ember által olvasható és értelmezhető utasítások sorozata, amivel közvetlenül, vagy közvetve (pl.: gépi kódra fordítás után) közölhetjük a számítógéppel egy adott feladat elvégzésének módját.
szamomra a nyelv szigoruan veve nem mas mint egy nyelvtan altal leirt szohalmaz(ezert nincs ertelme beszelni script nyelvrol, mert egyszeruen ilyen fogalom nem is letezhet). a programozasi nyelv szigoruan veve nem mas mint egy olyan nyelv, amivel hasonloan a fentihez, egy adott problema leirhato(igy belefer egy turing gep programja is), azaz meg szemantikaja is van.
[quote:cdbf8e8d8e="_Joel"]
Ezért van -Xms és -Xmx opció. -client jvm alapból max 64MB heap-et allokál, ezt lehet -Xmx-szel emelni nagyobbra.
Amúgy meg GC-ileg öntsünk tiszta vizet a pohárba, mert látom linkeket senki nem olvas. Java-ban ugyanis generációnkénti GC van, ami azt jelenti, hogy másként keressük a szemetet a friss és a régebben létrejött objektumok között.
Hát nekem ez akkor sem tetszik... :)
Szerintem egyszerűbb az osztály destruktorában felszabadítani az osztály objektuma által használt erőforrásokat. Ha ott megírtam a kódot (ami ugye egy rendes OO objektumhoz hozzátartozik mert hát én tudom hogy mit, mire és hogyan használok az osztályban) akkor elfelejthetem a problémát.
Így automatikusan felszabadul az összes felhasznált erőforrás pontosan akkor amikor megsemmisül az objektum.
Bár itt most a java és a c# nem túl jól szerepel, szerintem ezek a nyerők mind webes, mind desktop alkalmazások esetén.
- platformfüggetlen
- kevesebb hibalehetőség
- igazi objektumorientált nyelvek
- natív kód közeli sebesség
Összehasonlítottam a java-t többek között a php-vel is, de sebességben nagyságrendbeli a különbség. Persze tudom, nem minden a sebesség ...
Amit webes fronton szerintem elrontottak a java-val, az az, hogy egy applet futtatásához le kell töltsön az ember 15Mb-ot. Gondolom ezért terjed a flash, amit egyébként utálok.
Desktop oldalon meg a lassú indulást lehetne még felhozni hátrányként.
[quote:4f08aec4e9="Andrei"]Az egyik program, amivel dolgunk van az az ArchiCAD (epiteszeti tervezoszoftver). Ez az alkalmazas 6 millio sor C++ kod. Jocskan megizzadna a JVM, mire beizzit egy ilyen meretu cuccot. Es ha meg menne is akkor uj ertelmet nyernenek a Sun Fire 20-25k gepek, mert ez egy mezei workstationon nagyon hurka lenne.
A példa nagyon rossz. Először is a 6 millió sor C++ kód Java-ban írva valószínűleg jóval kevesebb lenne. Aztán más kérdés, hogy a teljes kód hány százaléka fut úgy általában és milyen kódrészletek azok, amelyek alig-alig kerülnek futásra. Vajon a gyakori kódrészleteket hogyan optimalizálta a C++ fordító? Tud-e olyan szintű paramétertől függő alternatív natív kódot, mint a Java HotSpot?
De visszatérve a beizzításra: most néztem, hogy az egyik projektünk közel 400.000 sor Java kód. A teljes alkalmazás, mellékelt jar fájlokkal együtt tömörítve 10MB (azaz tömörítve 10 MB csak a bájtkód). Vígan elfut nem csak a fejlesztői gépen, nem kell neki übergép.
Miért baj az, ha mondjuk az 1.5-ben thread safe lett az a fv, ami régen nem volt az, és ezért ajánlják, hogy használd a másikat? Ha Te ragaszkodsz a régi fv-hez, használhatod azt is, csak tudd, mik a hibái. Azokat a függvényeket nem kivették, hanem jobbakat adtak hozzá.
Az, hogy "ez meg az megváltozik": még arra is figyeltek Sunék, hogy az 1.5 foreach-e ne foreach legyen, hanem for, mert mi van, ha Frimen a kedvenc metódusát vagy változóját foreach-nek nevezte el, ne szúrjunk már ki vele, maradjon működőképes a programja...
Fejlődik a nyelv. Remélhetőleg javul. Tényleg nem értem, mi a bajod ezzel.
hat netbeans az netbeans errol nem tudok nyilatkozni, en vi-t hasznalok
de kiprobaltam:
http://javasite.bme.hu/~lazlo/src/no-leak.html
es
Linux hill 2.4.31 #8 Sun Jun 5 19:08:07 PDT 2005 i686
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
nem latok semmi lenyeges elterest a gc-ben akar
java apro.study.leak.Main
akar
java apro.study.leak.Main null
probalom
szivesen segitek, ha megmondod mi faj neked a gc mukodesben...
Megnéztem.. mégsem az volt a hiba ezek szerint, hogy nem main-ba
tettem be a setVisible-t? Mert utolag megnézve, tény azt rossz helyre tettem,
bár meg van ennek is az oka.
Átnezve a kodot.. látom a különbséget, sőt létrehoztam egy osztály-t a 4.1-es netbeans-el majd a 3.6-ossal:
- 4.1
public static void main(String args[]) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new proba().setVisible(true);
}
});
}
- 3.6
public static void main(String args[]) {
new Proba().show();
}
Erre meg én azt mondom bocs, b*ssz* meg a sun a java-jat!
Fri
[quote:9ff16fab08="maszili"]
Nyílvánvalóan a nyelv nem készülhet fel minden adatszerkezetre amit a programozó kitalálhat... de adhat eszközt arra hogy a programozó elkészítse a saját maga kitalált adatszerkezetén működő operátorokat. Ezzel elfedve a művelet során fellépő problémákat.
Ezek után nekem ne mondja senki hogy a java egy egyszerűbb, jobb, nagyobb kifejező erejű nyelv mint a c++ mert nem hiszem el... :)
Mint már írtam egyszer: szerintem rosszul közelíted meg a dolgot, mert javában nem tudsz *a-t írni, ezért ha az a = b-t felüldefiniálod a = b.clone() funkcionalitására, nem tudod miként megvalósítani a jelenlegi értelemben vett a = b műveletet, azaz hogy az a változó a b változó által mutatott objektumra mutasson.
Lehet, hogy csak megszokás, de az =-nek ez a funkcionalitása logikusan ábrázolt, és a clone() kitűnően kifejezi, hogy mélymásolást kell csinálni.
Nincs még 10 éves tapasztalat a hátam mögött, de az eddigi feladataim során minimális esetben találkoztam a clone() - azaz mélymásolás igényével. (nyilván ez adódhat a feladatok jellegéből is, de az OO szemléletnek a clone() kicsit mellékvágánya)
[quote:864fe40547="bitumen"]Személy szerint a héj-programozást hiányolom! Grafikai alkalmazásokon kívül nagyon ügyesen meg lehet egy kég shell-scriptel oldani mindent. (Holott a "grafikát" sokszor generáltam már úgy, hogy shell-script írt html-t :) )
azért majd egyszer próbálj meg egy komyolabb feladatot scriptből megoldani, esetleg vmi hálózati programozás, etc... :)
Én mindenesetre a java-nak drukkolok, de az egyáltalán nem biztos, hogy lesz java a jövő mobiltelefonjaiban.
Nyilván, ha a .net - nek sikerül a telefonpiacot megszereznie, akkor a java-nak kampec lesz. Ez ilyen egyszerű.
Bár nem ismerem a .net -et, de tartok attól, hogy képes lesz sok helyen átvenni a java szerepét.
Ha a szerverfarmot nézzük, a J2EE szerintem nem alternatíva a .net -tel szemben. Legalábbis a Sun referencia implementáció használhatatlan. Lehetetlen nyomkövetni és fejleszteni rajta. Akkor lássam legközelebb, amikor a hátam közepét...
Persze mesélik, hogy a IBM Websphere és a Bea Weblogic már nem olyan összecsapott munka, de nekem sajnos a Sun-ost kellett használnom. A JBoss-t sem próbáltam.
A java helyzete nem túl rózsás. Több konkurense is van.
[quote:bf53a92aa1="Csab"]
Jegyezzük meg: egy C++ progit lefordítasz, azonos platformon jó eséllyel menni fog. Ez java-ra nem igaz. Ha nincs java telepítve, megszívtad.
Ez nagyjából így is van, de az teljességhez az is hozzátartozik, hogy egyrészt egyre több gépen van már Java, másrészt ha pl valamilyen ügyviteli alkalmazást fejlesztesz, akkor tudod mely gépeken fog futni, ezen gépek valami központi kezelés felügyelete alatt állnak, és az esetek nagy részében simán megoldható a futtató környezet telepítése.
[quote:bf53a92aa1="Csab"]
Ha 5-ös java-t fordítasz és kihasználod az új API-t, az nagy valószínűséggel nem fog menni 1.4.2 és korábbi java-kon. Rengeteg szívás volt amiatt, hogy ahol a programot futtatták régebbi java volt.
Ne haragudj, de ebből a hozzáállásból nem tűnik ki a sok-sok éves tapasztalatod: ha viszonylag adott, hogy kik fogják használni, egy JRE frissítés általában megoldható, másrészt, ami sokkal fontosabb: mielőtt bármit csinál az ember, fel kell mérni, hogy a futtatáshoz szükséges feltételek biztosíthatóak-e. Enélkül nemhogy egy sort nem szabad leírni, de még a tervezéssel is óvatosan kell bánni.
(ha ilyen alapvető felmérést sem végeztetek, hogy milyen JRE, akkor mázlitok van, hogy "csak" ebbe futottatok bele)
Olvasgatom itt a hozzászólásokat és egy tipikus jelenségnek a megtestesítője vagy: villamosmérnök vagy, akinek tetszett az informatika, de leginkább csak hobbiszerűen űzi. Értem hobbiszerűen azt, hogy a BME VIK-en nem hiába van informatika szak, az informatikai tudományok elég kemény elméleti háttere van, amivel bizonyos kérdésekben történő állásfoglaláshoz nem árt tisztában lenni. És nem elég az, hogy nekiállsz írni egy programot valamilyen platformon és egy adott idő alatt valamekkora jártasságot szerezni.
Nem azt mondom, hogy villamosmérnökből nem lehet jó informatikus, csak azt, hogy a programozni tanulás önmagában nem ad elég elméleti hátteret - legalábbis bizonyos kérdések megválaszolásához nem.
Sajnos a BME TDK-kon is nagyon látszik az, mikor egy villamosmérnök hallgató informatikai témába vág bele. Ezen esetekben leginkább a konzulenseket nem értem egyébként.
Ne érts félre, nem akarlak megsérteni, senkit nem akarok megbántani, biztosan írtál remek programokat, csak nem árt, ha az ember tudja, hogy meddig terjed a kompetenciája.
[quote:066108907c="ParadoxH"]mi a személyes tapasztalatotok a pythonnal kapcsolatban? :roll:
- könnyen tanulható
- rengeteg modul van hozzá
- platform,- és architektura-független
- relatíve gyors (pl. a shell scriptekhez képest sokkal gyorsabb)
- nagyon jó C API-ja van
- az indentálások nagyon megkönnyítik a kód olvashatóságát
- az utasítások egyértelműek (hahhó Perl! :))
Security azért nincs C-ben, mert nincs rá szükség. A processzeket az operációs rendszer kézbentartja.
Ugyanez java alkalmazások esetén is megy, hogyha különböző JVM-ekben futnak. Ez viszont túl nagy ár a Security-ért. Eszméletlenül sok memóriát igényel párhuzamosan futtatni 5-6 JVM-et. A JVM-ek közti kommunikáció, objektumok átadása sem túl kecsegtető.
Éppen ezért találták ki a java-s security-t. Ez egy jó ötlet volt, csak pocsék megvalósítás mellett. Mindegy. Ez van, ezt kell szeretni, vagy elviselni.
[quote:a8a0128f39="_Joel"] Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
Mi az oka?
Szerinted nem jó program nyelv a C++?
Te miben fejlesztesz üzleti alkalmazást?
Én láttam pölö perl-ben írt működéstámogató rendszert és működött,
bár lassan.
Miért lenne az jobb, mint ha C++ ban írták volna?
Mi a baj azzal, hogy a programozónak a dolga a new() és a delete()?
Miért baj az, ha bizonyos dolgokra emlékeznie kell a programozónak?
[quote:0980153217="Csab"]
Ha a szerverfarmot nézzük, a J2EE szerintem nem alternatíva a .net -tel szemben. Legalábbis a Sun referencia implementáció használhatatlan. Lehetetlen nyomkövetni és fejleszteni rajta. Akkor lássam legközelebb, amikor a hátam közepét...
Erre gondolsz?
glassfish.dev.java.net
Amit leirsz, az kb 2-3 evvel ezelotti allapot. Akkor az RI tenyleg az volt, amit leirsz.
[quote:129588d0c7="syntern"][quote:129588d0c7="ssikiss"][quote:129588d0c7="feledhetetlen"]inkabb ez: erted-e az alapokat, vagy se
aki tudja erre az egyszeru kerdesre a valaszt az erti
aki nem, az csak dumal
Na most akkor lassan már elárulhatnátok, hogy mit kell azon az egy soron látni, hogy más is okuljon a java "szépségeiből".
:?:
El kell ismerni, hogy ez az egyszeru, trivialisan szep pelda tenyleg alaposan megizzaszthatja a C++-t hasznalo, a Javat feluletesen ismero embereket :). Hozzunk egy alternativat, hogy ne csak a Java-ra fujjatok, itt a .NET-es analogiaja:
lock (this) { }
Tenyleg csak azon mulik, hogy valodi OO szemlelet van, vagy csak szintaktikailag kezeled az OO-t....
A: Bibibi! Én tudom, hogy mit jelent a synchronize(this) {}
B: Az mind semmi! Én már használtam is!
A: Az is valami? Én javasoltam a SUN-nak, mikor megalkották a java-t!
B: Nekem öcsém? Nem hiszem! A java-t én találtam ki egyedüll!
.
.
.
[quote:a173d059bb="Panther"][quote:a173d059bb="Chain-Q"]jon valaki okostojas, es kozli h. szerencse h. kimaradt a Pascal, es persze nem mulasztja el bepastelni a hatulgombolosozos dumat. De hat ez mar nem engem minosit.
Sajnos téged minősít. "szerencsére" - ezt én írtam, a másikat meg nem.
Egyszerűen nem tetszik és kész, egyébként: az ada logikus, pascal idétlen. Miért nem lehet lezárni rendesen az if-eket (end if), és miért nem lehet az end elé pontos veszsőt tenni (üres utasítás a pontosvessző, ahelyt, hogy egy null-t kellene odaírni, stb).
Azért mert a spanyolok meg fordított kérdőjellel kezdik a kérdőmondatot. :P
[quote:9f6faf18ec="bocs"][quote:9f6faf18ec="syntern"]:) Ez jó. Meg tudod oldani azt C++-ban, hogy egy feldarabolt memóriaterületet összenyomj, hogy a sok kis memória összesen egy nagyot tegyen ki? Persze, elméletileg megoldható lehet (pedig nem, lásd: nem befolyásolt forrásból származó kód), a Java meg is oldja.
nem tudom, ez nálad valami fixa idea lehet, hogy a c++ malloc az nem képes a felszabadított blokkok utólagos egyesítésére.
Talán azért, mert úgy gondolom, hogy a mutatók miatt ez nem lehetséges. Persze ha tudsz jó példát hozni, akkor ezt beláthatom, hogy mégis lehetséges.
[quote:97ff152ed2="_Joel"]Egyébként C++-hoz is vannak GC-t alkalmazó megoldások, smart pointerek. Ha olyan rossz ez az ötlet, akkor miért alkalmazzák mégis sokan?
Mifelénk a tanszéken időről időre elhangzik valaki szájából a kövektező örök igazság (szabad fordításban): Minden automatizmus csak addig jó, amíg ki lehet kapcsolni.
Kb. 3 hónapja én is leteszteltem a C vs C++ vs Java-t /link, sajnos a lap a táblázatok előtt kicsit szát van csúszva/. Prímszámokat keresgéltem és többfajta implementációt is kipróbáltam. Az eredmények hasonlóak lettek, mint amit itt a Quicksortos példában láttunk.
Olyan szépen beálltak az arányok. N = 3, 6, 10 millióra kb. egyenlőek lettek /C, C++ -O3-mal/.
1. C++ std::vector
2. C++ tömb 2,7%-kal több idő
3. C tömb 4,8%-kal több idő
4. Java tömb 7,5%-kal több idő
Azoknak meg, akik azt mondják, hogy Java-ban a hülyék programoznak: :lol:
Én szeretem a C-t és a C++-t, de azért egy Java... Az osztálykönyvtára, meg a platformfüggetlensége meg az, hogy fél óra alatt összehozok egy J2EE webservice-t, hozzá egy webes, egy J2SE-s és egy mobilos klienst... Ekkora produktivitást mikor kapok én a C++-tól?
[quote:d63a34b09f="ssikiss"][quote:d63a34b09f="syntern"][quote:d63a34b09f="ssikiss"]Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
Hát, az én elképzeléseimben a dll egy bináris, amin belül lehet bármi, és ha nekem nem mondják meg, hogy mi van benne, meggebedhetek, akkor sem fogom tudni kitalálni a belső osztályszerkezetet, amennyiben véletlen C++-ról fordult az a dll, és nem pl. C-ről. Ennek ellenkezőjéről egy példával már meg is lehet győzni :)
Ez teljesen így van, csak mifelénk szokás mellé egy-két header-t meg interfész libet, meg doksit is adni, ha azt akarod, hogy tudjanak vele fejleszteni. :D
Jávában is illik doksit adni nem (sokra mész a jarban látható osztályszerkezettel)?
Lehet hogy én látom rosszul, de ha adsz interfészeket és doksit (= a másik oldal tudja, hogy mit fog kapni), akkor nincs szükség reflectionre. A reflection ott kell, ahol nem tudod, hogy mit kapsz.
[quote:7ed92f40dd="_Joel"]
A project manageré meg az a felelősség, hogy a projekt megadott időre, a megrendelő igényei szerint, minél kevesebb hibával kész legyen.
Na igen... a munkával töltött idő arányos a minőséggel... :)
[quote:7ed92f40dd="_Joel"]
Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
Ezt sem megcáfolni sem alátámasztani nem tudom... talán majd valaki más. :)
[quote:7ed92f40dd="_Joel"]
A programozó ugyanúgy el is felejtheti odatenni azt a dispose-t, vagy free()-t, mint ahogy gyakran el is felejti. Tudom, van rengeteg eszköz, amivel ezeket figyelni lehet és a jobb programozók használják is őket memory leak-ek felkutatására. Csak éppen emiatt ugyanannak az üzleti logikának a lekódolása 2x-3x annyi időbe kerül és 2x-3x annyi rizikóval járhat.
De nagyságrendekkel hatékonyabb a program működése... nem?
[quote:7ed92f40dd="_Joel"]
Nem külső alkalmazás. Egy JVM-en belüli folyamat, amiről a programozónak nem is kell tudnia (persze ha jó programozó akkor ismeri és tudja, hogy mi a különbség a fiatal meg az öreg generáció között, tudja hogyan működik a mark & sweep algoritmus, mikor érdemes olyan paraméterrel indítani a JVM-et ami bekapcsolja a párhuzamos vagy a megállásmentes gc-t... stb stb stb).
Itt most a külső alkalmazást úgy értettem hogy "nem a programozó által írt program része" hanem egy másik "külső" program.
[quote:7ed92f40dd="_Joel"]
Egyébként C++-hoz is vannak GC-t alkalmazó megoldások, smart pointerek. Ha olyan rossz ez az ötlet, akkor miért alkalmazzák mégis sokan?
Memtudom. Én nem használok ilyesmiket...
Szerintem amikor valaki megtervez egy olsztályt akkor azért körvonalazódnak azok az alapok amik mentén majd megvalósul a dolog. Így nem maradhat figyelmen kívül az erőforrások lefoglalása és felszabadítása sem. Egyszer kell megírni, az alkalmazása "automatikusan" megtörténik amikor szükséges.
[quote:7ed92f40dd="_Joel"]
Ez eléggé szűklátókörű kijelentés. Pár link:
fdavid írta: "Ezt nem teljesen ertem, hogy hogyan vetheto ossze a programhiba a gep teljesitmenyevel. Ha azt akarod mondani, hogy egy bizonyos feladat nem hajthato vegre jol mukodo program hianyaban, akkor ez trivialis, es nem ujkeletu problema. "
A szűk keresztmetszeten azt értettem h egy általános program megírásokor manapság nem a cpu lassúsága vagy a memória nagysága a probléma, hanem az h nem vagyunk képesek jól működő, viszonylag kevés hibát tartalmazó progit írni. A "mi" természetesen vállalatok, cégek programozók stb.
Arra gondolok h linux alatt (persze win alatt is így megy nagyjából) elkészül egy progi 1.0 verzió. Fél év múlva kijön a hibajavítás 1.1 verzió alatt. Kijavították az előző hibákat de újak kerültek bele...
És nem amiatt mert buták vagyunk, hanem mert nincs megfelelő programnyelv a kezünkben!
"A megoldas a minsoegbiztositas. Tisztesseges folyamatdefiniciok, modszerek, eszkozok, human eroforras osszhangaja, tervezes, dokumentalas, es atfogo teszt.
"
Így van! Ez jól hangzik, de sok cégnél rugdalják a programozó h minél előbb legyen kész a progi :( elvesznek a finomabb részletek.
Szerintem magába a prog nyelvbe kellene valahogy minőség biztosítást csempészni! Hogy ne tudd olyan könnyen elszúrni. Elhiszem h lehet nyugodt munkakörnyezetben jól dolgozni. De számtalanszor tapasztaltam h a kedves megrendelő tegnapra! várja a programot. És sok sok cégnél is így van. Azért mert nagy verseny van a piacon.
Első lépcsőfok szerintem a menedzselt prog nyelvek.
[quote:b4eaf5435a="hanischz"]
Régebben Builderben írtam a progikat (amiket eladtam). Nagyon jó kis API-t hoztak létre. Késöbb áttértem a visual C-re,
Itt adsz saját magad magyarázatot a problémára. Builder és visual C. Mind a kettő saját függvény / osztály könyvtárat készített valószínüleg úgy hogy nem egyeztették egymással (bárkivel) hogy ki mit és hogyan valósít meg. Ebből következik hogy inkompatibilisek egymással (mindenkivel) és megkérdőjeleződik a hordozhatóság is.
Ezt nem értem. Ha valaki GUI-s programokat akar írni Win alatt, akkor muszály az inkompatibilis utat választani C-ben! Mert említettem h nagyon le van maradva, ősrégi szabványos könyvtárak vannak C alatt.
Ráadásul a lefordított kód a win32 api-n alapul ami másogy viselkedik Win98 és XP alatt.
NEM a kettő átjárhatóságáról beszéltem. Teljesen mindegy melyik környezetet választod, akkor is beleütközöl a Windows-ok közötti különbségekbe.
[quote:44ff53962c="_Joel"][quote:44ff53962c="Andrei"]
Azt meg egyszeruen keptelen vagyok elfogadni, hogy a GC-t, mint a programtervezest konnyito eszkozt kelljen elkonyvelni.
Hopsz, ilyet nem akartam mondani. En csak azt mondtam, hogy Javaban a memory leak jellegu hibak altalaban tervezesi hibara eredeztethetoek vissza, mig C/C++-ban inkabb programozoi hibakra.
Nem Te mondtad, valamelyik masik nick hozzaszolasaban volt egy ilyen implicit gondolat.
[quote:eee4bb4c55="Csab"]Én személyesen a C++-t szeretem a legjobban.
Az osztályszerkezete jól átgondolt és gyors is.
....
megjelenesekor a jview.exe a microsoft VM sokkal gyorsabb volt mint sun vm
/* sok oka volt, ha valakit erdekel a tortenelem leirhatom */
de, az tetszett, hogy Gyuri egyre azt modogatta, mikor ezt felemlegettem neki:
''.. ez nem igazan gyorsasag, inkabb kapkodas... ,,
szoval c++ sebesseggel is ez a helyzet: kapkodas
igazi sebesseg novekedest ( jobb algoritmus nelkul )
a runtime profiler tud elerni
altalnosan mukodo c++ runtime profiler pedig nem nagyon van..
[quote:443f8208b9="Andrei"]Aztan jon a slusszpoen! Mi van, ha a programod eleve tobbszalu? Egyreszt mindegyikkel szinkronizalnod kell a GC-t, ami nem a jo skalazodas biztositeka.
Gondolom hallottál már arról, hogy a skálázódás nem azt jelenti, hogy minden hipergyors, hanem azt, hogy ha skálázódni kell, akkor tudunk, és nem omlik össze a rendszer, hanem biztosítjuk a folyamatos feldolgozást. Ha bővebben érdekel, akkor a J2EE specifikáció és tutoriálok környékén kezdj el nézelődni... :)
Nyugodtan lehet a szervereket, JVM-eket darabolni, 1-2 GB-on belül jól teljesít a Java GC, több szerver esetén meg biztosított a folyamatos feldolgozás. Aztán majdcsak befejezik a MVM-et, és ez is megoldódik :)
De hogy mondjak okosat is: a Java VM belső kapcsolói lehetőséget adnak arra, hogy szabályozd: maximum mennyi ideig fusson egy GC a teljes prociidő százalékában, ezrelékében akárhányad részében. Azaz legfeljebb annyi ideig fut, közben kidobálja a szemetet és felszabadul a memória. Ha ezt összekötöd object-pool használattal, akkor még azt is meg tudod határozni, hogy mikor fog futni GC.
Nos, bar en meg csak tanulom, de eddigi ismereteim alapjan a velemenyem:
Az IGAZI programozo programnyelvtol fuggetlenul gondolkodik, es nincs szuksege arra, hogy egyetlen programnyelven dolgozzon egesz elete soran.
En szerintem kicsit szetvalasztanam a programozast es a kodolast.
Csab: ne haragudj, ha offenziv a kerdes, de milyen vegzettseged van, miota es mennyit foglalkozol C++-al es Javaval? Csak azert kerdezem, mert nem tudom eldonteni, hogy mirol es milyen reszletesen irjak az altalad felvetett kerdesekre es "problemakra".
[quote:0c8066541d="syntern"]
Egyreszt azert, mert a C++ operator mogott barmi lehet,...
Igen ez így van...
[quote:0c8066541d="syntern"]
...masreszt mert az operator overloading tenyleg csak macro abban az ertelemben, hogy a vegso binarisban szepen atfordul a megfelelo metodushivasra.
Ha így gondolkodsz akkor az java összes üggvény / osztály használata is csak makró mert "szepen atfordul a megfelelo metodushivasra".
:D
[quote:0c8066541d="syntern"]
Innentol kezdve megint lehet vitatkozni a nyelv szintaktikajan, ami felesleges, mert egyreszt adottsag es nem most talaljuk ki, masreszt osszehasonlitjatok az almat a kortevel, es nem veszitek eszre, hogy mas a celjuk.
Mint már írtam itt nem szintaktikus összehasonlításról van szó.
Ez alapvető elvi / filozófiai kérdés, hogy a nyelv megengedi, a saját operátorok írását. A baj ott van hogy a java-ban az operátorok UTASÍTÁSOK melyeknek a működése bele van drótozva a fordítóba. A c++ esetén a programozó írhat alternatív operátorokat a gyáriak helyett mert azok NEM UTASÍTÁSOK.
Ebből én azt gondolom hogy a c++ hatékonyabb / rugalmasabb mint a java. Ezért a c++ jobb mint a java.
[quote:65e1048a52="popacsek"][quote:65e1048a52="syntern"][quote:65e1048a52="ssikiss"][quote:65e1048a52="feledhetetlen"]inkabb ez: erted-e az alapokat, vagy se
aki tudja erre az egyszeru kerdesre a valaszt az erti
aki nem, az csak dumal
Na most akkor lassan már elárulhatnátok, hogy mit kell azon az egy soron látni, hogy más is okuljon a java "szépségeiből".
:?:
El kell ismerni, hogy ez az egyszeru, trivialisan szep pelda tenyleg alaposan megizzaszthatja a C++-t hasznalo, a Javat feluletesen ismero embereket :). Hozzunk egy alternativat, hogy ne csak a Java-ra fujjatok, itt a .NET-es analogiaja:
lock (this) { }
Tenyleg csak azon mulik, hogy valodi OO szemlelet van, vagy csak szintaktikailag kezeled az OO-t....
A: Bibibi! Én tudom, hogy mit jelent a synchronize(this) {}
B: Az mind semmi! Én már használtam is!
A: Az is valami? Én javasoltam a SUN-nak, mikor megalkották a java-t!
B: Nekem öcsém? Nem hiszem! A java-t én találtam ki egyedüll!
.
.
.
8-)
milyen lenne, ha vicc helyett valaki leirna...
csak azert gondolom mert itt ugy dobaloztok a multithread meg "atomi muvelet" dumaval, hogy ez nem jelenthet problemat...
ez nem a nyelv szepsege, ez kulcsszo szintu ismerete annak amirol elszantan irogattok...
csak azt ertem ebbol a postbol: vicces szeretnel lenni, de a valaszt nem tudod
[quote:f1c554421e="lokoto"]
Az egyetlen probléma, hogy jelen esetben nincs "adott környezet", sem "adott feladat"...
Nincs környezet? Nincs feladat?
Amikor megírsz egy programot akkor mit csinálsz?
A környezet a számítógép és az a rendszer ami alá a programot írod, valamit az eszközök amiket felhasználhatsz.
A feladat az amit majd a program megírása során megoldasz.
A kérdés az hogy a programnyelv hogyan viszonyul ezekhez a dolgokhoz. Van amelyik jobban van és van olyan amelyik kevésbé.
[quote:f1c554421e="lokoto"]
Azaz ebből az esetből (op overloading) megállapítod, hogy a Java filozófiája rosszabb. Holott ez csak egyetlen kérdés a sok közül egy nyelv/platform esetén.
[quote:a4be8719ce="syntern"]Lehet hogy én látom rosszul, de ha adsz interfészeket és doksit (= a másik oldal tudja, hogy mit fog kapni), akkor nincs szükség reflectionre. A reflection ott kell, ahol nem tudod, hogy mit kapsz.
Ja, hogy reflection-ről beszélünk? Olyan biza C++-ban nincsen (typeid van, de az kevés). Ilyen-olyan megoldások (Managed Extensions for C++) vannak.
[quote:11c25f9923="Frimen"]
Ugye tesztelési, átvételi stb. jegyzőkönyvről még nem is hallottál?:)
Ugye verifikaciorol meg nem is hallottal :D Az eddigi hozzaszolasaid alapjan (kinyomtatja a bytecodot) nagyon-nagyon ugy tunik. A teszteles egyaltalan nem garantalja a hibamentesseget, de meg azt atveteli jegyzokonyv sem.
[quote:11c25f9923="Frimen"]
A szerződések kitételeiről a felelősség kérdésében nem is beszélve..:)
Tudhatnad, hogy torvenyesen nem lehet korlatlanul felelosseget kizarni. Egy szerzodeshez pedig ket fel kell, persze probalkozhatsz, max massal kotnek szerzodest.
[quote:3e74620e1a="syntern"][quote:3e74620e1a="bocs"]nem tudom, ez nálad valami fixa idea lehet, hogy a c++ malloc az nem képes a felszabadított blokkok utólagos egyesítésére.
Talán azért, mert úgy gondolom, hogy a mutatók miatt ez nem lehetséges. Persze ha tudsz jó példát hozni, akkor ezt beláthatom, hogy mégis lehetséges.
Kérlek, alaposabban olvass. felszabadított blokkok utólagos egyesítése triviális, pointerek nem játszanak.
Példa: adtam, lásd Microsoft implementáció.
[quote:faa5ff9448="bocs"] felszabadított blokkok utólagos egyesítése triviális, pointerek nem játszanak.
De a Java a fel nem szabaditott blokkokat is at tudja rendezni (defragmentalni) - a stop & copy vagy mark & copy algoritmus pont errol szol... Syntern erről beszélt.
[quote:9eb2fee226="feledhetetlen"]
csak azt ertem ebbol a postbol: vicces szeretnel lenni, de a valaszt nem tudod
Nem akartam leírni, mert akkor közkincs lesz ez a überfasza jelentkező-fingatós feladat. Ha megadom a választ, mit fogsz kérdezni a következő "interview" alkalmával?
Piszkálódást félretéve: valaki vagy tudja, hogy mit jelent java-ban a "synchronized", vagy nem. Ha tudja, akkor a feladatod megoldása TRIVIÁLIS. Ez olyan mintha azt kérdeznéd, mit jelent az, hogy "a++;".
Ha valaki tudja, hogy mit csinál a ++ operátor, akkor a feladat nem feladat, csak annak látszik.
[quote:293ffbd1df="bocs"][quote:293ffbd1df="syntern"][quote:293ffbd1df="bocs"]nem tudom, ez nálad valami fixa idea lehet, hogy a c++ malloc az nem képes a felszabadított blokkok utólagos egyesítésére.
Talán azért, mert úgy gondolom, hogy a mutatók miatt ez nem lehetséges. Persze ha tudsz jó példát hozni, akkor ezt beláthatom, hogy mégis lehetséges.
Kérlek, alaposabban olvass. felszabadított blokkok utólagos egyesítése triviális, pointerek nem játszanak. Példa: adtam, lásd Microsoft implementáció.
Kérlek gondold át:
0000: szabad memória blokk
0010: szabad memória blokk
0020: ide mutat egy pointer
0030: szabad memória blokk
A 00, és 10 összevonása triviális. Viszont a 00, 10, 30 egybevonása már nem az. A Java ezt tudja, és a C++ nem, implementációtól függetlenül, ugyanis nem tud mit mondani a pointerre.
[quote:60967c80c5="lokoto"]
...mert javában nem tudsz *a-t írni, ezért ha az a = b-t felüldefiniálod a = b.clone() funkcionalitására, nem tudod miként megvalósítani a jelenlegi értelemben vett a = b műveletet, azaz hogy az a változó a b változó által mutatott objektumra mutasson.
Itt érkeztünk el ahhoz a ponthoz hogy saját magad mondod ki azt, hogy a java filozófiája rosszabb mint a c++. :)
Fölösleges megkötésekkel gátat szab saját maga kifejező erejének...
[quote:60967c80c5="lokoto"]
Lehet, hogy csak megszokás, de az =-nek ez a funkcionalitása logikusan ábrázolt, és a clone() kitűnően kifejezi, hogy mélymásolást kell csinálni.
Korábbi hozzászólásomban (induljunk el a kályhától) kifejtettem hogy szerintem egyáltalán nem természetes a java filozófiája.
[quote:f4d052179b="Morzel"]Nos, bar en meg csak tanulom, de eddigi ismereteim alapjan a velemenyem:
Az IGAZI programozo programnyelvtol fuggetlenul gondolkodik, es nincs szuksege arra, hogy egyetlen programnyelven dolgozzon egesz elete soran.
En szerintem kicsit szetvalasztanam a programozast es a kodolast.
Morzel
ez teljesen jogos.
én úgy érelmezem, hogy most épp mi a kedvenc programozási nyelvem.
15 éve pl. a c64 assembly volt. :)
[quote:e5861f228f="Panther"][quote:e5861f228f="Chain-Q"]jon valaki okostojas, es kozli h. szerencse h. kimaradt a Pascal, es persze nem mulasztja el bepastelni a hatulgombolosozos dumat. De hat ez mar nem engem minosit.
Sajnos téged minősít. "szerencsére" - ezt én írtam, a másikat meg nem.
Oromomre szolgal, hogy akinek inge, az feloltozkodik vegre... :)
Egyszerűen nem tetszik és kész, egyébként: az ada logikus, pascal idétlen. Miért nem lehet lezárni rendesen az if-eket (end if),
He? Mivan az ifekkel?
és miért nem lehet az end elé pontos veszsőt tenni (üres utasítás a pontosvessző, ahelyt, hogy egy null-t kellene odaírni, stb).
He?! Mit nem lehet az End elott? Biztos ugyanarrol a nyelvrol beszelunk?
[quote:57950accba="drojid"]Engem pl érdekelne a történelem :)
akkor a kedvedert (es az archivumnak):
1.)
eloszor is azert volt gyorsabb, mert a microsoft-nal volt Compiler
a sun java vm ugy jelent meg, hogy csak interpreter volt
nem egy nagy dolog mert a P-code compiler mar a kezukben volt
azt viszonylag konnyu java byte-code-ra at borzolni
2.)
a sun vm green thread-del jelent meg a microsoft vm legelso valtozata mar nativ thread-es volt
/* amugy szemely szerint hianyolom a green thread-et */
3.)
a microsoft vm class loader-e elore forditott osztalyokat toltott, volt egy
egyszeru adatbazis ami timestamp alapjan ujra forditott, ha szukseges volt
igy a toltesi ideju forditassal a sun vm komoly hatrannyal indult
a microsoft vm sikeret joreszt egy Brad Silverberg nevu fickonak koszonhetik
O volt a szemelyzetis a Borland-nal es o volt az elso akit elcsabitottak
ezzel persze megvettek maguknak azt a tudomanyt, hogy kit erdemes megvenni a Borland-tol, peldaul a turbo pascal ota cummulalodo tudast
ezt onnan tudom, hogy a regi Quattor (egy borland spreadsheet) team Cseri Istvan, Frank Lajos (isten nyugosztalja) is atmenetelt a microsoft-hoz
a sun vm koncepcioja napjainkban 'erik be' a runtime profiler ( kulonosen "java -server" ) olyan sebesseg novekedest tud elerni ami a 'hulye' programot is fel tudja gyositani
jegyzem a legsotetebb pont a java tortenelmeben eppen a hotspot korul alakult ki (de ez mar egy masik tortenet...)
[quote:52f218df0f="Csab"]Security azért nincs C-ben, mert nincs rá szükség. A processzeket az operációs rendszer kézbentartja.
Ugyanez java alkalmazások esetén is megy, hogyha különböző JVM-ekben futnak. Ez viszont túl nagy ár a Security-ért. Eszméletlenül sok memóriát igényel párhuzamosan futtatni 5-6 JVM-et. A JVM-ek közti kommunikáció, objektumok átadása sem túl kecsegtető.
Éppen ezért találták ki a java-s security-t. Ez egy jó ötlet volt, csak pocsék megvalósítás mellett. Mindegy. Ez van, ezt kell szeretni, vagy elviselni.
Valahogy azt latom, (es ezert kerdeztem), hogy bar eleg regota foglalkozol Javaval, legfeljebb feluletesen tetted eddig. Ha egy kicsit is kovetted az esemenyeket, akkor tudod, hogy mostanra a JVM-ek kihasznaljak a shared memory-t, azaz JVM-enkent maximum nehany MB plusszra lehet szamitani, alig tobbre, mint a kulon process nativ alkalmazasoknal. Mielott ezt megprobalod banalis modon cafolni: mi 40 darab kulonallo JVM-et futtatunk egyetlen gepen a laborban, es ha nem tudnak hatekonyan megosztani a memoriat, akkor kb. ketszer annyi memoriat foglalnanak, mint a maximalis memoria a gepben. Igy meg meg eppen belefernek a fizikai memoriaba (igen, ezt is kimertuk :)).
A JVM-ek kozotti objektum atadasakor en elsosorban az RMI-re gondolok. Ha nem Java alkalmazas van, akkor egyeb socket-kezeles, vagy csak bonyolultabb protokoll jon szoba. A Java semmivel sem csinal mast, mint mindenki mas, a kulonbseg, hogy RMI-t fejleszteni alig nehany sor. Szoval nem ertem ezt a kommunikacio reszt sem.
Tovabba nem ertem a security-n valo lovaglast. Tudnal mondani egy alkalmazasi peldat, ahol ki kellett hasznalnod a Java security-t, maskeppen nem vagy csak csunyan lehetett volna megoldani?
1. Megalkották a C++-t, az egész jóra sikerült, de leálltak a további szabványosítással. Mindenki olyan könyvtárat ír, amilyet akar.
2. Megalkották a java-t és továbbra is fejlesztik, egy kézben van, ezért egységes megoldásokat használnak
A java fokozatosan fejlődik, míg a C++ áll. Persze hallottam, hogy beszélnek már az új C++ szabványról is...
A probléma valahol ott van, hogy nincsenek egységes C++-os könyvtárak úgy, ahogy java-ban.
Nekem személyesen a C++ magja, az alap szerkezete jobban tetszik, mint a java alap szerkezete. A C++ gazdagabb, míg a java az equals metódusaival fapadosnak tűnik. Egy választékos nyelven könnyebben fejezed ki magad. :-)
Ha a java olyan lenne, hogy a C++-os osztályszerkezeteket használná, én is java-s lennék. Számomra nehézkesnek tűnik az egész és áttekinthetetlen.
Elsősorban érzelmi okai vannak, hogy C++-t használok. Sokkal szebb és választékosabb a C++-os kifejezés forma.
[quote:8ecab8dcbb="lacipac"][quote:8ecab8dcbb="hop1"]És kimaradt a pascal :(
Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban.
http://www.wizzy.com/andyr/Mel.html
Real Programmers write in FORTRAN.
Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
[quote:45ec10abff="handler"]
Tudhatnad, hogy torvenyesen nem lehet korlatlanul felelosseget kizarni.
Tudnál jogszabályra hivatkozni?
Nekem laikusként úgy tűnik, nincs igazad. Gondolok pölö a "Magas feszültség! Életveszély!" táblára. Gondolom ezzel analóg módon, ha a programod forrásába/dokumentációjába, első megjelenő felhasználói interfészébe beleírod, hogy nem vállalsz felelősséget, akkor csak nem verhetik el a port rajtad, nem?
Én mobiltelefonokkal foglalkozom. Plusz néhány megabyte tudod mit jelent mobil telefonoknál?
A Security nekem azért fájó pont, mert sajnos "felsőbb döntésre" security-t is kellett implementálnom. No most valami hihetetlen értelmetlen dolgokkal kellett foglalkoznom ezalatt.
Pl. az összes:
AccessController.check( perm );
hívást le kellett cserélnem
SecurityManager sm = System.getSecurityManager();
if( sm != null )
sm.check( perm );
-re, minthogy az AccessController.check nem működik helyesen minden esetben. Szóval leimplementáltam a security-t, fogalmam sincs, hogy mi miért úgy megy ahogy, a tesztek végig futottak, többet nem akarom látni.
Sajnos nagyon mély vízbe dobtak legutóbb, mert a security mellett ClassLoader-t is kellett írnom, reflection-özni és a ProtectionDomain átizélgetése után eljutottam odáig, hogy elegem van a java-ból.
[quote:0ec746cb55="hanischz"]
Ezt nem értem. Ha valaki GUI-s programokat akar írni Win alatt, akkor muszály az inkompatibilis utat választani C-ben! Mert említettem h nagyon le van maradva, ősrégi szabványos könyvtárak vannak C alatt.
Ez igy természetes... miért várod el azt hogy a c++ tartalmazza a vindóz specifikus dolgokat? Mert akkor ne tegyünk kivételt és tartalmazhatná a világ összes specifikus dolgát is... a mikrokontrollerektől a szuperszámítógépekig... lehetőleg nem kifelejtve az összes létező oprendszer dolgait... nem?
[quote:0ec746cb55="hanischz"]
Ráadásul a lefordított kód a win32 api-n alapul ami másogy viselkedik Win98 és XP alatt.
Erről szerintem az m$ tehet... írjon olyan könyvtárat meg fordítót ami az összes vindózon egyformán működik.
[quote:0ec746cb55="hanischz"]
NEM a kettő átjárhatóságáról beszéltem. Teljesen mindegy melyik környezetet választod, akkor is beleütközöl a Windows-ok közötti különbségekbe.
Meg erről is az m$ tehet... szerintem.
Ha a szabványos könyvtárakat használod akkor az garantáltan működni fog mindenhol. A C++ nem akar egy olyan standard library-t csinálni amiben minden benne van. Olyat nem lehet csinálni. Illetve a java próbálkozik... :) Viszont ad egy olyan eszköztárat amivel könnyen, kis ráfordítással készíthetsz dolgokat a meglévőkből.
[quote:b6c1916799="syntern"][quote:b6c1916799="Andrei"]Aztan jon a slusszpoen! Mi van, ha a programod eleve tobbszalu? Egyreszt mindegyikkel szinkronizalnod kell a GC-t, ami nem a jo skalazodas biztositeka.
Gondolom hallottál már arról, hogy a skálázódás nem azt jelenti, hogy minden hipergyors, hanem azt, hogy ha skálázódni kell, akkor tudunk, és nem omlik össze a rendszer, hanem biztosítjuk a folyamatos feldolgozást. Ha bővebben érdekel, akkor a J2EE specifikáció és tutoriálok környékén kezdj el nézelődni... :)
Nyugodtan lehet a szervereket, JVM-eket darabolni, 1-2 GB-on belül jól teljesít a Java GC, több szerver esetén meg biztosított a folyamatos feldolgozás. Aztán majdcsak befejezik a MVM-et, és ez is megoldódik :)
De hogy mondjak okosat is: a Java VM belső kapcsolói lehetőséget adnak arra, hogy szabályozd: maximum mennyi ideig fusson egy GC a teljes prociidő százalékában, ezrelékében akárhányad részében. Azaz legfeljebb annyi ideig fut, közben kidobálja a szemetet és felszabadul a memória. Ha ezt összekötöd object-pool használattal, akkor még azt is meg tudod határozni, hogy mikor fog futni GC.
Parhuzamos linearis egyenletrendszer megoldot fejlesztettem Fortran/C/C++-ban. "Nagyjabol" vagom, hogy mi a skalazodas.
A GC-vel kapcsolatos elvaras jogosan lenne az, hogy linearishoz kozeli skalazodast mutasson. Mondjuk, hogy egy 5 szalon kiegyensulyozottan futo program egy 8 procis gepen fusson mar kb. 5-szor gyorsabban, mint egy procin. Maskulonben nem lenne ertelme megvenni ezeket a szep nagy napocskaslogos szervereket.
Egyreszt azert mert a jelenlegi "in-process GC" megkozelites -gondolom- eleg jol mukodik (csakugye visszafogja a fo programszalat), meg szepen is skalazodik. Namost kiontod a gyereket a furdovizzel, ha ehelyett beultetsz egy olyan strategiat, ami nem fogja vissza a fo programjaidat, viszont lepten nyomon egymas tyukszemere lepnek a programszalak meg a GC. Ez tipikus skalazodasi problema... Attol meg, hogy helyesen mukodik egy SMP-n, meg nem skalazodik jol a programod.
Az object pool nekem nem tetszo megoldas. Nem arrol volt szo, hogy automatikus memoriakezelest szeretnenk? Akkor miert is szarakodunk object-pool-lal?
-server kapcsoló, gondolom, csak sun jvm része, mert mi IBM-es jdk-t használunk és ott nem nagyon látszik működni.
Amúgy szerencsétlen IBM jdk gyorsabb lenne, mint a SUN, vagy tévedek?
Amennyiben a this változó lokkolva van, akkor vár.
Ha nincs lokkolva, keresztül megy rajta.
Mit lehet elmondani synchronized( this ) után?
- Aki a meghívásig lokkolta a this objektumot, az elengedte.
Indítasz egy Thread-et, ami lokkolja a this-t, amíg fut.
A synchronize { this } {} meg fogja várni, hogy a thread véget érjen és csak aztán megy tovább.
Egyébként ennek a példának semmi értelme sincs, mert a Thread.join() sokkal elegánsabb és érthetőbb is.
[quote:cedb9acadc="syntern"]0000: szabad memória blokk
0010: szabad memória blokk
0020: ide mutat egy pointer
0030: szabad memória blokk
A 00, és 10 összevonása triviális. Viszont a 00, 10, 30 egybevonása már nem az. A Java ezt tudja, és a C++ nem, implementációtól függetlenül, ugyanis nem tud mit mondani a pointerre.
hehe
keverjük itt a szezont a fazonnal
milyen megoldás révén tudja ezt a Java? Plusz erőforrás felhasználás révén (GC CPU idő, objektum referenciák vagy refcount, dupla(!!) heap méret a szükségeshez képest, nemdeterminisztikus viselkedés).
Tehát a GC költséget mindig megfizetteti veled, még akkor is, ha nyugodtan lehetne használni adott feladathoz determinisztikus allokációt/deallokációt.
Java-ban van választási lehetőséged, hogy GC-t vagy determinisztikus allokációt használsz ? Nincs.
C++-ban van? Igen, van.
C++ -os GC használata esetén lehetőséged van a heap fragmentáció megszüntetésére, például objektum áthelyezéssel, saját new operátor létrehozásával. Ennek meg kell fizetned az árát, pl refcount-ok / objektum referenciák lefoglalásával, fenntartásával, menedzselésével.
Szépen lehet így a körkörös referenciákat is kezelni.
Amikor csökkentem a saját objektumom referenciáját, megnézem, hogy van-e visszareferáló objektum. Ha annak 1 a referenciája és nekem is 1, akkor felszabadítható. Nagyobb ciklusok is detektálhatóak.
Persze való igaz, hogy mindenegyes referenciacsökkentésnél elvégezni ezt a szmötyit időigényes.
Persze a körkörös referenciákat cache-elni is lehet, így gyorsabb lesz.
Cserébe rendes destruktort kapunk, nem olyat, ami csak úgy ad hoc garbage collection-nél meghívódik. A C++-os destruktor nagyon hiányzik java-ból.
[quote:4ea31356be="Csab"]A Security nekem azért fájó pont, mert sajnos "felsőbb döntésre" security-t is kellett implementálnom. No most valami hihetetlen értelmetlen dolgokkal kellett foglalkoznom ezalatt.
Továbbra sem látom, hogy miért szidod a Java Security-t, csak azt látom, hogy valami ismeretlen dolgot kellett alkalmaznod munka közben, ami nem volt kellemes. Még mindig nem látom, hogy mire kellett használni Security-t és hogy arra a Java miért volt kényelmetlen.
[quote:4ea31356be="Csab"]Sajnos nagyon mély vízbe dobtak legutóbb, mert a security mellett ClassLoader-t is kellett írnom, reflection-özni és a ProtectionDomain átizélgetése után eljutottam odáig, hogy elegem van a java-ból.
Ez korántsem biztos, hogy a Java hibája, nem gondolod? :)
Bocs, h beleszólok a nagyok dolgába, de engem nemrég ez eléggé meglepett:
http://www.bytonic.de/html/benchmarks.html
ofkoz a játék nem egy mai darab, viszont az sem mondható rá, hogy vmi láma programozta, és optimalizálatlan :)
[quote:536c2f9f47="Csab"]A C++-os destruktor nagyon hiányzik java-ból.
A Java-s GC nagyon hiányzik a C++-ból.
Ennek a kijelentésnek kb ennyi értelme volt. Az előtte lévőknek még ennyi sem (hidd el, hogy komoly, akadémiai emberek foglalkoznak a gc témáinak kutatásaival nagy cégeknél és egyetemen egyaránt. Az előbb általam említett weboldalon publikációk tucatjait találod, amiken ha átrágod magad, akkor sokkal komolyabb érvekkel fogod tudni alátámasztani, hogy miért sz@r a gc úgy, ahogy van - ugye nem okoz gondot, hogy angolul vannak?)
Itt most a külső alkalmazást úgy értettem hogy "nem a programozó által írt program része" hanem egy másik "külső" program.
Mert szerinted a gc-t nem programozó írta? Dobjuk ki a libeket is, mert más írta? Nem értelek:)
Szerintem amikor valaki megtervez egy olsztályt akkor azért körvonalazódnak azok az alapok amik mentén majd megvalósul a dolog. Így nem maradhat figyelmen kívül az erőforrások lefoglalása és felszabadítása sem. Egyszer kell megírni, az alkalmazása "automatikusan" megtörténik amikor szükséges.
Nem egy malomban őrlünk. Természetesen akár asm-ben is mindent meg lehet írni, még performant is lesz, mert a drága CALL-ok helyett trükközhetsz sima ugrásokkal, stack használat helyett írhatsz önmódosító kódot ami MOV-okba rakosgatja a regiszterek értékét (386-on 2-3 óraciklust is lehetett nyerni ezekkel a trükkökkel). Tök gyors lesz. Meg tudod tervezni, hogy minden elférjen a regiszterekben, tudod, hogy melyik szegmens szelektort mire használod. Mindent meg lehet csinálni. Én is vagy egy évig irkáltam egy lemezújság kódját, realflat-tel, meg svga grafikával, stb stb (igaz ez még gimnáziumban volt).
A GC ugyanolyan fejlődési lépés a programozási nyelvek történetében, mint az asm-ről a C-re lépés, vagy az objektumorientáltság megjelenése. Gyorsítja a programozást, mert leveszi a programozó válláról a memóriamenedzsment feladatát. Ez a programozási feladatok 95%-ban nem gond, mert nem jár olyan teljesítményvesztéssel, ami elfogadhatatlan lenne az adott alkalmazás/projekt szempontjából, ugyanakkor meg lényegesen könnyíti a fejlesztést. Gyengébbek kedvéért: ugyanazt a feladatot a C++-ban fejlesztő cég 25 millió forintért vállalná be és 12 hónap alatt szállítaná az árut, a Javas cég meg 14 millió forintért vállalja be és 6 hónapos határidőt vállal (kötbérestül, mindenestül). A program végül egy olyan rendszerre kerül, ami 1 millió forintba kerül: ha teljesítményprobléma van, vesznek még 1 millióért még egy gépet. Megéri 11 millióval többet kifizetni egy elméleti 20-25%-os teljesítménytöbbletért és megéri még fél évet várni az adott online szolgáltatás beindítására?
Amennyiben a this változó lokkolva van, akkor vár.
Ha nincs lokkolva, keresztül megy rajta.
Mit lehet elmondani synchronized( this ) után?
- Aki a meghívásig lokkolta a this objektumot, az elengedte.
Indítasz egy Thread-et, ami lokkolja a this-t, amíg fut.
A synchronize { this } {} meg fogja várni, hogy a thread véget érjen és csak aztán megy tovább.
Egyébként ennek a példának semmi értelme sincs, mert a Thread.join() sokkal elegánsabb és érthetőbb is.
egyebkent rad gondoltam mikor irtam
ha elolvastad volna 1szer is nyelv meghatarozasat tudnad:
van nehany muvelet amit mindig meg KELL csinalnia a vm-nek
mikor belep egy szinkronizalt block-ba
ezek kozul az egyik peldaul az, hogy a monitor owner volatile valtozoit kiirja a memoriaba....
ja, hogy mi is az a volatile valtozo?
[quote:4f3ac11293="Exit"]Azoknak meg, akik azt mondják, hogy Java-ban a hülyék programoznak: :lol:
Én szeretem a C-t és a C++-t, de azért egy Java... Az osztálykönyvtára, meg a platformfüggetlensége meg az, hogy fél óra alatt összehozok egy J2EE webservice-t, hozzá egy webes, egy J2SE-s és egy mobilos klienst... Ekkora produktivitást mikor kapok én a C++-tól?
Java-ban elvileg van destruktor, gyakorlatilag nincs. A finalize metódus meghívódik ugyan a GC-ben, de ez nem ér semmit.
Képzeld el:
- Egymás után megnyitsz fájlokat, de nem zárod be őket.
Mielőtt a GC elkezdene dolgozni, a maximálisan megnyitható fájlok
számát simán elérheted. Aztán nem érted, miért hal be a program.
Éppen ezért a fájlokat, stream-eket illik close()-olni, mert amíg a GC fel nem szabadítja őket, addig igen sok erőforrást elvisznek.
A java API dokumentációja meglehetősen jó. Olvasod a függvény dokumentációját, érted, hogy mit csinál. Jóformán kézenfekvő.
Ez a security dokumentációról nem teljesen mondható el. Sőt, nagyon kevés kézenfekvő dologgal találkozik az ember. Nem logikus és struktúrálatlan. Szóval megőszülsz, mire a legelső sort képes vagy megírni security-vel.
[quote:f03ebfd139="maszili"][quote:f03ebfd139="lokoto"]
Az egyetlen probléma, hogy jelen esetben nincs "adott környezet", sem "adott feladat"...
Nincs környezet? Nincs feladat?
Amikor megírsz egy programot akkor mit csinálsz?
Itt nem egy konkrét programról van szó, hanem általánosan állapítod meg, hogy a Java filozófiája rosszabb, mint a C++.
[quote:f03ebfd139="maszili"]
Pontosítsunk!
Valójában halvány fogalmad sincs, hogyan csinálja.
Ez így helyes.
Mivel OO -rol beszélünk nincs rá szükségem és nem is érdekel... nekem pont elég egy absztakciós szinttel feljebb lévő problémával foglalkozni.
Ha jól látom még mindig nem árultad el, hogy ennek fényében hogy raknád bele az egész számokat 1-től 500000-ig egy java.util.ArrayList-be.
[quote:791bb27225="Morzel"]Nos, bar en meg csak tanulom, de eddigi ismereteim alapjan a velemenyem:
Az IGAZI programozo programnyelvtol fuggetlenul gondolkodik, es nincs szuksege arra, hogy egyetlen programnyelven dolgozzon egesz elete soran.
En szerintem kicsit szetvalasztanam a programozast es a kodolast.
Morzel
Az igazi programozo gondolkodik es tanul, aztan:
-megtervezi/megvalositja sajat forditoprogramjat
-megtervezi/megvalositja sajat programozasi nyelvet
-megtervezi/megvalositja sajat architecturajat
[quote:60b375c0c7="Csab"]A java API dokumentációja meglehetősen jó. Olvasod a függvény dokumentációját, érted, hogy mit csinál. Jóformán kézenfekvő.
Ez a security dokumentációról nem teljesen mondható el. Sőt, nagyon kevés kézenfekvő dologgal találkozik az ember. Nem logikus és struktúrálatlan. Szóval megőszülsz, mire a legelső sort képes vagy megírni security-vel.
Most ugyanarról beszélünk? http://java.sun.com/docs/books/tutorial/security1.2/
A kérdésemre (hogy miért Security, mire kellett használni) még nem adtál választ, csak kikerülted...
[quote:68b53a8b0f="Frimen"]Nem látom sehol a két kodot..:))
Én legalább beirtam a sajátom "üssetek agyon, ha.." alapon, de Te eddig csak a levegőbe beszéltél. Amugy nekem már az a sorrol sorra ugyanaz enyhén szolva röhelyes..:-) Szerintem van itt egy két C-s programozo, aki szivesen vetne pár pillantást arra a kodra.. én meg a java-s oldalára.
[code:1:68b53a8b0f]
class QuickSort{
static final int NUM_ITEMS = 50000000;
int[] numbers=new int[NUM_ITEMS];
public void initTomb(){
numbers[0]=1;numbers[1]=1;
for(int i=2;i<NUM_ITEMS;i++)
numbers[i]=(numbers[i-1]*3+numbers[i-2]*2)%4561;
}
public void sort(int bal, int jobb){
int i, j;
int elvalaszto;
int temp;
elvalaszto=(int)numbers[(bal+jobb)/2];
i=bal;
j=jobb;
while (i<=j){
while (numbers[i]<elvalaszto) i++;
while (numbers[j]>elvalaszto) j--;
if (i<=j) {
temp=numbers[i];numbers[i]=numbers[j];numbers[j]=temp;
i++; j--;
}//if
}//while
if (bal<j) sort(bal,j);
if (i<jobb) sort(i,jobb);
}
Bizonyára lehet máshogyan is csinálni részleteket, de tagadhatatlanul működik, és az a "röhejes" sorról sorra kód is látszódik, ha nem tévedek.
[code:1:68b53a8b0f]
$ g++ quick_sort.cpp
$ ./a.out
24190
23991
23996
23996
[/code:1:68b53a8b0f]
[code:1:68b53a8b0f]
$ g++ -O1 quick_sort.cpp
$ ./a.out
13123
12837
12881
12887
[/code:1:68b53a8b0f]
[code:1:68b53a8b0f]
$ g++ -O3 quick_sort.cpp
$ ./a.out
11521
11407
11301
11352
[/code:1:68b53a8b0f]
[code:1:68b53a8b0f]
$ javac QuickSort.java
$ java -cp . -Xmx250M QuickSort
16612
16667
16620
16724
[/code:1:68b53a8b0f]
[code:1:68b53a8b0f]
$ javac QuickSort.java
$ java -cp . -Xmx250M -server QuickSort
12583
12480
12497
12515
[/code:1:68b53a8b0f]
A számokat mindenki értékelje maga. Én azt olvasom ki ebből, hogy nem látom okát annak, hogy ne használjak Java-t akkor, ha abban nagyságrendekkel hamarabb oldok meg feladatot. Futásidőben nem rosszabb lényegesen, a -O3 esetleg lekörözi, mondjuk 10%-kal, ami egyrészt hibahatár, másrészt ritkán szoktak -O3-at használni, ha jól tudom, optimalizáció nélkül pedig magasan jobb mint a C++.
Egy kis infó a gépemről:
[code:1:68b53a8b0f]
$ cat /proc/version
Linux version 2.6.12-10-386 (buildd@terranova) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 Fri Nov 18 11:51:02 UTC 2005
$ g++ --version
g++ (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
$ java -version
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 47
model name : AMD Athlon(tm) 64 Processor 3000+
stepping : 0
cpu MHz : 1808.124
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm
bogomips : 3579.90
[/code:1:68b53a8b0f]
Engem egyáltalán nem érdekel a GC dokumentációja, mert szerintem koncepcionálisan van eltolva az egész.
Persze úgy tudom, amikor a java-t készítették, akkor is komoly harc volt a rendes destruktor pártiak és a GC-sek között. Sajnos a GC-sek győztek, pedig szerintem GC nélkül is megoldhatták volna az egészet.
Lennének jól használható destruktorok a java-ban és 10-szer olyan szépen lehetne java-ban programozni.
Teljesen logikátlan viselkedés az, hogy vezérelheted az objektum létrehozását, viszont nem vezérled az elpusztítását.
A legszebben a QT csinálja.
A "delete objektum" hatására felszabadítja az objektumot és a rá mutató referenciákat kinullázza. Ezt egy destroyed() szignál emittálásával éri el.
QT-ben van rendes destruktor,
a szerkezete miatt pedig kevés a Free Memory Read fagyás is.
[quote:457499ee04="maszili"]Hát nekem ez akkor sem tetszik... :)
Szerintem egyszerűbb az osztály destruktorában felszabadítani az osztály objektuma által használt erőforrásokat. Ha ott megírtam a kódot (ami ugye egy rendes OO objektumhoz hozzátartozik mert hát én tudom hogy mit, mire és hogyan használok az osztályban) akkor elfelejthetem a problémát.
Így automatikusan felszabadul az összes felhasznált erőforrás pontosan akkor amikor megsemmisül az objektum.
Persze, csinalhatod igy is. Amig nem adom kozre az en kodjaimat (varhatoan hetvege), probald ki a kovetkezot: hozz letre 200.000.000 objektumot C++-ban es Javaban is, C++ hivd meg meg a delete-et is ra. Ne legyen az adott osztalyon belul semmi mas, csak maga az osztaly, hogy tenyleg semmilyen zavaro tenyezo ne legyen. Merd az idot :)
[quote:2bcfcfd796="bocs"][quote:2bcfcfd796="syntern"]0000: szabad memória blokk
0010: szabad memória blokk
0020: ide mutat egy pointer
0030: szabad memória blokk
A 00, és 10 összevonása triviális. Viszont a 00, 10, 30 egybevonása már nem az. A Java ezt tudja, és a C++ nem, implementációtól függetlenül, ugyanis nem tud mit mondani a pointerre.
.
.
.
Java-ban van választási lehetőséged, hogy GC-t vagy determinisztikus allokációt használsz ? Nincs.
C++-ban van? Igen, van.
C++ -os GC használata esetén lehetőséged van a heap fragmentáció megszüntetésére, például objektum áthelyezéssel, saját new operátor létrehozásával. Ennek meg kell fizetned az árát, pl refcount-ok / objektum referenciák lefoglalásával, fenntartásával, menedzselésével.
Figyi, irjal mar egy kis c++ forrast ide amit le tudok forditani gcc-vel, es amiben gc-t hasznalsz...
Mar ugyertem, hogy demonstrald, a GC valasztasi lehetoseget.
java-ban (JNI, C) amugy en irtam heap manager-t, pontosabban atraktam azt amit mar tobbszor hasznaltam video jatekokban (nem referencia szamlalosat), mert azt gondoltam, hogy sok kis memoria szeleten jobban tudok rendezni mint a gc, de sajna nem: a gc algoritmusa 1000 elem folott mar verte a nativ heap manager-emet
amugy referencia szamlalos memoria manager-t utoljara a DCOM-ban lattam 'nem mukodni'
ugyhogy vegulis az egy modern valasztas :)
A gc amugy determinisztikus realtime thread-eken...
[quote:5b5ce7e886="imp"]ugyan sose fejlesztettem nagyobb java programot, de kíváncsi vagyok miért.
Most idézhetném a mutassuk meg az übernyelv szintű csodákat, bár a Java nem übernyelv, hanem inkább überplatform. Nézd meg (http://java.sun.com/j2se/1.5.0/docs/api/index.html), hogy mekkora az a funkcionalitás, amely a platform része, és még csak összevadászni sem kell sehonnan. Igen, ezek nagy része C++-hoz is megvan ilyenolyan libraryn keresztül, de ami a Java erőssége, hogy ezeket nem kell vadászni, mindent készen kapsz, sokkal kevesebbet kell kódolni. Szerintem. De vegyünk egy példát:
Én Javaban nagyon rövid kódrészletekkel elkészítek egy SQL-OO vagy egy XML-OO bindingot (= séma ismeretében transzparens a konkrét instance feldolgozása, program szinten csak a szemantikai objektumot látod), és rögtön a feldolgozásra tudok koncentrálni, nem pedig az SQL hívásokra, vagy nem az XML parsingra, karakterkódolásokra. Ugyanezt nem tudom elmondani C++-ról, és még a feladat sem volt túl nagy egy átlagos projektemhez képest.
És mielőtt valaki belekötne: mindent meg lehet írni Assemblyben is, mégsem tartja senki túlságosan célszerűnek.
[quote:aff1ad33e8="Csab"]Az osztályszerkezete jól átgondolt és gyors is. Jobb, mint a java szerkezete.
Úgy érzem az előző hozzászólásom választ ad a gyorsaság kérdésére, az átgondoltság pedig, háát, maradjunk annyiban, hogy megszokás kérdése :)
[quote:aff1ad33e8="Csab"]Az egyetlen fájó pontom az STL (standard template library).
Sehol egy rendes dokumentáció nincs róla és keveset tud.
Java Collections API + Generics, és eddig még nem láttam olyan C++ osztálykönyvtárat (2 éve még kerestem, lehet azóta írtak egyet), ami felvenné vele a versenyt...
Volatile változó az, amelyik nincs cache-elve legalábbis C++-ban.
Szóval thread safe és több szál egyszerre birizgálhatja.
int d=3;
for(; d > 0; d-- )
/* ... */
mov edx,3
label:
...
dec edx
jnz label
Szóval a C fordító a d változót benyomja a edx regiszterbe sebességi okok miatt. Csakhát ezzel a cache varázslással igencsak nem lesz i thread safe. Ha másik szál elkezdené bizgetni, meglepődne az értékén.
[quote:77dfbb61a1="handler"][quote:77dfbb61a1="Morzel"]Nos, bar en meg csak tanulom, de eddigi ismereteim alapjan a velemenyem:
Az IGAZI programozo programnyelvtol fuggetlenul gondolkodik, es nincs szuksege arra, hogy egyetlen programnyelven dolgozzon egesz elete soran.
En szerintem kicsit szetvalasztanam a programozast es a kodolast.
Morzel
Az igazi programozo gondolkodik es tanul, aztan:
-megtervezi/megvalositja sajat forditoprogramjat
-megtervezi/megvalositja sajat programozasi nyelvet
-megtervezi/megvalositja sajat architecturajat
;-)
Szerintem aki ezt megcsinalja, az csak szimplan hulye. Nameg ido milliomos.
[quote:5773050c76="feledhetetlen"]OO ugyben az a helyzet, hogy a C++ kiveri a biztositekot very1st OO szabalynal: minden objektum
a tobbi mar nem is erdekes...
persze be lehet tartani a szabalyokat C++ban is, sot Cben is, akar el is lehet nevezni egy ilyen szabalyrendszert ObjectiveC-nek, de az attol meg patkolas
egy makro preprocessor-bol (aminek a C++ keszult) nem lesz jobb nyelv
Csakis egy JLS szintu alapra lehet varat epiteni http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
[quote:5773050c76="maszili"]
Vegyük azt a példát amikor egy függvény egy változó tartalmával végez műveleteket. Ha érték szerint megy az átadás akkor a függvénynek van egy saját példánya amit nyugodtan megváltoztathat a munkája során anélkül hogy az eredetit elrontaná... De a programozó megteheti hogy a változó értéke helyett egy mutatót ad át... a programozó DÖNT!
sajnos az alapertelmezes szerint erteket ad at, pedig imho az a ritkabb
szoval ha a programozo az alapesetet koveti, altalaban rosszul dont...
Azt nem lehetne, hogy megegyezunk, hogy ezt a cikket nem emlegetjuk tobbet? Nem mondom, hogy nincs igaza, de altalaban aki beidezi, annak fogalma sincs arrol, hogy milyen lehet Fortran66-ban programozni. En kiprobaltam es nem voltam tole boldog. Utana tobb, mint egy evig nyomtam a Fortran77-et es a Fortran90-et, de meg az sem gyozott meg rola, hogy emiatt nem kellene szeretnem a Pascalt.
Van az ertek szerinti parameteratadasnak is ertelme. Az igaz, hogy altalaban referenciat erdemes atadni, es jo lenne, ha az lenne a default (ugye-ugye a C++-ban csak azert van igy, mert mar C-ben is igy volt, szoval megint igazodunk egy 40 eves tervezesi hibahoz).
Valoban a Fortran ebbol a szempontbol jobb, mert mindent referencia szerint ad at... Viszont nem tud atadni semmit sem ertek szerint. Ez azt jelenti, hogy ha egy konstanst adsz at, akkor az futasidoben fog egy segfault-tal elszallni...
[quote:1f944297ff="maszili"][quote:1f944297ff="lokoto"]
...mert javában nem tudsz *a-t írni, ezért ha az a = b-t felüldefiniálod a = b.clone() funkcionalitására, nem tudod miként megvalósítani a jelenlegi értelemben vett a = b műveletet, azaz hogy az a változó a b változó által mutatott objektumra mutasson.
Itt érkeztünk el ahhoz a ponthoz hogy saját magad mondod ki azt, hogy a java filozófiája rosszabb mint a c++. :)
Fölösleges megkötésekkel gátat szab saját maga kifejező erejének...
Elég meredek a következtetésed. Ettől még semmi nem rosszabb semminél, így definiálták a szintaktikát és szemantikát.
Primitív típusok esetén a változó az értéket hordozza, egyébként pedig hivatkozás egy objektumra. Pont.
De ha már szintaktika: tedd a szívedre a kezed, és mond azt, hogy a pointeres csillagozásokat soha nem tévesztetted el, és az általad írt kódban biztosan nincsen ilyen jellegű hiba.
Mikor a Javában meghatároztak a nyelv alapjait, valószínűleg végignézték, hogy jelenleg mi van, minek mi a hibája, előnye, és megpróbáltak jobbat kihozni (az adott feladatra).
Ha jól tudom a C# szintaktikája és szemantikája nagyon hasonlít a javáéra, vajon véletlen, hogy ott sincsenek pointerek?
De ha Neked a C++ tetszik jobban, akkor láss csillagokat, szíved joga.
[quote:1f944297ff="maszili"]
[quote:1f944297ff="lokoto"]
Lehet, hogy csak megszokás, de az =-nek ez a funkcionalitása logikusan ábrázolt, és a clone() kitűnően kifejezi, hogy mélymásolást kell csinálni.
Korábbi hozzászólásomban (induljunk el a kályhától) kifejtettem hogy szerintem egyáltalán nem természetes a java filozófiája.
Ez szerintem a Te problémád :-)
Nekem nagyon is logikus, átlátható, egyszerű, robusztus.
Művelet:
a = b;
mélymásolás esetén:
a == b false
jelenlegi működés:
a == b true
Nekem a jelenlegi működés logikusabb. Neked nem? :-)
Nyilván az ==-et is felül lehetne definiálni, de lássuk be, hogy az egyik kolléga által felvázolt szemethalmazt kapjuk nagyon rövid idő alatt, mert senki nem fogja tudni, hogy mi micsoda.
Arról nem is beszélve, hogy a mélymásolás logikája egy egyszerű operátori logika komplexitását jóval meghaladja.
A java ilyen: vagy ne használd, vagy fogadd el. Nem kötelező.
A természetben is sokkal drágább művelet a klónozás, mint a rámutatás, a függyvény hívás beírásának macerája is erre akarja felhívni a figyelmet, hogy egy kis mély értelmet is vigyünk a dologba ;-)
[quote:df7a7e192e="bocs"]keverjük itt a szezont a fazonnal
milyen megoldás révén tudja ezt a Java? Plusz erőforrás felhasználás révén (GC CPU idő, objektum referenciák vagy refcount, dupla(!!) heap méret a szükségeshez képest, nemdeterminisztikus viselkedés).
Kiemelem a dupla heap méretet, mert a többi már korábban meg lett cáfolva :). Nem kell neki dupla heap méret, mert simán össze tudja tolni a memória-szeleteket (gondolj bele: minden memória-részt csak előre kell mozgatni, az üres terület a végén kialakul), ráadásul a dolog csak akkor fut, amikor nincs elég töredezettségmentes memória-darab (ilyenkor pl. a C++ akár el is szállhat outofmemory-val) és csak addig, amíg létre nem jön elegendő méretű memória, feleslegesen nem dolgozik.
[quote:eca7a993ba="Csab"]Képzeld el:
- Egymás után megnyitsz fájlokat, de nem zárod be őket.
Mielőtt a GC elkezdene dolgozni, a maximálisan megnyitható fájlok
számát simán elérheted. Aztán nem érted, miért hal be a program.
Nem értem, nem értem, nem értem... Vajon mi lehet rossz így a Javaban :) Csatlakozok Joelhez, szakmát kell váltanom...
[quote:4c15551331="waiter"]Nem tudom, mi a "programozási nyelv" pontos definíciója, de IMHO egy programozási nyelvnek általános érvényű (és nem egy specializált) eszköznek kellene lennie, legyen szó bármilyen szoftverfejlesztési feladat megoldásáról.
- waiter -
Hogy őszinte legyek, tulajdonképpen ennek semmi értelme. Mert ez alapján a processzor gépi nyelve ideális, hisz mindent megírhatsz benne - végül is minden megírt program gépi nyelven fut le.
Egy dolog van: megfelelő feladathoz a megfelelő nyelvet használni. Egy nyelv addig él, amíg van mire használni és használják is.
[quote:d951840de5="_Joel"][quote:d951840de5="bocs"]legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
Maximálisan teljesíthető Java-ban, akár néhány száz sorban: http://access1.sun.com/techarticles/ImagingApps/JImage.html
http://java.sun.com/developer/technicalArticles/Media/AdvancedImage/index.html
hát ez tökéletesen mellément, joel.
itt JPEG, BMP stb képformátumok beolvasásához vannak Javas library-k, ami abszolút merőleges a problémára, amit írtam.
a probléma megoldásához
1. szigorú memóriakontrollra van szükség , különben elvesztél. gondolj bele, egy CT kép simán jöhet akár 800MB-os is _egy darabban_, ezt nem kétszerezheted meg, nem bízhatod GC-re, mert véged van.
2. pixelenkénti float műveletekre van szükség kép simításhoz. kimondottan erre kérek referenciát, mert ilyen Java-ban abszolúte nem találtam.
3. gépek vezérlése, alacsonyszintű io, frame grabbelés. ne mondd, hogy java az adekvát erre a feladatra, mert nem lesz igaz.
4. aztán hogy numerikus algoritmusra használjak Fortrant? ccc
tudod mit, én inkább használok egy olyan c++ nyelvet, amivel igen jó teljesítménnyel bármilyen feladatot kényelmesen, garantáltan közel gépi kód hatékonysággal, de emellett nagyon magas szinten, elegánsan megoldok.
Ha kell, saját valódi template-es tárolóosztályokat gyártok, mert éppen olyan kell. A Java-t itt tudomásom szerint komolyan nem szokták emlegetni, mert template területen nevetséges.
Ezért tart ott ez az ország, ahol tart:)
erre pedig inkább nem írok semmit, ez viccnek álcázott szemellenzősség
[quote:e27b6846a9="Csab"]Engem egyáltalán nem érdekel a GC dokumentációja, mert szerintem koncepcionálisan van eltolva az egész.
Sokunk szerint pedig nincs eltolva, és az általa nyújtott kényelem (fejlesztési idő 90%-a) elnyomja a használatát övező hátrányokat (Java learning curve első fele). Tudom, téged nem érdekel... Attól még ismerek olyan Java-s fejlesztő kiscéget (4-5 ember), akik évi 60-70 milliót összelapátolnak ezzel a használhatatlan, lassú, bugos nyelvvel és platformmal...
Szándékosan kerültem ki. Ha túl sokat beszélek a munkámról, előbb utóbb kirúgnak. Az igazat megvallva próbálok általános információkat adni, mert munkahelyi dolgokat nem lehet csak úgy kiadni.
Ez hasonlítana ahhoz, mintha egy program forrását a főnökeim engedélye nélkül felraknám a netre.
Az általános policy az, hogy senkinek semmit, amíg engedélyt nem kapsz rá. Persze nem olyan munkahelyem van, ahol csak úgy kirúgják az embereket, de tenni sem akarok az ügyben, hogy ezen változtassanak.
[quote:5f9723b8f0="lokoto"]
Itt nem egy konkrét programról van szó, hanem általánosan állapítod meg, hogy a Java filozófiája rosszabb, mint a C++.
Igen...
[quote:5f9723b8f0="lokoto"]
Ha jól látom még mindig nem árultad el, hogy ennek fényében hogy raknád bele az egész számokat 1-től 500000-ig egy java.util.ArrayList-be.
Nem is fogom mert engem nem érdekel a java... én nem használom. Majd az megmutatja aki használja a java-t.
Részemről a vita lezárva!
Szerintem elég magyarázatot fűztem az érveimhez hogy érthető legyen. A további szócséplés fölösleges.
[quote:d1049a910a="Csab"]Szándékosan kerültem ki. Ha túl sokat beszélek a munkámról, előbb utóbb kirúgnak. Az igazat megvallva próbálok általános információkat adni, mert munkahelyi dolgokat nem lehet csak úgy kiadni.
Világos, de addig amíg csak ennyit árulsz el, az csapódik le, hogy nem értesz hozzá, nem akarsz érteni hozzá, de fikázod. Nem bántó szándékkal mondom, megértem a munkahelyi indokokat, de akkor inkább semmit, mint ilyen vagdalkozást... Szerintem.
objektív véleményem szerint ez túl szubjektív - bár épp ezért _szavazás_ ennek a mókának a neve!
szubjektív véleményem szerint viszont senki sem tudja milyen az objektív vélemény, ezért eleve nem lehet véleményem - régen volt egy ilyen szkifi (amit a minap elborzadtomra fittyet sem hányva sztoikus nyugalommal közöltek velem, hogy "szájfáj"-nak köll ejteni) sztori egyébként, amelyikben az "Isten kilencmilliárd neve" is benne volt.
NODE akkómá,
- egyszerűségében, tisztaságában a C.
- szépségében, eleganciájában az ObjC (ami kimaradt, ezért ebben a véleményemben nyilván nem sok emberrel osztozhatok).
- jól átgondoltsága és a nyelv szerkezetének konzisztenciája miatt, közepesen komoly és nem mánikusan sebesség-orientált fejlesztésekre Ruby.
- rendszeradminisztrációra pedig (VSZ) Perl. ha a netbsdről azt tartják, hogy elfut még a ceruzahegyezőn is, akkor a cpan lesz az ahol a ceruzahegyező átmérőjének a fokát beállító modulokat lehet majd fellelni (persze a tökösebbje nem vacakol, a shelles cpan a spanja és miután csíkokban a hitel-kártyájára kiszórta a cpan jóságot, egyetlen "install" és köszönömcsókolom).
de az is lehet, hogy napok óta csak kávén élek és megint baromságokat mondtam. jaboccs.
[quote:74998bc36c="syntern"]
Annyit kell erről tudni, hogy a JVM-ben a leghatékonyabb MergeSort van implementálva. .NET-esek figyelem: a .NET runtime QuickSortot használ...
jujj... ez fájt
ajánlott irodalom: Knuth
nincs olyan hogy "a" legggyorsabb. minden a feladat részleteitől függ.
általában a quicksort gyorsabb.
A java-t azért így írták meg, hogy könnyen és biztonságosan lehessen programozni.
Hallottam esetet, hogy programot akartak írni és felvettek jó csomó kezdő szoftverfejlesztőt, azokat pedig "minthogy a java úgyis biztonságos", ráirányították egy komoly kereskedelmi projektre.
Igen nagy befürdés lett az eredménye. Kezdő programozókkal nem lehet rendes rendszert írni. Ahhoz szakértelem kell. Én kezdő programozókat a tesztelésre helyezném, de nem egy rendkívül fontos kód megírására.
Szóval C++,C,java teljesen mindegy, de szakértelmet igényel. Ezt nem lehet megúszni.
Én személy szerint a szebb megoldásokat jobban értékelem, mint a biztonságos megoldást.
A gyakorlat egyébként az, hogy a legtöbb java osztálynak van destruktora, csak
- stop
- unregister
- shutDown
- terminate
...
névre hallgatnak. Amit akkor kell meghívnod, amikor SZERINTED! az objektum megszűnik. Ez igencsak közel áll a delete utasításhoz.
A java ilyen: vagy ne használd, vagy fogadd el. Nem kötelező.
Nem is használjuk, ha nem muszáj, de nektek is el kell fogadni azt, hogy valakinek a java-s körülményesség nem fekszik.
Egyébként kíváncsi lennék, hogy ha nincs 2D, 3D gyorsítás, milyen sebességre lenne képes a java.
C++ alatt lehet közvetlenül a memóriába írni és onnan olvasni minden különösebb erőfeszítés nélkül. Ráállítasz egy pointert a grafikus képernyőre és megy.
Java-ban meghívod a getPoint(...) metódust, aztán a setPoint(...)-ot is, ami... Vagy ráállítasz egy 1000x1000-es tömböt?
Mialatt C-ben egyszerű írás olvasással jóformán energiabefektetés nélkül pontonként szőrözhetsz a képen, addig ez java-ban nem megy.
Összegyűjtenek pár alapműveletet:
- kép kirakása
- kitöltés
- rajzolások
- scroll
- sprite-ok
...
Ezt C,C++-ban megírják, azt kész. Ha ennél több kell, használj C-t. Persze az is igaz, hogy a játékok 99%-ánál ez elég is.
[quote:fe0e87033e="syntern"]
Én például nagyon kedvelem azt, hogy Linux / Windows / Solaris alatt ugyanabban a fejlesztői környezetben, ugyanúgy lehet fejlesztenem, ami ugyanúgy néz ki eredményben mindenhol. Elméletileg a C++ is képes erre, a gyakorlatban elég nehéz kivitelezni (vagy nekem nem ment, mindenesetre nem próbáltam sokáig, hamar rátértem Javara).
Ha egy kézben van a fejlesztés több platformra, akkor átvihető lesz a kód. Ebből ered a java hordozhatósága. A C körül akkor kezdődtek a problémák, amikor a borland más utakat kezdett taposni, mint a szabványos cé. Ha Egy vállalkozás adná minden platformon a cé fordítókat, akkor nem lenne a hordozhatósággal baj.
Azért azt kicsit dúrvának tartom, hogy valaki az érték szerinti paraméterátadás lehetőségét tervezési hibának tartja. :roll:
Egy másik téma, hogy mintha némelyek fejében kicsit pontatlan kép élne a C++-ról.
A C++-t olyan általános programozási nyelvnek tervezték, ami az oo tervezést, fejlesztést _is_ jól támogatja, de nem kötelező használni az oo eszközeit, és nem az alapjaitól oo, ellentétben a jávával.
[quote:19f493315d="bocs"]
hát ez tökéletesen mellément, joel.
itt JPEG, BMP stb képformátumok beolvasásához vannak Javas library-k, ami abszolút merőleges a problémára, amit írtam.
Nézd meg jobban. Pl ez szerinted mit csinal (nem en irtam, egy tech tip-bol ollozva: http://java.sun.com/developer/JDCTechTips/2005/tt0601.html
[code:1:19f493315d]
public class My3x3JAIKernels {
public static KernelJAI getkernel(int corner,
int edge,
int identity) {
float[] kernel = new float[9];
int sum = corner * 4 + edge * 4 + identity;
if (sum == 0) sum = 1; // to avoid dividing by zero
for (int i = 0; i < 9; i++) {
kernel[i] = (corner * CORNER[i]
+ edge * EDGE[i]
+ identity * IDENTITY[i]) / sum;
}
return new KernelJAI(3, 3, kernel);
}
}
1. szigorú memóriakontrollra van szükség , különben elvesztél. gondolj bele, egy CT kép simán jöhet akár 800MB-os is _egy darabban_, ezt nem kétszerezheted meg, nem bízhatod GC-re, mert véged van.
Miert biznad GC-re? Tisztaban vagy a GC mukodesevel, vagy csak bizonyosan nagy tapasztalattal rendelkezo C++ programozokent halvany lila elkepzeleseid vannak rola?
2. pixelenkénti float műveletekre van szükség kép simításhoz. kimondottan erre kérek referenciát, mert ilyen Java-ban abszolúte nem találtam.
A fenti konvolucios matrix(ok) alkalmazasa egy kepre megfelel ennek a kriteriumnak, vagy keressek masikat?
3. gépek vezérlése, alacsonyszintű io, frame grabbelés. ne mondd, hogy java az adekvát erre a feladatra, mert nem lesz igaz.
Gépek vezérlése: Ha RT kovetelmenyek vannak, ott valoban gond lehet a GC nem determinisztikus volta, bar az 5-os JVM ergonomics kapcsoloi ota ez talan kezelheto (foleg ha csak soft RT kovetelmenyek vannak).
Alacsonyszintu io: mire gondolsz, konkretan? Ugy erted, hogy Java-bol lassabban lehet irni ugyanazt a diszket? Vagy micsoda?
Frame grabbeles: Java Media Framework? Amikor utoljara neztem akkor eppen viszonylag keves formatumot ismert, de a plugin architektura miatt ez csak vendor tamogatas kerdese... (mondjuk ez kisse tenyleg remenytelen - bar a DVB-MHP es J2ME hazassag miatt meg lehet belole valami).
4. aztán hogy numerikus algoritmusra használjak Fortrant? ccc
Miért, az iparágban, HPC körökben, numerikus problémákra ez a de facto ipari szabvány nyelv, mind a mai napig. Nagy mátrixok szorozgatására a legkényelmesebb... legalábbis az öreg szakik szerint, én meg hiszek nekik.
tudod mit, én inkább használok egy olyan c++ nyelvet, amivel igen jó teljesítménnyel bármilyen feladatot kényelmesen, garantáltan közel gépi kód hatékonysággal, de emellett nagyon magas szinten, elegánsan megoldok.
Nyugi, a világ másik fele ugyanezért használ Java-t, és abszolúte nem fikázza a C++ programozókat amiért ugyanezt teszik. Valamiért a C/C++ világ jön mindig azzal, hogy a Java ugyanolyan lassú és sz@r mint 10 éve volt, holott nem.
Ha kell, saját valódi template-es tárolóosztályokat gyártok, mert éppen olyan kell. A Java-t itt tudomásom szerint komolyan nem szokták emlegetni, mert template területen nevetséges.
Na pont erről a fikázásról beszélek. "szokták", "nevetséges". Figyelj, tényleg nem sajnálom tőled a C++- tudásodat, egyelőre nagyon jól meg lehet élni belőle, de attól még nem kellene leszólni egy másik nyelvet/platformot mindenféle mondvacsinált indokkal.
Ezért tart ott ez az ország, ahol tart:)
erre pedig inkább nem írok semmit, ez viccnek álcázott szemellenzősség
Nem, ez sajnos tapasztalat. Clipperben és FoxProban készült ügyviteli programokkal van tele az ország, mert a "szakik" ahhoz értenek a mai napig.
[quote:f889a55970="wwrreecckk"]-server kapcsoló, gondolom, csak sun jvm része, mert mi IBM-es jdk-t használunk és ott nem nagyon látszik működni.
Amúgy szerencsétlen IBM jdk gyorsabb lenne, mint a SUN, vagy tévedek?
Az IBM a Sun JVM-et licenceli, és abba heckel kódot. Tipikusan azért, hogy fusson AIX-en, de lehet benne teljesítmény-tuning is.
Ha valaki még érdeklődik alternatív JVM iránt, akkor BEA JRockit.
bocs ha kicsit hosszu de kerdeztel, es valahogy azt erzem:
lehet tenyleg erdekel
Szoval: 800MB az c++ is 800MB
pixel muveletek:
java.awt.image.RasterOp
peldaul a ConvolveOp
ez float-tomboket vesz at mint azt lathatod is a jdk-hoz mellekelt
demoban: ${ahol a jdk van}/demo/jfc/Java2D/src/java2d/demos/Images/ImageOps.java
...
float data[][] = { {0.1f, 0.1f, 0.1f, // 3x3 blur
0.1f, 0.2f, 0.1f,
0.1f, 0.1f, 0.1f},
{-1.0f, -1.0f, -1.0f, // 3x3 sharpen
-1.0f, 9.0f, -1.0f,
-1.0f, -1.0f, -1.0f},
{ 0.f, -1.f, 0.f, // 3x3 edge
-1.f, 5.f, -1.f,
0.f, -1.f, 0.f},
{-1.0f, -1.0f, -1.0f, -1.0f, -1.0f, // 5x5 edge
-1.0f, -1.0f, -1.0f, -1.0f, -1.0f,
-1.0f, -1.0f, 24.0f, -1.0f, -1.0f,
-1.0f, -1.0f, -1.0f, -1.0f, -1.0f,
-1.0f, -1.0f, -1.0f, -1.0f, -1.0f}};
for (int j = 0; j < data.length; j++, i++) {
biop[i] = new ConvolveOp(new Kernel(dim[j][0],dim[j][1],data[j]));
}
...
pixel image transform muveletekre az
java.awt.geom.AffineTransform
The AffineTransform class represents a 2D affine transform that performs a linear mapping from 2D coordinates to other 2D coordinates that preserves the "straightness" and "parallelness" of lines. Affine transformations can be constructed using sequences of translations, scales, flips, rotations, and shears.
Such a coordinate transformation can be represented by a 3 row by 3 column matrix with an implied last row of [ 0 0 1 ]. This matrix transforms source coordinates (x, y) into destination coordinates (x', y') by considering them to be a column vector and multiplying the coordinate vector by the matrix according to the following process:
[ x'] [ m00 m01 m02 ] [ x ] [ m00x + m01y + m02 ]
[ y'] = [ m10 m11 m12 ] [ y ] = [ m10x + m11y + m12 ]
[ 1 ] [ 0 0 1 ] [ 1 ] [ 1 ]
[quote:28fe9ad692="bocs"][quote:28fe9ad692="_Joel"][quote:28fe9ad692="bocs"]legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
Maximálisan teljesíthető Java-ban, akár néhány száz sorban: http://access1.sun.com/techarticles/ImagingApps/JImage.html
http://java.sun.com/developer/technicalArticles/Media/AdvancedImage/index.html
hát ez tökéletesen mellément, joel.
itt JPEG, BMP stb képformátumok beolvasásához vannak Javas library-k, ami abszolút merőleges a problémára, amit írtam.
a probléma megoldásához
1. szigorú memóriakontrollra van szükség , különben elvesztél. gondolj bele, egy CT kép simán jöhet akár 800MB-os is _egy darabban_, ezt nem kétszerezheted meg, nem bízhatod GC-re, mert véged van.
2. pixelenkénti float műveletekre van szükség kép simításhoz. kimondottan erre kérek referenciát, mert ilyen Java-ban abszolúte nem találtam.
3. gépek vezérlése, alacsonyszintű io, frame grabbelés. ne mondd, hogy java az adekvát erre a feladatra, mert nem lesz igaz.
4. aztán hogy numerikus algoritmusra használjak Fortrant? ccc
tudod mit, én inkább használok egy olyan c++ nyelvet, amivel igen jó teljesítménnyel bármilyen feladatot kényelmesen, garantáltan közel gépi kód hatékonysággal, de emellett nagyon magas szinten, elegánsan megoldok.
Ha kell, saját valódi template-es tárolóosztályokat gyártok, mert éppen olyan kell. A Java-t itt tudomásom szerint komolyan nem szokták emlegetni, mert template területen nevetséges.
Ezért tart ott ez az ország, ahol tart:)
erre pedig inkább nem írok semmit, ez viccnek álcázott szemellenzősség
Nem fikázom a java-t, csak leírom, hogy vannak hátulütői.
Lehet, hogy ez néha keményre sikeredett, de szerintem a java még messze nem tökéletes.
Amikor van választásom, akkor C++-t használok, kivétel, ha netre akarok felrakni valami appletet, vagy szükségem van a könyvtári függvényeire (pl. XML parser) és nem akarok QT-t használni, mert az túl nagy ágyú lenne.
[quote:cde6ca554e="snq-"][quote:cde6ca554e="fdavid"][quote:cde6ca554e="_Joel"]Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
Hat most nem tudom, hogy ez marketing duma, vagy csak szimplan nagyotmondas. Egyik sem tul szimpatikus.
egyik sem, nagyon is kozel all az igazsaghoz (nyilvan a senki tulzas, mert mindig vannak viccharoldok)
Ugy kellett volna irni, hogy "senki nem kezd el fejleszteni". A gnome-osok sem veletlenul probalgatjak osszehozni linuxra a monot meg a c#-ot...
[quote:55ef194daa="syntern"] A Java teljesítménye (-server kapcsoló) a legtöbb esetben megközelíti ugyanazt a kódot megvalósító C++ programot a Hotspotnak köszönhetően, valamint az erősen rekurzív esetekben jócskán meg is előzi. (5-ös Java, gcc, -O1, 2, 3-mal is mérve, a -O3 már majdnem olyan jól teljesített mint a Java) A mérések kizárólag memória-kezelést és algoritmus végrehajtást mértek, ugyanaz a C++ kód és Java kód futott, feladatonkénti mérési idő 30-45 mp, hogy ne legyen nagy hiba az óra pontatlanságából. Sok esetben gyanítjuk, hogy a Hotspot optimalizálása alig kezdett el működni.
Azért kíváncsi lennék arra a C++ és Java kódra. Saját tapasztalatom, hogy C++-ban is lehet eszméletlenül lassú kódot írni, nem mindegy ugyanis, hogy mennyi tapasztalata van a programozónak. A Java hatalmas előnye szerintem, hogy a hátulgombolós programozók is tudnak vele boldogulni, mert rengeteg dolgot levesz a programozó válláról. Persze a hátránya is ugyanez :)
Amúgy én speciel, C és C++ nyelveket favorizáló programozóként, örülök ennek a nagy Java mániának, mert egyre több programozó már csak Javában tud gondolkodni, amellett, hogy egyre több a Javában csalódott potenciális megrendelő a rengeteg bukott Javás project miatt.
Ezért aztán folyamatosan felértékelődik a C és C++ tudás.
Úgyhogy nyomjátok csak, istenítsétek! Örülünk neki. Nekunk az is elég, ha kiszolgáljuk a "Javában eszükbe ne jusson kódolni!" klienseket. Szerencsére egyre többen vannak, ez tapasztalat.
És üdvözlöm a hátulgombolósokat alkalmazó cégeket :)
ajánlott irodalom: Knuth
nincs olyan hogy "a" legggyorsabb. minden a feladat részleteitől függ.
általában a quicksort gyorsabb.
Oké, akkor pontosítok a wikipedia segítségével:
Mergesort has an average and worst-case performance of O(n log n). In the worst case, merge sort does about 30% fewer comparisons than quicksort does in the average case; thus merge sort very often needs to make fewer comparisons than quicksort. In terms of moves, merge sort's worst case complexity is O(n log n)--the same complexity as quicksort's best case, and merge sort's best case takes about half as much time as the worst case.
However, merge sort performs 2n - 1 method calls in the worst case, compared to quicksort's n, thus has roughly twice as much recursive overhead as quicksort. Mergesort's most common implementation does not sort in place, meaning memory the size of the input must be allocated for the sorted output to be stored in. Sorting in-place is possible but requires an extremely complicated implementation.
Although merge sort can sort linked lists, it is also much more efficient than quicksort if the data to be sorted can only be efficiently accessed sequentially, and is thus popular in languages such as Lisp, where sequentially accessed data structures are very common. Unlike some optimized implementations of quicksort, merge sort is a stable sort as long as the merge operation is implemented properly.
More precisely, merge sort does between ⌈ n log n - n + 1 ⌉ and ⌈ n log n - 0.914·n ⌉ comparisons in the worst case.
[quote:f7eff28135="Csab"]Ezt a java-ban is meg lehetne szebben csinálni.
Amikor a referenciaszámláló eléri a nullát (körökörös referenciát is figyelembe véve) -> meghívódik egy destruktor
Szerintem érdemes lenne mélyebben megnézned a Java GC-t. Leegyszerűsítve persze hasonlóképpen működik, csak nem mindig nézi a "referenciaszámlálót", csak akkor, amikor éppen elfogy a szabad memória...
[quote:35e1628ac9="Csab"]Volatile változó az, amelyik nincs cache-elve legalábbis C++-ban.
Szóval thread safe és több szál egyszerre birizgálhatja.
int d=3;
for(; d > 0; d-- )
/* ... */
mov edx,3
label:
...
dec edx
jnz label
Szóval a C fordító a d változót benyomja a edx regiszterbe sebességi okok miatt. Csakhát ezzel a cache varázslással igencsak nem lesz i thread safe. Ha másik szál elkezdené bizgetni, meglepődne az értékén.
De java-ban fogalmam sincs mi az a volatile.
nem a cache maga problema
nem is arra szeretnenk garanciat, hogy minden muveletet csak az memoria valtozon csinaljon
azt lehet normalisan elvarni, hogy a volatile valtozok a vegrehajtasi sorrendbe irododjanak vissza a memoriab
vagyis:
[code:1:35e1628ac9]
public class VolatileTest
{
int a,b;
void inc()
{
a++;
b++;
}
}
[/code:1:35e1628ac9]
eseten elofordulhat, hogy egy masik thread b-t nagyobbnak latja mint a-t
de ha ez
[code:1:35e1628ac9]
public class VolatileTest
{
volatile int a,b;
void inc()
{
a++;
b++;
}
}
[/code:1:35e1628ac9]
akkor biztosak lehetunk hogy a mindig >= b-vel
a kerdesem [code:1:35e1628ac9]synchornized(this){}[/code:1:35e1628ac9] pedig azert nem trivialis, mert a MIKOR??? erzekeny pontot tudja meghatarozni
mivel a volatile csak a sorrendiseget biztositja, azt nem, hogy az a,b memoria cimekre mikor irodik be a es b erteke...
viszont, ha beiktatsz egy [code:1:35e1628ac9]synchornized(this){}[/code:1:35e1628ac9] sort akkor biztos lehetsz, hogy a tobbi thread is azt latja amit te vegre hajtasi szalad
800 MB-ra visszaterve: es tenyleg egyszerre memoriaban kell tartani az egesz kepet? Mekkora konvolucios matrix-szal dolgozol a kepsimitasnal?
JAI eseten ugyanis:
"The operation chain itself does not, however, handle the way image data are managed in the source and sink portions of the chain as this cannot always be controlled by the API itself. For example, if the image source is a file which is not tiled, then the entire image will be loaded. If a tiled source image file is used (e.g., tiled TIFF or FlashPIX), then only those tiles required to execute the operation chain will be read from the disk.
Similarly, at the data sink end of a chain, e.g., the display, if the entire image is requested and held in memory then that will provoke computation of all tiles in all intermediate operations in the chain and consequently reading of the entire image from disk. The data sink will be most efficient if it requests only those tiles that it needs and uses some kind of efficient algorithm for disposing of the destination tiles that it does not need, e.g., those neither being displayed nor adjacent to tiles being displayed.
To reduce RAM usage even further you also have the option of implementing your own tile cache which uses an alternate type of backing storage for the tiles in the cache, e.g., a disk file or a database. Such an approach may lower execution speed in some cases but there are always tradeoffs. There is also a mechanism to replace the "Least Recently Used" algorithm with a custom implementation via the tile cache metric and tile comparator features. "
Szoval ha tiled image lehet az input, akkor nem kell az a 800 MB... vagy ha csak a kepernyon levo reszt eleg konvolalni. Nem tudom mit csinal pontosan az alkalmazasod, csak talalgatok.
[quote:115d6b2edb="Csab"]Kiegészíteném azzal, hogy az osztály tartalmaz egy boolean stopped mezőt.
Oké, beidézel egy példát, amely a programozói nem-tudás példája, de ennek semmi köze ahhoz, hogy a Java mint nyelv jó-e vagy sem. Ha pl. a Whitespace nyelvet idézed be, akkor megértem, de itt nem erről van szó. Ugyanezt a kódot átírom C++-ba, és mondjam azt, hogy milyen rossz a C++, meg lehet benne csinálni egy boolean stopped mezőt?
[quote:afc1c9634a="Csab"]Amikor van választásom, akkor C++-t használok, kivétel, ha netre akarok felrakni valami appletet, vagy szükségem van a könyvtári függvényeire (pl. XML parser) és nem akarok QT-t használni, mert az túl nagy ágyú lenne.
tinyxml, xerces-c? ;)
van "platformfüggetlen" szálkezelés is (boost-ban) :)
(nem vagyok biztos, hogy reflection egyáltalán megvalósítható lenne-e a C++ oo képességei mellett)
Úgy néz ki, meg kell barátkozni a gondolattal, hogy egy pascal nem fér bele az első 10 választási lehetőségbe (mondjuk annyi szavazatot kapott volna, mint a lisp valszeg).
Ez van.
A jelöltek kiválasztásánál lehetett volna erősködni.
Egyébként én is szeretem, sokat programoztam benne, és most is kell néha (delphi).
syntern:
Meggyőző a qsort példa. Látszik, hogy ebben a példádban tökéletesen elhanyagolható sebesség-különbség jön ki C++ és Java között.
Régebben én is nézegettem a Javát, pont a kényelmessége miatt, hogy minden együtt van, nem kell libeket vadászgatni és az eltérő API-k és konvenciók miatt szívni, stb.
Ki is próbáltam, a fordító gyors, az egyszerű programok gyorsan futnak.
Azt viszont én pl. sehogy nem tudom lenyomni a felhasználó torkán, hogy GUI esetén egy bonyolultabb ablak megjelenése nem történik meg a másodperc töredéke alatt. Ha egy ablak 2 tizedmásodperc alatt jelenik meg, az már egy profi felhasználónak a használhatatlanság határa.
Azt sem lehet elmagyarázni szegény felhasználónak, hogy a program azért gondolkozik néha másodpercekig, mert olyankor szemetet gyűjt.
Egyszerűen nem lehet dolgozni egy komolyabb Java alkalmazással. Nem értem, miért nem a GUI gyorsításával foglalkoznak a SUN-nál?
Mellesleg most épp egy Java alkalmazás kiváltására írok programot C++-ban, mert a Java cuccos tökéletesen használhatatlanul lassú tetü.
Amennyiben a this változó lokkolva van, akkor vár.
Ha nincs lokkolva, keresztül megy rajta.
Mit lehet elmondani synchronized( this ) után?
- Aki a meghívásig lokkolta a this objektumot, az elengedte.
Indítasz egy Thread-et, ami lokkolja a this-t, amíg fut.
A synchronize { this } {} meg fogja várni, hogy a thread véget érjen és csak aztán megy tovább.
Egyébként ennek a példának semmi értelme sincs, mert a Thread.join() sokkal elegánsabb és érthetőbb is.
Ezzel "csak" annyi a baj, hogy a synchronize nem csak thread joinra hasznalhato, annal sokkal tobbet jelent. De kar ezt ragozni akkor, amikor erzelmi kerdes egy programozasi nyelv kivalasztasa :)
[quote:9e186c8b89="_Joel"]Egy JVM-ben elvileg csak egy elszabadult thread miatt lehetnek memory leak-jeid (vagy mondjuk akkor ha ugy programozol JDBC-t, hogy nem olvastal utana annak, hogy mit is csinalsz es elfelejted close-olni a statementedet meg a tobbit)
Joel már hiányoltalak!:-)
Viszont ismét bele kell kötnöm abba amit mondsz, mert hülyeség.
Egy tucatnyi modon lehet a Java-ban olyan programot irni, ami memory leak-es.
Ajánlom figyelmedbe az alábbi linket:
http://www.javaworld.com/javaworld/javatips/jw-javatip79.html
Ez ez csak egy példa a sok közül! Tudnék Neked még jópárat mutatni!
Fri
[quote:e8b57dfe0b="_Joel"]
Nézd meg jobban. Pl ez szerinted mit csinal (nem en irtam, egy tech tip-bol ollozva: http://java.sun.com/developer/JDCTechTips/2005/tt0601.html
hm
megnéztem, tényleg tud előre definiált N darab műveletet 2D-ben.
nekem speciel 3D kell, és speciális szűrők kellenek, úgyhogy számomra értéke... csekély.
egyébként a Sun oldalán írják, hogy
"The Java Advanced Imaging API may be run without any native code, i.e., without the code which provides native acceleration."
ja hogy natív kód van mögötte... így könnyű.
[quote:e8b57dfe0b="_Joel"]
1. szigorú memóriakontrollra van szükség , különben elvesztél. gondolj bele, egy CT kép simán jöhet akár 800MB-os is _egy darabban_, ezt nem kétszerezheted meg, nem bízhatod GC-re, mert véged van.
Miert biznad GC-re? Tisztaban vagy a GC mukodesevel, vagy csak bizonyosan nagy tapasztalattal rendelkezo C++ programozokent halvany lila elkepzeleseid vannak rola?
hm
lehet hogy nem voltam elég explicit.
tehát bejön szabványos képként 800MB egyben allokálva.
feladat: szabdald szét frame-ekre /egyedi képekre/, úgy hogy azok külön objektumok legyenek, külön kezelhetők, törölhetők stb, de közben ne fuss ki a RAM-ból.
Java-s megoldás van triviális?
[quote:e8b57dfe0b="_Joel"]
2. pixelenkénti float műveletekre van szükség kép simításhoz. kimondottan erre kérek referenciát, mert ilyen Java-ban abszolúte nem találtam.
A fenti konvolucios matrix(ok) alkalmazasa egy kepre megfelel ennek a kriteriumnak, vagy keressek masikat?
magad alatt vágtad a fát. a fenti ugyanis natív library-t használt, gyakran alkalmazott, "közönséges" szűrőkkel. nakünk viszont spéci szűrőink vannak, amiknek bezony a képbiteken natív kódban végig kell tekerni. erre Java-t javasolnál?
[quote:e8b57dfe0b="_Joel"]
3. gépek vezérlése, alacsonyszintű io, frame grabbelés. ne mondd, hogy java az adekvát erre a feladatra, mert nem lesz igaz.
Gépek vezérlése: Ha RT kovetelmenyek vannak, ott valoban gond lehet a GC nem determinisztikus volta, bar az 5-os JVM ergonomics kapcsoloi ota ez talan kezelheto (foleg ha csak soft RT kovetelmenyek vannak).
ja bocs én éles projektben nem akarok early adopter lenni.
[quote:e8b57dfe0b="_Joel"]
Alacsonyszintu io: mire gondolsz, konkretan? Ugy erted, hogy Java-bol lassabban lehet irni ugyanazt a diszket? Vagy micsoda?
spéci digitalizáló kártyákról adat io
[quote:e8b57dfe0b="_Joel"]
Frame grabbeles: Java Media Framework? Amikor utoljara neztem akkor eppen viszonylag keves formatumot ismert, de a plugin architektura miatt ez csak vendor tamogatas kerdese... (mondjuk ez kisse tenyleg remenytelen - bar a DVB-MHP es J2ME hazassag miatt meg lehet belole valami).
early adopter
[quote:e8b57dfe0b="_Joel"]
4. aztán hogy numerikus algoritmusra használjak Fortrant? ccc
Miért, az iparágban, HPC körökben, numerikus problémákra ez a de facto ipari szabvány nyelv, mind a mai napig. Nagy mátrixok szorozgatására a legkényelmesebb... legalábbis az öreg szakik szerint, én meg hiszek nekik.
nagy félreértés. Fortrant bocs nem bántani.
arra utaltam, hogy nyomatjuk, hogy mindenre Java, Java... esetleg néha kis Fortran, meg más célra ez, meg az...
akkor már meg is érkeztünk a dolog lényegéhez: nem mindenre jó a Java.
[quote:e8b57dfe0b="_Joel"]
még nem kellene leszólni egy másik nyelvet/platformot mindenféle mondvacsinált indokkal.
ööö mondvacsinált, ha a munkakörömben előforduló feladatok nagy százalékára nem alkalmas?
/de isten biz, én nem döglök meg egyik nyelvért se, csak b.sza a csőrömet ez a "gumimaci jó, gumimaci szép, építsük fel belőle a golden gate hidat" effektus/
[quote:454d616afa="Csab"]
C++ alatt lehet közvetlenül a memóriába írni és onnan olvasni minden különösebb erőfeszítés nélkül. Ráállítasz egy pointert a grafikus képernyőre és megy.
Java-ban meghívod a getPoint(...) metódust, aztán a setPoint(...)-ot is, ami... Vagy ráállítasz egy 1000x1000-es tömböt?
Mialatt C-ben egyszerű írás olvasással jóformán energiabefektetés nélkül pontonként szőrözhetsz a képen, addig ez java-ban nem megy.
Összegyűjtenek pár alapműveletet:
- kép kirakása
- kitöltés
- rajzolások
- scroll
- sprite-ok
...
Ezt C,C++-ban megírják, azt kész. Ha ennél több kell, használj C-t. Persze az is igaz, hogy a játékok 99%-ánál ez elég is.
a MemoryImageSource pontosan egy tombon mukodik, tessek elolvasni!
egy nokia6600 siman fut olyan alpha-s (32bit/pixel) "sprite?" kirakom ami runtime decompresszal(1:3) + tukroz + flippel, igen javaban
es ebben a leglassabb cpu van az s60-as sorozatbol...
[quote:7fe3d4a2d9="zsolt"]Egyszerűen nem lehet dolgozni egy komolyabb Java alkalmazással. Nem értem, miért nem a GUI gyorsításával foglalkoznak a SUN-nál? Mellesleg most épp egy Java alkalmazás kiváltására írok programot C++-ban, mert a Java cuccos tökéletesen használhatatlanul lassú tetü.
- lehet dolgozni, ha jól van megírva (korábban már hoztam a MagicDraw példát: nagy, Swing, mégis gyors - nekem legalábbis nem lassú)
Feature: Improve Windows Look and Feel
* Use Microsoft's API for rendering portions of components.
* Ensure Swing's Windows look and feel looks good on Longhorn.
Feature: Improve GTK Look and Feel
* Use GTK API for rendering portions of components (6185456).
* Bring Swing's GTK file chooser up to date with recent changes to GTK's file chooser (5090726).
- használhatatlan Java program: ott valamit a programozó rontott el, nem a nyelv hibája (láttam már nagyon rossz Swing programokat én is, de láttam már elegáns és teljesítő Swing programokat is).
[quote:cf70032d4f="edaile"]Egy programnyelvet azért szeretek, mert mindent meg lehet benne csinálni.
Ilyen a Java, Perl, PHP és a C++.
A Java-t én kihagynám a helyedben, mert azzal biztosan nem
lehet megcsinálni mindent. Nem kivántam még senkinek, de
remélem a pokolra jut aki kitalálta, hogy a memoria kezeléshez
hozzá se férjen a programozó.
Hogy dögölne meg.
Fri
[quote:c5d1188416="bocs"]
megnéztem, tényleg tud előre definiált N darab műveletet 2D-ben.
nekem speciel 3D kell, és speciális szűrők kellenek, úgyhogy számomra értéke... csekély.
Jaj ne legyél már ilyen.
http://www.developer.com/java/other/article.php/3522711
Nézd meg a sorozat korábbi cikkeit is.
[quote:c5d1188416="bocs"]
egyébként a Sun oldalán írják, hogy
"The Java Advanced Imaging API may be run without any native code, i.e., without the code which provides native acceleration."
ja hogy natív kód van mögötte... így könnyű.
Miért, szerinted a JVM-et miben írják?:))
tehát bejön szabványos képként 800MB egyben allokálva.
feladat: szabdald szét frame-ekre /egyedi képekre/, úgy hogy azok külön objektumok legyenek, külön kezelhetők, törölhetők stb, de közben ne fuss ki a RAM-ból.
Java-s megoldás van triviális?
Igen. JAI-val beload-olni. Automatikusan ezt csinálja, amit leírták anélkül, hogy te tudnál róla (jó ezt fel lehet fogni negatívumként is - de ha tudsz róla akkor meg befolyásolni is tudod, hogy ezt hogyan tegye).
magad alatt vágtad a fát. a fenti ugyanis natív library-t használt, gyakran alkalmazott, "közönséges" szűrőkkel. nakünk viszont spéci szűrőink vannak, amiknek bezony a képbiteken natív kódban végig kell tekerni. erre Java-t javasolnál?
Persze, hogy magam alatt vágom a fát, ezt már többször is elmondtad. Sőt, hülye is vagyok, de ezt meg vállalom. De mutathatnál egy ilyen spéci szűrőt amit nem lehet konvolúciós mátrixként felírni, illetve amit nem lehet Java-ban ugyanúgy leimplementálni (egy 800 mb meretu int array az Javaban sem mas, mint egy 800 mb meretu int array).
ja bocs én éles projektben nem akarok early adopter lenni.
JNI-vel akár, de meoldható. Tudom, natív kód, fujjj...
nagy félreértés. Fortrant bocs nem bántani.
arra utaltam, hogy nyomatjuk, hogy mindenre Java, Java... esetleg néha kis Fortran, meg más célra ez, meg az...
akkor már meg is érkeztünk a dolog lényegéhez: nem mindenre jó a Java.
Ki mondta, hogy mindenre jó a Java? Hiába van regexp api, csak perl-hez nyúlok, ha szöveget akarok feldolgozni...
ööö mondvacsinált, ha a munkakörömben előforduló feladatok nagy százalékára nem alkalmas?
Próbáltátok és nem ment, gondolom... Mások is próbálták úgy látom:
http://www.escorp.com/np_TeraMedica.asp
TeraMedica Healthcare Technologies has developed a revolutionary system that intelligently manages digital medical images for the healthcare enterprise. Imaging exams range from kilobytes to gigabytes and may include thousands of images. This poses unique challenges for processing transactions in a scalable manner, especially considering the requirement that the system must scale to millions of exams per year and hundreds of concurrent users. The system has a distributed architecture, utilizing several open source technologies such as JBoss, Hibernate, and JORAM.
Gondolom ez nem egészen ugyanaz a feladat, mint a tiétek. Nagyobb lélegzetűnek tűnik, és azt írják az egész Java...
/de isten biz, én nem döglök meg egyik nyelvért se, csak b.sza a csőrömet ez a "gumimaci jó, gumimaci szép, építsük fel belőle a golden gate hidat" effektus/
[quote:b306818594="Csab"]Nem fikázom a java-t, csak leírom, hogy vannak hátulütői. Lehet, hogy ez néha keményre sikeredett, de szerintem a java még messze nem tökéletes.
Mi meg leírtuk, hogy miért nincs igazad, és hogy milyen részeit nem vetted figyelembe :) Egyébként stimmel :)
[quote:b306818594="Csab"]Mindenesetre a kettő ötvözéséből fantasztikus dolgokat lehetne kihozni.
Igen, ezt hívják Java-nak :). Ha átgondolod alaposan, hogy miről van szó (futásidejű felderítése az osztályoknak = managelt környezet), akkor Te is belátod.
ui: Azért ilyen nagy az arcom, mert most nézem a heap-foglalások teszjeinek eredményét (néhány-millió new XY() hívás Java-ban, ill. new XZ() és delete hívás C++-ban. Igen, a Java közben elég sok GC-t futtat, de még így is 10x gyorsabb. Aki nem hiszi kimérheti, nyilvánossá teszek minden kódot, csak fejezzem be a cikket róla :)), ill. a GC futásának felső határának korlátozását.
[quote:be7b4ed70e="bocs"]
megmagyaráznád, mi lehet optimálisabb egy optimalizált tároló, hozzá optimalizált típus párosnál?
a cikket pedig köszönöm a nép nevében, olvasom!
Az optimumot globalis szinten nezd, ami adott tipusra optimalis, nem biztos, hogy globalisan is optimalis eredmenyt ad, kulonosen sok specializalt tipus eseten.
A kevesebb es egyszerubb kod (es adat) lehet, hogy belefer processzor cache-be, es a branch is jobban becsulheto. Pont emiatt nem jo optimalizacio az, ha a fordito mindent inline-ol.
/de isten biz, én nem döglök meg egyik nyelvért se, csak b.sza a csőrömet ez a "gumimaci jó, gumimaci szép, építsük fel belőle a golden gate hidat" effektus/
ez igy jo is, csak ne haragudjal azokra akik mikozben a felkesz hidon
jarnak, lelkesednek is picit...
[quote:122d70654b="Csab"]Ezt a java-ban is meg lehetne szebben csinálni.
Amikor a referenciaszámláló eléri a nullát (körökörös referenciát is figyelembe véve) -> meghívódik egy destruktor
Hozzá kéne adni még egy delete parancsot, amely kitörli az objektumot és ha mutat rá referencia, kinullázza a referenciákat.
Ez lenne szerintem az észszerű viselkedés.
Te Csab!
Egy dologra kernelek. Ulj mar le egy darab papirral es legalabb egyszer rajzold le (gondold vegig), hogy miafrancrol hadarsz itt! Aztan ha meg mindig borzasztoan okosnak tartod magad, akkor erdemes lenne egyszer csak a proba kedveert lekodolni, amit szeretnel, es akkor belatnad, hogy mekkora suletlensegeket beszelsz.
Mondok egy rovid peldat: van 500000 objektumod, amelyiknel mindegyikbol-mindegyikbe mutat referencia (most arrol ne beszeljunk, hogy ez milyen design eredmenye). Amikor ez a hobelevanc ugy-ahogy van elerhetetlenne valik a program szamara (mert kivulrol mar nincs ra juk hivatkozas), kivancsi lennek arra a referenciaszamlalos algoritmusra, ami kisutne, hogy ezt cuccot fel lehet szabaditani. Valszeg rohadt sokaig futna.
Most csak nagyon vazlatosan elmondom, hogy nagyjabol hogyan mukodik a GC (egyreszt, mert en sem ertek igazan hozza, masfelol tenyleg vannak jo doksik errol). Ha mar erted a lenyegi kulonbseget, akkor ujra vitazhatunk, de most ilyen kisdobos hozzaallassal kar vitatkozni arrol, hogy mi a jo es mi nem.
Szoval, amikor GC mukodesbe lep, akkor az algoritmus elindul a root-object referenciaktol (globalisok, static valtozok, lokalisok, regiszterek), es a referenciak menten bejarja azt a grafot, aminek a csomopontjai maguk az objektumok az elei pedig az adott objektumbol indulo referenciak (az algoritmus a szelteben kereses v. melysegi kereses neven fut az Alogritmusok konyvben). Ezen objektumok erhetoek el a program szamara, amik benne vannak ebben a grafban (szepen mondva elerhetoek a root-objectekbol). A tobbi objektum felszabadithato, akarhany hivatkozas is mutat rajuk.
A te modszered ott santikal, hogy mindenkeppen a referenciabol szandekozol megmondani a frankot, de nem az a lenyeg, hanem a root objectekbol valo elerhetoseg.
Ez sokkal gyorsabb, mint a te algoritmusod, de meg igy is lassu. Altalaban kulonfele heurisztikakat hasznalnak, amik meggyorsitjak a mukodest igaz csereben nem annyira precizek. Helyesen mukodnek, viszont nem biztos, hogy felszabaditjak az osszes osszes eldobhato objektumot.
Majd Joel kijavit, ha valahol tevedtem, mert sem GC guru nem vagyok, Java programot meg meg csak konyvben lattam forraskodban.
[quote:ec879deae1="Csab"]Ezt a problémát a rendes C++ sem oldja persze meg, hanem fagy. A QT-ben van egyedüli megoldás rá:
A QObject destruktora emittál egy destroyed() szignált delete-nél és aki referenciát tartott az objektumon, az ezután elengedi.
Ennél szebb megoldást nem láttam idáig.
QGuardedPtr<QObject> ptr;
Ahol ptr vagy létező objektumra mutat, vagy 0 az értéke.
Eros megkotes, hogy az osztalyaidnak a QObject-bol kell szarmaznia. Hogyan teljesited ezt a kriteriumot egy olyan konyvtarnal, aminek nincs meg a forrasa?
Ez nem túl meggyőző, hogy a java és a C++ ötvözete java-t eredményez.
Akkor miért használok, mégis C++-t java helyett, ahol lehet?
És a kollégáim miért nem rajonganak a java-ért?
A fent említett dolgok miatt nem használom a java-t. Meg az sem biztos, hogy lesz jövője. A C++ még megmarad egy darabig, de ha a .NET győz, a java röpül.
A java-nak igencsak erősítenie kell, ha versenyben akar maradni. Sok a konkurens.
A következő idézet erről az oldalról származik:
http://www.php.net/manual/hu/intro-whatcando.php
Ablakozós alkalmazások írása. A PHP valószínűleg nem a legjobb nyelv grafikus felületű asztali alkalmazások írásához, de ha nagyon jól ismered a PHP-t, és szeretnél néhány fejlett PHP szolgáltatást használni a kliens-oldali programjaidban, a PHP-GTK-t is használhatod ilyen programok írásához. Ezt használva lehetőséged van operációs rendszerfüggetlen programok írására is. A PHP-GTK a PHP egy kiterjesztése, nem érhető el a hivatalos PHP csomagban. Ha további információkra van szükséged látogsd meg a PHP-GTK webhelyet!
Köszi! :) Értettem. Elég lett volna, hogy RTFM! Ismét tanultam valamit...
syntern:
Jó, engem meggyőztél, hogy lehet még valami ebből a Javából. Egyelőre még maradok a C++-nál, márcsak azért is, mert most még biztosan használhatóbb kódot lehet vele írni. Aztán lehet, hogy tényleg eljön majd a Java ideje 1-2 év múlva (vagy épp a c#-é).
Nekem spec. a normális memóriakezelés biztosan fog hiányozni. Olyan ez mint a kézi és az automata sebességváltó. Ha az ember évek óta vezet kézi váltóval, nem biztos, hogy szívesen vesz automata kocsit.
[quote:4948fa923f="_Joel"][quote:4948fa923f="bocs"]
megnéztem, tényleg tud előre definiált N darab műveletet 2D-ben.
nekem speciel 3D kell, és speciális szűrők kellenek, úgyhogy számomra értéke... csekély.
Jaj ne legyél már ilyen.
http://www.developer.com/java/other/article.php/3522711
Nézd meg a sorozat korábbi cikkeit is.
Úgy látom, pixel műveleteknél csak valós tesztek segíthetnek annak eldöntésében, hogy ez mennyire életképes. Majd nekilátok egyszer, ha lesz rá idő, hogy x,y,z JVM k,l,m beállítások mellett hogyan teljesít.
[quote:4948fa923f="_Joel"][quote:4948fa923f="bocs"]
egyébként a Sun oldalán írják, hogy
"The Java Advanced Imaging API may be run without any native code, i.e., without the code which provides native acceleration."
ja hogy natív kód van mögötte... így könnyű.
Miért, szerinted a JVM-et miben írják?:))
?? nem tudom, de ezt úgy tűnik - ki tudja miért - nem Java-ban.
[quote:4948fa923f="_Joel"][quote:4948fa923f="bocs"]
tehát bejön szabványos képként 800MB egyben allokálva.
feladat: szabdald szét frame-ekre /egyedi képekre/, úgy hogy azok külön objektumok legyenek, külön kezelhetők, törölhetők stb, de közben ne fuss ki a RAM-ból.
Java-s megoldás van triviális?
Igen. JAI-val beload-olni. Automatikusan ezt csinálja, amit leírták anélkül, hogy te tudnál róla (jó ezt fel lehet fogni negatívumként is - de ha tudsz róla akkor meg befolyásolni is tudod, hogy ezt hogyan tegye).
szerintem ezt a memória kritikus feladatot te nem akarod megérteni.
a Java használata itt prohibitív.
adott egy X méretű folytonos memóriaterület. hogyan szeleteled fel anélkül, hogy lényegesen több memóriát foglalnál, mint X?
[quote:4948fa923f="_Joel"][quote:4948fa923f="bocs"]nakünk viszont spéci szűrőink vannak, amiknek bezony a képbiteken natív kódban végig kell tekerni. erre Java-t javasolnál?
De mutathatnál egy ilyen spéci szűrőt amit nem lehet konvolúciós mátrixként felírni, illetve amit nem lehet Java-ban ugyanúgy leimplementálni (egy 800 mb meretu int array az Javaban sem mas, mint egy 800 mb meretu int array).
lásd 1. pont. ha tényleg jó bittekerésre is a Java, akkor ez a pont nálad van. mondom ha tényleg jó.
[quote:4948fa923f="_Joel"]
[quote:4948fa923f="bocs"]
ja bocs én éles projektben nem akarok early adopter lenni.
Kifogás.
na ez csúnya volt, miután magad mondod "Ha RT kovetelmenyek vannak, ott valoban gond lehet"
kifogásnak tekinted, ha meghalhat egy páciens a gépben a GC miatt?
JNI-vel akár, de meoldható. Tudom, natív kód, fujjj...
ez az adekvát eszköz? ez a kérdés.
[quote:4948fa923f="_Joel"]
Ki mondta, hogy mindenre jó a Java? Hiába van regexp api, csak perl-hez nyúlok, ha szöveget akarok feldolgozni...
tehát összegezzük:
- pixel buzerálásra talán(!) mégis csak jó.
- numerikus alkalmazásokra inkáb Fortran. ezt akkor nem értem az előző pont miatt. ha ott jó, itt is jónak kellene lennie.
- memória kritikus alkalmazásokra nem jó
- időzítés kritikusokra nem jó
- hardver közeli dolgokra szenvedés /driver szintről ne is beszéljünk/
tehát jó lesz ez éles képfeldolgozásra?
érdekes, egyetlen szó sincs képfeldolgozásról. csak arról, hogy kórházi rendszer van Oracle adatbázis háttérrel, amihez Java a felület. Ebben mi a nagy szám?
Nos, a Nokia telefonokat véletlenül ismerem belülről. Az alap filozófia az, hogy mindent a gyors symbianban(???) kell megírni és köré kell csapni egy vékony java wrappert.
A telefonok egy része már arra is képes, hogy SVG-t rakjon ki a képernyőre. A SVG itt a virágkorát éli. De azért túlzás lenne azt gondolni, hogy az SVG megjelenítő java alatt fut...
A java arra kell, hogy a programozók kényelmesen és gyorsan programozzanak (mert ugye a symbian...), de a magot C++-ban írják.
Végülis a java.exe-ben is ugyanez a helyzet. A JRE-t is C++-ban írták meg, nem java-ban. Az izmosabb részek mind C++-on futnak.
Egyedül a C képes arra, hogy C-ben C fordítót és C runtime-ot meg lehet írni.
[quote:7c185254fe="handler"]
- a java bytecode jvm nelkul hasznosabb mint gondolnad, ugyanis bizonyithato a helyessege, vagy hogy megfelel a specifikacionak...
OK. Ezután az ügyfélnek azt mondom:
"Figyusz Kiccsávó, beverem az ormányod, ha használni akarod a programot.. inkább gyönyörködj a bájtkódban-ban, nézd meg milyen helyes, mennyire megfelel a specinek!":-)
De, egyébként igazad van, annyira hasznos önmagában, hogy minden java-s fejlesztő miután leforditotta, bájtról bájtra átnézi a bájtkodot.:)
[quote:7c185254fe="handler"]
- ez a foglaljunk kezzel memoriat nalad valami fetis? Miert nem veszed at a forditotol a memoriakezeles problemajat (c, c++ eseten) ha mar olyan jol kezeled a memoriat, elvegre Te is kioszthatod mikor melyik regiszterhalmazt hasznalja...
Nem c-ről és nem is c++-ról van szó.
Amugy igen.. nálam kényes téma. Egy hetet áldoztam arra, hogy megértsem ezt
az egész garbage collector/erőforrás gazdálkodás/memory leak együttest.. megérte.
Fri
[quote:b04bad043b="Andrei"]
Mondok egy rovid peldat: van 500000 objektumod, amelyiknel mindegyikbol-mindegyikbe mutat referencia (most arrol ne beszeljunk, hogy ez milyen design eredmenye). Amikor ez a hobelevanc ugy-ahogy van elerhetetlenne valik a program szamara (mert kivulrol mar nincs ra juk hivatkozas), kivancsi lennek arra a referenciaszamlalos algoritmusra, ami kisutne, hogy ezt cuccot fel lehet szabaditani. Valszeg rohadt sokaig futna.
A Garbage Collector sem nulla ideig fut rajta. :-)
Én a referencia csökkentésbe tenném bele a GC-t, hogy logikus legyen.
[quote:b04bad043b="Andrei"]
Most csak nagyon vazlatosan elmondom, hogy nagyjabol hogyan mukodik a GC (egyreszt, mert en sem ertek igazan hozza, masfelol tenyleg vannak jo doksik errol). Ha mar erted a lenyegi kulonbseget, akkor ujra vitazhatunk, de most ilyen kisdobos hozzaallassal kar vitatkozni arrol, hogy mi a jo es mi nem.
Szoval, amikor GC mukodesbe lep, akkor az algoritmus elindul a root-object referenciaktol (globalisok, static valtozok, lokalisok, regiszterek), es a referenciak menten bejarja azt a grafot, aminek a csomopontjai maguk az objektumok az elei pedig az adott objektumbol indulo referenciak (az algoritmus a szelteben kereses v. melysegi kereses neven fut az Alogritmusok konyvben). Ezen objektumok erhetoek el a program szamara, amik benne vannak ebben a grafban (szepen mondva elerhetoek a root-objectekbol). A tobbi objektum felszabadithato, akarhany hivatkozas is mutat rajuk.
A te modszered ott santikal, hogy mindenkeppen a referenciabol szandekozol megmondani a frankot, de nem az a lenyeg, hanem a root objectekbol valo elerhetoseg.
Ez sokkal gyorsabb, mint a te algoritmusod, de meg igy is lassu. Altalaban kulonfele heurisztikakat hasznalnak, amik meggyorsitjak a mukodest igaz csereben nem annyira precizek. Helyesen mukodnek, viszont nem biztos, hogy felszabaditjak az osszes osszes eldobhato objektumot.
Majd Joel kijavit, ha valahol tevedtem, mert sem GC guru nem vagyok, Java programot meg meg csak konyvben lattam forraskodban.
Engem nem érdekel, hogy hogyan működik belülről az egész. Legyen rendes belépési pont és kilépési pont (destruktor) és kész. Meg lehet rendesen és gyorsan csinálni, csak nem a legegyszerűbb.
Sőt, még az is elfogadható megoldás lenne, hogyha a referencia-számláló nullára megy -> destruktor, egyébként GC. Ha valakit ez zavar szüntesse meg a körkörös referenciákat. De destruktor nélkül elég gagyi az egész.
[quote:343560d3ed="lokoto"]
Elég meredek a következtetésed. Ettől még semmi nem rosszabb semminél, ...
Dehogynem... ha valamit (itt most értelmes / hasznos dologra gondoltam) egyszerűen meg tudok csinálni A eszközzel és azt NEM vagy csak körülményesen egy B-vel akkor az szerintem B rosszabb mint az A.
Kiemelem a fontos részleteket:
[quote:343560d3ed="lokoto"]
...mert javában nem tudsz *a-t írni, ezért ha az a = b-t felüldefiniálod a = b.clone() funkcionalitására, nem tudod miként megvalósítani a jelenlegi értelemben vett a = b műveletet, azaz hogy az a változó a b változó által mutatott objektumra mutasson.
[quote:343560d3ed="lokoto"]
... így definiálták a szintaktikát és szemantikát.
Ezt elfogadom. De a fentiek értelmében továbbra is fenntartom hogy rosszúl tették...
[quote:343560d3ed="lokoto"]
Primitív típusok esetén a változó az értéket hordozza, egyébként pedig hivatkozás egy objektumra. Pont.
Ezzel bonyolítva az értékadás műveletét... mert így többféle értékadásról beszélünk attól függően hogy az operandusok mik is valójában...
pl. ha csak ennyit látsz a kódból
a = b ;
akkor meg tudod mondani hogy az egyenlőség mit csinál?
Valószínüleg nem mert nem tudod hogy az a és b micsoda is tulajdonképen. Most átmásolja a tartalmát vagy csak a címét???... :)
[quote:343560d3ed="lokoto"]
Mikor a Javában meghatároztak a nyelv alapjait, valószínűleg végignézték, hogy jelenleg mi van, minek mi a hibája, előnye, és megpróbáltak jobbat kihozni (az adott feladatra).
Ha jól tudom a C# szintaktikája és szemantikája nagyon hasonlít a javáéra, vajon véletlen, hogy ott sincsenek pointerek?
A c#-t ugyanolyan rossznak tartom mint a java-t. Sőt még rosszabbnak mert az m$ műve. :twisted:
[quote:343560d3ed="lokoto"]
Művelet:
a = b;
mélymásolás esetén:
a == b false
jelenlegi működés:
a == b true
Nekem a jelenlegi működés logikusabb. Neked nem? :-)
Bevallom ezt nem értem... :oops:
Mi az hogy jelenlegi működés?
[quote:343560d3ed="lokoto"]
Nyilván az ==-et is felül lehetne definiálni, de lássuk be, hogy az egyik kolléga által felvázolt szemethalmazt kapjuk nagyon rövid idő alatt, mert senki nem fogja tudni, hogy mi micsoda.
Ez nem igaz...
Az == (összehasonlító) operátor MINDÍG azt jelenti hogy valamilyen szempontból a két operandus "egyenlő" vagy sem. Az eredménye mindíg egy igaz / hamis logikai érték lesz.
[quote:343560d3ed="lokoto"]
Arról nem is beszélve, hogy a mélymásolás logikája egy egyszerű operátori logika komplexitását jóval meghaladja.
Ezt nem értem... c++-ban amikor operátort írsz akkor bármilyen kód lehet az operátor működése mögött... a bármilyen kód szerintem lefedi a komplexitás fogalmát.
[quote:a09a7d2441="syntern"]En ugy vettem eszre aktiv Symbian fejlesztő ismerőseimen, hogy egyre cifrábbakat tudnak káromkodni a nyelv és a platform kényelmetlenségén .net és javahoz képest. Persze lehet, hogy nekik nem olyan fejlesztési feladatuk volt, mindenesetre az egyik szoftverükkel a nokia középvezetője példázódott valami konferencián... (symella, ha mond valamit és jól írom...).
Symbianhoz nem volt szerencsem, mert azok a telefonok egy egyedi oprendszert hasznaltak. Egyebkent nyilvan nekem sem a kedvenc kornyezetem a C (ez gondolom kiderult az eddigiekben), de tovabbra is azt allitom, hogy lehet benne tisztesseges szoftvert irni. Teny, hogy a fejlesztes kevesbe hatekony, de egyelore nagyon sok helyen egyutt kell elni vele.
[quote:a09a7d2441="syntern"]Én évekkel ezelőtt nagyon néztem a D nyelvet, programokat is írtam rajta. Egészen addig, míg egy alkalmazásnál azt mondta az üzemeltető, hogy vagy C++ vagy Java, ismeretlen marhaságokat ne akarjak futtatni. (erőgépen, felügyelt környezetben sok-sok procival)
Igen, de ez nem a nyelvet minositi. Osszesen annyi, hogy (meg?) nem elterjedt, es az illeto donteshozonak nem volt hozza bizalma. Kezdetben a Java sem tarolt, most pedig az egyik leggyakrabban hasznalt nyelv.
[quote:a09a7d2441="syntern"]Persze, de azt ugye tudod, hogy a C++-os memória-felszabadítás után az üres memória-terület töredezetté válik, míg Javaban a fogalom is ismeretlen? Azaz előfordulhat olyan C++ eset, amikor a GC takarít, de az allokáció sikertelen, mert a memória-terület nincs összenyomva, pedig egyébként a darab összessége elég lenne.
Erről a Tanú jut eszembe, meg a narancs...
Ezt nem tudtam, szoval koszi az infot, es a vegkovetkeztetessel is egyetertek, de megsem irnam oda a vegere, hogy "...de a mienk". En a C++-ra is csak egy eszkozkent tekintek. Egyebkent az egszet arra irtam, hogy a nyelv csak reszben meghatarozo, mert az egyeb toolkornyezet sokat tud meg hozni vagy rontani.
[quote:a09a7d2441="syntern"]Aha, ezek megoldások, de ha a szemlélet hibás, akkor ezek sem érnek semmit sem. Azaz mindegy milyen szinten, de tisztában kell lenni a szemlélettel, ha helyen akarod alkalmazni a technológiát.
Azt hiszem, hogy egyrol beszelunk.
[quote:a09a7d2441="syntern"]Persze, és a generáció során szépen generálják a memóriakezelést és a managelt környezet összes funkcionalitását, ahelyett, hogy a managelt környezetben futtatnák. Megint csak arról van szó, hogy van egy kitalált, működő rendszer, szeretnénk egy hasonlót, barkácsolunk magunknak, mert mi jobban értünk hozzá. Bejöhet, de általában nem fog.
Itt azert inkabb arrol van szo, hogy akiknek fejleszteniuk kell, azok alltalaban nem szoftverfejlesztok, hanem egy masik terulet szakemberei, es nekik vmilyen egyszerusitett es ismereteikhez szabott rendszert biztositanak egy altalanos nyelv helyett. (Pl. grafikus kodszerkeszto, vagy matlab simulink, stb.) A generalt kod egyebkent nem mindig tartalmazza az altalad emlitett megoldasokat (pl. managelt kod), de teny, hogy bizonyos tekintetben kiprobalt es szabvanyos megoldasokat hasznal fel.
[quote:31ee3c675d="Csab"]
Akkor miért használok, mégis C++-t java helyett, ahol lehet?
És a kollégáim miért nem rajonganak a java-ért?
Az a tény viszont, hogy te főleg mobil eszközökön próbálod használni megmagyarázza, hogy miért gondoltad a referenciaszámlálást kivitelezhetőnek és működőképes algoritmusnak: ott valóban nem kell több millió élő objektumot kezelni képes algoritmusban gondolkodni (legalábbis még néhány hónapig/évig).
[quote:733b3dc766="maszili"]
Ezzel bonyolítva az értékadás műveletét... mert így többféle értékadásról beszélünk attól függően hogy az operandusok mik is valójában...
pl. ha csak ennyit látsz a kódból
a = b ;
akkor meg tudod mondani hogy az egyenlőség mit csinál?
Valószínüleg nem mert nem tudod hogy az a és b micsoda is tulajdonképen. Most átmásolja a tartalmát vagy csak a címét???... :)
Miért, ha C++-ban azt látod, hogy
a = b;
akkor mit tudsz mondani? Mit csinál az a fránya =?
Csak úgy megkérdezném, hogy a hozzászólók közöl hányan tanultak/foglalkoztak deklaratív (Lisp, SML, Scheme) vagy logikai (Prolog es tarsai) programozással?
[quote:57d0a2835c="Frimen"]A Java-t én kihagynám a helyedben, mert azzal biztosan nem lehet megcsinálni mindent. Nem kivántam még senkinek, de
remélem a pokolra jut aki kitalálta, hogy a memoria kezeléshez
hozzá se férjen a programozó.
Hogy dögölne meg.
Fri
nem spagettiprogramozoknak keszult massziv ganyolashoz, arra vannak megfelelobb eszkozok
[quote:ac20c26c42="handler"]
Ugye verifikaciorol meg nem is hallottal :D Az eddigi hozzaszolasaid alapjan (kinyomtatja a bytecodot) nagyon-nagyon ugy tunik. A teszteles egyaltalan nem garantalja a hibamentesseget, de meg azt atveteli jegyzokonyv sem.
A szerződések kitételeiről a felelősség kérdésében nem is beszélve..:)
Tudhatnad, hogy torvenyesen nem lehet korlatlanul felelosseget kizarni. Egy szerzodeshez pedig ket fel kell, persze probalkozhatsz, max massal kotnek szerzodest.
Handler: No comment.
Én a kettőnk közt dúló háborút lezárnám azzal, hogy az utóbbi
mondatod még nekem is sokk volt:
"Tudhatnad, hogy torvenyesen nem lehet korlatlanul felelosseget kizarni."
De legalábbi jót röhögtem rajta.:-)
Fri
Javitsatok ki, de a C++ operator overload igazabol egy makro, ami a szintaktikan egyszerusit, es forditasidoben atirja a kodokat olyanra, hogy az adott funkcio fusson le. Azaz nyugodtan lehetne egy pre-Java nyelvu makrozast csinalni, ami atforditja Java szintaktikara a makrokat.
Szoval van ket szintaktikank, meg kozel transzformalni is lehet oket. Nyilvan a Java nyelvbe azert nem tettek bele, mert akkor nem volt celszeru. Ha a vilag nagyobbik fele most celszerunek latna, akkor masfel even belul a Java nyelv resze lehetne, ahogy az lett az annotacio is peldaul. Ha nem latjak celszerunek, szerintem csak azert van, mert konnyebben el tudnak olvasni egy beszedes metodusnevet, mint ertelmezni egy operatort, hogy akkor az most milyen objektum es mit fogok kapni belole.
[quote:0e3f41eaf1="feledhetetlen"]
amugy meg mindig varok az 'en nagyonis ertem a java-t es elmondom miert gyenge' csoportbol a valaszt arra kerdesre mit csinal a
[code:1:0e3f41eaf1]synchronized( this ) { }[/code:1:0e3f41eaf1]
a 'hat semmit' valasz eseten arra,
hogy miert nem szedi ki a fordito ?
ha javap-pal megnezed benne kell lennie...
[quote:93f2027112="_Joel"]Csak úgy megkérdezném, hogy a hozzászólók közöl hányan tanultak/foglalkoztak deklaratív (Lisp, SML, Scheme) vagy logikai (Prolog es tarsai) programozással?
[quote:f4dda66f8c="Csab"]Akkor miért használok, mégis C++-t java helyett, ahol lehet?
És a kollégáim miért nem rajonganak a java-ért?
Tipp: lehet, hogy csak felületesen ismered?
Tipp: lehet, hogy csak a mobil Java-t ismered?
[quote:f4dda66f8c="Csab"]A fent említett dolgok miatt nem használom a java-t. Meg az sem biztos, hogy lesz jövője. A C++ még megmarad egy darabig, de ha a .NET győz, a java röpül. A java-nak igencsak erősítenie kell, ha versenyben akar maradni. Sok a konkurens.
A .NET inkább marketingben konkurrens, a jelenlegi formájában ugyanis nem több, mint egy köztes nyelv a kód és a bináris között. Jónak jó, ügyesen fordítják binárisra (== JIT), szép nagy API van mellérakva, de a Java API egy kicsit nagyobb, úgyhogy ez sem érv. A JVM mint futási környezet egyedülálló. Majd ha közelében lesz bármi más, akkor lehet beszélni versenyről. Ha már a .NET-et hozod fel, mint Java konkurrenst, akkor gyakorlatilag beismered, hogy nagyon kevés az alternatíva. :)
Én azt szoktam mondani, hogy alap API szinten nincs nagy különbség Java és .NET között, de az első nem vendor-lock-in, ami nekem már megéri. Emellett még jól is teljesít, sok jó eszköz van hozzá, amelyekhez hasonló funkcionalitást (pl. jó kis refactoring) semmilyen pl. C++ fejlesztő-környezetben nem láttam eddig. Plussz eddig sikeresen elkerült a mobil világra történő fejlesztés, amíg van választás, addig nem akartam beleugrani egy tipikus szívás-témába... :)
[quote:0035639302="_Joel"]
De abban remélem egyetértünk, hogy Javaban a memory leak-ek
többnyire tervezési hibák és nem programozói hibák... ugye?
Egyetértünk.. részben.
Ugyanis ha összetett mintát álmondsz meg, amiben "külső" osztályok
is szerepet kapnak, akkor lehet Te is jól megtervezted.. lehet ők is.. csak épp
a kettő együtt nem müködik..:) Lásd a listeneres példát..
Bevallom én már falra mászok ettől az egész memoria kezeléstől a Java-ban,
mert tudom jó a garbage collector.. pontosabban értem miért jó, ha ugy van
kezelve a memóri ahogy.. de most hogy hibát keresek egyszerűen jó volna
látnom a gb miért nem semmisit meg egy adott objektumot.
Egy "külső" objektumrol van szó.. hol a leak.. nálam, vagy "náluk".. vagy
egyáltalák leak-e az a leak?
Fri
[quote:6c9c477632="Csab"]
Sőt, még az is elfogadható megoldás lenne, hogyha a referencia-számláló nullára megy
Vázolj nekünk egy frappáns megoldást arra, hogy hogyan véded ki a counter felfelé történő túlcsordulását... Ne felejtsd el, a y2k is a "2 számjegy elég az évnek" teljesítményhajhász programozói magatartása miatt lett az ami... (mármint dollármultimilliárdos biznisz:)
[quote:12b001ef97="snq-"]
nem spagettiprogramozoknak keszult massziv ganyolashoz, arra vannak megfelelobb eszkozok
Hát én ilyen optimista okostojás voltam régebben mint Te a beszólásod
alapján itélve, utána szembetaláltam magam pár "problémával", amitől
kiborult a bili.
A java nem csodaszer.. bizonyos dolgokra kifejezettem sz*r a java..
.. és még a spegtti is jobb nála.:)
Fri
[quote:bddbcd8474="Csab"]
A Garbage Collector sem nulla ideig fut rajta. :-)
Én a referencia csökkentésbe tenném bele a GC-t, hogy logikus legyen.
Fubaszki, nem vagy egyszeru. Eppen hogy az a lenyeg, hogy ebben a konkret esetben joforman zerus ideig agyal rajta a GC. Rajzold le magadnak!
Es kulonben sem az a cel, hogy nulla ido alatt menjen le a GC. Ha a te algoritmusod 3 evig fut, a GC, meg 2 perc alatt vegez, hidd el minden normalis IT mernok a GC mellett teszi le a voksat.
[quote:bddbcd8474="Csab"]
Engem nem érdekel, hogy hogyan működik belülről az egész. Legyen rendes belépési pont és kilépési pont (destruktor) és kész. Meg lehet rendesen és gyorsan csinálni, csak nem a legegyszerűbb.
Sőt, még az is elfogadható megoldás lenne, hogyha a referencia-számláló nullára megy -> destruktor, egyébként GC. Ha valakit ez zavar szüntesse meg a körkörös referenciákat. De destruktor nélkül elég gagyi az egész.
Senkit nem erdekel, hogyan mukodik belulrol az egesz, ezert ne is tegyunk mar olyan megszoritasokat, amirol ellenorizhetetlen, hogy teljesul egy adott program eseten. Eppen ez okozza a legnagyobb problemat a tradicionalis memoriamenedzsmenttel.
Pl ha adok neked 5 millio sor C++ kodot, hogyan dontod el, hogy helyes-e a memoriakezelese? Ugyanigy hogyan dontod el, hogy a program futasa soran lehet-e benne korkoros referencia? Ha ezt is tudod (mert ma jobbnal jobb "otletekkel" csalsz mosolyt az itteniek arcara), akkor rohanj el levedetni, egyszer meg meggazdagodhatsz belole...
Eppen ez a legnagyobb erenye a jol megvalositott GC-nek. Semmilyen megkotessel nem el a programoddal kapcsolatban, csak annyival, amit maga a nyelv kenyszerit ki. Ez azt jelenti, hogyha lefordul pl. a C# v. Java programod, akkor (elvileg) a memoriakezelese is helyes. Ezt C++ programrol soha nem fogod tudni elmondani.
[quote:c6cc6d76d7="KisKresz"]
Miért, ha C++-ban azt látod, hogy
a = b;
akkor mit tudsz mondani? Mit csinál az a fránya =?
Azt csinálja amit már kisiskolás korunkban megtanítottak velünk...
Egy jólnevelt értékadásnak megfelelően a b értéke belemásolódik az a-ba, úgy hogy a és b független egymástól. Ezt hívják a java-ban "mélységi másolásnak". Ha nem így akarom akkor azt külön jelzem a kiutált csillaggal... :) és máris egyértelműen látszik hogy mit jelent a kifejezés.
És az egészben az a vicc hogy az értékadás teljesen független az operandusok típusától, mert a programozó okos volt és elkészítette a megfelelő értékadó operátort az osztályhoz.
De nem csak az értékadó operátort írta meg hanem pl. a kiíró operátort is és igy kiírathatom az egyébként igen összetett objektum tartalmát ilyen egyszerűen (hasonlóan a primitív adattípusokhoz)
[quote:b1c3c8141a="Csab"]Ugye tudod mennyivel gyorsabb ellenőrizni, hogy a referencia elérte-e a nullát?
Ugye tudod, hogy a referencia update-lése nem 0 idő, ráadásul szinkronizációt igénylő pont, ami derékbatörheti a skálázódást multiprocesszoros rendszereken...
[quote:447eac7b9b="KisKresz"][quote:447eac7b9b="_Joel"]Csak úgy megkérdezném, hogy a hozzászólók közöl hányan tanultak/foglalkoztak deklaratív (Lisp, SML, Scheme) vagy logikai (Prolog es tarsai) programozással?
Én tanultam. Miért?
Rajtad érződik is:) De néhányan itt annyira a pointer-ek mellett érvelnek, hogy fogalmam nincs mit kezdenének egy változók nélküli nyelvvel, vagy olyannal amiben csak logikai igazságokat lehet leírni és kérdéseket feltenni...
(a prolog-sml-es targy volt az egyik zarovizsga targyam, nem veletlenul:)
[quote:97a2dd1224="lacipac"][quote:97a2dd1224="hop1"]És kimaradt a pascal :(
Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban.
Te KIS hátuldombolós gimnazista, TE aztán tudod!!!!
Erre a "hátulgombolós"-ra igazán dühös tudok lenni, ha hasonló tapasztalattal rendelkező ember puffogtatja, mint egy átlagos gimnazista lehet. Ha kivételes zseni vagy és mögötted van 4-5 vállalati project (nem feltétlen PASCAL-ban), akkor igen, mondhatsz ilyet.
Úgy gondolom, aki ilyet mond, annak semmit nem jelent és nem is látott modern PASCAL nyelvet, se a Delphi-t, se FreePascal és Lazarust! Így nem tudja és nem ért hozzá!
A Pascal eljutott a DOS-tól a .NET világáig, a struktúrált programozáson át az objektumorientáltságig. Windows, Linux , MacOS..... Mi a baj vele, hogy nem kell szenvedni.... Vagy az, hogy léteznek hozzá ingyenes komponensek is, amikkel lehet dolgozni. Még programba építhető saját szkript-nyelv komponenst is találtam hozzá.....
[quote:c84758dd07="syntern"]
ui: Azért ilyen nagy az arcom, mert most nézem a heap-foglalások teszjeinek eredményét (néhány-millió new XY() hívás Java-ban, ill. new XZ() és delete hívás C++-ban. Igen, a Java közben elég sok GC-t futtat, de még így is 10x gyorsabb. Aki nem hiszi kimérheti, nyilvánossá teszek minden kódot, csak fejezzem be a cikket róla :)), ill. a GC futásának felső határának korlátozását.
Ezt nem igazán értem. Mi értelme van összehasonlítani a EGY BIZONYOS jvm verzió alatt futtatott java program memóriafoglalását EGY BIZONYOS környezet (oprencer/fordító/libc ...) alatt lefordított és futtatott C++ program memóriafoglalásával?
Ebből kikerekedi vmi eredmény, ami alapján megállapítod, hogy "a java jobb mint A C++" ? Mi annak az akadálya, hogy egy hozzáértő ember írjon olyan memória-kezelő függvényeket/osztályokat C++ alá, ami übereli a javás eredményeket?
[quote:907a0144d1="fdavid"]
Pedig handler baratunknak igaza van.
http://www.digitalmars.com/d/
Itt mar csak az architektura hianyzik.
Nem olvstam végig, de..
>D is a fully garbage collected language
Na ez már alapból lehet al van b*szva!
Ezért sz*r a java is bizonyos dolgokra, mert garbage collector
a felelős a memóriáért: nincs a programozó kezében a memóra.
Fri
[quote:946c4fd1c9="_Joel"][quote:946c4fd1c9="Csab"]
Sőt, még az is elfogadható megoldás lenne, hogyha a referencia-számláló nullára megy
Vázolj nekünk egy frappáns megoldást arra, hogy hogyan véded ki a counter felfelé történő túlcsordulását... Ne felejtsd el, a y2k is a "2 számjegy elég az évnek" teljesítményhajhász programozói magatartása miatt lett az ami...
Bazzze _Joel, en mar ertem a sracot! Ezt a problemat is konnyu megoldani!
Ha azt el lehet intezni, hogy ne legyen korkoros hivatkozas, akkor mar azt is csipobol elintezzuk, hogy egy ojjektumra ne legyen tobb hivatkozas rongyos 4 milliardnal. Majd ugy programozunk, hogy kis papiron strigulazzuk a referenciakat, ha valaki eleri a hatart, kirugjuk a gennybe, nehogymar ilyen slendriansagot megengedjen maganak! Komoly C++ programozok vagyunk, vagy miaszosz. Sot, itt a 64 bites korszak kiccsavok, az annyi ojjektumreferenciat enged, hogy azt mar el sem tudjatok kepzelni.... Kerem kapcsojja ki!
Veszesen writeonly a srac, gondolkodni meg nem akar... Ez nagyon veszelyes kombinacio, foleg, ha C++-ban programozik. Remelem nem vonatfekdrivert fejleszt.
[quote:1337b636da="KisKresz"][quote:1337b636da="feledhetetlen"]
amugy meg mindig varok az 'en nagyonis ertem a java-t es elmondom miert gyenge' csoportbol a valaszt arra kerdesre mit csinal a
[code:1:1337b636da]synchronized( this ) { }[/code:1:1337b636da]
a 'hat semmit' valasz eseten arra,
hogy miert nem szedi ki a fordito ?
ha javap-pal megnezed benne kell lennie...
Te ugyanilyen mélységben kened-vágod a C++-t is?
KisKresz
8 eve nem irtam production quality C++ programot, azelott igen
persze akkor nem volt STL igazan a template sem volt
amugy akkoriban is egy szuk subset-et hasznaltunk csak a C++ jelolesekbol
amugy a tpop.awl.com konyvet tartom az igazi referencianak
abban jol megfer C, C++, Perl, Java mint reprezentans gyakorlati nyelvek
valahogy nalam van tekintelye Rob Pike-nak, es Kernighan-nek akkor is ha a binaris es/vagy operator precedenciajat mellenezte...
A java alapgondolata szerintem jó. A probléma az, hogy az egyszerűség kedvéért a C++-ból olyan dolgokat is kiszedtek, amit nem kellett volna.
Mindenesetre lehet reménykedni, lassan fejlesztői nyomásra csak visszapakolják ezeket és persze hatszor olyan jó lesz, mint a C++, aztán elmondják, hogy eredetileg is így szerették volna, csak nem volt a megvalósításra kellő energia.
Én szerencsésnek látom a C# megjelenését is. Nyilván, ha C#-ben könnyebb programozni, mint java-ban, ez a java-t is húzni fogja. A lényeg az, hogy legyen verseny.
[quote:833ad2f82b="hanischz"]
Ezt nem értem. Ha valaki GUI-s programokat akar írni Win alatt, akkor muszály az inkompatibilis utat választani C-ben! Mert említettem h nagyon le van maradva, ősrégi szabványos könyvtárak vannak C alatt.
Ez igy természetes... miért várod el azt hogy a c++ tartalmazza a vindóz specifikus dolgokat? Mert akkor ne tegyünk kivételt és tartalmazhatná a világ összes specifikus dolgát is... a mikrokontrollerektől a szuperszámítógépekig... lehetőleg nem kifelejtve az összes létező oprendszer dolgait... nem?
A mai (PC-n használt) nyelvektől elvárok bizonyos ALAP dolgokat. PL GUI kezelés, szálak, képek, multimédia, kivételkezelés, hálózat, stb. Különben hogyan írjak felhasználói programot? írjak parancssorit?
A java (és a .NET) pont ezeknek az új igényeknek próbál megfelelni.
Tehát a C++-tól nem vindózos dolgokat várok el, hanem hogy pl GUI-t tudjon kezelni PLATFORMFÜGGETLENÜL, és ne kelljen újraírnom Win98, WinXP, KDE, Gnome alatt.
Mert idő (és pénz) pazarlás (lehet).
CSAB írta:
"
Megpróbálom összefoglalni a lényeget.
1. Megalkották a C++-t, az egész jóra sikerült, de leálltak a további szabványosítással. Mindenki olyan könyvtárat ír, amilyet akar.
2. Megalkották a java-t és továbbra is fejlesztik, egy kézben van, ezért egységes megoldásokat használnak
A java fokozatosan fejlődik, míg a C++ áll. Persze hallottam, hogy beszélnek már az új C++ szabványról is...
A probléma valahol ott van, hogy nincsenek egységes C++-os könyvtárak úgy, ahogy java-ban.
Nekem személyesen a C++ magja, az alap szerkezete jobban tetszik, mint a java alap szerkezete. A C++ gazdagabb, míg a java az equals metódusaival fapadosnak tűnik. Egy választékos nyelven könnyebben fejezed ki magad.
Ha a java olyan lenne, hogy a C++-os osztályszerkezeteket használná, én is java-s lennék. Számomra nehézkesnek tűnik az egész és áttekinthetetlen.
Elsősorban érzelmi okai vannak, hogy C++-t használok. Sokkal szebb és választékosabb a C++-os kifejezés forma."
Teljesen egyetértek. Sokáig C++-t használtam és lényegre törő mivolta miatt szerettem meg. Ilyen most a C#. CSak valahogy még nem tud annyit mint a java. (És a mono sem, ami a szabad megvalósítása a .NET-nek).
Lehet egymast alappal/alaptalanul pocskondiazni, de ez az adatgyujtes egyszeru statisztika arrol, hogy ki mit hasznal.
En speciel pascalt (Kylix kornyezetben), es nem tudom, hova ikszeljek.
[quote:263e8e37ef="syntern"]Javitsatok ki, de a C++ operator overload igazabol egy makro,...
Nem igy van...
A operátor pontosan olyan programkód mint az adott osztály bármelyik tagfüggvénye.
[quote:263e8e37ef="syntern"]
... ami a szintaktikan egyszerusit, ...
Ez jó meglátás. Pont az a lényege a dolognak hogy a már megszokott operátorokat használhassam azokra az adattípusokra / objektumokra amelyeket én a programozó talált ki és így nem ismerhették a nyelv készítői.
[quote:263e8e37ef="syntern"]
... es forditasidoben atirja a kodokat olyanra, hogy az adott funkcio fusson le.
Nem átírja a kódot hanem meghívja a kódot.
[quote:263e8e37ef="syntern"]
Ha nem latjak celszerunek, szerintem csak azert van, mert konnyebben el tudnak olvasni egy beszedes metodusnevet, mint ertelmezni egy operatort, hogy akkor az most milyen objektum es mit fogok kapni belole.
Ezzel nem értek egyet...
Nem tartom valószínünek, hogy egy külföldiűl írt szó egyértelműbb lenne a megszokott =, ==, !=, +, ++, -, --, (), stb. operátorokhoz képest.
[quote:bef3f97417="syntern"]
Azert jol tudod fikazni azt a rendszert, amit nem is ismersz. Mernoki ereny :)
Szinte sejtettem hogy ez lesz belőle...
Amikor már elfogynak az érvek akkor jön a vitapartner becsmérlése... :evil:
Na akkor tisztázzuk a dolgokat!
- 1 -
Én láttam már java-t, valamilyen szinten ismerem, de nem komálom és nem használom. Ezt már a legelső hozzászólásomban elmondtam.
- 2 -
[quote:bef3f97417="syntern"]
Ha jól látom még mindig nem árultad el, hogy ennek fényében hogy raknád bele az egész számokat 1-től 500000-ig egy java.util.ArrayList-be.
Ennek mi köze van a témához?
Miért kellene nekem megírnom ezt java-ban?
- 3 -
Én felvázoltam nemtetszésemet a java-val kapcsolatban. Erre jöttél (többek között) Te hogy megcáfold. Szerintem nem sikerült. Ezek után a fejemhez vágod hogy ...jol tudod fikazni azt a rendszert, amit nem is ismersz. Elmondtam hogy IGEN, csak felületesen ismerem!
DE Te aki JÓL ismeri, NEM tudja megvédeni az érveit egy olyannal szemben aki kevésbé ismeri???!!!
Aztán tehetetlenségedben ahelyett hogy a vitapartnerednek igazat adnál elkezded szapulni...
Viselkedjünk már felnőtt, komoly emberként.
- 4 -
Én nem akarok erről a témáról átváltani egy személyeskedő egymást szidalmazó veszekedésbe! Annak SEMMI értelme! Attól senki nem lesz okosabb!
[quote:7b19516b83="Frimen"]
Ugyanis ha összetett mintát álmondsz meg, amiben "külső" osztályok
is szerepet kapnak, akkor lehet Te is jól megtervezted.. lehet ők is.. csak épp
a kettő együtt nem müködik..:) Lásd a listeneres példát..
Bevallom én már falra mászok ettől az egész memoria kezeléstől a Java-ban,
mert tudom jó a garbage collector.. pontosabban értem miért jó, ha ugy van
kezelve a memóri ahogy.. de most hogy hibát keresek egyszerűen jó volna
látnom a gb miért nem semmisit meg egy adott objektumot.
Egy "külső" objektumrol van szó.. hol a leak.. nálam, vagy "náluk".. vagy
egyáltalák leak-e az a leak?
Fri
Hűha... lehet hogy mégsem olyan jó dolog ez az egész? :)
[quote:f21632a507="maszili"][quote:f21632a507="KisKresz"]
Miért, ha C++-ban azt látod, hogy
a = b;
akkor mit tudsz mondani? Mit csinál az a fránya =?
Azt csinálja amit már kisiskolás korunkban megtanítottak velünk...
Egy jólnevelt értékadásnak megfelelően a b értéke belemásolódik az a-ba, úgy hogy a és b független egymástól. Ezt hívják a java-ban "mélységi másolásnak". Ha nem így akarom akkor azt külön jelzem a kiutált csillaggal... :) és máris egyértelműen látszik hogy mit jelent a kifejezés.
És az egészben az a vicc hogy az értékadás teljesen független az operandusok típusától, mert a programozó okos volt és elkészítette a megfelelő értékadó operátort az osztályhoz.
De nem csak az értékadó operátort írta meg hanem pl. a kiíró operátort is és igy kiírathatom az egyébként igen összetett objektum tartalmát ilyen egyszerűen (hasonlóan a primitív adattípusokhoz)
cout << a ;
Valójában halvány fogalmad sincs, mit csinál. Legfeljebb reménykedhetsz benne, hogy a programozónak is az volt a szándéka, amit te hiszel...
[quote:248ce29ec0="lzrd"]
Tudnál jogszabályra hivatkozni?
Nekem laikusként úgy tűnik, nincs igazad. Gondolok pölö a "Magas feszültség! Életveszély!" táblára. Gondolom ezzel analóg módon, ha a programod forrásába/dokumentációjába, első megjelenő felhasználói interfészébe beleírod, hogy nem vállalsz felelősséget, akkor csak nem verhetik el a port rajtad, nem?
PTK/A kártérítés általános szabályai:
342. § (1) Semmis valamely szerződésnek az a kikötése, amely a szándékos vagy súlyos gondatlanságból eredő károkozásért, az életben, a testi épségben, az egészségben okozott károsodásért, továbbá bűncselekmény következményeiért való felelősséget előre korlátozza vagy kizárja.
[quote:85980dc91d="Frimen"][quote:85980dc91d="edaile"]Egy programnyelvet azért szeretek, mert mindent meg lehet benne csinálni.
Ilyen a Java, Perl, PHP és a C++.
A Java-t én kihagynám a helyedben, mert azzal biztosan nem
lehet megcsinálni mindent. Nem kivántam még senkinek, de
remélem a pokolra jut aki kitalálta, hogy a memoria kezeléshez
hozzá se férjen a programozó.
Hogy dögölne meg.
Fri
Ne legy ennyire korlatolt. Ha memoriat akarsz javabol kezelni, arra boven van lehetoseged. Nezz szet az RT Java kornyeken. De keszithetsz sajat megoldast is.
A masik, hogy vegtelenul naiv vagy, ha azt hiszed, hogy manualisan olyan marha jol kezeled a memoriat ;-)
[quote:b26abf6c09="hanischz"]
A mai (PC-n használt) nyelvektől elvárok bizonyos ALAP dolgokat. PL GUI kezelés, szálak, képek, multimédia, kivételkezelés, hálózat, stb. Különben hogyan írjak felhasználói programot? írjak parancssorit?
Az igények jogosak de a megvalósításuk már nem.
Az mondod hogy GUI-t akarsz... rendben. De melyiket?
Ahány rendszer annyi féle. Nem lehet kötelezni mindenkit hogy márpedig építse be a rendszerébe az xy GUI API-ját mert mi azt akarjuk használni. Hiába vannak ajánlások / szabványok ha nem implementálja mindenki. Ez a probléma akkor oldódna meg ha a világ összes cége / fejlesztője leülne és megegyeznének egy nagy közös szabványról... :)
Andrew W. Appel: Garbage Collection Can Be Faster Than Stack Allocation
Az absztrakt első mondatában benne van a lényeg:
A very old and simple algorithm for garbage collection gives very good results when the physical memory is much larger than the number of reachable cells.
[quote:3d2911d762="lzrd"][quote:3d2911d762="_Joel"]
Ugye tudod mi a kulonbseg egy o(n*log(n)) es egy o(n^3) algoritmus kozott...
Én nem tudom. Meg lehet tudni mi az?
Kis ordónak hívják, és algoritmusok nagyságrendi lépésszámát jelöli. Ha beírod google-ba, hogy "kis ordó", akkor elég jó online anyagokat lehet találni, amik sokkal jobban elmagyarázzák, mint én. Pl ez itt egész korrektnek tűnik:
Szerintem akármelyik programnyelvről is legyen szó, programozni tudni kell.
Nos, aki írt bonyolult és nagy programot az tudja hogy a hibák száma a sorok számával nő!!!!! Hiába tudsz programozni...
Azért nem nulláztam változót, mert zavartak programozás közben (nem ideális munka környezet)! És persze nem tudtam figyelni. Nézd meg az MS programozókat. Láttam dokumentum filmet róluk, napi 16 órát is dolgoznak! Nehogy azt mondja valaki hogy 16 órán keresztül tud valaki koncentrálni...
Ezért kellenek a menedzselt és egyéb segítséggel felvértezett prog nyelvek h a rabszolga munkát a fordító automatikusan megcsinálja.
[quote:60dbdbc137="zsolt"]Nekem spec. a normális memóriakezelés biztosan fog hiányozni. Olyan ez mint a kézi és az automata sebességváltó. Ha az ember évek óta vezet kézi váltóval, nem biztos, hogy szívesen vesz automata kocsit.
:) bocs, hogy off, de azt is szokták mondani, hogy aki egyszer kipróbál egy jó automata váltót, az többet vissza se néz :)
[quote:64d6c7bda8="_Joel"]De néhányan itt annyira a pointer-ek mellett érvelnek, hogy fogalmam nincs mit kezdenének egy változók nélküli nyelvvel, vagy olyannal amiben csak logikai igazságokat lehet leírni és kérdéseket feltenni...
(a prolog-sml-es targy volt az egyik zarovizsga targyam, nem veletlenul:)
Most a burkolt leszólástól eltekintve, miért lenne érdemes ezeket a nyelveket tanulni? Milyen problémákat lehet velük hatékonyabban vagy gyorsabban megoldani, mint amire a "népszerűbb" nyelvek képesek?
(mindíg is érdekelt a Scheme, Lisp)
Miert van az, hogy valahanyszor idecibal az ember egy Java vagy C# kodot, akkor annak tobbnyire az a kozos vonasa, hogy lassu.
En fejlesztek C++-ban es C#-ban is munkam soran (es igazabol a C#-ot jobban szeretem), de eszembe se jutna ezt igy globalisan kijelenteni, hogy a GC leveri a hagyomanyos memoriafoglalast. Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
[quote:2e5d96e3a8="KisKresz"]
Valójában halvány fogalmad sincs, mit csinál.
Pontosítsunk!
Valójában halvány fogalmad sincs, hogyan csinálja.
Ez így helyes.
Mivel OO -rol beszélünk nincs rá szükségem és nem is érdekel... nekem pont elég egy absztakciós szinttel feljebb lévő problémával foglalkozni.
[quote:2e5d96e3a8="KisKresz"]
Legfeljebb reménykedhetsz benne, hogy a programozónak is az volt a szándéka, amit te hiszel...
Szerintem a világ elég nagy százalékának ugyanazt jelenti pl. a = jel... :) Miért írná meg máskép a programozó?
[quote:b2b27470aa="Frimen"]
OK. Ezután az ügyfélnek azt mondom:
"Figyusz Kiccsávó, beverem az ormányod, ha használni akarod a programot.. inkább gyönyörködj a bájtkódban-ban, nézd meg milyen helyes, mennyire megfelel a specinek!":-)
N ugyfel meg azt mondja neked X ido utan, hogy a programod rossz, a szamitasok nem helyesek es emiatt neki Y millio forintos kara keletkezett, es legyel szives minden kart es javitassal felmerulo koltseget megteriteni. :D
[quote:b2b27470aa="Frimen"]
Nem c-ről és nem is c++-ról van szó.
Amugy igen.. nálam kényes téma. Egy hetet áldoztam arra, hogy megértsem ezt
az egész garbage collector/erőforrás gazdálkodás/memory leak együttest.. megérte.
Fri
A fenti bytecode hozzaszolasodbol nem igy tunik. Osztott eroforrast hogy kezelsz? Refcount ? :D Memory leak (es memory corruption) nelkui kodot pedig aligha fogsz a fenti feltetel teljesulese nelkul csinalni...
[quote:aca5ce1970="hanischz"]Ilyen most a C#. CSak valahogy még nem tud annyit mint a java.
8O valahogy pedig nekem ugy tunik mostanaban a java (nyelv) kullog a c# mogott, tobb-kevesebb sikerrel (durvan felresikerult generics-koppitas, attributes, boxing, enhanced for loop...)
(nem a .NET-re es a java platformra gondoltal inkabb?)
[quote:e6ebba2a13="Andrei"]Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
a generalt kod sebessege pedig egyetlen szempont a sok kozul
[quote:f24643d462="maszili"]
[quote:f24643d462="syntern"]
Ha jól látom még mindig nem árultad el, hogy ennek fényében hogy raknád bele az egész számokat 1-től 500000-ig egy java.util.ArrayList-be.
Ennek mi köze van a témához?
Miért kellene nekem megírnom ezt java-ban?
Az a köze, hogy kiderült, hogy nem is ismered a Javat.
Ha elolvastad volna, hogy mire írom, akkor tudnád. Az "encapsulation"/"hidding" nem arra való, hogy szemellenzőt vegyünk, hanem arra, hogy egyszerűbb legyen az életünk, illetve ne tudjunk belenyúlni abba, amihez nincs közünk. Ettől függetlenül számos esetben illik ismerni egy osztály működését.
Például ha üres, alapértelmezett konstruktorral létrehozott listába pakolsz egymást után 500000 elemet, a háttér tömböt többször is meg kell növelni, majd az elemeket áttenni, ami nyilván nem az elérhető teljesítmény.
[quote:f24643d462="maszili"]
Én felvázoltam nemtetszésemet a java-val kapcsolatban. Erre jöttél (többek között) Te hogy megcáfold. Szerintem nem sikerült. Ezek után a fejemhez vágod hogy ...jol tudod fikazni azt a rendszert, amit nem is ismersz. Elmondtam hogy IGEN, csak felületesen ismerem!
DE Te aki JÓL ismeri, NEM tudja megvédeni az érveit egy olyannal szemben aki kevésbé ismeri???!!!
...
Viselkedjünk már felnőtt, komoly emberként.
Itt nem érvekről van szó, hanem arról, hogy durva kijelenteni az operator overloading hiánya miatt a Javáról, hogy rosszabb a filozófiája, mint a C++-é.
Ha nem ismered a Javát, kétlem, hogy ismernéd a filozófiáját, ergo mi alapján teszed a kijelentéseket? Ez komoly emberre vall?
Abból, hogy + jelet rakhatsz két objektum közé még a hatékonyság sem nő egyértelműen (nyilván kérdéses, hogy milyen hatékonyságot nézünk).
Banális példa: "sok" String összefűzése.
A hatékonyság más megközelítésből: írjál egy komplex üzleti logika alapján működő webalkalmazást.
Rugalmasság: dinamikus osztály betöltés/létrehozás, proxy, reflection. Ilyeneket tud a C++? De akár a memóriakezelést is idevehetjük, mert a kód rugalmassabban módosítható a GC-nek köszönhetően, mert a felszabadításokra kevésbé kell odafigyelni. De a rugalmasság kategóriába lehetne azt is sorolni, hogy ahol van JVM, ott a java programok általában azért elfutkosnak, mindenféle fordítgatás nélkül. És még biztosan hosszan lehetne sorolni, vica versa.
Itt két nyelvről van szó (ha eltekintünk a Java platform voltától), mindkettő megállja a maga helyét a megfelelő helyzetben, nyilván előfordul olyan eset is, amikor preferencia vagy egyéb szubjektív vagy más dimenziókban működő tényezők alapján történik a választás.
[quote:17b3e5a091="hanischz"]
Nos, aki írt bonyolult és nagy programot az tudja hogy a hibák száma a sorok számával nő!!!!! Hiába tudsz programozni...
Azért nem nulláztam változót, mert zavartak programozás közben (nem ideális munka környezet)! És persze nem tudtam figyelni. Nézd meg az MS programozókat. Láttam dokumentum filmet róluk, napi 16 órát is dolgoznak! Nehogy azt mondja valaki hogy 16 órán keresztül tud valaki koncentrálni...
Szia.
Nem tudom, hogy ki vagy, de egyet értek Veled.:)
Sőt hozzáteszem, a sorok számával és a program bonyolultságának fokával
egyenesarányosan nő a hibakeresés ideje.. és nehézsége.:)
Fri
Javaról: szerver oldalon elmegy.. kliens oldalon viszont
akkorát/annyit lehet szivni vele, mint egy szippntóskocsi/hivatásos..:)
[quote:b75f710769="aperger"][quote:b75f710769="lacipac"][quote:b75f710769="hop1"]És kimaradt a pascal :(
Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban.
Te KIS hátuldombolós gimnazista, TE aztán tudod!!!!
Erre a "hátulgombolós"-ra igazán dühös tudok lenni, ha hasonló tapasztalattal rendelkező ember puffogtatja, mint egy átlagos gimnazista lehet. Ha kivételes zseni vagy és mögötted van 4-5 vállalati project (nem feltétlen PASCAL-ban), akkor igen, mondhatsz ilyet.
...
Attila
szerintem olvasd el:
Az igazi programozó
http://www.szabilinux.hu/orlando_unix/igazi.html
" Legszembetûnõbb különbség a plebs és az igazi programozó között a használt nyelv. Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban."
alapmű. ismerni kell, nem magunkra venni. nem megsértődni.
"az igazi programozó akármilyen nyelvben is bír FORTRAN programokat írni"
[quote:98cdfa250b="ssikiss"]
Sorolnád, hogy mire *****?
Pl.:
- totál alkalmatlan olyan alkalmazáshoz, ami nagytömegű
dinamikusan változo adattal dolgozik (adatbázis), mert a
garbage collector működése enyhén szolva "késéges" és
kaotikus. (Jellemzően mit javasolnak a sun forumon: tegyél
a gépbe több memóriát, ne használd az alkalmazásod terminál
szerveren.. stb..)
Ami a legjobban tetszett: biztos memory leak van a progiban..:)
Erre kicsit bedühödtem és körülnéztem:
http://www.herongyang.com/jvm/
Szóval akárki akármit mond, a Java-ban a legnagyobb szivás a
garbage collector.
Fri
[quote:cefaceb114="fdavid"][quote:cefaceb114="hanischz"]Még pár év és több giga memória lesz a gépekben illetve még erősebb proci. Ilyen gépen remekül fognak futni a progik.
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
A masik, hogy enyhen szuklatokuruseg a dolgok jelen allapotaban a szoftverfejlesztest kizarolag PC-s (ertsd: szemelyi szamitogepes) kornyezetre vonatkoztatni. Ugyanis meglehetosen nagy szamu beagyazott eszkoz van korulottunk, amiket mar joreszt szinten magasszintu nyelveken (nagytobbsegeben C-ben) programoznak.
Hmmm, azt kell látni (legalábbis szerintem) hogy manapság nem a CPU és a memória mennyiség a szűk keresztmetszet. Hanem a programhibák tömkelege!
Nézd meg a mobil telefonod! Nem fagy néha? Talán C-ben írták :) Vagy egy csomó más progi pc-n. Linux vagy win alatt.. mindegy. Apache nevű webszerver c mivolta miatt (buffer túlcsordulás) törhetnek be internetről stb.
Egy általános programnál a megrendelő nem azt várja h egy 386-oson is elmenjen a progid, hanem hogy hamar! készen legyen és ne legyen benne hiba!
Tapasztalat!
A java-t is be lehet ágyazni.
Egyébként nem a java-t vagy a c#-ot magasztalom, mert azért megírhatták volna sokkal jobban is őket. Sajnos nekem túl szószátyár lett a java (azaz felesleges sorokat kell írni:rabszolgamunkát utálom), c# pedig túl az ms-hez kötődik, bár a mono feltörekvőben.
Hanem azt mondom h a mostani "válságra" (azaz hiba hiba hátán egy programban, pc, mobil telefon egyremegy, és kijavítanak egy hibát kettő új lesz), a megoldás a menedzselt kód.
Persze a teljesítményt követelő területeken minden csepp proci erőre szükség lesz, ott c vagy asm a megoldás egyelőre.
Az iparnak nagy a tehetetlensége, reégen váltani kellett volna de a konzervatívizmusuk miatt jön egy csomó probléma és általában a felhasznló szív. Pl miért kell egy routernek fagynia? Talán azért mert c vagy asm-ben gyorsan összehányták a kódot. Mert sajna a programozói munkahelyeken hajtják a programozót. Pedig ez szerintem művészet.
[quote:cfa1d3df2e="feledhetetlen"]hat netbeans az netbeans errol nem tudok nyilatkozni, en vi-t hasznalok
de kiprobaltam:
http://javasite.bme.hu/~lazlo/src/no-leak.html
es
Linux hill 2.4.31 #8 Sun Jun 5 19:08:07 PDT 2005 i686
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
nem latok semmi lenyeges elterest a gc-ben akar
java apro.study.leak.Main
akar
java apro.study.leak.Main null
probalom
szivesen segitek, ha megmondod mi faj neked a gc mukodesben...
Hmm.. megnéztem én is a programot amit összehoztál.
Kivettem belőle azt a "garafikont"(?), amit beletettél, mert bevallom 2-3 éve
még leesett volna az alsó álkapcsom.. sőt még pattogott is volna a padlón:)..,
hogy milyen ügyes vagy, ma azonban csak halkan felteszem a kérdést:
ugye azért ennél többet is tudsz?:)
Ajánlom figyelmedbe a közel egy tucat profilert.. de akár csak a jconsolt.
Ugyanis az a grafikon nagyjábol arra jó, hogy kezdőknek, vagy itt az olvasoknak maradjon tátva a szája, tényleges mélységi információt nem ad a "memóriában"
lévő objektumokrol. http://www.netbeans.org/kb/articles/nb-profiler-tutor-8.html
Megcsináltam a teszteket a programoddal, mindkét esetben ugyanazt a "rossz"
képet kaptam, mint az én megoldásomban a "rosszabbik" megvalósitásra (amiben
nincs helyi referencia).
De, hogy ne csak a levegőbe beszéljek, ki fogom rakni valahová a részleteket képpel
megtámogatva.. a hétvégén.. és azért megnézem én még mással is, azokban mit látok.
Fri
[quote:85e72087e7="ssikiss"]
Most a burkolt leszólástól eltekintve, miért lenne érdemes ezeket a nyelveket tanulni? Milyen problémákat lehet velük hatékonyabban vagy gyorsabban megoldani, mint amire a "népszerűbb" nyelvek képesek?
(mindíg is érdekelt a Scheme, Lisp)
ML-ről és funkcionális programozásról ez egy jó "miért is jó ez?" oldal:
A fő indok amúgy a verifikálhatóság és a korrektség ellenőrizhetősége.
Magyar infó, a 12. slide-tól érdekes:
http://dp.iit.bme.hu/prolog/eloadas_anyagok/dp05a-lpB1_p1.pdf
Ez meg egy egy sch-s projektben létrehozott SchML nevű nyelvről szóló előadás, pár érdekes háttérinfóral különböző nyelvekről:
http://nws.iif.hu/ncd2004/docs/0nj/nj101.htm
[quote:6cf3572894="sz"]
Az absztrakt első mondatában benne van a lényeg:
A very old and simple algorithm for garbage collection gives very good results when the physical memory is much larger than the number of reachable cells.
Nezd meg azt is, mikor szuletett ez az iras. 1986-ban!
Valaki meg bankokkal. Elárulom, hogy tapasztalataim szerint egyetlen egy olyan hazai szektor van, ami az államigazgatás informatikai sötétségével összemérhető gányolásokat alkot: a bankszektor. Néhol látszanak kivételek, de az összkép lesújtó. Telco-ban határozottan jó dolgozni, ott valahogy normálisabb a technológiai légkör.
(tessék megnézni java lista archívumát: pont múlt héten volt egy jsp-s kérdés, aholis a bank előírta, hogy minden kódnak a jsp-ben kell lennie... erre szokás azt mondani, hogy clueless).
[quote:05692856e9="maszili"][quote:05692856e9="KisKresz"]
Valójában halvány fogalmad sincs, mit csinál.
Pontosítsunk!
Valójában halvány fogalmad sincs, hogyan csinálja.
Ez így helyes.
Mivel OO -rol beszélünk nincs rá szükségem és nem is érdekel... nekem pont elég egy absztakciós szinttel feljebb lévő problémával foglalkozni.
[quote:05692856e9="KisKresz"]
Legfeljebb reménykedhetsz benne, hogy a programozónak is az volt a szándéka, amit te hiszel...
Szerintem a világ elég nagy százalékának ugyanazt jelenti pl. a = jel... :) Miért írná meg máskép a programozó?
Mert megteheti. És a programozó olyan állatfajta, hogy előbb-utóbb meg is teszi. Onnantól kezdve vagy bízol benne, vagy - és én inkább ezt csinálnám - utánanézel a dokumentációban, mi is történik. (Ugye VAN dokumentáció?) És akkor még nem is beszéltünk a leszármazott osztályokkal kapcsolatos problémákról, amiket viszont nem lehet olyan egyszerűen elintézni, hogy "de a programozó úgyse csinál olyat...".
Az igazat megvallva a C++ is képes összebonyolódni.
Amikor érték szerint adsz át objektumokat, akkor átláthatatlanul hívódnak meg a konstruktorok és míg te egy egyszerű programot írtál, lehet, hogy eszméletlen teljesítményt zabál a másolgatással, csak azért mert egy & referencia jelet kifelejtettél a függvények fejlécéből.
Mindenesetre én ilyen teljesítményproblémába nem futottam idáig. A teljesítményproblémák zöme át nem gondolt adatszerkezet miatt volt. Pl. lineáris keresések, amikor a referenciát cache-elhetni is lehetne.
Kezdő programozóknak a C++-t nem javasolnám. Maximum tesztelésre. A kezdő programozók java-ban kevesebb kárt képesek okozni, mint C++-ban.
A java szerkezetének köszönhetően pl. nem képesek globális változók millióit legyártani,... Persze java-ban is láttam már szemét kódot, de sokkal kevesebbet, mint C++-t.
C++-ban szebben lehet programozni, viszont a hülyék hihetetlenül átláthatatlan szemetet képesek gyártani.
Persze java-ról C++-ra váltani megint fájdalmas. Egy tipikus példa:
A legtragikusabb az, hogy ez a pár sor még le is futhat crash nélkül és csak a felhasználó számítógépén kezd fagyni. Legutóbbi munkám során ilyen kódot kellett karbantartani.
[quote:3c00dce0a5="snq-"][quote:3c00dce0a5="Andrei"]Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
a generalt kod sebessege pedig egyetlen szempont a sok kozul
[quote:972ac2e574="bocs"]
- pixel buzerálásra talán(!) mégis csak jó.
- numerikus alkalmazásokra inkáb Fortran. ezt akkor nem értem az előző pont miatt. ha ott jó, itt is jónak kellene lennie.
HPC numerikus alkalmazásokra jelenleg elterjedtebb a Fortran, de vannak próbálkozások (http://www.hpjava.org/) ezen a területen is.
[quote:972ac2e574="bocs"]
- memória kritikus alkalmazásokra nem jó
Inkább úgy mondanám, hogy nem tipikus objektumélethosszal rendelkező alkalmazások esetén GC tuningra és kézi memóriaméretezésre van szükség a jól teljesítő kód eléréséhez. Vagy 2x annyi fizikai memóriára, ami azért így a 64 bites computing teljes térnyerése (már a PC-k is!:) idején talán nem olyan erős követelmény.
Ameddig nem szemetelsz (értsd: nem kreálsz rengeteg közepes élethosszú objektumot, amik átcsúsznak a young generation-ből az eden-be vagy az old-ba) addig a GC nem visz el túl sok erőforrást: gyakorlatilag amit megspórolsz a new-n (mert csak egy pointer-t tolsz el a heap-en), azt elveszíted a GC-n. GC tekintetében az old generation GC-je az, ami drága, mert egy lassabb, mark&sweep/copy algoritmust használ a JVM (bár ezt is lehet kézzel változtatni), ráadásul ki tudja hány objektum került át az old gen-be (pl ha az elején lefoglaltál 800 MB-ot egy array-nak, amit soha nem dereferálsz, akkor az garantáltan ott fog csücsülni az old generation-ben)
- időzítés kritikusokra nem jó
Arra van ilyen:
http://java.sun.com/docs/books/realtime/
De az RT végülis jelentős mértékben függ a kerneltől, vagy akár a hardvertől...
- hardver közeli dolgokra szenvedés /driver szintről ne is beszéljünk/
tehát jó lesz ez éles képfeldolgozásra?
Nem mondtad még mindig meg, hogy másodpercenként hány képet kell feldolgozni, azt hol kell tárolni, honnan jönnek és ki mit csinál velük. Ha például az a feladat, hogy jönnek DICOM formátumban egy jól specifikált helyről, és bekerülnek egy data store-ba, majd csak a megjelenítésnél orvos szeme előtt kell rajtuk transzformációkat végetni, akkor teljesen jól lehet a feladatot Java-ban implementálni egy szép kis elosztott rendszerben.
érdekes, egyetlen szó sincs képfeldolgozásról. csak arról, hogy kórházi rendszer van Oracle adatbázis háttérrel, amihez Java a felület. Ebben mi a nagy szám?
Az, hogy a rendszer képeket, leleteket tárol és továbbít és tesz hozzáférhetővé az orvosok számára. Te pedig korábban azt írtad le, hogy Java-ban képek feldolgozása lehetetlen, teljesíthetetlen feladat.
Még egy dolog: a prog nyelvek legtöbbjét elég régen készítették. Pl.: Első UNIX, amely c-ben készült 24kB memóriájú szuperszámítógépen futott. Felét az oprendszer foglalta el.
Most nem nagy kunszt kevés hibát tartalmazó progit írni c-ben a maradék 12kB-ra.
(Ja: úgy tűnik utálom a c nyelvet pedig nem: egyik kedven nyelvem volt, de túl léptem rajta. Buildert az egyik legjobb fejl környezetnek tartom).
Megváltoztak a körülmények: akár több 100MB-os progikat több procira kell írni és a toldozott foltozott régebbi generációs nyelvek kevésbé alkalmasak mint egy újra tervezett nyelv.
[quote:c42a6c922c="popacsek"]Ezt nem igazán értem. Mi értelme van összehasonlítani a EGY BIZONYOS jvm verzió alatt futtatott java program memóriafoglalását EGY BIZONYOS környezet (oprencer/fordító/libc ...) alatt lefordított és futtatott C++ program memóriafoglalásával?
Körülbelül annyi, hogy ez az egy bizonyos, ez éppen és véletlenül a legkönnyebben hozzáférhető környezetek közül a legjobbnak számító. Azaz ha valaki nulláról kezd el foglalkozni valamelyik nyelvvel, akkor 95% eséllyel ezeknél köt ki.
[quote:c42a6c922c="popacsek"]Ebből kikerekedi vmi eredmény, ami alapján megállapítod, hogy "a java jobb mint A C++" ? Mi annak az akadálya, hogy egy hozzáértő ember írjon olyan memória-kezelő függvényeket/osztályokat C++ alá, ami übereli a javás eredményeket?
Semmi akadálya. Nyugodtan lehet überelni, kimérjük, publikáljuk. De most éppen ez az aktuális helyzet, ami. Az egész azt bizonyítja, hogy a Java nem rosszabb, mint a C++ :). Sokaknak már ez is sok, bele sem merek gondolni abba, mit szólnak hogyha az jön ki, hogy nemcsak hogy nem rosszabb, hanem jobb is :)
Az igazi programozó
http://www.szabilinux.hu/orlando_unix/igazi.html
" Legszembetûnõbb különbség a plebs és az igazi programozó között a használt nyelv. Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban."
alapmű. ismerni kell, nem magunkra venni. nem megsértődni.
"az igazi programozó akármilyen nyelvben is bír FORTRAN programokat írni"
Igaz... néha egy "kicsit" túl komolyan veszem ezt az egészet...
Köszi... Belenéztem... rendesen is el fogom olvasni...
[quote:6b065ac15b="Andrei"]
[..]
En fejlesztek C++-ban es C#-ban is munkam soran (es igazabol a C#-ot jobban szeretem), de eszembe se jutna ezt igy globalisan kijelenteni, hogy a GC leveri a hagyomanyos memoriafoglalast. Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
Mindennek megvan a maga helye. A manualis memoriagazdalkodasnak eppugy, mint a gc-nek.
A szemellenzos hozzaallassal van baj, mert hiaba meno valaki a manualis memorigazdalkodasban, real-world kornyezetben nem tud ezer fele (sokszor egymasnak ellentmondo) szempontot figyelbe vevo memorigazdalkodast csinalni. "Helyes" memoriagazdalkodast (nincs inicializalatlan memoriara hivatkozas, stb) meg kulonosen nem.
[quote:31b89ca6d7="Frimen"][quote:31b89ca6d7="fdavid"]
Pedig handler baratunknak igaza van.
http://www.digitalmars.com/d/
Itt mar csak az architektura hianyzik.
Nem olvstam végig, de..
>D is a fully garbage collected language
Na ez már alapból lehet al van b*szva!
Ezért sz*r a java is bizonyos dolgokra, mert garbage collector
a felelős a memóriáért: nincs a programozó kezében a memóra.
Fri
Olvass tovabb. Kezelheted a memoriat sk, es rabizhatod magad a garbage collectorra is.
[quote:d28bc66a4c="hanischz"]
Nos, aki írt bonyolult és nagy programot az tudja hogy a hibák száma a sorok számával nő!!!!! Hiába tudsz programozni...
Azért kell a problémát szétbontani több kisebb egyszerűbb problámára, hogy egyszerre csak kisebb dologgal kelljen foglalkozni. De ezt nem a programkód megírásakor kell tenni hanem még előtte a tervezési fázisban. Így nem lesz egybefüggő több ezer soros programkódod és konnyebben átláthatod. Hatékony eszközöket ad pl. a c++ arra hogy gyorsan és hatékonyan tudj programot írni... objektum orientáltság, polimorfizmus, template-ek, generikus programozás...
[quote:d28bc66a4c="hanischz"]
Azért nem nulláztam változót, mert zavartak programozás közben (nem ideális munka környezet)! És persze nem tudtam figyelni. Nézd meg az MS programozókat. Láttam dokumentum filmet róluk, napi 16 órát is dolgoznak! Nehogy azt mondja valaki hogy 16 órán keresztül tud valaki koncentrálni...
Ez a példa azt a véleményemet támasztja alá, hogy futásidőben történő hibajavításról van szó. Ami szugségtelen megfelelő odafigyelés/tervezés esetén.
[quote:d28bc66a4c="hanischz"]
Ezért kellenek a menedzselt és egyéb segítséggel felvértezett prog nyelvek h a rabszolga munkát a fordító automatikusan megcsinálja.
A fordítóprogram nem tudja kitalálni hogy mit szeretnél. Ha kifelejtesz egy műveletet akkor azt nem fogja kitalálni és megvalósítani helyetted. Ezért találták ki ezeket a futásidejű hibajavításokat amelyek mindenféle voodoo mágiával statisztikus módszerekkel megpróbálja helyrehozni a programozó baklövéseit úgy hogy nem ad százszázalékos biztonságot és fölöslegesen pazarolja az erőforrásokat.
miert van az, hogy errol azok irnak leginkabb akiknek nincsenek igazan megalapozott ismereteik, sem a javarol, sem a gc-rol, sem arrol, hogy a sebesseg mennyire nem minosit egy nyelvet...
nekem nem volt bajom soha sem a Cvel, sem a Cpluszplusszal,
/* hacsak nem a neve miatt ++?? */
de a Java abszolut 'kedvenc' nyelv nalam, es errol szolt a szavazas
nem azt latome a topiknyiton:
melyik a leggyorsabb nyelv?
ami amugy eleg butuska kerdes is,
megis egyre szuletnek valaszok ra
szoval kedvenc nyelv:
arrol irjunk miert szeretem a PHP-p, vagy miert szeretem a C-t
ne arrol, miert rossz a PHP multithread kezeles, vagy a Java gc...
[quote:53aa48db60="syntern"]
class QuickSort{
static final int NUM_ITEMS = 50000000;
int[] numbers=new int[NUM_ITEMS];
..
Bizonyára lehet máshogyan is csinálni részleteket, de tagadhatatlanul működik, és az a "röhejes" sorról sorra kód is látszódik, ha nem tévedek.
Sajnos nem tudom kiprobálni, mert a procim nem birja, a kernel "beszologat",
hogy kurblival állítgaja a frekvenciát.. igy hamis képet kapnék.. de hétvégén nézek,
valami szervert és azon megnézem..
Amugy.. bár tény nem értek sokat a c-hez én ugy tudom, hogy a 4-es gcc nem épp a
legjobban sikerült dolog.
De más.. érdekes kérdés ez a sebesség dolog..: http://www.kano.net/javabench/
.. és a "válasz".. http://www.freewebs.com/godaves/javabench_revisited/
Én függetlenül a tesztedtől, meg mindentől amit "olvastam" ismerve a java-t,
kevésbé a c-t, de a tapasztalataimat figyelembe véve, a c tenném a dobogóra
a java-val szemben.
Fri
Kivettem belőle azt a "garafikont"(?), amit beletettél, mert bevallom 2-3 éve
még leesett volna az alsó álkapcsom.. sőt még pattogott is volna a padlónSmile..,
hogy milyen ügyes vagy, ma azonban csak halkan felteszem a kérdést:
ugye azért ennél többet is tudsz?Smile
Ajánlom figyelmedbe a közel egy tucat profilert.. de akár csak a jconsolt.
Ezt a "grafikont"(?) 9 evvel ezelott csinaltam
Igen, tudok ennel tobbet is
Igen, ismerem a profiler-eket, a jconsole-t
Azt gondolom elhanyagolhatoan kicsi a kozos resze annak a ket halmaznak amit te tudsz a javarol, es annak amit en nem tudok
regebben ( http://javasite.bme.hu/~lazlo/src/muzeum/asm/ )
video jatekokat csinaltam 10 evig
Lehet meglepo, de en mar ugyanezt a fajta vitat vegigeltem mikor a C nyelv megjelent.
A C szar, a C nagy kodot csinal, a C lassu, maradjunk a gepikodnal.
Az Impossible Mission II nevu jatekban a vezeto fejleszto kitalalta, hogy o majd megirja C-ben Atatri-ST/IBM-PC-re, aztan a MANX nevu cross compiler csomaggal piff-puff atforditjuk a tobbi gepre.
Aztan mikor eljott a fejlesztesi ido vege fele a piff-puff ideje, leforditottuk a C kodot z80-ra 79K volt...
Kicsi baj volt, hogy a z80 16biten cimzett, es nemelyik target-nek kazettas magno volt a hattertara, igy kicsit furi a dinamikus toltes linkeles.
Szoval azt C kodot kezzel irtuk at z80 kodra Kovats Imivel (isten nyugosztalja). Akar meg is utalhattam volna akkor a C-t.
Aztan ugyanez volt a C++ is.
A C++ lassu, a C++ nem general jo kodot.
Hidd el, lattam mar dolgokat.
Java-t azota hasznalok amiota megjelent.
Rendre megirtam azokat a dolgokat amik meg-meg jelentek a kovetkezo kiadasban (perzisztencia/externalizacio, rmi, etc.)
Azt hittem, en vagyok balszerencses ezzzel, de aztan talalkoztam Gyepesi Gyurival aki egy egesz java szeru nyelvet csinalt meg.
Es aztan nem kis energiaval elmagyarazta, hogy akkor sem erdemes folytatni a fejlesztest, ha ez a nyelv jobb lenne mint a java.
Pedig az o nyelveben az activation framework mar alapbol benne volt mikor a javaban meg rmi sem volt.
[quote:b9377d1c37="Frimen"]Pl.:
- totál alkalmatlan olyan alkalmazáshoz, ami nagytömegű
dinamikusan változo adattal dolgozik (adatbázis), mert a
garbage collector működése enyhén szolva "késéges" és
kaotikus.
Még konkrétabban? Mi volt az a gyakorlati probléma, amit csak egyetlen módon lehetett megoldani a Java-val és az a GC miatt nem volt jó?
[quote:ba09bc95b8="handler"][quote:ba09bc95b8="Andrei"]
[..]
En fejlesztek C++-ban es C#-ban is munkam soran (es igazabol a C#-ot jobban szeretem), de eszembe se jutna ezt igy globalisan kijelenteni, hogy a GC leveri a hagyomanyos memoriafoglalast. Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
Mindennek megvan a maga helye. A manualis memoriagazdalkodasnak eppugy, mint a gc-nek.
A szemellenzos hozzaallassal van baj, mert hiaba meno valaki a manualis memorigazdalkodasban, real-world kornyezetben nem tud ezer fele (sokszor egymasnak ellentmondo) szempontot figyelbe vevo memorigazdalkodast csinalni. "Helyes" memoriagazdalkodast (nincs inicializalatlan memoriara hivatkozas, stb) meg kulonosen nem.
Felhivnam a figyelmedet, hogy ilyen kornyezetben a GC is borzaszto rosszul teljesit. A korkoros hivatkozasokkal pl. nemigen tud mit kezdeni, vagy erosen leromlik a teljesitmenye....
Sok tekintetben jobb, más tekintetben rosszabb.
Én sok helyen java-t használok, más helyeken C++-t.
Vegyünk egy példát: a KDE C++-ban van írva.
Ha grafikus felület alatt fish-et akarok használni, a KDE fish protokolját fogom elérni és nem szórakozom JAVA varázslással.
Nyilván linux alatt grafikus felületet nem véletlenül nem programozik senki JAVA-ban. Vagy GNOME, vagy KDE. Rengeteg linuxos programot használok, de egyik sem java-s felületű az Eclipse kivételéve.
Jegyezzük meg: egy C++ progit lefordítasz, azonos platformon jó eséllyel menni fog. Ez java-ra nem igaz. Ha nincs java telepítve, megszívtad. Márpedig alapból sem windowson, sem bizonyos linux disztribúciókon nincs java. Ha nem vagy rendszergazdi, megszívtad. Bár unixok alatt nagyon ritka, hogy ne lenne java.
Ha 5-ös java-t fordítasz és kihasználod az új API-t, az nagy valószínűséggel nem fog menni 1.4.2 és korábbi java-kon. Rengeteg szívás volt amiatt, hogy ahol a programot futtatták régebbi java volt.
Ha 2D / 3D alkalmazást akarok írni, ami több platformon is elfut, SDL-t választok, nem java-t. PC-n még nem láttam olyan java-s játékot, ahol rendesen lehetne scrollozni sebesség miatt.
A mobiltelefonos java kb. 20-szor olyan gyorsan scrolloz, mint a mezei PC-s referencia implementáció, pusztán azért, natív és kemény hardver gyorsítással megy.
Aki foglalkozott már 2D grafikával tudja, hogy mindenegyes ciklus fontos. Egyáltalán nem mindegy az a 60% sebességkülönbség. Egy 1000*1000 pontos felületen 1 Millió pontot kell újra rajzolni szükség esetén.
Jelentheti azt is, hogy a programod 1 GHz-en már nem fut el, csak 2 GHz-en. A jelenlegi gépek felét ugye kizártad.
Hozzászólások
[quote:9c0c8f42f5="bocs"]ajánlott irodalom: Knuth
nincs olyan hogy "a" legggyorsabb. minden a feladat részleteitől függ.
általában a quicksort gyorsabb.
Ah, elsőre nekem is a Knuth könyv jutott az eszembe, fel is ütöttem, de nekem egy magyar nyelvű van, amiben az algoritmusok nevei is magyarok. A mergesort melyik? Nem volt időm még este az egészet átnyálazni, csak láttam, hogy (cserélve) összefésülő, ilyesmik vannak. Vagy ez a mergesort is egy "család", sokféle megvalósítással?
Update: közben végigolvastam a thread végét is, és már nem aktuális a kérdésem :)
[quote:8f6b3e38b9="KisKresz"]
Mert megteheti. És a programozó olyan állatfajta, hogy előbb-utóbb meg is teszi.
Azért ennyire ne kanyarodjunk el a témától. :)
A téma nem az hogy melyik programozó milyen rossz programot készít. A téma az hogy melyik nyelv (c++ vs java) milyen eszközöket ad a kód megírásához.
[quote:8f6b3e38b9="KisKresz"]
Onnantól kezdve vagy bízol benne, vagy - és én inkább ezt csinálnám - utánanézel a dokumentációban, mi is történik. (Ugye VAN dokumentáció?)
Amikor az iskolában a tanárbácsi feladott egy ilyen példát
3 + 5
akkor Te mire gondoltál?
Arra hogy a gonosz tanárbácsi biztos jól ki akar baxni veled és nem összeadatni akarja a két számot hanem valami mást akar???...
na csináltam pár benchmarkot a gépemen (P4 3GHz, 512MB ram)
javac 1.5.0_05 fordito, java -cp . -Xmx250M parancssor
MS Visual C++ 2005 compiler, beallitasok: /Ox /Ob2 /Oi /Ot /Oy /GT /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MT /fp:fast /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt
QuickSort: a c++ 1.5-szer gyorsabban fut le 13468/8.703.
Erre lehet azt mondani, hogy elmegy.
Ha azonban egy icike picikét életszagúbb a feladat, ahol nem int-eket kell rendezni, hanem egy primitív struktúrát:
[code:1:82bf54d96c]class ArrayItem
{
public int Key;
public double Val1;
public double Val2;
public ArrayItem() {}
public ArrayItem(int aKey, double aVal1, double aVal2) {
Key = aKey;
Val1 = aVal1;
Val2 = aVal2;
}
};[/code:1:82bf54d96c]
Itt már érdekesebb a dolog: a sebességkülönbség itt több mint 5-szörös (9781/1812 tized annyi, vagyis 5M elemre).
Közben csúnyán szór a sebessége, néha 25%-kal lassabb. Mivel gyanítom, hogy ez a GC miatt van, 350MB-ra
felveszem a memóriáját. Ekkor elzabál 370MB memóriát az oprencertõl, de legalább a futásidõ fluktuáció megszûnik.
Struktúrát rendezni tehát én biztosan nem akarnék Java-ban.
De menjünk tovább. Az az ötletünk támad, hogy stringet is kellene tenni a rekordba.
A Val2 adattagot double helyett String-re cseréljük, amibe egy többnyire 7 jegyû számot teszünk.
String mûveletet ezzel ezután nem végzünk, csak rekord másolás van ide-oda.
Direkt memóriaigény: 5M * (4+8+7) = 95MB lenne.
Veszedelmes jószág a string, ugyanis ekkor 250 MB-nyi heap space kevés lesz a Java-nak, 350MB is, de 450 MB-ba már belefér.
Ezek szerint kb 4-5-ször annyi memóriát zabált a JVM, mint kellett volna.
A sebesség benchmark-hoz így levettem az 5M rekordot, 1M db-ra.
A sebesség mindössze kb 10-20%-kal vol gyengéb, mint c++ esetben, de memória használat 45MB vs. 180MB.
Következtetés: ha olyan feladataim vannak, ami feszegeti a futtató gép határait (cpu, memória), akkor
nem célszerû Java-t választani.
[quote:a63a3e87ba="syntern"]Az egész azt bizonyítja, hogy a Java nem rosszabb, mint a C++ :). Sokaknak már ez is sok, bele sem merek gondolni abba, mit szólnak hogyha az jön ki, hogy nemcsak hogy nem rosszabb, hanem jobb is :)
Nem. Az egész azt bizonyítja, az általad elkészített teszt (ami akár lehet hibás is, hiszen még nem láttuk) egy bizonyos implementációban/környezetben jobb értékeket produkált java környezetben, mint C++-os környezetben. Ez semmiképp nem jelenti azt, hogy a Java nem rosszabb, sőt jobb mint a C++.
Elméletileg egy java program nem futhat gyorsabban mint egy C++-os, mivel azt a byte-kódot futási időben kell lefordítani. A gyakorlatban persze előfordulhat ennek a fordítottja is, de ezt én inkább "implementációs hibának" tartom.
Ez persze nem jelenti azt, hogy a java rosszabb lenne a C++-nál.
[quote:77f6ed903d="lokoto"]Az a köze, hogy kiderült, hogy nem is ismered a Javat.
Mikor állítottam én azt hogy profi vagyok java-bol???????
Pont az ellenkezőjét állítottam! Azért kérdeztem meg itt azokat az embereket akik JÓL ismerik a java-t hogy felvilágosítást kapjak!
A kialakult helyzetre megpróbálok egy történettel válaszolni:
Egy vevő bemegy egy boltba és megkérdezi az eladót hogy az X termék tudja-e azt amit a másik boltban kapható Y. Az eladó megvizsgálja a kérdést és arra jut hogy az X tényleg nem tudja. Megpróbálja bebizonyítani a vevőnek, hogy de mégis... persze sikertelenül. Ekkor az eladó feldühödik és elzavarja a vevőt a francba azzal az indokkal hogy a vevő nem ismeri elég jól az X-et.
Költői kérdés: az eladó helyesen járt el?
[quote:77f6ed903d="lokoto"]
Ha elolvastad volna, hogy mire írom, akkor tudnád. Az "encapsulation"/"hidding" nem arra való, hogy szemellenzőt vegyünk, hanem arra, hogy egyszerűbb legyen az életünk, illetve ne tudjunk belenyúlni abba, amihez nincs közünk.
Részben... hozzátenném még azt is hogy jótékonyan elrejtse az objektum működését a felsőbb absztrakziós réteg elől.
[quote:77f6ed903d="lokoto"]
Ettől függetlenül számos esetben illik ismerni egy osztály működését.
Miért? Mit érdekel engem hogy pl. két mátrix objektum összeadásakor hogyan működik az összeadó algoritmus?
Amikor összeadsz két int típusú értéket akkor foglalkozol azzal hogy pl. a processzor milyen regisztereket használ a művelet során?... ugye hogy nem... csak az érdekel hogy az eredmény helyes legyen. És ez így van jól.
[quote:77f6ed903d="lokoto"]
Például ha üres, alapértelmezett konstruktorral létrehozott listába pakolsz egymást után 500000 elemet, a háttér tömböt többször is meg kell növelni, majd az elemeket áttenni, ami nyilván nem az elérhető teljesítmény.
Engem nem érdekel hogy a lista objektum hogyan oldja meg a problémáit. Az legyen a lista osztályt megíró programozó feladata.
[quote:77f6ed903d="lokoto"]
Itt nem érvekről van szó, hanem arról, hogy durva kijelenteni az operator overloading hiánya miatt a Javáról, hogy rosszabb a filozófiája, mint a C++-é.
Az operator overloading egy olyan eszköz ami egyszerűsíti / megkönnyíti a program írást. A java nem tudja mert az alap koncepciója (filozófiája) az hogy csak a gyárilag megírt operátorokat lehet használni, szemben a c++ filozófiájával ami támogatja a saját operátorokat. Ezek után én azt mondom hogy a java filozófiája rosszabb mint a c++ filozófiája.... ez így érthető volt? Ennél egyszerűbben már nem tudom leírni.
[quote:77f6ed903d="lokoto"]
Ha nem ismered a Javát, kétlem, hogy ismernéd a filozófiáját, ergo mi alapján teszed a kijelentéseket?
Fentebb már megválaszoltam... nem ismétlem magam.
[quote:77f6ed903d="lokoto"]
Ez komoly emberre vall?
Mindenképen... én személyeskedés nélkül kérdezek / érvelek.
[quote:77f6ed903d="lokoto"]
Abból, hogy + jelet rakhatsz két objektum közé még a hatékonyság sem nő egyértelműen (nyilván kérdéses, hogy milyen hatékonyságot nézünk).
Rendben... akkor próbálj úgy programozni hogy a + jel helyett használd ezt... szigorúan java stílusban :)
EzEgyOlyanOperátorAmiOsszeadjaAztAKétOperandustAmiAkétOldalánSzerepelDeAttólFüggőenHogyMilyenAKétOperandusTípusa
[quote:77f6ed903d="lokoto"]
A hatékonyság más megközelítésből: írjál egy komplex üzleti logika alapján működő webalkalmazást.
Parancs, értettem... :)
[quote:77f6ed903d="lokoto"]
Rugalmasság: dinamikus osztály betöltés/létrehozás, proxy, reflection. Ilyeneket tud a C++? De akár a memóriakezelést is idevehetjük, mert a kód rugalmassabban módosítható a GC-nek köszönhetően, mert a felszabadításokra kevésbé kell odafigyelni. De a rugalmasság kategóriába lehetne azt is sorolni, hogy ahol van JVM, ott a java programok általában azért elfutkosnak, mindenféle fordítgatás nélkül. És még biztosan hosszan lehetne sorolni, vica versa.
Belefáradtam... kész... ennyi... feladom!
[quote:2356c99071="maszili"][quote:2356c99071="KisKresz"]
Mert megteheti. És a programozó olyan állatfajta, hogy előbb-utóbb meg is teszi.
Azért ennyire ne kanyarodjunk el a témától. :)
A téma nem az hogy melyik programozó milyen rossz programot készít. A téma az hogy melyik nyelv (c++ vs java) milyen eszközöket ad a kód megírásához.
[quote:2356c99071="KisKresz"]
Onnantól kezdve vagy bízol benne, vagy - és én inkább ezt csinálnám - utánanézel a dokumentációban, mi is történik. (Ugye VAN dokumentáció?)
Amikor az iskolában a tanárbácsi feladott egy ilyen példát
3 + 5
akkor Te mire gondoltál?
Arra hogy a gonosz tanárbácsi biztos jól ki akar baxni veled és nem összeadatni akarja a két számot hanem valami mást akar???...
Nem, de annyit tudunk, hogy
a = b;
Nem volt szó pl. arról, hogy a és b típusa azonos (ugye, abból indultunk ki, hogy nem tudjuk a típusukat). Ebből levezetni, hogy ez mélymásolás...
KisKresz
[quote:6326daa089="Exit"]
Még konkrétabban? Mi volt az a gyakorlati probléma, amit csak egyetlen módon lehetett megoldani a Java-val és az a GC miatt nem volt jó?
Ha példa kell..:))
Menj föl a chat.hu-ra és lépj be.. akkor ugye elindul egy Java-s chat.
Használd és közben figyeld meg, hogy zabálja fel szép lassan a memórát,
(pl. KDE System Guard) azaz hogy foglal le egy kicsit, majd még egy kcisit..
Na most ezt szorozd be 10-el, mert egy adatbázis kezelő alkalmazás objektumok
százait (inkább ezreit) hozza létre egy sima lekérdezéskor is.
Szóval konkrétan:
- nekem a java-val az a bajom, hogy nincs a memoria kezelés a kezemben
(a System.gc() ugye sokra nem jó, a java parameterezése, mondjuk más
collector beinditása, vagy a heap birizgálása sem jár sok eredménnyel)
- a garbage collector sz*r, mert "ismeretlen" mikor ad vissza memóriát az OS-nek
(én még nem tapasztaltam ilyet)
Fri
Én mindennapos munkám során használok java-t és bizony vannak pillanatok, mikor nem nagyon szeretem.
Alapvetően xml-t szeretnék használni, de sajnos (ellentétben az msxml-es használattal) kényelmetlen, lassú és memóriaigényes.
Van pl egy lépés, amikor egy üzleti definíciót (mely egy 20 MB-os xml-ben van) kell XSLT-vel kitranszformálni (ant task), itt a javas xslt processzor rendszerint out of memoryval elszáll, és cammoghatok vissza a jó öreg msxml-hez, amely tutira megcsinálja, ráadásul fele annyi idő alatt.
Amúgy a PIKE-ra szavaznék, mert ha teljesítményre van szükség, akkor leprogramozom c-ben a "durva" részeket, ha pedig produktivitásra, akkor megírom pike-ban. Látott már valaki rajtam kívül PIKE-ot (http://pike.ida.liu.se/)??? :-D
hehe
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
[quote:186c997e3e="popacsek"][quote:186c997e3e="syntern"]Az egész azt bizonyítja, hogy a Java nem rosszabb, mint a C++ :). Sokaknak már ez is sok, bele sem merek gondolni abba, mit szólnak hogyha az jön ki, hogy nemcsak hogy nem rosszabb, hanem jobb is :)
Nem. Az egész azt bizonyítja, az általad elkészített teszt (ami akár lehet hibás is, hiszen még nem láttuk) egy bizonyos implementációban/környezetben jobb értékeket produkált java környezetben, mint C++-os környezetben. Ez semmiképp nem jelenti azt, hogy a Java nem rosszabb, sőt jobb mint a C++.
Elméletileg egy java program nem futhat gyorsabban mint egy C++-os, mivel azt a byte-kódot futási időben kell lefordítani. A gyakorlatban persze előfordulhat ennek a fordítottja is, de ezt én inkább "implementációs hibának" tartom.
Ez persze nem jelenti azt, hogy a java rosszabb lenne a C++-nál.
Lapozz vissza, bemásoltam az egyik példakódot. Kb. a 14. lap környéke. Ha nem hiszed, mérd ki magad. És de, futhat gyorsabban :)
[quote:cabad5397c="maszili"]
Arra hogy a gonosz tanárbácsi biztos jól ki akar baxni veled és nem összeadatni akarja a két számot hanem valami mást akar???...
Hmm, amikor Számításelmélet szigorlaton valamelyik véges testen, vagy gyűrűn értelmezett műveletnél kérdez a tanár egy ilyet... akkor valószinűleg elgondolkozom.
De most komolyan, mondjuk ket Bankszamla peldany eseten pontosan mire is alkalmaznad a + operatort? Es a melletted ulo programozo?
Ezt a linket meg nem kuldtem be:)
http://jazillian.com/reasons.html
[quote:699e9e12aa="Frimen"][quote:699e9e12aa="ssikiss"]
Sorolnád, hogy mire *****?
Pl.:
- totál alkalmatlan olyan alkalmazáshoz, ami nagytömegű
dinamikusan változo adattal dolgozik (adatbázis), mert a
garbage collector működése enyhén szolva "késéges" és
kaotikus. (Jellemzően mit javasolnak a sun forumon: tegyél
a gépbe több memóriát, ne használd az alkalmazásod terminál
szerveren.. stb..)
Ami a legjobban tetszett: biztos memory leak van a progiban..:)
Erre kicsit bedühödtem és körülnéztem:
http://www.herongyang.com/jvm/
Szóval akárki akármit mond, a Java-ban a legnagyobb szivás a
garbage collector.
Fri
Java != JVM Implementacio
[quote:5086026d29="Frimen"]
Ugyanis ha összetett mintát álmondsz meg, amiben "külső" osztályok
is szerepet kapnak, akkor lehet Te is jól megtervezted.. lehet ők is.. csak épp
a kettő együtt nem müködik..:) Lásd a listeneres példát..
Lously coupling:) De tenyleg. Legyen a modell egy facade es a valodi modellel kommunikaljon rmi-n, corba-n, soap-on keresztul (mondjuk fast infoset-tel). Nem hiszek abban, hogy ket kulon fejlesztogarda kozotti interfeszeket szorosan kellene csatolni.
Bovitsem ki a "tervezesi hiba" kategoriat "projektszervezesi" alkategoriaval?:)
[quote:29b0c63fbf="KisKresz"]
Nem, de annyit tudunk, hogy
a = b;
Nem volt szó pl. arról, hogy a és b típusa azonos ...
Ha nem azonos akkor szintaktikus hiba... fordítási időben...
[quote:29b0c63fbf="KisKresz"]
... (ugye, abból indultunk ki, hogy nem tudjuk a típusukat)....
De a fordító tudja...
[quote:29b0c63fbf="KisKresz"]
Ebből levezetni, hogy ez mélymásolás...
A c++ -ban csak egyféle értékadás van! Mivel az egész nyelv érték szerinti átadással mőködik, egyértelmű hogy az a = b átmásolja az adatokat. Ha ettől el kívánok térni (mutatókkal akarok dolgozni) akkor azt jeleznem kell... de akkor az látszik a kifejezésen.
[quote:6f5f3a1069="handler"]
Java != JVM Implementacio
Ez igaz is meg nem is..
.. igaz, mert mindkettő csak specifikáció..
.. nem igaz, mert a java jvm nélkül sokra nem jó, kirakod a kodot a
falra és gyönyörködsz benne?:)
.. nem igaz, mert foglalj már le légyszives "kézzel" memóriát java-ból,
majd szabadisd fel (ez a jvm "feladata)
Fri
[quote:dbfbd968eb="hop1"]És kimaradt a pascal :(
Meg még vagy 1234 nyelv, amiből minimum 123 előrébb tart a virtuális rangsorban, mint Wirth bácsi hátulgombólósoknak írt (lásd "Az igazi programozó" c. irományban) pacalja :-P
[quote:b4ab53c6f4="maszili"]Azért ennyire ne kanyarodjunk el a témától. :)
A téma nem az hogy melyik programozó milyen rossz programot készít. A téma az hogy melyik nyelv (c++ vs java) milyen eszközöket ad a kód megírásához.
Egyébként én nem ebben a témában írogatok. A C++ rengeteg eszközt ad nyelvi szinten (template, operator overloading, stb.). Itt azonban elhangzottak olyan dolgok, mint hogy az operator= miatt a C++ jobban OO, mint a Java, meg hogy az baj, hogy Javaban az a = b nem egyértelmű (a típus ismerete nélkül), míg C++-ban bezzeg... én csak ezekhez kapcsolódóan írom le a véleményemet.
KisKresz
[quote:55cdfc5f0f="feledhetetlen"]
melyik a leggyorsabb nyelv?
ami amugy eleg butuska kerdes is,
megis egyre szuletnek valaszok ra
Maximalisan igazad van, csak ez a hup. Itt en masfel eve majdnem kaptam egy ingyen "b@lf@sz" feliratu tomcat polot, csak mert azt mertem mondani egy cikkre reagalva, hogy az 5 kilences rendelkezesre allas nem az, aminek a cikkiro gondolta. Ha szakmai melysegekre vagyom, marad az angol szakirodalom. Hol vannak mar a 80-as, 90-es evek elejenek jo minosegu, kozertheto publikacioi es folyoiratai, amiket ha visszanezek mindig rajovok, hogy 1-1 kiemelkedoen tehetseges es lelkes embernek voltak koszonhetoek... Nomindegy.
[quote:7e6bbbd3e5="Csab"]Sok tekintetben jobb, más tekintetben rosszabb.
Én sok helyen java-t használok, más helyeken C++-t.
Kicsit megpróbálom tömöríteni amit mondtál: ha sebesség kell, hardveres gyorsítást használsz, és jelenleg azt C++-ból könyebben eléred.
Az összes többi kb. az, hogy megvan-e a runtime (JVM / megfelelő libek) vagy sem. Linuxra is van olyan, hogy nincs meg a lib, külön kell felrakni, ugyanez van Javaval is, nem látok lényeges különbséget, azon kívül, hogy a leggyakoribbak ott csücsülnek a Linux disztribben.
A hardver-gyorsítás Javaból is elérhető, a Java3D is ugyanúgy OpenGL-t használ mint egy C++ grafikus program. Persze, lehet mondani, hogy az XYZ hardverre nincs Java alapú hardveres gyorsítás, ez tény, ezt sohasem mondtam, hogy minden van. Én mindeddig csak azt állítom, hogy nem rosszabb Javaban programozni, mint C++-ban :)
[quote:2296392eba="feledhetetlen"]
Azt gondolom elhanyagolhatoan kicsi a kozos resze annak a ket halmaznak amit te tudsz a javarol, es annak amit en nem tudok
Én meg azt gondolom, hogy a nagyképűség az nagyképűség bármilyen szépen is
fogalmaz az ember, ha meg valaki olyan dedós szintre sűllyed mint az "én tudok
többet bibibi".. hát azt csak sajnálni tudom.
Fri
[quote:e0465724af="bocs"]na csináltam pár benchmarkot a gépemen (P4 3GHz, 512MB ram)
Hali!
Meg tudnád velünk osztani a forráskódokat? Én is szívesen lefuttatnám a tesztet.
Úgy hallottam, hogy win alatt talán szerencsésebb az ms c++ fordítóját használni, és nem a gcc-t - ez tényleg így van?
[quote:b2b78c5e61="zeller"][quote:b2b78c5e61="hop1"]És kimaradt a pascal :(
Meg még vagy 1234 nyelv, amiből minimum 123 előrébb tart a virtuális rangsorban, mint Wirth bácsi hátulgombólósoknak írt (lásd "Az igazi programozó" c. irományban) pacalja :-P
Gondolom neked is sikerult a thread elolvasasa nelkul obegatni. Koszi nekedis, tenyleg. Az erzes kolcsonos, ebben biztos lehetsz. 8)
[quote:22305b48a4="Andrei"]Felhivnam a figyelmedet, hogy ilyen kornyezetben a GC is borzaszto rosszul teljesit. A korkoros hivatkozasokkal pl. nemigen tud mit kezdeni, vagy erosen leromlik a teljesitmenye....
A mark and sweep vagy a stop and copy algoritmusra gondolsz? Azzal azert ugye tisztaban vagy, hogy hogyan is mukodik a gc a modern jvm-ekben? Hogy mikor es hogyan kerul egy objektum a young generation-bol a tulelo oregek koze, es ez gc-ileg pontosan mit is jelent: melyik generation-nel milyen algoritmusokat hasznal a jvm es ezt hogyan tudod te valtoztatni. Milyen statisztikai eloszlasa van az objektumoknak az eletidejuket tekintve, es erre vonatkozoan hogyan probalnak optimalizalni gc-ileg a virtualis gepek...
[quote:570d47c1b1="Frimen"] a nagyképűség az nagyképűség bármilyen szépen is
fogalmaz az ember
Frimen. Vedd észre, hogy kivel vitatkozol. Szerintem nem nagyképűség volt, csupán puszta tény.
[quote:576683589b="popacsek"]...
Elméletileg egy java program nem futhat gyorsabban mint egy C++-os, mivel azt a byte-kódot futási időben kell lefordítani.
...
toltesi idoben
vagy eppen barmikor, peldaul install time
nem lehet ezen tullepni ? a bytecode szukseges dolog
igy lehet kornyezet optimalizalni
a csuma-koppra-szevasz optimalizalt c++ kod a foditasi platformra van optimalizalva (vagy cross compilalva egy kornyezetre)
mi van ha a cel kornyezeten, mondjuk a memoria muveletek xxxlassuak de cpu gyors, vagy forditva
nekem ugytunik, hogy itt mindenki compiler optimizer szakerto, szoval talan csak be lehet azt latni, hogy a nativ kod generalasi lepesnek a cel kornyezet toltesi idejeben van eloszor jogsultsaga
amugy, a sebesseg NEM SZAMIT !!!
rule #1: do not optimize
rule #2: (experts only) do not optimize yet
Ennek olyan megmagyarázom a bizonyítvány szaga van.
Amikor leírod, hogy
a == b
tulajdonképpet mit akarsz?
Összehasonlítani a-t b-vel, vagy összehasonlítani a és b címét?
Az esetek döntő többségében eldönthető, mit csinál a plusz operátor.
person1.add( person2 )
Mi a fenét csinál? Csoportot, vagy házasságot?
A helyzet az, hogy rossz nevet adtak a függvénynek. Ez pedig nem az operator overloading hibája.
[quote:53c01cc256="handler"]
Felhivnam a figyelmedet, hogy ilyen kornyezetben a GC is borzaszto rosszul teljesit. A korkoros hivatkozasokkal pl. nemigen tud mit kezdeni, vagy erosen leromlik a teljesitmenye....
A legyegyszerubb refcount alapu gc nem tud mit kezdeni a korkoros hivatkozasokkal. Ez a legelso tema, amit gc tervezesenel felvetnek. Egesz jo RT GC megoldasok vannak mar.
Ettol fuggetlenul a GC *sem* univerzalis. Foleg ha van olyan ismereted, amit a GC nem tud kihasznalni.
[quote:39c7816d50="maszili"][quote:39c7816d50="KisKresz"]
Nem, de annyit tudunk, hogy
a = b;
Nem volt szó pl. arról, hogy a és b típusa azonos ...
Ha nem azonos akkor szintaktikus hiba... fordítási időben...
[quote:39c7816d50="KisKresz"]
... (ugye, abból indultunk ki, hogy nem tudjuk a típusukat)....
De a fordító tudja...
[quote:39c7816d50="KisKresz"]
Ebből levezetni, hogy ez mélymásolás...
A c++ -ban csak egyféle értékadás van! Mivel az egész nyelv érték szerinti átadással mőködik, egyértelmű hogy az a = b átmásolja az adatokat. Ha ettől el kívánok térni (mutatókkal akarok dolgozni) akkor azt jeleznem kell... de akkor az látszik a kifejezésen.
Aha...
[code:1:39c7816d50]
class BlaBla {
public:
BlaBla& operator=( const int i ) {
this->a = i;
return *this;
}
private:
int a;
};
[/code:1:39c7816d50]
[quote:aa6aef0964="KisKresz"][quote:aa6aef0964="syntern"]up, hátha valakinek még van hozzátennivalója (esetleg mérési eredmények? :) )
Belegázolni mások hitébe holmi mérési eredményekkel... :-)
KisKresz
Van aki a mérési eredményekben hisz :)
[quote:bc92be6204="Frimen"]Sajnos nem tudom kiprobálni, mert a procim nem birja, a kernel "beszologat", hogy kurblival állítgaja a frekvenciát.. igy hamis képet kapnék.. de hétvégén nézek, valami szervert és azon megnézem..
Amugy.. bár tény nem értek sokat a c-hez én ugy tudom, hogy a 4-es gcc nem épp a legjobban sikerült dolog.
Én függetlenül a tesztedtől, meg mindentől amit "olvastam" ismerve a java-t,
kevésbé a c-t, de a tapasztalataimat figyelembe véve, a c tenném a dobogóra a java-val szemben.
Fri
Persze, barmit tehetsz a dobogora, figyelmen kivul hagyhatod a tenyeket, hivatkozhatsz a csillagok egyuttallasara, meg arra, hogy a legfrissebb verzio igazabol joval rosszabb. Csak egyet kerek: ne hivatkozz a jovoben arra, hogy a Java lassu, amikor akar ki is merheted, hogy nem az, vagy ha nagyon kotozkodni akarsz es -O3-at hasznalsz, akkor nem lenyegesen lassu. Kosz.
[quote:315934cad1="maszili"]
Ezzel bonyolítva az értékadás műveletét... mert így többféle értékadásról beszélünk attól függően hogy az operandusok mik is valójában...
pl. ha csak ennyit látsz a kódból
a = b ;
akkor meg tudod mondani hogy az egyenlőség mit csinál?
Valószínüleg nem mert nem tudod hogy az a és b micsoda is tulajdonképen. Most átmásolja a tartalmát vagy csak a címét???... :)
Mivel a java erősen típusos nyelv, illik tudni a változók típusát. Ha tudod a változók típusát, meg tudni mondani, hogy mi történik.
No de mi a helyzet C++ esetén? Ott még ennyit sem lehet megmondani, de a kérdés inkább az, hogy van-e ennek a kérdésnek önmagában értelme?
Nincs, mert 'a' mást jelent Java és C++ esetén, így a műveletek is másként értelmezendők.
[quote:315934cad1="maszili"]
[quote:315934cad1="lokoto"]
Nyilván az ==-et is felül lehetne definiálni, de lássuk be, hogy az egyik kolléga által felvázolt szemethalmazt kapjuk nagyon rövid idő alatt, mert senki nem fogja tudni, hogy mi micsoda.
Ez nem igaz...
Az == (összehasonlító) operátor MINDÍG azt jelenti hogy valamilyen szempontból a két operandus "egyenlő" vagy sem. Az eredménye mindíg egy igaz / hamis logikai érték lesz.
Egyrészt a "mindig" mindig rövid i-vel van akár "MINDIG", akár "mindig", akár valamilyen egyéb kis- / nagybetű kombináció.
Másrészt nem állítottam, hogy nem logikai értéket ad vissza, hanem azt, hogy Neked kell megírnod az összehasonlítást ahhoz, hogy el tud dönteni igaz vagy hamis a vizsgálat. (feltételezve, hogy Javaban felül tudod definiálni a =-t, azaz látszik, hogy egy ilyen apróságnak, mint operátor felüldefiniálásnak milyen következményei vannak/lennének, ha egyáltalán az általad hiányolt lehetőségnek lenne értelme Javában)
Nézd, én semmiről nem akarlak meggyőzni, csak fogadd el azt, hogy amit egy Sun kaliberű cég létrehozott, majd amit egy Microsoft kaliberű cég lemásolt (vagy nem, de nem is ez a lényeg, hanem az, hogy hasonlót alkotott), nagyon sokan elfogadnak, annak a hátterében lehet valami.
Nem állítom, hogy a java mindenre jó vagy legjobb, de azért rosszabbnak minősíteni a C++-nál és leszólni, mert az = nem lehet klónozás és nincs benne pointer, meglehetősen korlátolt agyjárásra vall, ugyanis attól, hogy a szintaktikájuk hasonló (sőt, bizonyos részletekben azonos), a szemantikájuk *más*.
Az eltérő szemantika pedig a háttér rendszer/elképzelés következménye/velejárója/....
[quote:0d522db1c2="syntern"]
Küldj egy címet és elküldöm a konkrét kódokat. De hogy megnyugtatóbb legyen: ugyanúgy programozta le mindkét nyelvben pl. a mátrix-hatványozást, vagy a quicksortot (ugyanolyan induló tömbértékekre), ill. a prímszámkeresést. Nem nagy dolgok, de memóriazabáló (fusson a GC) és procizabáló (legyen idő mérni) feladatokat kerestünk. Direkt úgy készítettük elő a mérést, hogy semmi zavaró tényező ne legyen benne, tisztán a sebesség legyen mérhető, semmi mellébeszélés.
Na igen.. ezek azok a tipikus semmire nem jó idióta
tesztek, amiket jópáran alakalmaznak az ámitástechnikában.:)
Elég ha a Linux - Win$ összehasonlitásra gondolni..:)
Amiről itt szóvan az akárhogy is nézzük hamis képet ad.
Elhiszem.. lehet, hogy isztán tudományos számításoknál megállja
a helyét ez a "teszt", tényleg eléri a C-s teljesítményt a java, de könyörgöm,
a szoftverek 90 százaléka nem erről szól!!
Ott van felhasználó, a maga eseményeivel, általában grafikus felületet a
szolver,, lehetnek "nyulványai" (adatbázis, rmi, stb..) egy szoftvernek, amiket
kezelnie kell.. szóval ez egy idióta teszt sok szempontbol.
Fri
[quote:45b9de954f="kr304"][quote:45b9de954f="Exit"]Azoknak meg, akik azt mondják, hogy Java-ban a hülyék programoznak: :lol:
Én szeretem a C-t és a C++-t, de azért egy Java... Az osztálykönyvtára, meg a platformfüggetlensége meg az, hogy fél óra alatt összehozok egy J2EE webservice-t, hozzá egy webes, egy J2SE-s és egy mobilos klienst... Ekkora produktivitást mikor kapok én a C++-tól?
Hallottál már a GSoap-ról?
A leggyakrabban használt funkciók megvannak a C++ világban is, ez nem annyira nagy dolog, ahogyan megvannak a .NET világban is a megfelelő libek. De ha a könnyebbséget vizsgálod (ami erősen relatív és függ a múltbéli tapasztalatoktól), akkor valószínűleg ki fog jönni, hogy nem feltétlen a C++ a legkönnyebben kezelhető eszköz, a hosszú távú kódkarbantartásra és a platformok közötti hordozásra (főleg mikor már érint grafikus részeket is) biztosan nem.
Én például nagyon kedvelem azt, hogy Linux / Windows / Solaris alatt ugyanabban a fejlesztői környezetben, ugyanúgy lehet fejlesztenem, ami ugyanúgy néz ki eredményben mindenhol. Elméletileg a C++ is képes erre, a gyakorlatban elég nehéz kivitelezni (vagy nekem nem ment, mindenesetre nem próbáltam sokáig, hamar rátértem Javara).
[quote:d8703b8dc4="Csab"]Teljesen már szemszögből szemléljük a világot.
Én mobiltelefonokkal foglalkozom. Plusz néhány megabyte tudod mit jelent mobil telefonoknál?
A Security nekem azért fájó pont, mert sajnos "felsőbb döntésre" security-t is kellett implementálnom. No most valami hihetetlen értelmetlen dolgokkal kellett foglalkoznom ezalatt.
Pl. az összes:
AccessController.check( perm );
hívást le kellett cserélnem
SecurityManager sm = System.getSecurityManager();
if( sm != null )
sm.check( perm );
-re, minthogy az AccessController.check nem működik helyesen minden esetben. Szóval leimplementáltam a security-t, fogalmam sincs, hogy mi miért úgy megy ahogy, a tesztek végig futottak, többet nem akarom látni.
Sajnos nagyon mély vízbe dobtak legutóbb, mert a security mellett ClassLoader-t is kellett írnom, reflection-özni és a ProtectionDomain átizélgetése után eljutottam odáig, hogy elegem van a java-ból.
az erdekelne hogyan csinaltal mobil telefonra ClassLoader-t
de tenyleg
de mar az is jo lenne ha megmondanad, mit jelent ez bárhol a kódban: [code:1:d8703b8dc4]synchronized (this) {}[/code:1:d8703b8dc4]
Mindig mosolygok a java-s mátrix implementációkon.
java
Matrix result = (((a.add( b )).multiple( c )).divide( 23. )).inv();
c++
Matrix result = ~(((a+b)*c)/23);
[quote:89f56dd9a0="feledhetetlen"]
http://javasite.bme.hu/~lazlo/src/muzeum/asm/
Egy valami tűnt fel az első forrásban: SUB AX,AX. Ez is egy órajel idejű művelet volt, mint a XOR AX,AX? (nincs már meg a 386-os utasításainak órajeltáblázata, pedig...)
Amennyire gány volt az x86 asm, én annyira szerettem használni... régi szép idők...
[quote:03cbac0f11="maszili"][quote:03cbac0f11="KisKresz"]
Valójában halvány fogalmad sincs, mit csinál.
Pontosítsunk!
Valójában halvány fogalmad sincs, hogyan csinálja.
Ez így helyes.
Mivel OO -rol beszélünk nincs rá szükségem és nem is érdekel... nekem pont elég egy absztakciós szinttel feljebb lévő problémával foglalkozni.
Mókás :-)
Újabb egyszerű feladat: egy java.util.ArrayListbe tedd bele az egész számokat 1-től 500000-ig.
[quote:910a1b3f88="syntern"]valószínűleg ki fog jönni, hogy nem feltétlen a C++ a legkönnyebben kezelhető eszköz, a hosszú távú kódkarbantartásra és a platformok közötti hordozásra (főleg mikor már érint grafikus részeket is) biztosan nem.
hmmm
QT?
"kissé" gyorsabban válaszol desktopon, mint egy javas felület.
persze megy unixokon, win-en, PDA-n stb.
[quote:97a675355e="Csab"]
A helyzet az, hogy rossz nevet adtak a függvénynek. Ez pedig nem az operator overloading hibája.
A helyzet az, hogy OO szemponból a mai napig a smalltalkot tartom a legjobbnak, még ha a szintaktikáját valószinűleg egy évtized alatt sem bírnám megszokni (too seventies). Az a nyelv például operátorok nélkül is teljesen jól megvan.
A helyzet tovább az, hogy az operátorok matematikai szimbólumok. Így matematikai objektumok esetén lenne értelme a felülbírálatuknak. Ha Java-ban lehetőség lenne a java.lang.Number-ből származtatott osztályoknál operator overloading-ra, annak valószinűleg látnám értelmét. Általános, üzleti objektumok esetén operátorokat definiálgatni metódushívások helyett azonban szerintem a legnagyobb bűn, amit ember a munkatársai vagy az utódja ellen elkövethet.
[quote:2bb0dfc574="lokoto"]lemásolt (vagy nem
ha meg az operator overloading a tema, akkor nem teljesen: C# Overloadable Operators
Úgy látom egy dologban konszenzus van: a C alapvető szerepét nem
kérdőjelezi meg senki. Ennek nagyon örülök. Én erre voksoltam, de csak
azért mert már vagy 5 éve nem használok assemblyt PC-n.
[quote:5bc1dc15af="_Joel"][quote:5bc1dc15af="feledhetetlen"]
http://javasite.bme.hu/~lazlo/src/muzeum/asm/
Egy valami tűnt fel az első forrásban: SUB AX,AX. Ez is egy órajel idejű művelet volt, mint a XOR AX,AX? (nincs már meg a 386-os utasításainak órajeltáblázata, pedig...)
Amennyire gány volt az x86 asm, én annyira szerettem használni... régi szép idők...
xor reg,reg 001100dw
88/86 3
286 2
386 2
sub reg,reg 001010dw
88/86 3
286 2
386 2
a sub ax,ax kifejezobb szerintem, es nullaza a auxiliary carry-t is
ami xor ax,ax utan hatarozatlan allapotban van
[quote:7fb4c93e87="feledhetetlen"]amugy, a sebesseg NEM SZAMIT !!!
Szerintem inkább maradjunk annyiban, h vannak esetek, amikor a sebesség nem számít.
[quote:9dbc355912="maszili"]
Ez a példa azt a véleményemet támasztja alá, hogy futásidőben történő hibajavításról van szó. Ami szugségtelen megfelelő odafigyelés/tervezés esetén.
Lehet. De akkor az autómban az ABS, a kipörgésgátló és a menetstabilizátor is ugyanilyen felesleges hibajavítás. Ami szükségtelen megfelelő odafigyelés/vezetés esetén. Mégis életet/anyagiakat menthet.
[quote:96dbdb3c6d="Andrei"][quote:96dbdb3c6d="gee"]en UML modellezesre Umbrello-t hasznalok, es tetszik. Ja, ez QT, nem swing.
Ugy alapjaban veve tetszett volna, de nekem Windowsos valtozat is kellene.
Megjegyzem, QT van Windowsra. De nem tudom, maga az Umbrello megy-e.
Te megnezted, es nincs w32 valtozat?
Üdv!
Bár nem akarok ismét beszállni a java vs c vitába, mert korábban leírtam a véleményem, de van még egy valószínűleg javában írt játék: IL-2 nevű rep szimulátor, a legjobb amit láttam...
Be van ágyazva (úgy mint a chrome-ba) a java futási környezet. És elég szép...
[quote:51210f6da3="handler"][quote:51210f6da3="lzrd"]
Tudnál jogszabályra hivatkozni?
Nekem laikusként úgy tűnik, nincs igazad. Gondolok pölö a "Magas feszültség! Életveszély!" táblára. Gondolom ezzel analóg módon, ha a programod forrásába/dokumentációjába, első megjelenő felhasználói interfészébe beleírod, hogy nem vállalsz felelősséget, akkor csak nem verhetik el a port rajtad, nem?
PTK/A kártérítés általános szabályai:
342. § (1) Semmis valamely szerződésnek az a kikötése, amely a szándékos vagy súlyos gondatlanságból eredő károkozásért, az életben, a testi épségben, az egészségben okozott károsodásért, továbbá bűncselekmény következményeiért való felelősséget előre korlátozza vagy kizárja.
Ezexerint nincs igazad, hála a magasságosnak, de azért köszi! :)
Szal nem verhetik el a port a programozón, ha nem súlyosan és nem szándékosan gondatlan...
[quote:2439693bd5="Frimen"]Na igen.. ezek azok a tipikus semmire nem jó idióta
tesztek, amiket jópáran alakalmaznak az ámitástechnikában.:)
Elég ha a Linux - Win$ összehasonlitásra gondolni..:)
Amiről itt szóvan az akárhogy is nézzük hamis képet ad.
Elhiszem.. lehet, hogy isztán tudományos számításoknál megállja
a helyét ez a "teszt", tényleg eléri a C-s teljesítményt a java, de könyörgöm,
a szoftverek 90 százaléka nem erről szól!!
Ott van felhasználó, a maga eseményeivel, általában grafikus felületet a
szolver,, lehetnek "nyulványai" (adatbázis, rmi, stb..) egy szoftvernek, amiket
kezelnie kell.. szóval ez egy idióta teszt sok szempontbol.
Fri
Bizonyára Te is belátod, hogy egy ilyen teljesítménymérő tesznek nem az a célja, hogy az adatbázis sebességét mérje, mivel az pl. mind C++-ból, mint Javaból nagy valószínűséggel ugyanannyi lesz. Hasonlóképpen vonatkozik ez diskműveletekre, hálózatra, mert itt is az overhead nem a nyelv és a managelt környezet, hanem dominánsan a TCP stack, a vas, a kábel. Szóval ha tudsz mondani olyan tesztet, ami tisztán a Java managelt környezetet hasonlítja össze a C++ natív futásával, és nem ez a "tipikusan buta" teszt, akkor szeretettel várom és kimérem. De amíg csak azt tudod mondani egy neked nem tetsző eredményre, hogy ez butaság, addig ne haragudj, de nem tudom komolyan venni amit írsz.
Kihagytam a felhasználói felületet. A tesztünk kifejezetten elkerült mindent ami a felhasználói felülettel jár, mivel az csak és kizárólag szubjektív mérés lehet. A szépség fogalmának mérése leginkább a megszokottságéval korrellál, a sebességet mérni pedig még nem sikerült kitalálnom, hogyan lenne célszerű és pontos.
Szóval ha van elképzelés, hogy hogyan máshogy lehetne összehasonlítani a C++-t a Javaval, akkor szeretettel várom, addig pedig csak azt tudom mondani, hogy a C++ semmilyen előnyt nem nyújt az alkalmazások nagy részében a Javahoz képest, amivel szemben a Java azért tud előnyt biztosítani.
[quote:cccc5bae8b="_Joel"][quote:cccc5bae8b="Frimen"] a nagyképűség az nagyképűség bármilyen szépen is
fogalmaz az ember
Frimen. Vedd észre, hogy kivel vitatkozol. Szerintem nem nagyképűség volt, csupán puszta tény.
1. Arra akarsz célozni, hogy essem hasra az előtt, aki valahol oktat, tanit
programozást, java-t, vagy mert 9 éve foglalkozik java-val mig én csak 5
éve? Hmm.. elég érdekes gondolat.. ilyesmi távol áll tölem.
2. Egy tény is lehet nagyképűség, nem zárja ki egyik a másikat.
MIndemellett nem vitatom, nyilván sokkal többet tud nálam a programozásról,
csak nekem tényleg kicsit fanatikus+"ekkora m ellényem" tipusnak tünik a fickója.
Szerintem ez a java & C sebesség kérdésében igen csak megmutatkozik.
Amugy érdekes.. azt vártam valaki reagálni fog itt a c-s példára, de nem..
Valószinű nem ez a legjobb forum ilyesmire..
Fri
[quote:93418b7220="bocs"]na csináltam pár benchmarkot a gépemen (P4 3GHz, 512MB ram)
javac 1.5.0_05 fordito, java -cp . -Xmx250M parancssor
MS Visual C++ 2005 compiler, beallitasok: /Ox /Ob2 /Oi /Ot /Oy /GT /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MT /fp:fast /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt
QuickSort: a c++ 1.5-szer gyorsabban fut le 13468/8.703.
Erre lehet azt mondani, hogy elmegy.
Kérlek mérd ki a Java-t -server kapcsolóval. Ha megfigyelted a példáimat, akkor kijön, hogy a -server kapcsoló lényegesen jobb. Valamint nagyon érdekelne a struktúrás programkód, hogy mennyire sikerült ugyanazt megvalósítani a két nyelvben. A memória-számolási értékek is gyanúsak. A Java 16 biten tárolja belül a Stringet, köszönhetően az Unicode-nak, bár nem ismerem az MSC++-t, hogy az hogyan, gyanítom ez is benne van.
Szóval amit leírtál, az nagyon gyanús, hogy valami nem ugyanolyan. El tudnád küldeni a kódokat?
Hát nem tudom. Én tudok legfeljebb 4-6 sorban XSLT-t transzformálni, és ebben a validálás is benne van. Az out-of-memory-ra pedig tessék megtanulni a -Xmx kapcsolót. Egy 20MB-os XML beolvasva 40MB (Unicode), innen indul a feldolgozás... A teljesítményre meg ott a -server kapcsoló :) (Be lehet állítani alapértelmezettnek is)
[quote:756144bb16="Csab"]
Ezt hogyan oldják meg?
Mármint, a jar-ban van egy "blabla" sztring, b jarban hasonlóképen szintén van egy "blabla" sztring.
a-jaros "blabla" == b-jaros "blabla" ?
Ujra:
Literal strings within different classes in different packages likewise represent references to the same String object.
a likewise szo jelentese megvan?
[quote:18e561dc66="ssikiss"]Úgy néz ki, meg kell barátkozni a gondolattal, hogy egy pascal nem fér bele az első 10 választási lehetőségbe (mondjuk annyi szavazatot kapott volna, mint a lisp valszeg).
Allok elebe, hogy a Lisp/C#/Assembly/Ruby negyesbol barmelyiket lenyomna, ha lenne Pascal lehetoseg. De persze nincs, mert az hatulgombolosoknak valo, nem l33t f4c3z h4x0roknak biztos. Foleg figyelembe veve h. min. 2 embert tudok, aki pl. assembly-re szavazott mert nem volt Pascal, ami jelen allas szerint az asm-ra leadott vote-ok tobb mint 10%-a...
Ez nincs, sajnos... :(
[quote:d3674484d1="_Joel"]... Nomindegy.
szerintem nem mind1
ez egy jo forum
azt szeretnem hinni, hogy barmennyire is azok latszanak minositeni egy forumot akik irnak bele, megis az olvasas miatt van a forum
senki nem irna, ha nem olvasnak
mindig arra gondolok, biztos vannak akik csak olvassak
es lehet tobben vannak mint azok akik triggerelik a:
"ha hallgattam volna, bolcs maradtal volna" kenyszert masokban
naiv post-jaikkal
megis ertelme van igy is: nyitottsagot eredmenyezhet
attol tartok sem az oktatas, sem a kiscsoportos fejlesztes,
nem ad tul sok lehetoseget arra, hogy kilassunk a tankonyvbol,
vagy eppen a kovetkezo (mar megint kesunk) milestone nyomasa alol
szoval szerintem, nyugodtan irjon mindenki akinek van kedvence
irja le miert az
ennek a nalunk is honos porosz oktatasi rendszernek az a legsulyosabb nyuge, hogy megtanit "nem tevedni"
pedig a tevedes, a probalkozas, ezek az alkoto megismeres iranyjelzoi
szoval azt gondolom szabad tevedni, szabad lelkesedni
szabad azt mondani az XP thread schedulererol, hogy jo
szabad a solaris rendszer konfiguralasara azt mondani, hogy ertheto
es szabad erre valaszolni
nekem kedvenc nyelvem a Java :)
[quote:15ad25d839="Chain-Q"]Allok elebe, hogy a Lisp/C#/Assembly/Ruby negyesbol barmelyiket lenyomna, ha lenne Pascal lehetoseg.
igen, a HUP olvasoi kozott, ahol a kedvenc nyelv a php, biztosan kedveltebb lenne ezeknel.
de ha egy kicsit elvonatkoztatunk ettol a szavazastol, melyek lennenek az (object) pascal -mint nyelv, mert azokrol beszelunk- azon featurejei, amikkel lebeszelnel arrol a fixa ideamrol, hogy a c# -az osszes featurejevel- superior a mezonyben (ismet: mint nyelv, mert azokrol beszelnuk)?
[quote:e67f58a0e8="_Joel"]Lehet. De akkor az autómban az ABS, a kipörgésgátló és a menetstabilizátor is ugyanilyen felesleges hibajavítás. Ami szükségtelen megfelelő odafigyelés/vezetés esetén. Mégis életet/anyagiakat menthet.
De legalább ki lehet kapcsolni... (;
[quote:d068f01560="lokoto"]
Mivel a java erősen típusos nyelv, illik tudni a változók típusát. Ha tudod a változók típusát, meg tudni mondani, hogy mi történik.
Ha ez így működik akkor szerintem a nyelv a programozóra hárít egy feladatot... mert a programozónak kell fejben tartania az osszes általa használt objektum típusát és megfontolni hogy pl. egy értékadás esetén hogyan is működik az értekadás...
[quote:d068f01560="lokoto"]
Egyrészt a "mindig" mindig rövid i-vel van akár "MINDIG", akár "mindig", akár valamilyen egyéb kis- / nagybetű kombináció.
Mivan?... már nincs mibe belekötni????... :-D
Ok. Ezek után rövid i-vel írom.
[quote:d068f01560="lokoto"]
... Neked kell megírnod az összehasonlítást ahhoz, hogy el tud dönteni igaz vagy hamis a vizsgálat.
Pontosan! És ez így van jól. Én találtam ki azt a típust csak én lehetek az aki meg tudja mondani hogy miként kell összehasonlítani. De ha már megmondtam / megírtam akkor az osztályomat felhasználóknak már nem kell törődni vele a felhasználás során. Egyszerűen használhatja az összehasonlító operátort mint ahogy korábban, más adatípusok esetében.
[quote:d068f01560="lokoto"]
Nézd, én semmiről nem akarlak meggyőzni, csak fogadd el azt, hogy amit egy Sun kaliberű cég létrehozott, majd amit egy Microsoft kaliberű cég lemásolt (vagy nem, de nem is ez a lényeg, hanem az, hogy hasonlót alkotott), nagyon sokan elfogadnak, annak a hátterében lehet valami.
Engem nem érdekel az hogy egy nagy cég hozta létre... attól még nem biztos hogy jobb valami ha egy nagy cég készítette.
Porkoláb Zoltán (elte) mondta annakidején az előadáson hogy az ada-t egy bizottság készítette a c-t meg egy zseni. :)
[quote:d068f01560="lokoto"]
...de azért rosszabbnak minősíteni a C++-nál és leszólni, mert az = nem lehet klónozás és nincs benne pointer, meglehetősen korlátolt agyjárásra vall,...
Kérem mellőzni a személyeskedést! :evil:
Több oldalon keresztül próbálom megvilágítani példákkal hogy szerintrem miért nem jo a java...
[quote:d068f01560="lokoto"]
... ugyanis attól, hogy a szintaktikájuk hasonló (sőt, bizonyos részletekben azonos), a szemantikájuk *más*.
Az eltérő szemantika pedig a háttér rendszer/elképzelés következménye/velejárója/....
Itt alapvető filozófiai eltérésekről van szó, nem szintaktikai / szemantikai eltérésekről.
[quote:3a1049ca90="sz"][quote:3a1049ca90="feledhetetlen"]amugy, a sebesseg NEM SZAMIT !!!
Szerintem inkább maradjunk annyiban, h vannak esetek, amikor a sebesség nem számít.
igazad van 'altalaban' de itt...
idezem magam:
[quote:3a1049ca90="feledhetetlen"] melyik a leggyorsabb nyelv?
ami amugy eleg butuska kerdes is,
megis egyre szuletnek valaszok ra
szoval erre gondoltam, persze szamit a sebesseg
de a sebesseg nem egy nyelv tulajdonsaga
vegyel egy 10*gyorsabb gepet, oszt gyorsabb ami lassu...
vagy hasznalj dedikalt IO processort..
megkerdeznem, hogy egy IBM370 hany megahertzen 'hasit'?
tenyleg, erre en is kivancsi lennek, marmint h miert lesz "jobb" egy nyelv a masiknal? en pl. C-t hasznalok csak, ha programozok, de ez azert van, mert ezt tanitottak (persze nem a tanarok, hanem a temavezetoim). Miert kellene megfontolnom, h megprobalkozom massal is?
Teljesen elegedett vagyok a C-vel (oke, neha bosszantoan maceras, de altalaban csak sajat amatorsegemnek tudom be, lasd pl. tomb muveleteknel folyton ket for ciklust kiirni), de kivancsi is vagyok, mit rejt a tobbi nyelv.
[quote:7d495f9375="syntern"]
Kihagytam a felhasználói felületet. A tesztünk kifejezetten elkerült mindent ami a felhasználói felülettel jár, mivel az csak és kizárólag szubjektív mérés lehet. A szépség fogalmának mérése leginkább a megszokottságéval korrellál, a sebességet mérni pedig még nem sikerült kitalálnom, hogyan lenne célszerű és pontos.
Ha publikus a dolog akkor én is nagyon szívesen megnézném azt a programkódot... van rá mód?
Volt szerencsém sokat szívni java-val.
Legyen két osztály: A és B
A tartalmaz referenciát B-re, B tartalmaz referenciát A-ra.
Egyik osztály sem lesz felszabadítva amikor elengeded, hanem elleakelődik. Ezeket a referenciákat kellett null-al felülírni, hogy ne zabálja szét a memóriát.
Persze én csak a 4 évvel ezelőtti java-t mondom, a mostani nem tudom, hogy hogyan viselkedik.
A tapasztalatom az, hogy java-ban real-time alkalmazásokat nem érdemes írni. A gyors és időigényes műveleteket sosem java-ban írtuk meg, hanem natív C-ben.
A java-t és a C++-t a JNI-vel lehetett összekapcsolni. A JNI-ről annyit érdemes mondani, hogy az assembly logikusabb és áttekinthetőbb...
Szerintem a java webes alkalmazásokra való, meg egyszerűbb játékokra, de komolyabbakra semmiképpen.
- Sosem fogsz 2D / 3D motort írni java alatt
- Nem fogsz videót, DVD-t nézni java alatt
- Nem fogsz tudni megírni mondjuk egy TCP/IP stacket java-ban a misztikus késleltetések miatt (pl. Garbage Collection).
- A kriptográfiai erőforrás zabáló algoritmusokról nem is beszélve
A java csak akkor használható ilyen dolgokra, ha az időigényes szálak natívban futnak.
Azaz lehet JNI-ben gányolni, a JNI pedig nem hordozható binárisan és nem sokkal kényelmesebb, mint egy hexeditor.
[quote:c565eac7ff="feledhetetlen"][quote:c565eac7ff="popacsek"]...
Elméletileg egy java program nem futhat gyorsabban mint egy C++-os, mivel azt a byte-kódot futási időben kell lefordítani.
...
toltesi idoben
vagy eppen barmikor, peldaul install time
nem lehet ezen tullepni ? a bytecode szukseges dolog
igy lehet kornyezet optimalizalni
a csuma-koppra-szevasz optimalizalt c++ kod a foditasi platformra van optimalizalva (vagy cross compilalva egy kornyezetre)
mi van ha a cel kornyezeten, mondjuk a memoria muveletek xxxlassuak de cpu gyors, vagy forditva
nekem ugytunik, hogy itt mindenki compiler optimizer szakerto, szoval talan csak be lehet azt latni, hogy a nativ kod generalasi lepesnek a cel kornyezet toltesi idejeben van eloszor jogsultsaga
amugy, a sebesseg NEM SZAMIT !!!
rule #1: do not optimize
rule #2: (experts only) do not optimize yet
Te is a körülményekre és környezetre hivatkozol. Nem tudtok ettől elvonatkoztatni?
Én továbbra is állítom amit az előbb:
Adott egy JIT fordító, és egy C++ compiler. TFH egy adott forráskódból ugyanazt a bináris kódot generálják. Csakhogy míg a JIT fordító runtime fordítja, így összességében lassabban fog lefutni a JIT-es esetben a kód. Pont.
Még egy-két eredmény:
g++ -O2 -march=k8 -o qs QuickSort.cpp
./qs
5371
5173
5173
5173
java -version
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_05-b05, mixed mode)
javac QuickSort.java
java -server -Xmx250m QuickSort
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
java -server -Xmx350m QuickSort
8707
8556
8552
8553
8553
Mellesleg a java-s QuickSort futása közben kevesebb free memória volt vmiért ...
Azért fordítottam -march=k8-al, mert nálam ezzel fordult az egész rendszer. Kipróbáltam anélkül is:
g++ -O2 -o qs QuickSort.cpp
./qs
5372
5172
5172
5172
Másik gépen:
g++ -O2 -o qs -march=athlon-xp QuickSort.cpp
./qs
9325
9199
9158
java -server -Xmx250m QuickSort
15893
15876
60-70% -os különbség ...
neha azert csak leirom ujra miert csak a Java:
nyelvszabvany!!!!
mutasson mar nekem valaki egy olyan c++ nyelv szabvanyt
ami van olyan atfogo mint a JLS
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
amiben le van irva a futasi kornyezet, a nativ ki/bejarat,
es nincsen kod tobbertelmuseg
szoval az is eleg, ha csak a java.lang.* szintig, nem a tobbi csingilingi
csak ennyi, egy ilyen szabvanyt c++ ra
emlexem a borland-nal kulon osztaly volt a c++ compiler csoporton belul
akik dirket a c++ tobbertelmusegeket kerestek
nem, nem azert hogy megoldjak, azert hogy maskent oldjak meg mint a msc/watcom c++ ban
ha valamire akkor az ilyen szemet kis vendorlocking-ra a c++ kivalo
es ha a sun (helyesen) nem kemenyit be a microsoft language "extension"-jei ellen akkor ezt az 'aldast' tovabb elvezhetnenk
a c++ kivalo tovabba titkosirasra, a torekeny baseclass-ok miatt 6 oras forditasokra egy sor valtoztatas miatt...
[quote:4577167f6c="_Joel"]Lehet. De akkor az autómban az ABS, a kipörgésgátló és a menetstabilizátor is ugyanilyen felesleges hibajavítás. Ami szükségtelen megfelelő odafigyelés/vezetés esetén. Mégis életet/anyagiakat menthet.
Rossz példa...
Ezek az eszközök nem az autógyártás / tervezés során elkövetett hibákat javítják hanem a felhasználás során elkövetetteket.
Ha fordítási időben történő hibajavítás ellen semmi kifogásom nincs, mert akkor a programozó legalább megtanulja hogy nem jól csinált valamit. De így abban a tévhitben él hogy jó kódot írt ... csak éppen kétnaponta újra kell indítani az alkalmazást / szervert és erősebb vasat kell venni alá hogy elbírja...
Így szépen kinevelődnek a hanyag / nem megfelelő tudással rendelkező programozók és nő a vacak programok száma.
[quote:c3e595890b="bocs"][quote:c3e595890b="syntern"]valószínűleg ki fog jönni, hogy nem feltétlen a C++ a legkönnyebben kezelhető eszköz, a hosszú távú kódkarbantartásra és a platformok közötti hordozásra (főleg mikor már érint grafikus részeket is) biztosan nem.
hmmm QT? "kissé" gyorsabban válaszol desktopon, mint egy javas felület.
persze megy unixokon, win-en, PDA-n stb.
Hát nem tudom, valószínűleg igazad lehet, bár fejlesztettem már KDE alá, és az akkor nem győzött meg, mert külön vacakolni kellett a Windowsos portolással. Mindenesetre egy gráfkezelő és szerkesztő környezet (jung.sf.net) integrálása nem volt nehéz Java alatt, megy Linuxon, Windowson, különösebb strapa és újrafordítás nélkül. Nekem ez jobban bejön, mint a vacakolás :)
nyenyec blogján (nyenyec.freeblog.hu) olvastam egy jót erről és maximálisan egyet tudok vele érteni:
Amúgy van neki egy a témába vágó megjegyzése is:
A javaban összeadás definiált még string-ekre
eszméletlenül hiányzik az összeadás azonos tömbökre a[] + b[], helyette ArrayCopy-val hülyéskedünk
Értelmes az összeadás: halmazokra és vektorokra is
Lehetne nyilván a Vektort és a Stringet is Numberből származtatni, de ez szerintem nagyon kemény megkötés lenne.
[quote:1f96a2e57d="snq-"]de ha egy kicsit elvonatkoztatunk ettol a szavazastol, melyek lennenek az (object) pascal -mint nyelv, mert azokrol beszelunk- azon featurejei, amikkel lebeszelnel arrol a fixa ideamrol, hogy a c# -az osszes featurejevel- superior a mezonyben (ismet: mint nyelv, mert azokrol beszelnuk)?
Mivel igyekszem tavoltartani magam mindentol amihez az M$-nek koze van mint fejleszto, ezert a C#-t sem ismerem annyira, hogy a fenti kerdesre erdemben valaszoljak. Igen, fajgyulolo vagyok, es eloiteleteim vannak. Beismerem. Ez van.
Azért ez http://www.bytonic.de/html/benchmarks.html nem olyan rossz...
[quote:bd63633b0c="handler"]
PTK/A kártérítés általános szabályai:
342. § (1) Semmis valamely szerződésnek az a kikötése, amely a szándékos vagy súlyos gondatlanságból eredő károkozásért, az életben, a testi épségben, az egészségben okozott károsodásért, továbbá bűncselekmény következményeiért való felelősséget előre korlátozza vagy kizárja.
[quote:bd63633b0c="lzrd"]
Ezexerint nincs igazad, hála a magasságosnak, de azért köszi! :)
Szal nem verhetik el a port a programozón, ha nem súlyosan és nem szándékosan gondatlan...
Meglehetosen furcsa kovetkeztetest tudsz levonni. Te allitottal valamit (egy tablaval ki lehet zarni minden felelosseget). En *egy* peldaval cafoltam. Ebbol egyaltalan nem kovetkezik, hogy az allitasnak csak egy cafolata lehetseges.
[quote:163c82ab8f="Frimen"]
...
Szerintem ez a java & C sebesség kérdésében igen csak megmutatkozik.
Amugy érdekes.. azt vártam valaki reagálni fog itt a c-s példára, de nem..
Valószinű nem ez a legjobb forum ilyesmire..
Fri
nem az execution time az igazi elteres a C es a java kozott
hanem a runtime sebesseg optimalizalas lehetosegenek megorzese/elvesztese
A normalis C forditok is mind pseudo koddal dolgoznak, csak a forditas
soran az utolso lepesben 'bevasaljak' a platform specifikus targykodot.
A javaban az utolso compiler pass el van halasztva a toltesi (sot a futasi) idore.
A Java annyi elonnyel indul, hogy a Compiler (java terminologiaban a Compiler a just in time Compiler) megkapja az eselyt extensive optimalizaciora. Illetve a bytecode megorzi ezt az eselyt.
Ez lehetoseget ad akar az elhalasztott profiled runtime optimalizaciora is mint azt a HotSpot teszi.
Arra szeretnek csak ramutatni, hogy a leforditott java kodban megmarad a gyorsitas lehetosege, mig a C targykod 'doglott' ebbol a szempontbol.
Leggyorsabban az a kod fut, ami nincs ;-)
[quote:e61da76f74="_Joel"]
Hmm, amikor Számításelmélet szigorlaton valamelyik véges testen, vagy gyűrűn értelmezett műveletnél kérdez a tanár egy ilyet... akkor valószinűleg elgondolkozom.
De most komolyan, mondjuk ket Bankszamla peldany eseten pontosan mire is alkalmaznad a + operatort? Es a melletted ulo programozo?
Én nem azt mondtam hogy pl. a + operátort minden esetben lehet használni. Nyílván olyan esetekben ahol egyértelmű mert olyan a művelet amit a + jellel szokás jelölni.
pl.
matrix a,b,c;
a=b+c;
[quote:99b104bbfc="blau"]Miert kellene megfontolnom, h megprobalkozom massal is?
nem kell, de lehetnek olyan featureok, nyelvi elemek, amik segithetetnek abban, hogy a fejlesztesi ido nagy reszeben a megoldando problemara koncentralj, vagy karbantarthatobb kodot irj, valoban ujrafelhasznalhato osszetevokkel.
csodafegyver persze nincs, egy gyors-hack adatkoverzionak perllel vagy pythonnal, eszkozcsatolonak c-ben allnek neki. c# meg mehet minden masra:)
Itt egy összehasonlítás... a kuglival találtam...
Java vs. C++
http://verify.stanford.edu/uli/java_cpp.html
[quote:49ee333aab="snq-"][quote:49ee333aab="blau"]Miert kellene megfontolnom, h megprobalkozom massal is?
nem kell, de lehetnek olyan featureok, nyelvi elemek, amik segithetetnek abban, hogy a fejlesztesi ido nagy reszeben a megoldando problemara koncentralj, vagy karbantarthatobb kodot irj, valoban ujrafelhasznalhato osszetevokkel.
csodafegyver persze nincs, egy gyors-hack adatkoverzionak perllel vagy pythonnal, eszkozcsatolonak c-ben allnek neki. c# meg mehet minden masra:)
ertem. nem provokacio akart lenni, tenyleg kivancsi vagyok, hogy milyen megkozelitesek leteznek egy programozo szamara (nem vagyok, es valszeg nem is leszek az).
b
Hehe, alapvetően nem érti a Pascalt. Ott blokkok vannak, amik begin-el kezdődnek és end-el végződnek. Ez mindig így van. És ha meg akarja az ember jelölni az end-et, mert sok egymásba ágyazott blokk van, akkor egyszerűen megjegyzéssel utánateszi, hogy { if }
[quote:c2441c2ff1="Csab"]Mindig mosolygok a java-s mátrix implementációkon.
java
Matrix result = (((a.add( b )).multiple( c )).divide( 23. )).inv();
c++
Matrix result = ~(((a+b)*c)/23);
mi a baj a java valtozattal, el lehet olvasni?
amugy meg nem ertem, miert inv, es miert divide, miert nem div, es invert ?
nekem egyszer, egy F-15 Strike Eagle nevu programot kellett atirnom
a jatek egy azota kihalt Forth nevu nyelv egy idiomaja volt
azt kell mondanom hogy ott hosszu idore el ment a kedvem attol, hogy ilyen titkosiras kifejezeseket irjak at olvashatora
ha valaki meg emlexik a Forth-ra, vagy esetleg magara a Microprose-os Sid Meier fele sid nyelvre, kerem erositsen meg...
[quote:a9a4dbfc88="trey"]A 2005-ös év kedvenc programozási nyelve.
Idén tetszett a FLORA-2 (XSB, ~ Prolog alapokon). Egész kellemes a logikája, valamint az objektumkezelése.
Szavazatom azonban a Java-é lett. (Azonban érdekelne, hogy hányan használják napi szinten a Prologot, vagy valamely leszármazottját. Remélem jövőre nem felejtem el ajánlani.:))
[quote:2b01257234="maszili"]
Mikor állítottam én azt hogy profi vagyok java-bol???????
Pont az ellenkezőjét állítottam! Azért kérdeztem meg itt azokat az embereket akik JÓL ismerik a java-t hogy felvilágosítást kapjak!
Szerintem senki nem állította azt, hogy azt állítod profi vagy Javából. Itt azzal az egy aprósággal van gond, hogy nem érted meg azt, hogyha nem ismersz valamit kellőképpen, akkor elég nehéz róla érdemben nyilatkozni, minősíteni.
[quote:2b01257234="maszili"]
A kialakult helyzetre megpróbálok egy történettel válaszolni:
Egy vevő bemegy egy boltba és megkérdezi az eladót hogy az X termék tudja-e azt amit a másik boltban kapható Y. Az eladó megvizsgálja a kérdést és arra jut hogy az X tényleg nem tudja. Megpróbálja bebizonyítani a vevőnek, hogy de mégis... persze sikertelenül. Ekkor az eladó feldühödik és elzavarja a vevőt a francba azzal az indokkal hogy a vevő nem ismeri elég jól az X-et.
Költői kérdés: az eladó helyesen járt el?
Tudod egyáltalán, hogy miről irogatsz?
Ha már ennél a nem túl frappáns példánál tartunk: jelen társalgás arról szól, hogy attól, hogy X nem tud egy olyan dolgot, amit Y, attól még X lehet egy jó termék.
Kicsit még konkrétabban - bár ez a példa sem tökéletes: tfh, egy terepjáróban vannak terepfokozatok, egy forma1-es kocsiban nincsenek. A terepjáró jobb autó (ennyi információ alapján)?
[quote:2b01257234="maszili"]
[quote:2b01257234="lokoto"]
Például ha üres, alapértelmezett konstruktorral létrehozott listába pakolsz egymást után 500000 elemet, a háttér tömböt többször is meg kell növelni, majd az elemeket áttenni, ami nyilván nem az elérhető teljesítmény.
Engem nem érdekel hogy a lista objektum hogyan oldja meg a problémáit. Az legyen a lista osztályt megíró programozó feladata.
Na látod, itt a probléma. 500000 Integer esetén majdnem 100%-os a sebességnövekedést lehet elérni azzal, hogy tudod miként működik. Jelen esetben csak egy konstruktor hívásnyi különbség van (vagy egy metódus hívásnyi kicsit más környezetben, lényegen nem változtat).
int cnt = 500000;
java.util.ArrayList l = new java.util.ArrayList();
for (int i = 0; i < cnt; i++)
l.add(new Integer(i));
int cnt = 500000;
java.util.ArrayList l = new java.util.ArrayList(cnt);
for (int i = 0; i < cnt; i++)
l.add(new Integer(i));
Jól sejtem, hogy ez nem Java specifikus?
[quote:2b01257234="maszili"]
Az operator overloading egy olyan eszköz ami egyszerűsíti / megkönnyíti a program írást. A java nem tudja mert az alap koncepciója (filozófiája) az hogy csak a gyárilag megírt operátorokat lehet használni, szemben a c++ filozófiájával ami támogatja a saját operátorokat. Ezek után én azt mondom hogy a java filozófiája rosszabb mint a c++ filozófiája.... ez így érthető volt? Ennél egyszerűbben már nem tudom leírni.
Teljesen érthető, hogy mit akarsz mondani, konkrétan azt, hogy hiányolod a Javából az operator overloadingot, és Neked emiatt jobban tetszik a C++. (de ettől még nem rosszabb a Java filozófiája - a két értékelésnek enyhén szólva más a dimenziója)
Fordítsunk a helyzeten (kérem a szöveget nem kiragadni a környezetéből):
- a C++ filozófiája rosszabb, mint a Javáé, mert nincs benne reflection
- a C++ filozófiája rosszabb, mert nincs benne GC
- a C++ filozófiája rosszabb, mert nincsenek benne csomagok
[quote:2b01257234="maszili"]
Mindenképen... én személyeskedés nélkül kérdezek / érvelek.
Ha én értelek félre, elnézést, de szerintem Te egy nem Tőlem származó hozzászólást tulajdonítasz nekem.
(amúgy amire gondolsz, az egy egyszerű megállapítás volt vki részéről, amin szerintem nem felháborodni és megsértődni kellene, hanem elgondokodni rajta)
[quote:2b01257234="maszili"]
Rendben... akkor próbálj úgy programozni hogy a + jel helyett használd ezt... szigorúan java stílusban :)
EzEgyOlyanOperátorAmiOsszeadjaAztAKétOperandustAmiAkétOldalánSzerepelDeAttólFüggőenHogyMilyenAKétOperandusTípusa
Ez durva sarkítás - csak komoly ember módjára...
[quote:2b01257234="maszili"]
Belefáradtam... kész... ennyi... feladom!
Mit is szoktál ilyenkor írni...? Kifogytak az érvek...?
[quote:da8c33cf52="maszili"]
Így szépen kinevelődnek a hanyag / nem megfelelő tudással rendelkező programozók és nő a vacak programok száma.
Egy program vacaksága nincs összefüggésben a felhasznált progamnyelvvel.
Ajánlom figyelmebe ezeket a linkeket:
http://blogs.sun.com/roller/page/alanc?entry=solaris_desktop_summit_performance_day
http://blogs.sun.com/roller/page/jmr#solaris_desktop_summit_performance_day1
Most megy egy desktop performance summit Solaris és Gnome fejlesztők részvételével (Sun-on belül). Hihetetlen milyen gány kódokat találnak:
" * bmc noticed a lot of time being spent in the close() system call, which seemed strange. Tracking this down to the stack trace involved, yippi saw it was socket closes in the gdmlogin configuration calls. When gdmlogin needs to get a configuration value from the parent gdm daemon it opens a socket, checks the version, asks for the value it needs, then tears down the socket. Over and over again it does this, instead of simply caching the socket and reusing it for future calls, so yippi is looking into seeing if we can convert it to do so.
* bmc also noticed a lot of stat() system calls, and found two big causes:
o gdm has a list of possible supported locales and stats the locale directories for each ones to see which are installed. We thought of two ways to reduce the cost of these. First, instead of having gdmlogin do this every time, having the parent do it and pass the list to the children could reduce the time on systems with multiple login screens, such as multiseat systems, including Sun Ray. That shouldn't make much difference on single user system though, but the second idea, to change the scan to instead read the parent directory containing all the locales and use the list of it's subdirs instead of a huge list of all possible subdirs could greatly cut down the number of system calls on systems with only a few locales installed.
o gdm was also scanning lots of directories to find the icons for the gtk theme, including stat'ing the same directory over and over again. Another group is looking into gtk performance and will be looking into this more."
[quote:d93fe408b7="syntern"]
Bizonyára Te is belátod, hogy egy ilyen teljesítménymérő tesznek nem az a célja, hogy az adatbázis sebességét mérje, mivel az pl. mind C++-ból, mint Javaból nagy valószínűséggel ugyanannyi lesz. Hasonlóképpen vonatkozik ez diskműveletekre, hálózatra, mert itt is az overhead nem a nyelv és a managelt környezet, hanem dominánsan a TCP stack, a vas, a kábel.
Szerintem ebben nincs igazad.
Itt nem TCP-ről van szó, és nem is az alkalmazás szintű protokollrol, hanem arról,
hogy egy "driver", legyen az java estében jdbc, rmi milyen teljesitmenyre képes,
mennyit "tud".
[quote:d93fe408b7="syntern"]
Szóval ha tudsz mondani olyan tesztet, ami tisztán a Java managelt környezetet hasonlítja össze a C++ natív futásával, és nem ez a "tipikusan buta" teszt, akkor szeretettel várom és kimérem. De amíg csak azt tudod mondani egy neked nem tetsző eredményre, hogy ez butaság, addig ne haragudj, de nem tudom komolyan venni amit írsz.
Kihagytam a felhasználói felületet. A tesztünk kifejezetten elkerült mindent ami a felhasználói felülettel jár, mivel az csak és kizárólag szubjektív mérés lehet. A szépség fogalmának mérése leginkább a megszokottságéval korrellál, a sebességet mérni pedig még nem sikerült kitalálnom, hogyan lenne célszerű és pontos.
A komolyan nem vevés kölcsönös.:)
Nem foglalkoztam soha azzal, hogy teljesitmény teszteket kutassak fel.:)
Amugy.. lehet, hogy szubjektiv egy felhasználói felület, de mivel a programok több
mint 50 százaléka guis felülettel dolgozik addig nem lehet félresöpörni.. mondom továbbra is (ezért) idióta teljesitménytesztekkel. A másik.. hogy egy szervert bővithetsz, egy munkállomás bővithetsz, egy felhasználót meg, bármely szubjektiv is a véleménye nem lehet kihagyni a valós tesztekből, mert az, hogy mennyire megelégeded a
szoftverrel, döntő tényező.
[quote:d93fe408b7="syntern"]
Szóval ha van elképzelés, hogy hogyan máshogy lehetne összehasonlítani a C++-t a Javaval, akkor szeretettel várom, addig pedig csak azt tudom mondani, hogy a C++ semmilyen előnyt nem nyújt az alkalmazások nagy részében a Javahoz képest, amivel szemben a Java azért tud előnyt biztosítani.
Nincs érteleme.. ezt bizonyitja több tucatnyi program.
Egy C-ben irt GUI-s program sokszor nagyságrendekkel gyorsabb mint egy java-ban
irt program.
Mielőtt azt mondod C-s bérenc vagyok, magam is Javazom, és bevallom magamban
sül a pofám amkor látom, hogy egy c-s program hogy dobálja fel az ablakokat..
szemben a java csiga lassuságával.
Fri
[quote:8f8990ebde="syntern"]különösebb strapa és újrafordítás nélkül. Nekem ez jobban bejön, mint a vacakolás :)
jaja, virágozzon száz virág.
mások a preferenciáink. nekem fizikai fájdalmat okoz, ha a processzoridő felét, kétharmadát kidobom az ablakon egy kis "vacakolás" kedvéért, és cserébe általában kapok egy meglehetősen lassú érzetet keltő desktop alkalmazást.
/de nem akarok itt már túl sokat szájat tépni, csak nem szeretném, hogy valakiben az a kép alakuljon ki, hogy a Java mindennél jobban alkalmas bármilyen feladatra/
Azt lattatok, hogy a sourceforge-on a Java vezeti a listat?
http://sourceforge.net/softwaremap/trove_list.php?form_cat=160
(Ha azt akarod valaszolni erre, hogy a C es a C++ osszeadva tobb, akkor ne tedd, mert csunya vita lenne belole).
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
Mivel a java erősen típusos nyelv, illik tudni a változók típusát. Ha tudod a változók típusát, meg tudni mondani, hogy mi történik.
Ha ez így működik akkor szerintem a nyelv a programozóra hárít egy feladatot... mert a programozónak kell fejben tartania az osszes általa használt objektum típusát és megfontolni hogy pl. egy értékadás esetén hogyan is működik az értekadás...
Nem értelek. Javában ponthogy baromira egyszerű:
primitív típus esetén (boolean, int, long, double, ...)
a = b; // a felveszi b értékét
egyéb esetben:
a = b; // a ugyanarra az objektumra lesz referencia, mint b (máshogy fogalmazva: mindkét változón uazt az objektumot lehessen elérni)
Nem elég egyszerű és egyértelmű?
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
Egyrészt a "mindig" mindig rövid i-vel van akár "MINDIG", akár "mindig", akár valamilyen egyéb kis- / nagybetű kombináció.
Mivan?... már nincs mibe belekötni????... :-D
Ok. Ezek után rövid i-vel írom.
Nem belekötök a dolgokba, csak leírom a véleményet, a "mindíg" pedig kifejezetten zavar. Köszi.
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
... Neked kell megírnod az összehasonlítást ahhoz, hogy el tud dönteni igaz vagy hamis a vizsgálat.
Pontosan! És ez így van jól. Én találtam ki azt a típust csak én lehetek az aki meg tudja mondani hogy miként kell összehasonlítani. De ha már megmondtam / megírtam akkor az osztályomat felhasználóknak már nem kell törődni vele a felhasználás során. Egyszerűen használhatja az összehasonlító operátort mint ahogy korábban, más adatípusok esetében.
Ez mind rendben van, uezt javában is meg tudod írni, de:
primitívek esetén:
a == b: true, ha ugyanaz az értékük, false egyébként
egyéb esetben:
a == b: true, ha uarra az objektumra mutatnak
Ez a definíció (tudtommal, ha nem is pontosan így fogalmazva). A Java így gondolkodik, legalábbis jelenleg. Lehet, hogy Java8-ban felüldefiniálhatod pl a +-t, de jelenleg nem lehet, elképzelhető, hogy ez kényelmetlen némely esetben, de egy ilyen miatt rosszabbnak minősíteni a Javát, az húzós.
Örülnék, ha csak ennyi lenne összeségében a probléma - bármilyen nyelvvel, környezettel.
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
Nézd, én semmiről nem akarlak meggyőzni, csak fogadd el azt, hogy amit egy Sun kaliberű cég létrehozott, majd amit egy Microsoft kaliberű cég lemásolt (vagy nem, de nem is ez a lényeg, hanem az, hogy hasonlót alkotott), nagyon sokan elfogadnak, annak a hátterében lehet valami.
Engem nem érdekel az hogy egy nagy cég hozta létre... attól még nem biztos hogy jobb valami ha egy nagy cég készítette.
Porkoláb Zoltán (elte) mondta annakidején az előadáson hogy az ada-t egy bizottság készítette a c-t meg egy zseni. :)
Mindennél van jobb, nem is vitatom, de jelenleg úgy tűnik, hogy elég sok igényt kielégít, elég nagy piaca van (ez a tény nem igazolja, hogy a Java jó, csak azt mutatja, hogy valamire azért mégiscsak lehet használni, költeni kevésbé szeretnek a cégek, mint osztalékot fizetni)
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
...de azért rosszabbnak minősíteni a C++-nál és leszólni, mert az = nem lehet klónozás és nincs benne pointer, meglehetősen korlátolt agyjárásra vall,...
Kérem mellőzni a személyeskedést! :evil:
Több oldalon keresztül próbálom megvilágítani példákkal hogy szerintrem miért nem jo a java...
nyugodtan, vannak hátrányai, de meglátásom szerint elég gyenge érv az, hogy azért nem jó a java, mert:
a.equals(b) helyett nem írhatsz a == b kifejezést, vagy a = b.clone() helyett nem írhatsz a = b kifejezést.
[quote:abe2a8e178="maszili"][quote:abe2a8e178="lokoto"]
... ugyanis attól, hogy a szintaktikájuk hasonló (sőt, bizonyos részletekben azonos), a szemantikájuk *más*.
Az eltérő szemantika pedig a háttér rendszer/elképzelés következménye/velejárója/....
Itt alapvető filozófiai eltérésekről van szó, nem szintaktikai / szemantikai eltérésekről.
A szintaktikának kicsit kevesebb köze van a filozófiához, de alapvetően egyetértünk.
És meg is érkeztünk: egy filozófia nem lehet rossz vagy jó, egy filozófia van, esetleg a benne megfogalmazott állításokat valamilyen értékrend szerint lehet értékelni, de abszolút minősíteni nem, mert abszolút igazság nincs (legalábbis így rémlik...).
Ilyen "apró" szintaktikai jellemzők alapján minősíteni lehet egy nyelvet, de egyéb jellemzőkkel nem biztos, hogy arányban áll a jelentősége.
(szerintem ez nem olyan téma, hogy egy autó akkor jó, ha piros, egyébként legyen az bármilyen is, de tuti rossz, vagy rosszabb, mint egy piros autó)
[quote:479805c9af="popacsek"]Adott egy JIT fordító, és egy C++ compiler. TFH egy adott forráskódból ugyanazt a bináris kódot generálják. Csakhogy míg a JIT fordító runtime fordítja, így összességében lassabban fog lefutni a JIT-es esetben a kód. Pont.
Kivéve ha nem JIT fordító, hanem runtime profiler. A Java HotSpot egy runtime profiler, hosszú távú optimalizációra berendezkedve.
És végre az első alternatív mérések :)
[quote:479805c9af="popacsek"]g++ -O2 -march=k8 -o qs QuickSort.cpp
./qs
5371
5173
5173
5173
java -server -Xmx350m QuickSort
8707
8556
8552
8553
8553
[...]
60-70% -os különbség ...
Valahogy ebből nekem az jön le, hogy a C++ kód sebessége ugyanúgy runtime környezet függő, mint ahogy a Java függ a JVM képességeitől. (Próbáld ki pl. alap Ubuntu telepítéssel.) Ennek két következménye van:
1. Van még mit fejlődnie a JVM-nek, és gyanítom, hogy fog fejlődni. (Érdemes lenne kimérni JRockit-tal, van erre is kapacitásod?)
2. Az emberek látják a te 60-70%-os tesztedet, de nem fogják tapasztalni, hanem azt tapasztalják amit én, azaz +-10%-ot. Gentoo (és egyéb fordítsd le az összes forrást) kivételével nincs olyan szoftver-disztrib, amelyik teljes egészében speciálisan processzor-optimalizált lenne, beleértve ebbe nem csak az oprendszereket, hanem az egyes dobozos szoftvereket is.
Azaz megintcsak arról van szó, hogy menj mindenben a hardver közelébe, és akkor gyors leszel. Igaz ez a Javara is. Vagy maradj meg általánosnak (C++ is) és akkor hasonló teljesítményt produkálsz (Java is). Ellenvélemény?
[quote:7a3561da7b="feledhetetlen"]
ha valaki meg emlexik a Forth-ra, vagy esetleg magara a Microprose-os Sid Meier fele sid nyelvre, kerem erositsen meg...
Én emlékszem a Forth-ra, jó kis veremalapú nyelv volt... :-)
(Igazán soha nem használtam, csak érdekes volt a felépítése.)
Egyébként volt egy nyelv, talán APL volt a neve, ahol egy csomó (nem betű és nem szám) ASCII karakter volt mindenféle operátor, pl. beépített mátrixműveletei voltak.
KisKresz
hello,
[quote:d96d03b256="Nickname"]Filozófiailag mitől kedvenc egy programnyelv ?
...
csak úgy kérdem, mert olyan kiváncsi vok.
pl: egy feladatot relatíve könnyen, és gyorsan meg tudsz oldani; bonyolult feladatot meg tudsz vele oldani; a kettőt tudod ötvözni :)
ezek alapján az assembly szerintem egyértelműen kiesik, bár semmi bajom vele, de lássuk be: elég lassan lehet benne fejleszteni (csak példa volt).
A C egy fokkal jobb, bár én kimondottan szeretek C-ben progamozni, imho a Pythonban történő fejlesztés lényegesen gyorsabb. :) Ezen kívül elég sok platformon megvan, a Linuxok többségében alapból benne van, egyszerre töb verzió fenn lehet, kicsi... mi kell még? :)
a.
sf-rol kigyujtve:
Java (16796 projects)
C++ (16767 projects)
C (15969 projects)
PHP (12228 projects) (egy jo hosszu spagettittesztat lehetne ebbol csinalni)
Perl (6221 projects)
Python (4552 projects)
C# (2905 projects)
Assembly (1613 projects)
Ruby (402 projects)
Lisp (323 projects)
[quote:e2bcfb2262="popacsek"]
Mellesleg a java-s QuickSort futása közben kevesebb free memória volt vmiért ...
hogy oszinten legyek utalom az osszes ilyen 'nem eleg gyors' uzekedest
ez hajszolta bele a sun-t abba a kapitalis baromsagba, hogy a JLS-t athagva intel fpu kodokat forditson az 1.1-ben
mert nem volt eleg 'gyors'
az lett az eredmenye, hogy ma a hotspot compiler az x86 platformon tud olyat produkalni, hogy egy futtatasi session-on belul egy double szorzas ugyanazokkal a szamokkal 2 fele eredmenyt produkal, persze kozel azonosat :)
felemelo lenne, ha java sebessegrol az irna ezutan aki meg tudja mondani hogyan tortenhet ez meg...
hello,
[quote:9dc0ee8393="waiter"]
Nem tudom, mi a "programozási nyelv" pontos definíciója, de IMHO egy programozási nyelvnek általános érvényű (és nem egy specializált) eszköznek kellene lennie, legyen szó bármilyen szoftverfejlesztési feladat megoldásáról.
- waiter -
"pontos definíciót" már adtak, szerintem ha egy nyelvben megvannak az elemi programok megvalósításához szükséges nyelvi elemek (értékadás, elágazás, ciklus, etc...), akkor azt nyugodtan hívhatjuk programnyelvnek.
Elméletileg assemblyben is írhatsz CGI-t, de a gyakorlatban PHP-ban kicsit hamarabb végzel vele, és könnyebben fogod bővíteni, meg ilyenek... :))
a.
[quote:396447198c="feledhetetlen"]az lett az eredmenye, hogy ma a hotspot compiler az x86 platformon tud olyat produkalni, hogy egy futtatasi session-on belul egy double szorzas ugyanazokkal a szamokkal 2 fele eredmenyt produkal, persze kozel azonosat :)
felemelo lenne, ha java sebessegrol az irna ezutan aki meg tudja mondani hogyan tortenhet ez meg...
Tudnád demonstrálni a kódot?
[quote:068db231ba="gee"][quote:068db231ba="Andrei"][quote:068db231ba="gee"]en UML modellezesre Umbrello-t hasznalok, es tetszik. Ja, ez QT, nem swing.
Ugy alapjaban veve tetszett volna, de nekem Windowsos valtozat is kellene.
Megjegyzem, QT van Windowsra. De nem tudom, maga az Umbrello megy-e.
Te megnezted, es nincs w32 valtozat?
Sajnos nincs. A weboldalon keresnek olyan embert, aki bevallalna a windows-os portot.
Marad a Posseidon, bar nem teljesen ingyenes (de nem is Javas).
Valóban meglepő. Lehet, hogy az újabb java-k már gyorsabbak.
Bár érdekes, hogyha az Eclipse-t nézed, azért érezni rajta, hogy java-s program. Szerintem lomha a grafikus felülete.
Annyira elmerültetek a részletekben, hogy az elképesztő!
Szerintem érdemesebb megnézni, hogy a két nyelven (C++ vs. Java) mennyi idő és erőfeszítés révén lehet ugyanazt elérni.
Engem eléggé meggyőzött korábban a Java sebessége itt a topic-on beírt példákban (én is kipróbáltam a qsort példát). Ezért aztán megnéztem, hogyan lehet Swing-gel dolgozni, ha az ember egy grafikus progit akar összehozni. Őszintén szólva teljesen elborzadtam a rengeteg származtatás meg osztály láttán. Még az eseménykezelés is egy katasztrófa.
Szerintem Javában legalább 3-szor akkora munka felületet programozni, mint egy jó C++-os toolkittel.
Itt egy példa, ahol a Java kód forrása közel 7-szer (hétszer!!!) akkora, mint a teljesen ugyanazt végző C++ kód:
http://upp.sourceforge.net/www$uppweb$vsswing$en-us.html
Ráadásul ez a C++ toolkit is platform-független.
Úgyhogy a Java az én szememben továbbra is maradt egy nagy nulla...
[quote:7c5b1e982a="lokoto"]
Nem értelek. Javában ponthogy baromira egyszerű:
primitív típus esetén (boolean, int, long, double, ...)
a = b; // a felveszi b értékét
egyéb esetben:
a = b; // a ugyanarra az objektumra lesz referencia, mint b (máshogy fogalmazva: mindkét változón uazt az objektumot lehessen elérni)
Nem elég egyszerű és egyértelmű?
Korábban írtam hogy nem... miért kell ugyannak az operátornak kétféleképen működni? Mégy szerencse hogy csak kétféle működése van... mi lenne ha több lenne? :)
[quote:7c5b1e982a="lokoto"]
Ez mind rendben van, uezt javában is meg tudod írni, de:
primitívek esetén:
a == b: true, ha ugyanaz az értékük, false egyébként
egyéb esetben:
a == b: true, ha uarra az objektumra mutatnak
Erre pont ugyanazt tudom válaszolni mint az előbb.
[quote:7c5b1e982a="lokoto"]
Mindennél van jobb, nem is vitatom, de jelenleg úgy tűnik, hogy elég sok igényt kielégít, elég nagy piaca van (ez a tény nem igazolja, hogy a Java jó, csak azt mutatja, hogy valamire azért mégiscsak lehet használni, költeni kevésbé szeretnek a cégek, mint osztalékot fizetni)
Én egy szóval sem állítottam hogy a java nem jó semmire. Ennek a topic-nak az a címe hogy Kedvenc programozási nyelvem. Na ennek keretén belül mondtam el a véleményemet: Szerintem a c++ jobb mint a java.
[quote:7c5b1e982a="lokoto"]
nyugodtan, vannak hátrányai, de meglátásom szerint elég gyenge érv az, hogy azért nem jó a java, mert:
a.equals(b) helyett nem írhatsz a == b kifejezést, vagy a = b.clone() helyett nem írhatsz a = b kifejezést.
Ha végigolvastad a korábbi hozzászólásokat és ezek után sem érted hogy mit próbálok magyarázni akkor kész... ennél jobban már nem tudom elmondani. Sajnos nem tudok olyan könyvet ajánlani amiben ezek a filozófiai kérdések le lennének írva. Be kell ülni valamelyik egyetemre egy jó tanár előadására. :)
[quote:7c5b1e982a="lokoto"]
És meg is érkeztünk: egy filozófia nem lehet rossz vagy jó, egy filozófia van, esetleg a benne megfogalmazott állításokat valamilyen értékrend szerint lehet értékelni, de abszolút minősíteni nem, mert abszolút igazság nincs (legalábbis így rémlik...).
Szerintem meg lehet jó vagy rossz egy filozófia, mert azt az adott környezetben az adott feladat megoldása során vizsgáljuk. Ha nem így lenne akkor elég lenne a strukturált programozás és nem lenne szükség az OO-ra.
[quote:c6358494b1="_Joel"][quote:c6358494b1="Andrei"]Felhivnam a figyelmedet, hogy ilyen kornyezetben a GC is borzaszto rosszul teljesit. A korkoros hivatkozasokkal pl. nemigen tud mit kezdeni, vagy erosen leromlik a teljesitmenye....
A mark and sweep vagy a stop and copy algoritmusra gondolsz? Azzal azert ugye tisztaban vagy, hogy hogyan is mukodik a gc a modern jvm-ekben? Hogy mikor es hogyan kerul egy objektum a young generation-bol a tulelo oregek koze, es ez gc-ileg pontosan mit is jelent: melyik generation-nel milyen algoritmusokat hasznal a jvm es ezt hogyan tudod te valtoztatni. Milyen statisztikai eloszlasa van az objektumoknak az eletidejuket tekintve, es erre vonatkozoan hogyan probalnak optimalizalni gc-ileg a virtualis gepek...
En csak annyit tudok, hogy hiaba erolkodunk egyszeruen nem eleg gyors a GC egy csomo feladatra. Mondom, ide kell cibalni azokat a real world powerappokat, amivel igazolni tudod, hogy ez az egesz szisztema megallja a helyet egy hasonlo hagyomanyos C++ alkalmazassal szemben. Mert ezeknek hiszek, de amig a csavokam egy feloldalas kodon probalja demonstralni a technologia felsobbrenduseget, addig nemigen tudom komolyan venni. Na hallod, feloldalas algoritmust minden nyelven elegansan es hatekonyan lehet lekodolni.
Az egyik program, amivel dolgunk van az az ArchiCAD (epiteszeti tervezoszoftver). Ez az alkalmazas 6 millio sor C++ kod. Jocskan megizzadna a JVM, mire beizzit egy ilyen meretu cuccot. Es ha meg menne is akkor uj ertelmet nyernenek a Sun Fire 20-25k gepek, mert ez egy mezei workstationon nagyon hurka lenne.
Azt meg egyszeruen keptelen vagyok elfogadni, hogy a GC-t, mint a programtervezest konnyito eszkozt kelljen elkonyvelni. A programozast konnyiti. Bizonyos feladatokat, amiket eddig a programozonak explicit kellett elvegezni, a runtime kornyezet megteszi helyetted, de ez nem jelenti azt, hogy nem kell a tervezes soran vegiggondolni az objektumok elettartamat. Szar kodot barmiben tudsz irni es talan Java-ban meg konnyebb is, mint mas nyelven.
Csak konnyebb idomitott programozok 1000 fos hordajat ertelmes munkara szoritani, mert szegenykem kevesebb dolgot tud elrontani Java-val... Javaban vigan kodolnak az indiai outsource rabszolgak, mikozben keptelenek lennenek C++-ban egy normalis konstruktort megirni, vagy egy kicsit is komplikaltabb kifejezes mukodeset precizen elkepzelni.
[quote:e29d52615c="Csab"]Volt szerencsém sokat szívni java-val. Legyen két osztály: A és B. A tartalmaz referenciát B-re, B tartalmaz referenciát A-ra.
Egyik osztály sem lesz felszabadítva amikor elengeded, hanem elleakelődik. Ezeket a referenciákat kellett null-al felülírni, hogy ne zabálja szét a memóriát.
Persze én csak a 4 évvel ezelőtti java-t mondom, a mostani nem tudom, hogy hogyan viselkedik.
Nem tudom, hogy 4 éve hogyan működött (bár emlékeim szerint mindig futó threadekből elérhető objektum-referenciákkal dolgozott, azaz sohasem fordult elő a fenti eset), de hogy ma nem így működik, az biztos.
[quote:e29d52615c="Csab"] A tapasztalatom az, hogy java-ban real-time alkalmazásokat nem érdemes írni. A gyors és időigényes műveleteket sosem java-ban írtuk meg, hanem natív C-ben.
Ez persze nem biztos, hogy azért történt, mert a Java lassú lenne :). Mindenesetre most már nyomulnak a Real Time JavaVM-el is, ha valakit ez a része érdekel.
[quote:e29d52615c="Csab"]A java-t és a C++-t a JNI-vel lehetett összekapcsolni. A JNI-ről annyit érdemes mondani, hogy az assembly logikusabb és áttekinthetőbb...
Ízlések és pofonok. Én emlékeim szerint először és utoljára papíron, egy vizsgán írtam JNI-s programot, de legalábbis ott kérdeztek valami JNI-t, és nem volt semmi gondom vele. Arról nem is beszélve, hogy CORBA-n is össze lehet kapcsolni a kettőt. Meg még 100+1 módon...
[quote:e29d52615c="Csab"]Szerintem a java webes alkalmazásokra való, meg egyszerűbb játékokra, de komolyabbakra semmiképpen.
- Sosem fogsz 2D / 3D motort írni java alatt
Semmivel sem rosszabb, mint egy C++ 3D engine, mivel mindkettő hardver szinten OpenGL-t fog kezelni. Lásd: Java3D API. Láttam már simán futó fps-t Javaban írva.
[quote:e29d52615c="Csab"]- Nem fogsz videót, DVD-t nézni java alatt
Ez még sohasem merült fel bennem :)
[quote:e29d52615c="Csab"]- Nem fogsz tudni megírni mondjuk egy TCP/IP stacket java-ban a misztikus késleltetések miatt (pl. Garbage Collection).
A TCP/IP stack véletlenül nem az operációs rendszer feladata?
A "misztikus késleltetések" ellen (ha már mindenképpen ez a szűk keresztmetszet) pedig vannak bevált módszerek: pl. oda lehet figyelni a program objektumaira, nem összevissza használni, lehet poolokat definiálni, stb. Tessék kihasználni a GC filozófiáját: nem fut addig, amíg nem kell futnia.
[quote:e29d52615c="Csab"]- A kriptográfiai erőforrás zabáló algoritmusokról nem is beszélve
Mire gondolsz? Mi az, ami lassabb lenne, mint ugyanaz C++-ban implementálva?
[quote:e29d52615c="Csab"]A java csak akkor használható ilyen dolgokra, ha az időigényes szálak natívban futnak. Azaz lehet JNI-ben gányolni, a JNI pedig nem hordozható binárisan és nem sokkal kényelmesebb, mint egy hexeditor.
A korábban már idézett mérésen kb. azt hivatott egy egyszerű példával bizonyítani, hogy ez így nem igaz. Persze állíthatunk bármit, de én most tettem számokat is mögé, és rövidesen egy kisebb cikkben is bemutatjuk a teljes mérési eredményeket.
[quote:d644abd0f0="zsolt"]Annyira elmerültetek a részletekben, hogy az elképesztő!
Szerintem érdemesebb megnézni, hogy a két nyelven (C++ vs. Java) mennyi idő és erőfeszítés révén lehet ugyanazt elérni.
Engem eléggé meggyőzött korábban a Java sebessége itt a topic-on beírt példákban (én is kipróbáltam a qsort példát). Ezért aztán megnéztem, hogyan lehet Swing-gel dolgozni, ha az ember egy grafikus progit akar összehozni. Őszintén szólva teljesen elborzadtam a rengeteg származtatás meg osztály láttán. Még az eseménykezelés is egy katasztrófa.
Szerintem Javában legalább 3-szor akkora munka felületet programozni, mint egy jó C++-os toolkittel.
Itt egy példa, ahol a Java kód forrása közel 7-szer (hétszer!!!) akkora, mint a teljesen ugyanazt végző C++ kód:
http://upp.sourceforge.net/www$uppweb$vsswing$en-us.html
Ráadásul ez a C++ toolkit is platform-független.
Úgyhogy a Java az én szememben továbbra is maradt egy nagy nulla...
Az eszkoz nem megfelelo ismerete nem elegseges indok a leszolasra. Peldual probald mar ki a Netbeans 5.0 (beta2)-ben levo Matisse felulet-epitot. Csak probald ki, es hasonlitsd ezutan ossze egyeb eszkozokkel. En vegigprobaltam a legtobb Visual *-ot, egy idoben Delphiztem is, lattam mar glide-ot, es ezek mellett azt mondom, hogy a Netbeans 5 felulet-epitese eleg power eszkoz.
Hogy kinek mennyire nem jon be a Swing filozofiaja, az megint mas kerdes. Egyszeruen masfajta logikat kovet, mas problemat cimez meg a megoldasaival, mint pl. a Visual * eszkozok. Eltart egy darabig, mig valaki ezt megismeri, viszont eddig csak olyan embert ismerek, akik a Swing mely megismerese es alkalmazasa utan egyszeruen benanak nezik a tobbi ablakozo rendszert, hogy az meg arra sem kepes. De ezt ugysem hiszik el a jelen levok, talan ha egyszer kiprobaljak...
[quote:272934b1be="handler"]
Meglehetosen furcsa kovetkeztetest tudsz levonni. Te allitottal valamit (egy tablaval ki lehet zarni minden felelosseget). En *egy* peldaval cafoltam. Ebbol egyaltalan nem kovetkezik, hogy az allitasnak csak egy cafolata lehetseges.
Nem is olyan urcsa az! A szándékos gondatlanságból eredő károk felelősségét nem zárhatod ki SZERZŐDÉSBEN. Ez könnyen emészthető. Nyilván, aki ártó kódot készít előre megfontotlt szándékkal, az ne mentesülhessen a számonkérés alól akkor se, ha a felhasználó elfogadja is a szerződést a neki előnytelen feltételekkel.
A másik kitétel, a SÚLYOS gondatlanságról szól. Érted? Súlyos gondatlanság. Ha az általában elvárható gondossággal építed fel a programodat ártó szándék nélkül, akkor szerződésben is kizárhatod a felelősségedet. Sajnos ez van. Szal igen is beleteheted a szerződésbe, hogy nem vagy felelős a program használatából eredő károkért. Hiszen úgy jártál el -a program elkészítésekor-, ahogyan az általában elvárható. Ez bizony cáfolat arra, hogy bele ne írhasd a szerződésbe a felelősséged kizárását. Szerintem. Ha netán ez se győzne meg és úgy éreznéd, hogy neked van igazad, akkor inkább elismerem, hogy én tévedtem.
[quote:7dcb0603bb="Andrei"]
Azt meg egyszeruen keptelen vagyok elfogadni, hogy a GC-t, mint a programtervezest konnyito eszkozt kelljen elkonyvelni.
Hopsz, ilyet nem akartam mondani. En csak azt mondtam, hogy Javaban a memory leak jellegu hibak altalaban tervezesi hibara eredeztethetoek vissza, mig C/C++-ban inkabb programozoi hibakra.
Ami az indiai rabszolgakat illeti, abban egyetertunk. A szoghez kalapacs, csavarhoz csavarkulcs elv alapjan gondolom abban is, hogy minden nyelvnek es kornyezetnek megvan a maga helye.
Amugy netbeans nem tudom hanymillio sor, de eleg szepen megy 512M memoriaval is. Modularis, dinamikus alkalmazasok irasara nem rossz a Java, akar meg desktop oldalon sem, bar az teny, hogy foleg szerveroldalon eli meg mindig a reneszanszat (csak eleg megnezni a web frameworkok szamat, es az egyre ujabb buzzwordoket (2-3 eve ugye az AOP volt a nagy szam, mostanaban a dependency injection es tarsai... kivancsi vagyok mi jon jovore:)
[quote:6641df635d="syntern"][quote:6641df635d="feledhetetlen"]az lett az eredmenye, hogy ma a hotspot compiler az x86 platformon tud olyat produkalni, hogy egy futtatasi session-on belul egy double szorzas ugyanazokkal a szamokkal 2 fele eredmenyt produkal, persze kozel azonosat :)
felemelo lenne, ha java sebessegrol az irna ezutan aki meg tudja mondani hogyan tortenhet ez meg...
Tudnád demonstrálni a kódot?
nekem egy zart fizikai szimulacio erdemenyekent jelent meg
az elosztott szamitasimodelben, gyakran kaptam eltero eredmenyeket ugyanarra a szimulaciora
szinte hihetetlen volt...
aztan kiderult, hogy a 'rossz' eredmenyek mindig x86, java > 1.3 rendszerekbol jonnek
aztan lokalisan is tudtam reprodukalni, ha x86-on futtot a kod
sparc, motorola, powerpc rendben volt...
nem preparaltam ki a hibat a szimulaci core meg
lines:103804
files:923
szoval kicsit tullepi a post meret korlatait
ha senkinek nincs otlete (es nem talalja a guglival se) akkor holnap megirom
[quote:5162fcd164="maszili"][quote:5162fcd164="lokoto"]
Nem értelek. Javában ponthogy baromira egyszerű:
primitív típus esetén (boolean, int, long, double, ...)
a = b; // a felveszi b értékét
egyéb esetben:
a = b; // a ugyanarra az objektumra lesz referencia, mint b (máshogy fogalmazva: mindkét változón uazt az objektumot lehessen elérni)
Nem elég egyszerű és egyértelmű?
Korábban írtam hogy nem... miért kell ugyannak az operátornak kétféleképen működni? Mégy szerencse hogy csak kétféle működése van... mi lenne ha több lenne? :)
Egy kicsit mar tulragjatok ezt a csontot. Egyreszt azert, mert a C++ operator mogott barmi lehet, masreszt mert az operator overloading tenyleg csak macro abban az ertelemben, hogy a vegso binarisban szepen atfordul a megfelelo metodushivasra. Innentol kezdve megint lehet vitatkozni a nyelv szintaktikajan, ami felesleges, mert egyreszt adottsag es nem most talaljuk ki, masreszt osszehasonlitjatok az almat a kortevel, es nem veszitek eszre, hogy mas a celjuk. A celokat mar ossze lehet hasonlitani, de ez ugyben erdemes eloszedni a ket nyelv specifikaciojat (ha jol tudom, akkor a C++-nak is van olyan, csak eppen penzert adjak...)
[quote:500809fc76="lokoto"]Mit is szoktál ilyenkor írni...? Kifogytak az érvek...?
A bölcsebbje már feladta mindkét oldalon... :P
Amugy meg egy erdekes cikk a "Killer Game Programming in Java" c. konyv ki nem adott C melleklete:
http://fivedots.coe.psu.ac.th/~ad/jg/appC/index.html
"'ll start by considering memory leaks: what they are, how to find them in code, and how to get rid of them.
I'll supply background information on the generational approach to garbage collection used in the JVM, information I'll need in order to decide how to tweak the collectors.
I'll describe several techniques for reducing collector pause time, by experimenting with two examples: JumpingJack (the side-scroller from chapter 12) and FPShooter3D (the first-person shooter from chapter 24). The basic approach is to supply options to the JVM; no changes are needed to the application code.
I'll graphically display the copious amounts of performance information generated by the JVM. Garbage collections statistics will be visualized with HPjtune, and profiling details rendered with HPjmeter. Both are freeware tools that work with a wide range of JVMs.
I'll finish by describing techniques for gathering heap-related statistics by adding code to Java applications."
Remelem el is olvassatok, de szoljatok ha hiaba irogatom a linkeket:)
[quote:579816c7fd="_Joel"]
Egy program vacaksága nincs összefüggésben a felhasznált progamnyelvvel.
Közvetlen összefüggésben nincs mert a programozó a meghatározó tényező... DE közvetetten van.
A programnyelv egy eszköz amivel a programozó a programot készíti. Ha az adott programnyelv ad megfelelő eszközöket (korábbi hozzászólásomban felsoroltam párat) hogy jó programot készítsen a programozó, sőt rákényszeríti (pl. erősen típusos nyelvek) a helyes kód megírására, akkor közvetetten van összefüggés a program minősége és a programnyelv között.
Másrészről véleményem szerint a java eleve azt tételezi fel a programozóról hogy hülye mert nem tud jól működő programot írni... ezért rakták bele ezeket a futás időben történő, programhibákból adódó anomáliák kijavítására készült hibajavító kódokat.
És így valóban hülyék (is) fognak programokat írni java-ban.
Persze a hülye itt most átvitt értelemben szerepel és nem akarok megbántani senkit.
Néhány extra a javahoz:
Java5:
Ez valami csodálatos újdonság , mert végre implementálták az automatikus kasztolást az int és Integer meg egyéb primitív típusok között. Eleve így kellett volna megírni. A felsorolási enum típus is végre megjelent: nem tudom hogy működik, de remélem helyettesíteni fogja a 100 db-os 'public final static int' matyóhímzéseket.
Java10:
Remélhetőleg meghozza a várva várt java destruktorokat
Java20:
Kivágják a java-s security-t oda ahova való, leülnek, újra megtervezik, úgy hogy érthető és logikus legyen. Lássuk a tényeket: a java programozók 90%-ának fogalma sincs, hogy megy a ProtectionDomain, SecurityManager, AccessController, PrivilegedAction, doPrivileged, Permission, implies,...
Nos ezeknek a programozóknak kell security-t implementálni. Ez ugye vicces. Kb. úgy hangzik, mintha egyszerű kőműveseknek kellene a villámvédelmet megcsinálni. Valami lesz ugyan belőle, de hogy valóban védeni fog-e?
Java30:
Megjelenik a többszörös öröklés és nem kell többé implements varázslással és külön interfészekkel megoldani ezt a hihetetlenül bonyolult problémát.
Java40:
Elkezdik végre alkalmazni a signal/slot kezelést. A KutyaFüleListener, KecskeBékaListener,... interfészek eltűnnek a süllyesztőben és egyszerű connect signal-lal megoldható lesz az egész. Nem értem, miért nem került ez eleve bele a javaba. C++-ban csinálták meg először, pedig java-ban sokkal könnyebb lenne implementálni. Egy hétvége alatt Reflection-nel meg tudnám csinálni.
----------------
Nos, java40 után fogom először azt mondani, hogy a java jól átgondolt, használható programnyelv. Egyenlőre az a véleményem, hogy fejlődésben van.
Ezt pro és kontra el lehet mondani. Ha arra használod a nyelvet, amire való, kevés sort kell írnod. Ha másra, sokat.
A java alapvetően arra lett kitalálva, hogy egyszerű internetes appleteket lehessen írni, amik szépen mutatnak egy weboldalon. Erre tökéletesen meg is felel. A fontos az volt, hogy egyszerű legyen és hordozható.
A Sun persze rájött, hogy a java képességei azért túlmennek az appleteken és elindult az alkalmazásfejlesztés irányába. Ez több, kevesebb sikerrel járt. Sok kényelmetlen dolgot hordoz magában, amit idővel majd kijavítanak.
Mindenesetre jó, ha van a java-nak konkurense, mert akkor rá van kényszerítve, hogy fejlesszen. Meddig kellett várni míg az enum megjelent!
[quote:b7f62d428b="maszili"]
A programnyelv egy eszköz amivel a programozó a programot készíti. Ha az adott programnyelv ad megfelelő eszközöket (korábbi hozzászólásomban felsoroltam párat) hogy jó programot készítsen a programozó, sőt rákényszeríti (pl. erősen típusos nyelvek) a helyes kód megírására, akkor közvetetten van összefüggés a program minősége és a programnyelv között.
Láttál már Java-t, vagy csak irogatsz róla?
objektum orientáltság - pipa
polimorfizmus - pipa
template-ek, generikus programozás - generics csak 1.5 ota es kicsit mas, mint a C++-ban, de azert hasznalhato... legyen pipa
erősen típusosság - pipa
többszörös öröklődés - helyett interfészek használata... ezen elvitatkozhatunk
ezen túl automatikus memóriamenedzsment ... Még C++-hoz is VAN! :)
Elfogadod, hogy a Java is ad annyi programnyelvi eszközt a programozó kezébe, mint a C++? Mert ha igen, akkor sok mást is el kell ismerj.
Pedig megbántasz, cirka 4 millió fejlesztőt világszerte. Mert mondhatnád, hogy C++-ba meg azért raktak referenciákat, mert feltételezték, hogy a programozó hülye és nem tud pointerekkel operálni. Meg, hogy a C-be azért raktak struktúrákat, mert a programozó hülye és nem bírja fejben kiszámítani az egyes struktúratagok címzési eltolását. Meg, hogy az assemblyben azért ilyen idióta betűszavakat használnak, mert a programozó hülye, és nem bírja megjegyezni a hexadecimális kódját egy relatív ugrásnak. És akkor már vissza is érkeztünk a lyukkártyás programozókhoz, akik szidják a terminálon dolgozókat. Hogy az a vaskalap nem bír elrozsdásodni...
Még egyszer: GC akkor van, ha elfogy a memória. Fogja és végignézni mi a szemét és eltakarítja. Ha úgy írod meg a programot, jól méretezed a heap-et, a young és az old generation-t, akkor a programod akár úgy is futhat, hogy az indulását követő első 5-6 másodpercen túl SOHA NEM AKTIVIZÁLÓDIK A GARBAGE COLLECTION (legalábbis az old generation-re ezt elég könnyű elérni, a young-nál meg nem is annyira érdekes, mert optimális esetben a gc által elvett erőforrás kevesebb, mint amennyibe C/C++ esetén a malloc/free, new/delete kerül heap objektumok esetén)! Persze ehhez az kell, hogy ne szemetelj a memóriába, minden objektumod "éljen", de pl J2ME esetén vannak játékok amiket arra optimalizálnak, hogy GC nélkül fusson a telefonon. Mert lehet, csak ismerni kell a rendszer működését, és nem érdemi információ hiányában, a nagy általános elgondolások és tévhitek ismeretében nyilatkozni dolgokról.
[quote:47ec7893ae="Csab"]Lássuk a tényeket: a java programozók 90%-ának fogalma sincs, hogy megy a ProtectionDomain, SecurityManager, AccessController, PrivilegedAction, doPrivileged, Permission, implies,...
Nos ezeknek a programozóknak kell security-t implementálni.
ezt eleg meredek a java hibajakent felroni
[quote:47ec7893ae="Csab"]nem kell többé implements varázslással és külön interfészekkel megoldani
ez izles es megszokas kerdesen kivul miert erdekes?
[quote:f7edb3b01d="ssikiss"]Azért azt kicsit dúrvának tartom, hogy valaki az érték szerinti paraméterátadás lehetőségét tervezési hibának tartja. :roll:
Egy másik téma, hogy mintha némelyek fejében kicsit pontatlan kép élne a C++-ról.
A C++-t olyan általános programozási nyelvnek tervezték ami az oo tervezést, fejlesztést _is_ jól támogatja, de nem kötelező használni az oo eszközeit, és nem az alapjaitól oo, ellentétben a jávával.
mondanam, hogy a c++ mint precompiler jelent meg, nem mint nyelv
Sot tobb precompiler, amit aztan nagy nehezen ugyahogy osszemasziroztak.
ugyhogy ezt a folyamatot inkabb ne nevezzuk tervezesnek...
[quote:dad7d52f18="gee"][quote:dad7d52f18="Andrei"][quote:dad7d52f18="gee"]en UML modellezesre Umbrello-t hasznalok, es tetszik. Ja, ez QT, nem swing.
Ugy alapjaban veve tetszett volna, de nekem Windowsos valtozat is kellene.
Megjegyzem, QT van Windowsra. De nem tudom, maga az Umbrello megy-e.
Te megnezted, es nincs w32 valtozat?
No, megneztem, csak X11 es KDE ala irja. Szoval Win kilove.
Viszont en meg akarnam nezni ezt a MagicDraw-t. De latom am, hogy penzes, ha jol latom, a community edition letoltheto ingyen, de abban meg a diagramok jo reszere azt mondja, limited. :-(
Mindegy, azert megnezem
[quote:f957de6f00="feledhetetlen"]
mondanam, hogy a c++ mint precompiler jelent meg, nem mint nyelv
Nem lehet, hogy attól függetlenül, hogy az első megvalósítása precompiler volt, azért azt még programozási nyelvnek találta ki BS? A programozási nyelv egy elméleti ajánlás, szabvány, vagy valami ilyesmi, a megvalósítás pedig ennek egy megjelenési formája. Ez így túl elrugaszkodott kijelentés?
Mindenesetre amíg a JRE-t és java compilert C, C++-ban írják, addig nem érdemes a C++ ellen pampogni.
[quote:4888e16805="feledhetetlen"]aztan lokalisan is tudtam reprodukalni, ha x86-on futtot a kod sparc, motorola, powerpc rendben volt...
nem preparaltam ki a hibat a szimulaci core meg
lines:103804
files:923
szoval kicsit tullepi a post meret korlatait
Jó lenne ez a megírás, igencsak érdekelne. Főleg akkor, ha lokális gépen reprodukálható, és nem hálózati átvitel hibája.
[quote:32e89a1b55="hop1"]És kimaradt a pascal :(
Én is hiányoltam, pedig annak is van free megvalósítása. Így az assembly-re szavaztam. Bár ritkán használom (itt nem is az volt a kérdés), de frankó kicsi és gyors progikat lehet vele fejleszteni. Hm, a "modern" GUI-szel felszerelt alkalmazásokhoz képest szinte nincs is méretük... (sóhaj)
[quote:c96f5ab6cf="Csab"]A java alapvetően arra lett kitalálva, hogy egyszerű internetes appleteket lehessen írni, amik szépen mutatnak egy weboldalon. Erre tökéletesen meg is felel. A fontos az volt, hogy egyszerű legyen és hordozható.
A Sun persze rájött, hogy a java képességei azért túlmennek az appleteken és elindult az alkalmazásfejlesztés irányába. Ez több, kevesebb sikerrel járt. Sok kényelmetlen dolgot hordoz magában, amit idővel majd kijavítanak.
Amennyit en ennek utanaolvastam, elobb volt cel a hordozhatosag es az egyszeruseg (1990 kornyeke) (pontosabban a C++ felrehasznalasi lehetosegeinek lehetoseg szerinti csokkentese), es csak joval kesobb jott kepbe az applet (1994)... Mindenesetre az applet volt az elso igazi nagy alkalmazasa, hala a Microsoftnak kikopott a mainstreambol...
[quote:c96f5ab6cf="Csab"]Mindenesetre jó, ha van a java-nak konkurense, mert akkor rá van kényszerítve, hogy fejlesszen. Meddig kellett várni míg az enum megjelent!
Az enum nem a versenytarsak miatt jelent meg, hanem kozossegi nyomasra, meghozza az aktiv Java fejlesztok nyomasara (ertsd: nem az a cel, hogy C++-t csinaljanak, hanem hogy tenyleg igenyelt dolgok keruljenek a nyelvbe). Viszont a versenytarsak mindig jok. Meg lehet nezni, hogy mennyire fejlodik vagy sem az MS C++ forditoja, es meg lehet nezni a Java elmult ot eves fejlodeset. A .NET-et csak kicsit sorolom ide versenytarsnak, mert a Java tapasztalatokbol sokat atvett (ami teljesen egeszseges viselkedes, nem ertem, hogy ki miert fuj erre), es kesz versenypalyan kezdett. Ugyanakkor technologiai lehetosegekben a Java tobb, uzleti szempontbol pedig nem csak egy ceg all mogotte.
[quote:52a5b2eed6="Andrei"]Marad a Posseidon, bar nem teljesen ingyenes (de nem is Javas).
Nem javas? Biztos vagy te ebben? (;
[quote:6514b49597="Csab"]Mindenesetre amíg a JRE-t és java compilert C, C++-ban írják, addig nem érdemes a C++ ellen pampogni.
Mar megint az almat hasonlitod a kortevel. :)
[quote:a3f6a068af="syntern"]
Jó lenne ez a megírás, igencsak érdekelne. Főleg akkor, ha lokális gépen reprodukálható, és nem hálózati átvitel hibája.
nem a halozati atvital hibaja... :)
szoval megmondom:
az a helyzet eleg nagy szamitasi kod kell, hogy a hotspot elhalassza a forditasi lepest a profile utanra
mindenfele quicksort-os gyerek kodokat egybol lenyel megemeszt kikop es fut mint nativ
nalam a targykod 800k es be is huzza magat mielott el kezd szamolni
ilyenkor class inicializerek static{...} persze lefutnak
limiteket szamolnak, konstansokat a szamitasi pontossagtol fuggoen
Pi, e etc...
szoval a hotspot ezeket a szamitasokat interpretalja, hogy a futasi meresek utan tudjon optimalizalni
az interpretalas a nyelvszabvany koveto stilusban IEEE float muveletek hajt vegre
aztan a kod persze fut tovabb (8-10 perc egy 700Mhz PIII-on)
ekkor fogja magat a hotspot es nativ forditja a szamitasokat
ezek a szamitasok persze mar intel FPU muveletekke valnak
ezek eredmenya nem egyezik az IEEE szabvannyal leven nehany bittel pontosabb...
szoval ez nem titok regen kiderult mar ahogy megjelent a hotspot
az elso szepsegtapasz volt a strict_fp method classifier
ez azt eredmenyezte hogy az eljaras kodjaban nem fordul le platform nativra az fp muvelet
ez persze a kod, nem vegrehajtasi szal, vagyis ahogy kilep pl egy Math.sin-re azon megint elcsuszhat
erre kiadtak a StrictMath osztalyt amiben a szamitasi muveletek IEEE konformok maradtak
szoval az 1.1-ben kerult bele a bomba, mert akkor nem tunt problematikusnak, kicsit kesobb robbant...
de igy legalabb gyorsabb volt :(
[quote:2e84a8b9f4="hanischz"][quote:2e84a8b9f4="fdavid"][quote:2e84a8b9f4="hanischz"]Még pár év és több giga memória lesz a gépekben illetve még erősebb proci. Ilyen gépen remekül fognak futni a progik.
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
A masik, hogy enyhen szuklatokuruseg a dolgok jelen allapotaban a szoftverfejlesztest kizarolag PC-s (ertsd: szemelyi szamitogepes) kornyezetre vonatkoztatni. Ugyanis meglehetosen nagy szamu beagyazott eszkoz van korulottunk, amiket mar joreszt szinten magasszintu nyelveken (nagytobbsegeben C-ben) programoznak.
Hmmm, azt kell látni (legalábbis szerintem) hogy manapság nem a CPU és a memória mennyiség a szűk keresztmetszet. Hanem a programhibák tömkelege!
Ezt nem teljesen ertem, hogy hogyan vetheto ossze a programhiba a gep teljesitmenyevel. Ha azt akarod mondani, hogy egy bizonyos feladat nem hajthato vegre jol mukodo program hianyaban, akkor ez trivialis, es nem ujkeletu problema.
1. Ugyanakkor tovabbra is fenntartom, hogy korul kell nezni a bagyazott rendszerek kornyeken. Nagyon komoly teljesitmenymegszoritasok mellett kell fejleszteni.
Ugyanis kicsit kellemetelen lenne, ha pl. egy mosogep, vagy egy ABS vezerloegyseg, vagy egy mobiltelefon, stb. mai PC szintu teljesitmenyt igenyelne, a hozza tartozo meretekkel, hutessel, es arral.
2. De nezhetjuk a szemelyi szamitogepeket is. A teljesitmeny novekedesenek felhasznalasa jo, ha annak konkret celja van, es nem ugyanannak a funkcionalitasnak a gyengebb es eroforrasigenyes megvalositasa okan kell otthon dragabb szamitogepet tartsak.
3. A szuperszamitogepek eseteben pedig a bekerulesi es uzemeltetesi koltsegek okan meglehetosen nagy luxus lenne az eroforrasokat nem a szamitasi cel erdekeben hasznositani.
Ezen kivul lehet arrol beszelni, hogy a programozo ideje vagy a gep kerul-e tobbe. Egy beagyazott rendszernel vagy a szperszamitogepek eseten mar nem olyan egyertelmu, hogy vegyel bele tobb RAM-ot, az olcsobb.
[quote:2e84a8b9f4="hanischz"]Nézd meg a mobil telefonod! Nem fagy néha? Talán C-ben írták :) Vagy egy csomó más progi pc-n. Linux vagy win alatt.. mindegy. Apache nevű webszerver c mivolta miatt (buffer túlcsordulás) törhetnek be internetről stb.
Volt alkalmam mobiltelefonba is fejleszteni, koszoni szepen - amit en irtam - nem fagy le. Es mas programjaim sem. Szoval nem a nyelven mulik, hogy egy program jo-e vagy sem. Raadasul a mobiltelefonokban is egyre tobb a Javas resz, es azokkal legalabb annyi hibajavitas es egyeb problema van, mint a C-s reszekkel. Ugyanis nem ezen mulik. A nyereseg ott van, ha egy nyelvben kenyelmesen es hatekonyan lehet dolgozni, es ezzel idot lehet nyerni. Ilyen szempontbol a Java sokkal jobb, mint a C vagy C++, de sajnos teljesitmeny okoknal fogva a Java nem uberkiraly. Bar az lenne. De ott van a D nyelv (http://www.digitalmars.com/d/), ami azt hiszem, hogy igencsak eltalalt holmi.
A masik, hogy C++-hoz is van GC, vagy pl. ott a QT, amivel alom dolgozni. Masik oldalrol sok olyan programozasi kornyezet van, ahol nincs meg debugger, coverage, profiling tool sem, pedig ugye ezek C-hez letezo dolgok. Na persze.
Szoval ismet csak peldak arra, hogy a nyelv onmagaban meg kozel sem donto.
[quote:2e84a8b9f4="hanischz"]Egy általános programnál a megrendelő nem azt várja h egy 386-oson is elmenjen a progid, hanem hogy hamar! készen legyen és ne legyen benne hiba!
Tapasztalat!
Nem biztos. Lehet, hogy azt varja el, hogy biztonsaggal, es _idoben_ kinyiljon a legzsak. Ja es szarnak a managelt kodra.
[quote:2e84a8b9f4="hanischz"]Hanem azt mondom h a mostani "válságra" (azaz hiba hiba hátán egy programban, pc, mobil telefon egyremegy, és kijavítanak egy hibát kettő új lesz), a megoldás a menedzselt kód.
Nem! A managelt kod csak toredeket oldaj meg a problemaknak, es raadasul ujakat hoz be, a hibas szemlelettel.
A megoldas a minsoegbiztositas. Tisztesseges folyamatdefiniciok, modszerek, eszkozok, human eroforras osszhangaja, tervezes, dokumentalas, es atfogo teszt.
[quote:2e84a8b9f4="hanischz"]Persze a teljesítményt követelő területeken minden csepp proci erőre szükség lesz, ott c vagy asm a megoldás egyelőre.
Ez sem feltetlenul igaz. Assemblert nagyon keves helyen hasznalnak, es gyakran nem C-ben, hanem magasabb szintu kornyezetben fejlesztenek, es csak generaljak a C kodot. Ja es Pascal is elofordul meg itt-ott, persze nem uj projektekeben.
[quote:739d08800e="maszili"]Itt egy összehasonlítás... a kuglival találtam...
Java vs. C++
http://verify.stanford.edu/uli/java_cpp.html
2003, 1.3-as JVM. Régebbi nem volt?
[quote:e70fce1124="_Joel"]
Még egyszer: GC akkor van, ha elfogy a memória. Fogja és végignézni mi a szemét és eltakarítja. Ha úgy írod meg a programot, jól méretezed a heap-et, a young és az old generation-t, akkor a programod akár úgy is futhat, ... stb.
Joel.. látom Te Java fanatikus vagy és GC hivő..:))
Én a maga részéről azt mondom a GC-re, hogy egy sz*r szemét.
De, hogy ne csak a levegőbe beszéljek:
- környezet: NetBeans 4.1 + Profiler, 1.5.0_05 jdk
A teszt program a hozzászólás végén.
A lényeg a következő:
- a kod letrehoz egy fő-frame-t, 1 darab button-nal
- ha raklikkelsz a gombra, akkor letrejon egy ablak x darab button-nal
- a letrejott ablakot be kell zarni a ablak bezaras ikonjaval
A lényeg:
- két actionlistener megvalositast hoztam letre (Megvalositas 1, 2.)
- a kulonbsegek:
a. Az elso helyi valtozokban "tarolja el" a letrehozott ablak es panel referenciáját,
tehet mikor bezarod a letrejott ablakot az "nem szabadul fel", ha viszont masodszor
is raboksz a gombra null-azza a ket referenciat.
b. ebben az esetben nem hasznalja a helyi referenciat.
Kicsit bonyolult igy leirva, nezd meg a kodot.. pár sor.
Mi a lényeg?
1. Mindkettő megoldás szabályos (javits ki, ha nincs igazam)
2. A különbség mégis "látványos" ha a profiler-el nézed a JButton class-t
A magam részéről ezért mondom, hogy sz*r a gc.
Az, hogy "relative" két helyes, hellyel közzel ugyanaz a megvalósitás két különböző
eredményt ad.. katasztrófális szerintem.
Az egyik esetben ott a memory leak.. a másiknál nincs ott.
Nos?
Vélemény?
Fri
package leak;
import java.awt.event.*;
import javax.swing.*;
public class Main extends JFrame implements ActionListener {
JPanel panel = null;
JFrame frame = null;
public Main() {
setTitle("frame1");
setLocation(0, 0);
setSize(100, 160);
JButton button = new JButton("Letrehoz..");
button.addActionListener(this);
getContentPane().add(button);
setVisible(true);
}
public static void main(String[] args) {
Main main = new Main();
}
// Megvalositas 1
/*
public void actionPerformed(ActionEvent ev) {
if (frame == null) {
frame = new JFrame("frame");
frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
frame.setSize(360, 260);
panel = new JPanel();
for (int i = 0; i < 50; i++) {
panel.add(new JButton(Integer.toString(i)));
}
frame.getContentPane().add(panel);
frame.setVisible(true);
} else {
// panel.removeAll();
// frame.getContentPane().removeAll();
panel = null;
frame = null;
}
}*/
// Megvalositas 2
public void actionPerformed(ActionEvent ev) {
JFrame frame = new JFrame("frame");
frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
frame.setSize(360, 260);
JPanel panel = new JPanel();
for (int i = 0; i < 50; i++) {
panel.add(new JButton(Integer.toString(i)));
}
frame.getContentPane().add(panel);
frame.setVisible(true);
}
}
[quote:800cab5ece="feledhetetlen"]szoval az 1.1-ben kerult bele a bomba, mert akkor nem tunt problematikusnak, kicsit kesobb robbant...
de igy legalabb gyorsabb volt :(
Ez jó, köszi hogy leírtad, mindig tanul újat az ember :)
[quote:1f6f5fbd03="feledhetetlen"]
Arra szeretnek csak ramutatni, hogy a leforditott java kodban megmarad a gyorsitas lehetosege, mig a C targykod 'doglott' ebbol a szempontbol.
elmélet, elmélet, elmélet....
a gyakorlat meg a fenti freewebs.com-os linken olvasható: a c++ sokszor 2x gyorsabb, néha 4x.
ennyi.
[quote:3fde236eef="feledhetetlen"]
de igy legalabb gyorsabb volt :(
Emlekszem, olvastam errol sun internal anyagokat 2-3 eve... ott mintha az Intelt szidtak volna a mernokok amiert nem kepes IEEE-t hasznalo FPU-t tervezni es hasznalni.
[quote:c1975476d6="maszili"]
Szerintem meg lehet jó vagy rossz egy filozófia, mert azt az adott környezetben az adott feladat megoldása során vizsgáljuk. Ha nem így lenne akkor elég lenne a strukturált programozás és nem lenne szükség az OO-ra.
Az egyetlen probléma, hogy jelen esetben nincs "adott környezet", sem "adott feladat", hanem ezt állítod:
[quote:c1975476d6="maszili"]
Itt érkeztünk el ahhoz a ponthoz hogy saját magad mondod ki azt, hogy a java filozófiája rosszabb mint a c++. :)
Fölösleges megkötésekkel gátat szab saját maga kifejező erejének...
Azaz ebből az esetből (op overloading) megállapítod, hogy a Java filozófiája rosszabb. Holott ez csak egyetlen kérdés a sok közül egy nyelv/platform esetén.
Ez alapján lehetetlen egyik filozófiáját a másikénál rosszabbnak nyilvánítani, mert pl egy ügyviteli rendszer esetén (egy korábbi példával élve) valószínűleg nehezen értelmezhető két bankszámla összeadása (és viszonylag ritkán van szükség egyéb OpOL-ra).
Miert nem whitespace, befunge, brainfck vagy fp hivoknek unlambda ;-)
Mielőtt meköveztek hogy "erre" a memory leak-k szót használtam..
.. azrét tettem, mert a nem épp optimális esetben, csak csupán pár
objektum jön létre, egy komolyabb alkalmazás esetén ezrekről, tizezrekről
beszélhetünk.. és ott már nagyon nem mindegy, mennyire is hatékony a
memoria kezelés.
Fri
Tessek elolvasni a GC Threads cimu reply-t ezen a hiren:
http://www.theserverside.com/news/thread.tss?thread_id=37984
Ha lesz egy kis szabadidom jobban atgondolom, hogy a multi core-multi thread CPU-k hasznalata eseten egy konkurrens GC algoritmus (ahol kulon, a programmal parhuzasmosan futo GC szal vegzi a takaritast) pontosan milyen hatranyokkal es elonyokkel jar, egyaltalan meg kell-e akasztani barhol is a fo program mukodeset, es vesztunk vagy nyerunk-e ezzel a mukodesi semaval...
[quote:733448482c="syntern"][quote:733448482c="Csab"]Mindenesetre amíg a JRE-t és java compilert C, C++-ban írják, addig nem érdemes a C++ ellen pampogni.
Mar megint az almat hasonlitod a kortevel. :)
javac C-ben van irva? de tenyleg???
elmondod, hogyan jutottal erre a kovetkeztetesre?
jre/lib nalam 89M total ebbol nativ 31M a nativ (feltetelezzuk C)
akkor ez miben van irva?
[quote:94114348e3="lokoto"]Fordítsunk a helyzeten (kérem a szöveget nem kiragadni a környezetéből):
- a C++ filozófiája rosszabb, mint a Javáé, mert nincs benne reflection
- a C++ filozófiája rosszabb, mert nincs benne GC
- a C++ filozófiája rosszabb, mert nincsenek benne csomagok
csak azért válaszolok erre a hülyeségre, nehogy valaki azt gondolja, hogy így igaz, ahogy leírod.
reflection, GC megírható c++-ban, amit írtál? igen. C++ GC-re példa linket is adtam.
A c++ nyelv a power usereknek, ami szinte korlátlanul bővíthető, ha hozzáértő áll neki.
Ezzel szemben a Java: azt eszed amit eléd raknak... legfeljebb majd néhány év múlva mást is eléd raknak.
eszed, nem eszed, nem kapsz mást.
Valaki azt mondta pár hozzászólással régebben hogy ez az egész GC (és a szemlélet) egy olyan törzsfejlődés a programozás terén mint az OO a struktúrált programozáshoz képest. Akkor kérdezem én, hogy van-e lehetőség arra hogy egy tetszőleges objektumom számára definiáljak pl. értékadó operátort.
c++ -ban pofon egyszerűen megoldható és így valóban teljesűl az OO szemlélet és még a kód is egyszerű és átlátható.
pl. legyen X és Y egy tetszőlegesen bonyolult adatszerkezettel megvalósított objektum, ekkor felírható így az értékadás...
X = Y ;
Nincsenek pionterek, referenciák, nincsen memory leak, stb... nem kell tudnom semmit az objektumok működéséről (OO).
Ez java-ban hogy néz ki?
[quote:4ff6979a11="syntern"]Van még mit fejlődnie a JVM-nek, és gyanítom, hogy fog fejlődni. (Érdemes lenne kimérni JRockit-tal, van erre is kapacitásod?)
Később szerkesztettem a hozzászólást, ott leírtam, hogy szimpla -O2-es optimalizációval (-march=k8 nélkül) is nagyjából ugyanazt az eredményt hozta.
JRockit-tel nincs kedvem most szórakozni, de IBM jdk-val megnéztem, mert az van fenn.
export JAVA_HOME=/opt/IBMJava2-amd64-142
$JAVA_HOME/bin/java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 2.2)
IBM J9SE VM (build 2.2, J2RE 1.4.2 IBM J9 2.2 Linux amd64-64 j9xa64142-20050929 (JIT enabled)
J9VM - 20050915_1103_LHdSMr
JIT - r7_level20050909_1801)
Elég érdekes eredményeket adott:
$JAVA_HOME/bin/java -Xmx300M QuickSort
21188
6686
6683
Számomra az a konklúzió, hogy
1. A java bár nagyon "ott" van, de nem éri el a C++ programok sebességét (és memóriafoglalása is nagyobb, és valjuk be lassabban is töltődnek be a java programok).
Ha "el akarjuk adni" a java-t, ne a sebességet említsük első helyen. Vannak a java-nak más olyan tulajdonságai, amelyek értékes programozási nyelvvé teszik.
2. A 4-es g++ -ban vmit nagyon el*******. (Én 3.4.3-assal fordítottam,
úgy jött ki az 5173-as eredmény.)
3. Szerintem az IBM jdk-ja a legjobb teljesítmény szempontjából.
Régebben próbáltam egy-két benchmark teszt erejéig a JRockit-et, de nem volt elég meggyőző.
Bár nem sok értelmét látom a sebességet hajkurászni "kedvenc" címszó alatt (lásd az előző postomat), kérnék minden benchmar huszárt, ha már -O1 -O2 -O3, stb kapcsolókkal varázsol C oldalról, legyen szíves a javac mögé bepöttyinteni egy -O -g:none-t. Esetleg egy -server talán egy -b bónuszkapcslót (a -Xnoclassgc vagy a -Xincgc csak perverzeknek) a java után.
thx.
/a pártatlan/ :roll: :lol:
[quote:bdfcfec52e="snq-"][quote:bdfcfec52e="Csab"]Lássuk a tényeket: a java programozók 90%-ának fogalma sincs, hogy megy a ProtectionDomain, SecurityManager, AccessController, PrivilegedAction, doPrivileged, Permission, implies,...
Nos ezeknek a programozóknak kell security-t implementálni.
ezt eleg meredek a java hibajakent felroni
Úgy kell megírni, hogy érthető legyen.
[quote:bdfcfec52e="snq-"][quote:bdfcfec52e="Csab"]nem kell többé implements varázslással és külön interfészekkel megoldani
ez izles es megszokas kerdesen kivul miert erdekes?
Eggyel kevesebb interfész osztályt kell definiálni. Jelenleg 2 osztályt csinálsz, egy megvalósító osztályt és egy interfészt. Dupla munka, dupla karbantartás.
Bár a C++ header, source is dupla munka, csak másképp.
[quote:03b0d3b700="bocs"][quote:03b0d3b700="lokoto"]Fordítsunk a helyzeten (kérem a szöveget nem kiragadni a környezetéből):
- a C++ filozófiája rosszabb, mint a Javáé, mert nincs benne reflection
- a C++ filozófiája rosszabb, mert nincs benne GC
- a C++ filozófiája rosszabb, mert nincsenek benne csomagok
csak azért válaszolok erre a hülyeségre, nehogy valaki azt gondolja, hogy így igaz, ahogy leírod.
reflection, GC megírható c++-ban, amit írtál? igen. C++ GC-re példa linket is adtam.
A c++ nyelv a power usereknek, ami szinte korlátlanul bővíthető, ha hozzáértő áll neki.
Ezzel szemben a Java: azt eszed amit eléd raknak... legfeljebb majd néhány év múlva mást is eléd raknak.
eszed, nem eszed, nem kapsz mást.
"csak azért válaszolok erre a hülyeségre, nehogy valaki azt gondolja, hogy így igaz, ahogy leírod." :)
Kíváncsian várom a C++ reflectionre vonatkozó linket. Ahogyan kíváncsian várom a C++ többgenerációs (= nem referencia counter) GC-re is a linket. Valamint arra is kíváncsian várom a választ, hogy a Java miért nem szinte korlátlanul bővíthető, és hogy a C++-ban miért nem csak azt eszed, amit eléd raknak :) (a vége komolytalannak tűnhet, de teljesen komolyan: milyen pontokon látsz korlátozásokat? A szintaktikai dolgoktól szerintem eltekinthetünk, mert szerintem lényegtelen, hogy operátorhoz írsz metódust, vagy metódust írsz)
bash/fpc
Elég rég óta dolgozom JAVA közelben.
A JNI-ről annyit, hogy debugolni tökéletesen lehetetlen és ha nagy programot írsz, az teljesen áttekinthetetlen lesz. Néha misztikus fagyások. Szóval senkinek sem ajánlom.
Persze mindenre lehet java-t használni, csak nem mindenre érdemes.
Láttam már szervert, amit java-ban írtak és irgalmatlan erős gépeken úgy ment, mint egy beteg tetű.
Mivel több éves fejlesztés volt, így nem lehetett újra kezdeni és nulláról megírni. Menedzsment hiba volt, hogy java-ra rakták az egészet. Érdemes megemlíteni a JVM hibákat is. Mit csinálsz, ha fagy a JVM? Egy szerver nem fagyhat csak úgy ki. C-ben még lehet bütykölni, nade ha a JVM fagy? Szóval a titokzatos memory leak-ek, JVM fagyások,... miatt késett a szerver projekt fél évet. A Java a Sun kezében van és igencsak kell könyörögni ahhoz, hogy egy JVM hibát kijavítsanak.
Szerver alkalmazást sosem írtam volna java-ban. Az értelmes megoldás szeritem az, hogy szervert C és C++-ban ír az ember, a kezelőfelületét pedig java-ban.
Nálunk a java, C++ a következőként oszlik el.
Ha hardver specifikus dolgokat akarunk csinálni, akkor C++.
Ha hordozható szoftvert akarunk, akkor java.
Ha kell hardver specifikus és hordozható is:
- a hardver specifikus részek C, C++
- a többi java
Nyilván mobiltelefonon könnyebb jó java-t implementálni, mint PC-n.
Igazán jó hardver gyorsítást lehet a mobil processzorba tenni, ennek megfelelően veri a PC-s JVM-eket.
A Sun már készített olyan processzort, amelynek java a nyelve. Nyilván ilyen processzoron a C,C++ lassabb, mint a java.
A 80x86-os processzorok C-re lettek optimalizálva. Akkor még nem volt java, épp ezért veri a C mindenütt a java-t. Megfelelő hardverrel fordított állás is elérhető.
Persze egy OpenSource JVM sokat segítene a dolgokon. Nem tudom, hogy készült-e ilyen.
[quote:9e1e9ad733="Chain-Q"]jon valaki okostojas, es kozli h. szerencse h. kimaradt a Pascal, es persze nem mulasztja el bepastelni a hatulgombolosozos dumat. De hat ez mar nem engem minosit.
Sajnos téged minősít. "szerencsére" - ezt én írtam, a másikat meg nem.
Egyszerűen nem tetszik és kész, egyébként: az ada logikus, pascal idétlen. Miért nem lehet lezárni rendesen az if-eket (end if), és miért nem lehet az end elé pontos veszsőt tenni (üres utasítás a pontosvessző, ahelyt, hogy egy null-t kellene odaírni, stb).
Abban reménykedek, hogy a fenntebb említett JDK-k licensze nem tartalmazott tiltásokat benchmark eredmények közzétételére ...
[quote:7a03cc8693="Csab"]
Ezt pro és kontra el lehet mondani. Ha arra használod a nyelvet, amire való, kevés sort kell írnod. Ha másra, sokat.
A java alapvetően arra lett kitalálva, hogy egyszerű internetes appleteket lehessen írni, amik szépen mutatnak egy weboldalon. Erre tökéletesen meg is felel. A fontos az volt, hogy egyszerű legyen és hordozható.
A Sun persze rájött, hogy a java képességei azért túlmennek az appleteken és elindult az alkalmazásfejlesztés irányába. Ez több, kevesebb sikerrel járt. Sok kényelmetlen dolgot hordoz magában, amit idővel majd kijavítanak.
Mindenesetre jó, ha van a java-nak konkurense, mert akkor rá van kényszerítve, hogy fejlesszen. Meddig kellett várni míg az enum megjelent!
a java megrendelesre keszult, egy settopbox-okat gyarto konzorcium rendelte meg a sun-tol
a konzorcium felbomlott a nyelv (akkor meg Oak) viszont joreszt elkeszult
bar ezt en olvastam, de szerintem igaz lehet
sajnos az 1.0 megjelenese elsietett volt
az applet abszolut csak egy zsenialis marketing huzas volt
az applet szerintem inkabb hasznalt mint artott
a fejlesztes nem csak azert lassu, mert Bill, James es meg Guy is elfelejtette megerdeklodni nalad mi kellene bele, hogy te is hasznald
inkabb azert mert a szabvannyal NAGYON ovatosan kell banni,
ugyanis ami 'tapad az ragad'
biztos tudod milyen sulyos konfliktus szarmazott az NFS tul gyors szabvanyositasabol
vagy NetBIOS 'mindentbele ami tetszik' szabvanybol
szoval nekem inkabb az tetszik ha megfontoltan de biztosan halad a Java
akar az is tetszik, hogy az uj JavaBeans specifikacio visszater a POJO modelhez
az enum nem azert nem kerult be mert a tervezok kifelejtettek:
az enum tipusos kellett legyen
a generics csak tervben volt mikor ki kellett adni a javat
logikailag a generics megjelenese utan kerulhetett bele
utana bele is kerult
szeretnem azert ha kicsit osszehasonlitanad a c++ enumot a java enum-mal... szerintem 'not the same ballpark'
talan azert mert jol meg lett tervezve?
az generics az enum tobszoros visszateresi ertek az eredeti tervben is benne voltak
ezt nem olvastam: az 5 evvel ezelotti JavaOne-on halottam James Gosling-tol, hajlamos vagyok hinni neki...
[quote:d8e874d5bd="Panther"]
Egyszerűen nem tetszik és kész, egyébként: az ada logikus, pascal idétlen. Miért nem lehet lezárni rendesen az if-eket (end if), és miért nem lehet az end elé pontos veszsőt tenni (üres utasítás a pontosvessző, ahelyt, hogy egy null-t kellene odaírni, stb).
Nem értem a hozzászólásod! Nem logikus, Miért?
BLOKK = BEGIN utasítás;[utasítás;]... END; vagy utasítás;
Minek kell ezt feszegetni... C/C++/Java:
BLOKK = {utasítás;[utasítás;]...} v. utasítás;
Mennyivel jobbak ezek?
Nem véletlenül használják a Pascalt az oktatásban, egyszerű, logikus. Ezt nem lehet megkérdőjelezni.
Fejlődik és gyorsan lehet vele fejleszteni.
Hogy "Nem tetszik".... :-) jó hagyjuk... Én ISMEREM és szeretem
Chain-Q-nek ajánlom, bár tudom hogy a Kylix-et nem szereti :-)
- az FPC jól halad,
- a Lazarus fejlődik...
- a ZeOS DBO is elindul a Lazarusz alatt, bár nálam még a DBGrid dob egy hátast, de jó lesz
Van jövője a nyelvnek a többiekkel meg nem kell foglalkozni!
Attila
[quote:a4a4db7463="popacsek"]Később szerkesztettem a hozzászólást, ott leírtam, hogy szimpla -O2-es optimalizációval (-march=k8 nélkül) is nagyjából ugyanazt az eredményt hozta.
Olvastam, és ppont emiatt írtam, hogy szerintem a C++-nál sem a compiler, hanem a runtime (azaz, hogy mire van fordítva a minden más) határozza meg a teljesítményt.
[quote:a4a4db7463="popacsek"]1. A java bár nagyon "ott" van, de nem éri el a C++ programok sebességét (és memóriafoglalása is nagyobb, és valjuk be lassabban is töltődnek be a java programok).
Ha "el akarjuk adni" a java-t, ne a sebességet említsük első helyen. Vannak a java-nak más olyan tulajdonságai, amelyek értékes programozási nyelvvé teszik.
Egyetértek, de másképpen fogalmazok: minden más dologban jobban el lehet adni a Javat, és most már a sebességre sem lehet azt mondani, hogy lassú lenne.
[quote:2f5f12f26f="Csab"]Persze egy OpenSource JVM sokat segítene a dolgokon. Nem tudom, hogy készült-e ilyen.
mustang.dev.java.net
[quote:438b478c50="maszili"]hogy van-e lehetőség arra hogy egy tetszőleges objektumom számára definiáljak pl. értékadó operátort.
Nincs éspedig szándékosan nincs operator overloading. Ez egyike volt a "Java legyen egyszerubb, mint a C++" tervezesi elgondolasnak. Ez a vita időnként periodikusan előjön különféle helyeken, pl itt:
http://forums.java.net/jive/thread.jspa?threadID=192&messageID=31003
[quote:e807702a70="Csab"]
Egy hétvége alatt Reflection-nel meg tudnám csinálni.
Ugy, mint a referenciaszamlalasos automatikus memkezelest? :twisted:
Lassunk nehany alapveto problemat C++-bol?
- Nincs override kulcsszo? (Elarulom: valszeg elfelejtettek anno)
- Miert kell ujraforditani egy osztaly fuggeseit, ha privat mezot adsz hozza az osztalydefiniciohoz? Nekem ez kulonosen kinos, mert olyan programon is dolgozunk, aminek az ujraforditasa 6-8 ora egy eleg jo gepen.
- Az altalad felsorolt security feature-eket nem lelem a C++-ban sem. Ha a Java programozok nem ismerik az ilyen dolgokat, azt tenyleg nem kenheted a nyelvre.
- Siralmas a szabvanyos osztalykonyvtar. 2005-ben a legmagasabb absztrakcios szint a map, meg a szoveges konzol lenne?
- Zerus tamogatas a halozatkezelesre, grafikara, szalkezelesre, oprendszer szolgaltatasok eleresere.
- Rettenetesen elbarmolt szintaktika. Soha senki nem gondolta at. A klasszikus kerdes az UHH-bol: a=b/*p; kifejezes vajon mi? Komment kezdete, vagy osztas egy pointer altal mutatott ertekkel.
- A XXI. szazadban jarunk, de a programozasi nyelvunk meg mindig nagyon kemenyen tamaszkodik a preprocesszor szolgaltatasaira. Miert is nincs benne egy unit szisztema? Object Pascal-ban, Java-ban, C#-ban van, es maris elfeledkezhetunk a header-guide-okrol, es a forditoprogram szepen megoldja a dolgokat.
- Nincs szabvanyos ABI, a forditoprogram irok pedig legtobb rajuk bizott reszletet kepesek kulonbozokeppen megvalositani. Kapj mar el legyszives egy Watcom alol dobott kivetelt Borland C++-ban, Visual C++-ban, GCC-ben! Nem fog menni. Sot ami a megalol: altalaban meg az osztalyokat sem vagy kepes felhasznalni. Miert kell legalabb haromfele name mangling? Miert kell legalabb haromfele fuggvenyhivasi elv?
- Allitolag nem valami egyszeru a nyelvtan. Allitolag meg csak nem is kornyezetfuggetlen...
En birom a C++-t, meg naprol-napra abban programozok a munkamban, de ra kellett jonnom, hogy egyvalamit tamogat igazan es az onmagad tokonszurasa. :)
[quote:de493bfec6="_Joel"]Tessek elolvasni a GC Threads cimu reply-t ezen a hiren:
http://www.theserverside.com/news/thread.tss?thread_id=37984
Ha lesz egy kis szabadidom jobban atgondolom, hogy a multi core-multi thread CPU-k hasznalata eseten egy konkurrens GC algoritmus (ahol kulon, a programmal parhuzasmosan futo GC szal vegzi a takaritast) pontosan milyen hatranyokkal es elonyokkel jar, egyaltalan meg kell-e akasztani barhol is a fo program mukodeset, es vesztunk vagy nyerunk-e ezzel a mukodesi semaval...
Elso blikkre meg lesz kotve a kezed nehany helyen.
pl. nezd ezt a kifejezest
A::A()
{
parent=new B();
}
Itt ugyebar eleg komoly problemat jelentene egy GC futas a new utan, de az egyenlosegjel utasitas vegrehajtasa elott. Nem ertek a Java-hoz, elkepzelheto, hogy a fenti sor eleve atomi muvelet. Minden bizonnyal lehetne olyan kodot fabrikalni, ahol tutira problemat jelentene egy masik szalon futo GC.
Szinten problematikusnak erzem a destruktorok (gondolom Javaban is vannak) futasat. Egy kicsit aggalyos, hogy a konstruktor a programszalban fut , a destruktor viszont a GC szalban. Onmagaban nem problema (bar nem szep megoldas), de vannak olyan nem a Java altal kezelt eroforrasok, amik nem viselik jol, hogy masik szalbol probaljak felszabaditani oket, mint, amiben lefoglaltak.
En ugy erzem, hogy kell valamilyen szinkronizacio a programszallal.
Aztan jon a slusszpoen! Mi van, ha a programod eleve tobbszalu? Egyreszt mindegyikkel szinkronizalnod kell a GC-t, ami nem a jo skalazodas biztositeka.
[quote:83b5cdc7c8="popacsek"]Abban reménykedek, hogy a fenntebb említett JDK-k licensze nem tartalmazott tiltásokat benchmark eredmények közzétételére ...
Emlékeim szerint csak a .NET-nek vannak ilyen félelmei :)
[quote:06c7ee9960="syntern"]...
Az enum nem a versenytarsak miatt jelent meg, hanem kozossegi nyomasra, meghozza az aktiv Java fejlesztok nyomasara (ertsd: nem az a cel, hogy C++-t csinaljanak, hanem hogy tenyleg igenyelt dolgok keruljenek a nyelvbe). ...
ezzel nem ertek 1et
csak ez kis ad hoc forum hany olyan igenyt felvetett amivel siman c++ szintre lehetne szegregalni a java-t
a nyelvbe az keruljon amit az ehhez (computer languages) erto emberek abba jonak latnak
ugyanugy a fordito iro emberek nem tudjak, hogyan kell alkalmazast fejleszteni
az igazi elmeleti szakember egy button se tud rendes helyre rakni egy dialogba,
van olyan kivalo programozo kollegam aki 2 ev windows-on valo fejlesztes utna sem tudott felrakni egy winzip-et a gepere..
ez igy van rendjen, a nyelv szakember csinaljon nyelvet
az alkalmazas programozo csinaljon alkalmazast
[quote:579c8a740e="Csab"]
Eggyel kevesebb interfész osztályt kell definiálni. Jelenleg 2 osztályt csinálsz, egy megvalósító osztályt és egy interfészt. Dupla munka, dupla karbantartás.
Amit minden rendes IDE el tud rejteni előled (felveszed az új metódust az interfészbe, mire feldob egy ablakot, hogy az azt implementáló osztályokba akkor ő most létrehozza ezt a metódust és belerak egy //TODO remarkot is, hogy a TODO listában is megjelenjen az újonnan implementálandó kód, mint feladat...)
[quote:db67b1aeb6="bocs"]
a gyakorlat meg a fenti freewebs.com-os linken olvasható: a c++ sokszor 2x gyorsabb, néha 4x.
ennyi.
Inkább azt mondd, mennyit sikerült javítani Syntern quicksort C++ példáján? Megvan már legalább a 1,5x-es gyorsaság a Java kódhoz képest?
[quote:69b9c5846e="feledhetetlen"]2 ev windows-on valo fejlesztes utna sem tudott felrakni egy winzip-et a gepere..
Ez gyanús. Biztos azért nem, mert Linuxot használt. Bár akkor meg azért gyanús :wink:
[quote:e0ce78bbbb="bocs"][quote:e0ce78bbbb="lokoto"]Fordítsunk a helyzeten (kérem a szöveget nem kiragadni a környezetéből):
- a C++ filozófiája rosszabb, mint a Javáé, mert nincs benne reflection
- a C++ filozófiája rosszabb, mert nincs benne GC
- a C++ filozófiája rosszabb, mert nincsenek benne csomagok
csak azért válaszolok erre a hülyeségre, nehogy valaki azt gondolja, hogy így igaz, ahogy leírod.
reflection, GC megírható c++-ban, amit írtál? igen. C++ GC-re példa linket is adtam.
A c++ nyelv a power usereknek, ami szinte korlátlanul bővíthető, ha hozzáértő áll neki.
Ezzel szemben a Java: azt eszed amit eléd raknak... legfeljebb majd néhány év múlva mást is eléd raknak.
eszed, nem eszed, nem kapsz mást.
Igen, csak az már nem az alapnyelv / alaprendszer által nyújtott reflection, ergo elmondható, hogy a C++ filozófiája alapból nem támogatja. Ugyanez igaz a GC-re, és a csomagok elvére is (ez utóbbira gyanítom, hogy nem is fejleszthető semmi pótlás).
Tudtommal dinamikusan nem lehet osztályt betölteni C++ alatt, és még biztos sok más példát fel lehetne hozni, de nem látom értelmét, úgy tűnik nem fogtad fel a lista lényegét (tipp: el kellene olvasni, mi volt előtte).
Csodálom, hogy a Prologos kollégának még nem estetek neki, hogy a Prologban mi minden nincs és így milyen rossz ...
Vagy csak nem hallottatok még róla, nemhogy csináltatok is alatta valamit? :twisted:
Izomból biztos jobb programozni (lásd ArrayList példa...), mert bizonyos úgymond programozói fogásokat szerintem még egy JIT sem tud kioptimalizálni...
Hát nálam tökugyanaz az eredmény mindkét módszerrel, Eclipse és JProfiler-rel néztem.
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)
Badarság azt gondolni, hogy azért, mert nem volt szükség a helyre, de ha kell, akkor jön a GC és megeszi a szemetet?
[quote:3aacc184cd="_Joel"]
Nincs éspedig szándékosan nincs operator overloading. Ez egyike volt a "Java legyen egyszerubb, mint a C++" tervezesi elgondolasnak. Ez a vita időnként periodikusan előjön különféle helyeken, pl itt:
Hát ez az... pont azért kérdeztem hogy hogyan néz ki java-ban a dolog. Mert az X=Y -nál mi lehet egyszerűbb?... az ilyen dolgok (+ GC és társai) miatt is mondom én hogy nem komálom a java-t és a c++ -t jobbank tartom.
[quote:666f64221f="popacsek"]64-Bit Server VM
Khm, C++ is 64 bites kódot fordított (elsősorban pointerek hosszára gondolok)? Csak mert nem mindegy, CPU cache, meg egyéb hasonló low level szempontból sem...
Ajjaj, megint kezdődik...
Üdv!
A véleményem szerint a jövő mindenképpen a menedzselt programozási nyelveké (mármint általános feladatra).
Azon egyszerű oknál fogva h jóval biztonságosabb mint a régebbi nyelvek. Márpedig az internetes betörések jórésze buffer túlcsordulásos hiba miatt következik be.
Még pár év és több giga memória lesz a gépekben illetve még erősebb proci. Ilyen gépen remekül fognak futni a progik.
Nemrég írtam egy nagyobb lélegzetvételű progit. Javában. Nem bántam meg. Régebbi nyelvek valamelyikét használva a tesztelési és hibajavítási szakasz sokkal sokkal tovább tartott volna.
Volt olyan h visual c-ben web szervert írtam. Csak azért mert egy változót elfelejtettem lenullázni, 1 hétig szenvedtem mert a progi kiszámítatlanul fagyott.
Javában ill C#-ban ilyen nem lett volna.
A kedvelem a C#-ot (és a nyílt mono-t), de még fiatalka ,a javában sokkal több mindent megvalósítottak, így a java-ra szavaztam.
[quote:fb19ce7593="_Joel"]mustang.dev.java.net
Jó, de... de... de akkor ez meg azért nem jó, mert miért pont egy ló a logoja? :wink:
[quote:2abd22e7c2="lokoto"]Csodálom, hogy a Prologos kollégának még nem estetek neki, hogy a Prologban mi minden nincs és így milyen rossz ...
Vagy csak nem hallottatok még róla, nemhogy csináltatok is alatta valamit?
Prologból írtam a diplomamunkám, azzal foglalkoztam előtte 1-2 évig.
Konklúzióm: nagy hűhó semmiért.
Tudományos szempontból biztos érdekes, mérnöki szempontból katasztrófa.
De a személyeskedő hozzászólásokat nyugodtan elhagyhatod, mert könnyen be lehet bukni velük.
[quote:d0f62537c9="Frimen"]Itt nem TCP-ről van szó, és nem is az alkalmazás szintű protokollrol, hanem arról, hogy egy "driver", legyen az java estében jdbc, rmi milyen teljesitmenyre képes, mennyit "tud".
Szerintem ket kulon dologrol beszelunk. Egy JDBC driver az valami gyartofuggo dolog. Irhatok en MySQL-hez JDBC drivert es hasznalhatom az oaltaluk keszitett drivert, ket kulonbozo meresi eredmenyt kapok, mivel az implementaciom kulonbozo. Egy Javas DB drivert szinten csak ugy van ertelme osszehasonlitani egy C++-os driverrel, hogyha ugyanolyan az implementacio, maskeppen nem tudsz korrekt sebessegadatot merni. Almat az almaval, kortet a kortevel, de ne keverjuk oket.
Ugyanez vonatkozik pl. az RMI-re. Ha implementalsz RMI-t C++-ban, akkor ossze lehet hasonlitani a ket implementacio sebesseget, de az meg mindig nem a Java C++ osszehasonlitas, hanem egy adott dolog ket nyelven torteno implementaciojanak osszehasonlitasa. Es meg veletlenul se mondjuk azt, hogy a Java es a C rmi ugyanaz, mert utobbi ha jol tudom nem hozza at az exceptionoket.
[quote:d0f62537c9="Frimen"]Nem foglalkoztam soha azzal, hogy teljesitmény teszteket kutassak fel.:)
Nem is kertelek erre, csupan arra, hogy olyan osszehasonlitasi modot mondj, ami tenyleg realisan a platformokat meri, es nem alma-korte implementaciokat. Ha mondasz ilyent, mi implementaljuk, kimerjuk, elmondjuk az eredmenyeket.
[quote:d0f62537c9="Frimen"]Nincs érteleme.. ezt bizonyitja több tucatnyi program.
Egy C-ben irt GUI-s program sokszor nagyságrendekkel gyorsabb mint egy java-ban irt program.
Ugy erted, hogy "jajj gyorsabb a nativ program mint a Swing sajat komponensei"? Mert ebben igazad van, de lehet Javaban is nativ komponensekbol epitekezni: AWT. Hozzateszem, hogy a 6-os Javaban mar a Swing is nativ komponensekbol rajzolodik ki.
[quote:68a351ebf3="maszili"]c++ -ban pofon egyszerűen megoldható és így valóban teljesűl az OO szemlélet és még a kód is egyszerű és átlátható.
Na, kicsit durva kijelenteni a C++-ról, hogy valóban teljesíti az OO szemléletet, amikor a többalakúság csak mutatókon keresztül érhető el, a függvényeknél meg meg kell mondani, hogy virtuálisak-e... gyakorlatilag hatékonysági megfontolásokból egy csomó öszvér megoldás van benne.
[quote:68a351ebf3="maszili"]X = Y ;
Nincsenek pionterek, referenciák, nincsen memory leak, stb... nem kell tudnom semmit az objektumok működéséről (OO).
Nincs memory leak, HA jól írták meg... és ránézésre nem látszik, hogy milyen kód fut le... ez is csak egy lehetőség, amit a nyelv biztosít, de ésszel kell használni.
KisKresz
[quote:859a629b55="_Joel"][quote:859a629b55="popacsek"]64-Bit Server VM
Khm, C++ is 64 bites kódot fordított (elsősorban pointerek hosszára gondolok)?
Igen 64bitest (nem tud mást). De kipróbáltam 32bites környezetben is (athlon-xp), az eredmények arányaiban nem térnek el.
Ismerős dolog. A menedzsment mindig jobban tudja, hogy mi a jó, mint a programozók. Volt szerencsém hozzá. A Telelogic kifejlesztett egy SDL nyelvet, amely kiválóan alkalmas volt protokollok megvalósítására (legalábbis a marketing szöveg szerint).
Mi programozók az első kanyarban mondtuk, hogy C++, mert as SDL-lel eszméletlen sok szívás lesz. A válasz az volt, hogy azért mondjuk ezt, mert nem ismerjük az SDL-t. Szóval fele akkora fejlesztési sebességgel SDL-ben írtuk meg a protokollt. Az SDL egyébként C++ kódot generált, de ez igazi generált kód volt ám, a zb435349857frbdc234 egy tipikus változónév volt.
Aztán eljött az igazság órája. Az SDL-t nem lehetett karban tartani és hihetetlen sok misztikus hiba volt benne. Ígyhát olyan döntés született, hogy átírhatom végre C++-ba.
A fél éves munkát 1 hét alatt átírtam, még 1 hét tesztelés, aztán jött egy teljesítmény mérés. A Telelogic csoda kihajítása megháromszorozta a protokoll teljesítményét.
Szerintem a programozó jobban tudja, mint a nyelvész zseni...
[quote:0120c56b39="KisKresz"]gyakorlatilag hatékonysági megfontolásokból egy csomó öszvér megoldás van benneKisKresz
hálisten
ezért zabál közel annyi memóriát mint elvárható
ezért egy 2x méretű adatstruktúra másolása jól bevcsülhetően 2x annyi ideig tart, nem pedi 5x annyi ideig ki tudja miért stb
power tool for power users
aminek persze egyenes következménye, hogy könnyebb magad tökön bökni vele. de amikor ki kell facsarni a teljesítményt a gépből - igen, ilyen is van ;) akkor ez kell.
[quote:336ef6dd9a="syntern"]Kíváncsian várom a C++ reflectionre vonatkozó linket.
próbáltad már a google-t? írd be "c++ reflection"
[quote:336ef6dd9a="syntern"]Ahogyan kíváncsian várom a C++ többgenerációs (= nem referencia counter) GC-re is a linket.
bocsánat, lehet írni ilyet c++-ban? Bármilyet lehet, ami a programozónak tetszik. semmi akadályát nem látom - feltételezem a JVM-beli sem java-ban írták.
[quote:336ef6dd9a="syntern"]Valamint arra is kíváncsian várom a választ, hogy a Java miért nem szinte korlátlanul bővíthető.
feladathoz illesztett, saját kódolású template-es konténerek, amelyek minden típusnál optimális gépi kódra lesznek fordítva, szemben a Java gyakorlatilag parasztvakítás szintű Generics/template támogatásával ? /hiszen maga a SUN írja le, hogy a Java Generics-ből fordítás után eltűnik a típus információ... :(/
egyébként a fórumban írtam már kérdést egybefüggő memóriaterület feldarabolására Java-ban. Ez egyszerűen megoldhatatlan, mert kifelejtették a _nyelvből_ a reallocot. Nincs, nem lesz, nem tudod megvalósítani, mert a sun mérnökei így döntöttek.
Na ilyen nincs a c++-ban: ha a feladat megoldható, meg tudod benne oldani.
Érdekes, hogy a PHP scripting language, mint "programozási nyelv" van jelen és az is érdekes, hogy most (2005. nov. 21. 0:20) vezet a többi konvencionális programozási nyelvhez képest...
IMHO, tekinthető a PHP programozási nyelvnek abból a szempontból, hogy algoritmusokat lehet vele leírni és ezeket (egy interpreteren keresztül) futtatni. Ugyanakkor az is igaz, hogy a PHP egy script nyelv és kizárólag a dinamikus webes tartalmak megjelenítéséhez fejlesztették, ennélfogva a programozói feladatoknak csak egy leszűkített halmaza oldható meg vele. Pl. C, C++ vagy Java nyelvekkel lehet készíteni interaktív és hardvereszközökkel is kommunikáló, GUI frontendet is és dinamikusan generált webes felületet is, de PHP-vel csak ez utóbbit.
Nem tudom, mi a "programozási nyelv" pontos definíciója, de IMHO egy programozási nyelvnek általános érvényű (és nem egy specializált) eszköznek kellene lennie, legyen szó bármilyen szoftverfejlesztési feladat megoldásáról.
- waiter -
[quote:260fb4293f="drojid"]Hát nálam tökugyanaz az eredmény mindkét módszerrel, Eclipse és JProfiler-rel néztem.
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)
Badarság azt gondolni, hogy azért, mert nem volt szükség a helyre, de ha kell, akkor jön a GC és megeszi a szemetet?
Akkor pasz.. a t*k*m ki van a java-val kliens oldalon.
Most akkor mit higgyen az ember? Nekem Netbeans + Profiler az első esetben
"azonnali takaritás" van, a másik esetben meg szemét marad ott.. igy értettem a különbséget.
Passz.. ez a Sun rosszabb mint a M$.
Fri
[quote:088b38d6e2="bocs"]elmélet, elmélet, elmélet....
a gyakorlat meg a fenti freewebs.com-os linken olvasható: a c++ sokszor 2x gyorsabb, néha 4x. ennyi.
En is nagyon szeretem a gyakorlatot. Pont azert mertuk ki. Kivancsian varom, hogy mas architekturan, mas kornyezetben milyen meresi adatokat kaptok.
[quote:c84d063619="aperger"]Nem értem a hozzászólásod! Nem logikus, Miért?
Számomra nem az. Úgysem tudom precízen megfogalmazni, viszont nem díjazom, ha olyat állítanak, hogy én mondtam vmit, amikor más.
C#-ot sem szeretem, pedig abban tényleg tudok programozni gond nélkül (feltéve ha az osztály- és függvényneveket ismerem :)). Ízlések és pofonok.
Optimalis gepi kod ;-))) Hat persze! Szerinted ha minden tipushoz van tipusspecifikus kod, akkor optimalis lesz? Ki kell abranditsalak.
Az elet bonyolult, de a processzorok es a forditoprogramok is meglehetosen bonyolultra sikeredtek.
Olvasnivalo: Hans-J. Boehm: Threads Cannot be Implemented as a Library
Kedves Andrej.
A referencia számlálós memóriakezelés működne.
Sajnos neked nincs fogalmad sem a java működéséről.
Az i++, i-- szerinted mit csinál multi threades környezetben?
Tökéletesen viselkedik, ugyanis a primitív típusok automatikusan szinkronizálva vannak java-ban. Ezt jó tudni.
Ha egy mezei i++ nem jelent komoly problémát skálázási szempontból, a referencia számlálás sem lesz problémás.
Tudom, hogy hiper advanced java guru vagy, de azért ne hidd azt, hogy a világon mindent te tudsz a legjobban...
[quote:ca847ad0c8="handler"]Optimalis gepi kod ;-))) Hat persze! Szerinted ha minden tipushoz van tipusspecifikus kod, akkor optimalis lesz? Ki kell abranditsalak.
megmagyaráznád, mi lehet optimálisabb egy optimalizált tároló, hozzá optimalizált típus párosnál?
a cikket pedig köszönöm a nép nevében, olvasom!
[quote:0a30b6b214="popacsek"][quote:0a30b6b214="_Joel"][quote:0a30b6b214="popacsek"]64-Bit Server VM
Khm, C++ is 64 bites kódot fordított (elsősorban pointerek hosszára gondolok)?
Igen 64bitest (nem tud mást). De kipróbáltam 32bites környezetben is (athlon-xp), az eredmények arányaiban nem térnek el.
De az is csontra optimalizált környezet, nem?
[quote:47aefab881="syntern"]
Szerintem ket kulon dologrol beszelunk.
..
Nem is kertelek erre, csupan arra, hogy olyan osszehasonlitasi modot mondj, ami tenyleg realisan a platformokat meri, es nem alma-korte implementaciokat. Ha mondasz ilyent, mi implementaljuk, kimerjuk, elmondjuk az eredmenyeket.
Ebben egyetértünk, mert nem tudom miről beszélsz.
Implementációk, utópisztikus összehasonlitási "elvekről".. ez mind mind kamu,
mellébeszélés.
Összehasonlitást Te is ki tudsz találni.. nem kell hozzá sok ész: fogsz x java-s, x c-s programozot, kitalasz egy egyszerű feladatot: adatkihozás adatbázisbol, kiirás fájlba.
Erre megint mondhatod: "hát de igy meg ugy implementáció".. erre én meg azt mondanám: ki nem tesz rá magasról.. a "felhasználó" ha valós helyzetről van szó
magasról tesz az implementációra.
Ez hasonlit arra, mikor a nomrál formákat tanitják ami szép elmélet, valóságban
azonban az embernek igazodnia kell és a cél érdekében tenni az "elvekre", ha kell.
[quote:47aefab881="syntern"]
Ugy erted, hogy "jajj gyorsabb a nativ program mint a Swing sajat komponensei"? Mert ebben igazad van, de lehet Javaban is nativ komponensekbol epitekezni: AWT. Hozzateszem, hogy a 6-os Javaban mar a Swing is nativ komponensekbol rajzolodik ki.
AWT: Javits ki ha tevedek, de meg nem a standard sun-os java része még, valamint
nem fut el minden.
6-os Java: persze.. majd.. egyszer.. ha kijön, de hol van az még!:)
Fri
[quote:4b513bf37f="bocs"][quote:4b513bf37f="syntern"]Kíváncsian várom a C++ reflectionre vonatkozó linket.
próbáltad már a google-t? írd be "c++ reflection"
Kipróbáltam. Nem találtam olyan linket, ahol egy általam írt és fordított C++ libraryt valaki más csak úgy reflection-nel fel tudott volna deríteni, anélkül, hogy erre én előre felkészülnék. (Tfh, hogy én csak egy objektum-mutatót adok át paraméternek valahova.) Nagyon okosan bevezetik a Javahoz nagyon hasonló osztály-hierarchiát, mindenki örököljön csak az Objectből, de innentől kezdve a másik félnek is ismernie és kezelnie kell ezt az Objectet.
Azaz ami nincs: nem befolyásolt forrásból származó kód reflection kezelése.
bocsánat, lehet írni ilyet c++-ban? Bármilyet lehet, ami a programozónak tetszik. semmi akadályát nem látom - feltételezem a JVM-beli sem java-ban írták.
Továbbra is ami hiányzik: nem befolyásolt forrásból származó kód GC kezelése. Ha minden kódod memóriáját te kezeled, akkor persze, megoldható, de rögtön borul az egész, ha nem csak a saját kódodért felelsz.
feladathoz illesztett, saját kódolású template-es konténerek, amelyek minden típusnál optimális gépi kódra lesznek fordítva, szemben a Java gyakorlatilag parasztvakítás szintű Generics/template támogatásával ? /hiszen maga a SUN írja le, hogy a Java Generics-ből fordítás után eltűnik a típus információ... :(/
Ez most bővíthetőségi vagy optimalizációs kérdés? Logikailag megoldod ugyanúgy a feladatot, és mindkét esetben a környezetre bízod az implementációt.
:) Ez jó. Meg tudod oldani azt C++-ban, hogy egy feldarabolt memóriaterületet összenyomj, hogy a sok kis memória összesen egy nagyot tegyen ki? Persze, elméletileg megoldható lehet (pedig nem, lásd: nem befolyásolt forrásból származó kód), a Java meg is oldja.
Nálam mindkét esetben egyformán működik, vagy azonnal takarít, vagy nem, amikor kedve van. (Illetve gondolom ennél kézzelfoghatóbb a működése, de nem látok bele, mi alapján dönt.)
Én nem temetném azért a Java-t, bár én csak SE-t és ME-t használok, EE-t nem, de szeretem. Kézre áll, könnyű vele haladni, az ésszel kódolást pedig semmi nem váltja ki.
Nem akartam eddig beleszólni, mert nem vagyok nagy szoftverfejlesztő guru. Azt el szeretném mégis mondani, hogy a szemléletem asm és c alapokon, beágyazott rendszereken cseperedett, szeretni szoktam a kicsi és gyors programokat. Régebben csőlátással tekintettem erre a kérdésre, például adatbáziskezelőt írtam assemblyben, ezt ma már bevallani is csak pironkodva merem :) Én azt látom, hogy azokra a feladatokra, amikkel találkoztam mostanában, a java nagyon jó kis eszköz desktopon. Nekem az is jó, ha számlázót írok linuxon, és az pont ugyanúgy működik és ugyanúgy néz ki vindóz alatt is, bár ez ma a MS tulajdonképpeni egyeduralma miatt még nem olyan óriási jelentőségű.
Szívesen írnék MCU-ra is java VM-et, meg alkalmazást, de azt már csak azért, mert érdekes, mókás feladat. Ha valami RT alkalmazás kell rá, akkor nyilván nem Javaznék rajta, hanem eldobnám a szoftveres CNC-met és elővenném a szoftvervésőm és szoftverreszelőm, és asm-c-ben csinálnám, mert oda az a jobb.
És még valami: akár überkirály a java, akár nem, divatos, sok helyen erőltetik, a Sun is nő, meg kell tanulni, ismerni kell, és kész. (Ráadásul még szeretem is :) )
Na most jól megmondtam a frankót :wink:
[quote:5e89921048="hanischz"]Még pár év és több giga memória lesz a gépekben illetve még erősebb proci. Ilyen gépen remekül fognak futni a progik.
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
[quote:5e89921048="hanischz"]Volt olyan h visual c-ben web szervert írtam. Csak azért mert egy változót elfelejtettem lenullázni, 1 hétig szenvedtem mert a progi kiszámítatlanul fagyott.
Javában ill C#-ban ilyen nem lett volna.
Szerintem akármelyik programnyelvről is legyen szó, programozni tudni kell.
[quote:7870d08474="drojid"][quote:7870d08474="_Joel"]mustang.dev.java.net
Jó, de... de... de akkor ez meg azért nem jó, mert miért pont egy ló a logoja? :wink:
Hmm, még idáig ez volt a legelfogadhatóbb ellenérv az elmúlt néhány tucat hozzászólás között:))
[quote:df5ffc146b="maszili"][quote:df5ffc146b="_Joel"]
Nincs éspedig szándékosan nincs operator overloading. Ez egyike volt a "Java legyen egyszerubb, mint a C++" tervezesi elgondolasnak. Ez a vita időnként periodikusan előjön különféle helyeken, pl itt:
Hát ez az... pont azért kérdeztem hogy hogyan néz ki java-ban a dolog. Mert az X=Y -nál mi lehet egyszerűbb?... az ilyen dolgok (+ GC és társai) miatt is mondom én hogy nem komálom a java-t és a c++ -t jobbank tartom.
a getc() is egyszerunek tunik
egeszen addig amig egyszer meg nem nezed a windows.h-ban mi is az valojaban
az X=Y es tarsaik olyan makrok amiket a programozok is megirhatnak
vagyis mikor olvasod, fogalmad nincs rola, hogy mi tortenik valojaban,
csak ha megnezed a X assigment operator kodot
Javaban is vannak makrok, pl:
String a = "first "+"letter";
DE! ezek pontosan (megtanulhatoan) le vannak irva a nyelvszabvanyba, hogy mire kell forditani.
Ha ezt:
[code:1:df5ffc146b]String a = "first "+"letter";[/code:1:df5ffc146b]
latom egy Java kodban, tudom mi tortenik.
Az X=Y eseten max akkor, ha en irtam es meg emlexem is ra.
Ezzel viszajutunk ahhoz:
A Javat azert szeretjuk, mert tudjuk mi az: 1 (egy) nyelv szabvany.
Igenis a logikus epitkezeshez aximomak kellenek!
Ellentmodasmentes, egyertelmu stb...
[quote:487c671973="Frimen"]6-os Java: persze.. majd.. egyszer.. ha kijön, de hol van az még!:)
Én nemrég próbáltam Mustang-ot, tök jó, bár van egy halom (szerintem) felesleges fícsör benne. Inkább az a baj, hogy most is nehéz azt mondani a juzernek, hogy de igenis tessék 5.0-t telepíteni, ha használni akarod a programomat, mert desktopon szerintem még most is jóval több 1.4 jre van, mint 5.0...
[quote:21c46f8cf6="Frimen"]Implementációk, utópisztikus összehasonlitási "elvekről".. ez mind mind kamu, mellébeszélés. Összehasonlitást Te is ki tudsz találni.. nem kell hozzá sok ész: fogsz x java-s, x c-s programozot, kitalasz egy egyszerű feladatot: adatkihozás adatbázisbol, kiirás fájlba. Erre megint mondhatod: "hát de igy meg ugy implementáció".. erre én meg azt mondanám: ki nem tesz rá magasról.. a "felhasználó" ha valós helyzetről van szó magasról tesz az implementációra. Ez hasonlit arra, mikor a nomrál formákat tanitják ami szép elmélet, valóságban azonban az embernek igazodnia kell és a cél érdekében tenni az "elvekre", ha kell.
Adj szabad kezet tetszoleges feladat implementaciojara, mondj egy eredmenyt, amit latni szeretnel, es kihozom. Nem veletlen a sok pl. Linux-Windows osszehasonlitasban kijovo eszmeletlen kulonbseg: ha akarom, tudom ugy alakitani, tudom ugy implementalni. hogy a C++ lassabb legyen. Ennyit a kamuzasrol.
[quote:21c46f8cf6="Frimen"][quote:21c46f8cf6="syntern"]Ugy erted, hogy "jajj gyorsabb a nativ program mint a Swing sajat komponensei"? Mert ebben igazad van, de lehet Javaban is nativ komponensekbol epitekezni: AWT. Hozzateszem, hogy a 6-os Javaban mar a Swing is nativ komponensekbol rajzolodik ki.
AWT: Javits ki ha tevedek, de meg nem a standard sun-os java része még, valamint nem fut el minden.
Kijavitalak: Te az SWT-re gondoltal, en meg a Java eleg regota alkalmazott awt-jere: http://java.sun.com/developer/onlineTraining/awt/contents.html
[quote:21c46f8cf6="Frimen"]6-os Java: persze.. majd.. egyszer.. ha kijön, de hol van az még!:)
Felfoghatod ugy is, hogy kijott. Mi mar kiprobaltuk, mertuk, gyorsabb, mint az 5-os :)
[quote:eb5a15569f="Csab"]
A referencia számlálós memóriakezelés működne.
Komoly szaklapokban komoly publikációk vannak arról, hogy miért jobb és skálázhatóbb a többgenerációs memóriafelosztás, a mark&sweep vagy a stop© megfelelő alkalmazása a referencia számlálásnál.
Andrei tudtommal nem Java guru, csak egy értelmes ember (legalábbis az itteni meg a hwsw-s megnyilvánulásai alapján:).
[quote:eb5a15569f="Maszili"]
Hát ez az... pont azért kérdeztem hogy hogyan néz ki java-ban a dolog.
[code:1:eb5a15569f]
Integer x = 5;
Integer y;
y = x;
[/code:1:eb5a15569f]
x és y referenciák, nem önálló objektumok. Ami értékadásnak látszik, az referencia szerinti értékadás, vagyis a memóriában egyetlen Integer objektumod lesz, amire két referencia is mutat (ha egy másik objektumot akarsz másolva létrehozni az az y = x.clone(); művelet lenne).
[quote:52f41fd394="feledhetetlen"]az interpretalas a nyelvszabvany koveto stilusban IEEE float muveletek hajt vegre
aztan a kod persze fut tovabb (8-10 perc egy 700Mhz PIII-on)
ekkor fogja magat a hotspot es nativ forditja a szamitasokat
ezek a szamitasok persze mar intel FPU muveletekke valnak
ezek eredmenya nem egyezik az IEEE szabvannyal leven nehany bittel pontosabb...(
nekünk volt hasonló eredményünk c++-ra, az többnyire azért volt, mert a fordító jól optimalizált.
Ekkor a kód nem vette ki a küzbülső számítási eredményt a 10 byte-os long double-s FPU stack-ből, és töltötte be ideiglenesen 8 byte-os double változóba, majd azt vissza az FPU-ba, hanem az FPU stack-en hagyott értékkel azonnal tovább számolt.
ja +1 érv a c++ mellett: hardverig le tudod debuggolni (tudom, a javas nem debuggol, hanem elolvassa a szabványt... ;) ).
[quote:07f91ce3b3="_Joel"]Valaki űrtechnológiával dobálózott:
http://www.sun.com/aboutsun/media/features/mars.html
http://www.java.com/en/everywhere/marsrover.jsp
Valaki meg bankokkal. Elárulom, hogy tapasztalataim szerint egyetlen egy olyan hazai szektor van, ami az államigazgatás informatikai sötétségével összemérhető gányolásokat alkot: a bankszektor. Néhol látszanak kivételek, de az összkép lesújtó. Telco-ban határozottan jó dolgozni, ott valahogy normálisabb a technológiai légkör.
(tessék megnézni java lista archívumát: pont múlt héten volt egy jsp-s kérdés, aholis a bank előírta, hogy minden kódnak a jsp-ben kell lennie... erre szokás azt mondani, hogy clueless).
Joel ne legyel write-only! Azt irtam, hogy az ertelmesebb hi-tech szektorok fele a Java jelentosege egyre csokken (mig a bankargyerek a 32 procis Sun vason szive szerint meg az oprendszert is jsp-ben kepzelne el). Tudom, hogy a Marsjarokban fut egy nagy rakas Java kod, de ez is lehet az egyik ok, amiert annyira sok problema van veluk. Javaslom attanulmanyozasra a Voyager 1-2 szondak technikai bravurjait es ra kell jonni, hogy azok is kepesek ezen a szinten mukodni (Fortran + Assembly kodokkal).
De meg senki nem volt konstruktiv, es nem mutatott nekem eddig egy frappans, hatekony, jol hasznalhato desktop Java alkalmazast (Matlab nem er :) ), ami bizonyitana szamomra, hogy mennyivel tobbet ad ez a nyelv es ez a platform (bocsanat ez a Nyelv es ez a Platform), mint barmi mas.
Andrei
[quote:28b8e80983="KisKresz"]Na, kicsit durva kijelenteni a C++-ról, hogy valóban teljesíti az OO szemléletet, amikor a többalakúság csak mutatókon keresztül érhető el, a függvényeknél meg meg kell mondani, hogy virtuálisak-e... gyakorlatilag hatékonysági megfontolásokból egy csomó öszvér megoldás van benne.
A c++ már csak ilyen... sok helyen használatosak a mutatók...
[quote:28b8e80983="KisKresz"]
Nincs memory leak, HA jól írták meg... és ránézésre nem látszik, hogy milyen kód fut le...
Pont ez a lényege az OO-nak. Nem tudom hogy hogyan működik és nem is kell tudnom hogy hogyan működik.
Azért pl. a STL-t valószínüleg jól írták meg :)
[quote:28b8e80983="KisKresz"]
ez is csak egy lehetőség, amit a nyelv biztosít, de ésszel kell használni.
Ezt nem értem... milyen lehetőség?
Egyébként meg pont arról folyik a beszélgetés hogy a két nyelv a java és c++ milyen lehetőségeket ad a helyes kód megírásához.
Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
GC C++ alatt ügyben innen érdemes indulni. Egy érdekes idézet valamelyik lapról:
Tehát a C++-ban rád bízzák, hogy mit csinálsz. Ez lehet előny és hátrány is. :)
[quote:f4bc7e87a7="syntern"]Kiemelem a dupla heap méretet, mert a többi már korábban meg lett cáfolva
ezért volt ott a "vagy" - hogy milyen plusz erőforrást igényel, az a GC collection algoritmustól függ.
Értem én, hogy elméletileg nincs szükség nagyobb heap-re ;), ezzel szemben meg ott van a fórumban az általam végzett mérés, ahol a ténylegesen szükségesnél 3x-4x több memória kellett a Javas példaprogramnak. A memóriazabálás teljesen általános tapasztalat. Van ahol ez kizárja a Java-t, például az én munkakörömben is.
A SUN oldalain is úgy írják: a GC tipikusan +15% prociidőt jelent. A memóriafoglalási többletet nem is merik odaírni.
A GC ismertetésénél pedig a Sun oldalain is így írják: "mindenhol jó, kivéve a most demanding alkalmazásokat".
Erről beszéltem, én pl ilyenekkel dolgozom, tehát néhol a GC prohibitív.
Néha ugyan lehet, hogy csakis GC-vel célszerű megoldani a dolgot.
[quote:a238181100="feledhetetlen"]
...az X=Y es tarsaik olyan makrok amiket a programozok is megirhatnak...
Szerintem itt valami félreértés van... én nem makrókról beszélek hanem rendes értékadó operátor megírásáról. Az nem makró hanem az osztály része.
[quote:a238181100="feledhetetlen"]
vagyis mikor olvasod, fogalmad nincs rola, hogy mi tortenik valojaban,
csak ha megnezed a X assigment operator kodot
Ezt hívják OO-nak... :) nem érdekel hogy belül hogyan működik...
[quote:28b379764f="syntern"][quote:28b379764f="popacsek"][quote:28b379764f="_Joel"][quote:28b379764f="popacsek"]64-Bit Server VM
Khm, C++ is 64 bites kódot fordított (elsősorban pointerek hosszára gondolok)?
Igen 64bitest (nem tud mást). De kipróbáltam 32bites környezetben is (athlon-xp), az eredmények arányaiban nem térnek el.
De az is csontra optimalizált környezet, nem?
CFLAGS="-O2 -march=athlon-xp -pipe"
Ja megvalami. A Java uberalles dolgait nem biztos, hogy a Sun oldalairol idecibalt tanulmanyokkal kellene megerositeni. A mosoporrol sem ugy vitatkoznank, hogy idelinkeljuk a reklamot, amiben kiviszi a porkoltszaftos fufoltot. :) :)
Andrei
[quote:289e2b45dc="Csab"]- Sosem fogsz 2D / 3D motort írni java alatt
Ezt már linkelték előttem, de van több is.
[quote:289e2b45dc="Csab"]- Nem fogsz videót, DVD-t nézni java alatt
Java to be Used in Blu-ray DVD Players
Mellesleg azért ez marhára érdekelne, hogy írhatunk e majd Java progit pl.: PS3-ra? :o
[quote:289e2b45dc="Csab"]- Nem fogsz tudni megírni mondjuk egy TCP/IP stacket java-ban a misztikus késleltetések miatt (pl. Garbage Collection).
A JNode-ban azért már lehet, hogy megpróbálták.
[quote:289e2b45dc="Csab"]- A kriptográfiai erőforrás zabáló algoritmusokról nem is beszélve
java.security, javax.crypto standard csomagok. A legtöbbhöz még stream támogatás is van.
[quote:1e95f1037e="_Joel"]
[code:1:1e95f1037e]
Integer x = 5;
Integer y;
y = x;
[/code:1:1e95f1037e]
Ezt ugye viccnek szántad? :)
Én olyan objektumokról beszélek amelyek NEM elemi adatszerkezetek, hanem azoknál sokkal bonyolultabb, sokkal összetettebb a programozó által kitalált (esetleg más bonyolult és elemi adatszerkezetekból felépített) adatstuktúra. Ami ráadásul zárt (OO) és fogalmam sincs hogy mi van benne...
Na akkor hogy néz ki pl. az értékadás?
[quote:d9f39bf062="Andrei"]
De meg senki nem volt konstruktiv, es nem mutatott nekem eddig egy frappans, hatekony, jol hasznalhato desktop Java alkalmazast (Matlab nem er :) ), ami bizonyitana szamomra, hogy mennyivel tobbet ad ez a nyelv es ez a platform (bocsanat ez a Nyelv es ez a Platform), mint barmi mas.
Nem akartam write only lenni (bar a kollega "hibajavitas" felkialtasa a garbage collection-re kisse kihoz a sodrombol - miert kell egy masfajta paradigmat egybol lekezeloen, alsobbrendunek tekinteni, holott komoly tudomanyos kutatasok, publikaciok bizonyitjak a hasznossagat es hatekonysagat marginalisnak nem tekintheto esetkben is - tudom, a kutatas elefantcsoronytornya is nagyon messze van a gyakorlati alkalmazasoktol).
Azt meg foleg nem akarom az egeszbol kihozni, hogy a Nyelv és Platform tobbet erne, mint barmi mas. Csak azt probalom bizonygatni, hogy er ugyanannyit. Igen, a Java programok memoriaigenye nagyobb, mint a C++ programoke, amiknek meg megintcsak nagyobb a memoriaigenye, mint a C programoke, amiknek meg nagyobb a memoriaigenye, mint az assembly programoke. Igen, a jelenlegi stabil (1.5)-os JVM nem teljesen desktop friendly. A Mustang build-eket ha kiprobalja valaki, latni fogja, hogy ez eroteljesen valtozoban van.
Igy ok?
[quote:938bdee379="Csab"]Kedves Andrej.
A referencia számlálós memóriakezelés működne.
Sajnos neked nincs fogalmad sem a java működéséről.
Az i++, i-- szerinted mit csinál multi threades környezetben?
Tökéletesen viselkedik, ugyanis a primitív típusok automatikusan szinkronizálva vannak java-ban. Ezt jó tudni.
jo tudni:
a long, double tipusok irasa (a nyelvszabvany szerint) elvegezheto 2 (ketto) elemi lepesben:
http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7
nyelvszabvany, nyelvszabvany, nyelvszabvany...
[quote:dd2b155cf7="Csab"]
Ismerős dolog. A menedzsment mindig jobban tudja, hogy mi a jó, mint a programozók. Volt szerencsém hozzá. A Telelogic kifejlesztett egy SDL nyelvet, amely kiválóan alkalmas volt protokollok megvalósítására (legalábbis a marketing szöveg szerint).
Mi programozók ....
...
Szerintem a programozó jobban tudja, mint a nyelvész zseni...
szerintem meg fele ekkora onbizalommal egy jobbankepzett hentes mar veheti is torakotomias talcat..
[quote:bf7ff18c4a="Andrei"]Ja megvalami. A Java uberalles dolgait nem biztos, hogy a Sun oldalairol idecibalt tanulmanyokkal kellene megerositeni. A mosoporrol sem ugy vitatkoznank, hogy idelinkeljuk a reklamot, amiben kiviszi a porkoltszaftos fufoltot. :) :)
Sun-nak semmi köze nem volt ahhoz, hogy a NASA java-ban irta meg a vezerloszoftvert. Utolag felkaptak a marketingesek.
Ezt lattad: http://javapathfinder.sourceforge.net/ ?
"What is Java PathFinder
The answer used to be simple: "JPF is an explicit state software model checker for Java bytecode". Today, JPF is a swiss army knife for all sort of runtime based verification purposes.
If you are not familiar with formal methods, this basically means JPF is a Java virtual machine that executes your program not just once (like a normal VM), but theoretically in all possible ways, checking for property violations like deadlocks or unhandled exceptions along all potential execution paths. If it finds an error, JPF reports the whole execution that leads to it. Unlike a normal debugger, JPF keeps track of every step how it got to the defect.
JPF is a pure Java application that can be run either as a standalone command line tool, or embedded into systems like development environments. It was mostly developed - and is still used - at the NASA Ames Research Center. Started in 1999 as a feasibility study for software model checking, JPF has found its way into academia and industry, and has even helped detect defects in real spacecraft."
[quote:04be588d6e="drojid"][quote:04be588d6e="_Joel"]mustang.dev.java.net
Jó, de... de... de akkor ez meg azért nem jó, mert miért pont egy ló a logoja? :wink:
Gondolom akkor az Anjuta-t se szereted. :wink:
[quote:5c22cd13a6="bocs"]
ja +1 érv a c++ mellett: hardverig le tudod debuggolni (tudom, a javas nem debuggol, hanem elolvassa a szabványt... ;) ).
a szabvany nem a debug helyett van
a dolog kicsit forditott: azert van java mert van JLS
amugy meg mindig varok az 'en nagyonis ertem a java-t es elmondom miert gyenge' csoportbol a valaszt arra kerdesre mit csinal a
[code:1:5c22cd13a6]synchronized( this ) { }[/code:1:5c22cd13a6]
a 'hat semmit' valasz eseten arra,
hogy miert nem szedi ki a fordito ?
ha javap-pal megnezed benne kell lennie...
Jaj most itt rossz színben tűnök fel, pedig én is a java-t szeretem és Mustang van fent. Bár most meg a C++ oldal utál, szal mexívtam így is, úgy is :-)
A lovassal pedig csak arra céloztam, hogy írhatunk bármit, linkelhetünk projecteket, írhatunk konkrét mérési eredményeket, hogy a java igenis jó, mindig lesz valami, ami miatt fújhatnak rá, hogy márpedig akkor sem az... :-)
[quote:6da3561daf="maszili"]
Na akkor hogy néz ki pl. az értékadás?
Két azonos típusú objektum között ugyanígy. Új objektum esetén meg a megfelelő konstruktorral.
[code:1:6da3561daf]
Person p = new Person("Gipsz", "Jakab", 32, "programozó");
Person q;
q = p;
q.setLastName("Józsi");
assert p.getLastName == "Józsi";
q = p.clone();
q.setLastName("Jakab");
assert p.getLastName == "Józsi";
[/code:1:6da3561daf]
Az = Java-ban referenciát másol. Teccik érteni?
Mondjuk a clone() jó működéséhez (property osztályokat ne csak másolja, hanem új példányokat hozzon létre azokból is) a clone()-t felül kell definiálnod ezekben az összetett adattípusokban, de C++-ban is neked kell megírni a másolást végző kódot.
[quote:3ccaeede40="drojid"][quote:3ccaeede40="feledhetetlen"]2 ev windows-on valo fejlesztes utna sem tudott felrakni egy winzip-et a gepere..
Ez gyanús. Biztos azért nem, mert Linuxot használt. Bár akkor meg azért gyanús :wink:
solaris volt elotte
mara mar megtanulta windows-t is hasznalni, most meg arrol nem lehet lerobbantani
[quote:494b9e30f3="hanischz"]Még pár év és több giga memória lesz a gépekben illetve még erősebb proci. Ilyen gépen remekül fognak futni a progik.
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
A masik, hogy enyhen szuklatokuruseg a dolgok jelen allapotaban a szoftverfejlesztest kizarolag PC-s (ertsd: szemelyi szamitogepes) kornyezetre vonatkoztatni. Ugyanis meglehetosen nagy szamu beagyazott eszkoz van korulottunk, amiket mar joreszt szinten magasszintu nyelveken (nagytobbsegeben C-ben) programoznak.
[quote:cdfbca5ffc="maszili"][quote:cdfbca5ffc="feledhetetlen"]
...az X=Y es tarsaik olyan makrok amiket a programozok is megirhatnak...
Szerintem itt valami félreértés van... én nem makrókról beszélek hanem rendes értékadó operátor megírásáról. Az nem makró hanem az osztály része.
[quote:cdfbca5ffc="feledhetetlen"]
vagyis mikor olvasod, fogalmad nincs rola, hogy mi tortenik valojaban,
csak ha megnezed a X assigment operator kodot
Ezt hívják OO-nak... :) nem érdekel hogy belül hogyan működik...
ha az OO indulatszo, akkor valoban annak hivjak
ha az ObjectOriented-re utalsz akkor annak az implementation hiding csak egy icipici resze
amugy igazad van, valoban felreertettem, nem a beepitett
copyonassigment-re gondoltam
a copyon parameteratadas, es ertekadas amugy szerintem rossz gyakorlatot sugall, igy kerulhetnek a stack-be 50ks objektumok...
Ez egy "feledhetetlen" feladat triviális megoldással 8)
[quote:6ecefdfa47="Andrei"]De meg senki nem volt konstruktiv, es nem mutatott nekem eddig egy frappans, hatekony, jol hasznalhato desktop Java alkalmazast (Matlab nem er :) ), ami bizonyitana szamomra, hogy mennyivel tobbet ad ez a nyelv es ez a platform (bocsanat ez a Nyelv es ez a Platform), mint barmi mas.
_szerintem_ azert van ez igy, mert az elobbi (az alkalmazas frappanssaga, hatekonysaga, jol hasznalhatosaga) a Felhasznalo szemszogebol itelheto meg - az utobbi ( nyelv/platform superiorsaga) pedig ettol fuggetlenul, a Fejleszto szemszogebol. (== nehez egy kinyomtatott szovegrol megmondani, hogy a billentyuzet, amin irtak kenyelmes/jo-e)
legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
aztán ezekre a képekre ráengedjek mondjuk egyszerű, primitív bilineáris szűrőt, ami pixelenként többfajta lebegőpontos műveletet végez.
semmi flame, csak találós kérdés: vajon milyen nyelven programozom, Java-ban vagy C++ -ban?
naugye.
hát rettenetesen fáznék attól, ha teljesítménygyilkos nyelven kellene dolgoznom, mert egyszer csak kiderülne, hogy a feladat a nyelv választás miatt megoldhatatlan... ez pedig az általam választott nyelvről még soha nem derült ki.
[quote:8a380672e5="Csab"]Persze mindenre lehet java-t használni, csak nem mindenre érdemes. Láttam már szervert, amit java-ban írtak és irgalmatlan erős gépeken úgy ment, mint egy beteg tetű.
Én is. De ez nem biztos, hogy a Java hibája, ugye? :) C++-ban is tudok rossz programot írni, ha nagyon akarok :)
[quote:26443d7ef9="popacsek"][quote:26443d7ef9="feledhetetlen"]
... mit csinal a
[code:1:26443d7ef9]synchronized( this ) { }[/code:1:26443d7ef9]
a 'hat semmit' valasz eseten arra,
hogy miert nem szedi ki a fordito ?
ha javap-pal megnezed benne kell lennie...
Ez egy "feledhetetlen" feladat triviális megoldással 8)
lehet nem voltam vilagos:
ennek a sornak VAN funkcioja, ertelmes dolgot csinal
interview-n biztos meg is kerdeznem :)
Kedves frimen:
a legeslegelso amit a a swingrol tudni kell:
CSAK CSAK CSAK a swing thread-rol vegezz swing muvelteket
vagyis aki a main thread-bol csinal setVisible vagy akarmi mas muveletet az magara vessen...
a java helyett pedig nincsen mas:
ezt be kell latni
az idezett kod hibas, csak okulasul legyen itt...
----- 8< -----
package leak;
import java.awt.event.*;
import javax.swing.*;
public class Main extends JFrame implements ActionListener {
JPanel panel = null;
JFrame frame = null;
public Main() {
setTitle("frame1");
setLocation(0, 0);
setSize(100, 160);
JButton button = new JButton("Letrehoz..");
button.addActionListener(this);
getContentPane().add(button);
setVisible(true);
}
public static void main(String[] args) {
Main main = new Main();
}
Jónéhány éve java programozásból élek, ezért írtam, hogy triviális.
Vhogy úgy vagyok a java-val, hogy szép, és jó, és igazi oo nyelv, de azért a C++ -ra szavaztam.
Frimen:
Az, hogy nem takarít nem csoda, mert mint azt már mondottam: GC akkor van, ha elfogy a memória. Magyarul olyan, mint a lusta kollégista: csak akkor kezd el takarítani, ha már meg sem bír mozdulni a szeméttől. Amúgy valóban mindkét esetben beragasztod a fránya actionlistener-en keresztül a komponenseidet, dehát nemhiába szoktak cégek GUI-s munkákra úgy Java fejlesztőt keresni, hogy "x év Swing tapasztalat".
6-os java pedig tényleg kint van, ráadásul a forráskód is teljes egészében elérhető (sőt, még hibajavításokat és patch-eket is lehet küldeni hozzá), kb összevethető stabilitással, mint a Linux kernel, vagy a PHP 5.akárhány (folyamatos development). A Java konferencián Tim úgy vetített Netbeans-ről, hogy Mustang futott alatta - mondjuk banki rendszer alá még nem tenném.
[quote:0f60aa2c8c="popacsek"]Jónéhány éve java programozásból élek, ezért írtam, hogy triviális.
...
ok, trivialis, de irdd mar le mi is az a trivialis valasz?
csak azert erolkodom, mert azt gondolom nem az
szamit, hogy mennyi ideje, meg hol, meg mennyire
hivatasszeruen programozol javaban:
inkabb ez: erted-e az alapokat, vagy se
aki tudja erre az egyszeru kerdesre a valaszt az erti
aki nem, az csak dumal
[quote:eda05a99b4="fdavid"]
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
Nevetségesnek ezt a szemléletet tartom, és csodálkozom, hogy az életből még nem vetted észre, hogy ez butaság. Egy bankot nem az fogja érdekelni, hogy na jó, venni kell még +X gépet, azért, hogy gyorsabb legyen a cucc. Az fogja érdekelni, hogy mennyire stabil a program, milyen gyorsan van kész, tudja-e kifogástalanul azokat a feature-öket, amiket kért.
Te verheted a melled, hogy kézzel csinálod a memória-menedzsmentet, de ezzel max. a 20e forintos c/c++ könyvelőprogramodat tudod majd reklámozni, hogy szerezz plussz 1-2 vevőt.
Nyilván megvan a területe a c/c++-nak is, de emiatt sz@rozni a java programokat - ehhez nagy pofa kell. Kb annyi, mint amit a 20e forintos példával írtam.
Van egy feladat, meg kell oldani. Lehet hozzá ezt is, azt is használni. Van, ahol a java lesz a jobb megoldás.
[quote:72eb3161cb="bocs"]
egyszer csak kiderülne, hogy a feladat a nyelv választás miatt megoldhatatlan...
Feladat: beszédszintézis
http://research.sun.com/techrep/2002/abstract-114.html
"The Java™ platform has a stigma of being a poor performer and has often been shunned as an environment for developing speech engines. We decided to better understand this stigma by writing a speech synthesis engine entirely in the Java programming language.
Remarkably, we were able to get better performance from our engine than one using similar algorithms written in C. Our team, composed of three engineers with significant backgrounds in the C and Java programming languages, also found it easier to make algorithm modifications using the Java programming language than using C. "
Tudom, kiragadott példa.
Többszálas programot írtál?
[quote:e5e4e5358f="_Joel"]Többszálas programot írtál?
én éppen akkor nem
mellettem a másik asztalnál éppen adatgyűjtést, motor vezérlést stb raknak össze, ugyancsak c++ -ban, sok-sok konkurrens szállal, csilivili grafikus felülettel
---
más: privát munkámban nemlineáris illesztéseket, mátrix műveleteket csináltam. vajon ennek célszerű lett volna java-ban nekiállni?
erősen kétlem.
Valaki fel tudna világosítani, hogy miért van szükség GC-re?
Minden objektumnak van egy referenciája.
Amikor ez a referencia nullára csökken, azaz senki nem használja, meghívjuk a destruktort és fölszabadítjuk az objektumot.
[quote:6bb92c1308="feledhetetlen"]
ha az OO indulatszo, akkor valoban annak hivjak
ha az ObjectOriented-re utalsz akkor annak az implementation hiding csak egy icipici resze
Nem indulatszó... Az enkapszuláció (szerintem) az egyik legfontosabb része az OO-nak... mert általa (is) lehet egy magasabb absztrakciós szintre lépni, így egyszerűsítve (bezárva) a problémákat.
[quote:6bb92c1308="feledhetetlen"]
amugy igazad van, valoban felreertettem, nem a beepitett
copyonassigment-re gondoltam
a copyon parameteratadas, es ertekadas amugy szerintem rossz gyakorlatot sugall, igy kerulhetnek a stack-be 50ks objektumok...
Vegyük azt a példát amikor egy függvény egy változó tartalmával végez műveleteket. Ha érték szerint megy az átadás akkor a függvénynek van egy saját példánya amit nyugodtan megváltoztathat a munkája során anélkül hogy az eredetit elrontaná... De a programozó megteheti hogy a változó értéke helyett egy mutatót ad át... a programozó DÖNT!
[quote:6bb92c1308="feledhetetlen"]
Badarság...
[quote:03345331f0="feledhetetlen"]inkabb ez: erted-e az alapokat, vagy se
aki tudja erre az egyszeru kerdesre a valaszt az erti
aki nem, az csak dumal
Na most akkor lassan már elárulhatnátok, hogy mit kell azon az egy soron látni, hogy más is okuljon a java "szépségeiből".
:?:
[quote:cf9d10aa02="waiter"] Pl. C, C++ vagy Java nyelvekkel lehet készíteni interaktív és hardvereszközökkel is kommunikáló, GUI frontendet is és dinamikusan generált webes felületet is, de PHP-vel csak ez utóbbit.
A következő idézet erről az oldalról származik:
http://www.php.net/manual/hu/intro-whatcando.php
konklúzió lemaradt: a Java használata ezeken a helyeken kizárt.
[quote:13388a108f="laja"][quote:13388a108f="fdavid"]
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
Nevetségesnek ezt a szemléletet tartom, és csodálkozom, hogy az életből még nem vetted észre, hogy ez butaság. Egy bankot nem az fogja érdekelni, hogy na jó, venni kell még +X gépet, azért, hogy gyorsabb legyen a cucc. Az fogja érdekelni, hogy mennyire stabil a program, milyen gyorsan van kész, tudja-e kifogástalanul azokat a feature-öket, amiket kért.
Te verheted a melled, hogy kézzel csinálod a memória-menedzsmentet, de ezzel max. a 20e forintos c/c++ könyvelőprogramodat tudod majd reklámozni, hogy szerezz plussz 1-2 vevőt.
Nyilván megvan a területe a c/c++-nak is, de emiatt sz@rozni a java programokat - ehhez nagy pofa kell. Kb annyi, mint amit a 20e forintos példával írtam.
Van egy feladat, meg kell oldani. Lehet hozzá ezt is, azt is használni. Van, ahol a java lesz a jobb megoldás.
Igen csak akkor nem a Java-t kell nagy garral hype-olni, hogy igy hi-tech, meg ugy cutting edge, meg uberalles.
Egyebkent a bankok tipikusan nagyon konzervativak es unalmasak, amikor a technologiai fejlettseget nezzuk. Az infrastrukturajukhoz kepest a szolgaltatasaik elkepesztoen szegenyesek es elmaradottak.
Es akkor erdemes megnezni mi tortenik a Java-val, ahogy haladunk erdekesebb szektorok fele (ipari alkalmazasok, ur-tenger-legkor-gyogyszer-asvanykincs kutatas vagy ugy egyaltalan HPC-supercomputing). Egyre kevesebb orajelnyi idot eszik meg a JVM az ilyen szektorokban es egyre tobbszor van jelen a C/C++/Fortran meg a mindenfele specialis nyelvek. Sot az igazan high-end-ben mar kerek 0 kornyeken mozoghat a Java jelentosege/haszna/ertelme. Es hidd el ezek nem a 20e forintos szamlazoprogramok.
Hozzateszem: a minap kerestem egy egyszeru UML rajzolo tool-t nehany diagram elkeszitesehez. Talaltam egy csomo Java-s progit, tapasztalat:
- Lassuak (ugy nez ki, hogy az 1.8-as Dothan proci 2 mega L2-vel szar)
- Zabaltak a memoriat (sorry csak 1 giga ram van a notebookomban)
- Rondak (tudom, hogy ez szubjektiv, de a baratnom is elegge csunyanak tartotta) :lol:
- Volt nehany, ami rendesen szetszallt (pl. ArgoUML, amire epul kereskedelmi termek is).
Namost ehhez a "minoseghez" nem kell java. Es mindig ez van. Mutasson mar nekem valaki egy szep, gyors, hatekony Java programot! Nemigen van.
De tudjatok mit? Hasznaljunk Fortran77-et! Abban nincs dinamikus memoriakezeles. Igy nincsenek memory leak-ek sem. Viszont csereben pokolian gyors kodot general a forditoprogram. Hmmm?
[quote:4736c2a252="maszili"][quote:4736c2a252="KisKresz"]Na, kicsit durva kijelenteni a C++-ról, hogy valóban teljesíti az OO szemléletet, amikor a többalakúság csak mutatókon keresztül érhető el, a függvényeknél meg meg kell mondani, hogy virtuálisak-e... gyakorlatilag hatékonysági megfontolásokból egy csomó öszvér megoldás van benne.
A c++ már csak ilyen... sok helyen használatosak a mutatók...
Ezt nem értem mire írtad. De egyébként igazad van. :-)
[quote:4736c2a252="maszili"]
[quote:4736c2a252="KisKresz"]
Nincs memory leak, HA jól írták meg... és ránézésre nem látszik, hogy milyen kód fut le...
Pont ez a lényege az OO-nak. Nem tudom hogy hogyan működik és nem is kell tudnom hogy hogyan működik.
Azért pl. a STL-t valószínüleg jól írták meg :)
Az STL hogy jön ide?
Egyébként igaz, amit írtál, de ha C++-ban ilyet látsz:
A a;
A b;
...
A = B;
Nem csak azt nem tudod, hogyan csinálja, de azt se, hogy mit, egészen addig, amíg bele nem másztál vagy az A dokumentációjába vagy magába az implementációjába. Vagy bízol az A programozójában, hogy nem rakott valami elvetemült funkciót az értékadásba.
[quote:4736c2a252="maszili"]
[quote:4736c2a252="KisKresz"]
ez is csak egy lehetőség, amit a nyelv biztosít, de ésszel kell használni.
Ezt nem értem... milyen lehetőség?
Egyébként meg pont arról folyik a beszélgetés hogy a két nyelv a java és c++ milyen lehetőségeket ad a helyes kód megírásához.
Lehetőségen az operator overloading-ot értettem. Egyébként, ha már az OO és a C++ és az = kapcsolatáról van szó, érdemes áttanulmányozni ezt a weblapot, miért is ütik egymást:
http://www.awprofessional.com/content/images/020163371x/items/item33.html
Egyébként Scott Meyer More Effective C++ c. könyvéből van, ami szerintem alapmű (az Effective C++ és az Effective STL is).
KisKresz
Induljunk el a kályhától.
Most vonatkoztassunk el mindenféle számítógéptől és prog. nyelvtől gondolkodjunk tisztán matematikusként. Amikor az ember leír egy olyan algebrai kifejezést hogy
a = b
akkor ezzel azt szeretné mondani hogy bé értéke legyen benne á-ban. És emmi egyébről szó nincs... mindenki természetesnek veszi hogy a és b egymástól független változók, csak az értékük egyforma. Ezt ugye nem vitatja senki... legalább is remélem.
Akkor most térjünk vissza a prog. nyelvekhez.
[quote:ada789ceb4="feledhetetlen"]
...a copyon parameteratadas, es ertekadas amugy szerintem rossz gyakorlatot sugall...
Az előbbi példámra hivatkozva szeretnék rámutatni arra hogy az érték szerinti átadás a természetes. Ezt szoktuk meg a matematikában. Korábban még példát (a függvényes) is írtam hogy a programozás során gyakorlati haszna van.
Ezek után nézzük az operátorokat.
Megkérdeztem hogy hogyan néz ki java-ban egy értékadás ha nem elemi adattípusokról van szó.
[quote:ada789ceb4="_Joel"]
[code:1:ada789ceb4]
q = p.clone();
[/code:1:ada789ceb4]
Hát én pont erről beszéltem. Egy egy szerű a = b helyett mindenféle varázs tagfüggvényeket kell hívogatni...
És mindez miért van?
[quote:ada789ceb4="_Joel"]
Nincs éspedig szándékosan nincs operator overloading. Ez egyike volt a "Java legyen egyszerubb, mint a C++" tervezesi elgondolasnak.
Na most ettől egyszerűbb lett a nyelv? Hogy az algebra megszületése óta használt egyenlőség jel helyett / mellett varázsfüggvényeket kell hívogatni?...
Miért nem ad eszközt a java arra hogy a saját magam kreált objektumhoz megírhassam a saját operátorait, hogy úgy használhassam mintha elemi adattípusok lennének? Nem ez valósítaná meg az egyszerű, átlátható OO szemléletet?
Nyílvánvalóan a nyelv nem készülhet fel minden adatszerkezetre amit a programozó kitalálhat... de adhat eszközt arra hogy a programozó elkészítse a saját maga kitalált adatszerkezetén működő operátorokat. Ezzel elfedve a művelet során fellépő problémákat.
Ezek után nekem ne mondja senki hogy a java egy egyszerűbb, jobb, nagyobb kifejező erejű nyelv mint a c++ mert nem hiszem el... :)
[quote:b9fa9c23a0="bocs"]
Prologból írtam a diplomamunkám, azzal foglalkoztam előtte 1-2 évig.
Konklúzióm: nagy hűhó semmiért.
Tudományos szempontból biztos érdekes, mérnöki szempontból katasztrófa.
Sínen vagyunk... :-)
Ha ennyire katasztrófa lenne mérnöki szempontból és tudományosból is csak "biztos érdekes", szerintem ennek sem lenne létjogosultsága: SICStus Prolog Homepage (Overview of Licenses - Prices in Euros)
Szabad esetleg tudni, hogy mi volt a feladatod?
[quote:1c2299566b="Csab"]Kedves Andrej.
A referencia számlálós memóriakezelés működne.
Sajnos neked nincs fogalmad sem a java működéséről.
Az i++, i-- szerinted mit csinál multi threades környezetben?
Tökéletesen viselkedik, ugyanis a primitív típusok automatikusan szinkronizálva vannak java-ban. Ezt jó tudni.
Ha egy mezei i++ nem jelent komoly problémát skálázási szempontból, a referencia számlálás sem lesz problémás.
Tudom, hogy hiper advanced java guru vagy, de azért ne hidd azt, hogy a világon mindent te tudsz a legjobban...
Ahogy en is leirtam, meg Joel is leirta: en nem vagyok Java guru, sot. Soha eletemben nem irtam Java programot.
Gyerunk tovabb a szakmai tevedeseidre (ehhez nem kell Java gurunak lenni, csak mondjuk az egyetem elso ket eveben egy kicsit jobban odafigyelni)!
Nem az volt a baj, hogy nem lehet szinkronizalt modon novelni vagy csokkenteni egy valtozo erteket, hanem az, hogy a szinkronizacio szukseges minden ilyen muvelet eseten. Ettol a problematol nem szabadulsz meg sem akkor ha azt kell irnod, hogy:
i++;
vagy valami ilyesmit, hogy
lock(i)
{
i++;
}
Elhiszem en neked, hogy a Java az elso valtozattal is helyesen mukodik, de a budos eletben nem fogod tudni kikerulni azt a problemat, hogy szinkronizalni KELL (legfeljebb mas teszi meg helyetted). Raadasul a referenciaszamlalasnal minden egyes ertekadasnal el kell vegezni ezt a muveletet, mig a GC on-demand mukodtetheto. Hatalmas kulonbseg!
Es a tul gyakori szinronizacio nagyon problemas SMP kornyezetben. Hiaba veszel szep sokprocis gepet, nem kapsz szamottevo teljesitmenynovekedest.
Az mar csak hab a tortan, hogy ezt a problemat nem is en vetettem fel, hanem _Joel (bevallom oszinten en nem gondoltam vegig ezt a vonalat, en az algoritmikus problemakra koncentraltam).
[quote:25e2adae49="bocs"]unkámban nemlineáris illesztéseket, mátrix műveleteket csináltam. vajon ennek célszerű lett volna java-ban nekiállni?
erősen kétlem.
Én is. Erre Fortran való.
Ez a reflection kicsit túl van lihegve nem?
Én ha tehetem nem használom a reflection-t java-ban, nemcsak azért mert nagyon lassú, hanem azért is mert - szerintem - nem szép megoldás, kerülendő technika. Szinte minden esetben kiváltható szebb, gyorsabb, átláthatóbb megoldással.
Alaposabban belegondolva én nem a nyelv miatt szavaztam a C++-ra a java ellenében, hanem a megvalósítás miatt. Amit én már régen beletettem volna a java-ba az az, hogy amit egyszer lefordít bytekódról, akkor azt ne kelljen megint lefordítani, hanem tegye le file-ba, vagy ilyesmi. Különösen igaz ez a JRE osztályokra. Azokat eleve le kellene fordítani telepítéskor, vagy eleve olyan csomagokat kellene csinálniuk, amiben le van fordítva. És a swing-en is üthetnének vmit ...
[quote:c5c2e438f1="maszili"]Vegyük azt a példát amikor egy függvény egy változó tartalmával végez műveleteket. Ha érték szerint megy az átadás akkor a függvénynek van egy saját példánya amit nyugodtan megváltoztathat a munkája során anélkül hogy az eredetit elrontaná... De a programozó megteheti hogy a változó értéke helyett egy mutatót ad át... a programozó DÖNT!
Igen, de C++-ban az érték szerinti paraméterátadás elég veszélyes is lehet, gondolok itt a kivágásra (object slicing).
KisKresz
[quote:52ec6adfd9="Csab"]Sok tekintetben jobb, más tekintetben rosszabb.
Én sok helyen java-t használok, más helyeken C++-t.
Vegyünk egy példát: a KDE C++-ban van írva.
Ha grafikus felület alatt fish-et akarok használni, a KDE fish protokolját fogom elérni és nem szórakozom JAVA varázslással.
Nyilván linux alatt grafikus felületet nem véletlenül nem programozik senki JAVA-ban. Vagy GNOME, vagy KDE. Rengeteg linuxos programot használok, de egyik sem java-s felületű az Eclipse kivételéve.
Jegyezzük meg: egy C++ progit lefordítasz, azonos platformon jó eséllyel menni fog. Ez java-ra nem igaz. Ha nincs java telepítve, megszívtad. Márpedig alapból sem windowson, sem bizonyos linux disztribúciókon nincs java. Ha nem vagy rendszergazdi, megszívtad. Bár unixok alatt nagyon ritka, hogy ne lenne java.
Ha 5-ös java-t fordítasz és kihasználod az új API-t, az nagy valószínűséggel nem fog menni 1.4.2 és korábbi java-kon. Rengeteg szívás volt amiatt, hogy ahol a programot futtatták régebbi java volt.
Ha 2D / 3D alkalmazást akarok írni, ami több platformon is elfut, SDL-t választok, nem java-t. PC-n még nem láttam olyan java-s játékot, ahol rendesen lehetne scrollozni sebesség miatt.
A mobiltelefonos java kb. 20-szor olyan gyorsan scrolloz, mint a mezei PC-s referencia implementáció, pusztán azért, natív és kemény hardver gyorsítással megy.
Aki foglalkozott már 2D grafikával tudja, hogy mindenegyes ciklus fontos. Egyáltalán nem mindegy az a 60% sebességkülönbség. Egy 1000*1000 pontos felületen 1 Millió pontot kell újra rajzolni szükség esetén.
Jelentheti azt is, hogy a programod 1 GHz-en már nem fut el, csak 2 GHz-en. A jelenlegi gépek felét ugye kizártad.
Hmmm, írtam java scrollozós progit: Egy k nagy bitmap-ban (memóriában) írtam szöveget, majd ezt mozgattam a képernyőn. Win alatt 500Fps!!!! felett jött ki. Linux alatt kevesebb 100fps, bár 3d gyorsítás nem volt bekapcsolva (lehet h számít a 2d képek rajzolásánál...).
3d motor beépítve, ami autómatikusan használja az opengl, directx-et.
Játékok: Chrome, IL-2.
Az sem probléma h nincs telepítve a java futtató környezet: én bemásoltam a progimat a jre-be és így írtam ki cd-re. Tökéletesen fut..
Igazából az az igazi előnye a javának h nem kell mindenféle platformra átültetni és átírni a progidat. Én sokat szívtam h Win98 alatt máshogy működött a C++ progik mint a NT alatt!
Pl 32000 pixelnél nagyobb (szélességű, magasságú) képet NEM tudsz létrehozni Win 98 alatt.
Másik szívás Visual Studio (200x verziójú), fájlmegnyitó ablakot, ami tökéletesen futott XP alatt. DE, Win98 alatt meg sem jelent! Hát én nem akarok ilyenekkel szívni. Ezért ha nem sebességkritikus atommag szimulációkat vagy Doom5-öt írom :) (tehát csak egy általános interaktív progit), akkor java-t választom. Ha sebesség kritikus, akkor megvizsgálom, vajon java alatt mennyivel lassabb... és eldöntöm.
[quote:07f97ac373="bocs"]legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
Maximálisan teljesíthető Java-ban, akár néhány száz sorban: http://access1.sun.com/techarticles/ImagingApps/JImage.html
http://java.sun.com/developer/technicalArticles/Media/AdvancedImage/index.html
Néhány Success story:
http://java.sun.com/products/java-media/jai/success/
Különösen a biomedical rész lehet számodra érdekes:
Biomedical Imaging
* Apteryx S.A.R.L. - Factor analysis of medical image sequences
* DECODON GmbH - Analysis of 2D gel electrophoresis images
* Millenium Technology Inc. - Magnetic resonance(MR) imaging systems
* National Center for Microscopy and Imaging Research - Mosaicking, Tomography, and Telemicroscopy
* Neologica - Web-based DICOM medical image viewing component
[quote:07f97ac373="bocs"]
konklúzió lemaradt: a Java használata ezeken a helyeken kizárt.
Ezért tart ott ez az ország, ahol tart:)
A java-val nekem rengeteg bajom volt. Lehet, hogy a sortolós algoritmus gyorsan működik, de a teszt nem volt helyes.
- Egyrészt: mivel a memória méretét felnövelted 256 MByte-re, ezzel gyakorlatilag kikapcsoltad a java Garbage Collection nevű förmedvényét.
- A GC-t már Commodore 64 alatt is utáltam.
A GC lényege, hogy mindig akkor kapcsol be, amikor nem kellene.
Szóval java-ban a GC-nek köszönhetően sosem fogsz pl. video / DVD lejátszó szoftvert írni.
Nyilván, ha a tesztet a GC-vel mérnéd más eredményt adna.
Másodszor a java a GC-nek köszönhetően eszméletlen sok memóriát zabál fel. Rengeteg cirkuláris referenciát tartalmazó objektumot meg fel sem szabadít. Elnyeli. Nem egyszerű feladat egy java programban memory leakage-et javítani.
A C++ konstruktor / destruktor függvényei igencsak hiányoznak a java-ból. A többszörös öröklés is.
[quote:8d9fe256b4="Csab"]Amikor ez a referencia nullára csökken, azaz senki nem használja, meghívjuk a destruktort és fölszabadítjuk az objektumot.
És ez vezet el a már említett körkörös referencia zavarokhoz, amik miatt egyik gc sem úgy működik ahogy leírtad. Itt le is van írva:
http://www.memorymanagement.org/faq.html#gc.ref
Bővebb infóért:
http://www.memorymanagement.org/
Ajánlom az Articles szekció Beginner's Guide cikkét.
[quote:4f14dea05b="zsolt"][quote:4f14dea05b="syntern"]
A Java teljesítménye (-server kapcsoló) a legtöbb esetben megközelíti ugyanazt a kódot megvalósító C++ programot a Hotspotnak köszönhetően, valamint az erősen rekurzív esetekben jócskán meg is előzi. (5-ös Java, gcc, -O1, 2, 3-mal is mérve, a -O3 már majdnem olyan jól teljesített mint a Java) A mérések kizárólag memória-kezelést és algoritmus végrehajtást mértek, ugyanaz a C++ kód és Java kód futott, feladatonkénti mérési idő 30-45 mp, hogy ne legyen nagy hiba az óra pontatlanságából. Sok esetben gyanítjuk, hogy a Hotspot optimalizálása alig kezdett el működni.
Azért kíváncsi lennék arra a C++ és Java kódra. Saját tapasztalatom, hogy C++-ban is lehet eszméletlenül lassú kódot írni, nem mindegy ugyanis, hogy mennyi tapasztalata van a programozónak.
Küldj egy címet és elküldöm a konkrét kódokat. De hogy megnyugtatóbb legyen: ugyanúgy programozta le mindkét nyelvben pl. a mátrix-hatványozást, vagy a quicksortot (ugyanolyan induló tömbértékekre), ill. a prímszámkeresést. Nem nagy dolgok, de memóriazabáló (fusson a GC) és procizabáló (legyen idő mérni) feladatokat kerestünk. Direkt úgy készítettük elő a mérést, hogy semmi zavaró tényező ne legyen benne, tisztán a sebesség legyen mérhető, semmi mellébeszélés.
[quote:62a506aa4e="Csab"]A java-val nekem rengeteg bajom volt. Lehet, hogy a sortolós algoritmus gyorsan működik, de a teszt nem volt helyes.
- Egyrészt: mivel a memória méretét felnövelted 256 MByte-re, ezzel gyakorlatilag kikapcsoltad a java Garbage Collection nevű förmedvényét.
- A GC-t már Commodore 64 alatt is utáltam.
Másodszor a java a GC-nek köszönhetően eszméletlen sok memóriát zabál fel. Rengeteg cirkuláris referenciát tartalmazó objektumot meg fel sem szabadít. Elnyeli. Nem egyszerű feladat egy java programban memory leakage-et javítani.
Nem tudom, hogy mennyire tűnt fel, de egy 50.000.000 elemű integer tömbön fut a quicksort mindkét esetben. Mivel mind a Java, mind a C++ 4 bájton tárol egy intet, ezért minimum 200 MB-ot eszik mindkettő. Én a Java esetében a parancssori kapcsolóval a maximális memóriafoglalást állítottam 250 MB-ra, a minimálisról és a menet közbeniről nem mondtam semmit. Kliens esetében -Xmx207 is elegendő lett volna, -server esetében 215 kellett neki. Arról nem is beszélve, hogy menet közben nincs változás az igényelt memória méretében. De hogy pontosabb kép legyen:
A C++ kód a top szerint 191M-et foglal, a Java kód 201M-et (-server kapcsolóval 202M-et). A 10MB különbség az, ami a teljes optimalizálási környezetet adja. Szerintem annyit megér.
Azaz még egyszer: ebben a tesztben meg sem hívódik a GC, de nem azért, mert túl sok memória van szabadon, hanem mert az algoritmus menet közben nem igényel és nem szabadít fel memóriát. Várom a következő belekötést :)
És kimaradt a pascal :(
[quote:02d54d8786="bocs"]legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
aztán ezekre a képekre ráengedjek mondjuk egyszerű, primitív bilineáris szűrőt, ami pixelenként többfajta lebegőpontos műveletet végez.
semmi flame, csak találós kérdés: vajon milyen nyelven programozom, Java-ban vagy C++ -ban?
Mondok masikat: wikipedia-t letoltottem, es a linkek menten graffa alakitom. Azt tudni kell, hogy az angol wikipedia 800.000+ bejegyzest tartalmaz, a letoltott angol dump XML formatumu, kicsomagolva 5 GB. Van hozza XSD sema, es en szeretek idohatekonyan fejleszteni, ugyhogy egybol az XML-t objektumos formaban beolvasva kezelni.
Szerinted miben irtam meg a programot? :) Nana hogy Javaban, es mit ne mondjak buszke vagyok arra, hogy nagyon egyszeru volt vegigparsolni az 5GB XML-t, csak ismerni kellett hozza a megfelelo eszkozoket. Bizonyara C-ben is ment volna, de nem hiszem, hogy minden eszkoz rendelkezesre all, es nem hiszem, hogy egy nap alatt vegeztem volna vele. Ezzel csak azt akarom mondani, hogy a memoriahatekony programozas nem nyelvi csoda, ismerni kell az eszkozt amit hasznalsz, es meg lehet csinalni streaming modban is mindent.
A programozási nyelv egy eszköz, és felesleges azon vitatkozni melyik a jobb. Szerintem. Nekem amire néhanapján kell jó a pascal, ezt tanultam, ezt "tudom" használni. Azokról pedig akik úgy mondanak valamiről véleményt, hogy nem is ismerik, meg van a véleményem :) Épp ezért a többi nyelvről nem is beszélek.
[quote:621cb9c01c="handler"]
N ugyfel meg azt mondja neked X ido utan, hogy a programod rossz, a szamitasok nem helyesek es emiatt neki Y millio forintos kara keletkezett, es legyel szives minden kart es javitassal felmerulo koltseget megteriteni. :D
Ugye tesztelési, átvételi stb. jegyzőkönyvről még nem is hallottál?:)
A szerződések kitételeiről a felelősség kérdésében nem is beszélve..:)
[quote:621cb9c01c="handler"]
A fenti bytecode hozzaszolasodbol nem igy tunik. Osztott eroforrast hogy kezelsz? Refcount ? :D Memory leak (es memory corruption) nelkui kodot pedig aligha fogsz a fenti feltetel teljesulese nelkul csinalni...
Osztott erőforrást.. fogok egy erőforrást és felvágom kis darabokra oszt szétosztom.:)
Pontosan melyik feltételről is van szó?
Fri
Gyepesi Gyuri irta 2001-ben, nem emlexem miert, de tanulsagos lehet,
mivel Gyurinal jobbat nem ismerek java-val kapcsolatban...
http://javasite.bme.hu/~lazlo/gyuri_2000.txt
Kedves Csab,
[quote:eb9dbbe9fd="Csab"]
- Egyrészt: mivel a memória méretét felnövelted 256 MByte-re, ezzel gyakorlatilag kikapcsoltad a java Garbage Collection nevű förmedvényét.
Szerinted 50 millio int-hez megis mekkorara kellene meretezni a heap-et? :)) 200 MB-ra biztosan szukseg van. Gondolom azert adott meg 256 MB-ot syn, mert gyakran szoktak ennyit megadni az emberek.
Garbage Collection-t nem az -Xmx iktatja ki, hanem maganak a tesztnek az a jellege, hogy alapvetoen nem jar memoria allokacios muveletekkel: egy mar kesz tombot sortol az algoritmus. Nem allokal, nem peldanyosit, nem bazguralja a memoriaallokaciot. Egyvalamit mer: mennyire jo a Java bytecode-bol az adott platform gepi kodjat generalo optimalizacio es forditas.
Ezt most bővebben ki kéne fejteni, nem látom az összefüggést.
Ajánlom figyelmedbe ezt a whitepapert:
http://java.sun.com/docs/hotspot/gc5.0/ergo5.html
"The maximum pause time goal is specified with the command line flag
-XX:MaxGCPauseMillis=<nnn>"
" -XX:GCTimeRatio=<nnn>
The ratio of garbage collection time to application time is
1 / (1 + <nnn>)
For example -XX:GCTimeRatio=19 sets a goal of 1/20th or 5% of the total time for garbage collection."
A GC lényegében akkor kapcsol be, amikor valamelyik generációban elfogy az allokálható hely.
Nyilván lehet olyan tesztet csinálni, ami sok objektum létrejöttével jár (pl meg van adva, hogy 64MB memóriát használhat a program és le kell allokálni összesen 500 MB-nyi memóriát miközben C++-ban dispose-olsz, Javaban meg eldobálsz referenciákat). Kérdés, hogy ez mire jó, és milyen valós alkalmazáshoz hasonlít, hogy relevanciája is legyen a mérésnek.
De egyszerű feladat, egy csomó profiling eszköz van, amivel egy kis hozzáértéssel egész gyorsan meg lehet találni, hogy hol és mi a baj. A cirkuláris referencia pedig nem okoz gondot. Csak olvass utána hogyan is működik a GC, és rájössz te is. Nem kell hozzá egyetemi diploma.
Hát persze, minden C++ programozónak. De csak egy ideig, utána megtanulják használni az interfészeket és megtanulnak bízni a GC-ben, illetve megtanulják a tuningolását.
Nem tudom. Lehet programozó hiba is.
Jó, lehet, hogy negatív irányban vagyok elfogult a java-val szemben.
A munkahelyemen is állandóan java-ban kell programozni és visszasírom a régi jó C++, C-s időket.
Mindenesetre ha lehet választani java és .net között, a java-nak drukkolok.
Persze a java-nak egyre több konkurense lesz. A mobiltelefonos iparban a Macromedia Flash, Python, PHP,... még szóbajöhet, mint alternatíva. Gyorsabb és olcsóbb megoldások. A Sun dollármilliókat kaszál a telefonokot futó java implementációkból.
Szóval az alap java az egész jó.
A Sun, aki viszont mögötte van, már nem a legjobb választás. Nehéz vele együttműködni.
[quote:c19fc536d9="hop1"]És kimaradt a pascal :(
Szerencsére.
[quote:ea5d873baf="_Joel"]
.. bar az teny, hogy foleg szerveroldalon eli meg mindig a reneszanszat (csak eleg megnezni a web frameworkok szamat, es az egyre ujabb buzzwordoket (2-3 eve ugye az AOP volt a nagy szam, mostanaban a dependency injection es tarsai... kivancsi vagyok mi jon jovore:)
Ezzel egyet kell, hogy értsek.
Szerver oldalon nem sok gondom volt még a java-val.. ott "általában" van elég erőforrás.
Cliens oldalon.. viszont már megingott a hitem a Java-ban..
Lássuk Joel mit tudsz..:
mitől lehet szerinted az, hogy 2 ellenőrző is azt mutatja, hogy már nincs leak: a heap
rendben: az objektumok föltámadnak, majd porba hullnak.. a foglalt/free/össz heap
nem nő.. mégis azt látom, hogy a memóri felhasználás folyamatosan nő.
A poén, hogy linux alatt nem nő a memória felhasználás.. M$ 2003 alatt nő..
most boot-olok át M$ XP-re, hogy lássam ott mi van.
Te mit használsz (fejlesztő eszköz, checkelő)?
Fri
[quote:ca0b3614c6="Csab"]Másodszor a java a GC-nek köszönhetően eszméletlen sok memóriát zabál fel. Rengeteg cirkuláris referenciát tartalmazó objektumot meg fel sem szabadít. Elnyeli. Nem egyszerű feladat egy java programban memory leakage-et javítani.
Először is csak C++-ban van olyan, hogy a cirkuláris referenciák elnyelődhetnek, a Javaban ez nem létezik. A Java kidobja azokat az objektumokat, amelyekre futó szálból nincs referencia (ez finomhangolható, el lehet érni tudatos beállításokkal azt, hogy csak egyszerű referencia-számláló fusson, de minek).
Másodszor nem értem, hogy a GC-nek köszönhetően miért zabálna sok memóriát? A GC elsősorban prociidőt eszik akkor, amikor éppen nincs elég szabad memória, és az új igénylés már nem szolgálható ki. Azaz nem olyankor, amikor éppen kedve tartja, hanem akkor, amikor szükséges. C++-ban is akkor szabadítod fel az objektumot (ha nem felejted el), amikor szükséges, a különbség az, hogy Java esetében:
1. nincs memória-töredezettség (azaz ha kis apró szabad szeletek vannak, akkor a többit összenyomja, és nagyobb hely lesz - szintén csak akkor, ha ez szükséges)
2. ha tényleg nincs referenciád az adott objektumra, akkor kidobja. Felejtsük el a körkörös referenciát, thread szinten indul a GC.
Egy Java programban akkor van memory leak, ha a fejlesztő nem szüntet meg referenciát a megfelelő objektumra. De ez már inkább az, hogy a Javaban programozás nem azt jelenti, hogy ismerem a nyelv szintaktikáját, hanem azt, hogy ismerem a nyelv működését.
Elvileg az összes C++ library támogatja az összeadást.
QString a1( "first" ), a2( "last" );
QString result = a1 + a2;
std::string a1("first" ), a2( "last" );
std::string result = a1+a2;
A probléma az, hogy a string kezelés nem egységes. Az STL string kezelő (std::string) túl gagyi ahhoz, hogy közös legyen, rossz a dokumentációja, így minden könyvtár úgy implementálja, ahogy akarja.
A javadoc-kal ugyanez a helyzet. Mialatt java alatt egységes, C++-ban legalább 3-4 féle javadoc szerű szabvány létezik.
Kár, hogy a java-ból az operator overloading kimaradt. C++ alatt ez baromi áttekinthető kódot eredményez.
Az a==b sokkal szebb, mint az a.equals(b)
[quote:ef681df25d="Frimen"]
Ez igaz is meg nem is..
.. igaz, mert mindkettő csak specifikáció..
.. nem igaz, mert a java jvm nélkül sokra nem jó, kirakod a kodot a
falra és gyönyörködsz benne?:)
.. nem igaz, mert foglalj már le légyszives "kézzel" memóriát java-ból,
majd szabadisd fel (ez a jvm "feladata)
Fri
- a java bytecode jvm nelkul hasznosabb mint gondolnad, ugyanis bizonyithato a helyessege, vagy hogy megfelel a specifikacionak...
- ez a foglaljunk kezzel memoriat nalad valami fetis? Miert nem veszed at a forditotol a memoriakezeles problemajat (c, c++ eseten) ha mar olyan jol kezeled a memoriat, elvegre Te is kioszthatod mikor melyik regiszterhalmazt hasznalja...
[quote:5393cac61d="Frimen"]mégis azt látom, hogy a memóri felhasználás folyamatosan nő.
A poén, hogy linux alatt nem nő a memória felhasználás.. M$ 2003 alatt nő..
Ennek alapjan ez bugnak tunik. Van valami platformfuggo a kodban (pl SWT)?
Az a baj, hogy olyan szinten amilyenen szeretnék, semmit. "Hivatalból" netbeans-szel játszom időnként újra és újra (including netbeans profiler), eclipse-t neha nezegetem de nem hasznalom. H meg veletlenul XML Schemat kell szerkeszteni akkor szerzek egy JDevelopert:) Sajnos egyre jobban tavolodom a fejlesztestol ebben a munkakorben, es ez nem tulsagosan tolt el sok eletorommel.
Hamár felmerült a "garbage collector/erőforrás gazdálkodás/memory leak" ...
Feltennék egy kérdést.
Nem logikusabb olyan kódot írni ami jól működik? Mert akkor nem szükséges a futásidőben történő erőforáspocsékló hibajavításokkal terhelni a rendszert... Vagy rosszúl látom? :)
Előrebocsájtom hogy a JAVA-t nem ismerem (a C++ -t igen) behatóan és nem fikázás akart lenni a kérdésem, csupán érdeklődöm.
[quote:726a48257c="fdavid"]Volt alkalmam mobiltelefonba is fejleszteni, koszoni szepen - amit en irtam - nem fagy le. Es mas programjaim sem. Szoval nem a nyelven mulik, hogy egy program jo-e vagy sem.
En ugy vettem eszre aktiv Symbian fejlesztő ismerőseimen, hogy egyre cifrábbakat tudnak káromkodni a nyelv és a platform kényelmetlenségén .net és javahoz képest. Persze lehet, hogy nekik nem olyan fejlesztési feladatuk volt, mindenesetre az egyik szoftverükkel a nokia középvezetője példázódott valami konferencián... (symella, ha mond valamit és jól írom...)
[quote:726a48257c="fdavid"]De ott van a D nyelv (http://www.digitalmars.com/d/), ami azt hiszem, hogy igencsak eltalalt holmi.
Én évekkel ezelőtt nagyon néztem a D nyelvet, programokat is írtam rajta. Egészen addig, míg egy alkalmazásnál azt mondta az üzemeltető, hogy vagy C++ vagy Java, ismeretlen marhaságokat ne akarjak futtatni. (erőgépen, felügyelt környezetben sok-sok procival)
[quote:726a48257c="fdavid"]A masik, hogy C++-hoz is van GC, vagy pl. ott a QT, amivel alom dolgozni.
Persze, de azt ugye tudod, hogy a C++-os memória-felszabadítás után az üres memória-terület töredezetté válik, míg Javaban a fogalom is ismeretlen? Azaz előfordulhat olyan C++ eset, amikor a GC takarít, de az allokáció sikertelen, mert a memória-terület nincs összenyomva, pedig egyébként a darab összessége elég lenne.
Erről a Tanú jut eszembe, meg a narancs...
[quote:726a48257c="fdavid"]Nem! A managelt kod csak toredeket oldaj meg a problemaknak, es raadasul ujakat hoz be, a hibas szemlelettel. A megoldas a minsoegbiztositas. Tisztesseges folyamatdefiniciok, modszerek, eszkozok, human eroforras osszhangaja, tervezes, dokumentalas, es atfogo teszt.
Aha, ezek megoldások, de ha a szemlélet hibás, akkor ezek sem érnek semmit sem. Azaz mindegy milyen szinten, de tisztában kell lenni a szemlélettel, ha helyen akarod alkalmazni a technológiát.
[quote:726a48257c="fdavid"]Ez sem feltetlenul igaz. Assemblert nagyon keves helyen hasznalnak, es gyakran nem C-ben, hanem magasabb szintu kornyezetben fejlesztenek, es csak generaljak a C kodot. Ja es Pascal is elofordul meg itt-ott, persze nem uj projektekeben.
Persze, és a generáció során szépen generálják a memóriakezelést és a managelt környezet összes funkcionalitását, ahelyett, hogy a managelt környezetben futtatnák. Megint csak arról van szó, hogy van egy kitalált, működő rendszer, szeretnénk egy hasonlót, barkácsolunk magunknak, mert mi jobban értünk hozzá. Bejöhet, de általában nem fog.
[quote:d955a0d381="feledhetetlen"]http://javasite.bme.hu/~lazlo/gyuri_2000.txt
Ez jo, de halistennek azert az elmult 5 ev sem mult el nyomtalan (pl NIO, concurrent api, jvm optimalizaciok, stb).
[quote:baeaeb5c78="_Joel"]
Nyilván lehet olyan tesztet csinálni, ami sok objektum létrejöttével jár (pl meg van adva, hogy 64MB memóriát használhat a program és le kell allokálni összesen 500 MB-nyi memóriát miközben C++-ban dispose-olsz, Javaban meg eldobálsz referenciákat). Kérdés, hogy ez mire jó, és milyen valós alkalmazáshoz hasonlít, hogy relevanciája is legyen a mérésnek.
Ettől függetlenül kimérjük :)
[quote:b0f028921e="Csab"]
A Sun, aki viszont mögötte van, már nem a legjobb választás. Nehéz vele együttműködni.
www.jcp.org - Java Community Process
(link küldözgetős hangulatom van ma, úgy tűnik)
Milyen muris, hogy ezt a hibát még tapasztalt java programozók is elkövetik.
Az == és az equals metódus nem ugyan az. Az, hogy a két Józsi meg ugyanoda fordítódik-e, implementáció függő.
[quote:c1d30efc97="popacsek"]Ez a reflection kicsit túl van lihegve nem?
Én ha tehetem nem használom a reflection-t java-ban, nemcsak azért mert nagyon lassú, hanem azért is mert - szerintem - nem szép megoldás, kerülendő technika. Szinte minden esetben kiváltható szebb, gyorsabb, átláthatóbb megoldással.
A Config es a Commander osztalyokra hivatkoznek:
http://javasite.bme.hu/~lazlo/src/telenio/Main.java.html
ez nem a reflection legfontosabb hasznalat, de a parancsminta igy sokkal karbantarthatobb mint a switch block-ban megvalositott trivialis valtozat.
[quote:c1d30efc97="popacsek"]
Alaposabban belegondolva én nem a nyelv miatt szavaztam a C++-ra a java ellenében, hanem a megvalósítás miatt. Amit én már régen beletettem volna a java-ba az az, hogy amit egyszer lefordít bytekódról, akkor azt ne kelljen megint lefordítani, hanem tegye le file-ba, vagy ilyesmi. Különösen igaz ez a JRE osztályokra. Azokat eleve le kellene fordítani telepítéskor, vagy eleve olyan csomagokat kellene csinálniuk, amiben le van fordítva. És a swing-en is üthetnének vmit ...
Feltalaltad amit a microsoft java (jview.exe) vm-ben is feltalaltak.
Ott volt erre egy nagy adatbazis a windows home alatti dzsuvaban.
Ettol 'gyorsabb' volt a vm inditas.
Az update pedig a class hash-re alapult.
(Errol mar irtam)
Elegge biztos vagyok, hogy minimum 40 patentet jegyzett be a microsoft 20ezer jogasza erre. Neha ez is szamit...
mi a személyes tapasztalatotok a pythonnal kapcsolatban? :roll:
[quote:9451d949c7="Andrei"]De meg senki nem volt konstruktiv, es nem mutatott nekem eddig egy frappans, hatekony, jol hasznalhato desktop Java alkalmazast (Matlab nem er :) ), ami bizonyitana szamomra, hogy mennyivel tobbet ad ez a nyelv es ez a platform (bocsanat ez a Nyelv es ez a Platform), mint barmi mas.Andrei
Volt itt aki UML modellezőt keresett. Nekem a MagicDraw nevű eszköz nagyon bejött, próbáld ki. Nem azért, mert versenyez bármilyen csilivilli és megszokott alkalmazáshoz, hanem mert minden Java platform alatt ugyanúgy néz ki (Swing) és a Swing ellenére is meg tudták írni gyorsra, elegánsra.
Jah igen: láttam hogy mennyire egyszerű plugint fejleszteni hozzá, ami macerálja a modellt és kommunikál egy J2EE szerverrel, lekéri a J2EE szerver memóriában lévő EJB beanjeit és azokat majdnem on-the-fly kirajzolja, a módosításokat pedig visszaírja az appszerverbe. Nem biztos, hogy egy 3D kóder ettől hasraesik, mindenesetre elegáns és szép megoldás volt egy hülye problémára.
[quote:79d253eeaf="syntern"]
Adj szabad kezet tetszoleges feladat implementaciojara, mondj egy eredmenyt, amit latni szeretnel, es kihozom. Nem veletlen a sok pl. Linux-Windows osszehasonlitasban kijovo eszmeletlen kulonbseg: ha akarom, tudom ugy alakitani, tudom ugy implementalni. hogy a C++ lassabb legyen. Ennyit a kamuzasrol.
Ha Neked szabad kezed van és a másiknak is.. de még ha meg is álapodtok észerű elvekben, akkor is lepipálja a java-s programodat egy c-ben megirt.:)
Bevallom ennyire fanatikussal még nem találkoztam mint Te vagy.:))
[quote:79d253eeaf="syntern"]
Kijavitalak: Te az SWT-re gondoltal, en meg a Java eleg regota alkalmazott awt-jere:
Megkövetlek.. néha már jajong a fejem ettől a sok röviditéstől, 10 percenként
kitalálnak egyet.:)
AWT.. nem ettem meszet, hogy egy elavult technologiával irjak meg egy mai programot.
Az awt elavult.. a swing elcseszett.. a kettő között lenne az igazság.. szerintem.
Felfoghatod ugy is, hogy kijott. Mi mar kiprobaltuk, mertuk, gyorsabb, mint az 5-os :)
Tyja.. ha a gyorsaság a fontos.. érdekes modón még mindig sokan használnak 1.4-es
javat, föleg kritikus környezetben.. szeirnted ez véletlen?
Fri
[quote:5248b3a9af="Csab"]
A GC lényege, hogy mindig akkor kapcsol be, amikor nem kellene.
Szóval java-ban a GC-nek köszönhetően sosem fogsz pl. video / DVD lejátszó szoftvert írni.
A gc addig nem fut amig nem tudja az ossze nem-realtime thread-et leloni.
Nem tudja leloni, ha a thread eppen nativ reszeben tartozkodik a programnak.
Ergo: a video bitblt, illetve nativ decoder dll alatt sem fog GC futni...
Nem hiszem, hogy a gc logikaja akadalyozna barkit, hogy dvd lejatszo szoftvert irjon.
a legelso gc implementacio is felismerte a hurkokat a fuggosegi grafban, nem tudom hol talaltal olyan felreimplementalt vm-et amiben ez nem igy van... (kaffe?)
a nyelvdefinico puszta meglete teszi igazan egyedive a javat
fontos meg megjegyezni, hogy a nativ kijarat/bejarat resze a nyelvdefinicionak
es ezt egyetlen mas nyelven sincs igy
a "hogyan jon le egy objektum/thread a nativ szintre",
es "hogyan megy vissza" altalaban nem nyelv szinten meghatarozottak
maximum library, de az is implementor/library fugges inkabb
a gc kenyelmes de azt is latni kell, hogy a gc nem a kenyelem miatt kell:
a gc alapja dgc-nek
dgc pedig alapja az elosztott szamitasi modelnek
ezek az eredmenyek/tulajdonsagok (rmi+dgc) puszta meglete is olyan
fontos feltetel ami mellett a sebesseg csak a sokadik szempont
[quote:0376357748="Csab"]
Az a==b sokkal szebb, mint az a.equals(b)
Az lehet, de egyrészt nem egyértelmű (már sokan leírták), másrészt mivel javában nincs pointer, ezért ez a művelet más célra van fenntartva.
Egy totálisan móriczka példa:
String s1 = new String("bela");
String s2 = new String("bela");
System.out.println("s1 == s2: " + (s1 == s2));
System.out.println("s1.equals(s2): " + s1.equals(s2));
[quote:e0e2018394="Frimen"]
Bevallom ennyire fanatikussal még nem találkoztam mint Te vagy.:))
Hmm, 2000 óta ismerem Syntern-t (bár azt hiszem abban a gólyatáborban nem voltam, amiben ő volt gólya - de már elsőévesként egyiket volt az InfoSite-ot összerakó srácoknak), de fanatikusnak nem nevezném. Bár ha azt nézzük, hogy az Automatizálási tanszéken Java-val foglalkozva doktoranduszkodik, J2EE labort és tárgyat tart... (syn, bocs hogy lebuktatlak)
[quote:2792111809="Csab"]
Milyen muris, hogy ezt a hibát még tapasztalt java programozók is elkövetik.
Az == és az equals metódus nem ugyan az. Az, hogy a két Józsi meg ugyanoda fordítódik-e, implementáció függő.
Jaaaaa... ez van ha 3 orat alszik az ember ejjel
[quote:6c08739028="feledhetetlen"]Kedves frimen:
a legeslegelso amit a a swingrol tudni kell:
CSAK CSAK CSAK a swing thread-rol vegezz swing muvelteket
vagyis aki a main thread-bol csinal setVisible vagy akarmi mas muveletet az magara vessen...
a java helyett pedig nincsen mas:
ezt be kell latni
az idezett kod hibas, csak okulasul legyen itt...
Bocs, már látom, mire gondoltál.. igazad van és egyetértek.. nem onnan
szoktam.:)
Látszik, hogy nem szoktam igy "nyersen" dolgozni..:)
De ez a problémán nem változtat.. nekem akkor eltérés van a két
megvalósitás memoria használata között.
Fri
Csak tudnád, hány olyan hibával találkoztam idáig, ahol equals helyett == -t írtak...
[quote:2198d2a5d4="lokoto"][quote:2198d2a5d4="bocs"]...Prolog...
Szabad esetleg tudni, hogy mi volt a feladatod?
Pneumatikus oszlop szabályozási feladata.
Tudod, témavezetőm egy egész üzemet élesben vezérlő programot írt Prologban... de az a nyelv egyszerűen nem erre való, nem jó eszköz ilyen feladatra. Tapasztalat.
Sok helyen hasznos lehet, de van ahol nem jó választás. A c++ -al viszont nehéz befürödni, csak nagyon ritkán derül ki a projekt végén, hogy mégsem ezzel kellett volna.
Egyébként a Prologra ugyanaz vonatkozik, mint a Java-ra: mindenki használja nyugodtan, csak az ellen a beteges szemlélet ellen fújok, hogy "Java-n kívül más nyelv nincs", amint az explicite itt el is hangzott a fórumon.
[quote:397b8064b9="_Joel"]Frimen:
Az, hogy nem takarít nem csoda, mert mint azt már mondottam: GC akkor van, ha elfogy a memória. Magyarul olyan, mint a lusta kollégista: csak akkor kezd el takarítani, ha már meg sem bír mozdulni a szeméttől. Amúgy valóban mindkét esetben beragasztod a fránya actionlistener-en keresztül a komponenseidet, dehát nemhiába szoktak cégek GUI-s munkákra úgy Java fejlesztőt keresni, hogy "x év Swing tapasztalat".
1. Az egyik esetben nálam azonnal takarit (minden esetben) a másik esetben nem.
2. Azért érdekelne szerinted hol ragad be és mitől az actionlistenerben az objektum?
Ugyanis mint láthatod, az első esetben szándékosan "ragasztom be" az objektumokat,
ha megnézed a második klickre nullázom fel a referenciákat.
Szóval Joel, előbb tanulj meg kodot értelmezni, utána gere nekem ekkora mellénnyel.
Fri
[quote:7f84f3f05d="hanischz"]Igazából az az igazi előnye a javának h nem kell mindenféle platformra átültetni és átírni a progidat. Én sokat szívtam h Win98 alatt máshogy működött a C++ progik mint a NT alatt!
Pl 32000 pixelnél nagyobb (szélességű, magasságú) képet NEM tudsz létrehozni Win 98 alatt.
Másik szívás Visual Studio (200x verziójú), fájlmegnyitó ablakot, ami tökéletesen futott XP alatt. DE, Win98 alatt meg sem jelent! Hát én nem akarok ilyenekkel szívni.
Operációs rendszerek közti különbségekbe ütköztél, ez nem a C++ hibája. Ha valami egységes elemkészletet használtál volna, amelyik win98 és nt alatt is megy, vagy utánanézel, hogy az általad használt operációs rendszer specifikus elemek a korábbi verziókban is benne voltak-e, akkor ez nem fordult volna elő. C++-ban is lehet (majdnem) platformfüggetlenül programozni, ha akarsz. :)
[quote:dd98059aa3="ssikiss"]Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
Hát, az én elképzeléseimben a dll egy bináris, amin belül lehet bármi, és ha nekem nem mondják meg, hogy mi van benne, meggebedhetek, akkor sem fogom tudni kitalálni a belső osztályszerkezetet, amennyiben véletlen C++-ról fordult az a dll, és nem pl. C-ről. Ennek ellenkezőjéről egy példával már meg is lehet győzni :)
[quote:57c559ab08="_Joel"]Frimen:
Az, hogy nem takarít nem csoda, mert mint azt már mondottam: GC akkor van, ha elfogy a memória. Magyarul olyan, mint a lusta kollégista: csak akkor kezd el takarítani, ha már meg sem bír mozdulni a szeméttől. Amúgy valóban mindkét esetben beragasztod a fránya actionlistener-en keresztül a komponenseidet, dehát nemhiába szoktak cégek GUI-s munkákra úgy Java fejlesztőt keresni, hogy "x év Swing tapasztalat".
1. Az egyik esetben nálam azonnal takarit (minden esetben) a másik esetben nem.
2. Azért érdekelne szerinted hol ragad be és mitől az actionlistenerben az objektum?
Ugyanis mint láthatod, az első esetben szándékosan "ragasztom be" az objektumokat,
ha megnézed a második klickre nullázom fel a referenciákat.
Szóval Joel, előbb tanulj meg kodot értelmezni, utána gyere nekem ekkora mellénnyel.
Fri
Üdv!
Szeritem általános esetben nem számít h a c++ vagy akármilyen nyelv 10-50%-al gyorsabb kódot generál mint a java. Mert többet szívhatsz az utólagos memória kezelési és egyéb hibákkal és a különböző platformra való átírással.
Régebben Builderben írtam a progikat (amiket eladtam). Nagyon jó kis API-t hoztak létre. Késöbb áttértem a visual C-re, de 1-2év programozás után elegem lett abból h a Windows api még csak nem is objektum orientált! (Legalábbis nem teljesen. Hanem egy része esemény vezérelt. Egy beviteli mező háttérszínét közvetlenül nem lehet béállítani hanem csak eseményt kiváltó kóddal elég tré módon).
Másik gond az említett inkompatibilitás a különböző Windows-ok között. Nagyon sokat szívtam h kis "apróságokban" és a dokumentációkban nem említve különböznek a Win-ek.
Harmadik h a megrendelő tegnap előttre kéri a programot és nem volt időm lassan, nyugodtan , minden részét megtervezve és letesztelve megírnom a programokat.
Ezért sokat kellett hibát javítanom utólag és ezt men szerettem. Akkor figyeltem fel a menedzselt kódú környezetekre. Java vagy C#. Az utóbbi szerintem kényelmesebb (legalábbis nekem, mert C++os voltam), De a java azért sokkal több api-t tartalmaz mint a .Net. (Egyelőre.)
Mondjuk a QT könyvtárakat nem ismerem, nem tudom milyen plussz funkciókat tartalmaz... de lehet h jót tenne a linuxnak h mondjuk a grafikus programokat mono-ra átírnák. Poén lenne ha a köv MS Office simán menne linux alatt. :)
ui.: A c++ fájlkezelés sokkal lassabb mint a sima c alatt. Lemértem. (amikor még adatbázis motort akartam írni. 1 év fejlesztés után rájöttem h k sok munka... inkább hazsnálom a meglévőket.)
Hányadik hozzászólásban volt ez?
Személy szerint a héj-programozást hiányolom! Grafikai alkalmazásokon kívül nagyon ügyesen meg lehet egy kég shell-scriptel oldani mindent. (Holott a "grafikát" sokszor generáltam már úgy, hogy shell-script írt html-t :) )
[quote:355fa2c7e3="maszili"]Nem logikusabb olyan kódot írni ami jól működik? Mert akkor nem szükséges a futásidőben történő erőforáspocsékló hibajavításokkal terhelni a rendszert...
Logikusnak biztosan logikus, de jelenleg még emberek kódolnak, nem logikai automaták. C és C++ memory leak tekintetében jóval veszélyesebb műfaj, mint a Java. Egy JVM-ben elvileg csak egy elszabadult thread miatt lehetnek memory leak-jeid (vagy mondjuk akkor ha ugy programozol JDBC-t, hogy nem olvastal utana annak, hogy mit is csinalsz es elfelejted close-olni a statementedet meg a tobbit), hiszen a garbage collection garantalja neked, hogy az olyan objektumok amikre nem hivatkozik elo thread objektumbol elerheto uton masik objektum, azok periodikusan fel fognak szabadulni valamelyik gc utemben. Amit Java-ban elveszitesz C++-hoz kepest az a stack-en letrehozott objektumok lehetosege.
A GC nem hibajavitas, hanem memoriamenedzsment.
[quote:3f1f1c0d71="laja"][quote:3f1f1c0d71="fdavid"]
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
Nevetségesnek ezt a szemléletet tartom, és csodálkozom, hogy az életből még nem vetted észre, hogy ez butaság. Egy bankot nem az fogja érdekelni, hogy na jó, venni kell még +X gépet, azért, hogy gyorsabb legyen a cucc. Az fogja érdekelni, hogy mennyire stabil a program, milyen gyorsan van kész, tudja-e kifogástalanul azokat a feature-öket, amiket kért.
Te verheted a melled, hogy kézzel csinálod a memória-menedzsmentet, de ezzel max. a 20e forintos c/c++ könyvelőprogramodat tudod majd reklámozni, hogy szerezz plussz 1-2 vevőt.
Nyilván megvan a területe a c/c++-nak is, de emiatt sz@rozni a java programokat - ehhez nagy pofa kell. Kb annyi, mint amit a 20e forintos példával írtam.
Van egy feladat, meg kell oldani. Lehet hozzá ezt is, azt is használni. Van, ahol a java lesz a jobb megoldás.
Nem tudom, hogy te milyen alapon szemelyeskedsz, de ha mar megszolittattam, akkor valaszolok:
1. ne irjal f@szsagokat, kulonosen ne ugy, hogy azt ugy allitod be, hogy en irtam
2. a baromsagaidbol ne vonjal le a szemelymre vonatkozo kovetkezteteseket
Konkretan:
1. az elet != bank, igy aztan a szuklatokoruseg nem ereny
2. sehol nem allitottam, hogy kezzel csinalom a memoria managementet (bar tortenetesen minden olyan nyelvebn, ahol erre szukseg van, ott igen)
3. egy program nem a GC-tol lesz stabil
4. eletemben nem irtam konyveloprogramot
5. nem szaroztam a javat, mindemellett nem vagyok rola egyertelmuen jo velemennyel, de emlekeim szerint az en postjaimban a java szoba sem kerult
A hozzaszolasomhoz nehezen kapcsolhato, minden szakami alapot nelkulozo, durva szemelyes tamadast a kovetkezokben mar nem fogom ennyire baratsagosna kezelni.
[quote:e150dbde09="Csab"]Valaki fel tudna világosítani, hogy miért van szükség GC-re?
Minden objektumnak van egy referenciája.
Amikor ez a referencia nullára csökken, azaz senki nem használja, meghívjuk a destruktort és fölszabadítjuk az objektumot.
:D
Igen. Miert van szukseg programozasi nyelvekre. Megirjuk a programot gepi kodban aztan fut a gepen....
Amirol te nagyvonaluan megfeledkeztel az az, hogy hol taroljuk azt a bizonyos "referenciat"? Pl. a GC-nek ez az egyik legfontosabb feladata, hogy nyilvantartsa a hivatkozasokat az objektumokra.
Amit felvazoltal, alapjaiban igaz, de vannak vele problemak. Es ez a kenyes resze a GC-nek.
- Problema1: Mikor szabaditsuk fel a memoriat? Rogton azutan, hogy eldobjuk az objektumot, vagy varjunk vele, hatha lehet okosabban is csinalni. Elarulom lehet okosabban is csinalni...
- Problema2: A te bombamegoldasod semmit nem tud kezdeni azzal, ha a konkret peldanyok korbehivatkozzak egymast. Merugye az objektumok hivatkozasi grafjaban nem azt a peldanyt lehet eldobni, amire nincs referencia, hanem azt, ami nem erheto el a root objectekbol. Ez kicsivel osszetettebb kerdes...
Na ezert kell GC.
A Java procirol csak annyit, hogy nem jarsz jobban akkor sem ha a JVM-et letolod a szilicium szintjere. Osszetett aramkoroket igenyel egy bonyolult utasitaskeszlet megvalositasa. Az eredmeny altalaban az, hogy csak alacsony orajelen kepes futni a proci.
[quote:002a007d3b="ssikiss"][quote:002a007d3b="hanischz"]Igazából az az igazi előnye a javának h nem kell mindenféle platformra átültetni és átírni a progidat. Én sokat szívtam h Win98 alatt máshogy működött a C++ progik mint a NT alatt!
Pl 32000 pixelnél nagyobb (szélességű, magasságú) képet NEM tudsz létrehozni Win 98 alatt.
Másik szívás Visual Studio (200x verziójú), fájlmegnyitó ablakot, ami tökéletesen futott XP alatt. DE, Win98 alatt meg sem jelent! Hát én nem akarok ilyenekkel szívni.
Operációs rendszerek közti különbségekbe ütköztél, ez nem a C++ hibája. Ha valami egységes elemkészletet használtál volna, amelyik win98 és nt alatt is megy, vagy utánanézel, hogy az általad használt operációs rendszer specifikus elemek a korábbi verziókban is benne voltak-e, akkor ez nem fordult volna elő. C++-ban is lehet (majdnem) platformfüggetlenül programozni, ha akarsz. :)
A C++ "hibája" az h nem elég platformfüggetlen. Azaz inkább a tudása megkopott. Nem tud Bitmap-at kezelni, vagy szálakat egységesen pl. Mikor megcsinálták az api-t akkor még nem kellett ilyen sok mindent tudni mint manapság.
Kellett egy új, a mai elvárásoknak megfelelő api és ezt csak egy újratervezett környezettel lehet megoldani.
Különben nagyon sok specifikus dolgot kell bele tenni.
[quote:aad6ee61e6="dacas"][quote:aad6ee61e6="hop1"]És kimaradt a pascal :(
Én is hiányoltam, pedig annak is van free megvalósítása. Így az assembly-re szavaztam.
En is igy tettem, bar en meg kulon kertem is a Pascalt (meg tavaly is), de latom magasrol le vagyunk szarva. A tema feletti okoskodasrol csak annyit, hogy meg jo, hogy miutan az ember nyilt forrasu Pascal forditot fejleszt a szabadidejeben, 2-3 fele processzorra (esetemben pl. 68k, x86, powerpc) meg vagy 4-5 fele OS-re, jon valaki okostojas, es kozli h. szerencse h. kimaradt a Pascal, es persze nem mulasztja el bepastelni a hatulgombolosozos dumat. De hat ez mar nem engem minosit.
Udv,
Chain-Q (A Free Pascal Compiler csapat tagja)
Ps: Egyebkent ha mar az assemblynel tartunk, akkor nagyon nem mindegy, hogy x86, powerpc, vagy milyen assembly ugye. :) Ilyen alapon a C meg a Pascal is ugyanaz a nyelv, mert hasonlo kategoriaba esnek. :P
http://javasite.bme.hu/~lazlo/src/GuiShell.java.html
[quote:3eddc4ab53="Frimen"][quote:3eddc4ab53="feledhetetlen"]Kedves frimen:
a legeslegelso amit a a swingrol tudni kell:
CSAK CSAK CSAK a swing thread-rol vegezz swing muvelteket
vagyis aki a main thread-bol csinal setVisible vagy akarmi mas muveletet az magara vessen...
a java helyett pedig nincsen mas:
ezt be kell latni
az idezett kod hibas, csak okulasul legyen itt...
Talán ha el is magyaráznád, és meg is mutatnád Te hogy csinálnád elfogadnám.. igy okoskodás.
Szóval?
Fri
Mire gondolsz?
String a = "valami";
String b = "valami";
Szerintem nem biztos, hogy a == b igaz lesz. Implementáció függő.
String a = "valami";
String b = a;
Viszont már biztos menni fog.
És nekem a nagyon sok utómunkából volt elegem.
[quote:ce40a84cad="syntern"][quote:ce40a84cad="ssikiss"]Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
Hát, az én elképzeléseimben a dll egy bináris, amin belül lehet bármi, és ha nekem nem mondják meg, hogy mi van benne, meggebedhetek, akkor sem fogom tudni kitalálni a belső osztályszerkezetet, amennyiben véletlen C++-ról fordult az a dll, és nem pl. C-ről. Ennek ellenkezőjéről egy példával már meg is lehet győzni :)
Csatlakoznek +
Udvos lenne, ha neha forrassal is szemleltetnek a ezeket a "C++ is megvan" dolgokat az ahhoz ertok.
Olyasmivel ami minden rpm-aptget-portege-install-library-magic nelkul is lefordul mondjuk "gcc tutti.cxx" modon.
Peldaul a fent emlitett reflection..
csak azert mert ugye a nyelvrol beszelunk, es nem arrol, hogy "melyik nyelvhez van a legtobb library hozzatakolva"
orulok hogy bekerulhetett a c#, koszi
[quote:6d5caebb96="bocs"]
Sok helyen hasznos lehet, de van ahol nem jó választás. A c++ -al viszont nehéz befürödni, csak nagyon ritkán derül ki a projekt végén, hogy mégsem ezzel kellett volna.
Egyébként a Prologra ugyanaz vonatkozik, mint a Java-ra: mindenki használja nyugodtan, csak az ellen a beteges szemlélet ellen fújok, hogy "Java-n kívül más nyelv nincs", amint az explicite itt el is hangzott a fórumon.
Szerintem alapvetően egyetértünk, beleértve, hogy ugyanez igaz a C++-ra is. Vannak dolgok, amiket nem C++-ban hatékonyabb megcsinálni, hanem Javában, Prologban, vagy másban.
Lehet, hogy rosszul látom, de a hozzászólások között alapvetően inkább a C++ pártiak részéről jött elő, hogy a "C++ az isten", a Java pedig csökevény. Fordított szerintem nem nagyon volt.
A Java pártiak megpróbáltak bizonyos tévhiteket eloszlatni, illetve kidomborítani olyan Java tulajdonságokat, amik könnyebben kezelhetővé teszik a Javát a C++-szal szemben bizonyos esetekben, hogy a C++ pártiak belássák: bizony van létjogosultsága a Javának illetve a benne megfogalmazott elveknek.
Ha annyira jó lenne a C++, mint ahogyan itt többen is állítják, valószínűleg nem terjedt volna el annyira és olyan területekre a Java (lásd EE, ami elég messze van az applettől, aminek kezdeti népszerűségét köszönheti), mint ahol most van, ezenkívül valószínűleg a Microsoft sem jött volna elő hasonló elvekkel leváltani a C++-t (és ne hozzátok elő, hogy C#-ban bezzeg van operator overloading, mert ez részletkérdés).
Nyilván kiderült, hogy én is Java párti vagyok, az ok eléggé egyszerű: amiket csinálok, ahhoz teljesen megfelel a Java, ha nem Java lenne, akkor 3 másik platformot/környezetet kellene ismernem, és közel sem biztos, hogy jobb sülne ki belőle, ráadásul az energiát 3 platform/környezet megismerésére kellene fordítani, ami nyilván nem annyira hatékony. Ezenkívül bizonyos szintig hordozhatóságra is szükségem van, amit a Java teljes kényelemmel nyújt az általam igényelt esetekben.
Na aki az assembly-t X-elte be mint kedvenc, es erdekelne melo a kozeli/tavoli jovoben az dobjon egy mailt arpi kukac mplayerhq.hu
(x86+mmx, ppc vagy arm kod iras, optimalizalas)
bocs az offtopicert :)
A'rpi
OO ugyben az a helyzet, hogy a C++ kiveri a biztositekot very1st OO szabalynal: minden objektum
a tobbi mar nem is erdekes...
persze be lehet tartani a szabalyokat C++ban is, sot Cben is, akar el is lehet nevezni egy ilyen szabalyrendszert ObjectiveC-nek, de az attol meg patkolas
egy makro preprocessor-bol (aminek a C++ keszult) nem lesz jobb nyelv
Csakis egy JLS szintu alapra lehet varat epiteni
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
[quote:0f9176f81e="maszili"]
Vegyük azt a példát amikor egy függvény egy változó tartalmával végez műveleteket. Ha érték szerint megy az átadás akkor a függvénynek van egy saját példánya amit nyugodtan megváltoztathat a munkája során anélkül hogy az eredetit elrontaná... De a programozó megteheti hogy a változó értéke helyett egy mutatót ad át... a programozó DÖNT!
sajnos az alapertelmezes szerint erteket ad at, pedig imho az a ritkabb
szoval ha a programozo az alapesetet koveti, altalaban rosszul dont...
[quote:0f9176f81e="maszili"]
[quote:0f9176f81e="feledhetetlen"]
Badarság...
nem en irtam: http://javasite.bme.hu/~lazlo/notes/realman.html
[quote:54fccd0193="syntern"]:) Ez jó. Meg tudod oldani azt C++-ban, hogy egy feldarabolt memóriaterületet összenyomj, hogy a sok kis memória összesen egy nagyot tegyen ki? Persze, elméletileg megoldható lehet (pedig nem, lásd: nem befolyásolt forrásból származó kód), a Java meg is oldja.
nem tudom, ez nálad valami fixa idea lehet, hogy a c++ malloc az nem képes a felszabadított blokkok utólagos egyesítésére.
Microsoft megvalósítás
Természetesen, mivel ez c++, saját new handlert is írhatsz, ami saját különbejáratú algoritmus alapján kezeli a heap-et... ugye ez c++, ahol a nyelv feltételezi, hogy a programozó tudja, mit is akar ;)
[quote:20610057c3="syntern"]Volt itt aki UML modellezőt keresett. Nekem a MagicDraw nevű eszköz nagyon bejött, próbáld ki. Nem azért, mert versenyez bármilyen csilivilli és megszokott alkalmazáshoz, hanem mert minden Java platform alatt ugyanúgy néz ki (Swing) és a Swing ellenére is meg tudták írni gyorsra, elegánsra.
Nem olvastam vegig, mert sok az oldal, es keves az ido, de en UML modellezesre Umbrello-t hasznalok, es tetszik. Vannak dolgok, amik mas, penzes rendszerekben jobbak, de ez eddig a legjobb, amit lattam, es ingyenes. Ja, ez QT, nem swing.
Beolvasni azt hiszem, csak C++-t tud, Java bean-eket szerintem nem.
Visszairni se csak ugy, csak kodot generalni tud.
Nekem manapsag nincs idom sokat szopni kodolassal, igy pythont hasznalok, ezert java-val egyuttmukodesrol nem tudok reszleteket.
[quote:e5b675db33="feledhetetlen"]http://javasite.bme.hu/~lazlo/src/GuiShell.java.html
Megnéztem.. mégsem az volt a hiba ezek szerint, hogy nem main-ba
tettem be a setVisible-t? Mert utolag megnézve, tény azt rossz helyre tettem,
bár meg van ennek is az oka.
Átnezve a kodot.. látom a különbséget, sőt létrehoztam egy osztály-t a 4.1-es netbeans-el majd a 3.6-ossal:
- 4.1
public static void main(String args[]) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new proba().setVisible(true);
}
});
}
- 3.6
public static void main(String args[]) {
new Proba().show();
}
Erre meg én azt mondom bocs, b*ssz* meg a sun a java-jat!
Fri
[quote:f2c7498fcb="hanischz"]
Régebben Builderben írtam a progikat (amiket eladtam). Nagyon jó kis API-t hoztak létre. Késöbb áttértem a visual C-re,
Itt adsz saját magad magyarázatot a problémára. Builder és visual C. Mind a kettő saját függvény / osztály könyvtárat készített valószínüleg úgy hogy nem egyeztették egymással (bárkivel) hogy ki mit és hogyan valósít meg. Ebből következik hogy inkompatibilisek egymással (mindenkivel) és megkérdőjeleződik a hordozhatóság is.
Visszatérve a GC-re felmerült bennem egy kérdés.
Korábban azt írta valaki hogy a GC csak akkor lép működésbe ha elfogy a memória. Ha ez így van akkor a GC működése miatt a java-vm minden más programot kiszorít a memóriából, fölöslegesen pazarolva az erőforrásokat? Pusztán azért hogy a programozó élhessen azzal a "kényelemmel", hogy összedobálhatja a kódot, nemtörődve az erőforrások kezelésével?
[quote:e7fbdbbb6a="Csab"]Persze a java-nak egyre több konkurense lesz. A mobiltelefonos iparban a Macromedia Flash, Python, PHP,... még szóbajöhet, mint alternatíva. Gyorsabb és olcsóbb megoldások.
A Flashnél nagyobb vendor lock-int csak a Microsoft produkál. Ha valaki nézte már a Flash bináris specifikációt, az szerintem hamar belátja. Egyszerűen nincs értelmes eszköz, amivel el lehet kezdeni foglalkozni vele. Úgy indítod, hogy 7-es verzió alatt nincs Unicode kezelés, azaz ha normális alkalmazást akarsz írni, akkor a régebbi eszközök kiesnek. Az egyetlen használható az OpenLaszlo, de a Macromedia Flexhez képest csak gyerekjáték (igaz nem is kerül 10.000$/2CPU-ba :) ). Nagyon látványosak a demói, cserébe nagyon nehéz kezdeni vele valamit.
A többit nem nevezném alternatívának, valahogy nem egy pályán mozognak.
[quote:2a349f22c9="syntern"][quote:2a349f22c9="ssikiss"]Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
Hát, az én elképzeléseimben a dll egy bináris, amin belül lehet bármi, és ha nekem nem mondják meg, hogy mi van benne, meggebedhetek, akkor sem fogom tudni kitalálni a belső osztályszerkezetet, amennyiben véletlen C++-ról fordult az a dll, és nem pl. C-ről. Ennek ellenkezőjéről egy példával már meg is lehet győzni :)
Ez teljesen így van, csak mifelénk szokás mellé egy-két header-t meg interfész libet, meg doksit is adni, ha azt akarod, hogy tudjanak vele fejleszteni. :D
Jávában is illik doksit adni nem (sokra mész a jarban látható osztályszerkezettel)?
[quote:a5d434fe1c="_Joel"]C és C++ memory leak tekintetében jóval veszélyesebb műfaj, mint a Java.
Ezzel egyetértek... a c/c++ nem próbál a programozó helyett gondolkodni. A programozóé a felelőség hogy miként oldja meg a problémát.
De ad eszközöket arra hogy jól működő kódot írjon a programozó. Elég ha csak arra gondolunk hogy egy osztálynak vannak konstruktorai, destruktorai. Ott a programozó saját maga elintézheti az erőforrások (ami bármi lehet) lefoglalását, felszabadítását.
Tehát ha a programozó használja a c++ által nyújtott eszközöket akkor szerintem fölösleges egy külső alkalmazás használata ami azt figyeli hogy milyen memória területet nem használ már senki... amit aztán felszabadíthat.
És mi a helyzet az egyéb erőforrásokkal? Amik nem egy lefoglalt memóriaterületet jelentenek hanem valami mást? Arra hogy működik a JAVA hibajavítása?
[quote:a5d434fe1c="_Joel"]
A GC nem hibajavitas, hanem memoriamenedzsment.
Direkt hibajavítást írtam mert továbbra is fenntartom azt a véleményemet, hogy a nem kívánt memóriahasználat megszüntetését végző program egy hibajavító program.
[quote:f551fe4916="ssikiss"][quote:f551fe4916="feledhetetlen"]inkabb ez: erted-e az alapokat, vagy se
aki tudja erre az egyszeru kerdesre a valaszt az erti
aki nem, az csak dumal
Na most akkor lassan már elárulhatnátok, hogy mit kell azon az egy soron látni, hogy más is okuljon a java "szépségeiből".
:?:
El kell ismerni, hogy ez az egyszeru, trivialisan szep pelda tenyleg alaposan megizzaszthatja a C++-t hasznalo, a Javat feluletesen ismero embereket :). Hozzunk egy alternativat, hogy ne csak a Java-ra fujjatok, itt a .NET-es analogiaja:
lock (this) { }
Tenyleg csak azon mulik, hogy valodi OO szemlelet van, vagy csak szintaktikailag kezeled az OO-t....
up, hátha valakinek még van hozzátennivalója (esetleg mérési eredmények? :) )
[quote:f772e7988f="_Joel"]
Hányadik hozzászólásban volt ez?
en biztos irtam ilyet, mert amugy igy gondolom :)
kicsit olyan ez mint a szergej esete a lampagyarban:
szergej a zsebeben lopkodta az alkatreszeket a lampagyarbol
de sohasem lett lampaja, mert mindig geppisztoly lett belole mire osszerakta
analogous:
ha egy olyan nyelvet akar valaki osszerakni ami tudja az activation-t
annak olyan darabjai leszenek mint a java darabjai
ha sikerul osszerakni java lesz, akkor is ha masnak nevezik
a lenyeg az, hogy a top level kontrol, a barmilyen nyelven megirt komponensek vezerlese, ma java-ban a legegyszerubb
es nemcsak sebesseg miatt nem erdemes mindent javaban irni,
inkabb azert mert sokminden mar meg van irva, tesztelt, mukodik...
Filozófiailag mitől kedvenc egy programnyelv ?
1. emlékek, tanulmányok, első sikerek otthon éjjel vörös szemmel ? :-D
2. olcsó ? (mármint bene fejleszteni, bár a legtöbbhöz elég egy texteditor, de akkor is debugolni,tesztelni azért már lehet drágább is)
3. hatékony ? (fejlesztési időben,futási időben,modularitásban,stb)
4. olvasható = könnyen tanulható ?
5. ismert (elakadok, találok a "házban" havert, aki tud segíteni)
6. "platform független" már ha létezhet ilyen... nem kell újralinkelni,fordítani, stb
csak úgy kérdem, mert olyan kiváncsi vok.
[quote:f0bd108aa6="Andrei"]Aztan jon a slusszpoen! Mi van, ha a programod eleve tobbszalu?
valljuk be, hogy ez eleg gyakori, ha eppen nem helloworld vagy lottoszamgenerator a "feladat":)
[quote:b340e2a21f="gee"]Nem olvastam vegig, mert sok az oldal, es keves az ido, de en UML modellezesre Umbrello-t hasznalok, es tetszik. Vannak dolgok, amik mas, penzes rendszerekben jobbak, de ez eddig a legjobb, amit lattam, es ingyenes. Ja, ez QT, nem swing.
MagicDrawnak van community edition változata, amikor utoljára néztem tudott mindent, amit úgy általában az ingyenes eszközök tudtak. Ez mondjuk régebben (= másfél éve) volt, azóta nem követtem a fejlődést.
Megmondom őszintén, hogy nem olvastam végig a fórumot, de néhány téma a Java/C#/Php/C kapcsán megragadott. Nem akarom ragozni a különböző funkcionalitást, ilyen-olyan vallási vitákat, csak azt írom le, amit az egyik hallgatóm kimért több gépen is:
A Java teljesítménye (-server kapcsoló) a legtöbb esetben megközelíti ugyanazt a kódot megvalósító C++ programot a Hotspotnak köszönhetően, valamint az erősen rekurzív esetekben jócskán meg is előzi. (5-ös Java, gcc, -O1, 2, 3-mal is mérve, a -O3 már majdnem olyan jól teljesített mint a Java) A mérések kizárólag memória-kezelést és algoritmus végrehajtást mértek, ugyanaz a C++ kód és Java kód futott, feladatonkénti mérési idő 30-45 mp, hogy ne legyen nagy hiba az óra pontatlanságából. Sok esetben gyanítjuk, hogy a Hotspot optimalizálása alig kezdett el működni.
Ezek után ha valaki azt mondja, hogy neki a PHP gyorsabb mint a Java, nem hiszem el :), valamint azt sem fogadom el, hogy mindig megéri C++-t erőltetni és a Java-t lassúnak titulálni. Aztán ezekhez már csak hozzá kell tenni az eszközöket, a kész és elérhető libraryket, a J2EE-ről nem is beszélve, és magyarázni sem érdemes tovább, miért jó a Java :)
[quote:b1866488e6="gee"][quote:b1866488e6="syntern"]Volt itt aki UML modellezőt keresett. Nekem a MagicDraw nevű eszköz nagyon bejött, próbáld ki. Nem azért, mert versenyez bármilyen csilivilli és megszokott alkalmazáshoz, hanem mert minden Java platform alatt ugyanúgy néz ki (Swing) és a Swing ellenére is meg tudták írni gyorsra, elegánsra.
Nem olvastam vegig, mert sok az oldal, es keves az ido, de en UML modellezesre Umbrello-t hasznalok, es tetszik. Vannak dolgok, amik mas, penzes rendszerekben jobbak, de ez eddig a legjobb, amit lattam, es ingyenes. Ja, ez QT, nem swing.
Beolvasni azt hiszem, csak C++-t tud, Java bean-eket szerintem nem.
Visszairni se csak ugy, csak kodot generalni tud.
Nekem manapsag nincs idom sokat szopni kodolassal, igy pythont hasznalok, ezert java-val egyuttmukodesrol nem tudok reszleteket.
Ugy alapjaban veve tetszett volna, de nekem Windowsos valtozat is kellene.
A visszairas, kodgeneralas nem kell, csak tudjak diagramot rajzolni, menteni, nyomtatni. Nem vagyok az a fajta, aki UML diagram nelkul mar a billentyuzetet sem tudja megtalalni. Na offtopic over...
[quote:0d5924af6b="Frimen"]
Ha Neked szabad kezed van és a másiknak is.. de még ha meg is álapodtok észerű elvekben, akkor is lepipálja a java-s programodat egy c-ben megirt.:)
Bevallom ennyire fanatikussal még nem találkoztam mint Te vagy.:))
Nna, akkor eljutottunk arra a pontra, amit megceloztunk a meressel: irj egy QuickSort programot C-ben, en is irok egyet javaban. Adjuk oda nekik ugyanazt az adathalmazt es merjuk meg a sebesseget, ki pipal le kit. Segitsegul megirtuk elore a QuickSort programot C-ben es Javaban egyarant, sorrol sorra ugyanaz, es je, a Java gyorsabb. Lehet hogy fanatizmus, de engem ez meggyozott arrol, hogy az "akkor is lepipalja" nem mindig all fenn, ha tetszik, ha nem.
[quote:0d5924af6b="Frimen"]Tyja.. ha a gyorsaság a fontos.. érdekes modón még mindig sokan használnak 1.4-es javat, föleg kritikus környezetben.. szeirnted ez véletlen?
Szerintem ez marketing hiba :), valamint elsosorban azert hasznalnak 1.4-et (ertsd azert nem cserelik le akkor sem, ha le tudnak), mert az XY appserver 1.4-re van certifikalva, es nincs az a donteshozo, aki el meri vesziteni a licenct egy ilyen csere miatt.
[quote:c0cb8281b0="Csab"]Mire gondolsz?
String a = "valami";
String b = "valami";
Szerintem nem biztos, hogy a == b igaz lesz. Implementáció függő.
String a = "valami";
String b = a;
Viszont már biztos menni fog.
a lenyeg megint elenyesz az programminglegend mogott:
Igenis NEM implementacio fuggo JLS3.10.5 String Literals :
Literal strings within the same class (§8) in the same package (§7) represent references to the same String object (§4.3.1).
Literal strings within different classes in the same package represent references to the same String object.
Literal strings within different classes in different packages likewise represent references to the same String object.
Strings computed by constant expressions (§15.28) are computed at compile time and then treated as if they were literals.
Strings computed by concatenation at run time are newly created and therefore distinct.
The result of explicitly interning a computed string is the same string as any pre-existing literal string with the same contents.
[quote:7c50044192="maszili"]
Korábban azt írta valaki hogy a GC csak akkor lép működésbe ha elfogy a memória. Ha ez így van akkor a GC működése miatt a java-vm minden más programot kiszorít a memóriából, fölöslegesen pazarolva az erőforrásokat? Pusztán azért hogy a programozó élhessen azzal a "kényelemmel", hogy összedobálhatja a kódot, nemtörődve az erőforrások kezelésével?
Ezért van -Xms és -Xmx opció. -client jvm alapból max 64MB heap-et allokál, ezt lehet -Xmx-szel emelni nagyobbra.
Amúgy meg GC-ileg öntsünk tiszta vizet a pohárba, mert látom linkeket senki nem olvas. Java-ban ugyanis generációnkénti GC van, ami azt jelenti, hogy másként keressük a szemetet a friss és a régebben létrejött objektumok között.
Java-ban a heap-et a memory management feloszti több szeletre. Van a young generation, a tenured generation es a permanent generation. Young-ban vannak a frissen letrehozott objektumok, tenured-ben a tulelo (hosszabb eletciklusu) objektumok, a permanent-ben pedig a class-ok, metodusok metaadatait reprezentalo objektumok elnek (ezzel nem nagyon kell foglalkozni).
Szemetgyujtes minden egyes generacioban akkor tortenik, amikor az adott generacio tele lesz. A Young-ot fel lehet osztani meg 3 reszre: van az Eden (itt jonnek letre az uj objektumok) és 2 egyenlő méretű survivor space (aki tudja, hogyan működig a stop© algoritmus, az ennek az okat is fel tudja ismerni).
Amikor a young generation tele lesz, akkor minor szemetgyujtes tortenik, ami eleg gyors. Egyreszt azert, mert a young generation merete toredeke az osszes felhasznalt memorianak, masreszt az algoritmus arra optimalizal, hogy keves a tulelok szama (sok a holt objektum). Ez altalaban statisztikailag igazolhato is. Minor szemetgyujtes eseten nehany tulelo objektumot atpakol a JVM a tenured generacioba (ez is befolyasolhato)
Ha a tenured generacio telik be, akkor ott tortenik egy teljes (major) szemetgyujtes, ami viszont joval lassabb (akar tizedmasorperces megallast is okozhat a JVM-ben). Adott tehat a feladat: ugy meretezni a young es a tenured generation-t, hogy minel kevesebb major collection kovetkezzen be. Errol lehet jokat olvasni itt:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
[quote:0e758c4767="maszili"] A programozóé a felelőség hogy miként oldja meg a problémát.
A project manageré meg az a felelősség, hogy a projekt megadott időre, a megrendelő igényei szerint, minél kevesebb hibával kész legyen. Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
A programozó ugyanúgy el is felejtheti odatenni azt a dispose-t, vagy free()-t, mint ahogy gyakran el is felejti. Tudom, van rengeteg eszköz, amivel ezeket figyelni lehet és a jobb programozók használják is őket memory leak-ek felkutatására. Csak éppen emiatt ugyanannak az üzleti logikának a lekódolása 2x-3x annyi időbe kerül és 2x-3x annyi rizikóval járhat.
Nem külső alkalmazás. Egy JVM-en belüli folyamat, amiről a programozónak nem is kell tudnia (persze ha jó programozó akkor ismeri és tudja, hogy mi a különbség a fiatal meg az öreg generáció között, tudja hogyan működik a mark & sweep algoritmus, mikor érdemes olyan paraméterrel indítani a JVM-et ami bekapcsolja a párhuzamos vagy a megállásmentes gc-t... stb stb stb).
Egyébként C++-hoz is vannak GC-t alkalmazó megoldások, smart pointerek. Ha olyan rossz ez az ötlet, akkor miért alkalmazzák mégis sokan?
Ez eléggé szűklátókörű kijelentés. Pár link:
http://www-128.ibm.com/developerworks/java/library/j-jtp10283/
http://cybertiggyr.com/gene/garbage-collection-cpp/
http://www.thesa.com/th/th-78-73-175-th-19-17-188.htm
[quote:2789de7771="_Joel"]
Ennek alapjan ez bugnak tunik. Van valami platformfuggo a kodban (pl SWT)?
[quote:2789de7771="_Joel"]
Az a baj, hogy olyan szinten amilyenen szeretnék, semmit. "Hivatalból" netbeans-szel játszom időnként újra és újra (including netbeans profiler), eclipse-t neha nezegetem de nem hasznalom. H meg veletlenul XML Schemat kell szerkeszteni akkor szerzek egy JDevelopert:) Sajnos egyre jobban tavolodom a fejlesztestol ebben a munkakorben, es ez nem tulsagosan tolt el sok eletorommel.
Nem semmi olyat nem használok a kódban..
Viszont megtaláltam a különbséget.. csak még.. nem értem.
Az van, hogy ha Netbeans-ből (4.1) futtatom az alkalmazást.. akkor jól müködik,
stabilan tartja a erőforrás felhasználást (profiler), látom is a OS-ben is, viszont
ha "normál" futtatom, akkor felzabálja a memóriát.
Vesszek meg ha értem..
Fri
[quote:43150cb02f="syntern"]Ezek után ha valaki azt mondja, hogy neki a PHP gyorsabb mint a Java, nem hiszem el :)
eleve ne is allj szoba olyannal, aki a kocsogdudat hasonlitja a harfahoz :)
[quote:238dd42f5f="syntern"]up, hátha valakinek még van hozzátennivalója (esetleg mérési eredmények? :) )
Belegázolni mások hitébe holmi mérési eredményekkel... :-)
KisKresz
[quote:d2863c6c3a="_Joel"][quote:d2863c6c3a="Frimen"]
Bevallom ennyire fanatikussal még nem találkoztam mint Te vagy.:))
Hmm, 2000 óta ismerem Syntern-t (bár azt hiszem abban a gólyatáborban nem voltam, amiben ő volt gólya - de már elsőévesként egyiket volt az InfoSite-ot összerakó srácoknak), de fanatikusnak nem nevezném. Bár ha azt nézzük, hogy az Automatizálási tanszéken Java-val foglalkozva doktoranduszkodik, J2EE labort és tárgyat tart... (syn, bocs hogy lebuktatlak)
Aki nem ismerne a tanszeket: amikor en szakiranyra mentem, akkor ezt a tanszeket mindenki MicroSoft tanszekkent emlegette :).
Mas: bevallom oszenten azota harapok ilyen erosen a Java teljesitmeny kerdesre, amiota kiderult, hogy egyik TDK-zo hallgatom valoszinuleg azert nem kapott elso dijat, csak masodikat, mert a biraloja es a szekcioelnoke is abban a kozel 10 evvel ezelotti allapotban elt, hogy a Java lassu. Szomoru egy ilyent atelni.
A JCP a legrosszabb lehetőség.
1. kitalálsz valamit
2. a JCP-n megpróbálod keresztülvinni
3. a JCP teljesen mást akar, egyezkedni kell konkurens cégekkel
4. a konkurens cégek hátráltatnak
5. sikerült szabványt létrehozni
6. kiadod a telefonodat
7. megveszik a vásárlók
Ez ugye 2 év legalább. A JCP késlelteti benne a legtöbbet. Pláne akkor, mikor a konkurens cégeknek még nincs kész terméke. Húzzák az időt. hogy neked se legyen...
Tudod, hogy 2 év alatt a Macromedia mennyit fejlődik?
Az örök kérdés az, hogy érdemes-e a JCP-vel szüttyögni, amikor jóval egyszerűbb megoldások is vannak, persze java nélkül.
[quote:9e987acea0="syntern"]El kell ismerni, hogy ez az egyszeru, trivialisan szep pelda tenyleg alaposan megizzaszthatja a C++-t hasznalo, a Javat feluletesen ismero embereket :). Hozzunk egy alternativat, hogy ne csak a Java-ra fujjatok, itt a .NET-es analogiaja:
lock (this) { }
Tenyleg csak azon mulik, hogy valodi OO szemlelet van, vagy csak szintaktikailag kezeled az OO-t....
Még mindíg arra lennék kíváncsi szájbarágósan, hogy mit csinál a fenti sor.
:?
[quote:6ec659d16f="syntern"]
Nna, akkor eljutottunk arra a pontra, amit megceloztunk a meressel: irj egy QuickSort programot C-ben, en is irok egyet javaban. Adjuk oda nekik ugyanazt az adathalmazt es merjuk meg a sebesseget, ki pipal le kit. Segitsegul megirtuk elore a QuickSort programot C-ben es Javaban egyarant, sorrol sorra ugyanaz, es je, a Java gyorsabb. Lehet hogy fanatizmus, de engem ez meggyozott arrol, hogy az "akkor is lepipalja" nem mindig all fenn, ha tetszik, ha nem.
Nem látom sehol a két kodot..:))
Én legalább beirtam a sajátom "üssetek agyon, ha.." alapon, de Te eddig csak a levegőbe beszéltél.
Amugy nekem már az a sorrol sorra ugyanaz enyhén szolva röhelyes..:-)
Szerintem van itt egy két C-s programozo, aki szivesen vetne pár pillantást arra a kodra.. én meg a java-s oldalára.
[quote:6ec659d16f="syntern"]
Szerintem ez marketing hiba :), valamint elsosorban azert hasznalnak 1.4-et (ertsd azert nem cserelik le akkor sem, ha le tudnak), mert az XY appserver 1.4-re van certifikalva, es nincs az a donteshozo, aki el meri vesziteni a licenct egy ilyen csere miatt.
Igenis meg nem is.
Én az előbb csodálkoztam rá, hogy ugymond a frame.setVisible már nem aktuális.. szálbol ajánlott inditani.. többektöl hallottam már és tapasztaltam is, hogy mekkorákat
szivtak a javaban azzal, hogy egy függvény elavult lesz, már "nem elég" jó.. vagy megváltozik ez meg az.. már én is bánom, hogy váltottam 1.5-ösre.. de azt is tudom egyszer ugyis váltani kellett volna.
Szerintem pár java verzió és a public static void main(String args[]) is deprecated lesz.:))
Fri
[quote:df1f5f763d="waiter"]Érdekes, hogy a PHP scripting language, mint "programozási nyelv" van jelen és az is érdekes, hogy most (2005. nov. 21. 0:20) vezet a többi konvencionális programozási nyelvhez képest...
IMHO, tekinthető a PHP programozási nyelvnek abból a szempontból, hogy algoritmusokat lehet vele leírni és ezeket (egy interpreteren keresztül) futtatni. Ugyanakkor az is igaz, hogy a PHP egy script nyelv és kizárólag a dinamikus webes tartalmak megjelenítéséhez fejlesztették, ennélfogva a programozói feladatoknak csak egy leszűkített halmaza oldható meg vele. Pl. C, C++ vagy Java nyelvekkel lehet készíteni interaktív és hardvereszközökkel is kommunikáló, GUI frontendet is és dinamikusan generált webes felületet is, de PHP-vel csak ez utóbbit.
Nem tudom, mi a "programozási nyelv" pontos definíciója, de IMHO egy programozási nyelvnek általános érvényű (és nem egy specializált) eszköznek kellene lennie, legyen szó bármilyen szoftverfejlesztési feladat megoldásáról.
- waiter -
Wikipediabol:
szamomra a nyelv szigoruan veve nem mas mint egy nyelvtan altal leirt szohalmaz(ezert nincs ertelme beszelni script nyelvrol, mert egyszeruen ilyen fogalom nem is letezhet). a programozasi nyelv szigoruan veve nem mas mint egy olyan nyelv, amivel hasonloan a fentihez, egy adott problema leirhato(igy belefer egy turing gep programja is), azaz meg szemantikaja is van.
Ebbe persze tokeletesen beleillik a php is.
[quote:cdbf8e8d8e="_Joel"]
Ezért van -Xms és -Xmx opció. -client jvm alapból max 64MB heap-et allokál, ezt lehet -Xmx-szel emelni nagyobbra.
Amúgy meg GC-ileg öntsünk tiszta vizet a pohárba, mert látom linkeket senki nem olvas. Java-ban ugyanis generációnkénti GC van, ami azt jelenti, hogy másként keressük a szemetet a friss és a régebben létrejött objektumok között.
Hát nekem ez akkor sem tetszik... :)
Szerintem egyszerűbb az osztály destruktorában felszabadítani az osztály objektuma által használt erőforrásokat. Ha ott megírtam a kódot (ami ugye egy rendes OO objektumhoz hozzátartozik mert hát én tudom hogy mit, mire és hogyan használok az osztályban) akkor elfelejthetem a problémát.
Így automatikusan felszabadul az összes felhasznált erőforrás pontosan akkor amikor megsemmisül az objektum.
Bár itt most a java és a c# nem túl jól szerepel, szerintem ezek a nyerők mind webes, mind desktop alkalmazások esetén.
- platformfüggetlen
- kevesebb hibalehetőség
- igazi objektumorientált nyelvek
- natív kód közeli sebesség
Összehasonlítottam a java-t többek között a php-vel is, de sebességben nagyságrendbeli a különbség. Persze tudom, nem minden a sebesség ...
Amit webes fronton szerintem elrontottak a java-val, az az, hogy egy applet futtatásához le kell töltsön az ember 15Mb-ot. Gondolom ezért terjed a flash, amit egyébként utálok.
Desktop oldalon meg a lassú indulást lehetne még felhozni hátrányként.
[quote:4f08aec4e9="Andrei"]Az egyik program, amivel dolgunk van az az ArchiCAD (epiteszeti tervezoszoftver). Ez az alkalmazas 6 millio sor C++ kod. Jocskan megizzadna a JVM, mire beizzit egy ilyen meretu cuccot. Es ha meg menne is akkor uj ertelmet nyernenek a Sun Fire 20-25k gepek, mert ez egy mezei workstationon nagyon hurka lenne.
A példa nagyon rossz. Először is a 6 millió sor C++ kód Java-ban írva valószínűleg jóval kevesebb lenne. Aztán más kérdés, hogy a teljes kód hány százaléka fut úgy általában és milyen kódrészletek azok, amelyek alig-alig kerülnek futásra. Vajon a gyakori kódrészleteket hogyan optimalizálta a C++ fordító? Tud-e olyan szintű paramétertől függő alternatív natív kódot, mint a Java HotSpot?
De visszatérve a beizzításra: most néztem, hogy az egyik projektünk közel 400.000 sor Java kód. A teljes alkalmazás, mellékelt jar fájlokkal együtt tömörítve 10MB (azaz tömörítve 10 MB csak a bájtkód). Vígan elfut nem csak a fejlesztői gépen, nem kell neki übergép.
[quote:99c7f33a61="Csab"]Tudod, hogy 2 év alatt a Macromedia mennyit fejlődik?
ugy erted miutan takaritonostul kilora megvette az Adobe?
Egy programnyelvet azért szeretek, mert mindent meg lehet benne csinálni.
Ilyen a Java, Perl, PHP és a C++.
Miért baj az, ha mondjuk az 1.5-ben thread safe lett az a fv, ami régen nem volt az, és ezért ajánlják, hogy használd a másikat? Ha Te ragaszkodsz a régi fv-hez, használhatod azt is, csak tudd, mik a hibái. Azokat a függvényeket nem kivették, hanem jobbakat adtak hozzá.
Az, hogy "ez meg az megváltozik": még arra is figyeltek Sunék, hogy az 1.5 foreach-e ne foreach legyen, hanem for, mert mi van, ha Frimen a kedvenc metódusát vagy változóját foreach-nek nevezte el, ne szúrjunk már ki vele, maradjon működőképes a programja...
Fejlődik a nyelv. Remélhetőleg javul. Tényleg nem értem, mi a bajod ezzel.
hat netbeans az netbeans errol nem tudok nyilatkozni, en vi-t hasznalok
de kiprobaltam:
http://javasite.bme.hu/~lazlo/src/no-leak.html
es
Linux hill 2.4.31 #8 Sun Jun 5 19:08:07 PDT 2005 i686
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
nem latok semmi lenyeges elterest a gc-ben akar
java apro.study.leak.Main
akar
java apro.study.leak.Main null
probalom
szivesen segitek, ha megmondod mi faj neked a gc mukodesben...
[quote:b139965c27="Frimen"][quote:b139965c27="feledhetetlen"]http://javasite.bme.hu/~lazlo/src/GuiShell.java.html
Megnéztem.. mégsem az volt a hiba ezek szerint, hogy nem main-ba
tettem be a setVisible-t? Mert utolag megnézve, tény azt rossz helyre tettem,
bár meg van ennek is az oka.
Átnezve a kodot.. látom a különbséget, sőt létrehoztam egy osztály-t a 4.1-es netbeans-el majd a 3.6-ossal:
- 4.1
public static void main(String args[]) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new proba().setVisible(true);
}
});
}
- 3.6
public static void main(String args[]) {
new Proba().show();
}
Erre meg én azt mondom bocs, b*ssz* meg a sun a java-jat!
Fri
[quote:9ff16fab08="maszili"]
Nyílvánvalóan a nyelv nem készülhet fel minden adatszerkezetre amit a programozó kitalálhat... de adhat eszközt arra hogy a programozó elkészítse a saját maga kitalált adatszerkezetén működő operátorokat. Ezzel elfedve a művelet során fellépő problémákat.
Ezek után nekem ne mondja senki hogy a java egy egyszerűbb, jobb, nagyobb kifejező erejű nyelv mint a c++ mert nem hiszem el... :)
Mint már írtam egyszer: szerintem rosszul közelíted meg a dolgot, mert javában nem tudsz *a-t írni, ezért ha az a = b-t felüldefiniálod a = b.clone() funkcionalitására, nem tudod miként megvalósítani a jelenlegi értelemben vett a = b műveletet, azaz hogy az a változó a b változó által mutatott objektumra mutasson.
Lehet, hogy csak megszokás, de az =-nek ez a funkcionalitása logikusan ábrázolt, és a clone() kitűnően kifejezi, hogy mélymásolást kell csinálni.
Nincs még 10 éves tapasztalat a hátam mögött, de az eddigi feladataim során minimális esetben találkoztam a clone() - azaz mélymásolás igényével. (nyilván ez adódhat a feladatok jellegéből is, de az OO szemléletnek a clone() kicsit mellékvágánya)
[quote:94c126c659="popacsek"]Bár itt most a java és a c# nem túl jól szerepel, szerintem ezek a nyerők mind webes, mind desktop alkalmazások esetén.
Mindjart megkapod az überindokot, miszerint azert szar, mert fel kell telepiteni 91283 megas framework-ot egy 20Kb-os exe miatt :wink:
hello,
[quote:864fe40547="bitumen"]Személy szerint a héj-programozást hiányolom! Grafikai alkalmazásokon kívül nagyon ügyesen meg lehet egy kég shell-scriptel oldani mindent. (Holott a "grafikát" sokszor generáltam már úgy, hogy shell-script írt html-t :) )
azért majd egyszer próbálj meg egy komyolabb feladatot scriptből megoldani, esetleg vmi hálózati programozás, etc... :)
a shell sebességéről most ne beszéljünk :)
a.
Én mindenesetre a java-nak drukkolok, de az egyáltalán nem biztos, hogy lesz java a jövő mobiltelefonjaiban.
Nyilván, ha a .net - nek sikerül a telefonpiacot megszereznie, akkor a java-nak kampec lesz. Ez ilyen egyszerű.
Bár nem ismerem a .net -et, de tartok attól, hogy képes lesz sok helyen átvenni a java szerepét.
Ha a szerverfarmot nézzük, a J2EE szerintem nem alternatíva a .net -tel szemben. Legalábbis a Sun referencia implementáció használhatatlan. Lehetetlen nyomkövetni és fejleszteni rajta. Akkor lássam legközelebb, amikor a hátam közepét...
Persze mesélik, hogy a IBM Websphere és a Bea Weblogic már nem olyan összecsapott munka, de nekem sajnos a Sun-ost kellett használnom. A JBoss-t sem próbáltam.
A java helyzete nem túl rózsás. Több konkurense is van.
[quote:bf53a92aa1="Csab"]
Jegyezzük meg: egy C++ progit lefordítasz, azonos platformon jó eséllyel menni fog. Ez java-ra nem igaz. Ha nincs java telepítve, megszívtad.
Ez nagyjából így is van, de az teljességhez az is hozzátartozik, hogy egyrészt egyre több gépen van már Java, másrészt ha pl valamilyen ügyviteli alkalmazást fejlesztesz, akkor tudod mely gépeken fog futni, ezen gépek valami központi kezelés felügyelete alatt állnak, és az esetek nagy részében simán megoldható a futtató környezet telepítése.
[quote:bf53a92aa1="Csab"]
Ha 5-ös java-t fordítasz és kihasználod az új API-t, az nagy valószínűséggel nem fog menni 1.4.2 és korábbi java-kon. Rengeteg szívás volt amiatt, hogy ahol a programot futtatták régebbi java volt.
Ne haragudj, de ebből a hozzáállásból nem tűnik ki a sok-sok éves tapasztalatod: ha viszonylag adott, hogy kik fogják használni, egy JRE frissítés általában megoldható, másrészt, ami sokkal fontosabb: mielőtt bármit csinál az ember, fel kell mérni, hogy a futtatáshoz szükséges feltételek biztosíthatóak-e. Enélkül nemhogy egy sort nem szabad leírni, de még a tervezéssel is óvatosan kell bánni.
(ha ilyen alapvető felmérést sem végeztetek, hogy milyen JRE, akkor mázlitok van, hogy "csak" ebbe futottatok bele)
Olvasgatom itt a hozzászólásokat és egy tipikus jelenségnek a megtestesítője vagy: villamosmérnök vagy, akinek tetszett az informatika, de leginkább csak hobbiszerűen űzi. Értem hobbiszerűen azt, hogy a BME VIK-en nem hiába van informatika szak, az informatikai tudományok elég kemény elméleti háttere van, amivel bizonyos kérdésekben történő állásfoglaláshoz nem árt tisztában lenni. És nem elég az, hogy nekiállsz írni egy programot valamilyen platformon és egy adott idő alatt valamekkora jártasságot szerezni.
Nem azt mondom, hogy villamosmérnökből nem lehet jó informatikus, csak azt, hogy a programozni tanulás önmagában nem ad elég elméleti hátteret - legalábbis bizonyos kérdések megválaszolásához nem.
Sajnos a BME TDK-kon is nagyon látszik az, mikor egy villamosmérnök hallgató informatikai témába vág bele. Ezen esetekben leginkább a konzulenseket nem értem egyébként.
Ne érts félre, nem akarlak megsérteni, senkit nem akarok megbántani, biztosan írtál remek programokat, csak nem árt, ha az ember tudja, hogy meddig terjed a kompetenciája.
hello,
[quote:066108907c="ParadoxH"]mi a személyes tapasztalatotok a pythonnal kapcsolatban? :roll:
- könnyen tanulható
- rengeteg modul van hozzá
- platform,- és architektura-független
- relatíve gyors (pl. a shell scriptekhez képest sokkal gyorsabb)
- nagyon jó C API-ja van
- az indentálások nagyon megkönnyítik a kód olvashatóságát
- az utasítások egyértelműek (hahhó Perl! :))
a.
OFF, de erdemes megnezni
a kovetkezo helyet a prog. nyelvekkel
most ismerkedoknek:
http://spoj.sphere.pl
foleg a hasznalhato nyelvek tekinteteben...
Visszatérve a security-re.
Security azért nincs C-ben, mert nincs rá szükség. A processzeket az operációs rendszer kézbentartja.
Ugyanez java alkalmazások esetén is megy, hogyha különböző JVM-ekben futnak. Ez viszont túl nagy ár a Security-ért. Eszméletlenül sok memóriát igényel párhuzamosan futtatni 5-6 JVM-et. A JVM-ek közti kommunikáció, objektumok átadása sem túl kecsegtető.
Éppen ezért találták ki a java-s security-t. Ez egy jó ötlet volt, csak pocsék megvalósítás mellett. Mindegy. Ez van, ezt kell szeretni, vagy elviselni.
[quote:3b27901182="Panther"][quote:3b27901182="hop1"]És kimaradt a pascal :(
Szerencsére.
A TE szerencsédre igy nem arra szavaztam
[quote:a8a0128f39="_Joel"] Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
Mi az oka?
Szerinted nem jó program nyelv a C++?
Te miben fejlesztesz üzleti alkalmazást?
Én láttam pölö perl-ben írt működéstámogató rendszert és működött,
bár lassan.
Miért lenne az jobb, mint ha C++ ban írták volna?
Mi a baj azzal, hogy a programozónak a dolga a new() és a delete()?
Miért baj az, ha bizonyos dolgokra emlékeznie kell a programozónak?
[quote:0980153217="Csab"]
Ha a szerverfarmot nézzük, a J2EE szerintem nem alternatíva a .net -tel szemben. Legalábbis a Sun referencia implementáció használhatatlan. Lehetetlen nyomkövetni és fejleszteni rajta. Akkor lássam legközelebb, amikor a hátam közepét...
Erre gondolsz?
glassfish.dev.java.net
Amit leirsz, az kb 2-3 evvel ezelotti allapot. Akkor az RI tenyleg az volt, amit leirsz.
[quote:129588d0c7="syntern"][quote:129588d0c7="ssikiss"][quote:129588d0c7="feledhetetlen"]inkabb ez: erted-e az alapokat, vagy se
aki tudja erre az egyszeru kerdesre a valaszt az erti
aki nem, az csak dumal
Na most akkor lassan már elárulhatnátok, hogy mit kell azon az egy soron látni, hogy más is okuljon a java "szépségeiből".
:?:
El kell ismerni, hogy ez az egyszeru, trivialisan szep pelda tenyleg alaposan megizzaszthatja a C++-t hasznalo, a Javat feluletesen ismero embereket :). Hozzunk egy alternativat, hogy ne csak a Java-ra fujjatok, itt a .NET-es analogiaja:
lock (this) { }
Tenyleg csak azon mulik, hogy valodi OO szemlelet van, vagy csak szintaktikailag kezeled az OO-t....
A: Bibibi! Én tudom, hogy mit jelent a synchronize(this) {}
B: Az mind semmi! Én már használtam is!
A: Az is valami? Én javasoltam a SUN-nak, mikor megalkották a java-t!
B: Nekem öcsém? Nem hiszem! A java-t én találtam ki egyedüll!
.
.
.
8-)
[quote:a173d059bb="Panther"][quote:a173d059bb="Chain-Q"]jon valaki okostojas, es kozli h. szerencse h. kimaradt a Pascal, es persze nem mulasztja el bepastelni a hatulgombolosozos dumat. De hat ez mar nem engem minosit.
Sajnos téged minősít. "szerencsére" - ezt én írtam, a másikat meg nem.
Egyszerűen nem tetszik és kész, egyébként: az ada logikus, pascal idétlen. Miért nem lehet lezárni rendesen az if-eket (end if), és miért nem lehet az end elé pontos veszsőt tenni (üres utasítás a pontosvessző, ahelyt, hogy egy null-t kellene odaírni, stb).
Azért mert a spanyolok meg fordított kérdőjellel kezdik a kérdőmondatot. :P
Ezt hogyan oldják meg?
Mármint, a jar-ban van egy "blabla" sztring, b jarban hasonlóképen szintén van egy "blabla" sztring.
a-jaros "blabla" == b-jaros "blabla" ?
[quote:9f6faf18ec="bocs"][quote:9f6faf18ec="syntern"]:) Ez jó. Meg tudod oldani azt C++-ban, hogy egy feldarabolt memóriaterületet összenyomj, hogy a sok kis memória összesen egy nagyot tegyen ki? Persze, elméletileg megoldható lehet (pedig nem, lásd: nem befolyásolt forrásból származó kód), a Java meg is oldja.
nem tudom, ez nálad valami fixa idea lehet, hogy a c++ malloc az nem képes a felszabadított blokkok utólagos egyesítésére.
Talán azért, mert úgy gondolom, hogy a mutatók miatt ez nem lehetséges. Persze ha tudsz jó példát hozni, akkor ezt beláthatom, hogy mégis lehetséges.
Az is idétlen. Nekünk,
[quote:97ff152ed2="_Joel"]Egyébként C++-hoz is vannak GC-t alkalmazó megoldások, smart pointerek. Ha olyan rossz ez az ötlet, akkor miért alkalmazzák mégis sokan?
Mifelénk a tanszéken időről időre elhangzik valaki szájából a kövektező örök igazság (szabad fordításban): Minden automatizmus csak addig jó, amíg ki lehet kapcsolni.
Kb. 3 hónapja én is leteszteltem a C vs C++ vs Java-t /link, sajnos a lap a táblázatok előtt kicsit szát van csúszva/. Prímszámokat keresgéltem és többfajta implementációt is kipróbáltam. Az eredmények hasonlóak lettek, mint amit itt a Quicksortos példában láttunk.
Olyan szépen beálltak az arányok. N = 3, 6, 10 millióra kb. egyenlőek lettek /C, C++ -O3-mal/.
1. C++ std::vector
2. C++ tömb 2,7%-kal több idő
3. C tömb 4,8%-kal több idő
4. Java tömb 7,5%-kal több idő
Azoknak meg, akik azt mondják, hogy Java-ban a hülyék programoznak: :lol:
Én szeretem a C-t és a C++-t, de azért egy Java... Az osztálykönyvtára, meg a platformfüggetlensége meg az, hogy fél óra alatt összehozok egy J2EE webservice-t, hozzá egy webes, egy J2SE-s és egy mobilos klienst... Ekkora produktivitást mikor kapok én a C++-tól?
[quote:d63a34b09f="ssikiss"][quote:d63a34b09f="syntern"][quote:d63a34b09f="ssikiss"]Miért ne lehetne dinamikusan osztályt betölteni C++-ban? dll-ben lehet bármi, osztály is. A névterek elsőre ugyanazt tudják, mint jávában a csomagok.
Hát, az én elképzeléseimben a dll egy bináris, amin belül lehet bármi, és ha nekem nem mondják meg, hogy mi van benne, meggebedhetek, akkor sem fogom tudni kitalálni a belső osztályszerkezetet, amennyiben véletlen C++-ról fordult az a dll, és nem pl. C-ről. Ennek ellenkezőjéről egy példával már meg is lehet győzni :)
Ez teljesen így van, csak mifelénk szokás mellé egy-két header-t meg interfész libet, meg doksit is adni, ha azt akarod, hogy tudjanak vele fejleszteni. :D
Jávában is illik doksit adni nem (sokra mész a jarban látható osztályszerkezettel)?
Lehet hogy én látom rosszul, de ha adsz interfészeket és doksit (= a másik oldal tudja, hogy mit fog kapni), akkor nincs szükség reflectionre. A reflection ott kell, ahol nem tudod, hogy mit kapsz.
[quote:7ed92f40dd="_Joel"]
A project manageré meg az a felelősség, hogy a projekt megadott időre, a megrendelő igényei szerint, minél kevesebb hibával kész legyen.
Na igen... a munkával töltött idő arányos a minőséggel... :)
[quote:7ed92f40dd="_Joel"]
Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
Ezt sem megcáfolni sem alátámasztani nem tudom... talán majd valaki más. :)
[quote:7ed92f40dd="_Joel"]
A programozó ugyanúgy el is felejtheti odatenni azt a dispose-t, vagy free()-t, mint ahogy gyakran el is felejti. Tudom, van rengeteg eszköz, amivel ezeket figyelni lehet és a jobb programozók használják is őket memory leak-ek felkutatására. Csak éppen emiatt ugyanannak az üzleti logikának a lekódolása 2x-3x annyi időbe kerül és 2x-3x annyi rizikóval járhat.
De nagyságrendekkel hatékonyabb a program működése... nem?
[quote:7ed92f40dd="_Joel"]
Nem külső alkalmazás. Egy JVM-en belüli folyamat, amiről a programozónak nem is kell tudnia (persze ha jó programozó akkor ismeri és tudja, hogy mi a különbség a fiatal meg az öreg generáció között, tudja hogyan működik a mark & sweep algoritmus, mikor érdemes olyan paraméterrel indítani a JVM-et ami bekapcsolja a párhuzamos vagy a megállásmentes gc-t... stb stb stb).
Itt most a külső alkalmazást úgy értettem hogy "nem a programozó által írt program része" hanem egy másik "külső" program.
[quote:7ed92f40dd="_Joel"]
Egyébként C++-hoz is vannak GC-t alkalmazó megoldások, smart pointerek. Ha olyan rossz ez az ötlet, akkor miért alkalmazzák mégis sokan?
Memtudom. Én nem használok ilyesmiket...
Szerintem amikor valaki megtervez egy olsztályt akkor azért körvonalazódnak azok az alapok amik mentén majd megvalósul a dolog. Így nem maradhat figyelmen kívül az erőforrások lefoglalása és felszabadítása sem. Egyszer kell megírni, az alkalmazása "automatikusan" megtörténik amikor szükséges.
[quote:7ed92f40dd="_Joel"]
Ez eléggé szűklátókörű kijelentés. Pár link:
Hát, talán más a szemléletem...
:D :lol: :D
Én személyesen a C++-t szeretem a legjobban.
Az osztályszerkezete jól átgondolt és gyors is. Jobb, mint a java szerkezete.
Az egyetlen fájó pontom az STL (standard template library).
Sehol egy rendes dokumentáció nincs róla és keveset tud.
Az std::vector és std::map osztályok meglehetősen gagyik, az std::string-ről nem is beszélve.
Nem véletlen, hogy a legtöbb C++ függvénykönyvtár újat készít helyettük és senki nem használja az STL-t.
Csak kár érte, hogy nincs C++-ban egységes string kezelés, hanem mindenhol más.
[quote:40bfea554b="syntern"]itt a .NET-es analogiaja: lock (faxsag) { }
picit szorszalhasogatok: c#-os
[quote:226354ffe1="aperger"][quote:226354ffe1="Panther"][quote:226354ffe1="hop1"]És kimaradt a pascal :(
Szerencsére.
A TE szerencsédre igy nem arra szavaztam
Hú de jó nekem...
Az Ada95-öt se felejtsük ki a sorból :P Néha szívok vele, de azért jó nyelv :)
[quote:58ae9b2ad8="Csab"]Az osztályszerkezete jól átgondolt és gyors is. Jobb, mint a java szerkezete.
8O
Hi,All! :) jól elvitatkozgatunk...
fdavid írta: "Ezt nem teljesen ertem, hogy hogyan vetheto ossze a programhiba a gep teljesitmenyevel. Ha azt akarod mondani, hogy egy bizonyos feladat nem hajthato vegre jol mukodo program hianyaban, akkor ez trivialis, es nem ujkeletu problema. "
A szűk keresztmetszeten azt értettem h egy általános program megírásokor manapság nem a cpu lassúsága vagy a memória nagysága a probléma, hanem az h nem vagyunk képesek jól működő, viszonylag kevés hibát tartalmazó progit írni. A "mi" természetesen vállalatok, cégek programozók stb.
Arra gondolok h linux alatt (persze win alatt is így megy nagyjából) elkészül egy progi 1.0 verzió. Fél év múlva kijön a hibajavítás 1.1 verzió alatt. Kijavították az előző hibákat de újak kerültek bele...
És nem amiatt mert buták vagyunk, hanem mert nincs megfelelő programnyelv a kezünkben!
"A megoldas a minsoegbiztositas. Tisztesseges folyamatdefiniciok, modszerek, eszkozok, human eroforras osszhangaja, tervezes, dokumentalas, es atfogo teszt.
"
Így van! Ez jól hangzik, de sok cégnél rugdalják a programozó h minél előbb legyen kész a progi :( elvesznek a finomabb részletek.
Szerintem magába a prog nyelvbe kellene valahogy minőség biztosítást csempészni! Hogy ne tudd olyan könnyen elszúrni. Elhiszem h lehet nyugodt munkakörnyezetben jól dolgozni. De számtalanszor tapasztaltam h a kedves megrendelő tegnapra! várja a programot. És sok sok cégnél is így van. Azért mert nagy verseny van a piacon.
Első lépcsőfok szerintem a menedzselt prog nyelvek.
Üdv!
Itt adsz saját magad magyarázatot a problémára. Builder és visual C. Mind a kettő saját függvény / osztály könyvtárat készített valószínüleg úgy hogy nem egyeztették egymással (bárkivel) hogy ki mit és hogyan valósít meg. Ebből következik hogy inkompatibilisek egymással (mindenkivel) és megkérdőjeleződik a hordozhatóság is.
Ezt nem értem. Ha valaki GUI-s programokat akar írni Win alatt, akkor muszály az inkompatibilis utat választani C-ben! Mert említettem h nagyon le van maradva, ősrégi szabványos könyvtárak vannak C alatt.
Ráadásul a lefordított kód a win32 api-n alapul ami másogy viselkedik Win98 és XP alatt.
NEM a kettő átjárhatóságáról beszéltem. Teljesen mindegy melyik környezetet választod, akkor is beleütközöl a Windows-ok közötti különbségekbe.
[quote:44ff53962c="_Joel"][quote:44ff53962c="Andrei"]
Azt meg egyszeruen keptelen vagyok elfogadni, hogy a GC-t, mint a programtervezest konnyito eszkozt kelljen elkonyvelni.
Hopsz, ilyet nem akartam mondani. En csak azt mondtam, hogy Javaban a memory leak jellegu hibak altalaban tervezesi hibara eredeztethetoek vissza, mig C/C++-ban inkabb programozoi hibakra.
Nem Te mondtad, valamelyik masik nick hozzaszolasaban volt egy ilyen implicit gondolat.
[quote:eee4bb4c55="Csab"]Én személyesen a C++-t szeretem a legjobban.
Az osztályszerkezete jól átgondolt és gyors is.
....
megjelenesekor a jview.exe a microsoft VM sokkal gyorsabb volt mint sun vm
/* sok oka volt, ha valakit erdekel a tortenelem leirhatom */
de, az tetszett, hogy Gyuri egyre azt modogatta, mikor ezt felemlegettem neki:
''.. ez nem igazan gyorsasag, inkabb kapkodas... ,,
szoval c++ sebesseggel is ez a helyzet: kapkodas
igazi sebesseg novekedest ( jobb algoritmus nelkul )
a runtime profiler tud elerni
altalnosan mukodo c++ runtime profiler pedig nem nagyon van..
[quote:443f8208b9="Andrei"]Aztan jon a slusszpoen! Mi van, ha a programod eleve tobbszalu? Egyreszt mindegyikkel szinkronizalnod kell a GC-t, ami nem a jo skalazodas biztositeka.
Gondolom hallottál már arról, hogy a skálázódás nem azt jelenti, hogy minden hipergyors, hanem azt, hogy ha skálázódni kell, akkor tudunk, és nem omlik össze a rendszer, hanem biztosítjuk a folyamatos feldolgozást. Ha bővebben érdekel, akkor a J2EE specifikáció és tutoriálok környékén kezdj el nézelődni... :)
Nyugodtan lehet a szervereket, JVM-eket darabolni, 1-2 GB-on belül jól teljesít a Java GC, több szerver esetén meg biztosított a folyamatos feldolgozás. Aztán majdcsak befejezik a MVM-et, és ez is megoldódik :)
De hogy mondjak okosat is: a Java VM belső kapcsolói lehetőséget adnak arra, hogy szabályozd: maximum mennyi ideig fusson egy GC a teljes prociidő százalékában, ezrelékében akárhányad részében. Azaz legfeljebb annyi ideig fut, közben kidobálja a szemetet és felszabadul a memória. Ha ezt összekötöd object-pool használattal, akkor még azt is meg tudod határozni, hogy mikor fog futni GC.
Nos, bar en meg csak tanulom, de eddigi ismereteim alapjan a velemenyem:
Az IGAZI programozo programnyelvtol fuggetlenul gondolkodik, es nincs szuksege arra, hogy egyetlen programnyelven dolgozzon egesz elete soran.
En szerintem kicsit szetvalasztanam a programozast es a kodolast.
Morzel
Engem pl érdekelne a történelem :)
Csab: ne haragudj, ha offenziv a kerdes, de milyen vegzettseged van, miota es mennyit foglalkozol C++-al es Javaval? Csak azert kerdezem, mert nem tudom eldonteni, hogy mirol es milyen reszletesen irjak az altalad felvetett kerdesekre es "problemakra".
[quote:0c8066541d="syntern"]
Egyreszt azert, mert a C++ operator mogott barmi lehet,...
Igen ez így van...
[quote:0c8066541d="syntern"]
...masreszt mert az operator overloading tenyleg csak macro abban az ertelemben, hogy a vegso binarisban szepen atfordul a megfelelo metodushivasra.
Ha így gondolkodsz akkor az java összes üggvény / osztály használata is csak makró mert "szepen atfordul a megfelelo metodushivasra".
:D
[quote:0c8066541d="syntern"]
Innentol kezdve megint lehet vitatkozni a nyelv szintaktikajan, ami felesleges, mert egyreszt adottsag es nem most talaljuk ki, masreszt osszehasonlitjatok az almat a kortevel, es nem veszitek eszre, hogy mas a celjuk.
Mint már írtam itt nem szintaktikus összehasonlításról van szó.
Ez alapvető elvi / filozófiai kérdés, hogy a nyelv megengedi, a saját operátorok írását. A baj ott van hogy a java-ban az operátorok UTASÍTÁSOK melyeknek a működése bele van drótozva a fordítóba. A c++ esetén a programozó írhat alternatív operátorokat a gyáriak helyett mert azok NEM UTASÍTÁSOK.
Ebből én azt gondolom hogy a c++ hatékonyabb / rugalmasabb mint a java. Ezért a c++ jobb mint a java.
[quote:af1bcb675e="popacsek"]
Összehasonlítottam a java-t többek között a php-vel is, de sebességben nagyságrendbeli a különbség.
Érdekes, én is összehasonlítottam és nekem is nagyságrendbeli különbség lett az alkalmazások sebességében. Csak éppen a PHP javára... :D
[quote:c48834e311="hop1"]És kimaradt a pascal :(
Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban.
[quote:65e1048a52="popacsek"][quote:65e1048a52="syntern"][quote:65e1048a52="ssikiss"][quote:65e1048a52="feledhetetlen"]inkabb ez: erted-e az alapokat, vagy se
aki tudja erre az egyszeru kerdesre a valaszt az erti
aki nem, az csak dumal
Na most akkor lassan már elárulhatnátok, hogy mit kell azon az egy soron látni, hogy más is okuljon a java "szépségeiből".
:?:
El kell ismerni, hogy ez az egyszeru, trivialisan szep pelda tenyleg alaposan megizzaszthatja a C++-t hasznalo, a Javat feluletesen ismero embereket :). Hozzunk egy alternativat, hogy ne csak a Java-ra fujjatok, itt a .NET-es analogiaja:
lock (this) { }
Tenyleg csak azon mulik, hogy valodi OO szemlelet van, vagy csak szintaktikailag kezeled az OO-t....
A: Bibibi! Én tudom, hogy mit jelent a synchronize(this) {}
B: Az mind semmi! Én már használtam is!
A: Az is valami? Én javasoltam a SUN-nak, mikor megalkották a java-t!
B: Nekem öcsém? Nem hiszem! A java-t én találtam ki egyedüll!
.
.
.
8-)
milyen lenne, ha vicc helyett valaki leirna...
csak azert gondolom mert itt ugy dobaloztok a multithread meg "atomi muvelet" dumaval, hogy ez nem jelenthet problemat...
ez nem a nyelv szepsege, ez kulcsszo szintu ismerete annak amirol elszantan irogattok...
csak azt ertem ebbol a postbol: vicces szeretnel lenni, de a valaszt nem tudod
[quote:f1c554421e="lokoto"]
Az egyetlen probléma, hogy jelen esetben nincs "adott környezet", sem "adott feladat"...
Nincs környezet? Nincs feladat?
Amikor megírsz egy programot akkor mit csinálsz?
A környezet a számítógép és az a rendszer ami alá a programot írod, valamit az eszközök amiket felhasználhatsz.
A feladat az amit majd a program megírása során megoldasz.
A kérdés az hogy a programnyelv hogyan viszonyul ezekhez a dolgokhoz. Van amelyik jobban van és van olyan amelyik kevésbé.
[quote:f1c554421e="lokoto"]
Azaz ebből az esetből (op overloading) megállapítod, hogy a Java filozófiája rosszabb. Holott ez csak egyetlen kérdés a sok közül egy nyelv/platform esetén.
Az előző hozzászólásomban leírtam...
[quote:a4be8719ce="syntern"]Lehet hogy én látom rosszul, de ha adsz interfészeket és doksit (= a másik oldal tudja, hogy mit fog kapni), akkor nincs szükség reflectionre. A reflection ott kell, ahol nem tudod, hogy mit kapsz.
Ja, hogy reflection-ről beszélünk? Olyan biza C++-ban nincsen (typeid van, de az kevés). Ilyen-olyan megoldások (Managed Extensions for C++) vannak.
[quote:11c25f9923="Frimen"]
Ugye tesztelési, átvételi stb. jegyzőkönyvről még nem is hallottál?:)
Ugye verifikaciorol meg nem is hallottal :D Az eddigi hozzaszolasaid alapjan (kinyomtatja a bytecodot) nagyon-nagyon ugy tunik. A teszteles egyaltalan nem garantalja a hibamentesseget, de meg azt atveteli jegyzokonyv sem.
[quote:11c25f9923="Frimen"]
A szerződések kitételeiről a felelősség kérdésében nem is beszélve..:)
Tudhatnad, hogy torvenyesen nem lehet korlatlanul felelosseget kizarni. Egy szerzodeshez pedig ket fel kell, persze probalkozhatsz, max massal kotnek szerzodest.
Villamos mérnök vagyok és kb. 3 éve foglalkozom java-val.
C-vel 12
C++-szal 10
Egyébként informatikus állásban dolgozom.
[quote:3e74620e1a="syntern"][quote:3e74620e1a="bocs"]nem tudom, ez nálad valami fixa idea lehet, hogy a c++ malloc az nem képes a felszabadított blokkok utólagos egyesítésére.
Talán azért, mert úgy gondolom, hogy a mutatók miatt ez nem lehetséges. Persze ha tudsz jó példát hozni, akkor ezt beláthatom, hogy mégis lehetséges.
Kérlek, alaposabban olvass.
felszabadított blokkok utólagos egyesítése triviális, pointerek nem játszanak.
Példa: adtam, lásd Microsoft implementáció.
Az igazi programozó FORTRANban dolgozik....
ES NEM NAGYON ER RA FORUMOZGATNI:)
tortenelmi pillanatnak vagyunk tanui; a c-betus assembly megelozte a spagettit a szavazasban
[quote:faa5ff9448="bocs"]
felszabadított blokkok utólagos egyesítése triviális, pointerek nem játszanak.
De a Java a fel nem szabaditott blokkokat is at tudja rendezni (defragmentalni) - a stop & copy vagy mark & copy algoritmus pont errol szol... Syntern erről beszélt.
tolmi, a célom nem a php fikázása volt. Az állításodat meg nem hiszem el.
[quote:9eb2fee226="feledhetetlen"]
csak azt ertem ebbol a postbol: vicces szeretnel lenni, de a valaszt nem tudod
Nem akartam leírni, mert akkor közkincs lesz ez a überfasza jelentkező-fingatós feladat. Ha megadom a választ, mit fogsz kérdezni a következő "interview" alkalmával?
Piszkálódást félretéve: valaki vagy tudja, hogy mit jelent java-ban a "synchronized", vagy nem. Ha tudja, akkor a feladatod megoldása TRIVIÁLIS. Ez olyan mintha azt kérdeznéd, mit jelent az, hogy "a++;".
Ha valaki tudja, hogy mit csinál a ++ operátor, akkor a feladat nem feladat, csak annak látszik.
[quote:293ffbd1df="bocs"][quote:293ffbd1df="syntern"][quote:293ffbd1df="bocs"]nem tudom, ez nálad valami fixa idea lehet, hogy a c++ malloc az nem képes a felszabadított blokkok utólagos egyesítésére.
Talán azért, mert úgy gondolom, hogy a mutatók miatt ez nem lehetséges. Persze ha tudsz jó példát hozni, akkor ezt beláthatom, hogy mégis lehetséges.
Kérlek, alaposabban olvass. felszabadított blokkok utólagos egyesítése triviális, pointerek nem játszanak. Példa: adtam, lásd Microsoft implementáció.
Kérlek gondold át:
0000: szabad memória blokk
0010: szabad memória blokk
0020: ide mutat egy pointer
0030: szabad memória blokk
A 00, és 10 összevonása triviális. Viszont a 00, 10, 30 egybevonása már nem az. A Java ezt tudja, és a C++ nem, implementációtól függetlenül, ugyanis nem tud mit mondani a pointerre.
[quote:60967c80c5="lokoto"]
...mert javában nem tudsz *a-t írni, ezért ha az a = b-t felüldefiniálod a = b.clone() funkcionalitására, nem tudod miként megvalósítani a jelenlegi értelemben vett a = b műveletet, azaz hogy az a változó a b változó által mutatott objektumra mutasson.
Itt érkeztünk el ahhoz a ponthoz hogy saját magad mondod ki azt, hogy a java filozófiája rosszabb mint a c++. :)
Fölösleges megkötésekkel gátat szab saját maga kifejező erejének...
[quote:60967c80c5="lokoto"]
Lehet, hogy csak megszokás, de az =-nek ez a funkcionalitása logikusan ábrázolt, és a clone() kitűnően kifejezi, hogy mélymásolást kell csinálni.
Korábbi hozzászólásomban (induljunk el a kályhától) kifejtettem hogy szerintem egyáltalán nem természetes a java filozófiája.
[quote:f4d052179b="Morzel"]Nos, bar en meg csak tanulom, de eddigi ismereteim alapjan a velemenyem:
Az IGAZI programozo programnyelvtol fuggetlenul gondolkodik, es nincs szuksege arra, hogy egyetlen programnyelven dolgozzon egesz elete soran.
En szerintem kicsit szetvalasztanam a programozast es a kodolast.
Morzel
ez teljesen jogos.
én úgy érelmezem, hogy most épp mi a kedvenc programozási nyelvem.
15 éve pl. a c64 assembly volt. :)
[quote:e5861f228f="Panther"][quote:e5861f228f="Chain-Q"]jon valaki okostojas, es kozli h. szerencse h. kimaradt a Pascal, es persze nem mulasztja el bepastelni a hatulgombolosozos dumat. De hat ez mar nem engem minosit.
Sajnos téged minősít. "szerencsére" - ezt én írtam, a másikat meg nem.
Oromomre szolgal, hogy akinek inge, az feloltozkodik vegre... :)
He? Mivan az ifekkel?
He?! Mit nem lehet az End elott? Biztos ugyanarrol a nyelvrol beszelunk?
[quote:57950accba="drojid"]Engem pl érdekelne a történelem :)
akkor a kedvedert (es az archivumnak):
1.)
eloszor is azert volt gyorsabb, mert a microsoft-nal volt Compiler
a sun java vm ugy jelent meg, hogy csak interpreter volt
nem egy nagy dolog mert a P-code compiler mar a kezukben volt
azt viszonylag konnyu java byte-code-ra at borzolni
2.)
a sun vm green thread-del jelent meg a microsoft vm legelso valtozata mar nativ thread-es volt
/* amugy szemely szerint hianyolom a green thread-et */
3.)
a microsoft vm class loader-e elore forditott osztalyokat toltott, volt egy
egyszeru adatbazis ami timestamp alapjan ujra forditott, ha szukseges volt
igy a toltesi ideju forditassal a sun vm komoly hatrannyal indult
a microsoft vm sikeret joreszt egy Brad Silverberg nevu fickonak koszonhetik
O volt a szemelyzetis a Borland-nal es o volt az elso akit elcsabitottak
ezzel persze megvettek maguknak azt a tudomanyt, hogy kit erdemes megvenni a Borland-tol, peldaul a turbo pascal ota cummulalodo tudast
ezt onnan tudom, hogy a regi Quattor (egy borland spreadsheet) team Cseri Istvan, Frank Lajos (isten nyugosztalja) is atmenetelt a microsoft-hoz
a sun vm koncepcioja napjainkban 'erik be' a runtime profiler ( kulonosen "java -server" ) olyan sebesseg novekedest tud elerni ami a 'hulye' programot is fel tudja gyositani
jegyzem a legsotetebb pont a java tortenelmeben eppen a hotspot korul alakult ki (de ez mar egy masik tortenet...)
[quote:52f218df0f="Csab"]Security azért nincs C-ben, mert nincs rá szükség. A processzeket az operációs rendszer kézbentartja.
Ugyanez java alkalmazások esetén is megy, hogyha különböző JVM-ekben futnak. Ez viszont túl nagy ár a Security-ért. Eszméletlenül sok memóriát igényel párhuzamosan futtatni 5-6 JVM-et. A JVM-ek közti kommunikáció, objektumok átadása sem túl kecsegtető.
Éppen ezért találták ki a java-s security-t. Ez egy jó ötlet volt, csak pocsék megvalósítás mellett. Mindegy. Ez van, ezt kell szeretni, vagy elviselni.
Valahogy azt latom, (es ezert kerdeztem), hogy bar eleg regota foglalkozol Javaval, legfeljebb feluletesen tetted eddig. Ha egy kicsit is kovetted az esemenyeket, akkor tudod, hogy mostanra a JVM-ek kihasznaljak a shared memory-t, azaz JVM-enkent maximum nehany MB plusszra lehet szamitani, alig tobbre, mint a kulon process nativ alkalmazasoknal. Mielott ezt megprobalod banalis modon cafolni: mi 40 darab kulonallo JVM-et futtatunk egyetlen gepen a laborban, es ha nem tudnak hatekonyan megosztani a memoriat, akkor kb. ketszer annyi memoriat foglalnanak, mint a maximalis memoria a gepben. Igy meg meg eppen belefernek a fizikai memoriaba (igen, ezt is kimertuk :)).
A JVM-ek kozotti objektum atadasakor en elsosorban az RMI-re gondolok. Ha nem Java alkalmazas van, akkor egyeb socket-kezeles, vagy csak bonyolultabb protokoll jon szoba. A Java semmivel sem csinal mast, mint mindenki mas, a kulonbseg, hogy RMI-t fejleszteni alig nehany sor. Szoval nem ertem ezt a kommunikacio reszt sem.
Tovabba nem ertem a security-n valo lovaglast. Tudnal mondani egy alkalmazasi peldat, ahol ki kellett hasznalnod a Java security-t, maskeppen nem vagy csak csunyan lehetett volna megoldani?
Megpróbálom összefoglalni a lényeget.
1. Megalkották a C++-t, az egész jóra sikerült, de leálltak a további szabványosítással. Mindenki olyan könyvtárat ír, amilyet akar.
2. Megalkották a java-t és továbbra is fejlesztik, egy kézben van, ezért egységes megoldásokat használnak
A java fokozatosan fejlődik, míg a C++ áll. Persze hallottam, hogy beszélnek már az új C++ szabványról is...
A probléma valahol ott van, hogy nincsenek egységes C++-os könyvtárak úgy, ahogy java-ban.
Nekem személyesen a C++ magja, az alap szerkezete jobban tetszik, mint a java alap szerkezete. A C++ gazdagabb, míg a java az equals metódusaival fapadosnak tűnik. Egy választékos nyelven könnyebben fejezed ki magad. :-)
Ha a java olyan lenne, hogy a C++-os osztályszerkezeteket használná, én is java-s lennék. Számomra nehézkesnek tűnik az egész és áttekinthetetlen.
Elsősorban érzelmi okai vannak, hogy C++-t használok. Sokkal szebb és választékosabb a C++-os kifejezés forma.
[quote:4a27e5504f="popacsek"]tolmi, a célom nem a php fikázása volt.
Nekem sem célom a Java fikázása, tekintve hogy jómagam is használom(J2EE).
[quote:4a27e5504f="popacsek"]Az állításodat meg nem hiszem el.
LOL :) Értettem. Elfogadva. :D
[quote:8ecab8dcbb="lacipac"][quote:8ecab8dcbb="hop1"]És kimaradt a pascal :(
Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban.
http://www.wizzy.com/andyr/Mel.html
[quote:45ec10abff="handler"]
Tudhatnad, hogy torvenyesen nem lehet korlatlanul felelosseget kizarni.
Tudnál jogszabályra hivatkozni?
Nekem laikusként úgy tűnik, nincs igazad. Gondolok pölö a "Magas feszültség! Életveszély!" táblára. Gondolom ezzel analóg módon, ha a programod forrásába/dokumentációjába, első megjelenő felhasználói interfészébe beleírod, hogy nem vállalsz felelősséget, akkor csak nem verhetik el a port rajtad, nem?
Teljesen már szemszögből szemléljük a világot.
Én mobiltelefonokkal foglalkozom. Plusz néhány megabyte tudod mit jelent mobil telefonoknál?
A Security nekem azért fájó pont, mert sajnos "felsőbb döntésre" security-t is kellett implementálnom. No most valami hihetetlen értelmetlen dolgokkal kellett foglalkoznom ezalatt.
Pl. az összes:
AccessController.check( perm );
hívást le kellett cserélnem
SecurityManager sm = System.getSecurityManager();
if( sm != null )
sm.check( perm );
-re, minthogy az AccessController.check nem működik helyesen minden esetben. Szóval leimplementáltam a security-t, fogalmam sincs, hogy mi miért úgy megy ahogy, a tesztek végig futottak, többet nem akarom látni.
Sajnos nagyon mély vízbe dobtak legutóbb, mert a security mellett ClassLoader-t is kellett írnom, reflection-özni és a ProtectionDomain átizélgetése után eljutottam odáig, hogy elegem van a java-ból.
[quote:0ec746cb55="hanischz"]
Ezt nem értem. Ha valaki GUI-s programokat akar írni Win alatt, akkor muszály az inkompatibilis utat választani C-ben! Mert említettem h nagyon le van maradva, ősrégi szabványos könyvtárak vannak C alatt.
Ez igy természetes... miért várod el azt hogy a c++ tartalmazza a vindóz specifikus dolgokat? Mert akkor ne tegyünk kivételt és tartalmazhatná a világ összes specifikus dolgát is... a mikrokontrollerektől a szuperszámítógépekig... lehetőleg nem kifelejtve az összes létező oprendszer dolgait... nem?
[quote:0ec746cb55="hanischz"]
Ráadásul a lefordított kód a win32 api-n alapul ami másogy viselkedik Win98 és XP alatt.
Erről szerintem az m$ tehet... írjon olyan könyvtárat meg fordítót ami az összes vindózon egyformán működik.
[quote:0ec746cb55="hanischz"]
NEM a kettő átjárhatóságáról beszéltem. Teljesen mindegy melyik környezetet választod, akkor is beleütközöl a Windows-ok közötti különbségekbe.
Meg erről is az m$ tehet... szerintem.
Ha a szabványos könyvtárakat használod akkor az garantáltan működni fog mindenhol. A C++ nem akar egy olyan standard library-t csinálni amiben minden benne van. Olyat nem lehet csinálni. Illetve a java próbálkozik... :) Viszont ad egy olyan eszköztárat amivel könnyen, kis ráfordítással készíthetsz dolgokat a meglévőkből.
[quote:b6c1916799="syntern"][quote:b6c1916799="Andrei"]Aztan jon a slusszpoen! Mi van, ha a programod eleve tobbszalu? Egyreszt mindegyikkel szinkronizalnod kell a GC-t, ami nem a jo skalazodas biztositeka.
Gondolom hallottál már arról, hogy a skálázódás nem azt jelenti, hogy minden hipergyors, hanem azt, hogy ha skálázódni kell, akkor tudunk, és nem omlik össze a rendszer, hanem biztosítjuk a folyamatos feldolgozást. Ha bővebben érdekel, akkor a J2EE specifikáció és tutoriálok környékén kezdj el nézelődni... :)
Nyugodtan lehet a szervereket, JVM-eket darabolni, 1-2 GB-on belül jól teljesít a Java GC, több szerver esetén meg biztosított a folyamatos feldolgozás. Aztán majdcsak befejezik a MVM-et, és ez is megoldódik :)
De hogy mondjak okosat is: a Java VM belső kapcsolói lehetőséget adnak arra, hogy szabályozd: maximum mennyi ideig fusson egy GC a teljes prociidő százalékában, ezrelékében akárhányad részében. Azaz legfeljebb annyi ideig fut, közben kidobálja a szemetet és felszabadul a memória. Ha ezt összekötöd object-pool használattal, akkor még azt is meg tudod határozni, hogy mikor fog futni GC.
Parhuzamos linearis egyenletrendszer megoldot fejlesztettem Fortran/C/C++-ban. "Nagyjabol" vagom, hogy mi a skalazodas.
A GC-vel kapcsolatos elvaras jogosan lenne az, hogy linearishoz kozeli skalazodast mutasson. Mondjuk, hogy egy 5 szalon kiegyensulyozottan futo program egy 8 procis gepen fusson mar kb. 5-szor gyorsabban, mint egy procin. Maskulonben nem lenne ertelme megvenni ezeket a szep nagy napocskaslogos szervereket.
Egyreszt azert mert a jelenlegi "in-process GC" megkozelites -gondolom- eleg jol mukodik (csakugye visszafogja a fo programszalat), meg szepen is skalazodik. Namost kiontod a gyereket a furdovizzel, ha ehelyett beultetsz egy olyan strategiat, ami nem fogja vissza a fo programjaidat, viszont lepten nyomon egymas tyukszemere lepnek a programszalak meg a GC. Ez tipikus skalazodasi problema... Attol meg, hogy helyesen mukodik egy SMP-n, meg nem skalazodik jol a programod.
Az object pool nekem nem tetszo megoldas. Nem arrol volt szo, hogy automatikus memoriakezelest szeretnenk? Akkor miert is szarakodunk object-pool-lal?
[quote:5209d94681="feledhetetlen"]hogy kit erdemes megvenni a Borland-tol
Anders Heljsberg ;)
-server kapcsoló, gondolom, csak sun jvm része, mert mi IBM-es jdk-t használunk és ott nem nagyon látszik működni.
Amúgy szerencsétlen IBM jdk gyorsabb lenne, mint a SUN, vagy tévedek?
synchronize( this ) {}
A következőt csinálja:
Amennyiben a this változó lokkolva van, akkor vár.
Ha nincs lokkolva, keresztül megy rajta.
Mit lehet elmondani synchronized( this ) után?
- Aki a meghívásig lokkolta a this objektumot, az elengedte.
Indítasz egy Thread-et, ami lokkolja a this-t, amíg fut.
A synchronize { this } {} meg fogja várni, hogy a thread véget érjen és csak aztán megy tovább.
Egyébként ennek a példának semmi értelme sincs, mert a Thread.join() sokkal elegánsabb és érthetőbb is.
[quote:cedb9acadc="syntern"]0000: szabad memória blokk
0010: szabad memória blokk
0020: ide mutat egy pointer
0030: szabad memória blokk
A 00, és 10 összevonása triviális. Viszont a 00, 10, 30 egybevonása már nem az. A Java ezt tudja, és a C++ nem, implementációtól függetlenül, ugyanis nem tud mit mondani a pointerre.
hehe
keverjük itt a szezont a fazonnal
milyen megoldás révén tudja ezt a Java? Plusz erőforrás felhasználás révén (GC CPU idő, objektum referenciák vagy refcount, dupla(!!) heap méret a szükségeshez képest, nemdeterminisztikus viselkedés).
Tehát a GC költséget mindig megfizetteti veled, még akkor is, ha nyugodtan lehetne használni adott feladathoz determinisztikus allokációt/deallokációt.
Java-ban van választási lehetőséged, hogy GC-t vagy determinisztikus allokációt használsz ? Nincs.
C++-ban van? Igen, van.
C++ -os GC használata esetén lehetőséged van a heap fragmentáció megszüntetésére, például objektum áthelyezéssel, saját new operátor létrehozásával. Ennek meg kell fizetned az árát, pl refcount-ok / objektum referenciák lefoglalásával, fenntartásával, menedzselésével.
Szépen lehet így a körkörös referenciákat is kezelni.
Amikor csökkentem a saját objektumom referenciáját, megnézem, hogy van-e visszareferáló objektum. Ha annak 1 a referenciája és nekem is 1, akkor felszabadítható. Nagyobb ciklusok is detektálhatóak.
Persze való igaz, hogy mindenegyes referenciacsökkentésnél elvégezni ezt a szmötyit időigényes.
Persze a körkörös referenciákat cache-elni is lehet, így gyorsabb lesz.
Cserébe rendes destruktort kapunk, nem olyat, ami csak úgy ad hoc garbage collection-nél meghívódik. A C++-os destruktor nagyon hiányzik java-ból.
[quote:4ea31356be="Csab"]A Security nekem azért fájó pont, mert sajnos "felsőbb döntésre" security-t is kellett implementálnom. No most valami hihetetlen értelmetlen dolgokkal kellett foglalkoznom ezalatt.
Továbbra sem látom, hogy miért szidod a Java Security-t, csak azt látom, hogy valami ismeretlen dolgot kellett alkalmaznod munka közben, ami nem volt kellemes. Még mindig nem látom, hogy mire kellett használni Security-t és hogy arra a Java miért volt kényelmetlen.
[quote:4ea31356be="Csab"]Sajnos nagyon mély vízbe dobtak legutóbb, mert a security mellett ClassLoader-t is kellett írnom, reflection-özni és a ProtectionDomain átizélgetése után eljutottam odáig, hogy elegem van a java-ból.
Ez korántsem biztos, hogy a Java hibája, nem gondolod? :)
[quote:c5fb258821="maszili"]Ebből én azt gondolom hogy a c++ hatékonyabb / rugalmasabb mint a java. Ezért a c++ jobb mint a java.
Azt kifelejtetted, hogy pointerek is vannak benne :P
Bocs, h beleszólok a nagyok dolgába, de engem nemrég ez eléggé meglepett:
http://www.bytonic.de/html/benchmarks.html
ofkoz a játék nem egy mai darab, viszont az sem mondható rá, hogy vmi láma programozta, és optimalizálatlan :)
[quote:536c2f9f47="Csab"]A C++-os destruktor nagyon hiányzik java-ból.
A Java-s GC nagyon hiányzik a C++-ból.
Ennek a kijelentésnek kb ennyi értelme volt. Az előtte lévőknek még ennyi sem (hidd el, hogy komoly, akadémiai emberek foglalkoznak a gc témáinak kutatásaival nagy cégeknél és egyetemen egyaránt. Az előbb általam említett weboldalon publikációk tucatjait találod, amiken ha átrágod magad, akkor sokkal komolyabb érvekkel fogod tudni alátámasztani, hogy miért sz@r a gc úgy, ahogy van - ugye nem okoz gondot, hogy angolul vannak?)
Nem feltétlenül. Olvasnivalók:
http://java.sun.com/docs/hotspot/gc1.4.2/
http://www-128.ibm.com/developerworks/java/library/j-jtp01274.html
Mert szerinted a gc-t nem programozó írta? Dobjuk ki a libeket is, mert más írta? Nem értelek:)
Nem egy malomban őrlünk. Természetesen akár asm-ben is mindent meg lehet írni, még performant is lesz, mert a drága CALL-ok helyett trükközhetsz sima ugrásokkal, stack használat helyett írhatsz önmódosító kódot ami MOV-okba rakosgatja a regiszterek értékét (386-on 2-3 óraciklust is lehetett nyerni ezekkel a trükkökkel). Tök gyors lesz. Meg tudod tervezni, hogy minden elférjen a regiszterekben, tudod, hogy melyik szegmens szelektort mire használod. Mindent meg lehet csinálni. Én is vagy egy évig irkáltam egy lemezújság kódját, realflat-tel, meg svga grafikával, stb stb (igaz ez még gimnáziumban volt).
A GC ugyanolyan fejlődési lépés a programozási nyelvek történetében, mint az asm-ről a C-re lépés, vagy az objektumorientáltság megjelenése. Gyorsítja a programozást, mert leveszi a programozó válláról a memóriamenedzsment feladatát. Ez a programozási feladatok 95%-ban nem gond, mert nem jár olyan teljesítményvesztéssel, ami elfogadhatatlan lenne az adott alkalmazás/projekt szempontjából, ugyanakkor meg lényegesen könnyíti a fejlesztést. Gyengébbek kedvéért: ugyanazt a feladatot a C++-ban fejlesztő cég 25 millió forintért vállalná be és 12 hónap alatt szállítaná az árut, a Javas cég meg 14 millió forintért vállalja be és 6 hónapos határidőt vállal (kötbérestül, mindenestül). A program végül egy olyan rendszerre kerül, ami 1 millió forintba kerül: ha teljesítményprobléma van, vesznek még 1 millióért még egy gépet. Megéri 11 millióval többet kifizetni egy elméleti 20-25%-os teljesítménytöbbletért és megéri még fél évet várni az adott online szolgáltatás beindítására?
[quote:2781c07bc0="Csab"]synchronize( this ) {}
A következőt csinálja:
Amennyiben a this változó lokkolva van, akkor vár.
Ha nincs lokkolva, keresztül megy rajta.
Mit lehet elmondani synchronized( this ) után?
- Aki a meghívásig lokkolta a this objektumot, az elengedte.
Indítasz egy Thread-et, ami lokkolja a this-t, amíg fut.
A synchronize { this } {} meg fogja várni, hogy a thread véget érjen és csak aztán megy tovább.
Egyébként ennek a példának semmi értelme sincs, mert a Thread.join() sokkal elegánsabb és érthetőbb is.
egyebkent rad gondoltam mikor irtam
ha elolvastad volna 1szer is nyelv meghatarozasat tudnad:
van nehany muvelet amit mindig meg KELL csinalnia a vm-nek
mikor belep egy szinkronizalt block-ba
ezek kozul az egyik peldaul az, hogy a monitor owner volatile valtozoit kiirja a memoriaba....
ja, hogy mi is az a volatile valtozo?
[quote:4f3ac11293="Exit"]Azoknak meg, akik azt mondják, hogy Java-ban a hülyék programoznak: :lol:
Én szeretem a C-t és a C++-t, de azért egy Java... Az osztálykönyvtára, meg a platformfüggetlensége meg az, hogy fél óra alatt összehozok egy J2EE webservice-t, hozzá egy webes, egy J2SE-s és egy mobilos klienst... Ekkora produktivitást mikor kapok én a C++-tól?
Hallottál már a GSoap-ról?
Java-ban elvileg van destruktor, gyakorlatilag nincs. A finalize metódus meghívódik ugyan a GC-ben, de ez nem ér semmit.
Képzeld el:
- Egymás után megnyitsz fájlokat, de nem zárod be őket.
Mielőtt a GC elkezdene dolgozni, a maximálisan megnyitható fájlok
számát simán elérheted. Aztán nem érted, miért hal be a program.
Éppen ezért a fájlokat, stream-eket illik close()-olni, mert amíg a GC fel nem szabadítja őket, addig igen sok erőforrást elvisznek.
adalek a java&sebesseg temahoz: http://chromethegame.com/en/show.php
[quote:2a2b091755="Csab"]Aztán nem érted, miért hal be a program.
Bizony. És inkább elmegyek asztalosnak, hátha ahhoz több tehetségem van:)
A java API dokumentációja meglehetősen jó. Olvasod a függvény dokumentációját, érted, hogy mit csinál. Jóformán kézenfekvő.
Ez a security dokumentációról nem teljesen mondható el. Sőt, nagyon kevés kézenfekvő dologgal találkozik az ember. Nem logikus és struktúrálatlan. Szóval megőszülsz, mire a legelső sort képes vagy megírni security-vel.
[quote:f03ebfd139="maszili"][quote:f03ebfd139="lokoto"]
Az egyetlen probléma, hogy jelen esetben nincs "adott környezet", sem "adott feladat"...
Nincs környezet? Nincs feladat?
Amikor megírsz egy programot akkor mit csinálsz?
Itt nem egy konkrét programról van szó, hanem általánosan állapítod meg, hogy a Java filozófiája rosszabb, mint a C++.
[quote:f03ebfd139="maszili"]
Pontosítsunk!
Valójában halvány fogalmad sincs, hogyan csinálja.
Ez így helyes.
Mivel OO -rol beszélünk nincs rá szükségem és nem is érdekel... nekem pont elég egy absztakciós szinttel feljebb lévő problémával foglalkozni.
Ha jól látom még mindig nem árultad el, hogy ennek fényében hogy raknád bele az egész számokat 1-től 500000-ig egy java.util.ArrayList-be.
[quote:e06aaa3ed8="_Joel"]Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
Hat most nem tudom, hogy ez marketing duma, vagy csak szimplan nagyotmondas. Egyik sem tul szimpatikus.
[quote:791bb27225="Morzel"]Nos, bar en meg csak tanulom, de eddigi ismereteim alapjan a velemenyem:
Az IGAZI programozo programnyelvtol fuggetlenul gondolkodik, es nincs szuksege arra, hogy egyetlen programnyelven dolgozzon egesz elete soran.
En szerintem kicsit szetvalasztanam a programozast es a kodolast.
Morzel
Az igazi programozo gondolkodik es tanul, aztan:
-megtervezi/megvalositja sajat forditoprogramjat
-megtervezi/megvalositja sajat programozasi nyelvet
-megtervezi/megvalositja sajat architecturajat
;-)
ugyan sose fejlesztettem nagyobb java programot, de kíváncsi vagyok miért.
Ugh, a chrome javában iródott? :o
[quote:60b375c0c7="Csab"]A java API dokumentációja meglehetősen jó. Olvasod a függvény dokumentációját, érted, hogy mit csinál. Jóformán kézenfekvő.
Ez a security dokumentációról nem teljesen mondható el. Sőt, nagyon kevés kézenfekvő dologgal találkozik az ember. Nem logikus és struktúrálatlan. Szóval megőszülsz, mire a legelső sort képes vagy megírni security-vel.
Most ugyanarról beszélünk? http://java.sun.com/docs/books/tutorial/security1.2/
A kérdésemre (hogy miért Security, mire kellett használni) még nem adtál választ, csak kikerülted...
[quote:68b53a8b0f="Frimen"]Nem látom sehol a két kodot..:))
Én legalább beirtam a sajátom "üssetek agyon, ha.." alapon, de Te eddig csak a levegőbe beszéltél. Amugy nekem már az a sorrol sorra ugyanaz enyhén szolva röhelyes..:-) Szerintem van itt egy két C-s programozo, aki szivesen vetne pár pillantást arra a kodra.. én meg a java-s oldalára.
[code:1:68b53a8b0f]
class QuickSort{
static final int NUM_ITEMS = 50000000;
int[] numbers=new int[NUM_ITEMS];
public void initTomb(){
numbers[0]=1;numbers[1]=1;
for(int i=2;i<NUM_ITEMS;i++)
numbers[i]=(numbers[i-1]*3+numbers[i-2]*2)%4561;
}
public void sort(int bal, int jobb){
int i, j;
int elvalaszto;
int temp;
elvalaszto=(int)numbers[(bal+jobb)/2];
i=bal;
j=jobb;
while (i<=j){
while (numbers[i]<elvalaszto) i++;
while (numbers[j]>elvalaszto) j--;
if (i<=j) {
temp=numbers[i];numbers[i]=numbers[j];numbers[j]=temp;
i++; j--;
}//if
}//while
if (bal<j) sort(bal,j);
if (i<jobb) sort(i,jobb);
}
public static void main(String[] args){
long time_start;
long time_stop;
long duration;
QuickSort qs = new QuickSort();
for(int i=0; i<30; i++){
time_start=System.currentTimeMillis();
qs.initTomb();
qs.sort(0,NUM_ITEMS-1);
time_stop=System.currentTimeMillis();
duration=time_stop-time_start;
System.out.println(" "+duration);
}
}
}
[/code:1:68b53a8b0f]
[code:1:68b53a8b0f]
#include <stdio.h>
#include <stdlib.h>
#include<sys/types.h>
#include<sys/time.h>
#include<time.h>
#define NUM_ITEMS 50000000
class QuickSort {
public:
int* numbers;
void initTomb();
void sort(int, int);
};
void QuickSort::initTomb(){
numbers[0]=1;numbers[1]=1;
for(int i=2;i<NUM_ITEMS;i++)
numbers[i]=(numbers[i-1]*3+numbers[i-2]*2)%4561;
}
void QuickSort::sort(int bal, int jobb){
int i, j;
int elvalaszto;
int temp;
elvalaszto=(int)numbers[(bal+jobb)/2];
i=bal;
j=jobb;
while (i<=j){
while (numbers[i]<elvalaszto) i++;
while (numbers[j]>elvalaszto) j--;
if (i<=j) {
temp=numbers[i];numbers[i]=numbers[j];numbers[j]=temp;
i++; j--;
}//if
}//while
if (bal<j) sort(bal,j);
if (i<jobb) sort(i,jobb);
}
int main(){
int i=0;
int l,duration;
timeval start_time, end_time;
QuickSort qs;
qs.numbers = new int[NUM_ITEMS];
for(l=0;l<30;l++){
gettimeofday(&start_time, (struct timezone*)0);
qs.initTomb();
qs.sort(0,NUM_ITEMS-1);
gettimeofday(&end_time,(struct timezone*)0);
duration= (end_time.tv_sec-start_time.tv_sec)*1000000+
(end_time.tv_usec-start_time.tv_usec);
printf(" %d\n",duration/1000);
}//for
return 0;
}
[/code:1:68b53a8b0f]
Bizonyára lehet máshogyan is csinálni részleteket, de tagadhatatlanul működik, és az a "röhejes" sorról sorra kód is látszódik, ha nem tévedek.
[code:1:68b53a8b0f]
$ g++ quick_sort.cpp
$ ./a.out
24190
23991
23996
23996
[/code:1:68b53a8b0f]
[code:1:68b53a8b0f]
$ g++ -O1 quick_sort.cpp
$ ./a.out
13123
12837
12881
12887
[/code:1:68b53a8b0f]
[code:1:68b53a8b0f]
$ g++ -O3 quick_sort.cpp
$ ./a.out
11521
11407
11301
11352
[/code:1:68b53a8b0f]
[code:1:68b53a8b0f]
$ javac QuickSort.java
$ java -cp . -Xmx250M QuickSort
16612
16667
16620
16724
[/code:1:68b53a8b0f]
[code:1:68b53a8b0f]
$ javac QuickSort.java
$ java -cp . -Xmx250M -server QuickSort
12583
12480
12497
12515
[/code:1:68b53a8b0f]
A számokat mindenki értékelje maga. Én azt olvasom ki ebből, hogy nem látom okát annak, hogy ne használjak Java-t akkor, ha abban nagyságrendekkel hamarabb oldok meg feladatot. Futásidőben nem rosszabb lényegesen, a -O3 esetleg lekörözi, mondjuk 10%-kal, ami egyrészt hibahatár, másrészt ritkán szoktak -O3-at használni, ha jól tudom, optimalizáció nélkül pedig magasan jobb mint a C++.
Egy kis infó a gépemről:
[code:1:68b53a8b0f]
$ cat /proc/version
Linux version 2.6.12-10-386 (buildd@terranova) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 Fri Nov 18 11:51:02 UTC 2005
$ g++ --version
g++ (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
$ java -version
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 47
model name : AMD Athlon(tm) 64 Processor 3000+
stepping : 0
cpu MHz : 1808.124
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm
bogomips : 3579.90
[/code:1:68b53a8b0f]
Engem egyáltalán nem érdekel a GC dokumentációja, mert szerintem koncepcionálisan van eltolva az egész.
Persze úgy tudom, amikor a java-t készítették, akkor is komoly harc volt a rendes destruktor pártiak és a GC-sek között. Sajnos a GC-sek győztek, pedig szerintem GC nélkül is megoldhatták volna az egészet.
Lennének jól használható destruktorok a java-ban és 10-szer olyan szépen lehetne java-ban programozni.
Teljesen logikátlan viselkedés az, hogy vezérelheted az objektum létrehozását, viszont nem vezérled az elpusztítását.
A legszebben a QT csinálja.
A "delete objektum" hatására felszabadítja az objektumot és a rá mutató referenciákat kinullázza. Ezt egy destroyed() szignál emittálásával éri el.
QT-ben van rendes destruktor,
a szerkezete miatt pedig kevés a Free Memory Read fagyás is.
[quote:457499ee04="maszili"]Hát nekem ez akkor sem tetszik... :)
Szerintem egyszerűbb az osztály destruktorában felszabadítani az osztály objektuma által használt erőforrásokat. Ha ott megírtam a kódot (ami ugye egy rendes OO objektumhoz hozzátartozik mert hát én tudom hogy mit, mire és hogyan használok az osztályban) akkor elfelejthetem a problémát.
Így automatikusan felszabadul az összes felhasznált erőforrás pontosan akkor amikor megsemmisül az objektum.
Persze, csinalhatod igy is. Amig nem adom kozre az en kodjaimat (varhatoan hetvege), probald ki a kovetkezot: hozz letre 200.000.000 objektumot C++-ban es Javaban is, C++ hivd meg meg a delete-et is ra. Ne legyen az adott osztalyon belul semmi mas, csak maga az osztaly, hogy tenyleg semmilyen zavaro tenyezo ne legyen. Merd az idot :)
[quote:2bcfcfd796="bocs"][quote:2bcfcfd796="syntern"]0000: szabad memória blokk
0010: szabad memória blokk
0020: ide mutat egy pointer
0030: szabad memória blokk
A 00, és 10 összevonása triviális. Viszont a 00, 10, 30 egybevonása már nem az. A Java ezt tudja, és a C++ nem, implementációtól függetlenül, ugyanis nem tud mit mondani a pointerre.
.
.
.
Java-ban van választási lehetőséged, hogy GC-t vagy determinisztikus allokációt használsz ? Nincs.
C++-ban van? Igen, van.
C++ -os GC használata esetén lehetőséged van a heap fragmentáció megszüntetésére, például objektum áthelyezéssel, saját new operátor létrehozásával. Ennek meg kell fizetned az árát, pl refcount-ok / objektum referenciák lefoglalásával, fenntartásával, menedzselésével.
Figyi, irjal mar egy kis c++ forrast ide amit le tudok forditani gcc-vel, es amiben gc-t hasznalsz...
Mar ugyertem, hogy demonstrald, a GC valasztasi lehetoseget.
java-ban (JNI, C) amugy en irtam heap manager-t, pontosabban atraktam azt amit mar tobbszor hasznaltam video jatekokban (nem referencia szamlalosat), mert azt gondoltam, hogy sok kis memoria szeleten jobban tudok rendezni mint a gc, de sajna nem: a gc algoritmusa 1000 elem folott mar verte a nativ heap manager-emet
amugy referencia szamlalos memoria manager-t utoljara a DCOM-ban lattam 'nem mukodni'
ugyhogy vegulis az egy modern valasztas :)
A gc amugy determinisztikus realtime thread-eken...
[quote:5b5ce7e886="imp"]ugyan sose fejlesztettem nagyobb java programot, de kíváncsi vagyok miért.
Most idézhetném a mutassuk meg az übernyelv szintű csodákat, bár a Java nem übernyelv, hanem inkább überplatform. Nézd meg (http://java.sun.com/j2se/1.5.0/docs/api/index.html), hogy mekkora az a funkcionalitás, amely a platform része, és még csak összevadászni sem kell sehonnan. Igen, ezek nagy része C++-hoz is megvan ilyenolyan libraryn keresztül, de ami a Java erőssége, hogy ezeket nem kell vadászni, mindent készen kapsz, sokkal kevesebbet kell kódolni. Szerintem. De vegyünk egy példát:
Én Javaban nagyon rövid kódrészletekkel elkészítek egy SQL-OO vagy egy XML-OO bindingot (= séma ismeretében transzparens a konkrét instance feldolgozása, program szinten csak a szemantikai objektumot látod), és rögtön a feldolgozásra tudok koncentrálni, nem pedig az SQL hívásokra, vagy nem az XML parsingra, karakterkódolásokra. Ugyanezt nem tudom elmondani C++-ról, és még a feladat sem volt túl nagy egy átlagos projektemhez képest.
És mielőtt valaki belekötne: mindent meg lehet írni Assemblyben is, mégsem tartja senki túlságosan célszerűnek.
[quote:aff1ad33e8="Csab"]Az osztályszerkezete jól átgondolt és gyors is. Jobb, mint a java szerkezete.
Úgy érzem az előző hozzászólásom választ ad a gyorsaság kérdésére, az átgondoltság pedig, háát, maradjunk annyiban, hogy megszokás kérdése :)
[quote:aff1ad33e8="Csab"]Az egyetlen fájó pontom az STL (standard template library).
Sehol egy rendes dokumentáció nincs róla és keveset tud.
Java Collections API + Generics, és eddig még nem láttam olyan C++ osztálykönyvtárat (2 éve még kerestem, lehet azóta írtak egyet), ami felvenné vele a versenyt...
Volatile változó az, amelyik nincs cache-elve legalábbis C++-ban.
Szóval thread safe és több szál egyszerre birizgálhatja.
int d=3;
for(; d > 0; d-- )
/* ... */
mov edx,3
label:
...
dec edx
jnz label
Szóval a C fordító a d változót benyomja a edx regiszterbe sebességi okok miatt. Csakhát ezzel a cache varázslással igencsak nem lesz i thread safe. Ha másik szál elkezdené bizgetni, meglepődne az értékén.
De java-ban fogalmam sincs mi az a volatile.
[quote:77dfbb61a1="handler"][quote:77dfbb61a1="Morzel"]Nos, bar en meg csak tanulom, de eddigi ismereteim alapjan a velemenyem:
Az IGAZI programozo programnyelvtol fuggetlenul gondolkodik, es nincs szuksege arra, hogy egyetlen programnyelven dolgozzon egesz elete soran.
En szerintem kicsit szetvalasztanam a programozast es a kodolast.
Morzel
Az igazi programozo gondolkodik es tanul, aztan:
-megtervezi/megvalositja sajat forditoprogramjat
-megtervezi/megvalositja sajat programozasi nyelvet
-megtervezi/megvalositja sajat architecturajat
;-)
Szerintem aki ezt megcsinalja, az csak szimplan hulye. Nameg ido milliomos.
Morzel
Ezt a java-ban is meg lehetne szebben csinálni.
Amikor a referenciaszámláló eléri a nullát (körökörös referenciát is figyelembe véve) -> meghívódik egy destruktor
Hozzá kéne adni még egy delete parancsot, amely kitörli az objektumot és ha mutat rá referencia, kinullázza a referenciákat.
Ez lenne szerintem az észszerű viselkedés.
Az érdekesség kedvéért még beleírtam a következőt is:
[code:1:f038ff3945]
qs.initTomb();
// qs.sort(0,NUM_ITEMS-1);
java.util.Arrays.sort(qs.numbers);
[/code:1:f038ff3945]
[code:1:f038ff3945]$ java -cp . -Xmx250M -server QuickSort
8095
8012
[/code:1:f038ff3945]
Annyit kell erről tudni, hogy a JVM-ben a leghatékonyabb MergeSort van implementálva. .NET-esek figyelem: a .NET runtime QuickSortot használ...
[quote:5773050c76="feledhetetlen"]OO ugyben az a helyzet, hogy a C++ kiveri a biztositekot very1st OO szabalynal: minden objektum
a tobbi mar nem is erdekes...
persze be lehet tartani a szabalyokat C++ban is, sot Cben is, akar el is lehet nevezni egy ilyen szabalyrendszert ObjectiveC-nek, de az attol meg patkolas
egy makro preprocessor-bol (aminek a C++ keszult) nem lesz jobb nyelv
Csakis egy JLS szintu alapra lehet varat epiteni
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
[quote:5773050c76="maszili"]
Vegyük azt a példát amikor egy függvény egy változó tartalmával végez műveleteket. Ha érték szerint megy az átadás akkor a függvénynek van egy saját példánya amit nyugodtan megváltoztathat a munkája során anélkül hogy az eredetit elrontaná... De a programozó megteheti hogy a változó értéke helyett egy mutatót ad át... a programozó DÖNT!
sajnos az alapertelmezes szerint erteket ad at, pedig imho az a ritkabb
szoval ha a programozo az alapesetet koveti, altalaban rosszul dont...
[quote:5773050c76="maszili"]
[quote:5773050c76="feledhetetlen"]
Badarság...
nem en irtam: http://javasite.bme.hu/~lazlo/notes/realman.html
Azt nem lehetne, hogy megegyezunk, hogy ezt a cikket nem emlegetjuk tobbet? Nem mondom, hogy nincs igaza, de altalaban aki beidezi, annak fogalma sincs arrol, hogy milyen lehet Fortran66-ban programozni. En kiprobaltam es nem voltam tole boldog. Utana tobb, mint egy evig nyomtam a Fortran77-et es a Fortran90-et, de meg az sem gyozott meg rola, hogy emiatt nem kellene szeretnem a Pascalt.
Van az ertek szerinti parameteratadasnak is ertelme. Az igaz, hogy altalaban referenciat erdemes atadni, es jo lenne, ha az lenne a default (ugye-ugye a C++-ban csak azert van igy, mert mar C-ben is igy volt, szoval megint igazodunk egy 40 eves tervezesi hibahoz).
Valoban a Fortran ebbol a szempontbol jobb, mert mindent referencia szerint ad at... Viszont nem tud atadni semmit sem ertek szerint. Ez azt jelenti, hogy ha egy konstanst adsz at, akkor az futasidoben fog egy segfault-tal elszallni...
[quote:1f944297ff="maszili"][quote:1f944297ff="lokoto"]
...mert javában nem tudsz *a-t írni, ezért ha az a = b-t felüldefiniálod a = b.clone() funkcionalitására, nem tudod miként megvalósítani a jelenlegi értelemben vett a = b műveletet, azaz hogy az a változó a b változó által mutatott objektumra mutasson.
Itt érkeztünk el ahhoz a ponthoz hogy saját magad mondod ki azt, hogy a java filozófiája rosszabb mint a c++. :)
Fölösleges megkötésekkel gátat szab saját maga kifejező erejének...
Elég meredek a következtetésed. Ettől még semmi nem rosszabb semminél, így definiálták a szintaktikát és szemantikát.
Primitív típusok esetén a változó az értéket hordozza, egyébként pedig hivatkozás egy objektumra. Pont.
De ha már szintaktika: tedd a szívedre a kezed, és mond azt, hogy a pointeres csillagozásokat soha nem tévesztetted el, és az általad írt kódban biztosan nincsen ilyen jellegű hiba.
Mikor a Javában meghatároztak a nyelv alapjait, valószínűleg végignézték, hogy jelenleg mi van, minek mi a hibája, előnye, és megpróbáltak jobbat kihozni (az adott feladatra).
Ha jól tudom a C# szintaktikája és szemantikája nagyon hasonlít a javáéra, vajon véletlen, hogy ott sincsenek pointerek?
De ha Neked a C++ tetszik jobban, akkor láss csillagokat, szíved joga.
[quote:1f944297ff="maszili"]
[quote:1f944297ff="lokoto"]
Lehet, hogy csak megszokás, de az =-nek ez a funkcionalitása logikusan ábrázolt, és a clone() kitűnően kifejezi, hogy mélymásolást kell csinálni.
Korábbi hozzászólásomban (induljunk el a kályhától) kifejtettem hogy szerintem egyáltalán nem természetes a java filozófiája.
Ez szerintem a Te problémád :-)
Nekem nagyon is logikus, átlátható, egyszerű, robusztus.
Művelet:
a = b;
mélymásolás esetén:
a == b false
jelenlegi működés:
a == b true
Nekem a jelenlegi működés logikusabb. Neked nem? :-)
Nyilván az ==-et is felül lehetne definiálni, de lássuk be, hogy az egyik kolléga által felvázolt szemethalmazt kapjuk nagyon rövid idő alatt, mert senki nem fogja tudni, hogy mi micsoda.
Arról nem is beszélve, hogy a mélymásolás logikája egy egyszerű operátori logika komplexitását jóval meghaladja.
A java ilyen: vagy ne használd, vagy fogadd el. Nem kötelező.
A természetben is sokkal drágább művelet a klónozás, mint a rámutatás, a függyvény hívás beírásának macerája is erre akarja felhívni a figyelmet, hogy egy kis mély értelmet is vigyünk a dologba ;-)
[quote:df7a7e192e="bocs"]keverjük itt a szezont a fazonnal
milyen megoldás révén tudja ezt a Java? Plusz erőforrás felhasználás révén (GC CPU idő, objektum referenciák vagy refcount, dupla(!!) heap méret a szükségeshez képest, nemdeterminisztikus viselkedés).
Kiemelem a dupla heap méretet, mert a többi már korábban meg lett cáfolva :). Nem kell neki dupla heap méret, mert simán össze tudja tolni a memória-szeleteket (gondolj bele: minden memória-részt csak előre kell mozgatni, az üres terület a végén kialakul), ráadásul a dolog csak akkor fut, amikor nincs elég töredezettségmentes memória-darab (ilyenkor pl. a C++ akár el is szállhat outofmemory-val) és csak addig, amíg létre nem jön elegendő méretű memória, feleslegesen nem dolgozik.
[quote:2fa2126f49="syntern"]egy SQL-OO vagy egy XML-OO bindingot
ORM-nek hivjak, es nem feltetlenul javas kivaltsag
[quote:eca7a993ba="Csab"]Képzeld el:
- Egymás után megnyitsz fájlokat, de nem zárod be őket.
Mielőtt a GC elkezdene dolgozni, a maximálisan megnyitható fájlok
számát simán elérheted. Aztán nem érted, miért hal be a program.
Nem értem, nem értem, nem értem... Vajon mi lehet rossz így a Javaban :) Csatlakozok Joelhez, szakmát kell váltanom...
[quote:4c15551331="waiter"]Nem tudom, mi a "programozási nyelv" pontos definíciója, de IMHO egy programozási nyelvnek általános érvényű (és nem egy specializált) eszköznek kellene lennie, legyen szó bármilyen szoftverfejlesztési feladat megoldásáról.
- waiter -
Hogy őszinte legyek, tulajdonképpen ennek semmi értelme. Mert ez alapján a processzor gépi nyelve ideális, hisz mindent megírhatsz benne - végül is minden megírt program gépi nyelven fut le.
Egy dolog van: megfelelő feladathoz a megfelelő nyelvet használni. Egy nyelv addig él, amíg van mire használni és használják is.
[quote:96b8226534="snq-"][quote:96b8226534="syntern"]egy SQL-OO vagy egy XML-OO bindingot
ORM-nek hivjak, es nem feltetlenul javas kivaltsag
Nyilván nem Javas, ezt nem is feltételeztem. Én csak azzal a feltételezéssel éltem, hogy kevesebb kódsorból elérem ugyanazt :)
[quote:d951840de5="_Joel"][quote:d951840de5="bocs"]legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
Maximálisan teljesíthető Java-ban, akár néhány száz sorban: http://access1.sun.com/techarticles/ImagingApps/JImage.html
http://java.sun.com/developer/technicalArticles/Media/AdvancedImage/index.html
hát ez tökéletesen mellément, joel.
itt JPEG, BMP stb képformátumok beolvasásához vannak Javas library-k, ami abszolút merőleges a problémára, amit írtam.
a probléma megoldásához
1. szigorú memóriakontrollra van szükség , különben elvesztél. gondolj bele, egy CT kép simán jöhet akár 800MB-os is _egy darabban_, ezt nem kétszerezheted meg, nem bízhatod GC-re, mert véged van.
2. pixelenkénti float műveletekre van szükség kép simításhoz. kimondottan erre kérek referenciát, mert ilyen Java-ban abszolúte nem találtam.
3. gépek vezérlése, alacsonyszintű io, frame grabbelés. ne mondd, hogy java az adekvát erre a feladatra, mert nem lesz igaz.
4. aztán hogy numerikus algoritmusra használjak Fortrant? ccc
tudod mit, én inkább használok egy olyan c++ nyelvet, amivel igen jó teljesítménnyel bármilyen feladatot kényelmesen, garantáltan közel gépi kód hatékonysággal, de emellett nagyon magas szinten, elegánsan megoldok.
Ha kell, saját valódi template-es tárolóosztályokat gyártok, mert éppen olyan kell. A Java-t itt tudomásom szerint komolyan nem szokták emlegetni, mert template területen nevetséges.
erre pedig inkább nem írok semmit, ez viccnek álcázott szemellenzősség
[quote:e27b6846a9="Csab"]Engem egyáltalán nem érdekel a GC dokumentációja, mert szerintem koncepcionálisan van eltolva az egész.
Sokunk szerint pedig nincs eltolva, és az általa nyújtott kényelem (fejlesztési idő 90%-a) elnyomja a használatát övező hátrányokat (Java learning curve első fele). Tudom, téged nem érdekel... Attól még ismerek olyan Java-s fejlesztő kiscéget (4-5 ember), akik évi 60-70 milliót összelapátolnak ezzel a használhatatlan, lassú, bugos nyelvvel és platformmal...
Szándékosan kerültem ki. Ha túl sokat beszélek a munkámról, előbb utóbb kirúgnak. Az igazat megvallva próbálok általános információkat adni, mert munkahelyi dolgokat nem lehet csak úgy kiadni.
Ez hasonlítana ahhoz, mintha egy program forrását a főnökeim engedélye nélkül felraknám a netre.
Az általános policy az, hogy senkinek semmit, amíg engedélyt nem kapsz rá. Persze nem olyan munkahelyem van, ahol csak úgy kirúgják az embereket, de tenni sem akarok az ügyben, hogy ezen változtassanak.
[quote:5f9723b8f0="lokoto"]
Itt nem egy konkrét programról van szó, hanem általánosan állapítod meg, hogy a Java filozófiája rosszabb, mint a C++.
Igen...
[quote:5f9723b8f0="lokoto"]
Ha jól látom még mindig nem árultad el, hogy ennek fényében hogy raknád bele az egész számokat 1-től 500000-ig egy java.util.ArrayList-be.
Nem is fogom mert engem nem érdekel a java... én nem használom. Majd az megmutatja aki használja a java-t.
Részemről a vita lezárva!
Szerintem elég magyarázatot fűztem az érveimhez hogy érthető legyen. A további szócséplés fölösleges.
[quote:b9a3e84c70="hop1"]És kimaradt a pascal :(
Akkor az összes Basic-et be kellett volna venni :)
Én személyesen az Objective-C-t hiányolom, de ez a nyelv a Mac OS X környezetén kívül meglehetősen ritka .. sajnos. :)
Azért rakok ide neki egy szavazatot: (x)
:))))
[quote:056aebf138="fdavid"][quote:056aebf138="_Joel"]Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
Hat most nem tudom, hogy ez marketing duma, vagy csak szimplan nagyotmondas. Egyik sem tul szimpatikus.
egyik sem, nagyon is kozel all az igazsaghoz (nyilvan a senki tulzas, mert mindig vannak viccharoldok)
[quote:d1049a910a="Csab"]Szándékosan kerültem ki. Ha túl sokat beszélek a munkámról, előbb utóbb kirúgnak. Az igazat megvallva próbálok általános információkat adni, mert munkahelyi dolgokat nem lehet csak úgy kiadni.
Világos, de addig amíg csak ennyit árulsz el, az csapódik le, hogy nem értesz hozzá, nem akarsz érteni hozzá, de fikázod. Nem bántó szándékkal mondom, megértem a munkahelyi indokokat, de akkor inkább semmit, mint ilyen vagdalkozást... Szerintem.
objektív véleményem szerint ez túl szubjektív - bár épp ezért _szavazás_ ennek a mókának a neve!
szubjektív véleményem szerint viszont senki sem tudja milyen az objektív vélemény, ezért eleve nem lehet véleményem - régen volt egy ilyen szkifi (amit a minap elborzadtomra fittyet sem hányva sztoikus nyugalommal közöltek velem, hogy "szájfáj"-nak köll ejteni) sztori egyébként, amelyikben az "Isten kilencmilliárd neve" is benne volt.
NODE akkómá,
- egyszerűségében, tisztaságában a C.
- szépségében, eleganciájában az ObjC (ami kimaradt, ezért ebben a véleményemben nyilván nem sok emberrel osztozhatok).
- jól átgondoltsága és a nyelv szerkezetének konzisztenciája miatt, közepesen komoly és nem mánikusan sebesség-orientált fejlesztésekre Ruby.
- rendszeradminisztrációra pedig (VSZ) Perl. ha a netbsdről azt tartják, hogy elfut még a ceruzahegyezőn is, akkor a cpan lesz az ahol a ceruzahegyező átmérőjének a fokát beállító modulokat lehet majd fellelni (persze a tökösebbje nem vacakol, a shelles cpan a spanja és miután csíkokban a hitel-kártyájára kiszórta a cpan jóságot, egyetlen "install" és köszönömcsókolom).
de az is lehet, hogy napok óta csak kávén élek és megint baromságokat mondtam. jaboccs.
[quote:74998bc36c="syntern"]
Annyit kell erről tudni, hogy a JVM-ben a leghatékonyabb MergeSort van implementálva. .NET-esek figyelem: a .NET runtime QuickSortot használ...
jujj... ez fájt
ajánlott irodalom: Knuth
nincs olyan hogy "a" legggyorsabb. minden a feladat részleteitől függ.
általában a quicksort gyorsabb.
A java-t azért így írták meg, hogy könnyen és biztonságosan lehessen programozni.
Hallottam esetet, hogy programot akartak írni és felvettek jó csomó kezdő szoftverfejlesztőt, azokat pedig "minthogy a java úgyis biztonságos", ráirányították egy komoly kereskedelmi projektre.
Igen nagy befürdés lett az eredménye. Kezdő programozókkal nem lehet rendes rendszert írni. Ahhoz szakértelem kell. Én kezdő programozókat a tesztelésre helyezném, de nem egy rendkívül fontos kód megírására.
Szóval C++,C,java teljesen mindegy, de szakértelmet igényel. Ezt nem lehet megúszni.
Én személy szerint a szebb megoldásokat jobban értékelem, mint a biztonságos megoldást.
A gyakorlat egyébként az, hogy a legtöbb java osztálynak van destruktora, csak
- stop
- unregister
- shutDown
- terminate
...
névre hallgatnak. Amit akkor kell meghívnod, amikor SZERINTED! az objektum megszűnik. Ez igencsak közel áll a delete utasításhoz.
Nem is használjuk, ha nem muszáj, de nektek is el kell fogadni azt, hogy valakinek a java-s körülményesség nem fekszik.
Egyébként kíváncsi lennék, hogy ha nincs 2D, 3D gyorsítás, milyen sebességre lenne képes a java.
C++ alatt lehet közvetlenül a memóriába írni és onnan olvasni minden különösebb erőfeszítés nélkül. Ráállítasz egy pointert a grafikus képernyőre és megy.
Java-ban meghívod a getPoint(...) metódust, aztán a setPoint(...)-ot is, ami... Vagy ráállítasz egy 1000x1000-es tömböt?
Mialatt C-ben egyszerű írás olvasással jóformán energiabefektetés nélkül pontonként szőrözhetsz a képen, addig ez java-ban nem megy.
Összegyűjtenek pár alapműveletet:
- kép kirakása
- kitöltés
- rajzolások
- scroll
- sprite-ok
...
Ezt C,C++-ban megírják, azt kész. Ha ennél több kell, használj C-t. Persze az is igaz, hogy a játékok 99%-ánál ez elég is.
[quote:fe0e87033e="syntern"]
Én például nagyon kedvelem azt, hogy Linux / Windows / Solaris alatt ugyanabban a fejlesztői környezetben, ugyanúgy lehet fejlesztenem, ami ugyanúgy néz ki eredményben mindenhol. Elméletileg a C++ is képes erre, a gyakorlatban elég nehéz kivitelezni (vagy nekem nem ment, mindenesetre nem próbáltam sokáig, hamar rátértem Javara).
Ha egy kézben van a fejlesztés több platformra, akkor átvihető lesz a kód. Ebből ered a java hordozhatósága. A C körül akkor kezdődtek a problémák, amikor a borland más utakat kezdett taposni, mint a szabványos cé. Ha Egy vállalkozás adná minden platformon a cé fordítókat, akkor nem lenne a hordozhatósággal baj.
[quote:14c0b6c930="Csab"]Szóval C++,C,java teljesen mindegy, de szakértelmet igényel. Ezt nem lehet megúszni.
Ezzel egyetértünk, de szerintem ennek ellentétét nem is állította senki sem.
[quote:14c0b6c930="Csab"]A gyakorlat egyébként az, hogy a legtöbb java osztálynak van destruktora, csak
- stop
- unregister
- shutDown
- terminate
...
névre hallgatnak. Amit akkor kell meghívnod, amikor SZERINTED! az objektum megszűnik. Ez igencsak közel áll a delete utasításhoz.
Ezekkel még nem találkoztam :)
Azért azt kicsit dúrvának tartom, hogy valaki az érték szerinti paraméterátadás lehetőségét tervezési hibának tartja. :roll:
Egy másik téma, hogy mintha némelyek fejében kicsit pontatlan kép élne a C++-ról.
A C++-t olyan általános programozási nyelvnek tervezték, ami az oo tervezést, fejlesztést _is_ jól támogatja, de nem kötelező használni az oo eszközeit, és nem az alapjaitól oo, ellentétben a jávával.
[quote:3be728d61a="aperger"][quote:3be728d61a="lacipac"][quote:3be728d61a="hop1"]És kimaradt a pascal :(
Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban.
Te KIS hátuldombolós gimnazista, TE aztán tudod!!!!
Erre a "hátulgombolós"-ra igazán dühös tudok lenni, ha hasonló tapasztalattal rendelkező ember puffogtatja, mint egy átlagos gimnazista lehet.
Népi és iparművészeti plédán keresztül megvilágítva a dolgot olyan a különbség, mint a keresztszemes hímzés, meg a gobelin...
[quote:19f493315d="bocs"]
hát ez tökéletesen mellément, joel.
itt JPEG, BMP stb képformátumok beolvasásához vannak Javas library-k, ami abszolút merőleges a problémára, amit írtam.
Nézd meg jobban. Pl ez szerinted mit csinal (nem en irtam, egy tech tip-bol ollozva: http://java.sun.com/developer/JDCTechTips/2005/tt0601.html
[code:1:19f493315d]
public class My3x3JAIKernels {
private static final float[] IDENTITY = {0, 0, 0,
0, 1, 0,
0, 0, 0};
private static final float[] EDGE = {0, 1, 0,
1, 0, 1,
0, 1, 0};
private static final float[] CORNER = {1, 0, 1,
0, 0, 0,
1, 0, 1};
public static KernelJAI getkernel(int corner,
int edge,
int identity) {
float[] kernel = new float[9];
int sum = corner * 4 + edge * 4 + identity;
if (sum == 0) sum = 1; // to avoid dividing by zero
for (int i = 0; i < 9; i++) {
kernel[i] = (corner * CORNER[i]
+ edge * EDGE[i]
+ identity * IDENTITY[i]) / sum;
}
return new KernelJAI(3, 3, kernel);
}
}
[/code:1:19f493315d]
[code:1:19f493315d]
private void convolveImage(KernelJAI kernel) {
ParameterBlock pb = new ParameterBlock();
pb.addSource(image);
pb.add(kernel);
image = JAI.create("convolve", pb, null);
}
[/code:1:19f493315d]
[code:1:19f493315d]
convolveImage(My3x3JAIKernels.getkernel(corner, edge, identity)));
[/code:1:19f493315d]
Miert biznad GC-re? Tisztaban vagy a GC mukodesevel, vagy csak bizonyosan nagy tapasztalattal rendelkezo C++ programozokent halvany lila elkepzeleseid vannak rola?
A fenti konvolucios matrix(ok) alkalmazasa egy kepre megfelel ennek a kriteriumnak, vagy keressek masikat?
Gépek vezérlése: Ha RT kovetelmenyek vannak, ott valoban gond lehet a GC nem determinisztikus volta, bar az 5-os JVM ergonomics kapcsoloi ota ez talan kezelheto (foleg ha csak soft RT kovetelmenyek vannak).
Alacsonyszintu io: mire gondolsz, konkretan? Ugy erted, hogy Java-bol lassabban lehet irni ugyanazt a diszket? Vagy micsoda?
Frame grabbeles: Java Media Framework? Amikor utoljara neztem akkor eppen viszonylag keves formatumot ismert, de a plugin architektura miatt ez csak vendor tamogatas kerdese... (mondjuk ez kisse tenyleg remenytelen - bar a DVB-MHP es J2ME hazassag miatt meg lehet belole valami).
Miért, az iparágban, HPC körökben, numerikus problémákra ez a de facto ipari szabvány nyelv, mind a mai napig. Nagy mátrixok szorozgatására a legkényelmesebb... legalábbis az öreg szakik szerint, én meg hiszek nekik.
Nyugi, a világ másik fele ugyanezért használ Java-t, és abszolúte nem fikázza a C++ programozókat amiért ugyanezt teszik. Valamiért a C/C++ világ jön mindig azzal, hogy a Java ugyanolyan lassú és sz@r mint 10 éve volt, holott nem.
Na pont erről a fikázásról beszélek. "szokták", "nevetséges". Figyelj, tényleg nem sajnálom tőled a C++- tudásodat, egyelőre nagyon jól meg lehet élni belőle, de attól még nem kellene leszólni egy másik nyelvet/platformot mindenféle mondvacsinált indokkal.
Nem, ez sajnos tapasztalat. Clipperben és FoxProban készült ügyviteli programokkal van tele az ország, mert a "szakik" ahhoz értenek a mai napig.
[quote:f889a55970="wwrreecckk"]-server kapcsoló, gondolom, csak sun jvm része, mert mi IBM-es jdk-t használunk és ott nem nagyon látszik működni.
Amúgy szerencsétlen IBM jdk gyorsabb lenne, mint a SUN, vagy tévedek?
Az IBM a Sun JVM-et licenceli, és abba heckel kódot. Tipikusan azért, hogy fusson AIX-en, de lehet benne teljesítmény-tuning is.
Ha valaki még érdeklődik alternatív JVM iránt, akkor BEA JRockit.
bocs ha kicsit hosszu de kerdeztel, es valahogy azt erzem:
lehet tenyleg erdekel
Szoval: 800MB az c++ is 800MB
pixel muveletek:
java.awt.image.RasterOp
peldaul a ConvolveOp
ez float-tomboket vesz at mint azt lathatod is a jdk-hoz mellekelt
demoban: ${ahol a jdk van}/demo/jfc/Java2D/src/java2d/demos/Images/ImageOps.java
...
float data[][] = { {0.1f, 0.1f, 0.1f, // 3x3 blur
0.1f, 0.2f, 0.1f,
0.1f, 0.1f, 0.1f},
{-1.0f, -1.0f, -1.0f, // 3x3 sharpen
-1.0f, 9.0f, -1.0f,
-1.0f, -1.0f, -1.0f},
{ 0.f, -1.f, 0.f, // 3x3 edge
-1.f, 5.f, -1.f,
0.f, -1.f, 0.f},
{-1.0f, -1.0f, -1.0f, -1.0f, -1.0f, // 5x5 edge
-1.0f, -1.0f, -1.0f, -1.0f, -1.0f,
-1.0f, -1.0f, 24.0f, -1.0f, -1.0f,
-1.0f, -1.0f, -1.0f, -1.0f, -1.0f,
-1.0f, -1.0f, -1.0f, -1.0f, -1.0f}};
for (int j = 0; j < data.length; j++, i++) {
biop[i] = new ConvolveOp(new Kernel(dim[j][0],dim[j][1],data[j]));
}
...
pixel image transform muveletekre az
java.awt.geom.AffineTransform
The AffineTransform class represents a 2D affine transform that performs a linear mapping from 2D coordinates to other 2D coordinates that preserves the "straightness" and "parallelness" of lines. Affine transformations can be constructed using sequences of translations, scales, flips, rotations, and shears.
Such a coordinate transformation can be represented by a 3 row by 3 column matrix with an implied last row of [ 0 0 1 ]. This matrix transforms source coordinates (x, y) into destination coordinates (x', y') by considering them to be a column vector and multiplying the coordinate vector by the matrix according to the following process:
[ x'] [ m00 m01 m02 ] [ x ] [ m00x + m01y + m02 ]
[ y'] = [ m10 m11 m12 ] [ y ] = [ m10x + m11y + m12 ]
[ 1 ] [ 0 0 1 ] [ 1 ] [ 1 ]
[quote:28fe9ad692="bocs"][quote:28fe9ad692="_Joel"][quote:28fe9ad692="bocs"]legutóbbi feladatom az volt, hogy egy hálózatról egyben, 200MB-os méretben érkező bitfolyamot (orvosi képet) hatékonyan felszeleteljek a memóriában, úgy, hogy közben ne foglaljak többet, mint a kép mérete.
Maximálisan teljesíthető Java-ban, akár néhány száz sorban: http://access1.sun.com/techarticles/ImagingApps/JImage.html
http://java.sun.com/developer/technicalArticles/Media/AdvancedImage/index.html
hát ez tökéletesen mellément, joel.
itt JPEG, BMP stb képformátumok beolvasásához vannak Javas library-k, ami abszolút merőleges a problémára, amit írtam.
a probléma megoldásához
1. szigorú memóriakontrollra van szükség , különben elvesztél. gondolj bele, egy CT kép simán jöhet akár 800MB-os is _egy darabban_, ezt nem kétszerezheted meg, nem bízhatod GC-re, mert véged van.
2. pixelenkénti float műveletekre van szükség kép simításhoz. kimondottan erre kérek referenciát, mert ilyen Java-ban abszolúte nem találtam.
3. gépek vezérlése, alacsonyszintű io, frame grabbelés. ne mondd, hogy java az adekvát erre a feladatra, mert nem lesz igaz.
4. aztán hogy numerikus algoritmusra használjak Fortrant? ccc
tudod mit, én inkább használok egy olyan c++ nyelvet, amivel igen jó teljesítménnyel bármilyen feladatot kényelmesen, garantáltan közel gépi kód hatékonysággal, de emellett nagyon magas szinten, elegánsan megoldok.
Ha kell, saját valódi template-es tárolóosztályokat gyártok, mert éppen olyan kell. A Java-t itt tudomásom szerint komolyan nem szokták emlegetni, mert template területen nevetséges.
erre pedig inkább nem írok semmit, ez viccnek álcázott szemellenzősség
Kiegészíteném azzal, hogy az osztály tartalmaz egy boolean stopped mezőt.
class MyClass {
private stopped = false;
public MyClass() {}
public void stop() {
stopped = true;
...
}
public myMethod( ... ) {
if( stopped )
throw new BehaltamException();
...
}
}
Hát, ez bizony gyönyörű.
Nem fikázom a java-t, csak leírom, hogy vannak hátulütői.
Lehet, hogy ez néha keményre sikeredett, de szerintem a java még messze nem tökéletes.
Amikor van választásom, akkor C++-t használok, kivétel, ha netre akarok felrakni valami appletet, vagy szükségem van a könyvtári függvényeire (pl. XML parser) és nem akarok QT-t használni, mert az túl nagy ágyú lenne.
[quote:cde6ca554e="snq-"][quote:cde6ca554e="fdavid"][quote:cde6ca554e="_Joel"]Nem véletlen az a tendencia, hogy üzleti alkalmazást ma már C/C++-ban senki nem fejleszt.
Hat most nem tudom, hogy ez marketing duma, vagy csak szimplan nagyotmondas. Egyik sem tul szimpatikus.
egyik sem, nagyon is kozel all az igazsaghoz (nyilvan a senki tulzas, mert mindig vannak viccharoldok)
Ugy kellett volna irni, hogy "senki nem kezd el fejleszteni". A gnome-osok sem veletlenul probalgatjak osszehozni linuxra a monot meg a c#-ot...
[quote:55ef194daa="syntern"]
A Java teljesítménye (-server kapcsoló) a legtöbb esetben megközelíti ugyanazt a kódot megvalósító C++ programot a Hotspotnak köszönhetően, valamint az erősen rekurzív esetekben jócskán meg is előzi. (5-ös Java, gcc, -O1, 2, 3-mal is mérve, a -O3 már majdnem olyan jól teljesített mint a Java) A mérések kizárólag memória-kezelést és algoritmus végrehajtást mértek, ugyanaz a C++ kód és Java kód futott, feladatonkénti mérési idő 30-45 mp, hogy ne legyen nagy hiba az óra pontatlanságából. Sok esetben gyanítjuk, hogy a Hotspot optimalizálása alig kezdett el működni.
Azért kíváncsi lennék arra a C++ és Java kódra. Saját tapasztalatom, hogy C++-ban is lehet eszméletlenül lassú kódot írni, nem mindegy ugyanis, hogy mennyi tapasztalata van a programozónak. A Java hatalmas előnye szerintem, hogy a hátulgombolós programozók is tudnak vele boldogulni, mert rengeteg dolgot levesz a programozó válláról. Persze a hátránya is ugyanez :)
Amúgy én speciel, C és C++ nyelveket favorizáló programozóként, örülök ennek a nagy Java mániának, mert egyre több programozó már csak Javában tud gondolkodni, amellett, hogy egyre több a Javában csalódott potenciális megrendelő a rengeteg bukott Javás project miatt.
Ezért aztán folyamatosan felértékelődik a C és C++ tudás.
Úgyhogy nyomjátok csak, istenítsétek! Örülünk neki. Nekunk az is elég, ha kiszolgáljuk a "Javában eszükbe ne jusson kódolni!" klienseket. Szerencsére egyre többen vannak, ez tapasztalat.
És üdvözlöm a hátulgombolósokat alkalmazó cégeket :)
[quote:cb6450a643="bocs"]jujj... ez fájt
ajánlott irodalom: Knuth
nincs olyan hogy "a" legggyorsabb. minden a feladat részleteitől függ.
általában a quicksort gyorsabb.
Oké, akkor pontosítok a wikipedia segítségével:
Mergesort has an average and worst-case performance of O(n log n). In the worst case, merge sort does about 30% fewer comparisons than quicksort does in the average case; thus merge sort very often needs to make fewer comparisons than quicksort. In terms of moves, merge sort's worst case complexity is O(n log n)--the same complexity as quicksort's best case, and merge sort's best case takes about half as much time as the worst case.
However, merge sort performs 2n - 1 method calls in the worst case, compared to quicksort's n, thus has roughly twice as much recursive overhead as quicksort. Mergesort's most common implementation does not sort in place, meaning memory the size of the input must be allocated for the sorted output to be stored in. Sorting in-place is possible but requires an extremely complicated implementation.
Although merge sort can sort linked lists, it is also much more efficient than quicksort if the data to be sorted can only be efficiently accessed sequentially, and is thus popular in languages such as Lisp, where sequentially accessed data structures are very common. Unlike some optimized implementations of quicksort, merge sort is a stable sort as long as the merge operation is implemented properly.
More precisely, merge sort does between ⌈ n log n - n + 1 ⌉ and ⌈ n log n - 0.914·n ⌉ comparisons in the worst case.
[quote:f7eff28135="Csab"]Ezt a java-ban is meg lehetne szebben csinálni.
Amikor a referenciaszámláló eléri a nullát (körökörös referenciát is figyelembe véve) -> meghívódik egy destruktor
Szerintem érdemes lenne mélyebben megnézned a Java GC-t. Leegyszerűsítve persze hasonlóképpen működik, csak nem mindig nézi a "referenciaszámlálót", csak akkor, amikor éppen elfogy a szabad memória...
A reflection pl. komolyan hiányzik a C++-ból. Valószínűleg azért, mert teljesen más a szerkezete.
Mindenesetre a kettő ötvözéséből fantasztikus dolgokat lehetne kihozni.
[quote:35e1628ac9="Csab"]Volatile változó az, amelyik nincs cache-elve legalábbis C++-ban.
Szóval thread safe és több szál egyszerre birizgálhatja.
int d=3;
for(; d > 0; d-- )
/* ... */
mov edx,3
label:
...
dec edx
jnz label
Szóval a C fordító a d változót benyomja a edx regiszterbe sebességi okok miatt. Csakhát ezzel a cache varázslással igencsak nem lesz i thread safe. Ha másik szál elkezdené bizgetni, meglepődne az értékén.
De java-ban fogalmam sincs mi az a volatile.
nem a cache maga problema
nem is arra szeretnenk garanciat, hogy minden muveletet csak az memoria valtozon csinaljon
azt lehet normalisan elvarni, hogy a volatile valtozok a vegrehajtasi sorrendbe irododjanak vissza a memoriab
vagyis:
[code:1:35e1628ac9]
public class VolatileTest
{
int a,b;
void inc()
{
a++;
b++;
}
}
[/code:1:35e1628ac9]
eseten elofordulhat, hogy egy masik thread b-t nagyobbnak latja mint a-t
de ha ez
[code:1:35e1628ac9]
public class VolatileTest
{
volatile int a,b;
void inc()
{
a++;
b++;
}
}
[/code:1:35e1628ac9]
akkor biztosak lehetunk hogy a mindig >= b-vel
a kerdesem [code:1:35e1628ac9]synchornized(this){}[/code:1:35e1628ac9] pedig azert nem trivialis, mert a MIKOR??? erzekeny pontot tudja meghatarozni
mivel a volatile csak a sorrendiseget biztositja, azt nem, hogy az a,b memoria cimekre mikor irodik be a es b erteke...
viszont, ha beiktatsz egy [code:1:35e1628ac9]synchornized(this){}[/code:1:35e1628ac9] sort akkor biztos lehetsz, hogy a tobbi thread is azt latja amit te vegre hajtasi szalad
[/code]
800 MB-ra visszaterve: es tenyleg egyszerre memoriaban kell tartani az egesz kepet? Mekkora konvolucios matrix-szal dolgozol a kepsimitasnal?
JAI eseten ugyanis:
"The operation chain itself does not, however, handle the way image data are managed in the source and sink portions of the chain as this cannot always be controlled by the API itself. For example, if the image source is a file which is not tiled, then the entire image will be loaded. If a tiled source image file is used (e.g., tiled TIFF or FlashPIX), then only those tiles required to execute the operation chain will be read from the disk.
Similarly, at the data sink end of a chain, e.g., the display, if the entire image is requested and held in memory then that will provoke computation of all tiles in all intermediate operations in the chain and consequently reading of the entire image from disk. The data sink will be most efficient if it requests only those tiles that it needs and uses some kind of efficient algorithm for disposing of the destination tiles that it does not need, e.g., those neither being displayed nor adjacent to tiles being displayed.
To reduce RAM usage even further you also have the option of implementing your own tile cache which uses an alternate type of backing storage for the tiles in the cache, e.g., a disk file or a database. Such an approach may lower execution speed in some cases but there are always tradeoffs. There is also a mechanism to replace the "Least Recently Used" algorithm with a custom implementation via the tile cache metric and tile comparator features. "
Szoval ha tiled image lehet az input, akkor nem kell az a 800 MB... vagy ha csak a kepernyon levo reszt eleg konvolalni. Nem tudom mit csinal pontosan az alkalmazasod, csak talalgatok.
[quote:115d6b2edb="Csab"]Kiegészíteném azzal, hogy az osztály tartalmaz egy boolean stopped mezőt.
Oké, beidézel egy példát, amely a programozói nem-tudás példája, de ennek semmi köze ahhoz, hogy a Java mint nyelv jó-e vagy sem. Ha pl. a Whitespace nyelvet idézed be, akkor megértem, de itt nem erről van szó. Ugyanezt a kódot átírom C++-ba, és mondjam azt, hogy milyen rossz a C++, meg lehet benne csinálni egy boolean stopped mezőt?
[quote:afc1c9634a="Csab"]Amikor van választásom, akkor C++-t használok, kivétel, ha netre akarok felrakni valami appletet, vagy szükségem van a könyvtári függvényeire (pl. XML parser) és nem akarok QT-t használni, mert az túl nagy ágyú lenne.
tinyxml, xerces-c? ;)
van "platformfüggetlen" szálkezelés is (boost-ban) :)
(nem vagyok biztos, hogy reflection egyáltalán megvalósítható lenne-e a C++ oo képességei mellett)
A 2005-ös év kedvenc programozási nyelve.
Úgy néz ki, meg kell barátkozni a gondolattal, hogy egy pascal nem fér bele az első 10 választási lehetőségbe (mondjuk annyi szavazatot kapott volna, mint a lisp valszeg).
Ez van.
A jelöltek kiválasztásánál lehetett volna erősködni.
Egyébként én is szeretem, sokat programoztam benne, és most is kell néha (delphi).
Mit jelent a platform független szálkezelés?
Hozzálinkelsz egy függvény könyvtárat, azt kész?
Nem is tudtam, hogy a xerces C-ben is megy. De jó! :-)
syntern:
Meggyőző a qsort példa. Látszik, hogy ebben a példádban tökéletesen elhanyagolható sebesség-különbség jön ki C++ és Java között.
Régebben én is nézegettem a Javát, pont a kényelmessége miatt, hogy minden együtt van, nem kell libeket vadászgatni és az eltérő API-k és konvenciók miatt szívni, stb.
Ki is próbáltam, a fordító gyors, az egyszerű programok gyorsan futnak.
Azt viszont én pl. sehogy nem tudom lenyomni a felhasználó torkán, hogy GUI esetén egy bonyolultabb ablak megjelenése nem történik meg a másodperc töredéke alatt. Ha egy ablak 2 tizedmásodperc alatt jelenik meg, az már egy profi felhasználónak a használhatatlanság határa.
Azt sem lehet elmagyarázni szegény felhasználónak, hogy a program azért gondolkozik néha másodpercekig, mert olyankor szemetet gyűjt.
Egyszerűen nem lehet dolgozni egy komolyabb Java alkalmazással. Nem értem, miért nem a GUI gyorsításával foglalkoznak a SUN-nál?
Mellesleg most épp egy Java alkalmazás kiváltására írok programot C++-ban, mert a Java cuccos tökéletesen használhatatlanul lassú tetü.
Hogyan oldod meg másképpen azt, ha megszüntetsz egy objektumot, de mindenki más tarthat rá referenciát és hívogathatja?
[quote:a6fd3b1789="Csab"]synchronize( this ) {}
A következőt csinálja:
Amennyiben a this változó lokkolva van, akkor vár.
Ha nincs lokkolva, keresztül megy rajta.
Mit lehet elmondani synchronized( this ) után?
- Aki a meghívásig lokkolta a this objektumot, az elengedte.
Indítasz egy Thread-et, ami lokkolja a this-t, amíg fut.
A synchronize { this } {} meg fogja várni, hogy a thread véget érjen és csak aztán megy tovább.
Egyébként ennek a példának semmi értelme sincs, mert a Thread.join() sokkal elegánsabb és érthetőbb is.
Ezzel "csak" annyi a baj, hogy a synchronize nem csak thread joinra hasznalhato, annal sokkal tobbet jelent. De kar ezt ragozni akkor, amikor erzelmi kerdes egy programozasi nyelv kivalasztasa :)
[quote:9e186c8b89="_Joel"]Egy JVM-ben elvileg csak egy elszabadult thread miatt lehetnek memory leak-jeid (vagy mondjuk akkor ha ugy programozol JDBC-t, hogy nem olvastal utana annak, hogy mit is csinalsz es elfelejted close-olni a statementedet meg a tobbit)
Joel már hiányoltalak!:-)
Viszont ismét bele kell kötnöm abba amit mondsz, mert hülyeség.
Egy tucatnyi modon lehet a Java-ban olyan programot irni, ami memory leak-es.
Ajánlom figyelmedbe az alábbi linket:
http://www.javaworld.com/javaworld/javatips/jw-javatip79.html
Ez ez csak egy példa a sok közül! Tudnék Neked még jópárat mutatni!
Fri
[quote:e8b57dfe0b="_Joel"]
Nézd meg jobban. Pl ez szerinted mit csinal (nem en irtam, egy tech tip-bol ollozva: http://java.sun.com/developer/JDCTechTips/2005/tt0601.html
hm
megnéztem, tényleg tud előre definiált N darab műveletet 2D-ben.
nekem speciel 3D kell, és speciális szűrők kellenek, úgyhogy számomra értéke... csekély.
egyébként a Sun oldalán írják, hogy
"The Java Advanced Imaging API may be run without any native code, i.e., without the code which provides native acceleration."
ja hogy natív kód van mögötte... így könnyű.
[quote:e8b57dfe0b="_Joel"]
Miert biznad GC-re? Tisztaban vagy a GC mukodesevel, vagy csak bizonyosan nagy tapasztalattal rendelkezo C++ programozokent halvany lila elkepzeleseid vannak rola?
hm
lehet hogy nem voltam elég explicit.
tehát bejön szabványos képként 800MB egyben allokálva.
feladat: szabdald szét frame-ekre /egyedi képekre/, úgy hogy azok külön objektumok legyenek, külön kezelhetők, törölhetők stb, de közben ne fuss ki a RAM-ból.
Java-s megoldás van triviális?
[quote:e8b57dfe0b="_Joel"]
A fenti konvolucios matrix(ok) alkalmazasa egy kepre megfelel ennek a kriteriumnak, vagy keressek masikat?
magad alatt vágtad a fát. a fenti ugyanis natív library-t használt, gyakran alkalmazott, "közönséges" szűrőkkel. nakünk viszont spéci szűrőink vannak, amiknek bezony a képbiteken natív kódban végig kell tekerni. erre Java-t javasolnál?
[quote:e8b57dfe0b="_Joel"]
Gépek vezérlése: Ha RT kovetelmenyek vannak, ott valoban gond lehet a GC nem determinisztikus volta, bar az 5-os JVM ergonomics kapcsoloi ota ez talan kezelheto (foleg ha csak soft RT kovetelmenyek vannak).
ja bocs én éles projektben nem akarok early adopter lenni.
[quote:e8b57dfe0b="_Joel"]
Alacsonyszintu io: mire gondolsz, konkretan? Ugy erted, hogy Java-bol lassabban lehet irni ugyanazt a diszket? Vagy micsoda?
spéci digitalizáló kártyákról adat io
[quote:e8b57dfe0b="_Joel"]
Frame grabbeles: Java Media Framework? Amikor utoljara neztem akkor eppen viszonylag keves formatumot ismert, de a plugin architektura miatt ez csak vendor tamogatas kerdese... (mondjuk ez kisse tenyleg remenytelen - bar a DVB-MHP es J2ME hazassag miatt meg lehet belole valami).
early adopter
[quote:e8b57dfe0b="_Joel"]
Miért, az iparágban, HPC körökben, numerikus problémákra ez a de facto ipari szabvány nyelv, mind a mai napig. Nagy mátrixok szorozgatására a legkényelmesebb... legalábbis az öreg szakik szerint, én meg hiszek nekik.
nagy félreértés. Fortrant bocs nem bántani.
arra utaltam, hogy nyomatjuk, hogy mindenre Java, Java... esetleg néha kis Fortran, meg más célra ez, meg az...
akkor már meg is érkeztünk a dolog lényegéhez: nem mindenre jó a Java.
[quote:e8b57dfe0b="_Joel"]
még nem kellene leszólni egy másik nyelvet/platformot mindenféle mondvacsinált indokkal.
ööö mondvacsinált, ha a munkakörömben előforduló feladatok nagy százalékára nem alkalmas?
/de isten biz, én nem döglök meg egyik nyelvért se, csak b.sza a csőrömet ez a "gumimaci jó, gumimaci szép, építsük fel belőle a golden gate hidat" effektus/
A QT az előfordítójával sok varázslást elvégez. Talán a jövő generációs QT-k támogatni fogják.
A connect( obj, SIGNAL( "timeout()" ), this, SLOT( "slotTimeout()" ) )
az már igen közel áll a reflection-höz. Csak előfordító kell hozzá.
De a legjobb az lenne, ha a signal / slot / reflection bekerülne a C++-ba és előfordító nélkül is menne.
[quote:454d616afa="Csab"]
C++ alatt lehet közvetlenül a memóriába írni és onnan olvasni minden különösebb erőfeszítés nélkül. Ráállítasz egy pointert a grafikus képernyőre és megy.
Java-ban meghívod a getPoint(...) metódust, aztán a setPoint(...)-ot is, ami... Vagy ráállítasz egy 1000x1000-es tömböt?
Mialatt C-ben egyszerű írás olvasással jóformán energiabefektetés nélkül pontonként szőrözhetsz a képen, addig ez java-ban nem megy.
Összegyűjtenek pár alapműveletet:
- kép kirakása
- kitöltés
- rajzolások
- scroll
- sprite-ok
...
Ezt C,C++-ban megírják, azt kész. Ha ennél több kell, használj C-t. Persze az is igaz, hogy a játékok 99%-ánál ez elég is.
a MemoryImageSource pontosan egy tombon mukodik, tessek elolvasni!
egy nokia6600 siman fut olyan alpha-s (32bit/pixel) "sprite?" kirakom ami runtime decompresszal(1:3) + tukroz + flippel, igen javaban
es ebben a leglassabb cpu van az s60-as sorozatbol...
[quote:b8c5e8ec12="maszili"]Nem is fogom mert engem nem érdekel a java... én nem használom. Majd az megmutatja aki használja a java-t.
Azert jol tudod fikazni azt a rendszert, amit nem is ismersz. Mernoki ereny :)
[quote:b8c5e8ec12="maszili"]A további szócséplés fölösleges.
Ez biztos.
[quote:7fe3d4a2d9="zsolt"]Egyszerűen nem lehet dolgozni egy komolyabb Java alkalmazással. Nem értem, miért nem a GUI gyorsításával foglalkoznak a SUN-nál? Mellesleg most épp egy Java alkalmazás kiváltására írok programot C++-ban, mert a Java cuccos tökéletesen használhatatlanul lassú tetü.
- lehet dolgozni, ha jól van megírva (korábban már hoztam a MagicDraw példát: nagy, Swing, mégis gyors - nekem legalábbis nem lassú)
- Java 6.0: Mustang: http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustang/
Feature: Improve Windows Look and Feel
* Use Microsoft's API for rendering portions of components.
* Ensure Swing's Windows look and feel looks good on Longhorn.
Feature: Improve GTK Look and Feel
* Use GTK API for rendering portions of components (6185456).
* Bring Swing's GTK file chooser up to date with recent changes to GTK's file chooser (5090726).
- használhatatlan Java program: ott valamit a programozó rontott el, nem a nyelv hibája (láttam már nagyon rossz Swing programokat én is, de láttam már elegáns és teljesítő Swing programokat is).
Ezt a problémát a rendes C++ sem oldja persze meg, hanem fagy. A QT-ben van egyedüli megoldás rá:
A QObject destruktora emittál egy destroyed() szignált delete-nél és aki referenciát tartott az objektumon, az ezután elengedi.
Ennél szebb megoldást nem láttam idáig.
QGuardedPtr<QObject> ptr;
Ahol ptr vagy létező objektumra mutat, vagy 0 az értéke.
Általában mikor íródik be az értéke egy változónak a memóriába?
[quote:cf70032d4f="edaile"]Egy programnyelvet azért szeretek, mert mindent meg lehet benne csinálni.
Ilyen a Java, Perl, PHP és a C++.
A Java-t én kihagynám a helyedben, mert azzal biztosan nem
lehet megcsinálni mindent. Nem kivántam még senkinek, de
remélem a pokolra jut aki kitalálta, hogy a memoria kezeléshez
hozzá se férjen a programozó.
Hogy dögölne meg.
Fri
[quote:c5d1188416="bocs"]
megnéztem, tényleg tud előre definiált N darab műveletet 2D-ben.
nekem speciel 3D kell, és speciális szűrők kellenek, úgyhogy számomra értéke... csekély.
Jaj ne legyél már ilyen.
http://www.developer.com/java/other/article.php/3522711
Nézd meg a sorozat korábbi cikkeit is.
[quote:c5d1188416="bocs"]
egyébként a Sun oldalán írják, hogy
"The Java Advanced Imaging API may be run without any native code, i.e., without the code which provides native acceleration."
ja hogy natív kód van mögötte... így könnyű.
Miért, szerinted a JVM-et miben írják?:))
Igen. JAI-val beload-olni. Automatikusan ezt csinálja, amit leírták anélkül, hogy te tudnál róla (jó ezt fel lehet fogni negatívumként is - de ha tudsz róla akkor meg befolyásolni is tudod, hogy ezt hogyan tegye).
Persze, hogy magam alatt vágom a fát, ezt már többször is elmondtad. Sőt, hülye is vagyok, de ezt meg vállalom. De mutathatnál egy ilyen spéci szűrőt amit nem lehet konvolúciós mátrixként felírni, illetve amit nem lehet Java-ban ugyanúgy leimplementálni (egy 800 mb meretu int array az Javaban sem mas, mint egy 800 mb meretu int array).
Kifogás.
[quote:c5d1188416="_Joel"]
spéci digitalizáló kártyákról adat io
JNI-vel akár, de meoldható. Tudom, natív kód, fujjj...
Ki mondta, hogy mindenre jó a Java? Hiába van regexp api, csak perl-hez nyúlok, ha szöveget akarok feldolgozni...
Próbáltátok és nem ment, gondolom... Mások is próbálták úgy látom:
http://www.escorp.com/np_TeraMedica.asp
TeraMedica Healthcare Technologies has developed a revolutionary system that intelligently manages digital medical images for the healthcare enterprise. Imaging exams range from kilobytes to gigabytes and may include thousands of images. This poses unique challenges for processing transactions in a scalable manner, especially considering the requirement that the system must scale to millions of exams per year and hundreds of concurrent users. The system has a distributed architecture, utilizing several open source technologies such as JBoss, Hibernate, and JORAM.
Gondolom ez nem egészen ugyanaz a feladat, mint a tiétek. Nagyobb lélegzetűnek tűnik, és azt írják az egész Java...
Vagyis a Java sz@r. Értem én:)
[quote:b306818594="Csab"]Nem fikázom a java-t, csak leírom, hogy vannak hátulütői. Lehet, hogy ez néha keményre sikeredett, de szerintem a java még messze nem tökéletes.
Mi meg leírtuk, hogy miért nincs igazad, és hogy milyen részeit nem vetted figyelembe :) Egyébként stimmel :)
[quote:b306818594="Csab"]Mindenesetre a kettő ötvözéséből fantasztikus dolgokat lehetne kihozni.
Igen, ezt hívják Java-nak :). Ha átgondolod alaposan, hogy miről van szó (futásidejű felderítése az osztályoknak = managelt környezet), akkor Te is belátod.
ui: Azért ilyen nagy az arcom, mert most nézem a heap-foglalások teszjeinek eredményét (néhány-millió new XY() hívás Java-ban, ill. new XZ() és delete hívás C++-ban. Igen, a Java közben elég sok GC-t futtat, de még így is 10x gyorsabb. Aki nem hiszi kimérheti, nyilvánossá teszek minden kódot, csak fejezzem be a cikket róla :)), ill. a GC futásának felső határának korlátozását.
[quote:be7b4ed70e="bocs"]
megmagyaráznád, mi lehet optimálisabb egy optimalizált tároló, hozzá optimalizált típus párosnál?
a cikket pedig köszönöm a nép nevében, olvasom!
Az optimumot globalis szinten nezd, ami adott tipusra optimalis, nem biztos, hogy globalisan is optimalis eredmenyt ad, kulonosen sok specializalt tipus eseten.
A kevesebb es egyszerubb kod (es adat) lehet, hogy belefer processzor cache-be, es a branch is jobban becsulheto. Pont emiatt nem jo optimalizacio az, ha a fordito mindent inline-ol.
ez igy jo is, csak ne haragudjal azokra akik mikozben a felkesz hidon
jarnak, lelkesednek is picit...
[quote:122d70654b="Csab"]Ezt a java-ban is meg lehetne szebben csinálni.
Amikor a referenciaszámláló eléri a nullát (körökörös referenciát is figyelembe véve) -> meghívódik egy destruktor
Hozzá kéne adni még egy delete parancsot, amely kitörli az objektumot és ha mutat rá referencia, kinullázza a referenciákat.
Ez lenne szerintem az észszerű viselkedés.
Te Csab!
Egy dologra kernelek. Ulj mar le egy darab papirral es legalabb egyszer rajzold le (gondold vegig), hogy miafrancrol hadarsz itt! Aztan ha meg mindig borzasztoan okosnak tartod magad, akkor erdemes lenne egyszer csak a proba kedveert lekodolni, amit szeretnel, es akkor belatnad, hogy mekkora suletlensegeket beszelsz.
Mondok egy rovid peldat: van 500000 objektumod, amelyiknel mindegyikbol-mindegyikbe mutat referencia (most arrol ne beszeljunk, hogy ez milyen design eredmenye). Amikor ez a hobelevanc ugy-ahogy van elerhetetlenne valik a program szamara (mert kivulrol mar nincs ra juk hivatkozas), kivancsi lennek arra a referenciaszamlalos algoritmusra, ami kisutne, hogy ezt cuccot fel lehet szabaditani. Valszeg rohadt sokaig futna.
Most csak nagyon vazlatosan elmondom, hogy nagyjabol hogyan mukodik a GC (egyreszt, mert en sem ertek igazan hozza, masfelol tenyleg vannak jo doksik errol). Ha mar erted a lenyegi kulonbseget, akkor ujra vitazhatunk, de most ilyen kisdobos hozzaallassal kar vitatkozni arrol, hogy mi a jo es mi nem.
Szoval, amikor GC mukodesbe lep, akkor az algoritmus elindul a root-object referenciaktol (globalisok, static valtozok, lokalisok, regiszterek), es a referenciak menten bejarja azt a grafot, aminek a csomopontjai maguk az objektumok az elei pedig az adott objektumbol indulo referenciak (az algoritmus a szelteben kereses v. melysegi kereses neven fut az Alogritmusok konyvben). Ezen objektumok erhetoek el a program szamara, amik benne vannak ebben a grafban (szepen mondva elerhetoek a root-objectekbol). A tobbi objektum felszabadithato, akarhany hivatkozas is mutat rajuk.
A te modszered ott santikal, hogy mindenkeppen a referenciabol szandekozol megmondani a frankot, de nem az a lenyeg, hanem a root objectekbol valo elerhetoseg.
Ez sokkal gyorsabb, mint a te algoritmusod, de meg igy is lassu. Altalaban kulonfele heurisztikakat hasznalnak, amik meggyorsitjak a mukodest igaz csereben nem annyira precizek. Helyesen mukodnek, viszont nem biztos, hogy felszabaditjak az osszes osszes eldobhato objektumot.
Majd Joel kijavit, ha valahol tevedtem, mert sem GC guru nem vagyok, Java programot meg meg csak konyvben lattam forraskodban.
[quote:ec879deae1="Csab"]Ezt a problémát a rendes C++ sem oldja persze meg, hanem fagy. A QT-ben van egyedüli megoldás rá:
A QObject destruktora emittál egy destroyed() szignált delete-nél és aki referenciát tartott az objektumon, az ezután elengedi.
Ennél szebb megoldást nem láttam idáig.
QGuardedPtr<QObject> ptr;
Ahol ptr vagy létező objektumra mutat, vagy 0 az értéke.
Eros megkotes, hogy az osztalyaidnak a QObject-bol kell szarmaznia. Hogyan teljesited ezt a kriteriumot egy olyan konyvtarnal, aminek nincs meg a forrasa?
Ez nem túl meggyőző, hogy a java és a C++ ötvözete java-t eredményez.
Akkor miért használok, mégis C++-t java helyett, ahol lehet?
És a kollégáim miért nem rajonganak a java-ért?
A fent említett dolgok miatt nem használom a java-t. Meg az sem biztos, hogy lesz jövője. A C++ még megmarad egy darabig, de ha a .NET győz, a java röpül.
A java-nak igencsak erősítenie kell, ha versenyben akar maradni. Sok a konkurens.
[quote:da693905f4="mikcsabee"]
A következő idézet erről az oldalról származik:
http://www.php.net/manual/hu/intro-whatcando.php
Köszi! :) Értettem. Elég lett volna, hogy RTFM! Ismét tanultam valamit...
- waiter -
syntern:
Jó, engem meggyőztél, hogy lehet még valami ebből a Javából. Egyelőre még maradok a C++-nál, márcsak azért is, mert most még biztosan használhatóbb kódot lehet vele írni. Aztán lehet, hogy tényleg eljön majd a Java ideje 1-2 év múlva (vagy épp a c#-é).
Nekem spec. a normális memóriakezelés biztosan fog hiányozni. Olyan ez mint a kézi és az automata sebességváltó. Ha az ember évek óta vezet kézi váltóval, nem biztos, hogy szívesen vesz automata kocsit.
[quote:4948fa923f="_Joel"][quote:4948fa923f="bocs"]
megnéztem, tényleg tud előre definiált N darab műveletet 2D-ben.
nekem speciel 3D kell, és speciális szűrők kellenek, úgyhogy számomra értéke... csekély.
Jaj ne legyél már ilyen.
http://www.developer.com/java/other/article.php/3522711
Nézd meg a sorozat korábbi cikkeit is.
Úgy látom, pixel műveleteknél csak valós tesztek segíthetnek annak eldöntésében, hogy ez mennyire életképes. Majd nekilátok egyszer, ha lesz rá idő, hogy x,y,z JVM k,l,m beállítások mellett hogyan teljesít.
[quote:4948fa923f="_Joel"][quote:4948fa923f="bocs"]
egyébként a Sun oldalán írják, hogy
"The Java Advanced Imaging API may be run without any native code, i.e., without the code which provides native acceleration."
ja hogy natív kód van mögötte... így könnyű.
Miért, szerinted a JVM-et miben írják?:))
?? nem tudom, de ezt úgy tűnik - ki tudja miért - nem Java-ban.
[quote:4948fa923f="_Joel"][quote:4948fa923f="bocs"]
tehát bejön szabványos képként 800MB egyben allokálva.
feladat: szabdald szét frame-ekre /egyedi képekre/, úgy hogy azok külön objektumok legyenek, külön kezelhetők, törölhetők stb, de közben ne fuss ki a RAM-ból.
Java-s megoldás van triviális?
Igen. JAI-val beload-olni. Automatikusan ezt csinálja, amit leírták anélkül, hogy te tudnál róla (jó ezt fel lehet fogni negatívumként is - de ha tudsz róla akkor meg befolyásolni is tudod, hogy ezt hogyan tegye).
szerintem ezt a memória kritikus feladatot te nem akarod megérteni.
a Java használata itt prohibitív.
adott egy X méretű folytonos memóriaterület. hogyan szeleteled fel anélkül, hogy lényegesen több memóriát foglalnál, mint X?
[quote:4948fa923f="_Joel"][quote:4948fa923f="bocs"]nakünk viszont spéci szűrőink vannak, amiknek bezony a képbiteken natív kódban végig kell tekerni. erre Java-t javasolnál?
De mutathatnál egy ilyen spéci szűrőt amit nem lehet konvolúciós mátrixként felírni, illetve amit nem lehet Java-ban ugyanúgy leimplementálni (egy 800 mb meretu int array az Javaban sem mas, mint egy 800 mb meretu int array).
lásd 1. pont. ha tényleg jó bittekerésre is a Java, akkor ez a pont nálad van. mondom ha tényleg jó.
[quote:4948fa923f="_Joel"]
[quote:4948fa923f="bocs"]
ja bocs én éles projektben nem akarok early adopter lenni.
Kifogás.
na ez csúnya volt, miután magad mondod "Ha RT kovetelmenyek vannak, ott valoban gond lehet"
kifogásnak tekinted, ha meghalhat egy páciens a gépben a GC miatt?
[quote:4948fa923f="_Joel"][quote:4948fa923f="bocs"]
spéci digitalizáló kártyákról adat io
JNI-vel akár, de meoldható. Tudom, natív kód, fujjj...
ez az adekvát eszköz? ez a kérdés.
[quote:4948fa923f="_Joel"]
Ki mondta, hogy mindenre jó a Java? Hiába van regexp api, csak perl-hez nyúlok, ha szöveget akarok feldolgozni...
tehát összegezzük:
- pixel buzerálásra talán(!) mégis csak jó.
- numerikus alkalmazásokra inkáb Fortran. ezt akkor nem értem az előző pont miatt. ha ott jó, itt is jónak kellene lennie.
- memória kritikus alkalmazásokra nem jó
- időzítés kritikusokra nem jó
- hardver közeli dolgokra szenvedés /driver szintről ne is beszéljünk/
tehát jó lesz ez éles képfeldolgozásra?
[quote:4948fa923f="_Joel"]
http://www.escorp.com/np_TeraMedica.asp
érdekes, egyetlen szó sincs képfeldolgozásról. csak arról, hogy kórházi rendszer van Oracle adatbázis háttérrel, amihez Java a felület. Ebben mi a nagy szám?
/ja és személyeskedést hagyd, úgy kellemesebb/
Nos, a Nokia telefonokat véletlenül ismerem belülről. Az alap filozófia az, hogy mindent a gyors symbianban(???) kell megírni és köré kell csapni egy vékony java wrappert.
A telefonok egy része már arra is képes, hogy SVG-t rakjon ki a képernyőre. A SVG itt a virágkorát éli. De azért túlzás lenne azt gondolni, hogy az SVG megjelenítő java alatt fut...
A java arra kell, hogy a programozók kényelmesen és gyorsan programozzanak (mert ugye a symbian...), de a magot C++-ban írják.
Végülis a java.exe-ben is ugyanez a helyzet. A JRE-t is C++-ban írták meg, nem java-ban. Az izmosabb részek mind C++-on futnak.
Egyedül a C képes arra, hogy C-ben C fordítót és C runtime-ot meg lehet írni.
[quote:7c185254fe="handler"]
- a java bytecode jvm nelkul hasznosabb mint gondolnad, ugyanis bizonyithato a helyessege, vagy hogy megfelel a specifikacionak...
OK. Ezután az ügyfélnek azt mondom:
"Figyusz Kiccsávó, beverem az ormányod, ha használni akarod a programot.. inkább gyönyörködj a bájtkódban-ban, nézd meg milyen helyes, mennyire megfelel a specinek!":-)
De, egyébként igazad van, annyira hasznos önmagában, hogy minden java-s fejlesztő miután leforditotta, bájtról bájtra átnézi a bájtkodot.:)
[quote:7c185254fe="handler"]
- ez a foglaljunk kezzel memoriat nalad valami fetis? Miert nem veszed at a forditotol a memoriakezeles problemajat (c, c++ eseten) ha mar olyan jol kezeled a memoriat, elvegre Te is kioszthatod mikor melyik regiszterhalmazt hasznalja...
Nem c-ről és nem is c++-ról van szó.
Amugy igen.. nálam kényes téma. Egy hetet áldoztam arra, hogy megértsem ezt
az egész garbage collector/erőforrás gazdálkodás/memory leak együttest.. megérte.
Fri
[quote:789c38cd2c="Frimen"]
Ez ez csak egy példa a sok közül! Tudnék Neked még jópárat mutatni!
De abban remélem egyetértünk, hogy Javaban a memory leak-ek többnyire tervezési hibák és nem programozói hibák... ugye?
[quote:b04bad043b="Andrei"]
Mondok egy rovid peldat: van 500000 objektumod, amelyiknel mindegyikbol-mindegyikbe mutat referencia (most arrol ne beszeljunk, hogy ez milyen design eredmenye). Amikor ez a hobelevanc ugy-ahogy van elerhetetlenne valik a program szamara (mert kivulrol mar nincs ra juk hivatkozas), kivancsi lennek arra a referenciaszamlalos algoritmusra, ami kisutne, hogy ezt cuccot fel lehet szabaditani. Valszeg rohadt sokaig futna.
A Garbage Collector sem nulla ideig fut rajta. :-)
Én a referencia csökkentésbe tenném bele a GC-t, hogy logikus legyen.
[quote:b04bad043b="Andrei"]
Most csak nagyon vazlatosan elmondom, hogy nagyjabol hogyan mukodik a GC (egyreszt, mert en sem ertek igazan hozza, masfelol tenyleg vannak jo doksik errol). Ha mar erted a lenyegi kulonbseget, akkor ujra vitazhatunk, de most ilyen kisdobos hozzaallassal kar vitatkozni arrol, hogy mi a jo es mi nem.
Szoval, amikor GC mukodesbe lep, akkor az algoritmus elindul a root-object referenciaktol (globalisok, static valtozok, lokalisok, regiszterek), es a referenciak menten bejarja azt a grafot, aminek a csomopontjai maguk az objektumok az elei pedig az adott objektumbol indulo referenciak (az algoritmus a szelteben kereses v. melysegi kereses neven fut az Alogritmusok konyvben). Ezen objektumok erhetoek el a program szamara, amik benne vannak ebben a grafban (szepen mondva elerhetoek a root-objectekbol). A tobbi objektum felszabadithato, akarhany hivatkozas is mutat rajuk.
A te modszered ott santikal, hogy mindenkeppen a referenciabol szandekozol megmondani a frankot, de nem az a lenyeg, hanem a root objectekbol valo elerhetoseg.
Ez sokkal gyorsabb, mint a te algoritmusod, de meg igy is lassu. Altalaban kulonfele heurisztikakat hasznalnak, amik meggyorsitjak a mukodest igaz csereben nem annyira precizek. Helyesen mukodnek, viszont nem biztos, hogy felszabaditjak az osszes osszes eldobhato objektumot.
Majd Joel kijavit, ha valahol tevedtem, mert sem GC guru nem vagyok, Java programot meg meg csak konyvben lattam forraskodban.
Engem nem érdekel, hogy hogyan működik belülről az egész. Legyen rendes belépési pont és kilépési pont (destruktor) és kész. Meg lehet rendesen és gyorsan csinálni, csak nem a legegyszerűbb.
Sőt, még az is elfogadható megoldás lenne, hogyha a referencia-számláló nullára megy -> destruktor, egyébként GC. Ha valakit ez zavar szüntesse meg a körkörös referenciákat. De destruktor nélkül elég gagyi az egész.
[quote:343560d3ed="lokoto"]
Elég meredek a következtetésed. Ettől még semmi nem rosszabb semminél, ...
Dehogynem... ha valamit (itt most értelmes / hasznos dologra gondoltam) egyszerűen meg tudok csinálni A eszközzel és azt NEM vagy csak körülményesen egy B-vel akkor az szerintem B rosszabb mint az A.
Kiemelem a fontos részleteket:
[quote:343560d3ed="lokoto"]
...mert javában nem tudsz *a-t írni, ezért ha az a = b-t felüldefiniálod a = b.clone() funkcionalitására, nem tudod miként megvalósítani a jelenlegi értelemben vett a = b műveletet, azaz hogy az a változó a b változó által mutatott objektumra mutasson.
[quote:343560d3ed="lokoto"]
... így definiálták a szintaktikát és szemantikát.
Ezt elfogadom. De a fentiek értelmében továbbra is fenntartom hogy rosszúl tették...
[quote:343560d3ed="lokoto"]
Primitív típusok esetén a változó az értéket hordozza, egyébként pedig hivatkozás egy objektumra. Pont.
Ezzel bonyolítva az értékadás műveletét... mert így többféle értékadásról beszélünk attól függően hogy az operandusok mik is valójában...
pl. ha csak ennyit látsz a kódból
a = b ;
akkor meg tudod mondani hogy az egyenlőség mit csinál?
Valószínüleg nem mert nem tudod hogy az a és b micsoda is tulajdonképen. Most átmásolja a tartalmát vagy csak a címét???... :)
[quote:343560d3ed="lokoto"]
Mikor a Javában meghatároztak a nyelv alapjait, valószínűleg végignézték, hogy jelenleg mi van, minek mi a hibája, előnye, és megpróbáltak jobbat kihozni (az adott feladatra).
Ha jól tudom a C# szintaktikája és szemantikája nagyon hasonlít a javáéra, vajon véletlen, hogy ott sincsenek pointerek?
A c#-t ugyanolyan rossznak tartom mint a java-t. Sőt még rosszabbnak mert az m$ műve. :twisted:
[quote:343560d3ed="lokoto"]
Művelet:
a = b;
mélymásolás esetén:
a == b false
jelenlegi működés:
a == b true
Nekem a jelenlegi működés logikusabb. Neked nem? :-)
Bevallom ezt nem értem... :oops:
Mi az hogy jelenlegi működés?
[quote:343560d3ed="lokoto"]
Nyilván az ==-et is felül lehetne definiálni, de lássuk be, hogy az egyik kolléga által felvázolt szemethalmazt kapjuk nagyon rövid idő alatt, mert senki nem fogja tudni, hogy mi micsoda.
Ez nem igaz...
Az == (összehasonlító) operátor MINDÍG azt jelenti hogy valamilyen szempontból a két operandus "egyenlő" vagy sem. Az eredménye mindíg egy igaz / hamis logikai érték lesz.
[quote:343560d3ed="lokoto"]
Arról nem is beszélve, hogy a mélymásolás logikája egy egyszerű operátori logika komplexitását jóval meghaladja.
Ezt nem értem... c++-ban amikor operátort írsz akkor bármilyen kód lehet az operátor működése mögött... a bármilyen kód szerintem lefedi a komplexitás fogalmát.
[quote:a09a7d2441="syntern"]En ugy vettem eszre aktiv Symbian fejlesztő ismerőseimen, hogy egyre cifrábbakat tudnak káromkodni a nyelv és a platform kényelmetlenségén .net és javahoz képest. Persze lehet, hogy nekik nem olyan fejlesztési feladatuk volt, mindenesetre az egyik szoftverükkel a nokia középvezetője példázódott valami konferencián... (symella, ha mond valamit és jól írom...).
Symbianhoz nem volt szerencsem, mert azok a telefonok egy egyedi oprendszert hasznaltak. Egyebkent nyilvan nekem sem a kedvenc kornyezetem a C (ez gondolom kiderult az eddigiekben), de tovabbra is azt allitom, hogy lehet benne tisztesseges szoftvert irni. Teny, hogy a fejlesztes kevesbe hatekony, de egyelore nagyon sok helyen egyutt kell elni vele.
[quote:a09a7d2441="syntern"]Én évekkel ezelőtt nagyon néztem a D nyelvet, programokat is írtam rajta. Egészen addig, míg egy alkalmazásnál azt mondta az üzemeltető, hogy vagy C++ vagy Java, ismeretlen marhaságokat ne akarjak futtatni. (erőgépen, felügyelt környezetben sok-sok procival)
Igen, de ez nem a nyelvet minositi. Osszesen annyi, hogy (meg?) nem elterjedt, es az illeto donteshozonak nem volt hozza bizalma. Kezdetben a Java sem tarolt, most pedig az egyik leggyakrabban hasznalt nyelv.
[quote:a09a7d2441="syntern"]Persze, de azt ugye tudod, hogy a C++-os memória-felszabadítás után az üres memória-terület töredezetté válik, míg Javaban a fogalom is ismeretlen? Azaz előfordulhat olyan C++ eset, amikor a GC takarít, de az allokáció sikertelen, mert a memória-terület nincs összenyomva, pedig egyébként a darab összessége elég lenne.
Erről a Tanú jut eszembe, meg a narancs...
Ezt nem tudtam, szoval koszi az infot, es a vegkovetkeztetessel is egyetertek, de megsem irnam oda a vegere, hogy "...de a mienk". En a C++-ra is csak egy eszkozkent tekintek. Egyebkent az egszet arra irtam, hogy a nyelv csak reszben meghatarozo, mert az egyeb toolkornyezet sokat tud meg hozni vagy rontani.
[quote:a09a7d2441="syntern"]Aha, ezek megoldások, de ha a szemlélet hibás, akkor ezek sem érnek semmit sem. Azaz mindegy milyen szinten, de tisztában kell lenni a szemlélettel, ha helyen akarod alkalmazni a technológiát.
Azt hiszem, hogy egyrol beszelunk.
[quote:a09a7d2441="syntern"]Persze, és a generáció során szépen generálják a memóriakezelést és a managelt környezet összes funkcionalitását, ahelyett, hogy a managelt környezetben futtatnák. Megint csak arról van szó, hogy van egy kitalált, működő rendszer, szeretnénk egy hasonlót, barkácsolunk magunknak, mert mi jobban értünk hozzá. Bejöhet, de általában nem fog.
Itt azert inkabb arrol van szo, hogy akiknek fejleszteniuk kell, azok alltalaban nem szoftverfejlesztok, hanem egy masik terulet szakemberei, es nekik vmilyen egyszerusitett es ismereteikhez szabott rendszert biztositanak egy altalanos nyelv helyett. (Pl. grafikus kodszerkeszto, vagy matlab simulink, stb.) A generalt kod egyebkent nem mindig tartalmazza az altalad emlitett megoldasokat (pl. managelt kod), de teny, hogy bizonyos tekintetben kiprobalt es szabvanyos megoldasokat hasznal fel.
[quote:31ee3c675d="Csab"]
Akkor miért használok, mégis C++-t java helyett, ahol lehet?
És a kollégáim miért nem rajonganak a java-ért?
Az a tény viszont, hogy te főleg mobil eszközökön próbálod használni megmagyarázza, hogy miért gondoltad a referenciaszámlálást kivitelezhetőnek és működőképes algoritmusnak: ott valóban nem kell több millió élő objektumot kezelni képes algoritmusban gondolkodni (legalábbis még néhány hónapig/évig).
[quote:733b3dc766="maszili"]
Ezzel bonyolítva az értékadás műveletét... mert így többféle értékadásról beszélünk attól függően hogy az operandusok mik is valójában...
pl. ha csak ennyit látsz a kódból
a = b ;
akkor meg tudod mondani hogy az egyenlőség mit csinál?
Valószínüleg nem mert nem tudod hogy az a és b micsoda is tulajdonképen. Most átmásolja a tartalmát vagy csak a címét???... :)
Miért, ha C++-ban azt látod, hogy
a = b;
akkor mit tudsz mondani? Mit csinál az a fránya =?
KisKresz
Csak úgy megkérdezném, hogy a hozzászólók közöl hányan tanultak/foglalkoztak deklaratív (Lisp, SML, Scheme) vagy logikai (Prolog es tarsai) programozással?
[quote:57d0a2835c="Frimen"]A Java-t én kihagynám a helyedben, mert azzal biztosan nem lehet megcsinálni mindent. Nem kivántam még senkinek, de
remélem a pokolra jut aki kitalálta, hogy a memoria kezeléshez
hozzá se férjen a programozó.
Hogy dögölne meg.
Fri
nem spagettiprogramozoknak keszult massziv ganyolashoz, arra vannak megfelelobb eszkozok
[quote:ac20c26c42="handler"]
Ugye verifikaciorol meg nem is hallottal :D Az eddigi hozzaszolasaid alapjan (kinyomtatja a bytecodot) nagyon-nagyon ugy tunik. A teszteles egyaltalan nem garantalja a hibamentesseget, de meg azt atveteli jegyzokonyv sem.
A szerződések kitételeiről a felelősség kérdésében nem is beszélve..:)
Tudhatnad, hogy torvenyesen nem lehet korlatlanul felelosseget kizarni. Egy szerzodeshez pedig ket fel kell, persze probalkozhatsz, max massal kotnek szerzodest.
Handler: No comment.
Én a kettőnk közt dúló háborút lezárnám azzal, hogy az utóbbi
mondatod még nekem is sokk volt:
"Tudhatnad, hogy torvenyesen nem lehet korlatlanul felelosseget kizarni."
De legalábbi jót röhögtem rajta.:-)
Fri
[quote:09c2deed9b="Csab"]
A Garbage Collector sem nulla ideig fut rajta. :-)
Ugye tudod mi a kulonbseg egy o(n*log(n)) es egy o(n^3) algoritmus kozott...
[quote:09c2deed9b="Csab"]
Engem nem érdekel, hogy hogyan működik belülről az egész.
Azt látjuk.
Javitsatok ki, de a C++ operator overload igazabol egy makro, ami a szintaktikan egyszerusit, es forditasidoben atirja a kodokat olyanra, hogy az adott funkcio fusson le. Azaz nyugodtan lehetne egy pre-Java nyelvu makrozast csinalni, ami atforditja Java szintaktikara a makrokat.
Szoval van ket szintaktikank, meg kozel transzformalni is lehet oket. Nyilvan a Java nyelvbe azert nem tettek bele, mert akkor nem volt celszeru. Ha a vilag nagyobbik fele most celszerunek latna, akkor masfel even belul a Java nyelv resze lehetne, ahogy az lett az annotacio is peldaul. Ha nem latjak celszerunek, szerintem csak azert van, mert konnyebben el tudnak olvasni egy beszedes metodusnevet, mint ertelmezni egy operatort, hogy akkor az most milyen objektum es mit fogok kapni belole.
[quote:0e3f41eaf1="feledhetetlen"]
amugy meg mindig varok az 'en nagyonis ertem a java-t es elmondom miert gyenge' csoportbol a valaszt arra kerdesre mit csinal a
[code:1:0e3f41eaf1]synchronized( this ) { }[/code:1:0e3f41eaf1]
a 'hat semmit' valasz eseten arra,
hogy miert nem szedi ki a fordito ?
ha javap-pal megnezed benne kell lennie...
Te ugyanilyen mélységben kened-vágod a C++-t is?
KisKresz
[quote:0b36ee804d="Csab"]
.... Ha valakit ez zavar szüntesse meg a körkörös referenciákat. ...
ez király :)
[quote:93f2027112="_Joel"]Csak úgy megkérdezném, hogy a hozzászólók közöl hányan tanultak/foglalkoztak deklaratív (Lisp, SML, Scheme) vagy logikai (Prolog es tarsai) programozással?
Én tanultam. Miért?
KisKresz
[quote:c163d9496b="Frimen"]a java jvm nélkül sokra nem jó, kirakod a kodot a falra és gyönyörködsz benne?:)
gcj-vel nativba forgatott java kod jut hirtelen eszembe
Ugye tudod mennyivel gyorsabb ellenőrizni, hogy a referencia elérte-e a nullát?
Ahol meg körkörös referenciák vannak, ott maradhat a GC... Aki baromságot csinál, az vessen magára, ha késik a destruktora...
[quote:f4dda66f8c="Csab"]Akkor miért használok, mégis C++-t java helyett, ahol lehet?
És a kollégáim miért nem rajonganak a java-ért?
Tipp: lehet, hogy csak felületesen ismered?
Tipp: lehet, hogy csak a mobil Java-t ismered?
[quote:f4dda66f8c="Csab"]A fent említett dolgok miatt nem használom a java-t. Meg az sem biztos, hogy lesz jövője. A C++ még megmarad egy darabig, de ha a .NET győz, a java röpül. A java-nak igencsak erősítenie kell, ha versenyben akar maradni. Sok a konkurens.
A .NET inkább marketingben konkurrens, a jelenlegi formájában ugyanis nem több, mint egy köztes nyelv a kód és a bináris között. Jónak jó, ügyesen fordítják binárisra (== JIT), szép nagy API van mellérakva, de a Java API egy kicsit nagyobb, úgyhogy ez sem érv. A JVM mint futási környezet egyedülálló. Majd ha közelében lesz bármi más, akkor lehet beszélni versenyről. Ha már a .NET-et hozod fel, mint Java konkurrenst, akkor gyakorlatilag beismered, hogy nagyon kevés az alternatíva. :)
Én azt szoktam mondani, hogy alap API szinten nincs nagy különbség Java és .NET között, de az első nem vendor-lock-in, ami nekem már megéri. Emellett még jól is teljesít, sok jó eszköz van hozzá, amelyekhez hasonló funkcionalitást (pl. jó kis refactoring) semmilyen pl. C++ fejlesztő-környezetben nem láttam eddig. Plussz eddig sikeresen elkerült a mobil világra történő fejlesztés, amíg van választás, addig nem akartam beleugrani egy tipikus szívás-témába... :)
Egyaltalan nem. Jobb helyeken standard oktatasi anyag, amit itt leirtam...
[quote:0035639302="_Joel"]
De abban remélem egyetértünk, hogy Javaban a memory leak-ek
többnyire tervezési hibák és nem programozói hibák... ugye?
Egyetértünk.. részben.
Ugyanis ha összetett mintát álmondsz meg, amiben "külső" osztályok
is szerepet kapnak, akkor lehet Te is jól megtervezted.. lehet ők is.. csak épp
a kettő együtt nem müködik..:) Lásd a listeneres példát..
Bevallom én már falra mászok ettől az egész memoria kezeléstől a Java-ban,
mert tudom jó a garbage collector.. pontosabban értem miért jó, ha ugy van
kezelve a memóri ahogy.. de most hogy hibát keresek egyszerűen jó volna
látnom a gb miért nem semmisit meg egy adott objektumot.
Egy "külső" objektumrol van szó.. hol a leak.. nálam, vagy "náluk".. vagy
egyáltalák leak-e az a leak?
Fri
[quote:6c9c477632="Csab"]
Sőt, még az is elfogadható megoldás lenne, hogyha a referencia-számláló nullára megy
Vázolj nekünk egy frappáns megoldást arra, hogy hogyan véded ki a counter felfelé történő túlcsordulását... Ne felejtsd el, a y2k is a "2 számjegy elég az évnek" teljesítményhajhász programozói magatartása miatt lett az ami... (mármint dollármultimilliárdos biznisz:)
[quote:12b001ef97="snq-"]
nem spagettiprogramozoknak keszult massziv ganyolashoz, arra vannak megfelelobb eszkozok
Hát én ilyen optimista okostojás voltam régebben mint Te a beszólásod
alapján itélve, utána szembetaláltam magam pár "problémával", amitől
kiborult a bili.
A java nem csodaszer.. bizonyos dolgokra kifejezettem sz*r a java..
.. és még a spegtti is jobb nála.:)
Fri
[quote:bddbcd8474="Csab"]
A Garbage Collector sem nulla ideig fut rajta. :-)
Én a referencia csökkentésbe tenném bele a GC-t, hogy logikus legyen.
Fubaszki, nem vagy egyszeru. Eppen hogy az a lenyeg, hogy ebben a konkret esetben joforman zerus ideig agyal rajta a GC. Rajzold le magadnak!
Es kulonben sem az a cel, hogy nulla ido alatt menjen le a GC. Ha a te algoritmusod 3 evig fut, a GC, meg 2 perc alatt vegez, hidd el minden normalis IT mernok a GC mellett teszi le a voksat.
[quote:bddbcd8474="Csab"]
Engem nem érdekel, hogy hogyan működik belülről az egész. Legyen rendes belépési pont és kilépési pont (destruktor) és kész. Meg lehet rendesen és gyorsan csinálni, csak nem a legegyszerűbb.
Sőt, még az is elfogadható megoldás lenne, hogyha a referencia-számláló nullára megy -> destruktor, egyébként GC. Ha valakit ez zavar szüntesse meg a körkörös referenciákat. De destruktor nélkül elég gagyi az egész.
Senkit nem erdekel, hogyan mukodik belulrol az egesz, ezert ne is tegyunk mar olyan megszoritasokat, amirol ellenorizhetetlen, hogy teljesul egy adott program eseten. Eppen ez okozza a legnagyobb problemat a tradicionalis memoriamenedzsmenttel.
Pl ha adok neked 5 millio sor C++ kodot, hogyan dontod el, hogy helyes-e a memoriakezelese? Ugyanigy hogyan dontod el, hogy a program futasa soran lehet-e benne korkoros referencia? Ha ezt is tudod (mert ma jobbnal jobb "otletekkel" csalsz mosolyt az itteniek arcara), akkor rohanj el levedetni, egyszer meg meggazdagodhatsz belole...
Eppen ez a legnagyobb erenye a jol megvalositott GC-nek. Semmilyen megkotessel nem el a programoddal kapcsolatban, csak annyival, amit maga a nyelv kenyszerit ki. Ez azt jelenti, hogyha lefordul pl. a C# v. Java programod, akkor (elvileg) a memoriakezelese is helyes. Ezt C++ programrol soha nem fogod tudni elmondani.
[quote:c6cc6d76d7="KisKresz"]
Miért, ha C++-ban azt látod, hogy
a = b;
akkor mit tudsz mondani? Mit csinál az a fránya =?
Azt csinálja amit már kisiskolás korunkban megtanítottak velünk...
Egy jólnevelt értékadásnak megfelelően a b értéke belemásolódik az a-ba, úgy hogy a és b független egymástól. Ezt hívják a java-ban "mélységi másolásnak". Ha nem így akarom akkor azt külön jelzem a kiutált csillaggal... :) és máris egyértelműen látszik hogy mit jelent a kifejezés.
És az egészben az a vicc hogy az értékadás teljesen független az operandusok típusától, mert a programozó okos volt és elkészítette a megfelelő értékadó operátort az osztályhoz.
De nem csak az értékadó operátort írta meg hanem pl. a kiíró operátort is és igy kiírathatom az egyébként igen összetett objektum tartalmát ilyen egyszerűen (hasonlóan a primitív adattípusokhoz)
cout << a ;
[quote:b1c3c8141a="Csab"]Ugye tudod mennyivel gyorsabb ellenőrizni, hogy a referencia elérte-e a nullát?
Ugye tudod, hogy a referencia update-lése nem 0 idő, ráadásul szinkronizációt igénylő pont, ami derékbatörheti a skálázódást multiprocesszoros rendszereken...
[quote:447eac7b9b="KisKresz"][quote:447eac7b9b="_Joel"]Csak úgy megkérdezném, hogy a hozzászólók közöl hányan tanultak/foglalkoztak deklaratív (Lisp, SML, Scheme) vagy logikai (Prolog es tarsai) programozással?
Én tanultam. Miért?
Rajtad érződik is:) De néhányan itt annyira a pointer-ek mellett érvelnek, hogy fogalmam nincs mit kezdenének egy változók nélküli nyelvvel, vagy olyannal amiben csak logikai igazságokat lehet leírni és kérdéseket feltenni...
(a prolog-sml-es targy volt az egyik zarovizsga targyam, nem veletlenul:)
[quote:4d3a094883="Morzel"][quote:4d3a094883="handler"]Az igazi programozo gondolkodik es tanul, aztan:
-megtervezi/megvalositja sajat forditoprogramjat
-megtervezi/megvalositja sajat programozasi nyelvet
-megtervezi/megvalositja sajat architecturajat
;-)
Szerintem aki ezt megcsinalja, az csak szimplan hulye. Nameg ido milliomos.
Morzel
Pedig handler baratunknak igaza van.
http://www.digitalmars.com/d/
Itt mar csak az architektura hianyzik.
Nekem teljesen mindegy, hogy miért büdös az a valami, csak egy biztos, hogy nem szeretem szagolni.
[quote:97a2dd1224="lacipac"][quote:97a2dd1224="hop1"]És kimaradt a pascal :(
Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban.
Te KIS hátuldombolós gimnazista, TE aztán tudod!!!!
Erre a "hátulgombolós"-ra igazán dühös tudok lenni, ha hasonló tapasztalattal rendelkező ember puffogtatja, mint egy átlagos gimnazista lehet. Ha kivételes zseni vagy és mögötted van 4-5 vállalati project (nem feltétlen PASCAL-ban), akkor igen, mondhatsz ilyet.
Úgy gondolom, aki ilyet mond, annak semmit nem jelent és nem is látott modern PASCAL nyelvet, se a Delphi-t, se FreePascal és Lazarust! Így nem tudja és nem ért hozzá!
A Pascal eljutott a DOS-tól a .NET világáig, a struktúrált programozáson át az objektumorientáltságig. Windows, Linux , MacOS..... Mi a baj vele, hogy nem kell szenvedni.... Vagy az, hogy léteznek hozzá ingyenes komponensek is, amikkel lehet dolgozni. Még programba építhető saját szkript-nyelv komponenst is találtam hozzá.....
Attila
[quote:f95d143e09="Frimen"].. bizonyos dolgokra kifejezettem sz*r a java..
ezt irtam en is
[quote:f95d143e09="Frimen"].. és még a spegtti is jobb nála.:)
jah, latom kedvelt a php
[quote:c84758dd07="syntern"]
ui: Azért ilyen nagy az arcom, mert most nézem a heap-foglalások teszjeinek eredményét (néhány-millió new XY() hívás Java-ban, ill. new XZ() és delete hívás C++-ban. Igen, a Java közben elég sok GC-t futtat, de még így is 10x gyorsabb. Aki nem hiszi kimérheti, nyilvánossá teszek minden kódot, csak fejezzem be a cikket róla :)), ill. a GC futásának felső határának korlátozását.
Ezt nem igazán értem. Mi értelme van összehasonlítani a EGY BIZONYOS jvm verzió alatt futtatott java program memóriafoglalását EGY BIZONYOS környezet (oprencer/fordító/libc ...) alatt lefordított és futtatott C++ program memóriafoglalásával?
Ebből kikerekedi vmi eredmény, ami alapján megállapítod, hogy "a java jobb mint A C++" ? Mi annak az akadálya, hogy egy hozzáértő ember írjon olyan memória-kezelő függvényeket/osztályokat C++ alá, ami übereli a javás eredményeket?
[quote:907a0144d1="fdavid"]
Pedig handler baratunknak igaza van.
http://www.digitalmars.com/d/
Itt mar csak az architektura hianyzik.
Nem olvstam végig, de..
>D is a fully garbage collected language
Na ez már alapból lehet al van b*szva!
Ezért sz*r a java is bizonyos dolgokra, mert garbage collector
a felelős a memóriáért: nincs a programozó kezében a memóra.
Fri
[quote:946c4fd1c9="_Joel"][quote:946c4fd1c9="Csab"]
Sőt, még az is elfogadható megoldás lenne, hogyha a referencia-számláló nullára megy
Vázolj nekünk egy frappáns megoldást arra, hogy hogyan véded ki a counter felfelé történő túlcsordulását... Ne felejtsd el, a y2k is a "2 számjegy elég az évnek" teljesítményhajhász programozói magatartása miatt lett az ami...
Bazzze _Joel, en mar ertem a sracot! Ezt a problemat is konnyu megoldani!
Ha azt el lehet intezni, hogy ne legyen korkoros hivatkozas, akkor mar azt is csipobol elintezzuk, hogy egy ojjektumra ne legyen tobb hivatkozas rongyos 4 milliardnal. Majd ugy programozunk, hogy kis papiron strigulazzuk a referenciakat, ha valaki eleri a hatart, kirugjuk a gennybe, nehogymar ilyen slendriansagot megengedjen maganak! Komoly C++ programozok vagyunk, vagy miaszosz. Sot, itt a 64 bites korszak kiccsavok, az annyi ojjektumreferenciat enged, hogy azt mar el sem tudjatok kepzelni.... Kerem kapcsojja ki!
Veszesen writeonly a srac, gondolkodni meg nem akar... Ez nagyon veszelyes kombinacio, foleg, ha C++-ban programozik. Remelem nem vonatfekdrivert fejleszt.
[quote:1337b636da="KisKresz"][quote:1337b636da="feledhetetlen"]
amugy meg mindig varok az 'en nagyonis ertem a java-t es elmondom miert gyenge' csoportbol a valaszt arra kerdesre mit csinal a
[code:1:1337b636da]synchronized( this ) { }[/code:1:1337b636da]
a 'hat semmit' valasz eseten arra,
hogy miert nem szedi ki a fordito ?
ha javap-pal megnezed benne kell lennie...
Te ugyanilyen mélységben kened-vágod a C++-t is?
KisKresz
8 eve nem irtam production quality C++ programot, azelott igen
persze akkor nem volt STL igazan a template sem volt
amugy akkoriban is egy szuk subset-et hasznaltunk csak a C++ jelolesekbol
amugy a tpop.awl.com konyvet tartom az igazi referencianak
abban jol megfer C, C++, Perl, Java mint reprezentans gyakorlati nyelvek
valahogy nalam van tekintelye Rob Pike-nak, es Kernighan-nek akkor is ha a binaris es/vagy operator precedenciajat mellenezte...
[quote:bd4a69b2ce="Csab"]Ugye tudod mennyivel gyorsabb ellenőrizni, hogy a referencia elérte-e a nullát?
Ahol meg körkörös referenciák vannak, ott maradhat a GC... Aki baromságot csinál, az vessen magára, ha késik a destruktora...
Fogadjunk, hogy még sohasem implementáltál két gráf legnagyobb közös részgráfjának a megkeresését megcélzó algoritmust :P
A java alapgondolata szerintem jó. A probléma az, hogy az egyszerűség kedvéért a C++-ból olyan dolgokat is kiszedtek, amit nem kellett volna.
Mindenesetre lehet reménykedni, lassan fejlesztői nyomásra csak visszapakolják ezeket és persze hatszor olyan jó lesz, mint a C++, aztán elmondják, hogy eredetileg is így szerették volna, csak nem volt a megvalósításra kellő energia.
Én szerencsésnek látom a C# megjelenését is. Nyilván, ha C#-ben könnyebb programozni, mint java-ban, ez a java-t is húzni fogja. A lényeg az, hogy legyen verseny.
Ez igy természetes... miért várod el azt hogy a c++ tartalmazza a vindóz specifikus dolgokat? Mert akkor ne tegyünk kivételt és tartalmazhatná a világ összes specifikus dolgát is... a mikrokontrollerektől a szuperszámítógépekig... lehetőleg nem kifelejtve az összes létező oprendszer dolgait... nem?
A mai (PC-n használt) nyelvektől elvárok bizonyos ALAP dolgokat. PL GUI kezelés, szálak, képek, multimédia, kivételkezelés, hálózat, stb. Különben hogyan írjak felhasználói programot? írjak parancssorit?
A java (és a .NET) pont ezeknek az új igényeknek próbál megfelelni.
Tehát a C++-tól nem vindózos dolgokat várok el, hanem hogy pl GUI-t tudjon kezelni PLATFORMFÜGGETLENÜL, és ne kelljen újraírnom Win98, WinXP, KDE, Gnome alatt.
Mert idő (és pénz) pazarlás (lehet).
CSAB írta:
"
Megpróbálom összefoglalni a lényeget.
1. Megalkották a C++-t, az egész jóra sikerült, de leálltak a további szabványosítással. Mindenki olyan könyvtárat ír, amilyet akar.
2. Megalkották a java-t és továbbra is fejlesztik, egy kézben van, ezért egységes megoldásokat használnak
A java fokozatosan fejlődik, míg a C++ áll. Persze hallottam, hogy beszélnek már az új C++ szabványról is...
A probléma valahol ott van, hogy nincsenek egységes C++-os könyvtárak úgy, ahogy java-ban.
Nekem személyesen a C++ magja, az alap szerkezete jobban tetszik, mint a java alap szerkezete. A C++ gazdagabb, míg a java az equals metódusaival fapadosnak tűnik. Egy választékos nyelven könnyebben fejezed ki magad.
Ha a java olyan lenne, hogy a C++-os osztályszerkezeteket használná, én is java-s lennék. Számomra nehézkesnek tűnik az egész és áttekinthetetlen.
Elsősorban érzelmi okai vannak, hogy C++-t használok. Sokkal szebb és választékosabb a C++-os kifejezés forma."
Teljesen egyetértek. Sokáig C++-t használtam és lényegre törő mivolta miatt szerettem meg. Ilyen most a C#. CSak valahogy még nem tud annyit mint a java. (És a mono sem, ami a szabad megvalósítása a .NET-nek).
A java kicsit túlbonyolítottnak tűnik.
Egy fontos kérdés:
- A kedvenc programnyelvek közül miért maradtak ki a BASIC nyelvek?
- Mondjuk Visual Basic...
- És a Pascal származékok?
Érdekelne a válasz.
Lehet egymast alappal/alaptalanul pocskondiazni, de ez az adatgyujtes egyszeru statisztika arrol, hogy ki mit hasznal.
En speciel pascalt (Kylix kornyezetben), es nem tudom, hova ikszeljek.
[quote:263e8e37ef="syntern"]Javitsatok ki, de a C++ operator overload igazabol egy makro,...
Nem igy van...
A operátor pontosan olyan programkód mint az adott osztály bármelyik tagfüggvénye.
[quote:263e8e37ef="syntern"]
... ami a szintaktikan egyszerusit, ...
Ez jó meglátás. Pont az a lényege a dolognak hogy a már megszokott operátorokat használhassam azokra az adattípusokra / objektumokra amelyeket én a programozó talált ki és így nem ismerhették a nyelv készítői.
[quote:263e8e37ef="syntern"]
... es forditasidoben atirja a kodokat olyanra, hogy az adott funkcio fusson le.
Nem átírja a kódot hanem meghívja a kódot.
[quote:263e8e37ef="syntern"]
Ha nem latjak celszerunek, szerintem csak azert van, mert konnyebben el tudnak olvasni egy beszedes metodusnevet, mint ertelmezni egy operatort, hogy akkor az most milyen objektum es mit fogok kapni belole.
Ezzel nem értek egyet...
Nem tartom valószínünek, hogy egy külföldiűl írt szó egyértelműbb lenne a megszokott =, ==, !=, +, ++, -, --, (), stb. operátorokhoz képest.
[quote:bef3f97417="syntern"]
Azert jol tudod fikazni azt a rendszert, amit nem is ismersz. Mernoki ereny :)
Szinte sejtettem hogy ez lesz belőle...
Amikor már elfogynak az érvek akkor jön a vitapartner becsmérlése... :evil:
Na akkor tisztázzuk a dolgokat!
- 1 -
Én láttam már java-t, valamilyen szinten ismerem, de nem komálom és nem használom. Ezt már a legelső hozzászólásomban elmondtam.
- 2 -
[quote:bef3f97417="syntern"]
Ha jól látom még mindig nem árultad el, hogy ennek fényében hogy raknád bele az egész számokat 1-től 500000-ig egy java.util.ArrayList-be.
Ennek mi köze van a témához?
Miért kellene nekem megírnom ezt java-ban?
- 3 -
Én felvázoltam nemtetszésemet a java-val kapcsolatban. Erre jöttél (többek között) Te hogy megcáfold. Szerintem nem sikerült. Ezek után a fejemhez vágod hogy ...jol tudod fikazni azt a rendszert, amit nem is ismersz. Elmondtam hogy IGEN, csak felületesen ismerem!
DE Te aki JÓL ismeri, NEM tudja megvédeni az érveit egy olyannal szemben aki kevésbé ismeri???!!!
Aztán tehetetlenségedben ahelyett hogy a vitapartnerednek igazat adnál elkezded szapulni...
Viselkedjünk már felnőtt, komoly emberként.
- 4 -
Én nem akarok erről a témáról átváltani egy személyeskedő egymást szidalmazó veszekedésbe! Annak SEMMI értelme! Attól senki nem lesz okosabb!
[quote:7b19516b83="Frimen"]
Ugyanis ha összetett mintát álmondsz meg, amiben "külső" osztályok
is szerepet kapnak, akkor lehet Te is jól megtervezted.. lehet ők is.. csak épp
a kettő együtt nem müködik..:) Lásd a listeneres példát..
Bevallom én már falra mászok ettől az egész memoria kezeléstől a Java-ban,
mert tudom jó a garbage collector.. pontosabban értem miért jó, ha ugy van
kezelve a memóri ahogy.. de most hogy hibát keresek egyszerűen jó volna
látnom a gb miért nem semmisit meg egy adott objektumot.
Egy "külső" objektumrol van szó.. hol a leak.. nálam, vagy "náluk".. vagy
egyáltalák leak-e az a leak?
Fri
Hűha... lehet hogy mégsem olyan jó dolog ez az egész? :)
[quote:f21632a507="maszili"][quote:f21632a507="KisKresz"]
Miért, ha C++-ban azt látod, hogy
a = b;
akkor mit tudsz mondani? Mit csinál az a fránya =?
Azt csinálja amit már kisiskolás korunkban megtanítottak velünk...
Egy jólnevelt értékadásnak megfelelően a b értéke belemásolódik az a-ba, úgy hogy a és b független egymástól. Ezt hívják a java-ban "mélységi másolásnak". Ha nem így akarom akkor azt külön jelzem a kiutált csillaggal... :) és máris egyértelműen látszik hogy mit jelent a kifejezés.
És az egészben az a vicc hogy az értékadás teljesen független az operandusok típusától, mert a programozó okos volt és elkészítette a megfelelő értékadó operátort az osztályhoz.
De nem csak az értékadó operátort írta meg hanem pl. a kiíró operátort is és igy kiírathatom az egyébként igen összetett objektum tartalmát ilyen egyszerűen (hasonlóan a primitív adattípusokhoz)
cout << a ;
Valójában halvány fogalmad sincs, mit csinál. Legfeljebb reménykedhetsz benne, hogy a programozónak is az volt a szándéka, amit te hiszel...
KisKresz
[quote:248ce29ec0="lzrd"]
Tudnál jogszabályra hivatkozni?
Nekem laikusként úgy tűnik, nincs igazad. Gondolok pölö a "Magas feszültség! Életveszély!" táblára. Gondolom ezzel analóg módon, ha a programod forrásába/dokumentációjába, első megjelenő felhasználói interfészébe beleírod, hogy nem vállalsz felelősséget, akkor csak nem verhetik el a port rajtad, nem?
PTK/A kártérítés általános szabályai:
342. § (1) Semmis valamely szerződésnek az a kikötése, amely a szándékos vagy súlyos gondatlanságból eredő károkozásért, az életben, a testi épségben, az egészségben okozott károsodásért, továbbá bűncselekmény következményeiért való felelősséget előre korlátozza vagy kizárja.
[quote:ef44ecaee2="Csab"]Egy fontos kérdés:
- A kedvenc programnyelvek közül miért maradtak ki a BASIC nyelvek?
- Mondjuk Visual Basic...
- És a Pascal származékok?
Érdekelne a válasz.
nem/kevesebben javasoltak a listara valo felkerulesuket
[quote:85980dc91d="Frimen"][quote:85980dc91d="edaile"]Egy programnyelvet azért szeretek, mert mindent meg lehet benne csinálni.
Ilyen a Java, Perl, PHP és a C++.
A Java-t én kihagynám a helyedben, mert azzal biztosan nem
lehet megcsinálni mindent. Nem kivántam még senkinek, de
remélem a pokolra jut aki kitalálta, hogy a memoria kezeléshez
hozzá se férjen a programozó.
Hogy dögölne meg.
Fri
Ne legy ennyire korlatolt. Ha memoriat akarsz javabol kezelni, arra boven van lehetoseged. Nezz szet az RT Java kornyeken. De keszithetsz sajat megoldast is.
A masik, hogy vegtelenul naiv vagy, ha azt hiszed, hogy manualisan olyan marha jol kezeled a memoriat ;-)
[quote:bda0225691="_Joel"]
Ugye tudod mi a kulonbseg egy o(n*log(n)) es egy o(n^3) algoritmus kozott...
Én nem tudom. Meg lehet tudni mi az?
[quote:f3050bc565="Csab"]Mit jelent a platform független szálkezelés?
Hozzálinkelsz egy függvény könyvtárat, azt kész?
Izé. Annyira nem néztem meg. Ahol boost van, ott gondolom megy ez is. :oops:
[quote:b26abf6c09="hanischz"]
A mai (PC-n használt) nyelvektől elvárok bizonyos ALAP dolgokat. PL GUI kezelés, szálak, képek, multimédia, kivételkezelés, hálózat, stb. Különben hogyan írjak felhasználói programot? írjak parancssorit?
Az igények jogosak de a megvalósításuk már nem.
Az mondod hogy GUI-t akarsz... rendben. De melyiket?
Ahány rendszer annyi féle. Nem lehet kötelezni mindenkit hogy márpedig építse be a rendszerébe az xy GUI API-ját mert mi azt akarjuk használni. Hiába vannak ajánlások / szabványok ha nem implementálja mindenki. Ez a probléma akkor oldódna meg ha a világ összes cége / fejlesztője leülne és megegyeznének egy nagy közös szabványról... :)
Ajanlott olvasnivalo:
Andrew W. Appel: Garbage Collection Can Be Faster Than Stack Allocation
[quote:2c12768b89="Frimen"]A java nem csodaszer.. bizonyos dolgokra kifejezettem
sz*r a java..
.. és még a spegtti is jobb nála.:)
Fri
Sorolnád, hogy mire szar?
[quote:c890d9c745="handler"]Ajanlott olvasnivalo:
Andrew W. Appel: Garbage Collection Can Be Faster Than Stack Allocation
Az absztrakt első mondatában benne van a lényeg:
[quote:3d2911d762="lzrd"][quote:3d2911d762="_Joel"]
Ugye tudod mi a kulonbseg egy o(n*log(n)) es egy o(n^3) algoritmus kozott...
Én nem tudom. Meg lehet tudni mi az?
Kis ordónak hívják, és algoritmusok nagyságrendi lépésszámát jelöli. Ha beírod google-ba, hogy "kis ordó", akkor elég jó online anyagokat lehet találni, amik sokkal jobban elmagyarázzák, mint én. Pl ez itt egész korrektnek tűnik:
http://www.inf.unideb.hu/~aszalos/algoritmus/alg.pdf
Javában ill C#-ban ilyen nem lett volna.
Szerintem akármelyik programnyelvről is legyen szó, programozni tudni kell.
Nos, aki írt bonyolult és nagy programot az tudja hogy a hibák száma a sorok számával nő!!!!! Hiába tudsz programozni...
Azért nem nulláztam változót, mert zavartak programozás közben (nem ideális munka környezet)! És persze nem tudtam figyelni. Nézd meg az MS programozókat. Láttam dokumentum filmet róluk, napi 16 órát is dolgoznak! Nehogy azt mondja valaki hogy 16 órán keresztül tud valaki koncentrálni...
Ezért kellenek a menedzselt és egyéb segítséggel felvértezett prog nyelvek h a rabszolga munkát a fordító automatikusan megcsinálja.
[quote:60dbdbc137="zsolt"]Nekem spec. a normális memóriakezelés biztosan fog hiányozni. Olyan ez mint a kézi és az automata sebességváltó. Ha az ember évek óta vezet kézi váltóval, nem biztos, hogy szívesen vesz automata kocsit.
:) bocs, hogy off, de azt is szokták mondani, hogy aki egyszer kipróbál egy jó automata váltót, az többet vissza se néz :)
(ennek ellenére a C++ a kedvenc prognyelvem :) )
[quote:64d6c7bda8="_Joel"]De néhányan itt annyira a pointer-ek mellett érvelnek, hogy fogalmam nincs mit kezdenének egy változók nélküli nyelvvel, vagy olyannal amiben csak logikai igazságokat lehet leírni és kérdéseket feltenni...
(a prolog-sml-es targy volt az egyik zarovizsga targyam, nem veletlenul:)
Most a burkolt leszólástól eltekintve, miért lenne érdemes ezeket a nyelveket tanulni? Milyen problémákat lehet velük hatékonyabban vagy gyorsabban megoldani, mint amire a "népszerűbb" nyelvek képesek?
(mindíg is érdekelt a Scheme, Lisp)
Huhuuuu.
Ajanlott kozmondas: A papir sokmindent elbir.
Miert van az, hogy valahanyszor idecibal az ember egy Java vagy C# kodot, akkor annak tobbnyire az a kozos vonasa, hogy lassu.
En fejlesztek C++-ban es C#-ban is munkam soran (es igazabol a C#-ot jobban szeretem), de eszembe se jutna ezt igy globalisan kijelenteni, hogy a GC leveri a hagyomanyos memoriafoglalast. Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
[quote:2e5d96e3a8="KisKresz"]
Valójában halvány fogalmad sincs, mit csinál.
Pontosítsunk!
Valójában halvány fogalmad sincs, hogyan csinálja.
Ez így helyes.
Mivel OO -rol beszélünk nincs rá szükségem és nem is érdekel... nekem pont elég egy absztakciós szinttel feljebb lévő problémával foglalkozni.
[quote:2e5d96e3a8="KisKresz"]
Legfeljebb reménykedhetsz benne, hogy a programozónak is az volt a szándéka, amit te hiszel...
Szerintem a világ elég nagy százalékának ugyanazt jelenti pl. a = jel... :) Miért írná meg máskép a programozó?
[quote:b2b27470aa="Frimen"]
OK. Ezután az ügyfélnek azt mondom:
"Figyusz Kiccsávó, beverem az ormányod, ha használni akarod a programot.. inkább gyönyörködj a bájtkódban-ban, nézd meg milyen helyes, mennyire megfelel a specinek!":-)
N ugyfel meg azt mondja neked X ido utan, hogy a programod rossz, a szamitasok nem helyesek es emiatt neki Y millio forintos kara keletkezett, es legyel szives minden kart es javitassal felmerulo koltseget megteriteni. :D
[quote:b2b27470aa="Frimen"]
Nem c-ről és nem is c++-ról van szó.
Amugy igen.. nálam kényes téma. Egy hetet áldoztam arra, hogy megértsem ezt
az egész garbage collector/erőforrás gazdálkodás/memory leak együttest.. megérte.
Fri
A fenti bytecode hozzaszolasodbol nem igy tunik. Osztott eroforrast hogy kezelsz? Refcount ? :D Memory leak (es memory corruption) nelkui kodot pedig aligha fogsz a fenti feltetel teljesulese nelkul csinalni...
[quote:aca5ce1970="hanischz"]Ilyen most a C#. CSak valahogy még nem tud annyit mint a java.
8O valahogy pedig nekem ugy tunik mostanaban a java (nyelv) kullog a c# mogott, tobb-kevesebb sikerrel (durvan felresikerult generics-koppitas, attributes, boxing, enhanced for loop...)
(nem a .NET-re es a java platformra gondoltal inkabb?)
[quote:e6ebba2a13="Andrei"]Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
a generalt kod sebessege pedig egyetlen szempont a sok kozul
Vadonasuj:
http://java.sun.com/performance/reference/whitepapers/tuning.html
[quote:f24643d462="maszili"]
[quote:f24643d462="syntern"]
Ha jól látom még mindig nem árultad el, hogy ennek fényében hogy raknád bele az egész számokat 1-től 500000-ig egy java.util.ArrayList-be.
Ennek mi köze van a témához?
Miért kellene nekem megírnom ezt java-ban?
Az a köze, hogy kiderült, hogy nem is ismered a Javat.
Ha elolvastad volna, hogy mire írom, akkor tudnád. Az "encapsulation"/"hidding" nem arra való, hogy szemellenzőt vegyünk, hanem arra, hogy egyszerűbb legyen az életünk, illetve ne tudjunk belenyúlni abba, amihez nincs közünk. Ettől függetlenül számos esetben illik ismerni egy osztály működését.
Például ha üres, alapértelmezett konstruktorral létrehozott listába pakolsz egymást után 500000 elemet, a háttér tömböt többször is meg kell növelni, majd az elemeket áttenni, ami nyilván nem az elérhető teljesítmény.
[quote:f24643d462="maszili"]
Én felvázoltam nemtetszésemet a java-val kapcsolatban. Erre jöttél (többek között) Te hogy megcáfold. Szerintem nem sikerült. Ezek után a fejemhez vágod hogy ...jol tudod fikazni azt a rendszert, amit nem is ismersz. Elmondtam hogy IGEN, csak felületesen ismerem!
DE Te aki JÓL ismeri, NEM tudja megvédeni az érveit egy olyannal szemben aki kevésbé ismeri???!!!
...
Viselkedjünk már felnőtt, komoly emberként.
Itt nem érvekről van szó, hanem arról, hogy durva kijelenteni az operator overloading hiánya miatt a Javáról, hogy rosszabb a filozófiája, mint a C++-é.
Ha nem ismered a Javát, kétlem, hogy ismernéd a filozófiáját, ergo mi alapján teszed a kijelentéseket? Ez komoly emberre vall?
Abból, hogy + jelet rakhatsz két objektum közé még a hatékonyság sem nő egyértelműen (nyilván kérdéses, hogy milyen hatékonyságot nézünk).
Banális példa: "sok" String összefűzése.
A hatékonyság más megközelítésből: írjál egy komplex üzleti logika alapján működő webalkalmazást.
Rugalmasság: dinamikus osztály betöltés/létrehozás, proxy, reflection. Ilyeneket tud a C++? De akár a memóriakezelést is idevehetjük, mert a kód rugalmassabban módosítható a GC-nek köszönhetően, mert a felszabadításokra kevésbé kell odafigyelni. De a rugalmasság kategóriába lehetne azt is sorolni, hogy ahol van JVM, ott a java programok általában azért elfutkosnak, mindenféle fordítgatás nélkül. És még biztosan hosszan lehetne sorolni, vica versa.
Itt két nyelvről van szó (ha eltekintünk a Java platform voltától), mindkettő megállja a maga helyét a megfelelő helyzetben, nyilván előfordul olyan eset is, amikor preferencia vagy egyéb szubjektív vagy más dimenziókban működő tényezők alapján történik a választás.
[quote:17b3e5a091="hanischz"]
Nos, aki írt bonyolult és nagy programot az tudja hogy a hibák száma a sorok számával nő!!!!! Hiába tudsz programozni...
Azért nem nulláztam változót, mert zavartak programozás közben (nem ideális munka környezet)! És persze nem tudtam figyelni. Nézd meg az MS programozókat. Láttam dokumentum filmet róluk, napi 16 órát is dolgoznak! Nehogy azt mondja valaki hogy 16 órán keresztül tud valaki koncentrálni...
Szia.
Nem tudom, hogy ki vagy, de egyet értek Veled.:)
Sőt hozzáteszem, a sorok számával és a program bonyolultságának fokával
egyenesarányosan nő a hibakeresés ideje.. és nehézsége.:)
Fri
Javaról: szerver oldalon elmegy.. kliens oldalon viszont
akkorát/annyit lehet szivni vele, mint egy szippntóskocsi/hivatásos..:)
[quote:b75f710769="aperger"][quote:b75f710769="lacipac"][quote:b75f710769="hop1"]És kimaradt a pascal :(
Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban.
Te KIS hátuldombolós gimnazista, TE aztán tudod!!!!
Erre a "hátulgombolós"-ra igazán dühös tudok lenni, ha hasonló tapasztalattal rendelkező ember puffogtatja, mint egy átlagos gimnazista lehet. Ha kivételes zseni vagy és mögötted van 4-5 vállalati project (nem feltétlen PASCAL-ban), akkor igen, mondhatsz ilyet.
...
Attila
szerintem olvasd el:
Az igazi programozó
http://www.szabilinux.hu/orlando_unix/igazi.html
" Legszembetûnõbb különbség a plebs és az igazi programozó között a használt nyelv. Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban."
alapmű. ismerni kell, nem magunkra venni. nem megsértődni.
"az igazi programozó akármilyen nyelvben is bír FORTRAN programokat írni"
[quote:98cdfa250b="ssikiss"]
Sorolnád, hogy mire *****?
Pl.:
- totál alkalmatlan olyan alkalmazáshoz, ami nagytömegű
dinamikusan változo adattal dolgozik (adatbázis), mert a
garbage collector működése enyhén szolva "késéges" és
kaotikus. (Jellemzően mit javasolnak a sun forumon: tegyél
a gépbe több memóriát, ne használd az alkalmazásod terminál
szerveren.. stb..)
Ami a legjobban tetszett: biztos memory leak van a progiban..:)
Erre kicsit bedühödtem és körülnéztem:
http://www.herongyang.com/jvm/
Szóval akárki akármit mond, a Java-ban a legnagyobb szivás a
garbage collector.
Fri
[quote:cefaceb114="fdavid"][quote:cefaceb114="hanischz"]Még pár év és több giga memória lesz a gépekben illetve még erősebb proci. Ilyen gépen remekül fognak futni a progik.
Ez a szemlelet sajnos nagyon helytelen. A megnovekedett teljesitmeny nem azert kell, hogy sz@r programokat irhassunk, hanem azert, hogy olyan feladatokra legyen alkalmas egy gep, amiket korabban nem lehetett teljesitmenykorlatok miatt vegrehajtani. Tehat a plusz teljesitmenyt ertelmes celokra kell forditani.
A masik, hogy enyhen szuklatokuruseg a dolgok jelen allapotaban a szoftverfejlesztest kizarolag PC-s (ertsd: szemelyi szamitogepes) kornyezetre vonatkoztatni. Ugyanis meglehetosen nagy szamu beagyazott eszkoz van korulottunk, amiket mar joreszt szinten magasszintu nyelveken (nagytobbsegeben C-ben) programoznak.
Hmmm, azt kell látni (legalábbis szerintem) hogy manapság nem a CPU és a memória mennyiség a szűk keresztmetszet. Hanem a programhibák tömkelege!
Nézd meg a mobil telefonod! Nem fagy néha? Talán C-ben írták :) Vagy egy csomó más progi pc-n. Linux vagy win alatt.. mindegy. Apache nevű webszerver c mivolta miatt (buffer túlcsordulás) törhetnek be internetről stb.
Egy általános programnál a megrendelő nem azt várja h egy 386-oson is elmenjen a progid, hanem hogy hamar! készen legyen és ne legyen benne hiba!
Tapasztalat!
A java-t is be lehet ágyazni.
Egyébként nem a java-t vagy a c#-ot magasztalom, mert azért megírhatták volna sokkal jobban is őket. Sajnos nekem túl szószátyár lett a java (azaz felesleges sorokat kell írni:rabszolgamunkát utálom), c# pedig túl az ms-hez kötődik, bár a mono feltörekvőben.
Hanem azt mondom h a mostani "válságra" (azaz hiba hiba hátán egy programban, pc, mobil telefon egyremegy, és kijavítanak egy hibát kettő új lesz), a megoldás a menedzselt kód.
Persze a teljesítményt követelő területeken minden csepp proci erőre szükség lesz, ott c vagy asm a megoldás egyelőre.
Az iparnak nagy a tehetetlensége, reégen váltani kellett volna de a konzervatívizmusuk miatt jön egy csomó probléma és általában a felhasznló szív. Pl miért kell egy routernek fagynia? Talán azért mert c vagy asm-ben gyorsan összehányták a kódot. Mert sajna a programozói munkahelyeken hajtják a programozót. Pedig ez szerintem művészet.
[quote:cfa1d3df2e="feledhetetlen"]hat netbeans az netbeans errol nem tudok nyilatkozni, en vi-t hasznalok
de kiprobaltam:
http://javasite.bme.hu/~lazlo/src/no-leak.html
es
Linux hill 2.4.31 #8 Sun Jun 5 19:08:07 PDT 2005 i686
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
nem latok semmi lenyeges elterest a gc-ben akar
java apro.study.leak.Main
akar
java apro.study.leak.Main null
probalom
szivesen segitek, ha megmondod mi faj neked a gc mukodesben...
Hmm.. megnéztem én is a programot amit összehoztál.
Kivettem belőle azt a "garafikont"(?), amit beletettél, mert bevallom 2-3 éve
még leesett volna az alsó álkapcsom.. sőt még pattogott is volna a padlón:)..,
hogy milyen ügyes vagy, ma azonban csak halkan felteszem a kérdést:
ugye azért ennél többet is tudsz?:)
Ajánlom figyelmedbe a közel egy tucat profilert.. de akár csak a jconsolt.
Ugyanis az a grafikon nagyjábol arra jó, hogy kezdőknek, vagy itt az olvasoknak maradjon tátva a szája, tényleges mélységi információt nem ad a "memóriában"
lévő objektumokrol.
http://www.netbeans.org/kb/articles/nb-profiler-tutor-8.html
Megcsináltam a teszteket a programoddal, mindkét esetben ugyanazt a "rossz"
képet kaptam, mint az én megoldásomban a "rosszabbik" megvalósitásra (amiben
nincs helyi referencia).
De, hogy ne csak a levegőbe beszéljek, ki fogom rakni valahová a részleteket képpel
megtámogatva.. a hétvégén.. és azért megnézem én még mással is, azokban mit látok.
Fri
Linuxra van C# fordító, vagy a mono csak végrehajtó környezet?
[quote:580b093323="_Joel"]
Kis ordónak hívják, és algoritmusok nagyságrendi lépésszámát jelöli. Ha beírod google-ba,
Köszönöm! Máris nézem.
[quote:85e72087e7="ssikiss"]
Most a burkolt leszólástól eltekintve, miért lenne érdemes ezeket a nyelveket tanulni? Milyen problémákat lehet velük hatékonyabban vagy gyorsabban megoldani, mint amire a "népszerűbb" nyelvek képesek?
(mindíg is érdekelt a Scheme, Lisp)
ML-ről és funkcionális programozásról ez egy jó "miért is jó ez?" oldal:
http://www.dcs.napier.ac.uk/course-notes/sml/introfp.htm
A fő indok amúgy a verifikálhatóság és a korrektség ellenőrizhetősége.
Magyar infó, a 12. slide-tól érdekes:
http://dp.iit.bme.hu/prolog/eloadas_anyagok/dp05a-lpB1_p1.pdf
Ez meg egy egy sch-s projektben létrehozott SchML nevű nyelvről szóló előadás, pár érdekes háttérinfóral különböző nyelvekről:
http://nws.iif.hu/ncd2004/docs/0nj/nj101.htm
[quote:6cf3572894="sz"]
Az absztrakt első mondatában benne van a lényeg:
Nezd meg azt is, mikor szuletett ez az iras. 1986-ban!
Valaki űrtechnológiával dobálózott:
http://www.sun.com/aboutsun/media/features/mars.html
http://www.java.com/en/everywhere/marsrover.jsp
Valaki meg bankokkal. Elárulom, hogy tapasztalataim szerint egyetlen egy olyan hazai szektor van, ami az államigazgatás informatikai sötétségével összemérhető gányolásokat alkot: a bankszektor. Néhol látszanak kivételek, de az összkép lesújtó. Telco-ban határozottan jó dolgozni, ott valahogy normálisabb a technológiai légkör.
(tessék megnézni java lista archívumát: pont múlt héten volt egy jsp-s kérdés, aholis a bank előírta, hogy minden kódnak a jsp-ben kell lennie... erre szokás azt mondani, hogy clueless).
[quote:05692856e9="maszili"][quote:05692856e9="KisKresz"]
Valójában halvány fogalmad sincs, mit csinál.
Pontosítsunk!
Valójában halvány fogalmad sincs, hogyan csinálja.
Ez így helyes.
Mivel OO -rol beszélünk nincs rá szükségem és nem is érdekel... nekem pont elég egy absztakciós szinttel feljebb lévő problémával foglalkozni.
[quote:05692856e9="KisKresz"]
Legfeljebb reménykedhetsz benne, hogy a programozónak is az volt a szándéka, amit te hiszel...
Szerintem a világ elég nagy százalékának ugyanazt jelenti pl. a = jel... :) Miért írná meg máskép a programozó?
Mert megteheti. És a programozó olyan állatfajta, hogy előbb-utóbb meg is teszi. Onnantól kezdve vagy bízol benne, vagy - és én inkább ezt csinálnám - utánanézel a dokumentációban, mi is történik. (Ugye VAN dokumentáció?) És akkor még nem is beszéltünk a leszármazott osztályokkal kapcsolatos problémákról, amiket viszont nem lehet olyan egyszerűen elintézni, hogy "de a programozó úgyse csinál olyat...".
KisKresz
Az igazat megvallva a C++ is képes összebonyolódni.
Amikor érték szerint adsz át objektumokat, akkor átláthatatlanul hívódnak meg a konstruktorok és míg te egy egyszerű programot írtál, lehet, hogy eszméletlen teljesítményt zabál a másolgatással, csak azért mert egy & referencia jelet kifelejtettél a függvények fejlécéből.
Mindenesetre én ilyen teljesítményproblémába nem futottam idáig. A teljesítményproblémák zöme át nem gondolt adatszerkezet miatt volt. Pl. lineáris keresések, amikor a referenciát cache-elhetni is lehetne.
Kezdő programozóknak a C++-t nem javasolnám. Maximum tesztelésre. A kezdő programozók java-ban kevesebb kárt képesek okozni, mint C++-ban.
A java szerkezetének köszönhetően pl. nem képesek globális változók millióit legyártani,... Persze java-ban is láttam már szemét kódot, de sokkal kevesebbet, mint C++-t.
C++-ban szebben lehet programozni, viszont a hülyék hihetetlenül átláthatatlan szemetet képesek gyártani.
Persze java-ról C++-ra váltani megint fájdalmas. Egy tipikus példa:
[code:1:880a9ce0ed]
char * MyObject::writeString() {
char mybuf[ 128 ];
sprintf( mybuf, "Hello world!" );
return mybuf;
}
[/code:1:880a9ce0ed]
A legtragikusabb az, hogy ez a pár sor még le is futhat crash nélkül és csak a felhasználó számítógépén kezd fagyni. Legutóbbi munkám során ilyen kódot kellett karbantartani.
[quote:3c00dce0a5="snq-"][quote:3c00dce0a5="Andrei"]Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
a generalt kod sebessege pedig egyetlen szempont a sok kozul
masik pl. a kod generalasanak sebessege.
[quote:972ac2e574="bocs"]
- pixel buzerálásra talán(!) mégis csak jó.
- numerikus alkalmazásokra inkáb Fortran. ezt akkor nem értem az előző pont miatt. ha ott jó, itt is jónak kellene lennie.
HPC numerikus alkalmazásokra jelenleg elterjedtebb a Fortran, de vannak próbálkozások (http://www.hpjava.org/) ezen a területen is.
[quote:972ac2e574="bocs"]
- memória kritikus alkalmazásokra nem jó
Inkább úgy mondanám, hogy nem tipikus objektumélethosszal rendelkező alkalmazások esetén GC tuningra és kézi memóriaméretezésre van szükség a jól teljesítő kód eléréséhez. Vagy 2x annyi fizikai memóriára, ami azért így a 64 bites computing teljes térnyerése (már a PC-k is!:) idején talán nem olyan erős követelmény.
Ameddig nem szemetelsz (értsd: nem kreálsz rengeteg közepes élethosszú objektumot, amik átcsúsznak a young generation-ből az eden-be vagy az old-ba) addig a GC nem visz el túl sok erőforrást: gyakorlatilag amit megspórolsz a new-n (mert csak egy pointer-t tolsz el a heap-en), azt elveszíted a GC-n. GC tekintetében az old generation GC-je az, ami drága, mert egy lassabb, mark&sweep/copy algoritmust használ a JVM (bár ezt is lehet kézzel változtatni), ráadásul ki tudja hány objektum került át az old gen-be (pl ha az elején lefoglaltál 800 MB-ot egy array-nak, amit soha nem dereferálsz, akkor az garantáltan ott fog csücsülni az old generation-ben)
Arra van ilyen:
http://java.sun.com/docs/books/realtime/
De az RT végülis jelentős mértékben függ a kerneltől, vagy akár a hardvertől...
Nem mondtad még mindig meg, hogy másodpercenként hány képet kell feldolgozni, azt hol kell tárolni, honnan jönnek és ki mit csinál velük. Ha például az a feladat, hogy jönnek DICOM formátumban egy jól specifikált helyről, és bekerülnek egy data store-ba, majd csak a megjelenítésnél orvos szeme előtt kell rajtuk transzformációkat végetni, akkor teljesen jól lehet a feladatot Java-ban implementálni egy szép kis elosztott rendszerben.
Az, hogy a rendszer képeket, leleteket tárol és továbbít és tesz hozzáférhetővé az orvosok számára. Te pedig korábban azt írtad le, hogy Java-ban képek feldolgozása lehetetlen, teljesíthetetlen feladat.
legalabb egy "honorable mention"-t megerdemel :)
:)
Még egy dolog: a prog nyelvek legtöbbjét elég régen készítették. Pl.: Első UNIX, amely c-ben készült 24kB memóriájú szuperszámítógépen futott. Felét az oprendszer foglalta el.
Most nem nagy kunszt kevés hibát tartalmazó progit írni c-ben a maradék 12kB-ra.
(Ja: úgy tűnik utálom a c nyelvet pedig nem: egyik kedven nyelvem volt, de túl léptem rajta. Buildert az egyik legjobb fejl környezetnek tartom).
Megváltoztak a körülmények: akár több 100MB-os progikat több procira kell írni és a toldozott foltozott régebbi generációs nyelvek kevésbé alkalmasak mint egy újra tervezett nyelv.
Közben aki elvégezte még rajtam kívül a mérést: kíváncsian várom a tapasztalatokat.
[quote:c42a6c922c="popacsek"]Ezt nem igazán értem. Mi értelme van összehasonlítani a EGY BIZONYOS jvm verzió alatt futtatott java program memóriafoglalását EGY BIZONYOS környezet (oprencer/fordító/libc ...) alatt lefordított és futtatott C++ program memóriafoglalásával?
Körülbelül annyi, hogy ez az egy bizonyos, ez éppen és véletlenül a legkönnyebben hozzáférhető környezetek közül a legjobbnak számító. Azaz ha valaki nulláról kezd el foglalkozni valamelyik nyelvvel, akkor 95% eséllyel ezeknél köt ki.
[quote:c42a6c922c="popacsek"]Ebből kikerekedi vmi eredmény, ami alapján megállapítod, hogy "a java jobb mint A C++" ? Mi annak az akadálya, hogy egy hozzáértő ember írjon olyan memória-kezelő függvényeket/osztályokat C++ alá, ami übereli a javás eredményeket?
Semmi akadálya. Nyugodtan lehet überelni, kimérjük, publikáljuk. De most éppen ez az aktuális helyzet, ami. Az egész azt bizonyítja, hogy a Java nem rosszabb, mint a C++ :). Sokaknak már ez is sok, bele sem merek gondolni abba, mit szólnak hogyha az jön ki, hogy nemcsak hogy nem rosszabb, hanem jobb is :)
[quote:eabf212389="borzsakb"]
szerintem olvasd el:
Az igazi programozó
http://www.szabilinux.hu/orlando_unix/igazi.html
" Legszembetûnõbb különbség a plebs és az igazi programozó között a használt nyelv. Az igazi programozó FORTRANban dolgozik. A hátulgombolós Pascalban."
alapmű. ismerni kell, nem magunkra venni. nem megsértődni.
"az igazi programozó akármilyen nyelvben is bír FORTRAN programokat írni"
Igaz... néha egy "kicsit" túl komolyan veszem ezt az egészet...
Köszi... Belenéztem... rendesen is el fogom olvasni...
[quote:6b065ac15b="Andrei"]
[..]
En fejlesztek C++-ban es C#-ban is munkam soran (es igazabol a C#-ot jobban szeretem), de eszembe se jutna ezt igy globalisan kijelenteni, hogy a GC leveri a hagyomanyos memoriafoglalast. Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
Mindennek megvan a maga helye. A manualis memoriagazdalkodasnak eppugy, mint a gc-nek.
A szemellenzos hozzaallassal van baj, mert hiaba meno valaki a manualis memorigazdalkodasban, real-world kornyezetben nem tud ezer fele (sokszor egymasnak ellentmondo) szempontot figyelbe vevo memorigazdalkodast csinalni. "Helyes" memoriagazdalkodast (nincs inicializalatlan memoriara hivatkozas, stb) meg kulonosen nem.
Ja, és persze az igazi programozó bármely nyelven képes Fortranban programozni...
:)
[quote:31b89ca6d7="Frimen"][quote:31b89ca6d7="fdavid"]
Pedig handler baratunknak igaza van.
http://www.digitalmars.com/d/
Itt mar csak az architektura hianyzik.
Nem olvstam végig, de..
>D is a fully garbage collected language
Na ez már alapból lehet al van b*szva!
Ezért sz*r a java is bizonyos dolgokra, mert garbage collector
a felelős a memóriáért: nincs a programozó kezében a memóra.
Fri
Olvass tovabb. Kezelheted a memoriat sk, es rabizhatod magad a garbage collectorra is.
[quote:d28bc66a4c="hanischz"]
Nos, aki írt bonyolult és nagy programot az tudja hogy a hibák száma a sorok számával nő!!!!! Hiába tudsz programozni...
Azért kell a problémát szétbontani több kisebb egyszerűbb problámára, hogy egyszerre csak kisebb dologgal kelljen foglalkozni. De ezt nem a programkód megírásakor kell tenni hanem még előtte a tervezési fázisban. Így nem lesz egybefüggő több ezer soros programkódod és konnyebben átláthatod. Hatékony eszközöket ad pl. a c++ arra hogy gyorsan és hatékonyan tudj programot írni... objektum orientáltság, polimorfizmus, template-ek, generikus programozás...
[quote:d28bc66a4c="hanischz"]
Azért nem nulláztam változót, mert zavartak programozás közben (nem ideális munka környezet)! És persze nem tudtam figyelni. Nézd meg az MS programozókat. Láttam dokumentum filmet róluk, napi 16 órát is dolgoznak! Nehogy azt mondja valaki hogy 16 órán keresztül tud valaki koncentrálni...
Ez a példa azt a véleményemet támasztja alá, hogy futásidőben történő hibajavításról van szó. Ami szugségtelen megfelelő odafigyelés/tervezés esetén.
[quote:d28bc66a4c="hanischz"]
Ezért kellenek a menedzselt és egyéb segítséggel felvértezett prog nyelvek h a rabszolga munkát a fordító automatikusan megcsinálja.
A fordítóprogram nem tudja kitalálni hogy mit szeretnél. Ha kifelejtesz egy műveletet akkor azt nem fogja kitalálni és megvalósítani helyetted. Ezért találták ki ezeket a futásidejű hibajavításokat amelyek mindenféle voodoo mágiával statisztikus módszerekkel megpróbálja helyrehozni a programozó baklövéseit úgy hogy nem ad százszázalékos biztonságot és fölöslegesen pazarolja az erőforrásokat.
miert van az, hogy errol azok irnak leginkabb akiknek nincsenek igazan megalapozott ismereteik, sem a javarol, sem a gc-rol, sem arrol, hogy a sebesseg mennyire nem minosit egy nyelvet...
nekem nem volt bajom soha sem a Cvel, sem a Cpluszplusszal,
/* hacsak nem a neve miatt ++?? */
de a Java abszolut 'kedvenc' nyelv nalam, es errol szolt a szavazas
nem azt latome a topiknyiton:
melyik a leggyorsabb nyelv?
ami amugy eleg butuska kerdes is,
megis egyre szuletnek valaszok ra
szoval kedvenc nyelv:
arrol irjunk miert szeretem a PHP-p, vagy miert szeretem a C-t
ne arrol, miert rossz a PHP multithread kezeles, vagy a Java gc...
[quote:4e73a9d9cb="Csab"]Linuxra van C# fordító, vagy a mono csak végrehajtó környezet?
Van, a MonoDevelop egy komplett IDE.
[quote:53aa48db60="syntern"]
class QuickSort{
static final int NUM_ITEMS = 50000000;
int[] numbers=new int[NUM_ITEMS];
..
Bizonyára lehet máshogyan is csinálni részleteket, de tagadhatatlanul működik, és az a "röhejes" sorról sorra kód is látszódik, ha nem tévedek.
Sajnos nem tudom kiprobálni, mert a procim nem birja, a kernel "beszologat",
hogy kurblival állítgaja a frekvenciát.. igy hamis képet kapnék.. de hétvégén nézek,
valami szervert és azon megnézem..
Amugy.. bár tény nem értek sokat a c-hez én ugy tudom, hogy a 4-es gcc nem épp a
legjobban sikerült dolog.
De más.. érdekes kérdés ez a sebesség dolog..:
http://www.kano.net/javabench/
.. és a "válasz"..
http://www.freewebs.com/godaves/javabench_revisited/
Én függetlenül a tesztedtől, meg mindentől amit "olvastam" ismerve a java-t,
kevésbé a c-t, de a tapasztalataimat figyelembe véve, a c tenném a dobogóra
a java-val szemben.
Fri
[quote:fb11591c53="Csab"]Linuxra van C# fordító, vagy a mono csak végrehajtó környezet?
van: http://www.mono-project.com/CSharp_Compiler
[quote:da49958db4="fdavid"]
Olvass tovabb. Kezelheted a memoriat sk, es rabizhatod magad a garbage collectorra is.
OK. Igy korrekt.:)
Nem volt kedvem végigolvasni, mert a Java garbage collector-a
után a "garbage collector"-tól is hányingert kapok.:))
Fri
Ezt a "grafikont"(?) 9 evvel ezelott csinaltam
Igen, tudok ennel tobbet is
Igen, ismerem a profiler-eket, a jconsole-t
Azt gondolom elhanyagolhatoan kicsi a kozos resze annak a ket halmaznak amit te tudsz a javarol, es annak amit en nem tudok
regebben ( http://javasite.bme.hu/~lazlo/src/muzeum/asm/ )
video jatekokat csinaltam 10 evig
Lehet meglepo, de en mar ugyanezt a fajta vitat vegigeltem mikor a C nyelv megjelent.
A C szar, a C nagy kodot csinal, a C lassu, maradjunk a gepikodnal.
Az Impossible Mission II nevu jatekban a vezeto fejleszto kitalalta, hogy o majd megirja C-ben Atatri-ST/IBM-PC-re, aztan a MANX nevu cross compiler csomaggal piff-puff atforditjuk a tobbi gepre.
Aztan mikor eljott a fejlesztesi ido vege fele a piff-puff ideje, leforditottuk a C kodot z80-ra 79K volt...
Kicsi baj volt, hogy a z80 16biten cimzett, es nemelyik target-nek kazettas magno volt a hattertara, igy kicsit furi a dinamikus toltes linkeles.
Szoval azt C kodot kezzel irtuk at z80 kodra Kovats Imivel (isten nyugosztalja). Akar meg is utalhattam volna akkor a C-t.
Aztan ugyanez volt a C++ is.
A C++ lassu, a C++ nem general jo kodot.
Hidd el, lattam mar dolgokat.
Java-t azota hasznalok amiota megjelent.
Rendre megirtam azokat a dolgokat amik meg-meg jelentek a kovetkezo kiadasban (perzisztencia/externalizacio, rmi, etc.)
Azt hittem, en vagyok balszerencses ezzzel, de aztan talalkoztam Gyepesi Gyurival aki egy egesz java szeru nyelvet csinalt meg.
Es aztan nem kis energiaval elmagyarazta, hogy akkor sem erdemes folytatni a fejlesztest, ha ez a nyelv jobb lenne mint a java.
Pedig az o nyelveben az activation framework mar alapbol benne volt mikor a javaban meg rmi sem volt.
Igen, tudok ennel tobbet is
[quote:b9377d1c37="Frimen"]Pl.:
- totál alkalmatlan olyan alkalmazáshoz, ami nagytömegű
dinamikusan változo adattal dolgozik (adatbázis), mert a
garbage collector működése enyhén szolva "késéges" és
kaotikus.
Még konkrétabban? Mi volt az a gyakorlati probléma, amit csak egyetlen módon lehetett megoldani a Java-val és az a GC miatt nem volt jó?
[quote:ba09bc95b8="handler"][quote:ba09bc95b8="Andrei"]
[..]
En fejlesztek C++-ban es C#-ban is munkam soran (es igazabol a C#-ot jobban szeretem), de eszembe se jutna ezt igy globalisan kijelenteni, hogy a GC leveri a hagyomanyos memoriafoglalast. Persze lehet 1-2 mesterkelt peldat felemlegetni, de egy korrekten megirt real-world alkalmazas eseten azt fogod tapasztalni, hogy szemmel lathatoan lassabb a GC kod...
Mindennek megvan a maga helye. A manualis memoriagazdalkodasnak eppugy, mint a gc-nek.
A szemellenzos hozzaallassal van baj, mert hiaba meno valaki a manualis memorigazdalkodasban, real-world kornyezetben nem tud ezer fele (sokszor egymasnak ellentmondo) szempontot figyelbe vevo memorigazdalkodast csinalni. "Helyes" memoriagazdalkodast (nincs inicializalatlan memoriara hivatkozas, stb) meg kulonosen nem.
Felhivnam a figyelmedet, hogy ilyen kornyezetben a GC is borzaszto rosszul teljesit. A korkoros hivatkozasokkal pl. nemigen tud mit kezdeni, vagy erosen leromlik a teljesitmenye....
Sok tekintetben jobb, más tekintetben rosszabb.
Én sok helyen java-t használok, más helyeken C++-t.
Vegyünk egy példát: a KDE C++-ban van írva.
Ha grafikus felület alatt fish-et akarok használni, a KDE fish protokolját fogom elérni és nem szórakozom JAVA varázslással.
Nyilván linux alatt grafikus felületet nem véletlenül nem programozik senki JAVA-ban. Vagy GNOME, vagy KDE. Rengeteg linuxos programot használok, de egyik sem java-s felületű az Eclipse kivételéve.
Jegyezzük meg: egy C++ progit lefordítasz, azonos platformon jó eséllyel menni fog. Ez java-ra nem igaz. Ha nincs java telepítve, megszívtad. Márpedig alapból sem windowson, sem bizonyos linux disztribúciókon nincs java. Ha nem vagy rendszergazdi, megszívtad. Bár unixok alatt nagyon ritka, hogy ne lenne java.
Ha 5-ös java-t fordítasz és kihasználod az új API-t, az nagy valószínűséggel nem fog menni 1.4.2 és korábbi java-kon. Rengeteg szívás volt amiatt, hogy ahol a programot futtatták régebbi java volt.
Ha 2D / 3D alkalmazást akarok írni, ami több platformon is elfut, SDL-t választok, nem java-t. PC-n még nem láttam olyan java-s játékot, ahol rendesen lehetne scrollozni sebesség miatt.
A mobiltelefonos java kb. 20-szor olyan gyorsan scrolloz, mint a mezei PC-s referencia implementáció, pusztán azért, natív és kemény hardver gyorsítással megy.
Aki foglalkozott már 2D grafikával tudja, hogy mindenegyes ciklus fontos. Egyáltalán nem mindegy az a 60% sebességkülönbség. Egy 1000*1000 pontos felületen 1 Millió pontot kell újra rajzolni szükség esetén.
Jelentheti azt is, hogy a programod 1 GHz-en már nem fut el, csak 2 GHz-en. A jelenlegi gépek felét ugye kizártad.