sous ce titre confus se cache un probl=E8me qui l'est tout autant pour
moi, et ma faible exp=E9rience du c++ (je ne pratique pas assez) fait que
je n'arrive pas =E0 trouver le vocabulaire ad=E9quat.
Mon probl=E8me est le suivant : je souhaite r=E9aliser un ensemble de
classes qui vont me permettre de lire un fichier de configuration (texte
simple, avec une syntaxe classique variable=3Dvaleur) et de typer les
variables rencontr=E9es dans le fichier en fonction de certains
param=E8tres. Ces param=E8tres se trouveraient dans un second fichier dont
les lignes seraient de la forme variable=3Dtype (avec type choisi dans une
liste fixe).
Dans le programme, le but est d'obtenir une syntaxe la plus simple
possible de style :
configuration* c =3D new configuration(fichier_config, fichier_params);
// exemple pour un entier quelconque, "nom_de_l_entier" est
// le nom de la variable dans le fichier de config
int entier_quelconque =3D c["nom_de_l_entier"];
Fort na=EFvement, et n'ayant pas bien compris les templates j'avais
commenc=E9 =E0 cr=E9er une version de d=E9mo en d=E9finissant une
std::map<std::string, config_value<T>* > et une classe config_value
d=E9finie comme suit :
template <class T> class config_value
{
T value;
public:
config_value(T& t) : value(t) {}
}
Maintenant que j'ai bien relu le chapitre sur les templates, je me rend
compte de l'absurdit=E9 de ce syst=E8me, ne tapez pas. Cependant je tiens
toujours =E0 la simplicit=E9 d'utilisation d=E9crite plus haut, mais je
n'arrive pas =E0 trouver de syst=E8me qui me permette de stocker dans une
std::map des types h=E9t=E9rog=E8nes, ou qui au moins sont per=E7us comme
h=E9t=E9rog=E8nes par les utilisateurs de la classe.
Bref, existe-t-il une solution =E0 ce probl=E8me ou dois-je me rabattre sur
une solution de repli moins pratique ?
Tout dépend du contexte ; pour des données de configuration, tu as probablement pas tort, d'autant plus que ça donne une possibilité de renvoyer une erreur. (Note que dans l'implémentation classique, au moins deux erreurs sont possible : on ne trouve pas le paramètre, et le paramètre n'a pas le bon type. Que typiquement, il faut distinguer entre les deux, et que puisqu'il s'agit des données fournies par l'utilisateur, c'est difficile à dire qu'une erreur serait un fait « exceptionnel », pour justifier des exceptions.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
drkm wrote:
kanze@gabi-soft.fr writes:
Alternativement, il faut que l'utilisateur spécifie le type dans
le
nom de la fonction, par exemple :
std::string opt1 = Configuration::instance().get< std::string >(
"opt1" ) ;
int opt2 = Configuration::instance().get< int >( "opt2" ) ;
// etc.
Je trouve intéressant d'utiliser ici un argument destiné à
recevoir
Tout dépend du contexte ; pour des données de configuration, tu as
probablement pas tort, d'autant plus que ça donne une possibilité de
renvoyer une erreur. (Note que dans l'implémentation classique, au
moins
deux erreurs sont possible : on ne trouve pas le paramètre, et le
paramètre n'a pas le bon type. Que typiquement, il faut distinguer
entre
les deux, et que puisqu'il s'agit des données fournies par
l'utilisateur, c'est difficile à dire qu'une erreur serait un fait
« exceptionnel », pour justifier des exceptions.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Tout dépend du contexte ; pour des données de configuration, tu as probablement pas tort, d'autant plus que ça donne une possibilité de renvoyer une erreur. (Note que dans l'implémentation classique, au moins deux erreurs sont possible : on ne trouve pas le paramètre, et le paramètre n'a pas le bon type. Que typiquement, il faut distinguer entre les deux, et que puisqu'il s'agit des données fournies par l'utilisateur, c'est difficile à dire qu'une erreur serait un fait « exceptionnel », pour justifier des exceptions.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
drkm wrote:
writes:
Alternativement, il faut que l'utilisateur spécifie le type dans le
nom de la fonction, par exemple :
std::string opt1 = Configuration::instance().get< std::string >( "opt1" ) ; int opt2 = Configuration::instance().get< int >( "opt2" ) ; // etc.
Je trouve intéressant d'utiliser ici un argument destiné à recevoir
Tout dépend du contexte ; pour des données de configuration, tu as probablement pas tort, d'autant plus que ça donne une possibilité de renvoyer une erreur. (Note que dans l'implémentation classique, au moins deux erreurs sont possible : on ne trouve pas le paramètre, et le paramètre n'a pas le bon type. Que typiquement, il faut distinguer entre les deux, et que puisqu'il s'agit des données fournies par l'utilisateur, c'est difficile à dire qu'une erreur serait un fait « exceptionnel », pour justifier des exceptions.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
drkm wrote:
kanze@gabi-soft.fr writes:
Alternativement, il faut que l'utilisateur spécifie le type dans
le
nom de la fonction, par exemple :
std::string opt1 = Configuration::instance().get< std::string >(
"opt1" ) ;
int opt2 = Configuration::instance().get< int >( "opt2" ) ;
// etc.
Je trouve intéressant d'utiliser ici un argument destiné à
recevoir
Tout dépend du contexte ; pour des données de configuration, tu as
probablement pas tort, d'autant plus que ça donne une possibilité de
renvoyer une erreur. (Note que dans l'implémentation classique, au
moins
deux erreurs sont possible : on ne trouve pas le paramètre, et le
paramètre n'a pas le bon type. Que typiquement, il faut distinguer
entre
les deux, et que puisqu'il s'agit des données fournies par
l'utilisateur, c'est difficile à dire qu'une erreur serait un fait
« exceptionnel », pour justifier des exceptions.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Tout dépend du contexte ; pour des données de configuration, tu as probablement pas tort, d'autant plus que ça donne une possibilité de renvoyer une erreur. (Note que dans l'implémentation classique, au moins deux erreurs sont possible : on ne trouve pas le paramètre, et le paramètre n'a pas le bon type. Que typiquement, il faut distinguer entre les deux, et que puisqu'il s'agit des données fournies par l'utilisateur, c'est difficile à dire qu'une erreur serait un fait « exceptionnel », pour justifier des exceptions.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34