Salut,
 
Comment faire pour déclararer un tableau à une dimention sans connaitre au départ sa dimension?
 
Merci a tous,
 

On utilise les sytemes d'allocations dynamiques proposés par la fonction malloc (cf man malloc)

de toute maniere, à part si c'est une chaine de caracteres, un tableau dont tu ne connais pas la dimension, est un tableau perdu, car en le parcourant, tu ne sais pas là où tu peux tomber dans la mémoire.
 
Edit : j'ai mal lu la question :
pour un tableua de "double" par exemple tu fait un "double *Tab = NULL;"
 
et quand tu connait la dimention, tu fait Tab = (double*)calloc(dimesion_du_tableau_,sizeof(double));

comment dire :
 

 
suffit largement

Et même, d'une façon générale :  

http://mapage.noos.fr/emdel/notes.htm#malloc
 

Pour résumer,  
 
Je déclare mon tableau de la façon suivante :
 
Je connais pas ma dimension, alors je met une taille maximum,
 
int NBMAX = 20000;
 
double TAB[]=NULL;
 
TAB = (double*)malloc(NBMAX*sizeof(double));
 
Est ce bien ça?

c'est du gachis

 
 
C'est à dire? Pourrais-tu développer?

Non. ce que t'as fait ne va pas changer grand chose a ca:
double TAB[20000]; !

Pour te donner un exemple, tu fait:
double *TAB;
int taille;
printf("Donnez la taille du tableau :" ); // ou un truc dans le genre.
scanf("%d", &taille); // bon utilise autre fonction que scanf() toi... ce n'ai qu'un exemple ça
TAB = malloc( taille * sizeof(double) );

pire. un scanf pourri et pas de vérification du retour de malloc.

Ce n'ai qu'un exemple pour lui montrer l'idée hein  ... je ne lui ai pas donner un code source d'un prog !

Je lui ai préciser en commentaire de ne pas utiliser le scanf() , je ne le fait que pour l'exemple rapide.

Aparement notre ami yak6942 viens de faire connaissance avec malloc donc il devra lire la doc ou un petit cours sur l'utilisation de malloc, où il est certainement indiqué qu'il faut faire une vérification du retour de malloc

Non. Tu mets une taille raisonnable.

Pas du C.

On se tue à dire que le cast est inutile...
 
Je pense que tu n'as rien compris aux réponses. Il faut que tu relises tout et que tu poses des questions précises si nécessaire.
 

Qui ça on ?

http://forum.hardware.fr/hfr/Progr [...] m#t1510834
http://forum.hardware.fr/hfr/Progr [...] m#t1510843

Moi, j'appelle ça d'une façon C-narrow-minded.
 

issus du lien :
"Le compilateur n'est pas C mais par exemple pré-C++98"
Pourquoi pré-C++98 ?
 
"D'autre part, en C++98, un cast se fait avec static_cast<...>"
Non, en C++98, certains casts se font avec static_cast<>, mais pas tous.

Tant qu'on est dans les critiques :

Faut updater la date
 
(par contre pour le static_cast, il parle du cas du malloc, oui y'en a d'autres mais pas utilisés dans le cas d'un malloc)

Le contexte n'est pas mentionné dans la phrase en tout cas. Et je ne vois pas l'intérêt d'utiliser static_cast sur le retour d'un malloc. Il y a notament le C-cast qui convient pour cela.

d'un autre coté, je vois pas l'utilité d'utiliser malloc en c++

Paske je m'a fais eu Le gus a posté dans la cat. C

Ben malheureusement, si tu ne connais pas au-moins sa dymension il n'y a rien à faire...  
 

Pour résumer, 2 cas possibles
1) la taille "T" ne dépend pas de toi mais d'une donnée externe (lue dans un fichier, un capteur, un truc que tu ne connais pas quand tu écris le programme)
Alors:
tu déclares juste un pointeur => double *tab;
 
Puis, au moment de ton programme où tu connais enfin la taille "T", tu alloues la mémoire dont t'as besoin => "tab=malloc (T * sizeof(double))" ou bien "tab=malloc(T * sizeof(*tab))"
 
Enfin, quand tu n'as plus besoin de "tab", tu libères la mémoire => free(tab)
 
2) la taille "T" dépend de toi mais elle peut varier parce que tu fais évoluer ton programme (aujourd'hui t'as besoin de 50 doubles, demain ce sera 500, dans 3 ans ce sera 5000) mais, comme le dit Emmanuel, cela ne dépassera jamais une certaine taille "raisonnable" (style ce ne sera jamais 4Go)
Alors:
tu écris une macro avec un nom représentatif => #define TAILLE_MAX      50
 
Puis tu définis ton tableau avec cette macro comme taille => double tab[TAILLE_MAX]
Puis, partout où t'as besoin de balayer ton tableau, tu fais une boucle de 0 jusqu'à TAILLE_MAX
 
Le jour où tu dois le passer de 50 à 500, tu modifies simplement ta macro et tu recompiles
 
OU BIEN (certains n'aiment pas les macro car il y a danger que tu prennes un nom déjà utilisé par les headers officiels => conflit)
tu définis une constante avec un nom représentatif => const unsigned short taille_max=50
 
Puis tu fais comme au dessus mais tu utilises la constante "taille_max" au lieu de la macro "TAILLE_MAX"

3) Tu utilises les VLA (une extension C99).  
void f( size_t n )
{
    int tab[ n ];
    // la mémoire est libérée à la fin de la portée directement englobante de "tab".
}

j'ai un peu tendance à ne pas montrer ça aux débutants ...

Pas implémentée sur gcc... (status : "broken" )
 
http://gcc.gnu.org/gcc-4.1/c99status.html

En effet, ce n'est implémenté que partiellement. Lorsqu'il y a un risque, GCC emet un warning.
Si l'on utilise pas la construction T[ * ], j'ai l'impression que GCC est OK.

Je suis le seul à trouver ça choquant de bouffer 160 000 bytes sur la stack pour un beau tableau?
S'il y a quelques appels de fonctions imbriqués avec pour chacune ce genre de déclarations, ça promet. (Ne parlons meme pas de récursivité ou du jour ou ça passera de #define NBMAX 20000 à #define NBMAX 200000.....)
 
Edit : Ce qui me fait réagir, c'est que vous vous faites plaisir à disserter de l'inutilité du cast, sans éclairer le gars qui pose sa question (de toute évidence débutant) sur un point bien plus critique (stack vs heap).

Personnellement, je parlais de mémoire dynamique, alors la pile...

Et là, tu es conscient d'utiliser les VLA, et pas de la meilleure manière.

Et bien quitte à réagir, va jusqu'au bout, et expose au PO tes lumières.

http://fr.wikipedia.org/wiki/Alloc [...] C3%A9moire
 
Pour aller un peu plus loin, la pile est une ressource limitée qu'il vaut mieux éviter de gaspiller. Au dela de quelques dizaines (voire centaines) d'éléments dans un tableau (suivant la taille de chaque élément), il est préférable d'utiliser l'allocation sur le tas plutot que sur la pile.
 
On parle souvent de portabilité du code sur ce forum; écrire des fonctions avec comme postulat que la pile fait plusieurs centaines de Ko, c'est le début des ennuis.

euh c'est pas comme si on lui vait deja donner la soluce avec malloc :|