Discussion :

[Pragmateek]

Bonjour,

comment obtenir dynamiquement le type d'un objet, que ce soit sous forme d'un identifiant numérique ou textuel ou d'un objet plus complexe ?
L'équivalent du "typeof" de certains langages.

Merci.

[FR119492]

Salut!

le type d'un objet

Qu'appelles-tu un objet?

Sous quelle version de Fortran travailles-tu?

Jean-Marc Blan

[Pragmateek]

Bonjour,

un objet est n'importe quelle entité manipulée par le langage : type de base (entier, réel), type dérivé, voire des fonctions et sous-programmes.

La norme utilisée est Fortran 2003.

En particuliers pour les types dérivés :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
program appli
 
	type TA
		integer :: n
	end type TA
 
	type(TA) :: a = TA(1)
 
end program appli

Serait il possible de retrouver le type de l'objet "a".

Merci.

[FR119492]

Salut!
La nature d'un objet dépend de la manière dont il a été déclaré et non du contenu des octets correspondants. Preuve en est l'existence de l'instruction Equivalence:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
      Character*1 S(4)
      Real*4 A
      Equivalence (S,A)

Le contenu des 4 octets peut être considéré indifféremment comme 4 caractères ou un réel.
Jean-Marc Blanc

[Pragmateek]

La nature d'un objet dépend de la manière dont il a été déclaré et non du contenu des octets correspondants. Preuve en est l'existence de l'instruction Equivalence

En effet, mais certains langages comme C++ embarquent des informations supplémentaires sur le type de la série d'octets et permettent ainsi de déterminer dynamiquement le type d'un objet dont le type n'est pas connu à la compilation (lors de sa déclaration).

Cela peut être utile dans le cadre d'utilisation polymorphe d'un objet afin de déterminer son "vrai" type, celui qu'il a à l'exécution.

[Pragmateek]

Après quelques recherches il semble que la seule façon de procéder est d'utiliser la structure "select type".

Malheureusement celle-ci ne semble pas bien supportée par les compilateurs actuels comme "gfortran" et "ifort".

Connaissez-vous un compilateur qui soit à jour du standard 2003 ?

Merci.

[FR119492]

Connaissez-vous un compilateur qui soit à jour du standard 2003 ?

Je suis très conservateur. C'est pourquoi je suis pratiquement resté à mon bon vieux Fortran 77 (peut-être ne suis-je pas un exemple à suivre ) qui fait tout ce que je lui demande; la seule nouveauté du Fortran 90 qui me soit vraiment utile est le format EN pour l'affichage des résultats.
Jean-Marc Blanc

[Sylvain Bergeron]

Connaissez-vous un compilateur qui soit à jour du standard 2003 ?

Cray a annoncé la semaine dernière ou la précédente que son compilateur supporte maintenant complètement la norme Fortran 2003.

http://docs.cray.com/books/S-3901-70/

Extrait de l'intro :

This manual describes the Cray Fortran compiler for the Cray Compiling Environment (CCE) 7.0 Release. This compiler supports Cray XT systems using the Cray Linux Environment (CLE) operating system.

The Cray Fortran compiler supports ISO/IEC 1539-1:2004, the Fortran 2003 standard adopted by the International Organization for Standardization (ISO). This compiler also supports selected features from the Fortran 2008 standard. The Fortran 2008 standard has not been formally adopted at this time. Fortran 2008 feature implementations are based on the specifications in the Committee Draft (ISO/IEC SC22/WG5/N1723), and are subject to modification in the final standard.

The Cray Fortran compiler is also documented in man pages, beginning with the crayftn(1) man page. Where the information in this manual differs from the man page, the information in the man page supersedes this manual.

[Pragmateek]

Ah oui en effet ce compilateur semble bien respecter le standard mais ne produit apparemment que du code binaire pour machine du type Cray, donc a priori non utilisable pour compiler pour des machines de type IA-32/x86.

[FR119492]

Salut!
La nouvelle norme Fortran permet la programmation orientée objet. Mais est-ce vraiment une bonne idée? N'est-ce pas céder à la mode aux dépens de l'efficacité traditionnelle de ce langage?
Jean-Marc Blanc

[Pragmateek]

La programmation orientée objet est plus qu'une mode car elle facilite les bonnes pratiques de programmation : modularité, encapsulation, factorisation ...

Même si un développeur expérimenté pourra sans doute produire du code d'aussi bonne qualité sans l'utiliser elle permet un accroissement significatif de la productivité et une standardisation du code facilitant notamment la migration et la modélisation avec des langages comme UML.

Et c'est malheureusement l'absence du paradigme objet, ou du moins sa mauvaise implémentation, qui pousse nombre de développeurs à migrer vers d'autres langages comme C++.

[Sylvain Bergeron]

Même dans un programme purement mathématique, on peut simplifier les choses en utilisant la programmation orientée objet. Si j'ai un échantillon de 100 points 3D à manipuler, en F77, j'aurai quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
      real pt_x(100), pt_y(100), pt_z(100)
      real dist(100)
...
      do i=1,100
          dist(i) = CalcDist(0.0,0.0,0.0,pt_x(i),pt_y(i),pt_z(i))
      enddo
...

Alors qu'en F90 (et+), j'aurai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
      type (TPoint3D) :: pt(100), Origine = TPoint3D(0.0, 0.0, 0.0)
      real :: dist(100)
...
      dist(:) = Distance(Origine, pt(:))
...

[FR119492]

on peut simplifier les choses en utilisant la programmation orientée objet

Oui, mais qu'en est-il de la vitesse d'exécution?
Jean-Marc Blanc

[Sylvain Bergeron]

De mémoire, ce qui est lent dans la POO, c'est le polymorphisme, car c'est implanté (en général) avec des lookup tables (Le premier champs de l'objet est le type effectif de l'objet en texte et Objet.Methode() est résolu par une recherche dans la table des méthodes avec le nom texte de l'objet).

Pour le reste, ça dépend de l'application. L'exemple ci-haut avec TPoint pourrait être plus rapide en POO car les coordonnées xyz sont consécutives en mémoire et non distantes par la longueur des vecteurs; elles pourraient donc bénéficier du pipelining de la mémoire lors des calculs...

[FR119492]

Pour le reste, ça dépend de l'application.

Et pour résoudre des systèmes linéaires, calculer des valeurs propres, intégrer des équations différentielles ordinaires, de Poisson, Navier-Stokes et autres?

J'ai l'impression, peut-être fausse, que plus je suis proche du hardware, mieux je maîtrise. Quant à l'efficacité pour le programmeur, je m'en fiche, car je suis retraité et j'ai tout mon temps.
Jean-Marc Blanc

[Pragmateek]

Et pour résoudre des systèmes linéaires, calculer des valeurs propres, intégrer des équations différentielles ordinaires, de Poisson, Navier-Stokes et autres?

Tant que l'algorithme n'est pas "pollué" avec des "features" orientées objet nécessitant un peu plus de ressources la vitesse sera la même.

J'ai l'impression, peut-être fausse, que plus je suis proche du hardware, mieux je maîtrise.

En effet mais les compilateurs actuels sont capables d'optimiser le code, y compris orienté objet, bien plus qu'un développeur.
Ainsi il est généralement plus efficace de se concentrer sur l'algorithme, qui est le premier facteur à optimiser, et laisser au compilateur le soin de l'optimisation "technique" qui peut aller loin : déroulement de boucle, inlining de fonction/procédure ...
Mettre en place de telles optimisations dans le code source le rendrait très difficilement maintenable.

Toutefois certains langages, comme C++, permettent de maitriser tous les niveaux : de l'assembleur jusqu'à l'orienté objet, et s'adaptent ainsi à tout type de programmation.

Mais la vraie raison de l'utilisation de paradigmes comme la programmation orientée objet est de réduire les coûts de développement et de maintenance des applicatifs qui sont souvent des objectifs bien plus critiques que la performance pure.
Ce paradigme en a amené d'autres comme la programmation par aspect qui permet encore d'améliorer la qualité du logiciel.

Désormais l'objectif premier est plutôt d'optimiser la conception et de laisser le soin à des outils spécialisés de développer l'applicatif : c'est le credo de l'ingénierie dirigée par les modèles.
Un seul modèle peut ainsi permettre de générer automatiquement des applicatifs pour plusieurs langages/plateformes/architectures.