Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » News » L'avenir des programmeurs TI... (42 réponse(s))

./REPRISE DU POST PRECEDENT (post n°19) Marquer comme non lu.

deadbird

Ecrit le: Dimanche 12 septembre 2004 à 19:26

Membre: Habitué

Messages: 66

Membre n°68

Inscrit le 29 février 2004

Ah mais je ne critique pas! tu sais j'ai une 92+, une 89 et une V200, alors....
Et en plus je code majoritairement sous TIFS!

./Post n°20 Marquer comme non lu.

LionelA

Ecrit le: Dimanche 12 septembre 2004 à 19:32

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Désolé de donner mon opinion mais je crois pas que j'ai vu plus crado comme programmation que celle des MFC, donc (à moins que je ne comprenne pas ta derniere phrase) cela me semble plutot un contre argument

Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

./Post n°21 Marquer comme non lu.

Invité

Ecrit le: Dimanche 12 septembre 2004 à 19:39

Le C++ sur une TI, je ne vois vraiment mais alors vraiment pas l'intérêt.
Il y a des MFC ou des contrôles utiles ?
Si c'est juste pour que CASIO puisse écrire C++ quelque part et qu'on ait juste a=a+1; euh je préfère faire un prog en C sur TIGCC...
Et d'après mes souvenirs, le ClassPas n'as PAS de SDK intégré pour le C et l'ASM. Sur TI on en trouve, même incomplets.
Et le fait d'avoir un stylet me dérange sérieusement. Je préfère avoir un clavier externe TI qu'un stylet CASIO.
Certes son écran est plus garnd que sur une TI, sauf qu'il y a bien 50 pixels de chaque côté pour les menus et les fonctions, vu qu'on utilise un stylet : résultat, un écran 10x20 ?
Enfin bref, je ne vais pas écrire 50 pages, mais CASIO reste de la m***e. Ce n'est pas parce qu'ils ont ENFIN sorti un graph 3D et qu'ils se croient malins avec leur 4Mo que la V200 a depuis longtemps que je vais me mettre à genoux.
Le mieux c'est toujours TI. Et les programmes Ti évoluent beraucoup plus vite que sur CASIO. Je ne vois pas d'où vous sortez votre déclin.

./Post n°22 Marquer comme non lu.

DjFab

Ecrit le: Dimanche 12 septembre 2004 à 19:40

Membre: Ange

Messages: 593

Membre n°364

Inscrit le 15 juillet 2004

Découvrez mon site dédié à la TI-92+

http://perso.club-internet.fr/isabelle.bourliquaux/images/skin6/Banniere-Pub-Bomber-TI.gif

./Post n°23 Marquer comme non lu.

Thor

Ecrit le: Dimanche 12 septembre 2004 à 20:24

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Omega staff

Messages: 2182

Membre n°28

Inscrit le 03 février 2004

Je pense moi aussi que TI devrait réellement srtir une calculatrice top : un nouveau modèle quoi! Il faut, bien entendu que cette calto soit au top en comparaison des autres modéles des autres marques. Il est évident que le travail sera long pour redécouvrir les nouveaux "tips" et "entreails" (désolé mais je ne suis pas sur de l'orthographe de ce mot

) du nouveau modèle. Mais au fond du compte c'est ce qui est interressant

Cyril MOTTIER aka {==Thor==}
Modérateur général du forum de Tigen
[Etudiant à l'Institut National des Sciences Appliquées (INSA) de Rennes]
Mon site perso c'est ici

./Post n°24 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 13 septembre 2004 à 04:50

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Je ne travaille pas pour TI, mais je pense quand-même pouvoir répondre à ces questions:

geogeo :
Il faut se demander pourquoi Texas continue à utiliser un Z80 sur les TI84(+) alors que le coups d'autres processeurs plus puissant est sans doute moins cher car moins obsolète.

Parce que l'OS de ces modèles est écrit entièrement en assembleur Z80.

Pourquoi le processeur est bridé, alors que la TI fonctionne très bien à des fréquences 2.5x plus élevées (suffit juste de changer un condo, bref ça coûte rien)?

Parce que des fréquences plus élevées consomment plus de piles.

Pourquoi ils perdent de l'argent à ajouter des protections facilement cassables?

Parce qu'ils n'ont pas compris que les utilisateurs préfèrent avoir des programmes gratuits que des apps Flash payantes protégées par ces protections.

Pourquoi ils ne font qu'ajouter de la mémoire Flash? Il serait plus logique d'ajouter de la RAM! (Une puce Flash est plus couteuse qu'une puce de RAM du type SRAM).

Parce que la FlashROM n'est pas perdue lors d'un reset ou d'un épuisement des piles.

Pourquoi l'écran ne supporte t-il pas en Hardware les niveaux de gris et pourquoi les niveaux de gris ne sont-il pas exploités par Texas?

Parce que l'écran monochrome coûte moins cher et fonctionne tout aussi bien.

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°25 Marquer comme non lu.

squale92

Ecrit le: Mercredi 15 septembre 2004 à 08:17

Membre: Maître

Messages: 145

Membre n°94

Inscrit le 13 mars 2004

Le C++ sur une TI, je ne vois vraiment mais alors vraiment pas l'intérêt.

Quand tu as l'habitude de l'utiliser, le concept object n'est pas déplaisant, au contraire...
Réfléchir en pensant aux entités, et non aux traitements, c'est pas plus mal... sans parler des facilités que ça apporte (ne serait-ce que la surcharge de fonctions, c'est une chose fantastique)
Codant en C++ lorsque je suis sur PC, lorsque je repasse sur TI, il me manque bien souvent...

Pascal MARTIN
http://www.squalenet.net

./Post n°26 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 15 septembre 2004 à 13:16

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Il faudrait plutôt penser à l'efficacité (taille, vitesse) des programmes résultants qu'utiliser des concepts objets juste pour le plaisir de les utiliser. #roll#

./Post n°27 Marquer comme non lu.

Thor

Ecrit le: Mercredi 15 septembre 2004 à 13:25

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Omega staff

Messages: 2182

Membre n°28

Inscrit le 03 février 2004

Kevin Kofler :
Il faudrait plutôt penser à l'efficacité (taille, vitesse) des programmes résultants qu'utiliser des concepts objets juste pour le plaisir de les utiliser. #roll#

La taille des caltos actuelles est trés bien (en ce qui concerne les tailles comme la Ti-89) Sinon question performance je pense qu'il est temps d'innover! On n'attend pas non plus un PALM mais une cdalculatrice disposant d'un écran 256 couleurs ou en 64 NVG. Il faut également augmenter la fréquence processeur et la mémoire pour pouvoir réellement commencer à faire des calculs et des représentations de graphiques 3D.Enfin ce que je pense est peut-être un rêve

Cyril MOTTIER aka {==Thor==}
Modérateur général du forum de Tigen
[Etudiant à l'Institut National des Sciences Appliquées (INSA) de Rennes]
Mon site perso c'est ici

./Post n°28 Marquer comme non lu.

Onur

Ecrit le: Mercredi 15 septembre 2004 à 14:34

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

normalement ce qui nous plait a programmer sur une TI, c'est justement les manques et les limitations qui font qu'on est obliger de faire soit meme les optimisations, de descendre parfois a tres bas niveau en programmation et a d'autres moments pouvoir regarder seulement l'aspect general.

Si quelqu'un recherche de la puissance, de la memoire, de la rapidite, il n'a qu'a programmer sur PC, il pourra faire des jeux qui tue. Je pense que faire un bon jeu en 3d (et utilisable) sur pc peut prendre environ 6 mois, et un bon jeu sur caltoche aussi alors que les graphismes n'auront rien de comparable.. d'ailleurs rien ne sera comparable vu que c'est pas le meme plateforme. Donc le plaisir doit etre autre que exploiter toute la puissance d'une calculatrice car c'est la qu'on se trouve limite et ca donne envie de passer a autre choses pour certains.

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°29 Marquer comme non lu.

Invité

Ecrit le: Mercredi 15 septembre 2004 à 16:50

#27 : Si TI mets des couleurs ou augmente la mémoire de cetta façon ou quoi que ce soit qui soit aussi 'poussé', je pars de chez TI, je vends la mienne et je me prends un PC portable. Bah oui, la calto ne sert plus à rien si c'est pour avoir tout ça. Et je doute qu'elle soit autorisée au BAC ou à un examen...

./Post n°30 Marquer comme non lu.

Jfg

Ecrit le: Jeudi 16 septembre 2004 à 16:35

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

Nounours :
normalement ce qui nous plait a programmer sur une TI, c'est justement les manques et les limitations

Completement d'accord! Cette plateforme motive vraiment a optimiser, contrairement a la prgmation PC ou les gars n'hésitent pas à faire des méga copier coller ("après tout, ça ne rajoute que qlq ko à l'executables, et on a un disque dur de plusieurs Go").

Kill Mario

./Post n°31 Marquer comme non lu.

squale92

Ecrit le: Jeudi 16 septembre 2004 à 20:37

Membre: Maître

Messages: 145

Membre n°94

Inscrit le 13 mars 2004

Il faudrait plutôt penser à l'efficacité (taille, vitesse) des programmes résultants qu'utiliser des concepts objets juste pour le plaisir de les utiliser.

le plaisir de les utiliser... et, surtout, leur aspect pratique.

un exemple simple :

to_char(TYPE_A var);
to_char(TYPE_B var);
rien que ça, c'est pas de l'objet, c'est de la simple surcharge de fonction... mais ça manque terriblement en C... alors que ça ne doit pas augmenter la taille ou la vitesse des programmes résultants, puisque c'est géré par le compilateur au niveau de la signature de la fonction, qui n'est plus basée uniquement sur le nom, mais aussi sur les paramètres

Pascal MARTIN
http://www.squalenet.net

./Post n°32 Marquer comme non lu.

verytourist

Ecrit le: Jeudi 16 septembre 2004 à 20:45

Membre: Titan

Messages: 973

Membre n°26

Inscrit le 02 février 2004

"plusieur Go", t'es obsoléte, maitentant ils comptent en centaine de Go

./Post n°33 Marquer comme non lu.

Jfg

Ecrit le: Jeudi 16 septembre 2004 à 22:21

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

Je ne voulais pas offencer ceux qui ont des petits DD.
Ca me fait penser à mon (tout nouveau) prof d'info qui après avoir parler des derniers CPU en citant les pentium 5 à parler des capacités des DD: Il expliquait que le bas de gamme était 200 G0...
-no comment-

Kill Mario

./Post n°34 Marquer comme non lu.

serioussam

Ecrit le: Jeudi 16 septembre 2004 à 22:22

Membre: Maître Ultime

Messages: 3636

Membre n°23

Inscrit le 01 février 2004

Retour sujet, messieurs

la shasse é ouvèrte poure lay maychants

./Post n°35 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 17 septembre 2004 à 11:33

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

squale92 :

Il faudrait plutôt penser à l'efficacité (taille, vitesse) des programmes résultants qu'utiliser des concepts objets juste pour le plaisir de les utiliser.

Ce n'est pas du tout pratique, parce que du coup, si on veut déboguer, on ne sait plus quelle est la fonction to_char appelée (et ça porte aussi à des noms de fonctions illisibles dans l'assembleur produit, parce qu'il faut bien que le linker sache quelle des deux fonctions tu voulais, et qu'il y a donc du name mangling)! Avoir type_A_to_char et type_B_to_char est beaucoup plus clair.

Mais si tu veux vraiment la surcharge, cf. builtin_types_compatible_p. Ça peut se faire avec une macro GNU.
-Edité le Vendredi 17 septembre 2004 à 11:35 par Kevin Kofler-

./Post n°36 Marquer comme non lu.

squale92

Ecrit le: Vendredi 17 septembre 2004 à 12:39

Membre: Maître

Messages: 145

Membre n°94

Inscrit le 13 mars 2004

Avoir type_A_to_char et type_B_to_char est beaucoup plus clair.

mais nettement moins pratique...

tu as une variable a, unne variable b, et une variable c, faire un
printf("%s, %s, %s", to_char(a), to_char(b), to_char(c));
est nettement plus pratique qu'un
printf("%s, %s, %s", to_char_A(a), to_char_B(b), to_char_C(c));
(encore là ça va, vu que les variables ont le nom de leur type... mais dans un programme normal, ça serait loin d'être le cas... une solution à ce problème est la notation polonaise (je crois que c polonaise... plus trop sûr

enfin, à la MS, quoi, en préfixant chaque nom de variable d'une ou deux lettres précisant son type))

avec le nom du type inclu dans chaque nom de fonction, à chaque fois que tu veux appeler la fonction, il faut que tu cherche de quel type est la variable...
et si jamais tu décide de changer une variable de type (la passer de short à long, par exemple), il te faudra changer tous les appels de fonction lui correspondant

Mais si tu veux vraiment la surcharge, cf. builtin_types_compatible_p. Ça peut se faire avec une macro GNU.

OK, merci

Pascal MARTIN
http://www.squalenet.net

./Post n°37 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 17 septembre 2004 à 13:52

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

squale92 :

Avoir type_A_to_char et type_B_to_char est beaucoup plus clair.

mais nettement moins pratique...

tu as une variable a, unne variable b, et une variable c, faire un
printf("%s, %s, %s", to_char(a), to_char(b), to_char(c));
est nettement plus pratique qu'un
printf("%s, %s, %s", to_char_A(a), to_char_B(b), to_char_C(c))

(encore là ça va, vu que les variables ont le nom de leur type... mais dans un programme normal, ça serait loin d'être le cas... une solution à ce problème est la notation polonaise (je crois que c polonaise... plus trop sûr

enfin, à la MS, quoi, en préfixant chaque nom de variable d'une ou deux lettres précisant son type))

C'est la notation hongroise, et franchement, c'est affreux comme notation. Elle a un minimum de sens pour des types structure comme tes A, B, C, parce que le nom de la structure (par exemple WINDOW) décrit à quoi correspond la variable et pas sa représentation interne. Donc pour changer la représentation interne, on ne change que la structure (et dans ton cas aussi window_to_char) et pas le nom du type ou de la variable. Même si dans ce cas, je préfère myDialogWindow (qui suit l'ordre des mots naturel) à wndMyDialog (notation hongroise). Mais les préfixes pour des types comme int ou long, beurk.

Et au passage, to_char_A, beurk comme nom. Je préfère de loin A_to_char. (Encore une fois: ordre des mots naturel.)

avec le nom du type inclu dans chaque nom de fonction, à chaque fois que tu veux appeler la fonction, il faut que tu cherche de quel type est la variable...
et si jamais tu décide de changer une variable de type (la passer de short à long, par exemple), il te faudra changer tous les appels de fonction lui correspondant

Ben, short vs. long, on fait une fonction qui prend un long et on l'utilise que la variable soit de type short ou long.

./Post n°38 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 17 septembre 2004 à 13:55

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

En résumé, je distingue 2 cas:

long long

long double

:: Index » Forum Ti68K » News » L'avenir des programmeurs TI... (42 réponse(s))

Pages : 2/3 |« « 1 [2] 3 » »|

Page générée en 48.65ms avec 20 requetes