Aide-mémoire de l'abréviation C ++ et plus encore. Partie 1: C ++

Une fois, j'ai été interviewé pour le poste de développeur C ++ dans un bureau décent et même bien connu. J'avais déjà une certaine expérience à l'époque, on m'appelait même un développeur leader chez mon employeur à l'époque. Mais lorsqu'on m'a demandé si je savais des choses telles que DRY, KISS, YAGNI, NIH, j'ai dû répondre «Non» encore et encore.

J'ai échoué lamentablement, bien sûr. Mais alors les abréviations ci-dessus ont été googlé et mémorisées. En lisant des articles et des livres thématiques, en me préparant pour des interviews et en parlant avec des collègues, j'ai appris de nouvelles choses, les ai oubliées, googlé à nouveau et compris. Il y a quelques mois, un de mes collègues a mentionné avec désinvolture dans le chat de travail IIFE dans le contexte de C ++. Comme ce grand-père dans une blague, je suis presque tombé du poêle et je suis de nouveau entré dans Google.



C'est alors que j'ai décidé de composer (principalement pour moi) une feuille de triche pour les abréviations qui sont utiles pour un développeur C ++. Cela ne signifie pas qu'ils s'appliquent uniquement au C ++, ou qu'ils sont des concepts tout-tout de C ++ (vous pouvez écrire des volumes sur les idiomes du langage). Non, ce ne sont que des concepts que j'ai réellement rencontrés dans le travail et les entretiens, généralement exprimés sous forme d'abréviations. Eh bien, j'ai raté des choses absolument triviales comme LIFO, FIFO, CRUD, OOP, GCC et MSVC.

Néanmoins, les abréviations sont apparues décemment, j'ai donc divisé la feuille de triche en 2 parties: fortement caractéristique du C ++ et plus courante. Quand c'était approprié, j'ai regroupé les concepts, sinon je les ai simplement listés par ordre alphabétique. En général, leur ordre n'a pas beaucoup de sens.

Choses de base:
• ODR
• POD
• POF
• PIMPL
• RAII
• RTTI
• STL
• UB

Subtilités de la langue:
• ADL
• CRTP
• CTAD
• EBO
• IIFE
• NVI
• RVO et NRVO
• SFINAE
• SBO, SOO, SSO

MISE À JOUR:
• CV
• LTO
• PCH
• PGO
• SEH / VEH
• TMP
• VLA

Choses de base

ODR

Une règle de définition. La règle d'une définition. Simplifié signifie ce qui suit:

• Au sein d'une même unité de traduction, chaque variable, fonction, classe, etc., ne peut avoir plus d'une définition. Il y a autant de publicités que possible (sauf pour les transferts sans type de base donné, qui ne peuvent tout simplement pas être déclarés sans définition), mais pas plus d'une définition. Moins possible si l'entité n'est pas utilisée.
• Tout au long du programme, chaque fonction et variable non intégrée doit avoir exactement une définition. Chaque fonction en ligne et variable utilisée doit avoir une définition dans chaque unité de traduction.
• Certaines entités - par exemple, les classes, les fonctions en ligne et une variable, les modèles, les énumérations, etc. - peuvent avoir plusieurs définitions dans un programme (mais pas plus d'une dans une unité de traduction). En fait, cela se produit lorsque le même en-tête contenant une classe entièrement implémentée, par exemple, est connecté à plusieurs fichiers .cpp. Mais ces définitions devraient coïncider (je simplifie grandement, mais l'essentiel est le suivant). Sinon, ce sera UB .

Le compilateur détectera facilement une violation ODR dans une unité de traduction. Mais il ne pourra rien faire si la règle est violée à l'échelle d'un programme - ne serait-ce que parce que le compilateur traite une unité de traduction à la fois.

L'éditeur de liens peut trouver beaucoup plus de violations, mais, à proprement parler, il n'est pas obligé de le faire (car, selon la norme, UB est ici) et il peut manquer quelque chose. En outre, le processus de recherche de violations ODR au stade de la liaison est d'une complexité quadratique et l'assemblage de code C ++ n'est pas si rapide.

En conséquence, la principale responsabilité du respect de cette règle (en particulier au niveau du programme) incombe au développeur lui-même. Et oui - seules les entités avec un lien externe peuvent violer le RLL à l'échelle du programme; ceux de l'intérieur (c'est-à-dire définis dans des espaces de noms anonymes) ne participent pas à ce carnaval.

En savoir plus: une fois (anglais) , deux (anglais)

Pod

Plain Old Data. Structure de données simple. La définition la plus simple: c'est une telle structure que vous pouvez, comme elle est, sous forme binaire envoyer / recevoir de la bibliothèque C. Ou, ce qui est la même chose, copiez correctement avec simple memcpy .

De Standard à Standard, la définition complète a changé en détail. Le dernier POD C ++ 17 définit actuellement comment

• type scalaire
• ou une classe / structure / union qui:
  - il y a une classe triviale
  - il y a une classe avec un appareil standard
  - ne contient pas de champs non statiques non POD
  
• ou un tableau de ces types

Classe triviale:

• en a au moins un non supprimé:
  - constructeur par défaut
  - constructeur de copie
  - constructeur en mouvement
  - opérateur d'affectation de copie
  - opérateur d'affectation de déplacement
  
• tous les constructeurs par défaut qui copient et déplacent les constructeurs et les opérateurs d'affectation sont triviaux (simplifiés - générés par le compilateur) ou distants
• a un destructeur non distant trivial
• tous les types de base et tous les champs des types de classe ont des destructeurs triviaux
• pas de méthodes virtuelles (y compris destructeur)
• aucun type de base virtuelle

Classe avec un appareil standard (classe de mise en page standard):

• pas de méthodes virtuelles
• aucun type de base virtuelle
• aucun champ de lien non statique
• tous les champs non statiques ont le même modificateur d'accès (public / protégé / privé)
• tous les champs et classes de base non statiques sont également des types avec un périphérique standard
• tous les champs non statiques de la classe elle-même et tous ses ancêtres sont déclarés dans une seule classe (c'est-à-dire dans la classe elle-même ou dans l'un des ancêtres)
• Il n'hérite pas deux fois du même type, c'est-à-dire qu'il est impossible de le faire:
  

   struct A {}; struct B : A {}; struct C : A{}; struct D : B, C {}; 

• le type du premier champ non statique ou, s'il s'agit d'un tableau, le type de son élément ne doit coïncider avec aucun des types de base (en raison de l' EBO obligatoire dans ce cas)

Cependant, en C ++ 20, il n'y aura plus de concept de type POD , seuls le type trivial et le type avec le périphérique standard resteront.

En savoir plus: un (russe) , deux (anglais) , trois (anglais)

POF

Fonction ancienne simple. Une fonction simple de style C. Mentionnée dans la norme avant C ++ 14 inclus uniquement dans le contexte des gestionnaires de signaux. Les exigences pour cela sont:

• n'utilise que des choses communes à C et C ++ (c'est-à-dire pas d'exceptions et try-catch , par exemple)
• ne provoque pas directement ou indirectement des fonctions non POF , à l'exception des opérations sans bloc atomique ( std::atomic_init , std::atomic_fetch_add , etc.)

Seules ces fonctions, qui ont également une liaison C ( extern "C" ), sont autorisées par la norme à être utilisées comme gestionnaires de signaux. La prise en charge d'autres fonctions dépend du compilateur.

En C ++ 17, le concept de POF disparaît, au lieu de cela apparaît une évaluation sûre du signal. Dans ces calculs sont interdits:

• appels à toutes les fonctions de la bibliothèque standard, sauf atomique, sans verrouillage
• new appels et delete appels
• en utilisant dynamic_cast
• appel à l'entité thread_local
• tout travail avec des exceptions
• initialisation d'une variable statique locale
• attendre la fin de l'initialisation de la variable statique

Si le gestionnaire de signal fait l'une des actions ci-dessus, la norme promet UB .

Lire la suite: le temps (anglais)

PIMPL

Pointeur vers la mise en œuvre. Pointeur vers l'implémentation. L'idiome classique en C ++, également connu sous le nom de d-pointer, opaque pointer, compilation firewall. Cela consiste dans le fait que toutes les méthodes privées, les champs et autres détails d'implémentation d'une certaine classe sont alloués dans une classe distincte, et seules les méthodes publiques (c'est-à-dire une interface) et un pointeur vers une instance de cette nouvelle classe séparée restent dans la classe d'origine. Par exemple:



Pourquoi est-ce nécessaire, c'est-à-dire avantages:

• Encapsulation: les utilisateurs de la classe via la connexion d'en-tête ne reçoivent que ce dont ils ont besoin - une interface publique. Si les détails de l'implémentation changent, le code client n'a pas besoin d'être recompilé (voir ABI ).
• Temps de compilation: puisque l'en-tête public ne sait rien de l'implémentation, il n'inclut pas les nombreux en-têtes dont il a besoin. Par conséquent, le nombre d'en-têtes connectés implicitement dans le code client est réduit. La recherche de noms et la résolution des surcharges est également simplifiée, car l'en-tête public ne contient pas de membres privés (bien qu'ils soient privés, ils participent à ces processus).

Prix, c'est-à-dire inconvénients:

• Plus au moins un déréférencement de pointeur et plus un appel de fonction lors de l'accès aux méthodes publiques.
• La taille de la classe de mémoire nécessaire est augmentée de la taille du pointeur.
• Une partie de cette mémoire (probablement plus grande) est allouée sur le tas, ce qui affecte également négativement les performances.
• La constance logique peut facilement être violée. Par exemple, un tel code compile:
  
  

   void Foo::doThis() const { pImpl_->doThis(); // cosnt method pImpl_->doSmthElse(); // non-const method } 

Certaines de ces lacunes peuvent être supprimées, mais le prix complique davantage le code et introduit des niveaux d'abstraction supplémentaires (voir FTSE ).

En savoir plus: un (russe) , deux (russe) , trois (anglais)

RAII

L'acquisition de ressources est l'initialisation. La capture d'une ressource est l'initialisation. Le sens de cet idiome est que la rétention d'une certaine ressource dure tout au long de la vie de l'objet correspondant. La capture de la ressource a lieu au moment de la création / initialisation de l'objet, la libération - au moment de la destruction / finalisation du même objet.

Curieusement (principalement pour les programmeurs C ++), cet idiome est également utilisé dans d'autres langages, même ceux avec un garbage collector. En Java, c'est try-- , en Python l'instruction with , en C # la directive using , en Go the defer . Mais c'est en C ++ avec sa durée de vie des objets absolument prévisible que RAII s'intègre surtout organiquement.

En C ++, une ressource est généralement capturée dans le constructeur et libérée dans le destructeur. Par exemple, les pointeurs intelligents contrôlent la mémoire de cette façon, les flux de fichiers gèrent les fichiers, les verrous mutex verrouillent les mutex. La beauté est que, quelle que soit la façon dont le bloc est quitté (étendue) - est-ce normal à travers l'un des points de sortie, ou une exception a été levée - l'objet de contrôle des ressources créé dans ce bloc sera détruit et la ressource sera libérée. C'est-à-dire En plus d'encapsuler RAII en C ++, il contribue également à assurer la sécurité au sens des exceptions.

Limitations, où sans eux. Les destructeurs en C ++ ne renvoient pas de valeurs et ne devraient catégoriquement pas lever d'exceptions. En conséquence, si la libération de la ressource s'accompagne de l'une ou l'autre, il sera nécessaire d'implémenter une logique supplémentaire dans le destructeur de l'objet de contrôle.

Lire la suite: une fois (russe) , deux (anglais)

RTTI

Informations sur le type d'exécution. Identification du type lors de l'exécution. Il s'agit d'un mécanisme permettant d'obtenir des informations sur le type d'un objet ou d'une expression lors de l'exécution. Il existe dans d'autres langages, mais en C ++ il est utilisé pour:

• dynamic_cast
• typeid et type_info
• attraper l'exception

Une limitation importante: RTTI utilise une table de fonctions virtuelles, et ne fonctionne donc que pour les types polymorphes (un destructeur virtuel suffit). Une explication importante: dynamic_cast et typeid n'utilisent pas toujours RTTI , et fonctionnent donc pour les types non polymorphes. Par exemple, pour convertir dynamiquement un lien vers un descendant en un lien vers un ancêtre, RTTI n'est pas nécessaire; toutes les informations sont disponibles au moment de la compilation.

RTTI n'est pas gratuit, quoique un peu, mais il affecte négativement les performances et la taille de la mémoire consommée (d'où le conseil fréquent de ne pas utiliser dynamic_cast raison de sa lenteur). Par conséquent, les compilateurs, en règle générale, vous permettent de désactiver RTTI . GCC et MSVC promettent que cela n'affectera pas l'exactitude des exceptions de capture.

Lire la suite: une fois (russe) , deux (anglais)

STL

Bibliothèque de modèles standard. Bibliothèque de modèles standard. Partie de la bibliothèque standard C ++ qui fournit des conteneurs génériques, des itérateurs, des algorithmes et des fonctions d'assistance.

Malgré son nom bien connu, STL n'a jamais été ainsi appelé dans la norme. À partir des sections de la norme, la STL peut clairement être attribuée à la bibliothèque Containers, à la bibliothèque Iterators, à la bibliothèque Algorithm et partiellement à la bibliothèque General Utilities.

Dans les descriptions de travail, vous pouvez souvent trouver 2 exigences distinctes - la connaissance de C ++ et la familiarité avec STL . Je n'ai jamais compris cela, car STL fait partie intégrante du langage depuis la première norme de 1998.

Lire la suite: une fois (russe) , deux (anglais)

UB

Comportement indéfini. Comportement indéfini. Ce comportement est dans les cas d'erreur pour lesquels la norme n'a pas d'exigences. Beaucoup d'entre eux sont explicitement répertoriés dans la norme comme conduisant à l' UB . Il s'agit, par exemple:

• violation des limites d'un tableau ou d'un conteneur STL
• utilisation d'une variable non initialisée
• déréférencer un pointeur nul
• débordement d'entier signé

Le résultat d' UB dépend de tout dans une rangée - à la fois sur la version du compilateur et sur la météo sur Mars. De plus, ce résultat peut être n'importe quoi: une erreur de compilation, une exécution correcte et un crash. Un comportement indéfini est mauvais, il faut s'en débarrasser.

Un comportement indéfini, en revanche, ne doit pas être confondu avec un comportement non spécifié . Un comportement non spécifié est le comportement correct du programme correct, mais qui, avec l'autorisation de la norme, dépend du compilateur. Et le compilateur n'est pas tenu de le documenter. Par exemple, c'est l'ordre dans lequel les arguments d'une fonction sont évalués ou les détails d'implémentation de std::map .

Eh bien, ici, vous pouvez rappeler le comportement défini par l'implémentation. De non spécifié diffère dans la disponibilité de la documentation. Exemple: le compilateur est libre de faire le type std::size_t n'importe quelle taille, mais doit indiquer lequel.

En savoir plus: un (russe) , deux (russe) , trois (anglais)

Les subtilités de la langue

ADL

Recherche dépendante de l'argument. Recherche dépendante de l'argument. Il est la recherche de Koenig - en l'honneur d'Andrew Koenig. Il s'agit d'un ensemble de règles pour résoudre les noms de fonction non qualifiés (c'est-à-dire les noms sans l'opérateur :: :), en plus de la résolution de nom habituelle. Autrement dit: le nom d'une fonction est recherché dans les espaces de noms liés à ses arguments (c'est l'espace contenant le type de l'argument, le type lui-même, s'il s'agit d'une classe, tous ses ancêtres, etc.).


Même le trivial std::cout << "Hello World!\n" utilise ADL , std::basic_stream::operator<< pas surchargé pour const char* . Mais le premier argument de cette instruction est std::basic_stream , et le compilateur recherche et trouve une surcharge appropriée dans l' std .

Quelques détails: ADL n'est pas applicable si une recherche régulière a trouvé une déclaration d'un membre de classe, ou une déclaration de fonction dans le bloc courant sans using , ou une déclaration de non fonction ou modèle de fonction. Ou si le nom de la fonction est indiqué entre parenthèses (l'exemple ci-dessus ne compile pas avec (f)(s) ; vous devrez écrire (N::f)(s); ).

Parfois, ADL vous oblige à utiliser des noms de fonction pleinement qualifiés là où cela semble inutile.


En savoir plus: un (anglais) , deux (anglais) , trois (anglais)

CRTP

Modèle de modèle curieusement récurrent. Modèle récursif étrange. L'essence du modèle est la suivante:

• une classe hérite de la classe modèle
• la classe descendante est utilisée comme paramètre modèle de sa classe de base

Il est plus facile de donner un exemple:

 template <class T> struct Base {}; struct Derived : Base<Derived> {}; 

Le CRTP est un excellent exemple de polymorphisme statique. La classe de base fournit une interface, les classes dérivées fournissent une implémentation. Mais contrairement au polymorphisme ordinaire, il n'y a pas de surcharge pour créer et utiliser une table de fonctions virtuelles.


Un autre domaine d'utilisation courant pour CRTP est l'extension (ou le rétrécissement) de la fonctionnalité des classes héritées (quelque chose appelé mixin dans certaines langues). Peut-être les exemples les plus célèbres:

• struct Derived : singleton<Derived> { … }
• struct Derived : private boost::noncopyable<Derived> { … }
• struct Derived : std::enable_shared_from_this<Derived> { … }
• struct Derived : counter<Derived> { … } - compte le nombre d'objets créés et / ou existants

Inconvénients, ou plutôt, moments nécessitant une attention:

• Il n'y a pas de classe de base commune, vous ne pouvez pas créer une collection de différents descendants et y accéder via un pointeur sur le type de base. Mais si vous le souhaitez, vous pouvez hériter Base du type polymorphe habituel.
• Il existe une opportunité supplémentaire de tirer votre pied par négligence:
  
  
  Exemple

   template <typename T> struct Base {}; struct Derived1 : Base<Derived1> {}; struct Derived2 : Base<Derived1> {}; 

  
  Mais vous pouvez ajouter une protection:
  
  

   private: Base() = default; friend T; 

• Parce que Puisque toutes les méthodes ne sont pas virtuelles, les méthodes du descendant masquent les méthodes de la classe de base avec les mêmes noms. Par conséquent, il est préférable de les appeler différemment.
• En général, les descendants ont des méthodes publiques qui ne doivent être utilisées nulle part sauf la classe de base. Ce n'est pas bon, mais cela est corrigé par un niveau d'abstraction supplémentaire (voir FTSE ).

Lire la suite: une fois (russe) , deux (anglais)

CTAD

Déduction d'argument de modèle de classe. Déduire automatiquement le type du paramètre de modèle de classe. Il s'agit d'une nouvelle fonctionnalité de C ++ 17. Auparavant, seuls les types de variables ( auto ) et les paramètres de modèle de fonction étaient automatiquement affichés, c'est pourquoi des fonctions auxiliaires comme std::make_pair , std::make_tuple , etc. std::make_tuple . Maintenant, pour la plupart, elles ne sont pas nécessaires, car le compilateur capable d'afficher automatiquement les paramètres des modèles de classe:

 std::pair p{1, 2.0}; // -> std::pair<int, double> auto lck = std::lock_guard{mtx}; // -> std::lock_guard<std::mutex> 

La CTAD est une nouvelle opportunité, elle doit encore évoluer et se développer (C ++ 20 promet déjà des améliorations). En attendant, les restrictions sont les suivantes:

• L'inférence partielle des types de paramètres n'est pas prise en charge

   std::pair<double> p{1, 2}; //  std::tuple<> t{1, 2, 3}; //  

• Alias ​​de modèle non pris en charge

   template <class T, class U> using MyPair = std::pair<T, U>; MyPair p{1, 2}; //  

• Les constructeurs disponibles uniquement dans les spécialisations de modèles ne sont pas pris en charge.

   template <class T> struct Wrapper {}; template <> struct Wrapper<int> { Wrapper(int) {}; }; Wrapper w{5}; //  

• Les modèles imbriqués ne sont pas pris en charge

   template <class T> struct Foo { template <class U> struct Bar { Bar(T, U) {}; }; }; Foo::Bar x{ 1, 2.0 }; //  Foo<int>::Bar x{1, 2.0}; // OK 

• Évidemment, CTAD ne fonctionnera pas si le type du paramètre de modèle n'est pas lié aux arguments du constructeur.

   template <class T> struct Collection { Collection(std::size_t size) {}; }; Collection c{5}; //  

Dans certains cas, des règles d'inférence explicites qui devraient être déclarées dans le même bloc que le modèle de classe seront utiles.



Lire la suite: une fois (russe) , deux (anglais)

EBO

Optimisation de la base vide. Optimisation d'une classe de base vide. Aussi appelé EBCO (Empty Base Class Optimization).

Comme vous le savez, en C ++, la taille d'un objet d'une classe ne peut pas être nulle. Sinon, toute l'arithmétique des pointeurs se brisera, car à une adresse, il sera possible de marquer autant d'objets différents que vous le souhaitez. Par conséquent, même les objets de classes vides (c'est-à-dire les classes sans un seul champ non statique) ont une taille non nulle, qui dépend du compilateur et du système d'exploitation et est généralement égale à 1.

Ainsi, la mémoire est gaspillée en vain sur tous les objets des classes vides. Mais pas les objets de leurs descendants, car dans ce cas le Standard fait explicitement une exception. Le compilateur est autorisé à ne pas allouer de mémoire pour une classe de base vide et à enregistrer ainsi non seulement 1 octet de la classe vide, mais les 4 (selon la plate-forme), car il y a également alignement.


Mais comme différents objets du même type ne peuvent pas être placés à la même adresse, l' EBO ne fonctionnera pas si:

• Une classe vide se trouve deux fois parmi les ancêtres

   struct Empty {}; struct Empty2 : Empty {}; struct Foo : Empty, Empty2 { int i; }; std::cout << sizeof(Empty) << std::endl; // 1 std::cout << sizeof(Empty2) << std::endl; // 1 std::cout << sizeof(Foo) << std::endl; // 8 

• Le premier champ non statique est un objet de la même classe vide ou son descendant

   struct Empty {}; struct Foo : Empty { Empty e; int i; }; std::cout << sizeof(Empty) << std::endl; // 1 std::cout << sizeof(Foo) << std::endl; // 8 

Dans les cas où les objets des classes vides sont des champs non statiques, aucune optimisation n'est fournie (pour l'instant, l'attribut [[no_unique_address]] apparaîtra en C ++ 20). Mais dépenser 4 octets (ou combien le compilateur a besoin) pour chacun de ces champs est une honte, vous pouvez donc «réduire» les objets de classes vides avec le premier champ non statique non vide par vous-même.


En savoir plus: une fois (anglais) , deux (anglais)

IIFE

Expression de fonction immédiatement invoquée. Expression fonctionnelle appelée immédiatement. En général, c'est un idiome en JavaScript, d'où Jason Turner l'a emprunté avec le nom. En fait, il s'agit simplement de créer et d'appeler immédiatement un lambda:

 const auto myVar = [&] { if (condition1()) { return computeSomeComplexStuff(); } return condition2() ? computeSonethingElse() : DEFAULT_VALUE; } (); 

Pourquoi est-ce nécessaire? Eh bien, par exemple, comme dans le code ci-dessus afin d'initialiser une constante par le résultat d'un calcul non trivial et de ne pas obstruer la portée avec des variables et des fonctions inutiles.

En savoir plus: une fois (anglais) , deux (anglais)

NVI

Interface non virtuelle. Interface non virtuelle. Selon cet idiome, une interface de classe ouverte ne devrait pas contenir de fonctions virtuelles. Toutes les fonctions virtuelles sont rendues privées (protégées au maximum) et appelées à l'intérieur non ouvertes virtuelles.


Pourquoi est-ce nécessaire:

• Chaque fonction virtuelle ouverte fait 2 choses: elle définit l'interface publique de la classe et participe au comportement prioritaire dans les classes descendantes. L'utilisation de NVI élimine de telles fonctions avec une double charge: l'interface est définie par certaines fonctions, le changement de comportement par d'autres. Vous pouvez les modifier tous les deux indépendamment l'un de l'autre.
• (- -, . .), (. DRY ) — — . C'est-à-dire .

NVI – , (- ) (. FBC ).

: (.) , (.)

RVO NRVO

(Named) Return Value Optimization. () . copy elision – , . , ( copy elision – ).


RVO Foo bar , main ( bar ), f . RVO , bar f .

: main f . bar ( ), , .

NRVO RVO , , return , .


, NRVO , . , , , — NRVO .


RVO . NRVO .

RVO NRVO – . , . C++17: RVO copy elision, , .

: (N)RVO — . C++14 , C++17 RVO , C++20 – .

. -, (N)RVO - , .. . -, result std::move(result) , NRVO . : RVO prvalue, NRVO – lvalue, a std::move(result) – xvalue.

: (.) , (.) , (.)

SFINAE

Substitution Failure Is Not An Error. — . SFINAE — — — ++. , , , . , :

1. — (. ADL ).
2. — , , , . .
3. (viable functions), . — .

SFINAE : , , , ( ). .

SFINAE , , . - , . . , .


C++17 static if SFINAE , C++20 . .

: (.) , (.) , (.)

SBO, SOO, SSO

Small Buffer/Object/String Optimization. //. SSO Small Size Optimization, , , SSO – . SBO SOO – , SSO – .

, , - . , . , ( ), .

, std::string :


24 ( ). C'est-à-dire 24 . 24, , . . - . 8 ( — 24 ):


, — . .

std::string SSO std::function . std::vector , . . , std::swap , . SBO ( std::string ). boost::container::small_vector , , SBO .

: (.) , (.)

UDPATE

PyerK .

CV

const volatile. const , / , , UB . volatile , / (, - - ), . volatile volatile UB .

: (.) , (.) , (.)

LTO

Link Time Optimization. . , , . . . , : , . , .

: (.)

PCH

Precompiled Headers. . , . , .

: (.)

PGO

Profile-Guided Optimization. . , , . , .

: (.)

SEH/VEH

Structured/Vectored Exception Handling. MSVC . try-catch SEH : __try , __except , __finally , , , , - , . . VEH , .

: (.)

TMP

Template Meta-Programming. . — . C++ . . , TMP C++ , . . .

: (.)

VLA

Variable-Length Arrays. . C'est-à-dire , :

 void foo(int n) { int array[n]; } 

C++ . , . . C C99. C++ .

: (.)

PS

- - — . , , , C++. , , .