g++ TI - Page 1

Bon, malgré l'avis *assez* tranché de Kevin sur la question, j'aimerais savoir qui serait pour un
portage de C++ sur TI.
Kevin a certes dit dans tous les sens que ça ferait des programmes "immenses et lents", mais même si
le C++ est incontestablement plus lour que le C, ça ne fait pas des progs de 5 Ko simplement pour faire un Hello World.

J'aimerais aussi que vous gardiez à l'esprit qu'on a pas de POO sur TI, et que ça serait le langage incontournable pour ça.

Bon, alors voilà le principe:

1) Votez

2) Eventuellement, expliquez en postant, mettez vos réserves, vos suggestions...

[sondage=14044]

J'aimerais aussi que vous gardiez à l'esprit qu'on a pas de POO sur TI

Oui, parce que c'est souvent trop gourmand.

et que ça serait le langage incontournable pour ça.

Non, je pense qu'un langage interprété serait plus efficace pour faire de la POO : le plus gros problème du C++, à part la lenteur si on utilise des méthodes bourrins, c'est que le programme résultant est très gros, parce qu'il y a plein d'appels de méthodes à gérer en assembleur, alors que l'assembleur n'est pas vraiment efficace pour ça. Et en interprétant le langage, on pourrait résoudre le problème de la taille, tout en gardant évidemment la lenteur (mais après on pourrait parfaitement interfacer avec le C).

En plus s'il n'y a pas la STL, le C++ perd une partie de son intérêt (et s'il y a la STL, on va s'amuser avec les nombreuses alloc de mémoire).

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

On peut le porter de façon simple et en utilisant le moins possible les classes dans les libs standard,
laissant simplement à l'utilisateur la possibilité de faire ses classes pour son propre usage.
Ainsi, la langage ne devient gros et lent que si l'utilisateur abuse.

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)

Au fait:

[sondage=14045]

On peut le porter de façon simple et en utilisant le moins possible les classes dans les libs standard,
laissant simplement à l'utilisateur la possibilité de faire ses classes pour son propre usage. Ainsi, la langage ne devient gros et lent que si l'utilisateur abuse.

Si y a pas la classe std::string et std::vector, c'est même pas la peine d'essayer de faire autre chose que du C

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.
Et c'est pareil avec les string

On serait obligé de refaire la gestion du heap, et il ne faut pas oublier que le fait d'utiliser des string au lieu de char[] amènerait à un code bien plus gros et lent. Franchement, à mon avis, autant en profiter pour faire un vrai langage interprété. Cela dit si tu veux porter g++, c'est pas moi qui t'en empêcherai, hein

./4> t'es relou avec tes sondages

Par std::string, tu veux dire:

namespace std {
00003 class string
00004 {
00005 char *ptr;
00006 int len;
00007 };
00008 }

Dans ce cas,
typedef char* STRING; // ou un truc comme ça est bien plus simple.

Et puis si l'utilisateur a vraiment besoin de std::string, il se la fera lui-même
(Elle sera éventuellement dans la doc ou dans un zip de trucs optionnels)

Donc, on reste au char[]. D'ailleurs, dans la pratique, en C++ on se sert souvent
de ça plutôt que std::string. (Normal, c'est une aberration de prendre un axiome de base pour le compliquer)

Quant à std::vector, faut voir, mais comme je l'ai dit ci-haut je virerai tout ce que je peux comme classes, objets, héritage etc...
prédéfinis. (Ca m'a toujours agaçé sous VC++ qu'on soit dans tel namespace avec mon application qui hérite d'une montagne
de trucs)

Je veux essayer de faire du C++ sans les merdes du C++.

Essaye de programmer en C++ avant de songer à vouloir le porter sur TI... Parce que si pour toi std::string correspond à un typedef char *, tu n'as pas dû comprendre grand-chose au C++

(Ca m'a toujours agaçé sous VC++ qu'on soit dans tel namespace avec mon application qui hérite d'une montagne de trucs)

...

Non, ça ne correspond pas, mais je ne laisserait pas à l'utilisateur le choix débile d'utiliser des strings, je ne les définirai
pas.

Et j'ai précisé qqch comme ça en commentaire, c'est bien pour quelquechose: j'étais sûr que c'était faux.

Bah oui mais si y a pas de support des string et de plein d'autres structures de données de haut niveau le C++ perd une grande partie de son intérêt

Il y sera pour ceux qui le veulent, ou le demandent.

Mais j'envisage plus le C++ pour permettre des classes utilisateur.

En clair: je ne flooderai pas les headers ou le fichier .a avec des fonctions et des classes grosses comme des tanks.
Si l'utilisateur le veut, il le fera.

Ma conception c'est plus de pouvoir faire une classe Chien avec les méthodes Aboyer() et Manger() par exemple,
plutôt que de permettre l'usage de trucs de bourrins inutiles (un char[] va bien mieux qu'un string).

Alors c'est que tu n'as pas besoin de POO, sauf pour te la péter

Non. Tu donnes l'impression de ne pas savoir faire de classes par toi-même et d'avoir absolument besoin
qu'il y en ait prédéfinies et toutes cuites avec le compilateur.

La POO pour moi est censée:
1) Aider à représenter quelquechose de concret (Donc une classe totalement abstraite, comme std::string, peut aller se
faire foutre, car ce n'est pas fesable de la mettre, sinon la taille.........................)

2) Faciliter la vie du programmeur. Les compilateurs genre VC++ font le contraire, ils compliquent les choses
car selon eux tout doit être un objet, d'où ton application qui n'est qu'une instance d'une classe héritant de 200.

Je ne ferai pas un compilateur avec toutes les classes que veulent les gens. De toute façon sans
ce compilateur y'aurait même pas de classe sur TI.

La POO arrange la vie du programmeur, elle n'a jamais été utile pour l'optimisation.

Quelqu'un qui ne définit pas ses propres classes et a besoin qu'il y en ait dans le compilateur est complètement à côté de la POO.

[semi-troll]
Si tu veux faire de la POO sur TI, l'Objective-C est à mon avis un bien meilleur choix. C'est beaucoup plus léger, et c'est aussi plus orienté objet que le C++.
[/semi-troll][troll]
En clair, l'Objective C est incomparablement mieux que le C++.[/troll]

Quelqu'un qui ne définit pas ses propres classes et a besoin qu'il y en ait dans le compilateur est complètement à côté de la POO.

Ô grand maître, je m'incline devant ton savoir

Sally > J'y ai pensé. Mais le dernier en date qui a eu cette pensée a mystérieusement disparu . (Demande à Kevin)
Il est bien plus léger, tolère l'héritage simple et existe en compilateur dans la GNU Compiler Collection.

Mais une fois que le C++ serait porté sur TI, on en serait à 2 compilateurs GNU sur TI.
Ca pourrait être très bon signe pour la prog TI, puisque de là on devrait être capable d'adapter
les autres compilos, le Fortran, l'Ada, le Java, et l'Objective C bien sûr. Et même peut-être le Pascal,
mais c'est pas très utile, il y a l'Ultra Pascal, et le Pascal GNU est un peu à part j'ai l'impression.

Mais je connaît bien plus le C++ que l'Objective C, et puis les rapports avec le C sont si grands que
le portage de libs utilisables par le C est quasi-immédiat comme je l'ai dit.

Pollux > Oui, si pour toi la programmation orienté objet se résume à jongler avec des classes totalement abstraites et inutiles,
c'est ton choix mais ça se fera sans moi.

Une classe sert soi quand elle est concrète, pour simplifier la vie du programmeur, soit quand elle est abstraite ET sert à
quelquechose. Si tu veux la classe string, définie ainsi:

class string
{
char *ptr;
int len;
};

Ben dans ce cas tu peux aussi bien faire une structure en C ça sera exactement pareil.
Et ne me dit pas que cette classe a besoin d'hériter de quoi que ce soit ou qu'il pourrait
être utile de faire hériter une classe de celle-ci.

Bon, Pollux est le seul qui n'essaierait même pas le compilateur.
Les voix pour et celles contre sont à égalité.
Je remets les deux sondages:
[sondage=14044]

[sondage=14045]

Pollux > Oui, si pour toi la programmation orienté objet se résume à jongler avec des classes totalement abstraites et inutiles, c'est ton choix mais ça se fera sans moi.

Wow! Mais tout le monde n'est pas un Dieu de la programmation, hein, y en a qui préfèrent avoir des classes prédéfinies parce qu'ils ont du mal à programmer Hein, c'est bizarre de pas vouloir reprogrammer la gestion des chaînes de caractères, des tableaux, des tris pour chaque programme? Je n'ai envie de réimplementer qqch que si cette réimplémentation me permet de gagner qqch.

Une classe sert soi quand elle est concrète, pour simplifier la vie du programmeur, soit quand elle est abstraite ET sert à quelquechose.

Ouais! Alors la classe std::string, c'est une classe abstraite qui sert à rien?

Si tu veux la classe string, définie ainsi:

class string
{
char *ptr;
int len;
};

Ben dans ce cas tu peux aussi bien faire une structure en C ça sera exactement pareil.
Et ne me dit pas que cette classe a besoin d'hériter de quoi que ce soit ou qu'il pourrait être utile de faire hériter une classe de celle-ci.

Mais bien sûr! Pourquoi n'ai je pas pensé plutôt à faire une structure! Au fait, tu sais ce que c'est un constructeur?

Bon, Pollux est le seul qui n'essaierait même pas le compilateur.

N'importe quoi, je n'ai même pas voté

[cite]Pollux :

Wow! Mais tout le monde n'est pas un Dieu de la programmation, hein, y en a qui préfèrent avoir des classes prédéfinies parce qu'ils ont du mal à programmer Hein, c'est bizarre de pas vouloir reprogrammer la gestion des chaînes de caractères, des tableaux, des tris pour chaque programme? Je n'ai envie de réimplementer qqch que si cette réimplémentation me permet de gagner qqch.

t1 tu pousses tout à l'extrême. Je mettrai (ou mettrais ) ce qui est
utile, pas ce qui est con.

Ouais! Alors la classe std::string, c'est une classe abstraite qui sert à rien?

Mais bien sûr! Pourquoi n'ai je pas pensé plutôt à faire une structure! Au fait, tu sais ce que c'est un constructeur?

Oui, c'est une fonction. Quoi qu'il se passe quant tu as fait ta classe et
déclaré le constructeur quant tu l'appelleras ça feras un appel de fonction
que tu peux faire en C, tu déclare un pointeur vers la structure et
ta fonction alloue ça par le heap avec des valeurs par défaut.

Donc si tu veux faire mumuse avec "comment compliquer l'idée d'une chaîne
de caractères pour flooder la caltos", réjouis-toi, tu peux le faire en C.

N'importe quoi, je n'ai même pas voté

. Bon ben c'est un petit malin qui est passé juste avant toi pour
simplement voter non.

[cite]BlueSilk :

Pollux
:

Wow! Mais tout le monde n'est pas un Dieu de la programmation, hein, y en a qui préfèrent avoir des classes prédéfinies parce qu'ils ont du mal à programmer Hein, c'est bizarre de pas vouloir reprogrammer la gestion des chaînes de caractères, des tableaux, des tris pour chaque programme? Je n'ai envie de réimplementer qqch que si cette réimplémentation me permet de gagner qqch.

t1 tu pousses tout à l'extrême. Je mettrai (ou mettrais ) ce qui est
utile, pas ce qui est con.

Ouais! Alors la classe std::string, c'est une classe abstraite qui sert à rien?

Je crois que c'est pas la peine de discuter plus longtemps...

Mais bien sûr! Pourquoi n'ai je pas pensé plutôt à faire une structure! Au fait, tu sais ce que c'est un constructeur?

Oui, c'est une fonction. Quoi qu'il se passe quant tu as fait ta classe et
déclaré le constructeur quant tu l'appelleras ça feras un appel de fonction
que tu peux faire en C, tu déclare un pointeur vers la structure et ta fonction alloue ça par le heap avec des valeurs par défaut.

Arf mais il a tout compris!
Par exemple, pour rester avec que des string :

string ReadIt() {
  string s;
  while (!AtEnd()) {
    s+=GetWord();
    if (hasAnError)
      throw "Error while parsing '"+s+"'";
  }
  return s;
}

Pour moi ça donne, avec seulement une structure string :

string ReadIt() {
  string s=NewString();
  TRY {
    while (!AtEnd()) {
      string t=GetWord();
      string u=Concat(s.ptr,t.ptr);
      DelString(s);
      DelString(t);
      s=u;
      if (hasAnError) {
        // construire la chaîne
        string w=Concat("Error while parsing '",s.ptr);
        string x=Concat(w.ptr,"'");
        DelString(w);
        // nettoyer les var locales
        DelString(s);
        ER_throw(x);
      }
    }
  } CATCH (e) {
    // si on choppe une exception, il faut impérativement nettoyer s
    DelString(s);
    ER_throw(e);
  }
  return s;
}

Tu crois vraiment que la classe string est inutile? J'ajouterais d'ailleurs que si on n'impose pas la contrainte que Concat et DelString ne lance jamais d'exception (ce qui d'ailleurs pourrait arriver avec Concat à cause de pbs de mémoire), on a encore tout une rangée de TRY/CATCH que je n'ai pas mise, à chaque déclaration d'un string.

Donc si tu veux faire mumuse avec "comment compliquer l'idée d'une chaîne de caractères pour flooder la caltos", réjouis-toi, tu peux le faire en C.

Ah mais oui! D'ailleurs je me demande pourquoi ces idiots ont inventé la STL.

N'importe quoi, je n'ai même pas voté

. Bon ben c'est un petit malin qui est passé juste avant toi pour simplement voter non.

Bah oui. Si tu veux j'ai encore ma voix, donc je peux voter pour ce que tu veux si tu veux vérifier

Pollux
: Je crois que c'est pas la peine de discuter plus longtemps...

Tu crois vraiment que la classe string est inutile?

Non, elle est utile mais elle n'est pas ma priorité. Kevin a bien survécu
en C sans faire de classe string ni de surdéfinition.
De toute manière, si elle est *vitale* on peut toujours l'ajouter une fois
le compilo fait. Ou la définir et encourager les gens à utiliser les char[].

Bah oui. Si tu veux j'ai encore ma voix, donc je peux voter pour ce que tu veux si tu veux vérifier

Vote pour !!!

Non, elle est utile mais elle n'est pas ma priorité.

Je cite :
[ul][cite]BlueSilk :

Pollux :
Ouais! Alors la classe std::string, c'est une classe abstraite qui sert à rien?

[/ul]
Faut savoir, et en plus tu as dit que tu ne comptais pas les implémenter plus haut

(et ne me dit pas que c'était ironique, vu le smiley...)

Kevin a bien survécu en C sans faire de classe string ni de surdéfinition.

Où est le rapport avec Kevin? Bien sûr qu'on peut programmer en C! Mais n'importe quelle personne ayant déjà programmé en C sait parfaitement que c'est chiant à manipuler et que les trois quarts des lignes ne sont que des vérifications...

De toute manière, si elle est *vitale* on peut toujours l'ajouter une fois
le compilo fait. Ou la définir et encourager les gens à utiliser les char[].

Elle n'est pas vitale. Mais programmer en C++ tout en utilisant des pointeurs partout et en manipulant des char * en bas niveau, c'est débile! C'est précisément pour simplifier la gestion de ce genre de choses qu'il y a les constructeurs/destructeurs! Ou alors si la seule chose qui t'intéresse c'est avoir la syntaxe "objet.Méthode()", alors programme plutôt un préprocesseur

Pollux :
Faut savoir, et en plus tu as dit que tu ne comptais pas les implémenter plus haut
(et ne me dit pas que c'était ironique, vu le smiley...)

La classe sd::string ne sert qu'à se faciliter la vie. Ce n'est donc pas une priorité.
La priorité c'est les utilisateurs, et qu'ils puissent faire de la POO.
La seule raison pour laquelle je l'implémenterais serais la surdéfinition
de '+', que je devrais déplacer à char[], ça irait mieux.
Donc en définitive, ce n'est pas sûr que je la mettrai.

Où est le rapport avec Kevin? Bien sûr qu'on peut programmer en C! Mais n'importe quelle personne ayant déjà programmé en C sait parfaitement que c'est chiant à manipuler et que les trois quarts des lignes ne sont que des vérifications...

Ben après tant de temps en assembleur et en C, les utilisateurs pourront
bien continuer à se faire chier un moment en C++.

Elle n'est pas vitale. Mais programmer en C++ tout en utilisant des pointeurs partout et en manipulant des char * en bas niveau, c'est débile! C'est précisément pour simplifier la gestion de ce genre de choses qu'il y a les constructeurs/destructeurs!

Et s'adapter à sa plate-forme, c'est débile ? Je ne suis pas le genre qui
va dire que comme on ne peut pas programmer en C++ comme sur PC,
vaut mieux ne pas porter le C++, car ce raisonnement-là est débile.

Ou alors si la seule chose qui t'intéresse c'est avoir la syntaxe "objet.Méthode()", alors programme plutôt un préprocesseur

Ben nan, j'ai qu'à le faire direct avec struct.ptrfunc()
Mais l'héritage, le polymorphisme, l'encapsulation etc....
Ca finit par sortir un peu des cordes du C.

BlueSilk
:

Pollux :
Faut savoir, et en plus tu as dit que tu ne comptais pas les implémenter plus haut
(et ne me dit pas que c'était ironique, vu le smiley...)

La classe sd::string ne sert qu'à se faciliter la vie. Ce n'est donc pas une priorité. La priorité c'est les utilisateurs, et qu'ils puissent faire de la POO.

Et la POO, tu penses que ça sert à autre chose que de se faciliter la vie? Le C++ n'est pas plus Turing-complete que le C.

La seule raison pour laquelle je l'implémenterais serais la surdéfinition
de '+', que je devrais déplacer à char[], ça irait mieux. Donc en définitive, ce n'est pas sûr que je la mettrai.

Tu veux redéfinir char[]+char[] ?

(j'ai peur )

Où est le rapport avec Kevin? Bien sûr qu'on peut programmer en C! Mais n'importe quelle personne ayant déjà programmé en C sait parfaitement que c'est chiant à manipuler et que les trois quarts des lignes ne sont que des vérifications...

Ben après tant de temps en assembleur et en C, les utilisateurs pourront bien continuer à se faire chier un moment en C++.

Alors où est l'intérêt de passer en C++ si c'est pour continuer à se faire chier?

Elle n'est pas vitale. Mais programmer en C++ tout en utilisant des pointeurs partout et en manipulant des char * en bas niveau, c'est débile! C'est précisément pour simplifier la gestion de ce genre de choses qu'il y a les constructeurs/destructeurs!

Et s'adapter à sa plate-forme, c'est débile ? Je ne suis pas le genre qui
va dire que comme on ne peut pas programmer en C++ comme sur PC, vaut mieux ne pas porter le C++, car ce raisonnement-là est débile.

On peut programmer en C++ sur PC il me semble
Et je ne vois pas où tu veux en venir.

Ou alors si la seule chose qui t'intéresse c'est avoir la syntaxe "objet.Méthode()", alors programme plutôt un préprocesseur

Ben nan, j'ai qu'à le faire direct avec struct.ptrfunc()
Mais l'héritage, le polymorphisme, l'encapsulation etc.... Ca finit par sortir un peu des cordes du C.

* l'héritage -> euh, excuse-moi mais si tu n'as pas l'utilité des classes tu n'auras pas l'utilité de l'héritage, hein
* le polymorphisme -> ah oui tu veux aussi implémenter les templates?
* l'encapsulation -> ça ne devient nécessaire que si tu bosses sur des gros progs, ce qui n'est pas le cas sur TI

Pollux
: Et la POO, tu penses que ça sert à autre chose que de se faciliter la vie? Le C++ n'est pas plus Turing-complete que le C.

Mal exprimé.

Tu veux redéfinir char[]+char[] ?

(j'ai peur )

Alors où est l'intérêt de passer en C++ si c'est pour continuer à se faire chier?

Où était l'intérêt de passer en C puisqu'on se faisait chier, comme en
assembleur ? Rien. Simplement porter un langage.

On peut programmer en C++ sur PC il me semble Et je ne vois pas où tu veux en venir.

Je voulais dire que c'est pas parcequ'il est impossible de programmer sur
TI en C++ de la même façon que sur PC qu'il ne faut pas adapter
le C++ sur TI.

* l'héritage -> euh, excuse-moi mais si tu n'as pas l'utilité des classes tu n'auras pas l'utilité de l'héritage, hein

On se répète: dans l'état actuel des choses on peut pas se poser la question puisque c'est pas possible du tout.

* le polymorphisme -> ah oui tu veux aussi implémenter les templates?

Oui, mais pas dans la lib par défaut.

* l'encapsulation -> ça ne devient nécessaire que si tu bosses sur des gros progs, ce qui n'est pas le cas sur TI

Et ben on s'en servira pas !

Je crois que tout est résumé là-dedans :

dans l'état actuel des choses on peut pas se poser la question puisque c'est pas possible du tout.

Si on peut pas se poser la question de savoir si c'est utile, alors ne la pose pas et implémente-le...

Pollux :
Si la seule chose qui t'intéresse c'est avoir la syntaxe "objet.Méthode()", alors programme plutôt un préprocesseur

Ca existe : topics/27557-programmer-en-c-pour-les-ti8992v200-est-possible