tableaux et fonction

[invite64056dd8]

Bonjour à toutes et à tous,
j'ai une question très simple pour les gens qui on l'habitude de programmer en CPP, voilà je vous explique:
je veux écrire un programme qui calcule la moyenne d'un tableau via une fonction (sensée de calculer la moyenne), voilà ma proposition ,

#include <iostream>

using namespace std;


int main()
{
    int const cell(6);
    int a[cell];
    double AverageFunct(double a[],int cell);
    double moy(0);

    a[0] = 12;
    a[1] = 19;
    a[2] = 6;
    a[3] = 12;
    a[4] = 14;
    a[5] = 15;


  moy=AverageFunct(a[],5);

  cout<< moy <<endl;

    return 0;
}


double AverageFunct(double a[], int cell)
{
        double aver;

    for(int i(0); i<cell ; i++)
    {
        aver+=a[i];
    }
     aver/=cell;

     return aver;

}

le grand souci pour moi est l'affichage de la fonction !
merci pour votre aide .
-----

[invite4492c379]

Hello,

ton code a quelques petits problèmes, rien de trop grave je te rassure :

Les corrections sont en gras

#include <iostream>

using namespace std;


int main()
{
    int const cell(6);


    // int a[cell];
    double a[cell]; // Ta fonction AverageFunct a une signature
                            // qui demande un tableau de double en entrée

    // AverageFunct(double a[],int cell);
AverageFunct(double a,int cell); // Pb de syntaxe, pour un tableau en paramètre 
                                                         // on ne passe que son nom

 double moy(0);

    a[0] = 12;
    a[1] = 19;
    a[2] = 6;
    a[3] = 12;
    a[4] = 14;
    a[5] = 15;


    moy=AverageFunct(a[],5);

    cout<< moy <<endl;

    return 0;
}


double AverageFunct(double a[], int cell)
{
    double aver;

     for(int i(0); i<cell ; i++)
    {
        aver+=a[i];
    }
    aver/=cell;

    return aver;

}  

[invite1c6b0acc]

Bonjour,

Attention, photon57, ta correction est justifiée, mais tu t'es trompé dans la modif du code :
tu as fait ta correction de syntaxe de la fonction sur le prototype au lieu de la faire sur l'appel de la fonction.

Je pense que tu voulais écrire :

AverageFunct(double a[],int cell);
(...)
moy=AverageFunct(a,5);

[invite4492c379]

Merci Chanur

Ma faute ...

[A voir en vidéo sur Futura]

[invite2d7144a7]

Bonjour,

À quoi il faut ajouter l'utilisation d'une variable locale (aver) non initialisée dans la fonction AverageFunct.

Petit rappel : une variable locale est créée dans la pile, et n'est jamais initialisée automatiquement. Et paf les erreurs de calcul arrivent.

[invite4492c379]

Bonjour,

À quoi il faut ajouter l'utilisation d'une variable locale (aver) non initialisée dans la fonction AverageFunct.

Petit rappel : une variable locale est créée dans la pile, et n'est jamais initialisée automatiquement. Et paf les erreurs de calcul arrivent.

Bon pas jamais, mais effectivement c'est une très mauvaise pratique que de ne pas initialiser ses variables. Souvent ça s'apprend en mode debug

[invite2d7144a7]

Bonjour,

Bon pas jamais, mais effectivement c'est une très mauvaise pratique que de ne pas initialiser ses variables. Souvent ça s'apprend en mode debug

Si tu connais un cas où une variable locale à une fonction a été initialisée automatiquement, je suis preneur des conditions, en particulier du compilateur utilisé, et avec quelles options.

[Jack]

Tu connais des cas d'initialisation de variables locales en C++?

A+

PS: mince j'ai été un poil trop lent.

[invite1c6b0acc]

Bonjour,

Tu connais des cas d'initialisation de variables locales en C++?

Si tu connais un cas où une variable locale à une fonction a été initialisée automatiquement, je suis preneur des conditions, en particulier du compilateur utilisé, et avec quelles options.

Ben oui ...

Le compilateur Microsoft Visual Studio, en mode Debug, initialise touts les octets des variables locales automatiques à 0xcc
De plus, il ajoute une initialisation à 0xcd aux octets allouées par malloc() et pave la zone allouée de 0xdd quand on la libère.
En mode Release, il ne fait rien de tel.

Je pense que c'est pour avoir le plus de chance possible que le programme ne se comporte pas de la même façon en Debug et en Release ...
C'est plus fun pour debugger ...
Ils ont le sens de l'humour chez microsoft !

[invite4492c379]

Bon pas jamais, mais effectivement c'est une très mauvaise pratique que de ne pas initialiser ses variables. Souvent ça s'apprend en mode debug

Bonjour,

Si tu connais un cas où une variable locale à une fonction a été initialisée automatiquement, je suis preneur des conditions, en particulier du compilateur utilisé, et avec quelles options.

Tu connais des cas d'initialisation de variables locales en C++?

A+

PS: mince j'ai été un poil trop lent.

Justement, c'est le problème du pas jamais ... comme le font justement remarquer Chanur et mnon smiley il est très fréquent que le débuggeurs le fassent ... l'apparition du Heisenbug. Tout fonctionne bien en mode debug et tout plante lamentablement en prod ... après t'être arraché le cuir chevelu sur ce genre d'erreur tu deviens très attentif à ce genre de détails

[invite1c6b0acc]

après t'être arraché le cuir chevelu sur ce genre d'erreur tu deviens très attentif à ce genre de détails

Ouaip ...

[polo974]

Un autre détail:
faire la moyenne de 6 éléments en divisant par 5, bof...
enfin, ça ne doit pas se voir de toute façon tant qu'aver n'est pas initialisé...

[Jack]

Bonjour,

Le compilateur Microsoft Visual Studio, en mode Debug, initialise touts les octets des variables locales automatiques à 0xcc
De plus, il ajoute une initialisation à 0xcd aux octets allouées par malloc() et pave la zone allouée de 0xdd quand on la libère.
En mode Release, il ne fait rien de tel.

oui tu as raison, mais faut-il prendre en compte le mode debug? Le comportement n'est pas défini par la norme. En revanche, en exploitation, c'est bien le mode release qu'il faut considérer, et pour des raisons d'efficacité, il a été prévu de ne pas perdre de temps à initialiser la pile. C'est ce qui fait la force et la faiblesse du C.

Je pense que c'est pour avoir le plus de chance possible que le programme ne se comporte pas de la même façon en Debug et en Release ...
C'est plus fun pour debugger ...
Ils ont le sens de l'humour chez microsoft !

Ca fait penser aux auto test de la RAM. Je ne sais plus si c'est d'actualité, mais au boot, un motif de 0 et de 1 était écrit en mémoire et relu: ça pouvait donc donner une séquence de 0x55 ou de 0xaa. En l’occurrence il s'agit d'une séquence 11001100110 etc.

A+

[invite4492c379]

oui tu as raison, mais faut-il prendre en compte le mode debug? Le comportement n'est pas défini par la norme. En revanche, en exploitation, c'est bien le mode release qu'il faut considérer, et pour des raisons d'efficacité, il a été prévu de ne pas perdre de temps à initialiser la pile. C'est ce qui fait la force et la faiblesse du C.
(...)

La norme C99 ne définit pas grand chose point de vue matériel, jamais les mots stack ou heap ne sont mentionnés par exemple. Tout ça est à la charge de l'implémentateur (ça existe ce mot ?). Si la norme ne dit pas qu'il faut initialiser qqch alors il ne faut surtout pas le faire pour pouvoir gagner quelques microsecondes qui seront utiles dans les benchmarks.
Oui la faiblesse du C c'est ça aussi. C'est un langage rapide pour pro.

Sinon pour les variables qui ne sont pas initialisées il y a toujours l'option -Wall de gcc (ou une plus précise mais évidemment il faut lire la man page). Ça n'impacte pas les banchmarks et laisse la possibilité à l'utilisateur de s'assurer un minimum de ne pas faire trop de conneries.

[invite64056dd8]

je vous remercie énormément!

[invite2d7144a7]

Mai,

Justement, c'est le problème du pas jamais ... comme le font justement remarquer Chanur et mnon smiley il est très fréquent que le débuggeurs le fassent ... l'apparition du Heisenbug. Tout fonctionne bien en mode debug et tout plante lamentablement en prod ... après t'être arraché le cuir chevelu sur ce genre d'erreur tu deviens très attentif à ce genre de détails

Désolé, mais le mode debug est trop spécial pour venir me dire que parfois les variables locales sont initialisées automatiquement.

Ce mode n'étant utilisé que pour un programme qui ne fait pas ce qu'il est censé faire, il est clair que je ne tiens pas compte de ça.

Mais bien entendu, c'est au programmeur de savoir que les modes debug font plein de trucs que ne feront pas leur programme en mode release. Je suis d'ailleurs contre ces manips de ce mode, car ça tend plutôt à gêner la recherche de bug qu'à l'aider.

[invite4492c379]

Mai,

Désolé, mais le mode debug est trop spécial pour venir me dire que parfois les variables locales sont initialisées automatiquement.

Ce mode n'étant utilisé que pour un programme qui ne fait pas ce qu'il est censé faire, il est clair que je ne tiens pas compte de ça.

Mais bien entendu, c'est au programmeur de savoir que les modes debug font plein de trucs que ne feront pas leur programme en mode release. Je suis d'ailleurs contre ces manips de ce mode, car ça tend plutôt à gêner la recherche de bug qu'à l'aider.

Le problème est qu'avec une variable non initialisée correctement, ça plante et tu passes en mode debug. Tout ça car on préfère gagner en vitesse d'exécution plutôt que de gagner en vitesse de développement (sans compter la gestion mémoire du C ...).
Il n'est pas étonnant que java ou c# soit de plus en plus préférés.

[invite2d7144a7]

Bonjour,

Quand ça plante, j'arrête le programme, et je vérifie mon code (mes programmes sont très structurés en modules, chaque module testé séparément, et ils ne sont réunis que pas à pas, ce qui fait que je sais où chercher les problèmes quand il y en a, rares étant ceux conduisant à un plantage, la rigueur de développement éliminant la plupart des causes de gros bug).

D'autre part, "avec une variable non initialisée correctement", ça ne plante pas forcément, mais les calculs ont de très fortes chances d'être faux, ce qui est encore plus vicieux comme erreur, sauf si on a les moyens de contrôler les résultats par un autre moyen, ce qui n'est pas toujours le cas

[invite4492c379]

Bonjour,
Quand ça plante, j'arrête le programme, et je vérifie mon code (mes programmes sont très structurés en modules, chaque module testé séparément, et ils ne sont réunis que pas à pas, ce qui fait que je sais où chercher les problèmes quand il y en a, rares étant ceux conduisant à un plantage, la rigueur de développement éliminant la plupart des causes de gros bug).

C'est clair que la conception est la clé de la réussite. Malheureusement, les demandes d'aide proviennent souvent de personnes à qui on a malencontreusement conseillé de développer en C pour diverses bonnes ou mauvaises raisons (C c'est mieux que Java car C est plus rapide, par exemple).
Je n'ai jamais mis en doute tes compétences. Mais c'est aussi pourquoi je parlais de C comme un langage qui ne devrait pas
être conseillé à la légere car dans la majorité des cas cela dégoutera pour longtemps le pauvre hère qui va essayer de se lancer.

D'autre part, "avec une variable non initialisée correctement", ça ne plante pas forcément, mais les calculs ont de très fortes chances d'être faux, ce qui est encore plus vicieux comme erreur, sauf si on a les moyens de contrôler les résultats par un autre moyen, ce qui n'est pas toujours le cas

Pas forcément Mais tôt ou tard, ne pas initialiser une variable est souvent tout simplement un oubli ... et en C dans le pire des cas tu as toujours ton printf pour débugguer. Cela est acceptable lorsque c'est un hobby ou un projet d'école. Cela devient innaceptable s'il s'agit d'un projet industriel/professionnel. D'où la cobolisation progressive du C dans certains domaines.

[invite2d7144a7]

Bonjour,

Ceux qui ont appris correctement, et ceux qui lisent de temps en temps un bon cours ou didacticiel prennent une habitude qui devrait être systématique, quel que soit le langage utilisé : initialiser toute variable immédiatement après sa déclaration, même si on sait qu'on le fera nécessairement lors de sa première utilisation (par exemple, un compteur de boucle for en C), car nombre de bugs viennent de là : le programme évolue, et on se retrouve à utiliser la variable sans initialisation.

Bon, on va rompre là, sinon ça risque de durer jusqu'à la fin de l'univers.

[invite4492c379]

Bonjour,

Ceux qui ont appris correctement, et ceux qui lisent de temps en temps un bon cours ou didacticiel prennent une habitude qui devrait être systématique, quel que soit le langage utilisé : initialiser toute variable immédiatement après sa déclaration, même si on sait qu'on le fera nécessairement lors de sa première utilisation (par exemple, un compteur de boucle for en C), car nombre de bugs viennent de là : le programme évolue, et on se retrouve à utiliser la variable sans initialisation.

Bon, on va rompre là, sinon ça risque de durer jusqu'à la fin de l'univers.

OK, il suffit de préciser «Ceux qui ont appris correctement» pour ne pas avoir à aller plus loin.

[Dlzlogic]

Bonjour,
J'ai observé avec un certain étonnement une syntaxe que je ne connaissais pas pour initialiser une valeur
int Valeur(25);
Y a-t-il une différence avec ?
int Valeur=25;
Ou est-ce une possibilité qui "fait plus moderne", ou une indication dans la norme ? ou autre-chose ?

Si j'avais un conseil à donner, c'est de se méfier d'une moyenne calculée en faisant l'addition de tous les éléments puis en divisant par le nombre d'éléments, de celle façon on perd de la précision, c'est à dire, en gros, 1 chiffre significatif par dizaine de nombre. Il y a d'autres méthodes.

[invite4492c379]

Salut,
int i(0) est une syntaxe de c++ pour initialiser une variable. Une sorte de sucre syntaxique qui mime l'appel à un constructeur. À mon avis à éviter, l'affectation me semblant plus claire.

[invite2d7144a7]

Bonjour,

Salut,
int i(0) est une syntaxe de c++ pour initialiser une variable. Une sorte de sucre syntaxique qui mime l'appel à un constructeur. À mon avis à éviter, l'affectation me semblant plus claire.

Absolument d'accord.