Discussion :

[BioKore]

Bonjour à tous,

Dans le but de pratiquer un peu, je me propose de réaliser une bibliothèque permettant de réaliser des calculs vectoriels de base.
Je suis donc parti sur des structures du genre :

Code :

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

1
2
3
struct vec3 {
	float x,y,z;
};

et un fonctionnement similaire pour les tenseurs.

Accéder aux valeurs de la structure via les opérateurs '.' est une bonne chose. Cependant, de manière à faciliter un peu les claculs ultérieurs, je souhaiterais pouvoir accéder aux différentes variables (x, y, z) via l'opérateur [] où, vec[0] retourne x, vec[1] retourne y etc... Idem pour les tenseurs: mat[0][0] retourne xx, mat[0][1] retourne xy etc..
L'objectif est donc, comme présenté précédemment, de simplifier les algorithmes, mais aussi de laisser la possibilité à l'utilisateur d’appeler les valeurs soit via vec.x soit via vec[0].

Je me suis dit que ce type de fonctionnement devais être trivial dans le sens où vec.x est sensé être à l'adresse &vec, vec.y est sensé être à l'adresse &vec+sizeof(float) etc... Mais visiblement, je dois ajuster mon approche car *(&vec+sizeof(float)) est de type vec3 et non float.

Sans nécessairement me souffler la solution, une idée de la direction à prendre pour que je puisse répondre à ma problématique ?

Merci d'avance.

---

EDIT :

Comme à mon habitude, poster mon message ici m'a apporté la réponse : "pourquoi diable coller un sizeof au milieu de tout ça ???"

Réponse :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
struct vec3 {
	float x{.0f};
	float y{.0f};
	float z{.0f};
 
	float & operator[](size_t const id) {
		return *(&x+id);
	}
};

ceci fonctionne.

[dalfab]

Code :

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

1
2
3
4
5
6
7
8
9
struct vec3 {
	float x{.0f};
	float y{.0f};
	float z{.0f};
 
	float & operator[](size_t const id) {
		return *(&x+id);
	}
};

ceci fonctionne.

Ceci peut sembler fonctionner. Mais rien n'impose au compilateur de placer les x, y et z dans cet ordre.

La capacité d'avoir un accès par index est intéressante, le seul moyen sûr serait de créer le tableau et d'y accéder par des alias:

Code :

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

1
2
3
4
5
6
struct vec3 {
	float tab[3] = {.0f,.0f,.0f};
	float& x = tab[0];
	float& y = tab[1];
	float& z = tab[2];
};

Sauf que là le compilateur même s'il optimise en ne créant rien pour x,y et z (car ce sont des alias qui accèdent directement aux éléments du tableau), la structure devient de fait non copiable car contient des références. Et en plus le compilateur peut garder les 3 variables.
Ce que je ferais serait d'utiliser x, y et z sous le forme de fonctions.

Code :

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

1
2
3
4
5
6
struct vec3 {
	float tab[3] = {.0f,.0f,.0f};
	float& x() { return tab[0]; }
	float& y() { return tab[1]; }
	float& z() { return tab[2]; }
};

[BioKore]

Je me disais bien qu'il devais tout de même y avoir un kwak quelque part

Par contre, j'ai cru comprendre que les éléments d'une structure sont contigus. Suivant ce raisonnement, pourquoi le compilateur viendrait mettre du désordre la-dedans ?

Sinon la méthode proposée me plait bien (avec les alias). Pour pallier au problème de la "copie" une surcharge du constructeur par copie devrait pouvoir tout remettre dans l'ordre non ?


Merci encore.

[dalfab]

Par contre, j'ai cru comprendre que les éléments d'une structure sont contigus. Suivant ce raisonnement, pourquoi le compilateur viendrait mettre du désordre la-dedans ?

Tu as raison, d'ailleurs aucun compilateur à ma connaissance ne s'amuse à changer l'ordre, d'autant que la construction doit se faire dans l'ordre de déclaration (et la destruction dans l'ordre inverse). Ta solution a donc un risque très minime. on pourrait ajouter un static_assert( &y == &x + 1 );static_assert( &z == &x + 2 ); pour se protéger de dérives. Cette méthode reste peut-être à préférer!

Sinon la méthode proposée me plait bien (avec les alias). Pour pallier au problème de la "copie" une surcharge du constructeur par copie devrait pouvoir tout remettre dans l'ordre non ?

Oui, il suffit certainement de les écrire. Mais je viens de faire un essai et l'optimiseur persiste à conserver 3 pointeurs dans la structure et en plus il s'en sert; ce qui crée une augmentation de taille et une indirection gênante.

Malgré le risque de non portabilité, ta solution me semble donc meilleure.

[koala01]

Salut,

la structure devient de fait non copiable car contient des références.

Bah, ca, c'est encore assez facile à résoudre.

Bien sur, il y a la possibilité de définir son propre constructeur (sans oublier son propre opérateur d'affectation), mais il y a peut-être même encore plus simple, car, le véritable problème vient du fait que, dans l'état actuel, tab n'est pas copiable

Donc, si on s'arrange pour changer cet état de fait, par exemple, en utilisant une forme proche de

Code :

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

1
2
3
4
5
6
7
8
9
struct Vec3{
public:
    float & operator[](size_t index){
        assert(index <3  && "index out of bound"); //essayer d'accéder à un indice trop élevé est une erreur de programmation
        return tab[index]; 
   }
private:
    std::array<float, 3> tab;
};

Après, il est vrai que l'inclusion du fichier <array> sera invasive (comme l'inclusion de n'importe quel fichier d'en-tête dans un autre fichier d'en-tete), avec tout ce que cela comporte en termes d'augmentation du temps de compilation

Mais, en termes de facilité, on ne trouvera rien de plus simple

Comme souvent en C++, il faut être conscient que ce que l'on gagne d'un coté, on a de fortes chances de le perdre d'un autre. En l'occurrence, je m'abstiendrai donc bien de plaider pour une forme plutôt qu'une autre, d'autant plus qu'elles sont "assez facilement" interchangeables.

Je me limite donc à proposer une alternative viable à un problème donné, en te laissant seul juge de celle que tu préfères

[BioKore]

De souvenir, glm permet le même emploi que j'attends ; j'ai bien essayé de voir ce à quoi ça ressemblait dans le code mais... Je pense avoir encore besoin de beaucoup de pratique avant de pouvoir comprendre l'implémentation des vecteurs de cette bibliothèque (d'autant plus que, pour glm, les formats doivent être compatibles avec gls non ?).

Dans un premier temps, je vais continuer avec "ma" méthode. Je ferais évoluer là chose selon le besoin.


Merci pour ces retours !

[Médinoc]

Plutôt qu'une manipulation de pointeurs qui n'est pas garantie marcher, je préférerais passer par un switch qui lui, le serait:

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct vec3 {
	float x{.0f};
	float y{.0f};
	float z{.0f};
 
	float & operator[](size_t const id) {
		switch(id) {
			case 0: return x;
			case 1: return y;
			case 2: return z;
			default: throw std::domain_error("Seules les valeurs 0, 1 et 2 sont acceptées.");
		}
	}
}

[BioKore]

Oui !

Effectivement, en passant un peu de temps dans les codes de GLM, je retrouve ce type de fonctionnement.
Quel est l'avantage de passer par ce système ? n'est-ce pas plus "gourmand" en terme de ressources (tout est relatif) ?

Sinon, je profite de ce petit retour pour poser cette question par rapport au code de GLM, comment s'utilisent les templates du genre :

Code :

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

1
2
3
4
5
6
7
 
namespace glm
{
	template<typename T, qualifier Q>
	struct vec<4, T, Q>
	{ 
//...

C'est la première fois que je vois une écriture comme struct<...>{};. Quelqu'un sait m'expliquer comment cela fonctionne ? Car je trouve ça plutôt pratique de pouvoir différencier les objets via le <...> plutôt que directement par le nom.
J'ai essayé de créer une structure du même type pour des essais mais le compilateur me dit que ma structure n'est pas une class template...


Merci !

---

Ok, un simple template<size_t N, typename VT> struct vec; fait l'affaire Mais est-ce le meilleur moyen d'en arriver là ?
A voir. En tout cas, j'arrive à faire fonctionner mes vecteurs.

Merci encore !