g++ TI - Page 2

Oui, mais pour moi ça n'a pas grand intérêt (comme je l'ai expliqué plus haut).

snow-tiger>Euh, si tu nous donnais un exemple d'utilisation du C++ sur les TI ? A ma connaissance, il n'y a rien qui justifierait l'utilisation du C++ pour la compilation sur les TI.

Thibaut >
Tiens, un truc que j'avais pensé à faire.
J'ai bien fait de ne pas le faire.

Il marche bien ? Support complet des notions de POO genre héritage, classes...
et comment fait-on pour les headers ?

GC > En partant de ce principe, il n'y a rien non plus qui justifie l'utilisation du C sur les TI...
Plus sérieusement, la POO, évidemment. Si quelqu'un apprend la prog en général sur une TI, comme
je l'ai fait, il sera bien content de voir que son premier support de développement peut se programmer
en C++, et qu'il peut apprendre la POO sur sa TI, il n'est pas obligé de passer sur PC tout de suite...

GoldenCrystal
: snow-tiger>Euh, si tu nous donnais un exemple d'utilisation du C++ sur les TI ? A ma connaissance, il n'y a rien qui justifierait l'utilisation du C++ pour la compilation sur les TI.

Je serais bien content de pouvoir compiler ma classe c_huffman sans avoir à tout porter en C. Elle permet de compresser en progressif plusieurs streams ("fichiers") simultanément et d'entrelacer les streams compressés (par exemple : 10 octets du stream 1, 10 octets du 2, 10 octets du 1, ...)
Très difficile à porter sans les classes, donc en C.

BlueSilk :
Thibaut >
Tiens, un truc que j'avais pensé à faire.
J'ai bien fait de ne pas le faire.

Il marche bien ? Support complet des notions de POO genre héritage, classes... et comment fait-on pour les headers ?

Tout est dit là-bas dans le topic

./34>Nan, je paralis pas de ça.
Je te demande juste si il y a un programme qu'on ne pourrait écrire en C. Et si (comme) ce n'est pas le cas, le C++ sur TI n'a pas vraiment d'intérêt.

Et comme je l'ai écrit, en partant de ça aucun langage n'a le moindre intérêt, puisqu'on peut faire la même chose
en assembleur. Et l'assembleur non plus, puisqu'on peut le faire en langage machine, du direct.
Tu voies où je veux en venir: la simplicité pour le programmeur. Donc la POO.

De toute façon, les langages orientés objet sont bien trop gourmands pour que tu puisses faire de la programmation orientée objet sur TI, donc tu devrais oublier.

Ta da da. Tu as sous-entendu que c'était impossible. Faut que je te prouve le contraire maintenant.

Nan, j'ai pas sous-entendu que c'était impossible. Il y a d'autres moyens que le C++
Mais là où ça pêchera toujours c'est l'allocation mémoire. Il n'y a qu'a voir la place que prennent toutes les variables d'une classe et multiplier ça pour se rendre compte du travail affreux qui serait subi par la ti...
malloc, realloc, free... En permanence... Mais tu n'as pas vraiment le droit d'utiliser + de 100 Ko

Ben, va falloir serrer les fesses.
Et en effet, les autres moyens je m'en occuppe pas, vu la disparition tragique de celui qui a voulu porter l'Objective C.

Pollux :
Peut-être qu'un jour je me remettrai à GT-Basic

Au boulot !!

Pollux
:

De plus, l'interface avec le C, et même la conversion complète du C vers le C++ étant quasi immédiate, on pourra très vite voir débarquer la plupart des libs (extgraph, genlib, libs kernels standard comme ziplib et graphlib)

Oui, le problème n'est pas là. Le problème, c'est que si on laisse les gens programmer _vraiment_ en C++, alors il faut avoir ne serait-ce, pour reprendre l'exemple précédent, que la gestion des vector : à chaque fois que la taille du vecteur est multipliée par un facteur Q (par exemple Q=2), on est obligé de refaire une allocation mémoire : vu la qualité de malloc, ce n'est même pas la peine d'y penser... sans parler de la RAM gâchée : on peut avoir un tableau Q fois trop grand que nécessaire, donc si on a un tableau de 40 ko et Q qui est aussi faible que 1.2 (l'allocation est d'ailleurs presque 3x plus lente qu'avec Q=2), on perd 8 ko de RAM.

On fait comme AutoClBr 1: un HeapRealloc à chaque fois que la taille change. (Oui, HeapRealloc, pas realloc. Pas la peine d'utiliser des handles lockés.)

On fait comme AutoClBr 1: un HeapRealloc à chaque fois que la taille change. (Oui, HeapRealloc, pas realloc. Pas la peine d'utiliser des handles lockés.)

... ou comment transformer un algorithme d'ajout d'un élément en O(1) en algorithme en O(n) ...

À l'époque, j'avais testé AutoClBr avec 10000 parenthèses ajoutées une par une et ça n'a même pas pris une seconde, alors...

Ouééé, je vais faire une boucle infinie de références : dans topics/31944-chaines-cachees#4, ton propre algo est N fois plus lent que la normale à cause de ça : pour N=50, ça prendrait de l'ordre de 1 seconde à exécuter avec la gestion des std::string de la STL, mais là ça prend de l'ordre de 50 secondes avec ton realloc...

Donc ce n'est pas du tout un luxe Et je ne parle pas de la gestion d'un texte quelconque, où tu peux avoir besoin de manipuler un texte de 10 ko...