Introdução
O C ++ trata variáveis de tipos definidos pelo usuário com semântica de valores . Isso significa que os objetos são copiados implicitamente em vários contextos, e devemos entender o que "copiar um objeto" realmente significa.
Vamos considerar um exemplo simples:
class person
{
std::string name;
int age;
public:
person(const std::string& name, int age) : name(name), age(age)
{
}
};
int main()
{
person a("Bjarne Stroustrup", 60);
person b(a); // What happens here?
b = a; // And here?
}
(Se você está intrigado com a name(name), age(age)peça, isso é chamado de lista de inicializadores de membros .)
Funções-membro especiais
O que significa copiar um personobjeto? A mainfunção mostra dois cenários distintos de cópia. A inicialização person b(a);é realizada pelo construtor de cópia . Seu trabalho é construir um novo objeto com base no estado de um objeto existente. A atribuição b = aé realizada pelo operador de atribuição de cópia . Seu trabalho geralmente é um pouco mais complicado, porque o objeto de destino já está em algum estado válido que precisa ser tratado.
Como não declaramos nem o construtor de cópias nem o operador de atribuição (nem o destruidor), eles são implicitamente definidos para nós. Citação do padrão:
O construtor de cópias e o operador de atribuição de cópias, [...] e o destruidor são funções-membro especiais. [ Nota : A implementação declarará implicitamente essas funções de membro para alguns tipos de classe quando o programa não as declarar explicitamente.
A implementação os definirá implicitamente se eles forem usados. [...] nota final ] [n3126.pdf seção 12 §1]
Por padrão, copiar um objeto significa copiar seus membros:
O construtor de cópia definido implicitamente para uma classe não-união X executa uma cópia de membro de seus subobjetos. [n3126.pdf seção 12.8 §16]
O operador de atribuição de cópia definido implicitamente para uma classe não-união X executa a atribuição de cópia em membros dos seus subobjetos. [n3126.pdf seção 12.8 §30]
Definições implícitas
As funções-membro especiais definidas implicitamente personsão assim:
// 1. copy constructor
person(const person& that) : name(that.name), age(that.age)
{
}
// 2. copy assignment operator
person& operator=(const person& that)
{
name = that.name;
age = that.age;
return *this;
}
// 3. destructor
~person()
{
}
Cópia em membros é exatamente o que queremos neste caso:
namee agesão copiados, para obter um personobjeto independente e independente . O destruidor definido implicitamente está sempre vazio. Isso também é bom neste caso, pois não adquirimos nenhum recurso no construtor. Os destruidores dos membros são chamados implicitamente após a conclusão do persondestruidor:
Após executar o corpo do destruidor e destruir quaisquer objetos automáticos alocados dentro do corpo, um destruidor da classe X chama os destruidores dos membros diretos de X [n ]126.pdf 12.4 §6]
Gerenciando recursos
Então, quando devemos declarar explicitamente essas funções-membro especiais? Quando nossa classe gerencia um recurso , ou seja, quando um objeto da classe é responsável por esse recurso. Isso geralmente significa que o recurso é adquirido no construtor (ou passado para o construtor) e liberado no destruidor.
Vamos voltar no tempo ao C ++ pré-padrão. Não havia tal coisa std::string, e os programadores estavam apaixonados por indicadores. A personclasse pode ter se parecido com isto:
class person
{
char* name;
int age;
public:
// the constructor acquires a resource:
// in this case, dynamic memory obtained via new[]
person(const char* the_name, int the_age)
{
name = new char[strlen(the_name) + 1];
strcpy(name, the_name);
age = the_age;
}
// the destructor must release this resource via delete[]
~person()
{
delete[] name;
}
};
Ainda hoje, as pessoas ainda escrevem aulas nesse estilo e se metem em problemas: " Eu empurrei uma pessoa para um vetor e agora tenho erros de memória loucos! " Lembre-se de que, por padrão, copiar um objeto significa copiar seus membros, mas copiar o namemembro apenas copia um ponteiro, não a matriz de caracteres que ele aponta! Isso tem vários efeitos desagradáveis:
- Alterações via
apodem ser observadas via b.
- Uma vez
bdestruído, a.nameé um ponteiro pendente.
- Se
afor destruído, a exclusão do ponteiro danificado gera um comportamento indefinido .
- Como a tarefa não leva em consideração o que foi
nameapontado antes da tarefa, mais cedo ou mais tarde você terá vazamentos de memória por todo o lugar.
Definições explícitas
Como a cópia em membros não tem o efeito desejado, devemos definir explicitamente o construtor de cópias e o operador de atribuição de cópias para fazer cópias profundas da matriz de caracteres:
// 1. copy constructor
person(const person& that)
{
name = new char[strlen(that.name) + 1];
strcpy(name, that.name);
age = that.age;
}
// 2. copy assignment operator
person& operator=(const person& that)
{
if (this != &that)
{
delete[] name;
// This is a dangerous point in the flow of execution!
// We have temporarily invalidated the class invariants,
// and the next statement might throw an exception,
// leaving the object in an invalid state :(
name = new char[strlen(that.name) + 1];
strcpy(name, that.name);
age = that.age;
}
return *this;
}
Observe a diferença entre inicialização e designação: precisamos desmembrar o estado antigo antes de designar namepara evitar vazamentos de memória. Além disso, temos que nos proteger contra a atribuição automática do formulário x = x. Sem essa verificação, delete[] nameexcluiria a matriz que contém a cadeia de origem , porque quando você escreve x = x, ambas this->namee that.namecontêm o mesmo ponteiro.
Exceção de segurança
Infelizmente, esta solução falhará se new char[...]lançar uma exceção devido ao esgotamento da memória. Uma solução possível é introduzir uma variável local e reordenar as instruções:
// 2. copy assignment operator
person& operator=(const person& that)
{
char* local_name = new char[strlen(that.name) + 1];
// If the above statement throws,
// the object is still in the same state as before.
// None of the following statements will throw an exception :)
strcpy(local_name, that.name);
delete[] name;
name = local_name;
age = that.age;
return *this;
}
Isso também cuida da auto-atribuição sem uma verificação explícita. Uma solução ainda mais robusta para esse problema é o idioma de copiar e trocar , mas não abordarei os detalhes de segurança de exceção aqui. Mencionei apenas exceções para enfatizar o seguinte: Escrever aulas que gerenciam recursos é difícil.
Recursos não copiáveis
Alguns recursos não podem ou não devem ser copiados, como identificadores de arquivo ou mutexes. Nesse caso, simplesmente declare o construtor de cópias e o operador de atribuição de cópias como privatesem fornecer uma definição:
private:
person(const person& that);
person& operator=(const person& that);
Como alternativa, você pode herdar boost::noncopyableou declarar como excluído (no C ++ 11 e acima):
person(const person& that) = delete;
person& operator=(const person& that) = delete;
A regra de três
Às vezes, você precisa implementar uma classe que gerencia um recurso. (Nunca gerencie vários recursos em uma única classe, isso só causará problemas.) Nesse caso, lembre-se da regra de três :
Se você precisar declarar explicitamente o destruidor, o construtor de cópias ou o operador de atribuição de cópias, provavelmente precisará declarar explicitamente todos os três.
(Infelizmente, essa "regra" não é imposta pelo padrão C ++ ou por qualquer compilador que eu conheça.)
A regra dos cinco
A partir do C ++ 11, um objeto possui 2 funções-membro especiais extras: o construtor de movimentação e a atribuição de movimentação. A regra dos cinco estados para implementar essas funções também.
Um exemplo com as assinaturas:
class person
{
std::string name;
int age;
public:
person(const std::string& name, int age); // Ctor
person(const person &) = default; // Copy Ctor
person(person &&) noexcept = default; // Move Ctor
person& operator=(const person &) = default; // Copy Assignment
person& operator=(person &&) noexcept = default; // Move Assignment
~person() noexcept = default; // Dtor
};
A regra do zero
A regra de 3/5 também é conhecida como regra de 0/3/5. A parte zero da regra declara que você tem permissão para não escrever nenhuma das funções especiais de membro ao criar sua classe.
Adendo
Na maioria das vezes, você não precisa gerenciar um recurso por conta própria, porque uma classe existente, como std::stringjá faz isso por você. Basta comparar o código simples usando um std::stringmembro com a alternativa complicada e propensa a erros usando ae char*você deve estar convencido. Desde que você fique longe dos membros brutos do ponteiro, é improvável que a regra dos três diga respeito ao seu próprio código.
c++-faqwiki tag antes de votar para fechar .