Jojo Lancien
Messages postés6Date d'inscriptionvendredi 8 juin 2012StatutMembreDernière intervention 8 juin 2012 12 janv. 2009 à 08:56
Quand on veut se former en lisant les codes des autres, on ne recherche pas necessairement un code parfait. Les imperfections du code accompagnées des remarques et commentaires d'autres personnes me paraissent instructives. Et, donc, ce code m'interesse et je prendrais le temps de l'étudier.
Les remarques sur les différentes façons d'écrire sur disque m'interressent. Pour ma part, suivant l'humeur, j'utilise l'une ou l'autre. Ici, j'aurais sans doute choisi CreateFile, WriteFile et CloseHandle parce que je présume qu'elle sont plus rapides. Mais, dans d'autres cas, je préfère utiliser le bibliothèque standard du CPP qui est théoriquement plus portable.
e_NeX
Messages postés104Date d'inscriptionmardi 9 mars 2004StatutMembreDernière intervention30 novembre 2009 6 janv. 2009 à 21:51
merci de ces commentaires contructifs je vais travailler dessus et mettre a jour la source des que possible ;)
shenron666
Messages postés229Date d'inscriptiondimanche 14 septembre 2003StatutMembreDernière intervention20 août 2014 6 janv. 2009 à 20:40
"des threads, ça se synchronise" -> pas nécessairement, s'ils doivent accéder en écriture à une zone commune ou s'ils doivent collaborer mais s'ils peuvent travailler chacun dans leur coin sans se marcher dessus ce n'est pas obligatoire
par contre, il vaut mieux connaitre et se faire la main sur les différents synchronismes si on veux faire du multithreading
"si on fait du Windows alors et autres <fstream> n'ont rien à y faire" -> là dessus je suis d'accord, oublies windows E_NEX, penches toi sur boost qui permet de créer des threads avec boost::thread, de les synchronisr avec boost::interprocess, d'accéder au système de fichiers avec boost::filesystem et tout ça de manière portable et efficace
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 6 janv. 2009 à 09:51
UINT64 au lieu de double.
Variable starter NIET => synchro.
fstream => CreateFile, WriteFile, etc.
En avant pour l'effort de code.
e_NeX
Messages postés104Date d'inscriptionmardi 9 mars 2004StatutMembreDernière intervention30 novembre 2009 6 janv. 2009 à 05:56
Bonjour BruNews, content de tes commentaires :)
j'utilise le long double car les valeurs doivent stocker la taille des données, en bytes, qui doivent etre crées! donc un disque de 200Gb a remplir, ca en fais des bytes....
pour le WaitForSingleObject cela n'etait pas utile pour le bon fonctionnement!
la boucle tourne tant que les threads n'ont pas fini leur travail et a chaque secondes le travail effectué est mis a jour dans la partie graphique!
des que un thread a fini son travail, il le spécifie dans la variable starter!
je ne comprends pas la partie de iomanip et fstream!
j'en n'ai pourtant besoin!
je sais que je ne suis pas un expert et peut-être que je ne comprends pas tout ce que tu dis mais je code les choses bizzarement! Et ton commentaire spécifiant que ma source allait etre supprimée me laisse perplexe pour deux raisons:
1_ je n'ai pas l'impression que tu ai bien analysé le fonctionnement du programme
2_ moi quand je cherche de l'aide, je consulte rarement les forums mais plutot les codes avec les commentaires.
parcontre je promet que si ma source est encore la demain, je ferait l'effort de la commenter ;)
Allez, A+
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 5 janv. 2009 à 09:46
Salut,
des threads, ça se synchronise (WaitForSingleObject, WaitForMultipleObject), on ne fait pas de boucles éternelles pour savoir leur état.
Des 'double' n'ont rien à faire dans des calculs d'espace disque, on n'adresse que des octets complets.
Faut être cohérent en codant, si on fait du Windows alors et autres <fstream> n'ont rien à y faire.
char ID_c[2];
itoa(TH+1,ID_c,10);
NON, tu n'as qu'1 octet pour écrire le nombre (l'autre est pour le 0 final).
etc, etc...
C'est tres bien que tu commences la prog, je t'encourage a continuer.
Pour autant il ne faut pas confondre ton dossier de tests et les sources CS.
Une source se doit d'expliciter un point precis de prog, de repondre a une question souvent posee sur le forum, ..., un truc UTILE en somme.
Etudie bien avant et tu nous reposeras une source valable plus tard.
Un debutant doit étudier, les publications viendront plus tard.
12 janv. 2009 à 08:56
Les remarques sur les différentes façons d'écrire sur disque m'interressent. Pour ma part, suivant l'humeur, j'utilise l'une ou l'autre. Ici, j'aurais sans doute choisi CreateFile, WriteFile et CloseHandle parce que je présume qu'elle sont plus rapides. Mais, dans d'autres cas, je préfère utiliser le bibliothèque standard du CPP qui est théoriquement plus portable.
6 janv. 2009 à 21:51
6 janv. 2009 à 20:40
par contre, il vaut mieux connaitre et se faire la main sur les différents synchronismes si on veux faire du multithreading
"si on fait du Windows alors et autres <fstream> n'ont rien à y faire" -> là dessus je suis d'accord, oublies windows E_NEX, penches toi sur boost qui permet de créer des threads avec boost::thread, de les synchronisr avec boost::interprocess, d'accéder au système de fichiers avec boost::filesystem et tout ça de manière portable et efficace
6 janv. 2009 à 09:51
Variable starter NIET => synchro.
fstream => CreateFile, WriteFile, etc.
En avant pour l'effort de code.
6 janv. 2009 à 05:56
j'utilise le long double car les valeurs doivent stocker la taille des données, en bytes, qui doivent etre crées! donc un disque de 200Gb a remplir, ca en fais des bytes....
pour le WaitForSingleObject cela n'etait pas utile pour le bon fonctionnement!
la boucle tourne tant que les threads n'ont pas fini leur travail et a chaque secondes le travail effectué est mis a jour dans la partie graphique!
des que un thread a fini son travail, il le spécifie dans la variable starter!
je ne comprends pas la partie de iomanip et fstream!
j'en n'ai pourtant besoin!
je sais que je ne suis pas un expert et peut-être que je ne comprends pas tout ce que tu dis mais je code les choses bizzarement! Et ton commentaire spécifiant que ma source allait etre supprimée me laisse perplexe pour deux raisons:
1_ je n'ai pas l'impression que tu ai bien analysé le fonctionnement du programme
2_ moi quand je cherche de l'aide, je consulte rarement les forums mais plutot les codes avec les commentaires.
parcontre je promet que si ma source est encore la demain, je ferait l'effort de la commenter ;)
Allez, A+
5 janv. 2009 à 09:46
des threads, ça se synchronise (WaitForSingleObject, WaitForMultipleObject), on ne fait pas de boucles éternelles pour savoir leur état.
Des 'double' n'ont rien à faire dans des calculs d'espace disque, on n'adresse que des octets complets.
Faut être cohérent en codant, si on fait du Windows alors et autres <fstream> n'ont rien à y faire.
char ID_c[2];
itoa(TH+1,ID_c,10);
NON, tu n'as qu'1 octet pour écrire le nombre (l'autre est pour le 0 final).
etc, etc...
C'est tres bien que tu commences la prog, je t'encourage a continuer.
Pour autant il ne faut pas confondre ton dossier de tests et les sources CS.
Une source se doit d'expliciter un point precis de prog, de repondre a une question souvent posee sur le forum, ..., un truc UTILE en somme.
Etudie bien avant et tu nous reposeras une source valable plus tard.
Un debutant doit étudier, les publications viendront plus tard.
Cette souurce sera supprimée en soirée.