Il est parfaitement légal de lancer une exception dans un constructeur. En fait, c'est même la seule solution pour signaler une erreur lors de la construction d'un objet, puisque les constructeurs n'ont pas de valeur de retour.
Lorsqu'une exception est lancée à partir d'un constructeur, la construction de l'objet échoue. Par conséquent, le compilateur n'appellera jamais le destructeur pour cet objet, puisque cela n'a pas de sens. Cependant, ce comportement soulève le problème des objets partiellement initialisés, pour lesquels il est nécessaire de faire un peu de nettoyage à la suite du lancement de l'exception. Le C++ dispose donc d'une syntaxe particulière pour les constructeurs des objets susceptibles de lancer des exceptions. Cette syntaxe permet simplement d'utiliser un bloc try pour le corps de fonction des constructeurs. Les blocs catch suivent alors la définition du constructeur, et effectuent la libération des ressources que le constructeur aurait pu allouer avant que l'exception ne se produise.
Le comportement du bloc catch des constructeurs avec bloc try est différent de celui des blocs catch classiques. En effet, les exceptions ne sont normalement pas relancées une fois qu'elles ont été traitées. Comme on l'a vu ci-dessus, il faut utiliser explicitement le mot clé throw pour relancer une exception à l'issue de son traitement. Dans le cas des constructeurs avec un bloc try cependant, l'exception est systématiquement relancée. Le bloc catch du constructeur ne doit donc prendre en charge que la destruction des données membres partiellement construites, et il faut toujours capter l'exception au niveau du programme qui a cherché à créer l'objet.
De même, lorsque la construction de l'objet se fait dans le cadre d'une allocation dynamique de mémoire, le compilateur appelle automatiquement l'opérateur delete afin de restituer la mémoire allouée pour cet objet. Il est donc inutile de restituer la mémoire de l'objet alloué dans le traitement de l'exception qui suit la création dynamique de l'objet, et il ne faut pas y appeler l'opérateur delete manuellement.
Exemple 9-5. Exceptions dans les constructeurs.
using namespace std;
class A
 char *pBuffer;
 int *pData;
public:
 A() throw (int);
 ~A()
 cout « "A::~A()" « endl;
 static void *operator new(size_t taille)
 cout « "new()" « endl;
 return malloc(taille);
 static void operator delete(void *p)
 cout « "delete" « endl;
 free(p);
};
// Constructeur susceptible de lancer une exception :
A::A() throw (int)
try
 pBuffer = NULL;
 pData = NULL;
 cout « "Début du constructeur" « endl;
 pBuffer = new char[256];
 cout « "Lancement de l'exception" « endl;
 throw 2;
 // Code inaccessible :
 pData = new int;
catch (int)
 cout « "Je fais le ménage..." « endl;
 delete[] pBuffer;
 delete pData;
int main(void)
 try
 A *a = new A;
 catch (...)
 cout « "Aïe, même pas mal !" « endl;
 return 0;
Dans cet exemple, lors de la création dynamique d'un objet A, une erreur d'initialisation se produit et une exception est lancée. Celle-ci est alors traitée dans le bloc catch qui suit la définition du constructeur de la classe A. L'opérateur delete est bien appelé automatiquement, mais le destructeur de A n'est jamais exécuté.
En général, si une classe hérite de une ou plusieurs classes de base, l'appel aux constructeurs des classes de base doit se faire entre le mot clé try et la première accolade. En effet, les constructeurs des classes de base sont susceptibles, eux aussi, de lancer des exceptions. La syntaxe est alors la suivante :
Classe::Classe
 try : Base(paramètres) [, Base(paramètres) [...]]
catch ...

Pastéis de nata
Livre de cuisine/Desserts/Pastéis de nata

Un pastel de nata (au pluriel pastéis de nata), littéralement « pâtisserie(s) à la crème », est une pâtisserie typique de la cuisine portugaise, une sorte de flan pâtissier, parfois dégusté tiède.
La « Fábrica dos pastéis de Belém » (une pâtisserie située à Lisbonne) utilise également le terme « pastel de Belém ».
Même si la "vraie" recette n'est pas connue, celle-ci pourra vous permettre de réaliser vous même ces pâtisseries, avec des moules adaptés "(pour 15 unités)".

Japonais/Vocabulaire/Moyens de transport

Programmation C-C++/Identification des types

Le C++ est un langage fortement typé. Malgré cela, il se peut que le type exact d'un objet soit inconnu à cause de l'héritage. Par exemple, si un objet est considéré comme un objet d'une classe de base de sa véritable classe, on ne peut pas déterminer a priori quelle est sa véritable nature.
Cependant, les objets polymorphiques (qui, rappelons-le, sont des objets disposant de méthodes virtuelles) conservent des informations sur leur type dynamique, à savoir leur véritable nature. En effet, lors de l'appel des méthodes virtuelles, la méthode appelée est la méthode de la véritable classe de l'objet.
Il est possible d'utiliser cette propriété pour mettre en place un mécanisme permettant d'identifier le type dynamique des objets, mais cette manière de procéder n'est pas portable. Le C++ fournit donc un mécanisme standard permettant de manipuler les informations de type des objets polymorphiques. Ce mécanisme prend en charge l'identification dynamique des types et la vérification de la validité des transtypages dans le cadre de la dérivation.

Programmation C-C++/Les espaces de nommage

Les espaces de nommage sont des zones de déclaration qui permettent de délimiter la recherche des noms des identificateurs par le compilateur. Leur but est essentiellement de regrouper les identificateurs logiquement et d'éviter les conflits de noms entre plusieurs parties d'un même projet. Par exemple, si deux programmeurs définissent différemment une même structure dans deux fichiers différents, un conflit entre ces deux structures aura lieu au mieux à l'édition de liens, et au pire lors de l'utilisation commune des sources de ces deux programmeurs. Ce type de conflit provient du fait que le C++ ne fournit qu'un seul espace de nommage de portée globale, dans lequel il ne doit y avoir aucun conflit de nom. Grâce aux espaces de nommage non globaux, ce type de problème peut être plus facilement évité, parce que l'on peut éviter de définir les objets globaux dans la portée globale.

Programmation C-C++/Les templates
Programmation C-C++/La bibliothèque standard