Reprise du message précédent :

 
disons que faut s'habituer a laisser une tabulation avant de taper le code (sinon ca compile pas, car historiquement ca sortait sur des cartes perforées, et donc fallait laisser la place aux perforations)

 
tu confondrais pas avec python ?

 pour le format des cartes perforées il fallait que le code se trouve entre la 7e et la 72e colonne, mais sinon on s'en fout bien sur, c'est quoi cette idée de s'imposé un tab ?

Ca s'appelle la rétro-compatibilité.
Un truc qui a toujours existé en informatique pendant plus de 30 ans, et qui depuis quelques années part aux oubliettes.

 
n'imp, la rétro compatibilité pour les cartes perforées   , et surtout c'est un travail de preprocesseur
tant qu'on y ait autant codé qu'en fortrant 77 au maximun avec toute les droleries anti-prodictives que ca comporte, histoire de rester retro-compatible avec une machine dont le fabriquant a fait faillite il y a 25ans

Tu devrais discuter avec Uriel j'pense que certaines choses te surprendraient...

Quand on code en fortran, la productivité elle ne se gagne pas sur le temps de codage du prog, mais sur son temps d'execution...C'est vrai que devant un recruteur quand on parle fortran ça pète moins que c# et .net, autant à ce que je sache, quand on parle de calcul (juste des maths, pas d'interface graphique) c'est encore au fortran qu'on s'adresse. Les algos de traitement de données satellite que je connais sont en fortran. Vous trouvez que les entrées/sorties sur fichier du c++ sont une évolution? je les trouve dégueu, illisibles et inutilisables par rapport à celles du fortran et du c.
 

Je doutes que vous ayez compris mon post, mais ce n'est pas grave, c'est pas loin d'une private joke, vous devriez retourner vous coucher

Mon erreur est ptet seulement d'avoir mal sélectionné le post auquel je souhaitais répondre.

 
il y a un fossé entre un code écrit par un programmeur de métier en fortrant 90 ou plus et un torchon baclé en f77, et oui en fortrant 90 les performances sont au rendez-vous
 

 
franchement par rapport au C oui, sauf qu'en C c'est plus simple de contruire rapidement un format de sortie mais en C++ on a Boost.format donc aucunes excuses
 

 
boost.format
 
Edit: pour les performances en calcul scientifique, il y a des bibliotheques en C++ qui permettent de rivaliser avec fortrant 90, mais faut connaitre, c'est sur

Pour le fortran 90, je n'en sais rien, je ne fais que du 77. Lorsque j'ai eu besoin "d'objets" on m'a conseillé de passer au c et c'est ce que j'ai fait.
Pour les entrées/sorties, je parle de ce qui est intrinsèque au langage. Rajouter des librairies les unes sur les autres et faire croire que c'est bien...heuu non.
Pour ce qui est des librairies scientifiques, je pensait qu'un topic dans la rubrique biblio/links serait bien.
J'attends toujours des librairies c++ qui travaillent sur les matrices et qui ne soient pas juste des wrappers de routines lapack en fortran.  

genre Blitz++ ? http://www.oonumerics.org/blitz/

Bon bein on se le fait ce biblio/link scientifique alors.

 
boost c'est bien

 
+1
De même que les locks interprocess (pthread_rwlock_t )
 
Sinon, j'avais développé des forums en C avec classes (C++ ancien temps quoi ) sous windows et le jour où je les ai compilés sous linux avec un kernel 2.6, j'ai divisé par trois mes temps de génération (avec un 2.4, c'était par deux )

Mais bon c'est quand même pas au niveau du multiprocessing erlang

 
non

 
ben sous open VMS c'etait une tabulation (de mémoire)

de toute façon, par défaut 1 tab = 8 colonnes, donc "à partir de la 7° colonne", à compter qu'on part de 0, ça fait bien 8 colonnes

C'est de moins en moins vrai. Le temps où le fortran donnait des performances de calcul supérieures à celles des autres langages semble révolu maintenant. Les bibliothèques de calcul matriciel en C++ arrivent de nos jours à sérieusement rivaliser avec fortran.
 

Effectivement, les numériciens ne jurent que par fortran... pour des raisons historiques. Tous les codes de calcul un peu vieux ont été écrits en Fortran et il est beaucoup plus facile de continuer dans cette lignée plutôt que de se lancer dans une traduction en C++ de dizaines de milliers de lignes de code. Il serait à mon avis temps d'évoluer vers des langages plus récents (genre C++) qui permettraient d'obtenir des codes tout aussi performants, et plus faciles à écrire et à maintenir. Mais d'ici que j'arrive à convaincre les chercheurs de mon labo...

mouais ça depend... en tout cas point de vue disponibilité des librairies mathématiques il n'y a pas photo, c'est bien dommage dailleur. Le probleme avec le c/c++ pour le calcul scientifique c'est qu'il n'existe pas une grosse bete de librairie qui possede autant de chose que les MKL d'intel par exemple, on doit piocher une lib par ci et une autre par là.

Faut tout traduire en ASM

 
Tant qu'à faire

on peut même l'écrire en DX, comme ça on utilise le GPU qui calcule vite aussi

 
ca dépent du type de calcul... je crois que c'etait au MIT qu'ils ont essayé y'a 1 an d'utiliser les GPU pour faire du calcul. Ca marchait super bien sur les calculs matriciels mais pas terrible sur les opérations plus simples (normal, vu le mode de fonctionnement d'un GPU) et c'etait loin de rivaliser avec les cpu (surtout les multi-core actuels...)

 
oserais-je pointer vers ma signature  

 
Surotut que le C++ pondu comem ça et 10 à 20 plus lent que du FORTRAN, il faut une certaines quantité de jonglerie pr s'abstraire de ces problèmes et avoir un code C++ expressif, haut-niveau ET performant. mais bon 'experience, ca ce fait très bien