CLASSE TEMPLATE TABLEAUX SÉCURISÉS À ALLOCATIONS AUTOMATIQUES
cs_pepet
Messages postés
34
Date d'inscription
lundi 11 mars 2002
Statut
Membre
Dernière intervention
21 janvier 2003
-
21 août 2002 à 12:02
cs_Lightness1024! Messages postés 162 Date d'inscription jeudi 15 mars 2001 Statut Membre Dernière intervention 1 avril 2005 - 17 août 2005 à 13:01
cs_Lightness1024! Messages postés 162 Date d'inscription jeudi 15 mars 2001 Statut Membre Dernière intervention 1 avril 2005 - 17 août 2005 à 13:01
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/9885-classe-template-tableaux-securises-a-allocations-automatiques
https://codes-sources.commentcamarche.net/source/9885-classe-template-tableaux-securises-a-allocations-automatiques
17 août 2005 à 13:01
et oui tu as raison il faudrait la faire dériver de std::exception mais le but de cette classe c'etait juste de faire un conteneur totalement indépendant de la STL.
par rapport à std::vector je suis encore loin de la qualité qu'il peut fournir et je ne garanti pas non plus la compatibilité de l'interface avec les conteneurs stl (iterateurs...).
c'est juste qu'en C++ les conteneurs c'est quelque chose de tres marrant a coder, et utiliser la STL c'est se priver totalement de cette expérience, c'est pour ca que je ne l'aime pas :)
17 août 2005 à 10:50
un conseil:
fais dériver ta classe OutOfRange de std::exception qui contient déja une méthode what() a surchager qui renvoie un const char* et qui décrit l'erreur. comme ca y'aurait pas besoin d'utiliser ton GetErrorStringPtr qui est vraiment pas beau !!!!
sinon c'est pas mal, mais ya t'il un gain par rapport a l'utilisation de std::vector ??
15 août 2005 à 18:10
bon, j'ai eu quelques problemes quand j'ai fait mon ZIP (bzip2 plutot que "Deflate" ca n'a pas plu au site).
je suis donc désolé pour les 500 tentatives manquées qui ont floodées le log des mises à jour lol. pardon encore.
30 août 2002 à 08:41
24 août 2002 à 14:11
evidemment que c'est moi et même à 100% voyons et si il n'y avais qu'une ligne pas de moi j'aurais respecté la propriété intellectuelle et j'aurais cité l'auteur.
deuxièmement, int 32768 ?? non pas du tout ca c'est les variables de types 16 bits qui peuvent atteindre cette limite, et d'ailleur tu as ecris 2^8 ce qui fait 256 pas 32768. la variable int prend un registre processeur et sa taille dépend donc de la machine, et depuis les 386 ces registres font 32 bits donc un int fait 32 bits donc a une valeur maximum de 2 147 483 647 ce qui n'est pas si limité que ca pour une taille de tableau étant donné que la mémoire maximum allouable est de 4GO et le plus petit type etant BYTE on peut théoriquement allouer 50% de la mémoire au minimum si on utilise le maximum du type int (mais ca ne fonctionnera jamais dans la réalité il faut utiliser plusieurs tableaux pour remplir un espace aussi immense).
par contre etant donné que j'utilise new et delete peut etre que la rapidité d'allocation sera moins puissante que ta methode realloc.
et franchement je suis déçu que tu puisse croire que je n'ait pas édité de code moi même mais je te pardonne car tu ne me connais pas, et d'un coté c'est une sorte de compliment ! :)
21 août 2002 à 12:02
En tout cas le fait d'utiliser des INT pour gerer le tableau n'est peut etre pas recommender car un int a une valeur max de 2^8 = 32768 c ki limite grandement la taille du tableau.
j'ai mis 9/10 pour le code!
@+