/ / C ++ wskaźnik prywatny "przecieka"? - c ++, wycieki pamięci, wskaźniki

Własny wskaźnik C ++ "przecieka"? - c ++, wycieki pamięci, wskaźniki

Zamierzam utworzyć klasę do przechowywania długiej listy parametrów, które zostaną przekazane do funkcji. Użyjmy tego krótszego przykładu:

class ParamList{

public:
ParamList(string& a_string);
string& getString(); //returns my_string
private:
string& my_string;
}

Moje pytanie brzmi: my_string jest prywatny, ale zwracam odwołanie do niego. Czy nie jest to coś, co nazywa się wskaźnikiem prywatnym wyciekającym w C ++? Czy to nie jest dobra praktyka programistyczna? Chcę, aby wywoływacze getString mogli uzyskać referencję, a także ją zmodyfikować.

Proszę daj mi znać.

Dzięki, jbu

edit1: wywołujący użyje getString () i zmodyfikuje zwracany łańcuch.

Odpowiedzi:

3 dla odpowiedzi № 1

Odzyskiwanie prywatnego odniesienia jest całkowicie w porządku, o ile:

A. To jest const referencje i udokumentowałeś, kiedy odwołanie może zostać unieważnione lub
B. Odniesienie to ma być zmodyfikowane (tj. std::vector<T>::operator[])

Chociaż istnieją użyteczne przypadki do zwracania odniesienia nie const, powinieneś go zazwyczaj unikać. Obejmuje to Scott Meyers "Efektywny C ++ (3rd Edition, poz. 28): Unikaj zwracania "uchwytów" do wewnętrznych obiektów, jeśli chcesz rzucić okiem.


2 dla odpowiedzi nr 2

Po pierwsze, musisz zdecydować, czy ParamList będzie właścicielem ciągu znaków, czy tylko "wiedzieć o tym". Sposób, w jaki to napisałeś, z string& my_stringoznacza, że ​​ma on tylko uchwyt na cudzym łańcuchu. W takim przypadku modyfikacja ciągu znaków nie stanowi (większego) problemu, ponieważ ParamList nie jest jego właścicielem!

Jeśli chcesz, aby ParamList miał pełną kopię parametrów (zależy od problemu, który próbujesz rozwiązać), zrób coś takiego:

class ParamList{

public:
ParamList(const string& a_string); // do a strcpy in here.

const string& getString(); //returns my_string
void setString(const string& new_string); //do a strcpy here too.
private:
string my_string;
}

Zauważ, że lepiej jest raczej używać funkcji ustawiania i pobierania, niż zwracania odniesienia nie-const, tak aby ParamList mógł mieć trochę większą kontrolę nad modyfikowaniem jego członków.