Alkotója szerint egyre többen térnek vissza a C++ nyelvre
Jelentkezz be a hozzászóláshoz.
#33
A string mint típus tulajdonképp egy változó, az osztály pedig változók és az azokat kezelõ függvények összessége egybezárva. Ebbõl kifolyólag egy változó kevesebb helyet foglal, egyszerûbb kezelni, cserébe mindenki láthatja az adott érvényességi helyen belül. Persze lehet úgy is felfogni hogy minek ide optimalizáció, vegyünk a gépbe mégtöbb ramot, vinyót, de azért egy magas(abb) szintû nyelvben se kell feleslegesen pazarolni az erõforrást, még akkor se ha alapból nem olyan hatékony mint az asm.
A legfontosabb azonban a string elérése. Char[] esetén csak pointerrel címezheted (indirekt), változó és class esetén érték szerint is adhatsz át. A pointeres címzés amellett hogy hozzáértõ kezekben nagyon hasznos lehet, kevésbé hozzáértõknél a leggyakoribb hibaforrás. Arról nem is beszélve hogy string típus hiányában egyik függvény AnsiStringet ad vissza, a másik másmilyen strin osztályt vár bemenetként, aztán konvertálhatsz oda-vissza, ami szintén hibaforrás, és a futást lassító tényezõ.
Nem véletlen hogy a Java után a C#-ba is bejött a string típus (pascalban már volt alapból).
A legfontosabb azonban a string elérése. Char[] esetén csak pointerrel címezheted (indirekt), változó és class esetén érték szerint is adhatsz át. A pointeres címzés amellett hogy hozzáértõ kezekben nagyon hasznos lehet, kevésbé hozzáértõknél a leggyakoribb hibaforrás. Arról nem is beszélve hogy string típus hiányában egyik függvény AnsiStringet ad vissza, a másik másmilyen strin osztályt vár bemenetként, aztán konvertálhatsz oda-vissza, ami szintén hibaforrás, és a futást lassító tényezõ.
Nem véletlen hogy a Java után a C#-ba is bejött a string típus (pascalban már volt alapból).
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#32
Mennyiben rosszabb egy string osztály egy beépített típusnál ?
#31
Akkor hogy felfogd: string típus N-I-N-C-S C++-ban. Van AnsiString O-S-Z-T-Á-L-Y, meg K-A-R-A-K-T-E-R-T-Ö-M-B típus. Ez egyik se string T-Í-P-U-S, csak annak valamiféle pótléka. Mert pótolni azért lehet. De a hengerfejbõl se ugyanaz a gyári Honda, mint a vietnami utángyártott... Ezek a tények, amit rajtad kívül mindenki tud. A szánalmas bizonyítványmagyarázásod meg nem érdekel, vegyél inkább a kezedbe egy C++-os könyvet, sosem késõ tanulni!
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#30
Nezd baratom amit csinalsz az semmi mas mint szorszalhasogatas - raadasul teljesen ertelmetlen modon.
Azt irtad, hogy kihagytak a C++-bol a string tipust, melyre a valaszom az volt hogy a string osztaly a C++ standard resze. Ezek utan te elkezdtel valamit kavarni, amelynek a vilagon semmi ertelme.
A C++ -ban a felhasznaloi tipusok (leirom meg1x, hogy felfogd: tipusok) megadasara hasznalhato egyik eszkoz a class, azaz osztaly. Minekutan a string C++ template osztaly (char mint aktualis parameter) a C++ standard konyvtar resze innentol kezdve a C++ reszet kepezi a string tipus, megha az template osztaly segitsegevel is van megvalositva.
A C++ rendelkezik ugynevezett beepitett tipusokkal is, ezek a int, char stb., de ismet hangsulyozom, ezek beepitett tipusok, es ugyanugy a C++ reszei mint a string felhasznaloi tipus, de ha mar szorszalat hasogatunk, te tipusrol beszeltel, nem beepitett tipusrol (remelem most erre elmentel vagy 3x, hogy a reszletek mocskos getvajaba tocsogunk).
Hatalmas tevedesbe vagy ugyanakkor, ha azt gondolod, hogy a nyelv nem mas mint a szintaktikus, szemantikus szabalyok, tovabba a beepitett tipusok, vezerlesi szerkezetek stb. osszessege, ugyanis a kore epitett standard konyvtarak ugyanugy a nyelv reszet kepezik altalaban, igy a C++ eseteben is. (Remelem megvolt a 4. is)
Ha ezzel ugy gondolod, hogy vitatkozni szeretnel, akkor javaslom, hogy valamely BTK-s ismerossel tedd, mert filozofiai kerdesek megvitatasara nem ez a megfelelo kozosseg es forum sem.
Namost innentol kezdve gondold at, hogy valojaban mit is szerettel volna irni mert latom felremagyarazni dolgokat, feleslegesen kioktatni emberekt azt kivalloan tudsz... csak ertelmet nem latom.
Azt irtad, hogy kihagytak a C++-bol a string tipust, melyre a valaszom az volt hogy a string osztaly a C++ standard resze. Ezek utan te elkezdtel valamit kavarni, amelynek a vilagon semmi ertelme.
A C++ -ban a felhasznaloi tipusok (leirom meg1x, hogy felfogd: tipusok) megadasara hasznalhato egyik eszkoz a class, azaz osztaly. Minekutan a string C++ template osztaly (char mint aktualis parameter) a C++ standard konyvtar resze innentol kezdve a C++ reszet kepezi a string tipus, megha az template osztaly segitsegevel is van megvalositva.
A C++ rendelkezik ugynevezett beepitett tipusokkal is, ezek a int, char stb., de ismet hangsulyozom, ezek beepitett tipusok, es ugyanugy a C++ reszei mint a string felhasznaloi tipus, de ha mar szorszalat hasogatunk, te tipusrol beszeltel, nem beepitett tipusrol (remelem most erre elmentel vagy 3x, hogy a reszletek mocskos getvajaba tocsogunk).
Hatalmas tevedesbe vagy ugyanakkor, ha azt gondolod, hogy a nyelv nem mas mint a szintaktikus, szemantikus szabalyok, tovabba a beepitett tipusok, vezerlesi szerkezetek stb. osszessege, ugyanis a kore epitett standard konyvtarak ugyanugy a nyelv reszet kepezik altalaban, igy a C++ eseteben is. (Remelem megvolt a 4. is)
Ha ezzel ugy gondolod, hogy vitatkozni szeretnel, akkor javaslom, hogy valamely BTK-s ismerossel tedd, mert filozofiai kerdesek megvitatasara nem ez a megfelelo kozosseg es forum sem.
Namost innentol kezdve gondold at, hogy valojaban mit is szerettel volna irni mert latom felremagyarazni dolgokat, feleslegesen kioktatni emberekt azt kivalloan tudsz... csak ertelmet nem latom.
caddie
#29
Amíg egy keygent vagy 64k demot kell lekódolni, addig lehet asm-ban is wizardkodni, de ha vmi nagy progit kell alkotni, fõleg határidõre, akkor senki nem fogja megvárni amíg elszöszmötölsz API hívásokkal. Akkor már ketyeg a kötbér, ami a te bõrödre megy...
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#28
Vagy ezt:
Standard C++ Library Reference
string
A type that describes a specialization of the template class basic_string with elements of type char as a string.
typedef basic_string<char> string;
A másik linkeden is egybõl kiszúrja az ember szemét: String constructors Típusnak ugyebár nem nagyon van konstruktora. Kösz a linkeket, jól alátámasztottad amit mondtam. 😄
Standard C++ Library Reference
string
A type that describes a specialization of the template class basic_string with elements of type char as a string.
typedef basic_string<char> string;
A másik linkeden is egybõl kiszúrja az ember szemét: String constructors Típusnak ugyebár nem nagyon van konstruktora. Kösz a linkeket, jól alátámasztottad amit mondtam. 😄
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#27
Ugye el is olvastad mi van az MSDN-es linkeden? Idézem:
The C++ language supports two types of strings:
Null-terminated character arrays often referred to as C strings.
Template class objects, of type basic_string, that handle all char-like template arguments.
Ugye nem kell lefordítanom?
The C++ language supports two types of strings:
Null-terminated character arrays often referred to as C strings.
Template class objects, of type basic_string, that handle all char-like template arguments.
Ugye nem kell lefordítanom?
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#26
Igen, de hol van az leírva hogy ezt kötelezõ szeretni? Fenntartom magamnak a jogot hogy utálljam. <#vigyor2>
#25
"Köszönhetõ ez talán annak hogy próbáltam megismerkedni a Visual C++ -al, na számomra az minden de nem segítség 😊"
Már ne is haragudj, de ez inkább téged jellemez, mint a szerkesztõt... :-P
Már ne is haragudj, de ez inkább téged jellemez, mint a szerkesztõt... :-P
#24
A nap legjobb mondása:
"Szerintem akármennyi nyelv van mind jó valamire"
Igen ez így van szerintem is, különben nem lenne, ha nem lenne jó valamire.<#hehe>
"Szerintem akármennyi nyelv van mind jó valamire"
Igen ez így van szerintem is, különben nem lenne, ha nem lenne jó valamire.<#hehe>
#23
""sok esetben a sebesség miatt a C/C++ jóval kifizetõdõbb, mind a program futási mind a fejlesztési idejét tekintve."
Ezzel a kijelentéssel vitába szállnék. Olyan területeken, ahol a futási sebesség nem fontos szempont, jóval rövidebb fejlesztési idõket lehet elérni az új programozási nyelvek (C#, Java) segítségével."
Hát ha valami kód generátort használsz talán, de az nem fejlesztés. Elõfordult már nem egyszer, hogy jóval hamarabb sikerült kivitelezni egy programot egy nyelven, míg JAVA -ban még javában folyt a fejlesztés. Mindennek tetejében a Forráskód is kisebb lett, a futási sebességet nem firtattam soha, és elmentem 2 nap szabira kihasználván az elõnyömet. Ez nem hiszem, hogy annak tudható be, hogy baromi jó lennék, mert a JAVA fejlesztõk is kitettek magukért (Mellesleg ha már az ember újjaiban bene vagy egy pár év fejlesztés akkor oly mindegy a nyelv), hanem egyszerûen a nyelvi sajátosságoknak köszönhetõek a különbségek. Ráadásul én régimódiember vagyok, nem szeretem a 24 ablakos csili vili Buildereket, amik majd jól megmondják nekem hogy én mit is akarok, hanem elõrántok egy klsz kis editort és abban írogatom a kódot. Köszönhetõ ez talán annak hogy próbáltam megismerkedni a Visual C++ -al, na számomra az minden de nem segítség 😊
Ezzel a kijelentéssel vitába szállnék. Olyan területeken, ahol a futási sebesség nem fontos szempont, jóval rövidebb fejlesztési idõket lehet elérni az új programozási nyelvek (C#, Java) segítségével."
Hát ha valami kód generátort használsz talán, de az nem fejlesztés. Elõfordult már nem egyszer, hogy jóval hamarabb sikerült kivitelezni egy programot egy nyelven, míg JAVA -ban még javában folyt a fejlesztés. Mindennek tetejében a Forráskód is kisebb lett, a futási sebességet nem firtattam soha, és elmentem 2 nap szabira kihasználván az elõnyömet. Ez nem hiszem, hogy annak tudható be, hogy baromi jó lennék, mert a JAVA fejlesztõk is kitettek magukért (Mellesleg ha már az ember újjaiban bene vagy egy pár év fejlesztés akkor oly mindegy a nyelv), hanem egyszerûen a nyelvi sajátosságoknak köszönhetõek a különbségek. Ráadásul én régimódiember vagyok, nem szeretem a 24 ablakos csili vili Buildereket, amik majd jól megmondják nekem hogy én mit is akarok, hanem elõrántok egy klsz kis editort és abban írogatom a kódot. Köszönhetõ ez talán annak hogy próbáltam megismerkedni a Visual C++ -al, na számomra az minden de nem segítség 😊
#22
Sztem te siman C-rol beszelsz, nem Cpp-rol... a ketto meg eleg messze van egymastol.
caddie
#21
A mezei string egy valtozo meg class/?? Te valamit most bekavartal nagyon.
<#nezze>std::string, MSDN std::string
<#nezze>std::string, MSDN std::string
caddie
#20
Az AnsiString egy class, a mezei string meg egy változó, nem ugyanaz. String helyett van char*, vagy char[], meg jó nagy kavarodás hogy ki milyen típust ad vissza, és milyet vár bemenetként.
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#19
Tesóm megszállott Java-s, én meg C++ -os vagyok, és azon gondolkodik hogy tudnánk egy közös programot készíteni <#vigyor2>
És össze tudja hozni, hogy ha csinálok egy 'shared library'-t C++ -ban, használja Java-ban.
Szerintem akármennyi nyelv van mind jó valamire, a határaik meg lassan el lesznek mosva, mert van aki ezt ismeri, van aki meg azt...
És össze tudja hozni, hogy ha csinálok egy 'shared library'-t C++ -ban, használja Java-ban.
Szerintem akármennyi nyelv van mind jó valamire, a határaik meg lassan el lesznek mosva, mert van aki ezt ismeri, van aki meg azt...
#18
A pointereket imho max a kezdok utaljak mert nem ismerik... ennek kikerulesere a C++ nyelv amugy a referenciakat biztositja.
C++ reszet kepezi a string osztaly.
Java-rol ket dolgot, egyreszt a Java nem platform fuggetlen, hanem a Java maga egy platform. Masreszt a platformfuggetlenseg inkabb elmeleti, mint gyakorlati.
Harmadreszt pedig C++ is lehet bizonyos szinten platformfuggetlenul kodolni (kod szintu platform fuggetlensegrol van szo).
C++ reszet kepezi a string osztaly.
Java-rol ket dolgot, egyreszt a Java nem platform fuggetlen, hanem a Java maga egy platform. Masreszt a platformfuggetlenseg inkabb elmeleti, mint gyakorlati.
Harmadreszt pedig C++ is lehet bizonyos szinten platformfuggetlenul kodolni (kod szintu platform fuggetlensegrol van szo).
caddie
#17
Haxor: Korábban már (egy másik cikk hozzászólásában) felvetettük a C (és kisebb mértékben a C/UNIX) halhatatlanságának okát: a szakmai tudást. Ugyanez áll a C++ -re is: aki nem tud alap-algoritmust kódolni, azokban gondolkodni - nos az nem programozó.
Szeretem a ráncaimat, mert azt mutatják hogy éltem. Szeretem a beteg rózsákat, Hervadva ha vágynak, a nőket, A sugaras, a bánatos Ősz-időket
#16
hm, javaban meg referencia van, tulajdonképp ugyanaz mintha pointer lenne, de mivel abban csak referencia van nehezebb hibázni vele.
String osztályt meg lehet csinálni, javaban sincs string mint egyszerü tipus, az is class.
String osztályt meg lehet csinálni, javaban sincs string mint egyszerü tipus, az is class.
#15
Igen, de vannak sebessegkritikus dolgok. Irjal pl. Javaban egy mplayer szeru lejatszot, es szamold, hanyan fognak anyazni. Az mplayer pont a C es ASM miatt olyan amilyen (gyors+ganyolas :-).
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#14
nem lehet gepi godra forditani, max az interpetert belemented es ugy tunik, mint ha az lenne, de attol meg nem az
szerintem a c#é(es egyeb magas szinto programozasi nyelveké) a jovo, sokkal gyorsabban lehet ra fejleszteni, igy olcsobba valik a fejlesztes.
Az meg, hogy kicsit tobbet dolgozik vele a proci(bar ez se mindig igaz) kit erdekel, fejleszteni kell a hardwaret es kesz.
szerintem a c#é(es egyeb magas szinto programozasi nyelveké) a jovo, sokkal gyorsabban lehet ra fejleszteni, igy olcsobba valik a fejlesztes.
Az meg, hogy kicsit tobbet dolgozik vele a proci(bar ez se mindig igaz) kit erdekel, fejleszteni kell a hardwaret es kesz.
#13
A legnagyobb gaz a C/C++-szal az, hogy sokan nem figyelnek programozasnal, es itt-ott marad egy kis felszabaditatlan terulet, vagy lemarad a validaltatas, esetleg becsuszik egy-ket under/overflow hiba, amikre persze neked kene figyelned, de mivel a magasabbszintu nyelveknel ez automatikus, ezert sokan elfelejtik. Foleg akik "fent" kezdtek...
Es trabant, igen, mutato rulez :-)
Es trabant, igen, mutato rulez :-)
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#12
Sztem a C/C++ legnagyobb hibája az hogy kihagyták belõle a string típust, nagyon sok szívás, kényszerkonverzió, és ezekbõl eredõ számtalan és gyakori hibalehetõség adódik belõle.
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#11
Lehet javat és C#-ot is gépi kódra fordítani, ha nagyon akarod megteheted, de ezzel meg pont a hordozhatóságot veszted el, hiszen így már egy adott gépre optimalizálod.
A C/C++ legnagyobb elõnye amit a legtöbben utálnak: a pointerek. Pointer rulez. 😊
A C/C++ legnagyobb elõnye amit a legtöbben utálnak: a pointerek. Pointer rulez. 😊
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#10
Vagy méginkább: számlázó, könyvelõ és egyéb üzleti programok. Itt ugye nem a kliens sebessége a meghatározó, a lényeg úgyis Oracleban vagy MS SQL-ben van, a kezelõfelületet (amit a cégek szeretnek saját magukra szabatni) jóval könnyebb és gyorsabb összedobni C#-ban mint C++-ban. Nem mellékes hogy kevesebb a hibalehetõség C#-ban, ami ismerve hogy a fejlesztés nagy része hibajavítás, nem utolsó szempont. Persze nem szabad messiásnak képzelni, arra való amire kitalálták, de arra nagyon.
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#9
A C# azért jelentõs, mert jön fel mint a talajvíz, stabil a háttere (Mikorszopsz), valamint nem utolsó szempont hogy megalkotásában részt vett a Delphi fõatyaúristene, és a Delphi, meg a Java hibáin okulva alkották meg a C#-ot. A jövõje mindenképp biztos, olyannyira hogy Visual Studio.NET MCSD tanfolyamon már csak Visual Basicet, és C#-ot lehet választani, hiába része a cuccnak a Visual C++.
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#8
A managed kód (Java, C#) ugyan (nagy általánosságban) lassabb mint ugyanaz unmanaged (C, C++, stb.) kódban írva, viszont platformfüggetlen. Ez pedig igen nagy elõny. Valamit valamiért. Gyors nyilván akkor lesz, ha optimalizálod valamire, ugyanakkor másik gépen meg nem fog mûködni. Mikor melyik a cél, aszerint kell megválasztani a nyelvet.
A C/C++-t nem kell sajnálni, az összes jelentõs programnyelv alapja, így akkor is erõsen ajánlott megismerni, ha nemtán nem is fogjuk használni.
A C/C++-t nem kell sajnálni, az összes jelentõs programnyelv alapja, így akkor is erõsen ajánlott megismerni, ha nemtán nem is fogjuk használni.
Athlon64 3500+ | MSI K8N Diamond | Sapphire Radeon X850XT | 2*512 Samsung DDR | Creative Audigy2 | Maxtor 300 + 120GB SATA | Pioneer 109 | CoolerMaster Stacker ház | CoolerMaster RS-450-ACLY táp
#7
sztem. amíg a C-t és C++-t nem váltja ki semmi, addig nem kell tartani semmitõl. A java pedig erre abszolút nem képes, mivel nincs natív fordítási lehetõsége, stb. A többi nyelv pedig még annyit sem ér (python, szí sár).
#6
"sok esetben a sebesség miatt a C/C++ jóval kifizetõdõbb, mind a program futási mind a fejlesztési idejét tekintve."
Ezzel a kijelentéssel vitába szállnék. Olyan területeken, ahol a futási sebesség nem fontos szempont, jóval rövidebb fejlesztési idõket lehet elérni az új programozási nyelvek (C#, Java) segítségével.
Ahol a sebesség és teljesítmény a fõ szempont (pl. egy webszerver-programnál), ott a C++ a szûkséges, viszont a fejlesztési idõ ilyenkor jelentõsen megnõ.
Az a lényeg, hogy ezek a programnyelvek más és más feladatokra valók. Egy Doom3-szintû játékot vagy egy server-programot senki sem fog Java-ban írni, míg egy egyszerû tetrist vagy kisebb applikációt jóval egyszerûbb Java-ban összedobni, mint C++ -ban.
Ezzel a kijelentéssel vitába szállnék. Olyan területeken, ahol a futási sebesség nem fontos szempont, jóval rövidebb fejlesztési idõket lehet elérni az új programozási nyelvek (C#, Java) segítségével.
Ahol a sebesség és teljesítmény a fõ szempont (pl. egy webszerver-programnál), ott a C++ a szûkséges, viszont a fejlesztési idõ ilyenkor jelentõsen megnõ.
Az a lényeg, hogy ezek a programnyelvek más és más feladatokra valók. Egy Doom3-szintû játékot vagy egy server-programot senki sem fog Java-ban írni, míg egy egyszerû tetrist vagy kisebb applikációt jóval egyszerûbb Java-ban összedobni, mint C++ -ban.
#5
A C# közel sem jelentõs a nyelvek szempontjából. A JAVA jóval elterjetteb, de a C/C++ valóban régóta hasznlatban van, és még jó ideig az egyik legelterjetebb nyelv lesz, pláne mert sok esetben a sebesség miatt a C/C++ jóval kifizetõdõbb, mind a program futási mind a fejlesztési idejét tekintve.
#4
nagy hátrány, hogy a C#-hez Framework.NET, a Java-hoz pedig Java Runtime-ot kell letölteni és telepíteni. A Java ebbõl a szempontból további hátrányban lesz, mivel a .NET támogatott a Windows Update-rõl, valamint a Longhorn már tartalmazni fogja. Java-t nem.
Ráadásul ezek sebességei... legalábbis kíváni valót hagynak maguk után. Különösen, ami a Java-t illeti.
Szemben a C++, amihez nem kell semmi futtató környezet, telepítõ alkalmazással vihetõek a szükséges DLL-ek és egyéb fájlok.
Ráadásul ezek sebességei... legalábbis kíváni valót hagynak maguk után. Különösen, ami a Java-t illeti.
Szemben a C++, amihez nem kell semmi futtató környezet, telepítõ alkalmazással vihetõek a szükséges DLL-ek és egyéb fájlok.
#3
Csak nekem tûnt fel a cikkben, h az egyik álláspont ( C++ alkotója ), a porgramozók SZÁMÁRA vonatkozik, a másik pedig az ARÁNYÁRA.
Száma az informatika terjeszkedésével nyílvánvalóan nõ, azért sok nyelvnek ez az alapja, aránya is csökkenhet ezzel együtt.
Száma az informatika terjeszkedésével nyílvánvalóan nõ, azért sok nyelvnek ez az alapja, aránya is csökkenhet ezzel együtt.
[ helikopter ]
#2
A linken talalhato kepeknel egy kicsit el vannak jobra csuszva a grafikonok es nyelv alairasok... erre figyeljetek, mielott hibas kovetkezteteseket vonnatok le 😄
caddie
#1
En nem feltenem a C / C++ vonalat.
"Az Evans Data elemzõi például saját adataik alapján arra a következtetésre jutottak, hogy az elmúlt hat évben folyamatosan csökkent a C++ nyelvet használó programozók száma, és arányuk az 1998-as 76 százalékról 2004-re 46 százalékra zuhant. "
Sztem egyik adat sem valos. C-ben meg talan mindig tobben programoznak, mint C++ -ban. Ami realis alapot adhat a nyelvek jelenlegi hasznalati tendenciainak, az a vasarlolhato konyvek / felkinalt allasok szama.
C/C++ iranyvonal egyelore kivalthatatlan(C mar lassan 30 eve, C++ pedig 20 eve toretlenul fejlodik, javul... mindazonaltal a Java / C# -nak is ketsegtelenul hatalmas a felhasznalhatosagi faktora.
A masik dolog pedig az, hogy mint fent irtam, a C-t meg mindig rengetegen hasznaljak. Ezek egy resze nem is nagyon fog atterni C++-ra, mig egy masik reszuk jo esellyel C++ valasztja elobb utobb alternativanak, mivel a Java / C# nem kepes teljesitmeny teruleten meggkozeliteni az elobbi nyelveket. Erog hatalmas potencialis bazisa van meg a C++-nak.
Ez persze csak az en viziom, remelem jol kovetkeztetek.
"Az Evans Data elemzõi például saját adataik alapján arra a következtetésre jutottak, hogy az elmúlt hat évben folyamatosan csökkent a C++ nyelvet használó programozók száma, és arányuk az 1998-as 76 százalékról 2004-re 46 százalékra zuhant. "
Sztem egyik adat sem valos. C-ben meg talan mindig tobben programoznak, mint C++ -ban. Ami realis alapot adhat a nyelvek jelenlegi hasznalati tendenciainak, az a vasarlolhato konyvek / felkinalt allasok szama.
C/C++ iranyvonal egyelore kivalthatatlan(C mar lassan 30 eve, C++ pedig 20 eve toretlenul fejlodik, javul... mindazonaltal a Java / C# -nak is ketsegtelenul hatalmas a felhasznalhatosagi faktora.
A masik dolog pedig az, hogy mint fent irtam, a C-t meg mindig rengetegen hasznaljak. Ezek egy resze nem is nagyon fog atterni C++-ra, mig egy masik reszuk jo esellyel C++ valasztja elobb utobb alternativanak, mivel a Java / C# nem kepes teljesitmeny teruleten meggkozeliteni az elobbi nyelveket. Erog hatalmas potencialis bazisa van meg a C++-nak.
Ez persze csak az en viziom, remelem jol kovetkeztetek.
caddie