SENDER BY SMTP [AVEC FICHIER JOINT]
cosmobob
Messages postés
700
Date d'inscription
mardi 30 décembre 2003
Statut
Membre
Dernière intervention
27 janvier 2009
-
3 janv. 2005 à 00:57
HeavenForsaker Messages postés 223 Date d'inscription mercredi 13 juillet 2005 Statut Membre Dernière intervention 8 août 2011 - 19 juil. 2007 à 15:23
HeavenForsaker Messages postés 223 Date d'inscription mercredi 13 juillet 2005 Statut Membre Dernière intervention 8 août 2011 - 19 juil. 2007 à 15:23
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/28577-sender-by-smtp-avec-fichier-joint
https://codes-sources.commentcamarche.net/source/28577-sender-by-smtp-avec-fichier-joint
19 juil. 2007 à 15:23
je vois que tu envoi la pièce jointe avec un buffer de 2048 bytes, j'en déduis qu'on ne peux pas envoyer plus de données d'un seul coup au serveur ? est ce possible de tomber sur un serveur qui accepte moins de 2048 bytes? (auquel cas il y aurai un bug)
Thx
23 oct. 2006 à 18:20
1.ajouter odbc32.lib odbccp32.lib ws2_32.lib dans le projet
(seule ws2_32.lib est nécessaire je crois)
2.caster le résultat de VirtualAlloc
szBuff = (char*)VirtualAlloc(0, dwSizeFile+1, MEMDISPO, PAGE_READWRITE);
sinon j'avais une erreur de compilo (C2440)
17 juil. 2006 à 11:32
Je l'ai testé et malheureusement, lorsque je l'execute, j'obtiens l'erreur suivante:
" L'instruction à "0x01232f73" emploie l'adresse mémoire "0xccccccdc". La mémoire ne peut être "read"
L'erreur est generée dans le if suivant:
hFile1 = CreateFile(sztmp, GENERIC_READ, 0, 0, OPEN_EXISTING, 0, 0);
if (hFile1 == INVALID_HANDLE_VALUE) goto err_file;
As tu une idée concernant cette erreur ?
Merci d'avance.
4 mai 2005 à 05:22
10 avril 2005 à 10:46
Allez, au maximum il manquerait peut-etre une seule ligne de commentaire au début avant le passage en assembleur du style "// code assembleur équivalent à la fonction C strcpy()" mais sinon c'est super , enfin moi je trouve...
Merci pour cette source!
PS: Il est vrai que ce sont les "critiques" constructives qui font avancer et progresser, mais bon là je sais pas, vous auriez au moins pu le féliciter pour tout le boulot qu'il a fait et lui dire merci. On évalue mal de nos jours le prix de la connaissance....là le code est ammené sur un "plateau", donc de ma part merci à Arnotic ;)
23 mars 2005 à 07:43
C'est bête je vais devoir faire une conversion moi-même !
Pour la partie ASM il y aura pas un équivalent C++ ?
Sender.cpp:89: error: `isalpha' undeclared (first use this function)
8 févr. 2005 à 20:12
6 janv. 2005 à 23:55
ca fait qu'alourdir l'ecriture.....
6 janv. 2005 à 21:06
De plus, autant utiliser tout le temps strncpy() va évite de se tromper et d'utiliser un strcpy() sur un buffer saisie par l'utilisateur.
6 janv. 2005 à 18:37
6 janv. 2005 à 18:27
en quoi le fait d'ecrire *(c+31) = 'x';
est il plus performant qu'un c[31] = 'x';
ca change quelque chose au niveau du code assembleur?
5 janv. 2005 à 23:20
5 janv. 2005 à 22:55
de plus je dois dire que vos reponses a cosmobob ne sont pas tjs justifiées car je trouve qu'effectivement il essaie d'apporter des elements constructifs et argumentées a la discussion, et tjs sans agressivité, juste pr défendre son pt de vue et essayer d'avoir du retour...dc des reponses genre "va faire du .NET", je trouve ca assez limite ds lesprit, car ca sonne plutot "degage de la tu soule" alors qu'on préfèrerais un "moi mon pt de vue est le suivant pr les raisons suivantes"......a bon entendeur, salut, en esperant que ma modeste contribution a la discussion releve un peu l'humeur
4 janv. 2005 à 22:32
Donc Arnotic prend c'est critique comme de l'aide et non de l'humiliation.
+++ Que le code soit avec vous.
4 janv. 2005 à 22:24
- Lorsqu'on dépose une source sur le site, c'est dans le but de la partager et permettre à d'autres d'en retirer quelque chose pour progresser. Là j'ai du mal à voir se que ca peut apporter à quelqu'un tellement le code est illisible et pas commenté. Toi même tu n'y comprendras plus rien dans quelques temps ...
- Explique nous STP, comme le demande BlackGoddess, l'intérêt d'utiliser les codes numériques au lieu d'utiliser les macros pour les constantes de MessageBox() ?
- Pourquoi tes fichiers portent l'extension ".cpp" alors que tu fais du C ? C'est pas plus simple de mettre une extension ".c" que d'utiliser ".cpp" et d'aller changer les paramètres de génération pour générer du code c au lieu de c++ ?
- Pourquoi ton programme en mode debug lancé sous le debbugeur de Visual fait un "Run-Time Check Failure #2 - Stack around the variable 'input' was corrupted." ? Le mode debug n'est pas correctement configuré ?
- C'est bien "d'optimiser" son code, mais c'est encore mieux de le rendre "sûr" en utilisant "strncpy()" au lieu de "strcpy()" pour éviter les débordements de buffer par exemple ...
- ...
Finalement, quel est le ratio entre ton "optimisation" et le temps perdu à écrire le générateur de "strcpy()" et le temps que va perdre quelqu'un à comprendre ta source pour la modifier ?
Te sens pas aggressé mais je me pose juste des questions auxquelles j'aimerais avoir des réponses autre que "si ca te plais pas, t'as qu'à faire du .NET ou du JAVA".
4 janv. 2005 à 20:55
apres de toute maniere fo pas s'enerver ni s'enflammer sur ce genre de chose, ca reste des critiques sur un code (ce qui n'est qd meme pas foncierement qqchose de tres vexant), par sur la personne elle meme... ;p
bref, bon coding a tous ;)
4 janv. 2005 à 20:44
Enfin bon, de tte maniere, j'ai remarké sur ce site BOCOU de critiques (UN critique)...
4 janv. 2005 à 20:25
Sérieux, la c'est le pompon.
code les chaines en dur, et utilise les pointeurs pour éviter les copies. Concatène quand y a besoin.
D'habitude les codes comme ça ne m'empeche pas de dormir, mais la je crois que je vais mettre une sangle pour éviter les sursauts ...
4 janv. 2005 à 20:01
4 janv. 2005 à 19:17
ya 86716 octets dans ce zip qui correspondent a des fichiers qui servent a rien pour le code (les fichiers aps ncb et suo). fait une tite update en les enlevant et en mettant l'exe compilé par exemple, ca mangera pas de pain...
a+ ;)
4 janv. 2005 à 19:12
par horreur je voulais parler de la lisibilité du code drolement réduite (ceci se retrouve par exemple aussi au dernier paramètre des MessageBox, des defines ont été créés expres, quel est l'interêt de mettre les codes hexadécimaux qui y correspondent ?
peut-être une habitude de l'assembleur, mais le code ci-dessus est en C non ?
dans la fonction base64_enc, un fichier est créé pour les données "cibles". pourquoi pas un file mapping ?
je soutiens aussi la remarque de Nebula : sans aller faire du .NET, quel est le ratio temps gagné par cette technique de copie de chaine/ temps de reponse du serveur smtp ? ou de passage dans la fonction base64_enc ?
4 janv. 2005 à 19:10
4 janv. 2005 à 18:51
4 janv. 2005 à 18:47
Chacun code comme il veut, donc c'est pas la peine de répeter dix fois la même chose, on a compris ce que tu voulais faire passer comme message.
De toute manière, tu ne le fera jamais changer d'avis (Arnotic en l'occurence) :p
Moi je trouve ça marrant cette manière de faire, même si pour l'instant je me contente du "traditionnel" strcpy.
4 janv. 2005 à 18:41
4 janv. 2005 à 18:34
De plus tu optimise rien du tout car les optimisation ce font sur de boucle qui tourne pendant un longtemps pour ça fait un programme qui calcul les nombres premier et on comparera le programme le plus rapide.
Mais bon si tu t'obstine à faire comme ça fais comme ça mais entre un ligne de code et ton pavé, il y a deux différence, la relecture du code et le temps à le taper.
Et je pense que là tu perds du temps.
Enfin bon le C est c's mystères.
Bon codage à vous les gars.
4 janv. 2005 à 12:48
ya deux choses sur un forum comme celui la : le code source du programme, et l'executable généré. l'executable généré avec ton code ou t'as fait ton stringcopy la n'est absolument pas plus rapide, a la limite il sera peut etre plus gros qu'un exe généré en remplacant ton tintouin par un bete strncpy.
et ya le code source, qui a par contre enormément perdu en lisibilité. je suis pas sur qu'un newbie qui tombe dessus comprenne quelque chose.
en gros tu as fait un choix que tu dis réfléchi, alors que:
- il n'apporte strictement rien a l'exe généré
- la qualité du code source en est diminué
4 janv. 2005 à 08:52
4 janv. 2005 à 08:11
4 janv. 2005 à 06:54
Perso, je rentre ce soir et jV essayer (j'ai bien dit 'essayer') de faire des tests, pck vos reflexions m'enchantent peu, pour moi, a choisir en lisibilité (fo pas deconner, on comprend kan mm) et performances, le choix est vite fait...
Bon allez, bonne journée, a ce soir ;)
++
4 janv. 2005 à 01:05
4 janv. 2005 à 00:48
3 janv. 2005 à 23:57
Le passage sur ASM est a s'en taper le derriere par terre.
3 janv. 2005 à 23:48
imaginons qu'une équipe d'astronautes cherche a se rendre sur alpha du centaure située a plusieurs années lumiere d'ici, c'est comme si on se disait que les efforts de l'équipe pour diminuer le temps du voyage se focalisaient sur le trajet qui relie la maison du chef d'équipe a la base militaire, et qu'on construise une autoroute expres pour ca.
le voyage ne sera pas plus rapide.
la tu as fait pareil... ca manque de pertinence, et on dirait que tu crois que le programme s'améliore avec ce genre de passage alors que la probabilité de bogue a augmenté, que ton code n'est absolument pas réutilisable, etc...
bref sur ce, on peut pas convaincre les convaincus dirait on.
a++ ;)
3 janv. 2005 à 23:42
as tu suivi à la lettre ces conseils? lol
3 janv. 2005 à 23:41
3 janv. 2005 à 23:30
par contre juste un truc pour dire que c'est completement inutile de faire tout ce tintouin vu que juste apres tu as un:
SendMsg(sztmp, 0); SendMsg(MyMAIL->szMsg, 0); dont le temps d'execution n'est pas du meme ordre de grandeur que les:
*c '\r'; *(c+1) '\n'; *(c+2) = 'X'; *(c+3) = '-';
*(c+4) 'P'; *(c+5) 'r'; *(c+6) = 'i'; *(c+7) = 'o';
etc... qui le precedent. (genre le send risque de prendre un temps 100 millions de fois superieur (au sens strict)).
donc la ca n'apporte absolument rien au programme si ce n'est une perte complete de lisibilité (un strncpy aurait été aussi bien).
ca serait (eventuellement) utile lors d'un passage critique, mais la ca n'est absolument pas le cas, donc ca montre plutot une mauvaise maniere de penser ton code.
a++ ;)
3 janv. 2005 à 22:42
3 janv. 2005 à 22:37
L'affectation sur 4 octets necessite l'alignement sur un multiple de 4 au niveau de l'adresse cible, on n'en aurait aucune garantie ici.
3 janv. 2005 à 21:14
*c '\r'; *(c+1) '\n'; *(c+2) = 'X'; *(c+3) = '-';
*(c+4) 'P'; *(c+5) 'r'; *(c+6) = 'i'; *(c+7) = 'o';
*(c+8) 'r'; *(c+9) 'i'; *(c+10) = 't'; *(c+11) = 'y';
*(c+12) ':'; *(c+13) ' '; *(c+14) = '3'; *(c+15) = '\r';
*(c+16) '\n'; *(c+17) 'M'; *(c+18) = 'I'; *(c+19) = 'N';
*(c+20) 'E'; *(c+21) '-'; *(c+22) = 'V'; *(c+23) = 'e';
*(c+24) 'r'; *(c+25) 's'; *(c+26) = 'i'; *(c+27) = 'o';
*(c+28) 'n'; *(c+29) ':'; *(c+30) = ' '; *(c+31) = '1';
*(c+32) '.'; *(c+33) '0'; *(c+34) = '\r'; *(c+35) = '\n';
*(c+36) 'S'; *(c+37) 'u'; *(c+38) = 'b'; *(c+39) = 'j';
*(c+40) 'e'; *(c+41) 'c'; *(c+42) = 't'; *(c+43) = ':';
*(c+44) = ' ';
c = bnstrcpy(c+45, MyMAIL->szSujet);
*c '\r'; *(c+1) '\n'; *(c+2) = 'C'; *(c+3) = 'o';
*(c+4) 'n'; *(c+5) 't'; *(c+6) = 'e'; *(c+7) = 'n';
*(c+8) 't'; *(c+9) '-'; *(c+10) = 't'; *(c+11) = 'y';
*(c+12) 'p'; *(c+13) 'e'; *(c+14) = ':'; *(c+15) = ' ';
*(c+16) 'm'; *(c+17) 'u'; *(c+18) = 'l'; *(c+19) = 't';
*(c+20) 'i'; *(c+21) 'p'; *(c+22) = 'a'; *(c+23) = 'r';
*(c+24) 't'; *(c+25) '/'; *(c+26) = 'm'; *(c+27) = 'i';
*(c+28) 'x'; *(c+29) 'e'; *(c+30) = 'd'; *(c+31) = ';';
*(c+32) ' '; *(c+33) 'b'; *(c+34) = 'o'; *(c+35) = 'u';
*(c+36) 'n'; *(c+37) 'd'; *(c+38) = 'a'; *(c+39) = 'r';
*(c+40) 'y'; *(c+41) '='; *(c+42) = 'b'; *(c+43) = 'b';
*(c+44) '3'; *(c+45) '2'; *(c+46) = 'f'; *(c+47) = '0';
*(c+48) 'a'; *(c+49) '4'; *(c+50) = '1'; *(c+51) = 'b';
*(c+52) '7'; *(c+53) '1'; *(c+54) = '5'; *(c+55) = '5';
*(c+56) 'b'; *(c+57) '1'; *(c+58) = '8'; *(c+59) = '9';
*(c+60) '8'; *(c+61) '2'; *(c+62) = 'f'; *(c+63) = 'a';
*(c+64) '2'; *(c+65) '5'; *(c+66) = '6'; *(c+67) = 'e';
*(c+68) '5'; *(c+69) '9'; *(c+70) = '7'; *(c+71) = '4';
*(c+72) 'a'; *(c+73) 'b'; *(c+74) = 'a'; *(c+75) = '\r';
*(c+76) '\n'; *(c+77) '\r'; *(c+78) = '\n'; *(c+79) = '-';
*(c+80) '-'; *(c+81) 'b'; *(c+82) = 'b'; *(c+83) = '3';
*(c+84) '2'; *(c+85) 'f'; *(c+86) = '0'; *(c+87) = 'a';
*(c+88) '4'; *(c+89) '1'; *(c+90) = 'b'; *(c+91) = '7';
*(c+92) '1'; *(c+93) '5'; *(c+94) = '5'; *(c+95) = 'b';
*(c+96) '1'; *(c+97) '8'; *(c+98) = '9'; *(c+99) = '8';
*(c+100) '2'; *(c+101) 'f'; *(c+102) = 'a'; *(c+103) = '2';
*(c+104) '5'; *(c+105) '6'; *(c+106) = 'e'; *(c+107) = '5';
*(c+108) '9'; *(c+109) '7'; *(c+110) = '4'; *(c+111) = 'a';
*(c+112) 'b'; *(c+113) 'a'; *(c+114) = '\r'; *(c+115) = '\n';
*(c+116) 'C'; *(c+117) 'o'; *(c+118) = 'n'; *(c+119) = 't';
*(c+120) 'e'; *(c+121) 'n'; *(c+122) = 't'; *(c+123) = '-';
*(c+124) 'T'; *(c+125) 'y'; *(c+126) = 'p'; *(c+127) = 'e';
*(c+128) ':'; *(c+129) ' '; *(c+130) = 't'; *(c+131) = 'e';
*(c+132) 'x'; *(c+133) 't'; *(c+134) = '/'; *(c+135) = 'h';
*(c+136) 't'; *(c+137) 'm'; *(c+138) = 'l'; *(c+139) = '\r';
*(c+140) '\n'; *(c+141) 'C'; *(c+142) = 'o'; *(c+143) = 'n';
*(c+144) 't'; *(c+145) 'e'; *(c+146) = 'n'; *(c+147) = 't';
*(c+148) '-'; *(c+149) 'D'; *(c+150) = 'i'; *(c+151) = 's';
*(c+152) 'p'; *(c+153) 'o'; *(c+154) = 's'; *(c+155) = 'i';
*(c+156) 't'; *(c+157) 'i'; *(c+158) = 'o'; *(c+159) = 'n';
*(c+160) ':'; *(c+161) ' '; *(c+162) = 'i'; *(c+163) = 'n';
*(c+164) 'l'; *(c+165) 'i'; *(c+166) = 'n'; *(c+167) = 'e';
*(c+168) '\r'; *(c+169) '\n'; *(c+170) = '\r'; *(c+171) = '\n';
*(c+172) = 0;
Pkoi ne pas faire un strcpy() (jpense ke c pour les perfs, mais bon kan mm..) ? Ou pkoi ne pas remplacer par des :
*((DWORD *)(c + x)) = 0xXXXXXXXX ? Ne serait pas mieux et encore plus performant ?
Enfin, jme demande, si tu las fait, c kil ya une raison jpense !
Merci
++
3 janv. 2005 à 20:20
3 janv. 2005 à 20:13