[G.....9]

Czy jeżeli robię kopię w funkcji to argumenty powinny być zawsze przekazane by value?

void funkcja(std::string str)
{
    std::string s = std::move(str);
}

zamiast

void funkcja(const std::string& str)
{
    std::string s = str;
}

i analogicznie w konstruktorze?

Konstruktor(std::string str) : s(std::move(str){}

Mam wrażenie, że nikt tak nie robi, a nie widzę wad tego podejścia.
#cpp

[vytah]

@Gerax9: Dla ciężkich obiektów typu string używaj albo const string&, albo string&& i move. Często robi się oba jako overloady.

[G.....9]

@vytah: No właśnie o to mi chodzi, że lepiej zrobić kopie + move , to rozwiązuje obie te sytuacje i nie masz duplikowanego kodu.

std::string:
Dostaje l-value to masz copy+move.
Dostajesz r-value to masz constructor+move.

A wersji z const std::string&
Dostaje l-value to masz referencja+kopia.
Dostajesz r-value to masz constructor+kopia(!!!).

Wersja z overloadami
Dostaje l-value to masz referencja+kopia.
Dostajesz r-value to masz constructor+move.

[G.....9]

@Gerax9: Mały błąd we wpisie, oczywiście chodzi mi o obiekty wspierające efektywny move(string, shared_ptr), w przypadku obiektów typu "optional<int>" lepiej zrobić overload, albo const referencje.

[BeginEnd]

@Gerax9: Jedno i drugie podejście będzie działało. Jedno i drugie ma swoje wady i zalety. Generalna zasada jest żeby używać const & zamiast kopiowania, ale to jest raczej zalecenie. Jeżeli funkcja ma wziąć wartość parametru na własność w jakiś sposób (np zmienia jego wartość) to kopia może być ok. Przekazywanie przez kopię ogranicza pole manewru użytkownikowi funkcji - cokolwiek nie zrobi i tak finalnie będzie stworzona kopia przy wywołaniu.

Jak funkcja

[G.....9]

@BeginEnd:

jeżeli nie mam konkretnego powodu

Wydajność?

std::move( ) to więcej znaków niż const & + kopiowanie.

No to czemu nie piszesz w pythonie? Wtedy będzie mniej znaków.

[BeginEnd]

Wydajność?

@Gerax9: optymalizuję kod jeżeli jest to potrzebne. Wyleczyłem się z optymalizacji każdej linijki kodu. BTW: nie wiem czy wiesz ale przy krótkich stringach (do 22 znaków) oba podejścia są równoważne.

No to czemu nie piszesz w pythonie? Wtedy będzie mniej znaków.

@Gerax9: Bo kodzę w C++.

[G.....9]

@BeginEnd:

optymalizuję kod jeżeli jest to potrzebne. Wyleczyłem się z optymalizacji każdej linijki kodu.

Ale to nie jest jakaś specjalnie trudna optymalizacja, tylko po prostu zasada pisania kodu.

BTW: nie wiem czy wiesz ale przy krótkich stringach (do 22 znaków) oba podejścia są równoważne.

Właściwie to 15 znaków + '\0', a przynajmniej tak jest na systemach 64 bitowych, bo wtedy zamiast dwóch wskaźników masz te 16 bajtów.

[BeginEnd]

bo wtedy zamiast dwóch wskaźników masz

@Gerax9: + capacity = 3 słowa.

[MamCieNaHita]

@Gerax9: podejście z const referencją ma wadę jak przychodzi do konwersji. przekazując const char* stworzysz temporary stringa, którego będziesz kopiował, w podejściu z wartością zmovujesz ten, który powstał przy konwersji.

teoretycznie fajnie by było mieć obie sygnatury. w praktyce idzie się skichać przy 2^n overloadach dla n parametrów.

po to powstał perfect forwarding, żeby miec jeden generyczny overload, ale wtedy witajcie szablony i ich mankamenty.

[G.....9]

@BeginEnd: Możesz podać wersję kompilatora na której masz takie wyniki? Bo u mnie optymalizuje do 15 znaków. https://godbolt.org/z/K4W5z4feG

@MamCieNaHita No tak czyli value + move jest lepsze, bo też nie ma dodatkowej kopii przy r-value/const char*.

[BeginEnd]

@BeginEnd: Możesz podać wersję kompilatora na której masz takie wyniki? Bo u mnie optymalizuje do 15 znaków. https://godbolt.org/z/K4W5z4feG

@Gerax9: Nie mogę bo nie sprawdzałem dokładnie jaki to rozmiar. Ale masz rację, w plikach nagłówkowych jest zahardkodowane 15 znaków + '\0' .