Voila, j´ai un tableau pointé à deux dimensions, contenant un type structuré, mais quand je lance le programme, il Foire lorsque je met le malloc..

mon malloc donne:

for ( i=0;i<5;i++)
{
for ( j=0;i<4;j++)
{
groupes[i][j]=(struct Joueur*)malloc(sizeof(struct Joueur));
}
}

Quand je lance, il reste un instant et sort direct...

Quand j´enleve ce malloc, le reste du programme se poursuit, mais foire lorsque j´utilise justement ce tableau à deux dimensions...

Pourtant, juste au dessus, j´ai un malloc sur un tableau à 1 dim, et ça va correct :s

Aurais-je mal fait mon malloc

Il te faut faire un tab de ptr qui contiennent les adresses de tes structures. Je sais pas si tu l´as deja fait. Mais resoudre un bug sur trois lignes c´est durement possible.

on peut voir comment est ce que tu as déclaré groupes ? sans ça, on ne peut rien dire.

mais si tu as fait :

Joueur groupes[5][4];
alors le malloc est inutile.

Les malloc sur les tableaux à 2 dimensions, ca ce fait pas comme ca.

Par exemple pour un tableau d´int à 2 dimensions tu fait :

int** tableau;
int i;

tableau=(int**)malloc(NB_COLONNES*sizeof(int*));
for(i=0;i<NB_COLONNES;i++)
{
tableau[i]=(int*)malloc(NB_LIGNES*sizeof(int));
}

Mais comme dit dnob700, il faudrait qu´on sache comment t´as déclaré groupes pour pouvoir d´aider.

c´est deux approches différentes, toi tu alloues ton tableau ( et alors un * seul, avec offset pour l´acces, c´est bien aussi), alors que lui a un tableau dont il alloue chaque élément...

Difficile d´en dire plus sans savoir le but recherché :/

Moi je milite contre les tableaux a 2 dimensions
( c´est un choix perso)

tu peux faire ta matrice en 1 tableau en 1 dimension dans lequel l´élément x,y est défini par :

y*LARGEURMATRICE + x

enfin c´est évidemment un choix personnel.

JeanYvesYves !
Pourquoi es-tu contre les tableaux 2D? Par simple "impression" ou pour des raisons de performances, ou autres?

Toute façon c´est la façon d´ecrire qui change. C´est stocké de la meme manière en memoire je pense.

tout d´abord c´est chiant à initialiser, à manipuler, l´écriture ** n´est pas intuitive selon comment on considères ses données, etc. Donc entièrement d´accord avec JY², un tableau 1D avec offset, c´est bien mieux. D´autant plus qu´un tableau 1D, tu fais l´alloc mémoire en une passe, donc t´as un bloc continu ( bon, évidemment, si vous mettez en place une gestion de mem. avec des algos tordus...) ; alors qu´en version 2D, tu fais ton alloc en deux passes ( puisqu´en gros, t´as un tableau 1D de tableau 1D), donc tu as plusieurs morceaux de mémoire, qui peuvent ne pas etre continus. Meme si les performances ne s´en ressentent pas, merci pour la fragmentation :/

arf je sais ca fait longtemps que je ne suis pas passée et j´en profite pour vous souhaiter une excellente année 2005 à tous.
J´en profite aussi pour donner mon avis sur les tableaux à 2D. Moi ca ne me gêne pas tant que ça ne va pas à trois ou plus. Ben vi après j´ai du mal à comprendre la logique.

Wouhou Kilyn_ ! !!!! SAluttttt!!!
Merci, bonne année à toi aussi !
ça fait super longtemps que t´es pas passée c´est vrai! Tu m´a manqué!
Quoi dneuf? tu travailles toujours chez "Accenture technology solutions" ?

Ah ça fait plaisir de te voir

À tout le monde En ce qui me conerne, peu m´importe au niveau 2D/1D, mais je vais essayer la méthode de JYY, c vrai que ça a l´air moins lourd !

mais si t´alloue tout d´un coup genre :

int tableau[10][10];

dans ce cas là, je suppose que la mémoire est continu non ?

Rien y oblige, même si ça pourrait être le cas ( tous les tableaux se suivent à la queue-leu-leu).

Suppose si tu veux, c´est libre au compilo d´organiser ça

Kelios
---------

tiens j´ai une question simple qui m´est venu sur cdj : comment utiliser en c++ les double de 80 bits ( ou mieux) à la place de ceux de 64 bits qu´utilisent VC++ ?

si qqn à une idée, je lui serais reconnaissant.

Nativement, C++, VC++? Je crois pas que c´est possible...

J´vais voir sur la msdn, on sait jamais, mais pour VC6 je m´attend pas à des miracles...

J´en sais rien, . NET ou VC8 a peut-être, mais je m´attend pas à des miracles...

Le problème, c´est pas tant ça que le manque d´opérateurs appropriés...

Au pire, fuck le natif, tu te fais une grosse classe chaude et obèse, et ça roule...

Kelios
---------

Pour VC6 en tout cas:

( Tiré de la msdn Oct 2000):
Long Double
Previous 16-bit versions of Microsoft C/C++ and Microsoft Visual C++ supported the long double, 80-bit precision data type. In Win32 programming, however, the long double data type maps to the double, 64-bit precision data type. The Microsoft run-time library provides long double versions of the math functions only for backward compatibility. The long double function prototypes are identical to the prototypes for their double counterparts, except that the long double data type replaces the double data type. The long double versions of these functions should not be used in new code.

Double Functions and Their Long Double Counterparts
/ * ect. */

Et cepandant:
( Tiré de la msdn online):
Type long double

The range of values for a variable is bounded by the minimum and maximum values that can be represented internally in a given number of bits. However, because of Cs conversion rules ( discussed in detail in Type Conversions in Chapter 4) you cannot always use the maximum or minimum value for a constant of a particular type in an expression.

For example, the constant expression -32768 consists of the arithmetic negation operator ( ) applied to the constant value 32,768. Since 32,768 is too large to represent as a short int, it is given the long type. Consequently, the constant expression -32768 has long type. You can only represent 32,768 as a short int by type-casting it to the short type. No information is lost in the type cast, since 32,768 can be represented internally in 2 bytes.

The value 65,000 in decimal notation is considered a signed constant. It is given the long type because 65,000 does not fit into a short. A value such as 65,000 can only be represented as an unsigned short by type-casting the value to unsigned short type, by giving the value in octal or hexadecimal notation, or by specifying it as 65000U. You can cast this long value to the unsigned short type without loss of information, since 65,000 can fit in 2 bytes when it is stored as an unsigned number.

Microsoft Specific >

The long double contains 80 bits: 1 for sign, 15 for exponent, and 64 for mantissa. Its range is +/1.2E4932 with at least 19 digits of precision. Although long double and double are separate types, the representation of long double and double is identical.

END Microsoft Specific

Donc là, est-ce 80 bits, oui ou non? C,est supporté en 32 bits, oui ou non? Et puis, quesqu´ils entendent par " the representation of long double and double is identical" ? ?!

Kelios
---------

ben, la spécification de Intel donne au moins 3 type de nombre en virgule flottante :

les floats sur 50 bits et quelques, les double sur 64 bit et les extended double sur 80 bit.

ce qui est interessant c´est que sur les architecture pentium, le coprocesseur utilise des double de 80 bits seulement ( il convertit tout le reste en 80 bit).

donc on pourrait penser que même en utilisant les 64 bit de VC++ il ferait les calcul en 80 bit ( sauf àl´enregistrement). Mais après quelques test, on n´a pas plus de précision que celle des 64 bits.

VC++ lui n´utilise que du 64 bit, mais utilisé une lib qui " émulerait ça" n´aurait pas trop d´interet vu la vitesse qu´on y perdrait.

en fait je me demandais si en faisant de l´asm inline on peut utiliser les fonction 80 bits.
bon, ça va me prendre un peu de temps si on peut, mais tant pis, c´est interessant.

enfin merci pour ta réponse.

hihi MathieuN7 Oui je sais je réponds tardivement mais j´oublie souvent de revenir sur ce forum En effet je travaille toujours chez ATS et ca me fait pas vraiment plaisir. Un taf merdique, pas le droit de vouloir changer. La belle vie quoi !