Bonjour a tous et joyeux noel
Voila j'ai un probléme je voudrais mettre dans une variable poly 2 autres variables déclarées en int contenant par exemple 2 et 4. entre les 2 variables temp et stock déclarées en int je voufrais mettre en fixe "X^". donc poly doit donner 2X^4.
Comment dois je faire ?
Merci d'avance pour vos réponses.

C, C++ ?

ça serai en C.

je capte rien alors je me réfère au titre: strcat(destination, source) ou strncat(destination, source, taille_ma_destination) tout ca dans <string.h>

je comprends ça comme :
 
int temp = 2;
int stock = 4;
char poly[256];
 
sprintf(poly, "%dX^%d", temp, stock);

est bien mieux car plus sur

 
ca oci c est bien    
mais ca marche ke sous nunux  

ouais mais là c'est l'artillerie lourde puisque de asprintf fait appel à malloc

Je vous remercie tous pour vos réponses je vais tester ça de suite et je suis pas sous nunux.

 
---> Cygwin  

 
ça ne t'offre pas de garanties sur le résultat, c'est du code défensif et ça pue. Tu dois au minimum vérifier que ta chaine était assez longue et refaire une tentative jusqu'à ce que l'opération se soit déroulée correctement ou planter tout comme une grosse bouse (ce qui en C s'appelle abort()), mais surtout ne pas continuer avec un truc à moitié douteux (chaîne tronquée en l'occurence).
 
Ne fait pas de leçons sur des sujets que tu ne maîtrises pas.

je me tais parce que je connais pas la cmde
ms please poins d'agressivité  

voila: je rentre je tombe directe sur ton message et je suis de mauvaise humeur. je comprends pas trop pourquoi du code défensif est mauvais? et me prends pas pour plus bete je ne le suis: bien evidemment qu'on a interet à regarder le code de retour de snprintf pour s'assurer que tout s'est passé comme désiré

 
Ben pareil, j'étais encore en vacances quand je suis tombé là-dessus, ça m'a énervé ces conneries de nmachin. La bonne attitude n'est pas de faire un nmachin, la bonne attiude est de t'assurer que le résultat attendu est arrivé (c'est à dire te manger une exception si ça commence à chier), pas d'essayer de continuer dans n'importe quelles conditions.
Ne vous plaignez pas que les applications que vous utilisez tous les jours plantent alors que vous utilisez les techniques qui leurs ont permis de planter.
 
en savoir plus sur la qualité : http://www.eyrolles.com/php.inform [...] 091113.php il explique pourquoi c'est inutile et ralentissant (je sais, c'est étonnant) le code défensif ; c'est 400 balles bien placé, et crois-moi, c'est un mec qui a l'habitude de les placer au bar qui te le dit.
 
C'est marrant, mon prof de gestion de projet l'a eu comme prof pendant ses études en 1978, il parlait déjà de Z et de tous les trucs qui lui ont permit de faire avancer la qualité aujourd'hui (les études de mon prof, Meyer enseigne actuellement en Suisse après avoir fondé sa boite aux US).

tu captes rien ou quoi?
 
 
si t'es pas sure (et on ne l'ai jamais assez) que ton buffer soit assez grand, tu utlises snprintf qui t'evites une jolie erreur de segmentation. si snprintf t'indique qu'elle n'a pu imprimer autant d'élément que désiré, autrement dit que ton buffer était trop petit, tu n'as qu'a réalloué et ressayé. une fois que tout est bon, tu continues. Apres si tu as quelque chose à dire contre ça, c'est que vraiment on n'est pas sur la meme planete

 
Tu n'est pas sur la même planète. Les nfonctions permettent d'éviter des désagréments certains, mais on peut s'en passer. Mais sans être aussi extrémiste que nraynaud, je pense quand même qu'elles constituent un confort d'utilisation certain pour les utilisateurs.
 
Maintenant il est clair que compter sur elles pour éviter les débordements de buffer bien calibrés (c'est à dire qui font pas segfault, mais qui vont corrompre la pile et faire des choses douteuses, comme changer l'adresse de retour de la fonction en cours par exemple) n'est pas une bonne solution.

je comprends rien...
 
OK pour ton premier paragraphe: on peut s'en passer si on sait ce qu'on fait:
 
char buffer[100];
spirntf(buffer, "%d", 1);
 
doit apriori ne pas poser de problème.
 
mais alors pour ton deuxieme paragraphe, la je nage... Qu'est ce que tu entends par "pas compter sur elles" ? Evidemment si tu rentres un n qui ne correspond pas à la réalité...
 
EXpliquez moi, s'il vous plait, en quoi on peut critiquer ce code (extrait du man)
 

 
ton lien ne marche pas..
 
LeGreg

C'est la solution sûre, mais c'est aussi beaucoup pour un débutant, et ça amène d'autres problèmes:

• Pourquoi xmalloc, xrealloc ?
• Les allocations ne sont pas testées. C'est ça la différence x ?
• Il faudra penser à libérer la chaîne obtenue.
• Et si on ne veut pas d'allocation ?
• Quelle genre de gestion d'erreur veut-on ?

Bref, je préfères C++.

'tain bizarre, il marchait hier !
 
Conception et programmation objet de Bertrand Meyer chez eyrolles.

 
je ne critiquerais pas ce bout de code car il a largement plus qu'un simple nmachin, il fournit l'assurance que le snprintf aura  bien lieu jusqu'au bout de la chaine et ne sera pas tronqué, tu peux donc continuer ton programme sans crainte. Tu peux filer ta chaine à l'utilisateur (ce qui est parfois possible même avec une chaine tronquée) mais surtout la foutre dans un parser etc., ce que tu ne pourrais pas faire avec une chaine tronquée.

 
j'ai dit que c'était l'extrait du man. xmalloc et xealloc sont des wrapper de malloc et realloc qui stoppe le programme en cas d'échec (l'auteur de cette fonction s'est débarassé de cette façon du test de retour de malloc)
 
et si on veut pas d'allocation? on ferme sa gueule  et on croise les doigts
 
quant au C++, ici ce n'est pas la question
 
nraynaud> fo pas me prendre pour beaucoup plus con que je le suis  . ça sert à rien d'apprendre directement aux débutants à blinder leur code puisque la plupart s'en foutront pendant encore un bon moment . Je n'ai jamais dit qu'un nmachin faisait tout tout seul Démonstration est faite qu'on peut avoir un truc assez costaud