Ubuntu-fr

DevraisJamaiscoder

[C++][NTL]projet

Salutation!

Je suis sur un projet qui utilise la NTL... NTL que j'ai donc installé et qui marche très bien sur des exemples simples.

Du coup, j'essaye tranquillement de lancer mon projet avec les premiers testes... Le truc, c'est que quand je compile ce que j'ai fait, ça coince pas, mais l'application crée me donne un truc... Assez étrange...

La fonction est (notez que OUI, je sais qu'elle est sale... Mais mon but et surtout de voir comment ça marche! Je me suis aussi permis de mettre que ce qui semble utile... Le Makefile ne semble pas en cause par exemple).

NB : je sais où est leereur elle même, c'est le résultat que je ne comprend pas!

ZZ fonction(ZZ a,ZZ b){
    ZZ rend[1];
    ZZ *pointeur=rend;

    rend[0]=a;
    rend[1]=b;
    
return a;
}

et ce que j'éxécute dans le main :

     ZZ a,b,c;
    b=b+9999999;
    power(a,2,3217);
    


    c=fonction(b,a);

    cout<<c<<endl;

J'obtiens l'erreur :

~/Bureau/Programmation/projet$ ./main
*** glibc detected *** ./main: realloc(): invalid pointer: 0xbfa55c94 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0xb74ddbc2]
/lib/i386-linux-gnu/libc.so.6(realloc+0x2a5)[0xb74e1c65]
./main[0x80498f7]
./main[0x8049e48]
./main[0x8048c02]
./main[0x8048d45]
./main[0x8048ac7]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb7488113]
./main[0x8048981]
======= Memory map: ========
08048000-08056000 r-xp 00000000 08:11 1578840    /home/XXX/Bureau/Programmation/projet/main
08056000-08057000 r--p 0000d000 08:11 1578840    /home/XXX/Bureau/Programmation/projet/main
08057000-08058000 rw-p 0000e000 08:11 1578840    /home/XXX/Bureau/Programmation/projet/main
09235000-09256000 rw-p 00000000 00:00 0          [heap]
b746d000-b746f000 rw-p 00000000 00:00 0 
b746f000-b75e5000 r-xp 00000000 08:11 263110     /lib/i386-linux-gnu/libc-2.13.so
b75e5000-b75e7000 r--p 00176000 08:11 263110     /lib/i386-linux-gnu/libc-2.13.so
b75e7000-b75e8000 rw-p 00178000 08:11 263110     /lib/i386-linux-gnu/libc-2.13.so
b75e8000-b75eb000 rw-p 00000000 00:00 0 
b75eb000-b7607000 r-xp 00000000 08:11 263104     /lib/i386-linux-gnu/libgcc_s.so.1
b7607000-b7608000 r--p 0001b000 08:11 263104     /lib/i386-linux-gnu/libgcc_s.so.1
b7608000-b7609000 rw-p 0001c000 08:11 263104     /lib/i386-linux-gnu/libgcc_s.so.1
b7609000-b760a000 rw-p 00000000 00:00 0 
b760a000-b7632000 r-xp 00000000 08:11 265566     /lib/i386-linux-gnu/libm-2.13.so
b7632000-b7633000 r--p 00028000 08:11 265566     /lib/i386-linux-gnu/libm-2.13.so
b7633000-b7634000 rw-p 00029000 08:11 265566     /lib/i386-linux-gnu/libm-2.13.so
b7634000-b7712000 r-xp 00000000 08:11 7995878    /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
b7712000-b7713000 ---p 000de000 08:11 7995878    /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
b7713000-b7717000 r--p 000de000 08:11 7995878    /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
b7717000-b7718000 rw-p 000e2000 08:11 7995878    /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
b7718000-b771f000 rw-p 00000000 00:00 0 
b7732000-b7734000 rw-p 00000000 00:00 0 
b7734000-b7735000 r-xp 00000000 00:00 0          [vdso]
b7735000-b7753000 r-xp 00000000 08:11 263032     /lib/i386-linux-gnu/ld-2.13.so
b7753000-b7754000 r--p 0001d000 08:11 263032     /lib/i386-linux-gnu/ld-2.13.so
b7754000-b7755000 rw-p 0001e000 08:11 263032     /lib/i386-linux-gnu/ld-2.13.so
bfa37000-bfa58000 rw-p 00000000 00:00 0          [stack]
Abandon

DJC, je sais d'où vint l'erreur de base (le tableau rend qui est de taille trop petite...), c'est surtout que je comprend pas pourquoi ya pas d'erreur (ça à la limite ok, la syntaxe est correcte...)... main la réaction du main?

Dernière modification par DevraisJamaiscoder (Le 14/11/2011, à 11:52)

Haleth

Re : [C++][NTL]projet

Ton tableau est de la bonne taille (deux cases pour deux elements, ca me parait correct).

C'est plutot ca qui est louche :

ZZ *pointeur=rend;

---

Ubuntu is an ancien African word which means "I can't configure Debian"

Because accessor & mutator are against encapsulation (one of OOP principles), good OOP-programmers do not use them. Obviously, procedural-devs do not. In fact, only ugly-devs are still using them.

Luc Hermitte

Re : [C++][NTL]projet

Non. Le tableau a une taille 1, pas 2.

Haleth

Re : [C++][NTL]projet

Hawé, autant pour moi, ca marche parcque je fait du buffer overflow

Utilise gdb

---

Ubuntu is an ancien African word which means "I can't configure Debian"

Because accessor & mutator are against encapsulation (one of OOP principles), good OOP-programmers do not use them. Obviously, procedural-devs do not. In fact, only ugly-devs are still using them.

DevraisJamaiscoder

Re : [C++][NTL]projet

Salutation!
Cela fait long temps que je n'ai pas posté.

Entre temps, j'ai bien avancé... Mais il me manque quand même un certain nombre de truc, et je dois rendre demain .

En fait, mon premier problème est que je n'ai pas de quoi tester mes calcules sur les plus grands nombres...

En fait, il me faut une calculatrice très précise (avec des calcules sur des nombres avec jusqu'à 21-25 chiffres significatifs...).

DJC, vous avez une idée?

nicolas66

Re : [C++][NTL]projet

Tu peux soit utiliser GMP ou CLN. Je connais plus la deuxième bibliothèque : la prise en main est rapide et la documentation est claire.

---

"The computer was born to solve problems that did not exist before." (B. Gates)

DevraisJamaiscoder

Re : [C++][NTL]projet

Merci de ton aide!

Une autre question, plus bête surement, mais que je traîne depuis le début du projet... On me demande, entre autre, d'implémenté une exponentielle et une division euclidienne, ce qui en soit est facile...

Mais il y a un problème : il demande de le faire avec les opérator \ et ^ respectivement.

Or \ n'est pas un opérateur (ça je crois qu'il n'y a pas de solution...).

Et le ^ est déjà utilisé, d'où ambiguïté... Pour ça, j'ai mis mon exponentiation dans un namespace propre... Mais je ne vois pas comment faire pour pouvoir écrire "a^b" plutôt que "namespace_perso::operator^(a,b)"....

DJC, je vais rendre cette aprem... Dure la vie!

Dernière modification par DevraisJamaiscoder (Le 31/12/2011, à 10:30)