Forum Programmation.c Le break dans le fork()

Posté par  .
Étiquettes : aucune
0
17
juin
2006
Bonjour,

je fais des test au niveau du fork car j'ai un partiel mardi de programmation system en c et j'ai fait des tests avec des break mais j'arrive pas à comprendre le résultat d'un test.Voici le code, c'est un code simple je ne gére pas les erreurs ni rien c'est juste pour faire des test :

#include
#include <sys/wait.h>

using namespace std;

int main ()
{
for (int i=0;i<4;i++)
{
pid_t p = fork();
switch (p)
{
case 0 :
{break;
}
case 1 :
{cout << "mu " << endl;break;
}
}
}
}

Alors voila mon probleme quand je met en commentaire le break du fils, les peres ecrivent chacun leur "mu".
Et quand j'active le break du fils ca m'écrit plus rien ^o) et je comprends pas pourquoi ???
Quelqu'un peut-il m'aider ?
Merci d'avance.

Bash'
  • # Euh

    Posté par  (site web personnel) . Évalué à 6.

    T'es au courant que dans le père la valeur de retour de fork() c'est pas 1
    mais le n+ de PID ?
    • [^] # Re: Euh

      Posté par  . Évalué à 3.

      Ça, et le fait que break pose des problèmes d'incompatibilité avec fork()... :)
    • [^] # Re: Euh

      Posté par  . Évalué à 4.

      ah oui zut ch'ui fatigué là je crois :S
      Mais c'est gentil d'avoir répondu si vite.
      Merci.
      • [^] # Re: Euh

        Posté par  . Évalué à 4.

        On ajoutera également les faits suivants :

        - « cout », c'est du C++ et pas du C.
        - Tel que ton programme est écrit, tes breaks sortent de ton switch ... case, mais pas de ta boucle for. Moralité, les fils forquent à leur tour, et tu crées 4! processus en tout, soit 24 processus.
        • [^] # Re: Euh

          Posté par  . Évalué à 3.

          Pour chipouiller encore un peu, declarer des variables (pid_t p) au milieu d'un for(), ça fait pas très c non plus, en général, on les met au debut de la fonction.
          Autre chipouille, ton using namespace std; c'est du c++ aussi.
          Et tant que j'y suis, en compilant avec -Wall tu remarquera qu'il te manque moultes include. sys/types.h , unistd.h et éventuellement stdio.h si tu veux changer ton affichage par un printf().

          En gros, ton prog est un melange de c / c++.

          Je te conseil de lire le man 2 fork, et surtout les valeurs renvoyés. C'est faisable avec un switch, utilise default.
          • [^] # Re: Euh

            Posté par  . Évalué à 2.

            Pour chipouiller encore un peu, declarer des variables (pid_t p) au milieu d'un for(), ça fait pas très c non plus, en général, on les met au debut de la fonction.


            En réalité, on les déclare au début d'un bloc délimité par les accolades, car celui-ci ouvre un nouveau cadre de pile. Je n'ai jamais essayé d'en déclarer à l'intérieur d'un switch mais c'est tout-à-fait légal dans une boucle for par exemple ...

            Certains précompilateurs (celui de Sybase pour le Embedded C SQL, par exemple) ouvrent carrément des accolades « nues », sans condition initiale. Cela respecte totalement les prérogatives du langage même si c'est assurément dégueulasse et que ça souligne un défaut de conception sous-jacent ...
            • [^] # Re: Euh

              Posté par  (site web personnel) . Évalué à 2.

              Heu par contre déclarer une variable a l'intérieur d'un for est pas censé être légal...

              Ni même le int i = 0 a l'intérieur de la déclaration du for...

              Pour le premier problème ça revient a créer 4 fois la même variable, avec gcc en mode strict c99 tu te prendra une erreur...

              Pour le int i dans la déclaration du for c'est purement illégal en c
              • [^] # Re: Euh

                Posté par  . Évalué à 3.

                Il me semble qu'il est tout à fait autorisé de déclarer des variables en début de tout bloc, y compris dans un for, et non ça ne crée pas la variable plusieurs fois.

                Pour le "int i = 0", c'est justement en C99 que c'est légal, tout comme la possibilité de déclarer des variables n'importe où (comme en C++).
              • [^] # Re: Euh

                Posté par  . Évalué à 2.

                Pour le premier problème ça revient a créer 4 fois la même variable, avec gcc en mode strict c99 tu te prendra une erreur...


                Non, puisque tu entres dans le bloc et le quitte quatre fois de suite ...
                • [^] # Re: Euh

                  Posté par  . Évalué à 1.

                  Ca le quitte pas vraiment non plus. Y'a qu'une seule variable dans la pile, que ça soit une boucle ou non, c'est un bloc.

                  Par rapport à ce qui est dit au-dessus, mieux vaut créer les variables dans le bloc où elles sont utilisées, le plus interne possible, ça donne une vision plus claire de ce qui se passe (moins de variables "parasites"). C'est un peu le même principe qui fait éviter les variables globales, là c'est la même chose à l'échelle d'une fonction.
                  • [^] # Re: Euh

                    Posté par  (site web personnel) . Évalué à 2.

                    Effectivement en -std=c99 ça marche, mais par défaut gcc te jette avec l'erreur suivante :
                    test.c: In function &#8216;main&#8217;:
                    test.c:6: error: &#8216;for&#8217; loop initial declaration used outside C99 mode

                    Le code :
                    #include <stdio.h>

                    int main(int argc, char **argv)
                    {
                    for(int i = 0; i < 5; i++)
                    {
                    printf("i = %d\n", i);
                    }
                    return 0;
                    }
                    • [^] # Re: Euh

                      Posté par  . Évalué à 2.

                      D'accord, j'ai posté trop vite.

                      La déclaration d'un int dans l'entête de la boucle, oui, est interdit par le C99 (et tant mieux parce que c'est sale). Par contre rien ne t'empêche de créer une locale dans le corps de la boucle, entre les accolades ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.