C++/C et Ti - Page 7

jackiechan
a écrit : Et puis, il me semble que PpHd a dit dans le thread que tu cites que PedroM utilise en interne, des fonctionnalités du kernel.

C'est vrai, dans une certaine mesure. Mais ça se limite quand-même. Par exemple, le code de relogement des programmes pour kernel (et c'est ce qui prend le plus de place) est parfaitement retirable. Mais par exemple une grande partie de kernel::exec est nécessaire pour l'implémentation de NG_execute et ShellExecuteCommand (la deuxième devrait d'ailleurs utiliser la première normalement, mais bon) même si on n'a pas besoin de support pour les programmes pour kernel.

XDanger
a écrit : Tout dépendra des ROM_CALLs que PpHd réimplémentera. J'ai dit pourquoi je ne lui ferais pas de liste (il en refuserait certainement une grande partie, que ce soit pour PedroM 1.xx ou PedroM 2.xx)...

Ce n'est pas un problème. S'il refuse d'implémenter certains ROM_CALLs:
* on peut les implémenter nous-mêmes.
* s'il les refuse quand-même, on forke.
C'est ça le logiciel libre!

C'est vrai, dans une certaine mesure. Mais ça se limite quand-même. Par exemple, le code de relogement des programmes pour kernel (et c'est ce qui prend le plus de place) est parfaitement retirable. Mais par exemple une grande partie de kernel::exec est nécessaire pour l'implémentation de NG_execute et ShellExecuteCommand (la deuxième devrait d'ailleurs utiliser la première normalement, mais bon) même si on n'a pas besoin de support pour les programmes pour kernel.

Vu le gain qu'il va y avoir pour les inconvéniant que ca pour poser ca n'en vaut vraiment pas la peine. Plustôt que de débatre de ce qu'on pourait retirer de PedroM vous feriez mieux de penser a ce qu'on peut y rajouter.

Ce n'est pas un problème. S'il refuse d'implémenter certains ROM_CALLs:
* on peut les implémenter nous-mêmes.
* s'il les refuse quand-même, on forke. C'est ça le logiciel libre!

Je vois pas pourquoi PpHd refuserai d'implémenter des ROMCALLs si vous lui offrez
Quant au fork C'est ce donner beaucoup de mal pour un truc que vous méprisez a ce point

si vous etes pas content, vous pouvez aussi dévellopé votre propre ROM 200% _nostub...

> Je vois pas pourquoi PpHd refuserai d'implémenter des ROMCALLs si vous lui offrez
Si on lui offre le code complet, j'ai du mal à voir aussi.

En revanche, si on lui suggère juste des noms, alors là, il risque d'en refuser beaucoup. Ca dépend bien sûr de ce qu'on demande, mais si je demande quelque chose, il y aura les trucs de graphing et de calcul symbolique, qu'il refusera pendant longtemps encore...

Bah disons qu'il est encore libre de ce qu'il a envie de coder en priorité ou non et c'est normal qu'il commence par ce qui l'interesse le plus

Bah, je sais très bien et je n'ai pas dit le contraire...

Si tu regardes bien, dans TIGCC tu as C et GNU C. Le C c'est le C simple et le GNU C c'est une forme de C++.

Ce n'est pas du C++.

Monsieur Fesse
a écrit : Si tu regardes bien, dans TIGCC tu as C et GNU C. Le C c'est le C simple et le GNU C c'est une forme de C++.

le GNU C n'a *RIEN* a voir avec le C++

Ha non, GNU C n'est pas du C++...

"Monsieur Fesse" serait-il un flooder, par hasard ? Son intervention ne nous remet pas dans le topic...

pff ... du C++

y'a quand même quelques points communs mais ca reste du C.

Ils ont rajouté des trucs comme "inline" et la balise de commentaire "//" je crois...

#189 : on dirait un (très) débutant un peu (très) prétentieux. Mais comme il apporte une touche comique au forum, moi je le trouve très utile

Blue_Z
a écrit : Ils ont rajouté des trucs comme "inline" et la balise de commentaire "//" je crois...

Ce n'est pas du C++, c'est dans le standard ISO C99, ça.

"inline" aussi est du standard C99 ?
Quand aux commentaires unilignes, ça fait un moment qu'ils sont là, il n'y a que mon TRES vieux compilateur (Micro$oft QuickC) qui me dit "Avertissement CXXXX: 'commentaire uniligne' est une extension nouvelle"...

Link
a écrit : "inline" aussi est du standard C99 ?

Oui.

Quand aux commentaires unilignes, ça fait un moment qu'ils sont là, il n'y a que mon TRES vieux compilateur (Micro$oft QuickC) qui me dit "Avertissement CXXXX: 'commentaire uniligne' est une extension nouvelle"...

Si tu le mets en mode ISO C90 strict, il ne devrait pas accepter:
gcc -ansi te le rejettera carrément avec un "parse error" (parce que ça peut changer la signification du code, cf. la séquence //*).
gcc -pedantic te donnera un warning, gcc -pedantic-errors une erreur.
En revanche gcc -std=c99 -pedantic-errors (mode ISO C99 strict) accepte, évidemment.

Je n'ai pas dit que le GNU C était du C++ mais une FORME de C++.

il a quelque petits points commun mais de la a dire qu'il a une forme de C++ y'a un gouffre

ouai c'est complètement différent, je crois bien.

disons qu'avec des comentaires en //, les nested functions et les déclaration en cours de procedure... on s'en rapporche un peu mais on en reste très loin et puis il manquera toujours au C l'objet donc il y aurra toujours une très grosse différence entre les 2.

Mmm, je suis pas sûr que les fonctions imbriquées soient valables en C++.

Les fonctions imbriquées ne sont pas du C++.