J'ai des pb bizarres : dans une fonction j'ai besoin que l'utilisateur
me donne plusieurs infos, je fais donc des printf("question") et des scanf.
Sur les 3 premieres questions, ca marche bien, sur les 2 dernières, le
programme les affiche, mais le scanf ne semble pas marcher. Pourtant le
scanf recup sur les 5 fois un char *. C'est un bug? D'ailleurs si je ne
mets pas de \n sur le printf, parfois c'est encore pire...
voici un ex :
char *nom;
printf("nom\n");
scanf("%s", nom);
etc .. prenom, adress, tel, mail...
Parfois le scanf est comme sauté. Dans une autre fonction, je fais la
meme chose : une question, une reponse. Il m'affiche bien la question,
mais le scanf comme s'il était inactif, le programme ne me laisse pas
répondre, et passe à l'instruction suivante...
|> Formater des donnees de maniere generique quelque soit le format |> (inclus binaire, xdr, texte et texte structure) avec la possibilite |> de l'etendre facilement, avec (presque) aucun couplage entre les |> classes de donnees et les classes de formatage pour avoir la |> possibilite d'introduire de nouveaux formats pour une classe 'data' |> sans toucher a cette derniere.
En fait, tout faire. À la rigueur, je n'ai plus besoin d'autre code.
Exactement. Et c'est ce dont j'avais besoin. Une fois les formats des types basic + string + date effectues pour des styles de reference, il y a un minimum de travail a fournir pour le reste. Notament parce que plus l'objet est complexe plus j'utilise l'intropsection de objet via la reflection. Je n'ai donc plus qu'a ecrire du code lorque la structure de l'entree/sortie change, c'est a dire quelque chose de haut niveau.
|> Si je prends l'exemple des IOStream du C++, autant je trouve que les |> couches existantes du C (transport, buffering & low-level |> formatting) ont bien ete classerisees (structurees en classes, je |> sais pas ce qu'on doit dire ;-)) autant je trouve que cote |> *formatage* il n'y a aucune inovation et l'ensemble reste tres |> statique et complexe.
Encore, tout dépend ce qu'on a à faire. Dans l'ensemble, je suis d'accord avec ton évalutation, mais j'ai eu des cas aussi où les iostream était la solution parfaite.
Je n'ai pas dit le contraire. Mais avec un peu de poudre magique, les IOStream pourraient justement tout faire. Il manque une brique dans le design: les StreamStyle. Note que les formats existes sous forme restreinte: ce sont les manipulator & facet mais ils sont un peut statique (meme les user-defined doivent suivent des regles tres strictes). En les generalisant + les StreamStyles (pour decoupler class <-> format) tu n'as plus de limite du au design (en tout cas je n'en ai pas trouve). Je ne sais pas si c'est simple a faire en C++, notament a inclure dans les IOStream, je n'ai jamais essaye. Mais c'est la lecture du livre sur les IOStream & Locales qui m'a donne l'idee de ce design, simplement en generalisant la combinaison iword/pword (StyleStream) et les manipulator (Format).
a+, ld.
James Kanze wrote:
|> Formater des donnees de maniere generique quelque soit le format
|> (inclus binaire, xdr, texte et texte structure) avec la possibilite
|> de l'etendre facilement, avec (presque) aucun couplage entre les
|> classes de donnees et les classes de formatage pour avoir la
|> possibilite d'introduire de nouveaux formats pour une classe 'data'
|> sans toucher a cette derniere.
En fait, tout faire. À la rigueur, je n'ai plus besoin d'autre code.
Exactement. Et c'est ce dont j'avais besoin. Une fois les formats des
types basic + string + date effectues pour des styles de reference, il y
a un minimum de travail a fournir pour le reste. Notament parce que plus
l'objet est complexe plus j'utilise l'intropsection de objet via la
reflection. Je n'ai donc plus qu'a ecrire du code lorque la structure de
l'entree/sortie change, c'est a dire quelque chose de haut niveau.
|> Si je prends l'exemple des IOStream du C++, autant je trouve que les
|> couches existantes du C (transport, buffering & low-level
|> formatting) ont bien ete classerisees (structurees en classes, je
|> sais pas ce qu'on doit dire ;-)) autant je trouve que cote
|> *formatage* il n'y a aucune inovation et l'ensemble reste tres
|> statique et complexe.
Encore, tout dépend ce qu'on a à faire. Dans l'ensemble, je suis
d'accord avec ton évalutation, mais j'ai eu des cas aussi où les
iostream était la solution parfaite.
Je n'ai pas dit le contraire. Mais avec un peu de poudre magique, les
IOStream pourraient justement tout faire. Il manque une brique dans le
design: les StreamStyle. Note que les formats existes sous forme
restreinte: ce sont les manipulator & facet mais ils sont un peut
statique (meme les user-defined doivent suivent des regles tres
strictes). En les generalisant + les StreamStyles (pour decoupler class
<-> format) tu n'as plus de limite du au design (en tout cas je n'en ai
pas trouve). Je ne sais pas si c'est simple a faire en C++, notament a
inclure dans les IOStream, je n'ai jamais essaye. Mais c'est la lecture
du livre sur les IOStream & Locales qui m'a donne l'idee de ce design,
simplement en generalisant la combinaison iword/pword (StyleStream) et
les manipulator (Format).
|> Formater des donnees de maniere generique quelque soit le format |> (inclus binaire, xdr, texte et texte structure) avec la possibilite |> de l'etendre facilement, avec (presque) aucun couplage entre les |> classes de donnees et les classes de formatage pour avoir la |> possibilite d'introduire de nouveaux formats pour une classe 'data' |> sans toucher a cette derniere.
En fait, tout faire. À la rigueur, je n'ai plus besoin d'autre code.
Exactement. Et c'est ce dont j'avais besoin. Une fois les formats des types basic + string + date effectues pour des styles de reference, il y a un minimum de travail a fournir pour le reste. Notament parce que plus l'objet est complexe plus j'utilise l'intropsection de objet via la reflection. Je n'ai donc plus qu'a ecrire du code lorque la structure de l'entree/sortie change, c'est a dire quelque chose de haut niveau.
|> Si je prends l'exemple des IOStream du C++, autant je trouve que les |> couches existantes du C (transport, buffering & low-level |> formatting) ont bien ete classerisees (structurees en classes, je |> sais pas ce qu'on doit dire ;-)) autant je trouve que cote |> *formatage* il n'y a aucune inovation et l'ensemble reste tres |> statique et complexe.
Encore, tout dépend ce qu'on a à faire. Dans l'ensemble, je suis d'accord avec ton évalutation, mais j'ai eu des cas aussi où les iostream était la solution parfaite.
Je n'ai pas dit le contraire. Mais avec un peu de poudre magique, les IOStream pourraient justement tout faire. Il manque une brique dans le design: les StreamStyle. Note que les formats existes sous forme restreinte: ce sont les manipulator & facet mais ils sont un peut statique (meme les user-defined doivent suivent des regles tres strictes). En les generalisant + les StreamStyles (pour decoupler class <-> format) tu n'as plus de limite du au design (en tout cas je n'en ai pas trouve). Je ne sais pas si c'est simple a faire en C++, notament a inclure dans les IOStream, je n'ai jamais essaye. Mais c'est la lecture du livre sur les IOStream & Locales qui m'a donne l'idee de ce design, simplement en generalisant la combinaison iword/pword (StyleStream) et les manipulator (Format).
a+, ld.
Gabriel Dos Reis
James Kanze writes:
| Emmanuel Delahaye writes: | | |> James Kanze wrote on 13/11/04 : | |> > Je te donne une implémentation qui remplit toutes tes exigeances : | | |> > void | |> > format( void* ) | |> > { | |> > } | | |> > C'est simple, flexible, robuste et on ne peut plus rapide. | | |> Ne compile pas. Il manque le nom du paramètre. | | Il faut le nom du paramètre ?
Oui. Cela a toujours été le cas. Depuis toujours.
-- Gaby
James Kanze <james.kanze@free.fr> writes:
| Emmanuel Delahaye <emdel@YOURBRAnoos.fr> writes:
|
| |> James Kanze wrote on 13/11/04 :
| |> > Je te donne une implémentation qui remplit toutes tes exigeances :
|
| |> > void
| |> > format( void* )
| |> > {
| |> > }
|
| |> > C'est simple, flexible, robuste et on ne peut plus rapide.
|
| |> Ne compile pas. Il manque le nom du paramètre.
|
| Il faut le nom du paramètre ?
| Emmanuel Delahaye writes: | | |> James Kanze wrote on 13/11/04 : | |> > Je te donne une implémentation qui remplit toutes tes exigeances : | | |> > void | |> > format( void* ) | |> > { | |> > } | | |> > C'est simple, flexible, robuste et on ne peut plus rapide. | | |> Ne compile pas. Il manque le nom du paramètre. | | Il faut le nom du paramètre ?
