Jó C++ gyorstalpalót keresek

C/C++

Sziasztok!

Tudtok ajánlani jó C++ gyorstalpaló könyvet / e-könyvet / dokumentációt?
(sokadik nyelvként szeretném alapfokon megtanulni)

  • 121264 megtekintés

( aludanyi | 2013. 02. 03., v – 18:34 )

Neeeeeeeeeeeeeeeeeeeeeeeeeeem!!!

C++ nem egy gyorsan tanulható/csinálható dolog. PONT! PERIOD! FULL STOP!

Ahogy mondod, nincs is rosszabb, mint mikor jön egy Java developer, és elkezd C++-ozni, mert azt hiszi, azt is tudja. Jah de, van rosszabb, amikor egy C programozó csinálja ugyanezt.
Szóval a C++ egy igen összetett nyelv, és nehéz jól csinálni.
----
India delenda est.
Hülye pelikán

A C oldalt aláírom. Én C-ben kezdtem. most kénytelen vagyok C++-ozni. Biztosan megvan mindkét nyelvnek a maga szépsége, de a C++ nekem nagyon nem fekszik. A C nekem sokkal praktikusabb, egyszerűbb, fölösleges sallangoktól mentes nyelv. Ahol ezek a számomra sallangok biztosan jól jönnek máshol, de aki C-ben megtanult proramozni, és szereti is annak az (pl)objektumorientáltság jó eséjjel nem fog tetszeni.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Amikor Linus hisztizett a C++ ellen, na az nagyon szánalmas volt, de valamire rátapintott. A C++ egy kezdőbarátabb nyelv, és emiatt sokkal több a balf*sz, aki képes alkotni benne valamit, és emiatt azt hiszi, érti a nyelvet. A C++-t lehet szimplán okosabb C-ként használni (szorosabb típusellenőrzés, prototípusellenőrzés, const, constexpr, okosabb structok, egyszerű template (defineok helyett)), és lehet magasabb szinten is használni, de ha valaki nem tudja, mit miért használ és mi mire való, az nagyon csúnya dolgokat tud csinálni C++-ban. C-ben ez ritkább, mert aki buta, az hamar elvérzik a hello world után.
Szóval én nem látom semmi hasznát a C-nek az olyan területeken kívül, ahol nem érhető el C++ fordító vagy nem kényszerülsz valamiért C-re, de tény, hogy C++-ban könnyebb rejtett működést produkálni, ami odafigyelést kíván.
----
India delenda est.
Hülye pelikán

Meglepett +1
(még szoknom kell, hogy szeretem a C++-t).

Hozzátenném, hogy beágyazott környezetben (nálam a programozásról elsősorban ez ugrik be) nem használnék C++-t (ennek ellenére tettem, de ez más kérdés), inkább C-t. Amúgy beágyazott rendszereknél NagyZ kedvenc Java-ja is elvérzik (többé-kevésbé, nyilván lehet vele szórakozni, de nem elterjedt, a mobiltelefonokról ne beszéljünk, az kicsit más kategória).

Tudtommal akaratlan overheadja egy dolognak van csak: a kivételkezelésnek. Azt nyílván mellőzni kell embedded környezetben (ki lehet kapcsolni, a new sem fog bad_alloc-ot dobni).
Amúgy a C++ a zéró óverhed elvet tartja, tehát amit nem használsz, azért nem fizetsz. Polimorfizmus nem feltétlenül praktikus embedded rendszerben.
De mint említettem, a C++ szigorúbb fordítási idejű ellenőrzései már önmagában hasznosak, ha C kódot írsz és C++-al fordítod, már előrébb vagy. Érdemes egy kicsit const náculni is, valamint a C stílusú kasztolásokat lecserélni C++-osakra.
----
India delenda est.
Hülye pelikán

1. Pontosabban ki tudod fejezni, mit akarsz, a static_cast pl hibát ad fordításkor, ha egy privát bázisosztályra mutatóra vagy egy unrelated mutatóra akarsz konvertálni, a const_caston kívül semmi sem veszi el a constot, így nem tudsz véletlenül hibákat belerakni, pontosan azt kasztolsz arra, amit és ahogy akarsz, nincsenek implicit következmények. Jól definiáltak a műveletek (már ahol lehet).
2. A kasztolás rossz, és minél könnyebb őket megkeresni, minél jobban kiugrik a kódból, annál jobb. Ilyen szempontból a C stílusú kasztolás katasztrófa.
----
India delenda est.
Hülye pelikán

Az embereknek általában van egy téves előiteletük a C++-ról. Egyébként nincs olyan, hogy gyorsabb vagy lasabb nyelv, csak az van, hogy C++-ben lehetséges gyorsabb programokat írni mint C-ben (ha tudod, hogyan) :)

És még csak annyit, ha tényleg az ember full-stack programozó akar lenni, akkor mindkettő kötelező (C is és C++ is), hiszen majdnem minden igazán fontos kód a világon vagy C vagy C++.

Azok nem fontosak :) és sok +.

A biztonságkritikus szoftver halál, ha C/C++-ban van írva. Redundáns, újra fel nem használható fost írnak biztonságkritikus szoftver címen, oly módon, hogy a kód kb. 40%-a bullshit. A követelményeket programozáshoz nem értő bullshitter excel mérnökök állítják össze.

Legalábbis amit én láttam. Pl. CRC-vel védenek egy apró kis memóriaterületet, mondván, hogy az kritikus, és a kozmikus részecskék megváltoztathatják a memória állapotát. Jobb ilyenben nem részt venni.
Orvosi műszerekben, fékekben, hasonlókban fordul elő ilyesmi.

Nem tudom mi lenne a helyes, gondolom nem C, hanem valami más nyelv, és a redundanciát meg egy külön elfedett absztrakciós layer hozná be.

ADA is a great toy, but... you can't build the Real World with a toy.

A link azért jött ide mert elmondja, hogy miért uralkodik a C (és miért nincs és soha nem is lesz semmi esélje annak a többi "tökéletes" nyelvnek, hogy átvegyék a helyét). Röviden, a C és C++ mérnökök terméke és ezért csak a mérnököknek tetszik... de hát azok is építik a Real World-ot, az infrastrukturát amire minden épül és minden függ.

Nem kell mindenre C vagy C++ és sok mindenre nem is az a legjobb megoldás, de vannak (fontos) dolgok amire igen.

"The syntax and semantics of C is amazingly powerful and expressive."
"Its semantics are so simple and the syntax so powerful it lowers the cognitive load substantially, letting the programmer focus on what's important."

Ez az ember nem érti, mit jelentenek a fogalmak, amiket használ. C-ben a problémára lehet koncentrálni? Pont C-ben? Amikor millió hülyeségre kell odafigyelni mellette, kézzel foglalni a memóriát, kézzel kezelni a változást, mindig az adott helyen hibaellenőrizni stb? Ne már. Egyszerű és tiszta nyelv a C, kevés a rejtett működés benne, de ne keverjük ezt össze a kifejezőerővel.

"the "surface area" of C APIs tend to be simple and small."

Ez az ember szerintem még nem látott C APIkat. Pont hogy sokkal összetettebbek a függvényhívások, mert nincsenek objektumaid, minden szart oda kell írni, tele van minden flagekke, unionokkal.

"C is the fastest language out there, both in micro and in full stack benchmarks."

qsort vs sort
A C++ soha nem lassabb, és néha gyorsabb, mint a C, ha megfelelően van használva.

"there are dangling pointers and memory/resource leaks, bolted-on support for concurrency, ..., no namespaces. Error handling can be painfully cumbersome and verbose."

Tök jó, hogy ezekre a problémákra a C++-nak kész válaszai vannak, és egyedül a hibakezelésben van emiatt performance tradeoff.

Nem más ez, mint egy félig művelt C-fan rantolása.
----
India delenda est.
Hülye pelikán

De attól függetlenül még igaz, hogy a C (és még hozzátenném a C++ is) kiraly.

Egyébként az a "millió hülyeségre kell odafigyelni" az ami "important" ha akarod, hogy a megoldásod jó legyen. Ignorance is NOT bliss! Nem csak a MIT csinál a kód a fontos, hanem a HOGYAN csinálja a kód is fontos (programozás esetében super_important!)

Ez lehet, hogy neked hülyeség és disztrakció, de egy kompetens mérnöknek akinek nem csak a kényelem és a "first_row" rövid távú - látható - produktivitás a fontos, hanem mindenekelőtt a tehnikai validitás amelyre tovább lehet építeni és ami a hosszu távú - kevésbé látható - produktivitást növeli annak ez nagyon fontos.

Te kevered a dolgokat. Csak azért, mert nem akarok mindig mindent kézzel csinálni, még érthetem, hogy mi történik. Csak azért, mert nem kézifúróval fúrok, még értem, hogy a fúrógép hogy fúr, és alkalomadtán, ha szükséges, kézzel is meg tudom csinálni.
----
India delenda est.
Hülye pelikán

Rossz összehasonlitás (a fúró).

A lényeg abban van, hogy ha valamivel nem kell foglalkoznod akkor azzal nem fogsz foglalkozni. Nem vagyok biztos benne, hogy egy programozó ezt minden esetben megengedheti magának. Csak ennyi. De ez nem csak C vagy C++ esetében érvényes, mondtam már, hogy JVM/CLR és akár egy Lisp Machine esetében is fájni fog ha a gépet nem tartod szem előtt.

In his classic talk at the Turing awards, Dijkstra remarked that computer programming is an “intellectual challenge which will be without precedent in the cultural history of mankind”. What is it that makes software development so hard? Dijkstra himself gave the answer by concluding that a “competent programmer is fully aware of the strictly limited size of his own skull”.

so... it's not about programming languages it's about the size of the skull ;)

but...

It’s a reference made to the great cognitive challenges of software development. Programming stretches our cognitive abilities to a maximum and we need to counter with effective design strategies to handle the complexity inherent in software.

so... programming language facilities are important too :)

How's this for BS? :)))

"C is clearly not the cleanest language ever designed nor the easiest to use, so why do so many people use it?

• C is flexible: It is possible to apply C to most every application area, and to use most every programming technique with C. The language has no inherent limitations that preclude particular kinds of programs from being written.

• C is efficient: The semantics of C are ‘low level’; that is, the fundamental concepts of C mirror the fundamental concepts of a traditional computer. Consequently, it is relatively easy for a compiler and/or a programmer to efficiently utilize hardware
resources for a C program.

• C is available: Given a computer, whether the tiniest micro or the largest super-computer, the chance is that there is an acceptable-quality C compiler available and that that C compiler supports an acceptably complete and standard C language and library. There are also libraries and support tools available, so that a programmer rarely needs to design a new system from scratch.

• C is portable: A C program is not automatically portable from one machine (and operating system) to another nor is such a port necessarily easy to do. It is, however, usually possible and the level of difficulty is such that porting even major pieces of software with inherent machine dependences is typically technically and economically feasible."

Bjarne Stroustrup

Linux, BSD, Windows, AIX, OSX, QNX, VxWorks, JVM, CLR, Oracle, SQL Server, IBM DB2, MySQL, SAP, Exchange Server, Apache Web Server, IIS, GNOME, KDE, QNX, GCC, LLVM/Clang, Intel Compilers, Microsoft Compilers, Visual Studio, Chrome, Firefox, IE, Safari, OpenGL, DirectX, OpenCL, CUDA, VMware, Hyper-V, Citrix Software, Cisco Software, Adobe Software, Autodesk Software, Microsoft Office, OpenOffice/LibreOffice, Amazon, Bloomberg, Google Search Engine, Catia, almost all the game/3D engines...

és persze az INTEGRITY-178B RTOS (the OS of Airbus A380, Boeing 787 and of course B-2, F-22 and F-35), Next Generation Air Transportation System (NGATS)...

elég?

ha nem akkor:

"The current stable version of GCC is 4.7.2, which was released on September 20, 2012. GCC now uses C++ as its implementation language."

Szóval már nem is C hanem C++ :)

Igen, tudom hogy "the world runs on c and c++" (talán sutter mondta ezt a gonative konferencián?), csak a "majdnem minden" volt nekem egy kicsit túlzó. Amúgy igen, minden fontos szoftver C/C++, mert a fontos szoftvereknél általában komoly erőforrás megszorítások vannak.
----
India delenda est.
Hülye pelikán

Hát nem tudom, nekem nincs gyomrom a C-hez.
Hányingerem van, ha meglátok egy macro-t.
Zavar, hogy nincs konstuktor destruktor.

Persze lehet, h. azért mert nem láttam még szép C projectet, viszont szép C++ projectet már láttam.

Egy idő után minden általam látott C project leimplementált egy virtuális metódus hívó rendszert. Ilyenkor felmerül a kérdés, hogy akkor miért nem használun C++-t???

Szóval C-t én inkább úgy látom, hogy kis, rendszerkritikus feladatok nyelve, ahol az egyszerűség előny.
Illetve C++ kódban néhány hardcore optimalizáció C (ciklus mag optimalizációk pl.), de az ilyen kódok engem jobban emlékeztetnek az gépi kódra, mint a C-re.

Szerintem te túlságosan rózsaszínben látod a C nyelvet. Vegyünk egy egyszerű példát, string1-hez szeretnéd hozzáfűzni a string2-t.

Ezt C-ben hogyan implementálod le? Leméred a két char* string hosszát (2*strlen), átméretezed a string1-et (realloc), hozzámásolod a string2-t (memcpy, mivel az strcat folyton 0-t keresne) és lezárod nullával. Napi szinten szerintem ezrével írják ezt le az emberek és százával rontják el. Ráadásul az strlen nem egy gyors művelet.

Nyilván C-ben tudsz saját string típust létrehozni, ahol tárolod a hosszt, a típusodhoz írsz procedúrákat. De innentől lényegében már egy osztályt hoz létre az ember, csak rendes nyelvi támogatás nélkül. Másképp fogalmazva elég ritka olyan projectet találni, ahol nincs szükség containerekre. Ezeket meg sokkal biztonságosabb C++-ban megírni mint C-ben. A keletkező gépi kód meg nem kéne, hogy eltérjen.

Napi szinten szerintem ezrével írják ezt le az emberek és százával rontják el.
Igen, de legalább egyszerűen és gyorsan ki lehet javítani.

C egy egyszerű nyelv, egyszerűen felismerhető és javítható hibalehetőségekkel. C++ bonyolult nyelv, amely jól használva sok C-ben elkövethető egyszerű hibát megakadályoz. Viszont a bonyolultság olyan hibalehetőségeket teremt, amilyenről egy C programozó nem is álmodhat. Összességében nem vagyok meggyőződve arról, hogy egy C++ projektnél kevesebb időt kell tölteni debugolással.

"Igen, de legalább egyszerűen és gyorsan ki lehet javítani."

Ez biztos? Nagyon könnyű stringkezelésbe kis memóriatúlírási hibákat beletenni, amik kivédéséhez minden ilyen kis vacak kódot külön-külön tesztelni kell sokféle inputtal, gcc -fstack-protector-all, dmalloc, Valgrind és hasonló barátainkkal karöltve. C++-ban annyival egyszerűbb és gyorsabb ezeknek a kijavítása, hogy elég azt az egy-két string osztályt letesztelni, amit az ember életében ír.

"Nyilván C-ben tudsz saját string típust létrehozni, ahol tárolod a hosszt, a típusodhoz írsz procedúrákat. De innentől lényegében már egy osztályt hoz létre az ember, csak rendes nyelvi támogatás nélkül."

Az objektum orientált programozás messze-messze nem erről szól, hogy objektumaid vannak meg azokba dobálod bele a függvényeid.

Ha szerinted ez az OOP, akkor fogalmad sincs, hogy mi az.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Alapvetően egy modellezési szemlélet amely a megoldandó feladat adatait és az azokon végzett folyamatokat absztrakt módon és opcionálisan lazán csatolva, az egyes részegységeket egyszerűen cserélhetően, tesztelhetően, rétegekre és részekre bonthatóan ad megoldást. Mindezt úgy, hogy az adott részfeladat megvalósítását képes elrejteni előled.*

Példák:

A téged érintő világot objektumokkal modellezed le. Például vegyünk egy webshopot: vannak benne Termékkategória, Termék, Termékkép, Terméktulajdonság, Vevő, Kosár, Kosárelem, stb. objektumod. Ezeket szépen lemodellezed, az objektumoknál szépen felvésed a viselkedését is hozzácsatolva az objektumhoz. Pl. a Kosár.KosárbaTesz(Termék) metódusod módosít a kosár tartalmán. Ez eddig ugye trivi.

Viszont amibe már nagyon sokan nem gondolnak bele, hogy objektumokkal nem csak "tárgyakat" lehet modellezni, hanem folyamatokat vagy magát az alkalmazást is. Példa: van egy termékkategóriád amely tartalmaz magában Termék objektumokat. Te ezt meg akarod jeleníteni de a felhasználó kiválaszthatja, hogy név vagy ár szerint akarja rendezni. Ilyenkor készítesz egy egy RendezveListázó absztrakt osztályt, majd ebből származtatsz egy név és egy ár szerint rendező objektumot majd ezzel rendezteted. (Egyébként nagyjából ez a strategy pattern lényege).

Na de te ki akarod szervezni az egészet egy külső modulba ami teljesen cserélhető. Ekkor már bejön az az (egyébként nagyon elhanyagolt alapelv, hogy) felületre fejlesztés. Te csak annyit tudsz, hogy van egy IRendezveListázó interface-d, amelyről annyit tudsz, hogy van egy Rendez(Termékkategória) metódusa. Arról, hogy mi és hogyan van mögötte implementálva, arról fogalmad sem lehet, az számodra egy fekete doboz. Ami mögötte van az cserélhető, jöhet bárhonnan, míg megvalósítja azt a "felületet".

Vagy például mondhatnám a melóhelyi projektem: az úgy néz ki, hogy minden modul egy külön dll. (.NET-es a cucc), amelyben vannak modulok, amelyek implementálhatnak ilyen-olyan interfacet. Természetesen ezek a modulok hívogatják egymást. Meg lehetne csinálni azt is, hogy minden modul hordozza magával a saját singletonját/globális változóját/static változóját/egyéb kedvenc megoldását de meg lehet csinálni azt is, hogy van egy Application objektum, amelytől le lehet kérni adott interface-t megvalósító modulokat. Aztán, hogy azon belül hogyan van megvalósítva egy modul (vagy egyáltalán melyik .dll-t tölti be) az már csak és kizárólag a config fájltól függ.

* Egyébként szerintem sokaknak ez a problémája, hogy nem képesek absztrakt fogalmakkal dolgozni. pl. ott egy sima mezei echo "bizbasz", ami megjelenít egy szöveget a képernyőn/weblapon/bármin. Valójában ez akár sok-tízezer CPU utasítás lehet, azonban számukra egy egyszerű, elemi művelet. Viszont úgy látom, hogy sokakat zavar, hogy ha nem látják pontosan a szemük előtt a megvalósítást. Pl. 6 példányban CTRL+C,V-zett listázó, mert nem tudott az elvont "Valamit Listázó" fogalmával megbarátkozni, csak azzal, hogy ez a kód itt egy olyan listázó, ami X-et kilistáz.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

C++-ban sem lehet mindig elkerülni a makrózást. De inline függvények pl. már C99-ben is vannak.

Én kifejezetten örülök neki, hogy nincs konstruktor a C-ben. Egy kutya közönséges függvénnyel is meg lehet konstruálni egy objektumot, nem kell ehhez külön nyelvi elem. Ráadásul írhatok olyan konstruktorfüggvényt, amely pointert ad vissza a létrehozott objektumra (a C++ nyelvi elem csak értéket adhat vissza), így NULL-lal tudom jelezni, ha hiba van. Így aztán nem vagyok rákényszerítve a kivételkezelésre sem (másik borzasztó feature); C++-ban viszont csak úgy lehet a konstruktort failelni.

Hát virtuális metódusokat azt csinálok. Bár jelenleg azért fejlesztek C-ben, hogy lássam, hogy C++ nélkül is lehet élni. Eddig elég élhetőnek tűnik.

Az ugye megvan, hogy ami C-ben lehetséges, az C++-ban is (eltekintve a variable length arraytől)? Tehát egy kutya közönséges függvénnyel tudsz konstruálni objektumokat, senki nem kényszerít a konstruktorok használatára. A konstruktor nem ad vissza semmiféle értéket, nem is értem, hogy keverted ide.
Illetve ha borzasztónak tartod a kivételkezelést, az mondjuk jelzi, hogy nem értesz a programozáshoz úgy általában.
Persze ha vezérlési szerkezetként van használva, az nem jó, de szar programot mindennel lehet csinálni.
----
India delenda est.
Hülye pelikán

"Illetve ha borzasztónak tartod a kivételkezelést, az mondjuk jelzi, hogy nem értesz a programozáshoz úgy általában."

+1. Össze lehetne számolni, hogy hány helyen ellenőrzik egyáltalán a malloc eredményét...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Pont ezt akartam kérdezni,hogy akkor minden egyes memóriafoglalásánál végig
kell nézni, hogy ha nem sikerült, akkor mit tudunk csinálni, hogyan tudunk
az adott ágból normálisan kiszállni? Nem teszi ez iszonyatosan bonyolulttá
a kódot? (ha kihagyom, akkor gondolom nem :))

Pl. üríted a cache-t, amiben az objektumaidat tárolod. Én dolgoztam már ilyen rendszerrel, saját cache-ünk volt embedded device-on, ami nyilvánvalóan sokat gyorsított, viszont ha kellett az új, "hasznos" memória, akkor kellett futtatni egy GC-t.

Attól, hogy nem láttál még ilyen rendszereket, valószínűleg kismillió lehetőség van.

"Az ugye megvan, hogy ami C-ben lehetséges, az C++-ban is (eltekintve a variable length arraytől)?"
Ez bizonyos alacsony-szintű optimalizációknál rendben is van, és hasznos.

De tessék azt megmondani, hogy akkor két olyan C++ programozó, amelyik a C++ nyelv különböző részhalmazát használja és tartja jó feature-nek, vajon egy nyelvet beszél-e? Hány nyelv is akkor a C++?

Mert nem csak nyelvek vannak, hanem szokások és konvenciók is, hogy mit hogyan szokás (kell) megcsinálni. Ezek mind szükségesek ahhoz, hogy több fejlesztő együtt tudjon működni.

Ha pedig valaki a C++ extra feature-eit inkább károsnak tartja, akkor nem érdemesebb inkább C-t használnia, hogy ezzel C programozónak kategorizálja magát, és a magához hasonló gondolkodásúak között mozogjon?

"Illetve ha borzasztónak tartod a kivételkezelést, az mondjuk jelzi, hogy nem értesz a programozáshoz úgy általában."
Szerintem a kivételkezelés csak egészen kivételes esetekben hasznos. Pl. ha olyan kódod van, ami nem tudja, hogy mit hív meg.

Konkrét példa arra, hogy hogyan ne használjuk a kivételkezelést: Java API.
Hint: kivételkezelés != hibakezelés. Nem minden hiba kivételes.

És ha már a szokásokról beszéltem: C++-ban van egy szörnyű következménye a kivételkezelés bevezetésének. Ez pedig az, hogy a szokás arra kényszerít, hogy exception safe code-ot írj, mert valaki előbb-utóbb úgyis kivételt fog keresztül küldeni a kódodon. Az exception safety pedig behozza a RAII-t, a destruktorokat és még egy pár dolgot, amire figyelni.

Overdesign. Ez az, amire a C++ (részben a szokás által) csábít és kényszerít. Ezért használok C-t, mert ott elég nagy a penalty az overdesignhoz, hogy ne csábuljon el az ember, és kezdjen el olyan dolgokkal foglalkozni, amire lehet, hogy soha nem lesz szükség.

"Hány nyelv is akkor a C++?"

Többé kevésbé 1, de igazad van, hogy sokan sokféleképp használják. Ezért kell egy közös guideline, hogy adott projekten belül mit és hogy szabad használni. Ha az a szabály, hogy csak olyan kód kerülhet be, ami C és C++ fordítóval is lefordul, már előrelépés a C-hez képest, és innentől már látható, hogy megfelelő szabályozással megfelelő kód fog létrejönni. A C++ fícsöreit elhagyni csak azért, mert rettegsz a többi programozótól, ez olyan open source dolog. Pedig vannak jó open source példák is, lásd webkit.

A kivételkezelés igenis hibakezelés. Az a jó a kivételkezelésben, hogy az fogja kezelni a hibát, aki tudja, mit kezdjen vele, és ez teljesen automatikusan történik, az erőforrások leakelése nélkül. Nyílván nem mindig értelmes használni, de a C++ pont erre épít, hogy a programozó tudja, mikor melyik eszközhöz nyúljon.

Ha a te libed azt mondja, hogy NEM vagyok exception safe, akkor nem lesz az. Nem kényszerít senki rá, akkor a user fog vigyázni rá, hogy ne rakjon kivételdobást a konténereidbe, algoritmusaidba, vagy viseli a következményeket. C-ben sem kezel le mindenki minden hibát (csak hogy a legalapvetőbbet nézzük, a malloc hibáit), könyvtárakban sem.
Mellesleg az exception safety nagyrészt ingyen van (érdemes megnézni a standard könyvtárat ilyen szempontból), és ha neked a RAII egy olyan dolog, ami nyűg, akkor visszautalok arra, hogy nem érted ezt a programozás dolgot. A RAII olyan, mint egy falat kenyér, hatékony környezetben biztosítja az erőforrások felszabadítását.

"elég nagy a penalty az overdesignhoz, hogy ne csábuljon el az ember, és kezdjen el olyan dolgokkal foglalkozni, amire lehet, hogy soha nem lesz szükség."

És ezért nehéz robosztus programot írni C-ben.
----
India delenda est.
Hülye pelikán

"Az a jó a kivételkezelésben, hogy az fogja kezelni a hibát, aki tudja"
Igen, a mesében így van. A gyakorlatban pedig az történik, hogy hiba esetén dobunk egy kivételt, az elkapással meg ráérünk addig várni, amik tesztelés során eszkalálódik egy kezeletlen kivétel.

A RAII nagyon jó dolog, a baj nem a RAII-val van. A baj az, hogy RAII nem egy opció, hanem egy kényszer, kötelező használni, mert az exceptionök kockázata mellett még mindig ez a legnormálisabb módja az erőforrás-felszabadításnak.

Az még egy ideális helyzet, ha repül a kivétel, és nem kapja el semmi, mert akkor esély van arra, hogy egy logból kiderüljön, hogy a szokásos nem gömbölyűhöz képest sem gömbölyű valami.

Az igazán elegáns az, amikor a kivétel nagyon is el van kapva, és... és semmi... valami középrétegi hiba szépen, gondosan eltemetve egy catchben, utána az özönvízzel.

Ha nem kapja el semmi a kivételt, hogyan keletkezne logsor?

Sokan elfelejtik amúgy azt, hogy kivételt ott kell elkapni, ahol tudunk vele valami értelmeset kezdeni. Ha olyan helyen kapunk el kivételt, ahol már nem vagy még nem lehet semmit csinálni a kivételt okozó helyzettel, akkor igazából édesmindegy a dolog.

Elmeséled, hogy mi a baj a Java-ban használt Exception kezeléssel? (szándékosan nem
fordítom magyarra). Érdekelne.

Java-ban úgy van megoldva, hogy van Runtime exception, ami bármikor jöhet, de alapvetően
nem kellene használni, aztán van a normál exception, amit te beleírsz a kódodba, hogy
ha ott valami elszáll, akkor bizony ez fog jönni, és erről a hívó fél tud, és neki
ezt kötelező lekezelnie.

"Nem minden hiba kivételes." ezt sem értem.

A Lisp egy high-level nyelv, sokkal inkább az, mint a C++ vagy Java. Ahogy már mondtam, a kivételkezelésnek lehet értelme, de káros egy mid-level nyelvre ráerőltetni, mint a C (ahogyan a C++ teszi), vagy orrba-szájba erőltetni hibakezelésre (ahogyan a Java standard könyvtár teszi).

De mondok egy nyelvet, amelyek nincs annyira távol a megszokottaktól, és helyén kezeli a kivételkezelést: Go.

Egyrészt konkrét példát nem adtál arra, amikor kivétellel jeleznek egy nem kivételes hibát (bár elhiszem, hogy van ilyen, nekem fejből egy eset sem ugrik be). Másrészt ez miért is baj? Attól, hogy a hiba nem kivételes, annak kezelésére épp ugyanolyan jól alkalmazható a kivételes hibákhoz használt megoldás.

Ebben mi a logikai bukfenc? Azt a műveletet adtam utasításba, hogy nyisson meg egy fájlt a rendszer. Nem sikerült, kaptam egy Exceptiont a képembe egyébként megyek tovább a megszokott módon.

Szerintem pont, hogy tisztábbá teszi a kódot az, hogy nem kiscsillió ellenőrzéssel túrom tele a kódot, hanem csak azt ellenőrzöm, ami valóban a logikához tartozik. Kivételes esetekkel (mivel a program szempontjából az volt az elvárt, hogy a fájl megnyitása sikerül, emiatt "kivétel") meg foglalkozok ott, ahol akarok vagy lehet.

Ha sehol nem lehet, akkor meg szálljon el az app/thread, mint a győzelmi zászló.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mint már egyszer leírtam, java-ban az exception-ök jó részét KÖTELEZŐ elkapni. Nem opcionális,
hogy elkapod-e, vagy sem, hanem a fejlesztőnek a metódusban jeleznie kell, hogy ez bizony hibát
tud dobni, és a fejlesztőnek kötelező try-catch-be rakni, vagy továbbdobni.

Igy az egész logika végén valakinek muszáj elkapnia az exception-t, és ha ő ezzel utána nem
foglalkozik, az egy programozási hiba.

Példa:

FileInputStream fs = new FileInputStream("c:\temp.dat");
fs.read();

ezt így simán le sem írhatod, mert nem fog lefordulni. Helyette kötelező:

try{
FileInputStream fs = new FileInputStream("c:\temp.dat");
fs.read();
} catch (FileNotFoundException e){
// ide jön a hibakezelés...
}

Köszi, ez érdekes volt.

Viszont azzal nem értek egyet, hogy ha mondjuk használok 3 modult amik 3
különböző exception-t adnak, akkor azt az én metódusomnak ahogy vannak,
tovább kellene dobnia a felső szintnek.

Mi ezt a problémát úgy oldjuk meg, hogy a hívó fél elől elrejtjük a belső
exception-t. Ezzel nem szennyezzük szét az interface-t.

public interface MyInterface{

public void myMethod() throws MyException;

}

és az implementációban:

public class MyClass implements MyInterface{

void myMethod() throws MyException{

try {
... do some stuff
} catch (AException e){
throw new MyException(e);
} catch (BException e){
throw new MyException(e);
} catch (CException e){
.. ezzel már tudok valamit kezdeni
} finally{
.. itt pedig mindent lezárok
}
}

tehát a metódusom a hívó fél felé nem adja tovább
az összes lehetséges hibaokot, hanem szépen bezárja
egy saját exception-be. Ha valami okból a felső rétegnek
szüksége van mégis a belső exception típusára, akkor a
MyException-ből ki tudja vadászni.

De ez értelmetlen. Van mondjuk egy modulom, amely termékeket kezel és van egy modulom, amely mondjuk a kosarat. Meg van egy modulom, amely tutujgatja mindkettőt közvetett módon, megfelelő interfacekon keresztül. Ha lekérdezek egy terméket, hogy átadjam a kosár modulnak, de érvénytelen cikkszámot adok át, akkor miért ne dobna Exceptiont a termékkezelő mopdul?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem ugyanarról beszélünk. Nem egymás melletti szintekről, hanem egymás
alatti szintekről.

A kérdés az, hogy mondjuk elszáll a termék lekérdezés egy adatbázis hiba miatt. Akkor mit csinálsz?

Ami szerintem a logikus:

class ProductLogicImplementation implements IProductLogic{

public void getProduct(int id) throws ProductNotAvailableException{

try{
return dao.getProduct(id);
} catch (SQLException e){
throw new ProductNotAvailabeException(e);
}
}

}

Az nem logikus, hogy tetszőleges Exception-t továbbdobunk, hogy aztán majd
a felső réteg lekezelje:

public void getProduct(int id) throws SQLExeption{...}

Mivel pl. semmi nem garantálja, hogy a jó eséllyel interfaceként hivatkozott
osztályból pont SQLException fog jönni, hiába dobja egy konkrét implementáció
éppen azt.

Erre most jöttem rá, de hát végülis jobb későn, mint soha :)

Amikor meg akarok nyitni egy fájlt, akkor azt azért teszem, mert szükségem van rá (vagyis utána olvasni/írni akarom a fájlt), vagyis az a feltételezésem, hogy a fájl ott van és van jogosultságom a megnyitására. Ha ez nem sikerül, az bizony kivételes hiba. Az más kérdés, hogy jóval nagyobb a valószínűsége ennek az exceptionnek a bekövetkezésére, mint mondjuk az OutOfMemoryExceptionnek, és gyakrabban is le lehet úgy kezelni, hogy a program folytathassa a futását.

Közben még az jutott eszembe, javaban azért tűnhet úgy, hogy túl sokat foglalkozik a kivételkezeléssel, mert checked exceptionök vannak, vagyis minden metódusban vagy kezelni kell a keletkező exceptiont, vagy jelezni, hogy továbbdobásra kerüljön. Ettől még nincs több kivételkezelés, mint máshol (pl. .net), csak jobban látszik a kódban.

Hallottam már elég sokat az OOP-ről, programoztam is olyan nyelvekben, amelyek ezt a paradigmát támogatják. De igazából nem tudom megmondani, mi az OOP, szerintem egy rakás bullshit, aminek az egyetlen haszna, hogy segít a hozzá nem értő fejlesztőknek strukturált spagetti kódot írni.

Amit meg tudok mondani, hogy C++-ban egyetlen olyan feature segíti az OO fejlesztést, ami nincs benne a C-ben. Ez pedig az, hogy a C++ compiler automatikusan legenerálja a virtuálismetódus-táblákat. A többi a C-ben is elérhető. Az meg, hogy van private-protected-public láthatóság, az nem egy lényeges/hasznos feature.

"Az meg, hogy van private-protected-public láthatóság, az nem egy lényeges/hasznos feature."

Oh. Már bánom, hogy kifejtettem neked fentebb a C-s rantolásról a véleményem. Egy ilyen után látom, te sem a hozzáértők táborát gazdagítod.
Hadd kérdezzek valamit: a constról mi a véleményed?
----
India delenda est.
Hülye pelikán

Nézd, Stroustrup is megmondta, hogy a protected láthatóság egy hack, és gyakorlatban is általában úgy használják.

Az tiszta OOP-nek az felelne meg, ha az adattagok private-ek, a metódusok pedig public. Ezt pedig a C-ben magától értetődően megoldható. Egyszerűen nem kell berakni headerbe a struct definícióját, csak annyit hogy "struct Object;" vagy "typedef struct _Object *Object;". Ezzel már megvan a név, lehet rá pointert csinálni, és így meg lehet írni a headerben a függvény-prototípusokat. C++ épp ugyanúgy pointerként adja át az objektumot a metódusnak (this), csak ez el van rejtve. És ennek ellenére a C++ kényszerít, hogy fordítsd újra a kódod, ha valaki hozzárak a használt osztályhoz egy private adattagot (idióta value semantics). Jó, persze lehet pimpl-özni, de hol van az a C egyszerűségéhez képest, amikor ugyanazt adja, ami C-ben magától értetődő volt?

Komolyan nem értem, minek vitatkozol, ha nem értesz a C++-hoz. Pointert pontosan ugyanúgy lehet használni C++-ban is előre deklarálás után.

Csak ott kell az osztály definíciója, ahol konkrétan használod az osztály valamilyét, tehát létrehozol egy példányt belőle, meghívod egy függvényét, eléred egy adattagját.
----
India delenda est.
Hülye pelikán

http://stackoverflow.com/questions/2672015/hiding-members-in-a-c-struct

Jelenleg a 3. válasz, amiben a kód úgy kezdődik, hogy struct SomeStruct;
Ha változik a private rész, nem fog az összes kód újrafordulni, ami használja az adott "osztályt". Ha C-ben megy, akkor gondolom C++ is megengedi, csak idegen tőle.

"Hadd kérdezzek valamit: a constról mi a véleményed?"
Hopp, ez kimaradt.

Egy ideig szép dolognak tűnt, meg hasznos, meg fordítási idejű védelem, meg stb.

De amikor egy nem triviális esetben már nem tudom mennyi ideje azzal szopok, hogy normális legyen const-korrektség, és ne sírjon compiler, meg ne kelljen ocsmány const castokat alkalmazni, na, akkor megkérdőjelezem, hogy tényleg produktívabb lett-e ettől a fejlesztés.

Én azt gondolom, hogy sokkal inkább szolgálja a produktivitást, ha a fejlesztő odafigyel arra, amit éppen csinál, mint a C++ védelmi mechanizmusai.

"• General rules:
C++’s evolution must be driven by real problems.
Don’t get involved in a sterile quest for perfection.
C++ must be useful now.
Every feature must have a reasonably obvious implementation.
Always provide a transition path.
C++ is a language, not a complete system.
Provide comprehensive support for each supported
style.
Don’t try to force people to use a specific programming style.

• Design support rules:
Support sound design notions.
Provide facilities for program organization.
Say what you mean.
All features must be affordable.
It is more important to allow a useful feature than to
prevent every misuse.
Support composition of software from separately developed parts.

• Language-technical rules:
No implicit violations of the static type system.
Provide as good support for user-defined types as for
built-in types.
Locality is good.
Avoid order dependencies.
If in doubt, pick the variant of a feature that is easiest
to teach.
Syntax matters (often in perverse ways).
Preprocessor usage should be eliminated.

• Low-level programming support rules:
Use traditional (dumb) linkers.
No gratuitous incompatibilities with C.
Leave no room for a lower-level language below C++
(except assembler).
What you don’t use, you don’t pay for (zero-overhead
rule).
If in doubt, provide means for manual control."

Bjarne Stroustrup

Szerintem racionális magyarázata ennek nincs. A C++ simán használható extended C-ként, ami extra feature-t akarsz belőle használni, azt használod, amit nem akarsz, azt nem használod. Ha akarod, használhatod kényelmes C fordítónak is (// kommentek).
Én anno régen írtam Turbo C++ 1.0-ra programot, amit egy 4.77MHz-es PC/XT futtatott éveken át. Semmi template, semmi exception, semmi STL (ezeket szerintem nem is ismerte a fordító), sima objektumok, és ennyi.
A Java-t ne keverd ide, mert az GC-s nyelv, ami vagy tolerálható egy környezetben, vagy nem.

Mert objektumorientáltság egyfajta gondolkodásmódot kíván, mintákkal, best-practice-okkal
együtt. Egy c programozó (de lehet pascal,etc.) ezt a C-ből/pascal-ból/etc. nem fogja
tudni levezetni, mert máshogy old meg bizonyos problémákat.

Megjegyzés: az objektumorientált gondolkodásmód azért sokat adott a programok tervezhetőségéhez...

Egyetértek veled. Sokan bebizonyították már nekem, hogy a C kódok sokkal hosszabbak, és átláthatatlanabbak, mint a C++ Egyet is értek velük. Annyit akartam ezzel mondnai, hogy nekem jobban fekszik a C, és valóban igaz, C++-os munkám sokal kókányabb, mert nem ezt ismerem. Egyébként manapság van amolyan aha-élményem a c++-al kapcsolatban, hogy milyen remek ötlet ez az... Megvan a maga helye.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

ezért is teljesen ellenjavallom az OO programozás tanulását c++-ban.

Az a tapasztalatom, hogy az OO gondolkodásmód a tervezéssel, tervezési mintákkal, stb. java-ban nagyon hamar előjön, mert a java nyelv egy sok nehézséget levesz az ember nyakából, és jórészt a probléma OO alapú megoldásán tud gondolkodni, kevésbé a nyelvvel kell küzdeni. Mondhatni azt is, hogy belekényszeríti az embert, ami aztán ízlés kérdése, hogy ez jó, vagy nem jó.

Éppen ezért a java fejlesztők az idő jó részét architekturális tervezéssel, tervezési mintákkal való összelegózással, integrálással, unit teszteléssel töltik, aminek az a következménye, hogy egy átlagos csapat egy java szerű menedzselt (c#, etc.) nyelvben sokkal produktívabb, mint egy c++-os, és sokkal könyebb felhozni egy kevésbé jó képességű fejlesztőt használható szintre, mint c++ esetén.

"Az a tapasztalatom, hogy az OO gondolkodásmód a tervezéssel, tervezési mintákkal, stb. java-ban nagyon hamar előjön, "

Az én tapasztalatom az, hogy ami hamar előjön, az csupán annyi, hogy legalább egy osztály mindenképpen létezik... a többi jól megtervezett kopipészt.

De ez nem is csoda: az absztraháláshoz érni kell, mint a blueshoz (korán érő tehetségek és zsenik léteznek). Nincs az a nyelvi kényszerítő eszköz, ami ezt pótolja.

"... és sokkal könyebb felhozni egy kevésbé jó képességű fejlesztőt használható szintre, mint c++ esetén."

:)

Igen könyebben lehet irni "működő" szemetet, és be kell vallani, hogy a "fejlesztők" legalább 90% másra nem is képes (C++-ban makogni sem tudna).

Uncle Bob szépen mondta már, hogy sok "fejlesztő"-nek nem kellene ebben a szakmában dolgoznia, a programozás nem munka hanem mesterség, hivatás és az aki nem azért csinálja mert szereti az inkább ne csinálja!

Mit értesz működő szemét alatt? Tényleg kíváncsi lennék... mert bizony nem kevés c/c++ kódot láttam segfault-tal elszállni, szóval
nem igazán a nyelv határozza meg, hogy adott program jó-e, vagy sem, hanem az, hogy a célnak, amire készült, megfelel-e.

Tovább megyek: mi indokolja 2013-ban, hogy egy fejlesztőnek memória foglalással, stack vagy heap-en létrehozott objektumokkal,
copy construktorokkal, ki-kinek a tulajdonosa, 32 vagy 64 bites rendszerek közötti különbséggel, és egyéb hasonló problémákkal
küzdjön, ahelyett, hogy a feladatot oldaná meg. Mert a sokat hangoztatott "teljesítmény miatt" általában nem igaz, a programok
80-90%-ban ha az adott termék normálisan megtervezett, megfelelő algoritmusok vannak használva (nem O(n^x) lehetőség szerint)
nem szokott probléma lenni, nagyon ritkán van szükség bitvadászatra.

Ha jól tévedek, az alaptétel az volt, hogy a java a kezdetektől jó fejlesztői magaviseletre nevel.

Ezzel szemben ami a kezdetektől megjelenik, az az a viselkedés, hogy bármekkora objektumot bármikor le lehet és érdemes foglalni és bármeddig életben tartani, ami abból a hitből ered, hogy memória, az mindig van, és amikor nincs, a gc mindig pont úgy intézi, hogy jó legyen.

Ezt a viselkedést és hitet csak autoszívás, vagy főnöki/megrendelői pofonok tudják kiverni, miután kiderül, hogy egy (szemét) program csak-csak elvan egy jvm-ben (a finalizer sóhajt egyet, és elvégzi a rabszolgamunkát), de amint több ilyen appnak kéne egy motoron osztoznia, előjön a mindenki szív mindenki miatt jelenség -- pedig, illetve mert a gc tényleg megtesz minden tőle telhetőt.

A félreértés: nem igaz, hogy bármennyi memória van. Ha egy java fejleszőtől ezt hallottad, akkor valamit nagyon benézett. JVM-ben induláskor meg tudod adni, hogy mi
az a max heap méret, amit garantálnia kell tudni. Erre való a -Xmx paraméter. Ezután, ha a fejlesztő több memóriát foglal le, akkor bizony kap egy out of memory
excepion-t a vm-től, és lehet dolgozni a feladaton. Általában ilyenkor egy profiler-t kell indítani, megnézni,hogy mi az, ami sokat zabál, és megoldani, hogy ezt
ne tegye.

" nem igaz, hogy bármennyi memória van. Ha egy java fejleszőtől ezt hallottad, akkor valamit nagyon benézett. JVM-ben induláskor meg tudod adni, hogy mi
az a max heap méret, amit garantálnia kell tudni. Erre való a -Xmx paraméter. "

Oszt ha meghallják, hogy a szerverben a JVM 2, 3, 4 gigáján túl még van pártucat giga, akkor sértődötten követelik annak a hozzácsapását is, szándékosan észre nem véve, hogy a 2, 3, 4 G GC ciklusai már kézifék, fékezőernyő és horgony együttes aktiválását jelentik, és a GC log a finalizer üzenőfalának tekinthető.

En a Java helyett a manapsag divatos dinamikusan tipusos szkriptnyelveket mondanam aloe veranak, mint pl. a Ruby, Scala, Python es tarsaik.
Aki nem tud programozni, az ezekben a nyelvekben sem fog tudni programozni. Hiaba old meg helyetted a Rails sok mindent, aki nem tudja, hogy mit csinal, az nem fog tudni osszedobni egy blogot benne 15 perc alatt :)

Nekem 32GB van a gépben, de már két évvel ezelőtt is 16GB volt... mégis úgy állok neki mintha 64KB lenne (pazarlás szempontjából) :)

JVM, CLR vagy XYZ... csak azért mert sok memória van nem kell pazarolni. Használni kell a memóriát mert lényegessen jobb lessz a szoftver, de pazarolni nem kell.

Valószínűleg ami itt hiányzik az a "Java fejlesztő" fogalom pontos definíciója.
A definíció hiányában értjük félre egymást.

Ha úgy definiáljuk, hogy Java fejlesztő az, aki már eljutott odáig, hogy ne higgye, hogy a memória (akár a fizikai, akár a JVM-é) a végtelenségig növelhető (mellékhatás nélkül), akkor egyetértek mindennel, és elnézést kérek az összes Java fejlesztőtől, mind a háromtól. (kidding)

Pl. mert szükséged van teljesítményre?

Mindenkinek van war-story-ja erről. A VM sok esetben szűk keresztmetszet lehet.
Emlékszem, hogy kollega .NET-ben több ezer képen kellett, hogy dolgozzon, egy akkoriban izmos szerveren.
Mit ad Isten az lett a vége, hogy heap-pel és memória felszabadítással kellett szívnia .NET alatt.

Az "O(n) limit elégséges" szemlélet sokszor a kódot régen látott elméleti srácok sajátja. Bizony az O(n) előtt kihagyott konstans szorzó az, ami miatt szívunk.

Amúgy nem csak szerverek vannak. Az olyan arcok mint Te, elfelejtik, hogy a jelenlegi HW-ek 95%-án nincsen virtuális memória, és sajnos a rendszer-malloc sok esetben gagyi. Ebből az következik, a fejlesztő FŐ feladata, hogy stack és heap használatot optimalizáljon. Bizony, vannak területek, ahol ez különbözteti meg az amatőrt a profitól.

Feladatra koncentrálás: röhögnöm kell, amikor az i3 CPU-m 30%-át eszi vmelyik VM zenelejátszáskor.

Most ugye embedded fejlesztésről beszélünk? Nyilván embedded fejlesztés egy teljesen különálló történet.

Mert átlag gépnél (legyen az desktop vagy szerver) tudom értelmezni a "nincs virtuális memória" kitételt. Egyébként se látom, hogy ez hogy kapcsolódik a virtuális gépekhez, Java-ban a VM-nek megadod, hogy mennyi a max heap méret (-Xmx512m pl.), ebből gazdálkodhat, ebbe kell beleférni. Ha nem fér bele, akkor dobja az OutOfMemoryException-t.

Az amit nagyon nehéz továbbfejleszteni mert egy totál spaghetti (tudod az a VB mentalitással fejlesztett kód ami kb. 1000x komplikáltabb mint kellene és egy "super coupled dependency jungle"... de működik.

Egyébként én elég sokat .NET/C# (ASP.NET MVC) dolgozok, de ha nem ismered a CLR-t, annak viszonyát a géphez és OS-hez, akkor nem vagy jó programozó. Szóval "write high level, abstract as much as you should (but not more than that), but think low level".

Egyébként a legtöbb szoftver esetében nem az algoritmusokkal van a gond, hanem a "komponensek" egymáshoz viszonyulásával és az 1000x nagyobb komplexitással mint ami kell.

"tanulható/csinálható"

Azért nagyon nem mindegy, hogy melyikről van szó. Egy (tetszőleges) programozási nyelvet megtanulni nem nehéz, ellenben programozni megtanulni nehezebb, és eltart egy darabig. A C++ sem annyira nehezen tanulható nyelv, ellenben megtanulni C++-ban programozni sokkal nehezebb.

Nem. Egy nyelv nem csak maga a nyelv, hanem a stilus is és ami még fontosabb, a módszerek amelyekkel az adott nyelvben megoldod a problémákat. Minden nyelvre más expressiveness/permissiveness jellemző, és nem mindegy, hogy milyen a gondolkodásod amikor használod. Ha mondjuk Java-ban gondolkodsz (vagy C-ben, Python-ban stb.) akkor függetlenül, hogy ismered e a C++ alapjait, nem fogsz jó C++ kódot irni... és ha nem tudsz jó kódot irni akkor (praktikus és produktiv szempontból) nem is tanultad meg a nyelvet.

Kedvencem a másik "dinoszaurusz nyelv" a Lisp :) csak annyi, hogy a Lisp az még mindég verhetetlen... és az is marad. :)

...és persze a C is...

...egyébként minden más nyelv a Lisp és a C között van... (assembly az nem nyelv!)

"The most powerful programming language is Lisp. If you don't know Lisp (or its variant, Scheme), you don't know what it means for a programming language to be powerful and elegant. Once you learn Lisp, you will understand what is lacking in most other languages." - RMS

Többször is volt futó lelkesedésem, hogy én most ránézek mi a nagy hűhó a LISP körül, de soha nem találtam egy olyan leírást sem, ami az alapoktól indul, ami nem a gyakorlati programozásba akar bevezetni valami variánson keresztül, hanem konkrétan az alapfogalmakba, a lényegi részbe magyaráz bele. Ha tudsz ilyet, szeretettel várom.
És ugye tudod, hogy egy RMS idézet általában nem segít a népszerűsítésben?
----
India delenda est.
Hülye pelikán

Azért írtam, mert aki már látott _bármilyen_ funkcionális programozási nyelvet, az utána már más funkcionális nyelvekre nem boci szemekkel fog nézni.

És hát tudtommal informatika szakokon legalább egy funkcionális nyelvvel illik összeismertetni a hallgatókat, már csak azért, hogy tudják, hogy léteznek ilyenek.

Nem tartottam soha sokra a tisztán valamilyen nyelveket, funkcionális elemei meg bőven vannak pl a Pythonnak is. Tudok egy csomó mindent a funkcionális nyelvekről, de a LISP nekem úgy jött át, hogy az egy ilyen generál nyelv, minden nyelvek nyelve, amiben bármi kifejezhető.
----
India delenda est.
Hülye pelikán

szvsz egy gyorstalpaló bármiből a lehető leghatékonyabb tanulási módszer.
Egyrészt gondolni kell arra, hogy az ember ember és gyors sikerélményt akar, másrészt meg egyébként is: ráér a dolgokkal akkor foglalkozni, amikor kell. Mondjuk 21 napra 21 A4-es papíron mennyi minden elfér - ellentétben a 600+ oldalas, témakörök szerint tagolt szakkönyvekkel

A C++ nagyon jó nyelv, csak tudni kell használni. Egyébként nem tudom miért gondolod, hogy a C++11 letisztult? Hiszen semmitől sem lett megfosztva, csak kapott olyan újdonságokat amelyek még jobban növelik az erejét és még jobban megerősítik azt, hogy "tudni kell használni".

A C++ igazán nagy értéke nem az, hogy könnyű (mert még véletlenül sem az), hanem az, hogy gyakorlatilag nem korlátoz, nem akar semmire sem kényszeriteni (sem OOP sem XYZ...). Ezért lehet benne nagyokat alkotni és ezért lehet benne kinyirni is magad (főleg, ha nem tudod mit csinálsz).

Ahogy idosodok, egyre inkabb egyetertek a C++ bizottsag donteseivel.

Pl. regen nem ertettem, hogy miert nem a konstruktor inicializalasi listaja donti el a hivasi sorrendet. Ez azert volt, mert meg nem nott ki a fejem. Most mar ertem, es magam sem csinalnam maskeppen.

Ezt jelenti szamomra a letisztult.

( lx | 2013. 02. 04., h – 17:38 )

Az a gyorstalpalt C++ olyan, mint lefogyni 30 nap alatt 30 kg-t (megoldható, csak nem érdemes)?

Jó szar példa.
A programozást ill. annak a tanulását, bármilyen nyelvről legyen is szó, valahogyan el kell kezdeni. Arra pedig egy gyorstalpaló is megfelelő lehet. Persze tisztába kell lenni a tudásszinttel, és ennek tudatában használni ezt a tudást. És ez az utóbbi mondat minden tudásszintre igaz, bár az elején fontosabb.
A kérdező még csak nem is utalt rá, hogy olyan gyorstalpalóra vágyik, ami után egyből profi lesz.

( talisker | 2013. 02. 04., h – 17:50 )

+sub
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Ajánlom figyelmedbe ezt is ... ha már :)
Benrinnes 1974 | 21 Year Old | Rare Malts Selection
60.4% - mennyei

Meg hát a "Classics": Oban, Glenkinchie, Cragganmore, Talisker, Dalwhinnie, Lagavulin
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Még mindig jobb, mint amikor void maint írnak, mert a 10 éves C++ könyvük azt mondta, mert turbó c-t használt.
A system pause-t én sem szeretem, mert nem a problémát oldja meg (ti. eltűnik a konzolablak), hanem workaround, amikor pedig simán meg is lehetne oldani (indítsd konzolból bmeg).
De legalább találkozik a kölök a system függvénnyel.
----
India delenda est.
Hülye pelikán

Azt nem mondanám, hogy platformfüggetlen, hiszen nincs garantálva, hogy any keyre a cin fog olvasni valamit, még enterre sincs garantálva, hogy a konzol azt oda fogja adni a cinnek. De lényegesen függetlenebb, mint bármilyen system hívás. Persze még mindig jobb lenne, ha a kezdő eleve IDÉtlenül programozna, mert C/C++ világban a fordítási modell megértése nélkül nagyon sokat lehet szívni, azt pedig IDE nélkül a legkönnyebb megtanulni.
----
India delenda est.
Hülye pelikán

( bogolyandras | 2013. 02. 05., k – 14:26 )

Halihó!
Milyen jellegű programnyelveket ismersz? C, C#, Java? Vagy esetleg a scriptnyelvekben vagy otthon?
Szerintem elég időigényes dolog megérteni a C++ -t azoknak, akik még nem foglalkoztak olyan programnyelvekkel, ahol ennyire figyelni kell a memóriakezelésre.
Bár ezzel nem elrettenteni akarlak e remek nyelv megismerésétől, de én úgy tudom, hogy kevés ember van, akinek pikk pakk sikerül elsajátítania.

A hőskorban és empatikusabb iskolákban ma is a deklarált statikus változós pascalos alapozás után zúdították/ják rá az érzékenyebb lelkű diákságra a heapkezelést a pontereivel (még mindig Pascalban), hogy miután ott készségszinten beivódott mindez, C-ben, mint szükséges alapismeretet használatba vehessék.