C++ sur TIGCC - Page 2

Pollux :
"" Je dis pas que le C c'est pas bien, je dis que qd Link dit que ça n'apporte rien par rapport au code équivalent en C, il se trompe Le C++ et le C ont des objectifs différents, point.

Je parle de ta façon de lui "expliquer", j'en ai strictement rab de savoir si le C en a une plus grosse que le C++...

Link> hmm oui sur le coup j'ai cru que tu sous-entendais ça, mais en fait en relisant, pas du tout, désolé...

Vertyos> bah content pour toi, moi non plus

Je trouve que Moka rox, mais il reste malheuresement des bugs.

onur :
Je trouve que Moka rox, mais il reste malheuresement des bugs.

Selon moi, c'est sûrtout que le convertisseur laisse passer de nombreuses erreurs lors de la conversion. Ce qui donne l'impression d'un manque de robustesse. À mon avis c'est vrai pour le convertisseur, mais l'API fourni et le code C généré s'en tirent mieux.

Et pourquoi tu as pas fait un compilateur_on_PC + MachineVirtuelle_oncalc ?

Hmm une VM sur calto, c'est pas le pied question rapidité, en fait...

Mais non, voyons, la vitesse et la lourdeur, on s'en fout complètement...
La VM donne du code portable, l'OO donne du code modulaire et réutilisable. Et en plus, on fait moins de conneries en codant et la VM vérifie plus de trucs, donc c'est mieux. Que des avantages. Ce sont des faits et tout le monde sait qu'il n'y a rien à y redire. Ca va tout remplacer définitivement, tout ce vieux code non-OO et très platform-dependent. C'est comme les ordinateurs quantiques: que du bonheur.

Lionel Debroux :
Mais non, voyons, la vitesse et la lourdeur, on s'en fout complètement...
La VM donne du code portable, l'OO donne du code modulaire et réutilisable. Et en plus, on fait moins de conneries en codant et la VM vérifie plus de trucs, donc c'est mieux. Que des avantages. Ce sont des faits et tout le monde sait qu'il n'y a rien à y redire. Ca va tout remplacer définitivement, tout ce vieux code non-OO et très platform-dependent. C'est comme les ordinateurs quantiques: que du bonheur.

pataper

Je crois que c'est la premiere fois que je trouve XD drole

Nil a enfoncé une porte ouverte, j'ai suivi avec le canon !

Plus sérieusement, il n'y a pas que des grosses conneries dans mon post (portabilité de ce qui tourne sur une VM - même si c'est à nuancer car justement, il faut tenir compte des différences d'UI). Mais comme ça a été mentionné, l'OO n'est pas intéressant sur les calculettes sans les lourdes libs. Et les VMs sont également lourdes...

ouep, n'empeche y'aurait des trucs a faire avec des calculatrices scientifiques et des VM (je pense au portages de plusieurs langages comme CAML, Scheme etc.)

En soit, un parser scheme n'est pas tres complique a faire, c'est juste ultra long d'y foutre toutes les fonctions...

nEUrOO :
En soit, un parser scheme n'est pas tres complique a faire

Nooon, tu crois ? Et indépendamment de la bibliothèque de fonctions, y a toute une infrastructure à mettre en place (garbage collection ? call/cc ? etc...)

bah je veux dire par la que la syntaxe du scheme est extremement simple (langage fonctionnel) compare a d'autes, stoo

nEUrOO :
bah je veux dire par la que la syntaxe du scheme est extremement simple (langage fonctionnel) compare a d'autes, stoo

Oui je ne te contredisais pas, au contraire ^^

quant a l'infrastructure... c'est quelque chose de commun a toute VM (ce que je dis dands ./43).
en gros, faire une VM commune et des parsers s'appuyant dessus.... pour gerer plusieurs langages

VM ne signifie pas forcement language interprété. Un emulateur est une VM et c'est realisable, bref

nEUrOO :
quant a l'infrastructure... c'est quelque chose de commun a toute VM (ce que je dis dands ./43).
en gros, faire une VM commune et des parsers s'appuyant dessus.... pour gerer plusieurs langages

Mais les spécificités d'un langage se résument rarement aux parseurs ^^ Donc faire une VM multi-langage, c'est encore plus de boulot...

Pollux
:

nEUrOO :
quant a l'infrastructure... c'est quelque chose de commun a toute VM (ce que je dis dands ./43).
en gros, faire une VM commune et des parsers s'appuyant dessus.... pour gerer plusieurs langages

Mais les spécificités d'un langage se résument rarement aux parseurs ^^ Donc faire une VM multi-langage, c'est encore plus de boulot...

Ba non, par exemple, la VM java émule un processeur a pile (non pas électrique les piles) et rien n'empêcherais de faire un compilo C pour cette archi (on peut déjà programmer en ASM)

Ce serait quand même assez complexe puisque le bytecode (l'"assembleur") a conscience de notions orientées objets du langage au-dessus (Java).

Oui non mais j'ai pas dit que ça serait simple hein

Godzil :
VM ne signifie pas forcement language interprété. Un emulateur est une VM et c'est realisable, bref

Ouais d'abord. On peut déjà programmer en Z-code pour TI, je vous le rappelle (dsl )

reste a faire une VM ZCode pour NES et ensuite...

Je ne connais pas le Scheme, mais je pense qu'un parser Prolog ne devrait pas être trop compliqué à réaliser (en tous cas si on ne gère pas toutes les extensions Turbo Prolog qui ne sont pas normalisées).

onur :
Et pourquoi tu as pas fait un compilateur_on_PC + MachineVirtuelle_oncalc ?

Ça s'est fait ... pas par moi, mais par Wabasoft qui a été porté par un certain Stephan Effelsberg sur 68K :
http://www.ticalc.org/archives/files/fileinfo/189/18970.html

Le pire c'est que, bien que waba soit sorti bien avant que je démarre le projet Moka, je l'ai découvert après. Je me suis alors précipité pour l'essayer. Malheureusement, ou heureusement pour Moka, j'ai été déçu (mais impressionné tout de même). Voici mes critiques de la version 'v0.1' de Stephan Effelsber :

- Ne permet pas de prendre avantage de l'écran d'une TI-92 (limité à la résolution d'une TI-89 peu importe le matériel).
- L'accès aux fichiers n'est pas implémenté.
- Seule une partie minime de l'API waba (beaucoup plus limité que l'API java : se compare à l'API Moka si ma mémoire est bonne) est implémentée.
- Lenteur vraiment excessive (à l'oeil, comparable au TI-BASIC, pour les apps GUI du moins).

Par contre, c'est un vrai interpréteur de bytecode (on utilise le JDK pour compiler, mais on utilise des classes de base différentes) garbage collecté. Je crois que la plupart de ces lacunes pourraient être corrigées : le code est fourni et je n'ai pas eu trop de misère à permettre la reconnaissance de la résolution de l'écran. Cependant, à mon avis, Waba est moins bien adapté pour TI-68K que Moka : ce dernier est plus rapide et surtout, il permet une interopérabilité avec le C. La taille (domaine ou waba excelle p/r à Moka) des programmes Moka pourrait être réduite en améliorant encore l'optimisation effectuée par le convertisseur. Des progrès ont été faits en ce sens depuis les premières versions.