C/C++ programozás tanulása

Na OK, akkor linkelés:

Van egy library, mindegy, hogy statikus, vagy dinamikus, ami egy lefordított bináris cucc.
A library-hoz tartozik header file, ami gyakorlatilag felsorolja, hogy mik azok, amiket te kívülről látsz.

A programodba beincludeolod a headert, ezzel a fordítás rész lemegy.

Fordítás után az objekt fájlokból még valami futtathatót kell linkelned (ezt a gcc megcsinálja, akár egy parancsra is, de akkor is külön lépés).

Amikor linkelsz, akkor meg kell mondani, hogy melyik statikus libet (könyvtár.a), vagy dinamikus libet (könyvtár.so) akarod a programhoz linkelni.

Ha statikusan linkelsz egy objektumot, akkor abból amit a programod használ, azt hozzámásolja a végtermékhez, és amikor a programod fut, akkor a fájlon belül megtalálja.
Ha dinamikusan linkelsz, akkor csak eltárolja a fájlnevet, és amikor a programot elindítod, akkor a dinamikus linker megpróbálja megkeresni neked azt a fájlt, amit fordításkor adtál meg neki. Ha nem található, hibaüzenetet kapsz, ha megvan, betölti, és induláskor térképezi fel, hogy akkor az adott függvény hol található.

Ehhez neked program írása közben nem kell figyelned, mindegy, hogy a függvényt te írtad egy másik forrásfájlban vagy valaki más, és te csak a libet használod, a szintaktika ugyanaz.

Emellett még lehet futás közben is megnyitni dinamikus libet, és megkeresni benne szimbólumot, majd oda ugrani, de szerintem neked most nem ez kell. Ez akkor lehet érdekes, ha mondjuk menet közben betölthető és cserélhető modult készítesz, plugint, ilyesmit.

Ha jól emlékszem -- már régen volt --, akkor windows alatt void main()-el is lefordul a program.
Talán a szerző windows használt.

Jah, ez nekem is feltünt, de én int-et használtam mindig, az egyetemen így tanították és a szokás hatalma, amúgy jó kis könyv, nekem bejött.

Mert a szerző egy... khm.

Mondanám, hogy egy régi motoros, aki még Turbo C++-n szocializálódott, ami az akkor még nem alig létező szabványt sem támogatta.

Csak hát a könyv (utolsó?) kiadása 2003-as, alcíme meg az, hogy: "Az Ansi C++ tankönyve". Márpedig olyan C++ szabvány nincs, ami a void visszatérést engedi a main-ből.

Így inkább nem mondok a szerzőről semmit...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

sokan helytelenul void-oznak. errol van egy eleg jo iras: link

egyebkent meg senkinek nem ajanlom a 24 ora alatt programozzunk konyveket, semmilyen nyelven (mondjuk amit te irtal, ha jol emlekszem, nem 24 oras, de computerbook-os :))

---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering

Igazából majdnem mindegy, kb. ugyanazok vannak az összes kiadásban, maximum van amit szétbontott több tanácsra.

Az igazán új tanácsok a More Effective C++-ban vannak.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Szerintem Stroustrup könyve alap.

Egy baj van vele: nagyon tömör. (Igen, még így is 1000+ oldal. A C++ nehéz nyelv...)
Talán pont a Hatékony C++-ban van egy példa, miszerint a Stroustrup könyvben van egy egy soros komment egy példaprogramban, addig ugyanaz a téma a Meyers könyvben 4 oldal.

A Stroustrup könyv első könyvnek éppen ezért szerintem nem jó. Arra van kismillió másik könyv, én anno egy Computerbooks kiadványból kezdtem.

Ezután el lehet kezdeni használni (Qt, akármi).

Utána úgyis előjönnek olyan dolgok, amik nem világosak, vagy nem érhető miért pont úgy kell, stb. Ekkor jön a Stroustrup könyv, amiben szinte mindenre ott a válasz.

Ha csak gyors válasz kell valami C++-os problémára:
http://www.parashift.com/c++-faq-lite/index.html

Ha ezek után még tovább szeretnéd javítani a kódod minőségét, akkor jöhetnek azok a könyvek amiket ajánlottam.
Talán a Hatékony C++ olyan, amit előrébb lehet venni, mondjuk a Stroustruppal párhuzamosan. Ezekre úgyis azt ajánlják, hogy mindig azt olvasd el, ami éppen kell, ne az egészet egyvégtében.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Nalam meg egy pm-ben elkerheto.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

OK, ez esetben nem árt ismerni a GNU Autoconf - Automake rendszert és az M4 makrónyelvet. A nagyobb GPL-es projectek majdnem mind ezeket használják. Két projectet vittem végig ezekkel, de az a véleményem, hogy ha nem létszükséglet, akkor jobb, ha az ember valami mást próbál használni.
Build rendszerek közül nekem pl. scons jobban tetszett, az viszonylag egyszerű.
A vicc az, hogy mióta nagyobb projectekben veszek részt, kizárólag IDÉ-ket használunk, mert a hatékonyság nagyon fontos. Azóta szerencsére kezdem is autotools és scons dolgait elfelejteni.

...nem arról van szó, hogy nem értem meg az angol szöveget, hanem arról, hogy ha valamit félreértek, akkor rosszul tanulom meg. És ha létezik magyarul ilyen könyv, akkor miért ne használjam azt?
--
Azt akarom, hogy az emberek ne kényszerből tanuljanak, hanem azért, mert tudni akarnak.

Ma van akkor, ha az ember tud angolul, el is olvasott már néhány szakkönyvet ezen a nyelven, de mégis ötször olyan gyorsan olvas magyarul? Akko kell más okot találni, hogy belekössünk, vagy még mindig a szánalmas kategóriában van?

KisKresz

Szerintem jó könyv.
Jöhetne C++ nyelven is egy ilyen!

--
unix -- több, mint kód. filozófia.
Life is feudal

Arra lennék kíváncsi, hogy ez mennyire 'advanced', azaz, hogy az alap dolgoknál mennyivel mond többet? Például említi-e, hogy a definíciókat a kódblokk elejére kell tenni, ezért ha funkció hívása után szeretnénk új változót deklarálni, akkor új kódblokkot kell-e nyitni. Vagy hogy hogyan hozhatunk létre dinamikus tömböt? Vagy például mikor érdemes globális változókat használni? A lényeg, hogy nem 'Hogyan kezdjünk C programnyelven programozni' jellegű könyvet keresek, hanem valami hasonlót, mint Nyisztor Károly Gyakorlati C++ - rejtett lehetőségek, különleges megoldások c. könyve, ahol (hülyén fogalmazva) hacker-szinten ismertetik a nyelvet.
--
Azt akarom, hogy az emberek ne kényszerből tanuljanak, hanem azért, mert tudni akarnak.