Restreindre paramètre template à une famille de classes

Bonjour,

Je travaille sur un lecteur de CSV (CSV_reader) ligne par ligne, sans analyse, où l'exploitation des données est faite à part par l'implémentation d'une interface (Row_translator).

J'aimerais donc restreindre mon template CSV_reader aux classes dérivées de CSV_translator, afin d'appeler la méthode adaptée translate_row() à chaque lecture de ligne. Je tâtonne, et je n'arrive pas à faire taire mon compilateur.

Une idée ? Au fait, je suis au début de la conception, si vous avez une meilleure idée pour faire ce que je veux...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

class CSV_reader; class CSV_reader::Row_translator;   template <class Translator : public Row_translator> class CSV_reader : public CSVFile { std::ifstream m_csv;   public: class Row_translator { public: virtual void translate_row(Row const &) = 0; };   explicit CSV_reader(std::string path) : m_csv(path.c_str()) {}   void read(std::vector<Translator>&); };

---

J'ai essayé de profiter du polymorphisme sans template, mais sans succès :/

Merci d'avance.

Cordialement,

Kidpaddle2

Tu doit pouvoir vérifier que le paramètre template hérite (publiquement) de la classe que tu veus avec SFINAE, ou les concepts (si tu as un compilateur qui les as ou boost qui doit en avoir).

Merci de ta réponse.

J'utilise boost effectivement, mais il n'y a rien de natif dans le langage (quelque chose dans le goût de ce que j'ai marqué) ? Aussi, qu'est-ce qui me permettrait de le faire dans boost ?

SFINAE est une technique de programmation non spécifique à boost (j'ai pas de source d'exemple en tête, il faut chercher su google :s) les concepts que propose boost sont juste plus générique (je les ai pas utilisé, mais je pense qu'ils permettent de faire ca).

Non rien en natif dans le language, t'as boost.concept_check pour ça. Faut juste faire bien attention en définissant tes concepts..
Ou alors plus dans l'esprit de base, tu documentes tes concepts, et tu laisses l'utilisateur se tiré une balle dans le pied si il le veut. :).

Sinon ouai SFINAE + static_assert

Citation:

---

Envoyé par Goten

Ou alors plus dans l'esprit de base, tu documentes tes concepts, et tu laisses l'utilisateur se tiré une balle dans le pied si il le veut. :).

---

Je pense que documenter est aussi la meilleur solution, l'utilisateur est bien assez responsable pour savoir ce qu'il fait. concept ou SFINAE ca marche, mais c'est quand même assez lourd à mettre en place (surtout pour une seul classe) par rapport à une bonne doc.

Avec boost::enable_if et boost::is_base_of, ca marche nikel.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

#include <boost/type_traits.hpp> #include <boost/utility/enable_if.hpp>   class Base{}; class D: public Base{};   template <class C,class Enable=void> class foo; //la classe générale, ne pas donner de définition permet de générer une erreur si C ne dérive pas de Base   template <class C > class foo<C,typename boost::enable_if<boost::is_base_of<Base,C> >::type>{}; //une spécialisation partielle quand C dérive de Base.       int main(int argc, char const *argv[]) { foo<D> f; //foo<int> ff; //plante return 0; }

---

Edit: les concepts, c'est pour vérifier qu'une classe vérifie bien une interface donnée. Pour juste une histoire de rectriction, y'a plus léger dans boost.

oh dear, ça m'apprendra à pas lire le sujet en entier :p, j'ai loupé cette histoire de dérivation :p.

En effet la solution de David est la meilleure dans ce cas là.

En general:
-enable_if pour la selection/masquage d'interface au vu de traits présent ou non
- static_assert pour la vioaltion de pre-condition statique
- concept_check pour la vioaltion de cocnept

Faut toujours se poser la question de savoir si le test correspond vraiment à une selection par le traits ou une erreur.

Salut,
C++0x propose un std::enable_if, un std::is_base_of, un static_assert etc... Dispo sur Visual 2010 et gcc.
Sinon, SFINAE est sur la F.A.Q. C++ : F.A.Q : Qu'est-ce que SFINAE ?

Merci pour vos réponses.

Je viens d'essayer la méthode de Davidbrcz, mais visiblement cela ne marche pas avec les méthodes... A moins qu'il y ait une erreur ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

class CSV_reader : public CSVFile { std::ifstream m_csv;   public: class CSV_translator { public: virtual void translate_row(Row const &) = 0; };   explicit CSV_reader(std::string path) : m_csv(path.c_str()) {}   template<class Translator, class Enable = void> void read(std::vector<Translator> &);   template <class Translator> void read<Translator, typename boost::enable_if<boost::is_base_of<CSV_translator, Translator> >::type> (std::vector<Translator> &translator) { Iterator it(m_csv);   translator.translate_row(*(++it)); } };

---

Code:

---

1 2 3 4 5 6 7 8

template<class Translator, class Enable = void> void read(...);   template <class Translator> void read<Translator, typename boost::enable_if<boost::is_base_of<CSV_translator, Translator> >::type> (std::vector<Translator> &translator) { Iterator it(m_csv);

---

Personnellement, ça me parait un peu lourd. C'est toute une cuisine pour générer une erreur que tu aurais de toute façon. En plus tu utilises un std::vector<Translator> alors que 1/Translator hérite publiquement de CSV_translator et 2/que le vecteur est par valeur. Il y a quelque chose de bancale là dedans.

Je serais resté sur quelque chose de beaucoup plus simple :

Code:

---

1 2 3 4 5 6 7 8

class CSV_reader : public CSVFile { std::ifstream m_csv;   public: explicit CSV_reader(std::string path) : m_csv(path.c_str()) {}   template <class Translator> void read(std::vector<Translator> &translator) {

---

L'appel à translate_row donne de toute façon une erreur si Translator n'a pas défini une telle fonction. Le seul intérêt de static_assert dans ce cas (et il n'est pas mince) est d'éventuellement donner une erreur un peu plus explicite. En revanche, le montage avec CSV_translator et l'héritage, je ne le sent pas trop. Tu as besoin d'un 'concept' pas d'une classe de base.

P.S. : si tu poursuis dans l'idée d'approche générique, read ne devrait pas prendre un std::vector mais un range (~couple itérateur début/fin)

Merci de tes conseils. Je ne suis effectivement plus vraiment emballé par l'héritage, mais je souhaite conserver l'idée de spécialisation d'analyse (i.e. Traducteur) de ligne. Que veux-tu donc dire par concept, une meilleure idée ?

En ce qui concerne le range, le problème c'est que read() remplit, il ajoute dynamiquement des instances de traducteurs (qui auront été remplis par la traduction d'une ligne : une ligne brute -> un traducteur rempli). Comment puis-je donc donner un range si je ne connais pas la fin ?

Citation:

---

Envoyé par kidpaddle2

Que veux-tu donc dire par concept, une meilleure idée ?

---

A un moment, ça devait être introduit dans C++0x, mais ça été abandonné. Sinon, tu as Boost.Check Concept.
L'idée du concept, c'est de définir explicitement ce que tu attends de ton paramètre générique. C'est en quelque sorte un contrat au moins syntaxique.
En utilisant un concept tu indiques donc ce que tu attends du paramètre Translator plus explicitement pour un lecteur de ton code et les erreurs générées sont un peu plus compréhensible en théorie.
Ta fonction générique read<Translator> nécessite que t.translate_row(string_) pour t de type Translator et string_ std::string.

Citation:

---

Envoyé par kidpaddle2

je souhaite conserver l'idée de spécialisation d'analyse (i.e. Traducteur) de ligne.

---

:koi: Tu veux que read<Translator> requiert explicitement de Translator d'avoir une fonction translate_row ou tu veux spécialiser différemment read<Translator> selon des critères sur Translator ?

Citation:

---

Envoyé par kidpaddle2

En ce qui concerne le range, le problème c'est que read() remplit, il ajoute dynamiquement des instances de traducteurs (qui auront été remplis par la traduction d'une ligne : une ligne brute -> un traducteur rempli). Comment puis-je donc donner un range si je ne connais pas la fin ?

---

Tu peux quand même passer un std::[back|front]_insert_iterator (disons un output iterator construit si besoin avec un insert_iterator).

Code:

---

1 2 3 4 5

// iterator_ : <a href="http://www.cplusplus.com/reference/std/iterator/OutputIterator/" target="_blank">output iterator</a> (au sens des requis des itérateur) // *iterator : 'translate_rowable' (*it).translate_row(s) expression valide template <class iterator_> iterator_ read(iterator_ begin_) {

---

Merci de ta réponse, l'idée de std::insert_iterator est excellente ! Je vais essayer de l'implémenter.

En fait, je veux fixer une bonne fois pour toutes tout ce qui est lecture, et si les fichiers changent, ce seront les traducteurs qui changeront. Je veux donc non pas spécialiser read<>, mais spécialiser CSV_reader::Translator::translate_row().

Citation:

---

Envoyé par kidpaddle2

En fait, je veux fixer une bonne fois pour toutes tout ce qui est lecture, et si les fichiers changent, ce seront les traducteurs qui changeront. Je veux donc non pas spécialiser read<>, mais spécialiser CSV_reader::Translator::translate_row().

---

Je comprend pas. Translator est ton paramètre générique. Tu ne peux le spécialiser dans CVS_reader ? Peux-tu montrer en code (qui ne compile pas bien sûr) ce que tu voudrais faire ?

Bon, visiblement, j'étais parti du mauvais pied. Suite à une discussion parallèle (c'est le cas de le dire) concernant l'aspect "threads", j'ai finalement penché pour une structure "queue" héritée, voir le topic suivant (#6) : http://www.developpez.net/forums/d94...entre-threads/ .

Merci de votre aide à tous !