{"id":2078,"date":"2022-03-14T15:50:58","date_gmt":"2022-03-14T18:50:58","guid":{"rendered":"https:\/\/elemarjr.com\/cppmoderno\/?p=2078"},"modified":"2025-06-18T16:06:51","modified_gmt":"2025-06-18T19:06:51","slug":"a-regra-dos-cinco-apendice-d-v-1-0","status":"publish","type":"post","link":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/a-regra-dos-cinco-apendice-d-v-1-0\/","title":{"rendered":"A regra dos cinco \/ Ap\u00eandice D v 1.0"},"content":{"rendered":"

Em C++, uma classe deve ser respons\u00e1vel por gerenciar completa e eficientemente<\/span>\u00a0os recursos que referencia.<\/strong><\/p>\n

Mem\u00f3ria, threads<\/em>, conex\u00f5es com o banco de dados,\u00a0mutexes<\/em>, s\u00e3o apenas alguns exemplos de recursos, potencialmente escassos, que, uma vez alocados, se n\u00e3o forem adequadamente liberados, podem levar o ambiente produtivo a exaust\u00e3o. Pior ainda, se forem liberados “antes do tempo”, podem conduzir o programa a um comportamento inv\u00e1lido.<\/p>\nNos \u00faltimos anos, a gest\u00e3o da mem\u00f3ria, como recurso potencialmente escasso, em C++, ficou muito mais simples com o advento dos smart pointers<\/a><\/em>.<\/strong> Entretanto, o desafio ainda persiste para todos os demais tipos de recursos que demandam aloca\u00e7\u00e3o\/libera\u00e7\u00e3o.\n

\nC++, no lugar de ser “opinativa” (como outras linguagens) quanto a forma que recursos escassos devem ser gerenciados (adquiridos, mantidos e descartados), opta por dar controle total ao desenvolvedor.<\/strong> Essa decis\u00e3o certamente desagrada alguns e agrada muitos.\n
\n

Como pr\u00e1tica eficiente, nos \u00faltimos anos, convencionou-se que classes que precisam lidar com recursos potencialmente escassos devem implementar comportamentos especiais:<\/strong><\/p>\n

    \n
  1. Destrui\u00e7\u00e3o<\/strong> – liberando recursos sob “ger\u00eancia” do objeto;<\/li>\n
  2. Constru\u00e7\u00e3o com c\u00f3pia<\/strong>– evitando compartilhamento de controle sobre “recursos escassos” em objetos criados “copiando” um objeto existente;<\/li>\n
  3. Atribui\u00e7\u00e3o com c\u00f3pia <\/strong>– <\/em>evitando compartilhamento de controle sobre “recursos escassos” em objetos com valores copiados de\u00a0 um objeto existente;<\/li>\n
  4. Constru\u00e7\u00e3o com transfer\u00eancia<\/strong>– evitando aloca\u00e7\u00f5es desnecess\u00e1rias de recursos escassos, quando um objeto novo estiver sendo criado “copiando” dados de outro, pr\u00e9-existente, que n\u00e3o ser\u00e1 mais utilizado;<\/li>\n
  5. Atribui\u00e7\u00e3o com transfer\u00eancia <\/b>– evitando aloca\u00e7\u00f5es desnecess\u00e1rias de recursos escassos, quando um objeto estiver “copiando” dados de outro, pr\u00e9-existente, que n\u00e3o ser\u00e1 mais utilizado;<\/li>\n<\/ol>\n

    Destrui\u00e7\u00e3o<\/h2>\n
    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\" Se pegar emprestado, devolva, meu filho.<\/em>\r\n

    minha m\u00e3e<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    Comecemos com uma regra bem simples: se um objeto alocar qualquer\u00a0recurso potencialmente escasso, dever\u00e1 garantir sua libera\u00e7\u00e3o.<\/strong><\/p>\n

    #include <initializer_list>\r\n#include <iostream>\r\n\r\nclass Buffer {\r\npublic:\r\n  Buffer(const std::initializer_list<float>& values)\r\n          : _size{values.size()} {\r\n    _data_ptr = new float[values.size()];\r\n    std::copy(values.begin(), values.end(), _data_ptr);\r\n  }\r\n\r\n  auto begin() const { return _data_ptr; }\r\n  auto end() const { return _data_ptr + _size; };\r\n\r\n  ~Buffer() {\r\n    delete [] _data_ptr;\r\n    _data_ptr = nullptr;\r\n  }\r\n\r\nprivate:\r\n  size_t _size{0};\r\n  float* _data_ptr{nullptr};\r\n};\r\n\r\nint main() {\r\n  auto data = Buffer({1.0f, 2.0f, 3.0f, 4.0f, 5.0f}); \r\n\r\n  for (auto elem : data) {\r\n    std::cout << elem << std::endl;\r\n  }\r\n}\r\n<\/pre>\n
    No exemplo acima, mem\u00f3ria, um recurso escasso, \u00e9 alocada pelo construtor e liberada pelo destrutor.<\/p>\n
    Constru\u00e7\u00e3o com c\u00f3pia<\/h2>\n
    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\" N\u00e3o estrague o brinquedo do amiguinho.<\/em>\r\n
    minha m\u00e3e<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n
    A classe Buffer<\/code>, implementada no exemplo acima, parece estar fazendo “tudo certo” – ela “aloca” um determinado espa\u00e7o na mem\u00f3ria em sua inicializa\u00e7\u00e3o, no m\u00e9todo construtor, e “libera” mem\u00f3ria, mais tarde, ao sair de contexto, no m\u00e9todo destrutor. Entretanto, este c\u00f3digo n\u00e3o est\u00e1 protegido contra c\u00f3pias.<\/p>\n
    int main() {\r\n  auto data = Buffer({1.0f, 2.0f, 3.0f, 4.0f, 5.0f});\r\n\r\n  {\r\n    auto copy = data;\r\n  }\r\n\r\n  for (auto elem : data) {\r\n    std::cout << elem << std::endl;\r\n    \/\/ FAIL!\r\n  }\r\n}\r\n<\/pre>\n
    No c\u00f3digo acima, a vari\u00e1vel copy<\/code> recebe uma “c\u00f3pia” do objeto apontado em data<\/code>. Afinal, o programador fez a op\u00e7\u00e3o por realizar a aloca\u00e7\u00e3o na stack<\/em>. Assim, todas as refer\u00eancias presentes no objeto data<\/code>\u00a0s\u00e3o “replicadas” no objeto copy<\/code> e, infelizmente, ser\u00e3o destru\u00eddas assim que o contexto de copy<\/code> for encerrado – gerando comportamento inv\u00e1lido.<\/p>\n
    #include <initializer_list>\r\n#include <iostream>\r\n\r\nclass Buffer {\r\npublic:\r\n  Buffer(const std::initializer_list<float>& values)\r\n          : _size{values.size()} {\r\n    _data_ptr = new float[values.size()];\r\n    std::copy(values.begin(), values.end(), _data_ptr);\r\n  }\r\n\r\n  \/\/ copy constructor\r\n  Buffer(const Buffer& other) : _size{other._size} {\r\n    _data_ptr = new float[_size];\r\n    std::copy(other._data_ptr, other._data_ptr + _size, _data_ptr);\r\n  }\r\n\r\n  auto begin() const { return _data_ptr; }\r\n  auto end() const { return _data_ptr + _size; };\r\n\r\n  ~Buffer() {\r\n    delete [] _data_ptr;\r\n    _data_ptr = nullptr;\r\n  }\r\n\r\nprivate:\r\n  size_t _size{0};\r\n  float* _data_ptr{nullptr};\r\n};\r\n<\/pre>\n
    A sa\u00edda, como \u00e9 indicado no c\u00f3digo acima,\u00a0 \u00e9 implementar um construtor de c\u00f3pia que “duplica” as refer\u00eancias protegendo-as.<\/p>\n
    Eventualmente, outra alternativa seria “deletar” o construtor de c\u00f3pia tornando tal comportamento a c\u00f3pia n\u00e3o autorizada.<\/p>\n
    Buffer::Buffer(const Buffer& other) = delete;\r\n\r\nint main() {\r\n  auto data = Buffer({1.0f, 2.0f, 3.0f, 4.0f, 5.0f});\r\n\r\n  {\r\n    \/\/ No copies!\r\n    auto copy = data;\r\n  }\r\n\r\n  for (auto elem : data) {\r\n    std::cout << elem << std::endl;\r\n  }\r\n}\r\n<\/pre>\n
    Atribui\u00e7\u00e3o com c\u00f3pia<\/h2>\n
    C++ \u00e9 tremendamente eficiente em “poupar mem\u00f3ria”, mas, as vezes, essa “obsess\u00e3o” da linguagem acaba se revertendo em dor de cabe\u00e7a.<\/p>\n
    A implementa\u00e7\u00e3o da classe Buffer<\/code>, com um construtor de c\u00f3pia, ainda resulta em comportamento indesejado no c\u00f3digo que segue:<\/p>\n
    int main() {\r\n  auto data = Buffer({1.0f, 2.0f, 3.0f, 4.0f, 5.0f});\r\n\r\n  {\r\n    auto copy = data;\r\n    data = copy;\r\n  }\r\n\r\n  for (auto elem : data) {\r\n    std::cout << elem << std::endl;\r\n    \/\/ FAIL\r\n  }\r\n}\r\n<\/pre>\n
    No exemplo, ao reatribuir valor a vari\u00e1vel data<\/code>, no lugar de ser criada uma nova inst\u00e2ncia de Buffer<\/code>, C++, por padr\u00e3o, copia os valores de copy<\/code> para data<\/code>. Obviamente, o array<\/em> referenciado em copy<\/code> \u00e9 destru\u00eddo gerando comportamento potencialmente inesperado.<\/p>\n
    A sa\u00edda \u00e9 gerar uma sobrecarga do operador de atribui\u00e7\u00e3o.<\/p>\n
    #include <initializer_list>\r\n#include <iostream>\r\n\r\nclass Buffer {\r\npublic:\r\n  Buffer(const std::initializer_list<float>& values)\r\n          : _size{values.size()} {\r\n    _data_ptr = new float[values.size()];\r\n    std::copy(values.begin(), values.end(), _data_ptr);\r\n  }\r\n\r\n  \/\/ copy constructor\r\n  Buffer(const Buffer& other) : _size{other._size} {\r\n    _data_ptr = new float[_size];\r\n    std::copy(other._data_ptr, other._data_ptr + _size, _data_ptr);\r\n  }\r\n\r\n  \/\/ copy assignment\r\n  auto& operator=(const Buffer& other) {\r\n    delete [] _data_ptr;\r\n    _data_ptr = new float[other._size];\r\n    _size = other._size;\r\n    std::copy(other._data_ptr, other._data_ptr + _size, _data_ptr);\r\n    return *this;\r\n  }\r\n\r\n  auto begin() const { return _data_ptr; }\r\n  auto end() const { return _data_ptr + _size; };\r\n\r\n  ~Buffer() {\r\n    delete [] _data_ptr;\r\n    _data_ptr = nullptr;\r\n  }\r\n\r\nprivate:\r\n  size_t _size{0};\r\n  float* _data_ptr{nullptr};\r\n};\r\n<\/pre>\n
    Outra alternativa seria impedir atribui\u00e7\u00f5es.<\/p>\n
    auto& operator=(const Buffer& other) = delete;\r\n<\/pre>\n
    Constru\u00e7\u00e3o e atribui\u00e7\u00e3o com transfer\u00eancia<\/h2>\n
    Qual seria o resultado l\u00f3gico do c\u00f3digo abaixo?<\/p>\n
    void print(Buffer data) {\r\n  for (auto elem : data) {\r\n    std::cout << elem  < < std::endl;\r\n  }    \r\n}\r\n\r\nint main() {\r\n  print(Buffer({1.0f, 2.0f, 3.0f, 4.0f, 5.0f}));\r\n  return 0;\r\n}\r\n<\/pre>\n
    Por padr\u00e3o, o comportamento seria a cria\u00e7\u00e3o de um objeto na stack<\/em> associado a fun\u00e7\u00e3o main<\/code>que seria, imediatamente, copiado para um novo objeto na stack<\/em> associado a fun\u00e7\u00e3o print<\/code>.<\/p>\n
    Felizmente, quase todos os compiladores modernos reconhecem tal desperd\u00edcio e “evitam” a c\u00f3pia.<\/p>\n
    \r\n
    Use refer\u00eancias sempre que poss\u00edvel<\/p>\r\n<\/p>\n
    O c\u00f3digo a seguir possui s\u00f3 m\u00e9ritos.<\/strong> A fun\u00e7\u00e3o print<\/code> recebe uma refer\u00eancia somente leitura para um objeto.<\/p>\n
    void print(const Buffer& data) {\r\n  for (auto elem : data) {\r\n    std::cout << elem << std::endl;\r\n  }    \r\n}\r\n\r\nint main() {\r\n  auto data = Buffer({1.0f, 2.0f, 3.0f, 4.0f, 5.0f});\r\n  print(data);\r\n  return 0;\r\n}\r\n<\/pre>\n
    Sempre que poss\u00edvel utilize refer\u00eancias evitando c\u00f3pias desnecess\u00e1rias.<\/p>\n
    <\/div>\n
    Eventualmente, entretanto, o compilador n\u00e3o conseguira detectar tais desperd\u00edcios, competindo ao programador fazer a gest\u00e3o.<\/p>\n
    void print(Buffer data) {\r\n  for (auto elem : data) {\r\n    std::cout << elem << std::endl;\r\n  }    \r\n}\r\n\r\nint main() {\r\n  auto data = Buffer({1.0f, 2.0f, 3.0f, 4.0f, 5.0f});\r\n  print(std::move(data));\r\n  return 0;\r\n}\r\n<\/pre>\n
    No exemplo, utilizou-se std::move<\/code> como forma a indicar que o que se deseja fazer \u00e9 uma transfer\u00eancia de recursos escassos. Tal fun\u00e7\u00e3o, utiliza-se de implementa\u00e7\u00f5es de constru\u00e7\u00e3o e movimenta\u00e7\u00e3o por transfer\u00eancia para evitar desperd\u00edcios.<\/p>\n
    #include <initializer_list>\r\n#include <iostream>\r\n\r\nclass Buffer {\r\npublic:\r\n  Buffer(const std::initializer_list<float>& values)\r\n          : _size{values.size()} {\r\n    _data_ptr = new float[values.size()];\r\n    std::copy(values.begin(), values.end(), _data_ptr);\r\n  }\r\n\r\n  \/\/ copy constructor\r\n  Buffer(const Buffer& other) : _size{other._size} {\r\n    _data_ptr = new float[_size];\r\n    std::copy(other._data_ptr, other._data_ptr + _size, _data_ptr);\r\n  }\r\n\r\n  \/\/ move constructor\r\n  Buffer(Buffer&& other) : _size{other._size}, _data_ptr{other._data_ptr} {\r\n    other._data_ptr = nullptr;\r\n  }\r\n  \r\n  \/\/ copy assignment\r\n  auto& operator=(const Buffer& other) {\r\n    delete [] _data_ptr;\r\n    _data_ptr = new float[other._size];\r\n    _size = other._size;\r\n    std::copy(other._data_ptr, other._data_ptr + _size, _data_ptr);\r\n    return *this;\r\n  }\r\n  \r\n  \/\/ move assignment\r\n  auto& operator=(Buffer&& other) {\r\n    std::cout << \"move copy\";\r\n    _size = other._size;\r\n    _data_ptr = other._data_ptr;\r\n    other._data_ptr = nullptr;\r\n    return *this;\r\n  }\r\n  \r\n  auto begin() const { return _data_ptr; }\r\n  auto end() const { return _data_ptr + _size; };\r\n\r\n  ~Buffer() {\r\n    delete [] _data_ptr;\r\n    _data_ptr = nullptr;\r\n  }\r\n\r\nprivate:\r\n  size_t _size{0};\r\n  float* _data_ptr{nullptr};\r\n};\r\n<\/pre>\n
    Bem al\u00e9m da mem\u00f3ria…<\/h2>\n
    Todos os exemplos desse ap\u00eandice mostraram a aplica\u00e7\u00e3o da “regra dos cinco” em uma classe que gerenciava a mem\u00f3ria (um exemplo de recurso escasso). Entretanto, de todos os recursos, mem\u00f3ria \u00e9, potencialmente, o mais f\u00e1cil de gerenciar.<\/p>\n
    As coisas podem ficar realmente desafiadoras na gest\u00e3o de recursos como threads<\/em> que n\u00e3o podem ser simplesmente “duplicadas” ou transferidas. Da\u00ed a import\u00e2ncia de entender melhor cada cen\u00e1rio dar ao programador “poder para decidir”.<\/p>\n
    O compilador pode e deve ajudar, sempre que poss\u00edvel, a evitar enganos. Mas, nem s\u00f3 com receitas prontas s\u00e3o feitos programas, principalmente em systems programming<\/em>.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Em C++, uma classe deve ser respons\u00e1vel por gerenciar completa e eficientemente\u00a0os recursos que referencia. Mem\u00f3ria, threads, conex\u00f5es com o banco de dados,\u00a0mutexes, s\u00e3o apenas alguns exemplos de recursos, potencialmente escassos, que, uma vez alocados, se n\u00e3o forem adequadamente liberados, podem levar o ambiente produtivo a exaust\u00e3o. Pior ainda, se forem liberados “antes do tempo”, […]<\/p>\n","protected":false},"author":2,"featured_media":2121,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"hashtags":[],"tipo":[39],"url":[37],"apendices":[36],"capitulos":[],"class_list":["post-2078","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tipo-apendice","url-permanente","apendices-apendice-d"],"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/posts\/2078","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/comments?post=2078"}],"version-history":[{"count":43,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/posts\/2078\/revisions"}],"predecessor-version":[{"id":2122,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/posts\/2078\/revisions\/2122"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/media\/2121"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/media?parent=2078"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/categories?post=2078"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/tags?post=2078"},{"taxonomy":"hashtags","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/hashtags?post=2078"},{"taxonomy":"tipo","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/tipo?post=2078"},{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/url?post=2078"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/apendices?post=2078"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/cpp-moderno\/wp-json\/wp\/v2\/capitulos?post=2078"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}