Aide sur pointeurs et array en C - C - Programmation
Marsh Posté le 07-07-2016 à 13:12:54
Il serait bien de donner un exemple compilable...
>char *string = "";
>strcat(string,
Faudrait réserver de la mémoire avant... Autrement dit char *string=malloc(...) ou realloc(...) plus test si succès ou alors char string[<nombre>]; si la place nécessaire est connue au moment de la compilation.
Tes <machin>Pointer sont inutiles. Si tu déclares un tableau char tab[42] alors tab est un pointeur sur ce tableau. Autrement dit tu peux faire directement
>int length = getCharPointerSize(hexChar);
(D'autant plus que dans l'état actuel je vois un warning: tst.c:8:28: warning: initialization discards 'const' qualifier from pointer target type [enabled by default])
D'Ailleurs, dans le cas présent: int length = sizeof(hexChar)/sizeof(char)-1; mais attention, cela ne fonctionne plus dans une fonction à laquelle tu auras passé un pointeur vers hexChar. Tu peux aussi utiliser int length = strlen(hexChar); qui fonctionnera toujours à condition d'avoir une chaine de caractères (donc terminée par '\0'). Rajouter #include <string.h>.
Marsh Posté le 07-07-2016 à 13:47:19
Donc je fais :
Code :
|
rat de combat a écrit : Il serait bien de donner un exemple compilable... |
Marsh Posté le 07-07-2016 à 14:00:49
Bon... Explique nous avec des mots ce que tu veux faire. Ton code est loin d'être compilable.
Tu as activé les warnings de ton compilateur? gcc: Rajouter -Wall comme paramètre.
Marsh Posté le 07-07-2016 à 14:11:53
Bien simplement donner toutes les permutations des 16 chars hexadécimaux en 12 char hexadécimaux.
Je veux utiliser le fait que travailler sur des 0x.. serait plus rapide que de faire les "bêtes" permutations d'une chaine de caracteres que l'on trouve partout et qui sont très lentes
Ce code vient de mon code en java qui fonctionne, et je le souhaite en C pour des qestion de rapidité
Marsh Posté le 07-07-2016 à 23:52:28
Merlin66 a écrit : Bien simplement donner toutes les permutations des 16 chars hexadécimaux en 12 char hexadécimaux. |
ce qui doit donner 16**12=2,8*10**14 possibilités... Si c'est pour craquer un code ( ) ton ordi aura fort à faire...
Citation : Je veux utiliser le fait que travailler sur des 0x.. serait plus rapide que de faire les "bêtes" permutations d'une chaine de caracteres que l'on trouve partout et qui sont très lentes |
Pas compris... C'est quoi le format final dont tu as besoin?
edit tardif: Tu es conscient que là justement tu travailles sur des chaînes de caractères?
Marsh Posté le 08-07-2016 à 08:46:29
Merci de ta réponse, et oui je suis conscient :
- du nombre de possibilités (mais entre 3% d'usage du processeur en java et 50% d''utilisation en C
- et que cet algo utilise les char malheureusement.
en entrée j'ai besoin d'un :
uint8_t keys[6] = {0x00, 0x11, 0x22, 0x33, 0x44, 0x55}; (par exemple pour les valeurs)
Marsh Posté le 08-07-2016 à 09:17:02
Si tu veux aller vite, il vaudrait mieux te tourner vers du CUDA (CG Nvidia) ou son équivalent chez AMD et rendre ton algo parallélisable
Sinon, utiliser un algo appelé MapReduce (domaine du big data). dans tous les cas, il faudra avoir un algo parallélisable si tu veux de la perf.
Marsh Posté le 08-07-2016 à 14:42:22
16^12 = 281 474 976 710 656 combinaisons. C'est pas avec ton petit Androïd, comme tu dis, que tu vas y arriver en un temps "raisonnable"
Tu veux faire quoi en fait ? Que cherches tu à trouver avec ces combinaisons générées ?
Marsh Posté le 08-07-2016 à 17:44:54
Merlin66 a écrit : en entrée j'ai besoin d'un : |
Alors c'est complètement inutile (et même idiot au niveau perfs) de s'embêter avec des chars! Un caractère héxa = 4 bits complets, soit deux caractères = un octet complet. Tu peux simplement faire un compteur sur 6 octets pour parcourir l'ensemble des clés.
La méthode la plus directe c'est des boucles imbriquées:
Code :
|
Comme on veut parcourir toutes les valeurs possibles d'un uint8_t on ne peut pas le mettre directement dans l'en-tête de la boucle. Je passe par un autre tableau de int mais je me demande si il n'y a pas plus élégant.
Dans le printf() j'ai mis \r à la fin et non \n, c'est à dire retour au debut de la même ligne et non saut de ligne pour ne pas perdre trop de temps avec l'affichage. Attention, ce dernier est quand même très gourmand en temps, il faut absolument l'éviter dans le code final (en tout cas à cet endroit)!
On peut certainement optimiser d'avantage en passant à l'assembleur.
Reste à dire que même avec ça tu ne vas pas aller loin (surtout sur du Android) si il faut parcourir l'ensemble des possibilités...
Marsh Posté le 08-07-2016 à 18:06:33
Je viens de faire autre chose,
J'ai même pas eu l'info que tu me donnes avant, je testerais quand même !
Merci de ton aide précieuse en tout cas
Code :
|
Je pense qu'on peux faire encore mieux, mais je commence à avoir une résultat simple à lire et assez (pas assez) rapide.
rat de combat a écrit :
|
Marsh Posté le 08-07-2016 à 18:34:35
Ceci devrait coller, à adapter selon ses besoins.
Code :
|
C'est peut être optimisable.
A+,
Marsh Posté le 08-07-2016 à 23:19:54
Merlin66 a écrit : Je viens de faire autre chose,
|
Vu le nb de combinaisons, je te déconseille fortement de faire un algo récursif C'est un coup à faire péter la pile
Marsh Posté le 09-07-2016 à 00:36:18
Et une version C++11
Code :
|
A+,
Marsh Posté le 09-07-2016 à 00:42:46
rufo a écrit : |
A la louche s'il empile 281474976710656 appels, avec 4 ou 5 Peta Octets de Ram, ça peut passer...
A+,
Marsh Posté le 09-07-2016 à 11:49:59
gilou a écrit : C'est peut être optimisable. |
C'est.
Code :
|
A+,
Marsh Posté le 09-07-2016 à 12:12:25
C'est effectivement plus rapide que ma récursion :
0x0001FFFFFFF
Took 389.173279 seconds to execute (au lieu de 550)
De plus j'avais des soucis avec la version C++11 (android studio n'aime pas mélanger tout pour le moment)
Merci Gilou !
PS Je pense que le modulo 16 peut être amélioré (j'avais trouver un truc pour mon arduino à ce propos)
gilou a écrit :
|
Marsh Posté le 09-07-2016 à 19:25:44
A ce niveau, ce qui est couteux, c'est le printf à chaque étape.
Si on peut se permettre de bufferiser et écrire à l'écran toutes les n lignes (avec un n optimal à déterminer, dépendant probablement de la taille du buffer interne du printf) on doit pouvoir gagner pas mal.
> Je pense que le modulo 16 peut être amélioré (j'avais trouver un truc pour mon arduino à ce propos)
On peut tenter ici:
r[i] += 1;
if (r[i] == 16) r[i] = 0;
ou bien
r[i] = (r[i] == 15)?0:(r[i] + 1);
et voir si c'est plus efficace.
A+,
Marsh Posté le 10-07-2016 à 02:06:43
C'est sur qu'elle marche, mais écrire 12 boucles imbriquées...
Alors que ça c'est générique vis a vis du nombre de chiffres du résultat:
Code :
|
A+,
Marsh Posté le 13-07-2016 à 12:34:26
Je reviens pour m'excuser, j'ai oublié une chose essentielle...
Le test d'une clé prend en moyenne 3ms
La vitesse de l'algorithme n'est donc pas essentielle.
Désolé, je me sent ballot.
Malgré tout, je garde les codes sous le coude, notamment les moins gourmand en mémoire.
Marsh Posté le 13-07-2016 à 14:20:19
gilou a écrit : C'est sur qu'elle marche, mais écrire 12 boucles imbriquées... |
6 Je n'ai pas dit que c'était beau...
Citation : Alors que ça c'est générique vis a vis du nombre de chiffres du résultat: |
Certes, mais plus rapide? Enfin bon, de toute façon vu le nombre de possibilités (et vu qu'un test de clé c'est 3ms soit maxi 333 tests/s) c'est une question purement théorique. Mais c'est quand même intéressant, surtout si on fabrique une version assembleur aussi.
Marsh Posté le 07-07-2016 à 11:41:57
Bonjour j'aurais besoin d'aide avec les pointeurs et les tableaux, je suis un peu perdu et rouillé