salut
Je me demande quel est l'interet d'appeler la fonction exit() plutot que
return.
Par exemple, si j'ai le programme suivant:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
(void) printf("salut\n") ;
return EXIT_SUCCESS ;
}
et celui-ci:
int main(void)
{
(void) printf("salut\n") ;
exit(EXIT_SUCCESS) ;
}
Qu'est-ce que ca change? Je comprend pas tres bien...si quelqu'un peut
m'eclairer. :)
did
--
Toutes des ingrates...
http://www.netbsd.org/fr
http://www.isty-info.uvsq.fr/~rumeau/fclc/
Personellement, j'utilise exit() dans mon 'ASSERT()' maison, qui permet une sortie plus propre que le assert() standard sur ma plateforme de debug.
Si une assertion est fausse, comment peux-tu t'assurer que les pre-conditions des fonctions enregistrees avec atexit sont vraies?
Déjà, il ne peut y avoir qu'une seule fonction enregistrée avec atexit() à la fois. (Par défaut, il n'y en a pas).
Ensuite, tu veux dire quoi ? Qu'on ne peut pas mettre de ASSERT() dans cette fonction sous peine de récursion infinie? C'est possible, mais comme c'est déjà une sortie de secours, ça ne devrait pas trop géner.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Jean-Marc Bourguet <jm@bourguet.org> wrote:
Personellement, j'utilise exit() dans mon 'ASSERT()' maison, qui
permet une sortie plus propre que le assert() standard sur ma
plateforme de debug.
Si une assertion est fausse, comment peux-tu t'assurer que les
pre-conditions des fonctions enregistrees avec atexit sont vraies?
Déjà, il ne peut y avoir qu'une seule fonction enregistrée avec atexit() à la
fois. (Par défaut, il n'y en a pas).
Ensuite, tu veux dire quoi ? Qu'on ne peut pas mettre de ASSERT() dans cette
fonction sous peine de récursion infinie? C'est possible, mais comme c'est
déjà une sortie de secours, ça ne devrait pas trop géner.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Personellement, j'utilise exit() dans mon 'ASSERT()' maison, qui permet une sortie plus propre que le assert() standard sur ma plateforme de debug.
Si une assertion est fausse, comment peux-tu t'assurer que les pre-conditions des fonctions enregistrees avec atexit sont vraies?
Déjà, il ne peut y avoir qu'une seule fonction enregistrée avec atexit() à la fois. (Par défaut, il n'y en a pas).
Ensuite, tu veux dire quoi ? Qu'on ne peut pas mettre de ASSERT() dans cette fonction sous peine de récursion infinie? C'est possible, mais comme c'est déjà une sortie de secours, ça ne devrait pas trop géner.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', Horst Kraemer wrote:
C'est un vieu astuce qui garantit que
une vieille!
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Horst Kraemer <horst.kraemer@epost.de> wrote:
C'est un vieu astuce qui garantit que
une vieille!
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', Laurent Wacrenier <lwa@ teaser . fr> wrote:
Personellement, j'utilise exit() dans mon 'ASSERT()' maison, qui permet une sortie plus propre que le assert() standard sur ma plateforme de debug.
abort() n'est pas plus approprié ?
Sur ma plateforme de debug (BC 3.1 sous DOS), un assert() appelle abort(). Problème, les fichiers ne sont pas fermés, la mémoire n'est pas libérée. Plantage de BC (voire, du PC) au bout de quelques sorties brutales. Je n'ai pas ce problème avec exit().
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Laurent Wacrenier <lwa@ teaser . fr> wrote:
Personellement, j'utilise exit() dans mon 'ASSERT()' maison, qui permet
une sortie plus propre que le assert() standard sur ma plateforme de
debug.
abort() n'est pas plus approprié ?
Sur ma plateforme de debug (BC 3.1 sous DOS), un assert() appelle abort().
Problème, les fichiers ne sont pas fermés, la mémoire n'est pas libérée.
Plantage de BC (voire, du PC) au bout de quelques sorties brutales. Je n'ai
pas ce problème avec exit().
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Laurent Wacrenier <lwa@ teaser . fr> wrote:
Personellement, j'utilise exit() dans mon 'ASSERT()' maison, qui permet une sortie plus propre que le assert() standard sur ma plateforme de debug.
abort() n'est pas plus approprié ?
Sur ma plateforme de debug (BC 3.1 sous DOS), un assert() appelle abort(). Problème, les fichiers ne sont pas fermés, la mémoire n'est pas libérée. Plantage de BC (voire, du PC) au bout de quelques sorties brutales. Je n'ai pas ce problème avec exit().
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Jean-Marc Bourguet
Emmanuel Delahaye writes:
In 'fr.comp.lang.c', Jean-Marc Bourguet wrote:
Personellement, j'utilise exit() dans mon 'ASSERT()' maison, qui permet une sortie plus propre que le assert() standard sur ma plateforme de debug.
Si une assertion est fausse, comment peux-tu t'assurer que les pre-conditions des fonctions enregistrees avec atexit sont vraies?
Déjà, il ne peut y avoir qu'une seule fonction enregistrée avec atexit() à la fois.
Il me semblait que la norme imposait un minimum de 32 (et il y a des environnements ou la seule limite c'est la memoire disponible).
(Par défaut, il n'y en a pas).
D'accord. Sauf que je ne sais pas ce que font les bibliotheques que j'utilise.
Ensuite, tu veux dire quoi ?
Que si un assert echoue, tu ne sais pas pourquoi et que les structures de donnees internes dont dependent les fonctions enregistrees avec atexit peuvent etre corrompues,...
Le meilleur recours en cas d'incoherence dans la majorite des cas (*), c'est l'arret immediat -- eventuellement en loggant le probleme -- sans essayer de remettre de l'ordre ce qui peut faire plus de mal que de bien (cad que le bien qu'on peut faire est minime et le mal tres eleve bien que la proba du bien soit superieure a la proba du mal, l'esperance est negative). La seule chose admissible c'est de rendre des ressources au systeme quand il ne peut pas les recuperer tout seul et on ne peut pas compter sur ce qui est enregistre par atexit pour se limiter a ca.
(*) dans l'embarque on peut parfois mieux faire -- passer au systeme de secours ou redemarrer tout le systeme sont les premieres possibilites qui viennent a l'esprit --, je n'exclus pas des cas ou exit soit adapte mais en faire une polique generale...
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
In 'fr.comp.lang.c', Jean-Marc Bourguet <jm@bourguet.org> wrote:
Personellement, j'utilise exit() dans mon 'ASSERT()' maison, qui
permet une sortie plus propre que le assert() standard sur ma
plateforme de debug.
Si une assertion est fausse, comment peux-tu t'assurer que les
pre-conditions des fonctions enregistrees avec atexit sont vraies?
Déjà, il ne peut y avoir qu'une seule fonction enregistrée avec
atexit() à la fois.
Il me semblait que la norme imposait un minimum de 32 (et il y a des
environnements ou la seule limite c'est la memoire disponible).
(Par défaut, il n'y en a pas).
D'accord. Sauf que je ne sais pas ce que font les bibliotheques que
j'utilise.
Ensuite, tu veux dire quoi ?
Que si un assert echoue, tu ne sais pas pourquoi et que les structures
de donnees internes dont dependent les fonctions enregistrees avec
atexit peuvent etre corrompues,...
Le meilleur recours en cas d'incoherence dans la majorite des cas (*),
c'est l'arret immediat -- eventuellement en loggant le probleme --
sans essayer de remettre de l'ordre ce qui peut faire plus de mal que
de bien (cad que le bien qu'on peut faire est minime et le mal tres
eleve bien que la proba du bien soit superieure a la proba du mal,
l'esperance est negative). La seule chose admissible c'est de rendre
des ressources au systeme quand il ne peut pas les recuperer tout seul
et on ne peut pas compter sur ce qui est enregistre par atexit pour se
limiter a ca.
(*) dans l'embarque on peut parfois mieux faire -- passer au systeme
de secours ou redemarrer tout le systeme sont les premieres
possibilites qui viennent a l'esprit --, je n'exclus pas des cas ou
exit soit adapte mais en faire une polique generale...
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Personellement, j'utilise exit() dans mon 'ASSERT()' maison, qui permet une sortie plus propre que le assert() standard sur ma plateforme de debug.
Si une assertion est fausse, comment peux-tu t'assurer que les pre-conditions des fonctions enregistrees avec atexit sont vraies?
Déjà, il ne peut y avoir qu'une seule fonction enregistrée avec atexit() à la fois.
Il me semblait que la norme imposait un minimum de 32 (et il y a des environnements ou la seule limite c'est la memoire disponible).
(Par défaut, il n'y en a pas).
D'accord. Sauf que je ne sais pas ce que font les bibliotheques que j'utilise.
Ensuite, tu veux dire quoi ?
Que si un assert echoue, tu ne sais pas pourquoi et que les structures de donnees internes dont dependent les fonctions enregistrees avec atexit peuvent etre corrompues,...
Le meilleur recours en cas d'incoherence dans la majorite des cas (*), c'est l'arret immediat -- eventuellement en loggant le probleme -- sans essayer de remettre de l'ordre ce qui peut faire plus de mal que de bien (cad que le bien qu'on peut faire est minime et le mal tres eleve bien que la proba du bien soit superieure a la proba du mal, l'esperance est negative). La seule chose admissible c'est de rendre des ressources au systeme quand il ne peut pas les recuperer tout seul et on ne peut pas compter sur ce qui est enregistre par atexit pour se limiter a ca.
(*) dans l'embarque on peut parfois mieux faire -- passer au systeme de secours ou redemarrer tout le systeme sont les premieres possibilites qui viennent a l'esprit --, je n'exclus pas des cas ou exit soit adapte mais en faire une polique generale...
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Bertrand Mollinier Toublet
Vincent Lefevre wrote:
Dans l'article <bfgtf4$emri6$, Bertrand Mollinier Toublet écrit:
Alors d'accord, c'est une super vieille architecture, c'est plus vraiment utilise (meme les applis embarques utilisent des PowerPC et autres SPARCs maintenant), mais que ++i produise du code plus rapide que i++ c'est pas n'importe quoi. C'est juste vieux et perime.
++i produit du code plus rapide sur *une* machine particulière. Sur une autre machine avec un compilo aussi mauvais, ça peut être l'inverse. Maintenant, si c'est juste pour aller plus rapide sur une machine particulière avec de telles trivialités, je te conseillerais de programmer en assembleur.
C'est pas ce que je voulais dire. J'avais compris que tu considerais
l'idee que l'on raconte que "++i est plus rapide que i++" comme "n'importe quoi". Je faisais remarquer que je ne suis pas d'accord dans la mesure ou ca a un fondement historique (d'ou, ce n'est pas "n'importe quoi", c'est juste "vieux et perime").
Cela dit, en tant que tel, "vieux et perime", l'idee doit en effet etre oubliee, et l'on doit considerer qu'un compilateur decent sur une architecture courante va traiter au mieux les deux ecritures.
-- Bertrand Mollinier Toublet "Reality exists" - Richard Heathfield, 1 July 2003
Vincent Lefevre wrote:
Dans l'article <bfgtf4$emri6$1@ID-168218.news.uni-berlin.de>,
Bertrand Mollinier Toublet <bertrand.molliniertoublet@enst-bretagne.fr> écrit:
Alors d'accord, c'est une super vieille architecture, c'est plus
vraiment utilise (meme les applis embarques utilisent des PowerPC et
autres SPARCs maintenant), mais que ++i produise du code plus rapide
que i++ c'est pas n'importe quoi. C'est juste vieux et perime.
++i produit du code plus rapide sur *une* machine particulière.
Sur une autre machine avec un compilo aussi mauvais, ça peut être
l'inverse. Maintenant, si c'est juste pour aller plus rapide sur
une machine particulière avec de telles trivialités, je te
conseillerais de programmer en assembleur.
C'est pas ce que je voulais dire. J'avais compris que tu considerais
l'idee que l'on raconte que "++i est plus rapide que i++" comme
"n'importe quoi". Je faisais remarquer que je ne suis pas d'accord dans
la mesure ou ca a un fondement historique (d'ou, ce n'est pas "n'importe
quoi", c'est juste "vieux et perime").
Cela dit, en tant que tel, "vieux et perime", l'idee doit en effet etre
oubliee, et l'on doit considerer qu'un compilateur decent sur une
architecture courante va traiter au mieux les deux ecritures.
--
Bertrand Mollinier Toublet
"Reality exists" - Richard Heathfield, 1 July 2003
Dans l'article <bfgtf4$emri6$, Bertrand Mollinier Toublet écrit:
Alors d'accord, c'est une super vieille architecture, c'est plus vraiment utilise (meme les applis embarques utilisent des PowerPC et autres SPARCs maintenant), mais que ++i produise du code plus rapide que i++ c'est pas n'importe quoi. C'est juste vieux et perime.
++i produit du code plus rapide sur *une* machine particulière. Sur une autre machine avec un compilo aussi mauvais, ça peut être l'inverse. Maintenant, si c'est juste pour aller plus rapide sur une machine particulière avec de telles trivialités, je te conseillerais de programmer en assembleur.
C'est pas ce que je voulais dire. J'avais compris que tu considerais
l'idee que l'on raconte que "++i est plus rapide que i++" comme "n'importe quoi". Je faisais remarquer que je ne suis pas d'accord dans la mesure ou ca a un fondement historique (d'ou, ce n'est pas "n'importe quoi", c'est juste "vieux et perime").
Cela dit, en tant que tel, "vieux et perime", l'idee doit en effet etre oubliee, et l'on doit considerer qu'un compilateur decent sur une architecture courante va traiter au mieux les deux ecritures.
-- Bertrand Mollinier Toublet "Reality exists" - Richard Heathfield, 1 July 2003
Vincent Lefevre
Dans l'article , Emmanuel Delahaye écrit:
In 'fr.comp.lang.c', Laurent Wacrenier <lwa@ teaser . fr> wrote:
abort() n'est pas plus approprié ?
Sur ma plateforme de debug (BC 3.1 sous DOS), un assert() appelle abort(). Problème, les fichiers ne sont pas fermés, la mémoire n'est pas libérée. Plantage de BC (voire, du PC) au bout de quelques sorties brutales. Je n'ai pas ce problème avec exit().
Mauvais OS (si on peut appeler ça un OS), changer d'OS. :)
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <Xns93BFB1BAB7B4hsnoservernet@130.133.1.4>,
Emmanuel Delahaye <emdelYOURBRA@noos.fr> écrit:
In 'fr.comp.lang.c', Laurent Wacrenier <lwa@ teaser . fr> wrote:
abort() n'est pas plus approprié ?
Sur ma plateforme de debug (BC 3.1 sous DOS), un assert() appelle abort().
Problème, les fichiers ne sont pas fermés, la mémoire n'est pas libérée.
Plantage de BC (voire, du PC) au bout de quelques sorties brutales. Je n'ai
pas ce problème avec exit().
Mauvais OS (si on peut appeler ça un OS), changer d'OS. :)
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
In 'fr.comp.lang.c', Laurent Wacrenier <lwa@ teaser . fr> wrote:
abort() n'est pas plus approprié ?
Sur ma plateforme de debug (BC 3.1 sous DOS), un assert() appelle abort(). Problème, les fichiers ne sont pas fermés, la mémoire n'est pas libérée. Plantage de BC (voire, du PC) au bout de quelques sorties brutales. Je n'ai pas ce problème avec exit().
Mauvais OS (si on peut appeler ça un OS), changer d'OS. :)
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Manu
Emmanuel Delahaye wrote:
A cause du 0, ce n'est pas une boucle, mais un bloc, sauf qu'il permet à la macro de garder une sémantique 'instruction', c'est à dire avec un ';' obligatoire.
C'est cool ça m'a permis de corriger une macro qui par chance n'était jamais suivi de 'else'.
En fait, cette macro ne comportant qu'une ligne, on aurait pu faire l'économie du do-while(0)
Si je ne m'abuse il faudrait mettre des parenthèses autour...
De même la construction (a)?b:c est-elle vraiment plus rapide qu'un if-else avec les compilateurs actuels faisant de l'optimisation ?
Qui a parlé de plus rapide? C'est une construction comme une autre. J'ai trouvé que sa compacité était adaptée à la situtation.
C'est plus compact mais je trouve le (void)0 relativement peu "lisible". Enfin c'est perso.
C'est possible sur certaines implémémentations, mais je pense que quand on apprend le C (tu as parlé de 'prof'), ce genre de détail n'est pas important.
Si à la suite d'un profiling /sérieux/, on en déduit qu'une portion du code doit être optimisée, ce genre de considération peut éventuellement être prise en compte. Mais avant, il faut avoir épuisé le possibilités d'optimisation du compilateur.
D'ailleurs avec GCC 2.95.3, le code produit est rigouresement le même avec ou sans optimisation. De même que si on remplace : (a) ? (void)0 : SYS_assertfail (#a , __FILE__ , __LINE__ ) par: if(!(a)) SYS_assertfail (#a , __FILE__ , __LINE__ )
C'est pas très interessant à savoir mais c'est rassurant :)
-=( manu )=-
Emmanuel Delahaye wrote:
A cause du 0, ce n'est pas une boucle, mais un bloc, sauf qu'il permet à la
macro de garder une sémantique 'instruction', c'est à dire avec un ';'
obligatoire.
C'est cool ça m'a permis de corriger une macro qui par chance n'était
jamais suivi de 'else'.
En fait, cette macro ne comportant qu'une ligne, on aurait pu faire
l'économie du do-while(0)
Si je ne m'abuse il faudrait mettre des parenthèses autour...
De même la construction (a)?b:c est-elle vraiment plus rapide qu'un
if-else avec les compilateurs actuels faisant de l'optimisation ?
Qui a parlé de plus rapide? C'est une construction comme une autre. J'ai
trouvé que sa compacité était adaptée à la situtation.
C'est plus compact mais je trouve le (void)0 relativement peu "lisible".
Enfin c'est perso.
C'est possible sur certaines implémémentations, mais je pense que quand on
apprend le C (tu as parlé de 'prof'), ce genre de détail n'est pas important.
Si à la suite d'un profiling /sérieux/, on en déduit qu'une portion du code
doit être optimisée, ce genre de considération peut éventuellement être prise
en compte. Mais avant, il faut avoir épuisé le possibilités d'optimisation du
compilateur.
D'ailleurs avec GCC 2.95.3, le code produit est rigouresement le même
avec ou sans optimisation. De même que si on remplace :
(a) ? (void)0 : SYS_assertfail (#a
, __FILE__
, __LINE__
)
par:
if(!(a))
SYS_assertfail (#a
, __FILE__
, __LINE__
)
C'est pas très interessant à savoir mais c'est rassurant :)
A cause du 0, ce n'est pas une boucle, mais un bloc, sauf qu'il permet à la macro de garder une sémantique 'instruction', c'est à dire avec un ';' obligatoire.
C'est cool ça m'a permis de corriger une macro qui par chance n'était jamais suivi de 'else'.
En fait, cette macro ne comportant qu'une ligne, on aurait pu faire l'économie du do-while(0)
Si je ne m'abuse il faudrait mettre des parenthèses autour...
De même la construction (a)?b:c est-elle vraiment plus rapide qu'un if-else avec les compilateurs actuels faisant de l'optimisation ?
Qui a parlé de plus rapide? C'est une construction comme une autre. J'ai trouvé que sa compacité était adaptée à la situtation.
C'est plus compact mais je trouve le (void)0 relativement peu "lisible". Enfin c'est perso.
C'est possible sur certaines implémémentations, mais je pense que quand on apprend le C (tu as parlé de 'prof'), ce genre de détail n'est pas important.
Si à la suite d'un profiling /sérieux/, on en déduit qu'une portion du code doit être optimisée, ce genre de considération peut éventuellement être prise en compte. Mais avant, il faut avoir épuisé le possibilités d'optimisation du compilateur.
D'ailleurs avec GCC 2.95.3, le code produit est rigouresement le même avec ou sans optimisation. De même que si on remplace : (a) ? (void)0 : SYS_assertfail (#a , __FILE__ , __LINE__ ) par: if(!(a)) SYS_assertfail (#a , __FILE__ , __LINE__ )
C'est pas très interessant à savoir mais c'est rassurant :)
-=( manu )=-
Eddahbi Karim
Malheureusement, Borland C 3.1 (qui est né avant Linux) ne sait pas tourner sous un autre environnement, et je ne connais pas d'IDE aussi pratique et productif que celui ci. (Les clickodromes me fatiguent)
Pour l'instant le mien il me va :D. Tout ce que je fais c'est CTRL+S, F10, F9 et F3 pour tester mon code.
(Tant de fonctions alors que j'en demande si peu :)). Sinon, t'as emacs sous bash avec Linux. Par contre faut le personnaliser :/.
Voila, ThE_TemPLaR
Malheureusement, Borland C 3.1 (qui est né avant Linux) ne sait pas tourner
sous un autre environnement, et je ne connais pas d'IDE aussi pratique et
productif que celui ci. (Les clickodromes me fatiguent)
Pour l'instant le mien il me va :D.
Tout ce que je fais c'est CTRL+S, F10, F9 et F3 pour tester mon code.
(Tant de fonctions alors que j'en demande si peu :)).
Sinon, t'as emacs sous bash avec Linux.
Par contre faut le personnaliser :/.
Malheureusement, Borland C 3.1 (qui est né avant Linux) ne sait pas tourner sous un autre environnement, et je ne connais pas d'IDE aussi pratique et productif que celui ci. (Les clickodromes me fatiguent)
Pour l'instant le mien il me va :D. Tout ce que je fais c'est CTRL+S, F10, F9 et F3 pour tester mon code.
(Tant de fonctions alors que j'en demande si peu :)). Sinon, t'as emacs sous bash avec Linux. Par contre faut le personnaliser :/.
Voila, ThE_TemPLaR
Gabriel Dos Reis
Manu writes:
| C'est plus compact mais je trouve le (void)0 relativement peu "lisible".
C'est du C.
-- Gaby
Manu <news_NOSPAM@guzu.net> writes:
| C'est plus compact mais je trouve le (void)0 relativement peu "lisible".
