Juste pour savoir - Page 3

Godzil
: Perso, pour un projet de fac, je devait devel un toolkit :/ quand j'ai vu le boulot que ct en C :/ j'ai switché en C++ et comme par miracle c'est devenu super simple ^^

J'ai toujours dit que le paradigme orienté objet est bien adapté au GUI. Programmer sans objets un programme fenêtré c'est aussi érintant que de programmer une application ISPF en CLIST (pour ceux qui ne travaillent pas sous TSO - probablement tout le monde sauf moi - imaginez faire une série de menus et sous menus pour un programme DOS en utilisant des BATCH files) .

Au GUI et à l'analyse en informatique de gestion... l'objet est quand même très approprié pour tout ce qui est gestion justement par sa souplesse (les règles de gestion, notamment dans la fonction publique, sont succeptibles d'évolutions tous les... bah allez environ 1 mois 1/2 ).

Albert Instinct
:

Kevin Kofler :
Ben, je ne le prends pas trop mal (enfin sauf l'accusation gratuite "qui se croient supérieurs aux autres" qui pourraît être du Thibaut ).

Mais "croient tout savoir sur tout" ça te dérange pas ? donc tu te prends vraiment pour un être supérieur.

Ce n'est pas parce que ça ne me dérange pas autant que l'autre accusation que ça veut dire que je crois que c'est vrai!
Évidemment que je ne sais pas tout sur tout! Personne ne sait tout sur tout!

Jean-Mouloud
:

Kevin Kofler :
Le C99 n'est pas une technologie des années 80, c'est une technologie de la fin des années 90. Il n'existait même pas en les années 80.
Pour le C89/C90, oui, il doit disparaître au plus vite. Vive le C99!

Au profit de cette putain de norme de l'Open Group / liée à l'Open Group, manipulé par Sun pour se faire du fric tous les ans avec des nouvelles normes ?

L'Open Group n'y est pour rien. C'est un comité de standardisation de ISO. Et pas mal des nouveautés adoptées viennent des extensions de GCC à l'origine.
Et pour les histoires du "fric", je te signale que les standards Open Group (Single Unix Specification et POSIX) sont désormais consultables gratuitement, donc tu accuses la mauvaise organisation. C'est ISO qui fait payer les standards! Cela dit, il y a des drafts du C99 qui circulent légalement (ISO permet la redistribution des drafts préliminaires).

Si encore ça apportait quoi que ce soit. Mais le C99 j'appelle ça du C++ sans prog objet, avec les commentaires "//" officiels et tout. On pouvait déjà faire ça avec un compilo C++ en utilisant pas de POO, m^ si c'est parfaitement con.

Le C99 apporte aussi pas mal de nouveautés qui ne sont pas dans le C++. Par exemple: les tableaux de taille variable, les constructeurs de style &(struct foo){1,2,3}, les long long, les types complexes intégrés, les fonctions inline etc. (toutes des extensions GNU à l'origine). Et aussi quelques nouveautés qui n'étaient ni du C++, ni du GNU C, par exemple les pointeurs _restrict (que les versions récentes de GCC gèrent, mais parce que c'est dans le C99, pas parce que c'était une extension GNU traditionnelle) et les constructeurs de structures variables, style &(struct foo){x,y,z} (là aussi géré par les versions récentes de GCC). Quant aux fonctionnalités héritées du C++, ils n'ont vraiment pris que les meilleures: Les commentaires // étaient gérés par pratiquement tous les compilateurs C depuis longtemps. Et les déclarations au milieu du code et les déclarations dans un for sont vraiment utiles.

Et ensuite ils feront quoi ? Les objets en C ?

Non. Le C reste du C.

Hum, c'est en vérifiant d'abord qu'on parvient à la vérité, non en écoutant des pensées de Kevin.

C'est Zeljko qui a écrit ce passage!

Kevin, c'est pas toi qui trouvait que certains ajouts du C99 étaient débiles ? (il me semble me souvenir de ça, mais je ne sais plus quelles clauses étaient visées).

Je ne pense pas, parce que Kevin n'est pas du genre à critiquer le C99 ni les extensions GNU

Hooooo saint GNU veillez sur nous !

Que votre nom soit sanctifié !

Par le C99 le GNU et le richard Stallman,

Amen

Ma critique n°1 du C99 est que les statement expressions (les expressions en ({...})) de GCC n'ont pas été mises. Elles sont très utiles (surtout pour faire des macros qui ne boguent pas si on leur passe des paramètres complexes), et c'est dommage de les voir en extension seulement.

Toujours pas de réponse pour moi...

Bon, ma mémoire défaille peut-être (mais pourtant, il me semble bien que... enfin, bon, pour ce que j'en dis, moi,
Edit : double cross

nitro :
Toujours pas de réponse pour moi...

Je n'ai pas grand chose à répondre. Tu as raison, le C++ a aussi sa place dans le calcul numérique (et de plus en plus), c'était un exemple très mal choisi. Mais le FORTRAN reste très utilisé lui aussi, et comme déjà dit, le C99 vise aussi en particulier les numériciens.
Pour les autres paragraphes, je n'ai rien à répondre du tout.

Ouais bah je constate que tu préfères ne pas répondre plutôt que de reconnaitre que tu t'es trompé...

nitro :
Un jour tu comprendras peut-être qu'on préfere réduire le temps passé à développer/maintenir et non pas le temps passé à executer le code, qui est réduit automatiquement à chaque génération de processeurs.
Et si on veut des performances, la bonne idée est d'améliorer les optimisations du compilateur (cf. analyses statiques avancées d'Eiffel), et non pas de réduire l'abstraction et le pouvoir d'expression du langage.

Je suis plutôt d'accord avec ce paragraphe ...

D'où la citation bien connue (ou non ) de Paul Graham :
"Wasting programmer time is the true inefficiency, not wasting machine time."

nitro :
D'où la citation bien connue (ou non ) de Paul Graham :
"Wasting programmer time is the true inefficiency, not wasting machine time."

Ce devrait être reconnu comme une vérité de la Palice, un peu comme la citation suivante :

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense"
[ Edsger W. Dijkstra ]

Un personnage de bon sens, ce Dijkstra.

Un jour tu comprendras peut-être qu'on préfere réduire le temps passé à développer/maintenir et non pas le temps passé à executer le code, qui est réduit automatiquement à chaque génération de processeurs.

Oue mais le temps de compilation d'un projet C++ .
Meme un truc simple prend un temps fou. Et comme moi je rebuilde a chaque fois que je modifie un truc, puis que je relance les tests automatiques
pour verifier que j'ai pas tout casser, je n'ose imaginer la perte de temps que le C++ induirait sur ce projet.
(Remarque c'est du C incompilable en C++ car il respecte a la lettre le standard C ).

" Et le temps passe a executer le code, qui est reduit a chaque generation"
C'est grace a ce genre de raisonnement que l'industrie de l'informatique survit.
Les processeurs sont 20x plus puissant, mais les applications 17x + gourmande
(raisonnement un peu simpliste, il faudrait le nuancer, je l'accorde).

on préfere réduire le temps passé à développer/maintenir

La programmation evenementielle et la programmation OO empeche de certifier un programme comme bug-free.
Pour info, l'asm permet d'ecrire une preuve du programme.
Je suis le seul a trouver que les applications mettent bien plus de temps a sortir qu'avant ? Ca fait combien de temps que Doom 3 est en preparation?

Et si on veut des performances, la bonne idée est d'améliorer les optimisations du compilateur (cf. analyses statiques avancées d'Eiffel), et non pas de réduire l'abstraction et le pouvoir d'expression du langage.

J'ai passe l'age de croire que le compilateur pourra ameliorer le code que je lui donne.
Si on lui donne pas un code bien prepare, aux petits oignons, ben il est sous performant.
Et je fais aussi de l'analyse statique en C (gcov powa!).
Sinon je pense que les langages d'aujourd'hui (en particulier le C++) ne sont pas assez abstrait.
Troll powa

Sinon je pense que les langages d'aujourd'hui (en particulier le C++) ne sont pas assez abstrait.

Bah oué, moi aussi, mais c'est pour que les développeurs qui bossent en langage fonctionnel ne soient pas perdus :/ (parce que je vois mal tt le monde développer en Prolog, même si ça pawa ).

"langage fonctionnel" = CAML, donc ?

Bah le CamL peut être fonctionnel, d'un certain point de vue (mais je ne connais que peu ce langage). En tous cas, c'est plus fonctionnel que le Prolog

nitro :
Vive les années 50 !

En même temps, sur TI on ne peut pas vraiment se permettre de vouloir développer comme on ferait sur un PC d'aujourd'hui.

PpHd
: Et pour autre info, le C++ est aussi un langage des annees 80.

Mouais enfin plutôt 90...

Relis l'historique du C++! (Et le C est un langage des annees 70).

²

Sasume
:

nitro :
Vive les années 50 !

En même temps, sur TI on ne peut pas vraiment se permettre de vouloir développer comme on ferait sur un PC d'aujourd'hui.

Je crois que dans le contexte où nitro a dit ça, il parlait de la programmation PC (à cause de Kevin qui se lamentait de ne pas avoir de toolkit graphique en C non-objet )

./80 > caml est un langage fonctionnel avec des extensions impératives (et aussi objet), mais ça reste globalement un langage fonctionnel (on a le droit de ne jamais se servir des extensions si l'on veut )
ça ressemble à quoi le prolog ?

PpHd :
Oue mais le temps de compilation d'un projet C++ .

Oui c'est lent, mais c'est surtout à mon avis une limitation du compilateur (en particulier gcc).
Si tu prends du C# par exemple, le compilateur du projet Mono est extrêmement rapide (et il est codé en C#).

La programmation evenementielle et la programmation OO empeche de certifier un programme comme bug-free.
Pour info, l'asm permet d'ecrire une preuve du programme.

Le programme OO tu le compiles ça fait de l'assembleur. Si tu dis qu'on peut écrire une preuve pour l'asm, alors on peut aussi dans ce cas. Ou alors je n'ai pas compris ?

Je suis le seul a trouver que les applications mettent bien plus de temps a sortir qu'avant ? Ca fait combien de temps que Doom 3 est en preparation?

Je pense la même chose. Les applications d'aujourd'hui sont beaucoup plus grosses que celles d'avant, avec plus de fonctionnalités, et donc ça prend plus de temps à développer.
En ce qui concerne Doom 3, c'est surtout parce que c'est un terrain de jeu pour Carmack... comme pour Quake 1, il y aura dix fois plus de lignes de codes écrites pendant le développement que de lignes effectivement compilées dans l'exe à la fin.

J'ai passe l'age de croire que le compilateur pourra ameliorer le code que je lui donne.
Si on lui donne pas un code bien prepare, aux petits oignons, ben il est sous performant.

Moi j'ai passé l'age de croire qu'on peut le faire avec du C/C++. C'est beaucoup trop bas niveau.

Sinon je pense que les langages d'aujourd'hui (en particulier le C++) ne sont pas assez abstrait.

On est d'accord.

PpHd :
Oue mais le temps de compilation d'un projet C++

Delphi (objet pascal) est un langage OO et son compilateur bat à plat de couture la pluspart des compilos C.

PpHd :
La programmation evenementielle et la programmation OO empeche de certifier un programme comme bug-free.
Pour info, l'asm permet d'ecrire une preuve du programme.
Je suis le seul a trouver que les applications mettent bien plus de temps a sortir qu'avant ? Ca fait combien de temps que Doom 3 est en preparation?

Je ne veux pas troubler vos beaux rêves, mais c'est faux. La programmation OO facilite le débuggage. En effet, bien que certains mécanismes d'encapsulation existent dans les langages procéduraux (dont les procédures !), l'OO pousse plus loin. Un surcroît d'abstraction nuit à la performance, c'est vrai, mais permet d'effectuer des modifications dans une classe en particulier sans en affecter aucune autre. Il est possible de programmer en utilisant des types de données abstrait en procédural, mais c'est excessivement fastidieux à manipuler (et ça reviens en terme de performance à de la POO).

Une preuve du programme ...
On ne peut prouver qu'un programme est sans bug. ! [Les ing. prétendent y être en mesure, mais … ]
Au mieux, on peut prouver qu'il respecte parfaitement les spécifications (logique formelle), mais on ne peut prouver que les spécification sont correctement énoncées.

D'ailleurs, j'aimerais bien connaître le temps que ça prend pour faire la preuve formelle qu'un programme de la taille de DOOM3 codé en assembleur respecte les spécifications. Un programme comme DOOM3 n'est pas en préparation depuis un bail parce qu'il est codé en C++, mais parce que c'est un immense projet (peut être aussi qu'ils attendent que le hardware disponible sur le marché puisse le faire rouller).

PpHd :
J'ai passe l'age de croire que le compilateur pourra ameliorer le code que je lui donne.
Si on lui donne pas un code bien prepare, aux petits oignons, ben il est sous performant.
Et je fais aussi de l'analyse statique en C (gcov powa!).
Sinon je pense que les langages d'aujourd'hui (en particulier le C++) ne sont pas assez abstrait.

Un compilateur qui ne peut pas optimiser une expression mathématique est un mauvais compilateur (genre ceux de MS - acusation plus ou moins gratuite, en fait sans preuve, motivée par la rogne, ne pas me repprocher d'attaquer gratuitement Microsoft, SVP -). De plus, quand on veut être portable, où que notre code puisse suivre l'évolution technologique, c'est essentiel d'utiliser des compilateurs qui optimisent. Une expression peut s'exécuter très rapidement sur une machine (division de floats sur un Z/900 genre) vs une autre.

(genre ceux de MS - acusation plus ou moins gratuite, en fait sans preuve, motivée par la rogne, ne pas me repprocher d'attaquer gratuitement Microsoft, SVP -)

Si c'est à ce point 'gratuit', pourquoi l'avoir dit alors ?

c'est son coté altruiste

Sally
: ça ressemble à quoi le prolog ?

abbreviations("M$","Microsoft").

qualites("Linux","super"). 
qualites("Microsoft","merde").

abbrev_qualite(A,B) :-
  abbreviations(A,_X),
  qualites(_X,B).

:- abbrev_qualite("M$",X).
% X = "merde".

:- abbrev_qualite(X,"merde").
% X = "M$".

:- abbrev_qualite(X,Y).
% X = "M$", Y = "merde".

:/- abbrev_qualite("Linux","merde").
% Aucune solution.

Quesoft
:

PpHd :
Oue mais le temps de compilation d'un projet C++

Delphi (objet pascal) est un langage OO et son compilateur bat à plat de couture la pluspart des compilos C.

Parce qu'il optimise très mal!