Pb : plus con tu meurs [C] - C++ - Programmation
Marsh Posté le 08-11-2001 à 15:42:00
test est une commande Unix
essaye ./test pour exécuter
ou utilises un autre nom
[edtdd]--Message édité par jupiler--[/edtdd]
Marsh Posté le 08-11-2001 à 15:43:12
je meurt .......
desolais
return un 0 et fait un ./test pour demarer ou utilise un autre nom
merde grillaid
[edtdd]--Message édité par koulip31--[/edtdd]
Marsh Posté le 08-11-2001 à 15:44:30
koulip31 a écrit a écrit : je meurt ....... merde grillaid |
Marsh Posté le 08-11-2001 à 15:52:17
merci les gars
Marsh Posté le 08-11-2001 à 16:10:39
avec "\n" a la fin de la chaine ca marchera mieux.....
bah oui, quand tu lui dit d ecrire a partir d un buffer (ton "coucou" ), il y a une taille min avant que le buffer soit affiche
le "\n" arrange tout.....
Marsh Posté le 08-11-2001 à 16:33:02
tomate77 a écrit a écrit : avec "\n" a la fin de la chaine ca marchera mieux..... bah oui, quand tu lui dit d ecrire a partir d un buffer (ton "coucou" ), il y a une taille min avant que le buffer soit affiche le "\n" arrange tout..... |
je remeure encore un fois mais pour une autres raison PTDR
Marsh Posté le 08-11-2001 à 16:37:05
moi ca me fais pas rire, puisque c est vrai (sous freebsd en tout cas)
apres, si ca te plais pas comme explication, et bah explique...
Marsh Posté le 08-11-2001 à 16:42:43
tomate77 a écrit a écrit : moi ca me fais pas rire, puisque c est vrai (sous freebsd en tout cas) apres, si ca te plais pas comme explication, et bah explique... |
tss tsss ces jeunes
sous bsd
printf("toto" );
ou
printf("%s","toto" );
$>./test
toto$>
Marsh Posté le 08-11-2001 à 18:15:12
le "\n" est utile si un segmentation fault ou tout autre écriture imprévu se produit sur la sortie STDOUT.
sans le "\n", la dernière écriture sur STDOUT peut ne pas s'afficher
Marsh Posté le 08-11-2001 à 18:19:43
y a de koi devenir fou
#include <stdio.h>
int main(void){
printf("coucou\n" );
return (0);
}
ca marchera mieux comme ca
Marsh Posté le 08-11-2001 à 20:10:14
encore plus con... heu simple:D...
#include <stdio.h>
void main()
{
printf("prout\n" );
}
car la fonction ne retourne rien, printf s'en charge.
Pour la compile, il faut peut être respecter un ordre :
gcc prout.c -o prout
et puis vérifie que le fichier de sortie a les droits X (executable).
[edtdd]--Message édité par Fodger--[/edtdd]
Marsh Posté le 16-05-2002 à 08:42:44
mais apprenez a coder un peu....
deja, c est sur, printf bufferise, c est clair, c est net, le 1er qui dis le contraire je lui en colle une
de deux, la fction main est toujour typee int, car elle DOIT toujour renvoyer un code d erreur a l environnement
voila
Marsh Posté le 16-05-2002 à 09:08:14
TheJackal a écrit a écrit :
c plus joli |
moi j'aime pô , je trouve return(0); plus "cohérent" avec la syntaxe générale du C...
[jfdsdjhfuetppo]--Message édité par cycojesus le 16-05-2002 à 09:20:44--[/jfdsdjhfuetppo]
Marsh Posté le 16-05-2002 à 09:10:31
tomate77 a écrit a écrit : mais apprenez a coder un peu.... deja, c est sur, printf bufferise, c est clair, c est net, le 1er qui dis le contraire je lui en colle une de deux, la fction main est toujour typee int, car elle DOIT toujour renvoyer un code d erreur a l environnement voila |
Et il est pas necessaire de mettre un "\n" comme l'a dit qqu'un pour afficher le contenu de ce qui est bufferisé. Un fflush ca peut servir.
A+,
[jfdsdjhfuetppo]--Message édité par gilou le 16-05-2002 à 09:10:46--[/jfdsdjhfuetppo]
Marsh Posté le 16-05-2002 à 09:12:08
oui, mais un \n ou un fflush servenr a faire la meme chose : vider le buffer
c est ca ce que je voulais dire!!
Marsh Posté le 16-05-2002 à 09:44:12
Ahh ce que j'aime les discussions sterilllles. Et on sais tjs
pas si son prog fonctionne maintenant ;D
Marsh Posté le 16-05-2002 à 09:50:56
Discussion d'autant plus stérile que le problème vient certainement pas du "\n" mis ou pas mis. A mon avis c'est comme expliqué plus haut le fait que taper "test" à la ligne de commande appelle la commande "test" de Unix et pas son programme...
Marsh Posté le 16-05-2002 à 11:27:13
ah mon avis le mec, il a déjà réglé son problème
Marsh Posté le 16-05-2002 à 11:38:20
El Scorcho a écrit a écrit : Discussion d'autant plus stérile que le problème vient certainement pas du "\n" mis ou pas mis. A mon avis c'est comme expliqué plus haut le fait que taper "test" à la ligne de commande appelle la commande "test" de Unix et pas son programme... |
Oui, mais ca, je pense que c'etait clair pour tout le monde, non?
A+,
Marsh Posté le 16-05-2002 à 11:39:27
tomate77 a écrit a écrit : oui, mais un \n ou un fflush servenr a faire la meme chose : vider le buffer c est ca ce que je voulais dire!! |
En mode console, je pense pas que ton curseur revienne en debut de ligne avec un fflush...
A+,
Marsh Posté le 16-05-2002 à 17:44:21
Ah ben oui c clair que c résolu lol!!!
En fait c'était tout juste passke test appelait le test de Unix bien évidemment... MAis çà qd on sait pas ke ya une cde test sous Unix... ben on peut chercher lgpts lol
J'aurai du avoir le réflexe de ./test
Mais bon c pas grave, çà fait une jolie discussion lol
Bye !
Marsh Posté le 16-05-2002 à 19:42:49
cycojesus a écrit a écrit : moi j'aime pô ![]() |
Sauf que return n'est pas une fonction!
De meme tu n'appelles pas break(); mais break;
ou goto(label); mais goto label;
etc..
Pour revenir au probleme du int main, je vous fait partager une
citation tres a propos:
Quelqu'un m'a dit qu'au basketball tu ne peux pas prendre la balle en main et courir avec. Or j'ai teste avec une balle de basket et j'ai pu courir sans probleme! Visiblement ce type n'avait rien compris au basket
LEGREG
Marsh Posté le 16-05-2002 à 21:03:31
Et en plus, c'est pas "coucou" qu'il faut mettre, mais "Hello World !"
pour le "\n", j'ai eu des surprises à pas le mettre sous HP Unix ...
Question existencielle : à quoi sert cette commande test sous Unix ?
Marsh Posté le 08-11-2001 à 15:37:06
Hello,
pb tout con : j'écrit un prog C sous Linux, le plus con possible :
#include <stdio.h>
int main(void){
printf("coucou" );
return;
}
je compile : cc -o test test.c
je lance test et rien ne sors
Voilà.
---------------
Savoir c'est vivre, et maintenir dans l'ignorance, c'est presque un homicide.