33
-
Robin Hood #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). -
BiroAndras #32 Mennyiben rosszabb egy string osztály egy beépített típusnál ? -
Robin Hood #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! -
#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. -
trabant #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... -
trabant #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. :D -
trabant #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? -
Benoke #26 Igen, de hol van az leírva hogy ezt kötelező szeretni? Fenntartom magamnak a jogot hogy utálljam. 
-
#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 -
Benoke #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.
-
Benoke #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 :) -
#22
Sztem te siman C-rol beszelsz, nem Cpp-rol... a ketto meg eleg messze van egymastol. -
#21
A mezei string egy valtozo meg class/?? Te valamit most bekavartal nagyon.
std::string, MSDN std::string
-
trabant #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. -
#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
É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). -
#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ó. -
Yeti #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. -
#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 :-). -
#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.
-
#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 :-) -
trabant #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. -
trabant #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. :) -
trabant #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. -
trabant #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++. -
trabant #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. -
yy #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). -
Admiral #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. -
Benoke #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.
-
#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.
-
#2
A linken talalhato kepeknel egy kicsit el vannak jobra csuszva a grafikonok es nyelv alairasok... erre figyeljetek, mielott hibas kovetkezteteseket vonnatok le :D -
#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.