Bonjour,
Je souhaiterai pouvoir acquérir un texte de taille inconnu (grande en générale), je ne peux donc pas utiliser un tableau qui demande d'entrer une taille avant meme de la connaitre . La solution réside surement dans les pointeurs utilisés avec de l allocation dynamique mais j'avoue ne pas savoir l utiliser, je pensais faire un truc du style

merci

eu, sizeof text == sizeof(void*)
 
utilise un gros buffer ? et stocke tes lignes dans une sequence de string allouées dynamiquement
 
fputs("entrez le texte  : ", stdout);
fflush(stdout);

Si t'es sous Linux => man getline  
Sinon, tu fais du "fgetc" en boucle en stockant le caractère dans un tableau qui s'agrandit continuellement (realloc) => dans ce cas je te conseille d'allouer par blocs de "n" octets

t'as le droit d'utilise fgets tu sais ... tant que ça termine pas par un '\n', ben tu concatène/realloc.

sizeof sur un pointeur, ça va pas le faire... Tu dois définir une taille, allouer le bloc, faire le fgets(), surveiller tes niveaux, reallouer si nécessaire... C'est pas trivial mais c'est faisable.
 
Personnellement, j'ai reglé le problème définitivement (sauf bug):
 
http://mapage.noos.fr/emdel/clib.htm
Module IO et FSTR
fonctions get_line()
 
cette fonction pend des lignes de tailles quelquonques. elle retourne l'adresse de la ligne (à libérer un jour...)
 
Pour faire un tableau de lignes automatique:
 
http://mapage.noos.fr/emdel/clib.htm
Module FARR... (Flexible ARRay) Un peu subtil (code générique), mais bien pratique aussi...

 C'est a dire avec Malloc j'alloue pour une taille N et si le texte est plus grand je reallou de N ainsi de suite ?

realloue avec realloc (tu peux egalement allouer avec realloc pour simplifier le code, voir le man) et a chaque depassement de capacite realloue par bloc de N

Avant que le dépassement de capacité ne se produise...

 
Ou mieux, à la manière d'un std::vector C++, par bloc de 2N. N étant le nombre d'éléments alloué précédemment.

http://mapage.noos.fr/emdel/clib.htm
Module IO et FSTR
fonctions get_line()
 

 
ouai, moins de reallocation mais plus de perte en memoire, et realloc n'implique pas forcement copie + deplacement, mais tu as raison

edit

Tiens je me suis posé la question ya pas longtemps à propos du realloc, donc quand c'est possible un realloc ne fait pas de copie + déplacement ? même chose en C++ pour un std::vector quand c'est possible alors je suppose ? je suppose aussi que c'est dépendant de l'implémentation ?

pour realloc c'est dis dans les specification, l'adresse retourné est celle du buffer qui peut avoir été déplacé et la strategie de reallocation de std::vector est comme ++fab l'a dis

 
En C, après un realloc, il ne faut pas s'appuyer sur le fait que parfois, il n'y aura pas copie + déplacement. Notament si tu as des pointeurs (pointants la ou tu veux réallouer) , ils peuvent etre rendu invalides suite à un realloc.
 
En C++, avec std::vector, c'est encore plus traitre. Un accroissement de std::vector (quelqu'en soit la cause) est susceptible d'invalider des itérateurs.
Pour prévoir l'accroissement d'un std::vector, tu ne peux meme pas t'appuyer (de manière totalement portable) sur la stratégie d'allocation du "2*N". --> reserve()

normal, y a plein d'implémentation qui n'utilise pas 2 comme facteur, mais quelque chose proche du nombre d'or.

Tiens, ca m'interesserait de savoir en quoi le nombre d'or est un bon choix. Ou alors c'est juste du au fait qu'ils font Taille[n] = Taille[n-1] + Taille[n-2] parce que c'est simple, et qu'il se trouve que le rapport Taille[n]/Taille[n-1] tend alors vers le nombre d'or ?

Taille[n] = Taille[n-1] + Taille[n-2]
 
et hop, ça te permet d'allouer n en réutilisant les trucs précédemment alloués avec une peu de chance