Aide-Mémoire C++ – Notes de l’Auteur

Note de l’auteur

 

The World is built on C++.

Herb Sutter

C++ est profondément riche et intense comme langage. Avec le temps, il est devenu élégant et Moderne. Malgré des milliards dépensés en marketing, il n’a pas été remplacé par les langages dits « productifs ». Les systèmes d’exploitation comme Microsoft Windows, Mac OS ou Linux sont toujours faits avec. Les suites bureautiques comme Office aussi… Les jeux vidéo…

En 2018, j’ai contacté DUNOD pour leur proposer ce projet de livre car il n’existe que peu de livre sur le C++ Moderne, c’est-à-dire le C++ post C++11, date à laquelle sont apparues tout un ensemble de fonctionnalités comme les pointeurs intelligents, la déduction de type automatique (auto) et la suprématie de la bibliothèque standard STL avec ses strings, containers et algorithmes entre autres.

Beaucoup de livres C+ en français parlent de C++03 mais ne détaillent pas les fonctionnalités des derniers standards comme C++14 et C++17. Le nouveau standard C++20 arrive en Janvier 2020. Ce livre vous permet, par une approche par l’exemple, de connaitre toutes ses fonctionnalités.

En tant que professionnel du développement C++, je suis MVP Developer Technologies et j’ai accès au code source des derniers O.S. Windows. Pour vous donner une idée rapide, Microsoft a toujours fait ses O.S. et ses logiciels en C/C++. Pour Microsoft, le C++ c’est naturel, c’est comme l’électricité. Il n’y a pas de débat. On veut développer un produit, on le fait en C++. C’est avant tout une nécessité de peformance par défaut et de ce que les gens nomment « Power and Performance ». Le C++ ne fait aucun compromis la-dessus. Sans violer le NDA qui me lie à Microsoft, je peux vous dire que le code source de Windows 10 est truffé de C++ Moderne, des templates, d’utilisation de la STL et utilise toutes les fonctionnalités possibles de C++. Le code est propre, dense, orienté objet et comme dit Marian Luparu, Principal Group Manager de Visual C++, « Microsoft is committed to C++ ». Cela veut dire que Microsoft s’engage sur C++. Il ne faut pas oublier que son équipe et son produit, Visual C++ (MSVC),  le compilateur C++ de Microsoft, compile les produits comme Windows 10, Windows Server, Office, SQL Server entre autres donc Visual C++ est le joyau interne de Microsoft : c’est lui qui fabrique les logiciels phares de la société de Redmond. Chez Microsoft, chaque groupe produit fait du C++.

En 2011, Channel9 sortait une vidéo de Craig Symonds et Mohsen Agsen : C++ Renaissance[1]. Le C++ connaît actuellement une renaissance. Cela signifie que, par définition, le langage, les compilateurs et l’outillage de composition évoluent et on arrive à un état qui maximise l’efficacité, la productivité et la créativité des développeurs natifs dans tous les domaines matériels et logiciels (PC, appareils mobiles, systèmes d’exploitation, applications utilisateur, services, etc.). C++ est un langage de programmation « système » puissant, mais c’est plus que cela. C’est orienté objet, mais c’est plus que cela. Chez Microsoft, la plupart des produits phares sont écrits en C++ (et C, comme le noyau Windows…).

Dans le monde Linux, la suprémacie de C/C++ est sans comparaison. Comme dans Windows, le kernel et les drivers sont écrits en C et tout le reste en C++ sauf les couches historiques. Les applications phares comme Apache, MySQL, Redis pour ne citer qu’elles sont faites en C/C++. Il existe même une distribution Linux nommée Gentoo qui propose de construire son envrionnement Linux à partir des sources. Le système portage download un petit compilateur pour compiler GCC puis GCC compile tout : le noyau, les drivers, les couches de l’OS, bash & tools, X-Motif, Gnome, KDE, etc.

Je ne remercierais jamais assez Papy Jean-Marc de m’avoir fait découvrir le monde des ordinateurs quand j’étais tout jeune. Mon premier ordinateur était un Commodore C64 ou je découvrais les jeux vidéo. Puis nous avons eu un Amiga dans les années 80/90 et j’ai découvert AMOS Basic et je suis tombé dans la programmation. Je suis tombé par hasard sur les compilateurs Aztec C et Lattice C/C++ et ce fut mes débuts en C/C++. Puis, mon père a ramené de son travail un PC 286 SX25 avec Borland Turbo C et C++ pour MS-DOS. J’ai fait mes premières applications sous DOS puis pendant mes études, j’ai réalisé tous mes projets en Visual C++ sous Windows. A l’époque, nous sommes sous Windows 3.11 et Visual C++ 1.52c 16 bits. En 1993, Je fais un stage dans une entreprise qui fait un logiciel de 3D sous Windows NT et je découvre MSDN Library July 1994, la documentation des dévelopeurs Microsoft. Je tombe amoureux de cet environnement de Microsoft, des API Windows et du C++. Avec ma première paie je m’achète plein de livres Microsoft Press comme « Programming Windows », « Inside Visual C++ » et de livres sur C++. Le virus est implanté.

 

Christophe Pichaud,

Paris, France.

Samedi 23 novembre 2019 – 06:00 AM

[1] https://channel9.msdn.com/Shows/Going+Deep/Craig-Symonds-and-Mohsen-Agsen-C-Renaissance

La Programmation Orientée Objet en C++

Introduction

Il y a plusieurs façons d’utiliser le C++. On peut être utilisateur de classes ou concepteur de classes. Dans les deux cas, définir, designer et implémenter des classes sont les activités primaires des développeurs C++. Par où on commence ? En général, on démarre avec une abstraction ou un concept. On considère un truc à coder et puis on essaie de voir comment on va gérer son ou ses fonctions, ce qui est interne et ce qui est public et comment on va l’utiliser… Au démarrage de cette réflexion, il faut se mettre la casquette de celui qui va utiliser la classe. Notre exemple de concept pour cet article sera un élément graphique à dessiner comme une ligne, un rectangle, une ellipse, etc. En anglais, c’est un shape.

// C'est une déclaration de classe
class CShape;

// C'est la future manière avec laquelle je veux dessiner des Shapes
bool Draw(const CShape& item);

Ensuite on envisage la classe dans son ensemble :
class CShape
{
public:
	// interface publique

private:
	// implémentation privée
};

Qu’est-ce que l’on met en private/public et comment va-t-elle être structurée.  On commence petit bras et puis la classe prend du volume.

Constructeur et Destructeur

La première question qui vient à l’esprit est comment je vais créer mon objet et ai-je besoin de lui fournir des paramètres. Avec ma classe CShape, on peut se dire, je n’ai pas besoin mais aussi j’en ai besoin. Les deux possibilités existent ! Soit c’est une figure connue -> d’où une énumération pour les types connus et autre possibilité qui est de dessiner une image et là, il me faut un nom de fichier ; tout est ouvert !

enum ShapeType
{
	line,
	circle,
	rectangle,
	left_arrow,
	right_arrow,
	picture
};

L’avantage de l’énumération es que c’est évalué à la compilation. Il ne peut pas y avoir d’erreur sur le nommage car c’est un type explicite contrairement à une simple chaîne de caractères. Voyons sommairement comment pourrait être construite cette fameuse classe CShape…

class CShape
{
public:
	CShape();
	CShape(int x, int y, int xx, int yy, ShapeType type);
	CShape(int x, int y, int xx, int yy, std::string fileName);
	virtual ~CShape();

private:
	std::string m_fileName;
	ShapeType m_type;
};

J’y vois deux façons de créer un shape. Soit à partir de l’énumération soit à partir d’un fichier pour les images. Pour le moment, je ne sais pas comment organiser le dessin du shape. Dois-je le mettre à l’intérieur de la classe ou à l’extérieur ? Je ne sais pas… Il faut du temps pour considérer quelle sera la façon la plus naturelle de réaliser cette opération. Dans le monde Windows GDI+, pour dessiner un élément il faut un handle particulier qui possède toutes les primitives de dessins.  En pensant comment allait être dessiner un élément, on peut envisager d’inclure une méthode Draw dans la classe CShape. La première pensée, c’est de se dire, je vais implémenter tous les cas possibles dans Draw avec une construction qui ressemble à ça :

	void Draw(const CDrawingContext& ctxt) const
	{
		if (m_type == ShapeType::line)
		{
			ctxt.Line(m_rect.left, m_rect.bottom,
				m_rect.top, m_rect.right);
		}
		if (m_type == ShapeType::rectangle)
		{
			ctxt.Rectangle(m_rect);
		}
		// TODO
	}

Dans la classe, il est important de marquer les méthodes qui ne modifient pas les données private. Pour faire cela, on leur ajoute le mot-clé const à la fin comme c’est indiqué sur la méthode Draw.

De plus, lorsque l’on passe un argument qui n’as pas vocation à être modifié, on le passe en référence const. Comme on peut le voir ci-dessus, la définition d’une classe est un travail itératif dans lequel, les meilleures idées chassent celles d’avant ou les conforte. Si une classe est bien conçue, le lecture de ses membres public est limpide car on va à l’essentiel. Attention, les membres private expliquent aussi beaucoup de choses sur les détails d’implémentation. Maintenant, mettons-nous dans un contexte où il existe plusieurs classes et les principes vu ci-dessus ne suffisent pas à faire un modèle objet. Il nous faut des mécanismes plus sophistiqués pour relier les classes les unes avec les autres.

Les classes possèdent des associations et des comportements et c’est ici que les Jedi se positionnent pour y designer un modèle élégant, facile à utiliser et qui rend les services voulus.

Notre méthode Draw n’est pas OOP car si je rajoute un type dans l’énumération, je dois ajouter un if() dans la méthode Draw() et coder l’implémentation. On peut faire mieux, beaucoup mieux.

Les concepts de OOP

Les deux piliers de l’OOP sont l’héritage et le polymorphisme. L’héritage permet de grouper les classes en famille de types et permet de partager des opérations et des comportements et des données. Le polymorphisme permet de déclencher des opérations dans ces familles à un niveau unitaire. Ainsi ajouter ou supprimer une classe n’est pas trop un problème.

L’héritage définit une relation parent/enfant. Le parent définit l’interface public et l’implémentation private est commune à tous ses enfants. Chaque enfant choisit s’il veut hériter d’un comportement unique ou bien le surcharger. En C++, le parent est appelé « classe de base » et l’enfant « classe dérivée ». Le parent et les enfants définissent une hiérarchie de classes. Le parent est souvent une classe abstraite et les enfants implémentent les méthodes virtuelles pures pour que l’ensemble fonctionne.

Dans un programme OOP, on manipule les classes via un pointeur sur la classe de base plutôt que sur les objets dérivés.

Une classe abstraite

Revenons sur la classe CShape… La prochaine étape dans le design est de créer une classe abstraite pour identifier les opérations propres à chaque item – ce qui implique des opérations avec une implémentation basée sur une classe dérivée. Ces opérations sont des fonctions virtuelles pures de la classe de base. Une méthode virtuelle pure est une méthode abstraite. Il n’y a pas de corps. Cela implique que le classe devient abstraite aussi. Il n’est pas possible de créer un objet à partir d’une classe abstraite. La méthode Draw() doit être définie comme virtuelle pure car il y a plusieurs types de dessin à faire et que chaque dessin est propre à une classe donnée. Le corps de Draw() n’existe pas, c’est la raison pour laquelle on dit que la classe est abstraite ; il y a au moins une méthode virtuelle pure.

Voici donc comment on fait :

class CShapeEx
{
public:
	CShapeEx() {}
	CShapeEx(ShapeType type, RECT rect, const std::string &fileName) 
		: m_type(type), m_rect(rect), m_fileName(fileName) {}
	virtual ~CShapeEx() {}

public:
	virtual void Draw(const CDrawingContext& ctxt) const = 0;
	virtual void DrawTracker(const CDrawingContext& ctxt) const = 0;

private:
	std::string m_fileName;
	ShapeType m_type;
	RECT m_rect;
};

Et nous allons maintenant déclarer des classes dérivées de CShapeEx :

class CRectangle : public CShapeEx
{
public:
	CRectangle() {}
	virtual ~CRectangle() {}

public:
	virtual void Draw(const CDrawingContext& ctxt) const
	{
		// TODO
		std::cout << "Rectangle::Draw" << std::endl;
	}

	virtual void DrawTracker(const CDrawingContext& ctxt) const
	{
		// TODO
	}
};

class CLine : public CShapeEx
{
public:
	CLine() {}
	virtual ~CLine() {}

public:
	virtual void Draw(const CDrawingContext& ctxt) const
	{
		// TODO
		std::cout << "Line	::Draw" << std::endl;
	}

	virtual void DrawTracker(const CDrawingContext& ctxt) const
	{
		// TODO
	}
};

Si on veut rajouter un item à dessiner dans la hiérarchie, il suffit de rajouter une classe dérivée ! Maintenant nous allons voir comment fonctionne ce mécanisme de virtual…

	CDrawingContext ctxt;
	CRectangle * pRect = new CRectangle();
	CLine * pLine = new CLine();
	CShapeEx * ptr = nullptr;
	ptr = pRect;
	ptr->Draw(ctxt);
	ptr = pLine;
	ptr->Draw(ctxt);

On commence par déclarer 2 items à dessiner. Puis le manager, un pointeur sur la classe de base CShapeEx est déclaré. A chaque fois qu’il pointe sur un objet d’une classe dérivée, la fonction virtuelle Draw() appelée est celle de la classe dérivée car cette fonction est définie comme virtuelle.

code5

Maintenant, il nous manque quelque chose de très utile et qui évitera les usines à gaz de construction d’objets dérivés. Il nous faut une factory ! Un mécanisme de création d’objet.

La factory

class CFactory
{
private:
	CFactory();

public:
	static CShapeEx * CreateObject(ShapeType type)
	{
		if (type == ShapeType::line)
		{
			CLine * pObj = new CLine();
			pObj->m_type = type;
			return pObj;
		}

		if (type == ShapeType::rectange)
		{
			CRectangle * pObj = new CRectangle();
			pObj->m_type = type;
			return pObj;
		}

		// TODO

		return nullptr;
	}
};

Cette classe permet via une méthode static de créer un objet en fonction de son type dans l’énumération. Le type est affecté en variable membre de l’objet créé. On notera que le constructeur est private, cela veut dire que l’on ne peut pas déclarer d’objet CFactory. On ne peut qu’utiliser la méthode static CreateObject. Sauf que, la compilation tombe en erreur :

code6

Le membre m_type est inaccessible vue son niveau de protection… On va donc ajouter quelque chose à la classe CShapeEx :

class CShapeEx
{
public:
	CShapeEx() {}
	CShapeEx(ShapeType type, RECT rect, const std::string &fileName) 
		: m_type(type), m_rect(rect), m_fileName(fileName) {}
	virtual ~CShapeEx() {}

public:
	virtual void Draw(const CDrawingContext& ctxt) const = 0;
	virtual void DrawTracker(const CDrawingContext& ctxt) const = 0;

private:
	std::string m_fileName;
	ShapeType m_type;
	RECT m_rect;

	// La classe CFactory peux avoir accès aux membres...
	friend class CFactory;
};

On ajoute en fin de classe que la classe CFactory est amie de la classe CShapeEx. Et là, il n’y a plus d’erreur de compilation ! Les puristes comme AlainZ, à Redmond, vous diront que cela viole la mécanique objet et que c’est une construction exotique et qu’il vaut mieux passer par le constructeur pour passer le type… Je ne suis pas de cet avis. Je pense que c’est élégant de faire une entorse pour la factory. Voici maintenant le code qui appelle la factory :

	CDrawingContext ctxt;
	CShapeEx * pRect = CFactory::CreateObject(ShapeType::rectange);
	CShapeEx * pLine = CFactory::CreateObject(ShapeType::line);
	CShapeEx * ptr = nullptr;
	ptr = pRect;
	ptr->Draw(ctxt);
	ptr = pLine;
	ptr->Draw(ctxt);

Et le résultat est équivalent.

Compilation sous Linux

Pour ceux qui ne le savent pas, le langage C++ est normalisé ISO. Sur la plateforme Linux, là où tout est fait en C/C++, le langage possède plusieurs compilateurs dont le célèbre GCC. Vous pouvez utiliser Visual Studio Code que fournit Microsoft comme IDE pour compiler sous Linux via le terminal.

Il faut installer l’extension C++. Moi j’ai installé Cygwin et MSYS. Ainsi je dispose de commandes Linux.

code7

Une touche de C++ 11

On va essayer de continuer notre application de dessin en matérialisant la zone de dessiner. Cela ressemble à un ensemble de shapes sur un support de dessin. Première étape quand on pense au concept de la planche à dessin c’est quoi ? Le stockage des éléments graphiques dans un container STL. Oui Monsieur, quand on veut stocker quelque chose, on passe par les containers STL. On va donc utiliser le std::vector de la STL. On va stocker des shapes un peu particulier que sont les shapes partagés. Partagés ? Par qui ? Dans un vrai logiciel de dessin, on affiche les propriétés dans une grille et le dessin est sur le panneau central donc on partage nos objets et ce n’est pas que de l’affichage. Je vous montre le résultat.

code8

Sur cet écran, on voit que le rectangle gris sélectionné a ses attributs directement dans le grille de propriétés mais aussi sur le Ribbon. Comment faire pour partager les données entre le panneau de dessin, le Ribbon et la grille de propriétés ? Est-ce que l’on fait des copies des objets ? Oui, mais on fait des copies de pointeurs et non des copies d’objets. Pour faire cela, une utilise le mécanisme des pointeurs partagés de la STL. Voyons son utilisation. Premièrement, on va designer la zone de dessin.

La zone de dessin

Cette zone contient les objets shape à dessiner. On va donc créer un vector. Le container vector est défini dans . On va avoir une collection d’éléments partagés CShapeEx. Ainsi, on pourra stocker ce pointeur particulier où on veut sans se soucier de la libération de la mémoire. La zone de dessin est une vue fille MDI en jargon Windows. Elle possède deux scrollbars, un verticale et une horizontale. Si on veut faire une gestion de shared_ptr, il faut faire évoluer la factory :

	static std::shared_ptr CreateObject(ShapeType type)
	{
		std::shared_ptr pObj = nullptr;

		if (type == ShapeType::line)
		{
			pObj = std::make_shared();
			pObj->m_type = type;
			return pObj;
		}

		if (type == ShapeType::rectangle)
		{
			pObj = std::make_shared();
			pObj->m_type = type;
			return pObj;
		}

		return nullptr;
	}

On ne fait plus un new() mais un appel à std::make_shared().

De plus, dans l’utilisation des objets, cela donne ça :

	CDrawingContext ctxt;
	std::shared_ptr pRect = CFactory::CreateObject(ShapeType::rectangle);
	std::shared_ptr pLine = CFactory::CreateObject(ShapeType::line);
	std::shared_ptr ptr = nullptr;
	ptr = pRect;
	ptr->Draw(ctxt);
	ptr = pLine;
	ptr->Draw(ctxt);

Il existe même une façon de laisser le compilateur déterminer le type de variable utilisée en utilisant auto :

	CDrawingContext ctxt;
	auto pRect = CFactory::CreateObject(ShapeType::rectangle);
	auto pLine = CFactory::CreateObject(ShapeType::line);
	auto ptr = pRect;
	ptr->Draw(ctxt);
	ptr = pLine;
	ptr->Draw(ctxt);

Revenons à notre design de classes. Le container de shapes est juste une collection std::vector de std::shared_ptr :

class CElementContainer : public CObject
{
private:
	
public:
	DECLARE_SERIAL(CElementContainer);
	CElementContainer();
	virtual ~CElementContainer(void);

// ../..
// overridden for document i/o
virtual void Serialize(CElementManager * pElementManager, CArchive& ar);   
// Debuging Operations
public:
	void DebugDumpObjects(CModeler1View * pView);

// Operations MFC like
public:
	std::shared_ptr GetHead();
	int GetCount();
	void RemoveAll();
	void Remove(std::shared_ptr pElement);
	void AddTail(std::shared_ptr pElement);

// Attributes
private:
	vector m_objects;
};

Là, je vous montre un vrai code et les éléments sont matérialisés par la classe CElement mais c’est pareil que CShapeEx. On notera que les fonctions de gestion au vector sont des méthodes helpers dans cette classe. On notera aussi que la fonction Serialize qui permet de faire Load/Save est gérée dans cette classe. En effet, si il existe des donnés à mettre dans un fichier de données, c’est bien cette classe. Il faut maintenant intégrer cette classe dans la mécanique de fenêtrage Windows. Dans un canevas MFC, on possède un Document pour y stocker les données et une View pour y faire les opérations d’affichage.

Abstraction

La couche de dessin est confiée à une classe explicite et les méthodes ne sont pas directement insérées dans la vue. Pourquoi un tel niveau de poupées russes ? Parce que sinon, c’est crado. C’est trop entrelacé dans les couches Windows et le code est spaguetti. J’ai donc un e classe qui se nomme CElementManager qui fait le lien avec la View MFC. De ce fait beaucoup de méthodes prennent en paramètre une View… C’est de la délégation de comportement. Mais dans cette classe on trouve tous les éléments de la zone de dessin :

  • Les objets à afficher
  • Les éléments d’une sélection
  • Les éléments du presse-papier
  • La couleur de fond de la zone
  • Le mode du pointeur de souris
  • Le facteur de zoom
  • Un booléen pour savoir si on est en train de dessiner un gabarit
  • L’élément courant avec son type et son id et son nom

Voici un aperçu du fichier d’entêtes de la classe CElementManager :

code9

Cette classe est juste dépendante d’une View sur laquelle il va y avoir des opérations et des manipulations d’affichage. Exemple de méthode :

void CElementManager::ZoomIn(CModeler1View * pView)
{
	m_fZoomFactor += 0.10f;
	Invalidate(pView);
}

Conclusion

Pour un code orienté objet, il ne faut pas hésiter à faire des constructions, créer des classes et leur donner un minimum de responsabilités. De toute façon, si vous créé une classe et que vous n’y trouvez aucune méthode à mettre dedans, vous devrez faire machine arrière… La construction orientée objet est importante dans le développement moderne et on retrouvera les mêmes principes dans les autres langages comme Java ou C#.

Le code de l’application graphique est disponible ici : https://github.com/ChristophePichaud/UltraFluidModeler

Christophe PICHAUD
Consultant sur les technologies Microsoft