Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

C.21 appears to mandate the Rule of Five -- is that desirable?

Aperta
  • Qualcosa non va?
#2,335 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
documentation

Direzione di ricerca

Inizia leggendo la regola C.21 attuale e il testo relativo all'applicazione, quindi esamina la discussione correlata in #2164 e i falsi positivi di clang-tidy citati. Confronta la formulazione proposta con la motivazione documentata e il comportamento precedente a C++11. Il lavoro è completato quando sono disponibili una decisione approvata da un maintainer e un testo aggiornato della linea guida, se viene accettata una modifica.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

See also #2164 where this issue is creating false positives in Guidelines checkers such as clang-tidy.

Problem

C.21 mandates the Rule of Five:

C.21: If you define or =delete any copy, move, or destructor function, define or =delete them all

[...]

Enforcement

(Simple) A class should have a declaration (even a =delete one) for either all or none of the copy/move/destructor functions.

Is that too strong?

  • Yes, this will catch some errors, as noted: "to avoid unwanted effects like turning all potential moves into more expensive copies, or making a class move-only." That's good.
  • But this will also require programmers to write redundant boilerplate for classes that don't need it, such as classes that have user-written copy operations where move cannot be more efficient than copy and the programmer knows that writing only copy will cause move to be treated as copy for their type and know that's okay. Programmers hate being told to make code changes that they know don't change meaning just to satisfy a tool, and it's the kind of thing that causes them to disable a rule as noisy / low-value.

Note: The current rule and Enforcement would flag every pre-C++11 class with a user-defined copy operation.

One potential suggestion

The main noise seems to come from requiring explicit move operations. One change that could address #2164 and pre-C++11 types and most of the required-boilerplate cases would be to not require writing out move operations. Something like this:

C.21: If you define or =delete any copy, move, or destructor function, define or =delete all copy and destructor operations

[...]

Enforcement

(Simple) A class should have a declaration (even a =delete one) for all copy/destructor functions if any copy/move/destructor function is user-declared.

We could also add a note along the lines of "and if you write a copy operation check whether you should also write a more-efficient move operation, to avoid turning all potential moves into more expensive copies" -- as a Note here, or as a separate guideline.

Lingua principale
CSS
Stelle
45.3k
Fork
5.6k
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di isocpp/CppCoreGuidelines

Tutte le issue di isocpp/CppCoreGuidelines

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.