Just to provide some examples for the things said: STL containers.
typedef std::map tFrobozMap;
tFrobozMap frobozzes;
...
for(tFrobozMap::iterator it=frobozzes.begin(); it!=map.end(); ++it)
{
...
}
Il n'est pas rare d'utiliser aussi des typedefs comme
typedef tFrobozMap::iterator tFrobozMapIter;
typedef tFrobozMap::const_iterator tFrobozMapCIter;
Un autre exemple : utiliser des pointeurs partagés :
class Froboz;
typedef boost::shared_ptr FrobozPtr;
[mise à jour] Selon le commentaire - où les placer ?
Le dernier exemple - l'utilisation de shared_ptr
- est facile : ce sont du matériel de type en-tête réel - ou du moins un en-tête anticipé. Vous avez de toute façon besoin de la déclaration anticipée pour shared_ptr, et l'un de ses avantages déclarés est qu'il est sûr de l'utiliser avec une déclaration anticipée.
Dit d'une autre manière : s'il y a un shared_ptr, vous devriez probablement utiliser le type uniquement à travers un shared_ptr, donc séparer les déclarations n'a pas beaucoup de sens.
(Oui, xyzfwd.h est pénible. Je ne les utiliserai que dans les points chauds - sachant que les points chauds sont difficiles à identifier. Blâmez le modèle de compilation+liaison C++...)
Les typedefs de conteneurs que j'utilise généralement là où la variable de conteneur est déclarée - par exemple localement pour une variable locale, en tant que membres de classe lorsque l'instance de conteneur réelle est un membre de classe. Cela fonctionne bien si le type de conteneur réel est un détail d'implémentation - ne causant aucune dépendance supplémentaire.
S'ils font partie d'une interface particulière, ils sont déclarés conjointement avec l'interface avec laquelle ils sont utilisés, par exemple
// FrobozMangler.h
#include "Froboz.h"
typedef std::map tFrobozMap;
void Mangle(tFrobozMap const & frobozzes);
Cela devient problématique lorsque le type est un élément de liaison entre différentes interfaces - c'est-à-dire que le même type est nécessaire par plusieurs en-têtes. Quelques solutions :
- le déclarer conjointement avec le type contenu (adapté aux conteneurs fréquemment utilisés pour ce type)
- les déplacer dans un en-tête séparé
- les déplacer dans un en-tête séparé, et en faire une classe de données où le conteneur réel est à nouveau un détail d'implémentation
Je suis d'accord que les deux dernières options ne sont pas géniales, je ne les utiliserai que si je rencontre des problèmes (pas de manière proactive).
0 votes
Par curiosité, qu'est-ce que le MFC ?
1 votes
@Milan en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library