Aller au contenu

Mes aventures en programmation...

'Bruno

Par 'Bruno
dans On fait une pause

 Partager

Messages recommandés

'Bruno

'Bruno

Posté
Posté (modifié)

Ayant toujours gardé en tête mes projet d'écrire un programme de cartographie stellaire (pour faire des choses de ce genre : http://www.astrosurf.com/bsalque/m81.pdf ou mieux - j'ai des idées...), et aussi par goût, je me suis amusé à comparer la rapidité de calcul de trois langages très différents :

- le vénérable Fortran, langage datant des années 1950 et synonyme de programmation à l'ancienne, mais spécialisé dans les calculs ;

- le C, datant des années 1970 (ou fin 60s ?) et qui a servi à fabriquer Unix, aujourd'hui dépassé par le C++ (version objet) mais qui est « parlé » par tous les programmeurs ;

- le Java, fin des 90s, langage objet donc synonyme de programmation moderne.

 

Si comme moi vous aimez bien écrire des petits programmes pour l'astro, peut-être que vous vous êtes demandés s'il y a des différences de rapidité entre les langages ? Pour le tester, j'ai écrit rapidement un programme de détection de nombres premiers entre 1 et N, que j'ai traduit dans les trois langages ci-dessus. Les voici (dans l'ordre : Java JDK 1.7.0 , GNU C, GNU Fortran 77) :

 

/* Ce programme affiche tous les nombres premiers jusqu'à l'entier NMAX
  donné par l'utilisateur. En outre, il compte les nombres premiers. */
/* Version sans affichage pour évaluer seulement la rapidité de calcul. */

public class Prems1
{
public static void main(String[] args)
{
	/* Lecture du nombre maxi de nombres premiers à déterminer */
	System.out.print("NMAX = ") ;
	final int nmax = Clavier.lireInt() ;

	int z = 0 ;   // z est le nombre de nombres premiers trouvés.

	if (nmax >= 2)
	{
		System.out.println( 2 ) ; // 2 est le seul premier pair.
		z += 1 ;                  // on a trouvé le premier nombre premier.
	}

	/* Boucle sur tous les nombres impairs de 3 à nmax */

	for( int n=3 ; n <= nmax ; n+=2 )
	{

		/* On détermine si l'impair n est un nombre premier. */
		/* Pour ça, on va balayer les nombres de 3 à la partie entière de
		   la racine carrée de n --> ce sont tous les candidats diviseurs.
		   Pour chacun d'eux, on regarde si la division n/d a un reste nul.
		   Si oui, d est bien un diviseur, donc n n'est pas premier. */

		int rn = (int) Math.sqrt( 1.0 * n ) ;
		int d = 3 ;           // candidat diviseur (impair).
		boolean prem = true ; // true si n est premier,
		                      // false si on a trouvé un diviseur.

		while ((prem == true) && (d <= rn ))
		{
			if (n % d == 0) prem = false ;
			d += 2 ;
		}

		if (prem == true)
		{
			if (z % 100000 == 0) System.out.println( n ) ;
			z += 1 ;        // 1 nombre premier de plus.
		}

	}

	/* On affiche le nombre de nombres premiers trouvés. */

	System.out.println("TOTAL = " + (z) + " nombres premiers.") ;

}
}

 

/* Ce programme affiche tous les nombres premiers jusqu'à l'entier NMAX
  donné par l'utilisateur. En outre, il compte les nombres premiers. */
/* Version sans affichage pour évaluer seulement la rapidité de calcul. */

#include <stdio.h>
#include <math.h>

main()
{

int nmax ;   // nombre maxi donné par l'utilisateur
int n ;      // nombre courant (candidat à la primalité)

/* Lecture du nombre maxi de nombres premiers à déterminer */
printf("NMAX = ") ;
scanf("%d", &nmax) ;

int z = 0 ;   // z est le nombre de nombres premiers trouvés.

if (nmax >= 2)
{
	printf("2\n" ) ; // 2 est le seul premier pair.
	z += 1 ;         // on a trouvé le premier nombre premier.
}

/* Boucle sur tous les nombres impairs de 3 à nmax */

for( n=3 ; n <= nmax ; n+=2 )
{

	/* On détermine si l'impair n est un nombre premier. */
	/* Pour ça, on va balayer les nombres de 3 à la partie entière de
	   la racine carrée de n --> ce sont tous les candidats diviseurs.
	   Pour chacun d'eux, on regarde si la division n/d a un reste nul.
	   Si oui, d est bien un diviseur, donc n n'est pas premier. */

	int rn = (int) sqrt(1.0 * n) ;
	int d = 3 ;           // candidat diviseur (impair).
	int prem = 1 ; // 1 si n est premier,
	               // 0 si on a trouvé un diviseur.

	while ((prem == 1) && (d <= rn ))
	{
		if (n % d == 0) prem = 0 ;
		d += 2 ;
	}

	if (prem == 1)
	{
		if (z % 100000 == 0) printf("%d\n", n) ;
		z += 1 ;        // 1 nombre premier de plus.
	}

}

/* On affiche le nombre de nombres premiers trouvés. */

printf("TOTAL = %d nombres premiers.\n", z) ;

}

 

c	Ce programme affiche tous les nombres premiers jusqu'à l'entier NMAX
c	donné par l'utilisateur. En outre, il compte les nombres premiers.
c	Version sans affichage pour évaluer seulement la rapidité de calcul.

implicit none

integer nmax    ! nombre maxi donné par l'utilisateur.
integer n       ! nombre courant (candidat à la primalité).
integer z       ! z est le nombre de nombres premiers trouvés.
integer rn      ! racine carrée de n.
integer d       ! candidat diviseur (impair).
integer prem    ! 1 si n est premier,
                ! 0 si on a trouvé un diviseur.

c	Lecture du nombre maxi de nombres premiers à déterminer

print *, 'NMAX = '
read *, nmax

z = 0

if (nmax .ge. 2) then

   print *, '2'  ! 2 est le seul premier pair.
   z = z + 1     ! on a trouvé le premier nombre premier.

endif

c	Boucle sur tous les nombres impairs de 3 à nmax

do n = 3, nmax, 2

! On détermine si l'impair n est un nombre premier.
! Pour ça, on va balayer les nombres de 3 à la partie entière de
! la racine carrée de n --> ce sont tous les candidats diviseurs.
! Pour chacun d'eux, on regarde si la division n/d a un reste nul.
! Si oui, d est bien un diviseur, donc n n'est pas premier.

   rn = int( sqrt(1.0 * n) )
   d = 3       
   prem = 1    

! Simulation de la boucle 'while' :

200	   continue
   if ((prem .eq. 0) .or. (d .gt. rn )) goto 100

      if (mod(n, d) .eq. 0) prem = 0
      d = d + 2
      goto 200

100	   continue    ! fin 'while'

   if (prem .eq. 1) then

      if (mod(z, 100000) .eq. 0) print *, n
      z = z + 1    ! 1 nombre premier de plus.

   endif

enddo     ! fin boucle 'do n'

c	On affiche le nombre de nombres premiers trouvés.

print *, 'TOTAL = ', z, ' nombres premiers.'

end

 

Trois remarques :

- Je n'affiche que les nombres premiers n° 100.000, 200.000 et ainsi de suite afin de tester la rapidité de calcul, pas d'affichage (mais j'ai testé aussi la version où tous les nombres défilent à l'écran).

- L'algorithme est très simpliste puisque je cherche les diviseurs parmi 2 puis tous les impairs. J'aurais dû ne tester que les diviseurs premiers, mais il aurait fallu enregistrer les nombres premiers au fur et à mesure et je n'avais pas envie de m'embêter...

- Les puristes de la programmation vont frémir en voyant le programme Fortran : il contient un "goto" ! (En informatique comme en astro, les puristes n'aiment pas le goto :).) C'est obligé car le Fortran 77 ne possède pas de boucle "while" - il faut la simuler.

 

Les résultats que j'attendais :

- j'espérais que le Fortran serait le plus rapide, puisqu'il est spécialisé dans les calculs ;

- je m'attendais à ce que le Java soit le plus lent puisqu'il passe par une « machine virtuelle ».

 

Ben non !

 

Quand je fais tourner les programmes seuls, voici les temps de recherche des nombres premiers jusqu'à 100 millions :

- Fortran = 1'46"

- C = 1'47"

- Java = 1'47"

 

J'ai fait des « matchs » entre deux langages (en les faisant tourner en même temps), les temps sont identiques à la seconde près (par exemple C vs Java donne 1'53", C vs Fortran donne 1'55" pour les deux).

 

Quant au match à trois, curieusement il a vu le Java peiner un peu plus :

- Fortran = 2'36"

- C = 2'36"

- Java = 2'44"

 

Moralité : c'est du pareil au même ! Donc peu importe le langage, je me suis embêté pour rien...

 

(La version du programme qui affiche tous les nombres premiers est beaucoup plus lente, bien sûr (puisque l'affichage prend du temps) et se comporte différemment : le programme Fortran termine bien avant les deux autres, celui en Java étant légèrement derrière.)

 

Pour l'anecdote, j'ai découvert la programmation sur un Amstrad CPC 6128, avec le langage Basic fourni. J'avais écrit à l'époque un programme similaire, mais plus intelligent, avec un tableau qui stockait les nombres premiers au fur et à mesure, ainsi on ne testait que ceux-ci, ce qui est beaucoup plus rapide. Il avait pourtant fallu tout un dimanche après-midi pour obtenir les nombres premiers de 1 à 100.000 seulement. Une autre époque...

Modifié par 'Bruno
Leimury

Leimury

Posté
Posté

Bonjour,

 

Tu devrais essayer les machins #, C# est en lien direct avec .Net qui est le natif sous Windows.

Depuis Vista il y'a eu un gros travail de refactoring chez Microsoft et la plupart des bibliothèques causent le .net en natif et c'est la version C qui est émulée et subit un Marshaller (ou marshmaller je sais plus) quand tu attaques des langages compilés.

 

Grattes voir un peu Java, tu as des options pour maîtriser les perfs et la notion de JIT pour la compil à la volée.

Y'a moyen de gratter pas mal par ci par là.

Quand tu commences à toucher à des objets ne négliges surtout pas les finalizers.

On lit partout que c'est inutile mais pourtant quand on touche à des images ou autres données lourdes je t'assure que là on voit une nette différence entre une belle architecture avec finalizers et sans. Disons qu'un Garbagge collector ne peut peut être pas toujours rivaliser avec l'analyse d'un développeur.

 

Mé pourquoi ???

Quand on compil on a en général la bonne vieille option i386 qui passe peut être partout mais qui n'est vraiment pas adaptée à la bête à concours que tu as dans ta machine.

Ensuite tous les compilateurs ne se valent pas et on gagne à utiliser celui fourni par le fabricant de ton micro. Vas voir faire un tour sur le site d'Intel côté outils... ça vaut le détour :be:http://software.intel.com/en-us/intel-parallel-studio-xe/

Comme tu voies le Fortran et le C ne sont pas morts !

 

Tu peux peut être aussi tester C# histoire de voir... Sous Windows ça devrait pas être le pire.

 

Vu que tu cherches plutôt l'interop, utilises plutôt le java de Sun.

Côté calcul et langage pur Kaffe, Sun et Microsoft se valent mais dès que tu voudras aborder autre chose il n'y a que Sun qui propose les mêmes packages partout.

 

Non tu ne t'es pas embêté pour rien mais tu as des compilateurs tout pourris qui datent des années 90 et là même un script en Python fait mieux :p

'Bruno

'Bruno

Posté
  • Auteur
Posté (modifié)

Il existe des Java autres que Sun ? (Je pensais qu'il n'en existait qu'un.)

 

Pour l'instant ce qui m'intéresse, c'est ce dont j'avais parlé il y a un an ou deux : trouver un moyen simple de faire de la programmation graphique. Simple parce que je suis limité intellectuellement (le Java est probablement trop compliqué pour moi). Mais :

- En Fortran, je ne connais pas de bibliothèque graphique. Autrefois j'avais utilisé un truc appelé libgrx (qui existait aussi pour le C), mais c'est adapté aux écrans VGA 640x480...

- En C, j'ai de la bonne doc pour une bibliothèque appelée SDL, mais il faut définir les fonctions de base comme le tracé d'une ligne ou d'un cercle !

- En Java, j'ai de la doc sur des tracés simples et je pense que ça me permettra de faire un petit programme du genre simulation de pointage d'objets (on dessine dans un rond noir les étoiles, et on bouge le champ à la souris, quelque comme ça - il faudra être rapide et malin pour ne pas avoir à gérer un énorme stock d'étoiles). Donc il faut que je me force à comprendre la programmation objet, mais c'est compliqué.

- Pour l'instant, ce que je sais faire, c'est juste générer un fichier postscript (langage assez tordu aussi...), ce qui est très bien pour imprimer des cartes en vectoriel (j'utilise un ps2pdf pour en faire des fichiers PDF).

Modifié par 'Bruno
pascal_meheut

pascal_meheut

Posté
Posté

C'est du calcul sur les entiers, sans appels de méthodes, sans tableaux, sans récursivité...

 

Bref, ca teste autant le compilateur que de comparer des téléscopes en pointant l'appart de ta voisine à 200m par un temps un peu brumeux.

 

Après, sur des vrais programmes, les choses deviennent compliquées. Il y a encore 20 ans en gros, les compilos Fortran étaient effectivement les meilleurs. Vu que dès le 1er en 1957, ils avaient fait attention à ca, ca avait laissé des traces...

Mais on programmait encore en mono-proc le plus souvent.

 

Et Java ramait. Mais les compilateurs just-in-time ont fait d'énorme progrès et sur certains traitement, on montre que cette stratégie peut donner un avantage à Java sur des langages compilés statiquement comme Fortran et C.

Concrètement, on retrouve une quasi équivalence de performance dans pas mal de benchs.

 

Maintenant, si on recherche de la performance de nos jours, on va faire du parallélisme sous une forme ou une autre, utiliser les GPU et les gains obtenus en le faisant proprement seront sensiblement plus importants que ceux engendrés par le choix d'un langage...

jgricourt

jgricourt

Posté
Posté (modifié)

Les résultats que j'attendais :

- j'espérais que le Fortran serait le plus rapide, puisqu'il est spécialisé dans les calculs ;

- je m'attendais à ce que le Java soit le plus lent puisqu'il passe par une « machine virtuelle ».

 

Non celà n'a rien à voir, Fortran à la réputation d'être plus utilisé pour faire des calculs c'est historique (c'est beaucoup plus ancien que le C), les 2 autres langages que tu as utilisés sont des langage généralistes. Java n'est pas plus lent car ton programme Java est d’abord converti dans un langage intermédiaire appelé bytecode (le fichier .class) qui est un langage qui ne tourne que sur un processeur virtuel (qui n'existe pas vraiment) ensuite le byte code est réellement converti en code machine par le "just in time compiler" de Java pour tourner sur le processeur de ton ordinateur mais seulement en mémoire (pas de fichier). Donc étant donné les progrés des machine virtuelle Java ces dernières années il y a peu de différence entre Java et le C par exemple sur un programme de calcul aussi simple que le tiens. Par contre tu n'as certainement pas utilisé les options de compilation de ton compilateur C (-O2, -O3 etc ..) qui permettent d'optimiser le code machine généré et de booster la vitesse d'execution du programme parfois par 2 ou par 4 parfois.

 

Maintenant le match ne dit pas grand chose à part que le kernel de ton OS qui gère les processus n'est pas temps réel et que la durée effective d'execution d'un programme n'est pas établie à l'avance. Il y aussi une question de priorité et peut être que Java ne donne pas systématiquement la priorité maximale et ce pour de bonnes raisons. Pour dépasser les perf. de ton Amstrad tu devrais mieux exploiter l'architecture multi-core de ta machine en gérant plusieurs fils d’exécution par exemple ou en optimisant les résultats intermédiaires en les gardant en mémoire si il doivent resservir etc ...

 

Tu devrais essayer les machins #, C# est en lien direct avec .Net qui est le natif sous Windows.

 

Non windows est codé en C, seuls certains composants non critiques sont codés en C#, sinon C# et Java fonctionne de la même manière pour ce qui est de la génération de code il utilisent un compilateur à la volée pour générer du code machine natif au final. Après c'est vrai que C# permet de créer des composants ou des logiciels qui s'intègrent mieux à l'environnement Windows, par contre sur d'autre plateforme c'est différents (Linux entre autre) alors que Java fonctionne de la même manière partout même sur les machines les plus exotique. Je ne cache pas que lorsqu'on fait du calcul intensif il vaut mieux tout faire en C/C++ ne serait ce que pour les temps de chargement des programmes en mémoire et la possibilité d'aller encore plus loin dans l'optimisation des programmes. Pour des calculs scientifique j'aime bien la plateforme QT car elle offre une API C/C++ permettant de générer des programmes en natif, l'API propose de construire des IHM de haut niveau, et cerise sur le gâteau les programmes ne nécessitent aucune modif. pour fonctionner sur toutes les plateformes (un peu comme Java).

 

- En Fortran, je ne connais pas de bibliothèque graphique. Autrefois j'avais utilisé un truc appelé libgrx (qui existait aussi pour le C), mais c'est adapté aux écrans VGA 640x480...

- En C, j'ai de la bonne doc pour une bibliothèque appelée SDL, mais il faut définir les fonctions de base comme le tracé d'une ligne ou d'un cercle !

- En Java, j'ai de la doc sur des tracés simples et je pense que ça me permettra de faire un petit programme du genre simulation de pointage d'objets (on dessine dans un rond noir les étoiles, et on bouge le champ à la souris, quelque comme ça - il faudra être rapide et malin pour ne pas avoir à gérer un énorme stock d'étoiles). Donc il faut que je me force à comprendre la programmation objet, mais c'est compliqué.

Pour la programmation graphique il existe de bonnes bibliothèques pour ça que ce soit dans l’écosystème Java ou C# ou même QT qui intègre pas mal de choses, et tous permettent même faire de l'OPenGL pour faire des choses encore plus chiadées (voir Stellarium aussi qui est écrit en QT C/C++)

 

PS: en Java on peut générer directement du PDF (j'ai des exemples si tu veux) grâce à une API gratuite (iText) qui fonctionne comme une API de dessin quasiment, et je suis certain qu'il existe la même chose en C#. Enfin le langage de programmation ne change pas grand chose au code généré car le code machine est basique et ne comprends absolument pas ces raffinements de langage ;) Par contre pour le concepteur du programme cela apporte un cadre de programmation permettant d’implémenter des choses très complexes (à base de design pattern par exemple) et que malgré tout le code source reste compréhensible, maintenable, évolutif etc ... c'est plus dans le sens de la productivité que le gain est évident.

Modifié par jgricourt
Kelthuzad

Kelthuzad

Posté
Posté (modifié)

Salut,

 

Beaucoup de choses ont déjà été dites alors je fais court.

Je pense que C + SDL peut être pas mal pour une représentation 2D, sur le siteduzero y a un bon tutoriel si tu n'en as jamais fait.

Encore sur le siteduzero y a de bons cours sur la POO qui reprend bien depuis la base si tu veux te lancer plutôt sur de l'objet.

 

Pour la génération de pdf c'est également possible en C grâce à la bibliothèque Haru.

 

Sinon concernant les vitesses de calculs là-haut, ce n'est pas ça qui va bouffer en temps d'exécution, ça sera plutôt les entrées-sorties. Essaye d'écrire dans un fichier ou simplement un affichage console en boucle et le temps d'exécution augmente considérablement, je pense pas qu'il faille choisir le langage qui calcul le plus vite sur un projet comme celui-ci.

Modifié par Kelthuzad
Leimury

Leimury

Posté
Posté (modifié)

Non windows est codé en C, seuls certains composants non critiques sont codés en C#

 

Faudra que tu expliques ça à l'ingé de chez Microsoft (dame un peu agée aux cheveux gris) qui nous expliquait la nouvelle architecture (nouvelle en 2007) à la TechEd de Barcelone :D

Même au niveau de DirectX tout est fait pour accélérer le passage de paramètres avec les langages #. Quand tu programmes en C# il y'a pas mal de librairies bas niveau qui vont un chouilla plus vite parce que le passage de paramètres mange moins (Marshaller) .

Ce travail de fond entrepris avec Vista (le mal réglé) a permis entre autre d'isoler complètement les espaces mémoire interface et logiciel pour éviter que des virus se servent de la fenêtre facile à trouver et manipulable pour entrer dans l'espace mémoire d'une appli.

 

Il existe des Java autres que Sun ? (Je pensais qu'il n'en existait qu'un.)

 

Oui et non. Le bytecode est unique car Sun a gagné un procès contre Microsoft qui voulait s'amuser avec. Mais le bytecode ne permet pas grand chose tout seul.

Dès que tu veux toucher à l'écran, ajouter des boutons et que sais-je il te faut alors les packages.

Et là seul Sun les proposera quelle que soit ta plateforme.

 

Si tu joues sous Kaffe tu restes sous Linux.

Si tu joues sous Microsoft tu resteras sous Windows

Si tu joues sous Sun tu marches vraiment partout même avec les divers entrées sorties :)

Ca évidement si tu comptes développer une applet ou du code pour tous. Si c'est pour exécuter ton code sur le serveur et envoyer uniquement le résultat sur le client peu importe ton choix.

 

En vectoriel tu as le SVG http://fr.wikipedia.org/wiki/SVG

C'est affichable dans les navigateurs, même ceux de la pomme qui prennent pas le flash.

Vu que le SVG est considéré comme une image las tags du HTML s'y appliquent mais aussi tout ce qu'un navigateur sait faire avec une image (copier/coller, sauvegarder, imprimer...)

Par exemple pour une galaxie c'est souvent un ovale: en SGV tu peux utiliser l'oval avec inclinaison et taille en paramètre.

Je serais pas surpris qu'il y'ait une syntaxe pour les nuages de point façon amas et tu peux également y définir tes propres objets (constellation ?)

Tu as également des option intéressantes comme des gradients qui permettent assez facilement de définir une galaxie à la mode gris visuel si ça te chante.

Ca gère les couleurs avec le HAlpha (transparence :) )

Et le plus beau c'est que le rendu se fait côté client dans les navigateurs, tu ne manipules que du texte en XML.

 

Le XML peut faire peur mais faut pas.

S'il est vrai qu'on peut utiliser des librairies qui manipulent le XML on peut très bien le manipuler comme une bête chaine de caractère, ça mord pas :)

Modifié par Leimury
jgricourt

jgricourt

Posté
Posté (modifié)
Faudra que tu expliques ça à l'ingé de chez Microsoft (dame un peu agée aux cheveux gris) qui nous expliquait la nouvelle architecture (nouvelle en 2007) à la TechEd de Barcelone

Même au niveau de DirectX tout est fait pour accélérer le passage de paramètres avec les langages #. Quand tu programmes en C# il y'a pas mal de librairies bas niveau qui vont un chouilla plus vite parce que le passage de paramètres mange moins (Marshaller) .

 

Je pense qu'on ne parle pas de la même chose d'où la confusion, que le C# comme Java où bien d'autres langages permettent de transmettre des paramètres vers des fonctionnalités d'API native Windows cela se pratique tous les jours dans les projets informatique par contre le noyau et les composants critique de Windows ne sont pas écrit en C# c'est une certitude (montre moi les assemblies correspondantes alors ;)) Quant à la technique du Marshalling il y a exactement la même chose sous Java, cela permet de passer des paramètres entre librairies ou processus qui ne sont pas forcement constitués de la même technologie (les webservices sont un exemple d'application courant de même que le transport de fichiers de données XML).

 

Oui et non. Le bytecode est unique car Sun a gagné un procès contre Microsoft qui voulait s'amuser avec. Mais le bytecode ne permet pas grand chose tout seul.

Dès que tu veux toucher à l'écran, ajouter des boutons et que sais-je il te faut alors les packages.

Et là seul Sun les proposera quelle que soit ta plateforme.

 

 

Oui le language bytecode est clairement définit aujourd'hui (The Java Virtual Machine Instruction Set). Le langage Java permet de manipuler l'écran à loisir sans librairies additonnelles c'est pas trop le pb de même qu'on génère les interfaces graphiques que l'on veut après il est vrai que si l'on veut obtenir un rendu plus proche des IHM windows par ex il faut faire des appels plus direct dans les API sous jacentes (JNI, DLL call, etc ...) ou bien utiliser des librairies plus spécialisées qui permettrons d'invoquer les libs de Windows sans détour. Sinon il y a d'autres alternatives, comme RCP Eclipse qui est une librairie graphique très aboutie pour générer de beaux IHM que ce soit sous Windows ou Linux par ex. (une fois encore le code restera inchangé lorsqu'on change de plateforme). Sinon la JVM de Sun fonctionne à peut près partout c'est celle qui utilisée communément dans l'industrie (sauf lorsqu'on va utiliser de gros serveurs IBM hébergeant des serveurs d’applications comme dans les serveur centraux des banques où on utilise une JVM optimisée par IBM). :)

Modifié par jgricourt
'Bruno

'Bruno

Posté
  • Auteur
Posté (modifié)

Je note avec attention tout ce que vous me dites...

 

Je pense que C + SDL peut être pas mal pour une représentation 2D, sur le siteduzero y a un bon tutoriel si tu n'en as jamais fait.

C'est ce que j'ai regardé ces derniers temps. Eh bien figure-toi que cette bibliothèque ne contient pas de fonctions pour dessiner des lignes, des cercles, des ellipses, etc. Ce n'est pas fait pour ça, plutôt pour gérer des images BMP qui existent déjà.

 

Sinon concernant les vitesses de calculs là-haut, ce n'est pas ça qui va bouffer en temps d'exécution, ça sera plutôt les entrées-sorties.

Oui, comme je le disais, si je fais afficher les nombres (ça défile à l'écran), c'est beaucoup plus lent, et là les trois langages ne sont plus sur un pied d'égalité.

 

---------------------

Sinon, une idée que j'aimerais mettre en oeuvre, c'est d'écrire un petit utilitaire de simulation de pointage. Il affiche le ciel local à l'oeil nu (dans toute la fenêtre), ou au chercheur (dans un rond) ou à l'oculaire (idem) et la mission de l'utilisateur doit être de mettre l'objet dans l'oculaire, sachant que ce qui s'affiche n'est pas une carte mais une simulation du ciel (pas de tracé des constellations, etc.) (mais on peut imaginer une option "aide" qui donne quelques indications). Je sais faire tout ça au niveau des algorithmes, je sais programmer les calculs, mais je ne sais pas programmer les ouvertures de fenêtre ou la gestion de la souris. Ça fait longtemps que j'y réfléchis et je ne trouve rien d'assez simple. Par exemple Visual Basic, j'ai essayé en suivant un livre sensé être lisible par des débutants, et ça ne m'a vraiment pas plu (je ne veux plus voir sur mon ordinateur cette cochonnerie qui m'a créé un répertoire au nom débile à la racine).

 

J'ai cru que SDL serait la solution, d'autant que le site du zéro, comme le disait Kelthuzad, propose un bon tutoriel. Mais il faut tout redéfinir ! ==> Hors-jeu.

 

Là, j'ai trouvé un livre sur Java qui explique très bien la gestion des fenêtres et de la souris. En contrepartie, il faut utiliser la notion d'objet (mais bon, j'ai bien noté qu'on peut définir des espèces de fonctions traditionnelles avec le mot-clé "static" et j'imagine bien en abuser...) Donc j'entrevois enfin la possibilité de faire ce truc.

 

Mettons que le programme s'appelle Bidule. Pour le faire tourner, je taperai dans la fenêtre de commande > java Bidule (à moins qu'il y ait moyen de se passer de la fenêtre de commande, ce que suggère le bouquin, mais je ne suis pas encore au bout des 850 pages...) C'est embêtant de ne pas avoir de "vrai" exécutable (je sais, c'est fait exprès pour des raisons précises).

 

Car l'idée suivante, ce serait de mettre le programme sur ma page Web. Pour l'instant, je me dis qu'un utilisateur qui téléchargerait le programme serait obligé d'avoir installé Java sur sa machine afin de pouvoir taper > java Bidule. C'est compliqué (il y a encore deux semaines, je n'avais pas de Java sur ma machine, ou alors je n'étais pas au courant - en tout cas, mon Path n'était pas au courant et c'est ça qui compte). Je suppose qu'il existe une solution.

 

Qu'en pensez-vous ?

Modifié par 'Bruno
Leimury

Leimury

Posté
Posté (modifié)

Bonjour,

 

Tu es certain de vouloir que l'utilisateur télécharge un exe ?

Plus ça va et plus le téléchargement d'exe est soumis à vérification, contre vérification, et alerte et re-alerte qui expliquent sans catastrophisme aucun que cette opération peut aboutir à l'explosion d'un truc qui risque de mettre en péril la cohésion même de l'univers.

 

Même quand on sait ou ça s’exécute et qu'on se simplifie la vie avec du compilé on a tout de même la joie de voir son soft échouer sur certaines machines avec des messages d'une limpidité fracassante (error 124: la DLL qui était chez toi mais pas chez le gentil utilisateur :be:)

Avec java tu as vu que quand ça marche pas tout seul faut tout de même mettre les mains dans le cambouis.

Pour l'utilisateur définir un raccourcis qui fasse javaw tonappli.jar c'est pas vraiment la mer à boire vu qu'avant ça il faut qu'il s'occupe du JRE (JavaRuntimeEnvironment) s'il a un problème à l’exécution.

 

En java tu peux définir une applet qui s’exécutera directement dans le navigateur.

Le problème c'est qu'il faut que l'utilisateur ait configuré son navigateur pour autoriser les applets et sur la même source des packages java que toi (sun ?)

Dans les faits des applets on en croise pas beaucoup, y'a peut être une bonne raison non ?

 

Tu as peut être déjà vu ces petits jeux dans le navigateur

http://www.stratozor.com/bataille-navale/bataille-navale-moderne.php

Vu que tu es encore en recherche regardes voir du côté Flash (Flex,ActionScript)

Et le plus beau c'est que c'est également exécutable sans connexion si tu décides d'exposer ton fichier .jws au téléchargement.

 

Vu la description de ton projet je crois que la techno Flash serait plutôt indiquée.

Un exemple de gestion de collision

http://stephaneey.developpez.com/tutoriel/flashmx2004/collision/

 

Tutoriels des techniques de base des jeux en flash (collision, animations, images...)

http://flash.developpez.com/telecharger/index/categorie/267/Jeux

 

Bon ciel

Modifié par Leimury
pascal_meheut

pascal_meheut

Posté
Posté

+1. Surtout ne pas faire du Java quand on ne connait pas les problématiques de distribution et l'objet.

 

Et éviter de faire un exécutable si possible. Ou alors, le faire en un truc raisonnablement simplet et portable genre Qt mais même là, il y a un certain apprentissage.

 

L'inconvénient du flash, c'est que son avenir est moins brillant qu'il y a qques années mais c'est plus simple (et la non compatibilité avec iOS).

 

Malheurement, il n'y a pas aujourd'hui de techno qui tournerait partout et qui serait facile à déployer.

'Bruno

'Bruno

Posté
  • Auteur
Posté

Houlà, vous me mettez le doute... (Je me fais penser à un astronome débutant qui voulait acheter une lunette et qui hésite entre un ETX et un Dobson... :))

 

Pascal, que veux-tu dire exactement :

Surtout ne pas faire du Java quand on ne connait pas les problématiques de distribution et l'objet.

 

Pour simplifier, voici ce que j'aimerais bien faire :

1° - un programme qui dessine le ciel étoilé dans une fenêtre, et ce de façon interactive (avec les flèches du clavier ou la souris, on change l'orientation) ;

2° - mettre ça sur ma page Web sous une forme qui le rende utilisable (si c'est possible).

 

Je sais programmer des cartes du ciel imprimables (en Postscript) mais ce n'est évidemment pas interactif.

 

Si j'ai bien compris ce que tu dis, Leimury, il serait même possible d'utiliser ce programme sans le télécharger mais directement en l'utilisant depuis la page Web ?

jgricourt

jgricourt

Posté
Posté (modifié)
Si j'ai bien compris ce que tu dis, Leimury, il serait même possible d'utiliser ce programme sans le télécharger mais directement en l'utilisant depuis la page Web ?

 

Cela s'appel une applet ... mais cela nécessite que le client (le navigateur) soit pourvu de l'interpréteur Java (il suffit d'installer une JVM). Les applets comme les aplication flash du reste sont de vrais gouffres à ressources et ce n'est donc pas conseillé de charger un navigateur avec. Sinon on peut créer des pseudo exécutable Java ce sont des fichiers .jar (avec le descripteur qui va bien) qui ne s’exécuteront que dans la sandbox Java lorsqu'on double click dessus donc cela résous pas mal de pb de sécurité. Pour ta problématique de rendre tes cartes interactives, tu devrais décorréler complètement l'affichage du document lui même, n'importe quelle API de dessin (et Java en a plus que tu aurai besoin) te permet de créer en live les cartes (poser les objets à la souris sur l'écran, rajouter des labels, zoomer etc ...) et enfin un bouton d'action permetterai de générer le document à partir des objets de l'écran (que ce soit du Latex, du PDF en direct avec iText ou une autre solution tel que SVG comme suggéré par Leymury...). Sinon je suis d'accord avec Pascal, ce sera compliqué et contre productif si tu ne t'investies pas dans la programmation objets au départ car en faisant uniquement de la prog. séquentielle classique avec Java tu n'ira pas très loin dans ton projet.

Modifié par jgricourt
pascal_meheut

pascal_meheut

Posté
Posté

Pascal' date=' que veux-tu dire exactement :

[/quote']

 

Que faire du Java avec des méthodes statiques sans connaitre l'objet ne marchera pas bien. Enfin, si pour tes calculs.

Mais pour l'interface, ca ne va pas être la joie.

 

Et que distribuer un programme Java pour qu'il tourne sans que l'utilisateur ait à y connaitre quelque chose en informatique est possible mais pas tout simple.

 

J'ai fait 2 projets open-source multi-plateformes récemment : un en Java, l'autre en C++/Qt.

Dans les 2 cas, l'utilisateur télécharge et clique et ca se lance.

 

L'avantage de ce point de vue là va largement à C++/Qt même si je préfère Java à C++.

 

Reste ca où les technos Web. Oublie les applets, c'est une techno qui ne marche pas bien.

 

Par contre, faire du Javascript en alternative au flash ne serait pas idiot. C'est simple, léger, tu n'es pas obligé de faire de l'objet et ca tourne dans n'importe quel browser.

Maintenant, à quel point ca sera adapté à ton projet, je ne peux pas le vérifier là.

Leimury

Leimury

Posté
Posté (modifié)

Bonjour,

 

Non, l'Applet c'est pour Java alors que là Bruno parle du Flash.

 

Oui Bruno, on peut lancer du Flash sans connexion.

Comme tu l'as sans doute constaté sur ton propre PC Flash se met à jour assez souvent.

Flash est maintenant vraiment partout à part sur l'IPhone de façon officielle.

 

Vu qu'un truc pas testé ne vaut rien:

J'ai simplement lancé le swf d'un des jeux flash de chez Stratazor: http://www.stratozor.com/bataille-navale/bataille-navale-moderne.php

 

Tu vas sur un jeu flash avec Firefox;

tu vas ensuite sur Outils/Informations sur la page.

De là dans l'onglet Médias et tu verras le swf de ton jeu dans la liste.

Tu sélectionnes et tu cliques sur Enregistrer sous...

 

Là j'ai coupé ma connexion internet pour vérifier.

 

Même pas besoin d'un player (enfin c'est comme l'histoire de la prose, il est sous forme de plugin du navigateur)

Soit tu lances ton swf et tu lui indiques un navigateur comme appli

soit tu lances le navigateur et tu tapes le chemin du fichier dans la barre d'adresse.

Pas de problème, ça marche :)

 

Sur la plupart des sites le swf n'est pas partagé mais rien ne t'empêche de le rendre dispo de façon évidente.

Modifié par Leimury
yonafunu

yonafunu

Posté
Posté
Bonjour,

 

Non, l'Applet c'est pour Java alors que là Bruno parle du Flash.

 

Oui Bruno, on peut lancer du Flash sans connexion.

Comme tu l'as sans doute constaté sur ton propre PC Flash se met à jour assez souvent.

Flash est maintenant vraiment partout à part sur l'IPhone de façon officielle.

 

 

Ouai partout...sauf sur Linux où il n'y aura plus aucune mis à jour.

Leimury

Leimury

Posté
Posté (modifié)

Et alors ?

Aucune mise à jour ça veut tout de même dire qu'il y'a un truc qui marche non ?

 

Pour ce que recherche Bruno nulle besoin d'aller restreindre à la toute toute dernière version.

Juste par curiosité, le jeu de Bataille navale marche t'il sur le navigateur de ton Linux ?

 

Demandes voir à Bruno de quand date son compilateur Fortran :D

Je t'assure qu'il y'a une vie même sans mise à jour.

ActionScript 3.0 date de 2006: c'est plus tout neuf !

 

Quand on programme en Java ou en Flash on évite d'utiliser la version de demain, on préférera rester sur la plus ancienne qui intègre les fonctions dont on a besoin.

Vu que la règle (à part sur MacOs :p) est la compatibilité ascendante, celui qui a un vieux flash tournera aussi bien que le tout beau tout neuf.

Modifié par Leimury
'Bruno

'Bruno

Posté
  • Auteur
Posté

Bon, pour l'instant je vais rester sur mon idée de faire ça en Java parce que j'entrevois la possibilité d'aller au bout, et tant pis s'il faut apprendre de nouvelles techniques de programmation (après tout, ça fait partie du plaisir...). Je me préoccuperai en temps voulu de savoir comment on peut transmettre le truc.

 

J'aime bien ce que dit Leimury sur les mises à jour. Quand un programme est bon, pas besoin de le mettre à jour. Guide 8 (à mon avis le meilleur logiciel de cartographie céleste) date de 2002 et la version 9 n'est apparue que cette année. Comme ça, pas besoin d'acheter quelque chose tous les ans. Mon navigateur préféré, K-Meleon, n'est plus mis à jour. Pas grave, il marche. Pareil pour mon compilateur Fortran (de chez GNU), et depuis pas mal d'années. Pour lire les news, j'utilise XNews, que j'avais téléchargé au siècle dernier ; j'ai aujourd'hui la version de 2002 - la dernière à ce jour.

Leimury

Leimury

Posté
Posté

Au fait, Flash utilise ActionScript qui est en fait une spécialisation de JavaScript.

Y'a le mot Java dedans, ça va pas le faire ?

 

Tant qu'à te mettre à kekchose prends plutôt l'ActionScript.

Tu auras un meilleur rendu à l'écran et cette techno fait ses preuves en cross plateforme sur des jeux vraiment pas mal.

 

Tu voies ce qu'on répond quelquefois à kekun qui cherche en astrophoto et voudrait d'un truc improbable ?

Fais une recherche d'images.

 

Tapes voir Jeu Flash sous google et ensuite tu fais une recherche d'applets ou d'applis Java...

 

S'il y'a tellement de choses belles à voir en Flash c'est peut être pas un hasard.

 

J'aime bien Java mais force est de reconnaître que Flash simplifie beaucoup la vie du développeur et de l'utilisateur.

 

Dernier point... En Flash t'es pas obligé de te mettre à faire de l'objet :p

'Bruno

'Bruno

Posté
  • Auteur
Posté (modifié)

Ah, Leimury, tu as des arguments convaincants. Je vais voir ce que c'est qu'ActionScript...

 

Une chose qui me plaît, c'est qu'il y a plein de réactions. Comme quoi il n'y a pas que les discussions sur les soucoupes volantes qui provoquent des réponses ! :)

Modifié par 'Bruno
jgricourt

jgricourt

Posté
Posté (modifié)

Juste une petite remarque au passage JavaScript n'a rien à voir avec le langage Java c'est juste une erreur de casting ... ;) et puis, au niveau interface graphique, calculs un peu poussé et extensions possibles (par des libs externes) tu sera toujours limité avec les langages de scripting qui à la base sont prévus pour faire de petites applications (applets) rapidement. Sinon flash c'est un gouffre à mémoire, il y a longtemps que je l'ai désactivé sur mon navigateur et puis j'ai peur qu'avec des milliers d'objets affichés en temps réel sur une carte ce soit ingérable mais bon tu as aussi besoin de te faire ta propre expérience c'est comme cela qu'on progresse :)

Modifié par jgricourt
pascal_meheut

pascal_meheut

Posté
Posté
tu sera toujours limité avec les langages de scripting qui à la base sont prévus pour faire de petites applications (applets) rapidement.

 

D'un autre coté, quand tu vois ce qu'on fait en Javascript avec ou sans PHP, ca devient moins vrai (cf Google Maps, Google Docs par ex).

Mais effectivement, coté calcul pur, ca n'est pas encore ca.

 

Son problème est surtout qu'il a 2 besoins : faire des calculs et faire une interface.

Idéalement, on sépare les 2 aujourd'hui (comme le fait Mathematica) mais ca complique pas mal les choses.

'Bruno

'Bruno

Posté
  • Auteur
Posté

Ah, rebondissement... Pour l'affichage, je devrais lire de gros fichiers d'étoiles. À l'oeil nu ça va encore, mais l'affichage à l'oculaire du télescope utilisera le catalogue All-Sky qui va jusqu'à la magnitude 12-13 et contient 2.500.000 étoiles (il faudra sûrement que je le découpe par zones pour n'avoir pas à tout charger, sinon l'accès dans un gros tableau risque de ralentir l'affichage).

Leimury

Leimury

Posté
Posté (modifié)

Quand tu voies un GPS ou de l'affichage 3D la problématique est la même: c'est un iceberg.

Beaucoup de données mais très peu à afficher.

 

Stellarium, Astromist et les autres le font bien non ?

 

Ça dépendra surtout de comment tu crées ton catalogue en mémoire.

Tu devras forcément en passer par une phase de chargement/indexation au démarrage pour accélérer le fonctionnement.

C'est ce qui fait qu'on a par exemple intérêt à utiliser un set ou une map en C++ (ou les versions multi): ça classe à l'insertion et à l'utilisation c'est plus rapide puisqu'on sait que tout ce qui s'y trouve est classé.

 

Avec par exemple une multimap en DEC tu restreins facilement le ciel à une couronne avant de cycler dedans en AD.

Pour les objets plus étendus qu'un point tu as des redondances car le même objet est sur plusieurs références en DEC.

Ca supposerait que tu batisses l'indexation d'abord sur les étoiles pour avoir un échantillon de DECs réalistes.

 

Ou alors ton découpages en toutes petites zones.

Chaque zone est un vecteur qui contient des références vers les fiches de chacun de tes astres.

Une chtite formule pour avoir le numéro de zone en fonction d'un AD/DEC et roules Raoul.

 

Le plus gros problème c'est plutôt comment entrer le catalogue.

Le plus sage serait de prendre les catalogues texte existants et avoir une partie du soft qui sache la digérer en auto.

Tu ne veux tout de même pas jouer les opérateurs saisie sur 2500000 étoiles (+ les amas, les nébuleuses, les galaxies)

 

Les étoiles encore ça va, c'est juste un point mais pour les autres corps célestes ça se complique.

Rien qu'une galaxie a une largeur, une longueur et une orientation.

Les nébuleuses c'est du grand n'importe quoi avec des formes plus tordues les unes que les autres.

Ca peut être utile de définir la notion de centre et de rayon ou de rectangle externe en plus de le définition de la forme pour accélérer les recherches.

 

Une fois qu tu auras défini à quoi ressemble un bidule (étoiles, galaxies, doubles, amas...) pour ton soft tu auras déjà fait la moitié du boulot :)

 

Mais surtout, surtout, n'oublies pas ce que t'a appris ton test.

Ce qui bien optimisé mettait tout un après midi se fait maintenant en moins de 5mn sans optimisation.

 

Elle est pas belle la vie ? :beer:

 

PS: Tu connais le passage par valeur et par référence en C et sans doute aussi en fortran.

Dans la plupart des langages c'est clairement identifié et on sait qu'on manipule une copie ou alors qu'on touche directement le paramètre.

En Java c'est plus tordu.

les types simples (boolean, int...) sont toujours passés par valeur ou copie alors que les types complexes (Math.Long par exemple et tout ce qui hérite du type Object) sont toujours passés par référence.

Absolument aucune indication, c'est comme ça et ça peut surprendre quand on vient du C ou du Fortran :p

Modifié par Leimury
jgricourt

jgricourt

Posté
Posté (modifié)
D'un autre coté, quand tu vois ce qu'on fait en Javascript avec ou sans PHP, ca devient moins vrai (cf Google Maps, Google Docs par ex).

Mais effectivement, coté calcul pur, ca n'est pas encore ca.

 

Oui !

 

Son problème est surtout qu'il a 2 besoins : faire des calculs et faire une interface.

Idéalement, on sépare les 2 aujourd'hui (comme le fait Mathematica) mais ca complique pas mal les choses.

 

Non c'est plus simple au contraire, il n'y a rien de pire au niveau complexité et maintenabilité que de mélanger la présentation, les données et les processus qui traite ces données (les calculs ici). C'est un peu pour ça qu'on préfère utiliser des langages objets couplés à des schémas de construction éprouvés (MVC pour le web, API QT par ex) qui permettent une telle séparation car souvent dans un projet celui qui fait le design n'est pas le même que celui qui construit la base de donnée ni celui qui est en charge des calculs scientifiques ... :)

 

PS: @Leimury Java est très clair sur la problématique du mode de passage des arguments, ils se font uniquement par valeur y compris les références d'autres objets. En C# c'est plus tordu on peut faire les deux (comme en C) moyennant l'usage du modificateur "ref" ;). Le tout est de savoir ce que l'on fait mais en général il est préférable de ne pas modifier une structure de donnée passé en arguments (par référence justement) pour éviter les effets de bords ...

 

Cela me fait penser à un truc très important, c'est la libération de la mémoire des objets alloués dynamiquement (par les pointeurs en C par ex). Java et C# utilise un garbage collector dont le rôle est de détruire automatiquement les objets qui sortent du "scope" du programme (objets qui ne seront plus jamais utilisés), ce qui n'est pas le cas d'autres langages comme le C/C++, où celui qui réalise le programme doit penser aussi à virer les objets au bon moment sinon gare aux fuites mémoires qui peuvent faire planter l'application au bout d'un temps ... un petit bémol avec l'API QT (C/C++) qui lorsqu'on utilise certains objets de l'API permet de s'affranchir de cette tache.

Modifié par jgricourt
'Bruno

'Bruno

Posté
  • Auteur
Posté (modifié)
Beaucoup de données mais très peu à afficher.[...]

C'est en effet un problème très intéressant ! Les logiciels de planétarium ne font sûrement pas n'importe quoi... Quand je crée une carte en postscript, ça ne me dérange pas si ça prend quelques secondes, mais à présent il faudra que je me préoccupe d'aller vite.

 

Voici ce que j'ai en tête pour l'instant :

- D'abord, on pourrait charger le catalogue des 2.500.000 d'étoiles dans un tableau (AD + DE + magnitude = pas plus de 10 octets par étoile, donc < 25 Mo, c'est pas gros). Le programme n'aura alors plus qu'à parcourir le tableau et calculer si l'étoile est visible, et si oui l'afficher. Ce sera plus rapide que de parcourir le fichier, l'accès à la mémoire vive étant plus rapide que l'accès au disque dur. Mais à mon avis ce sera encore trop lent.

- Je vais donc découper le catalogue en plusieurs zones (d'ailleurs à l'origine il est découpé) afin de ne charger qu'un petit tableau. Dans les vues à l'oculaire, normalement on restera dans la même zone, sauf si on se déplace trop loin, auquel cas il faudra charger la nouvelle zone, mais ça n'arrivera pas souvent.

- Il y aura un catalogue pour les étoiles à l'oeil nu (pas besoin de charger celles de magnitudes 10) et un autre pour le chercheur (pas besoin de la magnitude 13...) C'est donc seulement à l'oculaire qu'il faudra le catalogue complet, mais à l'oculaire on se déplace sur de petites zones.

 

[...]Le plus sage serait de prendre les catalogues texte existants et avoir une partie du soft qui sache la digérer en auto.

Je ne comprends pas trop le problème. Je pars de catalogues existants, mais que je modifie à ma guise une fois pour toutes.

 

Les étoiles encore ça va, c'est juste un point mais pour les autres corps célestes ça se complique.

Mon but est de faire une simulation de pointage, donc l'idée, c'est des étoiles sous forme de ronds floutés aux bords (j'aimerais bien utiliser une pseudo-gaussienne, c'est-à-dire quelque chose qui ressemble à une gaussienne pour le réalisme, sans en être une vraiment car les calculs seraient longs (*)) et les objets flous du ciel profond seront des disques ou des ellipses à peine moins noirs que le ciel (et aux bords floutés). Le ciel aussi, j'aimerais le faire assez réaliste, donc bruité, mais sans calculer son niveau pixel par pixel, ce serait trop long...

 

(*) Une idée possible serait de dessiner quatre disques l'un sur l'autre : d'abord un grand disque gris foncé (donc à peine distinguable du ciel), puis un disque un peu plus petit et gris plus clair, puis encore un plus petit disque encore plus claire, et enfin un point clair. Comme ça, ça simulerait la décroissance de brillance. La taille des disques et leur niveau de gris dépendraient de la magnitude. Le nombre de disque aussi : une étoile très brillante risque de nécessiter plus de disques, une étoile à la limite sera juste un point gris foncé. En gros c'est l'idée. (Dessiner une vraie gaussienne serait probablement trop long à cause des calculs compliqués. Encore que, il faudrait essayer...)

 

Rien qu'une galaxie a une largeur, une longueur et une orientation.

Les catalogues fournissent ces données, y compris l'angle de position.

 

Les nébuleuses c'est du grand n'importe quoi avec des formes plus tordues les unes que les autres.

Là il faudra traiter au cas par cas et écrire une fonction qui dessinera un truc flou ayant une forme précise. Heureusement, les nébuleuses diffuses ne sont pas très nombreuses.

 

PS: Tu connais le passage par valeur et par référence en C et sans doute aussi en fortran. Dans la plupart des langages c'est clairement identifié et on sait qu'on manipule une copie ou alors qu'on touche directement le paramètre. En Java c'est plus tordu.

les types simples (boolean, int...) sont toujours passés par valeur ou copie alors que les types complexes (Math.Long par exemple et tout ce qui hérite du type Object) sont toujours passés par référence.

Oui, j'ai lu ça (mais c'est parce que le nom qu'on manipule n'est pas l'objet mais son adresse, je crois) et il faut faire attention en effet. Je préfère le passage par adresse, d'ailleurs en Fortran 77 il n'y a que ça (la récursivité est donc impossible, ce qui ne m'a jamais dérangé). Puisque je vais être obligé d'utiliser des objets, au moins ils seront passés par référence, j'y suis familier.

Modifié par 'Bruno
Antiath

Antiath

Posté
Posté

Une remarque sur ActionScript : attention avec flash. C'est effectivement un gouffre à mémoire et surtout c'est loin d'être simple à maitriser. J'ai l'habitude maintenant de construire mes interfaces graphiques en C# .NET, que j'apprécie particulièrement pour son accessibilité et sa documentation bien fournie. Ma compagne travaille elle sur ActionScript et j'ai pu constaté à quel point les libraires ActionScript sont mal documentées.

 

Je rejoins aussi Pascal sur la séparation en 2 languages. Je choisirais certainement le C/C++ pour le traitement des données et je passerais les informations utiles via un wrapper vers le code d'interface graphique écrit dans un language plus adapté à cet effet.

Leimury

Leimury

Posté
Posté (modifié)

Java et C# utilise un garbage collector dont le rôle est de détruire automatiquement les objets qui sortent du "scope" du programme (objets qui ne seront plus jamais utilisés)

Mouais... en théorie.

 

D'abord ça n'est pas le scope mais plutôt le nombre de références actives.

Le scope c'est grosso modo un niveau d'accolade.

 

Math.Long truc ()

{

Math.Long a(2);

return a;

} // on est sorti du scope mais le garbagge collector ne détruira pas a si l'appelant fait un trucmuche=truc(): trucmuche ajoute une poignée

 

Autre exemple:

 

void truc(Math.Long ioV)

{

Math.Long b(2);

ioV=b;

}

 

Math.Long a(17);

truc(a); // Maintenant a vaut 2.

 

// l'objet a a été détruit au moment ou on avait ioV=b

// l'objet b a pris du gallon quand il est passé par ioV=b

// l'objet connu sous le nom de b dans la fonction est maintenant l'objet connu sous le nom de a dans ce scope: il vit sa vie hors de son scope d'instanciation parce qu'il y'a une référence dessus.

 

A chaque fois que tu as un machin=bidule ou fonc(bidule), Java incrémente un compteur de référence sur le bidule.

Donc même à la sortie du scope l'éboueur ne va pas détruire un objet puisqu'il sera encore utilisé.

ex:

 

Math.Long a(2)

 

Le compteur est décrémenté quand tu sors de la fonction ou quand le scope de machin est terminé (fin d'accolade)

Ça n'est qu'avec un compteur à zéro que le machin se retrouve dans la liste des objets à détruire.

 

Vaut mieux s'occuper des finalizers si on veut éviter les lourdeurs.

Quand tu bosses sur des fichiers, des images et autres données lourdes tu as tout intérêt à faire des finalizers car le garbagge collector a beaucoup de mal à virer certaines choses et Java se traine comme une 2cv qui monterait une pente avec une grosse caravane.

Le problème avec les images et d'autres types complexes c'est qu'il y'a pas mal de boulot derrière et qu'il y'a toujours des références qui traînent sur une partie du bignou.

Sans finalizers pour prendre en charge les deinit le garbagge collector ne pourra jamais s'en débarrasser car il y'a toujours une poignée kekpart.

 

Le Gabagge collector c'est bête et méchant, ça vaut pas l'analyse plus fine d'un développeur qui gère de beaux finalizers.

 

PS: @Leimury Java est très clair sur la problématique du mode de passage des arguments, ils se font uniquement par valeur y compris les références d'autres objets.

 

Non, le passage ne se fait pas par valeur pour les objets en Java.

Simple à vérifier:

 

void funcObj(Math.Long ioV){ioV++;}

void funcVal(long inV) {inV++;}

 

Math.Long a(2);

funcOj(a); //a vaudra 3

 

long b=2;

funcVal(B); // b restera à 2

 

Tous les objets sont passés par référence et les types simples par valeur.

 

Suffit de le savoir mais disons que c'est piégeant quand on vient du C ou du C++.

En C++ tu écris funcObj(MathLong& ioV), je trouve que c'est moins chaffouin.

Pareil quand on écrit un funcObj(MathLong* ioObj), c'est simple et c'est pareil que ce soit une classe ou un type de base.

D'un autre côté un programmeur C++ qui écrit funcObj( obj truc) était surement mal réveillé car ça devient vite lourd sur une classe :be:

 

ce qui n'est pas le cas d'autres langages comme le C/C++, où celui qui réalise le programme doit penser aussi à virer les objets au bon moment sinon gare aux fuites mémoires qui peuvent faire planter l'application au bout d'un temps ... un petit bémol avec l'API QT (C/C++) qui lorsqu'on utilise certains objets de l'API permet de s'affranchir de cette tache.

 

Eboueur or not

ça fait un peu penser à goto or not ?

ou à auto ou manuelle?

vanille ou chocolat ?

Y'a pas vraiment de mieux ou moins bien, c'est surtout une affaire de gouts.

 

Je préfère sans éboueur mais pas parce que c'est mieux, juste parce que je préfère :p

 

PS: Les bouts de source sont un peu faux dans les détails (un ++ sur un Math.Long ça doit pas le faire) mais ça suffit pour se comprendre.

PS2: Je fais surtout du C++ :p

Modifié par Leimury
pascal_meheut

pascal_meheut

Posté
Posté
Oui !

Non c'est plus simple au contraire, il n'y a rien de pire au niveau complexité et maintenabilité que de mélanger la présentation, les données et les processus qui traite ces données (les calculs ici). C'est un peu pour ça qu'on préfère utiliser des langages objets couplés à des schémas de construction éprouvés (MVC pour le web, API QT par ex) qui permettent une telle séparation car souvent dans un projet celui qui fait le design n'est pas le même que celui qui construit la base de donnée ni celui qui est en charge des calculs scientifiques ... :)

 

Ne le prends pas mal mais on n'apprends pas à un vieux singe à faire la grimace ;)

 

Ma remarque se prenait dans le contexte de Bruno qui ne s'amuserait pas forcément à faire du client/serveur classique ou Web. Je parlais d'une séparation avec moteur de calcul pur d'un coté et interface indépendante non linkée, pas d'utilisation d'un pattern dans un même langage comme MVC. D'où mes exemples d'ailleurs.

Rejoignez la conversation !

Vous pouvez répondre maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous pour poster avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
 Partager
Aller sur la liste des sujets

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.