Dotaz: Inline funkce

[Wan-To]

Chtěl bych se zeptat, jestli je v pořádku psát různé get/set metody tříd jako inline funkce přímo do hlavičkových souborů.

Např.:

class Trida {
private:
    int x;
public:
    int getX() const {return x;}
    void setX(const int & x) {this->x = x;}
}

Nebude s přibývajícími třídami a dalšími inline gettery/settery příliš narůstat velikost programu?

Odpovědi

[Michal Kubeček]

Pokud se optimalizátor chová aspoň trochu slušně, neměl by ve výsledném kódu být žádný rozdíl oproti tomu, kdybyste k datovým polím přistupoval přímo.

[Wan-To]

To já vím, vždyť to jsou inline metody. Jde mi jen o to, zda je takový zápis "dobrým programátorským zvykem".

[Michal Kubeček]

Jak se to vezme. Někteří teoretici tvrdí, že je to Jediný Správný Způsob, ale já taková dogmata moc v lásce nemám. Spíš bych řekl, že je nejlepší dělat to tak, jak vám to vyhovuje. Ale určitě jsou ty get/set metody vhodné v případě, kdy hrozí riziko, že buď někdy v budoucnu nebo u některého potomka by ta hodnota nemusela být implementována jako klasické pole.

[Wan-To]

Teďka se ale nebavíme o správnosti použití get/set funkcí (o jejich nutnosti nepochybuji), nýbrž o použití inline funkcí pro implementaci getterů a setterů.

[Michal Kubeček]

Aha, takže vám jde jen o to, zda je správnější, aby to byly klasické funkce nebo inline? V tom případě bych to neřešil, pokud nepotřebujete, aby ty metody byly virtuální, určitě bych je udělal inline (aspoň jsou-li takto jednoduché). I když podle mých zkušeností je to nakonec celkem jedno, protože jak jsem zjistil, moderní kompilátory stejně berou inline spíš jako takovou nápovědu a v praxi stejně občas zinlinují normální funkci a naopak.

[8an]

Obávám se že to pořád není jak to autor myslel, v příkladu ani nikde klíčové slovo inline není...

Podle mě by v hlavičkových souborech neměl být žádný kód. Zkus si tu třídu dát do odděleného souboru, ten zvlášť zkompilovat, includovat do dvou jiných souborů, a celé to slinkovat dohromady. Tipuju že linker vyhodí chybu.

[Michal Kubeček]

Raději netipujte a buď se podívejte do specifikace, do nějaké učebnice, nebo to prostě zkuste. Toto je naprosto standardní záležitost, pokud tělo metody napíšete přímo do definice třídy, chová se to jako inline metoda a není žádný rozdíl mezi

  class A {
    // ...
    int f() { return x; }
  };

a

  class A {
    // ...
    int f();
  };

  inline int A::f()
  {
    return x;
  }

(někdy se tomu prvnímu názorně říká "implicit inline"), oboje funguje a linker žádnou chybu nevyhodí. První způsob se ale většinou používá jen tam, kde je tělo metody natolik triviální, že to není na úkor přehlednosti (spíš naopak).

[Wan-To]

Počkejte, když mám podobnou inline metodu, tak nemůže být virtuální? Kompilátor mi žádnou chybu nevyhodil, ale kdo ví, jak se bude pak aplikace chovat...

[Michal Kubeček]

Aplikace se bude chovat dobře. Jde jen o to, že virtuální metoda z podstaty nemůže být inline (protože nemůžete dát pointer na inline metodu do tabulky virtuálních metod). Proto pokud na takovou metodu kompilátor narazí, ignoruje inline a metodu v object file exportuje jako "weak symbol", takže linker použije jen jednu implementaci. Kompilátor si tedy nestěžuje a tiše problém vyřeší za vás; mám ale pocit, že jsem u nějakého překladače (Borland C++?) kdysi zažil, že v podobné situaci zahlásil warning, že metoda nebude inline.

Jeden drobný rozdíl jsem ale našel: pokud je to klasická inline metoda (explicitní), exportuje se ve všech modulech, do kterých byla její definice includována, zatímco je-li tělo metody definováno přímo v definici třídy (implicit inline), je symbol exportován jen v těch modulech, kde je použita nějaká instance příslušné třídy. Tedy pro GCC 4.1, jiné překladače se možná chovají odlišně.

[Wan-To]

class Neco {
public:
    virtual int getNeco() const {return -1;}
};

Metoda getNeco() tedy nebude inline, pokud to dobře chápu.

Ad. drobný rozdíl: já jsem s tím měl drobný problém. V jedné třídě byly všechny metody inline (uvedené v hlavičkovém souboru). Když jsem pak v jiném programu použil tuto třídu (měla být obsažená v .so knihovně), kompilátor hlásil nějakou chybu. Prostě dokud jsem alespoň jednu metodu nevložil do .cpp zdrojového kódu, třída nešla použít.

[Michal Kubeček]

K první otázce: z pohledu zdrojáku vám to může být jedno. Můžete ten hlavičkový soubor naincludovat do tolika modulů, do kolika uznáte za vhodné, a všechny pak slinkovat dohromady. Ale z pohledu implementace skutečně inline nebude, bude se muset použít nějaká forma instrukce CALL. To je prostě daň za to, že se konkrétní verze té metody zvolí až za běhu.

Co se týče druhého problému, něco podobného se mi také stalo, mám pocit, že tu hlášku psal až linker a byla o chybějící referenci na tabulku virtuálních metod té třídy. Ale nedaří se mi to teď zreprodukovat.

[Wan-To]

To je přesně ono, toto linker hlásil.

A moc díky za všechny informace, zase jsem o něco chytřejší