Witam,
Które sposób pisania jest bardziej wydajny czy może nie ma to znaczenia ?
I sposob
class Klasa {
public:
void metoda();
};
void Klasa::metoda{
// jakiś tam kod
}
II sposob
class Klasa {
public:
void metoda(){
// jakiś tam kod}
};
Pozdrawiam :)
To jest tak jakbyś się zapytał czy
<code = cpp>int i = 10
jest bardziej wydajniejsze od
<code = cpp> int i;
i = 10;
Nie wiem dlaczego ludzie na siłę szukają optymalizacji, tam gdzie jej nie ma :S
Tylko że tutaj ma to znaczenie i to spore.
class Klasa {
public:
void metoda(){
// jakiś tam kod
}
};
Jest tym samym co:
class Klasa {
public:
void metoda();
};
inline void Klasa::metoda{
// jakiś tam kod
}
Metody zaimplementowane w ciele klasy są metodami inline.
1 sposób się praktykuje z powodów technicznych (nagłówki mają mieć TYLKO deklaracje).
2 sposób stosuje się jedynie do szablonów (template), również z przyczyn technicznych.
Które sposób pisania jest bardziej wydajny
Bez znaczenia.
Metody zaimplementowane w ciele klasy są metodami inline.
To jest inne pojęcie „inline”.
Słowo inline znaczy „w miejscu”.
Metoda inline w znaczeniu zdefiniowanej w klasie, jest zdefiniowana w miejscu, czyli wewnątrz deklaracji klasy, a nie gdzieś poza nią. Jest to tylko i wyłącznie kwestia stylu kodu źródłowego, i nie ma żadnego wpływu na wynikowy kod programu.
Metoda inline w zaczeniu słowa kluczowego inline, oznacza podpowiedź dla kompilatora, aby kod wynikowy umieszczał w miejscu wywołania metody, w przeciwieństwie do instrukcji skoku w inne miejsce w pamięci. Ma to rzeczywiście wpływ na wynikowy program (szybszy kod kosztem zwiększenia zużycia pamięci).
Przeprowadzałem niedawno testy, i na przykład wydaje mi się, że GCC całkowicie ignoruje słowo inline: przy wyłączonej optymalizacji nie inline'uje niczego, a przy włączonej inline'uje agresywnie wszystko co popadnie.
Azarien napisał(a)
Metody zaimplementowane w ciele klasy są metodami inline.
To jest inne pojęcie „inline”.
Słowo inline znaczy „w miejscu”.
Metoda inline w znaczeniu zdefiniowanej w klasie, jest zdefiniowana w miejscu, czyli wewnątrz deklaracji klasy, a nie gdzieś poza nią. Jest to tylko i wyłącznie kwestia stylu kodu źródłowego, i nie ma żadnego wpływu na wynikowy kod programu.
Jestem prawie pewien że metody zdefiniowane w ciele klasy są metodami inline w znaczeniu podpowiedzi dla kompilatora. Żebym nie był gołosłowny podam pierwsze źródło jakie przychodzi mi na myśl: "Thinking in C++".
Możliwe że zawodzi mnie pamięć, lub moja znajomośc angielskiego nie pozwoliła mi zrozumieć autora książki ;).
Pozdrawiam.
Z tego co pamiętam to jest tak jak mówi kolega @const_variable. Metody zadeklarowane wewnątrz ciała klasy są domyślnie niejawnie zadeklarowane ze słowem inline.
Azarien napisał(a)
[...]
Przeprowadzałem niedawno testy, i na przykład wydaje mi się, że GCC całkowicie ignoruje słowo inline: przy wyłączonej optymalizacji nie inline'uje niczego, a przy włączonej inline'uje agresywnie wszystko co popadnie.
i to jest prawidłowe, bo to tylko podpowiedź, a kompilator ma prawo zrobić z tym co chce...
np. visual ma jeszcze swoje _forceinline, ono już chyba zawsze inlineuje jeśli się da, a jeśli nie (np z powodu: PROCPTR ptr = &proc;) generuje ostrzeżenie, aczkolwiek nie jestem pewny...
w każdym razie co się tyczy wydajności, to wszystko zależy od złożoności funkcji, dajmy na to, że funkcja wygląda tak:
void fun() { var = 1; }
no to załóżmy że będzie rozwinięta do 1 mov'a, no to narzut jaki będzie miało rozwinięcie funkcji będzie nieporównywalnie większy do jej treści, natomiast jeśli funkcja jest długa, to oczywiste że narzut wywołania jest nieproporcjonalnie malutki - nieznaczący, aczkolwiek zawsze jest.
Przykładowo kiedyś implementowałem swoją bibliotekę do macierzy zastępując D3DXMATRIX i metody do operacji na niej, na własne metody. Metody te nie są inline, a ja zastąpiłem je odpowiednikami inline, zysk jest rzędu mniejszego niż 1%, ale np. przy dużej ilości macierzy może już pójść w milisekundy :>
dodatkowo potem sprawdziłem jaka różnica jest przy zwracaniu wyniku w wersji:
Matrix operator*(Matrix&, Matrix&);
a
void operator*(Matrix& out, Matrix&, Matrix&);
i przekopiowanie przez też return daje podobny narzut do co wołanie func :> więc pisząc najoptymalniejszą wersję, może da się już przekroczyć 1% :D
Tylko że tutaj ma to znaczenie i to spore.
Może i znaczenie ma, ale nie ma różnicy w czasie wykonywania programy czy zużytej pamięci ...
Nikt się nie spodziewa co optymalizator „wymyśli”. Przykładowo byłem zaskoczony czymś takim (GCC 4.5.0):
z kodu
#include <iostream>
using namespace std;
class Liczba {
int x;
public:
Liczba(int ax);
friend ostream& operator <<(ostream&, const Liczba&);
};
Liczba::Liczba(int ax) {
x=ax;
}
ostream& operator <<(ostream& out, const Liczba &liczba) {
return out<<liczba.x;
}
int main() {
Liczba a(5);
cout<<a;
}
kompilator zrobił coś takiego (tzn. wygenerował identyczny kod wynikowy):
#include <iostream>
int main() {
std::cout<<5;
}
żadnego obiektu, żadnego konstruktora, żadnego operatora. po prostu 5.
Bardzo ciekawa dyskusja, która pomogła mi zrozumieć trochę więcej niż zamierzałem. Dziękuje bardzo wszystkim :)
@inlining defacto oraz słowo kluczowe inline -- jest to podpowiedź, standard mówi że kompilator nie musi na nią reagować, i żeby było śmieszniej, większość kompilatorów ją po prostu ignoruje