Discussion :

[emmesse]

bonjour,

j'ai deux fichiers:
lexical.hpp

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
#ifndef OBJETS_HPP
#define OBJETS_HPP
#include "commun.hpp"
#include <string>
 
class lexical{
private:
	diagramme *lexique[NBULEX];
	doubleTampon leDoubleTampon;
	std::string lexeme;
public:
	lexical(char *source);
	ULex anaLex();
};
#endif

lexical.cpp

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
#include "lexical.hpp"
using namespace std;
 
lexical::lexical(char *source){
	lexique[0]=new separateur;
	lexique[1]=new commentaires;
	lexique[2]=new identificateur;
	lexique[3]=new finFichier;
	lexique[4]=new nbreelE;
	lexique[5]=new entierE;
	lexique[6]=new nbreel;
	lexique[7]=new entier;
	lexique[8]=new add;
	lexique[9]=new moins;
	lexique[10]=new etoile;
	lexique[11]=new slash;
	lexique[12]=new po;
	lexique[13]=new pf;
	leDoubleTampon.init(source);
}

lors que je compile, j'obtiens ce messauge d'erreur:

Code :

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

1
2
3
lexical.cpp:8:1: error: ‘lexical’ does not name a type
 lexical::lexical(char *source){
 ^~~~~~~

quequ'un a une idée?

[dalfab]

Bonjour,
As-tu bien copié le début du fichier lexical.cpp? N'y a-t-il pas d'autres includes avant?
Le #define OBJETS_HPP est-il bien utilisé une seule fois, le nom doit être unique.

Attention, on ne doit normalement pas appeler new dans un code, sinon penser à écrire 5 méthodes de plus, voir "the big five rules".

[emmesse]

il falait remplacer OBJETS_HPP par LEXICAL_HPP

[emmesse]

en ce qui concerne le new, j'ai bien libéré les élément du tableau (delete) avec des destructeurs polymorphes (virtual ~diagramme())

[ternel]

Et en cas de copie du lexical? Et d'un move?

[emmesse]

Et en cas de copie du lexical? Et d'un move?

mon objet lexical n'est jamais copié

[koala01]

Salut,

en ce qui concerne le new, j'ai bien libéré les élément du tableau (delete) avec des destructeurs polymorphes (virtual ~diagramme())

Le problème, c'est qu'avec les quatorze new que tu as, tu as aussi quatorze occasions de te ramasser une std:bad_alloc (l'exception "type" lancée lorsque new échoue à faire ce qui est demandé)...

Le premier new ne posera peut-être pas de problème particulier si il échoue, vu que rien n'a encore été alloué dynamiquement (du moins, au niveau de cette classe, s'entend), mais les treize suivants peuvent mener à des catastrophes, parce que, s'ils échouent:

1. le fait de lancer une exception te fera sortir du constructeur, et, avec un peu de malchance, de la portée dans laquelle ton instance de lexical est créé ==>tu auras une fuite mémoire sur tous les pointeurs pour lesquelles l'allocation dynamique aura été menée à bien,
2. Le fait de lancer une exception te fera sortir du constructeur, et, avec un peu de malchance, tu restera dans la portée dans laquelle ton instance de lexical est créée, mais tous es pointurs pour lesquelles l'allocation dynamique n'aura pas eu lieu pointeront vers une adresse invalide, qui a peut de chances d'être représentée par nullptr. ==> plantage garanti la première fois que tu essayeras de déréférencer l'un de ces pointeurs

Bref, tu es perdant dans tous les cas

De plus, ton lexical ne devrait connaitre les éléments de lexique que comme des... diagrammes. Il n'y a aucune raison qu'il connaisse le type réel des quatorze éléments représentés par ces pointeurs.

C'est d'autant plus vrai que, si tu introduit cette connaissance pour le constructeur de ton lexical, toutes les données membres profiteront de cette connaissance, et, d'ici à ce que tu te retrouves avec un code proche de

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
 
//j'utilise static_cast, car on sait pertinemment de type réel de chacun des élément de lexique
switch( index){
    case 0:
        static_cast<separateur *>(lexique[0])->someSeparateurSpecifiqueFunction();
        break;
    case 1:
        static_cast<commentaires*>(lexique[1])->someCommentairesSpecifiqueFunction();
        break;
    case 1:
        static_cast<identificateur*>(lexique[2])->someIdentificateurSpecifiqueFunction();
        break;
    /* ... */
    case 13:
        static_cast<pf*>(lexique[13])->somePfSpecifiqueFunction();
        break;
}

il n'y aura qu'un pas que je suis sur que tu vas t'empresser de franchir

Ca fonctionne, oui... Tant que tu n'essayeras pas de rajouter un diagramme...

Car, là, tu dis purement et simplement "adieu" au second principe SOLID, à savoir O pour OCP (Open Close Principle ou principe "ouver /fermé", selon lequel un code doit être "ouvert aux évolutions", mais "fermé au modifications". En d'autre termes : une fois que ton code est écrit et validé (qu'il fait ce qu'il est sensé faire), tu ne dois plus y toucher, à moins de corriger un bug.

Pire encore, tu dis "adieu" au principe DRY (Don't repeat yoursef : "nous vous répétez pas"), et cela t'occasionnera encore d'autres problèmes.

Enfin, en faisant en sorte que ce soit ta classe lexical qui s'occupe de la création de tes diagramme, tu lui donne une responsabilité supplémentaire (même si elle est limitée au constructeur), si bien que cette classe se retrouve désormais avec au moins deux responsabilités distinctes -- trois si l'on considère celle de libérer la mémoire de tous ces pointeurs dans le destructeur -- (et sans doute bien d'avantage), à savoir:

1. Créer tous les diagrammes;
2. Maintenir les diagrammes en mémoire aussi longtemps qu'elle en a besoin
3. Libérer la mémoire occupée par les diagrammes une fois qu'elle a fini.
4. je ne connais pas ta classe, mais je suis sur qu'elle prend encore tout plein de responsabilités liées à l'utilisation de ces diagrammes... Me trompés-je

Je me suis arrêté à trois responsabilités certaines Cela en fait au moins deux de trop selon le premier principe SOLID, à savoir : S pour Single Responsability Principle (ou principe de la responsabilité unique) : chaque type de donnée, chaque donnée, chaque fonction ne devrait s'occuper que d'une seule et unique chose, de manière à pouvoir s'assurer qu'il / elle s'en occupe correctement.

Je vais m'arrêter là, mais voici ce que m'inspire les quelques lignes de code que tu nous a montrées. Et je suis sur qu'il y aurait encore bien des choses à dire sur le reste du code