programmer en C++ - Page 1

Je me demandais pourquoi tout le monde programme en C et pas en C++, alors j'ai essayé pour savoir si ça posait des problèmes, et finalement c'est tout un SDK que je suis en train de refaire. Je suis parti de minigp32v2 (GCC 3.2.2) et des librairies de Mirko, et je suis en train d'ajouter pas mal de fonctions (qui sont d'ailleurs plutôt des classes).

Si vous voulez vous mettre au C++, je pourrais un jour mettre mon SDK sur le net avec quelques examples.

ben je programme en C parce que je connais plus le C que le C++ c tout mais pq pas si ton sdk est efficace et simple deja que suis admiratif devant ton emu gba

au faite ca avance jsutement ton emu lool je sais c'est pas le sujet mais bon vu que ya thunderz qui me semble vouloir taide je pense que tu as du progresser un peu ?? nan jme trompe

huhu en voila une bonne de nouvelle
j'espere que ca pourra marcher sous ads ^^

jai une petite question quel genre de fonction as tu rajoute ?

je programme un peu en c++ et ca peut tjs etre interessant si ton sdk apporte de nvelles fonctions

grincheux
: au faite ca avance jsutement ton emu lool je sais c'est pas le sujet mais bon vu que ya thunderz qui me semble vouloir taide je pense que tu as du progresser un peu ?? nan jme trompe

Il a pas vraiment avancé, j'ai passé pas mal de temps dessus, mais c'était surtout pour le porter au SDK de mirko et à minigp32-v2. Maintenant je suis en vacances (ou plutôt en recherche de stage), alors j'ai plus de temps. Parler de l'émulateur est pas complètement hors sujet vu que les classes que je suis en train d'écrire sont les fonctions que j'ai du écrire pour l'émulateur.

rov :
huhu en voila une bonne de nouvelle j'espere que ca pourra marcher sous ads ^^

désolé c'est pas prévu pour l'instant

ok bonne chance pour ton stage dailleurs moi jy suis en stage ca se voit comme je bosse lool mais bon jai presque fini mon programme alors c'est bon

ben sinon pour lemu on peut attendr eon est po presses

tant pis ^^

pkoi y a t'il tant d'incompatibilité entre compilos alors que les langages sont strict et standardisé (ansi, c99, ...) ?

grincheux
: jai une petite question quel genre de fonction as tu rajoute ?

pour l'instant rien de très original, je viens de finir une classe gérant l'affichage de toutes sortes de choses :
- polices monotypes, variables
- MessagesBox
- Listes (avec barres de défilement)
- Barre de progression

je pense ensuite faire une classe s'occupant de tout ce qui est lié aux horloges et timers :
- changer la fréquence d'horloge
- régler des timers et définir des handles pour ceux-ci
(rq gérer les timers et la fréquence d'horloge dans la même classe permettrait la mise à jour automatique des timers lorqu'on change la fréquence d'horloge)
- définir un handle pour VSYNC

Dans une classe MMU, je vais mettre :
- une fonction pour créer un fichier d'échange (dans le genre "mémoire swap" sous linux). Ca permettrait de disposer virtuellement de plus de mémoire et également de mapper des gros fichiers (même très gros) directement en mémoire (exemple roms d'émulateurs).
- une fonction pour intercepter les exceptions et les rediriger où on veut


Il y a donc quelques fonctions qui sont nouvelles (tout ce qui touche à la MMU).

Ca devrait aller assez vite vu que toutes les fonctions ont déjà été écrites, j'ai juste à les porter en C++ dans des classes. (Sauf la fonction du "fichier d'échange")

rov :
tant pis ^^
pkoi y a t'il tant d'incompatibilité entre compilos alors que les langages sont strict et standardisé (ansi, c99, ...) ?

Je sais pas, en tout cas j'ai pas mal galéré à simplement utiliser les librairies de Mirko, alors je veux pas trop m'avancer avec ads. Peut-être que ça marchera très bien avec ads, qui sait ?

Aye, une si bonne nouvelle suivie d'une si grosse déception
Enfin c'est bien cool quand même

Mais si tu as un peu de temps ce serait bien si tu voulais t'occupper vite fait de la compatibilité ADS, ca devrait pas te prendre beaucoup de temps et je pense qu'on est un sacré paquet à l'utiliser

en tt cas ce qui a dedans ne rigole pas
bon courage :]

merci enf65 pour toutes ces precisions, moi perso qu'il soit comptabile ou pas c po le probleme jai tjs plein de compilo dc c po bien grave.

si il y avais le necessaire pour init l'ecran et les buffer en 2 et 4 bit ca serais super ^^

rov
: si il y avais le necessaire pour init l'ecran et les buffer en 2 et 4 bit ca serais super ^^

pas de problème, vu que ces fonctions sont déjà dans le sdk de Mirko

oups désolé, le jour où j'avais écrit ça, je m'étais planté ! oubliez ce que je viens d'écrire !

arf je savais pas ^^

en tt cas c cool merci.

C'est clair que se serai bien, ton sdk

Le compilateur, il gere le C++ ?

gcc et ads le supporte, par contre sdt ne compile que du C (sauf la version 2.50 a ce qu'il parais mais g jamais pu mettre le curseur dessus)

par hazard, qq saurais comment faire pour utiliser new et delete sur gp ??

rov
: par hazard, qq saurais comment faire pour utiliser new et delete sur gp ??

Salut,

J'utilise le SDT 2.50 et le c++ peut effectivement être compilé.
J'avais le même soucis et je pense avoir trouvé la solution
Tu dois définir toi-même tes opérateurs new et delete

par exemple :

inline void* operator new(size_t s)
{
    return gm_malloc( s );
}

inline void operator delete(void* p)
{
    return gm_free( p );
}

J'la sens moyen cette methode. C'est du style a pas appeler le destructeur sur tous les objets de ton tableau quand tu fais "delete [] tab;"
(si les elems de tab sont des objets, contenant chacun un pointeur vers une zone memoire allouee, ca va pas faire delete de toutes ces zones memoires)

Un code d'exemple vite fait

 class c{
   int * ptr;
public:
   c(){ptr = new int [10];}
   ~c {delete [] ptr;}
};

void main()
{
    c tableau[20];
    delete [] tableau; // <--- le destructeur de chaque element doit etre appele. Si il existe
}

EDIT: j'ai relu le post precedent. En fait c'est pire que ce que je pensais. new et delete ne sont pas des fonctions du C++, ce sont des mots cles. Un compilateur C++ qui n'accepte pas ces deux mots cles n'est pas un compilateur C++ valide.

je c pas ce ke vous en pensez mais c foireux le C++ sur gp!

manipulé d classes de cette facon c horrible!

un massacre du concept objet!

Salut Yaouank,

Je ne crée pas les opérateurs new et delete , d'ailleurs il n'est pas possible de créer des opérateurs.
new et delete sont bel et bien reconnus par le SDT mais ils n'allouent ou ne désallouent pas la mémoire par contre ils appellent bien respectivement le constructeur et le destructeur, je l'affirme donc cette méthode fonctionne d'ailleurs, je l'utilise sans aucun soucis.

Je parle bien ici de new et delete et pas de new[] et delete[] . La surcharge que je propose concerne new et delete et ne fonctionne effectivement pas pour les opérateurs new[] et delete[], bien que je ne doute pas qu'il soit possible de faire quelque chose du même acabi. En effet, surcharger new, delete, new[] ou delete[] permet de gérer l'allocation ou la désallocation mémoire, mais l'appel des constructeurs ou des destructeurs est à la charge de la librairie interne C++.

Bref je pense qu'au fond, si on explique bien les choses, nous sommes d'accord.

Baallrog :
je c pas ce ke vous en pensez mais c foireux le C++ sur gp!

manipulé d classes de cette facon c horrible!
un massacre du concept objet!

Je ne comprends pas pourquoi tu dis ça.

oua merci

moi non plus, le c++ marche nikel pour moi pour l'instant
y avais que new et delete qui posaient prblm

iKi :
Salut Yaouank,
Bref je pense qu'au fond, si on explique bien les choses, nous sommes d'accord.