Reprise du message précédent :
Désolé, mais je suis d'accord sur tous tes arguments sauf sur la conclusion qui recommande d'utiliser le C (peut-être n'as-tu pas utilisé, de manière intensive, assez de langages différents ?).
 
Ce que je reproche au C est que ce langage offre des outils extrêmement puissants sans véritable moyen de contrôle automatique et systématique par derrière. Ainsi, par exemple, le typage fort n'a aucune incidence sur les temps d'exécution, c'est simplement un outil que l'on se donne à la compilation pour qu'un programme -- le compilateur -- vérifie systématiquement et exhaustivement que ce que le programmeur a écrit est cohérent.
 
De plus, C use et abuse des implicites (et C++ est encore 10 fois pire). Exemple (bien sûr, un peu simplet, mais cela permet de mieux comprendre) : pourquoi devoir utiliser explicitement un pointeur pour un paramètre en sortie, alors que le compilateur pourrait prendre cela en charge automatiquement -- et sans risque d'erreur ! A l'exécution, le paramètre passé sera de toute façon un pointeur sur la zone mémoire à modifier, donc les performances seront identiques, mais au niveau source, le programmeur n'a plus à s'en préoccuper.
 
Enfin, tu le dis toi-même, en C, il vaut mieux programmer de manière basique plutôt que compliquée. Je suis 100 % d'accord ; mais je ne sais pas si nous en partageons la raison. Pour moi, la raison principale (parce que c'est celle qui à ma connaissance est la plus souvent vérifiée) en est que les optimisations que le compilateur peut apporter sur le code qu'il génère sont -- de très loin -- beaucoup plus efficaces que les optimisations à lucarne que le programmeur pourrait apporter dans son source, mais que le compilateur ne sait généralement pas bien optimiser le code trop sophistiqué. Donc un programme plus simple et apparemment naïf au niveau source permet souvent d'obtenir un programme plus rapide à l'exécution, parce que le compilateur a mieux réussi à l'optimiser.
 
Le problème, c'est que bien peu de programmeurs connaissent cette règle, et beaucoup optimisent (enfin, croient optimiser) leur code à la main, introduisant complexité, risque accru de bugs, et des coûts de maintenance plus importants. Pourquoi donc ne pas proposer aux programmeurs un langage dans lequel la solution la plus simple et la plus rapide à écrire est aussi la plus propre ?
 
Ainsi par exemple, avec un bon compilateur et une machine à peu près standard, il n'est pas plus efficace de parcourir un tableau par un pointeur plutôt que par un indice : parce que c'est nécessaire, le compilateur transformera la boucle sur indice par une boucle avec un pointeur baladeur. Mais combien de programmeurs savent cela ?
 
Or en C, il est aussi rapide d'écrire l'un ou l'autre des boucles ; mais l'une est beaucoup plus susceptible d'erreurs de programmation (et suivant la façon dont on l'écrit, elle peut aussi être beaucoup plus délicate, donc coûteuse, à maintenir et à faire évoluer dans le temps).
 
Pourquoi ne pas utiliser un langage qui autorise ces deux écritures, mais qui rend la manière sophistiquée plus lourde à écrire au niveau source. On n'interdit rien, simplement, comme cela, on est à peu près sûr que si le programmeur choisit la manière sophistiquée, il le fait pour une bonne raison, parce que cela lui prendra nettement plus de temps.
 
edit> Pour info, Ada a été créé en 1983, et à l'époque, il n'intégrait pas les concepts objets tels qu'on les entend aujourd'hui, en particulier l'héritage et le polymorphisme. On l'utilisait donc essentiellement comme un langage procédural, même si l'encapsulation était déjà un mécanisme fondamental de ce langage. Aujourd'hui Ada est, comme C++, un langage objet hybride, qui offre tous les mécanismes de l'objet sans imposer leur utilisation.

 
Bah, c'est qu'on doit avoir des avis finalement assez semblables, mais peut-être pas s'être compris totalement quant aux conclusions.
 
par contre c'est rare de rencontrer qqu'un qui connait le prob de la sur-optimisation au niveau de l'écriture mais qui finalement n'en est pas une. T'es pas mauvais
 
Par contre j'avoue que je m'interesse moins actuellement aux aspects tech des langages et plus aux aspects algorithmiques, en particulier je fais régulièrement des recherches en reprenant des algo basiques dont j'essaie de trouver des variantes, qui permetttent d'optimiser certaines situations ou des algo plus lourd sont en théorie bien mieux au niveau de la complexité (depend evidement tjrs du nombre n itération et/ou nbrs d'elem a traiter et du type d'elem).
 
Pour les pointeurs, tu sembles par contre avoir une vision plus radicale que moi. Dans certaines situations c'est très utile. Je précise que les situations dont je parle sont en fait assez rare dans la prog classique, mais dans les cas particuliers que je traite bcp moins.
 
Pour le typage, le vilain petit canard c'est le type void mais il n'empeche qu'il m'est deja arrivé de lui trouver une utilitée.
 
Mais c'est vrai que sous certains aspects je regrette que les compilateurs soient si cons lors de la compil. Il y a des prob qui passent totalement a la trappe, pour des raisons qui parfois m'échappent, et chaque compilateur a des prob de ce type qui lui sont particulier.
 

barbarella a écrit a écrit :   par contre c'est rare de rencontrer qqu'un qui connait le prob de la sur-optimisation au niveau de l'écriture mais qui finalement n'en est pas une. T'es pas mauvais

Il faut s'être tapé beaucoup de maintenance de code écrit par d'autres pour comprendre ça. Et ça prend du temps. Learning the hard way disent les anglophones...
 
Au passage, je n'ai pas dit que les pointeurs étaient à bannir (en tout cas, si c'est ce que tu as compris, je me suis mal exprimé, car ce n'est pas ce que je voulais dire). C'est un outil extrêmement puissant et utile, et de nombreuses structures de données -- au sens algorithmique -- reposent sur la notion de pointeur (va implémenter un B-Tree sans pointeurs...     ). Ce que je critique, c'est l'usage abusif qu'il en est fait en C et en C++.
 
C'est un peu comme le goto : c'est très utile, le goto, il y a quelques situations où l'on est bien content de l'avoir à disposition et de pouvoir s'en servir. Mais dans la plupart des cas, on peut se débrouiller avec d'autres structures de contrôle (qui ne sont rien d'autre que des goto conditionnels), qui sont nettement plus lisibles.
 
Bref, pour utiliser une image, je trouve stupide de tuer un moustique avec un missile de forte puissance : ça marche, très bien même, mais bonjour les dommages collatéraux...    

Et c'est pourtant logique: l'algorithme choisi dépend de la performance de chaque opération de base.
La force de C/C++ est de bien habiller un accès quasi direct aux opérations de base des processeurs.
 
 

L'idée est séduisante, mais difficile de concevoir des outils universels dans ce cas.
Ou alors, se contenter de décrire des structures, et s'en remettre intégralement au compilateur pour générer du bon code. C'est pas une mauvaise idée, mais qui conçoit le compilateur ?
 
Ainsi par exemple, avec un bon compilateur et une machine à peu près standard, il n'est pas plus efficace de parcourir un tableau par un pointeur plutôt que par un indice : parce que c'est nécessaire, le compilateur transformera la boucle sur indice par une boucle avec un pointeur baladeur. Mais combien de programmeurs savent cela ?
S'en remettre au compilateur...
Pour faire ça tranquille, j'aurais besoin de garanties ou d'informations sur ce qui ce passe.
 
 
C et C++ on des scories de l'évolution qui mettent des bâtons dans les roues à l'optimisation.
 
L'ambigüité du type char: codet ou caractère.

Le compilateur est obligé de prendre en compte qu'un des codets désigné par pi peut aussi l'être par pc.
 
La compilation séparée par fichier objet+linkage.
Elle empêche la mise inline automatique, l'optimisation de constantes.
 
La non-spécification du comportement attendu des types de base.
La variable peut-elle déborder, réduire par modulo, atteindre la valeur limite ?
 
Pour moi, c'est clair, C++ mérite une formulation plus moderne, ou le programmeur pourrait être beaucoup plus explicite sur ses intentions et ses besoins.

Pas seulement C/C++ : la plupart des langages procéduraux ou objet impératifs le font aussi. Quelle différence entre C et, par exemple, Pascal (dès lors qu'il est compilé en natif). Pour avoir beaucoup travaillé avec les deux langages sur PC il y a un certain temps, je peux te garantir que fonctionnellement ils sont parfaitement comparables, et du point de vue rapidité d'exécution, ils le sont aussi. Par contre, du point de vue lisibilité des programmes et facilité de maintenance...
 
edit> D'ailleurs, à mon avis, c'est un contresens de croire cela. Ce sont les processeurs qui ont évolué pour se rapprocher de notre mode de pensée, donc des langages de programmation évolués, pas l'inverse. Le principe des CALLs, ou des appels de fonction par indirection, par exemple, ont été introduits au niveau des processeurs parce qu'on avait besoin de ce genre de mécanismes pour implémenter efficacement certaines fonctionnalités des langages de programmation évolués (dans cet exemple, les fonctions et procédures, et les tables de fonctions).
 

Pas nécessairement. D'abord parce que le langage se doit de permettre une description précise de l'implantation mémoire d'une structure de données. Mais à côté de la description de la structure de données elle-même, pas dedans. Et surtout, pas implicitement.
 

Quelles garanties ? Quelles informations ? L'optimisation de programmes ne devrait jamais se faire en aveugle, donc tant que tu ne mesures rien avec un outil approprié (en clair, un profileur), tu n'as pas d'autre choix que de faire confiance au compilateur. De toute façon, tout le temps que tu passes à ne pas lui faire confiance et à essayer de "faire mieux que lui" -- mais au feeling -- est du temps perdu. Perdu parce que l'expérience montre que une absence quasiment systématique d'amélioration des performances.
 
Par contre, si tu mesures, précisément, un goulet d'étranglement au niveau d'une fonction particulière, libre à toi de recoder la fonction, soit sans changer de langage, soit en recodant carrément le tout en assembleur. Et même quand on recode le tout en assembleur, on part souvent du code généré par le compilateur... Preuve qu'il ne fait pas du si mauvais boulot que cela.
 

Ici, c'est précisément ce que j'appelle un typage insuffisamment fort. D'autres langages sont beaucoup plus stricts (Pascal, pour commencer), et on n'a pas tous ces problèmes.
 

Pour la compilation séparée, on ne pourra pas, à mon avis, s'en passer. C'est lié au caractère modulaire de notre programmation.
Par contre, la compilation séparée n'empêche en rien les optimisations dont tu parles, à l'édition de liens. C'est un parti-pris de l'éditeur de liens de ne pas effectuer ces optimisations.
 

100 % d'accord. J'irais même plus loin : l'implicite est de très loin la principale source de bugs. Non seulement pour les types de base (d'où l'utilité de s'en abstraire, même si derrière, ce sont eux que le compilateur utilisera ; mais tu vois, là encore, je propose de s'en remettre au compilateur). Mais aussi pour les structures que l'utilisateur définit.
 
Par exemple, en C++, le mécanisme de templates est extrêmement puissant, dans son principe : "soit un type T, j'écris du code quel que soit ce type". Sauf qu'il est très mal implanté en C++. Parce que si j'écris une fonction "template <class T> T min(T left, T right);", il est plus que probable que doive exister une fonction de comparaison entre 2 objets de type T. Mais où est-ce dit ? Nulle part. Qui va avertir l'utilisateur de ma fonction template qu'il doit écrire cette fonction ? Personne. Et s'il ne définit pas cette fonction, est-ce que le compilateur va râler ? En C++, non. C'est aberrant.
 
Voilà une formulation plus claire (je vous laisse deviner le nom du langage ) :

 
La formulation qu'utilisera Java dans le JDK 1.5, quoi que plus concise, respectera également un typage strict :

Et bien à mon avis, ce langage, qui tente de bannir l'implicite sans réduire la puissance d'expression, existe déjà, et je l'ai déjà nommé.

oua vous en dites des belles choses =)

BifaceMcLeOD a écrit a écrit : barbarella> Je suis d'accord pour le début de ton post : C est très bien adapté pour des programmes de taille raisonnable (quelques milliers de lignes voire dizaines de milliers de lignes). Le problème est qu'il est aujourd'hui utilisé dans des projets pour lesquels il est plus du tout adapté (des dizaines de millions de lignes). Parce qu'il n'a pas été conçu pour cela.     Au passage, excuse-moi, nicolasm, mais C99, pour moi, c'est du bricolage : les principaux problèmes du C restent dans cette nouvelle norme (et comment pourraient-ils disparaître ? En les éliminant, on se retrouverait avec un langage qui n'a rien à voir avec C).   Par contre, barbarella, je ne suis plus du tout d'accord quand tu dis que C est incontournable (enfin, je te cite, irremplaçable, mais avec un 'c cédille' ), et en particulier dans les domaines que tu cites. On utilise les outils qu'on se donne (je traduis ma pensée : ce n'est pas parce que c'est le langage le plus connu que c'est le meilleur), et il existe d'autres langages bien plus adaptés aux gros projets, à des contraintes de sécurité fortes, qui permettent aux programmeurs de réduire le nombre de leurs bugs bien plus efficacement, et qui génèrent des programmes tout aussi rapides. Par exemple, comment expliques-tu que tous les logiciels embarqués dans les fusées (européennes ou américaines, au moins), les missiles, les avions ne soient pas écrits en C (ou en C++). Pourtant, on a besoin d'efficacité dans ces secteurs, non ? Le problème, c'est qu'on a aussi besoin de la garantie d'un fonctionnement quasiment sans bugs, ce que C ou C++ sont très loin d'offrir.   De toute façon, quand on a besoin d'optimiser radicalement du code, effectivement on peut se tourner vers l'assembleur pour les quelques fonctions les plus coûteuses, et c'est vrai quel que soit le langage, donc on n'a pas besoin de C parce qu'il génère les programmes soi-disant les plus efficaces.   Alors tu vas peut-être me demander "si un tel langage existait, pourquoi on utilise C ou C++ et pas ce langage-là ?". Je n'en sais rien. Ce fameux langage, Ada, reste cantonné à des secteurs de l'économie très particuliers, et la raison pour laquelle les autres secteurs de l'économie l'ignorent m'échappe totalement. Pour moi, c'est comme demander pourquoi Java a été un incroyable succès à la fin des années 90 alors que ce même langage a été un bide total 5 ou 6 ans auparavant (pire qu'Ada), quand Sun a essayé de le lancer pour la première fois sur le marché. Pourtant, à part son nom, ce premier langage était rigoureusement identique au Java que nous connaissons...

ADA n'a pas connu le meme succes pour des raisons simples, les compilateurs etaient cher, lent et demandaient des machines qui n'etaient pas a la portee de toutes entreprises.
S'il n'est toujours pas le langage le mieux cote, c'est parcequ'il est diffcile et du fait allonge considerablement les temps de developpement surtout lorsque la conception a ete bacle (dans 50% des cas en etant tres gentil).
Pour ce qui est de l'oriente objet je ne connais pas la version 95 est-ce qu'elle tiens face a C++ ou Java

En réponse à BifaceMcLeOD:
 
Houlà !
Tu es de toutes évidence beaucoup plus expérimenté que moi, je vais essayer de suivre...
 

Mon Pascal date de pas mal.
Le Pascal moderne permet-il d'appeler un pointeur de fonction dans un tableau retourné par une fonction ?
 

En fait, ils évoluent en ce sens depuis le départ, non ?
C'est à priori une bonne chose, car on ne fait pas volontier (exemple) de calcul 3D si on ne dispose que de 0 et de 1.
Mais là, on entre de plein-pied dans la question du langage conditionné par la pensée, et réciproquement.
Ça dépasse de très loin mon pouvoir d'abstraction/imagination, je décroche...
 

Pour maîtriser le déroulement partiel, certains mélangent boucles classiques et constructions élaborées de patrons.
Ça me met mal à l'aise.
Il ne devrait y avoir qu'une façon d'écrire l'algorithme, avec des qualificatifs optionnels pour suggérer/imposer l'implémentation compilée.
Je crois que ça rejoint un peu le premier paragraphe, si je t'ai bien suivi.
 

Je parle du mode de compilation classique du C/C++, séparant la génération de code et le collage des morceaux.
Dans un tel système, impossible de mettre en ligne une fonction ordinaire, puisqu'elle peut être substituée à l'édition de liens.
Impossible de même d'intégrer dans le code une valeur constante "extern".
 
Ce n'est pas que cette méthode soit mauvaise, c'est qu'il est idiot de séparer des éléments qui se retrouveront dans une même cible de compilation.
Ça empêche l'optimiseur d'avoir une vue d'ensemble du programme.
Je trouve dommage de gâcher ici alors qu'on déploie des trésors d'imagination ailleurs.
 

Ce que tu dis, en gros, c'est que C++ n'a pas de norme pour spécifier les contraintes qu'on pose sur un type générique.
C'est vrai que c'est gênant, et pourtant je pense que ça a été voulu ainsi pour une bonne raison: s'en remettre au compilateur   pour le déterminer, plutôt que d'imposer au programmeur de faire la liste de ce qu'il utilise, avec le risque de se tromper.
Le compilateur râle bien si on apelle quelque chose qui n'existe pas. Il y a toutefois le risque de retomber silencieusement sur des conversions standard inappropiées.
 
Et puis il y a des cas tordus: Un patron utilisant, selon l'un de ses paramètres, deux spécialisations différentes d'un autre patron.
Contraintes variables, comment spécifier ça ?
 
 
Pour mettre un mot sur l'idée originale du topic quand même :
Je trouve que Java est un hybride, un mauvais compromis.
Très loin du matériel comparé à C et C++, mais pas assez haut niveau.
Confortable, mais trop rigide.
Il a du succès, c'est donc qu'il a des qualités et qu'il répond à des attentes, mais c'est surfait par effet de mode.

eh ben,
 
on est en pleine théorie du langage . Perso, je me sens bcp plus concerné par les prob d'optimisation bas niveau. De part l'absence de certains mécanismes dans les compilateurs on tente d'intégrer dans les proc des mécanismes intelligents d'optimisation du flux des instructions et des données. Mais comme c'est un automate qui fait ça c'est pas génial et quand on passe en manuel, on voit la diff.
 
ou je veux en venir ? je pense qu'il nous faudrait des compilateurs (oui je sais j'ai dévier de la théorie des langages a celle des compilateurs ) avec des capacités d'apprentissage d'algo d'optimisation. hummm ... Bon j'arrete là car je dévie vraiment trop
 
Sinon pour java, je suis convaincu que sa réelle raison d'être se situe dans la petite guerre-guerre que se livre Sun et MS. Donc il a des defauts mais ils sont mineur au regard des objetifs de Sun. (c'est mon avis evidement)

barbarella a écrit a écrit : eh ben, ou je veux en venir ? je pense qu'il nous faudrait des compilateurs (oui je sais j'ai dévier de la théorie des langages a celle des compilateurs ) avec des capacités d'apprentissage d'algo d'optimisation. hummm ... Bon j'arrete là car je dévie vraiment trop

 
en pratique, ca voudrait dire quoi, ca ? (je veux dire, qu'est ce que serait censé faire un tel compilo ?)

Heu... Il faut que je révise un peu, là, je ne peux pas te répondre tout suite.
Ca fait trop longtemps que je n'en ai pas fait de Pascal.
 

Je ne suis pas sûr de bien comprendre ce que tu entends par "patron" (j'ai plusieurs sens possibles dans mon carquois, et je ne voudrais pas faire d'erreur ). Tu peux donner un exemple concret ?
 

En théorie, rien n'interdit que le linker fasse ces optimisations-là. Il suffirait que le compilateur lui donne les infos nécessaires pour le faire. Le problème, c'est qu'on travaille toujours avec des linkers qui datent de la création du langage C, et qui n'ont quasiment pas évolué depuis, alors que les compilateurs ont, eux, beaucoup évolué. C'est ça qui est stupide.
La meilleure preuve, ce sont les contorsions que les compilateurs C++ sont toujours obligés de faire pour que le linker puisse supporter les méthodes de classes et la surcharge (le fameux name mangling).
 

Tu veux dire, j'ai deux types A et AA, et quatre types B, C, BB, et CC qui héritent respectivement de A, A, AA et AA. Et tu voudrais avoir des B et des BB ensemble seulement ou des C et des CC ensemble, mais jamais de B et des CC (ou des AA) et de C et des BB non plus. C'est ça ?
La surcharge suffit à l'exprimer, ça, non ? Alors bien sûr, on pourrait vouloir l'exprimer de manière plus automatique.
 

Exemple de rigidité(s) ? Si c'est l'incapacité à décrire la représentation mémoire d'une structure de données, interdisant par conséquent à Java le domaine de la programmation système, je suis d'accord. Mais il n'a pas été conçu pour cela non plus, il faut le reconnaître. Et ici, le reproche serait plutôt qu'il ne soit pas d'assez bas niveau, ce qui n'est pas ce que tu dis. Alors en quoi n'est-il pas d'assez haut niveau ?

BifaceMcLeOD a écrit a écrit : barbarella> Je suis d'accord pour le début de ton post : C est très bien adapté pour des programmes de taille raisonnable (quelques milliers de lignes voire dizaines de milliers de lignes). Le problème est qu'il est aujourd'hui utilisé dans des projets pour lesquels il est plus du tout adapté (des dizaines de millions de lignes). Parce qu'il n'a pas été conçu pour cela.     Au passage, excuse-moi, nicolasm, mais C99, pour moi, c'est du bricolage : les principaux problèmes du C restent dans cette nouvelle norme (et comment pourraient-ils disparaître ? En les éliminant, on se retrouverait avec un langage qui n'a rien à voir avec C).   Par contre, barbarella, je ne suis plus du tout d'accord quand tu dis que C est incontournable (enfin, je te cite, irremplaçable, mais avec un 'c cédille' ), et en particulier dans les domaines que tu cites. On utilise les outils qu'on se donne (je traduis ma pensée : ce n'est pas parce que c'est le langage le plus connu que c'est le meilleur), et il existe d'autres langages bien plus adaptés aux gros projets, à des contraintes de sécurité fortes, qui permettent aux programmeurs de réduire le nombre de leurs bugs bien plus efficacement, et qui génèrent des programmes tout aussi rapides. Par exemple, comment expliques-tu que tous les logiciels embarqués dans les fusées (européennes ou américaines, au moins), les missiles, les avions ne soient pas écrits en C (ou en C++). Pourtant, on a besoin d'efficacité dans ces secteurs, non ? Le problème, c'est qu'on a aussi besoin de la garantie d'un fonctionnement quasiment sans bugs, ce que C ou C++ sont très loin d'offrir.   De toute façon, quand on a besoin d'optimiser radicalement du code, effectivement on peut se tourner vers l'assembleur pour les quelques fonctions les plus coûteuses, et c'est vrai quel que soit le langage, donc on n'a pas besoin de C parce qu'il génère les programmes soi-disant les plus efficaces.   Alors tu vas peut-être me demander "si un tel langage existait, pourquoi on utilise C ou C++ et pas ce langage-là ?". Je n'en sais rien. Ce fameux langage, Ada, reste cantonné à des secteurs de l'économie très particuliers, et la raison pour laquelle les autres secteurs de l'économie l'ignorent m'échappe totalement. Pour moi, c'est comme demander pourquoi Java a été un incroyable succès à la fin des années 90 alors que ce même langage a été un bide total 5 ou 6 ans auparavant (pire qu'Ada), quand Sun a essayé de le lancer pour la première fois sur le marché. Pourtant, à part son nom, ce premier langage était rigoureusement identique au Java que nous connaissons...

 
beaucoup de dev pour le militaire ou l'aérospaciale sont fait en fortran, parceque dans l'industrie on sait que par expérience tout changement de technologie entraine des problèmes de fiabilité (que ce soit au niveau mécanique/électrique ou logiciel).
 
il a fallut des années (dizaines) aux ingénieurs pour atteindre un niveau correct dans le langage de "leur" époque (fortran/cobol).
 
passer à des langagues plus évolués, et fondamentalement supérieurs en performances et en robustesse quand on le maitrise, comme le C puis C++ puis Java, nécessite au minimum 5 ans d'expérience pour quelqu'un sachant programmer efficacement dans des langages comme le fortran/cobol (sachant qu'il faudra d'abord capter la philosophie d'un langage).
 
il est aussi plus facile d'apprendre le C/C++/Java à 18/20 ans, qu'a 40 ans après 20 ans de fortran/cobol. (c'est pareil pour tout le monde, et tous les jeunes dev comme moi qui ont vers 20 ans actuellement, souffriront dans 20 ans quand on leur demandera de maitriser des trucs en 1 an max alors qu'il faut toujours dans les 5 ans pour maitriser complètement un truc).
 
la preuve qu'un changement de technologique est -toujours- à problème même si la technologie est infiniment supérieure:
 
ariane 4 a eu je sais plus combiens de succès d'affilés (genre 20/30 lancements sans problèmes)
 
premier lancement d'ariane 5: boum auto-destruction ?
pourquoi ? problème mécanique ? életrique ?
non, ils avaient réutilisés le code en fortran utilisés dans les calculateurs d'ariane 4, et ça avait pété les plombs avec ariane 5 parceque des paramètres avaient évolués bien plus rapidement au lancement qu'avec ariane 4 et le calculateur était sorti d'une table de pré-calcul, entrainant un nettoyage de la ram.

bjone> A ma connaissance, le logiciel d'Ariane 4 et 5 est écrit en Ada.
Et effectivement, il y avait eu réutilisation d'un bout de code entre les 2 systèmes de contrôle de la fusée sans nouveau contrôle. Toujours à ma connaissance, un des paramètres de vol est sorti des bornes admises par le ce bout de logiciel. Il était physiquement admissible pas la nouvelle fusée, mais pas par l'ancienne. Et c'est une exception qui a été jetée pour signaler cette erreur. Le système de contrôle, récupérant l'exception, a essayé de corriger la trajectoire suite à ce paramètre hors bornes, mais il n'a pas réussi, puisque la trajectoire était par ailleurs correcte.
 
Et le système central a fini par juger que puisque la trajectoire n'était pas corrigeable et que ce paramètre était hors bornes, la fusée mettait en danger les populations au sol alentour, et il a fait exploser la fusée, par sécurité.
 
Pour info, les militaires utilisaient beaucoup le Fortran il y a 20 ans. Ils ont progressivement cessé, et toute l'infrastructure logicielle de l'OTAN est aujourd'hui écrite en Ada.

de toutes façon chaque langage a ses qualités et ses défaut, ça dépends du but à atteindre.
 
évidemment, avec la pratique on s'aperçoit que le C++ devrait totallement éclipser le C, car philosophiquement supérieur si on fait du C++ vraiment C++.
 
le C++ et le Java cohabiteront, car le but n'est pas le même (il a plus de portabilité en Java, mais plus de vitesse d'éxécution et de possibilité de travailler en bas-niveau près de l'os ou du matériel en C++/C).
 
il est peut-être possible que le C++ soit finalement éclipsé par le Java dans un futur moyennement lointain, quand il y aura des compilateurs byte-code java >> code machine très efficace (et une telle compilation pourrait être relativement rapide, car un compilateur C/C++ passe plus de temps à se bouffer des headers et une vérification lexicale/synthaxique qu'a générer le code).
 
ensuite pour les progammeurs qui préférent le Java (ou même le VB) à l'asm ou au C/C++, uniquement avec le seul argument qu'en Java y'a pas de pointeurs "visibles", c'est des programmeurs qui sont encore débutants et qu'ils savent pas ou ils vont quand ils programment.
 
après désolé si j'ai dit des conneries

Mais je ne crois pas que Java fera disparaitre C++. Ils n'ont pas le même objet (si vous me permettez ce petit jeu de mot).
 
C++ ne pourra être remplacé que par un langage qui peut remplir le même office, mais qui est plus sûr (i.e. qui offre moins de risques de bugs).

 
oki, j'ai dit partiellement une connerie, mais juste pour dire que le fait de ne pas utiliser de "nouveaux" langages dans le militaire/spacial au lié au soucis de robustesse dû au manque de compétances et tout simplement d'expérience qu'il aurait au moment du passage dans un nouveau langage (je dit pas ça méchamment, mais j'ai bossé dans une boite qui faisait de la métrologie, et c'est une réalité). d'un autre coté c'est pas plus mal comme ça, ça permet d'attendre que les outils autour des "nouveaux" langages évoluent et se fiabilisent.

Tu as essayé d'utiliser les premiers compilateurs C++ ? Ce n'était pas mal non plus... Enfin, j'ai utilisé ces compilateurs à l'époque (j'étais étudiant), c'est vrai que c'était lent (on avait des brouettes, en plus), mais ce n'était pas la mère à boire non plus...
 
Maintenant, ça fait près de 10 ans qu'il existe un compilateur gratuit, et il est comparable en efficacité à GCC (normal, il est précisément basé sur GCC ).
Quant à la difficulté du langage comme l'allongement des durées de projets, c'est un mythe, que j'ai souvent entendu à son sujet, mais qui ne résiste pas à un examen même rapide de projets existants. Encore faut-il être honnête : les phases d'intégration et de maintenance corrective sur un projet aujourd'hui prend toujours un temps faramineux aujourd'hui, et elles alourdissent énormément le coût des projets. Quant à la conception, on en est arrivé à une complexité similaire en C++ ou en Java dès qu'il faut concevoir des hiérarchies de classes.
 
Ada n'est pas fondamentalement plus difficile que C++ -- sur des gros projets, il est même plus facile à maîtriser, je trouve -- mais c'est sûr par contre que le premier programme qu'on écrit en Ada peut paraître pénible quand on vient du monde C ou C++, car le compilateur est vraiment très très très très très pénible (je veux dire, strict, bien sûr). Mais en quelques mois, on commence déjà à apprécier, quand on commence à réaliser combien le temps de débogage s'en trouve réduit. Et petit à petit, on s'habitue au typage strict du langage.
 
Pour l'aspect objet, Ada dans sa norme actuelle (que tous les compilateurs respectent depuis au moins 5 ans, obligatoirement) offre tous les mécanismes fondamentaux : encapsulation et abstraction de données (c'était déjà le cas dans la première norme), mais aussi héritage (simple uniquement) et polymorphisme (si j'ai oublié des mécanismes, dites-le moi ).
 
A noter une petite différence syntaxique qui peut dérouter les programmeurs C++ ou Java au premier abord. En Ada, la syntaxe est de type procédurale et non orientée envoi de message. Donc pas d'objet receveur explicite, type "monObjet->maMéthode()" : on écrit "maMéthode(monObjet);".
Et en cas de spécialisation d'une méthode, tous les paramètres de celle-ci sont spécialisés, et pas simplement le premier (qui est traditionnellement l'objet receveur). Donc si dans une classe Mere on a une méthode "toto (m1 : Mere, m2 : Mere)", la classe Fille héritant de Mere aura une méthode "toto (m1 : Fille, m2 : Fille)" et non une méthode "toto (m1 : Fille, m2 : Mere)", comme cela se serait produit en C++ ou en Java.

Biface > Les infos sur les templates et le futur JDK 1.5, je peux les obtenir où s'il te plait ?

 
A vue de nez, je dirait là :  
http://www.jcp.org/en/jsr/detail?id=176
 
Mais tant que c'est pas en public review, seul les membres du JCP peuvent y acceder.

Merci bien.

Tu en trouveras une description détaillée dans :
http://www.jcp.org/en/jsr/detail?id=14
 
Et puis aussi http://www.cis.unisa.edu.au/~pizza/gj/

Les templates de C++.
Basé sur ce principe, mais en plus ésotérique:

Ça garantit d'avoir une constante pré-calculée par le compilateur.
 

Injecter du code en ligne et optimiser les instructions, c'est le travail du compilateur.
Si un linkeur en est capable, c'est qu'il peut rappeler le compilateur, ou que lui et le compilateur ne font qu'un. Une très bonne idée d'ailleurs.
 
 

Pour prendre un exemple simpliste:

Selon la valeur de exp, le type devrat savoir multiplier ou diviser.
Bon, l'exemple est pas terrible... d'ailleurs, il montre qu'il faudrait pouvoir faire deux patrons, différents seulement par le signe de exp.
Là, je maîtrise pas le sujet...
 

La durée de vie des objets pas maîtrisable, ne pas pouvoir composer son propre type numérique ou conteneur...
Le C++ bien employé peut être de beucoup plus haut niveau. Il est moins intuitif, c'est bien dommage...
 
 

Aucun des deux n'éclipsera l'autre, ils sont trop différents.
Java: La portabilité (comportement reproductible), la facilité d'utilisation.
C++: La performance, le bas niveau, les trucs de ouf.

Merchi beaucoup.

Pour moi, là, ça revient à détourner le principe de la généricité, qui est, je le rappelle, d'offrir la possibilité de définir un type de données dont on ne sait rien, puis ensuite d'écrire du code utilisant ce type. Déjà, pouvoir avoir un paramètre numérique dans les arguments génériques, je trouve cela limite (mais pas inutile, je le reconnais, je l'ai même utilisé une fois).
 
Il devrait y avoir d'autres moyens de disposer d'une constante pé-calculée par le compilateur. Par exemple, par une directive genre pragma et une fonction garantie sans effet de bord (comme C++ sait le signifier) ; le compilateur devrait ensuite, ainsi que le pragma lui demande, être capable d'exécuter la fonction comme si le programme s'exécutait déjà pour trouver la valeur.
 

Ca ne marche pas, ça ?    
Si tu peux définir une valeur d'enum par une expression conditionnelle, je ne vois pas trop pourquoi le compilateur râlerait. Ou alors j'ai loupé un truc.  
Ceci dit, je redis que j'ai dit plus haut sur le type des paramètres génériques. On est en train de vouloir utiliser la généricité non pour écrire du code plus général (plus générique) mais à des fins d'optimisation, ce qui est en soi une mauvaise idée.
 

Là, je ne suis pas d'accord (en tout cas sur les exemples que tu donnes).
Ce n'est pas parce que Java utilise le principe de la durée de vie par attachement (en anglais, on dirait "by reachability", par "atteignabilité" ) qu'elle n'est pas maîtrisable. Au contraire (je rappelle, le principe de la dure de vie par attachement, c'est "un objet vit tant qu'on peut l'atteindre" ). J'ai travaillé sur des bases de données objet qui fonctionnaient sur le même principe (l'attachement) pour faire persister des objets, et là aussi, la maîtrise était totale.
Maintenant, je suis d'accord que ce n'est pas parce que un million d'objets devient inaccessible, donc qu'ils cessent tous d'exister, que la mémoire qu'ils occupaient est aussitôt libérée. Mais ceci est un autre problème.
 
Pour les types numériques -- je suppose que tu voulais parler d'étendre le jeu des types atomiques --, peu de langages permettent réellement de le faire. Java ne permet en effet de créer que des classes. Tu vas trouver que je la ramène encore, mais c'est une des choses que sait très bien faire Ada :

 
De plus, Java ne supporte pas la surcharge des opérateurs. C'est à la fois un bien et un moins bien. Moins bien parce que c'est vrai que c'est pratique, bien parce que tel que c'est possible en C++, c'est incroyablement dangereux.
De toute façon, la surcharge des opérateurs n'est qu'une aide syntaxique qui n'ajoute rien à la puissance d'expression (pour être tout à fait exact, seule la redéfinition des opérateurs "new" et "delete" augmente la puissance d'expression du langage, mais c'est précisément celle-là que je trouve très dangeureuse).
 

Pour la performance et le bas niveau, je persiste à croire qu'il existe d'autres langages beaucoup plus industriels. Quant aux "trucs de ouf"... en a-t-on vraiment besoin dans l'industrie ?

BifaceMcLeOD a écrit a écrit : Mais je ne crois pas que Java fera disparaitre C++. Ils n'ont pas le même objet (si vous me permettez ce petit jeu de mot).   C++ ne pourra être remplacé que par un langage qui peut remplir le même office, mais qui est plus sûr (i.e. qui offre moins de risques de bugs).

 
C'est clair que pour faire un moteur 3D, le C++ sera toujours nécessaire  

Non, Smaragdus, C++ ne sera pas nécessaire. Par contre, à choisir entre C++ et Java, C++ est (malheureusement) préférable, pour cet usage-là.
 
Quoique...   Vues le nombre croissant de fonctions 3D que les cartes graphiques prennent en charge, ce choix se justifie et se justifiera de moins en moins.

BifaceMcLeOD a écrit a écrit : Non, Smaragdus, C++ ne sera pas nécessaire. Par contre, à choisir entre C++ et Java, C++ est (malheureusement) préférable, pour cet usage-là.   Quoique...   Vues le nombre croissant de fonctions 3D que les cartes graphiques prennent en charge, ce choix se justifie et se justifiera de moins en moins.

 
ouaip, mais bon, un moteur 3D c pas que de l'affichage

BifaceMcLeOD a écrit a écrit : Non, Smaragdus, C++ ne sera pas nécessaire. Par contre, à choisir entre C++ et Java, C++ est (malheureusement) préférable, pour cet usage-là.   Quoique...   Vues le nombre croissant de fonctions 3D que les cartes graphiques prennent en charge, ce choix se justifie et se justifiera de moins en moins.

 
Pour info, un moteur 3D contient aussi un moteur physique...    
Actuellement, il n'y a pas mieux que le C++ pour faire un moteur optimisé et facile à interfacer avec les API graphiques. C'est pas du prosélytisme ou quoi que ce soit, c'est une constatation.

Non, c'est une méconnaissance des langages comparables à C++.
C++ n'est pas forcément le meilleur, mais indéniablement, c'est de loin le plus utilisé aujourd'hui.
 
Mais je connais ta position très pro-C++ en général, Smaragdus.

 
Raisonnemment incohérent : langage le plus utilisé => communauté, bibliothèque, etc... la plus importante pour t'aider et apprendre donc tout est dit.

 
l33t...  

   
Biface > Qu'est ce que tu verrais comme langage pour faire un moteur rapide, ADA ?

Quelle qu'elle soit, certains ici vont se gausser de ma réponse, d'un condescendant "Pfff !!! Attends, t'as déjà vu un moteur 3D efficace programmé en XXX ?!?".
 
Forcément, dans les lieux communs de la programmation, seuls 3 langages permettent d'écrire des exécutables rapides : l'assembleur, le C et C++. Tout ce que je prétends, c'est qu'il doit exister des langages rassemblant l'efficacité des programmes écrits en C ou C++, et une grande sécurité de programmation forte.
 
En l'occurrence, Cherrytree, Ada permet d'écrire des drivers, et il est, aujourd'hui, utilisé pour les interfaces utilisateurs des avions de ligne ou de chasse (avec toutes les notions de réalité augmentée, etc). Vous allez me dire, il n'y a pas de moteur 3D là-dedans. Peut-être, personnellement, je n'ai jamais participé à ce type de projet militaire.
Mais en tout cas, rien ne s'y oppose, car les performances des exécutables écrits en Ada sont au rendez-vous (sans jeu de mot).
Je rappelle au passage que l'un des domaines de prédilection d'Ada est le temps-réel.
 
PS: Merci du soutien, lorill.  

Je ne me gausse pas, cher Biface. Et si tu as perçu dans mes propos certes bref, un soupçon d'ironie, j'accuse ta paranoïa.
 
Je connais la robustesse d'ADA pour avoir appris les bases de ce langage en classe (IO et synchronisation), je demandais seulement, à tout hasard, si tu avais dans ta besace le nom d'un langage, qui serait un bon remplaçant de C++ pour l'écriture d'un moteur. Rien de plus.
 
Je suis un admirateur de tes propos, en vérité.

Ce n'est pas toi que je visais dans mes propos, Cherrytree...
 
Si tu veux que je suis plus explicite, le sieur en question s'est déjà fait rembarrer dans les cordes par un autre que moi.

BifaceMcLeOD a écrit a écrit : Ce n'est pas toi que je visais dans mes propos, Cherrytree...   Si tu veux que je suis plus explicite, le sieur en question s'est déjà fait rembarrer dans les cordes par un autre que moi.

Vraissemblablement, c'est moi le parano ! Quelle ironie. Désolé pour la méprise. Faudra que je remette à ADA, tiens, ça me rappellera le bon vieux temps.

BifaceMcLeOD a écrit a écrit :   PS: Merci du soutien, lorill.

 
bah, je connais pas ADA, mais je suis un fervent défenseur de la diversité. Tous les langages ne permettent pas d'exprimer les mêmes choses de la même manière.

Cherrytree a écrit a écrit : Vraissemblablement, c'est moi le parano ! Quelle ironie. Désolé pour la méprise.

Non, non, je reconnais que ce n'était pas clair.    
Y a pas de malaise.  

l'ada c'est bien.    
 
(ca c'est de l'argumentation)