Vecteur sans template

Vecteur sans template - C++ - Programmation

Marsh Posté le 14-02-2006 à 09:49:34    

Bonjour
 
je voudrais savoir si quelqu'un a une idée pour implémenter un std::vector sans template ?
"Sans template" est non négociable, "std::vector" c'est simplement un exemple de conteneur générique, souple et relativement performant.
J'ai vaguement dans l'idée qu'avec des macros a gogo y a peut-etre moyen, mais la lisibilité et la maintenabilité ne sont pas à négliger dans mon cas.

Message cité 1 fois
Reply

Marsh Posté le 14-02-2006 à 09:49:34   

Reply

Marsh Posté le 14-02-2006 à 22:31:30    

retrox a écrit :

je voudrais savoir si quelqu'un a une idée pour implémenter un std::vector sans template ?
"Sans template" est non négociable, "std::vector" c'est simplement un exemple de conteneur générique, souple et relativement performant.


 
Par curiosité alors -- puisque non négociable -- pourquoi sans template ?
 

retrox a écrit :

J'ai vaguement dans l'idée qu'avec des macros a gogo y a peut-etre moyen, mais la lisibilité et la maintenabilité ne sont pas à négliger dans mon cas.


 
Peut être que la rubrique généricité de la page de Laurent Deniau pourra t'interesser :
http://ldeniau.home.cern.ch/ldenia [...] /oopc.html


Message édité par ++fab le 14-02-2006 à 22:31:59
Reply

Marsh Posté le 15-02-2006 à 08:39:53    

je pige pas le pourquoi du "sans template", et je vois pas ce que les macros t'apporteront, les templates C++ n'etant basiquement que du gros copier coller de code

Reply

Marsh Posté le 15-02-2006 à 10:55:11    

Je ne comprends pas ce que tu entends par "non négociable".
 
Ou sinon faire la programmation par Objet, cad un truc dans le genre :
 

Code :
  1. class Vector {
  2.    private:
  3.       Elements* _type;
  4.    public:
  5.       Vector(Elements* aux) : _type(aux) { }
  6. };
  8. class Elements {
  9.    //On definit toutes les methodes qu'on veut utiliser dans les elements en virtuelles pures
  10. };
  12. class 2D : public Elements {
  13.     private:
  14.         int _x;
  15.         int _y;
  16. };


 
Il faut maintenant réadapter le code à ta convenance.

Message cité 1 fois
Message édité par Veovis27 le 15-02-2006 à 10:55:39
Reply

Marsh Posté le 15-02-2006 à 12:49:45    

Veovis27 a écrit :

Je ne comprends pas ce que tu entends par "non négociable".


 
je ne sais pas si t'a deja essayé mais faire générer des tonnes de code par des macros c'est inmaintenable (en fait pour le CPP tout le code se trouve sur la meme ligne), et tu n'aura jamais tout les controles statiques et les optimisations que permettent les templates C++, ce n'est pas un simple copier-collé

Reply

Marsh Posté le 15-02-2006 à 13:13:03    

Pas de template parce que je me prépare à recevoir des demandes de portage sur plateforme ne disposant pas de toutes les features C++ (ça vient de commencer avec une plateforme n'ayant pas de STL  :o ).
 
Merci pour le lien ++fab, je vais jeter un coup d'oeil.
 
Veovis, le probleme avec cette approche, c'est que tu ne peux pas mettre de type de base dans ton conteneur (sauf en encapsulant chaque type de base dans une classe, mais alors la bonjour la lisibilité).

Message cité 1 fois
Reply

Marsh Posté le 15-02-2006 à 13:41:14    

retrox a écrit :

Pas de template parce que je me prépare à recevoir des demandes de portage sur plateforme ne disposant pas de toutes les features C++ (ça vient de commencer avec une plateforme n'ayant pas de STL  :o ).


[:pingouino]
 

retrox a écrit :


Veovis, le probleme avec cette approche, c'est que tu ne peux pas mettre de type de base dans ton conteneur (sauf en encapsulant chaque type de base dans une classe, mais alors la bonjour la lisibilité).


 
Nan mais honnetement, en macro ca va pas etre possible, ou alors tellement laid que tu regretteras de pas avoir fait ca en asm

Reply

Marsh Posté le 16-02-2006 à 02:21:45    

pas forcément laid, ni plus difficile à maintenir s'il ne veut absolument pas upgrader son compilateur.
 

Code :
  1. #define BuildVectorClassFor(T) \
  2. class Vector_##T { \
  3. T *data; \
  4. size_t capacity,count; \
  5. public : \
  6. Vector_##T(size_t s=256) : capacity(s), count(0) { data=(T*)::calloc(capacity,sizeof(T)); } \
  7. ~Vector_##T() { free(data); } \
  8. T& operator[](size_t i) { return data[i]; } \
  9. void push_back(const T&v) { if(count<capacity) data[count++]=v; } \
  10. };
  13. BuildVectorClassFor(int);
  14. BuildVectorClassFor(double);
  16.     int main()
  17.     {
  18.        
  19.      Vector_int t;
  20.      Vector_double x;
  22.      x.push_back(7.34);
  23.      std::cout<<x[0]<<std::endl;

Reply

Marsh Posté le 16-02-2006 à 08:17:59    

le probleme c'est qu'il faut gérer les instenciations explicitement, si ta classe dépend d'autres classes templates (dont d'autres classes dépendent...) les instanciations seront d'autant plus dur à gérées (comment savoir si ce code n'a pas déja été défini ?)
aussi si ta une erreur dans le code accroche toi pour savoir à quelle ligne c'est (apres passage du cpp tout est sur la meme ligne)
 

Reply

Marsh Posté le 16-02-2006 à 08:30:04    

ah ouais, c'est bandant [:pingouino]

Reply

Marsh Posté le 16-02-2006 à 08:30:04   

Reply

Marsh Posté le 16-02-2006 à 08:48:03    

et en plus tu risques pas d'avoir des symboles définis plusieurs fois dans ton progue ?

Reply

Marsh Posté le 16-02-2006 à 09:26:19    

ouai et meme en laissant tout le code dans la déclaration de la classe ou en foutant dans le namespace anonyme il y a encore risque de de multiple definition au sein de la meme unité de compilation si on un schema de classe template avec des dépendance un peu plus complexe que ca (un truc normal quoi), c'est vraiment ingérable dans la pratique

Reply

Marsh Posté le 16-02-2006 à 17:38:39    


^^^  
je voudrais pas me faire l'avocat de cette méthode mais
il me semble que les warnings sont assez explicites pour ce qui est des redéfinitions et les erreurs pas beaucoup moins claires que cellles rencontrées avec les templates.
 
pour résoudre le problème d'origine, il faudrait avoir quelques tests unitaires sur cette improbable classe vector_sans_template
 
sinon on peut controuner le problème des "annonces" avec des classes internes :
 

Code :
  1. #define GetTypeOf(Class,Type,Identifier) Class##_##Type_##Identifier
  3. #define Vector(T,I) \
  4. class GetTypeOf(Vector,T,I) { \
  5. T *data; \
  6. size_t capacity,count; \
  7. public : \
  8. GetTypeOf(Vector,T,I) (size_t s=256) : capacity(s), count(0) { data=(T*)::calloc(capacity,sizeof(T)); } \
  9. ~GetTypeOf(Vector,T,I) () { free(data); } \
  10. T& operator[](size_t i) { return data[i]; } \
  11. void push_back(const T&v) { if(count<capacity) data[count++]=v; } \
  12. } I;
  14.     int main()
  15.     {
  17.      Vector(double,x);
  18.      Vector(double,y);             
  20.      x.push_back(7.34);
  21.      std::cout<<x[0]<<std::endl;
  22.     }

Reply

Marsh Posté le 16-02-2006 à 17:57:22    

CAI HORRIBLE LOIN DE MOI CE TRUC

Reply

Marsh Posté le 16-02-2006 à 18:07:59    

bon désolé, demandez gentiment de ma part à Markus Oberhumer
 
http://www.oberhumer.com/products/nrv/

Reply

Marsh Posté le 16-02-2006 à 18:09:32    

chouette, comme ca tout le code est dans le main
serieux ca sert a rien de continuer, c'est ingérable, c'est tout

Reply

Marsh Posté le 16-02-2006 à 18:09:53    

bin jsais pas si t'es allé voir le code miniLZO, par exemple, mais c'est absolument imbitable

Reply

Marsh Posté le 16-02-2006 à 18:11:27    

clair j'y ai participé :o)

Reply

Marsh Posté le 16-02-2006 à 18:37:23    

[:pingouno] autant c'est pratique, ca marche bien et tout, autant le code est affreux, encore plus que la zlib, ce qui n'est pas rien.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed