En C ++, il existe de nombreuses fonctionnalités qui peuvent être considérées comme potentiellement dangereuses - avec des erreurs de calcul dans la conception ou un codage inexact, elles peuvent facilement conduire à des erreurs. L'article fournit une sélection de ces fonctionnalités, donne des conseils sur la façon de réduire leur impact négatif.

Table des matières

Praemonitus, praemunitus.
Averti signifie armé. (lat.)

Présentation

En C ++, il existe de nombreuses fonctionnalités qui peuvent être considérées comme potentiellement dangereuses - avec des erreurs de calcul dans la conception ou un codage inexact, elles peuvent facilement conduire à des erreurs. Certains d'entre eux peuvent être attribués à une enfance difficile, certains à la norme C ++ 98 obsolète, mais d'autres sont déjà associés aux fonctionnalités du C ++ moderne. Considérez les principaux et essayez de donner des conseils sur la façon de réduire leur impact négatif.

1. Types

1.1. Instructions et opérateurs conditionnels

Le besoin de compatibilité avec C conduit au fait que dans l'instruction if(...) et similaires, vous pouvez remplacer n'importe quelle expression numérique ou pointeur, et pas seulement des expressions comme bool . Le problème est aggravé par la conversion implicite de bool en int dans les expressions arithmétiques et la priorité de certains opérateurs. Cela conduit, par exemple, aux erreurs suivantes:

if(a=b) quand correctement if(a==b) ,
if(a<x<b) , quand correctement if(a<x && x<b) ,
if(a&x==0) , quand correctement if((a&x)==0) ,
if(Foo) quand correctement if(Foo()) ,
if(arr) quand correctement if(arr[0]) ,
if(strcmp(s,r)) lorsqu'il est correct if(strcmp(s,r)==0) .

Certaines de ces erreurs provoquent un avertissement du compilateur, mais pas une erreur. Les analyseurs de code peuvent également parfois aider. En C #, de telles erreurs sont presque impossibles, l' if(...) et similaires nécessitent un type bool , vous ne pouvez pas mélanger des types bool et numériques dans des expressions arithmétiques.

Comment se battre:

• Programme sans avertissements. Malheureusement, cela n'aide pas toujours; certaines des erreurs décrites ci-dessus ne donnent pas d'avertissement.
• Utilisez des analyseurs de code statique.
• Technique de réception à l'ancienne: lors de la comparaison avec une constante, placez-la à gauche, par exemple if(MAX_PATH==x) . Il a l'air assez copropriété (et a même son propre nom - "notation Yoda"), et aide dans un petit nombre de cas.
• Utilisez le qualificatif const aussi largement que possible. Encore une fois, cela n'aide pas toujours.
• Prenez l'habitude d'écrire les expressions logiques correctes: if(x!=0) au lieu de if(x) . (Bien que vous puissiez tomber dans le piège des priorités des opérateurs ici, consultez le troisième exemple.)
• Soyez extrêmement attentif.

1.2. Conversions implicites

C ++ fait référence à des langages fortement typés, mais les conversions de types implicites sont largement utilisées pour raccourcir le code. Ces conversions implicites peuvent dans certains cas conduire à des erreurs.

Les conversions implicites les plus ennuyeuses sont les conversions d'un type numérique ou d'un pointeur vers bool et de bool vers int . Ce sont ces transformations (nécessaires à la compatibilité avec C) qui provoquent les problèmes décrits dans la section 1.1. Les conversions implicites qui peuvent potentiellement entraîner une perte de précision des données numériques (rétrécissement des conversions), par exemple du double au int sont pas toujours appropriées non plus. Dans de nombreux cas, le compilateur génère un avertissement (surtout lorsqu'il peut y avoir une perte de précision des données numériques), mais un avertissement n'est pas une erreur. En C #, les conversions entre types numériques et bool interdites (même explicites), et les conversions qui peuvent potentiellement entraîner une perte de précision dans les données numériques sont presque toujours une erreur.

Le programmeur peut ajouter d'autres conversions implicites: (1) définir un constructeur avec un paramètre sans le mot-clé explicit ; (2) la définition d'un opérateur de conversion de type. Ces transformations comblent des lacunes de sécurité supplémentaires basées sur des principes de typage solides.

En C #, le nombre de conversions implicites intégrées est beaucoup plus petit; les conversions implicites personnalisées doivent être déclarées à l'aide du mot clé implicit .

Comment se battre:

• Programme sans avertissements.
• Faites très attention aux modèles décrits ci-dessus, ne les utilisez pas sans besoin extrême.

2. Résolution du nom

2.1. Masquage de variables dans des étendues imbriquées

En C ++, la règle suivante s'applique. Soit

 //   {    int x;    // ... //  ,       {        int x;        // ...    } } 

Selon les règles C ++, la variable déclarée en cache la variable déclarée en La première déclaration x ne doit pas nécessairement être dans un bloc: elle peut être membre d'une classe ou d'une variable globale, elle doit juste être visible dans le bloc

Imaginez maintenant la situation où vous devez refactoriser le code suivant

 //   {    int x;    // ... //  ,       {    // -         } } 

Par erreur, des modifications sont apportées:

 //   {    //  , :    int x;    // -         // ...    //  :    // -      } 

Et maintenant, le code «quelque chose se fait avec de » fera quelque chose avec de ! Il est clair que tout ne fonctionne pas comme avant, et de trouver ce qui est souvent très difficile. Ce n'est pas en vain qu'en C # il est interdit de cacher les variables locales (bien que les membres de la classe le puissent). Notez que le mécanisme de masquage des variables sous une forme ou une autre est utilisé dans presque tous les langages de programmation.

Comment se battre:

• Déclarez les variables dans la portée la plus étroite possible.
• N'écrivez pas de blocs longs et profondément imbriqués.
• Utilisez des conventions de codage pour distinguer visuellement les identifiants de portée différente.
• Soyez extrêmement attentif.

2.2. Surcharge de fonction

La surcharge de fonctions fait partie intégrante de nombreux langages de programmation et C ++ ne fait pas exception. Mais cette opportunité doit être utilisée avec précaution, sinon vous pouvez avoir des ennuis. Dans certains cas, par exemple, lorsque le constructeur est surchargé, le programmeur n'a pas le choix, mais dans d'autres cas, le refus de surcharger peut être justifié. Tenez compte des problèmes qui surviennent lors de l'utilisation de fonctions surchargées.

Si vous essayez de considérer toutes les options possibles pouvant survenir lors de la résolution d'une surcharge, les règles de résolution d'une surcharge s'avèrent être très compliquées, et donc difficiles à prévoir. La complexité supplémentaire est introduite par les fonctions de modèle et la surcharge des opérateurs intégrés. C ++ 11 a ajouté des problèmes avec les liens rvalue et les listes d'initialisation.

Des problèmes peuvent être créés par l'algorithme de recherche pour que les candidats résolvent la surcharge dans les zones de visibilité imbriquées. Si le compilateur a trouvé des candidats dans la portée actuelle, la recherche se termine. Si les candidats trouvés ne sont pas appropriés, conflictuels, supprimés ou inaccessibles, une erreur est générée, mais aucune autre recherche n'est tentée. Et seulement s'il n'y a aucun candidat dans la portée actuelle, la recherche passe à la portée suivante, plus large. Le mécanisme de masquage du nom fonctionne, qui est presque le même que celui discuté dans la section 2.1, voir [Dewhurst].

Les fonctions de surcharge peuvent réduire la lisibilité du code, ce qui signifie provoquer des erreurs.

L'utilisation de fonctions avec des paramètres par défaut ressemble à l'utilisation de fonctions surchargées, bien que, bien sûr, il y ait moins de problèmes potentiels. Mais le problème de la mauvaise lisibilité et des erreurs possibles subsiste.

Avec une extrême prudence, les paramètres de surcharge et par défaut pour les fonctions virtuelles doivent être utilisés, voir la section 5.2.

C # prend également en charge la surcharge de fonctions, mais les règles de résolution des surcharges sont légèrement différentes.

Comment se battre:

• N'abusez pas de la surcharge de fonctions, ainsi que de la conception de fonctions avec des paramètres par défaut.
• Si les fonctions sont surchargées, utilisez des signatures qui ne font aucun doute lors de la résolution des surcharges.
• Ne déclarez pas les fonctions du même nom dans la portée imbriquée.
• N'oubliez pas que le mécanisme des fonctions distantes ( =delete ) apparu en C ++ 11 peut être utilisé pour interdire certaines options de surcharge.

3. Constructeurs, destructeurs, initialisation, suppression

3.1. Fonctions membres de classe générées par le compilateur

Si le programmeur n'a pas défini les fonctions membres de la classe dans la liste suivante - le constructeur par défaut, le constructeur de copie, l'opérateur d'affectation de copie, le destructeur - le compilateur peut le faire pour lui. C ++ 11 a ajouté un constructeur de déplacement et un opérateur d'affectation de déplacement à cette liste. Ces fonctions membres sont appelées fonctions membres spéciales. Ils ne sont générés que s'ils sont utilisés et des conditions supplémentaires spécifiques à chaque fonction sont remplies. Nous attirons l'attention sur le fait que cette utilisation peut s'avérer assez cachée (par exemple lors de l'implémentation de l'héritage). Si la fonction requise ne peut pas être générée, une erreur est générée. (À l'exception des opérations de relocalisation, elles sont remplacées par des opérations de copie.) Les fonctions membres générées par le compilateur sont publiques et intégrables. Des détails sur les fonctions spéciales des membres peuvent être trouvés dans [Meyers2].

Dans certains cas, une telle aide du compilateur peut être un «service baissier». L'absence de fonctions membres spéciales personnalisées peut conduire à la création d'un type trivial, ce qui, à son tour, provoque le problème des variables non initialisées, voir la section 3.2. Les fonctions membres générées sont publiques, ce qui n'est pas toujours cohérent avec la conception des classes. Dans les classes de base, le constructeur doit être protégé; parfois, pour un contrôle plus fin du cycle de vie de l'objet, un destructeur protégé est nécessaire. Si une classe a un descripteur de ressource brute en tant que membre et possède cette ressource, le programmeur doit alors implémenter le constructeur de copie, l'opérateur d'affectation de copie et le destructeur. La soi-disant «règle des trois grands» est bien connue, qui stipule que si un programmeur définit au moins une des trois opérations - constructeur de copie, opérateur d'affectation de copie ou destructeur - alors il doit définir les trois opérations. Le constructeur de déplacement et l'opérateur d'affectation de déplacement généré par le compilateur sont également loin de toujours ce dont vous avez besoin. Le destructeur généré par le compilateur conduit dans certains cas à des problèmes très subtils, pouvant entraîner une fuite de ressources, voir section 3.7.

Le programmeur peut interdire la génération de fonctions membres spéciales, en C ++ 11 il est nécessaire d'utiliser la construction "=delete" lors de la déclaration, en C ++ 98 déclarer la fonction membre correspondante privée et non définir.

Si le programmeur est à l'aise avec les fonctions membres générées par le compilateur, alors en C ++ 11, il peut l'indiquer explicitement, et pas simplement supprimer la déclaration. Pour ce faire, vous devez utiliser la construction "=default" lors de la déclaration, tandis que le code est mieux lu et que des fonctionnalités supplémentaires apparaissent liées à la gestion du niveau d'accès.

En C #, le compilateur peut générer un constructeur par défaut, cela ne pose généralement aucun problème.

Comment se battre:

• Contrôlez le compilateur générant des fonctions membres spéciales. Si nécessaire, mettez-les en œuvre vous-même ou interdisez-les.

3.2. Variables non initialisées

Les constructeurs et les destructeurs peuvent être appelés éléments clés du modèle d'objet C ++. Lors de la création d'un objet, le constructeur doit être appelé et lors de la suppression, le destructeur est appelé. Mais les problèmes de compatibilité avec C ont forcé certaines exceptions, et cette exception est appelée types triviaux. Ils sont introduits pour simuler les types sichny et le cycle de vie syshny des variables, sans l'appel obligatoire du constructeur et du destructeur. Le code C, s'il est compilé et exécuté en C ++, devrait fonctionner comme en C. Les types triviaux incluent les types numériques, les pointeurs, les énumérations, ainsi que les classes, les structures, les unions et les tableaux constitués de types triviaux. Les classes et les structures doivent remplir des conditions supplémentaires: absence de constructeur personnalisé, destructeur, copie, fonctions virtuelles. Pour une classe triviale, le compilateur peut générer un constructeur par défaut et un destructeur. Le constructeur par défaut met à zéro l'objet, le destructeur ne fait rien. Mais ce constructeur ne sera généré et utilisé que s'il est explicitement appelé lors de l'initialisation de la variable. Une variable de type trivial ne sera pas initialisée si vous n'utilisez pas une variante d'initialisation explicite. La syntaxe d'initialisation dépend du type et du contexte de la déclaration de variable. Les variables statiques et locales sont initialisées lorsqu'elles sont déclarées. Pour une classe, les classes de base immédiates et les membres de classe non statiques sont initialisés dans la liste d'initialisation du constructeur. (C ++ 11 vous permet d'initialiser des membres de classe non statiques lors de la déclaration, voir plus loin.) Pour les objets dynamiques, l'expression new T() crée un objet initialisé par le constructeur par défaut, mais le new T pour les types triviaux crée un objet non initialisé. Lors de la création d'un tableau dynamique d'un type trivial, new T[N] , ses éléments seront toujours non initialisés. Si une instance de std::vector<T> est créée ou étendue et que les paramètres ne sont pas fournis pour l'initialisation explicite des éléments, ils sont garantis pour appeler le constructeur par défaut. C ++ 11 introduit une nouvelle syntaxe d'initialisation - utilisant des accolades. Une paire de crochets vide signifie l'initialisation à l'aide du constructeur par défaut. Une telle initialisation est possible partout où l'initialisation traditionnelle est utilisée, en plus il est devenu possible d'initialiser des membres non statiques de la classe lors de la déclaration, ce qui remplace l'initialisation dans la liste d'initialisation du constructeur.

Une variable non initialisée est structurée comme suit: si elle est définie dans la portée de l' namespace (globalement), elle aura tous les bits zéro, si elle est locale ou créée dynamiquement, elle recevra un ensemble aléatoire de bits. Il est clair que l'utilisation d'une telle variable peut conduire à un comportement imprévisible du programme.

Certes, la progression ne s'arrête pas, les compilateurs modernes, dans certains cas, détectent les variables non initialisées et génèrent une erreur. Les analyseurs de code non initialisés détectent encore mieux.

La bibliothèque standard C ++ 11 possède des modèles appelés propriétés de type (fichier d'en-tête <type_traits> ). L'un d'eux vous permet de déterminer si le type est trivial. L'expression std::is_trivial<>::value est true si T type trivial et false sinon.

Les structures sysyliques sont aussi souvent appelées Plain Old Data (POD). Nous pouvons supposer que POD et le «type trivial» sont des termes presque équivalents.

En C #, les variables non initialisées provoquent une erreur qui est contrôlée par le compilateur. Les champs d'objets d'un type de référence sont initialisés par défaut si l'initialisation explicite n'est pas effectuée. Les champs d'objets d'un type significatif sont initialisés soit tous par défaut, soit tous doivent être initialisés explicitement.

Comment se battre:

• Prenez l'habitude d'initialiser explicitement une variable. Une variable non initialisée devrait "couper l'œil".
• Déclarez les variables dans la portée la plus étroite possible.
• Utilisez des analyseurs de code statique.
• Ne concevez pas de types triviaux. Pour s'assurer que le type n'est pas trivial, il suffit de définir un constructeur personnalisé.

3.3. Procédure d'initialisation pour les classes de base et les membres de classe non statiques

Lors de l'implémentation du constructeur de classe, les classes de base immédiates et les membres de classe non statiques sont initialisés. L'ordre d'initialisation est déterminé par la norme: d'abord, les classes de base dans l'ordre dans lequel elles sont déclarées dans la liste des classes de base, puis les membres non statiques de la classe dans l'ordre de déclaration. Si nécessaire, l'initialisation explicite des classes de base et des membres non statiques utilise la liste d'initialisation du constructeur. Malheureusement, les éléments de cette liste ne doivent pas nécessairement être dans l'ordre dans lequel l'initialisation a lieu. Ceci doit être pris en compte si, lors de l'initialisation, les éléments de liste utilisent des références à d'autres éléments de liste. En cas d'erreur, le lien peut être vers un objet qui n'a pas encore été initialisé. C ++ 11 vous permet d'initialiser des membres de classe non statiques lors de la déclaration (en utilisant des accolades). Dans ce cas, ils n'ont pas besoin d'être initialisés dans la liste d'initialisation du constructeur et le problème est partiellement supprimé.

En C #, un objet est initialisé comme suit: d'abord les champs sont initialisés, du sous-objet de base à la dernière dérivée, puis les constructeurs sont appelés dans le même ordre. Le problème décrit ne se produit pas.

Comment se battre:

• Conservez la liste d'initialisation du constructeur dans l'ordre de déclaration.
• Essayez de rendre l'initialisation des classes de base et des membres de classe indépendants.
• Utilisez l'initialisation des membres non statiques lors de la déclaration.

3.4. Procédure d'initialisation pour les membres de classe statique et les variables globales

Les membres de classe statiques, ainsi que les variables définies dans l' namespace portée (globalement) dans différentes unités de compilation (fichiers), sont initialisés dans l'ordre déterminé par l'implémentation. Ceci doit être pris en compte si, lors de l'initialisation, ces variables utilisent des références les unes aux autres. Le lien peut être vers une variable non initialisée.

Comment se battre:

• Prenez des mesures spéciales pour éviter cette situation. Par exemple, utilisez des variables statiques locales (singleton), elles sont initialisées à la première utilisation.

3.5. Exceptions dans les destructeurs

Le destructeur ne doit pas lever d'exceptions. Si vous enfreignez cette règle, vous pouvez obtenir un comportement indéfini, le plus souvent une résiliation anormale.

Comment se battre:

• Évitez de lancer des exceptions dans le destructeur.

3.6. Suppression d'objets et de tableaux dynamiques

Si un objet dynamique d'un type T

 T* pt = new T(/* ... */); 

puis il est supprimé avec l'opérateur de delete

 delete pt; 

Si un tableau dynamique est créé

 T* pt = new T[N]; 

puis il est supprimé avec l'opérateur delete[]

 delete[] pt; 

Si vous ne respectez pas cette règle, vous pouvez obtenir un comportement indéfini, c'est-à-dire que tout peut arriver: une fuite de mémoire, un crash, etc. Voir [Meyers1] pour plus de détails.

Comment se battre:

• Utilisez le bon formulaire de delete .

3.7. Suppression lorsque la déclaration de classe est incomplète

Le caractère omnivore de l'opérateur de delete peut créer certains problèmes; il peut être appliqué à un pointeur de type void* ou à un pointeur sur une classe qui a une déclaration incomplète (préemptive). L'opérateur de delete appliqué à un pointeur sur une classe est une opération en deux phases; d'abord, le destructeur est appelé, puis la mémoire est libérée.Si l'opérateur est appliqué deleteà un pointeur sur une classe avec une déclaration incomplète, aucune erreur ne se produit, le compilateur ignore simplement l'appel au destructeur (bien qu'un avertissement soit émis). Prenons un exemple:

 class X; //   X* CreateX(); void Foo() {    X* p = CreateX();    delete p; } 

warning C4150: deletion of pointer to incomplete type 'X'; no destructor called

S'il existe une implémentation Xet que CreateX()le code est compilé, s'il CreateX()renvoie un pointeur vers un objet créé par l'opérateur new, alors l'appel est Foo()exécuté avec succès, le destructeur n'est pas appelé. Il est clair que cela peut conduire à un épuisement des ressources, donc encore une fois sur la nécessité de traiter soigneusement les avertissements.

, -. , . , , , , . [Meyers2].

:

• .
• .
• .

4. ,

4.1.

++ , . . . , 1.1.

Voici un exemple:

 std::out<<c?x:y; 

 (std::out<<c)?x:y; 

 std::out<<(c?x:y); 

, , .

. << ?: std::out void* . ++ , . -, , . ?: . , ( ).

: x&f==0 x&(f==0) , (x&f)==0 , , , . - , , , , .

. / . / , /, . , x/4+1 x>>2+1 , x>>(2+1) , (x>>2)+1 , .

C# , C++, , - .

:

• , . , , .

4.2.

++ , . . , , . 4.1. — + += . . , : , (), && , || . , (-), (short-circuit evaluation semantics), , . & ( ). & , .. .

, - (-) , . .

- , , . . [Dewhurst].

C# , , , .

:

• .
• .

4.3.

++ , . ( : , (), && , || , ?: .) , , , . :

 int x=0; int y=(++x*2)+(++x*3); 

y .

, . .

 class X; class Y; void Foo(std::shared_ptr<X>, std::shared_ptr<Y>); 

Foo() :

 Foo(std::shared_ptr<X>(new X()), std::shared_ptr<Y>(new Y())); 

: X , Y , std::shared_ptr<X> , std::shared_ptr<Y> . Y , X .

:

 auto p1 = std::shared_ptr<X>(new X()); auto p2 = std::shared_ptr<Y>(new Y()); Foo(p1, p2); 

std::make_shared<Y> ( , ):

 Foo(std::make_shared<X>(), std::make_shared<Y>()); 

. [Meyers2].

:

• .

5.

5.1.

++98 , ( ), , ( , ). virtual , , . ( ), , , . , , . , ++11 override , , , . .

:

• override .
• . , .

5.2.

. , , . . . [Dewhurst].

:

• .

5.3.

, , . , , post_construct pre_destroy. , — . . , : ( ) . (, , .) , ( ), ( ). . [Dewhurst]. , , .

— - .

, C# , , , . C# : , , . , ( , ).

:

• , , .

5.4.

, , delete . , - .

:

• .

6.

— C/C++, . . . « ».

C# unsafe mode, .

6.1.

/++ , : strcpy() , strcat() , sprinf() , etc. ( std::vector<> , etc.) , . (, , , . . Checked Iterators MSDN.) , : , , ; , .

C#, unsafe mode, .

:

• , .
• .
• z-terminated , _s (. ).

6.2. Z-terminated

, . , :

 strncpy(dst,src,n); 

strlen(src)>=n , dst (, ). , , . . — . if(*str) , if(strlen(str)>0) , . [Spolsky].

C# string .

:

• .
• z-terminated , _s (. ).

6.3.

... . printf - , C. , , , , . , .

C# printf , .

:

• . , printf - /.
• .

7.

7.1.

++ , , , . Voici un exemple:

 const int N = 4, M = 6; int x,                // 1    *px,              // 2    ax[N],            // 3    *apx[N],          // 4    F(char),          // 5    *G(char),          // 6    (*pF)(char),      // 7    (*apF[N])(char),  // 8    (*pax)[N],        // 9    (*apax[M])[N],    // 10    (*H(char))(long);  // 11 

:

1. int ;
2. int ;
3. N int ;
4. N int ;
5. , char int ;
6. , char int ;
7. , char int ;
8. N , char int ;
9. N int ;
10. M N int ;
11. , char , long int .

, . ( .)

* & . ( .)

typedef ( using -). , :

 typedef int(*P)(long); PH(char); 

, .

C# , .

:

• .

7.2.

.

 class X { public:    X(int val = 0); // ... }; 

 X x(5); 

x X , 5.

 X x(); 

x , X , x X , . X , , :

 X x; X x = X(); X x{};    //   C++11 

, , , . [Sutter].

, , C++ ( ). . ( C++ .)

, , , , .

C# , , .

:

• .

8.

8.1. inline ODR

, inline — . , . inline (One Defenition Rule, ODR). . , . , ODR. static : , , . static inline . , , ODR, . , . - , -. .

:

• «» inline . namespace . , .
• — namespace .

8.2.

. . , , , , .

:

• , .
• , : () , -.
• using -: using namespace , using -.
• .

8.3. switch

— break case . ( .) C# .

:

• .

8.4.

++ , — , — . ( class struct ) , . ( , # Java.) — , .

1. , . ( std::string , std::vector , etc.), , .
2. , , .
3. , (slicing), , .

, , , . . , , . , . . — ( =delete ), — explicit .

C# , .

:

• , .
• .

8.5. Gestion des ressources

++ . , . - ( ), ++11 , , , .

C++ .

C# , . , . (using-) Basic Dispose.

:

• - .

8.6.

«» . , , C++ , STL- - .

. . , . . «», . COM- . (, .) , C++ . — . . . , («» ) , . .

# , . — .

:

• .
• .

8.7.

C++ , : , , . ( !) . , . , . , , . (, .)

C ( ), C++ C ( extern "C" ). C/C++ .

-. #pragma - , , .

, , , .

, , COM. COM-, , ( , ). COM , , .

C# . , — , C#, C# C/C++.

:

• .

8.8.

, . , . C++ . Au lieu de cela

 #define XXL 32 

 const int XXL=32; 

. inline .

# ( ).

:

• .

9.

1. . . . , .
2. .
3. . ++ — ++11/14/17.
4. - , - .
5. .

Les références