Discussion :

[Kiwii]

Bonjour,
Je suis arrivé au chapitre 10 et j'ai ( presque ) réussi le 1er exo.
Pourquoi presque ? Ce que je fais me parait cohérent mais la sortie l'est un peu moins

Je vous donne l'énoncé ;

Créez une fonction avec une variable statique qui est un pointeur (avec un argument par défaut à zéro).
Quand l'appelant fournit une valeur pour cet argument, elle est utilisée pour pointer au début d'un tableau de
int. Si vous appelez la fonction avec un argument à zéro (utilisant l'argument par défaut), la fonction retourne
la prochaine valeur dans le tableau, jusqu'à ce qu'il voit une valeur “-1” dans le tableau (pour agir comme
indicateur de fin de tableau). Testez cette fonction dans le main( ).

La fonction est nommée "fonction", le pointeur statique est "point2" et le pointeur qui me sert d'argument est "point"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#include <iostream>
 
using namespace std;
 
// #1
 
 
 
void fonction( int* point = 0 ){
    static int* point2;
 
    if ( point == 0 ){
        for (int i = 0 ; (*point2) != -1 ;i++ ){
            point2 += i;
            cout << *point2 << endl;
        }
    } else {
        point2 = point;
        cout << "tableau charge : " << point2 << endl;
    }
}
 
int main(){
    int tab[5] = { 42 , 7 , 5 , -8 , -1};
    int taab[6] = { 83 , 83 , -83 , -1 , 42};
 
    fonction(&tab[0]);
    fonction();
 
    fonction (&taab[0]);
    fonction ();
 
    return(0);
}

Merci d'avance pour vos critiques


Edit : Je crois que je me fais avoir sur la taille du pointeur

[Hoder]

Bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#include <iostream>
 
using namespace std;
 
// #1
 
 
 
void fonction( int* point = 0 ){
    static int* point2;
 
    if ( point == 0 ){
        for (int i = 0 ; (*point2) != -1 ;i++ ){
            point2 += 1; // Avec "+= i", tu faisais +1, +2, +3, +4 au lieu de juste faire +1
            cout << *point2 << endl;
        }
    } else {
        point2 = point;
        cout << "tableau charge : " << *point2 << endl; // Oubli du '*' (erreur que tu n'as pas fait juste au-dessus)
    }
}
 
int main(){
    int tab[5] = { 42 , 7 , 5 , -8 , -1};
    int taab[6] = { 83 , 83 , -83 , -1 , 42};
 
    fonction(&tab[0]);
    fonction();
 
    fonction (&taab[0]);
    fonction ();
 
    return(0);
}

Voilà Testé et vérifié.

[Steph_ng8]

Bonjour,

Un bon compilateur te dirait qu'une des variables est susceptible d'être utilisée alors qu'elle n'est pas initialisée.
Pas bon du tout…

Que se passe-t-il si la première fois que l'on appelle cette fonction on ne lui passe pas d'argument ou un argument NULL ?
Ou si on le fait après la découverte de la valeur « -1 » ?

la fonction retourne la prochaine valeur dans le tableau

Cette fonction n'est censée sortir qu'une seule valeur à la fois.

la fonction retourne la prochaine valeur dans le tableau

Visiblement, cette fonction est censée retourner une valeur.
Jusqu'à preuve du contraire, « void » indique qu'une fonction ne retourne rien.

Sinon, deux petites remarques.
Lorsque l'on déclare et initialise un tableau en même temps, on n'est pas obligé de spécifier sa taille.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int tab[] = { 42 , 7 , 5 , -8 , -1}; // Ça suffit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

&tab[0] == tab

[Kiwii]

Comment j'ai fait pour rester sur mon "i" alors que je pensais +1 ( j'ai relu plus de 10 fois cette ligne ).
L'* n'était pas un oubli et me servait à repérer le tableau par son adresse et non par sa première valeur.

Il est clair qu'il manque des structures de contrôle, j'ai pensé à ces éventuels problèmes mais mon soucis principal restait de faire fonctionner ce machin.
Le second fait est que je me suis trompé lors de la lecture de l'énoncé
Pas grave, je l'aurais fait de 2 façon différentes.

A propos des 2 remarques : c'est vrai que je m'embête avec des formules plus longues que nécessaire ...

Merci à vous deux, je posterai le code final et cocherai résolu en même temps .

PS : Est ce qu'il est possible d'afficher le nom d'une variable pointée à l'utilisateur ? J'aimerais avoir une sortie du style : " Tableau chargé : tab " et non l'adresse en hexadécimal ( l'adresse me sert de repère mais ce serait plus simple un nom qu'un nombre en hexa )

[Hoder]

A moins que ce ne soit une nouveauté en C++ dont je n'ai pas entendu parler (je débute en C++), je ne crois pas que ce soit possible et Google semble me le confirmer (ou alors mauvaise recherche...).

[ymoreau]

Un nom de variable n'est visible que dans ton code, c'est un "alias", le compilateur va justement transformer tout ça en adresses hexadécimales. Si tu as besoin de voir ce genre d'informations, c'est possible en utilisant un debugger et en compilant l'option autorisant le debuggage (-g pour gcc).

[Emmanuel Deloget]

Un nom de variable n'est visible que dans ton code, c'est un "alias", le compilateur va justement transformer tout ça en adresses hexadécimales. Si tu as besoin de voir ce genre d'informations, c'est possible en utilisant un debugger et en compilant l'option autorisant le debuggage (-g pour gcc).

Il est tout de même possible de s'en sortir, malgré ce problème. Pour expliquer tout ça, on va reprendre un point intéressant, qui va avoir du sens juste après.

La compilation d'un programme s'effectue en plusieurs phases. Ainsi, pour chaque fichier compilé, on a les phases suivantes :

1) pré-processing : c'est à ce moment que le pré-processeur (généralement un programme a part, mais il peut être intégré au compilateur) va gérer les #include, #define, ... bref : presque toutes les ligens qui commencent par un caractère '#'. A la fin de cette étape, on a un gros fichier qui ne contient plus aucune référence à une macro, ou à un autre fichier.

2) compilation : la compilation proprement dite. Cette phase peut elle même être scindée en plusieurs sous-phases :

2.1) l'analyse lexicale : chaque symbole, chaque mot du code source est vérifié pour voir si'il est légal dans le langage utilisé. Par exemple, un identifiant ne doit pas commencer par un chiffre.

2.2) l'analyse syntaxique : une fois qu'il est démontré valide, le mot ou symbole (ce sont les tokens) est considéré, et on essaie de lui trouver un sens logique, au vu de ce qui est déjà connu du code source. Par exemple, le compilateur va trouver les tokens suivants : 'x' '=' 'a' '+' '2' at va en déduire qu'il s'agit d'une addition et que sa syntaxe est valide. Cette phrase est alors découpée est transforme en ce qu'on appelle un arbre syntaxique, qui donne une représentation abstraite du code source. La représentation varie d'un compilateur à l'autre. Il suffit de savoir qu'elle contient l'intégralité des informations données par le développeur (le code source) ainsi que toutes les informations déterminées par le compilateur (tel symbole est un identifiant, tel autre est un nombre, etc).

3) génération de code : l'arbre syntaxique est transformé en langage machine, et le code dit "objet" est généré, sous la forme de fichiers objets (.obj, .o, selon la plateforme). Ce code ne contient plus les informations su type "ceci est une addition", "ceci est un nombre". Ces informations ne sont plus nécessaire à partir de maintenant. De même, toutes les informations concernant la définition de symboles internes à ce fichier sont supprimées, car étant internes, ils ont déjà été utilisés et n'ont plus d'intérêt.

Par contre, d'autres informations sont encore nécessaires : le nom des classes, des fonctions, ... qui peuvent être utilisés dans d'autres fichiers , ainsi que le nom des classes, fonctions, variables, etc qui sont utilisé dans ce fichier mais qui sont définis dans un autre fichier. Parce que pour l'instant, nous n'avons compilé qu'un seul fichier, et ce fichier fait peut-être référence à des informations qui sont en fait présentes dans d'autres fichiers (par exemple, le code d'une classe). Dans le fichier objet, on va donc retrouver du code à trou et des identifiants donnant des informations sur ces trous.

4) Une fois tous les fichiers compilés, on lance la dernière phase de la génération d'un programme : la phase d'édition de liens. Cette phase parcourt tous les fichiers objets obtenus, détermine où sont les trous, à quoi ils font référence, etc. Il remplace le trou dans un fichier par des informations provenant d'un autre fichier, de manière à la fin à obtenir un seul fichier objet complet, sans trou : le programme. Une fois l'édition de liens terminée, les noms des classes, des identifiants, etc ne sont plus d'aucune utilité. Ils ne sont donc pas inclus dans le fichier final, afin que l'utilisateur ne le demande de manière expresse (par exemple dans l'optique de débugger son programme).

Pour résumer :

A la fin de la phase 1: les macros ont disparu, de même que les noms de fichier #include, etc.

A la fin de la phase 2.2: les informations sur la structure du code (ceci est une addition,...) ne sont plus disponibles.

A la fin de la phase 3: les informations de nom des symboles locaux ne sont plus nécessaire, et sont donc supprimés.

A la fin de la phase 4: aucun nom de symbole (classe, variable, etc) n'est plus nécessaire. Tous les symboles sont supprimés.

Comment peut-on faire alors pour obtenir un nom de variable à partir d'une variable ? Une solution consiste à faire comme le propose YoniBlond : demander au compilateur de garder tous les symboles qu'il aurait du enlever. Une fois ces informations présentes dans le fichier final, il devient possible de les récupérer. C'est quand même une tâche très difficile, et je doute que ce soit une bonne idée que vous vous lanciez sur cette trace.

Du coup, l'unique autre solution est de gérer ce problème directement dans votre code, mais en tentant de le faire simplement. Fort heureusement, c'est tout à fait possible, même si j'aurais tendance à déconseiller une telle approche (parce que c'est quand même complexe à faire de manière correcte, et que ça peut poser des problèmes ardus en phase de debug s'il y a un problème).

Il existe une fonctionnalité merveilleuse offerte par le pré-processeur (phase 1). Cette fonctionnalité porte un nom barbare : stringification (prononcez STRINNNGUIFICAISHION) en anglais; je ne connais pas de correspondance en français). Stringifier, c'est transformer en chaîne de caractère. Pour peu qu'on l'utilise correctement, on peut tout strnigifier

C'est relativement simple : lorsque le caractère # est présent autre part qu'au début d'une ligne, et en particulier lorsqu'il est collé à un token quelconque, alors il transforme ce token en chaine de caractère. Un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::cout << #test << std::endl;

Affiche la chaine de caractère test dans la console.

Du coup, que se passe-t-il si je stringifie une variable ? Et bien je récupère le nom de cette variable sous la forme d'une chaine de caractère. C'est aussi simple que ça.

Il y a bien sûr une limitation : si j'écris le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
int tab[] = { 0, 1, 2 };
int* ptab = &tab[0];
std::cout << #ptab << std::endl;

On va bel et bien afficher ptab, et non pas tab. On stringifie exactement ce qui est situé après le caractère #, et non pas ce qui est représenté en vérité par l'identifiant.

Histoire de simplifier l'utilisation de cette fonctionnalité, on va créer une macro (oui, les macros, ce n'est pas bien, mais c'est la seule possibilité dans ce cas; toute autre présentation n'aura pas le résultat attendu).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#define OUT_S(var) "(" << #var << ") " << var
 
// utilisation: std::cout << OUT_S(tab) << std::endl;

Que viens-je de dire ? Qu'on va se retrouver avec la chaine "var" affichée, plutot que ce que représente var ? Et bien non. Car ce n'est pas un identifiant. A chaque fois que la macro OUT_S est utilisée, le pré-compilateur (phase 1) remplacer l'appel de cette macro par son corps, en substituant l'ensemble des informations. Par chance, cette substitution interviens avant la stringification.

Ainsi, std::cout << OUT_S(tab) << std::endl; deviendra le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
std::cout << "(" << #tab << ") " << tab << std::endl;

Qui, juste après, deviendra:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
std::cout << "(" << "tab" << ") " << tab << std::endl;

On a bien le résultat souhaité : on affiche le nom et la valeur de la variable.

[ram-0000]

1) pré-processing : c'est à ce moment que le pré-processeur (généralement un programme a part, mais il peut être intégré au compilateur) va gérer les #include, #define, ... bref : presque toutes les ligens qui commencent par un caractère '#'. A la fin de cette étape, on a un gros fichier qui ne contient plus aucune référence à une macro, ou à un autre fichier.

A la fin de la phase 1: les macros ont disparu, de même que les noms de fichier #include, etc.

Les commentaires sont aussi traités (et supprimés) lors de cette phase

[ymoreau]

C'est un gros hors sujet mais j'ai une question, quel est l'avantage de la Stringification par rapport à l'écriture directe en dur de "cout << "tab" << tab << endl;" ? Puisque la macro requiert de toute façon le nom exact de la variable.

[Emmanuel Deloget]

C'est un gros hors sujet mais j'ai une question, quel est l'avantage de la Stringification par rapport à l'écriture directe en dur de "cout << "tab" << tab << endl;" ? Puisque la macro requiert de toute façon le nom exact de la variable.

Si tu change le nom de la variable, tu n'a pas besoin de changer la chaîne qui la représente. Aucun risque donc que tu ne te mélange dans les noms de variable (ce qui peut arriver en cas de copier/coller). Ca fait une chose de moins à maintenir.

Au delà ? La stringification peut servir à bien d'autres choses. Par exemple, une macro my_assert (pas testée, donc possible qu'il y ait un ou deux pitits problèmes faciles à résoudre).

#define S(text) #text

#define my_assert(cond, code) \
do { \
if (!(cond)) { \
std::cout << "assert: condition " << S(cond) << " failed" << std::endl; \
code; \
} } while (0)

Utilisée ainsi :

void f(bool b)
{
my_assert(b == true, { throw exception("parameter shall be true"); });
}

Si on lui passe false, alors la console affichera "assert: condition (b == true) failed" et une exception sera générée.

[Kiwii]

Voilà, j'ai réalisé ce que l'énoncé demandais à la base ( j'avais fait légèrement plus complexe avant en fait )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// Seconde version
 
int fonction( int* point = 0 ){
    static int* point2;
 
    if ( point == 0 ){
        if ((*point2) != -1){
            point2 += 1;
            return((*point2));
        } else {
            cout << "On est deja a la fin du tableau " << endl;
            return 0;
        }
    } else {
        point2 = point;
        cout << "Premiere valeur du tableau charge : " << (*point2) << endl;
    }
}
 
int main(){
    int tab[] = { 42 , 7 , 5 , -8 , -1};
    int taab[] = { 83 , 83 , -83 , -1 , 42};
 
    fonction(tab);
    cout << fonction() << endl;
 
 
    fonction (taab);
    cout << fonction() << endl;
    cout << fonction() << endl;
    cout << fonction() << endl;
    cout << fonction() << endl;
    cout << fonction() << endl;
 
    return(0);
}

Il est clair qu'il manque des structures de contrôle mais j'ai un peu la flemme de les mettre. Je voit bien ce qui manque : l'histoire de l'appel de la fonction sans tableau chargé, la supression du 0 qui ressort quand
"cout << "On est deja a la fin du tableau " << endl;" sort ...

Merci à tous, c'est parti pour le 2e


EDIT : Pour le 3e exo, je crois qu'il y a une erreur dans la traduction ( je crois ^^' ) :

Créez une classe avec un tableau de ints. Définissez la taille du tableau en utilisant static const intdans la
classe. Ajoutez une variable const int, et initialisez la dans la liste d'initialisation du constructeur ; rendez le
constructeur inline. Ajoutez un membre static intet initialisez le avec une valeur spécifique. Ajoutez une
fonction membre static qui affiche la donnée du membre static. Ajoutez une fonction membre inlineappelant
print( )pour afficher sur la sortie toutes les valeurs du tableau et pour appeler la fonction membre static.
Testez cette fonction dans le main( ).

Creer une fonction utilisant un mot clef du language est impossible me semble t'il. On fait mention d'une fonction nommé print() plus tard, je suppose que cette fonction nommée static() est en fait print().

Je fais ptetre fausse route aussi ^^'

[Emmanuel Deloget]

Creer une fonction utilisant un mot clef du language est impossible me semble t'il. On fait mention d'une fonction nommé print() plus tard, je suppose que cette fonction nommée static() est en fait print().

Je fais ptetre fausse route aussi ^^'

Il ne s'agit pas de créer une fonction membre dont le nom est static(), mais de créer une fonction membre statique, c'est à dire partagée par toutes les instances de la classe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
class A
{
public:
  static void fonction();
};

L'exercice a pour but de faire comprendre la différence entre une fonction membre normale et une fonction membre statique, ainsi que les différences entre une variable membre normale et une variable membre statique.

[Steph_ng8]

Ajoutez une variable const int

Euh… Je suis le seul à tiquer sur cette phrase ?

[Médinoc]

Oui. Contrairement à java/C#, const signifie en général "variable non-modifiable", pas toujours "constante connue à la compilation"...

Un paramètre const par exemple est toujours une variable. Tout comme une variable membre non-statique const (listes d'initialisation powa).

[Steph_ng8]

Hum… ok.
C'est associer une « variable » avec une idée de « constance » qui me paraissait bizarre, voire contradictoire.
J'ai tendance à considérer toutes les « variables » déclarées avec le mot-clé « const » comme des « constantes nommées », puisqu'on ne peut pas en faire « varier » la valeur, et ce même si cette valeur n'est connue qu'à l'exécution.

Mais peut-être ai-je tort…

[Médinoc]

Mais à ce moment-là, que fais-tu des pointeurs const?

[Steph_ng8]

• const T* : on peut modifier l'adresse pointée, donc sa valeur variable
• T* const : on ne peut pas modifier l'adresse pointée, donc sa valeur constante
• const T* const : idem

Pour moi, le fait que les données pointées puissent être modifiées ou non n'entre pas en ligne de compte.

[Médinoc]

Je pensais plutôt à ce genre de chose:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int a;
int const * pca = &a;

[Steph_ng8]

Pour moi, il n'y a pas de différence.
Comme indiqué plus haut, je considère pca comme une variable.

[Médinoc]

Bien sûr. Mais c'est un pointeur en lecture seule vers une variable, non un pointeur vers une constante.