Pour chaque container, rendez les fichiers obligatoires avec le nom attendu.
Ciao Norminette ! Aucune norme n’est imposée. Vous pouvez suivre le style de votre choix. Mais ayez à l’esprit qu’un code que vos pairs ne peuvent comprendre est un code que vos pairs ne peuvent évaluer. Faites donc de votre mieux pour produire un code propre et lisible.

Le langage C, c’est fini pour l’instant. C’est l’heure du C++ ! Par conséquent :

Vous pouvez avoir recours à l’ensemble de la bibliothèque standard. Donc plutôt que de rester en terrain connu, essayez d’utiliser le plus possible les versions C++ des fonctions C dont vous avec l’habitude.
Cependant, vous ne pouvez avoir recours à aucune autre bibliothèque externe. Ce qui signifie que C++11 (et dérivés) et l’ensemble Boost sont interdits. Aussi, certaines fonctions demeurent interdites. Utiliser les fonctions suivantes résultera en la note de 0 : *printf(), *alloc() et free().

Les fuites de mémoires existent aussi en C++. Quand vous allouez de la mémoire, vous ne devez pas avoir de memory leaks.
Une fonction implémentée dans un fichier d’en-tête (hormis dans le cas de fonction template) équivaudra à la note de 0.
Vous devez pouvoir utiliser vos fichiers d’en-tête séparément les uns des autres. C’est pourquoi ils devront inclure toutes les dépendances qui leur seront néces- saires. Cependant, vous devez éviter le problème de la double inclusion en les protégeant avec des include guards. Dans le cas contraire, votre note sera de 0.

vector
- Vous n’avez pas à faire la spécialisation vector.
map
stack
- Elle utilisera votre classe vector comme container sous-jacent par défaut. Cependant, elle restera compatible avec les autres containers, ceux de la STL inclus.

iterators_traits
reverse_iterator
enable_if
- Oui, il s’agit de C++11 mais vous saurez le refaire en C++98.
- Le but est de vous faire découvrir SFINAE.
is_integral
equal et/ou lexicographical_compare
std::pair
std::make_pair

Le namespace doit être ft.
La structure de données interne utilisée pour chacun de vos containers doit être cohérente et justifiable (utiliser juste un tableau pour map n’est donc pas accepté).
Vous ne pouvez pas implémenter plus de fonctions publiques que ne possèdent les containers standards. Toute autre fonction supplémentaire doit être privée ou protégée. Chaque fonction et chaque variable publique doit être justifiée.
Toutes les fonctions membres, les fonctions non-membres et les surcharges d’un container sont attendues.
Vous devez vous conformer au nommage original. Faites attention aux détails.
Si le container possède un système d’itérateur, vous devez l’implémenter.
Vous devez utiliser std::allocator.
Pour les surcharges non-membres, le mot-clé friend est autorisé. Chaque utilisation de friend doit être justifiée et sera vérifiée en évaluation.
Bien entendu, pour implémenter map::value_compare, le mot-clé friend est autorisé.

Vous devez aussi fournir vos propres tests, au minimum un main.cpp, pour votre évaluation. Vous devez pousser plus loin que le main donné en exemple !
Vous devez créer deux binaires faisant tourner les mêmes tests : l’un avec vos containers et l’autre avec les containers standards.
Comparez les sorties et les performances / temps (vos containers peuvent être jusqu’à 20 fois plus lents que les originaux).
Pour tester vos containers : ft::.

CONTAINERS