DÉCOUPEUR DE FICHIERS (EN C++ BUILDER ET DEV-C++)
yoyo269
Messages postés
1403
Date d'inscription
lundi 23 février 2004
Statut
Membre
Dernière intervention
11 janvier 2009
-
14 févr. 2007 à 09:30
zaagane Messages postés 38 Date d'inscription mardi 19 avril 2005 Statut Membre Dernière intervention 30 avril 2008 - 14 oct. 2008 à 17:37
zaagane Messages postés 38 Date d'inscription mardi 19 avril 2005 Statut Membre Dernière intervention 30 avril 2008 - 14 oct. 2008 à 17:37
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/41465-decoupeur-de-fichiers-en-c-builder-et-dev-c
https://codes-sources.commentcamarche.net/source/41465-decoupeur-de-fichiers-en-c-builder-et-dev-c
14 oct. 2008 à 17:37
une nouvelle mise a jour.
maintenant le zip contient les deux versions:
- version avec une interface graphique en c++ builder.
- version sous console en DEV c++.
Merci de noter le travail.
25 févr. 2008 à 11:36
encore une nouvelle version:
- la portabilité du code est bien amélioré (split.h, build.h)
- une nouvelle interface graphique.
- une version console avec Dev c++.
- ...
5 mars 2007 à 09:46
Voila maintenant une nouvelle version est prés.
j'attend vos remarques et vos conseils.
26 févr. 2007 à 19:06
Merci beaucoup a votre aide et a vos conseils,
maintenant j'essaye de modifier le source et je prend en considération l'aide de Mick, alors attendez mois avec une nouvelle mise a jour.
(Je m?excuse pour les fautes de la langue)
26 févr. 2007 à 18:25
l'erreur suivant s'affcihé "Call to undefined function "min" malgré que jai ajouté :
#include <>
#include <functional>
#include
#include <vfw.h>
26 févr. 2007 à 18:00
Tu n'as pas grand chose à changer. Je me suis occupé que de la partie "split", à toi de faire pareil avec la partie "build"
pour la déclaration de ton buffer :
#define MAX_OCTET 32*512
char buf[MAX_OCTET] ;
Voila ta boucle de séparation du fichier :
for(int f=1;f<=nbr_partie;f++)
{
if ((destfd open(IntToStr(f).c_str(),O_BINARY | O_WRONLY)) -1) // ouvrir le fichier dst.
{
ShowMessage("cannot open destination files");
close(srcfd); //fermeture du fichier source.
return;
}
int reste = part_size;
while(reste)
{
int nboctet = min(MAX_OCTET, reste);
nlect = read(srcfd, buf, nboctet);
if(nlect)
{
write(destfd, buf, nlect);
ProgressBar1->Position += nlect;
Application->ProcessMessages();
reste -= nlect;
}
else
reste = 0; //force l'arret
}
close(destfd);
}
close(srcfd); //fermeture du fichier source.
Tu verra une très très grosse différence de vitesse.
Juste une remarque, YOYO t'a donné des infos qui a mon sens sont tout à fait constructives.
J'ai pu t'aider parce que j'ai de BCB5. Yoyo ne l'utilisant pas, il n'a pu te donner que des infos ou suggestions.
Yoyo, j'ai fait quelques mesures avec différente taille de buffer (sans l'affichage bien sûr). Effectivement, 512 est trop juste pour optimiser la vitesse. Semblerai qu'au delà de 4Ko, il n'y ai plus trop de différence (si la source et destination ne sont pas sur le même disque en tout cas).
Mick
26 févr. 2007 à 17:44
26 févr. 2007 à 17:11
Bon courage pour la suite alors.
YOYO, @+.
26 févr. 2007 à 17:04
Merci MickCo "Application->ProcessMessages();" ca marche bien maitenant l'interface a moins de blocage. mais je dois lis caractère par caractère. sinon l'architecture globale de mon pgms sera totalement changer.
SVP YOYO je veux des Remarques constructives et une aide si possible comme celle de MickCo et non pas autres choses
26 févr. 2007 à 16:12
26 févr. 2007 à 15:40
Il n'y a pas de bonne ou de mauvaise solution à partir du moment où ça marche correctement. Tout le débat va se situer autour du mot "correctement".
Dans le cas présent avec un petit peu d'optimisation, son programme remplira parfaitement son rôle !
Et en quoi ne serait-ce pas un vrai programme ? Parce qu'il n'y a pas de thread ou parce qu'il risque de prendre quelques ms de traitement en plus ? Voyons ....
26 févr. 2007 à 14:04
Enfin je connais cette 'bidouille' je veux dire, pas que cela remplace un thread sous C++ Builder.
Pour faire un thread (un vrai) avec C++ Builder, je n'en ai aucune idée.
C'est si simple en API Win32 ! :D
YOYO, @+.
26 févr. 2007 à 13:56
A bannir dans un vrai prog, il n'y a que les threads pour exploiter les architectures modernes des PCs.
26 févr. 2007 à 13:38
Quand je te parlais de thread, apparemment avec C++ Builder il suffit de : Application->ProcessMessages();
Et pour la vitesse, lire les fichiers avec un buffer beaucoup plus gros. Moi j'utilise 16 Ko minimum.
Après c'est à toi de juger, mais comme l'a dit MickCo, tu verras certainement une (très) GROSSE différence ! lol
Tiens-nous au courant des évolutions.
YOYO, @+.
26 févr. 2007 à 13:33
Juste après la ligne
ProgressBar1->Position+=1;
Rajoute :
Application->ProcessMessages();
En fait, ça permet à Windows de traiter tous les messages en attente dont le rafraichissement de la ProgressBar.
N'hésite pas à rajouter cette ligne dès qu'un traitement est long. Par contre ne l'appelle pas trop souvent pour éviter de dégrader tes performances.
Sinon, ton prog est très lent, pourquoi lis-tu octet par octet ?
Tu devrais allouer au moins 512 octets pour la lecture et l'écriture (512o = taille d'un secteur sur disque dur). Tu devrais voir une très grosse différence de vitesse.
Mick
26 févr. 2007 à 13:06
Ton interface se bloque, donc tu as une boucle très longue (while ou for) que tu dois mettre dans un thread. Comme ça plus de bloquage de l'interface.
Autre constat, (au moins pour la découpe) c'est extrêmement lent, malgré que ton programme prenne toutes les ressources système !!!
Un bon 1/4 d'heure pour découper un divx de 700 Mo.
Avec mon découpe fichiers je suis aux alentours d'une minute.
Donc beaucoup de travail à faire au niveau de l'optimisation.
Je vais essayer de jeter un oeil sur le code si j'ai le temps ! ;)
YOYO, @+.
26 févr. 2007 à 12:49
YOYO269,
Maintenant la mise a jour est prés et vous pouvez tester l'exécutable , mais j'ais un problème avec Le progressBar (c'est que la décomposition ou bien le regroupement est marche mais le progressBar se bloque), merci d'avance a votre aide.
24 févr. 2007 à 10:12
Rajoute un commentaire à ta source quand tu l'auras fait, comme ça on sera averti de la mise à jour. ;)
YOYO, @+.
24 févr. 2007 à 10:10
Merci bien MickCo, ca marche bien avec c++ Builder 6 et merci aussi a tes conseils.
( avec l'aide de MickCo) je modifierai le zip en ajoutant un exécutable marche sans les DLLs.
21 févr. 2007 à 11:48
j'utilise le C++B v5 mais je pense que ça doit être pareil.
Dans Projet->options->lieur décoche "Utiliser la RTL dynamique"
et dans l'onglet Paquets, décoche aussi "Construire avec les paquets d'exécution".
Voila, en principe ton exe n'a plus besoin des DLL de borland.
Une remarque, si tu sais ces chose, fais le d'office! En postant ta source, tu demandes aux autres de partager leurs idées avec toi. Fait déjà le premier pas en rendant tes sources lisible. Certains n'auront pas envie de faire l'effort de comprendre ce que tu as voulu faire. La plupart du temps, une source bien écrite avec des commentaires bien placé se lit tout seul. Et même pour toi, ça sera beaucoup plus facile si tu remets le nez dedans après quelques temps. Et ça devient même indispensable si tu travailles en équipe.
20 févr. 2007 à 18:49
MickCo ,j'oblie quelque chose !
comment créer un exe sans dépendance externe(avec c++ builder)
20 févr. 2007 à 09:34
MickCo, je sais ces choses mais Merci quand même. Mais le chose qui je ne le sais pas est comment créer un exe sans dépendance externe, je veux ta aide. merci d'avance .
Si qql n'a pas builder j'ai le setup de mon logiciel
19 févr. 2007 à 18:50
Tu dis :
"Car ce n'est pas comme ça que l'on apprend à bien programmer." ??? Ha bon ? Et pourquoi stp ?
"Mais force est de constater que beaucoup de ceux qui utilisent Builder ont beaucoup de mal pour faire autre chose après."
Tssstsss, n'oublie pas que en parlant de C++builder, on parle aussi de Delphi, donc attention à ne pas t'attirer les foudres de la communauté Delphi ;) En plus, comment peux tu justifier une telle déclaration ?
Je code en professionnel depuis près de 15 ans. A l'époque, je travaillais sous DOS en 32bit et avec ma propre librairie graphique, et même parfois avec du code assembleur. Tout ça pour dire que le fait de tout coder je sais ce que ça veut réellement dire.
Aujourd'hui, je trouve que c'est un vrai bonheur de ne pas me casser les pieds avec l'interface graphique. Il suffit juste de voir le nombre de ligne de code nécessaire juste à la création d'une fenêtre Windows. C++Builder (ou Delphi) permet de grandement simplifier cette tache mais en aucun te bloque pour aller au fond des chose si tu en as envie.
C'est surement déroutant au début, mais le gain de temps est vraiment appréciable. D'ailleurs, si je ne me trompe pas, VC 2005 en reprend le principe.
Le code pré-mâché ne concerne que les interfaces et les composants mis à ta disposition mais tu peux très bien faire du code natif si tu en as envie. Mais bon, a part pour savoir comment ça marche, il n'y a très peu d'intérêt vu leur qualité.
Zaagane,
Excuse nous, cette conversation n'a aucun rapport avec ta source.
Aussi parlons-en un peu, voila quelques conseils :
- Pas la peine de préciser "Form1->" quand dans le code du fichier unit1.cpp
Tu peux remplacer
Form1->RadioGroup1->Visible=false;
par
RadioGroup1->Visible=false;
C'est juste plus lisible.
- Nomme au maximum tes composants
Form1 est beaucoup moins explicite par ex que FormPrincipale
fais en de même avec les noms de fichiers
- Fais aussi attention à l'indentation,
Chez moi, rien n'est vraiment aligné. Ca gène vraiment la lisibilité.
En tout cas, bonne continuation.
19 févr. 2007 à 15:38
C'est l'un des premiers que j'ai essayé et vite abandonné.
Moi je préfère tout un code du début à la fin plutôt que d'avoir qq chose de prémâché.
Car ce n'est pas comme ça que l'on apprend à bien programmer.
Ce n'est que mon avis. Mais force est de constater que beaucoup de ceux qui utilisent Builder ont beaucoup de mal pour faire autre chose après.
Ce message n'a pas vraiment de rapport avec la source mais bon...;)
YOYO, @+.
19 févr. 2007 à 13:09
BruNews, il aurait été tout à fait possible de mettre un exe. Ce n'est pas du code interprété mais bien compilé. Effectivement, il faut soit installer les dll Borland ou soit créer un exe sans dépendance externe (ce qui est le plus simple à mon gout). Ca augmente la taille, mais de quelques 100aines de Ko seulement.
Ok, j'ai vu ton lien après coup.
Yoyo269, J'utilise la version 5 depuis de nombreuses années et j'ai vraiment du mal à en changer.
Pour mieux t'en rendre compte, tu devrais essayer les Turbo de chez Borland qui sont des versions light des autres produits (c++ builder, Delphi, etc.). Il y a des versions gratuites.
Après avoir essayé la plupart des IDE du marché, je t'assure que le c++builder est très très pratique d'utilisation.
Si tu a déjà entendu parler de Delphi, pour généraliser, le C++Builder c'est la version C++ de Delphi.
14 févr. 2007 à 10:27
http://www.cppfrance.com/code.aspx?ID=28232
qu'il est possible de coder sur Borland.
Produire du faux code vraiment interprété n'est l'exclusivité d'aucun IDE. Hors cppfrance, les exemples codés se font de plus en plus rares.
14 févr. 2007 à 09:46
Déjà que j'avais pas une bonne opinion sur C++ Builder, là c'est fini ! :D
YOYO, @+.
14 févr. 2007 à 09:37
14 févr. 2007 à 09:30
Comme ça on pourrait facilement tester.
Tout le monde n'a pas C++ Builder...loin de là meme ! ;)
YOYO, @+.