Discussion :

[gusgus]

Bonjours.

J'ai un petit bout de code:

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
17
18
19
20
21
22
23
24
25
26
27
28
29
#ifndef PHYSICSHIP
#define PHYSICSHIP
 
#include "PhysicCommon.h"
 
class PhysicShip
{
 
public:
	PhysicShip(std::string mName,PhysicModule* mOwner,float radius,float mass);
	~PhysicShip();
 
	void AddForce(btVector3 mForce);
	btVector3 GetForces();
 
	void SetPosition(btVector3 mPosition);
	btVector3 GetPosition();
 
	std::string pName;
 
private:
	btCollisionShape* ShipShape;
	btRigidBody* ShipBody;
	btDefaultMotionState* pMotionState;
 
	PhysicModule* Owner;
};
 
#endif

qui me génère les erreurs suivantes:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
1>PhysicShip.cpp
1>c:\c++\lne\physicmodule\PhysicShip.h(13) : error C2719: 'mForce'*: le paramètre formel avec __declspec(align('16')) ne sera pas aligné
1>c:\c++\lne\physicmodule\PhysicShip.h(16) : error C2719: 'mPosition'*: le paramètre formel avec __declspec(align('16')) ne sera pas aligné
1>.\PhysicShip.cpp(29) : error C2719: 'mForce'*: le paramètre formel avec __declspec(align('16')) ne sera pas aligné
1>PhysicModule.cpp
1>c:\c++\lne\physicmodule\PhysicShip.h(13) : error C2719: 'mForce'*: le paramètre formel avec __declspec(align('16')) ne sera pas aligné
1>c:\c++\lne\physicmodule\PhysicShip.h(16) : error C2719: 'mPosition'*: le paramètre formel avec __declspec(align('16')) ne sera pas aligné
1>main.cpp
1>c:\c++\lne\physicmodule\PhysicShip.h(13) : error C2719: 'mForce'*: le paramètre formel avec __declspec(align('16')) ne sera pas aligné
1>c:\c++\lne\physicmodule\PhysicShip.h(16) : error C2719: 'mPosition'*: le paramètre formel avec __declspec(align('16')) ne sera pas aligné
1>Le journal de génération a été enregistré à l'emplacement "file://c:\C++\LNE\PhysicModule\Release\BuildLog.htm"
1>PhysicModule - 7 erreur(s), 0 avertissement(s)
========== Génération*: 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

C'est la premiere fois que je rencontre cette erreur,et j'ai pas vraiment compris les explications données sur le net, et j'avoue que je sait pas trop quoi faire....

Note:j'utilise VC 2008 express et btVector est une class de Bullet Physic.

[Charlemagne]

J'ai déjà vu cette erreur, mais uniquement sous visual 2003 pour l'utilisation de registras SSE(__m128,__m128i), alors que d'autres compilos ne voyaient pas de problème (ICL, GCC). Faudrait peut-être tester avec Visual 2005/2008.

Je ne comprend pas vraiment l'erreur. C'est visiblement lors du passage de paramètre d'une variable alignée en mémoire.

J'ai fait des passages de paramètres par référence constante plutôt que par copie, et ça a calmé Visual...

[ram-0000]

Une idée comme cela, le type btVector3 est déclaré quelque part avec des caractèristique d'alignement particulières.

Le compilateur te prévient peut être qu'il ne peut préserver ces caractèristiques lors d'un passage de paramètre par valeur.

Essaiye de transformer en :

Code :

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

void AddForce(const btVector3 & mForce);

Juste pour voir

[gusgus]

Merci a vous 2

Effectivement passer les parametres par reference calme Visual.

Mais pour moi ce n'est pas vraiment une solution, j'ai pas envie de me balader avec des pointeurs partout, et avoir un truc qui marche pas dans un programme et dont je comprend pas pourquoi, sa me fait un peu peur: et si le bug revient alors que le programme fait 5000 lignes?

J'avoue que je ne comprend pas tres bien ce que c'est l'alignement (je suis en train de lire un article dessus sur la msdn, mais je pige pas ), j'ai jamais vraiment fait de "bas" niveau en c++...

Edit: je vien de voir sa:
http://www.bulletphysics.com/Bullet/...tVector3+align

Donc effectivement il faut passer par reference.Merci

[Charlemagne]

L'alignement est très utile pour les instructions vectorielles SIMD (SSE,SSE2...) pour des raisons de performances. Sur les processeurs Intel, la lecture et l'écriture de données alignées sur 16 octets (la valeur hexadécimale de adresse finit par 0) sont bien plus rapides que pour des données non alignées.

Il faut donc généralement proscrire l'utilisation de "malloc" ou "new", si l'on compte utiliser les instructions SIMD.
L'utilisation de "__declspec(align(16))" permet de s'assurer de l'alignement sur la pile.

Mais Visual est le seul à voir un problème dans le passage de paramètres. Bizarre car l'alignement de la pile est sensé être maintenu par tout bon compilo...

[koala01]

Salut,
Pour te permettre de comprendre l'alignement :

Ce sera l'explication "simple", et donc, forcément incomplète et peut être pas tout à fait juste

Tu l'aura remarqué, les processeurs (dits "familiaux", car il existe d'autres architectures qui sont en 64 bits depuis bien longtemps ) travaillent avec un nombre de bits de plus en plus évelé: 16 à l'époque des 3x86, 32 depuis que l'on est passé au PI (ou était-ce le PII ), 64 depuis ces dernières années.

Cela correspond au nombre de bits (d'interrupteurs) qui sont utilisables par les différents "registres" (l'endroit où le processeur manipule réellement les données).

Ce nombre de bits est directement responsable des limites de valeurs que le processeur peut utiliser (qui se calcule par la formule 2^(nombre de bits)-1, éventuellement également répartis de chaque coté du 0 ).

Ce nombre va aussi (du moins, c'était le cas pour les processeurs 16 et 32 bits) influer sur... le nombre de bits qui séparent deux adresses mémoire accessibles contigue:

En effet, l'"idéal", c'est (ou du moins, c'était, avec les anciens processeurs) d'être en mesure de "remplire" directement le registre avec les informations qui se trouvent dans une seule adresse mémoire accessible...

Il en découle un problème tout simple: il faut que, quel que soit le nombre de bits nécessaire pour représenter une variable, le premier bit de la variable se trouve... à une adresse mémoire directement accessible...

Cela signifie que, si tu as une structure ou une classe, chaque membre de cette structure (ou de cette classe) doit... commencer à une adresse mémoire qui est accessible...

Il n'existe qu'une exception à cette règle: le cas où plusieurs variables d'un type identique se suivent, qu'il s'agisse de variable séparées sous la forme de
struct s
{
char a;
char b;
char c;
};
ou d'une variable qui représente un tableau d'éléments contigus en mémoire (les bon vieux tableaux "classiques" char tab[3]; )

Le phénomène d'alignement de la mémoire correspond au fait que, si le nombre de bits utilisés par une donnée est inférieur à l'espace qui sépare deux adresses mémoire contigues, ben, c'est bien simple, les bits "surnuméraires" (ou plutôt non utilisés par la donnée) sont, purement et simplement perdus.

Tu peux avoir un aperçu du phénomène avec un code proche de

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
17
18
19
20
21
22
23
24
struct S
{
    char a;
    char b;
    char c;
};
struct S2
{
    char a;
    char b;
    char c;
    int i;
};
int main()
{
    cout<< "taille d'un char :"<<sizeof(char)<<endl
        << "taille d'un entier :"<<sizeof(int)<<endl
        << "taille de S : "<<sizeof(S)<<" (3 char = "
        <<sizeof(char)*3<<")"<<endl
        << "taille de S2 : "<<sizeof(S2)<<" (3 char + 1 int= "
        << sizeof(char)*3+sizeof(int)<<")"<<endl;
    return 0;
 
}

qui, chez moi, donne la sortie

Code :

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

1
2
3
4
taille d'un char :1
taille d'un entier :4
taille de S : 3 (3 char = 3)
taille de S2 : 8 (3 char + 1 int= 7)

et qui montre que, chez moi, l'alignement se fait sur l'équivalent de 4 bytes, soit,8*4 = 32 bits (car, chez moi toujours, un byte est codé sur 8 bits )

PS j'avais promis une explication simple, pas courte

[3DArchi]

Salut,
Le problème a l'air connu par les gens de bullets. On trouve quelques entrées dans leur forum. J'ai regardé un peu en diagonal et un utilisateur recommande tout simplement de rajouter WIN32 dans les définitions du préprocesseur. Ce n'est peut être pas la solution appropriée. A toi de creuser

[gusgus]

Merci!

PS j'avais promis une explication simple, pas courte

Et est ce que cela cause de réels problèmes de performances?Je suis pas un accro des performances alors pour gagner un 10eme de milliesegonde ou 10 ko dans la memoire....(et je n'utilise pas les SMID(peut-être que je devrais...)).

Et sinon, concrètement, il y a plein de cas ou on peu pas aligner non? comment fait-on dans ces cas la?

Edit:3DArchi , tu a poster quand j'etait moi même en train de poster. Je pense que je vais simplement utiliser des references comme ce qui est préconiser dans le poste que j'ai cité sur Bullet. Mais je n'ai pas vu de topic qui préconise de rajouter win32... Tu a un lien?

[3DArchi]

J'ai fais une recherche sur leur site avec 'C2719' : j'obtiens ça.
C'est dans cette discussion, la dernière intervention. Mais, bon, j'ai lu en diagonale, donc à mon avis, tu as intérêt à creuser un peu.

[gusgus]

Merci!je vais creuser.

Bonne journée à vous tous.