[marczi]

Idézet: h1ghland3r - Dátum: 2005. szept. 2., péntek - 10:20

Majd lejatszak a C#/.NET-tel, hogy ki marad eletben.

Bevallom oszinten (lesutott szemmel), nekem a Redmondiak megoldasa szimpatikusabb. Persze nekik konnyu, ok mar lattak, hogy mi a szopas a Javaban.

Nekem is szimpatikusabb, illetve jobban átgondolt rendszer. Az a bibi vele, hogy vajon a Microsoft (ha épp a helyzete úgy kívánja), nem fogja-e a GnuNET-et meg a Mono-t teljesen kicsinálni. A Java fejlesztése is azért többé-kevésbé nyílt, meg a Sunról eddig nem volt jellemzõ, hogy túlságosan visszaélt volna a szabadalmaival.

Szerkesztette: marczi 2005. 09. 02. 14:32 -kor

[Haderach]

Idézet: marczi - Dátum: 2005. szept. 2., péntek - 15:22

Nekem is szimpatikusabb, illetve jobban átgondolt rendszer. Az a bibi vele, hogy vajon a Microsoft (ha épp a helyzete úgy kívánja), nem fogja-e a GnuNET-et meg a Mono-t teljesen kicsinálni. A Java fejlesztése is azért többé-kevésbé nyílt, meg a Sunról eddig nem volt jellemzõ, hogy túlságosan visszaélt volna a szabadalmaival.

maga a c# meg a .NET CIL nyilt szabvany, azt barki barmire hasznalhatja. a problema a .NET class libraryval lehet, ugyanis ennek nagyresze nem resze a szabvanynak (bar talan az alap dolgok, mint pl tarolok, stb. nyiltak) de meg lehet figyelni, hogy a mono elegge jol hasznalhato a kiegeszito libekkel is (pl gtk#, qt#, firefox api stb.)
a sun meg szerintem csak azert nem all neki a blackdownnak, koffe-nak es tarsainak mert kb kicsinalna magat ha maga ellen hangolna a nyilt-kodu projekteken dolgozo fejlesztoket. mellesleg a java nyelv nincs szabvanyositva, es a class library es a java VM byte kodja sem, a sun kemeny licenszdijat ker a hasznalataert(az IBMtol, apple-tol pl.) raadasul kenye kedve szerint modosithatja akarki mas megkerdezese nelkul, szoval itt a c# es a .NET CIL joval nyiltabb.
es a c# valoban kenyelmesebb mint a java szvsz, a pici & puha megcsinalta megint azt, amit mar mas is megcsinalt es bejaratott, es megint jobbra csinalta, mint az eredeti

[bocsika]

szokták mondani: "ha látsz egy kis programot, ami iszonyat sok memóriát zabál, és iszonyat lassan reagál, akkor azt biztosan java-ban írták"

uraim, ez a való élet. elméletileg magyarázhatja nekem bárki, hogy milyen szép a java, amíg töredék erõforrást igényel egy c++ kód futtatása, és kb ugyanannyit a megírása.

nem kell attól félnem, hogy "úristen, mikor derül ki, hogy mégsem szabadott volna ezt java-ban megírni" - mint ahogy ez c++-ban még soha nem derült ki. A c++ defaultból jó teljesítményt ad, optimalizálva pedig nagyon jót.

Amúgy ha c++
- Garbage collection kell? boost SmartPointer
- Gui kell? van többfajta, én a Borland C++ Builder-ét favorizálom, mert 1 perc alatt összedobható vele szép felület
stb stb

Szóval aki nagy projektekben dolgozik, ahol a teljesítmény is számít, ott c++ a javaslatom, a szívások elkerülése végett.
Ahol a portabilitás az elsõdleges, ott mehet a java, de esetleg zsákutca lesz a vége.

[Haderach]

Idézet: bocsika - Dátum: 2005. szept. 13., kedd - 10:29

Amúgy ha c++
(*)- Garbage collection kell? boost SmartPointer
(**)- Gui kell? van többfajta, én a Borland C++ Builder-ét favorizálom, mert 1 perc alatt összedobható vele szép felület
stb stb

* a smart pointer nem igazi GC, ha mondjuk peldaul smartpointeres ojjektumot hozol letre fv parameterekent, es a kerdeses ojjekt konstruktora kivetelt dob, akkor mar elvesztetted a kerdeses objektumot, semmit nem tehetsz erte. de van meg tobb eset is amikor smartpointerrel szep mem.leak johet letre, szoval GC helyettesitesere nem teljesen alkalmas(persze hasznos dolog mert gyorsabb mint egy valodi GC)

** a borland c++ builder nem ingyenes, raadasul a VCL es az erre epulo eszkozok fejlesztese leallt, borland is .NETet meg javat nyom helyettuk (persze attol meg nem rossz a VCL de a win.forms azert sokkal jobb )

[pauz]

hali

nekem az lenne a gondom, hogy november vegere, kell csinalnom egy kis pascal feladatot:) de nagyon homaly, alapszinten ha megy.
egy adatfile kezeles lenne. egy file-al, pl ami notebook markakat tarol.
meg kell hozza menu, hogy lehessen a file-ba hozzadadni, keresni, torolni, kilepni ilyesmik.........

erre hol talalnak leirast magyarul a neten?

a masik tenyezo, hogy linux alatt kell futtatnom:)

varom a valaszokat, thx

[j.cs.]

pauz, maximális jóindulattal mondom:

Ha ez nem megy egyedül, inkább keress egy másik szakmát. Még nem késõ.

Szerkesztette: j.cs. 2005. 09. 20. 12:49 -kor

[pauz]

Idézet: j.cs. - Dátum: 2005. szept. 20., kedd - 13:49

pauz, maximális jóindulattal mondom:

Ha ez nem megy egyedül, inkább keress egy másik szakmát. Még nem késõ.

muszaki info szakon vagyok, nem programozoin

most lesz pascal, es mondtak mi a feleves es vmi "barati" hozzaszolast vartam, talalok e neten vmi segedanyagot magyarul

vagy vegyek egy pascal konyvet? abban tuti benne van?

[j.cs.]

Idézet: pauz - Dátum: 2005. szept. 20., kedd - 13:51

muszaki info szakon vagyok, nem programozoin

Gondoltam. Igen, vegyél. Vagy Google és olvass. Gondolom Pascalból valami laborotok csak van: oda bejárni, mintapéldákat megoldani, gyakorolni. Megérteni, feldolgozni, önállósodni.

Mûszaki menedzser szakon esetleg megbocsátható lenne a kérdésed. Infón nem nagyon. Ha az IT közgazdasági oldala érdekel, menj inkább közgázra.

Szerkesztette: j.cs. 2005. 09. 20. 16:03 -kor

[Hasse]

Mondjuk ezt rágcsálgasd, ha érdekel a dolog, elõre-hárta is lehet menni a cikkek között, ha túl bonyolult. Linux alá mondjuk Free Pascal nevû cucc van pl.
http://www.prog.hu/c...ajlkezeles.html

[h1ghland3r]

Idézet: bocsika - Dátum: 2005. szept. 13., kedd - 8:29

szokták mondani: "ha látsz egy kis programot, ami iszonyat sok memóriát zabál, és iszonyat lassan reagál, akkor azt biztosan java-ban írták"

uraim, ez a való élet. elméletileg magyarázhatja nekem bárki, hogy milyen szép a java, amíg töredék erõforrást igényel egy c++ kód futtatása, és kb ugyanannyit a megírása.

nem kell attól félnem, hogy "úristen, mikor derül ki, hogy mégsem szabadott volna ezt java-ban megírni" - mint ahogy ez c++-ban még soha nem derült ki. A c++ defaultból jó teljesítményt ad, optimalizálva pedig nagyon jót.

Amúgy ha c++
- Garbage collection kell? boost SmartPointer
- Gui kell? van többfajta, én a Borland C++ Builder-ét favorizálom, mert 1 perc alatt összedobható vele szép felület
stb stb

Szóval aki nagy projektekben dolgozik, ahol a teljesítmény is számít, ott c++ a javaslatom, a szívások elkerülése végett.
Ahol a portabilitás az elsõdleges, ott mehet a java, de esetleg zsákutca lesz a vége.

Az a baj, hogy borzaszto szuklatokoruen nezed a dolgokat.

Idézet

amíg töredék erõforrást igényel egy c++ kód futtatása, és kb ugyanannyit a megírása.

Ketszereset a portolasa, haromszorosat a masik programozonak valo atadasa....

Idézet

"úristen, mikor derül ki, hogy mégsem szabadott volna ezt java-ban megírni"

Szerintem a C++-ban keszulo Wines projektek jo resze mondjuk ugy 70%-a valszeg jobban jart volna, ha NEM C++-ban keszul. Mondjuk nem ajanlanam automatikusan a Java-t erre a celra, az szentigaz. Ugy allitod be a dolgokat, mintha csak ez a ket nyelv lenne a vilagon.

Tudod, mi a baj a smart pointerrel? Az, hogy csak egy hack. Pl. az auto_ptr tudtommal nem hasznalhato egyutt az STL kontenerekkel. A normalis megoldas az lenne, hogy a nyelv szintjen megoldjak a problemat, es utana elfelejtjuk az egeszet. Nem, ez itt a c++, itt tudnod kell, hogy hogyan mukodik belulrol az aktualis pointered, nehogy veletlenul hulyere szivasd magad vele. Bravo, szep OOP megoldas!

A GUI kerdeskorbe nem maszok bele, mert nem igazan ertek hozza, de a win.forms szerintem otszor korbefutja a C++ Builder/VCL parost. A VCL legnagyobb problemaja az, hogy Object Pascalhoz keszult, igy a C++ programozonak ugy kell egyutt elnie az OP korlatozottabb lehetosegeivel, hogy ki sem hasznalhatja a C++ nyujtotta elonyoket.

[Denevér]

Azt hiszem programozok egy ideje, és mindkét nyelv rajongó táborából vannak jó barátaim. Az utobbi idôben mobilokkal foglalkoztam, ami gyakorlatilag mindket nyelvet támogatja, azaz minden programozó egyeni izlése szerint választhat.

Ami engem illet a C++ hive vagyok és a strukturált programozási stílus a kedvencem. Leginkább az objektum orientált esemény vezérelt felépités áll közel hozzám, igaz ez a Javaban is megvan.

A hajam égnek áll amikor látok egy szép egysoros kódot, amit csak a szülôatyja ért. Értékelem ugyan, de a mindennapi munkát meg tudja zavarni. Aki szeret ilyet olvasgatni annak egészségére.  A napokban is találkoztam olyan kóddal amit a Visual Studió régi változata engedékenyen lefordít az új meg elszáll tôle, és vannak még szigorúbb fordítok amik az ujabb C/C++ szabvány alapján fordítanak.

Mint h1ghland3r már irta a hordozhatóság az korlátozott, mert elég sok nyelvjárás akad (C#, egyebek) és természetesen saját könyvtárral minden operációs rendszer alá másképp. Mondjuk ebben a Java is ludas, sorolhatnám a Midp 1.0 illetve 2.0 szabványokat, meg hogy melyik telefon hogy s miként támogatja ôket a funkciók mely részhalmazát... Hogy a többi java "tájszólást" meg ne említsem... ennyit a Java hordozhatóságárol. 

A szemléletes különbség elvi szinten van: A C++, c az elôfordított, mig a Java interpreted. Az elôbbi segit a hardver és az operációs rendszer szolgáltatásainak közvetlen elérésében, mig az utóbbi ezeket elrejti vagy nem is támogatja, mivel ahhoz el kellene hagyni a biztonságos egyen-homokozót.

Nem biztos, hogy sebességben is feltûnik a különbség, mert hiába a Borland C++ eszközzel 4 kattintás egy C++ GUI, a mögötte lévô kód sebességben - mivel az optimalizálási lehetôségek korlatozottak, illetve csökkentik a hordozhatóságot  - nem lesz sokkal gyorsabb mint egy ugyanolyan álltalanos Java kód egy jól beállitott interpreteren. Erôsen attól függ a dolog, hogy milyen vason fog a kód majd muzsikálni.

Amiért én mégis C++ mellett döntök, mert sokkal gépközelibb, azaz jobban kihasználja a hardvert. Nekem több lehetôséget ad alapból, ha az idômet rászánom. Ha van a vasra (procira) C++ forditó, akkor idôvel video(3D), audio, mobil specifikus cuccok egy c,c++-ban irt operációs rendszer alatt eleg jól programozhatók. Mivel a Java álltalános és hardver független szeretne lenni, így késôbb és kevésbe célhardverre szabottak az alkalmazásai magából a hordozhatóság definiciójából következôleg. Minnél jobban célhadver közeli lesz a Java, annál jobban veszti majd a hordozhatoságát és végül ugyanott lesz a két nyelv mint sebességben mind hordozhatóságban.

Ami azért nagyon zavar ha ringyoz alatt, néhányan Javaban fejlesztenek segédprogikat, hogy hordozható legyen a kód, és találkoztam olyan alkotással hogy nem kezelték az egéren középsô tekerentyût, mert az már nem álltalános hardver elem. Az + külön öröm ha két webes alkalmazás is van(csak hogy hordozható legyen a kliens), és mindkettôt használnom kellene, de mindegyik más Java környezetet kiván, esetleg egy kevésbe szeretett böngészôre kell az applet támogatottság miatt váltanom.
Bár az igaz, hogy ringyoz alatt egy trehányul megirt C++ progi (pl. Visual Studio) rántja magával az egész rendszert csapostul, papostul, tálcástul...   mig az applet csak a böngészôt fagyasztja le jobb esetben (elvesztve az összes szöveget amit épp már begépelt az ember...) 

(V)

[j.cs.]

Denever, ezen sokaig gondolkodhattal, de en ugy erzem bizonyos szempontbol (forraskereses, kijelentesek tenyekkel alatamasztasa) keveset. Nehez lenne osszegezni az osszes fontosabb targyi tevedest, mert nagyon szepen egybemosod a Javat mint nyelvet a Javaval mint futtatasi kornyezettel  es a Javaval mint API halmazzal.

Idézet

Ami engem illet a C++ hive vagyok és a strukturált programozási stílus a kedvencem

Ez igy onmagaban egy erdekes kijelentes, de tegyuk tul magunkat rajta. C# nem C++ nyelvjaras, de ezen is tegyuk tul magunkat.

Idézet

Hogy a többi java "tájszólást" meg ne említsem

De, emlitsd, kivancsi lennek mire gondolsz. Van egy nyelv specifikacio, tobbfajta API specifikacio (Mobile, Standard, Enterprise Edition - persze Mobile-on belul a tobbfele Device Profile - bar ahogy fejlodnek a mobil eszkozok imho ezek szep lassan ugy konvergalnak a Standard Edition fele), de nem tudsz nekem olyan .java file-t mutatni, ami IBM-s javac-cal leforditodik, Sun-ossal meg nem. Nincsenek tajszolasok.

Idézet

A C++, c az elôfordított, mig a Java interpreted

A Java byte code (ami ugye nem a Java nyelv maga, hanem egy absztrakt verem alapu feldolgozegyseg nyelve) idonkent interpreted  is lehet - mondjuk egyre ritkabban az. 

Idézet

mig az utóbbi ezeket elrejti vagy nem is támogatja, mivel ahhoz el kellene hagyni a biztonságos egyen-homokozót.

Akkor a JNI szerinted megis mi? Az SWT-t vagy a Java3D lib-eket miert platformspecifikusan kell letolteni?

Idézet

mert az már nem álltalános hardver elem

java.awt.event.MouseWheelEvent, 1.4-es Java ota resze a platformnak.

Hmmm... lattal te mar nem applet Java alkalmazast (Eclipse, NetBeans, Azureus, Project Looking Glass, stb)? Netan hasznaltad mar szerveroldalon (userkent biztosan)? Lehet, hogy jobb lenne a velemenyed...

[SFIJ]

szvsz egy prpgramnyelvnél nem az a legfontosabb, hogy géplözeli legyen, hanem
o) passzoljon a megoldandó feladathoz
o) lehetõleg gyorsan lehessen iterálni a fejlesztési ciklus során
o) jó teljesítményt nyújtson

ezért numerikus problémákhoz még mais frotrant célszerû használni, de webes fejlesztéshez ma énmár se c(++)-t se java derivatívokat nem használnék, hanem python, php és hozzá hasonló célnyelveket.

isten igazából az oops 3G nyelvek leginkább vastag kliensek GUIjaihoz jó, a java-t c-t c#-ot nagyon eröltetik midlleware-nek, bár én a mai tudásommal oda is már egy typeless interpretált 4G nyelvet tennék...

c, c++, c#, java akkor jo, ha valaminek tényleg van egy értelmesen felvehetõ adatmodelje, ha ezt kínunkban kell hegggesztenünk és nem oly trivi, vagy egy mezei relációs adatmodellre rámappelhetõ akkor lehet, hogy nem érdemes a híres oops nyelvekhez hozzányúlni.

[Denevér]

A jó teljesitmeny az tag fogalom. Ha nincs egy rakat pénz például gyors sun-munkaallomasokra, akkor nem árt a jo teljesitmenyhez a gépközeliség... Igaz pont a kedvencem az objektum adatstruktura igyekszik elvonatkoztatni a regiszterektôl és társaitól, szoval elviekben lassít. Bár a fordító azt csinál vele amit akar, a lefordított kodot már nem szoktam böngészni. Az akármilyen is lehet. 

A perl, phyton és az egyéb scripnyelvek valóban web-re nagyon jók, sôt még mobilon is vannak, bár legutobb a beep phytonban irt változatának portolásával szivogattam sokat, tekintve hogy néhány script alól hiányzott a c-"környezet".

Illetve mivel a legtöbb scripnyelv nem kényszerít tipusos gondolkodásra (szemben a programozás témazáróval  ) igen könnyû kezdô programozóként hibás kodot generálni. Volt egy perl script ami hibát dobott egy szerviz csomag hiányára, csak a gond ott volt, hogy a fordító azóta egy generációt lepett, de a script nem fogta, hogy v5+sp5 kisebb mint v6 sp0 és csak szorta hogy a 6os verziohoz pakoljak már fel sp-t. Még jó hogy volt hozzá. 

Igaz bármit könnyû scriptekkel megirni, ha elhiszem amit a nyelvek magukról reklámoznak. Ami engem illet nem csipem, hogy egy script miatt a dos-promtot kell hivogatnom. Nem hiszem hogy jot tesz a stabilitásnak, bár fagyáskor csak a dos prompt száll el, ami azért mégse a teljes gép...

A Fortranról csak hallottam, hálisten a numerikus problémák ezidáig elkerültek. x86-on és Arm-on kivül nem igazán mozgok.

j.cs.,

Valoban ami a Java-t illeti nem az erôs oldalam, sôt. Bár a napokban használtam Eclipse, mert cvs-bôl kellett a neten kodot bányásznom. Hát a cégnél nem sikerült, és nem lettem okosabb miért nem. Söt... Otthon aztán sikerült, így sejtem a tûzfal okozhatott problémát. Ennél az IDenél tapasztaltam a villogó kurzort, ami nem engedett gépelni. 
Elég sok IDE volt már a kezem alatt, de valahogy nem csipem, ha egy file/open ablakban véletlenül átrendezhetem a könyvtárstruktúrát...(kód újrahasznositás rulez
Mivel egy vasgolyot is képes vagyok elrontani, szeretem a letisztult rendszereket, amik csak azt csinalják amit kérek, és ha nem sikerül valami, informálnak mit csinalhatok másképp, vagy elôre megkérdik az összes lényeges dolgot amin a folyamat elcsuszhat.

Nyelvjárást és a nyelvi változatokat valóban összemostam, pl. a object c-t én egyfajta nyelvjárásnak mondanám. Olyan nyelv amit c-tudással meg lehet tanulni és érteni. Hivatalosan mindegyik önálló nyelv gondolom, de ennyi erôvel egy ujabb függvány könyvtár és máris kész egy újabb nyelv. Ha nem lenne közük egymáshoz, gondolom más lenne az elnevezés is...

Valóban az API specifikációkra gondoltam és a profileokra, és arra hogy van olyan java-t támogató eszköz amin fog futni ugyanaz a .java file mig egy masik java kompatibilis eszközön nem. Egy API specifikációt támogató különbözô cég által készített fordítók (Sun, IBM) átjárhatók, viszont a sok API specifikáció miatt elvész az átjárás. "PC-kod" 3Dlib-el már ritkán fut mobilon...

Az lehet hogy a Standard edition fele megy az egész Java, de a mobiloknál mindig kisebb lesz a vas mint a szerverszobában, tehát lesznek API specifikációk.  Az ujabb featurek mindig jönnek, (teszem azt szagos telefon  ) és eltart egy ideig mig a Java szag API elkészül és része lesz a Standard editionak...

Ha felsorolnál pár java byte kódot kezelô vast, akkor bölcsebbé tennél. :confused:

A JNI-vel veszted el a hordozhatóságot szerintem, de ugye azt se minden mobil támogatja, illetve azon keresztül se minden elérhetô. Késôbb még akár lehet is gyakorlati haszna. Az SWT-t meg nem ismerem,  a Java3D lib meg ugye felejthetô ha nem x86-os grafikus kartyád van, hanem teszem azt mobilon akarsz teret generálni. Szoval a támogatottság hiányosságait fenntartom. x86 bár elterjedt, de van rajta kivül is élet...
Azt hiszem az egér probléma épp az 1.3.x alatt ért. Egy ideje már használok Java futtatási környezetet igénylô dolgokat, de nem kizárt hogy eljön az idô amikor megszeretem. Csak még nincs itt 

Szerkesztette: Denevér 2005. 09. 21. 09:31 -kor

[h1ghland3r]

Idézet: SFIJ - Dátum: 2005. szept. 20., kedd - 22:20

szvsz egy prpgramnyelvnél nem az a legfontosabb, hogy géplözeli legyen, hanem
o) passzoljon a megoldandó feladathoz
o) lehetõleg gyorsan lehessen iterálni a fejlesztési ciklus során
o) jó teljesítményt nyújtson

ezért numerikus problémákhoz még mais frotrant célszerû használni, de webes fejlesztéshez ma énmár se c(++)-t se java derivatívokat nem használnék, hanem python, php és hozzá hasonló célnyelveket.

isten igazából az oops 3G nyelvek leginkább vastag kliensek GUIjaihoz jó, a java-t c-t c#-ot nagyon eröltetik midlleware-nek, bár én a mai tudásommal oda is már egy typeless interpretált 4G nyelvet tennék...

c, c++, c#, java akkor jo, ha valaminek tényleg van egy értelmesen felvehetõ adatmodelje, ha ezt kínunkban kell hegggesztenünk és nem oly trivi, vagy egy mezei relációs adatmodellre rámappelhetõ akkor lehet, hogy nem érdemes a híres oops nyelvekhez hozzányúlni.

Na ezzel teljesen egyetertek.

Mas teszta, hogy sokan ezeket a bolcs alapelveket ugy interpretaljak, hogy mivel a C++-t barmire ra tudjak eroltetni, ezert mindenre az a jo.

[csavar]

Üdv!

Saját tapasztalatom a c++, c# és a javával kapcsolatban:

Mindegyikben jó idõt eltöltöttem. '96 táján ismerkedtem meg a c++ -al. Teljesen lenyûgözött turbo pascal után. Nagyon jó fordítót használtam: Watcom C-t, (ez tudott generálni dos4gw-s progit, még a doom is ebben készült.)
Aztán borland builderrel ismerkedtem és szintén jó volt. Igaz, nagyon könnyû ROSSZ programot készíteni vele ha beledrótozod a progid érdemi részét a grafikus felület be.
De aztán írtam egy többszálas webszervert és vért izzadtam.

Igen, a memória lyukak miatt. Könnyû volt nem felszabadítani valamit: elég ha kódolsz és valakik megzavarnak... Ráadásul egy változót nem nulláztam le, ez plussz egy hét hibakeresést jelentett mivel fagyott a szerver.

Szóval ezek késztettek h áttérjek vagy javára v. c#-ra.

Hosszas tesztelés után az jött ki h jobb, elegánsabb a c#!!
DE!
A javát már régebben kezdte a sun, és ez azt jelenti h TÖBB minden dolgot megvalósított már. Példa: próbálj egy a programod felületén lévõ táblázatot kinyomtatni mind a kettõben. Meglepne ha c#-ban 50-100 sor alatt meglenne.
Javában pedig pár sor (bár itt is kellett görcsölni mire rájöttem a pár sorra)


Ezért választottam egyelõre a javat. Van egy tuti jó ingyenes fejlesztõeszköze (Netbeans), hasonlót tud mint a Builder.
Persze javában is van amitõl feláll a szõr a hátamon.

Rájöttem h nincs tökéletes nyelv, kompromisszumot kell kötni.

Találtam két javában írt játékot: IL-2 repülõgép szimulátort és Chrome nevû fps-t!!!!!!

Ezt szûrtem le magamnak évek alatt, nem szentírás a véleményem...

Üdv!

[Asker]

Megy vki a Java konferenciára?

Szerkesztette: Asker 2005. 09. 21. 18:42 -kor

[Hasse]

Majd a májkrámszoftosra pénteken. Sunnál jó a kaja?

[h1ghland3r]

Idézet: Hasse - Dátum: 2005. szept. 23., péntek - 9:48

Majd a májkrámszoftosra pénteken. Sunnál jó a kaja?

Latjatok feleim van akit csak a repikaja erdekel. A C# vs. Java haboru a konyhaban dol el.     

[bocsika]

"* a smart pointer nem igazi GC, ha mondjuk peldaul smartpointeres ojjektumot hozol letre fv parameterekent, es a kerdeses ojjekt konstruktora kivetelt dob, akkor mar elvesztetted a kerdeses objektumot, semmit nem tehetsz erte. "

ezt isten bizony nem értettem. természetesen a smart pointerek és az exception-ök tökéletesen együtt dolgoznak, semmi leak nincs.

"de van meg tobb eset is amikor smartpointerrel szep mem.leak johet letre"

körbe hivatkozásnál elképzelhetõ. gyakorlati jelentõsége szinte nulla.

"szoval GC helyettesitesere nem teljesen alkalmas(persze hasznos dolog mert gyorsabb mint egy valodi GC)"
jessz! tessék itt egy néhány tucat sorban megírt új SmartPtr osztály c++ hoz, ami jobb megoldást ad, mint az iszonyú teljesítmény zabálós GC rendszerek... na pont ezért szeretem én ezt a c++ nyelvet.

lábon tudod magad lõni vele? persze, hiszen nagyteljesítményû eszköz.
magas szinten tudsz vele dolgozni? ha az kell, igen! lásd a mátrix library-t, ami SSE-re optimalizált kódot ad az
A = B * C;
kódra (A,B,C mind mátrixok)
alacsony szinten, sõt assemblyben tudsz vele dolgozni? ha nagyon kell, igen.

"a borland c++ builder nem ingyenes, raadasul a VCL [...] fejlesztese leallt"
hát ez szimplán nem igaz. VCL folytatva.

"win.forms azert sokkal jobb"
ja. bár nem ingyenes, nincs legális linuxos verziója stb. szóval nem fenékig tejfel.

"Tudod, mi a baj a smart pointerrel? Az, hogy csak egy hack. Pl. az auto_ptr tudtommal nem hasznalhato egyutt az STL kontenerekkel. A normalis megoldas az lenne, hogy a nyelv szintjen megoldjak a problemat, es utana elfelejtjuk az egeszet. Nem, ez itt a c++, itt tudnod kell, hogy hogyan mukodik belulrol az aktualis pointered, nehogy veletlenul hulyere szivasd magad vele. Bravo, szep OOP megoldas!
"
ezt se bírom nagyon fogni. Mire ment a Java azzal. hogy GC-t építettek bele? csak arra való, hogy gyorsan, könnyen a lusta programozónak ne kelljen gondolkoznia rajta, hogy párban legyen a new és a delete.

cserébe iszonyat memóriazabáló lett, nemdeterminisztikus GC indulással, megkérdõjelezhetõ futási teljesítménnyel /akárhány Javas nagy programot próbáltam, mind iszonyú volt pl ibankos rendszerek, openoffice egyes részei, Poseidon UML editor, JBuilder felület stb. katasztrófa./.

amúgy nem auto_ptr -ról beszélünk, az elhibázott dolog, mindenki tudja. A smartpoiter  természetesen bármilyen konténerbe dobálható.

"ez itt a c++, itt tudnod kell, hogy hogyan mukodik belulrol az aktualis pointered, nehogy veletlenul hulyere szivasd magad vele. "

?? használtál már smart pointert? magas szinten tudnod kell, hogyan mûködik - mint minden eszközrõl. Azaz értékadásra share-eli a beledobott objektumot, az utolsó felhasználónál pedig lekapcsolja a villanyt, vagyis eldobja az objektumot.
ezen kívül semmit nem kell tudnod róla.