Un truc que j'ai pas pigé - Page 2

Tu t'enfonce mon pauvre... tu t'enfonce..

Thibaut (./29) :
Vous exagérez un peu avec KonanYao. Il ne parlait pas explicitement du système d'exploitation. Il parlait peut-être du reste : les différents modules et logiciels qui créent l'interface et les applications de la machine.

Merci Thibaut,c'est exactement de ça que je parlais.
Que Nucleus RTOS et le C.A.S soient codés en C,c'est plus ou moins normal.Il serait peu judicieux d'écrire complètement un O.S en C++,Java ou autre langage de relativement haut niveau.Et le C.A.S vient de Derive qui a été developpé pendant des decennies par une excellente équipe de developpeurs et ce serait con de ne pas profiter du fruit de leur travail.
Mais que TI veuille tout coder en C bien que leur soft semble assez complexe et ce en un temps assez limité(environ 3 ans d'après ce que j'ai oui dire ce qui est moins encore que le temps a été necessaire pour developper la première version de la TI92),je trouve ça plus qu'inquiétant.
Et comme resultat on voit les problèmes qu'a la TI-NSpire dont la liste ne cesse de s'allonger et je pressens qu'elle ne va pas arrêter de s'allonger de si tôt !

Le C++ est de loin, pas du tout un langage de haut niveau, mais plutot un langage au meme niveau que le C..

Godzil (./31) :
Tu t'enfonce mon pauvre... tu t'enfonce..

Je te signale que c'est pas moi qui est commencé mais par contre je sais très bien rendre les coups !

Et tu n'as pas repondu à ma question est ce oui ou non Microsoft qui a écrit toutes les applications qui tournent sur Windows ?
Si non comme je le pense pourquoi l'équipe de Nucleus RTOS irait écrire tout le soft de la TI-NSpire comme si cette équipe n'avait pas mieux à faire que se focaliser sur les applis d'un client.

Godzil (./33) :
Le C++ est de loin, pas du tout un langage de haut niveau, mais plutot un langage au meme niveau que le C..

Qu'est ce qui est difficle à comprendre dans la phrase "de relativement haut niveau".
Et si C++ est un langage de même niveau que le C,d'ou vient alors tout cette vague de messages de contestation contre le fait que j'ai preconisé que TI aurait du utiliser le C++ a la place du C ?

(je viens de lire tout le topic, t'es pas obligé d'être agressif comme ça, godzil... :/)

Godzil (./33) :
Le C++ est de loin, pas du tout un langage de haut niveau, mais plutot un langage au meme niveau que le C..

bien sûr on peut programmer en C++ au même niveau qu'en C, mais en général avec la STL [par exemple] le C++ permet de se mettre à un niveau clairement plus élevé que le C (même si y a pas certaines caractéristiques de haut niveau style type-safety)

Mais dire qu'on éviterait des erreurs de programmation avec C++ c'est se tromper.

ExtendeD (./15) :
Fais du C++ sans maîtriser le C, je te garantie que t'es mort d'avance.

Je connais bien ces 2 langages et je dois dire que maitriser le C avant de programmer le C++ peut être très utile mais peut biaiser mechamment l'utilisation correcte qu'un developpeur pourrait faire du C++ notamment au niveau du concept objet.
Personnalement je suis heureusement passer de C à Java avant d'apprendre le C++.
De ce fait je comprenais parfaitement les concepts objets avant d'utiliser le C++ et j'ai donc pu limiter au maximun le fait de faire principalement que du C lorsque j'écrivais des programmes C++.

./34: je vois pas quoi répondre a de telle absurditée Je parle de Nucleus, et c'est suremnet pas TI qui a dévelopé Nucleus, et Nucleus est un OS, le CAS une application, tu vois la différence ? C'est pas parceque le CAS est developé par TI que ça va forcement faire des trous de Nucleus. Alors reapprend un peu ce qu''est l'informatique stp..

./35: parceque le C++ n'est pas forcement adapté a l'embarqué, du moins ça dépend des contraintes, et le C++ n'est pas forcement a la portée d'un developpeur C "brute"

et la STL c'est le genre de choses a oublier si tu veux faire de l'embarqué donc bon...

./38 : Attention, il y a 2 problèmes :
- Faire un mélange malsain (sachant qu'un mélange sain est possible) de procédural avec de l'objet
- Utiliser C++ sans connaître parfaitement C, alors que C++ intègre quasimment tout C

je dirais meme que le C++ c'est du C avec notion objets (oui ça parais idiot dit comme ça), donc une bonne connaissance du C est indispensable

Godzil (./39) :
./34: je vois pas quoi répondre a de telle absurditée Je parle de Nucleus, et c'est suremnet pas TI qui a dévelopé Nucleus, et Nucleus est un OS, le CAS une application, tu vois la différence ? C'est pas parceque le CAS est developé par TI que ça va forcement faire des trous de Nucleus. Alors reapprend un peu ce qu''est l'informatique stp..

Dis moi Godzil je parle en chinois ou en egyptien ancien ou tu as des difficultés à comprendre mes posts ?

TI n'a pas developpé Nucleus RTOS pas plus que l'équipe de Nucleus n'a écrit le soft de la TI-NSpire(à par l'O.S sous jascent) et les applications de la NSpire.
A part l'O.S sous jascent,TI et d'autres partenaires(Hydryx,l'équipe Cabri geomete,etc...) ont écrit tout le reste du soft.
Et c'est la partie du soft qui tourne sur Nucleus que TI aurait du,selon moi,écrire en C++(sauf peut être le C.A.S et les parties critiques) et ainsi profiter des avantages qui vont avec,un peu comme Casio l'a fait avec le soft de la ClassPad,pour se simplifier la vie sur le long terme.
Je n'ai quand même pas imaginer que TI a eu beaucoup de difficultés à developer puis à maintenir le soft de la TI92 qui était beaucoup plus simple.
Mais si a l'époque ils n'avaient pas le choix car la machine n'avait qu'un 68k à 10 puis 12 Mhz et seulement 128 puis 256 ko de RAM,avec la NSpire qui a un proc 32 bits RISC à 150 Mhz et 32 Mo de RAM,il ne devrait plus avoir ce genre de limitations.
Tu comprends maintenant ou je dois expliquer encore plus simplement ?
Et je t'assure que si là ou je suis je ne connais pas l'informatique ce n'est surement pas toi qui pourrais me l'apprendre !

ExtendeD (./40) :
./38 : Attention, il y a 2 problèmes :
- Faire un mélange malsain (sachant qu'un mélange sain est possible) de procédural avec de l'objet
- Utiliser C++ sans connaître parfaitement C, alors que C++ intègre quasimment tout C

Je suis parfaitement d'accord !

Godzil a peut-être ses ragnagnas aujourd'hui

oué ça m'arrive aussi, parfois personne n'est parfait (et pour dévier vââchement, les hommes aussi ont des cycles d'humeur il parait)

bon allez les zamis, allons boire un café/choco/bière/chaispakoi/verre d'eau et revenons gentiment à la discussion. Ne nous perdons pas trop dans ces discussions, nous savons tous très bien que ce sont des appréciations personnelles et qu'on aura forcément des vues différentes

KonanYao
Godzil

essayons plutot de savoir quelles étaient les vues de TI en faisant deux versions, en comparaison de ce qu'on a maintenant , la 84+ et la titanium.

KonanYao (./9) :
codé à 100 % en C à ce qu'il parait ce qui est assez inquiétant)

Aie, aie, aie. Les commandes de vols des avions sont écrits en C.

KonanYao (./32) :
Mais que TI veuille tout coder en C bien que leur soft semble assez complexe et ce en un temps assez limité(

Disons que si Nuclueus est écrit en C, CAS/Derive est écrit en C, zlib est écrit en C, etc et ils ont des programmeurs C, alors le fait que le choix du C ne me choque pas plus que ca.
S'ils avaient choisis un autre CAS (par exemple, giac) le choix du C++ aurait été évident.

oué, heu, bon, viens prendre un café toi aussi #cafe#

Pas à 19H du soir. Une bière par contre.

loul

je viens d'en boire une, une Hou-gar-Dên

squalyl (./18) :
Et puis faire un OS embarqué en C++ c'est un peu... incongru, quoi. Ca me fait rigoler.

C'est tout à fait possible, cf. ECOS. Ceci dit, AMHA le C est plus adapté.

ExtendeD (./37) :
Mais dire qu'on éviterait des erreurs de programmation avec C++ c'est se tromper.

Une fois de plus, ça dépend de comment on l'utilise. Par exemple, je vois mal comment tu veux créer un buffer overflow avec des QString, mis à part avec quelque chose comme str.data()[31337] bien sûr. D'un autre côté, je vois mal comment on pourrait écrire un système d'exploitation rien qu'avec des classes de haut niveau comme QString ou std::string, on a forcément besoin de buffers et de tous les problèmes qui vont avec.

Kevin Kofler (./52) :

ExtendeD (./37) :
Mais dire qu'on éviterait des erreurs de programmation avec C++ c'est se tromper.

Une fois de plus, ça dépend de comment on l'utilise. Par exemple, je vois mal comment tu veux créer un buffer overflow avec des QString, mis à part avec quelque chose comme str.data()[31337] bien sûr. D'un autre côté, je vois mal comment on pourrait écrire un système d'exploitation rien qu'avec des classes de haut niveau comme QString ou std::string, on a forcément besoin de buffers et de tous les problèmes qui vont avec.

Oui mais on peut réduire au maximum l'utilisation du code écrit en C ou assembleur.

Et l'intérêt serait? Faire que ça rame encore plus et consomme encore plus de mémoire? AMS est déjà suffisamment inefficace en C.

Le C++ n'apporte rien en embarqué.

Tout dépend, pour un CAS c'est pas si mal par exemple.

peut être que je me base sur des trucs qui ont rien à voir mais

truc.cpp
#include <iostream>
int main(void) { std::cout << "Hello World" ; }

truc.c
#include <stdio.h>
int main(void) { printf("Hello World"); }

[squalyl@localhost ~]$ g++ truc.cpp
[squalyl@localhost ~]$ gcc truc.c -o b.out
[squalyl@localhost ~]$ ll a.out b.out
-rwxr-xr-x 1 squalyl users 6165 Aug 9 16:40 a.out
-rwxr-xr-x 1 squalyl users 4726 Aug 9 16:41 b.out
[squalyl@localhost ~]$ strip a.out
[squalyl@localhost ~]$ strip b.out
[squalyl@localhost ~]$ ll a.out b.out
-rwxr-xr-x 1 squalyl users 3924 Aug 9 16:41 a.out
-rwxr-xr-x 1 squalyl users 2940 Aug 9 16:41 b.out

ça doit s'améliorer avec des optimisations,chais pas, mais de base ...

qu'est ce qu'on peut faire en C++ qui est impossible en C?

En théorie rien, en pratique pour certain truc tu va te faire chier en C, et les IOStream sont pas trop réputé pour etre econome en utilisation de place...

[squalyl@localhost ~]$ gcc truc.c -o a.out
[squalyl@localhost ~]$ g++ truc.c -o b.out
[squalyl@localhost ~]$ ll *.out
-rwxr-xr-x 1 squalyl users 4726 Aug  9 16:56 a.out
-rwxr-xr-x 1 squalyl users 5187 Aug  9 16:56 b.out
[squalyl@localhost ~]$ strip *.out
[squalyl@localhost ~]$ ll *.out
-rwxr-xr-x 1 squalyl users 2940 Aug  9 16:56 a.out
-rwxr-xr-x 1 squalyl users 3336 Aug  9 16:56 b.out
[squalyl@localhost ~]$

même code exactement #chieur#

mieux:

[squalyl@localhost ~]$ gcc -O3 truc.c -o a.out
[squalyl@localhost ~]$ g++ -O3 truc.c -o b.out
[squalyl@localhost ~]$ strip *.out
[squalyl@localhost ~]$ ll *.out
-rwxr-xr-x 1 squalyl users 2956 Aug  9 16:58 a.out
-rwxr-xr-x 1 squalyl users 3352 Aug  9 16:58 b.out

g++ n'est pas gcc