Sujet Précédent Sujet Suivant

Decompilation Fichier TI .83p de TI 82 stats.fr ou 83,83+

ccgousset Messages postés 150 Date d'inscription samedi 1 août 2009 Statut Membre Dernière intervention 4 mars 2023 - 12 juin 2015 à 13:09
ccgousset Messages postés 150 Date d'inscription samedi 1 août 2009 Statut Membre Dernière intervention 4 mars 2023 - 17 juil. 2015 à 13:26

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/101062-decompilation-fichier-ti-83p-de-ti-82-stats-fr-ou-83-83

ccgousset Messages postés 150 Date d'inscription samedi 1 août 2009 Statut Membre Dernière intervention 4 mars 2023
17 juil. 2015 à 13:26

J'essaie de ce pas Captaine. L'expansion des macros et l'option pour ++11. Merci de tes conseils.

cptpingu Messages postés 3837 Date d'inscription dimanche 12 décembre 2004 Statut Modérateur Dernière intervention 28 mars 2023 123
11 juil. 2015 à 13:59

Bien différencier chaîne vide (donc un pointeur non nul, qui pointe sur une seule case contenant 0), d'un pointeur nul (pointeur valant 0).
NULL est une macro qui vaut 0 (0 et NULL, c'est absolument et strictement la même chose). Tu peux d'ailleurs remplacer: int i = 0; if (i == NULL) et tu verras que ça fonctionne. Tu peux le voir en faisant un gcc -E sur ton fichier (c'est une commande qui remplace les macros par leur valeur véritable). En faisant un "gcc -E monfichier.cc", tu verrais alors int i = 0; if (i == 0).

nullptr vaut aussi 0, la seule différence, c'est que le compilateur le traite différemment, de manière à ce que la surchage se fasse bien. Si tu as gcc 4.5, alors tu as accès au C++11. Il te suffit d'ajouter l'option -std=c++11, ce que je te conseille de faire (meilleurs performances, accès au nullptr, accès au foreach, STL plus complète, etc...).

ccgousset Messages postés 150 Date d'inscription samedi 1 août 2009 Statut Membre Dernière intervention 4 mars 2023
10 juil. 2015 à 17:20

Oui avec 0 ca marche mais ce nest pas logique car meme en c++ argv pointeur de chaine egal a seulement par 0 par convention . Cad fin de chaine, donc chaine vide a tel point que le compilo me renvoie une valeur <null> a l affcihage pour une chaine vide sur cette ligne de commande .. (gcc 4.5 ) . // 01 - ligne de commande --> argv[0] C:\Akis\b150703\BolosR.exe
01 - ligne de commande --> argv[1] src.tib
01 - ligne de commande --> argv[2] (null) <<<<< la en fait
et le nullptr inexistant dans mon systeme .
voila je regarde le topo preconisé .

cptpingu Messages postés 3837 Date d'inscription dimanche 12 décembre 2004 Statut Modérateur Dernière intervention 28 mars 2023 123
9 juil. 2015 à 15:58

Pour les listes, je n'avais pas vu que tu différenciais les commandes qui prenait un et deux tokens. Au temps pour moi, tu as raison.

0 en place de NULL pour la ligne de commande ca marche et je comprends pas bien

Si tu me précises un peu plus cette remarque, je devrait pouvoir l'expliquer plus clairement.

ccgousset Messages postés 150 Date d'inscription samedi 1 août 2009 Statut Membre Dernière intervention 4 mars 2023
9 juil. 2015 à 15:49

0 en place de NULL pour la ligne de commande ca marche et je comprends pas bien pourquoi ... je cherche mais t as raison Pingu .

ccgousset Messages postés 150 Date d'inscription samedi 1 août 2009 Statut Membre Dernière intervention 4 mars 2023
9 juil. 2015 à 14:27

Merci pour ton merci et tes remarques tres justes. L instanciation qui sert a rien car le prog était c++ a l origine. tu as raison je programme a la chevrotine . Cependant Capitaine les tokens dans une seule liste implique un moyen (au pire un denombrement) pour reconnaitres celles qui acceptent en parametre un ou deux octets . Sinon je suis daccors avce toi et notamment la couleur de console inutile ici. Merci

cptpingu Messages postés 3837 Date d'inscription dimanche 12 décembre 2004 Statut Modérateur Dernière intervention 28 mars 2023 123
19 juin 2015 à 12:28

Bonjour.

Un projet original, ça change, bravo.

Quelques remarques sur le code:

Évite les "using namespace", voir: http://0217021.free.fr/portfolio/axel.berardino/articles/bon-usage-using-namespace
Évite "NULL" en C++ (au profit de 0 ou mieux nullptr si tu es en C++11). Voir: http://0217021.free.fr/portfolio/axel.berardino/articles/null-en-cpp
Au lieu de faire un "collection.length() == 0", préfère un "collection.empty()". C'est algorithmiquement garantie en O(1) dans les specs, ce qui n'est pas le cas de "length()".
Pourquoi balancer du char* à tout va, alors qu'on a des std::string, des std::ostringstream, des StringRefs, et plein d'outils de manipulation de chaînes en C++ ?
Les attributs console c'est sympa, mais tu perds la portabilité pour une fonctionnalité dispensable (ne compilera pas sous Linux). Une directive de compilation pour les retirer si l'OS n'est pas Windows serait pas mal.
L'extension d'un header en C++ est généralement .hh ou .hpp, le .h étant plutôt réservé à du C.
En C++, une struct *est* une classe, et la syntaxe du C n'est pas nécessaire.

Ex:

typedef struct
{
  unsigned short token;
  size_t sz;
} token_t;

En C++, s'écrirait plutôt:

struct token_t
{
  unsigned short token;
  size_t sz;
};

Au lieu de passer du "std::string", passe du "const std::string&", sinon tu fais des copies inutiles.
Il reste des morceaux de codes qui trainent, qui n'ont pas d'effet, comme: "if(!fp) {}".
Il y a aussi des morceaux de codes utilisés, mais peu utiles, comme: "Compiler *pCompiler = &compiler;"
Un std::ostream se ferme tout seul. Le f.close() n'est donc pas nécessaire.
Les structures Token et TwoByte peuvent être remplacés par des std::string.
Un seul tableau avec tous les opcodes est suffisant.
Petite bizarrerie du code: Tu mets dans un grand tableau, en const, tous les opcodes (ce qui est bien). Mais au lieu de te servir du tableau, tu copies celui-ci dans une std::map ? Étant donné que ton tableau est continu, n'as (presque) pas de trou, il n'y pas besoin de std::map. Un accès direct sur le tableau (que tu remplis trié au préalable) aura le même effet en plus rapide (ça sera du O(1) contre du O(log(n) actuellement), et en prenant moins de ram. Tu pourrais alors faire ceci: StandardTokens[ZOOMOUT] (qui te retournerait "ZoomOut").
Dans ton système de log, tu confonds "severity" et "source". Une severity c'est généralement: debug, info, warning, error, critical. Une source représente le composant ou l'action: main, decompiler, hash, compiler, etc... C'est l'association de ces deux informations qui te permet de finement logger (et d'avoir le choix de ce que tu veux afficher). Un log prend usuellement 3 arguments: severity, source, message.
Pas besoin de faire N printf pour afficher une seule chaîne. Un seul std::cout (ou même printf) suffit. Car en C ceci: "cou" <saut de ligne ou espace> "cou", est équivalent à ceci: "coucou". En gros, si tu mets des chaînes côte à côte (espaces et sauts de lignes sont ignorés), le compilateur les concatène pour toi.
La méthode "decompile" est assez étrange. La fonction renvoie toujours vrai, il y a des "magic value" (ok - 3, 1 et 2), un coup les variables sont initialisées au moment de la déclaration, un coup elles le sont après et il y a un label de goto non utilisé qui traine. Je pense que tu compiles sans les flags de warning (où que tu les ignores).

Discussions similaires

logiciel pour lire un fichier .class

Ouvrir un fichier java

Lire informations fichier class dans un programme java

calculatrice

Lecture fichier plat, Accent

Votre réponse

Discussions similaires