Maciej Piechotka

Skoro działa tylko pod gcc4 to jest to średnie rozwiązanie. Nie lepiej deklaracje funkcji / klas trzymać jak Pan Kompilator przykazał w .h a definicje w .cpp? Wtedy raczej łatwo uniknąć problemu.

Akcesory i mutatory też chcesz trzymać w .cpp? Gratuluję szybkiego programu! Ale też nie podoba mi się rozwiązanie z szablonem, szczególnie, że cała definicja szablonu musi być dostępna. Jednak nawet ukazując (moim zdaniem) jedyne sensowne rozwiązanie, w artykuł wkradło się pewne niedomówienie. Otóż, warto takie metody zadeklarować jako inline (bo zakładam, że metod, których nie deklarowalibyśmy jako inline w pliku .hpp nie ma).

http://github.com/mina86/p2p-chat/blob/f0f6bf214966ef0fb7a357244ac6591792d378cd/src/application.hpp

Ah, już wiem co mi się nie zgadzało z tym brakiem inline. Chodzi bowiem nie o optymalizacje, tylko o to, że bez inline kompilator jest zobowiązany wygenerować kod i symbol. Wynika z tego, iż każda jednostka translacji dołączający tak skonstruowany plik nagłówkowy będzie posiadała własną definicję danych metod. W rezultacie, linkowanie się nie powiedzie:

$ cat header.hpp #include <iostream>

struct Bar;

struct Foo { static Foo *create(); void doFoo() { std::cout << „Foo!\n”; } void doBar(); Bar *bar;
};

struct Bar { static Bar *create(); void doFoo(); void doBar() { std::cout << „Bar!\n”; } Foo *foo;
};

void Foo::doBar() { bar->doBar(); }
void Bar::doFoo() { foo->doFoo(); }
$ cat foo.cpp #include „header.hpp”
Foo *Foo::create() { return new Foo(); }
$ cat bar.cpp #include „header.hpp”
Bar *Bar::create() { return new Bar(); }
$ cat main.cpp #include „header.hpp”

int main(void) { Foo *foo = Foo::create(); Bar *bar = Bar::create();

foo->bar = bar; bar->foo = foo;

foo->doBar(); bar->doFoo();

delete foo; delete bar; return 0;
}
$ make main.o foo.o bar.o
g++ -c -o main.o main.cpp
g++ -c -o foo.o foo.cpp
g++ -c -o bar.o bar.cpp
$ g++ -o main main.o foo.o bar.o
foo.o: In function `Bar::doFoo()’:
foo.cpp:(.text+0×106): multiple definition of `Bar::doFoo()’
main.o:main.cpp:(.text+0×106): first defined here
foo.o: In function `Foo::doBar()’:
foo.cpp:(.text+0×120): multiple definition of `Foo::doBar()’
main.o:main.cpp:(.text+0×120): first defined here
bar.o: In function `Bar::doFoo()’:
bar.cpp:(.text+0×106): multiple definition of `Bar::doFoo()’
main.o:main.cpp:(.text+0×106): first defined here
bar.o: In function `Foo::doBar()’:
bar.cpp:(.text+0×120): multiple definition of `Foo::doBar()’
main.o:main.cpp:(.text+0×120): first defined here
collect2: ld returned 1 exit status

Nie ma potrzeby oznaczania funkcji zdefiniowanych wewnątrz definicji klasy jako inline. To jest w tym przypadku domyślne.

Chodzi o funkcje zdefiniowane poza klasą.

Tak, ale z tego co widzę to Maciek się trochę zagalopował z inline :D

Tak teraz myślę, skoro jedyną rzeczą która nie pozwala umieścić definicji metod w pliku cpp jest kwestia wydajności, to można to rozwiązać bez posiłkowania się szablonami.
Wystarczy że definicję metod zachowamy w pliku hpp, ale wyrzucimy poza definicję klasy (zaznaczając, że są inline). Wtedy można umieścić definicję obu nieszczęsnych klas przed implementacją ich metod (zarówno tych inline jak i „zwykłych”) i wszyscy będą zadowoleni.
Może nie jest to rozwiązanie jakoś znacząco lepsze od tutaj zaprezentowanego, ale jakoś mi się bardziej coś takiego podoba niż zabawa z szablonami.

Tylko, że to mogą być stosunkowo duże klasy (w sensie „posiadające
skomplikowane funkcje”) i trudno wymagać, aby pełną implementację
umieszczać w nagłówku, szczególnie, że plik może być dołączany przez
większość plików projektu i wówczas zmiany w implementacji (która
powinna być ukryta) spowodują rekompilację wszystkiego.

Co więcej, nie ma to najmniejszego sensu, skoro metody, których nie
zamierzamy „inline’ować” nie stanowią dla nas kłopotu. Problem
stanowią jedynie metody zdefiniowane wewnątrz klasy, które odwołują
się do jeszcze nie zdefiniowanego typu — takie należy zadeklarować
jako inline, a ich definicje przerzucić na koniec pliku.

mina86: Właśnie o coś takiego mi chodziło, tylko najwyraźniej zbyt zagmatwanie to opisałem ;)
Domyślam się że w błąd wprowadził Cię fragment „klas przed implementacją ich metod (zarówno tych inline jak i ‘zwykłych’)”, ale zwracam uwagę, że nigdzie nie napisałem, że metody „nie-inline” też umieszczamy w hpp. W sumie to ich ta kwestia kompletnie nie dotyczy bo można sobie z nimi łatwo poradzić.
Tylko funkcje wstawiane w miejscu wykonania stanowią pewnego rodzaju komplikację, którą można rozwiązać przez umieszczenie ich poza definicją klasy (ale w pliku nagłówkowym) już po definicji wszelkich wymaganych zależności.
Chodzi mi o to, że nie widzę powodu aby dodatkowo utrudniać sobie życie skoro można to zrobić w IMO prostszy sposób.