Discussion :

[yan]

Pourtant, c'est le cas.
Pourquoi ça ne le saurait pas ?

ben a premier vu, parcourir un tableau directement et plus rapide que de le parcourir par des fonctions (cas du std::vector). Aprés je peut me trompé, mais meme les iterator sont pas de vrai "pointeur" (accés plus lent) et je n'ai jamais vu, pour du traitement d'image, une seule lib qui utilise le std::vector pour son buffer. Ou meme pour des partie les plus optimisé d'un code. Donc pour moi, les vector encapsule un tableau, il est donc plus lent du a l'accés par des fonctions. Par contre il est plus securisé.

[Laurent Gomila]

Tout peut être correctement inliné (même les opérations sur les itérateurs), donc cela revient strictement aux mêmes opérations que tu aurais faites sur ton tableau brut. Donc tu peux t'attendre à n'avoir aucune perte de performance après une compilation optimisée.

[yan]

Tout peut être correctement inliné (même les opérations sur les itérateurs), donc cela revient strictement aux mêmes opérations que tu aurais faites sur ton tableau brut. Donc tu peux t'attendre à n'avoir aucune perte de performance après une compilation optimisée.

voici le code de l'operateur [] pour le vector de VC8

reference operator[](size_type _Pos)
{ // subscript mutable sequence
_SCL_SECURE_VALIDATE_RANGE(_Pos < size());
return (*(_Myfirst + _Pos));
}

comme il y as "_SCL_SECURE_VALIDATE_RANGE(_Pos < size());" a chaque appel (inline ou non)
Pour moi c'est plus lent mais plus securisé.

[Jean-Marc.Bourguet]

comme il y as "_SCL_SECURE_VALIDATE_RANGE(_Pos < size());" a chaque appel (inline ou non) Pour moi c'est plus lent mais plus securisé.

Regarde un peu comment c'est defini.

[yan]

Regarde un peu comment c'est defini.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#define _SCL_SECURE_VALIDATE_RANGE(cond)				\
	{													\
		if (!(cond))									\
		{												\
			_ASSERTE((#cond, 0));						\
			_SCL_SECURE_OUT_OF_RANGE_NO_ASSERT;			\
		}												\
		__analysis_assume(cond);						\
	}

il y as bien au moin test

[Laurent Gomila]

Tu n'es pas remonté suffisamment loin. Cette macro ne fait quelque chose que si la macro _SECURE_SCL est définie à 1. Tu peux donc n'activer ces tests supplémentaires que lorsque tu le souhaites (genre en mode debug). Dans le cas contraire le code ne comportera aucune instruction superflue.

[yan]

a ok.
j'ai rien dit.
merci (enfin une reponse claire)

[Zbouirf]

petit détail mais qui accelerera un peu tes boucles "for" : utilise "++i" plutot que "i++". Pourquoi ?
car l'operateur de post incrementation realise plus d'operations que l'operateur de pre incrementation et utilise une variable temporaire. Voici leur implementation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
class X
{
public:
    X & operator++(void) // pré incrémentation
    {
         *this+=increment;
         return *this;
    }
    const X operator++(int) // post incrémentation
    {
          const X temp=const_cast<const X>(*this); // copie de l’objet dans son état actuel
          operator++(); // pre incrementation
          return temp;
    }
};

[Laurent Gomila]

Ca ne fera quand même aucune différence sur les types primitifs.