LANGAGE DE SCRIPT POUR AUTOMATISER DES ACTIONS DANS WINDOWS
Funto66
Messages postés
1267
Date d'inscription
mercredi 1 janvier 2003
Statut
Membre
Dernière intervention
28 février 2007
-
24 oct. 2003 à 16:09
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008 - 9 août 2006 à 13:35
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008 - 9 août 2006 à 13:35
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/17340-langage-de-script-pour-automatiser-des-actions-dans-windows
https://codes-sources.commentcamarche.net/source/17340-langage-de-script-pour-automatiser-des-actions-dans-windows
9 août 2006 à 13:35
9 août 2006 à 11:20
C'est très gentil !
C'est fou de voir qu'il y a encore des gens qui utilisent cette source ! C'est un programme que j'avais fait pendant que je cherchais du boulot et à dire vrai je m'en sert encore (y compris pour le boulot)
D'ailleurs ça fait des mois que j'ai envie de me mettre à MacroScript V3. J'ai plein d'idées pour l'améliorer mais je n'ai plus assez de temps libre. En plus je me suis marié le mois dernier : ça n'arrange rien ;)
Si ça tente quelqu'un de poursuivre ce travail ce serait AVEC GRAND PLAISIR que je partagerais mes idées et le peu de temps libre qu'il me reste !!!
6 août 2006 à 01:42
je l'utilise pour un autre programme (python)...
Je trouve ca bizzare que tu ais eu un trophet...
Moi je t'en aurai bien donné 2 ou 3...
Xeo
6 févr. 2004 à 17:22
vala pr moi ;-)
6 févr. 2004 à 12:01
il n'y a pas de fuite pardon, j'avais mal vu ...
mais c'etait assez moche, c'est pour ca!
5 févr. 2004 à 23:41
Bon, y a quelques progres depuis la derniere fois ;) Au niveau des fonctionalites, ca a l'air pas mal, allez je vais essayer de le mettre sur mon windoze!!! Si ce serait possible, tu pourrais faire un petit fichier expliquant la structure de MacroScript2 ? J'ai pas passe enormement de temps, mais je n'en saisi pas le principe, est-ce que j'ai toutes les sources ?
qu'est-ce que tu veux dire par chaque fonction est une dll?
tu peux en dire plus sur le fonctionnement, sans que je sois oblige de dissequer le code ?
sinon, quelques defaut qui vallent la peine d'etre corrige:
- une fuite memoire dans la classe Kernel. tu as des vector<Variable*>
dans le destructeur, il faut faire
typedef vector<Variable*>::const_iterator vc_it;
for(vc_it p = mp_variable.begin();p != mp_variables.end();++p)
delete *p;
idem pour son jumeau...
erase ne libere pas la memoire.
tu ne liberais que le premier element en fait
- tu utilises souvent at pour acceder a un element d'un string.
pour acceder a un element, tu as le choix entre operator[] et at. at verifie que l'indice est dans les bornes, s'il n'y est pas, il declenche l'exception range_error, or tu ne la capte jamais...
utilises donc plutot operator[].
- au lieu de faire des insert "a la fin", fait push_back (pour vector)
- il y a une technique pour lire et ecrire dans des std::string qui evite les buff[128], je te le ferais passe.
- sauf erreur, il manque encore quelques const ... (je sais c'est chiant d'en mettre partout!)
enfin bravo pour avoir fait un pas vers le C++ standard avec std::string!
maintenant, il reste a passer a pour les fichiers, c'est plus elegant!
d'autres choses aussi... mais pas vraiment cruciale!
tres bon travail d'ensemble quand meme !!! a bientot pour d'autres episodes ?
a+
3 févr. 2004 à 12:32
Bon après maints problèmes j'ai finalement pu poster MacroScript V2 sur cppfrance.
http://www.cppfrance.com/code.aspx?ID=20084
30 janv. 2004 à 16:25
Poste-le sur CppFrance !
Et une nouvelle version de MacEdit, non boguée !
Ah oui aussi ce qui serait pas mal ce serait des fonctions d'entrées/sorties standard; printf/scanf manque ^^
Aussi, je trouve que l'idée des "synonimes" est très bonne : on peut programmer en anglais ou en français, comme ça y'a pas de jaloux :) Par contre ça pourra peut-être compliquer la relecture par qq1 qui n'est pas habitué à ces noms de fonctions-là...
J'ai laissé un message sur le livre d'or ;)
29 janv. 2004 à 17:34
Saleté de SSII qui embauchent des ingénieurs pour des cacahuètes en leur demandant de bosser 70h par semaine...
Ce ptit coup de gueule étant passé, sachez que la version sans bug (enfin j'espere) est en ligne à la même adresse
29 janv. 2004 à 14:05
29 janv. 2004 à 14:01
Par contre je viens de me rendre compte qu'il y avait un bug... je le corrigerai ce soir. La je vais à un entretien d'embauche....'faut pas que je sois en retard....
29 janv. 2004 à 13:54
29 janv. 2004 à 13:52
NOMBRE transforme un Texte en Nombre
FORMATE transforme un Nombre en Texte
29 janv. 2004 à 13:49
29 janv. 2004 à 13:46
En gros c'est le premier élément qui donne le type.
Par ex:
var = "coucou"
"coucou" est un texte puisqu'il commence par ". Donc l'expression est évaluée en tant que Texte
var = 12 + 15
12 est un Nombre puisqu'il commence par un chiffre. Donc l'expression est évaluée en tant que Nombre
var2 = var1*2
le premier élément est var1. Si c'est un nombre l'expression est évaluée en tant que Nombre, si c'est un Texte, l'expression est évaluée en tant que Texte. Si la variable n'existe pas encore, une Erreur est déclenchée.
Dans tes exemples (que je réécris pour être conforme à la syntaxe MacroScript)
var = "589" 17
var = 17 + "589"
var = "abc" 17
var = 17 + "abc"
Le premier : "589" 17 est évalué en tant que texte. La concaténation se faisant avec le caractère ESPACE. Puisque c'est un texte le nombre 17 est transformé en Texte donc var = "58917"
Le second : 17 est un Nombre donc l'expression est évaluée en tant que Nombre. "589" n'est ni une variable ni un nombre -> erreur
troisieme : cf premier -> "abc17"
quatrieme : cf second -> erreur
29 janv. 2004 à 13:38
pr ce qui est de la reconnaissance auto du type, comment gères-tu ces cas-ci:
var = "589" + 17;
var = 17 + "589";
var = "abc" + 17;
var = 17 + "abc";
?
29 janv. 2004 à 13:37
Pour le lancer utilisez MacDebug
29 janv. 2004 à 13:34
Je signale quand même les changments majeurs de MacroScript 2 :
- Il n'y a plus besoin de déclarer les variables. Elles se déclarent automatiquement à l'affectation et le type est déterminé automatiquement
- Les paramètres des fonctions ne sont plus nécessairement des variables. Vous pouvez mettre des valeurs ou des variables indifférement. Par contre vous ne pouvez pas mettre une fonction en argument d'une autre fonction
- De nombreuses nouvelles fonctions. Notamment MAIL, TELECHARGE, CAPTURE (capture d'écran), ETEINDRE, REDEMARRE, FERME_SESSION, manipulation de fichiers, DATE, HEURE, RESOLUTION, ...
- La structure est complétement différente puisque chaque fonction est en fait une DLL. Du coup il est très facile de distribuer une nouvelle fonction. Un projet VC++ 6 tout prêt est diponible.
29 janv. 2004 à 13:12
29 janv. 2004 à 11:08
comme je l'avais annoncé il y a qq semaines je me suis mis à MacroScript 2. Il est dispo en avant-première sur
macroscript.free.fr/cppfrance/MacroScript 2.zip
Le site macroscript.free.fr est en ligne. Vous aurez d'ailleurs besoin de télécharger les fonctions qui se trouvent ici:
http://macroscript.free.fr/downloadExe.php4
pour que MacroScript fonctionne pleinement.
J'attends vos remarques avant de le mettre en source sur cppfrance
16 janv. 2004 à 18:07
Pour faire simple : http://www.boost.org/
16 janv. 2004 à 17:54
16 janv. 2004 à 17:53
On en avait parlé sur un autre code source, je sais plus lequel, et sur MSN aussi certainement.
Juste une remarque, on ne parle pas d'ASM TI mais d'ASM 68000 ou ASM 68k (du nom du processeur Motorola 68000).
Apparemment, si la RTTI est la seule "dépendance" du C++ et qu'elle n'est pas activée par défaut, il doit alors être possible d'écrire un OS en C++ ??
En ce qui concerne le garbage collector, il n'est pas en standard, mais je suppose que le système doit être le même que pour la RTTI : une librairie dynamique... (en fait j'en sais rien mais bon :p)
A parler de standard C++, il paraissait aussi que la librairie Boost devait se voir intégrée au standard dans quelques temps, je sais pas où ça en est.
16 janv. 2004 à 16:49
... passons ...
je sais plus où on a causé de cette histoire d'autonomie, c'était avec funto, ça c'est certain, quand il reviendra faudra lui demander ;-)
16 janv. 2004 à 14:33
Pendant que j'y suis, y quelques options interessantes par la, comme desactive stdafx.h par exemple, pour faire des codes plus portables...
avec DEV-C++, je ne sais pas.
Bon, pour ces histoires de C++ non autonomes, j'ai essaye de me renseigne, j'ai pas trouve grand chose...
Alors, a ma connaissance, la facon d'obtenir un executable en C ou en C++ est excatement la meme (compilation, assemblage, edition de lien).
L'executable est directement comprehensible par la machine.
si on ajoute la rtti, ou autre "run-time" (j'aime pas cet anglicisme), elle sera traite comme toutes les autres bibliotheques dynamiques.
l'editeur de lien (a la premiere edition de lien), met des informations dans l'exe pour qu'il y ait une seconde edition de lien a l'execution.
Lors de cette seconde edition de lien, le lieur dynamique charge en memoire la bibliotheque dynamique, et connecte les pointeurs d'appel de l'exe, aux fonctions de la dll.
donc, d'apres moi, le C et le C++ sont aussi autonomes, mais je peux me tromper!
Kirua, sur quelle page a-t'il ete dit que le C++ n'est pas autonome ?
ca m'intrigue cette histoire (!)
Pour le garbage collector, je sais qu'il en existe, mais y en a-t'il un qui soit incorpore au standard ?
A+
16 janv. 2004 à 10:27
16 janv. 2004 à 07:48
Autre chose, pr la TI, c'est du C parce que TI-GCC est un compilo C, s'il y avait un compilo C++ tu pourrais programmer en C++, puisqu'il s'agit "juste" de convertir le code source en ASM TI, non ??
15 janv. 2004 à 22:28
Pour ce qui est de tout à l'heure, effectivement msvcrt.dll n'a rien à voir avec Linux, je me suis mal exprimé, pardon.
msvcrt.dll = MS Visual C++ RunTime
Et il me semble bien que c'est elle qui se charge de la RTTI.
++fab >> comment on fait pour activer/désactiver la RTTI? (sous Visual C++ et Dev-C++)
Au sujet des garbage collectors, il me semble qu'il en existe un (ou plus?) pour C++, notamment sur la page de Bjarne Stroustrup lui-même :)
Au sujet des cas où le C est obligatoire (par rapport au C++), de ce que je sais :
-pour la programmation sur calculette TI
-pour la création d'un OS (ne doit pas dépendre de runtime...)
14 janv. 2004 à 17:24
question: le C++ et le C sont donc complètement indépendants d'une quelconque Run Time Library? il y a qq jours, sur CPPFRANCE, "il avait été dit que" le C++ n'était pas "autonome" et que de ce fait on ne pouvait pas tjs l'employer, que dans certains cas seul le C pouvait faire l'affaire. (exemple: programme pour un robot)
14 janv. 2004 à 11:16
A* a = //un objet dont on est cense ignore le type a la compilation bien sur
dynamic_cast<&> declenche une exception bad_cast en cas d'echec
dynamic_cast<*>renvoi un pointeur nul en cas d'echec
je pense que c'etait pas clair!
14 janv. 2004 à 00:31
La RTTI (Run Time Type Information), c'est l'identification des types a l'execution.
C'est un mecanisme optionnel, une option de compil donc.
Si vous l'activez, toute classe polymorphe (contenant au moins une fonction virtuelle), se voit ajouter a sa vtbl (table virtuelle), un pointeur sur un objet de type type_info, construit specialement a l'execution pour cela.
C'est un peu plus couteux, et c'est pour cela que ce mecanisme est optionnel.
La RTTI permet donc d'acceder a l'operateur typeid (oubliez, a ne jamais utiliser), et a l'operateur dynamic_cast< >
mettons que la class B derive de la classe A.
On peut naturellement affecter un B* a un A* (upcast)
pour faire le contraire (downcast), il faut utiliser static_cast<> si les types sont connus a la compilation.
dans le cas contraire, il faut faire un dynamic_cast.
ca s'utilise comme ca:
A* a = //un objet dont on est cense ignore le type a l'execution
B* b = dynamic_cast(a);
if(b) //renvoie de la valeur pointeur nul, declenchement de bad_cast pour les references
...//traitement (a est bien de type B)
NB: - si la classe n'est pas polymorphe, la RTTI ne fonctionne pas!
- s'il y a de l'heritage multiple, (C derive de A, et D derive de B et de C), il faut utiliser dynamic_cast a la place de static_cast (passage obligatoire par la vtbl)
- Le dynamic_cast gere l'heritage, a la difference de typeid.
- En general, on realise de bien meilleure conception en utilisant uniquement les fonctions virtuelles, mais dans certains cas, la RTTI est utile ...
C'est a peu pres l'essentiel, je crois.
Ce qui est sur, c'est qu'aucune dll M$ ne fait parti du C++ standard. Apres peut-etre que sous Visual, La rtti est gere par cette dll... aucune idee!
en tout cas, on s'en passe tres bien.
Pour le C, sauf erreur, il n'existe pas de rtti en standard, pas d'interet car pas d'heritage!
Sinon, merci du compliment, j'ai appris a la fac(20%) et tout seul (80%), j'ai avale quelques bouquins, et je developpe quotidiennement car je suis au chaumage...
allez dodo, j'ai une grosse journee demain!
baille :)
13 janv. 2004 à 20:59
lol, si ce que j'ai dit résume "en gros..." ce que tu voulais dire, explicite :-) parce que j'ai dû passer à côté de l'essentiel alors, je vois pas ce que j'aurais pu ajouter.
dis ++fab (on peut t'appeler comme ça? ;-)), t'as l'air de t'y connaître plutôt bien :-D tu as eu une formation particulière ou c'est tout en autodidacte ? (comme bcp ici finalement). et puis, si tu pouvais prendre qq minutes pr faire la lumière sur cette histoire de Run-Time C++, je comprends pas trop (entendu parlé de RTTI et de cette fichue DLL MS, mais je vois pas pq une dll MS serait partie intégrante du C++, c complètement opposé O_o)
13 janv. 2004 à 19:24
corruption de la pile ... Assez epilogue, MacroScript2 (on dirait un film au cine!) sera ecrit avec des passages par reference, et aura une gestion dynamique de memoire, non?
et avec std::basic_string ? bon choix, tiens nous au courant pour qu'on assiste a l'avant premiere!
Bon, un pointeur, c'est une zone memoire qui contient l'adresse d'une autre. S'il n'y en avait pas, cela signifirai que chaque zone memoire serait independante...
ou alors, ce serait les fichiers executables (.class) qui contiendrait tout les liens entre les zones memoires ? Forcement non, ce serait un beau gachis, et je sais pas si ce serait possible!
La seule chose, c'est qu'on ne peut pas les manipuler, bon, c'est bien pour la securite des programmes, mais frustrant pour le programmeur!
OK pour l'aspect performance vu sous cet aspect la. l'optimisation des "algorithme" alors, est cruciale avec Java.
Mon grand reproche a Java, c'est le fait que le garbage (le bien nomme) soit impose.
Il ralentit, commme chacun sait, les programmes, mais c'est plutot la philosophie d'impose qqchose qui m'irrite.
Il me semble qu'un garbage collector etait prevu en standard pour 2003 en C++ ? Je crois qu'il n'y est pas encore...
Le programmeur aurai alors eu le choix de l'activer ou non, voila une approche raisonnable!
Pour ceux qui n'aime pas prendre de risque avec la memoire (bouh femmelettes!), il existe en C++, une class auto_ptr en standard, bof a mon avis
mieux: un pointeur intelligent (smart pointer) utilisant un mecanisme de comptage de reference fait en general l'affaire. (J'essayerai de mettre le mien sur ce site bientot)
son defaut est qu'il ne gere pas les references cycliques, c'est tres couteux, le garbage les gerent, et c'est pour ca que c'est tres lent. Surtout qu'un objet ne va jamais sur la pile (en java)
Kirua: c'est ce que je voulais dire, en gros...
Funto66: Pour optimiser, le mieux est de decrire les algorithmes a l'aide de la std. Ce que tu dis n'est pas evident, mais j'ai du mal a trouver un contre-exemple...
Je te confirme que le noyau Linux est ecrit en C, le runtime M$.dll ? connais pas! et je veux pas etre presente!
A+
13 janv. 2004 à 17:46
13 janv. 2004 à 17:08
Juste un détail pour plus_plus_fab : Linux (et Windows aussi d'ailleurs) n'a pas été écrit en C tout simplement parce que ce n'est pas possible, le C dépendant d'un runtime (msvcrt.dll) ^^. Cependant, comme tu dis, c'est vrai que c'est beaucoup plus dur pour un programmeur de déduire les optimisations que fera le compilo; à la limite, le mieux est d'écrire du code déjà optimisé, comme ça le compilo peut plus optimiser grand chose :p (ouhla, je sens que je viens de dire une connerie moi...)
13 janv. 2004 à 16:43
bonne continuation en tt cas ;-)
13 janv. 2004 à 16:31
Pour const je me suis documenté et j'essaierai de m'en servir à l'avenir.
Par contre je me dois de défendre le Java! Premièrement je rappelle qu'il est faut de dire que les pointeurs n'existent pas en Java : au contraire ils sont partout ! (bon ils sont masqués mais ils existent ;)
Mais je suis d'accord qu'il est impossible de manipuler la mémoire aussi facilement qu'en C.
Par contre je trouve au contraire que l'aspect "performance" est bien plus important en Java qu'en C. En effet un algo qui est 2 fois plus lent qu'un autre en C : ça ne se voit pas : 0.00001s contre 0.00002s ! En Java en revanche, la machine virtuelle ralentit tout, donc il faut optimiser!
Et pour ce qui est des destructeurs... c'est l'une des choses qui font que Java est un très bon langage... Ils ont trouvés un moyen de ne pas se taper à chaque fois les delete dans les destructeurs... C'est pas génial pour le programmeur ? (D'ailleurs ce principe de Java comme de nombreux autres ont été repris dans C#)
Et comme tu le dis en se souciant moins des aspects de gestion de la mémoire on peut davantage se consacrer à la POO.
Pour information : Suite aux pressions du lobby anti-microsoft et pro-lib standard, j'ai décidé de faire MacroScript 2 sans CString. La structure du prog est complétement différente, il y a de nouvelles fonctions, et le langage a été encore simplifié. Je n'en dit pas plus pour le moment parceque je ne sais pas quand ça sera fini, j'ai commencé hier....
13 janv. 2004 à 16:13
En reponse a garslouche,
Lorsque tu passes des arguments dont tu ignores a priori la taille (Ces fameux CString...), il faut considerer qu'il sont gros!
il vaut mieux utiliser un passage par reference dans ce cas.
pour le mot-clef const: il s'utilise a de nombreuses sauces...
je parlais de const pour ce qui est des fonctions membres, ex:
la fonction void MaClasse::print(); ne modifie pas l'objet cree par MaClasse, alors je la declare ainsi:
void MaClasse::print()const; (le const fait parti de la declaration)
Ainsi, tu es plutot javanais ? Le "probleme" avec Java, c'est qu'on est bride au maximum, impossible de gerer la memoire, impossible de parler de pointeurs, et presque aucune instruction destine a la JVM pour demander des optimisations ,sauf "final", pour les constantes et les classes(contraignant).
Du coup, quand on passe au C++, on ne pense plus "performance", et on fait des programmes moins bons a mon sens.
Et on a tendance a oublier de programmer les destructeurs... (c'est de coutume, meme s'ils ne font rien)
Par contre, on acquiers une bonne culture objet, c'est l'avantage.
OK pour #pragma once, mais ca ne respecte pas le standard, comme tu le dis en fait...
OK pour cosinus!
pour funto66, et le #define:
utiliser enum pour un nouveau type, OK. On peut aussi l'utiliser de maniere anonyme.
par contre, pour definir une constante, je n'utilise pas non plus #define, il faut se poser la question si cette variable peut etre une variable de classe (static) ?
Si oui, alors c'est souvent une bonne solution de la declarer ainsi. Elle pourra alors etre specialise si la classe a laquelle elle appartient est un modele, ou eventuellement accedee publiquement par l'instance de la classe ou d'une classe derivee...
dans le pire des cas, on cree une constante d'espace de nom. Jamais de global, hein ?
D'une maniere generale, il vaut mieux, en C++, se concentrer sur la conception, permettre au compilateur d'optimiser (via const notament), et finalement laisser le soin au compilateur
d'optimiser...(Ainsi que l'editeur de lien, c'est lui qui s'occupe des constantes)
D'ailleurs, Le noyau Linux n'est pas ecrit en C++ (en plus du fait que la compilation est plus lente qu'en C), notament en raison de la complexite de ce langage, et des optimisations agressives et imprevisibles des compilateurs (notament pour les classes virtuelles)
->trop complique pour le commun des mortels, et meme pour les demi-dieux Thorvalds & Cox !!!
bye
10 janv. 2004 à 15:52
PS: j'avais envie de dire ça, c'est venu comme ça... faut dire que je viens de me lever ^^
10 janv. 2004 à 11:18
Je vais corriger ton code et recompiler l'interpréteur alors, merci pour le débogage ;)
En ce qiu concerne le débat const vs #define vs enum; j'avais déjà fait un même débat sur ce site ^^ Pour ce que vient de dire Kirua, je ne suis pas sûr que le compilo n'optimise pas directement en remplaçant 2 par 2.0f lorsque tu fais par exemple "float var=2;" ;la conversion serait inutile. Au niveau du principe, je pense que les enum valent bien les #define (sauf pour les nombres à virgule, bien sûr), mais personnellement je ne les utilise pas dans les mêmes cas : j'utilise enum pour créer un nouveau type, et #define pour les constantes. Pour ce qui est du mot-clef const (pour une déclaration en global), en fait son désavantage par rapport à enum c'est qu'il crée une variable qui n'a pas de droit de changer, donc qu'il prend de la place mémoire pour rien (il peut être remplacé par une valeur immédiate). Cependant, il permet au compilo de contrôler les types et ces constantes peuvent être passées par pointeur ou par référence (encore que je ne vois pas trop l'intérêt...). D'ailleurs, je me demande si une des optimisations du compilo ne serait pas de justement remplacer par la valeur directe, à la façon d'un #define, si l'on ne demande nulle part l'adresse de la constante.
Et puis, pour le contrôle des types :
#define PI 3.1415f
ou
const float PI = 3.1415f
ne revient pas au même? Le compilo fera le même contrôle des types...
Waow, je vois que j'ai écrit beaucoup dis donc lol
PS hors-sujet : j'en ai MARRE de devoir poster plusieurs fois le même commentaire sur CppFrance ! ça vous le fait pas à vous?
9 janv. 2004 à 21:18
ben si justement il y a ambiguité :-) si tu veux forcer le float dans un calcul mais que ton nombre est 2, tu dois absolument écrire 2.0f, ou bien (float)2. sinon ça peut éventuellement être mal interprêté.
9 janv. 2004 à 20:38
Merci pour ces commentaires très constructifs.
Je vais quand même m'efforcer d'y répondre...
Pour CString on peut dire ce qu'on voudra, n'empêche que c'est une très bonne classe dans la mesure où elle est très facile à utiliser. Après peut-être que sa gestion de la mémoire et sa vitesse ne sont pas optimales mais honnetement rares sont les projets où cette vitesse est vraiment primordiale. En fait à part les projets temps-réel je n'ai jamais rencontré un cas où c'est discernable "à l'oeil nu".
Ceci-dit ce qui me pousse à utiliser les CString c'est aussi l'habitude tout simplement.
Pour le passage des arguments par valeurs, c'est vrai que j'aurais du utiliser les pointeurs. Mais il ne s'agit que de petits objets.
L'utilisation des gros tableaux est effectivement assez calamiteuse. C'est une des choses qui sera changée si je fais MacroScript 2. On en a d'ailleurs parlé avec Kirua sur la source de l'Editeur de MacroScript (http://www.cppfrance.com/code.aspx?ID=17852)
Pour le mot-clé const...c'est bien possible ! Je ne sais pas trop comment m'enservir. A vrai dire je ne suis pas un pro en C++. En fait je fais plutot du Java à la base. (C'est peut-être pour ça aussi que j'utilise les CString)
Pour l'utilisation d'enum à la place de #define, j'ai lu plusieurs débats à ce propos et j'en ai conclu que ça revenait strictment au même et que chaque programmeur devait faire ce qui lui plaisait le plus. Ceci-dit je dois reconnaitre que je préfére enum mais à l'époque je n'y avais pas pensé.
Pour ce qui est des headers, les lignes
#ifndef HEADER_H
#define HEADER_H
...
#endif,
peuvent avantageusement être remplacée par
#pragma once
(uniquement avec VC++)
Pour la classe Calcul, je suis tout-à-fait d'accord qu'elle peut largement être optimisée. D'ailleurs j'ai vu sur ce site une source qui fait ces opérations bien mieux que moi. En fait j'avais juste envie d'appliquer l'algo auquel j'avais pensé.
Par contre l'utilisation de cosinus et sinus n'a pas d'interet ici. En effet un des principes de MacroScript est de bannir l'utilisation des fonctions à l'intérieur des paramètres. Ainsi pour calculer un cosinus il faudrait faire qqc comme:
DECLARE a, nombre
DECLARE cos_a, nombre
a=12
COSINUS a, cos_a
Par contre je confirme que stdafx me casse les cou.......des
9 janv. 2004 à 19:34
Pour les define par contre je ne vois de problème. Il n'y a pas plus d'ambiguité float/int que quand on écrit 1 ou 2 directement dans le code!
9 janv. 2004 à 19:27
et pareil pr la STL puisque tu en parles ^^
utiliser des consts au lieu de define est très avantageux: les variables sont typées, et donc le compilo sait exactement ce que tu en attends. les define du preprocesseur opèrent juste des remplacements, donc l'ambiguité float/int etc est réelle et génante !
je commente les commentaires, super ^^
9 janv. 2004 à 14:54
Tout d'abord, felicitation pour ton code !
C'est plutot clair a comprendre (a mon avis), car le code est bien organise, et on comprend rapidement, en gros, ce dont il s'agit. Pour une fois que je vois un code ecrit uniquement en P.O.O, j'apprecie !
Ca change agreablement des habituelles usines a gaz ou autre conplexes petro-chimiques !!!
J'ai juste quelques petites remarques :
- Dommage que tu utilises CString, tu trouves que la classe std::string est incomplete ?
Moi, elle me satisfait pleinement. Normalement, tout y est, et de maniere optimise (gestion des chaines courtes, mecanisme de copie sur ecriture ...). Tu peux avoir besoin de l'entete pour certains traitements. Bon, c'est quand meme Stroustrup en personne,et J.Shopiro qui ont ecrit cette classe. Ce serait leur faire insulte que de dire qu'une classe microsoftienne surclasse basic_string !
- Concernant le passage des arguments dans tes fonctions, utilises "const Type&", au lieu de "Type" lorsque sizeof(Type) > 4 octets (generalement). Ca evite une copie qui peut etre couteuse...
- Dommage qu'il n'y ait pas une gestion dynamique de la memoire, j'ai vu des gros tableaux (512,1024)
c'est tres couteux en utilisation de la memoire, et tres couteux en efficacite lorsque tu passe tes tableaux par valeur (remarque precedente). Utilise std::vector (entete <vector>) par exemple, c'est simple d'emploi et tres efficace.
- Une fonction membre doit etre declare const, si celle-ci ne modifie pas l'objet (a moins que ne traine le mot cle "mutable"...) . Ca permet au compilateur d'optimiser.
- en C++, normalement, on utilise rarement le preprocesseur, #define LIGNE_SAUT 0,...,par exemple, peut-etre remplace par un enum (static) dans la classe qui l'utilise. La macro peut surement etre reecrite dans un header, avec les mots cles inline,template (en temps que membre private/protected)
- il vaut mieux commencer un header (header.h ici) par
#ifndef HEADER_H
#define HEADER_H
et finir par #endif,
tres conseille, quand on compile a la mimine!
Voila voila pour les remarques "de forme", concernant le code lui-meme, j'ai pas tout lu, et je te fais confiance! pour la classe Calcul, je pense qu'on peut faire mieux concernant l'algo d'evaluation de l'expression, parce ce que si tu ajoutes une fonction du genre sinus, exposant, alors tu dois modifié "profondement" le code de ta fonction getValeur, ca me parait etre un defaut, mais bon... Tiens j'essayerai de le faire 12c4...
NB: C'est quand meme la pagaille toutes ces microsofteries "stdafx et Cie" !
Allez, bon courage, bonne prog !
A+
9 janv. 2004 à 09:44
C'est une erreur de parenthesage dans mon code :
void Script::F_Si (CString params[], unsigned nParams) {
CString condition = params[0];
// Recherche de l'opérateur
int pos;
int comp;
if ( (pos = condition.Find("<=")) > -1)
comp = 0;
else if ( (pos = condition.Find(">=")) > -1)
comp = 1;
else if ( (pos = condition.Find("<")) > -1)
comp = 2;
else if ( (pos = condition.Find(">")) > -1)
comp = 3;
else if ( (pos = condition.Find("=")) > -1)
comp = 4;
else
{
Erreur("Condition de la fonction SI invalide.\nUtilisez = < > <= >=");
return;
}
....
Avant je mettais
pos = condition.Find("<=") > -1
mais en fait pos valait TRUE ou FALSE (càd 1 ou 0), du coup pour ta variable pos_x il prenait le premier caractère : p pour la premiere variable....
Je mettrais la source à jour bientot. Mais là je suis occupé à chercher du boulot....
Ceci-dit pour ton programme il ne fait rien car par défaut les variables de type nombre valent 0. Du coup le premier SI envoie à test_pos_y, le second SI envoie à fin_prog....et c fini !
8 janv. 2004 à 23:38
Le code :
// PosCurseur.mac
DECLARE pos_x, nombre
DECLARE pos_y, nombre
DECLARE str_x, texte
DECLARE str_y, texte
DECLARE msg_constant1, texte
msg_constant1="Positionnez le curseur en (0;0) et faites OK pour quitter.\nLe curseur est en ("
DECLARE msg_constant2, texte
msg_constant1=";"
DECLARE msg_constant3, texte
msg_constant1=")"
DECLARE msg_final, texte
DECLARE var_zero, nombre
var_zero=0
LIGNE debut_boucle
SI pos_x=var_zero, test_pos_y, affichage_position_curseur
LIGNE test_pos_y
SI pos_y=var_zero, fin_prog, affichage_position_curseur
LIGNE affichage_position_curseur
POSITION_SOURIS pos_x, pos_y
FORMATE str_x, pos_x, 0
FORMATE str_y, pos_y, 0
CONCATENE msg_constant1, str_x, msg_final
CONCATENE msg_final, msg_constant2, msg_final
CONCATENE msg_final, str_y, msg_final
CONCATENE msg_final, msg_constant3, msg_final
MESSAGE msg_final
VA_A_LA_LIGNE debut_boucle
LIGNE fin_prog
Voilà, si ça vient du code, est-ce qu'on pourrait m'éclaircir merci :)
29 déc. 2003 à 04:21
JVAIS LIMPRIMER ET LETUDIER A MAX POUR MA CULTURE PTETE KE JVAIS EN FAIRE UN OSSI MOI LOL
merci bcp :-) bon jen fait pas trop non plus. =)
29 déc. 2003 à 04:08
28 déc. 2003 à 21:32
ca fait quasiment peur!!! :)))
en tout cas bravo pour ton excellent travail... moi aussi j'attend apres l'editeur!
13 nov. 2003 à 00:55
12 nov. 2003 à 22:05
Bon bah c'est pas grave je recommence...
Merci beaucoup pour ces compliments, ça me touche. C'est la première fois que je gagne un trophé. C'est très émouvant. Je tiens à remercier mon producteur ainsi que mon attaché de presse sans qui je ne serais pas là ;)
Blaques à part ça fait vachement plaisir!
Merci encore
11 nov. 2003 à 23:16
http://www.cppfrance.com/trophees.aspx
11 nov. 2003 à 23:06
c genial ton truc!!!!
programme complet, fiable, genial! :D
je met 10!
25 oct. 2003 à 19:07
Pour évaluer les expressions mathémtiques c'est en cours, j'ai fait l'algo il faut juste coder. Les commandes de saut sont aussi une extension possible mais j'hésite un peu : le if, for et le while ne sont pas vraiment dans l'esprit de MacroScript puisque ce ne sont ni des variables ni des fonctions. Je pensais tout-de-même implémenter un if simplifié et utiliser les goto. Je m'y mettrais dans quelques temps. Pour l'instant je bosse sur l'éditeur en couleurs, il devrait être dispo bientot.
25 oct. 2003 à 18:05
une petite info sans importance: l'extension .mac est déjà utilisée par CabriGéomètre (logiciel de dessin mathématique), mais je ne pense pas que bcp de gens de cppfrance disposent de ce logiciel.
J'aime bcp tout code en tt cas, n'importe qui peut scripter facilement, tu en as vraiment fait un langage User Friendly, je crois qu'en ce sens tu as atteinds l'objectif principal, et puis d'après ce que j'ai lu ds ton ReadMe, on peut réellement facilement ajouter des fonctions, c'est super ;-)
j'ai une question: est-ce que tu as une fonction pr évaluer une expression? 5+3*2 par exemple.
mais comme je ne vois pas de commandes de saut (if, for, while, goto...) je suppose que tu n'en as pas eu besoin. C'est mieux ainsi, bien plus simple ^^ mais peut-être utile à ajouter si tu voyais dans ce programme plus qu'un exercice, et réellement une application.
je te félicite pour ce travail, et je cote 9/10.
Ciao ;-)
25 oct. 2003 à 12:33
wxWindows, c'est en fait le MFC open source, mais en mieux ^^
C'est sous une license proche de la LGPL et c'est portable sous Windows, Mac, Linux, où ça reprend à chaque fois le look and feel de l'OS, parce que ça utilise l'API Win32 sous Windows, GTK+ sous Windows ou Classic sous Mac. Je te conseille de l'essayer, d'autant plus que t'as un composant spécial dedans (Scintilla) qui te permet de créer une zone de texte avec coloration syntaxique (c'est prévu pour ça) ;)
http://www.wxwindows.org
http://www.scintilla.org
Et dsl pour la note, j'avais oublié lol maintenant c'est rectifié ;)
24 oct. 2003 à 17:13
Pour Funto66 : si tu veux créer un langage tout dépend du genre de langage que tu vises! Si c'est un truc un peu compliqué oublie mon code et utilise Lexx et Yacc. Je ne m'en suis servi qu'une fois (pendant mes études) et je ne maitrise pas trop mais c'est vraiment puissant. En revanche si c'est un langage simple tu peux t'inspirer de ce que j'ai fait : en fait ce langage évite la plupart des difficultés : les arguments des fonctions ne sont que des variables, on ne peut pas faire d'opération sur les nombres (genre a=(5*8+2) ou même a=1+1). Mon but en faisant ce langage était que ce soit simple à utiliser et facile à mettre en oeuvre. Je te conseille de voir les simplifications que tu peux faire à ton langage pour simplifier sa programmation (surtout si tu n'en a jamais fait!).
Pour NString j'ai regardé ça a l'air sympa. wxWindows : connais pas. Qt c'est chouette mais j'ai mes petites habitudes ;) . Quant à la lib standard elle est un peu insuffisante à mon goût.
Pour la note de 10/10 c'est sympa...mais il faudrait la mettre (dans la partie grise à gauche)...
---------------------------------------------
Pour EtLaBanana : Ravi que ça te plaise! Pour fermer les fenêtres c'est une bonne idée, je vais y travailler!
Pour l'éditeur j'espere le faire assez rapidement ça ne devrait pas être trop difficile je pense. Et je t'en informerai.
24 oct. 2003 à 16:53
Exactement ce que je cherchais! En plus je voulais asavoir comment on simule une action au clavier!! Trop cool !
Quand tu auras fait l'éditeur je le veux!
PS: Tu pourrais ajouter un truc pour fermer les fenêtres, parceque simuler ALT+F4 c'est un peu limite....
24 oct. 2003 à 16:09
félicitations, je trouve ton prog super bien fait, et en plus ça peut être utile ;)
j'essaie de créer un langage aussi en ce moment et c'est pas facile...
J'ai regardé le code, tout en POO, c'est bien fait, rien à dire, à part l'usage des MFC lol
C'est clair que les CString t'as pas l'air de pouvoir t'en passer....
Mais t'as des alternatives : NString, de ce site, est super; std::string, de la bib standard (c'est ce que j'utilise ;) ), wxString de wxWindows ou QString de Qt....
Bon, ben voilà, et ton idée de créer un éditeur coloré est super ;)
Je te mets 10/10 pour le boulot fourni :)