2. hét: C99 nyelvi elemek

Attól függ, melyik nyelven. Az f() C-ben azt jelenti, hogy a függvény tetszőlegesen sok, tetszőleges típusú paramétert vehet át. Ez nem jó semmire, csak történelmi okokból megmaradt. Az f(void) pedig azt, hogy a függvény nem kaphat paramétert. Ezzel szemben az f() és az f(void) C++-ban ugyanazt jelenti: a függvény nem kaphat paramétert. C++-ban az f() formát szokás használni, de a C kompatibilitás miatt elfogadja az f(void)-ot is.

A baj, hogy csak egyetlen egy buf[] karaktertömb van. Ez az első printf()-nél még nem gond. De mire meghívódik a második printf(), addigra ugyanaz a tömb többször is felül lett írva, r1, r2 és r3 sztring reprezentációjával. Mivel mindhárom hívás ugyanannak a tömbnek a címével tér vissza, a printf() háromszor fogja ugyanazt a törtet kiírni. Hogy melyiket, azt nem lehet tudni, mivel a függvényparaméterek kiértékelési sorrendje kötetlen, és nem tudjuk, az r1, r2 vagy r3-hoz tartozó tostring_ratio() hívódik utoljára.

A tostring_ratio_1() azért, mert a buf[] lokális változó, ami a függvényből visszatéréskor megszűnik. A hívónak egy érvénytelen pointert (dangling pointer) adunk. A tostring_ratio_2() ugyan megoldja, hogy minden hívásnál külön tömb legyen, de azt a hívónak fel kell majd szabadítania, és így a függvény eddigi használati módja válik helytelenné, ti. nincs felszabadítva a memóriaterület. A tostring_ratio_3() pedig csak addig működik, amíg nem akarunk egy printf()-ből tíznél több törtet kiírni.

Helytelen. Az r paraméter a függvény lokális változója; a visszatéréskor az r.buf megszűnik.

Esetleg úgy, hogy a hívó biztosítja a sztring helyét. De ezzel sajnos nem kerülünk közelebb a kényelmes használathoz:

char const *tostring_ratio(Ratio r, char *buf) {
    sprintf(buf, "%d/%d", r.num, r.den);
    return buf;
}

/* ... */
char buf1[100], buf2[100], buf3[100];
printf("r1 = %s\n", tostring_ratio(r1, buf1));
printf("%s + %s = %s\n",
    tostring_ratio(r1, buf1), tostring_ratio(r2, buf2), tostring_ratio(r3, buf3));

A program helyes, mert az összetett literálisként megadott tömb élettartama a blokk végéig tart. Így létezni fog akkor is, amikor a printf() megkapja a címet – ugyanazt a címet, amit a tostring_ratio() megkapott, és változatlanul visszaadott (még ha a mutatott memóriatartalom változott is). A makró is helyes, mert pont ugyanarra fejtődik ki, ami az eredeti kód is volt.

Az ötlet működőképes, de két hátulütője van. Az egyik, hogy a névtelen tömbök mindig inicializálásra kerülnek, és ez felesleges, mert a függvény úgyis felülírja a tartalmukat. A másik, hogy a makrót könnyű rosszul használni; egy óvatlan pillanatban leírt return TOSTRING_RATIO(r) már hibás.

Nem igaz. Értékadással meg lehet/szabad változtatni. De ez nem gond, mert értéket adni csak egy másik Ratio objektumból lehet, és annak is a konstruktorral kellett létrejönnie.

A C++ programnak semmi baja nem lesz. A C program viszont elromlik, mivel az alábbi sor nem név szerint, hanem sorrendjük szerint hivatkozik a tagváltozókra:

Ratio new = { num/a, den/a };

Elég összehasonlítani a számlálókat és a nevezőket, mivel a törtek már egyszerűsítve vannak.

int equal_ratio(Ratio r1, Ratio r2) {
   return r1.num == r2.num && r2.den == r2.den;
}

bool operator==(Ratio r1, Ratio r2) {
    return r1.num() == r2.num() && r1.den() == r2.den();
}

Rossz ötlet. Törteket lehet összeadni, összeszorozni, de olyan műveletről nem hallott még senki, hogy „x-re cseréljük egy tört számlálóját”. Ha mégis ilyet szeretnénk, ahhoz nem kell új tagfüggvény, megoldható a mostani osztállyal is:

Ratio new_numerator(Ratio r, int num) {
    return Ratio(num, r.den());
}

Egyet, a cast-ot. A C++ szintaktikai szabályai szerint az kötelezően tagfüggvény. A többi lehet globális is, és jobb is úgy megírni őket. Például:

/* ez tag */
Ratio::operator double() const {
    return (double) num_ / (double) den_;
}

/* minden más visszavezethető a konstruktorra és a két getterre */
Ratio & operator+=(Ratio &r1, Ratio r2) {
    r1 = r1 + r2;
    return r1;
}

/* egyoperandusú - (negálás) */
Ratio operator-(Ratio r) {
    return Ratio(-r.num(), r.den());
}

/* a konstruktor egyszerűsíti is a beolvasott törtet! */
std::istream & operator>>(std::istream &is, Ratio &r) {
    int num, den;
    char c;
    is >> num >> c >> den;
    r = Ratio(num, den);
    return is;
}

A fenti kódrészletek a szintaktikát hivatottak bemutatni. Egy „komoly” változatnál figyelni kellene, hogyan kezeljük a nullával osztást (hibás nevező) és az előjeleket.

Az alábbi két osztály tökéletesen csereszabatos. És igen, a konstruktorok szándékosan privát elérésűek. Mivel akár valós és képzetes részből, akár hosszból és szögből szeretnénk létrehozni egy komplex számot, mindkét esetben két double lenne a konstruktor paramétere, sajnos nem tudjuk kihasználni a függvénynév túlterhelést. Marad a névvel rendelkező konstruktor, mint szokásos nyelvi fordulat (named constructor idiom). A statikus tagfüggvények nyelvileg is részét képezik az osztálynak, így elérik a privát konstruktort.

class Complex {
  public:
    static Complex make_complex_reim(double re, double im) {
        return Complex(re, im);
    }
    static Complex make_complex_rfi(double r, double fi) {
        return Complex(r*cos(fi), r*sin(fi));
    }

    double get_re() const {
        return re_;
    }
    double get_im() const {
        return im_;
    }
    double get_r() const {
        return sqrt(re_*re_ + im_*im_);
    }
    double get_fi() const {
        return atan2(im_, re_);
    }

  private:
    double re_, im_;
    Complex(double re, double im): re_(re), im_(im) {}
};

class Complex {
  public:
    static Complex make_complex_reim(double re, double im) {
        return Complex(sqrt(re*re+im*im), atan2(im, re));
    }
    static Complex make_complex_rfi(double r, double fi) {
        return Complex(r, fi);
    }

    double get_re() const {
        return r_*cos(fi_);
    }
    double get_im() const {
        return r_*sin(fi_);
    }
    double get_r() const {
        return r_;
    }
    double get_fi() const {
        return fi_;
    }

  private:
    double r_, fi_;
    Complex(double r, double fi): r_(r), fi_(fi) {}
};

Nem. A C99-ben és a C++-ban a main() speciális függvény. Ha kihagyjuk belőle a return-t, a fordító úgy veszi, 0-val tért vissza. A C89-ben ez még nem volt így.

Az első igen, a második nem. Az elsőben globális változó a karaktertömb, a másodikban lokális.

Így már le sem fordítható a kódrészlet. A függvény statikus lokális, azaz adatszegmensben tárolt, globális élettartamú p pointeréhez olyan inicializáló érték kellene, amely fordítási idejű konstans. Mivel azonban a megadott tömb a veremben van, a címe nem konstans. A static kulcsszóval amúgy sem a tömb, hanem a pointer élettartamát változtatjuk, hiszen az a p definíciójához tartozik.

A „szokásos”: definiálatlan. Valószínűleg helytelenül fog működni a programunk. A fordító nem ellenőrzi ezt az értékadást; ránk van bízva, hogy helyesen használjuk.

Vigyázat! VLA csak veremben lehet!

/* jó megoldás */
struct Matrix {
    int width, height;
    double **data;
};

/* rossz megoldás */
struct Matrix {
    int width, height;
    double data[width][height];
};

Vigyázat! A flexibilis tömb nem lehet kétdimenziós!

/* jó megoldás lehet */
struct Matrix {
    int width, height;
    double **data;
};

/* rossz megoldás */
struct Matrix {
    int width, height;
    double data[][];
};

Csak a flexibilis tag előtti része másolódik, mivel az ilyen struktúra (szinte) minden szempontból úgy viselkedik, mint a flexibilis tag nélküli változata. A tömb nem másolódhat, mivel annak méretéről a fordítónak nincs tudomása.