Et tu m'expliques où est la différence avec une chaîne dans ce que tu racontes ?
Lol le comportement d'une chaîne est très différente du comportement d'un nombre, donc le descripteur est différent...
(je dis pas qu'il n'y a pas de différence dans ton implémentation, au contraire, mais je dis qu'il n'y a aucune différence entre les besoins d'une chaîne et les besoins d'un tableau : on n'a pas moins besoin de concaténer 2 tableaux que de concaténer deux chaînes -- je comprends pas trop pourquoi tu autorises la concaténation pour les chaînes, et pas pour les tableaux...)
On dirait un changement de sujet.
Lol bah fallait me le dire plutôt. Donc pour toi la concaténation de nombres est identique à la concanétation de tableaux?
Premièrement le GFA-Basic n'a jamais supporté ça, deuxièmement j'y ai jamais pensé et j'en voit pas l'utilité et troisièmement c'est possible à faire genre A()+B(). D'ailleur je crois que le TI-Basic supporte la concaténation de listes.
Pour finir je recommence sur la différence entre chaîne, tableaux et tableau de chaînes.
Quant on a un tableau numérique, le but est d'accéder facilement à une valeur, pour ça c'est simple, on calcule l'adresse ou se trouve la valeur et on modiifie le contenu si necessaire. Pour une chaîne c'est autre chose, il faut parcourir le descripteur pour connaitre sa taille, récupérer une adresse à partir du numéro du handle et après faire les opérations necessaires. Rien qu'avec ça la différence entre chaînes et variables numériques est différente donc la différence est identique entre tableaux numériques et tableaux de chaînes.
Une chose que je ne comprend pas, vous en demandez toujours plus comme concaténer des tableaux... alors qu'il y a bien des choses plus importantes à faire avant. Surtout que cette possibilité est peu utilisée et surtout est implantable facilement lorsque mon format de variables et tableaux sera clairement défini.
Bref tout ça pour une histoire de tas qui pour moi n'a vraiment pas une place indispensable dans ce genre de projet. Genre on contourne le tas avec des chaînes de caractères fixes de 65 caractères et puis basta. (une chose à noter le GFA-Basic sur Atari ST consomme toute la mémoire pour la gestion de chaînes de taille fixe alors que dans mon cas c'est autre chose).
Ce qui me semble le plus important est de trouver des phases d'optimisations pour l'execution du programme, comme diminuer le nombre de tokens, éléminer les répétitions comme A=A+1 dans le cas de AA1+=, stocker pour les entiers les 2 dernières valeurs dans des registres...
Les objectifs de mon langages sont les suivantes:
- Remplacer le TI-Basic mais ne pas devenir pour autant un langage proche du C ou de l'ASM, je veux dire par là que mon objectif n'est pas d'avoir des vitesses d'execution proche de l'ASM ou du C et donc de faire des jeux avancés.
- Etre très rapide.
- Très compact pour tenir dans un secteur de la flash ou 2 maximum.
- Très souple et puissant, proposer toutes les fonctions du GFA-Basic avec la possibilité d'utiliser des pointeurs...
- Possibilité de faire des procédures et d'ajouter des APIs.
Pour finir, il y a toujours une alternative pour obtenir des programmes d'une vitesse très proche du C en réalisant tout simplement un compilateur on-calc ou sur PC pour le GFA-Basic en transformant le fichier qui contient les tokens d'execution en langage machine. (mais c'est pas mon objectif).
C'est ma dernière réponse ici, j'ai des engagements à tenir. La discussion continue ici:
http://pws.tigen.org/forum/index.php?action=rubrique&forum=5&cat=105&page=1 ou nul part.
)
Et ça sert dans une grande partie des algos (et ils ne sont pas forcément de taille connue à l'avance)
Et ça sert dans une grande partie des algos (et ils ne sont pas forcément de taille connue à l'avance)
