-----------------------------------------------------------------------
L'auteur de ces conseils d'utilisation ne désire plus les maintenir et
les rend donc à la communauté. Vous pouvez reprendre le flambeau en
contactant l'équipe de modération de fr.usenet.reponses à l'adresse
fur (chez) fr-chartes (point) org.
-----------------------------------------------------------------------
=====================================================
= Conseils d'utilisation du groupe fr.comp.lang.c =
=====================================================
---------------------------------------------------------
Nom : fr.comp.lang.c
Statut : non modéré
Description : Langages de programmation C et assimiles
Date de création : 16/12/96
---------------------------------------------------------
1 - Charte du groupe :
----------------------
Ce groupe est dédié aux discussions autour du langage C.
En particulier, il est recommandé que les discussions
sur les différentes API, librairies et environnements de
compilation des éditeurs de compilateurs pour MS-Windows
se déroulent dans fr.comp.ms-windows.programmation.
De même, le langage C++ a maintenant son groupe à lui : fr.comp.lang.c++ .
On trouvera par exemple dans fr.comp.lang.c :
* des échanges de point de vue, de techniques de programmation, des
sources, des commentaires.
* des questions précises résolues éventuellement par les usagers du
groupe. Questions issues soit de personnes compétentes visant à
résoudre des problèmes très pointus, mais aussi des questions de
débutants visant à améliorer ou approfondir leurs connaissances.
* des informations générales sur les langages de programmation (adresses
de sites, critique de produits commerciaux).
* des initiations aux différents langages assurées par des experts de
bonne volonté.
Il est préférable, s'il est nécessaire d'échanger des fichiers source
de plus d'une centaine de lignes, d'indiquer une référence sur
un site Web ou FTP ou récupérer le fichier en question.
Depuis mi-avril 97, le groupe fr.comp.lang.c++ accueille les
discussions autour du langage C++. fr.comp.lang.c ne doit
plus être utilisé pour cela.
2 - Conclusion :
----------------
Pour obtenir plus de renseignements sur les "Conseils d'utilisation",
vous pouvez vous reporter au message intitulé "A propos des Conseils
d'utilisation" posté dans fr.usenet.reponses et fr.bienvenue.
Pour toutes autres informations et/ou pour débuter sur Usenet, vous
devriez consulter ces deux groupes et visiter le site web qui a été
mis en place à http://usenet-fr.news.eu.org/fr-chartes/ .
Nous espérons que ces informations et conseils contribueront à
la qualité des échanges dans les forums de discussion, dans
l'intérêt et pour le plaisir de tous les lecteurs et auteurs.
--
La présente publication des documents de fr.usenet.reponses fait suite à
la panne du robot MaintFAQ. Ce document n'a pas été mis à jour depuis.
Si vous souhaitez maintenir ce document, contactez-moi à jogo@matabio.net.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
bpascal123
Bjr ou bsr,
Une personne dans cette discussion a conseillé de ne pas ajouter 'n' à la fin de printf pour une raison que j'ai lue mais je ne plus à quel endroit dans cette discussion (certaines réponses sont très longues et pour la plupart des échanges, je suis dépassé).
Ne pas ajouter 'n' à la fin de printf ne m'a pas interpellé directement. Je pense avoir compris pourquoi, en cherchant pourquoi un tableau à 2 dimensions affiche la première ligne avec un décalage d'u n espace :
exemple.1: ... printf("nnAffichage : n") ; /* pour 'n' à cet endroit l'affichage de la première ligne est décallé */
for ( i = 0 ; i < LigA ; i++ ) { for ( j = 0 ; j < ColA ; j++ ) printf(" %d ", MatA[i][j] ) ; printf("n") ; } ...
Exemple2 : printf("nnAffichage : ") ; printf("n") ; /* à cet endroit 'n', l'affichage ligne et colonne n'est pas décallé */
for ( i = 0 ; i < LigA ; i++ ) { for ( j = 0 ; j < ColA ; j++ ) printf(" %d ", MatA[i][j] ) ; printf("n") ; }
Sous environnement windows, il n'y a pas de différence entre l'exemple 1 et 2, pourquoi ?
Sous linux gcc, je suis contraint de faire appel au code de l'exemple 2 qui heureusement fonctionne avec windows. Je voudrais comprendre pourquoi 'n' à la fin de printf et 'n' dans une instruction spécifique ne sont pas équivalents.
Je commence un peu avec le langage assembleur pour avoir quelques notions. Est-ce qu'en assembleur on peut voir l'exemple ci-dessus et comprendre pourquoi visuellement ?
Merci Pascal
Bjr ou bsr,
Une personne dans cette discussion a conseillé de ne pas ajouter 'n'
à la fin de printf pour une raison que j'ai lue mais je ne plus à quel
endroit dans cette discussion (certaines réponses sont très longues et
pour la plupart des échanges, je suis dépassé).
Ne pas ajouter 'n' à la fin de printf ne m'a pas interpellé
directement. Je pense avoir compris pourquoi, en cherchant pourquoi un
tableau à 2 dimensions affiche la première ligne avec un décalage d'u n
espace :
exemple.1:
...
printf("nnAffichage : n") ; /* pour 'n' à cet endroit
l'affichage de la première ligne est décallé */
for ( i = 0 ; i < LigA ; i++ )
{
for ( j = 0 ; j < ColA ; j++ )
printf(" %d ", MatA[i][j] ) ;
printf("n") ;
}
...
Exemple2 :
printf("nnAffichage : ") ;
printf("n") ; /* à cet endroit 'n',
l'affichage ligne et colonne n'est pas décallé */
for ( i = 0 ; i < LigA ; i++ )
{
for ( j = 0 ; j < ColA ; j++ )
printf(" %d ", MatA[i][j] ) ;
printf("n") ;
}
Sous environnement windows, il n'y a pas de différence entre l'exemple
1 et 2, pourquoi ?
Sous linux gcc, je suis contraint de faire appel au code de l'exemple
2 qui heureusement fonctionne avec windows.
Je voudrais comprendre pourquoi 'n' à la fin de printf et 'n' dans
une instruction spécifique ne sont pas équivalents.
Je commence un peu avec le langage assembleur pour avoir quelques
notions.
Est-ce qu'en assembleur on peut voir l'exemple ci-dessus et comprendre
pourquoi visuellement ?
Une personne dans cette discussion a conseillé de ne pas ajouter 'n' à la fin de printf pour une raison que j'ai lue mais je ne plus à quel endroit dans cette discussion (certaines réponses sont très longues et pour la plupart des échanges, je suis dépassé).
Ne pas ajouter 'n' à la fin de printf ne m'a pas interpellé directement. Je pense avoir compris pourquoi, en cherchant pourquoi un tableau à 2 dimensions affiche la première ligne avec un décalage d'u n espace :
exemple.1: ... printf("nnAffichage : n") ; /* pour 'n' à cet endroit l'affichage de la première ligne est décallé */
for ( i = 0 ; i < LigA ; i++ ) { for ( j = 0 ; j < ColA ; j++ ) printf(" %d ", MatA[i][j] ) ; printf("n") ; } ...
Exemple2 : printf("nnAffichage : ") ; printf("n") ; /* à cet endroit 'n', l'affichage ligne et colonne n'est pas décallé */
for ( i = 0 ; i < LigA ; i++ ) { for ( j = 0 ; j < ColA ; j++ ) printf(" %d ", MatA[i][j] ) ; printf("n") ; }
Sous environnement windows, il n'y a pas de différence entre l'exemple 1 et 2, pourquoi ?
Sous linux gcc, je suis contraint de faire appel au code de l'exemple 2 qui heureusement fonctionne avec windows. Je voudrais comprendre pourquoi 'n' à la fin de printf et 'n' dans une instruction spécifique ne sont pas équivalents.
Je commence un peu avec le langage assembleur pour avoir quelques notions. Est-ce qu'en assembleur on peut voir l'exemple ci-dessus et comprendre pourquoi visuellement ?
Merci Pascal
Samuel Devulder
a écrit :
Bjr ou bsr,
Une personne dans cette discussion a conseillé de ne pas ajouter 'n' à la fin de printf pour une raison que j'ai lue mais je ne plus à quel endroit dans cette discussion (certaines réponses sont très longues et pour la plupart des échanges, je suis dépassé).
Il faut dire qu'il y en a qui préférent couper les cheveux en 4 ici que répondre simplement au problème de l'OP ;-)
Sous environnement windows, il n'y a pas de différence entre l'exemple 1 et 2, pourquoi ?
Sous linux gcc, je suis contraint de faire appel au code de l'exemple 2 qui heureusement fonctionne avec windows. Je voudrais comprendre pourquoi 'n' à la fin de printf et 'n' dans une instruction spécifique ne sont pas équivalents.
En fait quel que soit l'environnement il ne devrait y avoir aucune différences entre afficher "chainen" ou "chaine" puis "n".
As tu essayé fprintf(stdout, "chainen"); fflush(stdout); histoire de forcer le vidage des tampons? Mais bon ca n'explique pas pourquoi printf() oublirait le "n" final. C'est pas normal cet oubli de la part du printf(). Il doit y avoir autre chose dans le contexte qui explique cela, mais je ne vois pas. On manque de détails.
Je commence un peu avec le langage assembleur pour avoir quelques notions. Est-ce qu'en assembleur on peut voir l'exemple ci-dessus et comprendre pourquoi visuellement ?
Ben non. Si difference il y a, elle est dans l'implémentation du printf, et pas dans l'asm de ton code. Fondamentalement l'asm d'un code C signifie la même chose que le code C lui même. Le compilo n'ajoute rien de plus à la sémantique du prog en le traduisant en langage machine. Un code bon en C reste bon en ASM, idem s'il est mauvais en C il est mauvais en ASM. Aucune différence ou subtilité à ce niveau.
sam.
bpascal123@googlemail.com a écrit :
Bjr ou bsr,
Une personne dans cette discussion a conseillé de ne pas ajouter 'n'
à la fin de printf pour une raison que j'ai lue mais je ne plus à quel
endroit dans cette discussion (certaines réponses sont très longues et
pour la plupart des échanges, je suis dépassé).
Il faut dire qu'il y en a qui préférent couper les cheveux en 4 ici que
répondre simplement au problème de l'OP ;-)
Sous environnement windows, il n'y a pas de différence entre l'exemple
1 et 2, pourquoi ?
Sous linux gcc, je suis contraint de faire appel au code de l'exemple
2 qui heureusement fonctionne avec windows.
Je voudrais comprendre pourquoi 'n' à la fin de printf et 'n' dans
une instruction spécifique ne sont pas équivalents.
En fait quel que soit l'environnement il ne devrait y avoir aucune
différences entre afficher "chainen" ou "chaine" puis "n".
As tu essayé
fprintf(stdout, "chainen"); fflush(stdout);
histoire de forcer le vidage des tampons? Mais bon ca n'explique pas
pourquoi printf() oublirait le "n" final. C'est pas normal cet oubli de
la part du printf(). Il doit y avoir autre chose dans le contexte qui
explique cela, mais je ne vois pas. On manque de détails.
Je commence un peu avec le langage assembleur pour avoir quelques
notions.
Est-ce qu'en assembleur on peut voir l'exemple ci-dessus et comprendre
pourquoi visuellement ?
Ben non. Si difference il y a, elle est dans l'implémentation du printf,
et pas dans l'asm de ton code. Fondamentalement l'asm d'un code C
signifie la même chose que le code C lui même. Le compilo n'ajoute rien
de plus à la sémantique du prog en le traduisant en langage machine. Un
code bon en C reste bon en ASM, idem s'il est mauvais en C il est
mauvais en ASM. Aucune différence ou subtilité à ce niveau.
Une personne dans cette discussion a conseillé de ne pas ajouter 'n' à la fin de printf pour une raison que j'ai lue mais je ne plus à quel endroit dans cette discussion (certaines réponses sont très longues et pour la plupart des échanges, je suis dépassé).
Il faut dire qu'il y en a qui préférent couper les cheveux en 4 ici que répondre simplement au problème de l'OP ;-)
Sous environnement windows, il n'y a pas de différence entre l'exemple 1 et 2, pourquoi ?
Sous linux gcc, je suis contraint de faire appel au code de l'exemple 2 qui heureusement fonctionne avec windows. Je voudrais comprendre pourquoi 'n' à la fin de printf et 'n' dans une instruction spécifique ne sont pas équivalents.
En fait quel que soit l'environnement il ne devrait y avoir aucune différences entre afficher "chainen" ou "chaine" puis "n".
As tu essayé fprintf(stdout, "chainen"); fflush(stdout); histoire de forcer le vidage des tampons? Mais bon ca n'explique pas pourquoi printf() oublirait le "n" final. C'est pas normal cet oubli de la part du printf(). Il doit y avoir autre chose dans le contexte qui explique cela, mais je ne vois pas. On manque de détails.
Je commence un peu avec le langage assembleur pour avoir quelques notions. Est-ce qu'en assembleur on peut voir l'exemple ci-dessus et comprendre pourquoi visuellement ?
Ben non. Si difference il y a, elle est dans l'implémentation du printf, et pas dans l'asm de ton code. Fondamentalement l'asm d'un code C signifie la même chose que le code C lui même. Le compilo n'ajoute rien de plus à la sémantique du prog en le traduisant en langage machine. Un code bon en C reste bon en ASM, idem s'il est mauvais en C il est mauvais en ASM. Aucune différence ou subtilité à ce niveau.
sam.
-ed-
On 14 nov, 13:53, "" wrote:
Bjr ou bsr,
Une personne dans cette discussion a conseillé de ne pas ajouter 'n' à la fin de printf pour une raison que j'ai lue mais je ne plus à que l
Quelle discussion ? Es-tu conscient que tu as posté dans le fil 'charte' ?
L'equipe fr-chartes Afficher le profil Autres options 2 nov, 09:01 Groupes de discussion : fr.comp.lang.c De : "L'equipe fr-chartes" Date : Mon, 02 Nov 2009 09:01:10 +0100 Date/heure locale : Lun 2 nov 2009 09:01 Objet : [Conseils d'utilisation] fr.comp.lang.c Répondre | Répondre à l'auteur | Transférer | Imprimer | Message individuel | Afficher l'original | Signaler ce message | Rechercher les mes sages de cet auteur Archive-Name: fr/chartes/comp.lang.c
Auteur: Sylvain Nierveze
etc.
(Ou alors est-ce une diablerie de Google qui a accroché ton post au mauvais endroit ?)
On 14 nov, 13:53, "bpascal...@googlemail.com"
<bpascal...@googlemail.com> wrote:
Bjr ou bsr,
Une personne dans cette discussion a conseillé de ne pas ajouter 'n'
à la fin de printf pour une raison que j'ai lue mais je ne plus à que l
Quelle discussion ? Es-tu conscient que tu as posté dans le fil
'charte' ?
L'equipe fr-chartes
Afficher le profil
Autres options 2 nov, 09:01
Groupes de discussion : fr.comp.lang.c
De : "L'equipe fr-chartes" <fr-char...@fr-chartes.org>
Date : Mon, 02 Nov 2009 09:01:10 +0100
Date/heure locale : Lun 2 nov 2009 09:01
Objet : [Conseils d'utilisation] fr.comp.lang.c
Répondre | Répondre à l'auteur | Transférer | Imprimer | Message individuel | Afficher l'original | Signaler ce message | Rechercher les mes sages de cet auteur
Archive-Name: fr/chartes/comp.lang.c
Auteur: Sylvain Nierveze
etc.
(Ou alors est-ce une diablerie de Google qui a accroché ton post au
mauvais endroit ?)
Une personne dans cette discussion a conseillé de ne pas ajouter 'n' à la fin de printf pour une raison que j'ai lue mais je ne plus à que l
Quelle discussion ? Es-tu conscient que tu as posté dans le fil 'charte' ?
L'equipe fr-chartes Afficher le profil Autres options 2 nov, 09:01 Groupes de discussion : fr.comp.lang.c De : "L'equipe fr-chartes" Date : Mon, 02 Nov 2009 09:01:10 +0100 Date/heure locale : Lun 2 nov 2009 09:01 Objet : [Conseils d'utilisation] fr.comp.lang.c Répondre | Répondre à l'auteur | Transférer | Imprimer | Message individuel | Afficher l'original | Signaler ce message | Rechercher les mes sages de cet auteur Archive-Name: fr/chartes/comp.lang.c
Auteur: Sylvain Nierveze
etc.
(Ou alors est-ce une diablerie de Google qui a accroché ton post au mauvais endroit ?)
bpascal123
> Quelle discussion ? Es-tu conscient que tu as posté dans le fil 'charte' ?
(Ou alors est-ce une diablerie de Google qui a accroché ton post au mauvais endroit ?)
Il y avait un message sur la charte de ce groupe (qui cherche des personnes pour reprendre le flambeau - avec mon niveau en programmation, la flamme me brûlerait les mains :) ), bref, j'ai fait répondre à ce post mais c'est allé dans un nouveau fil de discussion de la charte. Je n'ai pas compris.
Pascal
> Quelle discussion ? Es-tu conscient que tu as posté dans le fil
'charte' ?
(Ou alors est-ce une diablerie de Google qui a accroché ton post au
mauvais endroit ?)
Il y avait un message sur la charte de ce groupe (qui cherche des
personnes pour reprendre le flambeau - avec mon niveau en
programmation, la flamme me brûlerait les mains :) ), bref, j'ai fait
répondre à ce post mais c'est allé dans un nouveau fil de discussion
de la charte. Je n'ai pas compris.
> Quelle discussion ? Es-tu conscient que tu as posté dans le fil 'charte' ?
(Ou alors est-ce une diablerie de Google qui a accroché ton post au mauvais endroit ?)
Il y avait un message sur la charte de ce groupe (qui cherche des personnes pour reprendre le flambeau - avec mon niveau en programmation, la flamme me brûlerait les mains :) ), bref, j'ai fait répondre à ce post mais c'est allé dans un nouveau fil de discussion de la charte. Je n'ai pas compris.
Pascal
Lucas Levrel
Le 14 novembre 2009, Samuel Devulder a écrit :
a écrit : > Sous environnement windows, il n'y a pas de différence entre l'exemple > 1 et 2, pourquoi ?
> Sous linux gcc, je suis contraint de faire appel au code de l'exemple > 2 qui heureusement fonctionne avec windows.
Mais bon ca n'explique pas pourquoi printf() oublirait le "n" final. C'est pas normal cet oubli de la part du printf(). Il doit y avoir autre chose dans le contexte qui explique cela, mais je ne vois pas. On manque de détails.
Autrement dit, Pascal : fais un exemple complet (= qui compile) qui montre le problème. Chez moi ceci ne produit aucun décalage : --- #include <stdio.h> int main(void){ int i,j; printf("nnAffichage : n") ; for ( i = 0 ; i < 3 ; i++ ){ for ( j = 0 ; j < 3 ; j++ ) printf(" %i ", i*j ) ; printf("n") ; } return 0; } --- Compilé avec gcc toto.c, ./a.out donne : ---
Affichage : 0 0 0 0 1 2 0 2 4 ---
-- LL
Le 14 novembre 2009, Samuel Devulder a écrit :
bpascal123@googlemail.com a écrit :
> Sous environnement windows, il n'y a pas de différence entre l'exemple
> 1 et 2, pourquoi ?
> Sous linux gcc, je suis contraint de faire appel au code de l'exemple
> 2 qui heureusement fonctionne avec windows.
Mais bon ca n'explique pas pourquoi
printf() oublirait le "n" final. C'est pas normal cet oubli de la part du
printf(). Il doit y avoir autre chose dans le contexte qui explique cela, mais
je ne vois pas. On manque de détails.
Autrement dit, Pascal : fais un exemple complet (= qui compile) qui montre
le problème. Chez moi ceci ne produit aucun décalage :
---
#include <stdio.h>
int main(void){
int i,j;
printf("nnAffichage : n") ;
for ( i = 0 ; i < 3 ; i++ ){
for ( j = 0 ; j < 3 ; j++ ) printf(" %i ", i*j ) ;
printf("n") ;
}
return 0;
}
---
Compilé avec gcc toto.c, ./a.out donne :
---
a écrit : > Sous environnement windows, il n'y a pas de différence entre l'exemple > 1 et 2, pourquoi ?
> Sous linux gcc, je suis contraint de faire appel au code de l'exemple > 2 qui heureusement fonctionne avec windows.
Mais bon ca n'explique pas pourquoi printf() oublirait le "n" final. C'est pas normal cet oubli de la part du printf(). Il doit y avoir autre chose dans le contexte qui explique cela, mais je ne vois pas. On manque de détails.
Autrement dit, Pascal : fais un exemple complet (= qui compile) qui montre le problème. Chez moi ceci ne produit aucun décalage : --- #include <stdio.h> int main(void){ int i,j; printf("nnAffichage : n") ; for ( i = 0 ; i < 3 ; i++ ){ for ( j = 0 ; j < 3 ; j++ ) printf(" %i ", i*j ) ; printf("n") ; } return 0; } --- Compilé avec gcc toto.c, ./a.out donne : ---
