:o/ - Page 4

JKB a tapoté du bout de ses petites papattes :


Puisque tu nous cherches :

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. GOODBYEWORLD.
000300 DATE-WRITTEN. 15/10/11 19:47.
000400 AUTHOR UNKNOWN.
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 DEBUT.
100300 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100400 DISPLAY "GOODBYE WORLD !" LINE 15 POSITION 10.
100500 STOP RUN.

Tu me files ton adresse que je te téléch^^^^^^envoie la carte perforée
par la Poste ?

Le Sat, 15 Oct 2011 19:49:38 +0200,


    Tu risques de devoir trier un bac de cartes _sans_ le coup de feutre
    sur le côté ! Mon thérapeute m'a toujours interdit de toucher à un
    truc qui ressemble au COBOL !

    JKB

On 15 oct, 19:34, JKB



Argh !

         PROGRAM GOODBYE
         WRITE (*,10) " Good bye, World ! "
 10      FORMAT(A12)
         END



Allez, quoi, allez, tu nous les expliques ... alleeeeeeeeez !

( et pourquoi pas en Cobol, vite fait avant l'apE9%ro ? )

Jean-Christophe a tapoté du bout de ses petites papattes :


Tu ne lis pas mes posts ? En plus c'était un hommage à notre école
commune. :)

Le Sat, 15 Oct 2011 10:58:43 -0700 (PDT),


    Il y a des caractères en trop...

    JKB

snipped-for-privacy@rayleigh.systella.fr...

===============
"\n" est un simple retour à la ligne, son absence n'empêche pas l'affichage
(du moins avec mon compilateur "Borland" )

After serious thinking maioré wrote :


Sisi le stdout ne mange pas beaucoup de pain et evite de s'arracher les
cheveux. Croyez moi....

Le Sat, 15 Oct 2011 19:46:35 +0200,
maioré <> écrivait :


    C'est parce qu'un fflush() implicite est fait par la fonction
    _exit() appelée à la fin de l'exécution du programme. Si tu colles
    un printf("Hello, Word") au milieu d'un programme, rien ne te
    garantit qu'il sera affiché. Je connais même un système où le buffer
    n'est envoyé vers stdout que lorsqu'il reçoit un '\n' (+'\r' si on
    veut repartir en début de ligne) et la routine de sortie l'affiche
    quand elle a le temps (sauf si un fflush() sournois force cet
    affichage).

    JKB

snipped-for-privacy@rayleigh.systella.fr...

==============
Oui, il y a des particularités, c'est pourquoi je précise avec la suite "
Borland C++" pas de problème.
"\n" saut de ligne et début de ligne.  "\r" début de ligne sans saut ..
Sans contrôle de position , la chaîne s'affiche quand même mais à la
dernière position du curseur .
Les "vieux C" fonctionnaient de cette façon je crois .
Bonne journée

On 15 oct, 18:46, JKB :

|  printf( "Goodbye, World !" );



Tu chipotes, parce-que tu prE9%sumes de l'OS sur lequel ca tourne ;
sous DOS ca marche trE9%s bien sans '\n',
le curseur reste juste E0% la fin de la chaine.
D'ailleurs il n'est mEA%me pas dit qu'il y a un OS :o)
ca pourrait trE9%s bien EA%tre un soft C
tournant sur le uC d'une carte maison.

Ceci dit, entre les disparitions de Ritchie et de Steve,
les mE9%dias ont E9%tE9% bien plus prolixes sur Steve alors que
c'est Ritchie qui en a fait le plus pour l'informatique.
( opinion toute personnelle, s'entend )

Le Sat, 15 Oct 2011 10:51:34 -0700 (PDT),


    Parce que tu rends la main au système au travers de _exit(). Si tu
    ne rends pas la main au système, il n'y a aucune raison que ce soit
    synchrone.



    Même remarque.



    Nous sommes bien d'accord.

    JKB

On 15 oct, 21:02, JKB

| S'il n'y a pas un '\n' E0% la fin de la chaEE%ne, il vaut mieux
| ajouter un fflush(stdout) pour EA%tre sFB%r que E7%a s'affiche.



| Parce que tu rends la main au systE8%me au travers de _exit().
| Si tu ne rends pas la main au systE8%me,
| il n'y a aucune raison que ce soit synchrone.

J'ai compilE9% et exE9%cutE9% ceci sous DOS
( avec VC++ v6.0 sur un PC sous Win7)
le programme affiche *instantanE9%ment* :
Hello, world !
puis une pause de 4 secondes
puis l'affichage donne :
Hello, world !Goodbye, world !
puis il stoppe.

/* -------------------------------- */
#include <stdio.h>

int main(void)
{
const unsigned int max 3D% 0xFFFFFFF0;
unsigned int i, j, k, l, z3D%0;

  printf("Hello, world !");

  for( i3D%3; --i; )
   for( j3D%max; --j; )
    for( k3D%max; --k; )
     for( l3D%max; --l; )
      ++z;

  printf("Goodbye, world !");

  return 0;
}

Jean-Christophe submitted this idea :


On peut aussi lire cette page...
http://stackoverflow.com/questions/1716296/why-does-printf-not-flush-after-the-call-unless-a-newline-is-in-the-format-strin

...

Le Sat, 15 Oct 2011 13:55:52 -0700 (PDT),


    Je crois surtout que tu as un problème de compréhension de la
    norme. Le fait que rien ne t'assure que ce soit affiché
    immédiatement ne l'interdit pas. C'est un peu comme en maths.
    Lorsqu'une mère dit à son gosse que s'il n'est pas sage, il aura une
    claque ne signifie en aucun emanière que s'il est sage, il n'en aura
    pas ;-)

    Quant à utiliser VC++ comme archétype de la norme C, eh bien,
    comment dire...

    JKB

On 16 oct, 10:48, JKB




Qu'ouis-je  ?
Ceci est un affront !
Puisque nous habitons tous deux la capitale,
rendez-vous aujourd'huy E0% 15 heures
sur le Champ de Mars, avec nos tE9%moins.
Et bien qu'E9%tant l'offensE9%, je te laisse le choix des armes.
(Silex, Quatrains, Piolet, Octo-syllabes, Katana, Vax ...)



Pourtant un ordinateur est une machine dE9%terministe,
alors qu'est-ce qui cause que ce sera affichE9% ou pas ?



Ok.


Je vois ce que tu veux dire, et suis tout E0% fait d'accord.
J'ai utilisE9% ce que j'avais sous la main, E0% la maison.

Mais E0% l'E9%poque oF9% au boulot j'E9%crivais des softs sous DOS,
quand j'affichais la progression des traitements vers
l'E9%cran via printf() je n'ai *jamais* constatE9% cela.
(je conviens que ce n'est pas un contre-argument
E0% ta rE9%ponse, mais bon, quand mEA%me ... )

Le Sun, 16 Oct 2011 04:11:45 -0700 (PDT),


    Si tu veux !



    Je suis très bon au lancé de SS20, tartagueule après ça !



    Sérieusement ? Ta libc bufferise les I/O. Elle les traite
    lorsqu'elle a le temps (lorsque ton processeur fait les pieds au
    mur) ou quand on lui demande gentiment (avec un fflush(whatever)).
    Sous DOS, il y a de fortes chances qu'elle soit synchrone. Sous
    Windows, à mon avis, pour des raisons de comptabilité avec des vieux
    softs qui faisaient l'hypothèse d'I/O synchrones, il y a de forte
    chance aussi qu'elle soit synchrone. Sous Unix, c'est juste faux.
    Personnellement, pour ne pas avoir de problèmes, je colle toujours
    un fflush() lorsque je veux être sûr que les buffers soient
    effectivement vidés.

    Par ailleurs, fflush() existe déjà en C89. Attention, un piège
    amusant est que fflush() vide les tampons en espace _utilisateur_.
    Si tu veux aussi les vider en espace noyau (par exemple pour des
    choses tournant autour des disques), il faut ajouter sync() ou
    fsync().



    Essaie la même chose sur un système multitâche. Tu risques d'avoir
    de grosses surprises ;-) Je ne disconviens pas que 99% du temps, ça
    fonctionnera, mais le 1% restant risque de te poser problème...

    JKB

On 16 oct, 13:20, JKB





Alea jacta est, fluctuat nec mergitur, et caetera.




Palsambleu, cela contrarie les rE8%gles de la Chevalerie !
DE9%gottE9% aux puces de Montreuil, ou de Saint-Ouen ?




Comme je l'ai dit, une carte E0% uC et un compilo C avec par exemple
la lib d'un afficheur LCD ne va pas faire ce genre de choses.
Ca reste simple ( simplet si tu prE9%fE8%res )
C'est pour cela que je pense qu'il faut distinguer le printf()
du C, et le systE8%me - s'il y en a un - sur lequel ca tourne.



Bon, ok.



Oui, bien recu.
Comme je n'ai jamais eu ce problE8%me, je croyais que.
Merci pour la leE7%on.

Le Sun, 16 Oct 2011 05:59:03 -0700 (PDT),


    Mais seulement dans les rues en pente !



    Dégottées directement chez feu Monsieur Sun.



    Non, _rien_ ne te l'assure. Lorsque tu appelles printf(), tu
    appelles en fait (par macro interposée ou fonction inline) un
    certains nombre des choses imbriquées. Généralement, ça donne ceci :

    printf(arg)
        -> fprintf(stdout, arg)
        -> write(FILENO_STDOUT, arg, strlen(arg))

    Le printf() n'est _pas_ une fonction intrinsèque du compilo. C'est
    même pour cela que tu as besoin d'inclure stdio.h et stdlib.h. Plus
    exactement, rien ne te garantit que ce soit une fonction intrinsèque
    du compilo. Un autre piège amusant est d'oublier que printf() peut
    Ãªtre une macro, mais on va éviter les subtilités du style
    printf("%s", ptr++) qui peut être assez casse gueule. Je sais que ce
    truc n'arrivera ni avec gcc, ni avec VC++. Mais dans le cas général,
    c'est à proscrire, parce que, en C89 qui ne connaît pas inline, ça
    pourrait bien terminer en :

    write(FILENO_STDOUT, ptr++, strlen(ptr++));

    qui est une expression qui contient un méchant effet de bord !

    Pour revenir au sujet qui nous intéresse. ton compilo n'a aucune raison
    de savoir si ton printf() est ou n'est pas synchrone. Tu n'as aucun
    moyen de le maîtriser le déroulement des opérations dans la libc
    (contrairement à Motif, où tu peux forcer la libXm dans un mode synchrone).
    En d'autres termes, même dans un environnement monotâche, tu peux avoir
    une libc qui bufferise et qui n'envoie tes informations à la console que
    lorsqu'elle en a envie (c'était une pratique de la libc du compilo C
    TSC tournant sous Flex-9 qui affichait la sortie standard quand il y
    avait plus d'une ligne [80 caractères] à afficher et elle affichait
    ligne par ligne.). Croire que le comportement synchrone est
    un dû est une erreur de programmation. Enfin, c'est toi qui vois.

    Personnellement, je me tape du C depuis une grosse vingtaine
    d'années. Durant tout ce temps, j'ai eu l'occasion de corriger pas
    mal de code (du style de ceux des thésards que j'encadrais). Je suis
    tombé comme tout le monde (et je tombe encore de temps en temps) sur
    des subtilités de la norme C. Que ceux qui n'ont jamais écrit de
    telles bourdes me lancent la première pierre. Néanmoins, il y a un
    certain nombres d'erreurs que je ne fais plus et mon expérience me
    dit que la plupart des erreurs non reproductibles dans un programme
    en C qui ne vient pas d'erreur de mémoire vient de ces préjugés.
    C'est aussi entre autres pour cela que j'ai écrit mon propre langage
    de programmation à l'usage de mon labo.



    Naon !



    J'espère bien ! ;-)



    De rien, aujourd'hui, c'était gratuit ;-)

    JKB

On 16 oct, 15:17, JKB




Ah bon !
J'ai cru qu'il s'agissait de ceci :
http://tinyurl.com/3qxwjzl
Mais s'il s'agit d'un lancer d'une station Sparc,
mEA%me E0% mon E2%ge j'aurai bien le temps d'esquiver.





Si, parce-que - dans ce cas - c'est *moi* qui code le
comportement en aval de printf(), j'y suis bien obligE9%,
sinon comment veux-tu que le truc sache comment s'y prendre,
vu qu'il n'a aucune idE9%e du format, ni des ports de sortie, etc ?
Sous DOS ou Windows ou autre je te crois volontiers,
mais ce que je dE9%cris est totalement diffE9%rent.




Evidemment, l'usage de prE9% ou post incrE9%mentation
dans une macro c'est du casse-pipe garanti.

Sinon, personnellement je ne flush() que les sorties fichier,
et uniquement quand j'ai besoin d'EA%tre sFB%r que
ca se fasse E0% un endroit voulu de mon programme.




Oui, j'entends bien et j'acquiesce trE9%s volontiers,
mais tu persistes E0% ignorer les cas oF9% un printf()
est AB% dE9%routE9% maison BB% par le programmeur.
( dE9%ja je t'entends d'ici marmonner qu'E0% ce moment-lE0%
ce n'est plus du printf standard C ... oui, mais bon. )




LE0%, c'est sFB%r qu'il n'y a pas mieux.

A une E9%chelle plus modeste, il y a quelque temps dE9%ja
je m'E9%tais fait un compilo maison E9%crit en C,
pour un langage maison (que j'ai nommE9% C-- :o)
pour faire facilement du calcul sur des quaternions avec
de TRES belles sorties 3D grE2%ce au merveilleux OpenGL.
En nettoyant correctement les sources, je trouverai bien E0%
caser ca dans un projet pro, parce-que ca en jette un max.





ME9%ssie !
Je dis cela justement parce-que sur une carte uC sans OS
c'est *moi* qui me tape l'envoi des chars vers le LCD
par un dE9%tournement du printf() qui remplit un buffer RAM,
qui en aval sera vidE9% par une interruption,
alors je sais pertinemment que dans ce cas il n'y a aucune,
mais aucune obligation de '\n' pour envoyer les chars.





Ben tiens : je ne tiens pas E0% ce que, pour enfoncer le clou,
en un click tu coupes l'alimentation rE9%seau de mon arrondissement.





Bon, ce n'est pas aujourd'hui que je vais me faire embaucher :o)
Mais si tu tiens E0% EA%tre rE9%tribuE9% pour toutes ces informations,
tu peux te payer sur une avance de mon futur salaire :oD

Le Sun, 16 Oct 2011 07:23:35 -0700 (PDT),


    Et non, parce qu'à moins d'écrire ta propre libc, donc ton propre
    compilo, tu es tributaire des fichiers d'inclusion.


ceci :


    Je viens de te dire que fflush() sur les fichiers, ça ne sert à rien
    s'il n'y a pas un fsync() qui suit...


raison

synchrone).

avoir

que


    Exactement. D'ailleurs c'est _mal_ de dérouter une fonction
    standard. Plus casse-gueule que ça, je ne vois pas.



    Je répète que c'est _mal_ d'utiliser pour cela printf().



    Je m'inscris par avance.

    JKB