stanOfSky :
"ne les utilisera pas forcement comme on le voudrai et ne les optimisera pas forcement" => je me demande quelle optimisation on peut appliquer à un goto ?! :))
ouaip goto et label c de l'assembleur pur...
le c a été créé pour programmer dans un langage non pas machine mais plus humain, le but final d'un langage étant de ressembler au maximum à un langage dit huamin (le c++ c different c juste une notion d'objet, heritage etc... ajouté au c mais c vrai que ca rend plus "humain" le langage)
pour ma part je suis contre les goto parce que c vrai qu'avec tro d'utilisation ca rend un source incomprehensibe. de plus le compilo ne les utilisera pas forcement comme on le voudrai et ne les optimisera pas forcement (fau bien utiliser les flags de compilation)
et pis bon les goto c de l'asm...alors ca detruit tout l'esprit langage évolué...
pour les erreurs, ya les exception :p
En gros:
+ de chance de bug (difficile de contrôler les entrées/sorties)
code + dur à lire et comprendre ( code spaghetti illisible à par pour son auteur)
code + dur à valider (preuve de validité - plutôt formelle)
le code ne reflête pas la structure logique de ton programme
le compilateur peut être troublé lors de la phase d'optimisation.
Le seul endroit où il semble que le goto peut être intéressant est la gestion des erreur. (le fameux long jump du C par exemple)
A part ça...
ok. Donc pas d'avis precis sur le sujet. Il y a des fois ou mettre un goto simplifierai grandement les choses, mais au niveau du code generé je n'ai jamais comparé. J'avoue quand même que je ne les utilise jamais, ...
Je m'en suis deja explique mais reprenons:
je n'ai rien ni 'pour' ni 'contre' les goto puisqu'a mon epoque certains tabous et interdits n'avaient pas cours. Je sais seulement qu'un goto envoyant sur un label clairement nomme me semble souvent plus simple a relire au niveau du code que tout un tas d'imbrications et d'indentation du code. Il est a noter egalement que meme si on l'ecrit sans goto, le compilo les mettra (JMP asm), ce n'est pas parce qu'on les aura masque qu'ils n'y seront pas.
juste une question : il semble en effet que tu aime bien les goto, puisque si ma mémoire est bonne tu en utilise aussi pour la fonction d'acces au mdb que tu as deja mis en ligne il y a fort longtemp. Quel interet trouve tu dans les goto, et pourquoi personne ne les aime si ce n'est parceque ca rapelle trop la syntaxe du basic ?
StanOfSky > salut, me semble que ma fonction Replace() n'utilise pas de win32, seulement le prog exemple qui s'en sert, devrait donc pouvoir etre utilisee par d'autres.
mais bon la STL fau l'utiliser pour les template "Standart Template Librairie"
c si tu veu utiliser de maniere effficace tous les conteneurs tels que les listes, vecteur, map, etc.... ou alors ne pas te galérer avec les allocation pour les string, ou utiliser des objets pour les entrées sorties...
sinon les stdio.h stdlib.h string.h du c vont tres bien.
pour cet exemple par exemple ya moyen d'utilise strncmp, strcpy etc...
dsl de pas mettre une version mais j'ai vraiment pas le tps ni l'envie.
pour les goto je suis désolé mais ca ne s'utilise pas ni en C, ni en C++ et c tres fortement contrindiqué dan tous les cours et tutoriaux que tu pourras voir. de plus ca ne sera pas forcement plus optimisé que de mettre de simples if ca dépend totalement de ton compilateur et de tes options de compilations...
et je te rassure brunews, je me sui pas abimé les yeux a regarder tro lgtps ton code :p j'ai pas di kil etait mauvais non plus
seulement coder pour une plateforme spécifique comme ca fait ici n'est pas necessaire pour ce genre de fonction. autant faire de l'algorythmie et rendre une fonction compatible avec toutes les plateformes. le code linux n'est pas mieux qd il est tro spécialisé, fau juste utiliser des librairies standart pour que le code soit portable
comme ca ici tout le monde sera content, et aura son code pour sa plateforme :p
et pis bon je vois po le tro le pb avec avoir des gros exécutables???
ca vous gene en quoi d'avoir un exe qui fait 50-100 ko de plus parce que vous utilisez la STL (vous perdrez d'autant plus a vouloir recodé des classes de listes, vecteurs etc...)
Salut LA JE E VAIS PLUS UTILISER la STL mais a la place je utiliserait ton code
c super je te met un 10/10 ( au forum ) bravoo :)
c genial et c facil a comprendre
see you
Merci
Bonjour, je vous propose cette version parce que je trouve les goto en peu "barbare" ;-), peut être moins rapide et plus bugguée mais à vous tester... surtout moins longue à taper.
Pour la partie win32 je fais confiance à Brunews :-)
char* Replace( char* s, const char* m, const char* n )
{
int sS strlen( s ), sM strlen( m ), sN = strlen( n );
if ( !sM ) return s;
char* c = s;
while( c = strstr( c, m ) ) {
memmove( c + sN, c + sM, sS - ( s - c ) + 1 );
memcpy( c, n, sN );
c += sN;
}
return s;
}
Si tu as d'autres question tu demandes, pas de prob je te reponds comme on l'a fait plus haut. Excuse mais je ne suis vraiment pas doue pour mettre des commentaires direct dans la source, je ne vois pas d'emblee ou il y en aurait besoin.
Tu as des doutes dans la func Replace() ?
Est ce que tu peut mettre des commentaire dans ta source car la j'ai meme pas volu la lire en regardant toute ces line sans commentaire
Merci .
et si ta pas le temp je vais essayer de creé la mien est essayer de la rondre encore plus petite.
Merci Encore
Ben mon opinion c que toutes les sources son bonne car dans chaque source on aqui des nouvelles fonction et des nouvelles maniere de progué
MAIS j'ai toujour la meme question est ce que quand on utilise la stl le prog deviend bcp plus gros que avec la win32 ? combient presque ?
Mais au lieu de nous repeter barbare, moche etc ... dis nous donc pourquoi, et un petit exemple transforme en 'joli' serait le bienvenu. Juste que ensuite j'irai verifier ce que le compilo a produit pour voir si c'est vraiment plus efficace.
Puis le win32 si c'est si moche, faut pas t'abimer les yeux a le regarder, c'est note dans la source que c'est win32.
Comme si j'allais regarder une source 'Linux' et j'y mets que c'est moche, ce serait nimporte quoi, je suis contre alors je n'y touche pas et basta.
ouai mais la t'as po besoin d'utiliser la stl mais seulement un peu de stdlib ou string.h ou stdio.h et encore meme pas sur donc t'aura po un exe enorme
en plus ta fonction sera réutilisable dans tous les contextes et plateformes
et pis les goto c vraiment barbare dans un langage assez évolué comme le c ou meme evolué comme le c++
Je ne voudrais pas critiquer mais si cette source est un exemple, c'est pas vraiment très clair.
Certes on apprend mieux en essayant de comprendre seul mais quelques commentaires seraient bienvenus parce que certaines lignes peuvent rester obscures pour le programmeur peu averti.
ben je l'avait poster et il n'a pas etait aimmer et je l'avait effacer mais la je vais la reposer
mais ce que je ne comprend pas est ce que en ajoutant les library standare STL le prog devien bcp plus grand ?
Mais encore bravo BREWNEWS!!!!
berk kes ke c moche le code win32. Pourquoi ne pas avoir fait un code portable avec les librairies standarts???
en plus utiliser des goto c po un bon exemple pour les débutants...
pardon BruNews mais j ai pas fait de l'asm alors est ce que tu peut m'expliquez la differnce entre une fonction avec _stdcall et sans.(c plus rapide ?....c fait koi au juste ).
deconde la fonction INLINE C KOI AU JUSTE ? Ben j'ai bcp de question alors je ne trouve pas meiux que toi ..
Merci
on s'en sert:
int a = func(10, 12);
le compilo genere:
push 12
push 10
call func
add esp, 8 ; DEPILAGE PARAMS ICI PAR APPELANT
Si func est __stdcall, pas d'instruction de depilage des params car func aura replace le stack pointer (ESP) a sa sortie.
func en cdecl finit par:
ret 0
func en __stdcall finit par:
ret 8
VirtualAlloc est appel direct d'allocation memoire en win32.
VirtualFree est son pendant, desalloc.
__stdcall, la fonction depilera les params au lieu qu'en cdecl (ordinaire C/C++) c'est l'appelant qui depile.
re :
comme je debut encore en c++ je pas compris des choses dans ta source :
-c koi au juste __stdcall ?
-VirtualFree(pmem, 0, MEM_RELEASE);
-pmem = (char*) VirtualAlloc(0, r, MEMDISPO, PAGE_READWRITE);
-#define MEMDISPO (MEM_RESERVE | MEM_COMMIT | MEM_TOP_DOWN)
Merci d'avance :)
Merci pour ta source j'aibien aimmer je te pose un 10/10.
ben la source que j'avait commencer et proche de la tien mais il avait un prob que je n'avait pas vu c pour ca que j'ai pas volu continu
encore merci
"ne les utilisera pas forcement comme on le voudrai et ne les optimisera pas forcement" => je me demande quelle optimisation on peut appliquer à un goto ?! :))
le c a été créé pour programmer dans un langage non pas machine mais plus humain, le but final d'un langage étant de ressembler au maximum à un langage dit huamin (le c++ c different c juste une notion d'objet, heritage etc... ajouté au c mais c vrai que ca rend plus "humain" le langage)
pour ma part je suis contre les goto parce que c vrai qu'avec tro d'utilisation ca rend un source incomprehensibe. de plus le compilo ne les utilisera pas forcement comme on le voudrai et ne les optimisera pas forcement (fau bien utiliser les flags de compilation)
et pis bon les goto c de l'asm...alors ca detruit tout l'esprit langage évolué...
pour les erreurs, ya les exception :p
- Messages postés
-
364
- Date d'inscription
- mercredi 11 février 2004
- Statut
- Membre
- Dernière intervention
- 5 octobre 2006
2http://home.swbell.net/mck9/cobol/style/antigoto.html
En gros:
+ de chance de bug (difficile de contrôler les entrées/sorties)
code + dur à lire et comprendre ( code spaghetti illisible à par pour son auteur)
code + dur à valider (preuve de validité - plutôt formelle)
le code ne reflête pas la structure logique de ton programme
le compilateur peut être troublé lors de la phase d'optimisation.
Le seul endroit où il semble que le goto peut être intéressant est la gestion des erreur. (le fameux long jump du C par exemple)
A part ça...