Discussion :

[oodini]

Bonjour,

J'ai une fonction d'API qui attend en paramètre un float[][4].

Je lui envoie un pointeur float*, et Visual C++ m'envoie bouler :
impossible de convertir le paramètre 1 de 'float *' en 'double [][4]'

Y aurait-il quelque chose qui m'a échappé ?

Merci.

[poukill]

Les types sont incompatibles entre eux !
Un float* n'a rien à voir avec un float[][4] !

Exemple d'un code qui fonctionne :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
void fonction (float test[][4])
{
	std::cout << "fonction" << std::endl;
}
 
int main()
{
	float var[2][4];
	fonction(var);      
}

[oodini]

Le problème avec ton code est que je ne connais pas la taille d'une des dimensions du tableau lors de la déclaration. Je dois donc utiliser des pointeurs.

Comment devrais-je donc déclarer et allouer mon pointeur pour qu'il corresponde à un tableau bidimensionnel ?

Merci.

[Montag]

Salut,

Tu peux faire quelque chose comme:

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
#include <iostream>
 
using namespace std;
 
 
 
void test(float tab[][4])
{
 
  cout << tab[5][3] << endl;
 
  return;
 
}
 
 
int main(void)
{
 
  float (*tab) [4]=NULL;
 
  tab=new float [10][4];
  tab[5][3]=12;
  test(tab);
  delete tab;
 
  return 0;
 
}

[oodini]

Merci !

Et pour la ligne suivante :

Code :

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

float (*tab) [4]=NULL;

y a-t-il moyen de déclarer une variable membre float*, et de retomber par la suite ce que tu m'as suggéré par une affectation qui précise le type du pointeur ?

[r0d]

Tout ceci est du C.

En c++, on utilisera une classe/structure et et conteneur. Par exemple:

Code :

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

1
2
3
4
5
6
struct QuatreFloat
{
    float tab[4];
};
 
std::vector<QuatreFloat> monTableau;

Ca peut paraitre plus compliqué, à premiere vue, qu'un tableau "C style" à 2 diñension , mais en fait le c++ fourni tant d'outil pour manipuler une telle structure qu'au final l'utilisation est plus simple, plus sure, souvent plus rapide, etc.

[oodini]

Ouaip, mais la fonction de l'API que j'utilise demande un float[][4] (alors que c'est une API C++...).

Si tu veux déplacer ma question dans la section du C, je n'y verrai aucun inconvénient.

[Montag]

Merci !

Et pour la ligne suivante :

Code :

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

float (*tab) [4]=NULL;

y a-t-il moyen de déclarer une variable membre float*, et de retomber par la suite ce que tu m'as suggéré par une affectation qui précise le type du pointeur ?

Je n'ai pas bien compris ce que tu veux faire, pourrais-tu donner un exemple.

[oodini]

Je crois que j'ai trouvé mon bonheur sur la page suivante :

http://c-faq.com/aryptr/ary2dfunc3.html
(notamment le lien en bas de page)

Je suis en train d'appliquer ce qui est expliqué, et j'arrive à quelque chose comme :

Code :

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

1
2
3
4
5
 
float **mCVs;
mCVs = (float **)malloc(rows * sizeof(float *));
for(int i = 0; i < rows ; i++)
	mCVs[i] = (float *)malloc(4 * sizeof(float));

Je devrais ensuite pouvoir envoyer mCVs en tant que paramètre d'une fonction qui attend un float[][4].

[Médinoc]

Sauf que c'est complètement du C, et surtout ça ne donne pas un tableau de tableaux mais un tableau de pointeurs vers des tableaux.

Absolument pas ce qu'il faut pour une fonction demandant un float (*)[4].

[Médinoc]

Je propose:

Code C++ :

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

1
2
3
4
5
6
typedef float QuatreFloat[4];
std::vector<QuatreFloat> monTableau;
 
//Et pour montrer que ça marche,
//cette ligne devrait compiler:
float (*ptr)[4] = &monTableau[0];

Ainsi tu profites de la fonctionnalité des vecteurs et tu as vraiment un tableau de float[4]...

[poukill]

Ouaip, mais la fonction de l'API que j'utilise demande un float[][4] (alors que c'est une API C++...).

Une API C++ prend cette chose en paramètre ? Je demande à voir !

[befalimpertinent]

Je viens bien comprendre que l'API demande un float [][4] sortit d'on ne sait où mais de là à utiliser des mallocs ...

[Médinoc]

Je confirme.
La seule raison qui pousserait à utiliser malloc() serait que la bibliothèque fasse un free() sur le pointeur passé. Et ce serait une mauvaise raison, car toute resource allouée par un module doit être désallouée par le même module.

[poukill]

Oui, tout ça est particulièrement sale...

On peut savoir quelle API demande ça ?

[r0d]

Des noms, des noms!!!

Si tu veux déplacer ma question dans la section du C, je n'y verrai aucun inconvénient.

Bah je ne sais pas trop... si c'est une API c++...

[oodini]

Oui, tout ça est particulièrement sale...

On peut savoir quelle API demande ça ?

Il s'agit d'Autodesk Maya, dans la classe MPointArray :
http://www.kxcad.net/autodesk/maya/M...ointArray.html
Comme vous pourrez le voir, le tableau passé en paramètre est destiné à être rempli par les fonctions (par get(), par exemple).

Le but est de transformer ce tableau d'instances de classe MPoint (4 coordonnées) en un tableau unidimensionnel de flottants.

Ne leur jetez pas la pierre : je dois justement envoyer toutes ces données à une autre API, qui est C, celle-là...

[poukill]

Ouais m'enfin un tableau de points, je l'aurai plutôt écrit :

Code :

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

std::vector< std::pair<T, T> > m_TableauPoints;

L'interface n'est quand même pas top top... Après si ça convient, tant mieux...

[oodini]

Je ne me souviens pas avoir vu une seule fois dans cette API une quelconque dépendance à la STL. Sans doute un choix politique...

Par ailleurs, comme je dois envoyer les données à une API C, passer par la STL m'obligerait à dupliquer les données. Elles seraient donc présentes 3 fois en mémoire :

1 - Dans la scène Maya
2 - Dans la structure de données utilisant la STL
3 - Dans l'espace mémoire que j'envoie à l'API C

La RAM étant un problème crucial dans les scènes 3D, ce n'est pas plus mal de bosser sur ces structures de données primitives...