A bejárók lényegében egy egységes felületet kívánnak nyújtani a különböző adatszerkezetekhez, hogy egyes algoritmusoknak ne kelljen tudnia, hogy például egy zsák adatszerkezet az most tömbösen vagy láncolt listásan lett-e vajon megvalósítva. Ugyebár miért is kéne tudnia? Bizonyos algoritmusoknál ez mindegy is.

A bejárókat meghatározott műveleteik alapján csoportosítani lehet (azt pedig, hogy milyen operátorok vannak definiálva, azt az határozza meg, hogy az egyes operátorok mennyire műveletigényesek - általában csak az alacsony műveletigényű funkciókhoz szokás operátort rendelni, a nagyobbakhoz pedig függvényt). Ez a standard template library-ban szépen meg is van téve, ám én erre a részre nem kanyarodnék rá, mivel egyrészt maga megérne jópár bejegyzést (az STL és az STL bejárókkal kapcsolatos része is), másrészt pedig nem szeretném ennyire elbonyolítani a helyzetet. Ezért a korábban már megírt láncolt lista adatszerkezetünkhöz fogok egy bejárót írni. Természetesen amennyire lehetséges tartom magam az STL-ben használt elnevezésekhez és ugyanazok az operátorok itt is ugyanazt a funkciót fogják betölteni (tehát visszakanyarodva az első "bejáró" meghatározásunkhoz, ez egy bejáró lesz, mert bejáróként fog viselkedni :) ).

Szerencsére az eredeti osztályunkat csak két függvénnyel kell kiegészíteni. Az egyik a begin(), ami egy, a lista elején álló bejáróval fog visszatérni. Az end() pedig a lista végén áll.

typedef cList_const_iterator<T> const_iterator;
typedef cList_iterator<T> iterator;

iterator begin(void)
{
    return *(new iterator(*(list->next)));
}
iterator end(void)
{
    return *(new iterator(*list));
}

A mutatók mintájára bejáróból is két fajtánk lesz, egy sima és egy konstans, ahogy az a fenti kódból is látszik. A typedef rész azért egy lényeges dolog (azon kívül, hogy a két függvényt egy csöppnyit szebbé és rövidebbé teszi), mert így cList<T>::iterator it; formában létre tudunk hozni egy cList<T>-beli bejárót (az STL is így viselkedik, ezért tartom magam ehhez). Na, jöhet az izgalmasabb része a dolognak, első körben a cList_iterator osztály:

template<class T> class cList_const_iterator;

template<class T> class cList_iterator
{
    private:
        listNode<T>* current_item;

        friend class cList_const_iterator<T>;
    public:
        cList_iterator(listNode<T>& value)
        {
            current_item = &value;
        }
        cList_iterator(const cList_iterator<T>& other)
        {
            current_item = other.current_item;
        }
        cList_iterator<T>& operator++()
        {
            current_item = current_item->next;
            return *this;
        }
        cList_iterator<T>& operator=(cList_iterator<T>& other)
        {
            this->current_item = other.current_item;
            return *this;
        }
        T& operator*()
        {
            return current_item->data;
        }
        bool operator==(const cList_iterator<T>& other)
        {
            return (current_item == other.current_item);
        }
        bool operator!=(const cList_iterator<T>& other)
        {
            return (current_item != other.current_item);
        }
};

Bár a cList_iterator-ral kezdünk, mégis előbb a cList_const_iterator-t kell egy sorban definiálni, az osztályban szereplő friend sor miatt (ami azért kell, hogy majd a const_iterator el tudja érni az iterator private adattagját (ami kell majd a copy konstruktorához, hogy lehessen cList_iterator-ból cList_const_iterator-t csinálni)). A dolog teljesen egyszerű egyébként, a current_item tárolja, hogy épp hogy vagyunk, lépdesni ugyanúgy lépdesünk vele, mint ahogy a láconlt lista kódjában is tettük. Akár a -- operátort is meg lehetne írni, mivel a listánk kétirányú volt. Érdemes még odafigyelni arra, hogy a * operátor referenciát ad vissza, tehát (ha minden igaz :D ) szerepelhet egyenlőség bal oldalán (a bejárón keresztül megváltoztatható az aktuális elem értéke). Második kör, a cList_const_iterator osztály. Csak azokat a funkciókat írom le, amivel bővült, illetve amik változtak (azt nem tekintem változásnak, hogy cList_iterator helyett csak cList_const_iterator-t kell írni):

template<class T> class cList_const_iterator
{
    private:
        const listNode<T>* current_item;
    public:
        cList_const_iterator(const cList_iterator<T>& other)
        {
            current_item = (const listNode<T>*)other.current_item;
        }
        T operator*()
        {
            return current_item->data;
        }
};

Az utolsó ami még hiányzik, az egy kis példakód, hogy mit is tudunk kezdeni ezzel a bejáróval, amit épp megírtunk. A lent látható kód a listán való végigmenés rövid, fájdalommentes, átlátható, bejárókat használó kódja:

cList<int> int_list;

int_list << 0 << 1 << 2 << 3 << 4 << 5 << 6 << 7 << 8 << 9;

for (cList<int>::const_iterator it = int_list.begin(); it != int_list.end(); ++it) {
    std::cout << *it << std::endl;
}
std::cout << "Lista vége" << std::endl;

Ennyit a saját készítésű bejárókról (az STL-ről meg talán a későbbiekben még egy nagyobb lélegzetvételű dolog születhet, ha úgy alakul - addig is ajánlott olvasmány a dologgal kapcsolatban a fentebb említett Nagy Könyv 19. fejezete). További jó iterálást mindenkinek.

% Prolog
% A léptetés miatt kétszer adom át a listát, egyéb segéd-
% függvényekkel lehet máshogy is de beépített függvények 
% nincsenek, csak tanítanak néhány alapot, de ezekre most
% nem térnék ki, és nem is alkalmazok.

pith(L,P):- getpith(L,L,P).

% Gyorsan leírom a listákat hogy tiszta legyen, alapvetően 
% kétféleképpen lehet listákat leírni, az első: [A,B], ez 
% egy két elemű lista, ami tulajdonképpen 3 elemű. Na ezt 
% adjátok össze :) szóval, az első, tehát az A az mindig az
% első elem, a B pedig egy másik kételemű lista, aminek első 
% eleme a B, a második eleme pedig a [], tehát az üres lista.
% A második típus a listáknál a [A|B] kinézetű, ez annyit 
% tesz, hogy A a lista első eleme, B pedig az utána lévő 
% összes többi. pl. ha ezt adjuk rá: [1,2,3,4,5] vagyis egy 
% 5 elemű listát akkor az A = 1, és a B = [2,3,4,5] vagyis 
% 4 elemű lista. Ezen kívül még egy elem látható, a '_', 
% ez minden karakter lehet, tehát ez egy olyan, amit 
% figyelmen kívül hagyunk. Ennyit a listák bevezetéséről :)
% A két listát máshogy dolgozom fel, az A,B,C a lista első 
% három eleme mindig. A második lista az első elemen kívül
% mindent tartalmaz, tehát a léptetést szolgálja a mi 
% esetünkben, de mint említettem erre már vannak kifinomultabb
% technikák is, de beépített függvény nincs. Ezen felül a P 
% a visszatérési érték. A ZH-ban egy struktúraként kellett 
% visszaadni a megtalált számhármast, ezért most egy kicsit 
% a struktúrákról is: A struktúrák abban különböznek a 
% függvényektől, hogy nincs testük, tehát pl. p(A,B,C). 
% Függvénynév, argumentumok, és egy '.' :)
% Még egy új elem, amit eddigi prolog tudásotok még nem 
% tartalmaz, hogy prologban az if-then-else így néz ki: 
% ( feltétel -> igaz ág ; hamis ág )

getpith([A,B,C|_],[_|D],P):-   % függvény kezdete 
   (                           % feltétel kezdete
   A > 0 ,                     % A,B,C > 0
   B > 0 , 
   C > 0 , 
   A < B ,                     % A < B < C
   B < C , 
   X is A*A+B*B,               % A*A+B*B=C*C - vizsgálat
   Y is C*C,                   %  előtt a kiértékelődés
   X = Y                       %  miatt két változót használok
   ->                          % igaz ág
   P = p(A,B,C)                % a 3 szám p struktúrában
   ;                           % hamis ág
   getpith(D,D,P)              % a következő 3 elem vizsgálata
   )                           % if-then-else vége
.                              % függvény vége

% Tömörebben: getpith([A,B,C|_],[_|D],P):- (A>0,B>0,C>0,A<B,B<C,X is A*A+B*B,Y is C*C,X=Y->P=p(A,B,C);getpith(D,D,P)).

% Használat: 
% pith([1,3,5,3,7,24,25,8,7],P).
% Várt eredmény:
% P = p(7,24,25)

SML-ben most hirtelen nem is tudom van-e comment, nem rémlik, hogy láttam volna, úgyhogy inkább ide írom, a hozzászólásokat :) Tehát SMLben máshogy működnek a listák, egy kicsit ezekről: a listák formailag ugyanolyanok, de a függvényekben másként lehet szétszedni őket, amint látható. Most n1 az első elem, n2 a második, n3 a harmadik, ns pedig az összes többi. Az operátor ami ezek között van op:: egy listába fűzi össze a tagokat, így a léptetés is jóval egyszerűbb, ahogy az else ágnál is látszik; szándékosan nem szedtem szét több sorba, mivel lényegében ugyanaz, mint a prolognál. A további különbségek, hogy itt normális if-then-else szerkezet van, csak ugye még a then-t is ki kell írni :) illetve az andalso a sima 'és' kapcsolatot hivatott jelképezni, and-jellel nem megy a dolog, próbáltam kettővel és hárommal is :D igazából hárommal jó lenne, csak akkor más formában kéne, de erről most nem beszélnék, így egyszerűbb. A prologgal ellentétben itt egy listát adunk vissza, mivel nincs olyan struktúra, mint prologban, és ide nem is kell külön X, és Y a másodfokú egyenlethez, mivel az '='-nél kiértékelődik a két oldal :) Még két újdonság lehet, a függvény végén a '| pith _ = []', ami azt jelenti, hogyha a legelső argumentumra nem illeszkedik a bemenet, akkor egy üres lista lesz az eredmény. Tehát ha n1::n2::n3::ns -re nem négyelemű lista jön, ami lehet 3 érték és egy üres elem, akkor átugrik a másik lehetőségre pith _ -ra, ahol a _ a prologhoz hasonlóan a bármit jelenti. Erről azt hiszem eleget is beszéltem. Aztán pedig a függvényhívást így is el lehet végezni, kicsit rövidebben, mint az SML bevezetőben írtam, tehát nem kell 'val x =' az elejére, ilyenkor azt kapjuk, hogy az 'it'-nek az eredménye amit kaptunk, magyarán, "valami pont annyi amennyi a függvény értéke" :D Az utolsó sor végén pedig láthatjuk hogy ez egy int lista.

fun pith(n1::n2::n3::ns) = ( if n1 > 0 andalso n2 > 0 andalso n3 > 0 andalso n1 < n2 andalso n2 < n3 andalso n1*n1+n2*n2=n3*n3 then [n1,n2,n3] else pith(n2::n3::ns)) | pith _ = [];
> val pith = fn : int list -> int list
pith([1,3,5,3,7,24,25,8,7]);
> val it = [7, 24, 25] : int list

/* C++ megvalósítás */
/* Ennek a működését remélem nem kell ecsetelnem :) próbáltam 
Prologhoz hasonlóan struktúrában visszaadni a pith() 
visszatérési értékét, azt hiszem eléggé jól látható, 
hogy mi is a prolog és sml pozitívuma cpp-vel ellentétben :) 
azt hiszem a listakezelésük egy csöppet veri a cpp-ét, 
legalábbis rövidségben, és hatékonyságban :) */

#include <iostream>

using namespace std;

struct p { int a,b,c; };

p pith(int a, int b, int c) {
   p tmp;
   tmp.a=0;
   tmp.b=0;
   tmp.c=0;
   if(a>0&&b>0&&c>0&&a<b&&b<c&&(a*a+b*b==c*c)) {
      tmp.a=a;
      tmp.b=b;
      tmp.c=c;
   }
   return tmp;
}

int main() {
   int listaelemek[8];
   listaelemek[0]=1;
   listaelemek[1]=3;
   listaelemek[2]=5;
   listaelemek[3]=3;
   listaelemek[4]=7;
   listaelemek[5]=24;
   listaelemek[6]=25;
   listaelemek[7]=8;
   p tmp;
   for(int i=0;listaelemek[i+2]!=0;i++) {
      tmp=pith(listaelemek[i],listaelemek[i+1],listaelemek[i+2]);
      if(tmp.a!=0) { 
         cout << "p(" << tmp.a << ",";
         cout << tmp.b << "," << tmp.c << ")"; 
         break; 
      }
   }
   return 0;
}

Annak idején én egy közlekedési példával lettem bevezetve a származtatás világába. Tegyük fel, hogy van egy személygépkocsi, egy tehergépkocsi, egy kamion, stb. osztályunk. Mindegyik osztályban van valami közös, például, hogy van kormánya, meg van X darab kereke. Ezek miatt a közös részek miatt érdemes őket egy bázisosztályból származtatni. Tehát legyen egy járművek osztályunk, amiben megvan minden közös tulajdonság, ami a járműveket jellemzi és minden egyediséget a belőle származtatott osztályokban valósítunk meg.

Ezzel sikerült elrugaszkodnunk eléggé a valóság talajáról - már ha ez esetben egyáltalán lehet erről beszélni. Térjünk hát át egy kézzel foghatóbb és egyszerűbben kódolhatóbb (mondhatni hétköznapi) problémára, melyet az A C++ programozási nyelv c. könyvben találtam. Tegyük fel, hogy valamilyen cég számára írunk egyfajta alkalmazott-nyilvántartó programot, ahol használunk valami ilyesféle típusokat:

struct Alkalmazott
{
	std::string vezeteknev;
	std::string keresztnev;
	int fizetes;
};

struct Osztalyvezeto
{
	Alkalmazott alk;
	std::set<Alkalmazott*> csoport;
};

Az Osztalyvezeto kódjából remekül látszik már így is, hogy az osztályvezető is egy alkalmazott, tehát nála is meg lehet/kell adni az alkalmazottaknál bevezetett mezőket. Viszont ennek a megoldásnak van egy olyan hatalmas hátránya, hogy az Osztalyvezeto típusokra nem használhatjuk azokat a függvényeket, amiket az Alkalmazott típusra írtunk. Több okból sem. Ebből az egyik, hogy például nem létezik Osztalyvezeto.fizetes tag, csak Osztalyvezeto.alk.fizetes. Ez talán még megoldható. De ha egy függvény egy Alkalmazott-ra mutató pointert vár, akkor nem adhatunk neki egy Osztalyvezeto-re mutató pointert. Ebben az esetben legalábbis nem. De ha így írjuk a dolgokat, akkor már igen:

struct Osztalyvezeto : public Alkalmazott
{
	std::set<Alkalmazott*> csoport;
};

Ez esetben az Osztalyvezeto osztályt származtattuk az Alkalmazott osztályból, így az Alkalmazott lett az Osztalyvezeto bázisosztálya, így rendelkezik minden tulajdonsággal, amivel az Alkalmazott rendelkezik, valamint Alkalmazott* típusú változónak értékül adhatunk Osztalyvezeto*-ot. Természetesen egy származtatott osztály is lehet bázisosztály így az Osztalyvezeto-ből származtathatjuk az Igazgato-t. Sőt, egy osztályt akár több bázisosztályból is származtathatunk. Az így létrejött kapcsolatrendszert szokás osztályhierarchiának nevezni és irányított gráffal lehet szépen szemléltetni, ahol a nyíl mindig a származtatott osztály felől mutat a bázisosztály felé.

A fenti példának is megvan az a hátránya, hogy ritkán szokás így használni, hogy csak adatszerkezet van függvények nélkül. A függvények behozatala némiképp megzavarja a képet, bár sok változás nem történik. Nézzük ezt a felállást:

class Alkalmazott
{
	private:
		std::string vezeteknev;
		std::string keresztnev;
		int fizetes;
	public:
		Alkalmazott(const std::string& vnev, const std::string& knev, const int& fiz) : vezeteknev(vnev), keresztnev(knev), fizetes(fiz) {}
		void print() const
		{
			std::cout << "Név: " << vezeteknev << " " << keresztnev << std::endl;
			std::cout << "Fizetés: " << fizetes << " Ft" << std::endl;
		}
};

class Osztalyvezeto : public Alkalmazott
{
	std::set<Alkalmazott*> csoport;

	public:
		Osztalyvezeto(const std::string& vnev, const std::string& knev, const int& fiz) : Alkalmazott(vnev, knev, fiz) {}
		void print() const
		{
			Alkalmazott::print();

			std::cout << "Csoport:" << std::endl;
			
			for (std::set<Alkalmazott*>::iterator current = csoport.begin(); current != csoport.end(); ++current) {
				(*current)->print();
			}
		}
};

Ami először feltűnik, hogy felülírjuk a már létező print() függvényt a származtatott osztályban (meg belecsempésztem mindkét osztályba egy-egy konstruktort, hogy tudjak működő példát adni pár sorral lejjebb). Ugyanakkor a felülírott függvényt is meghívjuk, ugyanis másként nem tudnánk kiírni a vezeteknev, keresztnev, fizetes mezőket, mivel ezek az Alkalmazott osztály private mezői, tehát csak az Alkalmazott osztályon belül érhetőek el. Ha a bázisosztály private mezője úgy viselkedne a származtatott osztályban, mintha a származtatott osztály sajátja lenne, akkor a private értelmét vesztené, ugyanis bármilyen private mező feloldható lenne egy egyszerű származtatással.

Viszont akármennyire is hihetetlennek tűnhet, de már ez az egyszerű print() utasítás is hordoz magában hibákat. Gondoljuk csak meg, hogy mit csinálhat az alábbi kód:

int main()
{
	Alkalmazott alk("Iksz", "Ipszilon", 150000);
	Osztalyvezeto oszt("Adsf", "Jklé", 350000);

	Osztalyvezeto* osztp;
	osztp = &oszt;

	Alkalmazott* alkp;
	alkp = &oszt;

	alkp->print();
}

Mire számítunk? Természetesen arra, hogy kétszer egymásután ugyanazt olvashatjuk a képernyőn. Ennek ellenére nem ez fog történni, mivel az Alkalmazott* nem tud arról, hogy az Osztalyvezeto objektum felülírta az eredeti print()-et. Vagyis igazából nem is tud az Osztalyvezeto létezéséről, ezért az eredeti, Alkalmazott-ban megadott print()-et hívja meg. Ezt most csúnyán megszívtuk, gondolhatná a kedves olvasó, mivel mi értelme van, hogy Alkalmazott*-nak értékül adhatunk Osztalyvezeto*-ot is, ha nem tudjuk használni az Alkalmazott*-on keresztül az Osztalyvezeto által felüldefiniált függvényeket? De szerencsére van megoldás a virtuális függvények személyében.

class Alkalmazott
{
	/* ... */
	public:
		/* ... */
		virtual void print() const
		{
			std::cout << "Név: " << vezeteknev << " " << keresztnev << std::endl;
			std::cout << "Fizetés: " << fizetes << " Ft" << std::endl;
		}
};

Azzal, hogy a print megadása elé tettünk egy virtual szócskát, jeleztük, hogy az adott függvényt a származtatott osztályokban felül lehet bírálni, így egy Alkalmazott* esetén a virtuális függvény megfelelő példánya fog meghívódni. Egy osztálynak lehetnek tisztán virtuális (pure virtual) függvényei is, vagyis a bázisosztályban nem adunk meg semmiféle megvalósítást és a függvényt (maradva a print példájánál) így deklaráljuk:

class Alkalmazott
{
	/* ... */
	public:
		/* ... */
		virtual void print() const = 0;
		virtual ~Alkalmazott() {}
};

Így az osztályunkat nem lehet példányosítani (fordítási idejű hibát generál), mivel egy függvénye nincs megvalósítva. Az ilyen osztályokat hívjuk absztrakt osztályoknak. Az absztrakt osztályokat felületként (interface) vagy más osztályok bázisosztályaként tudjuk használni. Egy pure virtual függvényt ha a származtatott osztályban nem adunk meg, akkor pure virtual marad ebből következik, hogy a származtatott osztály is absztrakt osztály lesz. Emellett az absztrakt osztályhoz virtuális destruktor is jár, hogy biztosítsuk a származtatott osztályunk utáni rendrakást.

Ezzel az objektum-orientált C++ világába bevezető sorozat befejező epizódjának végére értünk. Remélem mindenkire ragadt valami a bejegyzések olvasása közben. Sok sikert a gyakorlati alkalmazáshoz.

Tehát akkor egy kis kód:

#include <iostream>
#include <string>
#include <libpq-fe.h>

int main()
{
	// kapcsolódáshoz szükséges adatok
	const std::string	conninfo = "host=localhost port=5432 dbname=polaa user=polaa password=";
	// a kapcsolatmutató
	PGconn			*conn;
	// az eredménymutató
	PGresult		*res;

	/* kapcsolódás */
	conn = PQconnectdb(conninfo.c_str());
	if (PQstatus(conn) != CONNECTION_OK) 
	{
		std::cout << "Kapcsolódási hiba: " << PQerrorMessage(conn) << std::endl;
		PQfinish(conn);
		return 1;
	}
	
	/* ... */
}

Először is be kell vezetnünk néhány elengedhetetlen változót. Az adatbázishoz a PGconn *PQconnectdb(const *conninfo) függvénnyel kapcsolódhatunk hasonló módon, mint PHP-ban. A következő ellenőrzés szerintem magáért beszél.
A ConnStatusType PQstatus(const PGconn *conn) függvénnyel a kapcsolat aktuális állapotáról kaphatunk információt.
A void PQfinish(const PGconn *conn) függvény szerepe, hogy lezárja a kapcsolatot és felszabadítsa a PGconn által lefoglalt memóriát.

/* ... */
int main()
{
	/* ... */

	/* parancs */
	res = PQexec(conn, "INSERT INTO teszt VALUES (5, 10)");
	if (PQresultStatus(res) != PGRES_COMMAND_OK)
	{
		std::cout << "Parancsvégrehajtási hiba: " << PQerrorMessage(conn) << std::endl;
		PQclear(res);
		PQfinish(conn);
		return 1;
	}
	PQclear(res);
	
	/* ... */
}

A következő fontos függvény a PGresult *PQexec(PGconn *conn, const char *query), mely egy kérést küld a szervernek és egy Pgresult-ban tárolja az eredményt.
Ezt az eredményt a ExecStatusType PQresultStatus(const PGresult *res) függvénnyel ellenőrizhetjük.
A PGresult által lefoglalt memóriát a void PQclear(const PGresult *res) függvénnyel szabadíthatjuk fel. Fontos minden alkalommal meghívni, hogy még véletlenül se maradjon memória szemét hátra a programunk után.

/* ... */
int main()
{
	/* ... */

	/* lekérdezés */
	res = PQexec(conn, "SELECT * FROM teszt");
	if (PQresultStatus(res) != PGRES_TUPLES_OK)
	{
		std::cout << "Lekérdezés hiba: " << PQerrorMessage(conn) << std::endl;
		PQclear(res);
		PQfinish(conn);
		return 1;
	}
	/* lekérdezés feldolgozása */
	int rowNum, fieldNum;
	int i, j;

	rowNum		= PQntuples(res);
	fieldNum	= PQnfields(res);

	for (i = 0; i < fieldNum; i++)
	{
		std::cout << PQfname(res, i) << "\t";
	}
	std::cout << std::endl;

	for (i = 0; i < rowNum; i++)
	{
		for (j = 0; j < fieldNum; j++)
		{
			std::cout << PQgetvalue(res, i, j) << "\t";
		}
		std::cout << std::endl;
	}
	PQclear(res);

	PQfinish(conn);
	return 0;
}

A bemutató forrás végére hagytam a lekérdezést. Az eredménytáblában történő navigálást számos függvény könnyíti meg.
A sorok, illetve oszlopok számát az int PQntuples(const PGresult *res), illetve az int PQnfields(const PGresult *res) függvények adják vissza.
Az egyes oszlopok nevét a char *PQfname(const PGresult *res, int field_num) adja meg az oszlop indexe alapján (ami természetesen 0-ról indul). Az egyes mezők tartalmát a char *PQgetvalue(const PGresult *res, int tup_num, int field_num) függvény adja meg a PQfname-hez hasonló módon.

Ezekkel az alapfüggvényekkel már nyugodtan lehet kisebb-nagyobb adatbázis műveleteket végezni. Az objektum-orientált megoldást majd egy következő bejegyzésben részletezem.
A fenti kódot csak windowson próbáltam, mert csak. Fontos megjegyezni, hogy ott a lefordult exe mellé a következő dll-eket kell másolni még a PgSql-ünk bin nevü könyvtárából: comerr32.dll, krb5_32.dll, libiconv-2.dll, libintl-2.dll, libpq.dll.

Ilyen megközelítésben természetesen eléggé használhatatlannak bizonyul a kódunk, mert csak arra az egy típusra működik megfelelően. Még szerencse, hogy itt vannak a sablonok, amikkel ez a probléma relatíve egyszerűen áthidalható.

Bevezetésnek kezdjünk valami egyszerű függvénnyel, mondjuk amivel össze tudunk adni mindenféle objektumot, aminek meg van adva a + operátora (tény, hogy a példa cseppet értelmetlen, de mondjuk gondoljunk akkor egy sort() függvényre, aminek végülis mindegy, hogy milyen adatokat hasonlít össze, amíg annak az adatszerkezetnek megvan a < vagy > operátora).

#include <string>
#include <iostream>

template<class T> T Add(const T& o1, const T& o2)
{
    return o1 + o2;
}

int main()
{
    int i1 = 1;
    int i2 = 2;
    int i3 = Add(i1, i2);
    std::cout << i3 << std::endl;

    std::string s1 = "abc";
    std::string s2 = "xyz";
    std::string s3 = Add(s1, s2);
    std::cout << s3 << std::endl;
}

Ennyi az egész, tulajdonképpen csak a választott függvényünk elé tesszük, hogy template<class T> és mindenhol, ahol egyébként mondjuk int-et írtunk volna, ott T-t használunk. Hasonló a helyzet az osztályok esetében is, nézzük először a már megírt cList.h fájlunk sablonosított változatát.

#ifndef __CLIST_H__
#define __CLIST_H__

template<class T> struct listNode
{
    listNode<T> *prev;
    listNode<T> *next;
    T data;

    listNode()
    {
        next = prev = this;
    }
    listNode(const T& num)
    {
        next = prev = this;
        data = num;
    }
};

template<class T> class cList
{
    private:
        listNode<T>* list;

        void Create(void);
        void Destroy(void);

        void Remove(listNode<T>* target);
        listNode<T>* Get(listNode<T>* target);
    public:
        cList(void);
        cList(const cList<T> &other);
        ~cList(void);

        class E_OUTOFMEMORY {};
        class E_INVALIDITEM {};

        void left_insert(listNode<T>* target, listNode<T>* data);
        void right_insert(listNode<T>* target, listNode<T>* data);
        listNode<T>* get_first(void);
        listNode<T>* get_last(void);
        listNode<T>* Search(const T& number);

        cList<T>& operator+(const cList<T>& other);
        cList<T>& operator=(const cList<T>& other);
        cList<T>& operator>>(T& number);
        cList<T>& operator>>(listNode<T>* pointer);
        cList<T>& operator<<(const T& number);
        cList<T>& operator<<(listNode<T>* pointer);
};

Pár <T>-től talán még megszabadulhatnánk, ha a listNode osztályt a cList osztályon belül adnánk meg, de most már mindegy (egy kis gyakorlás gyanánt mindenki megcsinálhatja magának). Most, hogy volt egy kis szünet, mindenki kifújta magát, visszatérhetünk az osztály metódusainak kibontogatására (maradunk a cList.h-ban):

template<class T> void cList<T>::Create(void)
{
    list = new listNode<T>();
    if (!list) throw E_OUTOFMEMORY();
 
    list->next = list;
    list->prev = list;
    return;
}

template<class T> void cList<T>::Destroy(void)
{
    while (list->prev != list) {
        Remove(list->prev);
    }
    return;
}

template<class T> void cList<T>::Remove(listNode<T>* target)
{
    listNode<T>* tmp = Get(target);
    delete tmp;
    return;
}

template<class T> listNode<T>* cList<T>::Get(listNode<T>* target)
{
    target->prev->next = target->next;
    target->next->prev = target->prev;
    target->prev = target;
    target->next = target;
    return target;
}

template<class T> cList<T>::cList(void)
{
    Create();
}

template<class T> cList<T>::cList(const cList<T>& other)
{
    Create();
 
    listNode<T>* tmp = other.list->next;
    while (tmp != other.list) {
        listNode<T>* node = new listNode<T>(tmp->data);
        if (!node) throw E_OUTOFMEMORY();
 
        this->left_insert(this->list, node);
        tmp = tmp->next;
    }
}

template<class T> cList<T>::~cList(void)
{
    Destroy();
    delete list;
}

template<class T> void cList<T>::left_insert(listNode<T>* target, listNode<T>* data)
{
    data->prev = target->prev;
    data->next = target;
    target->prev->next = data;
    target->prev = data;
    return;
}
template<class T> void cList<T>::right_insert(listNode<T>* target, listNode<T>* data)
{
    data->prev = target;
    data->next = target->next;
    target->next->prev = data;
    target->next = data;
    return;
}

template<class T> listNode<T>* cList<T>::get_first(void)
{
    if (list->next == list) throw E_INVALIDITEM();
    return Get(list->next);
}
template<class T> listNode<T>* cList<T>::get_last(void)
{
    if (list->prev == list) throw E_INVALIDITEM();
    return Get(list->prev);
}

template<class T> listNode<T>* cList<T>::Search(const T& number)
{
    listNode<T>* tmp = list->next;
    while (number != tmp->data && tmp != list) {
        tmp = tmp->next;
    }
    if (tmp == list) throw E_INVALIDITEM();
    return tmp;
}

template<class T> cList<T>& cList<T>::operator+(const cList<T>& other)
{
    listNode<T>* tmp = other.list->next;
    while (tmp != other.list) {
        listNode<T>* node = new listNode<T>(tmp->data);
        if (!node) throw E_OUTOFMEMORY();
 
        this->left_insert(this->list, node);
        tmp = tmp->next;
    }
}
template<class T> cList<T>& cList<T>::operator=(const cList<T>& other)
{
    if (this == &other) return *this;
    this->Destroy();
 
    listNode<T>* tmp = other.list->next;
    while (tmp != other.list) {
        listNode<T>* node = new listNode<T>(tmp->data);
        if (!node) throw E_OUTOFMEMORY();
 
        this->left_insert(this->list, node);
        tmp = tmp->next;
    }
    return *this;
}

template<class T> cList<T>& cList<T>::operator>>(T& number)
{
    number = get_last()->data;
    return *this;
}
template<class T> cList<T>& cList<T>::operator>>(listNode<T>* pointer)
{
    pointer = get_last();
    return *this;
}
 
template<class T> cList<T>& cList<T>::operator<<(const T& number)
{
    listNode<T>* tmp = new listNode<T>(number);
    if (!tmp) throw E_OUTOFMEMORY();
 
    left_insert(list, tmp);
    return *this;
}
template<class T> cList<T>& cList<T>::operator<<(listNode<T>* pointer)
{
    left_insert(list, pointer);
    return *this;
}

#endif

Nincs más hátra, mint egy megfelelő main.cpp-vel tesztelni ezt a rengeteg kódot, hogy egyáltalán működik-e ez az egész:

#include <string>
#include <iostream>

#include "cList.h"

int main()
{
        cList<int> list1;
        list1 << 1 << 2 << 3 << 4 << 5;
        int num;
        list1 >> num;
        std::cout << num << std::endl;

        cList<char> list2;
        list2 << 'a' << 'b' << 'c' << 'd' << 'e';
        char chr;
        list2 >> chr;
        std::cout << chr << std::endl;

        cList<std::string> list3;
        list3 << "alma" << "barack" << "citrom" << "dinnye" << "eper";
        std::string str;
        list3 >> str;
        std::cout << str << std::endl;
}

A fenti kód lefordítása majd futtatása után keletkezett kimenet legjobb esetben az, hogy 5, e, eper (mindegyik új sorban). Ezzel a sablonizációs bejegyzés végére is értünk, a legközelebbi alkalommal származtatni fogunk, ha a C++ istenei is így akarják.

Felhasználói felület

Mint ahogy már az első bejegyzésben is elmeséltem, a private és public blokkok tárgyalásánál, a felhasználói felület jó dolog, mivel megszabhatjuk vele, hogy a felhasználó milyen módon férhet hozzá az objektum adataihoz, milyen módon használhatja magát az osztályt. Kezdjük a sort a már annyiszor emlegetett left_insert()-tel:

void cList::left_insert(listNode* target, listNode* data)
{
    data->prev = target->prev;
    data->next = target;
    target->prev->next = data;
    target->prev = data;
    return;
}

Jaj, de jó. Ismét egy szép hosszú sor mutató állítgatás. Lehet sejteni, hogy mi is fog következni. Igen, rajzolni fogok. Vagyis már rajzoltam, az eredmény itt jobbra látható a zagyvaságom mellett (stílusosan, mivel ez egy balos beillesztés).
Kis képmagyarázat mielőtt belevágnánk: minden két sor egy-egy sort valósít meg a kódból (a függvény megadását, a return; utasítást és a lezáró zárójelet kihagyva). A jobb felső elem, amihez képest balra szúrjuk be a jobb alsó elemet. Tehát, az első két (kód)sorban csak annyit csinálunk, hogy a beszúrandó listaelem két mutatóját (először a hátrafelé, aztán az előrefelé mutatót) ráállítjuk a célelem előtti elemre, illetve magára a célelemre. Aztán jön az izgi rész, amikor is megbontjuk magát a listát, és befűzzük az elemünket. Először a célelem visszafelé mutatója által mutatott objektum előrefelé mutató mutatóját állítjuk rá a befűzendő elemre, majd a célelem visszafelé mutatóját.
Figyelem! A képen ez a két lépés (szándékosan) fel van cserélve, hogy rajzolási szempontból könnyebb legyen ábrázolnom a dolgot (így nem kellett kereszteznem két mutatót, ami még átláthatatlanabbá tenné az ábrát).

Huhh, haladunk ezerre. Következhet a right_insert(), ami nem okoz majd túl nagy meglepetéseket, ezért különösebb kommentárt nem is fűznék hozzá (igen, képet sem, szóval mindenki megkönnyebbülhet), beszéljen inkább a kód, meg talán az előző magyarázat/kép hatására egyértelmű is lesz a dolog:

void cList::right_insert(listNode* target, listNode* data)
{
    data->prev = target;
    data->next = target->next;
    target->next->prev = data;
    target->next = data;
    return;
}

Semmi meglepő, semmi meghökkentő. Jöjjön két függvény, amivel adatokat szedhetünk ki a listából ("név" szerint az első és az utolsó elemet):

listNode *cList::get_first(void)
{
    if (list->next == list) throw E_INVALIDITEM();
    return Get(list->next);
}
listNode* cList::get_last(void)
{
    if (list->prev == list) throw E_INVALIDITEM();
    return Get(list->prev);
}

Ismét látható, hogy mennyire hasznos tud lenni a kétirányú, ciklikus fejelemes lista. Rosszabb esetekben kénytelenek lennénk végigmenni az egész listán, hogy az utolsó elemet ki tudjuk szedni. Vagy kivételként kellene kezelni az utolsó elemet, mert a mutatója (vagy az egyik mutatója) nullpointer. De szerencsére nem kell, így meg is vagyunk a dologgal. Ezekkel az eszközökkel már nagyjából tudunk mit kezdeni a listával, de a felület a megvalósítandó feladattól függően változhat. Minden esetre én még írtam bele egy Search() függvényt is, biztos ami biztos:

listNode* cList::Search(const int& number)
{
    listNode* tmp = list->next;
    while (number != tmp->data && tmp != list) {
        tmp = tmp->next;
    }
    if (tmp == list) throw E_INVALIDITEM();
    return tmp;
}

A keresett elemre mutató mutatóval tér vissza, vagy egy kivételt dob, ha nem találja a megadott elemre. Nem egy lényeges dolog, főleg ha szükség sincs rá, mindenesetre sok vizet nem zavar. Jöjjön valami - relatíve - izgalmasabb dolog: újra operátorokat fogunk írni.

Lista operátorok

Mint azt az általános operátoros leírásnál említettem, mindig törekedjünk arra, hogy az operátor valami rá jellemző dolgot hajtson végre. Extrém példaként felhozhatnám azt, hogy mondjuk a - operátort és a + operátort a komplex számoknál felcseréli valaki. Szegény programozó, aki meg akarja használni az objektumot, csak les, hogy mi a fene van. Persze mindenki azt csinál, amit akar, de nem árt az ilyen íratlannak mondható "szabályokra" is ügyelni.

Elsőként a + operátor segítségével fogunk két listát összefűzni. A kód igazából nem olyan hatékony, mint amilyen lenni tudna. Ha például a másik objektumra nem lenne szükségünk, akkor egyszerűen a mi objektumunk végét megbontanánk és hozzácsatolnánk a másik objektumot, vigyázva arra, hogy a fejelemet ne vegyük bele a játékba. Így se lesz sokkal bonyolultabb, csak végigmegyünk a másik objektumon, és szépen hozzáadogatjuk a listánk végére az elemeket (hasonlít egy picit a dolog a copy konstruktorhoz):

cList& cList::operator+(const cList& other)
{
    listNode* tmp = other.list->next;
    while (tmp != other.list) {
        listNode* node = new listNode(tmp->data);
        if (!node) throw E_OUTOFMEMORY();

        this->left_insert(this->list, node);
        tmp = tmp->next;
    }
}

Következőnek jöhet az egyenlőség operátor. Működését tekintve csak annyit, hogy először kiürítjük a listát, majd a másik lista elemeit átmásoljuk a mi listánkba (copy konstruktorhoz és a + operátorhoz hasonlóan). Az első feltétel meg azért szükséges, hogy ha saját magát adjuk értékül a listának, akkor abból se legyen para.

cList& cList::operator=(const cList& other)
{
    if (this == &other) return *this;
    this->Destroy();

    listNode* tmp = other.list->next;
    while (tmp != other.list) {
        listNode* node = new listNode(tmp->data);
        if (!node) throw E_OUTOFMEMORY();

        this->left_insert(this->list, node);
        tmp = tmp->next;
    }
    return *this;
}

Már csak két operátor van, amit meg fogok valósítani, a << operátor és párocskája a >>. Lényegi haszna nem lesz egyiknek sem, tulajdonképpen csak hasznos álnevekként funkcionálnak majd a végére beszúrás és az utolsó elem kiszedése számára.

cList& cList::operator>>(int& number)
{
    number = get_last()->data;
    return *this;
}
cList& cList::operator>>(listNode* pointer)
{
    pointer = get_last();
    return *this;
}

cList& cList::operator<<(const int& number)
{
    listNode* tmp = new listNode(number);
    if (!tmp) throw E_OUTOFMEMORY();

    left_insert(list, tmp);
    return *this;
}
cList& cList::operator<<(listNode* pointer)
{
    left_insert(list, pointer);
    return *this;
}

A két plusz függvény tényleg csak a kódot teszi szemléletesebbé, átláthatóbbá. Bár ez a két dolog sosem lehet "csak" tényező. Legalább is nekem mindig fontos volt, hogy két-három hónap után is tudjam, hogy mit csinál az általam írt kód, és ezt eddig a Perl kivételével minden nyelvben sikerült is megtennem. :)
Pár példa a használatra:

cList lista;
lista << 6 << 7 << 1 << 12 << 23;
int szam;
lista >> szam;

Amint az látszik is, eléggé szemléletes. Először a 6-ot, 7-et, 1-et, 12-t, 23-at beletesszük a listába, majd kiszedjük az utolsó elemet (vagyis a szam értéke a végén 23 lesz).

Ezzel végére is értünk a mai napra rendelt dolgoknak. A sablonok ismét a csúszás áldozatává válnak, cserében viszont senki mással nem kell megosztaniuk majd a következő - szám szerint az ötödik - bejegyzést. Addig is további jó próbálkozást.

Az első képen gyönyörűen látszik a tömb (felül) és a láncolt lista (alul). Mi is a gondunk a szimpla tömbbel? Csak fix méretben foglalhatjuk le. Annyira fix méretben, hogy már a fordításkor tudnunk kell, hogy mekkorát szeretnénk. De ez csak egy gond. Egy másik gond, hogy ha nem egy szimpla int-et vagy hasonlóan egyszerű objektumot, hanem valami szép nagy dolgot pakolunk bele, és azt szeretnénk rendezni, az ugye nem kis erőforrásigényű, ahogy cserélgeti az objektumokat a memóriaterületen, hogy sorban legyenek. Perszer erre lehet azt mondani, hogy a kriz az hülye, mert miért nem objektumokra mutató mutatókból csinál tömböt, és akkor csak a mutatókat kell mozgatnia. No igen, ez egy fokkal jobb ötlet, és azt a problémánkat is megolja, hogy fordítási időben kell tudnunk a tömb méretét. Elég a tömb lefoglalásakor akár dinamikusan egy változóban tudni a méretet. A probléma még mindig probléma, hogy ha azt a fix méretet túllépjük, akkor az gáz.

Itt jön a képbe a láncolt lista. A szerkezet lényege, hogy egy listaelem egy adatrészből és egy mutatórészből áll. Pontosítok: egy listaelem egy adatrészből és legalább egy mutatórészből áll. Miért jó ez? Egyrészről azért, mert a listaelemeket dinamikusan, a futási idő alatt foglalgatjuk le, felső határ csak a memória mérete, nem pedig egy előre meghatározott szám. Másrészről pedig itt is megvan az az előny, hogy csak a pointereket kell új címre állítani ahhoz, hogy rendezni tudjuk a listánkat. Izgi, mi? :)

Hogy ne legyen ilyen egyszerű a helyzet, mi egy fejelemes, kétirányú, ciklikus láncolt listát fogunk csinálni. ez azt jelenti, hogy a listaelemben két mutató van, amiből az egyik az előző, a másik a következő elemre fog mutatni (ezért kétirányú), a lista első eleme nem tartalmaz adatot, az csak azért van hogy az első elem beszúrása és az utolsó elem törlése jóval könnyebb legyen (tehát fejelemes) és az utolsó elem "következő elem" mutatója nem nullpointer, hanem a fejelemre mutat (ugyanígy a fejelem "előző elem" mutatója az utolsó elemre mutat). Kezdjük talán a dolog egyszerűbb végénél, a listaelem szerkezetének a megvalósításánál:

struct listNode
{
    listNode* prev;
    listNode* next;
    int data;

    listNode()
    {
        next = prev = this;
    }
    listNode(const int& num)
    {
        next = prev = this;
        data = num;
    }
};

Csoddálatos. Értelem szerűen van egy prev mutató az előző elemre, egy next mutató a következő elemre és egy data, amiben az adatokat tároljuk. Itt az ideje, hogy magának a listának is nekiálljunk. A dolog végtelenül egyszerű, szükségünk lesz egy listNode* változóra, ami "tartani" fogja a lista fejelemét, egy befűző és egy kifűző függvényre, amivel új elemeket szúrhatunk be, illetve létezőket vehetünk ki.

class cList
{
    private:
        // A lista fejelemére mutató pointer
        listNode* list;

        // Üres lista létrehozása
        void Create(void);

        // Lista kiürítése
        void Destroy(void);

        // target című elem törlése
        void Remove(listNode* target);

        // target című elem kifűzése
        listNode* Get(listNode* target);
    public:
        // Konstruktor
        cList(void);

        // Copy Konstruktor
        cList(const cList& other);

        // Destruktor
        ~cList(void);

        // Kivétel osztályok
        class E_OUTOFMEMORY {};
        class E_INVALIDITEM {};

        void left_insert(listNode* target, listNode* data) {}
};

Ennyi egyenlőre elég is lesz, bár az objektum kezelőfelülete még a tervezés szintjén sincs kész (a left_join()-t leszámítva, ami csak azér került bele (üresen), hogy leforduljon a kód, majd a negyedik részben lesz rendesen kifejtve), de azzal ráérünk később is foglalkozni. Kezdjük akkor sorban a megvalósítást, először a Create() függvénnyel, ami létrehozza az üres listát (amiben csak a fejelem van).

void cList::Create(void)
{
    list = new listNode();
    if (!list) throw E_OUTOFMEMORY();

    list->next = list;
    list->prev = list;
    return;
}

A cList:: előtag annak köszönhető, hogy az osztály definícióján kívül van megvalósítva a függvény. Gondolom nem annyira ismeretlen eljárás ez. Az objektum szerkezete megy a fejelembe (.h vagy .hpp), a többi meg az ugyanolyan nevű .cpp fájlba. Áttérhetünk a Destroy() függvényre, ami a fejelemen kívül minden elemet töröl a listából.

void cList::Destroy(void)
{
    while (list->prev != list) {
        Remove(list->prev);
    }
    return;
}

Rettentő cselesen a Remove() függvényt használtam a dologhoz, így tulajdonképpen egyesével kifűzve az összes elemet a listából, mígnem a fejelem prev mutatója meg nem egyezik a lista fejelemének a címével. Ahogy illik, a Remove() megvalósításával folytatom a sort. Lassan, de biztosan közeledünk a vége felé... :)

void cList::Remove(listNode* target)
{
    listNode* tmp = Get(target);
    delete tmp;
    return;
}

Ismét továbbadjuk a dolog megvalósítását egy másik függvénynek, a Get()-nek, ami így is, úgy is kifűzi az elemet, akkor miért ismételnénk meg ugyanazt a kódot még egyszer a Remove()-ban is? Tehát, a Get()-tel kifűzetjük, majd a kapott elemet töröljük. Nna, nézzük azt a Get()-et, ha már egyszer ennyi minden épül rá:

listNode* cList::Get(listNode* target)
{
    target->prev->next = target->next;
    target->next->prev = target->prev;
    target->prev = target;
    target->next = target;
    return target;
}

Nos, ez egy nem egyszerű dolog. Igazából egyszerű, csak leírni lenne túl bonyolult, inkább veszem a bátorságot és rajzolok egy ábrát hozzá. Egy "jó" ábra felér egy bekezdésnyi szöveggel. Mindenesetre az ábrát is megmagyarázom inkább. Fő a biztonság. Szóval, a kép első sorában az alaphelyzetet látjuk. A második sor a függvény első sorának hatását hivatott szemléltetni, azaz a kifűzendő listaelem előtti elemnek a következő elemre mutató mutatóját átállítjuk a kifűzendő elem utáni elemre. A kép harmadik sorának lényege ugyanez, csak fordítva, mivel a kifűzendő elem utáni elem előző elemre mutató mutatóját állítjuk a kifűzendő elem előtti elemre. Így a lista maga már nem függ a kifűzendő elemtől, mindenesetre a biztonság kedvéért a két mutatóját saját magára állítjuk (a függvény utolsó két mutató állítása). Végül visszatérünk a kifűzött elem mutatójával. Ezzel le is tudtuk az objektum private részét, jöhet a public:

cList::cList(void)
{
    Create();
}

Egyszerűbb nem is lehetne, csak a Create()-et hívjuk, meg hogy legyen egy üres listánk. Nézzük a copy konstruktort:

cList::cList(const cList& other)
{
    Create();

    listNode* tmp = other.list->next;
    while (tmp != other.list) {
        listNode* node = new listNode(tmp->data);
        if (!node) throw E_OUTOFMEMORY();

        this->left_insert(this->list, node);
        tmp = tmp->next;
    }
}

Lényegében az értékül adott listán végigmegyünk és egyesével beszúrjuk az elemeit a saját listánkba. Mint említettem annak idején, a copy konstruktor fontos dolog. Gondoljunk csak bele, hogy mi történne akkor, ha nem írnánk sajátot. Az objektum változóinak értéke szépen átmásolódna. Tehát ha B objektumnak adjuk kezdőértékül A objektumot, akkor B objektum list változója ugyanoda fog mutatni, mint az A objektum list változója, tehát ha az A objektumot megszüntetjük, akkor a B objektum tulajdonképpen a "semmibe" fog mutatni. De ha B objektum listáján változtatunk (kifűzünk, befűzünk), akkor A objektum listája is változik.
A left_insert() az első paraméterként kapott pointer által mutatott listaelemhez képest balra fűz be egy elemet. Mivel esetünkben a lista fejelemét kapja meg a függvény, és mivel a lista fejelemének bal oldalra mutató mutatója (azaz a prev) a lista utolsó elemére mutat, ez azt jelenti, hogy a lista végére fűzzük be az elemet. Jöjjön végül, de nem utolsó sorban a destruktor:

cList::~cList(void)
{
    Destroy();
    delete list;
}

Nem meglepő módon a destruktor (ami ugyebár a konstruktor úgymond ellentéte, és akkor fut le, amikor az objektum megszűnik) a Destroy() függvénnyel kiüríti a listát, majd a list változó segítségével megszünteti a fejelemet is.
Asszem ennyi elég is lesz mára. Az objektum felhasználói felületét (a public függvények, mint például a left_insert()) és néhány operátort a következő részben fogunk megírni, és ha nem nyúlik túl hosszúra a dolog (mint ahogy most), akkor végre a sablonokat is kitárgyaljuk.

A mai terv első körben a Complex objektum szorzásának (operator*) és az összehasonlító operátornak (operator==) megvalósítása és a komplex számunk megjelenítése valamiféleképpen a képernyőn. Az első két dologgal nem lesz túl sok gondunk az előző rész alapján. Csak két új függvénnyel kell bővítenünk az objektumot:

Complex operator*(const Complex& num)
{
    return Complex(re*num.re - im*num.im, re*num.im + im*num.re);
}

bool operator==(const Complex& num) const
{
    return (re == num.re && im == num.im);
}

Tuladjonképpen semmi új, leszámítva a második függvény első sorának a végén azt a kis const szavacskát, ami azt hivatott jelezni, hogy a függvény az objektumot nem módosítja.
Most, hogy ezt is tisztáztuk, evezzünk izgalmasabb vizekre. Fontos megemlíteni, hogy nem csak az osztályon belül definiálhatunk operátorokat, hanem az osztályon kívül is. Ez már csak azért is egy hasznos dolog, mert elég gyakran adódhat olyan eset, hogy nem tudunk belenyúlni a kódba, amihez viszont egy operátort hozzá akarunk csapni (értelmes és mindent megmagyarázó példát lásd egy picit lejjebb).

Copy konstruktor

A copy konstruktor szépsége esetünkben abban testesül meg, hogy használata teljesen felesleges, viszont bevezetését már ezen a szinten fontosnak tartom, mivel a későbbiekben létfontosságúvá válik, szóval jobb, ha már most hozzászokunk. Ez a konstruktor se más mint a többi, a lényegbeli különbség csak annyi, hogy paraméterként egy, az objektum típusával megegyező objektumot kap, amivel kezdenie kell valamit.

Complex(const Complex& other) : re(other.re), im(other.im) {}

Mivel esetünkben a megírt konstruktor viselkedése nem különbözik az alapértelmezettől (mert hát minden objektumnak ugyanúgy van copy konstruktora, mint konstruktora is, akár megadjuk a kódban akár nem), ezért célszerűbb elhagyni, mivel - A C++ programozási nyelv c. könyv állítása szerint - rövidebb gépikódot eredményez. Azért megjegyezném, hogy nem biztos, hogy tökéletesen átgondolt lépés volt tőlem, hogy int-nek választottam az osztály re és im változóit, lehet célszerűbb lett volna float vagy esetleg double, de ezt inkább az elvégzendő feladat határozza meg.

Kimenetgenerálás

Esetenként szükségünk lehet olyan dolgokra, hogy a véres verejtékkel kiszámolt komplex számunkat a júzer képernyőjén teljes pompájában jelenítsük meg. Az első gondolat természetsen valami olyasmi lehet, hogy csinálunk például egy to_string() vagy print() tagfüggvényt. Nem egy rossz gondolat, de ha már adva van egy operátor erre a célra (operator<<), akkor miért is ne használnánk azt, ahelyett hogy önkényesen definiálunk valami függvényt a probléma megoldására?

friend std::ostream& operator<<(std::ostream& out, Complex& num)
{
    out << num.re << " + " << num.im << "i";
    return out;
}

Bár fentebb azt említettem, hogy az osztályon kívül is definiálhatunk operátorokat, ez esetben mégsem tanácsos ezt tenni (a friend kulcsszó elhagyásával minden további nélkül helyes lenne szintaktikailag), mivel a Complex osztály re és im változói a private blokkban vannak, vagyis nem tudnánk elérni őket abban az esetben. Ezzel tulajdonképpen már meg is magyaráztam a friend kulcsszó lényegét: nélküle nem tudnánk két paraméteres operator<< függvényt megadni az osztályon belül. Ha viszont az osztályon kívül adnánk meg, akkor pedig nem tudnánk elérni a private blokkban lévő változókat.
Egyébként az ostream objektum felelős a kimenetért. A sikeres fordítás előfeltétele egy #include <iostream> valahol a .cpp fájl elején. A megkapott ostream objektum visszaadása a beleírás után hasonló célt szolgál, mint az előző bejegyzésben az egyenlőség operátornál (tehát, hogy lehessen ilyesmiket is írni: std::cout << "Hello, World!" << Complex(2,1) << std::endl;). Ezzel a végére is értünk a második résznek. A következő rész tartalmából: megpróbálunk valami új adatstruktúrát összehozni, kivesézni a jó- és rossztulajdonságait, összehasonlítani a szimpla tömbbel. És ha minden igaz még egy sablont is fogunk ráhúzni!

Osztályok

Talán tisztázzuk is rögtön ezeket a public, private dolgokat. A public részben elhelyezett függvényeket (illetve változókat) az osztály példányosítása után lehet használni, míg a private részben lévőket csak az osztály maga tudja felhasználni. Ezek a kis cimkék nagyon hasznosak tudnak lenni, így egy objektumhoz létre tudunk hozni egy nyilvános (public) felhasználói felületet, aminek ismeretével használni lehet majd az osztályt. Arra gondoltam, hogy a komplex számokat megvalósító osztály elég jó bevezető lehet, aztán majd a későbbiekben jobban elrugaszkodunk a valóságtól.

class Complex
{
    int re, im;

    public:
        Complex(const int& R, const int& I)
        {
            re = R;
            im = I;
        }
};

Ezzel így, ebben a formában semmit sem értünk el, mert hát egy struct is képes lett volna erre annak idején C-ben, a konstruktort leszámítva (az osztály nevével megegyező nevű rémséget (vagy gyakrabban rémségeket) nevezzük konstruktornak, amivel például a kezdeti értékadást végezhetjük el, mint esetünkben is). Aki nem szeret ilyen sokat írni, annak ajánlom a Complex(int R, int I) : re(R), im(I) {} - kicsit haxorosabb - formájú konstruktort, amivel ugyanezt a hatást érhetjük el. Itt az ideje, hogy valami izgalmasat is kezdjünk, a kezünkbe adott fene nagy hatalommal. Írjunk operátorokat!

Operátorok

class Complex
{
    int re, im;

    public:
        Complex(const int& R, const int& I) : re(R), im(I) {}
        Complex(const int& R) : re(R), im(0) {}

        // Összeadás
        Complex operator+(const Complex& num)
        {
            return Complex(re+num.re, im+num.im);
        }
        // Értékadás
        Complex& operator=(const Complex& num)
        {
            re = num.re;
            im = num.im;

            return *this;
        }

        Complex& operator=(const int& num)
        {
            re = num;
            im = 0;

            return *this;
        }
};

Mint az szépen látszik, a konstruktort és az egyenlőség operátort túlterheltem, hogy a következő megadások is működjenek:

Complex c1 = 3;
Complex c2(6, 3);
c1 = 5;
c1 = c2;

Az első sorban a második konstruktor futott le, mivel ez nem egy egyszerű értékadás (a Complex c1(3); hosszabb formája). A második sorban (egyértelműen) az első konstruktor futott le, a harmadik illetve negyedik sorokban értelemszerűen a megfelelő értékadó operátor függvények. Most, hogy már ilyen rengeteg kódunk van, itt az ideje egy kicsit egyszerűsíteni a dolgokon. Az egyszerűsítés a második konstruktornak köszönhető, mivel ezzel egy int-Complex típuskonverziót is definiáltunk. Tehát az értékadás operátor túlterhelése ilyen módon feleslegessé vált.
Érdemes lehet még pár szót fecsérelni arra, hogy az értékadó operátor miért tér vissza egy Complex referenciával, és mi a fene az a *this. Az első kérdésre egy kicsit a dolgok mélyére kell nézni. Mi is történik egy c1 = c2 = 5; sor hatására? Hosszabban valahogy így írhatnánk fel a dolgot: c1.operator=(c2.operator=(Complex(5)). Így már világosan látszik, hogy ha nem térne vissza azzal az értékkel az értékadás, mint amit az objektum felvett, akkor bizony a második értékadás értelmetlen lenne. Ez nem feltétlenül baj, de engem úgy neveltek, hogy ha egy új típust/objektumot ír az ember, akkor az ott használt operátorok viselkedésükben próbáljanak minél jobban hasonlítani az operátor eredeti viselkedéséhez.
A második válasz már lényegesen egyszerűbb, a this változó egy, az objketum éppen használt példányára mutató pointer, amit minden - nem static - tagfüggvényben használhatunk, tehát a *this maga az objektum amivel éppen dolgozunk.

Bevezetésnek, kedvcsinálónak talán ennyi elég is lesz. A következő részben kiegészítjük a Complex osztályunkat pár új operátorral és egy új konstruktorral is (copy konstruktor), majd gyengéden súroljuk a std névtér streamjeit is, csak hogy tényleg ne tűnjön olyan egyszerűnek az élet.

std::string host = "www.something.com";
std::string port = "80";
std::string data = "GET / HTTP/1.1\\nHost: www.something.com\\nConnection:close\\n\\n";

Már csak az az aprócska dolog maradt, hogy akkor most hát, innen hogyan tovább. Először is rakjunk össze egy c-szerű megoldást, a jobb érthetőség kedvéért, aztán majd jöhetnek az objektumok, hogy a dolog ki is nézzen valahogy.

Első lépésben szükség lesz még pár változóra, mondjuk egy bufferre, egyre amiben a socketet tároljuk, egyben, amiben a host visszafejtése után nyert struct adatokat és egyben amiben a kapcsolódáshoz szükséges adatokat tároljuk.

/*
 * Ebben találjuk a sockaddr_in struct-ot és a htons()
 * függvényt, amire majd a későbbiekben szükségünk lesz.
 */
#include <netinet/in.h>
/*
 * Ebben van a hostent struct és a gethostbyname() függvény.
 */
#include <netdb.h>

int main()
{
    /* ... */
    char        buffer[32]; // Az olvasásnál használt buffer
    int         s;          // Ez kell a socketnek
    sockaddr_in sin;        // Ez tárolja a kapcsolódó adatokat
    hostent*    hp;         // Ez pedig a host adatokat
    /* ... */
}

Az első ...-nál vannak az elején megadott host, port, data változók, amikhez nem árt egy #include <string> sor a többi #include között. A második ... után fogjuk a kódot folytatni a socket létrehozásával.

/*
 * Erre a header fájlra van szükség a socket() függvényhez
 */
#include <sys/socket.h>
/* ... */
int main ()
{
    /* ... */
    if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
        return 1;
    }
    /* ... */
}

A socket() függvény első paramétere határozza meg a címcsaládot, azaz hogy a cím hogyan legyen értelmezve. Ez IP esetén az AF_INET konstans, a többi típust a socket.h -ban meg lehet találni. A második paraméter a kapcsolat típusának meghatározásáért felelős, ami TCP esetén SOCK_STREAM, UDP esetén SOCK_DGRAM. Az utolsó a protokoll meghatározása, ami IP esetén 0, egyéb esetek az /etc/protocols-ban találhatóak meg. Most, hogy ezzel megvagyunk, ideje, hogy a hostunkból kapjunk egy használható structot a gethostbyname() függvény segítségével.

/* ... */
int main()
{
    /* ... */
    if ((hp = gethostbyname(host.c_str())) == 0) {
        return 2;
    }
    sin.sin_family = AF_INET;
    bcopy(hp->h_addr, (char*)&sin.sin_addr, hp->h_length);
    sin.sin_port = htons(atoi(port.c_str()));
    /* ... */
}

A host megkapással egyben le is rendeztem a másik struct adatainak feltöltését, mivel minden szükséges adat a rendelkezésünkre állt. Azaz a cím család itt is AF_INET lett, a címet a hp struct-ból másolgattuk át, a portot pedig már a legelején stringként megadtuk, abból csináltunk char*-ot majd int-et és végül a htons() függvény segítségével host byte orderből network byte ordert csináltunk (ami nekem még nem teljesen tiszta, hogy miért is kell ezt így, sz'al ha valakinek valami infója van róla, szivesen venném). Így most már nincs más hátra mint csatlakozni és elküldeni a kérést.

/* ... */
int main()
{
    /* ... */
    if (connect(s, (sockaddr*)&sin, sizeof(sin)) < 0) {
        return 3;
    }

    int num;
    num = write(s, data.c_str(), data.length());
    if (num < 0) {
        return 4;
    }
    /* ... */
}

A connect() első paramétere a megnyitott socket-ünk, a második a kapcsolat adatai a harmadik pedig a kapcsolat adatainak a mérete. A write() első paramétere a socket a második az adat (char* formában), a harmadik pedig a küldendő adat hossza. Most, hogy megvolt a csatlakozás, megvolt a kérés, már csak megfelelő fogadtatásban kell részesíteni az érkező adathalmazt.

/* ... */
int main()
{
    /* ... */
    while ((num = read(s, buffer, sizeof(buffer))) > 0) {
        buffer[num] = '\\0';
        std::cout << buffer;
    }
    close(s);
    return 0;
}

Megkaptuk az adatokat, lezárjuk a kapcsolatot, kilépünk a programból. Persze a kóddal a legnagyobb probléma (azon kívül, hogy ezekkel a /* ... */ kommentekkel talán még kibogózhatatlanabbá tettem), hogy nagyon is egyszer haszálatos, eléggé átláthatatlan meg egyébként is csúnya. Nézzünk akkor egy osztályos megoldást:

#ifndef __SOCKET_H__
#define __SOCKET_H__

#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

#include <string>

#define E_SOCKET_ERROR  1
#define E_HOST_ERROR    2
#define E_CONNECT_ERROR 3
#define E_WRITE_ERROR   4

class Socket
{
    private:
        char buffer[32];
        int sock;
        hostent* hp;
        sockaddr_in sin;
    public:
        Socket();
        Socket(const std::string& host, const std::string& port)
        {
            this->Open(host, port);
        }
        ~Socket()
        {
            this->Close();
        }
        void Open(const std::string& host, const std::string& port)
        {
            // Socket létrehozása
            if ((this->socket = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
                throw new Socket::SocketException(E_SOCKET_ERROR);
            }

            // Host visszafejtése
            if ((this->hp = gethostbyname(host.c_str())) == 0) {
                throw new Socket::SocketException(E_HOST_ERROR);
            }

            // sockaddr_in struct feltöltése
            this->sin.sin_family = AF_INET;
            bcopy(this->hp->h_addr, (char*)&this->sin.sin_addr, this->hp->h_length);
            this->sin.sin_port = htons(atoi(port.c_str()));

            // Csatlakozás
            if (connect(this->sock, (sockaddr*)&this->sin, sizeof(this->sin)) < 0) {
                throw new Socket::SocketException(E_CONNECT_ERROR);
            }
        }
        void Send(const std::string& data)
        {
            int wb = write(this->sock, data.c_str(), data.length());
            if (wb < 0) {
                throw new Socket::SocketException(E_WRITE_ERROR);
            }
        }
        std::string GetLine()
        {
            int rb;
            std::string ret;
            do {
                rb = read(this->sock, this->buffer, 1);
                if (rb > 0) {
                    if (this->buffer[0] != '\\n') {
                        ret += this->buffer[0];
                    }
                    else {
                        break;
                    }
                }
            } while (rb > 0);

            return ret;
        }
        void Close()
        {
            close(this->sock);
            return;
        }
        class SoketException
        {
            public:
                int errorCode;
                SocketException(const int& code)
                {
                    this->errorCode = code;
                }
        };
};

#endif

Csak a kép teljességéért, egy rövidke példaprogram, ami ezt a Socket.h fájlt használja és ugyanazt eredményezi, mint az osztály nélküli kód.

#include "Socket.h"

#include <string>
#include <iostream>

int main()
{
    std::string host = "www.something.com";
    std::string port = "80";
    std::string data = "GET / HTTP/1.1\\nHost: www.something.com\\nConnection:close\\n\\n";

    Socket* sock;

    try {
        sock->Open(host, port);
        sock->Send(data);

        std::string row;
        while ((row = sock->GetLine()).length() > 0) {
            std::cout << row << std::endl;
        }

        sock->Close();
    }
    catch (Socket::SocketException e) {
        delete sock;
        return e.errorCode;
    }
    delete sock;
    return 0;
}

Egy cseppet szebb lett. Mondjuk nézőpont kérdése. Egy egyszer használatos gyors socketelésre felesleges lenne osztályt írni, de ha már az embernek kéznél van egy ilyen, akkor gyorsabban megírhat egy egyszerhasználatos socketelést, mint egyébként. Bár az igazsághoz hozzátartozik, hogy így a kód mérete picikét nagyobb lett (ha jól emlékszem alapból 16k volt, így meg 20k lett g++-szal fordítva mindenféle extra paraméterezés nélkül).