Comment dois-je traiter avec “signé/non signé” incompatibilité de mises en garde (C4018)?

Je travaille avec beaucoup de code de calcul écrit en C++ avec la haute performance et faible surcharge de la mémoire à l'esprit. Il utilise des conteneurs STL (surtout vector) beaucoup, et parcourt que les conteneurs presque dans chaque fonction.

L'itération du code ressemble à ceci:

for (int i = 0; i < things.size(); ++i)
{
    //...
}

mais il produit de la signé/non signé incompatibilité avertissement (C4018 dans Visual Studio).

Remplacement int avec certains unsigned type est un problème parce que nous avons souvent l'utilisation d'OpenMP pragmas, et il faut le compteur à int.

Je suis sur le point de supprimer les (centaines de) mises en garde, mais j'ai peur, j'ai perdu un peu de solution élégante à ce problème.

Sur les itérateurs. Je pense que les itérateurs sont grands lorsqu'il est appliqué dans les endroits appropriés. Le code que j'ai travaille avec la volonté de jamais changer d'accès aléatoire de conteneurs dans les list ou quelque chose (donc itération avec int i est déjà conteneur agnostique), et toujours besoin de l'index en cours. Et le code que vous avez besoin de type (itérateur lui-même et l'index) juste complique les choses et dissimule la simplicité du code sous-jacent.

Pouvez-vous poster un exemple où le pragma OpenMP ne vous empêche à l'aide d'un type non signé? Selon ceci cela devrait fonctionner pour tout intergal type, pas seulement int.
Je crois que cette question est mieux pour stackoverflow.
int et std::vector<T>::size_type peut aussi être différente de la taille ainsi que dans ce paramètre. Par exemple, sur un LLP64 système (comme Windows 64 bits), sizeof(int) == 4 mais sizeof(std::vector<T>::size_type) == 8.
double possible de acceptable correctif pour la majorité des signed/unsigned mises en garde?
double possible de stackoverflow.com/questions/8188401/...
Cochez cette suggestion visualstudio.uservoice.com/forums/121579-visual-studio-ide/...

InformationsquelleAutor Andrew T | 2011-04-19

c++refactoring

52

C'est dans votre things.size() type. Il n'est pas int, mais size_t (il existe en C++, en C), ce qui équivaut à une certaine "habitude" type non signé, c'est à dire unsigned int pour x86_32.

Opérateur "moins" (<) ne peut être appliqué à deux opérandes de signe différent. Il n'y a tout simplement pas de ces opcodes, et la norme ne spécifie pas, si le compilateur peut faire implicite signe de conversion. Jusqu'à ce qu'il traite signé nombre non signés et émet un avertissement.

Il serait correct de l'écrire comme
```
for (size_t i = 0; i < things.size(); ++i) { /**/ }
```
ou même plus vite
```
for (size_t i = 0, ilen = things.size(); i < ilen; ++i) { /**/ }
```
- -1 non, il n'est pas size_t. Son est std::vector< THING >::size_type.
- Pendant que vous êtes techniquement correct, il est difficile d'imaginer comment une conforme aux normes de mise en œuvre pourrait se retrouver avec des sous-jacents différents types de std::size_t et std::vector<T>::size_type.
- pourquoi est - ++ - je être considéré comme le meilleur? Pour des boucles n'est pas là ", pas de" différence?
- ce n'est pas grave du tout pour les primitives où la valeur de retour n'est pas utilisé. Cependant, pour types personnalisés (où l'opérateur est surchargé), post incrément est presque toujours moins efficace (puisque c'est de faire une copie de l'objet avant qu'il a été incrémenté). Les compilateurs ne peut pas (nécessairement) optimiser pour les types personnalisés. Donc, le seul avantage est la cohérence (de primitives vs types personnalisés).
- dépend de l'allocateur utilisé. Si la valeur par défaut de l'allocateur (std::allocator<T>) est utilisé, alors size_type == std::size_t. Pour personnalisé allocateurs, size_type pourrait être autre chose que std::size_t.
- Oui, vous avez raison. Ma déclaration ne vaut que pour la valeur par défaut de l'allocateur. Un allocateur personnalisé peut utiliser autre chose que std::size_t, mais je crois qu'il serait encore à un unsigned type intégral, et il ne pourrait probablement pas représenter une plus grande portée que les std::size_t, donc c'est encore sûr à utiliser std::size_t que le type pour un indice de boucle.
- Je suis pas clair ce que l'on entend par cette partie de la réponse: "la norme ne spécifie pas[...] si le compilateur peut faire implicite de la conversion des signes." La norme exige la conversion ("[I]f l'opérande qui a unsigned integer a rang supérieur ou égal au rang de la catégorie de l'autre opérande, l'opérande de type entier signé doit être converti dans le type de l'opérande de type entier non signé.")
- pourquoi est-ilen = les choses.size(); i < ilen; plus rapide que i<choses.size() ???
InformationsquelleAutor
13

Idéalement, je voudrais utiliser une construction comme ceci à la place:
```
for (std::vector<your_type>::const_iterator i = things.begin(); i != things.end(); ++i)
{
  //if you ever need the distance, you may call std::distance
  //it won't cause any overhead because the compiler will likely optimize the call
  size_t distance = std::distance(things.begin(), i);
}
```
Cela a un très net avantage que votre code devient tout à coup un conteneur agnostique.

Et en ce qui concerne votre problème, si certains de bibliothèque que vous utilisez vous oblige à utiliser int où un unsigned int serait un meilleur ajustement, de leur API est en désordre. De toute façon, si vous êtes sûr que ces int sont toujours positifs, vous pouvez juste faire:
```
int int_distance = static_cast<int>(distance);
```
Qui permettra de préciser clairement votre intention de le compilateur: il ne sera pas vous embêter avec des avertissements plus.
- J' toujours besoin de la distance. Peut-être static_cast<int>(things.size()) pourraient être les solutions, si il n'y a pas d'autres.
- Si vous décidez de supprimer l'avertissement, le meilleur moyen serait probablement utiliser un compilateur spécifique pragma (sur MSVC ce sera un #pragma warning(push) #pragma warning(disable: 4018) /* ... function */ #pragma warning(pop)) plutôt que d'utiliser une inutile de fonte. (Jette cacher légitime erreurs, m'kay? 😉 )
- Pas vrai. Fonte != la conversion. L'avertissement est d'avertissement au sujet d'une conversion implicite est permis par la norme qui peut être dangereux. Un plâtre, cependant, invite les conversions explicites à la partie qui peut être plus dangereux que ce qui avait été parlé par l'avertissement. Strictement parlant, au moins sur x86, pas de conversion qui va arriver à tous -- le processeur ne se soucient pas si vous traitez une partie spécifique de mémoire, signés ou non, tant que vous utilisez les bonnes instructions à travailler avec elle.
- Lors du conteneur-agnostique causes O(N^2) complexité (et dans votre exemple, il n', que la distance() est O(N) pour une liste<>), je ne suis pas si sûr, c'est un avantage :-(.
- C'est exactement le point: on ne peut pas en être sûr. Si l'OP a quelques éléments, alors il est probablement plus grande. Si il a des millions de personnes, probablement pas tellement. Seulement le profilage peut dire à la fin, mais les bonnes nouvelles sont: vous pouvez toujours optimiser le code faciles à gérer!
InformationsquelleAutor ereOn
7

Si vous ne pouvez pas/ne pas utiliser des itérateurs et si vous ne pouvez pas/ne pas utiliser std::size_t pour l'indice de boucle, faire un .size() à int la fonction de conversion des documents de l'hypothèse et de la conversion explicite silence l'avertissement du compilateur.
```
#include <cassert>
#include <cstddef>
#include <limits>

//When using int loop indexes, use size_as_int(container) instead of
//container.size() in order to document the inherent assumption that the size
//of the container can be represented by an int.
template <typename ContainerType>
/* constexpr */ int size_as_int(const ContainerType &c) {
    const auto size = c.size();  //if no auto, use `typename ContainerType::size_type`
    assert(size <= static_cast<std::size_t>(std::numeric_limits<int>::max()));
    return static_cast<int>(size);
}
```
Ensuite, vous écrivez votre boucle comme ceci:
```
for (int i = 0; i < size_as_int(things); ++i) { ... }
```
L'instanciation de ce modèle de fonction sera presque certainement être insérée. Dans les versions de débogage, l'hypothèse sera vérifiée. Dans les versions release, il ne sera pas et le code sera aussi rapide que si vous l'avez appelé size() directement. Ni la version produira un message d'avertissement du compilateur, et c'est une légère modification de la idiomatiques boucle.

Si vous voulez attraper l'hypothèse échecs dans la version ainsi, vous pouvez remplacer l'affirmation d'une instruction if qui jette quelque chose comme std::out_of_range("container size exceeds range of int").

Noter que cela résout à la fois le signed/unsigned de comparaison ainsi que le potentiel sizeof(int) != sizeof(Container::size_type) problème. Vous pouvez laisser tous vos messages d'avertissements activés et les utiliser pour attraper les vrais bugs dans d'autres parties de votre code.

InformationsquelleAutor Adrian McCarthy

Vous pouvez utiliser:

type size_t, pour supprimer les messages d'avertissement
itérateurs + distance (comme le sont la première allusion)
uniquement des itérateurs
fonction de l'objet

Par exemple:

//simple class who output his value
class ConsoleOutput
{
public:
ConsoleOutput(int value):m_value(value) { }
int Value() const { return m_value; }
private:
int m_value;
};
//functional object
class Predicat
{
public:
void operator()(ConsoleOutput const& item)
{
std::cout << item.Value() << std::endl;
}
};
void main()
{
//fill list
std::vector<ConsoleOutput> list;
list.push_back(ConsoleOutput(1));
list.push_back(ConsoleOutput(8));
//1) using size_t
for (size_t i = 0; i < list.size(); ++i)
{
std::cout << list.at(i).Value() << std::endl;
}
//2) iterators + distance, for std::distance only non const iterators
std::vector<ConsoleOutput>::iterator itDistance = list.begin(), endDistance = list.end();
for ( ; itDistance != endDistance; ++itDistance)
{
//int or size_t
int const position = static_cast<int>(std::distance(list.begin(), itDistance));
std::cout << list.at(position).Value() << std::endl;
}
//3) iterators
std::vector<ConsoleOutput>::const_iterator it = list.begin(), end = list.end();
for ( ; it != end; ++it)
{
std::cout << (*it).Value() << std::endl;
}
//4) functional objects
std::for_each(list.begin(), list.end(), Predicat());
}

InformationsquelleAutor

3

Je peux également proposer la solution suivante pour le C++11.
```
for (auto p = 0U; p < sys.size(); p++) {
}
```
(C++ n'est pas assez intelligent pour auto p = 0, de sorte que je dois mettre p = 0U....)
- +1 pour le C++11. À moins qu'il y est un bon raison pour laquelle vous ne pouvez pas utiliser le C++11, je pense qu'il est préférable d'utiliser les nouvelles fonctionnalités... ils sont censés être d'une grande aide. Et certainement utiliser for (auto thing : vector_of_things) si vous n'avez pas besoin de l'index.
- Mais qui résout uniquement le problème de ce paramètre. Cela n'aide pas si size() retourne un type plus grand que unsigned int, ce qui est extrêmement commun.
InformationsquelleAutor Stepan Yakovenko
3

Je vais vous donner une meilleure idée
```
for(decltype(things.size()) i = 0; i < things.size(); i++){
//...
}
```
decltype est

Inspecte le type déclaré de l'entité ou le type et la valeur de la catégorie
d'une expression.

Donc, Il en déduit le type de things.size() et i sera un type comme même que things.size(). Donc,
i < things.size() sera exécuté sans aucun avertissement

InformationsquelleAutor Daniel
1

J'ai eu un problème similaire. À l'aide de size_t ne fonctionnait pas. J'ai essayé l'autre qui a travaillé pour moi. (ci-dessous)
```
for(int i = things.size()-1;i>=0;i--)
{
//...
}
```
InformationsquelleAutor Karthik_elan

Je voudrais juste faire

int pnSize = primeNumber.size();
for (int i = 0; i < pnSize; i++)
cout << primeNumber[i] << ' ';

InformationsquelleAutor Don Larynx

Vous devez vous connecter pour publier un commentaire.