Compréhension -Weffc++

Considérons le programme suivant:

#include <string>

struct S {
    S (){}

private:
    void *ptr = nullptr;
    std::string str = "";
};

int main(){}

Ce, lorsqu'il est compilé avec -Weffc++ sur GCC 4.7.1, va cracher:

avertissement: 'struct S' a pointeur de données des membres de la [-Weffc++] 
avertissement: mais ne remplace pas S '(const S&)' [-Weffc++] 
avertissement: ou 'operator=(const S&)' [-Weffc++]

Qui ne pose pas de problème normalement, sauf pour un couple de choses avec cet exemple:

  1. Si je commente peu importe le constructeur, le pointeur de la déclaration, ou de la chaîne de déclaration, l'avertissement disparaît. C'est étrange parce que vous pensez que le pointeur serait suffisant, mais il n'est pas. En outre, la modification de la chaîne de déclaration d'un entier de la déclaration de causes à la disparition, alors qu'il vient seulement quand il y a une chaîne de caractères (ou probablement d'autres choix de classes). Pourquoi ne l'avertissement disparaît dans ces circonstances?
  2. Souvent cet avertissement s'affiche lorsque tous le pointeur est en train de faire est de pointage d'une variable existante (le plus souvent maintenu par le système d'exploitation). Il n'y a pas new, et pas de delete. Lorsque la classe avec la poignée, dans ces cas, est copié, je ne veux pas d'une copie en profondeur. Je veux les deux poignées pour pointer vers le même objet interne (comme une fenêtre, par exemple). Est-il possible de faire le compilateur de réaliser cela sans se surcharger inutilement le constructeur de copie et l'opérateur d'affectation, ou de la désactivation de l'avertissement complètement avec #pragma? Pourquoi suis-je dérangé, en premier lieu, lorsque la Règle de Trois n'a même pas l'appliquer?

OriginalL'auteur chris | 2012-07-16

  1. 5

    1. Quand vous le faites, vous avez un POD de la structure. Comme il ne peut pas tous les constructeurs, -Weffc++ ne prend pas la peine de vérifier.

    2. Utiliser une référence ou shared_ptr objet ou tout autre objet qui enveloppent un pointeur.

    J'ai pensé qu'il pourrait être quelque chose comme ça pour le #1. Mais pour le #2, je n'ai jamais vraiment vu ou imaginé le de les utiliser pour les descripteurs utilisés pour interagir avec le système. En passant le pointeur autour est tout ce que vous faites; vous pouvez la traiter comme si elle n'est pas un pointeur à tous, comme tout ce qui est important, c'est l'adresse qu'il points de, pas ce qui est là. Un handle de fenêtre est techniquement un void *. L'utilisation va quelque chose comme HWND hwnd = CreateWindow (...); ShowWindow (hwnd, SW_SHOW); Chaque pointeur aspect est pris en charge déjà; c'est un peu comme c'est déjà un pointeur intelligent. Que faites-vous dans ce cas?
    Ne sais pas quoi HWND mais si c'est un pointeur et que vous avez CreateWindow, vous avez probablement appeler DestroyWindow os quelque chose. Alors c'est le bon endroit pour shared_ptr<HWND> avec DestroyWindow lié à un destructeur, il n'est pas, -Weffect n'est pas pour vous.
    Oui, c'est l'un des nombreux objets stockés en tant que void *. Le plus drôle, c'est que DestroyWindow est généralement ce que les rend la poignée de la fenêtre hors de portée. D'autres pourraient ne pas vous obliger à appeler quelque chose pour les supprimer. La chose à propos de shared_ptr<HWND> est que c'est comme un HWND *, ce qui est inutile. Il devrait être plus comme un shared_ptr<void>, mais les poignées ne sont pas quelque chose que vous déréférencement ou quoi que ce soit. Dans ce cas, les pointeurs peuvent être considérés comme des variables normales.
    Ouais, ça ressemble à HWND est pas conçu pour le C++. De toute façon est toujours une bonne idée d'envelopper les anciennes structures C dans certaines classes, à faire du C++ plus efficace. Le protip est que la classe joue un rôle dans la modélisation conceptuelle.
    Oui, la plupart de la winapi est C. Le problème est lorsque vous enroulez dans les classes, mais depuis qu'ils sont techniquement des pointeurs, l'avertissement de coups de pied dans les indésirables.

    OriginalL'auteur Arpegius

  2. 20

    Du CCG -Weffc++ a plusieurs problèmes, je ne l'utilise jamais. Le code qui vérifie la présence de "problèmes" est assez simpliste et donc les mises en garde à la fin trop brutale et inutile.

    Cette alerte est basée sur l'Article 11 de la première édition de Effective C++ et Scott l'a changé (pour le mieux) dans les éditions ultérieures. Le G++ code ne vérifie pas pour les réels de l'allocation dynamique, seulement la présence de pointeur membres.

    Voir ce que j'ai écrit au sujet de cet avertissement dans GCC de bugzilla lorsque l'on compare les lignes directrices de la première édition avec la troisième édition:

    Article 11: Définir un constructeur de copie et un opérateur d'affectation pour les classes avec
    la mémoire allouée dynamiquement.

    Remplacé par l'Article 14: "Réfléchir sur la copie de comportement dans
    ressources-la gestion de classes" - l'avis est moins précis, mais plus utile. Je suis
    pas sûr de savoir comment le transformer en un avertissement si!

    Un autre problème avec Weffc++: Avoir un non-destructeur virtuel sur un privé de la classe de base n'est pas autorisé, pour aucune bonne raison.

    OriginalL'auteur Jonathan Wakely