Quelqu'un pourrait me dire pourquoi les boucle sont lentes ?
si je fait :
nIdFic est un entier
sMaChaîne est une chaîne
nIdFic = fOuvre("fichier de plusieurs méga", FOLectureEcriture)
SI nIdFic=-1 ALORS
Erreur("L'ouverture du fichier a échoué", ErreurInfo())
SINON
// Première ligne
sMaChaîne = fLitLigne(nIdFic)
TANTQUE sMaChaîne<>EOT
// Ligne suivante
sMaChaîne = fLitLigne(nIdFic)
FIN
// Fermeture du fichier
fFerme(nIdFic)
FIN
La boucle est lente comme toutes les autres boucles dans mes
programmes.
Es-tu certain que le fichier en question a bien un CR+LF en fin de chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où la lenteur...
Si cette hypothèse est vraie, tu dois utiliser fLit() avec une taille de bloc fixe, chercher le LF dans la chaine retournée, puis extraire toi-même la ligne souhaitée...
Michel Fages
Bonjour,
Es-tu certain que le fichier en question a bien un CR+LF en fin de
chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer
plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où
la lenteur...
Si cette hypothèse est vraie, tu dois utiliser fLit() avec une taille
de bloc fixe, chercher le LF dans la chaine retournée, puis extraire
toi-même la ligne souhaitée...
Es-tu certain que le fichier en question a bien un CR+LF en fin de chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où la lenteur...
Si cette hypothèse est vraie, tu dois utiliser fLit() avec une taille de bloc fixe, chercher le LF dans la chaine retournée, puis extraire toi-même la ligne souhaitée...
Michel Fages
VincentC
Vinii a formulé ce mardi :
Bonjour,
Quelqu'un pourrait me dire pourquoi les boucle sont lentes ?
si je fait : nIdFic est un entier sMaChaîne est une chaîne
nIdFic = fOuvre("fichier de plusieurs méga", FOLectureEcriture) SI nIdFic=-1 ALORS Erreur("L'ouverture du fichier a échoué", ErreurInfo()) SINON // Première ligne sMaChaîne = fLitLigne(nIdFic) TANTQUE sMaChaîne<>EOT // Ligne suivante sMaChaîne = fLitLigne(nIdFic) FIN
// Fermeture du fichier fFerme(nIdFic) FIN
La boucle est lente comme toutes les autres boucles dans mes programmes.
Merci pour vos sugestions
Vincent
Qu'est-ce qui est lent : l'accès au fichier (accès disque, taille du fichier) ? Le traitement que tu effectue sur chaque ligne ?
Je suppose que tu ne fais pas que SmaChaine = FlitLigne ...
Lent par rapport à quoi ?
Et pourquoi une ouverture en Lecture/Ecriture ?
J'utilise le même principe pour lire des fichiers textes et je ne trouve pas de lenteur excessive (sur l'accès fichier). la lenteur venait plutôt de l'insertion d'un enrg HF.
Cdt.
Vinii a formulé ce mardi :
Bonjour,
Quelqu'un pourrait me dire pourquoi les boucle sont lentes ?
si je fait :
nIdFic est un entier
sMaChaîne est une chaîne
nIdFic = fOuvre("fichier de plusieurs méga", FOLectureEcriture)
SI nIdFic=-1 ALORS
Erreur("L'ouverture du fichier a échoué", ErreurInfo())
SINON
// Première ligne
sMaChaîne = fLitLigne(nIdFic)
TANTQUE sMaChaîne<>EOT
// Ligne suivante
sMaChaîne = fLitLigne(nIdFic)
FIN
// Fermeture du fichier
fFerme(nIdFic)
FIN
La boucle est lente comme toutes les autres boucles dans mes programmes.
Merci pour vos sugestions
Vincent
Qu'est-ce qui est lent : l'accès au fichier (accès disque, taille du
fichier) ?
Le traitement que tu effectue sur chaque ligne ?
Je suppose que tu ne fais pas que SmaChaine = FlitLigne ...
Lent par rapport à quoi ?
Et pourquoi une ouverture en Lecture/Ecriture ?
J'utilise le même principe pour lire des fichiers textes et je ne
trouve pas de lenteur excessive (sur l'accès fichier). la lenteur
venait plutôt de l'insertion d'un enrg HF.
Quelqu'un pourrait me dire pourquoi les boucle sont lentes ?
si je fait : nIdFic est un entier sMaChaîne est une chaîne
nIdFic = fOuvre("fichier de plusieurs méga", FOLectureEcriture) SI nIdFic=-1 ALORS Erreur("L'ouverture du fichier a échoué", ErreurInfo()) SINON // Première ligne sMaChaîne = fLitLigne(nIdFic) TANTQUE sMaChaîne<>EOT // Ligne suivante sMaChaîne = fLitLigne(nIdFic) FIN
// Fermeture du fichier fFerme(nIdFic) FIN
La boucle est lente comme toutes les autres boucles dans mes programmes.
Merci pour vos sugestions
Vincent
Qu'est-ce qui est lent : l'accès au fichier (accès disque, taille du fichier) ? Le traitement que tu effectue sur chaque ligne ?
Je suppose que tu ne fais pas que SmaChaine = FlitLigne ...
Lent par rapport à quoi ?
Et pourquoi une ouverture en Lecture/Ecriture ?
J'utilise le même principe pour lire des fichiers textes et je ne trouve pas de lenteur excessive (sur l'accès fichier). la lenteur venait plutôt de l'insertion d'un enrg HF.
Cdt.
Christophe Charron
Vinii a écrit :
Bonjour,
Quelqu'un pourrait me dire pourquoi les boucle sont lentes ?
si je fait : nIdFic est un entier sMaChaîne est une chaîne
nIdFic = fOuvre("fichier de plusieurs méga", FOLectureEcriture) SI nIdFic=-1 ALORS Erreur("L'ouverture du fichier a échoué", ErreurInfo()) SINON // Première ligne sMaChaîne = fLitLigne(nIdFic) TANTQUE sMaChaîne<>EOT // Ligne suivante sMaChaîne = fLitLigne(nIdFic) FIN
// Fermeture du fichier fFerme(nIdFic) FIN
La boucle est lente comme toutes les autres boucles dans mes programmes.
Merci pour vos sugestions
Vincent
Bonjour, en l'espèce, fchargetexte sera peut-être plus approprié?
-- Cordialement Christophe Charron
PROLOGIQ 7 bis Rue des Aulnes 69410 Champagne au Mont d'Or
Tel : 0 437 499 107 Fax : 0 437 499 105 mailto:
Vinii a écrit :
Bonjour,
Quelqu'un pourrait me dire pourquoi les boucle sont lentes ?
si je fait :
nIdFic est un entier
sMaChaîne est une chaîne
nIdFic = fOuvre("fichier de plusieurs méga", FOLectureEcriture)
SI nIdFic=-1 ALORS
Erreur("L'ouverture du fichier a échoué", ErreurInfo())
SINON
// Première ligne
sMaChaîne = fLitLigne(nIdFic)
TANTQUE sMaChaîne<>EOT
// Ligne suivante
sMaChaîne = fLitLigne(nIdFic)
FIN
// Fermeture du fichier
fFerme(nIdFic)
FIN
La boucle est lente comme toutes les autres boucles dans mes programmes.
Merci pour vos sugestions
Vincent
Bonjour,
en l'espèce, fchargetexte sera peut-être plus approprié?
--
Cordialement
Christophe Charron
PROLOGIQ
7 bis Rue des Aulnes
69410 Champagne au Mont d'Or
Quelqu'un pourrait me dire pourquoi les boucle sont lentes ?
si je fait : nIdFic est un entier sMaChaîne est une chaîne
nIdFic = fOuvre("fichier de plusieurs méga", FOLectureEcriture) SI nIdFic=-1 ALORS Erreur("L'ouverture du fichier a échoué", ErreurInfo()) SINON // Première ligne sMaChaîne = fLitLigne(nIdFic) TANTQUE sMaChaîne<>EOT // Ligne suivante sMaChaîne = fLitLigne(nIdFic) FIN
// Fermeture du fichier fFerme(nIdFic) FIN
La boucle est lente comme toutes les autres boucles dans mes programmes.
Merci pour vos sugestions
Vincent
Bonjour, en l'espèce, fchargetexte sera peut-être plus approprié?
-- Cordialement Christophe Charron
PROLOGIQ 7 bis Rue des Aulnes 69410 Champagne au Mont d'Or
Tel : 0 437 499 107 Fax : 0 437 499 105 mailto:
Vinii
MiF a exposé le 04/04/2006 :
Bonjour,
Es-tu certain que le fichier en question a bien un CR+LF en fin de chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où la lenteur...
Si cette hypothèse est vraie, tu dois utiliser fLit() avec une taille de bloc fixe, chercher le LF dans la chaine retournée, puis extraire toi-même la ligne souhaitée...
Michel Fages
Salut,
effectivement mon fichier est unix, mais c'est pas le pb, j'ai utilisé un fichier comme j'aurais pu utiliser autre chose par exemple :
i est un entier s est une chaîne hd, hf, dif sont des Heures hd = HeureSys() POUR i = 0 A 1000000 s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" FIN Multitâche(-1) hf = HeureSys() dif = HeureDifférence(hd, hf) Info(dif) // resultat environ 12 secondes
De 12 à 14 secondes traitement !!!
PS le fichier du premier test : j'ai essayé de l'ouvrir comme suit : nIdFic = fOuvre("mon gros fichier", foLecture) et de le lire : sMaChaîne = fLit(nIdFic, 78)
même lenteur
MiF a exposé le 04/04/2006 :
Bonjour,
Es-tu certain que le fichier en question a bien un CR+LF en fin de
chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer
plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où
la lenteur...
Si cette hypothèse est vraie, tu dois utiliser fLit() avec une taille
de bloc fixe, chercher le LF dans la chaine retournée, puis extraire
toi-même la ligne souhaitée...
Michel Fages
Salut,
effectivement mon fichier est unix, mais c'est pas le pb,
j'ai utilisé un fichier comme j'aurais pu utiliser autre chose par
exemple :
i est un entier
s est une chaîne
hd, hf, dif sont des Heures
hd = HeureSys()
POUR i = 0 A 1000000
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
s = "123"
FIN
Multitâche(-1)
hf = HeureSys()
dif = HeureDifférence(hd, hf)
Info(dif) // resultat environ 12 secondes
De 12 à 14 secondes traitement !!!
PS le fichier du premier test :
j'ai essayé de l'ouvrir comme suit :
nIdFic = fOuvre("mon gros fichier", foLecture)
et de le lire :
sMaChaîne = fLit(nIdFic, 78)
Es-tu certain que le fichier en question a bien un CR+LF en fin de chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où la lenteur...
Si cette hypothèse est vraie, tu dois utiliser fLit() avec une taille de bloc fixe, chercher le LF dans la chaine retournée, puis extraire toi-même la ligne souhaitée...
Michel Fages
Salut,
effectivement mon fichier est unix, mais c'est pas le pb, j'ai utilisé un fichier comme j'aurais pu utiliser autre chose par exemple :
i est un entier s est une chaîne hd, hf, dif sont des Heures hd = HeureSys() POUR i = 0 A 1000000 s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" s = "123" FIN Multitâche(-1) hf = HeureSys() dif = HeureDifférence(hd, hf) Info(dif) // resultat environ 12 secondes
De 12 à 14 secondes traitement !!!
PS le fichier du premier test : j'ai essayé de l'ouvrir comme suit : nIdFic = fOuvre("mon gros fichier", foLecture) et de le lire : sMaChaîne = fLit(nIdFic, 78)
même lenteur
Vinii
Dans son message précédent, MiF a écrit :
Bonjour,
Es-tu certain que le fichier en question a bien un CR+LF en fin de chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où la lenteur...
Si cette hypothèse est vraie, tu dois utiliser fLit() avec une taille de bloc fixe, chercher le LF dans la chaine retournée, puis extraire toi-même la ligne souhaitée...
Michel Fages
Pour info : je fait le même test en perl sur un fichier de 50M texte unix (le même fichier que pour mon test windev) il contient AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA sur 1000000 lignes
Lecture du fichier entient 1 seconde en perl et j'attend encore pour la lecture windev (j'ai pas eu la patience d'attendre)
Dans son message précédent, MiF a écrit :
Bonjour,
Es-tu certain que le fichier en question a bien un CR+LF en fin de
chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer
plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où
la lenteur...
Si cette hypothèse est vraie, tu dois utiliser fLit() avec une taille
de bloc fixe, chercher le LF dans la chaine retournée, puis extraire
toi-même la ligne souhaitée...
Michel Fages
Pour info :
je fait le même test en perl sur un fichier de 50M texte unix (le même
fichier que pour mon test windev) il contient
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
sur 1000000 lignes
Lecture du fichier entient 1 seconde en perl et j'attend encore
pour la lecture windev (j'ai pas eu la patience d'attendre)
Es-tu certain que le fichier en question a bien un CR+LF en fin de chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où la lenteur...
Si cette hypothèse est vraie, tu dois utiliser fLit() avec une taille de bloc fixe, chercher le LF dans la chaine retournée, puis extraire toi-même la ligne souhaitée...
Michel Fages
Pour info : je fait le même test en perl sur un fichier de 50M texte unix (le même fichier que pour mon test windev) il contient AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA sur 1000000 lignes
Lecture du fichier entient 1 seconde en perl et j'attend encore pour la lecture windev (j'ai pas eu la patience d'attendre)
Georges Peyre
Bonjour,
Il se trouve que MiF a formulé :
Es-tu certain que le fichier en question a bien un CR+LF en fin de chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où la lenteur...
A ce propos j'ai justement un problème posé par cette différence de fin de ligne.
Je dois lire des fichiers qui sont tantôt dans un format tantôt dans l'autre.
Quelque soit le fichier à lire je veux pouvoir transformer ou non ce fichier pour toujours obtenir un CR+LF
Comme déterminer qu'un fichier est au format unix ou non ?
Cordialement
-- Elle est pas belle la vie ?
Bonjour,
Il se trouve que MiF a formulé :
Es-tu certain que le fichier en question a bien un CR+LF en fin de
chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer
plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où
la lenteur...
A ce propos j'ai justement un problème posé par cette différence de fin
de ligne.
Je dois lire des fichiers qui sont tantôt dans un format tantôt dans
l'autre.
Quelque soit le fichier à lire je veux pouvoir transformer ou non ce
fichier pour toujours obtenir un CR+LF
Comme déterminer qu'un fichier est au format unix ou non ?
Es-tu certain que le fichier en question a bien un CR+LF en fin de chaque ligne (et non pas un LF seul comme certains fichiers Unix) ?
Si tu n'as pas de CR+LF sur chaque ligne, Windev doit alors allouer plusieurs megas de mémoire pour pouvoir exécuter le fLitLigne, d'où la lenteur...
A ce propos j'ai justement un problème posé par cette différence de fin de ligne.
Je dois lire des fichiers qui sont tantôt dans un format tantôt dans l'autre.
Quelque soit le fichier à lire je veux pouvoir transformer ou non ce fichier pour toujours obtenir un CR+LF
Comme déterminer qu'un fichier est au format unix ou non ?
Cordialement
-- Elle est pas belle la vie ?
Romain PETIT
Georges Peyre avait prétendu :
Bonjour,
Bonjour,
Comme déterminer qu'un fichier est au format unix ou non ?
Pour ma part, j'utilise la méthode suivante (pour des fichiers qui ne sont pas trop volumineux) : - fChargeTexte - extraitchaine(..., caract(10)) - si le dernier caractère de la chaine extraite est caract(13), alors c'est un fichier Windows sinon c'est un Unix-like (je ne traite pas de fichiers du monde Mac)
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Georges Peyre avait prétendu :
Bonjour,
Bonjour,
Comme déterminer qu'un fichier est au format unix ou non ?
Pour ma part, j'utilise la méthode suivante (pour des fichiers qui ne
sont pas trop volumineux) :
- fChargeTexte
- extraitchaine(..., caract(10))
- si le dernier caractère de la chaine extraite est caract(13), alors
c'est un fichier Windows sinon c'est un Unix-like (je ne traite pas de
fichiers du monde Mac)
A+
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
Comme déterminer qu'un fichier est au format unix ou non ?
Pour ma part, j'utilise la méthode suivante (pour des fichiers qui ne sont pas trop volumineux) : - fChargeTexte - extraitchaine(..., caract(10)) - si le dernier caractère de la chaine extraite est caract(13), alors c'est un fichier Windows sinon c'est un Unix-like (je ne traite pas de fichiers du monde Mac)
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Georges Peyre
Bonjour Romain
Romain PETIT a exposé le 05/04/2006 :
Comme déterminer qu'un fichier est au format unix ou non ?
Pour ma part, j'utilise la méthode suivante (pour des fichiers qui ne sont pas trop volumineux) : - fChargeTexte - extraitchaine(..., caract(10)) - si le dernier caractère de la chaine extraite est caract(13), alors c'est un fichier Windows sinon c'est un Unix-like (je ne traite pas de fichiers du monde Mac)
Merci pour ce conseil que je vais suivre.
Dans le même ordre d'idée j'ai le problème de savoir comment détecter qu'un fichier est au format UNICODE ou au format ANSI afin de pouvoir utiliser ou non la fonction UnicodeVersAnsi ?
Cordialement
-- Elle est pas belle la vie ?
Bonjour Romain
Romain PETIT a exposé le 05/04/2006 :
Comme déterminer qu'un fichier est au format unix ou non ?
Pour ma part, j'utilise la méthode suivante (pour des fichiers qui ne sont
pas trop volumineux) :
- fChargeTexte
- extraitchaine(..., caract(10))
- si le dernier caractère de la chaine extraite est caract(13), alors c'est
un fichier Windows sinon c'est un Unix-like (je ne traite pas de fichiers du
monde Mac)
Merci pour ce conseil que je vais suivre.
Dans le même ordre d'idée j'ai le problème de savoir comment détecter
qu'un fichier est au format UNICODE ou au format ANSI afin de pouvoir
utiliser ou non la fonction UnicodeVersAnsi ?
Comme déterminer qu'un fichier est au format unix ou non ?
Pour ma part, j'utilise la méthode suivante (pour des fichiers qui ne sont pas trop volumineux) : - fChargeTexte - extraitchaine(..., caract(10)) - si le dernier caractère de la chaine extraite est caract(13), alors c'est un fichier Windows sinon c'est un Unix-like (je ne traite pas de fichiers du monde Mac)
Merci pour ce conseil que je vais suivre.
Dans le même ordre d'idée j'ai le problème de savoir comment détecter qu'un fichier est au format UNICODE ou au format ANSI afin de pouvoir utiliser ou non la fonction UnicodeVersAnsi ?
Cordialement
-- Elle est pas belle la vie ?
MiF
Bonjour,
Ton exemple représente 24 millions d'assignations de chaînes...
Pour ce genre de traitement, un langage interprété comme Windev n'est pas la bonne solution... Le développement, c'est comme le bricolage; chaque outil est destiné à un usage spécifique. Tu ne prendrais pas un tournevis pour planter un clou, ni un marteau pour tourner une vis...
C'est la même chose dans ton cas. Windev n'est pas adapté à ce genre de besoin.
Michel Fages
Bonjour,
Ton exemple représente 24 millions d'assignations de chaînes...
Pour ce genre de traitement, un langage interprété comme Windev n'est
pas la bonne solution... Le développement, c'est comme le bricolage;
chaque outil est destiné à un usage spécifique. Tu ne prendrais pas
un tournevis pour planter un clou, ni un marteau pour tourner une
vis...
C'est la même chose dans ton cas. Windev n'est pas adapté à ce genre
de besoin.
Ton exemple représente 24 millions d'assignations de chaînes...
Pour ce genre de traitement, un langage interprété comme Windev n'est pas la bonne solution... Le développement, c'est comme le bricolage; chaque outil est destiné à un usage spécifique. Tu ne prendrais pas un tournevis pour planter un clou, ni un marteau pour tourner une vis...
C'est la même chose dans ton cas. Windev n'est pas adapté à ce genre de besoin.
Michel Fages
Romain PETIT
Georges Peyre a exposé le 05/04/2006 :
Dans le même ordre d'idée j'ai le problème de savoir comment détecter qu'un fichier est au format UNICODE ou au format ANSI afin de pouvoir utiliser ou non la fonction UnicodeVersAnsi ?
En gros, et pour faire vite et /mal/, si 1 caractère sur 2 est 0x0, il y a de très fortes chance que ce soit de l'Unicode..
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Georges Peyre a exposé le 05/04/2006 :
Dans le même ordre d'idée j'ai le problème de savoir comment détecter qu'un
fichier est au format UNICODE ou au format ANSI afin de pouvoir utiliser ou
non la fonction UnicodeVersAnsi ?
Dans le même ordre d'idée j'ai le problème de savoir comment détecter qu'un fichier est au format UNICODE ou au format ANSI afin de pouvoir utiliser ou non la fonction UnicodeVersAnsi ?
