7
votes

autoriser uniquement le comportement défini en C ++?

est-il possible dans GCC / G ++ ou MS C ++ de définir un drapeau qui permet uniquement de comportement défini? alors quelque chose comme le ci-dessous me donne un avertissement ou de préférence une erreur xxx


6 commentaires

Je compile en utilisant g ++ -wall -ansi -peantic ou parfois g ++ -wall -weffc ++ -ansi -pedantic .


Je trouve -wnon-virtual-dtor indispensable aussi.


@Mark: Cela ne va pas attraper un comportement indéfini.


Je suis upvote la question à cause des réponses splendides. OT: La légende a-t-il une fois un compilateur qui a signalé que le compilateur n'a pas pu détecter aucune de vos erreurs 'au lieu de "0 erreurs, 0 avertissements"


@Mark B Il y a des cas où cela est parfaitement raisonnable; Les destructeurs protégés sont le cas évident.


Je trouve -error essentiel. Il traite tous les avertissements comme des erreurs. Vous forçant ainsi à corriger tous les avertissements avant que le code compile. (Remarque en plus de tous les drapeaux de @rob ci-dessus).


5 Réponses :


8
votes

Un comportement non défini et non spécifié est désigné de manière spécifique dans la norme, car elle pourrait entraîner une charge indue sur la mise en œuvre de diagnostiquer tous les exemples de celui-ci (ou qu'il serait impossible de déterminer).

On s'attend à ce que le programmeur veille à éviter ces zones non définies.

Pour votre exemple indiqué, il devrait être assez évident d'un programmeur pour tout simplement pas écrire ce code dans la première place .

qui étant dit, g ++ -wall attrapera un certain code, tel que le retour manquant dans une fonction non vides pour donner un exemple.

EDIT: @sehe fait également indiquer -Hante-point qui attrapera cette construction de code précise, bien que le point de séquence doit exister entre l'évaluation de chaque argument (l'ordre dans lequel des arguments sont évalués est non précisé toutefois).


0 commentaires

1
votes

Pendant que je suis d'accord avec la réponse de Mark, je pensais juste que je devrais vous faire savoir ... xxx

Lors de la compilation du code ci-dessus avec gcc -wall , i Obtenez les avertissements suivants: xxx

à cause de a ++ et ++ a , je suppose. Donc, dans une certaine mesure, cela a été mis en œuvre. Mais évidemment, nous ne pouvons pas nous attendre à ce que tout comportement non défini soit reconnu par le compilateur.


0 commentaires

2
votes

Cela m'a donné un bon rire. Désolé pour ça, ne voulait aucune infraction; C'est une bonne question.

Il n'y a pas de compilateur sur la planète qui permet uniquement de comportement défini à 100%. C'est la nature indéfinie des choses qui le rend si dur. Il y a beaucoup de cas abordés dans la norme, mais ils sont souvent trop vagues pour mettre en œuvre efficacement dans un compilateur.

Je sais que les développeurs de Clang ont montré un intérêt à ajouter cette fonctionnalité, mais ils n'ont pas Commencé aussi loin que je sache.

La seule chose que vous puissiez faire maintenant et dans l'avenir proches / loin, le niveau d'avertissement et le strictisme de votre compilateur. Malheureusement, même dans les versions récentes, MSVC est une douleur à cet égard. Sur le niveau d'avertissement 4 et plus, il crache des avertissements stupides qui n'ont rien à voir avec la correction du code, et vous devez souvent sauter à travers des cerceaux pour les amener à partir.

GCC est meilleur à cela dans mon expérience personnelle. J'utilise personnellement ces options, assurant les contrôles les plus stricts (je connais actuellement) xxx i

​​i bien sûr assurera des avertissements zéro, si vous voulez appliquer même cela, il suffit d'ajouter -WERROR à la ligne ci-dessus et toute erreur sera erronée. C'est surtout le std et Pedantic Options qui appliquent le comportement standard, wextra attrape quelques semi-erreurs hors probabilité.

Et bien sûr, compilez votre code avec différents compilateurs si possible (et assurez-vous qu'ils diagnostiquent correctement le problème en demandant ici, où les gens savent ce que la norme dit / signifie).


2 commentaires

Vous êtes manquant -wonversion !


Wow, tu as raison. Il a eu un cas d'un taille_t -> int conversion. Gotta love c ++ pour pédanterie :)



7
votes

gnu c ++ a ce qui suit

  -Wstrict-overflow

  -Wstrict-overflow

   -fstrict-aliasing
   -fstrict-overflow


1 commentaires

+1. Vous pouvez également utiliser -werror = point de séquence , donc g ++ refusera de le compiler.



3
votes

Non. Par exemple, envisagez les éléments suivants:

int badfunc(int &a, int &b) {
    return func(a++, b++);
}


0 commentaires