cs_ghuysmans99
Messages postés3982Date d'inscriptionjeudi 14 juillet 2005StatutMembreDernière intervention30 juin 201316 23 déc. 2009 à 17:37
@nisandsystems
Regarde le bout de code : il ne fait qu'appeler la fonction "sort" de l'interpréteur de commandes !
Mais t'as raison de le dire : ce n'est pas en VB pur qu'on peut arriver à des performances pareilles ...
NISANDSYSTEMS
Messages postés146Date d'inscriptionvendredi 1 novembre 2002StatutMembreDernière intervention13 décembre 2014 23 déc. 2009 à 17:00
Bonsoir,
Apprendez vbtistes de tout horizon, à saluer vos autrespar un simple bonjour ou bonsoir.
A quoi bon essayer de faire tourner un moteur qui est déjà cassé?
Les strings en vb..., consomment plus qu'une dauphine des années 50.
10 000 ligne de 100 caractères..., peut-etre tres réaliste mais certainement pas en vb ou du moins de cette façon là.
Bonsoir.
nhervagault
Messages postés6063Date d'inscriptiondimanche 13 avril 2003StatutMembreDernière intervention15 juillet 201137 23 déc. 2009 à 16:42
Les calculs ont été effectuées sur un altair ou Cray XT5-HE.
Ce source devrait être détruit.
cs_ghuysmans99
Messages postés3982Date d'inscriptionjeudi 14 juillet 2005StatutMembreDernière intervention30 juin 201316 23 déc. 2009 à 16:38
Sans donner la config processeur/DD, ces chiffres n'ont aucune utilité !
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 23 déc. 2009 à 16:28
(10.000 CHAINES DE 100 CARACTÈRES PAR SECONDE)
d'ou viennent ces chiffres ?
dépend du lecteur, de savoir si on lit/ecrit sur le meme drive
...
cs_ghuysmans99
Messages postés3982Date d'inscriptionjeudi 14 juillet 2005StatutMembreDernière intervention30 juin 201316 23 déc. 2009 à 16:10
En effet, il faudrait vérifier le code de sortie de la commande "sort". Mais de toutes façons ce n'est certainement pas comme ça qu'il faut faire pour trier des chaines de caractères dans un fichier texte !
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 23 déc. 2009 à 15:55
J'ajoute que ce code est dangereux, de même que celui de ghuismans99
En effet, sort a beau être rapide ; RIEN ne vous permet là d'être sûr que le tri a bien été terminé au moment ou l'on sort de la sub Tri
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 23 déc. 2009 à 15:54
quite a vanter la rapidité de la chose, dommage de ne pas exploiter le switch /O au profit d'une redirection de la sortie standard vers le fichier de sortie.
cs_ghuysmans99
Messages postés3982Date d'inscriptionjeudi 14 juillet 2005StatutMembreDernière intervention30 juin 201316 23 déc. 2009 à 15:43
- C'est du VB et pas du QuickBasic, donc on dimensionne ses variables !
- A la limite bon pour Codyx.org, mais pas VBFrance.com.
- DOS n'existe plus, et c'est bien Windows que tu appelles.
- Qui te dit que Windows est installé sur C: ?
- On concatène des chaines de caractères via & et pas +
- On ouvre un fichier avec un ID retourné par FreeFile, un autre fichier est peut-être ouvert avec l'ID=1
Voilà le code corrigé :
Public Function Tri(FichierSource As String, FichierDestination As String) As Boolean
'Cette fonction renvoit FALSE si aucune erreur ne s'est produite, sinon TRUE Dim F As Integer: F FreeFile: Dim Path As String: Path Environ("TEMP") & "\tri.bat"
Dim S As String: S = "sort """ & FichierSource & """ > """ & FichierDestination & """"
On Error Resume Next
Open Path For Output As #F: Print #F, S: Close #F
Shell Path, 1
If Err Then
Tri = True
Exit Function
End If
Err.Clear
Kill Path
End Function
23 déc. 2009 à 17:37
Regarde le bout de code : il ne fait qu'appeler la fonction "sort" de l'interpréteur de commandes !
Mais t'as raison de le dire : ce n'est pas en VB pur qu'on peut arriver à des performances pareilles ...
23 déc. 2009 à 17:00
Apprendez vbtistes de tout horizon, à saluer vos autrespar un simple bonjour ou bonsoir.
A quoi bon essayer de faire tourner un moteur qui est déjà cassé?
Les strings en vb..., consomment plus qu'une dauphine des années 50.
10 000 ligne de 100 caractères..., peut-etre tres réaliste mais certainement pas en vb ou du moins de cette façon là.
Bonsoir.
23 déc. 2009 à 16:42
Ce source devrait être détruit.
23 déc. 2009 à 16:38
23 déc. 2009 à 16:28
d'ou viennent ces chiffres ?
dépend du lecteur, de savoir si on lit/ecrit sur le meme drive
...
23 déc. 2009 à 16:10
23 déc. 2009 à 15:55
En effet, sort a beau être rapide ; RIEN ne vous permet là d'être sûr que le tri a bien été terminé au moment ou l'on sort de la sub Tri
23 déc. 2009 à 15:54
23 déc. 2009 à 15:43
- A la limite bon pour Codyx.org, mais pas VBFrance.com.
- DOS n'existe plus, et c'est bien Windows que tu appelles.
- Qui te dit que Windows est installé sur C: ?
- On concatène des chaines de caractères via & et pas +
- On ouvre un fichier avec un ID retourné par FreeFile, un autre fichier est peut-être ouvert avec l'ID=1
Voilà le code corrigé :
Public Function Tri(FichierSource As String, FichierDestination As String) As Boolean
'Cette fonction renvoit FALSE si aucune erreur ne s'est produite, sinon TRUE Dim F As Integer: F FreeFile: Dim Path As String: Path Environ("TEMP") & "\tri.bat"
Dim S As String: S = "sort """ & FichierSource & """ > """ & FichierDestination & """"
On Error Resume Next
Open Path For Output As #F: Print #F, S: Close #F
Shell Path, 1
If Err Then
Tri = True
Exit Function
End If
Err.Clear
Kill Path
End Function