J'aimerai stocker des données dans un executables, de type CSV.
Pour le moment, je fais un bete (en gros)
std::wstring Datas=
L"xx;xxx\r\n"
L"xx;xxx\r\n"
L"xx;xxx";
(et je parse ensuite le CSV, la n'est pas le probleme)
Mais j'aimerai pourvoir avoir ce texte dans un fichier a part (dans mon
cas, pour pouvoir les travailler dans un tableur)
J'ai en tete que deux possibilités qui ne me conviennent pas :
- une ressource attachée, mais ce n'est pas portable (Windows uniquement )
- un fichier texte chargé au demarage, mais ma bibliotheque (DLL ou SO)
doit etre auto-suffisante, donc pas de fichiers a coté possible
Donc : comment faire pour pouvoir avoir le texte inclu dans l'executable?
Le fichier devrait etre du type :
xx;xxx
xx;xxx
xx;xxx
(les L" devrait etre viré, et le \r\n mi en code equivalent, bref etre
lisible par un tableur :) )
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Loïc Joly
J'aimerai stocker des données dans un executables, de type CSV. Pour le moment, je fais un bete (en gros) std::wstring Datas > L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx"; (et je parse ensuite le CSV, la n'est pas le probleme)
Mais j'aimerai pourvoir avoir ce texte dans un fichier a part (dans mon cas, pour pouvoir les travailler dans un tableur)
J'ai en tete que deux possibilités qui ne me conviennent pas : - une ressource attachée, mais ce n'est pas portable (Windows uniquement )
Il me semble que Qt fourni un système de ressources portable. Après, faut voir si les licenses te conviennent.
-- Loïc
J'aimerai stocker des données dans un executables, de type CSV.
Pour le moment, je fais un bete (en gros)
std::wstring Datas > L"xx;xxxrn"
L"xx;xxxrn"
L"xx;xxx";
(et je parse ensuite le CSV, la n'est pas le probleme)
Mais j'aimerai pourvoir avoir ce texte dans un fichier a part (dans mon
cas, pour pouvoir les travailler dans un tableur)
J'ai en tete que deux possibilités qui ne me conviennent pas :
- une ressource attachée, mais ce n'est pas portable (Windows uniquement )
Il me semble que Qt fourni un système de ressources portable. Après,
faut voir si les licenses te conviennent.
J'aimerai stocker des données dans un executables, de type CSV. Pour le moment, je fais un bete (en gros) std::wstring Datas > L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx"; (et je parse ensuite le CSV, la n'est pas le probleme)
Mais j'aimerai pourvoir avoir ce texte dans un fichier a part (dans mon cas, pour pouvoir les travailler dans un tableur)
J'ai en tete que deux possibilités qui ne me conviennent pas : - une ressource attachée, mais ce n'est pas portable (Windows uniquement )
Il me semble que Qt fourni un système de ressources portable. Après, faut voir si les licenses te conviennent.
-- Loïc
Martinez Jerome
Loïc Joly wrote:
Il me semble que Qt fourni un système de ressources portable. Après, faut voir si les licenses te conviennent.
D'une la licence Qt ne me convient pas (certes mon soft est GPL, mais j'aime garder le controle sur la licence que j'utilise, c'est un choix :) ), et de deux installer Qt juste pour ca, gloups :) (j'utilise wxWidgets, raté :( )
Snif, pas une bonne solution pour moi :(
Loïc Joly wrote:
Il me semble que Qt fourni un système de ressources portable. Après,
faut voir si les licenses te conviennent.
D'une la licence Qt ne me convient pas (certes mon soft est GPL, mais
j'aime garder le controle sur la licence que j'utilise, c'est un choix
:) ), et de deux installer Qt juste pour ca, gloups :)
(j'utilise wxWidgets, raté :( )
Il me semble que Qt fourni un système de ressources portable. Après, faut voir si les licenses te conviennent.
D'une la licence Qt ne me convient pas (certes mon soft est GPL, mais j'aime garder le controle sur la licence que j'utilise, c'est un choix :) ), et de deux installer Qt juste pour ca, gloups :) (j'utilise wxWidgets, raté :( )
Snif, pas une bonne solution pour moi :(
Stan
"Martinez Jerome"
a écrit dans le message de news: df6qd0$
J'aimerai stocker des données dans un executables, de type CSV. Pour le moment, je fais un bete (en gros) std::wstring Datas > L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx"; (et je parse ensuite le CSV, la n'est pas le probleme) ...
Je ne suis pas certain d'avoir compris ton pb. Dis moi si je me trompe. Tu veux un fichier source ( ou de ressource ) qui, une fois compilé, soit dans l'excécutable. Cependant, pour le manipuler, tu souhaites qu'il soit au format csv. Si c'est le cas, je ne vois que la solution d'un petit script ( genre awk ) qui te convertisses ton csv en .cpp ( par exemple en créant un const char[] = "..." ).
Ais-je bien compris le pb initial ?
-- -Stan
"Martinez Jerome"
<je_ro_me.ma_rt_in_ez@xxxfrancetelecomxxx.supprimerlesxxxet_.xxxcom.invalid>
a écrit dans le message de news: df6qd0$loa1@news.rd.francetelecom.fr...
J'aimerai stocker des données dans un executables, de type CSV.
Pour le moment, je fais un bete (en gros)
std::wstring Datas > L"xx;xxxrn"
L"xx;xxxrn"
L"xx;xxx";
(et je parse ensuite le CSV, la n'est pas le probleme)
...
Je ne suis pas certain d'avoir compris ton pb.
Dis moi si je me trompe.
Tu veux un fichier source ( ou de ressource ) qui, une fois
compilé, soit dans l'excécutable.
Cependant, pour le manipuler, tu souhaites qu'il soit au format csv.
Si c'est le cas, je ne vois que la solution d'un petit script ( genre awk )
qui
te convertisses ton csv en .cpp ( par exemple en créant un const char[] =
"..." ).
J'aimerai stocker des données dans un executables, de type CSV. Pour le moment, je fais un bete (en gros) std::wstring Datas > L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx"; (et je parse ensuite le CSV, la n'est pas le probleme) ...
Je ne suis pas certain d'avoir compris ton pb. Dis moi si je me trompe. Tu veux un fichier source ( ou de ressource ) qui, une fois compilé, soit dans l'excécutable. Cependant, pour le manipuler, tu souhaites qu'il soit au format csv. Si c'est le cas, je ne vois que la solution d'un petit script ( genre awk ) qui te convertisses ton csv en .cpp ( par exemple en créant un const char[] = "..." ).
Ais-je bien compris le pb initial ?
-- -Stan
Marc Boyer
Le 02-09-2005, Stan a écrit :
"Martinez Jerome"
J'aimerai stocker des données dans un executables, de type CSV. Pour le moment, je fais un bete (en gros) std::wstring Datas >> L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx"; (et je parse ensuite le CSV, la n'est pas le probleme) ...
Je ne suis pas certain d'avoir compris ton pb. Dis moi si je me trompe. Tu veux un fichier source ( ou de ressource ) qui, une fois compilé, soit dans l'excécutable. Cependant, pour le manipuler, tu souhaites qu'il soit au format csv. Si c'est le cas, je ne vois que la solution d'un petit script ( genre awk ) qui te convertisses ton csv en .cpp ( par exemple en créant un const char[] = "..." ).
On peut compliquer un peu cette solution avec un #include.
Data.csv: xx;xxx xx;xxx
Data.rc: généré avec sed/awk L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx";
Et dans le fichier .cpp std::strings Datas #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Le 02-09-2005, Stan <z.y.l.o.g@wanadoo.fr> a écrit :
J'aimerai stocker des données dans un executables, de type CSV.
Pour le moment, je fais un bete (en gros)
std::wstring Datas >> L"xx;xxxrn"
L"xx;xxxrn"
L"xx;xxx";
(et je parse ensuite le CSV, la n'est pas le probleme)
...
Je ne suis pas certain d'avoir compris ton pb.
Dis moi si je me trompe.
Tu veux un fichier source ( ou de ressource ) qui, une fois
compilé, soit dans l'excécutable.
Cependant, pour le manipuler, tu souhaites qu'il soit au format csv.
Si c'est le cas, je ne vois que la solution d'un petit script ( genre awk )
qui
te convertisses ton csv en .cpp ( par exemple en créant un const char[] =
"..." ).
On peut compliquer un peu cette solution avec un #include.
Data.csv:
xx;xxx
xx;xxx
Data.rc: généré avec sed/awk
L"xx;xxxrn"
L"xx;xxxrn"
L"xx;xxx";
Et dans le fichier .cpp
std::strings Datas #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?
J'aimerai stocker des données dans un executables, de type CSV. Pour le moment, je fais un bete (en gros) std::wstring Datas >> L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx"; (et je parse ensuite le CSV, la n'est pas le probleme) ...
Je ne suis pas certain d'avoir compris ton pb. Dis moi si je me trompe. Tu veux un fichier source ( ou de ressource ) qui, une fois compilé, soit dans l'excécutable. Cependant, pour le manipuler, tu souhaites qu'il soit au format csv. Si c'est le cas, je ne vois que la solution d'un petit script ( genre awk ) qui te convertisses ton csv en .cpp ( par exemple en créant un const char[] = "..." ).
On peut compliquer un peu cette solution avec un #include.
Data.csv: xx;xxx xx;xxx
Data.rc: généré avec sed/awk L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx";
Et dans le fichier .cpp std::strings Datas #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Stan
"Marc Boyer" a écrit dans le message de news:
Et dans le fichier .cpp std::strings Datas > #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Marc Boyer --
Perso, cela ne me géne pas de générer un .cpp avec script. Quand tu parles de manipuler, cela signifie sans doute que le dit source contient autre chose ? Mais dans le cas présent, j'utiliserais un seul fichier pour cette "variable".
-- -Stan
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrndhg6vf.bfc.Marc.Boyer@localhost.localdomain...
Et dans le fichier .cpp
std::strings Datas > #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Marc Boyer
--
Perso, cela ne me géne pas de générer un .cpp avec script.
Quand tu parles de manipuler, cela signifie sans doute que le dit
source contient autre chose ?
Mais dans le cas présent, j'utiliserais un seul fichier pour cette
"variable".
Et dans le fichier .cpp std::strings Datas > #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Marc Boyer --
Perso, cela ne me géne pas de générer un .cpp avec script. Quand tu parles de manipuler, cela signifie sans doute que le dit source contient autre chose ? Mais dans le cas présent, j'utiliserais un seul fichier pour cette "variable".
-- -Stan
Marc Boyer
Le 02-09-2005, Stan a écrit :
"Marc Boyer" a écrit dans le message de news:
Et dans le fichier .cpp std::strings Datas >> #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Perso, cela ne me géne pas de générer un .cpp avec script. Quand tu parles de manipuler, cela signifie sans doute que le dit source contient autre chose ?
Oui.
Mais dans le cas présent, j'utiliserais un seul fichier pour cette "variable".
Dans ce cas, en effet, passer par un fichier intermédiaire n'a pas beaucoup de sens (hormis le fait de laisser le nom et le type de la chaine dans un .cpp et pas dans un script sed/awk). Après, un fichier pour contenir une seule variable de config, je ne sais pas si c'est une bonne idée, mais je ne suis pas spécialiste de la gestion des fichiers de config.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Le 02-09-2005, Stan <z.y.l.o.g@wanadoo.fr> a écrit :
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrndhg6vf.bfc.Marc.Boyer@localhost.localdomain...
Et dans le fichier .cpp
std::strings Datas >> #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Perso, cela ne me géne pas de générer un .cpp avec script.
Quand tu parles de manipuler, cela signifie sans doute que le dit
source contient autre chose ?
Oui.
Mais dans le cas présent, j'utiliserais un seul fichier pour cette
"variable".
Dans ce cas, en effet, passer par un fichier intermédiaire n'a pas
beaucoup de sens (hormis le fait de laisser le nom et le type
de la chaine dans un .cpp et pas dans un script sed/awk).
Après, un fichier pour contenir une seule variable de config,
je ne sais pas si c'est une bonne idée, mais je ne suis pas
spécialiste de la gestion des fichiers de config.
Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?
Et dans le fichier .cpp std::strings Datas >> #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Perso, cela ne me géne pas de générer un .cpp avec script. Quand tu parles de manipuler, cela signifie sans doute que le dit source contient autre chose ?
Oui.
Mais dans le cas présent, j'utiliserais un seul fichier pour cette "variable".
Dans ce cas, en effet, passer par un fichier intermédiaire n'a pas beaucoup de sens (hormis le fait de laisser le nom et le type de la chaine dans un .cpp et pas dans un script sed/awk). Après, un fichier pour contenir une seule variable de config, je ne sais pas si c'est une bonne idée, mais je ne suis pas spécialiste de la gestion des fichiers de config.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
kanze
Marc Boyer wrote:
"Martinez Jerome" lid>
J'aimerai stocker des données dans un executables, de type CSV. Pour le moment, je fais un bete (en gros) std::wstring Datas= L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx"; (et je parse ensuite le CSV, la n'est pas le probleme) ...
Je ne suis pas certain d'avoir compris ton pb. Dis moi si je me trompe. Tu veux un fichier source ( ou de ressource ) qui, une fois compilé, soit dans l'excécutable. Cependant, pour le manipuler, tu souhaites qu'il soit au format csv. Si c'est le cas, je ne vois que la solution d'un petit script ( genre awk ) qui te convertisses ton csv en .cpp ( par exemple en créant un const char[] = "..." ).
On peut compliquer un peu cette solution avec un #include.
Data.csv: xx;xxx xx;xxx
Data.rc: généré avec sed/awk L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx";
Et dans le fichier .cpp std::strings Datas= #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Et L"xx;xxxrn" n'est pas du .cpp.
L'avantage que je vois (ici) dans l'include, c'est que le script peut être assez générique, sans connaitre le nom de la variable, par exemple. Mais la plupart du temps, au moins chez moi, de tels scripts génère des struct propre à l'application. Alors, je ne vois pas l'intérêt de faire que le script ne connaît pas le nom de la variable, quand il est obligé à connaître des structures, etc.
Ici, il faut aussi se poser la question s'il ne vaudrait pas mieux que le script (AWK) et le compilateur fasse le parse directement. AWK sait déjà séparer les lignes d'un fichier CVS en champs. Si toutes les lignes ont le même format, le corps du programme AWK devient simplement :
J'aimerai stocker des données dans un executables, de type CSV.
Pour le moment, je fais un bete (en gros)
std::wstring Datas=
L"xx;xxxrn"
L"xx;xxxrn"
L"xx;xxx";
(et je parse ensuite le CSV, la n'est pas le probleme)
...
Je ne suis pas certain d'avoir compris ton pb. Dis moi si je
me trompe. Tu veux un fichier source ( ou de ressource )
qui, une fois compilé, soit dans l'excécutable. Cependant,
pour le manipuler, tu souhaites qu'il soit au format csv. Si
c'est le cas, je ne vois que la solution d'un petit script (
genre awk ) qui te convertisses ton csv en .cpp ( par
exemple en créant un const char[] = "..." ).
On peut compliquer un peu cette solution avec un #include.
Data.csv:
xx;xxx
xx;xxx
Data.rc: généré avec sed/awk
L"xx;xxxrn"
L"xx;xxxrn"
L"xx;xxx";
Et dans le fichier .cpp
std::strings Datas=
#include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Et L"xx;xxxrn" n'est pas du .cpp.
L'avantage que je vois (ici) dans l'include, c'est que le script
peut être assez générique, sans connaitre le nom de la variable,
par exemple. Mais la plupart du temps, au moins chez moi, de
tels scripts génère des struct propre à l'application. Alors, je
ne vois pas l'intérêt de faire que le script ne connaît pas le
nom de la variable, quand il est obligé à connaître des
structures, etc.
Ici, il faut aussi se poser la question s'il ne vaudrait pas
mieux que le script (AWK) et le compilateur fasse le parse
directement. AWK sait déjà séparer les lignes d'un fichier CVS
en champs. Si toutes les lignes ont le même format, le corps du
programme AWK devient simplement :
J'aimerai stocker des données dans un executables, de type CSV. Pour le moment, je fais un bete (en gros) std::wstring Datas= L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx"; (et je parse ensuite le CSV, la n'est pas le probleme) ...
Je ne suis pas certain d'avoir compris ton pb. Dis moi si je me trompe. Tu veux un fichier source ( ou de ressource ) qui, une fois compilé, soit dans l'excécutable. Cependant, pour le manipuler, tu souhaites qu'il soit au format csv. Si c'est le cas, je ne vois que la solution d'un petit script ( genre awk ) qui te convertisses ton csv en .cpp ( par exemple en créant un const char[] = "..." ).
On peut compliquer un peu cette solution avec un #include.
Data.csv: xx;xxx xx;xxx
Data.rc: généré avec sed/awk L"xx;xxxrn" L"xx;xxxrn" L"xx;xxx";
Et dans le fichier .cpp std::strings Datas= #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Et L"xx;xxxrn" n'est pas du .cpp.
L'avantage que je vois (ici) dans l'include, c'est que le script peut être assez générique, sans connaitre le nom de la variable, par exemple. Mais la plupart du temps, au moins chez moi, de tels scripts génère des struct propre à l'application. Alors, je ne vois pas l'intérêt de faire que le script ne connaît pas le nom de la variable, quand il est obligé à connaître des structures, etc.
Ici, il faut aussi se poser la question s'il ne vaudrait pas mieux que le script (AWK) et le compilateur fasse le parse directement. AWK sait déjà séparer les lignes d'un fichier CVS en champs. Si toutes les lignes ont le même format, le corps du programme AWK devient simplement :
Ensuite, le compilateur C++ convertit les valeurs numérique en format interne.
-- James Kanze GABI Software 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
Stan
a écrit dans le message de news:
Ici, il faut aussi se poser la question s'il ne vaudrait pas mieux que le script (AWK) et le compilateur fasse le parse directement. AWK sait déjà séparer les lignes d'un fichier CVS
Chez moi, il ne le sait pas, il faut lui dire ;-) BEGIN { FS=";" }
Sacré awk !
en champs. Si toutes les lignes ont le même format, le corps du programme AWK devient simplement :
-- -Stan
<kanze@gabi-soft.fr> a écrit dans le message de news:
1125668012.320774.219570@g49g2000cwa.googlegroups.com...
Ici, il faut aussi se poser la question s'il ne vaudrait pas
mieux que le script (AWK) et le compilateur fasse le parse
directement. AWK sait déjà séparer les lignes d'un fichier CVS
Chez moi, il ne le sait pas, il faut lui dire ;-)
BEGIN { FS=";" }
Sacré awk !
en champs. Si toutes les lignes ont le même format, le corps du
programme AWK devient simplement :
Ici, il faut aussi se poser la question s'il ne vaudrait pas mieux que le script (AWK) et le compilateur fasse le parse directement. AWK sait déjà séparer les lignes d'un fichier CVS
Chez moi, il ne le sait pas, il faut lui dire ;-) BEGIN { FS=";" }
Sacré awk !
en champs. Si toutes les lignes ont le même format, le corps du programme AWK devient simplement :
-- -Stan
James Kanze
Marc Boyer wrote:
"Marc Boyer" a écrit dans le message
de news:
Et dans le fichier .cpp std::strings Datas >>> #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Perso, cela ne me géne pas de générer un .cpp avec script. Quand tu parles de manipuler, cela signifie sans doute que le dit source contient autre chose ?
Oui.
Mais dans le cas présent, j'utiliserais un seul fichier pour cette "variable".
Peut-être. Mais dans le cas présent, il s'avère que les scripts pourraient avoir un intérêt générique (ce qui est rarement le cas).
Dans ce cas, en effet, passer par un fichier intermédiaire n'a pas beaucoup de sens (hormis le fait de laisser le nom et le type de la chaine dans un .cpp et pas dans un script sed/awk).
Mais c'est ici, c'est peut-être un avantage. Si j'ai une autre application, il se peut bien qu'elle ait besoin d'un tableau semblable, mais c'est beaucoup moin probable qu'elle veut le même nom de variable.
Évidemment, on pourrait aussi utiliser un script dans un script :
Après, un fichier pour contenir une seule variable de config, je ne sais pas si c'est une bonne idée, mais je ne suis pas spécialiste de la gestion des fichiers de config.
Tous dépend, et comme j'ai dit par ailleurs, c'est fort possible qu'il y a un intérêt à générer des structures plus complexes, tant qu'on y est. (Souvent, il est intéressant d'utiliser les agglomérés ici, plutôt que des collections de la STL, afin d'éviter des problèmes potentiels de l'ordre d'initialisation. N'oublions pas qu'une des caractèristiques de la STL, c'est que ses algorithmes peuvent s'appliquer aussi à des structures de base.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Marc Boyer wrote:
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le
message
de news: slrndhg6vf.bfc.Marc.Boyer@localhost.localdomain...
Et dans le fichier .cpp
std::strings Datas >>> #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Perso, cela ne me géne pas de générer un .cpp avec script.
Quand tu parles de manipuler, cela signifie sans doute que le dit
source contient autre chose ?
Oui.
Mais dans le cas présent, j'utiliserais un seul fichier pour
cette "variable".
Peut-être. Mais dans le cas présent, il s'avère que les scripts
pourraient avoir un intérêt générique (ce qui est rarement le
cas).
Dans ce cas, en effet, passer par un fichier intermédiaire
n'a pas beaucoup de sens (hormis le fait de laisser le nom et
le type de la chaine dans un .cpp et pas dans un script
sed/awk).
Mais c'est ici, c'est peut-être un avantage. Si j'ai une autre
application, il se peut bien qu'elle ait besoin d'un tableau
semblable, mais c'est beaucoup moin probable qu'elle veut le
même nom de variable.
Évidemment, on pourrait aussi utiliser un script dans un
script :
Après, un fichier pour contenir une seule variable de
config, je ne sais pas si c'est une bonne idée, mais je ne
suis pas spécialiste de la gestion des fichiers de config.
Tous dépend, et comme j'ai dit par ailleurs, c'est fort possible
qu'il y a un intérêt à générer des structures plus complexes,
tant qu'on y est. (Souvent, il est intéressant d'utiliser les
agglomérés ici, plutôt que des collections de la STL, afin
d'éviter des problèmes potentiels de l'ordre d'initialisation.
N'oublions pas qu'une des caractèristiques de la STL, c'est que
ses algorithmes peuvent s'appliquer aussi à des structures de
base.)
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Et dans le fichier .cpp std::strings Datas >>> #include "Data.rc"
Cela évite que le sed/awk manipule directement le .cpp.
Perso, cela ne me géne pas de générer un .cpp avec script. Quand tu parles de manipuler, cela signifie sans doute que le dit source contient autre chose ?
Oui.
Mais dans le cas présent, j'utiliserais un seul fichier pour cette "variable".
Peut-être. Mais dans le cas présent, il s'avère que les scripts pourraient avoir un intérêt générique (ce qui est rarement le cas).
Dans ce cas, en effet, passer par un fichier intermédiaire n'a pas beaucoup de sens (hormis le fait de laisser le nom et le type de la chaine dans un .cpp et pas dans un script sed/awk).
Mais c'est ici, c'est peut-être un avantage. Si j'ai une autre application, il se peut bien qu'elle ait besoin d'un tableau semblable, mais c'est beaucoup moin probable qu'elle veut le même nom de variable.
Évidemment, on pourrait aussi utiliser un script dans un script :
Après, un fichier pour contenir une seule variable de config, je ne sais pas si c'est une bonne idée, mais je ne suis pas spécialiste de la gestion des fichiers de config.
Tous dépend, et comme j'ai dit par ailleurs, c'est fort possible qu'il y a un intérêt à générer des structures plus complexes, tant qu'on y est. (Souvent, il est intéressant d'utiliser les agglomérés ici, plutôt que des collections de la STL, afin d'éviter des problèmes potentiels de l'ordre d'initialisation. N'oublions pas qu'une des caractèristiques de la STL, c'est que ses algorithmes peuvent s'appliquer aussi à des structures de base.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Stan wrote:
a écrit dans le message de news:
Ici, il faut aussi se poser la question s'il ne vaudrait pas mieux que le script (AWK) et le compilateur fasse le parse directement. AWK sait déjà séparer les lignes d'un fichier CVS
Chez moi, il ne le sait pas, il faut lui dire ;-) BEGIN { FS=";" }
Sacré awk !
Dans ce sens, il faut lui dire tout. N'empêche que si le fichier commence :
#! /usr/bin/awk -F ; -f
ça doit marcher.
Le vrai problème avec AWK, c'est qu'il existe plusieurs versions. Prèsque partout, on en a la version standard (POSIX), mais la façon de l'invoquer varie : awk (comme exigé par POSIX), nawk, gawk --posix...
J'utilise awk beaucoup dans mes fichiers de make, et j'ai bien été obligé à introduire une variable pour son invocation dans site.mk (un fichier include de tous les autres makefile, de façon à adapter le fichier à des particularités de l'installation locale).
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Stan wrote:
<kanze@gabi-soft.fr> a écrit dans le message de news:
1125668012.320774.219570@g49g2000cwa.googlegroups.com...
Ici, il faut aussi se poser la question s'il ne vaudrait pas
mieux que le script (AWK) et le compilateur fasse le parse
directement. AWK sait déjà séparer les lignes d'un fichier CVS
Chez moi, il ne le sait pas, il faut lui dire ;-)
BEGIN { FS=";" }
Sacré awk !
Dans ce sens, il faut lui dire tout. N'empêche que si le fichier
commence :
#! /usr/bin/awk -F ; -f
ça doit marcher.
Le vrai problème avec AWK, c'est qu'il existe plusieurs
versions. Prèsque partout, on en a la version standard (POSIX),
mais la façon de l'invoquer varie : awk (comme exigé par POSIX),
nawk, gawk --posix...
J'utilise awk beaucoup dans mes fichiers de make, et j'ai bien
été obligé à introduire une variable pour son invocation dans
site.mk (un fichier include de tous les autres makefile, de
façon à adapter le fichier à des particularités de
l'installation locale).
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Ici, il faut aussi se poser la question s'il ne vaudrait pas mieux que le script (AWK) et le compilateur fasse le parse directement. AWK sait déjà séparer les lignes d'un fichier CVS
Chez moi, il ne le sait pas, il faut lui dire ;-) BEGIN { FS=";" }
Sacré awk !
Dans ce sens, il faut lui dire tout. N'empêche que si le fichier commence :
#! /usr/bin/awk -F ; -f
ça doit marcher.
Le vrai problème avec AWK, c'est qu'il existe plusieurs versions. Prèsque partout, on en a la version standard (POSIX), mais la façon de l'invoquer varie : awk (comme exigé par POSIX), nawk, gawk --posix...
J'utilise awk beaucoup dans mes fichiers de make, et j'ai bien été obligé à introduire une variable pour son invocation dans site.mk (un fichier include de tous les autres makefile, de façon à adapter le fichier à des particularités de l'installation locale).
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34