mefiblog - főoldal

Ez már régi téma. :) Ha jól tudom nem az egész Visual Studiot rakta ingyenesbe, hanem egyenként a részeit.

ha jol latom, ezek csak az „express” valtozatok. mellesleg nekem az egesz Visual Studio-rol a „bloatware” jut eszembe. mi a halalt birtak ezen ennyit programozni? egyszer kellett DirectShow ala fejlesztenem valamit, es 2 Gb-nyi mindenfele szart fel kellett pakolnom azert, hogy vegre nekiallhassak. Linuxban meg fog az ember egy gcc-t, egy vim-et (jo, aki a klikkelgetos IDE-ket szereti: anjuta-t vagy kdevelop-ot), a szukseges library-ket, es csokolom.

Tamás:Szerintem megéri kivárni a telepítés végéig. :)

chateve: Csak az express verziók ingyenesek. Nem régi téma, mert eddig csak átmenetileg volt ingyenes, most viszont úgy döntöttek, hogy ingyenes is marad.

Tamás: KDeveloppal játszadoztam, nekem tetszett. De ugye a vinnyózok kicsit elmaradottabbak, mint a linuxok.

Az ASP.net fejlesztőkörnyezetük egyszerűbb voltozatát is (aminek nemtom a nevét) már ingyen osztogatták a PHP konferencián.

Szerveroldali nyelvekben inkább PHP párti vagyok, ASP szervert elég nehezen találni.

ez igen! mostmár van értelme Micros környezetben fejleszteni. eddig az volt a legnagyobb baj, hogy ha ilyet akartam volna meg kellett volna vennem minden szart a windows mellé.. ami úgy fél millára jött volna ki :D most viszont fasza.. főleg nekem, mert suli xp-jét legálissan használhatom itthon :P
amúgy én is PHP párti vagyok és az ASP eléggé sux szerintem. viszont a Visual Studio C és C++ környezete érdekel, mert ez a két leghatékonyabb progrmnyelv a gépi kódú programok közül jelenleg. sokan a Delphit isteníttik, de ezzel nem értek együtt :D lasabb és nagyobb a kimeneti fájlja ugyanannak a programnak.
na szal most meglepődtem… ezt sosem hittem volna :D

Devilll:
1. a C es C++ nem gepi kodu, max gepi kodra fordit. :) de az hagyjan, a Microsoft-fele C fordito nem arrol hires, hogy a leggyorsabb kodot keszitene, az icl pl siman veri a legtobb helyzetben, de sokszor a MinGW-ben levo gcc is, pedig az nem is nativ Windows platformra fordit, hanem fut alatta egy POSIX emulacios reteg.
2. most sem ingyenes a Visual Studio, csak egy resze, amit Express neven illetnek. nincs benne minden, ami a teljes Visual Studioban benne van.
3. a kimeneti fajl merete nem jelent semmit, attol fugg, mi van statikusan linkelve bele es mi az, amit dinamikusan, DLL-bol tolt be. Delphi asszem defaultbol statikusan linkel, ezert a nagyobb meret.
4. a „leghatekonyabb programnyelv” szerintem leginkabb az, ha tobbet keversz, attol fuggoen, hogy mire van szukseged: teljesitmenyre vagy atlathato forraskodra. en pl azt preferalom, hogy Python-ban irom meg a programot, es a sebessegigenyes reszeket atultetem C-be, amit utana Python beepulo modulkent hasznalok. a C lehet, hogy marha gyors, de ha neked kell pocsolnod az osszes memoriakezelesi hulyeseggel, memory leak-ekkel, buffer tulirassal, a hajadat kiteped, mire megirsz egy rendes programot.

1. a C és C++ van az Assembly után a legközelebb a gépi kódhoz és majdnem ugyanarra fordít. nagyon közeli állapotú az exe, így géi kódnak nevezhető
2. nem ingyenes minden része persze :) de nekem nem is kell minden. elég a fordíttó :P
3. a kimeneti fájl mérete igenis jelent valamit. mivel nem mind1, hogy pl egy komplett 3D alkalmazás mérete 100 mega vagy 200… nem mind1 mennyi idő alatt rántod be a memóriába, stb.. :) gondolkodj komoly programokban. másrészről ha kevesebb fölösleges információ van az EXE-ben, akkor kisebb a méret és már ez is sokszor segít abbam, hogy ráférhessél egy cd-re, stb… és ugyanígy a DLL mérete is csökkenthető
4. leghatákonyebb programnyelv valóban a kevert. de most egyesével nézd, mert én is úgy mondtam
5. ha elég gyakorlott vagy nem kell pöcsölni a memóriakezeléssel, mert meg tod írni a prgrammal együtt kisujjból. nem mondom, hogy mindent tudok, de szerencsére a memóriakezelés már nem jelent egy ideje gondot.
6. sose oktass ki egy programozót, mert lehet, hogy többet tud nálad sok szempontból a gyakorlata miatt. én még CSAK 12-13 éve programozok. asszem ez elég tapasztalat ahhoz, hogy a véleményem elmondjam.

Nehogy nekem összevesszetek itt. :)

nem szándékozom :) csak próbálom kijavítgatni, mert részben nekem van igazam és részben neki :D szal most szépen javítgatjuk egymást amíg nem értünk egyet :P

5. C-ben szerintem akkor is kell csillagot vadászni, ha vérprofi vagy benne. Javában meg csomagolni. :)

Devilll:
2. maga a Microsoft Visual C fordito meg az alap library-k eddig is ingyenesen letolthetoek voltak. van vagy kb 15 Mb maximum, ehhez nem kell a Visual Studio halistennek. asszem a Platform SDK-hoz is hozza lehetett ferni, bar erre mar nem mernek megeskudni. epp ezert nem ertem, hogy ha maga a C fordito 15 mega, akkor a maradekon mit programoztak ennyit :)
3. persze hogy jelent, ugy ertem, hogy nem jelent semmit, hogy valoszinuleg a Delphit is ra lehet beszelni a dinamikus linkelesre, csak akkor lehet, hogy egy-ket DLL megletetol fuggeni fog a Delphiben irott programod. de a Visual Studio-ban irt alkalmazasoknal is eppugy megvannak ezek a DLL-fuggosegek.
kozben utananeztem: a Delphi alapertelmezesben statikusan linkeli az .EXE-be a Visual Component Library-t, hogy ne kelljen a hozza tartozo DLL-eket a programoddal cipelni. hasonlits ossze egy VCL nelkuli delphis programot egy Visual C-ssel, szerintem nem lesz ekkora kulonbseg.
5. nincs az a programozo, akinek ne lenne tele memory leak-ekkel a C-ben vagy C++-ban irt programja, hacsak kulon nem szorakozik orakat azzal, hogy valgrind-del (vagy valami hasonlo eszkozzel, nem tudom, Windows alatt hogy hivjak) megkeresse oket. a memoriakezeles elveit nyilvan hamar meg lehet tanulni, es azt is elhiszem, hogy bizonyos gyakorlottsag utan az ember almabol felebresztve felrantja a red-black tree kezeleset menedzselo kodot kisujjbol, de nekem ne mondja azt senki, hogy soha nem felejt el felszabaditani egy-egy memoriateruletet vagy nem boklaszik felre egy-egy pointere ugy, hogy nem veszi eszre. es rohadtul ruhellem, amikor C-ben ilyen hibak okat vadaszom negy oran keresztul. (ennek ellenere nyilvan ha sebessegkritikus alkalmazast irok, akkor csakis C, semmi mas)
6. ha ez szamit, kb 15 eve programozok (sajnos), negy evig tartottam laborokat a BME-n C-bol, szoval en sem ma kezdtem. de nem hiszem, hogy szamitana. :)

2. hmm.. jó tudni. én úgy tudtam a fordítója fizetős volt.
3. persze. megvannak a DLL függőségek. de a Visual Studio előnye, hogy megnézhetem, hogy mitől függök egy listában. ráadásul ha akarom ezeket bebetonozhatom az EXE-be ha jól tudom. Delphinél nincs ennyire leegyszerűsítve. ott nekem kell egyesével megkeresni a függőségeket, vagy install shild-et csinálni, ami nem mindíg állapítja ezeket meg jól.
jó, hogy utánna néztél. a VCL-t tényleg linkeli, ha nem kapcsolod ki. DE van egy kis baj. ha te mást használsz.. olyat ami nincs a Delphiben alapból, akkor megszívod, mert nem fogja belinkelni. hanem majd a másik gépen futtatás közben ugrál, hogy még ez sincs + az sincs :)
5. tényleg nehéz megcsinálni, hogy minél kevesebb memóriát zabálj fel. de meg lehet. én például ennek érdekében amit csak lehet dinamikussan foglaltatok le. persze így is marad valamennyi leak. de minimálisra csökkenthető, ami a mostani memóriaméretek mellett úgy vélem elhanyagolható. Szóval ha 1 megát elpazarlok leak-re (mert nem figyelek) az 512-ből akkor mi van? mondjuk ez elég durva már :D de még az sem világ vége… nem is mondtam, hogy nem felejtem el néha… előfordul. de ezek általában előbb-utóbb kiderülnek. és inkább előbb, mert aprogramokat általában azért írom, hogy nyúzzam.
6. szerintem sokat számít a gyakorlat. de én meg azt útálom de rohadtul, ha hülyének néznek. általában nem szólok hozzá olyan témához, amihez nem értek (sok emberrel ellentétben)

2. ket eve mar ingyen volt, lehet, hogy ez nem volt mindig igy, nem tudom, Windows platform alatt eleg regota nem fejlesztek komolyan, max neha szorakozasbol.
3. fogsz egy Dependency Walker-t, raengeded a delphis .exe-dre, es megmondja, milyen DLL-ektol fugg. http://www.dependencywalker.com/-rol letoltheto, ingyenes, nekem meg nem volt olyan, hogy kihagyott volna valamit (bar nyilvan azt mondjuk nem fedezi fel, ha a felhasznalotol keri be a DLL nevet :). az mas kerdes, hogy egy ehhez hasonlo eszkozt miert nem birtak belerakni a Delphi fejlesztokornyezetebe, de ez mar legyen a Borland problemaja. legalabb kisebb lett :) (bar asszem a Delphi 5 is egy CD-n terpeszkedett mar a regi szep idokben, abba is hagytam a vele valo foglalkozast, mert a gepeim mindig szarabbak voltak, mint ami ezeknek kellett volna)
5. leak eseten arra gondolok, hogy lefoglalsz valamit malloc-kal, aztan elfelejted free-zni. az ilyennek az eselyet tipikusan csak noveli, ha dinamikusan foglalgatsz dolgokat. es kelloen komplex program eseten utolag marha nehez debuggolni, hogy akkor pontosan hol is van az a free nelkuli malloc a 35000 sornyi programkododban. a helyzetet csak bonyolitja, ha optimalizalni probalsz es reference counting-ot csinalsz meg copy-on-write-tal trukkozol.
a kerdesedre pedig valaszolva: tfh irsz valami szerverfolyamatot, es mondjuk 1 ora futas alatt leakel 1 megat. az napi 24 mega, es kb 21 nap alatt szepen felzabalja az egesz memoriat, aztan lehet utana szepen naplozni a malloc-free parokat fajlba (LD_PRELOAD-dal ganyolva), hivasi pontokkal egyutt, es silabizalgatni, hogy melyiknek nincs meg a parja. (jo, erre van a valgrind, de annak se sokkal szebb a kimenete). egyebkent igazabol most mar nem vagom, hogy ebben a pontban mi a vita targya :) a memory leak rossz, ezt nem vitatjuk. C-vel tobbet kell szivni, hogy elkeruld, de neha megeri, gondolom ezt sem. egy one-shot kis programocskanal, ami lefut fel perc alatt, es rajtam kivul ugyse hasznalja senki, nyilvan a kutyat sem erdekel a memory leak. de ha mondjuk egy library-t irok, amirol nem tudom, hogy hol, hanyan, milyen kornyezetben fogjak majd hasznalni, kutya kotelessegem megkeresni az utolso kis memoriaszivargast is, mielott release-t csinalnek belole.
6. amennyiben ram celoztal: nem, nem neztelek hulyenek.

remelem lassan kezdunk konszenzusra jutni :)

2. 4-5 éve néztem utoljára. akkor még fizetős volt. azóta c-t és c++-t csak gcc-vel és devcpp-vel fordítottam szinte… bár devcpp eléggé kiszámíthatatlan, szóval szívessen lecserélem :D
3. ha megvennék egy majdnem félmilliós szoftvert (például Delphi) akkor had várjam már el, hogy egy ilyen egyszerű apróság benne legyen. félmillióért igazán adhatnánk egy teljes értékű programot. ne nekem kelljen már összevadászni a netről a kiegészíttőket. de amúgy tegyük fel a poén kedvéért, hogy egy szoftvert veszünk. Delphi és Visual Studio legyen a választék mondjuk. Visual Studioban sok olyan apróság van ami megkönnyíti a programozó dolgát. és árban nem sokban különböznek. tehát valószínűleg a Visual Studio-t venném meg. De ugye ez nem fog megtörténni amíg van használható és ingyenes compiler…
5. ebben semmi vita nem volt. csak megállapítottam, hogy nem az 1 megás free néküli mallocba hal meg a felhasználó gépe. az általános felhasználók közül viszonylag kevesen hagyják a gépük folyamatossan bekapcsolva. amúgy úgy programozok, hogy megírom a malloc-ot, aztán a free-t és csak utánna a kettő közti tölteléket :) tehát nagy valószínűséggel meg lesz a free a mallochoz… de ez részletkérdés :D ez olyan, mint a kapcsos zárójelek írása.. azt is párban írom rögtön, mert néha rohadt nehéz megtalálni, hogy hol hagytam le egyet.
amúgy szerveralkalmazásokat nagyon ritkán kell írnom. legtöbbször, csak felhasználói progik és/vagy webes felületek :)
6. rád gondoltam, mivel úgy éreztem, hogy hülyének nézel.. teljessen olyan érzésem volt.

jah. szép lassan :D úgylátom te is meg tudsz magyarázni ;)

2. izé, ez tényleg csak érdeklődés: hogyhogy kiszámíthatatlan? nem gcc van alatta?
3. na ez az, ezért nem veszek én sem zárt forráskódú szoftvert :) a Visual Studio viszont személy szerint az én életemet nem könnyítette meg, pont azért, mert fel kellett pakolnom 2 Gbyte-ot, hogy egyáltalán nekiállhassak valaminek, utána meg nézhettem a Nagy Homokórát, mert tetű lassú volt. (jó, mint mondtam, a gépem nem egy atomerőmű, de ugyanezen a dev-cpp vígan eléldegél, a vim-ről meg már ne is beszéljünk)
5. próbálom megvédeni az álláspontomat, miért utálok C-ben kódolni, minden előnye ellenére :) a malloc-free vagy new-delete párok számolása ugyanis nem olyan egyszerű, mint a kapcsos zárójelek esete. banális példa:

char *s1 = new char[20];
char *s2 = new char[20];
[…mindenféle egyéb kód…]
s2 = s1;
[…mindenféle egyéb kód…]
delete(s1);
delete(s2);

itt ugye megvan minden new-delete pár, mégis van leak, mert elvesztettünk egy pointert. vagy más: van egy függvényed, ami allokál memóriát egy pointerbe egy malloc-kal, és ezt a pointert visszaadja. utána már neked kell gondoskodnod arról, hogy _minden_ helyen, ahol meghívod a függvényt, el ne felejtsd utána a visszatérési értékét free-zni, ha már nincs rá szükség. és ekkor ugye még csak nem is fog megegyezni a programodban a malloc-ok száma a free-kkel.

2. devcpp alatt? de igen. de valamiért befagy folyton fordíttás közben. gyanítom, hogy a linkelésnél elronthatja és ezért kerül végtelen ciklusba. de nem tudom pontossan a hiba okát. egyébként más gépen még nem próbáltam. előfordulhat, hogy nekem van valami olyanom, amivel összeakad. de nekem folyamatossan lefagy.
3. ez igaz. mondjuk az én 1,7GHz-s gépemen már egész jól megy…. és ez sem egy kimondott erőmű :)
5. ez igaz. bár elég szőrszál hasogatás. ynilván értelemszerű és logikus amit mondtál. és ebben totál igazad van, hogy pointert veszthetek. de azok a pointerek amiket elvesztek a memóriában maradnak úgyis. semmi nem dobja őket ki, csak a program leállása és akkor a window beszünteti létezésüket elvileg… :)
na de erre oda kell figyelni ;) amúgy megnyugtatlak. én is jobban szeretem például a PHP-t a C-nél :) de PHP-ben nem lehet mindent. például a mai napig hiányolok egy compilert hozzá. tudom, hogy a PHP-t direkt interpeteresre találták ki :) de annyira faszás lett, hogy szerintem lehetőséget kéne biztosíttani egy compilerre is, ami linuxra vagy windowsra, vagy leginkább mindkettőre fordíttani képes a forrásaim :) pl nekem sok, a szerverem karbantartó programom írtam PHP-ben és nagyon jól és stabilan futnak konzolon…

chateve:te egy köcsög buzi vagy faszopó geci

kiss arpád: köszönjük ezen értelmes hozzászólást.