honnétement, ça doit être LA MORT à coder : déjà un compilateur ANSI-C, c'est grave dur !!!
(du moins, d'après els sources de compilo ON-PC que j'ai vu !)
mais alors... compilon C++... surtout avec les faibles ressources de la TI, c po gagné !
/me supplie PpHd d'aider Nitro !!!!!!!!!!
/me attend le mode Kernel avec impatience !!! (pr pouvoir utiliser les libs en ASM... vu que je code en ASM que pour ça ou presque)
pas de fonctions ?
heu... ça va qd même être dur : tout le monde a l'habitude d'en utiliser... même si énormément de choses sont gérables par objets !
PpHd Le 28/01/2002 à 19:25 Pas forcement. Tu creer une classe program, puis tes variables globales, puis tes methodes a l'interieur de ta classe sont comme des fonctions. A autre chose, seules les methodes seront de domaine public.
L'héritage multiple existe aussi en C++. Et plus de contraintes veut dire du code encore moins efficace, notamment si les contraintes obligent à utiliser de l'orienté objet.
Ça me surprend énormément de la part d'un fan de l'optimisation maximale de parler de code orienté objet, qui est le contraire exact de l'optimisation (du moins dans la famille de la programmation procédurale).
nitro Le 28/01/2002 à 21:28 Kevin, l'idée ici n'est pas de produire du code optimal, pour ça il y a l'asm. En t'écoutant on a l'impression que tu ne connais pas le plaisir que c'est de programmer en orienté objet ?
So much code to write, so little time.
Nitro> vivement ce week-end, que je puisse tester ça !!!
PpHd> en gros, si on vuet un code pas optimisé, on utilise l'objet... et si on veut un code optimisé, l'ASM, c'est ça ?
arf...
HP vs TI, l'écrat se réduit, non ?
PpHd Le 30/01/2002 à 09:46 >PpHd et les autres: il n'y aura pas de mode kernel tant qu'il n'y a pas une doc claire et détaillée du format du stub.
Desole mais c'est relativement bien detaille. Pourquoi tu repompes pas le code de prgm.cc ?
>KK:Parce que le langage que veut PpHd est plus efficace que le C++??? Les 3 lignes de code généré qu'il a postées disent exactement le contraire (que c'est encore moins efficace que le C++).
Ca n'a pas pour but d'etre efficace mais d'etre 100% oriente objet.
Un language oriente objet n'a pas pour finalite d'etre performant. Il existe d'autres languages pour. Il a pour but d'etre abstrait.
nitro Le 30/01/2002 à 14:06 >La compression ExePack, ça te dit quelque chose? La dernière version compresse aussi les programmes pour kernel. Et ça évite ce genre de problèmes
Je ne penses pas que les programmeurs aprécient de perdre 45 secondes à chaque compilation. Deja on m'a demandé de mettre une version non compressée de AS (alors que j'utilisais toujours ExePack avant), alors pour CC qui est 3 fois plus gros ce n'est meme pas la peine d'y penser.
L'idéal serait d'avoir un ExePack qui te laisserai le choix du ratio vitesse / taux de compression, en utilisant plusieurs algo différents.
>Desole mais c'est relativement bien detaille. Pourquoi tu repompes pas le code de prgm.cc
Parce que je trouve ça mal fait, ce n'est pas adapté à mon cas (et je ne veux pas d'un AS qui fait 60 Ko), donc je prefere le faire proprement moi meme... enfin bon, tant pis pas de mode kernel.
[edit]Edité par Nitro le 30-01-2002 à 14:08:35[/edit]
So much code to write, so little time.
>PpHd:
>Ca n'a pas pour but d'etre efficace mais d'etre 100% oriente objet.
>Un language oriente objet n'a pas pour finalite d'etre performant. Il existe d'autres languages pour. Il a pour but d'etre abstrait.
Et tu veux donc encore plus aider les programmeurs à être paresseux et à ne pas programmer de manière efficace avec des langages faits pour? L'introduction du C avec TIGCC a déjà fait assez de dégats sur ce point là, il ne faut pas faire encore plus de concessions aux programmeurs paresseux.
>>PpHd et les autres: il n'y aura pas de mode kernel tant qu'il n'y a pas une doc claire et détaillée du format du stub.
>Desole mais c'est relativement bien detaille. Pourquoi tu repompes pas le code de prgm.cc ?
Le minimum qu'il faudra faire, c'est rajouter de manière claire les nouveautés de PreOs et où et comment elles sont stockées. J'en ai besoin si je veux adapter obj2ti à ces nouveautés, et je pense que Nitro en aura besoin lui aussi.
>Et franchement ca ne sert qu'a perdre du temps d'utiliser exepack avec des compilateurs.
Ça sert à:
- réduire la consommation de mémoire permanente, sachant qu'on n'a que 640 KO d'archive (ou 1 MO pour les 2 ou 3 chanceux qui ont un prototype de la V200)
- dans le cas de AS et de CC, éviter que ça plante si le programme est désarchivé
[edit]Edité par Kevin Kofler le 30-01-2002 à 16:13:06[/edit]

PpHd Le 30/01/2002 à 16:38 >Et tu veux donc encore plus aider les programmeurs à être paresseux et à ne pas programmer de manière efficace avec des langages faits pour?
>L'introduction du C avec TIGCC a déjà fait assez de dégats sur ce point là, il ne faut pas faire encore plus de concessions aux programmeurs
>paresseux.
Bah de toute facon, il y a de grandes chances pour que je ne le fasse pas.
>Le minimum qu'il faudra faire, c'est rajouter de manière claire les nouveautés de PreOs et où et comment elles sont stockées. J'en ai besoin si je
>veux adapter obj2ti à ces nouveautés, et je pense que Nitro en aura besoin lui aussi.
Ok je rajouterais dans Preos une doc plus claire sur le format.
>- réduire la consommation de mémoire permanente, sachant qu'on n'a que 640 KO d'archive (ou 1 MO pour les 2 ou 3 chanceux qui ont un
>prototype de la V200)
Pour un compilateur utilise souvent, c'est une perte de temps dnas le processus de developement.
>- dans le cas de AS et de CC, éviter que ça plante si le programme est désarchivé
Moui.