Template & méthode virtuelle

Version imprimable

03/02/2013, 21h36
Neckara

Template & méthode virtuelle
Bonjour,

Actuellement j'essaye de créer une petite bibliothèque permettant d'encapsuler l'accès aux bases de données.

Mais je me heurte à un problème pour le résultats des requêtes.

J'ai une classe résultat qui doit avoir une méthode virtuelle pure permettant d'obtenir une ligne de résultat.
Je pensais donc retourner un tuple et faire :
Code:

1 2 template<typename T> virtual std::tuple<T> operator[](unsigned int i) = 0;
Mais on ne peut pas déclarer une méthode template virtuelle :

Citation:

erreur : templates may not be 'virtual'

Que cela ne tienne, il me suffit de créer une classe LigneResultat ainsi qu'une classe ElementResultat et de faire en sorte que Resultat contienne un vector de LigneResultat qui lui-même contienne un vector de ElementResultat.

Sauf qu'à partir de l'ElementResultat il faut que je puisse le convertir dans le bon type appropriée, conversion qui dépends des bibliothèques d'accès de BDD que j'utilise dans l'implémentation (pqxx pour postgresql, etc...).
Il faudrait donc que ElementResultat définisse une méthode template abstraite qui serait redéfinie par chaque implémentation :
Code:

1 2 template<typename T> virtual T as<T>(bool & reussite)= 0;
:aie:

Auriez-vous une idée de comment je pourrais procéder?
03/02/2013, 23h27
jouana

Bonjour tu as une solution ici http://codepad.org/VVjGIDQL

Bonjour,

Merci pour ta réponse mais je ne vois pas vraiment comment l'utiliser.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 class Resultat { template <typename Elements> std::tuple<Elements> operator[](int i) { //creation du tuple //parcours tuple Type x = getElements<Type>(); //affectation dans le tuple //fin parcours } } class PSQLResultat : public Resultat{}; class MySQLResultat : public Resultat{};
Or je vois mal comment récupérer la valeur dans le bon type (getElement) vu que cela dépend de l'implémentation dans PSQLResultat (implémentation pour postgreSQL, les résultats sont stockés sous forme de pqxx::resultat ) et dans MySQLResultat (implémentation pour MySQL, les résultats sont stockés sous forme de ??? ).

04/02/2013, 09h19
jouana

Tu ne peux pas la solution est de poser ton interface puis le template via la classe qui implemente ton interface
04/02/2013, 09h27
Bousk

Salut neckara,
De ce que je comprends tu veux mettre dans l'interface ta méthode de traduction des types, or je pense que celle-ci devrait être implementation-defined puisque dépendant du type de db derrière et donc totalement privée.
Mon attention se porterait plus sur la création d'une interface commune de données, et non sur la factorisation de leur origine et transformation nécessaire pour y arriver.
04/02/2013, 10h53
Neckara

Citation:

Envoyé par jouana

Tu ne peux pas la solution est de poser ton interface puis le template via la classe qui implemente ton interface

Mais comment déclarer la méthode de l'interface vu que selon ce que l'utilisateur demande, peut retourner des types différents.

Citation:

Salut neckara,
De ce que je comprends tu veux mettre dans l'interface ta méthode de traduction des types,

Non, si c'était le cas, je n'aurais aucun problème avec les "virtuel template", je veux traduire la valeur voulue par l'utilisateur dans le type voulu en utilisant la méthode définie dans l'implémentation. Mais l'utilisateur ne doit pas connaître la classe d'implémentation, il doit passer obligatoirement par l'interface.

Citation:

Mon attention se porterait plus sur la création d'une interface commune de données, et non sur la factorisation de leur origine et transformation nécessaire pour y arriver.

L'interface commune de donnée est la classe Resultat mais il faut réussir à faire une méthode virtuelle pure permettant de récupérer les données que l'utilisateur souhaite et là je bloque totalement.
04/02/2013, 11h07
Bousk

Là où je te perds c'est que pour moi Resultat devrait être le plus haut niveau de ta hiérarchie, et peut alors posséder des méthodes template de transformation, non nécessairement virtual.

Ou alors tu parles de la traduction "user data" => "db data" pour des ajouts en DB ?
Dans ce dernier cas, il devrait suffire de proposer des méthodes pour les types "normaux" (string, int, ...).
04/02/2013, 11h17
Neckara

De Resultat héritent PSQLResultat et MySQLResultat.

Le problème c'est que même en mettant des templates de transformations non-virtuels, ce sont les classes PSQLResultat et MySQLResultat qui savent faire ces transformations, pas Resultat.

Là je parle de "dbData" => "C++Data"
04/02/2013, 12h11
jouana

Et une interface genre db qui retourne le champ réclamé en paramètre comme en java getString, getInt...

Et tes obj en dessous tu as un item pour chaque db.
Après tu manipule l'interface donc tu t'enfou du type de db.
04/02/2013, 12h23
Neckara

Citation:

Et une interface genre db qui retourne le champ réclamé en paramètre comme en java getString, getInt...

J'y avais pensé mais elle ne me plaisait pas tellement car il faut définir une méthode pour chaque type (long long int, double, char, bool, string) mais je pense que ce doit être la seule solution...
04/02/2013, 12h30
white_tentacle

Ta liste de types est finie, je suppose ? (int, date, string, bool, time, deux trois que j’oublie et basta…).

Du coup, tu n’as pas besoin de passer par un template. Déclare getAsInt, getAsString, … (parce que de toute façon, je pense que tu vas devoir spécialiser tous tes templates, du coup, l’intérêt me semble limité… Et si ce n’est pas le cas, rien ne t’empêche de déclarer une fonction template privée pour factoriser le bazar).
04/02/2013, 19h02
Neckara

Citation:

Envoyé par white_tentacle

Ta liste de types est finie, je suppose ? (int, date, string, bool, time, deux trois que j’oublie et basta…).

En fait cela risque de dépendre de l'utilisateur et de ce qu'il stocke dans sa base de donnée.
Je ne peux pas être sûr de faire tous les types nécessaire si par exemple il a stocké un objet en champ de bit dans la base de données (dans ce cas là, un reinterpret_cast<> pourrait être possible (?) ).

Citation:

Envoyé par white_tentacle

Du coup, tu n’as pas besoin de passer par un template. Déclare getAsInt, getAsString, … (parce que de toute façon, je pense que tu vas devoir spécialiser tous tes templates, du coup, l’intérêt me semble limité… Et si ce n’est pas le cas, rien ne t’empêche de déclarer une fonction template privée pour factoriser le bazar).

Même pas, généralement les bibliothèques utilisées on une méthode to<Type> ou as<Type>(T).

Tu peux peut être remplacer l'héritage par un paramètre template ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 enum DBType { MySQL, PSQL }; template <DBType dbtype> struct Element { template <class T> struct fail { enum { value = false; }: }; template <class T> T as(bool& success) { // forcer une spécialisation static_assert(fail<T>::value, ""); } }; template <> template <> int Element<MySQL>::as<int>(bool& success) { ... }
Ainsi l'ajout d'un type ne se résume qu'a ajouter une spécialisation pour l'utilisateur. Et avec une spécialisation partielle tu peux avoir une spécialisation pour plusieurs types.

Citation:
Envoyé par Iradrille
Tu peux peut être remplacer l'héritage par un paramètre template ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 enum DBType { MySQL, PSQL }; template <DBType dbtype> struct Element { template <class T> struct fail { enum { value = false; }: }; template <class T> T as(bool& success) { // forcer une spécialisation static_assert(fail<T>::value, ""); } }; template <> template <> int Element<MySQL>::as<int>(bool& success) { ... }
Ainsi l'ajout d'un type ne se résume qu'a ajouter une spécialisation pour l'utilisateur. Et avec une spécialisation partielle tu peux avoir une spécialisation pour plusieurs types.
Je n'aime pas trop cette solution car l'utilisateur indique le type de base de donnée qu'il souhaite utiliser à l'ouverture de celle-ci ou défini le type de base de donnée par défaut à utiliser.
Mais ensuite, il ne doit plus y toucher.

Si je dois faire une classe Element template selon le type de base de donnée, je vais devoir faire de même pour toutes mes autres classes d'accès à la base de données :aie:

L'utilisateur va donc avoir accès en permanence au type de la base de donnée utilisée alors qu'il ne devrait pas, ce qui enlève tout l'intérêt de l'encapsulation de ces bases de données.

Citation:

Envoyé par Neckara

En fait cela risque de dépendre de l'utilisateur et de ce qu'il stocke dans sa base de donnée.
Je ne peux pas être sûr de faire tous les types nécessaire si par exemple il a stocké un objet en champ de bit dans la base de données (dans ce cas là, un reinterpret_cast<> pourrait être possible (?) ).

Tu peux prendre en compte les types de bases avec des fonctions non template asInt(), asFloat etc...
et fournir une méthode unsigned char *asRawData() pour les types utilisateurs, charge à l'utilisateur après de créer l'objet à partir de ça.
Code:

1 2 3 4 5 6 7 8 9 10 11 Element *elt = /* ... */; // au lieu d'avoir struct UserType { /* ... */ }; UserType obj(elt->as<UserType>()); // on aurait struct UserType { UserType(unsigned char *rawData) { /* ... */ } }; UserType obj(elt->asRawData());
Bref transférer la logique de la fonction "as" vers les constructeurs des types non pris en charges de base.
-> le contrôle d'erreurs si le type n'est pas bon est lui aussi divisé en plusieurs endroits, mais les exceptions peuvent résoudre ce problème.

Si tu as peu d'implémentations, tu peux faire un truc un peu moche et pénible à faire évoluer (impossible d'ajouter une implémentation après coup sans modifier l'interface) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
class db_impl {
public :
    virtual ~db_impl() {}
 
    // Toute l'interface qui peut être partagée entre deux implémentations
}
 
class db_mysql : public db_impl {
public :
 
    template<typename T>
    T as (unsigned int i) {
        // Implémentation MySQL
    }
}
 
class db_pqxx : public db_impl {
public :
 
    template<typename T>
    T as (unsigned int i) {
        // Implémentation pqxx
    }
}
 
// ...
 
enum db_type {
    mysql,
    pqxx,
    // ...
};
 
class db {
    std::unique_ptr<db_impl> impl;
    db_type type;
 
public :
 
    template<typename T>
    T as(unsigned int i) {
        switch (type) {
        case mysql : return dynamic_cast<db_mysql&>(*impl).as<T>(i);
        case pqxx  : return dynamic_cast<db_pqxx&>(*impl).as<T>(i);
        // ...
        }
    }
};

Un autre inconvénient est que l'appel à db.as<T>(i) doit compiler pour toutes les implémentations possibles, quelle que soit celle qui est effectivement utilisée.

05/02/2013, 10h02
Neckara

Bonjour,

Merci pour vos réponses.
Je pense utiliser la solution de Iradrille reprenant celle de white_tentacle et de jouana qui me semble être le plus intéressant.