Nouveaux langages pour la programmation des processeurs multicoeurs
Wykaaa
Chapel ou X10 pour la programmation du parall�lisme et plus
particuli�rement, la programmation des processeurs multicoeurs ?
cjps...@gmail.com
> Quelqu'un connaît-il et/ou a-t-il déjà utilisé des langages tels que
> Chapel ou X10 pour la programmation du parallélisme et plus
> particulièrement, la programmation des processeurs multicoeurs ?
Pourquoi réinventer un nouveau langage. Ceux (Ada ou java par
exemple) qui exploitent les architectures multiprocesseurs sont
portables sur les multi coeurs. J'ai recompilé un programme Ada qui
exploitait le parallélisme d'une machine SGI irix à 12 processeurs sur
une machine linux avec un processeur à huit coeurs sans rien changer.
Wykaaa
>> Chapel ou X10 pour la programmation du parall�lisme et plus
>
> Pourquoi r�inventer un nouveau langage. Ceux (Ada ou java par
> exemple) qui exploitent les architectures multiprocesseurs sont
> exploitait le parall�lisme d'une machine SGI irix � 12 processeurs sur
> une machine linux avec un processeur � huit coeurs sans rien changer.
>
Ok mais es-tu s�r que le logiciel exploite au mieux les huit coeurs ?
Si ces langages nouveaux existent pour ces architectures
multiprocesseurs/multicoeurs, il doit bien y avoir une raison.
cjps...@gmail.com
> cjpsi...@gmail.com a écrit :> On 13 juin, 12:03, Wykaaa <wyk...@yahoo.fr> wrote:
> >> Quelqu'un connaît-il et/ou a-t-il déjà utilisé des langages tels que
> >> Chapel ou X10 pour la programmation du parallélisme et plus
> >> particulièrement, la programmation des processeurs multicoeurs ?
>
> > Pourquoi réinventer un nouveau langage. Ceux (Ada ou java par
> > exemple) qui exploitent les architectures multiprocesseurs sont
> > exploitait le parallélisme d'une machine SGI irix à 12 processeurs sur
> > une machine linux avec un processeur à huit coeurs sans rien changer.
>
> Ok mais es-tu sûr que le logiciel exploite au mieux les huit coeurs ?
> Si ces langages nouveaux existent pour ces architectures
> multiprocesseurs/multicoeurs, il doit bien y avoir une raison.
Il y a un article de Robert Dewar : http://www.adaic.org/whyada/multicore.html
sur le sujet.
Pour ma part, je suis incapable de dire si on peut faire mieux ou non.
Ce que je sais pour l'avoir vérifié, c'est que les huits coeurs
étaient utilisés à 100%. Je n'ai pas eu le temps de faire les
benchmarks que j'avais fait à l'époque sur SGI.
Je ne suis pas spécialiste mais seulement utilisateur et j'ai eu
plusieurs applications à paralléliser. Dont une en fortran.
Pour celle là après avoir lorgné sur MPI et openMP, j'ai utilisé une
petite blibliothèque écrite en Ada qui permettait de lancer des appels
à des routines fortran dans des tâches Ada. Le résultat a été que
seulement 20 lignes du code fortran ont été modifiées pour un gains
atteignant 98% du parallélisme théorique. Ce qui fait 2% d'overhead.
Je n'ai pas poussé plus loin car j'avais atteint mon but et je n'avais
pas de budjet pour autre chose. J'aurais aimé explorer le super
linéaire.
Pour ce qui est de la création de nouveaux langages je crois qu'il y a
et aura toujours des gens pour réinventer la roue. Et le parallélisme
est une belle roue. Je leur conseillerais de s'intéresser à Ada car il
pourront y trouver des enseignements importants, notamment comment
gérer les exceptions dans un contexte multi-tâche. Ou encore quelles
sont les difficultés pour faire de l'optimisation d'une application
multi coeur, pour le compilateur mais aussi pour le programmeur, par
exemple gérer les problèmes de localisation des données dans les
câches. Etc... Les concepteurs d'Ada ont travaillé là dessus depuis
1980.
Ne pas oublier que le langage, son compilateur et le run-time sont
dépendants de l'OS et du hardware. Le multi-threading doit être
correctement implanté dans le système d'exploitation. Il se pose aussi
le problème du placement des threads soit de manière autoritaire sur
une plate-forme dédiée à l'application soit par affinité sur un
serveur partagé.
<Mode_dithyrambe>
L'avantage d'Ada de mon point de vue est que c'est un langage
généraliste très complet qui a évolué au cours de ses révisions
successives pour intégrer des nouveautés (programmation objet,
distribution, bibliothèques mathématiques, conteneurs, objet protégé,
interface à la java...) en les intégrant dans les traits adoptés dés
le départ (généricité, tasking, modularité, typage fort, exceptions,
interfaçage avec d'autres langages, accès au bas niveau...) tout en
gardant une compatibilité ascendante remarquable.
</Mode_dithyrambe>
Bien sûr, j'aimerais bien lui ajouter quelques nouveautés moi aussi
(par exemple : équation aux dimension et unités, boucle parallèle,
tranche de tableau multidimensionnel, extension d'énumérés...), mais
je ne vais pas définir un nouveau langage de programmation à empiler
sur la tour de Babel.
Aucun langage n'est le dernier langage. Mais avant d'entreprendre la
définition d'un nouveau langage le minimum est de regarder ce qui
existe et ce qu'il convient de modifier ou d'améliorer plutôt que
repartir de zéro. Si le but est seulement de faire du parallélisme sur
machine multi-coeur on aura un langage incomplet. Pour le moment tout
ce que j'ai vu sur le sujet (je mets de côté le parallélisme massif et
les architectures dédiées) me parait en retard d'une génération.
Wykaaa
>>>> Quelqu'un conna�t-il et/ou a-t-il d�j� utilis� des langages tels que
>>>> Chapel ou X10 pour la programmation du parall�lisme et plus
>>> Pourquoi r�inventer un nouveau langage. Ceux (Ada ou java par
>>> exemple) qui exploitent les architectures multiprocesseurs sont
>>> exploitait le parall�lisme d'une machine SGI irix � 12 processeurs sur
>>> une machine linux avec un processeur � huit coeurs sans rien changer.
>> Ok mais es-tu s�r que le logiciel exploite au mieux les huit coeurs ?
>> Si ces langages nouveaux existent pour ces architectures
>> multiprocesseurs/multicoeurs, il doit bien y avoir une raison.
>
> Il y a un article de Robert Dewar : http://www.adaic.org/whyada/multicore.html
> sur le sujet.
>
> Pour ma part, je suis incapable de dire si on peut faire mieux ou non.
> �taient utilis�s � 100%. Je n'ai pas eu le temps de faire les
> benchmarks que j'avais fait � l'�poque sur SGI.
>
> Je ne suis pas sp�cialiste mais seulement utilisateur et j'ai eu
> plusieurs applications � parall�liser. Dont une en fortran.
> Pour celle l� apr�s avoir lorgn� sur MPI et openMP, j'ai utilis� une
> petite bliblioth�que �crite en Ada qui permettait de lancer des appels
> � des routines fortran dans des t�ches Ada. Le r�sultat a �t� que
> seulement 20 lignes du code fortran ont �t� modifi�es pour un gains
> atteignant 98% du parall�lisme th�orique. Ce qui fait 2% d'overhead.
> Je n'ai pas pouss� plus loin car j'avais atteint mon but et je n'avais
> pas de budjet pour autre chose. J'aurais aim� explorer le super
> lin�aire.
>
> Pour ce qui est de la cr�ation de nouveaux langages je crois qu'il y a
> et aura toujours des gens pour r�inventer la roue. Et le parall�lisme
> est une belle roue. Je leur conseillerais de s'int�resser � Ada car il
> pourront y trouver des enseignements importants, notamment comment
> sont les difficult�s pour faire de l'optimisation d'une application
> multi coeur, pour le compilateur mais aussi pour le programmeur, par
> c�ches. Etc... Les concepteurs d'Ada ont travaill� l� dessus depuis
> 1980.
>
> Ne pas oublier que le langage, son compilateur et le run-time sont
> correctement implant� dans le syst�me d'exploitation. Il se pose aussi
> le probl�me du placement des threads soit de mani�re autoritaire sur
> une plate-forme d�di�e � l'application soit par affinit� sur un
> serveur partag�.
>
> <Mode_dithyrambe>
> L'avantage d'Ada de mon point de vue est que c'est un langage
> successives pour int�grer des nouveaut�s (programmation objet,
> distribution, biblioth�ques math�matiques, conteneurs, objet prot�g�,
> interface � la java...) en les int�grant dans les traits adopt�s d�s
> le d�part (g�n�ricit�, tasking, modularit�, typage fort, exceptions,
> interfa�age avec d'autres langages, acc�s au bas niveau...) tout en
> gardant une compatibilit� ascendante remarquable.
> </Mode_dithyrambe>
>
> Bien s�r, j'aimerais bien lui ajouter quelques nouveaut�s moi aussi
> (par exemple : �quation aux dimension et unit�s, boucle parall�le,
> tranche de tableau multidimensionnel, extension d'�num�r�s...), mais
> je ne vais pas d�finir un nouveau langage de programmation � empiler
> sur la tour de Babel.
>
> Aucun langage n'est le dernier langage. Mais avant d'entreprendre la
> existe et ce qu'il convient de modifier ou d'am�liorer plut�t que
> repartir de z�ro. Si le but est seulement de faire du parall�lisme sur
> machine multi-coeur on aura un langage incomplet. Pour le moment tout
> les architectures d�di�es) me parait en retard d'une g�n�ration.
Je connais tr�s bien Ada 83 car j'ai tremp� dans l'�criture d'un
compilateur. Le multitasking Ada et ses "rendez-vous" n'�taient pas
sp�cifi�s au mieux dans la premi�re mouture de Ada car, sur des machines
incluant les s�maphores au niveau de l'assembleur, il en fallait 2 pour
respecter les sp�cification Ada.
Cela semble s'�tre arrang� avec Ada 95 mais j'avoue qu'alors j'�tais sur
d'autres domaines.
Je suis d'accord qu'Ada est un bon langage trop m�connu ou, peut-�tre,
qui "fait peur" aux d�veloppeurs car trop contraignant mais, concernant
la gestion des multicoeurs, je ne suis pas certain qu'il soit le plus
ad�quat (mais je peux me tromper...).
Peut-�tre qu'une des solutions pour g�rer au mieux le
multithreading/multicoeurs est d'�crire en Ada, g�n�rer du bytecode et
le faire ex�cuter par la derni�re JVM de Sun qui g�re les threads en natif.
Encore faut-il que la g�n�ration Ada -> bytecode soit optimis�e pour le
multiprocesseur/multicoeur... ce qui est loin d'�tre gagn�.
cjps...@gmail.com
> cjpsi...@gmail.com a écrit :> >>>> Quelqu'un connaît-il et/ou a-t-il déjà utilisé des langages tels que
> >>>> Chapel ou X10 pour la programmation du parallélisme et plus
> >>>> particulièrement, la programmation des processeurs multicoeurs ?
> >>> Pourquoi réinventer un nouveau langage. Ceux (Ada ou java par
> >>> exemple) qui exploitent les architectures multiprocesseurs sont
> >>> exploitait le parallélisme d'une machine SGI irix à 12 processeurs sur
> >>> une machine linux avec un processeur à huit coeurs sans rien changer.
> >> Ok mais es-tu sûr que le logiciel exploite au mieux les huit coeurs ?
> >> Si ces langages nouveaux existent pour ces architectures
> >> multiprocesseurs/multicoeurs, il doit bien y avoir une raison.
>
> > Il y a un article de Robert Dewar :http://www.adaic.org/whyada/multicore.html
> > sur le sujet.
>
> > Pour ma part, je suis incapable de dire si on peut faire mieux ou non.
> > étaient utilisés à 100%. Je n'ai pas eu le temps de faire les
> > benchmarks que j'avais fait à l'époque sur SGI.
>
> > Je ne suis pas spécialiste mais seulement utilisateur et j'ai eu
> > plusieurs applications à paralléliser. Dont une en fortran.
> > Pour celle là après avoir lorgné sur MPI et openMP, j'ai utilisé une
> > petite blibliothèque écrite en Ada qui permettait de lancer des appels
> > à des routines fortran dans des tâches Ada. Le résultat a été que
> > seulement 20 lignes du code fortran ont été modifiées pour un gains
> > atteignant 98% du parallélisme théorique. Ce qui fait 2% d'overhead.
> > Je n'ai pas poussé plus loin car j'avais atteint mon but et je n'avais
> > pas de budjet pour autre chose. J'aurais aimé explorer le super
> > linéaire.
>
> > Pour ce qui est de la création de nouveaux langages je crois qu'il y a
> > et aura toujours des gens pour réinventer la roue. Et le parallélisme
> > pourront y trouver des enseignements importants, notamment comment
> > sont les difficultés pour faire de l'optimisation d'une application
> > multi coeur, pour le compilateur mais aussi pour le programmeur, par
> > 1980.
>
> > Ne pas oublier que le langage, son compilateur et le run-time sont
> > correctement implanté dans le système d'exploitation. Il se pose aussi
> > le problème du placement des threads soit de manière autoritaire sur
> > une plate-forme dédiée à l'application soit par affinité sur un
> > serveur partagé.
>
> > L'avantage d'Ada de mon point de vue est que c'est un langage
> > successives pour intégrer des nouveautés (programmation objet,
> > distribution, bibliothèques mathématiques, conteneurs, objet protégé,
> > interface à la java...) en les intégrant dans les traits adoptés dés
> > le départ (généricité, tasking, modularité, typage fort, exceptions,
> > interfaçage avec d'autres langages, accès au bas niveau...) tout en
> > gardant une compatibilité ascendante remarquable.
> > </Mode_dithyrambe>
>
> > Bien sûr, j'aimerais bien lui ajouter quelques nouveautés moi aussi
> > (par exemple : équation aux dimension et unités, boucle parallèle,
> > je ne vais pas définir un nouveau langage de programmation à empiler
> > sur la tour de Babel.
>
> > Aucun langage n'est le dernier langage. Mais avant d'entreprendre la
> > existe et ce qu'il convient de modifier ou d'améliorer plutôt que
> > machine multi-coeur on aura un langage incomplet. Pour le moment tout
>
> Je connais très bien Ada 83 car j'ai trempé dans l'écriture d'un
> compilateur. Le multitasking Ada et ses "rendez-vous" n'étaient pas
> spécifiés au mieux dans la première mouture de Ada car, sur des machines
> incluant les sémaphores au niveau de l'assembleur, il en fallait 2 pour
> respecter les spécification Ada.
> Cela semble s'être arrangé avec Ada 95 mais j'avoue qu'alors j'étais sur
> d'autres domaines.
> Je suis d'accord qu'Ada est un bon langage trop méconnu ou, peut-être,
> qui "fait peur" aux développeurs car trop contraignant mais, concernant
> la gestion des multicoeurs, je ne suis pas certain qu'il soit le plus
> Peut-être qu'une des solutions pour gérer au mieux le
> multithreading/multicoeurs est d'écrire en Ada, générer du bytecode et
> le faire exécuter par la dernière JVM de Sun qui gère les threads en natif.
> Encore faut-il que la génération Ada -> bytecode soit optimisée pour le
> multiprocesseur/multicoeur... ce qui est loin d'être gagné.
La plupart des compilos Ada basent le tasking sur les threads fournis
par l'OS (je suppose que c'est cela que veut dire natif) comme je
suppose la JVM. A l'époque de Ada83 les threads n'existaient pas
encore (je n'en avait pas encore entendu parler en tout cas).
Je ne vois pas en quoi rajouter une couche d'interprétation de
bytecode permettrait d'accélérer le programme.
Les tests que j'ai fait d'un programme Ada utilisant le multi-
processing (à base de multithreading donc) en le portant sur une
machine mono-processeur ont montré un overhead de moins de 2% entre le
programme non parallélisé et le programme parallélisé.
Je pense qu'Ada est une solution beaucoup plus facile à utiliser que
la programmation directe en C ou C++ d'une lib de type pthread. Et je
ne vois pas pourquoi ce serait moins performant. Que les appels à la
lib de thread soient générés par le compilo plutôt qu'écrits à la main
ne change rien en terme de performance. Ou bien j'ai manqué quelque
chose !
De plus j'ai remarqué, lors de mes tests, que l'utilisation
généralisée de la pile que fait Ada permettait de localiser presque
automatiquement les données dans le câche et d'en accélérer l'accès.
Dans mon équipe on a donc élaboré une technique de programmation qui
consistait à recopier une version locale des données dans la procédure
de traitement, des réaliser les calculs et de ne renvoyer les
résultats que si les calculs s'étaient bien déroulés. On gagnait sur
trois tableaux : données locales (pas de synchronisation d'accès), un
mode transactionnel sûr, et la cerise sur le gâteau un gain de
performance non négligeable, tout cela grâce à la recopie des données
et résultats ce qui aurait fait hurler tout programmeur omnubilé par
l'optimisation au niveau code machine.
Si on doit améliorer quelque chose pour le parallélisme de type
multicoeur il vaut mieux, à mon humble avis, améliorer les
bibliothèques de threads. Soit en les optimisant encore et encore soit
en faisant évoluer leur paradigme en parallèle avec une évolution du
hardware. Mais là je suis totalement incompétent. Tout ce que je sais
c'est qu'il y a trois couches qui sont visées par de possibles
évolutions : le langage + compilateur/optimiseur/run-time, l'OS et le
hardware.
Wykaaa
[snip]
>> Je connais tr�s bien Ada 83 car j'ai tremp� dans l'�criture d'un
>> compilateur. Le multitasking Ada et ses "rendez-vous" n'�taient pas
>> sp�cifi�s au mieux dans la premi�re mouture de Ada car, sur des machines
>> incluant les s�maphores au niveau de l'assembleur, il en fallait 2 pour
>> respecter les sp�cification Ada.
>> Cela semble s'�tre arrang� avec Ada 95 mais j'avoue qu'alors j'�tais sur
>> d'autres domaines.
>> Je suis d'accord qu'Ada est un bon langage trop m�connu ou, peut-�tre,
>> qui "fait peur" aux d�veloppeurs car trop contraignant mais, concernant
>> la gestion des multicoeurs, je ne suis pas certain qu'il soit le plus
>> ad�quat (mais je peux me tromper...).
>> Peut-�tre qu'une des solutions pour g�rer au mieux le
>> multithreading/multicoeurs est d'�crire en Ada, g�n�rer du bytecode et
>> le faire ex�cuter par la derni�re JVM de Sun qui g�re les threads en natif.
>> Encore faut-il que la g�n�ration Ada -> bytecode soit optimis�e pour le
>> multiprocesseur/multicoeur... ce qui est loin d'�tre gagn�.
>
> La plupart des compilos Ada basent le tasking sur les threads fournis
> par l'OS (je suppose que c'est cela que veut dire natif) comme je
> suppose la JVM. A l'�poque de Ada83 les threads n'existaient pas
> encore (je n'en avait pas encore entendu parler en tout cas).
Si, les threads existaient mais ils n'�taient pas encore "populaires".
Les diff�rentes JVM n'utilisent pas, en g�n�ral, les threads de l'OS. La
JVM r�cente de Sun, � ma connaissance, fait plut�t exception.
J'ai trouv� ceci :
-https://java-champions.dev.java.net/pdfs/sunJVM-on-intel-multicoreservers.pdf
-ch.sun.com/sunnews/events/2009/apr/adworkshop/pdf/5-1-Java-Performance.pdf
-www.intel.com/technology/architecture/downloads/quad-core-06.pdf
>
> Je ne vois pas en quoi rajouter une couche d'interpr�tation de
> bytecode permettrait d'acc�l�rer le programme.
> Les tests que j'ai fait d'un programme Ada utilisant le multi-
> processing (� base de multithreading donc) en le portant sur une
> machine mono-processeur ont montr� un overhead de moins de 2% entre le
> programme non parall�lis� et le programme parall�lis�.
Je cherche une solution portable utilisant "au mieux" une architecture
hardware multiprocesseurs/multicoeurs.
Il me semble que la JVM de Sun reste le meilleur compromis.
Reste � trouver le langage le plus "confortable pour coder et qui g�n�re
du bytecode "optimis�".
>
> Je pense qu'Ada est une solution beaucoup plus facile � utiliser que
> la programmation directe en C ou C++ d'une lib de type pthread. Et je
> ne vois pas pourquoi ce serait moins performant. Que les appels � la
> lib de thread soient g�n�r�s par le compilo plut�t qu'�crits � la main
> ne change rien en terme de performance. Ou bien j'ai manqu� quelque
> chose !
En C++, il y a la TBB mais ceci est plus sp�cifique que le bytecode.
>
> De plus j'ai remarqu�, lors de mes tests, que l'utilisation
> g�n�ralis�e de la pile que fait Ada permettait de localiser presque
> automatiquement les donn�es dans le c�che et d'en acc�l�rer l'acc�s.
>
> Dans mon �quipe on a donc �labor� une technique de programmation qui
> consistait � recopier une version locale des donn�es dans la proc�dure
> de traitement, des r�aliser les calculs et de ne renvoyer les
> r�sultats que si les calculs s'�taient bien d�roul�s. On gagnait sur
> trois tableaux : donn�es locales (pas de synchronisation d'acc�s), un
> mode transactionnel s�r, et la cerise sur le g�teau un gain de
> performance non n�gligeable, tout cela gr�ce � la recopie des donn�es
> et r�sultats ce qui aurait fait hurler tout programmeur omnubil� par
> l'optimisation au niveau code machine.
J'ai cru comprendre que c'est un peu vers quoi s'oriente la JVM de Sun.
C'est effectivement une piste int�ressante.
>
> Si on doit am�liorer quelque chose pour le parall�lisme de type
> multicoeur il vaut mieux, � mon humble avis, am�liorer les
> biblioth�ques de threads. Soit en les optimisant encore et encore soit
> en faisant �voluer leur paradigme en parall�le avec une �volution du
> hardware. Mais l� je suis totalement incomp�tent. Tout ce que je sais
> c'est qu'il y a trois couches qui sont vis�es par de possibles
> �volutions : le langage + compilateur/optimiseur/run-time, l'OS et le
> hardware.
Le probl�me des librairies, c'est qu'elles vont �tre souvent d�pendantes
d'un hardware sp�cifique et/ou d'un langage.
cjps...@gmail.com
> cjpsi...@gmail.com a écrit :> >> cjpsi...@gmail.com a écrit :> >>>> cjpsi...@gmail.com a écrit :> On 13 juin, 12:03, Wykaaa <wyk...@yahoo.fr
>
> [snip]
>
>
>
> >> Je connais très bien Ada 83 car j'ai trempé dans l'écriture d'un
> >> compilateur. Le multitasking Ada et ses "rendez-vous" n'étaient pas
> >> spécifiés au mieux dans la première mouture de Ada car, sur des machines
> >> incluant les sémaphores au niveau de l'assembleur, il en fallait 2 pour
> >> respecter les spécification Ada.
> >> d'autres domaines.
> >> Je suis d'accord qu'Ada est un bon langage trop méconnu ou, peut-être,
> >> la gestion des multicoeurs, je ne suis pas certain qu'il soit le plus
> >> Peut-être qu'une des solutions pour gérer au mieux le
> >> multithreading/multicoeurs est d'écrire en Ada, générer du bytecode et
> >> le faire exécuter par la dernière JVM de Sun qui gère les threads en natif.
> >> multiprocesseur/multicoeur... ce qui est loin d'être gagné.
>
> > La plupart des compilos Ada basent le tasking sur les threads fournis
> > par l'OS (je suppose que c'est cela que veut dire natif) comme je
> > encore (je n'en avait pas encore entendu parler en tout cas).
>
> Les différentes JVM n'utilisent pas, en général, les threads de l'OS. La
> JVM récente de Sun, à ma connaissance, fait plutôt exception.
>
Sans les threads de l'OS il me parait assez difficile de faire du
multiprocessing, car c'est l'OS qui gère l'allocation des threads sur
les processeurs ainsi que la migration des données ou des threads
selon l'affinité.
> J'ai trouvé ceci :
> -https://java-champions.dev.java.net/pdfs/sunJVM-on-intel-multicoreser...
> -ch.sun.com/sunnews/events/2009/apr/adworkshop/pdf/5-1-Java-Performance.pdf
> -www.intel.com/technology/architecture/downloads/quad-core-06.pdf
>
>
Je connais la doc Intel. Nous avons deux machines bi processeur xeon
quad core sous linux.
Sur lesquelles nous faisons du calcul scientifique.
>
> > Je ne vois pas en quoi rajouter une couche d'interprétation de
> > bytecode permettrait d'accélérer le programme.
> > Les tests que j'ai fait d'un programme Ada utilisant le multi-
> > processing (à base de multithreading donc) en le portant sur une
> > machine mono-processeur ont montré un overhead de moins de 2% entre le
> > programme non parallélisé et le programme parallélisé.
>
> Je cherche une solution portable utilisant "au mieux" une architecture
> hardware multiprocesseurs/multicoeurs.
> Il me semble que la JVM de Sun reste le meilleur compromis.
> Reste à trouver le langage le plus "confortable pour coder et qui génère
> du bytecode "optimisé".
>
Tout depend si la portabilité est au niveau du code source ou de
l'exécutable.
Mais si on doit dépendre de la JVM ou est la portabilité ?
>
>
> > Je pense qu'Ada est une solution beaucoup plus facile à utiliser que
> > la programmation directe en C ou C++ d'une lib de type pthread. Et je
> > ne vois pas pourquoi ce serait moins performant. Que les appels à la
> > lib de thread soient générés par le compilo plutôt qu'écrits à la main
> > ne change rien en terme de performance. Ou bien j'ai manqué quelque
> > chose !
>
> En C++, il y a la TBB mais ceci est plus spécifique que le bytecode.
>
Il s'agit d'une bibliothèque de haut niveau qui essaie de combler les
manques de C++ : tasking, STL thread safe...
C'est loin du bytecode effectivement. Le problème c'est la
standardisation.
>
>
> > De plus j'ai remarqué, lors de mes tests, que l'utilisation
> > généralisée de la pile que fait Ada permettait de localiser presque
> > automatiquement les données dans le câche et d'en accélérer l'accès.
>
> > Dans mon équipe on a donc élaboré une technique de programmation qui
> > consistait à recopier une version locale des données dans la procédure
> > de traitement, des réaliser les calculs et de ne renvoyer les
> > résultats que si les calculs s'étaient bien déroulés. On gagnait sur
> > trois tableaux : données locales (pas de synchronisation d'accès), un
> > mode transactionnel sûr, et la cerise sur le gâteau un gain de
> > performance non négligeable, tout cela grâce à la recopie des données
> > et résultats ce qui aurait fait hurler tout programmeur omnubilé par
> > l'optimisation au niveau code machine.
>
> J'ai cru comprendre que c'est un peu vers quoi s'oriente la JVM de Sun.
> C'est effectivement une piste intéressante.
>
>
>
> > Si on doit améliorer quelque chose pour le parallélisme de type
> > multicoeur il vaut mieux, à mon humble avis, améliorer les
> > bibliothèques de threads. Soit en les optimisant encore et encore soit
> > en faisant évoluer leur paradigme en parallèle avec une évolution du
> > hardware. Mais là je suis totalement incompétent. Tout ce que je sais
> > c'est qu'il y a trois couches qui sont visées par de possibles
> > évolutions : le langage + compilateur/optimiseur/run-time, l'OS et le
> > hardware.
>
> Le problème des librairies, c'est qu'elles vont être souvent dépendantes
> d'un hardware spécifique et/ou d'un langage.
Pas si elles sont conformes à un standard. Le compilateur GNAT utilise
je crois les librairies posix thread lorsqu'elles sont founies par
l'OS, mais peut très bien s'adapter à d'autres. On peut même choisir
la lib de thread sur certains OS. Sur machines embarquées il y a des
noyaux qui fournissent leur propre libraries. Mais là je n'y connait
pas grand chose. Dans le cas ou le langage prends en charge le
parallélisme c'est au compilateur de se débrouiller et de gérer la
dépendance avec le hardware l'OS et les librairies. C'est l'avantage
de Ada et Java mais Java à en plus à gérer une JVM.
Pour nous la portabilité doit être au niveau du code source. Le
portage consiste toujours et seulement en une recompilation. On
travaille toujours sur du standard pour ne pas passer du temps à
adapter le code quand on change de machine ou de compilo ou de version
d'OS.
Compiler de 100000 à 800000 ligne de code ce n'est pas rien.
Wykaaa
>> [snip]
>>
>>
>>
>>>> Je connais tr�s bien Ada 83 car j'ai tremp� dans l'�criture d'un
>>>> compilateur. Le multitasking Ada et ses "rendez-vous" n'�taient pas
>>>> sp�cifi�s au mieux dans la premi�re mouture de Ada car, sur des machines
>>>> incluant les s�maphores au niveau de l'assembleur, il en fallait 2 pour
>>>> respecter les sp�cification Ada.
>>>> d'autres domaines.
>>>> Je suis d'accord qu'Ada est un bon langage trop m�connu ou, peut-�tre,
>>>> la gestion des multicoeurs, je ne suis pas certain qu'il soit le plus
>>>> Peut-�tre qu'une des solutions pour g�rer au mieux le
>>>> multithreading/multicoeurs est d'�crire en Ada, g�n�rer du bytecode et
>>>> le faire ex�cuter par la derni�re JVM de Sun qui g�re les threads en natif.
>>>> multiprocesseur/multicoeur... ce qui est loin d'�tre gagn�.
>>> La plupart des compilos Ada basent le tasking sur les threads fournis
>>> par l'OS (je suppose que c'est cela que veut dire natif) comme je
>>> encore (je n'en avait pas encore entendu parler en tout cas).
>> Les diff�rentes JVM n'utilisent pas, en g�n�ral, les threads de l'OS. La
>> JVM r�cente de Sun, � ma connaissance, fait plut�t exception.
>>
>
> Sans les threads de l'OS il me parait assez difficile de faire du
> les processeurs ainsi que la migration des donn�es ou des threads
> selon l'affinit�.
C'est pour cela que, sur telle ou telle plate-forme, il ne faut pas se
"tromper" de JVM.
>
>> J'ai trouv� ceci :
>> -https://java-champions.dev.java.net/pdfs/sunJVM-on-intel-multicoreser...
>> -ch.sun.com/sunnews/events/2009/apr/adworkshop/pdf/5-1-Java-Performance.pdf
>> -www.intel.com/technology/architecture/downloads/quad-core-06.pdf
>>
>>
> Je connais la doc Intel. Nous avons deux machines bi processeur xeon
> quad core sous linux.
> Sur lesquelles nous faisons du calcul scientifique.
En Ada donc, si j'ai tout compris.
>>> Je ne vois pas en quoi rajouter une couche d'interpr�tation de
>>> bytecode permettrait d'acc�l�rer le programme.
>>> Les tests que j'ai fait d'un programme Ada utilisant le multi-
>>> processing (� base de multithreading donc) en le portant sur une
>>> machine mono-processeur ont montr� un overhead de moins de 2% entre le
>>> programme non parall�lis� et le programme parall�lis�.
>> Je cherche une solution portable utilisant "au mieux" une architecture
>> hardware multiprocesseurs/multicoeurs.
>> Il me semble que la JVM de Sun reste le meilleur compromis.
>> Reste � trouver le langage le plus "confortable pour coder et qui g�n�re
>> du bytecode "optimis�".
>>
> Tout depend si la portabilit� est au niveau du code source ou de
> l'ex�cutable.
Je souhaite une portabilit� au niveau du code source.
> Mais si on doit d�pendre de la JVM ou est la portabilit� ?
Oui mais cela me semble la moins mauvaise solution quand m�me car il y a
beaucoup d'activit� autour de ces probl�mes dans le monde Java.
>
>>
>>> Je pense qu'Ada est une solution beaucoup plus facile � utiliser que
>>> la programmation directe en C ou C++ d'une lib de type pthread. Et je
>>> ne vois pas pourquoi ce serait moins performant. Que les appels � la
>>> lib de thread soient g�n�r�s par le compilo plut�t qu'�crits � la main
>>> ne change rien en terme de performance. Ou bien j'ai manqu� quelque
>>> chose !
>> En C++, il y a la TBB mais ceci est plus sp�cifique que le bytecode.
>>
> Il s'agit d'une biblioth�que de haut niveau qui essaie de combler les
> manques de C++ : tasking, STL thread safe...
> C'est loin du bytecode effectivement. Le probl�me c'est la
> standardisation.
Tout � fait. On est d'accord.
>>
>>> De plus j'ai remarqu�, lors de mes tests, que l'utilisation
>>> g�n�ralis�e de la pile que fait Ada permettait de localiser presque
>>> automatiquement les donn�es dans le c�che et d'en acc�l�rer l'acc�s.
>>> Dans mon �quipe on a donc �labor� une technique de programmation qui
>>> consistait � recopier une version locale des donn�es dans la proc�dure
>>> de traitement, des r�aliser les calculs et de ne renvoyer les
>>> r�sultats que si les calculs s'�taient bien d�roul�s. On gagnait sur
>>> trois tableaux : donn�es locales (pas de synchronisation d'acc�s), un
>>> mode transactionnel s�r, et la cerise sur le g�teau un gain de
>>> performance non n�gligeable, tout cela gr�ce � la recopie des donn�es
>>> et r�sultats ce qui aurait fait hurler tout programmeur omnubil� par
>>> l'optimisation au niveau code machine.
>> J'ai cru comprendre que c'est un peu vers quoi s'oriente la JVM de Sun.
>> C'est effectivement une piste int�ressante.
>>
>>
>>
>>> Si on doit am�liorer quelque chose pour le parall�lisme de type
>>> multicoeur il vaut mieux, � mon humble avis, am�liorer les
>>> biblioth�ques de threads. Soit en les optimisant encore et encore soit
>>> en faisant �voluer leur paradigme en parall�le avec une �volution du
>>> hardware. Mais l� je suis totalement incomp�tent. Tout ce que je sais
>>> c'est qu'il y a trois couches qui sont vis�es par de possibles
>>> �volutions : le langage + compilateur/optimiseur/run-time, l'OS et le
>>> hardware.
>> Le probl�me des librairies, c'est qu'elles vont �tre souvent d�pendantes
>> d'un hardware sp�cifique et/ou d'un langage.
>
> Pas si elles sont conformes � un standard. Le compilateur GNAT utilise
> je crois les librairies posix thread lorsqu'elles sont founies par
> l'OS, mais peut tr�s bien s'adapter � d'autres. On peut m�me choisir
> la lib de thread sur certains OS. Sur machines embarqu�es il y a des
> noyaux qui fournissent leur propre libraries. Mais l� je n'y connait
> pas grand chose. Dans le cas ou le langage prends en charge le
> parall�lisme c'est au compilateur de se d�brouiller et de g�rer la
> d�pendance avec le hardware l'OS et les librairies. C'est l'avantage
> de Ada et Java mais Java � en plus � g�rer une JVM.
Oui mais �a s'ex�cute directement dans un navigateur. Dans mon cas, les
calculs pourraient m�me �tre r�partis sur des machines diff�rentes �
travers un "extranet".
>
> Pour nous la portabilit� doit �tre au niveau du code source. Le
> portage consiste toujours et seulement en une recompilation. On
> travaille toujours sur du standard pour ne pas passer du temps �
> adapter le code quand on change de machine ou de compilo ou de version
> d'OS.
> Compiler de 100000 � 800000 ligne de code ce n'est pas rien.
Je connais ce genre de probl�me...
Pas trop de surprises lors des recompilations malgr� toutes ces
pr�cautions ?
cjps...@gmail.com
> cjpsi...@gmail.com a écrit :> >> cjpsi...@gmail.com a écrit :> >>>> cjpsi...@gmail.com a écrit :> >>>>>> cjpsi...@gmail.com a écrit :> On 13 juin, 12:03, Wykaaa <wyk...@yahoo.fr
> >> [snip]
>
> >>>> Je connais très bien Ada 83 car j'ai trempé dans l'écriture d'un
> >>>> compilateur. Le multitasking Ada et ses "rendez-vous" n'étaient pas
> >>>> spécifiés au mieux dans la première mouture de Ada car, sur des machines
> >>>> incluant les sémaphores au niveau de l'assembleur, il en fallait 2 pour
> >>>> respecter les spécification Ada.
> >>>> d'autres domaines.
> >>>> Je suis d'accord qu'Ada est un bon langage trop méconnu ou, peut-être,
> >>>> la gestion des multicoeurs, je ne suis pas certain qu'il soit le plus
> >>>> Peut-être qu'une des solutions pour gérer au mieux le
> >>>> multithreading/multicoeurs est d'écrire en Ada, générer du bytecode et
> >>>> le faire exécuter par la dernière JVM de Sun qui gère les threads en natif.
> >>>> multiprocesseur/multicoeur... ce qui est loin d'être gagné.
> >>> La plupart des compilos Ada basent le tasking sur les threads fournis
> >>> par l'OS (je suppose que c'est cela que veut dire natif) comme je
> >>> encore (je n'en avait pas encore entendu parler en tout cas).
> >> Les différentes JVM n'utilisent pas, en général, les threads de l'OS. La
>
> > Sans les threads de l'OS il me parait assez difficile de faire du
> > les processeurs ainsi que la migration des données ou des threads
> > selon l'affinité.
>
> C'est pour cela que, sur telle ou telle plate-forme, il ne faut pas se
> "tromper" de JVM.
>
>
>
> >> -https://java-champions.dev.java.net/pdfs/sunJVM-on-intel-multicoreser...
> >> -ch.sun.com/sunnews/events/2009/apr/adworkshop/pdf/5-1-Java-Performance.pdf
> >> -www.intel.com/technology/architecture/downloads/quad-core-06.pdf
>
> > Je connais la doc Intel. Nous avons deux machines bi processeur xeon
> > quad core sous linux.
> > Sur lesquelles nous faisons du calcul scientifique.
>
> En Ada donc, si j'ai tout compris.
>
Sur cette machine on utilise, pour la partie éléments finis du calcul,
le logiciel code-aster de EDF, qui est écrit essentiellement en
fortran77, C et python.
Pour la génération des données c'est du C++. Pour l'exploitation des
résultats c'est du C++, fortran95 et Ada uniquement pour la librairie
de multithreading utilisé pour le traitement final des résultats qui
représente un calcul lourd facilement parallélisable (loi d'Amdhal
oblige).
Pour le logiciel code-aster on découpe les données pour faire des
tranches de calcul qu'on distribue sur les processeurs via un shell
script. On n'a pas le choix car on ne peut pas toucher au code source
de code-aster.
Le langage Ada est utilisé pour une application de CAO (800000 lignes
dont 95% en Ada). Pour cette application le parallélisme n'a été
utilisé que pour un algo de triangulation rapide.
> >>> Je ne vois pas en quoi rajouter une couche d'interprétation de
> >>> bytecode permettrait d'accélérer le programme.
> >>> Les tests que j'ai fait d'un programme Ada utilisant le multi-
> >>> processing (à base de multithreading donc) en le portant sur une
> >>> machine mono-processeur ont montré un overhead de moins de 2% entre le
> >>> programme non parallélisé et le programme parallélisé.
> >> Je cherche une solution portable utilisant "au mieux" une architecture
> >> hardware multiprocesseurs/multicoeurs.
> >> Il me semble que la JVM de Sun reste le meilleur compromis.
> >> Reste à trouver le langage le plus "confortable pour coder et qui génère
> >> du bytecode "optimisé".
>
> > Tout depend si la portabilité est au niveau du code source ou de
> > l'exécutable.
>
> Je souhaite une portabilité au niveau du code source.
>
> > Mais si on doit dépendre de la JVM ou est la portabilité ?
>
> Oui mais cela me semble la moins mauvaise solution quand même car il y a
> beaucoup d'activité autour de ces problèmes dans le monde Java.
>
Oui cela veut dire aussi beaucoup d'évolutions et donc des
modifications et des problèmes de portabilité.
>
>
> >>> Je pense qu'Ada est une solution beaucoup plus facile à utiliser que
> >>> la programmation directe en C ou C++ d'une lib de type pthread. Et je
> >>> ne vois pas pourquoi ce serait moins performant. Que les appels à la
> >>> lib de thread soient générés par le compilo plutôt qu'écrits à la main
> >>> ne change rien en terme de performance. Ou bien j'ai manqué quelque
> >>> chose !
> >> En C++, il y a la TBB mais ceci est plus spécifique que le bytecode.
>
> > Il s'agit d'une bibliothèque de haut niveau qui essaie de combler les
> > manques de C++ : tasking, STL thread safe...
> > C'est loin du bytecode effectivement. Le problème c'est la
> > standardisation.
>
> Tout à fait. On est d'accord.
>
>
>
>
>
> >>> De plus j'ai remarqué, lors de mes tests, que l'utilisation
> >>> généralisée de la pile que fait Ada permettait de localiser presque
> >>> automatiquement les données dans le câche et d'en accélérer l'accès.
> >>> Dans mon équipe on a donc élaboré une technique de programmation qui
> >>> consistait à recopier une version locale des données dans la procédure
> >>> de traitement, des réaliser les calculs et de ne renvoyer les
> >>> résultats que si les calculs s'étaient bien déroulés. On gagnait sur
> >>> trois tableaux : données locales (pas de synchronisation d'accès), un
> >>> mode transactionnel sûr, et la cerise sur le gâteau un gain de
> >>> performance non négligeable, tout cela grâce à la recopie des données
> >>> et résultats ce qui aurait fait hurler tout programmeur omnubilé par
> >>> l'optimisation au niveau code machine.
> >> J'ai cru comprendre que c'est un peu vers quoi s'oriente la JVM de Sun.
> >> C'est effectivement une piste intéressante.
>
> >>> Si on doit améliorer quelque chose pour le parallélisme de type
> >>> multicoeur il vaut mieux, à mon humble avis, améliorer les
> >>> bibliothèques de threads. Soit en les optimisant encore et encore soit
> >>> en faisant évoluer leur paradigme en parallèle avec une évolution du
> >>> hardware. Mais là je suis totalement incompétent. Tout ce que je sais
> >>> c'est qu'il y a trois couches qui sont visées par de possibles
> >>> évolutions : le langage + compilateur/optimiseur/run-time, l'OS et le
> >>> hardware.
> >> Le problème des librairies, c'est qu'elles vont être souvent dépendantes
> >> d'un hardware spécifique et/ou d'un langage.
>
> > Pas si elles sont conformes à un standard. Le compilateur GNAT utilise
> > je crois les librairies posix thread lorsqu'elles sont founies par
> > l'OS, mais peut très bien s'adapter à d'autres. On peut même choisir
> > la lib de thread sur certains OS. Sur machines embarquées il y a des
> > noyaux qui fournissent leur propre libraries. Mais là je n'y connait
> > pas grand chose. Dans le cas ou le langage prends en charge le
> > parallélisme c'est au compilateur de se débrouiller et de gérer la
> > dépendance avec le hardware l'OS et les librairies. C'est l'avantage
> > de Ada et Java mais Java à en plus à gérer une JVM.
>
> Oui mais ça s'exécute directement dans un navigateur. Dans mon cas, les
> calculs pourraient même être répartis sur des machines différentes à
> travers un "extranet".
>
Nous on compte utiliser le navigateur pour la saisie et le contrôle
des données ainsi que la restitution des résultats. Pas pour les
calculs. Mais pour l'instant aucun choix n'a été fait quand pour cette
partie qui devrait être sous-traitée.
>
>
> > Pour nous la portabilité doit être au niveau du code source. Le
> > portage consiste toujours et seulement en une recompilation. On
> > travaille toujours sur du standard pour ne pas passer du temps à
> > adapter le code quand on change de machine ou de compilo ou de version
> > d'OS.
> > Compiler de 100000 à 800000 ligne de code ce n'est pas rien.
>
> Je connais ce genre de problème...
> Pas trop de surprises lors des recompilations malgré toutes ces
> précautions ?
Depuis le temps on a appris à maitriser les problèmes de portabilité,
en se gardant d'utiliser les extensions et en n'utilisant que ce qui
est bien opérationnel au niveau compilation. Un gros travail de
définition de règles de programmation doit être fait en amont du
projet lorsqu'on utilise un langage qu'on ne connait pas bien. Cela a
été le cas notamment avec C++. Pour ce qui est du fortran et d'Ada il
n'y a pas de problèmes la norme est en général très bien respectée.
Pour le C++ on a eu quelques surprises sous windows avec le
compilateurs Microsoft et avec les évolutions du GCC. Pour le fortran
on a eu aussi des surprises avec le compilateurs Intel. On a fini par
ne plus utiliser que le GCC en réalisation pour tout les langages
(fortran, C++ et Ada) aussi bien sur windows que Linux. Mais par
principe on compile de temps en temps avec les autres compilateurs
pour s'assurer qu'on reste portable.
S'il n'y avait que moi ce serait Ada qui serait choisi comme langage.
Quand je vois la quantité de code C++ qu'on a produit je plains celui
qui fera la maintenance.
Wykaaa
>>>> [snip]
>>>>>> Je connais tr�s bien Ada 83 car j'ai tremp� dans l'�criture d'un
>>>>>> compilateur. Le multitasking Ada et ses "rendez-vous" n'�taient pas
>>>>>> sp�cifi�s au mieux dans la premi�re mouture de Ada car, sur des machines
>>>>>> incluant les s�maphores au niveau de l'assembleur, il en fallait 2 pour
>>>>>> respecter les sp�cification Ada.
>>>>>> d'autres domaines.
>>>>>> Je suis d'accord qu'Ada est un bon langage trop m�connu ou, peut-�tre,
>>>>>> la gestion des multicoeurs, je ne suis pas certain qu'il soit le plus
>>>>>> Peut-�tre qu'une des solutions pour g�rer au mieux le
>>>>>> multithreading/multicoeurs est d'�crire en Ada, g�n�rer du bytecode et
>>>>>> le faire ex�cuter par la derni�re JVM de Sun qui g�re les threads en natif.
>>>>>> multiprocesseur/multicoeur... ce qui est loin d'�tre gagn�.
>>>>> La plupart des compilos Ada basent le tasking sur les threads fournis
>>>>> par l'OS (je suppose que c'est cela que veut dire natif) comme je
>>>>> encore (je n'en avait pas encore entendu parler en tout cas).
>>>> Les diff�rentes JVM n'utilisent pas, en g�n�ral, les threads de l'OS. La
>>> Sans les threads de l'OS il me parait assez difficile de faire du
>>> les processeurs ainsi que la migration des donn�es ou des threads
>>> selon l'affinit�.
>> C'est pour cela que, sur telle ou telle plate-forme, il ne faut pas se
>> "tromper" de JVM.
>>
>>
>>
>>>> -https://java-champions.dev.java.net/pdfs/sunJVM-on-intel-multicoreser...
>>>> -ch.sun.com/sunnews/events/2009/apr/adworkshop/pdf/5-1-Java-Performance.pdf
>>>> -www.intel.com/technology/architecture/downloads/quad-core-06.pdf
>>> Je connais la doc Intel. Nous avons deux machines bi processeur xeon
>>> quad core sous linux.
>>> Sur lesquelles nous faisons du calcul scientifique.
>> En Ada donc, si j'ai tout compris.
>>
>
> le logiciel code-aster de EDF, qui est �crit essentiellement en
> fortran77, C et python.
>
> Pour la g�n�ration des donn�es c'est du C++. Pour l'exploitation des
> r�sultats c'est du C++, fortran95 et Ada uniquement pour la librairie
> de multithreading utilis� pour le traitement final des r�sultats qui
> repr�sente un calcul lourd facilement parall�lisable (loi d'Amdhal
> oblige).
>
> Pour le logiciel code-aster on d�coupe les donn�es pour faire des
> tranches de calcul qu'on distribue sur les processeurs via un shell
> script. On n'a pas le choix car on ne peut pas toucher au code source
> de code-aster.
>
> dont 95% en Ada). Pour cette application le parall�lisme n'a �t�
> utilis� que pour un algo de triangulation rapide.
>
>>>>> Je ne vois pas en quoi rajouter une couche d'interpr�tation de
>>>>> Les tests que j'ai fait d'un programme Ada utilisant le multi-
>>>>> machine mono-processeur ont montr� un overhead de moins de 2% entre le
>>>>> programme non parall�lis� et le programme parall�lis�.
>>>> hardware multiprocesseurs/multicoeurs.
>>>> Il me semble que la JVM de Sun reste le meilleur compromis.
>>>> du bytecode "optimis�".
>>> Tout depend si la portabilit� est au niveau du code source ou de
>>> l'ex�cutable.
>>
>>> Mais si on doit d�pendre de la JVM ou est la portabilit� ?
>> Oui mais cela me semble la moins mauvaise solution quand m�me car il y a
>> beaucoup d'activit� autour de ces probl�mes dans le monde Java.
>>
>
> Oui cela veut dire aussi beaucoup d'�volutions et donc des
> modifications et des probl�mes de portabilit�.
>
>>
>>>>> Je pense qu'Ada est une solution beaucoup plus facile � utiliser que
>>>>> la programmation directe en C ou C++ d'une lib de type pthread. Et je
>>>>> ne change rien en terme de performance. Ou bien j'ai manqu� quelque
>>>>> chose !
>>>> En C++, il y a la TBB mais ceci est plus sp�cifique que le bytecode.
>>> Il s'agit d'une biblioth�que de haut niveau qui essaie de combler les
>>> manques de C++ : tasking, STL thread safe...
>>> standardisation.
>> Tout � fait. On est d'accord.
>>
>>
>>
>>
>>
>>>>> De plus j'ai remarqu�, lors de mes tests, que l'utilisation
>>>>> g�n�ralis�e de la pile que fait Ada permettait de localiser presque
>>>>> automatiquement les donn�es dans le c�che et d'en acc�l�rer l'acc�s.
>>>>> Dans mon �quipe on a donc �labor� une technique de programmation qui
>>>>> consistait � recopier une version locale des donn�es dans la proc�dure
>>>>> de traitement, des r�aliser les calculs et de ne renvoyer les
>>>>> r�sultats que si les calculs s'�taient bien d�roul�s. On gagnait sur
>>>>> trois tableaux : donn�es locales (pas de synchronisation d'acc�s), un
>>>>> mode transactionnel s�r, et la cerise sur le g�teau un gain de
>>>>> performance non n�gligeable, tout cela gr�ce � la recopie des donn�es
>>>>> l'optimisation au niveau code machine.
>>>> J'ai cru comprendre que c'est un peu vers quoi s'oriente la JVM de Sun.
>>>>> Si on doit am�liorer quelque chose pour le parall�lisme de type
>>>>> multicoeur il vaut mieux, � mon humble avis, am�liorer les
>>>>> biblioth�ques de threads. Soit en les optimisant encore et encore soit
>>>>> en faisant �voluer leur paradigme en parall�le avec une �volution du
>>>>> hardware. Mais l� je suis totalement incomp�tent. Tout ce que je sais
>>>>> c'est qu'il y a trois couches qui sont vis�es par de possibles
>>>>> hardware.
>>>> Le probl�me des librairies, c'est qu'elles vont �tre souvent d�pendantes
>>> Pas si elles sont conformes � un standard. Le compilateur GNAT utilise
>>> je crois les librairies posix thread lorsqu'elles sont founies par
>>> la lib de thread sur certains OS. Sur machines embarqu�es il y a des
>>> noyaux qui fournissent leur propre libraries. Mais l� je n'y connait
>>> pas grand chose. Dans le cas ou le langage prends en charge le
>>> d�pendance avec le hardware l'OS et les librairies. C'est l'avantage
>>> de Ada et Java mais Java � en plus � g�rer une JVM.
>> calculs pourraient m�me �tre r�partis sur des machines diff�rentes �
>>
> Nous on compte utiliser le navigateur pour la saisie et le contr�le
> des donn�es ainsi que la restitution des r�sultats. Pas pour les
> calculs. Mais pour l'instant aucun choix n'a �t� fait quand pour cette
> partie qui devrait �tre sous-trait�e.
>
>>
>>> Pour nous la portabilit� doit �tre au niveau du code source. Le
>>> portage consiste toujours et seulement en une recompilation. On
>>> adapter le code quand on change de machine ou de compilo ou de version
>>> d'OS.
>> Je connais ce genre de probl�me...
>> Pas trop de surprises lors des recompilations malgr� toutes ces
>
> Depuis le temps on a appris � maitriser les probl�mes de portabilit�,
> en se gardant d'utiliser les extensions et en n'utilisant que ce qui
> d�finition de r�gles de programmation doit �tre fait en amont du
> projet lorsqu'on utilise un langage qu'on ne connait pas bien. Cela a
> n'y a pas de probl�mes la norme est en g�n�ral tr�s bien respect�e.
> Pour le C++ on a eu quelques surprises sous windows avec le
> on a eu aussi des surprises avec le compilateurs Intel. On a fini par
> (fortran, C++ et Ada) aussi bien sur windows que Linux. Mais par
> principe on compile de temps en temps avec les autres compilateurs
> pour s'assurer qu'on reste portable.
>
> S'il n'y avait que moi ce serait Ada qui serait choisi comme langage.
> qui fera la maintenance.
Je r�ponds globalement � l'ensemble de tes commentaires et tout d'abord
merci pour ce retour d'exp�rience.
Il est clair qu'il y a int�r�t � toujours utiliser les m�mes
compilateurs et les GCC ne sont pas les plus mauvais m�me s'il peut y
avoir des surprises lors des �volutions.
Pourquoi insistes-tu surtout sur la difficult� potentielle de
maintenance du code C++ ?
Du code C++ bien �crit (et j'en ai quand m�me vu dans l'industrie pour
des "logiciels r�els" et pas des d�monstrateurs ou des prototypes...) se
maintient assez facilement. Il faut qu'il soit tr�s bien �crit, par contre.
Cependant, j'ai remarqu� des comportements diff�rents sur des traits
pointus du langage entre diff�rents compilateurs (mais c'�tait il y a 10
ans).
Pour Ada, il devrait y avoir beaucoup moins de surprises avec les
compilateurs car il doivent impl�menter toute la norme mais rien que la
norme. J'adore Ada pour cela et on peut �crire vraiment du beau code qui
se lit comme un texte en langue naturelle (c'est ce qu'essayait de faire
Grady Booch dans ses exemples, au d�but dans sa fameuse librairie de
composants).
Je n'ai pas essay� Ada sur mon Mac pro 8-core. Peut-�tre que je devrais.
Il faut dire que, maintenant, je suis bien plus � l'aise en Java ou C++
qu'en Ada (surtout 95) que je n'ai pas beaucoup pratiqu�.
En fait j'essaie de me cantonner � Java sauf quand �a devient impossible
(ce qui est rarement le cas mais je ne programme plus que des trucs pour
moi, je suis jeune retrait�...).
cjps...@gmail.com
>
> > Depuis le temps on a appris à maitriser les problèmes de portabilité,
> > projet lorsqu'on utilise un langage qu'on ne connait pas bien. Cela a
> > n'y a pas de problèmes la norme est en général très bien respectée.
> > on a eu aussi des surprises avec le compilateurs Intel. On a fini par
> > (fortran, C++ et Ada) aussi bien sur windows que Linux. Mais par
> > principe on compile de temps en temps avec les autres compilateurs
> > pour s'assurer qu'on reste portable.
>
> > S'il n'y avait que moi ce serait Ada qui serait choisi comme langage.
> > qui fera la maintenance.
>
> Je réponds globalement à l'ensemble de tes commentaires et tout d'abord
> merci pour ce retour d'expérience.
>
> Il est clair qu'il y a intérêt à toujours utiliser les mêmes
> compilateurs et les GCC ne sont pas les plus mauvais même s'il peut y
> avoir des surprises lors des évolutions.
>
> Pourquoi insistes-tu surtout sur la difficulté potentielle de
> maintenance du code C++ ?
> des "logiciels réels" et pas des démonstrateurs ou des prototypes...) se
> maintient assez facilement. Il faut qu'il soit très bien écrit, par contre.
> Cependant, j'ai remarqué des comportements différents sur des traits
> pointus du langage entre différents compilateurs (mais c'était il y a 10
> ans).
>
> Pour Ada, il devrait y avoir beaucoup moins de surprises avec les
> norme. J'adore Ada pour cela et on peut écrire vraiment du beau code qui
> se lit comme un texte en langue naturelle (c'est ce qu'essayait de faire
> composants).
> Je n'ai pas essayé Ada sur mon Mac pro 8-core. Peut-être que je devrais.
> Il faut dire que, maintenant, je suis bien plus à l'aise en Java ou C++
> qu'en Ada (surtout 95) que je n'ai pas beaucoup pratiqué.
> En fait j'essaie de me cantonner à Java sauf quand ça devient impossible
> (ce qui est rarement le cas mais je ne programme plus que des trucs pour
Pour moi, la difficulté de maintenance du C++ est surtout dans la
lisibilité.
Il faut choisir les bonnes règles de programmation et ce n'est pas
facile, il faut
de l'expérience. La tendance (c'est ce que j'ai remarqué dans le gros
projet
auquel je participe) est d'imposer des règles qui mettent l'accent sur
le
comment plus que sur le quoi. On a ainsi une dépendance excessive à
l'implémentation du code (à mon avis). De telle sorte que si on veut
faire une
évolution de l'implémentation il faut changer beaucoup de choses.
D'autre part il y a les problèmes liés intrinsèquement à C++ :
la dépendance entre unités de compilation est textuelle et non
sémantique.
mon
avis de .
cjps...@gmail.com
Oups la réponse est partie toute seule avant la fin. Je reprends donc.
Pour moi, la difficulté de maintenance du C++ est surtout dans la
lisibilité.
Il faut choisir les bonnes règles de programmation et ce n'est pas
facile, il faut
de l'expérience. La tendance (c'est ce que j'ai remarqué dans le gros
projet
auquel je participe) est d'imposer des règles qui mettent l'accent sur
le
comment plus que sur le quoi. De telle sorte que si on veut
faire une évolution de l'implémentation il faut changer beaucoup de
choses.
D'autre part il y a les problèmes liés intrinsèquement à C++ :
-la dépendance entre unités de compilation est textuelle et non
sémantique.
-on ne peut pas compiler séparément spécification et
l'implémentation.
-on ne peut pas compiler séparément les templetes.
-on n'a pas de typage fort au niveau des types primitifs (entier,
flottant, ...).
-les énumérés ont une sémantique d'entier.
-il n'y a pas de sémantique de tableau, ce qui fait qu'on doit
passer par la
STL ou implémenter ses propres templates pour un simple tableau.
J'ai vu
beaucoup de débats sur pour ou contre la STL. Moi je l'utilise en
lui faisant
confiance (peut-être naivement). Mais il manque les tableaux à
dimension multiple
ce qui fait qu'on bricole des trucs pas très orthodoxes parfois.
-il y a une utilisation excessive de l'allocation dynamique : la
pile n'accepte que
des variables dont la taille est connue à la compilation.
Disons (encore une fois ce n'est que mon avis) que la programmation se
fait plus
dans le domaine de la solution que dans le domaine du problème. Ce qui
fait que
pour savoir ce que fait un morceau de code un effort intellectuel
important est
nécessaire pour faire une remontée sémantique. Je sais, on peut
programmer de telle
sorte que cet effort soit minimisé. Mais j'observe que le langage
n'encourage pas
trop cela et que les programmeurs non plus.
Tout cela donne une charge de travail supplémentaire pour le
programmeur de maintenance.
Enfin ce n'est que mon avis, et c'est peut-être une critique sur nos
méthodes de
développement en C++.
Je serais bientôt moi aussi retraité et n'aurais plus qu'à programmer
pour mon plaisir.
Deux domaines m'intéressent : le parallélisme et je pense aller un peu
plus loin dans ce domaine
que ce que j'ai pu faire jusqu'à présent et la robotique, mais là je
suis totalement néophyte :-)
Wykaaa
> On Jun 16, 9:05 am, "cjpsi...@gmail.com" <cjpsi...@gmail.com> wrote:
>> On Jun 16, 12:15 am, Wykaaa <wyk...@yahoo.fr> wrote:
>>
>>
>>
>>
>>
>>>> projet lorsqu'on utilise un langage qu'on ne connait pas bien. Cela a
>>>> n'y a pas de probl�mes la norme est en g�n�ral tr�s bien respect�e.
>>>> on a eu aussi des surprises avec le compilateurs Intel. On a fini par
>>>> (fortran, C++ et Ada) aussi bien sur windows que Linux. Mais par
>>>> principe on compile de temps en temps avec les autres compilateurs
>>>> pour s'assurer qu'on reste portable.
>>>> S'il n'y avait que moi ce serait Ada qui serait choisi comme langage.
>>>> qui fera la maintenance.
>>> Je r�ponds globalement � l'ensemble de tes commentaires et tout d'abord
>>> merci pour ce retour d'exp�rience.
>>> Il est clair qu'il y a int�r�t � toujours utiliser les m�mes
>>> avoir des surprises lors des �volutions.
>>> Pourquoi insistes-tu surtout sur la difficult� potentielle de
>>> maintenance du code C++ ?
>>> des "logiciels r�els" et pas des d�monstrateurs ou des prototypes...) se
>>> maintient assez facilement. Il faut qu'il soit tr�s bien �crit, par contre.
>>> pointus du langage entre diff�rents compilateurs (mais c'�tait il y a 10
>>> ans).
>>> Pour Ada, il devrait y avoir beaucoup moins de surprises avec les
>>> norme. J'adore Ada pour cela et on peut �crire vraiment du beau code qui
>>> se lit comme un texte en langue naturelle (c'est ce qu'essayait de faire
>>> composants).
>>> Je n'ai pas essay� Ada sur mon Mac pro 8-core. Peut-�tre que je devrais.
>>> Il faut dire que, maintenant, je suis bien plus � l'aise en Java ou C++
>>> qu'en Ada (surtout 95) que je n'ai pas beaucoup pratiqu�.
>>> En fait j'essaie de me cantonner � Java sauf quand �a devient impossible
>>> (ce qui est rarement le cas mais je ne programme plus que des trucs pour
>
>
> Oups la r�ponse est partie toute seule avant la fin. Je reprends donc.
>
> Pour moi, la difficult� de maintenance du C++ est surtout dans la
> lisibilit�.
> Il faut choisir les bonnes r�gles de programmation et ce n'est pas
> facile, il faut
> de l'exp�rience. La tendance (c'est ce que j'ai remarqu� dans le gros
> projet
> auquel je participe) est d'imposer des r�gles qui mettent l'accent sur
> le
> comment plus que sur le quoi. De telle sorte que si on veut
> choses.
Connais-tu ce manuel de r�gles de programmation C++ de Lockheed Martin
Corporation ?
www.research.att.com/~bs/JSF-AV-rules.pdf
>
>
> D'autre part il y a les probl�mes li�s intrins�quement � C++ :
> -la d�pendance entre unit�s de compilation est textuelle et non
> s�mantique.
> -on ne peut pas compiler s�par�ment sp�cification et
> l'impl�mentation.
> -on ne peut pas compiler s�par�ment les templetes.
> -on n'a pas de typage fort au niveau des types primitifs (entier,
> flottant, ...).
> -les �num�r�s ont une s�mantique d'entier.
> -il n'y a pas de s�mantique de tableau, ce qui fait qu'on doit
> passer par la
> STL ou impl�menter ses propres templates pour un simple tableau.
> J'ai vu
> beaucoup de d�bats sur pour ou contre la STL. Moi je l'utilise en
> lui faisant
> confiance (peut-�tre naivement). Mais il manque les tableaux �
> dimension multiple
Je ne suis pas certain qu'il faille faire une confiance aveugle � la
STL, je suis m�me plut�t certain du contraire.
> ce qui fait qu'on bricole des trucs pas tr�s orthodoxes parfois.
> -il y a une utilisation excessive de l'allocation dynamique : la
> pile n'accepte que
> des variables dont la taille est connue � la compilation.
Ok, la compilation s�par�e en C++ n'est pas une compilation
"ind�pendante" � la Ada qui reste effectivement le nec plus ultra.
Pour le reste, chaque langage � sa s�mantique...
>
> Disons (encore une fois ce n'est que mon avis) que la programmation se
> fait plus
> dans le domaine de la solution que dans le domaine du probl�me. Ce qui
> fait que
> pour savoir ce que fait un morceau de code un effort intellectuel
> important est
> n�cessaire pour faire une remont�e s�mantique. Je sais, on peut
> programmer de telle
> sorte que cet effort soit minimis�. Mais j'observe que le langage
> n'encourage pas
> trop cela et que les programmeurs non plus.
>
> Tout cela donne une charge de travail suppl�mentaire pour le
> programmeur de maintenance.
> Enfin ce n'est que mon avis, et c'est peut-�tre une critique sur nos
> m�thodes de
> d�veloppement en C++.
C++ est pratiquement ma deuxi�me langue maternelle :-)
J'ai donn� beaucoup de cours C++ en entreprise, j'ai audit� beaucoup de
code et j'ai pas mal programm� dans ce langage.
C++ est un langage extr�mement puissant � condition qu'on le ma�trise
r�ellement (ce qui demande plusieurs ann�es de pratique...).
En tout �tat de cause il requiert des m�thodes de d�veloppement tr�s
rigoureuses et des r�gles de programmation "en b�ton". C'est le propre
de tout langage de programmation puissant mais non contraignant.
Evidemment Ada est presque � l'oppos� de cela car il est contraignant
pour le programmeur mais c'�tait une exigence forte exprim�e dans le
cahier des charges du DoD � l'�poque car l'accent �tait mis sur la
lisibilit�, la fiabilit� et plus g�n�ralement tous les crit�res du g�nie
logiciel qui �tait � son z�nith dans les ann�es 80. �a a bien chang�
depuis, h�las, avec les (pseudo)concepts de l'extr�me programming qui ne
sont qu'une fumeuse tentative de formaliser la fameuse (non)m�thode bien
connue des d�buts de l'informatique qui est la m�thode dite d'essai/erreur.
>
> Je serais bient�t moi aussi retrait� et n'aurais plus qu'� programmer
> pour mon plaisir.
> Deux domaines m'int�ressent : le parall�lisme et je pense aller un peu
> plus loin dans ce domaine
> que ce que j'ai pu faire jusqu'� pr�sent et la robotique, mais l� je
> suis totalement n�ophyte :-)
La robotique est un domaine vaste. Il y a une assez forte imbrication
des dispositifs mat�riel et des logiciels. Je ne suis pas sp�cialiste
mais je suis assez fascin� par l'ing�niosit� de certains "senseurs".
cjps...@gmail.com
> Connais-tu ce manuel de règles de programmation C++ de Lockheed Martin
> Corporation ?www.research.att.com/~bs/JSF-AV-rules.pdf
Oui je connais. J'ai essayé d'en faire profiter le chef de projet.
> Je ne suis pas certain qu'il faille faire une confiance aveugle à la
> STL, je suis même plutôt certain du contraire.
>
C'est cela le problème avec C++. Quand on demande conseil on a
invariablement une réponse du type : ça il vaut mieux pas s'y fier.
Moi j'ai décidé de faire confiance à la STL sinon il fallait prendre
autre chose
comme Boost ou autre ou bien réinventer la roue.
Le chef de projet était lui aussi contre la STL au début. Mais il
fallait bien
prendre quelque chose. On n'était pas assez aguerris pour s'en passer.
J'avais eu le même problème avec Ada fin des années 80 début 90. Tout
le monde disait qu'il
ne fallait pas utiliser la généricité. Moi je l'ai utilisée à outrance
pour le plus
grand bénéfice du projet.
A partir du moment où un concept à été choisi par des gens qui
connaissent (j'ose l'espérer)
pour faire partie d'un langage je me dit que tôt ou tard les anomalies
ou disfonctionnements
seront corrigés, Jusque là j'ai eu de la chance :-)
> Ok, la compilation séparée en C++ n'est pas une compilation
> "indépendante" à la Ada qui reste effectivement le nec plus ultra.
> Pour le reste, chaque langage à sa sémantique...
Je trouve C++ très puissant. Le seul problème c'est par quel bout le
prendre pour en faire
l'apprentissage. Pour faire quelque chose de propre il faut quasiment
connaitre tout le langage.
Exemple je déclare une classe; on me dit attention aux constructeurs
par copie, si je n'en
veux pas il faut que je les déclare protégés. Et avec certains
compilateurs il faut même que
je les implémente!!!
A chaque trait du langage on a peur de se retrouver dans des
ramifications inextricables.
Il faut un certain temps pour ingurgiter tout cela.
> C++ est pratiquement ma deuxième langue maternelle :-)
> J'ai donné beaucoup de cours C++ en entreprise, j'ai audité beaucoup de
> code et j'ai pas mal programmé dans ce langage.
> C++ est un langage extrêmement puissant à condition qu'on le maîtrise
> réellement (ce qui demande plusieurs années de pratique...).
Pour moi cela fait 3 ans et ce n'est pas assez :-)
> En tout état de cause il requiert des méthodes de développement très
> rigoureuses et des règles de programmation "en béton". C'est le propre
> de tout langage de programmation puissant mais non contraignant.
> Evidemment Ada est presque à l'opposé de cela car il est contraignant
> pour le programmeur mais c'était une exigence forte exprimée dans le
> cahier des charges du DoD à l'époque car l'accent était mis sur la
> lisibilité, la fiabilité et plus généralement tous les critères du génie
> logiciel qui était à son zénith dans les années 80. Ça a bien changé
> depuis, hélas, avec les (pseudo)concepts de l'extrême programming qui ne
> sont qu'une fumeuse tentative de formaliser la fameuse (non)méthode bien
> connue des débuts de l'informatique qui est la méthode dite d'essai/erreur.
>
>
J'ai vu des trucs là dessus : même avec Ada ils se lancent là dedans.
Ce n'est pas forcément idiot. Avec Ada, on peut écrire les
spécifications et les compiler,
Il y a des outils pour faire des body vides. On peut donc quasiment
avoir un programme
exécutable depuis le début. C'est parfois le seul moyen d'avoir le
financement d'un projet.
Il faut monter quelque chose qui tourne. Il faut parfois vendre du
vide :-)
Une foi j'ai fait toutes les specifications des objets métiers en Ada,
compilé le
tout pour éliminer les erreurs et j'ai donné les fichiers sources à
l'équipe de réalisation.
Le développement n'était même pas en Ada. Ils m'ont dit bien plus tard
que c'était les
meilleurs documents qu'ils avaient eu pour le projet.
Depuis j'essaie d'avoir toujours un exécutable qui tourne. Mais ce
n'est pas pour autant
que je sacrifie les spécifications. Au contraire. Il y a plus de
travail en amont et moins en aval.
>
> La robotique est un domaine vaste. Il y a une assez forte imbrication
> des dispositifs matériel et des logiciels. Je ne suis pas spécialiste
> mais je suis assez fasciné par l'ingéniosité de certains "senseurs".
J'ai passé ma carrière à développer des logiciels servant à la
conception
et au calcul des ponts et j'ai toujours été frustré d'être éloigné de
la matière
qui était mise en oeuvre à partir de nos calculs. On a passé notre
temps à simuler :-)
C'est peut-être pour cela que je m'intéresse au matériel et à sa
combinaison avec le logiciel.
Wykaaa
>> Corporation ?www.research.att.com/~bs/JSF-AV-rules.pdf
>
> Oui je connais. J'ai essay� d'en faire profiter le chef de projet.
>
>> Je ne suis pas certain qu'il faille faire une confiance aveugle � la
>>
>
> C'est cela le probl�me avec C++. Quand on demande conseil on a
> invariablement une r�ponse du type : �a il vaut mieux pas s'y fier.
>
> Moi j'ai d�cid� de faire confiance � la STL sinon il fallait prendre
> autre chose
> comme Boost ou autre ou bien r�inventer la roue.
>
> Le chef de projet �tait lui aussi contre la STL au d�but. Mais il
> fallait bien
> prendre quelque chose. On n'�tait pas assez aguerris pour s'en passer.
J'ai connu un client qui n'utilisait pas la STL et qui a tout recod� �
sa fa�on, uniquement pour �tre portable sur tous les environnements.
>
> J'avais eu le m�me probl�me avec Ada fin des ann�es 80 d�but 90. Tout
> le monde disait qu'il
> ne fallait pas utiliser la g�n�ricit�. Moi je l'ai utilis�e � outrance
> pour le plus
> grand b�n�fice du projet.
La g�n�ricit� n'a jamais pos� de probl�me en Ada, � ma connaissance. Moi
aussi je l'ai utilis�e intensivement d�s le d�but et je m'en suis
toujours f�licit�. C'est vraiment une tr�s grande r�ussite de Ada avec
la compilation ind�pendante.
>
> A partir du moment o� un concept � �t� choisi par des gens qui
> connaissent (j'ose l'esp�rer)
> pour faire partie d'un langage je me dit que t�t ou tard les anomalies
> ou disfonctionnements
> seront corrig�s, Jusque l� j'ai eu de la chance :-)
Je n'ai pas toujours eu cette "chance" :-(
>
>> Ok, la compilation s�par�e en C++ n'est pas une compilation
>> "ind�pendante" � la Ada qui reste effectivement le nec plus ultra.
>
>> Pour le reste, chaque langage � sa s�mantique...
>
> Je trouve C++ tr�s puissant. Le seul probl�me c'est par quel bout le
> prendre pour en faire
> l'apprentissage. Pour faire quelque chose de propre il faut quasiment
> connaitre tout le langage.
Non, je ne suis pas vraiment d'accord. Cependant il m'est arriv� de
donner un cours de C++ � des gens qui avaient d�j� commenc� � programmer
(ils venaient de C). Ils m'ont dit qu'ils �taient tomb� dans tous les
pi�ges du langage que je d�crivais dans mon cours...
Mon exp�rience c'est qu'on ne peut pas se mettre � programmer en C++ en
apprenant tout seul. Il faut un bon cours au d�but pour �tre boost� et
bien comprendre le langage (et sa philosophie, car il y en a une).
>
> Exemple je d�clare une classe; on me dit attention aux constructeurs
> par copie, si je n'en
> veux pas il faut que je les d�clare prot�g�s. Et avec certains
> compilateurs il faut m�me que
> je les impl�mente!!!
Lesquels ? car il faut les d�noncer...
Pour les constructeurs de copie, c'est un peu plus compliqu� que cela.
On peut s'en dispenser si, partout o� il y a un passage par valeur d'une
instance de classe, on le remplace par un passage par r�f�rence
constante (�a devrait d'ailleurs �tre le mode de passage par d�faut des
param�tres s'il n'y avait pas ce probl�me historique de compatibilit�
ascendante avec le langage C).
Si on ne veut pas des constructeurs de copie, il faut les d�clar�s non
pas prot�g�s mais carr�ment priv�s !
Une autre r�gle qu'il faut absolument respecter c'est que si, dans les
constructeurs d'une classe, on a de l'allocation dynamique (new), alors
on DOIT fournir un constructeur de copie et surcharger l'affectation
pour cette classe (et coder r�ellement ce qu'il faut dans ces m�thodes).
>
> A chaque trait du langage on a peur de se retrouver dans des
> ramifications inextricables.
> Il faut un certain temps pour ingurgiter tout cela.
La liste de ce qu'il faut ma�triser pour commencer est assez longue mais
ne concerne quand m�me pas tout le langage.
>
>
>> C++ est pratiquement ma deuxi�me langue maternelle :-)
>> J'ai donn� beaucoup de cours C++ en entreprise, j'ai audit� beaucoup de
>> code et j'ai pas mal programm� dans ce langage.
>> C++ est un langage extr�mement puissant � condition qu'on le ma�trise
>> r�ellement (ce qui demande plusieurs ann�es de pratique...).
>
> Pour moi cela fait 3 ans et ce n'est pas assez :-)
Ca d�pend � quelle dose tu codes en C++. Au d�but de C++, Stroustrup
disait qu'il fallait entre 12 et 18 mois pour �tre autonome en C++, �
condition de coder tous les jours...
>
>> En tout �tat de cause il requiert des m�thodes de d�veloppement tr�s
>> rigoureuses et des r�gles de programmation "en b�ton". C'est le propre
>> de tout langage de programmation puissant mais non contraignant.
>> Evidemment Ada est presque � l'oppos� de cela car il est contraignant
>> pour le programmeur mais c'�tait une exigence forte exprim�e dans le
>> cahier des charges du DoD � l'�poque car l'accent �tait mis sur la
>> lisibilit�, la fiabilit� et plus g�n�ralement tous les crit�res du g�nie
>> logiciel qui �tait � son z�nith dans les ann�es 80. �a a bien chang�
>> depuis, h�las, avec les (pseudo)concepts de l'extr�me programming qui ne
>> sont qu'une fumeuse tentative de formaliser la fameuse (non)m�thode bien
>> connue des d�buts de l'informatique qui est la m�thode dite d'essai/erreur.
>>
>>
>
> J'ai vu des trucs l� dessus : m�me avec Ada ils se lancent l� dedans.
> Ce n'est pas forc�ment idiot. Avec Ada, on peut �crire les
> sp�cifications et les compiler,
> Il y a des outils pour faire des body vides. On peut donc quasiment
> avoir un programme
> ex�cutable depuis le d�but. C'est parfois le seul moyen d'avoir le
> financement d'un projet.
> Il faut monter quelque chose qui tourne. Il faut parfois vendre du
> vide :-)
C'est un grand plus de Ada. Dans mes cours Ada, j'ai toujours pr�conis�
d'�crire toutes les sp�cifications des packages et de les compiler avant
de faire les body. Je disais m�me que la compilation sans erreur des
sp�cifications terminait la phase de conception globale.
>
> Une foi j'ai fait toutes les specifications des objets m�tiers en Ada,
> compil� le
> tout pour �liminer les erreurs et j'ai donn� les fichiers sources �
> l'�quipe de r�alisation.
> Le d�veloppement n'�tait m�me pas en Ada. Ils m'ont dit bien plus tard
> que c'�tait les
> meilleurs documents qu'ils avaient eu pour le projet.
Ceci n'est pas �tonnant. C'est une excellente fa�on de faire.
>
> Depuis j'essaie d'avoir toujours un ex�cutable qui tourne. Mais ce
> n'est pas pour autant
> que je sacrifie les sp�cifications. Au contraire. Il y a plus de
> travail en amont et moins en aval.
Ca devrait �tre la r�gle dans un projet. D'ailleurs les chiffres
montrent que plus le projet est gros (en nombre de lignes de code) et
plus le % de la phase de codage diminue (en temps et en hommes.ans), cf.
le mod�le COCOMO.
[snip la fin]
cjps...@gmail.com
> J'ai connu un client qui n'utilisait pas la STL et qui a tout recodé à
> sa façon, uniquement pour être portable sur tous les environnements.
>
Oui mais quel travail, et comment connaitre tous les environnements.
C'est aux fabricants de compilateurs de connaitre leur environnement
et de
coder proprement la STL. Sinon à quoi bon la mettre dans la norme?
> > Je trouve C++ très puissant. Le seul problème c'est par quel bout le
> > prendre pour en faire
> > l'apprentissage. Pour faire quelque chose de propre il faut quasiment
> > connaitre tout le langage.
>
> Non, je ne suis pas vraiment d'accord. Cependant il m'est arrivé de
> donner un cours de C++ à des gens qui avaient déjà commencé à programmer
> (ils venaient de C). Ils m'ont dit qu'ils étaient tombé dans tous les
> pièges du langage que je décrivais dans mon cours...
> Mon expérience c'est qu'on ne peut pas se mettre à programmer en C++ en
> apprenant tout seul. Il faut un bon cours au début pour être boosté et
> bien comprendre le langage (et sa philosophie, car il y en a une).
Nous on a eu droit un cours de trois jours :-(
> > Exemple je déclare une classe; on me dit attention aux constructeurs
> > par copie, si je n'en
> > veux pas il faut que je les déclare protégés. Et avec certains
> > compilateurs il faut même que
> > je les implémente!!!
>
> Lesquels ? car il faut les dénoncer...
Le g++. Il ne résolvait pas au link.
> Pour les constructeurs de copie, c'est un peu plus compliqué que cela.
> On peut s'en dispenser si, partout où il y a un passage par valeur d'une
> instance de classe, on le remplace par un passage par référence
> constante (ça devrait d'ailleurs être le mode de passage par défaut des
> paramètres s'il n'y avait pas ce problème historique de compatibilité
> ascendante avec le langage C).
Cela on c'est imposé dans notre manuel de programmation.
> Si on ne veut pas des constructeurs de copie, il faut les déclarés non
> pas protégés mais carrément privés !
Pour faire de types limités comme en Ada ?
> Une autre règle qu'il faut absolument respecter c'est que si, dans les
> constructeurs d'une classe, on a de l'allocation dynamique (new), alors
> on DOIT fournir un constructeur de copie et surcharger l'affectation
> pour cette classe (et coder réellement ce qu'il faut dans ces méthodes).
Peut-on se passer de new en utilisant la STL pour tout ce qui est
dynamique ?
J'ai écrit un programme comme cela mais je n'ai pas vérifié si il y
avait des fuites mémoires.
Les données membres dynamiques des classes étaient implantés via la
STL. Et j'ai laissé les
constructeurs et destructeurs par défaut.
Les seuls new étaient pour les intances polymorphes.
> La liste de ce qu'il faut maîtriser pour commencer est assez longue mais
> ne concerne quand même pas tout le langage.
>
> >> C++ est un langage extrêmement puissant à condition qu'on le maîtrise
> >> réellement (ce qui demande plusieurs années de pratique...).
>
> > Pour moi cela fait 3 ans et ce n'est pas assez :-)
>
> Ca dépend à quelle dose tu codes en C++. Au début de C++, Stroustrup
> disait qu'il fallait entre 12 et 18 mois pour être autonome en C++, à
> condition de coder tous les jours...
Non je ne code pas tous les jours. Heureusement :-)
Je m'intéresse avant tout au domaine du problème et après à sa
solution
et je préfère ne coder que quand j'ai une solution ou au moins une
ébauche.
Le problème c'est que parfois la solution demande des essais et des
erreurs :-(
Surtout quand on n'est pas sur de soi quand à l'implémentation. Un
langage de
programmation offre toujours plusieurs manières de faire. Il faut
choisir la bonne.
Ce que j'essaie de faire c'est de masquer un maximum les données et
l'implémentation
pour éviter les couplages.
> C'est un grand plus de Ada. Dans mes cours Ada, j'ai toujours préconisé
> d'écrire toutes les spécifications des packages et de les compiler avant
> de faire les body. Je disais même que la compilation sans erreur des
> spécifications terminait la phase de conception globale.
>
Je suis d'accord.
Luc Hermitte
On 16 juin, 19:51, "cjpsi...@gmail.com" <cjpsi...@gmail.com> wrote:
> Peut-on se passer de new en utilisant la STL pour tout ce qui est
> dynamique ?
De new[] oui, mais pas de new. C'est même une pratique qui tend à être
préférée dans le code métier.
Pour new, la pratique qui tend à être préférée consiste à confier le
résultat à une capsule RAII.
</>
--
Luc Hermitte
Luc Hermitte
> > par copie, si je n'en veux pas il faut que je les déclare protégés.
> > Et avec certains compilateurs il faut même que je les implémente!!!
>
> Lesquels ? car il faut les dénoncer...
> Pour les constructeurs de copie, c'est un peu plus compliqué que cela.
> On peut s'en dispenser si, partout où il y a un passage par valeur d'une
> instance de classe, on le remplace par un passage par référence
> paramètres s'il n'y avait pas ce problème historique de compatibilité
> ascendante avec le langage C).
> pas protégés mais carrément privés !
> constructeurs d'une classe, on a de l'allocation dynamique (new), alors
> on DOIT fournir un constructeur de copie et surcharger l'affectation
Disons, que tout commence avec la dichotomie classe à sémantique de
valeur Vs classe à sémantique d'entité.
Avec la sémantique d'entité, par défaut il faut interdire la copie.
Parfois on peut supporter le clonage (qui est un besoin que j'ai très
rarement expérimenté).
Avec la sémantique de valeur, (par définition) on la supporte.
Quant à la Forme Canonique Orthodoxe de Coplien que tu évoques, il
faut bien garder à l'esprit qu'elle ne s'applique qu'à la sémantique
de valeur.
Si la classe est responsable d'une ressource, alors il faut la libérer
dans le destructeur, et gérer sa duplication à la main -- chose qui
par défaut est sans intérêt en sémantique d'entité.
Donc non.
Il ne faut pas définir constructeur de copie et opérateur
d'affectation dès qu'une classe est responsable d'une ressource brute.
S'y intéresser oui, les définir pas en sémantique d'entité. Dans ce
cas, on les interdit sans avoir besoin de réfléchir, ni même de
constater la présence d'une ressource brute, et on passe à la suite.
On y reviendra si pour une raison obscure on venait à découvrir un
besoin de cloner les instances de la classe.
On en revient clairement à ce qui a été dit plus tôt : le C++ est un
langage où l'on s'intéresse autant, si ce n'est plus, aux sémantiques
et autres idiomes qu'à la syntaxe. Les bonnes règles sont multiples et
relativement simples à mettre en œuvre une fois leurs fondements
compris. Toutes ne sont pas propres à ce langage : LSP, couplage
faible, Loi de Déméter, DIP, OCP, exception-safety, fonctions courtes,
etc. sont autant de principes tout aussi valables dans les autres
langages.
--
Luc Hermitte
Côme Desplats
Je viens justement de lire une interview du cr�ateur du langage Erlang
qui a l'air de bien r�pondre � cette probl�matique :
http://www.cio.com.au/article/307418/-z_programming_languages_erlang
Wykaaa
>>> par copie, si je n'en veux pas il faut que je les d�clare prot�g�s.
>>> Et avec certains compilateurs il faut m�me que je les impl�mente!!!
>> Lesquels ? car il faut les d�noncer...
>> Pour les constructeurs de copie, c'est un peu plus compliqu� que cela.
>> On peut s'en dispenser si, partout o� il y a un passage par valeur d'une
>> instance de classe, on le remplace par un passage par r�f�rence
>> constante (�a devrait d'ailleurs �tre le mode de passage par d�faut des
>> param�tres s'il n'y avait pas ce probl�me historique de compatibilit�
>> ascendante avec le langage C).
>> pas prot�g�s mais carr�ment priv�s !
>> Une autre r�gle qu'il faut absolument respecter c'est que si, dans les
>> constructeurs d'une classe, on a de l'allocation dynamique (new), alors
>> on DOIT fournir un constructeur de copie et surcharger l'affectation
>
> Disons, que tout commence avec la dichotomie classe � s�mantique de
> valeur Vs classe � s�mantique d'entit�.
> Avec la s�mantique d'entit�, par d�faut il faut interdire la copie.
> Parfois on peut supporter le clonage (qui est un besoin que j'ai tr�s
> rarement exp�riment�).
> Avec la s�mantique de valeur, (par d�finition) on la supporte.
>
> Quant � la Forme Canonique Orthodoxe de Coplien que tu �voques, il
> faut bien garder � l'esprit qu'elle ne s'applique qu'� la s�mantique
> de valeur.
> Si la classe est responsable d'une ressource, alors il faut la lib�rer
> dans le destructeur, et g�rer sa duplication � la main -- chose qui
> par d�faut est sans int�r�t en s�mantique d'entit�.
Je ne sais pas ce que tu entends par "s�mantique d'entit�". Ceci ne me
para�t pas �tre un terme consacr�. De m�me pour s�mantique de valeur...
>
> Donc non.
> Il ne faut pas d�finir constructeur de copie et op�rateur
> d'affectation d�s qu'une classe est responsable d'une ressource brute.
Je ne sais pas ce que signifie "ressource brute".
> S'y int�resser oui, les d�finir pas en s�mantique d'entit�. Dans ce
> cas, on les interdit sans avoir besoin de r�fl�chir, ni m�me de
> constater la pr�sence d'une ressource brute, et on passe � la suite.
C'est quoi la suite ?
> On y reviendra si pour une raison obscure on venait � d�couvrir un
> besoin de cloner les instances de la classe.
>
>
> On en revient clairement � ce qui a �t� dit plus t�t : le C++ est un
> langage o� l'on s'int�resse autant, si ce n'est plus, aux s�mantiques
> et autres idiomes qu'� la syntaxe.
Quand on programme, j'ose esp�rer qu'on ne s'int�resse qu'� la
s�mantique de son application et de ses objets m�tiers. la syntaxe du
langage est cens�e �tre connue :-)
Les bonnes r�gles sont multiples et
> relativement simples � mettre en �uvre une fois leurs fondements
> compris. Toutes ne sont pas propres � ce langage : LSP, couplage
> faible, Loi de D�m�ter, DIP, OCP, exception-safety, fonctions courtes,
> etc. sont autant de principes tout aussi valables dans les autres
> langages.
D'accord mais la discussion portait surtout sur C++.
Wykaaa
Merci pour ce lien.
Erlang n'est qu'une possibilit� parmi d'autres. Il faut des benchmarks.
Luc Hermitte
> > Disons, que tout commence avec la dichotomie classe à sémantique de
> > valeur Vs classe à sémantique d'entité.
> > Avec la sémantique d'entité, par défaut il faut interdire la copie.
> > Parfois on peut supporter le clonage (qui est un besoin que j'ai très
> > rarement expérimenté).
> > Avec la sémantique de valeur, (par définition) on la supporte.
>
> > Quant à la Forme Canonique Orthodoxe de Coplien que tu évoques, il
> > de valeur.
> > Si la classe est responsable d'une ressource, alors il faut la libérer
> > dans le destructeur, et gérer sa duplication à la main -- chose qui
> > par défaut est sans intérêt en sémantique d'entité.
>
> paraît pas être un terme consacré. De même pour sémantique de valeur...
Certains parlent de classes valeur ou de classes entité (ou de
sémantique de référence) (dichotomie que l'on retrouve à mi-mot dans
le AC++ si on regarde de plus près comment sont organisés les
chapitres).
Mais, ce sont bien des termes consacrés que l'on retrouve en C++. (je
te laisse chercher dans les archives de fclc++ sur entité et
valeur :P).
Rapidement, pour les valeurs on s'intéresse à l'égalité d'état et on y
adjoint la copiabilité (désolé pour le néologisme).
Pour les entités, c'est l'identité qui prime. La notion de copie n'a
plus de sens. Deux jumeaux ont beau être égaux sur bien des points,
ils n'en restent pas moins deux individus (/entités) différents. Toute
classe tirée d'une hiérarchie de classes polymorphes a implicitement,
de par la syntaxe du C++, une sémantique d'entité.
> > Donc non.
> > Il ne faut pas définir constructeur de copie et opérateur
> > d'affectation dès qu'une classe est responsable d'une ressource brute.
>
> Je ne sais pas ce que signifie "ressource brute".
N'importe quelle ressource (pointeur, socket, pot de peinture, ...)
qui n'a pas été encapsulée dans une structure RAII (auto_ptr,
shared_ptr, unique_ptr, vector, ...).
> > S'y intéresser oui, les définir pas en sémantique d'entité. Dans ce
> > cas, on les interdit sans avoir besoin de réfléchir, ni même de
> > constater la présence d'une ressource brute, et on passe à la suite.
>
> C'est quoi la suite ?
Le vrai problème que l'on a à résoudre.
Il y a quelques années, j'avais défini une hiérarchie de classes de
réseau de neurones artificiels où j'allais jusqu'à modéliser chaque
neurone (plutôt que de travailler avec des couches modélisées par des
matrices (mathématiques)). Dans la mouvance de surchargeons tout (et
sans tuteur C++ien pour me guider), j'avais défini constructeur de
copie et opérateur d'affectation (j'ai un doute pour lui maintenant
que je sais que c'est impossible) qui dupliquaient tous les neurones
et qui retissaient tous les liens. Et au final ? Je ne m'en suis
jamais servi. Aujourd'hui j'interdirai ces opérations et je passerai à
la _suite_ : c'est à dire définir les algos de propagation et
d'apprentissage, et l'utiliser dans du code "client".
> > On y reviendra si pour une raison obscure on venait à découvrir un
> > besoin de cloner les instances de la classe.
>
> > On en revient clairement à ce qui a été dit plus tôt : le C++ est un
> > langage où l'on s'intéresse autant, si ce n'est plus, aux sémantiques
> > et autres idiomes qu'à la syntaxe.
>
> Quand on programme, j'ose espérer qu'on ne s'intéresse qu'à la
> sémantique de son application et de ses objets métiers. la syntaxe du
> langage est censée être connue :-)
Je ne fais pas allusion à la sémantique de l'application, mais à des
sémantiques incontournables en C++ (valeur, entité, RAII, ...) qui
devraient certes être connues dans un monde idéal... :(
> > Les bonnes règles sont multiples et
> > relativement simples à mettre en œuvre une fois leurs fondements
> > compris. Toutes ne sont pas propres à ce langage : LSP, couplage
> > faible, Loi de Déméter, DIP, OCP, exception-safety, fonctions courtes,
> > etc. sont autant de principes tout aussi valables dans les autres
> > langages.
>
> D'accord mais la discussion portait surtout sur C++.
Pfff. J'avais essayé de recadrer avec le forum (parce qu'avec la
question initiale, cela va être dur) en rebondissant sur un message
antérieur (vu que nous ne sommes pas sur fclc++). :)
--
Luc Hermittte
Wykaaa
>>> valeur Vs classe � s�mantique d'entit�.
>>> Avec la s�mantique d'entit�, par d�faut il faut interdire la copie.
>>> Parfois on peut supporter le clonage (qui est un besoin que j'ai tr�s
>>> rarement exp�riment�).
>>> Avec la s�mantique de valeur, (par d�finition) on la supporte.
>>> Quant � la Forme Canonique Orthodoxe de Coplien que tu �voques, il
>>> de valeur.
>>> Si la classe est responsable d'une ressource, alors il faut la lib�rer
>>> dans le destructeur, et g�rer sa duplication � la main -- chose qui
>>> par d�faut est sans int�r�t en s�mantique d'entit�.
>> Je ne sais pas ce que tu entends par "s�mantique d'entit�". Ceci ne me
>
> Certains parlent de classes valeur ou de classes entit� (ou de
> s�mantique de r�f�rence) (dichotomie que l'on retrouve � mi-mot dans
> le AC++ si on regarde de plus pr�s comment sont organis�s les
> chapitres).
>
> Mais, ce sont bien des termes consacr�s que l'on retrouve en C++. (je
> te laisse chercher dans les archives de fclc++ sur entit� et
> valeur :P).
Je persiste et je signe : ces termes ne sont pas pertinents et tr�s peu
utilis�s car "confusing". Ils n'apportent rien � la "science" et Kevlin
Henney (c'est bien lui qui est � l'origine du terme "entity class" ?)
dit beaucoup de b�tises malgr� son ultra-pr�sence sur le web et dans le
domaine objet.
> Rapidement, pour les valeurs on s'int�resse � l'�galit� d'�tat et on y
> adjoint la copiabilit� (d�sol� pour le n�ologisme).
> Pour les entit�s, c'est l'identit� qui prime.
La notion de copie n'a
> plus de sens. Deux jumeaux ont beau �tre �gaux sur bien des points,
> ils n'en restent pas moins deux individus (/entit�s) diff�rents. Toute
> classe tir�e d'une hi�rarchie de classes polymorphes a implicitement,
> de par la syntaxe du C++, une s�mantique d'entit�.
Ah, tiens, voil� que la syntaxe agit sur la s�mantique maintenant. Je
croyais, na�vement sans doute, qu'on attribuait plut�t une s�mantique �
une syntaxe. ce n'est JAMAIS la syntaxe qui guide la s�mantique (sauf
les nombres de G�del mais l�, c'est autre chose, on est dans le domaine
des m�tamath�matiques).
D�cid�ment ce vocable de "s�mantique d'entit�" s�me une grande confusion
(d'ailleurs l'article "entity class" sur le Wikipedia anglais est
pratiquement orphelin, presque personne ne pointe sur lui et c'est tant
mieux !).
le concept d'objet m�tier me para�t 10000 fois plus pertinent. Le terme
"entity class" me semble vouloir rapprocher le mod�le objet du mod�le
entit�/relation , ce qui est un non-sens que font pratiquement tous les
informaticiens qui ont pratiqu� le mod�le relationnel avant l'objet.
L'approche objet est radicalement diff�rente et ne l'encombrons pas d'un
vocabulaire ambigu qui ne fait qu'obscurcir les choses.
>
>>> Donc non.
>>> Il ne faut pas d�finir constructeur de copie et op�rateur
>>> d'affectation d�s qu'une classe est responsable d'une ressource brute.
>> Je ne sais pas ce que signifie "ressource brute".
>
> N'importe quelle ressource (pointeur, socket, pot de peinture, ...)
> qui n'a pas �t� encapsul�e dans une structure RAII (auto_ptr,
> shared_ptr, unique_ptr, vector, ...).
>
>
>>> S'y int�resser oui, les d�finir pas en s�mantique d'entit�. Dans ce
>>> cas, on les interdit sans avoir besoin de r�fl�chir, ni m�me de
>>> constater la pr�sence d'une ressource brute, et on passe � la suite.
>> C'est quoi la suite ?
>
> Le vrai probl�me que l'on a � r�soudre.
> Il y a quelques ann�es, j'avais d�fini une hi�rarchie de classes de
> r�seau de neurones artificiels o� j'allais jusqu'� mod�liser chaque
> neurone (plut�t que de travailler avec des couches mod�lis�es par des
> matrices (math�matiques)). Dans la mouvance de surchargeons tout (et
> sans tuteur C++ien pour me guider), j'avais d�fini constructeur de
> copie et op�rateur d'affectation (j'ai un doute pour lui maintenant
> que je sais que c'est impossible) qui dupliquaient tous les neurones
> et qui retissaient tous les liens. Et au final ? Je ne m'en suis
> jamais servi. Aujourd'hui j'interdirai ces op�rations et je passerai �
> la _suite_ : c'est � dire d�finir les algos de propagation et
> d'apprentissage, et l'utiliser dans du code "client".
D�finir les algos rel�ve de la conception d�taill�e. Nous parlions de
sp�cifications et de conception globale...
La discussion ne se situais pas au niveau du code...
>
>
>>> On y reviendra si pour une raison obscure on venait � d�couvrir un
>>> besoin de cloner les instances de la classe.
>>> On en revient clairement � ce qui a �t� dit plus t�t : le C++ est un
>>> langage o� l'on s'int�resse autant, si ce n'est plus, aux s�mantiques
>>> et autres idiomes qu'� la syntaxe.
>> Quand on programme, j'ose esp�rer qu'on ne s'int�resse qu'� la
>> s�mantique de son application et de ses objets m�tiers. la syntaxe du
>> langage est cens�e �tre connue :-)
>
> Je ne fais pas allusion � la s�mantique de l'application, mais � des
> s�mantiques incontournables en C++ (valeur, entit�, RAII, ...) qui
> devraient certes �tre connues dans un monde id�al... :(
Nul ne nie que RAII doit �tre appliqu� strictement mais si l'on suit les
principes de base de l'objet, on est comme monsieur Jourdain, on fait du
RAII sans le savoir ;-)
>
>
>>> Les bonnes r�gles sont multiples et
>>> relativement simples � mettre en �uvre une fois leurs fondements
>>> compris. Toutes ne sont pas propres � ce langage : LSP, couplage
>>> faible, Loi de D�m�ter, DIP, OCP, exception-safety, fonctions courtes,
>>> etc. sont autant de principes tout aussi valables dans les autres
>>> langages.
>> D'accord mais la discussion portait surtout sur C++.
>
> Pfff. J'avais essay� de recadrer avec le forum (parce qu'avec la
> question initiale, cela va �tre dur) en rebondissant sur un message
> ant�rieur (vu que nous ne sommes pas sur fclc++). :)
Oui c'est s�r qu'on est loin du sujet initial, quoique...
Luc Hermitte
> > On 17 juin, 14:15, Wykaaa <wyk...@yahoo.fr> wrote:
> >>> valeur Vs classe à sémantique d'entité.
> >>> Avec la sémantique d'entité, par défaut il faut interdire la copie.
> >>> Parfois on peut supporter le clonage (qui est un besoin que j'ai très
> >>> rarement expérimenté).
> >>> Avec la sémantique de valeur, (par définition) on la supporte.
> >>> Quant à la Forme Canonique Orthodoxe de Coplien que tu évoques, il
> >>> de valeur.
> >>> Si la classe est responsable d'une ressource, alors il faut la libérer
> >>> dans le destructeur, et gérer sa duplication à la main -- chose qui
> >>> par défaut est sans intérêt en sémantique d'entité.
> >> Je ne sais pas ce que tu entends par "sémantique d'entité". Ceci ne me
> >> paraît pas être un terme consacré. De même pour sémantique de valeur...
>
> > Certains parlent de classes valeur ou de classes entité (ou de
> > le AC++ si on regarde de plus près comment sont organisés les
> > chapitres).
>
> > Mais, ce sont bien des termes consacrés que l'on retrouve en C++. (je
> > te laisse chercher dans les archives de fclc++ sur entité et
> > valeur :P).
>
> Je persiste et je signe : ces termes ne sont pas pertinents et très peu
> utilisés car "confusing". Ils n'apportent rien à la "science" et Kevlin
> Henney (c'est bien lui qui est à l'origine du terme "entity class" ?)
> dit beaucoup de bêtises malgré son ultra-présence sur le web et dans le
> domaine objet.
Les concepts, si ce n'est les termes, sont plus vieux que son article.
Du moins c'est ce que me fait dire le message #135 et suivants ici vu
l'âge du livre de J.O. Coplien :
http://www.developpez.net/forums/redirect-to/?redirect=http%3A%2F%2Fgroups.google.com%2Fgroup%2Ffr.comp.lang.c%2B%2B%2Fbrowse_frm%2Fthread%2F4c44a082f5bd0cf1%2Fafc5641bd310a0ce%3Fhl%3Den%26q%3Dforme%2Bcanonique%2Borthodoxe%2Bkanze%2Bfclc%252B%252B%23afc5641bd310a0ce
Le titre du chapitre 12 de AC++ "Making class objects act like values"
a tendance à me renforcer dans cette dichotomie. Aussi scolaire et
artificielle soit-elle, j'arrive à l'appliquer à l'essentiel de mes
classes.
Je retrouve "value semantics" dans Extended STL (OK, l'auteur une
approche autre pour beaucoup de choses).
Prenons Stepanov. Dans son /Element of Programming/ (qu'il a
malheureusement retiré de son site, il semblerait qu'il faille
obligatoirement investir dans son livre maintenant), je lis p19:
----------
* A value is an abstract idea (logical or mathematical) such as false
or 2 or a geometrical point
* An entity is an idea of a thing such as a car or an email message
- An entity has attributes with values, such as job level or salary
of
an employee
- An entity can be composed of other entities called parts, such
as the engine of a car or the body of an email message
- An entity can be in relationships with other entities, such as
the supervisor of an employee
* An activity is an idea of changes performed on entities that
changes their attributes or creates new entities, such as
promoting a given employee
-----
Dans /C++ Standard Library: A Tutorial and Reference/ de 1999 (bien
avant l'article de Henney), § 5.10.2 "Value Semantics or Reference
Semantics".
Certes, une fois on va parler de reference, l'autre d'entité. Mais les
termes sont bien plus ancrés au C++ que ce que tu l'as remarqué. Est-
ce que maintenant c'est resté trop confiné à clc++m/fclc++ et chez
Addisson-Wesley? C'est possible, je ne saurais le dire.
> > La notion de copie n'a
> > plus de sens. Deux jumeaux ont beau être égaux sur bien des points,
> > ils n'en restent pas moins deux individus (/entités) différents. Toute
> > classe tirée d'une hiérarchie de classes polymorphes a implicitement,
> > de par la syntaxe du C++, une sémantique d'entité.
>
> Ah, tiens, voilà que la syntaxe agit sur la sémantique maintenant. Je
> croyais, naïvement sans doute, qu'on attribuait plutôt une sémantique à
> une syntaxe. ce n'est JAMAIS la syntaxe qui guide la sémantique (sauf
> les nombres de Gödel mais là, c'est autre chose, on est dans le domaine
> des métamathématiques).
C'est un "effet de bord" du C++. Je savais que je passais trop vite là
dessus.
Rendre affectable une classe tirée d'une hiérarchie relève de la haute
voltige en C++ : cf les deux contournements que sont l'idiome
enveloppe-lettre et le mini-framework pour rendre /Regular/ des objets
(article de Stépanov et/ou Sean Parent chez Adobe). En prenant la
"définition" de "un type valeur est copiable, affectable, et
comparable (!= ordonnable)" on arrive au point où la syntaxe fait que
la sémantique de valeur est difficilement compatible avec ces classes
tirées de hiérarchies.
Maintenant, ce n'est pas un problème car dans les faits, en présence
de hiérarchie, on manipule quasi systématiquement des entités en C++.
Nous n'y sommes pas poussés à dériver systématiquement d'un type
Object. D'où le raccourci.
> Décidément ce vocable de "sémantique d'entité" sème une grande confusion
> (d'ailleurs l'article "entity class" sur le Wikipedia anglais est
> pratiquement orphelin, presque personne ne pointe sur lui et c'est tant
> mieux !).
En effet il n'y a rien sur les divers termes associés. Tant mieux ? Je
ne pense pas. Cela nous protègerait des règles qualité bâclées qui
stipulent que toute classe devrait suivre la Forme Canonique Orthodoxe
de Coplien (FCOdC) sans se soucier des conditions d'applicabilité.
> le concept d'objet métier me paraît 10000 fois plus pertinent.
La partie métier est très importante, tout à fait. Cependant, au
moment où on s'occupe de la mise en œuvre, on finit par se retrouver
dans l'espace du langage. Et dans cet espace, il y a des règles
simples qui apportent de la robustesse au code [en gros le cœur de la
discussion au moment où je suis intervenu]. Ranger nos types dans
l'une des deux familles (quand applicable) est un gain majeur.
> Le terme
> "entity class" me semble vouloir rapprocher le modèle objet du modèle
> entité/relation, ce qui est un non-sens que font pratiquement tous les
> informaticiens qui ont pratiqué le modèle relationnel avant l'objet.
> L'approche objet est radicalement différente et ne l'encombrons pas d'un
> vocabulaire ambigu qui ne fait qu'obscurcir les choses.
Le choix du terme n'est peut être pas heureux. C'est possible. Ta
remarque va dans la direction de l'omniprésence de "reference
semantics" chez nos amis anglo-saxons. Personnellement, je trouve que
le terme est trop bas niveau, et qu'il ne met pas suffisamment
l'accent sur l'aspect identitaire.
De plus, la dichotomie est bien là, en particulier en C++ où on peut
avoir des valeurs dénuées de vie et qui sont définies par le biais de
classes, et des entités qui vivent et qui ont des comportements et qui
sont aussi définies grâce à des classes.
> > Le vrai problème que l'on a à résoudre.
> > Il y a quelques années, j'avais défini une hiérarchie de classes de
> > réseau de neurones artificiels où j'allais jusqu'à modéliser chaque
> > neurone (plutôt que de travailler avec des couches modélisées par des
> > matrices (mathématiques)). Dans la mouvance de surchargeons tout (et
> > sans tuteur C++ien pour me guider), j'avais défini constructeur de
> > copie et opérateur d'affectation (j'ai un doute pour lui maintenant
> > que je sais que c'est impossible) qui dupliquaient tous les neurones
> > et qui retissaient tous les liens. Et au final ? Je ne m'en suis
> > jamais servi. Aujourd'hui j'interdirai ces opérations et je passerai à
> > la _suite_ : c'est à dire définir les algos de propagation et
> > d'apprentissage, et l'utiliser dans du code "client".
>
> Définir les algos relève de la conception détaillée. Nous parlions de
> spécifications et de conception globale...
> La discussion ne se situais pas au niveau du code...
Hum ...
Tout de même, quand on parle des pièges du C++ et de la pertinence de
partir sur la FCOdC en présence d'un membre pointeur, ou des passages
d'arguments par référence constante, nous sommes à un niveau bien plus
détaillé que celui de la mise en œuvre des algorithmes.
--
Luc Hermitte
Wykaaa
>>> On 17 juin, 14:15, Wykaaa <wyk...@yahoo.fr> wrote:
>>>>> valeur Vs classe � s�mantique d'entit�.
>>>>> Avec la s�mantique d'entit�, par d�faut il faut interdire la copie.
>>>>> Parfois on peut supporter le clonage (qui est un besoin que j'ai tr�s
>>>>> rarement exp�riment�).
>>>>> Avec la s�mantique de valeur, (par d�finition) on la supporte.
>>>>> Quant � la Forme Canonique Orthodoxe de Coplien que tu �voques, il
>>>>> de valeur.
>>>>> Si la classe est responsable d'une ressource, alors il faut la lib�rer
>>>>> dans le destructeur, et g�rer sa duplication � la main -- chose qui
>>>>> par d�faut est sans int�r�t en s�mantique d'entit�.
>>>> Je ne sais pas ce que tu entends par "s�mantique d'entit�". Ceci ne me
>>>> para�t pas �tre un terme consacr�. De m�me pour s�mantique de valeur...
>>> Certains parlent de classes valeur ou de classes entit� (ou de
>>> s�mantique de r�f�rence) (dichotomie que l'on retrouve � mi-mot dans
>>> chapitres).
>>> Mais, ce sont bien des termes consacr�s que l'on retrouve en C++. (je
>>> te laisse chercher dans les archives de fclc++ sur entit� et
>>> valeur :P).
>> Je persiste et je signe : ces termes ne sont pas pertinents et tr�s peu
>> Henney (c'est bien lui qui est � l'origine du terme "entity class" ?)
>> dit beaucoup de b�tises malgr� son ultra-pr�sence sur le web et dans le
>> domaine objet.
>
> Les concepts, si ce n'est les termes, sont plus vieux que son article.
> Du moins c'est ce que me fait dire le message #135 et suivants ici vu
> http://www.developpez.net/forums/redirect-to/?redirect=http%3A%2F%2Fgroups.google.com%2Fgroup%2Ffr.comp.lang.c%2B%2B%2Fbrowse_frm%2Fthread%2F4c44a082f5bd0cf1%2Fafc5641bd310a0ce%3Fhl%3Den%26q%3Dforme%2Bcanonique%2Borthodoxe%2Bkanze%2Bfclc%252B%252B%23afc5641bd310a0ce
Oui et la discussion �tait assez "fumeuse"...
>
> Le titre du chapitre 12 de AC++ "Making class objects act like values"
> a tendance � me renforcer dans cette dichotomie. Aussi scolaire et
> artificielle soit-elle, j'arrive � l'appliquer � l'essentiel de mes
> classes.
Oui tout �a, excuse-moi, est relativement superficiel. Pour faire des
classes correctes, ce n'est pas tr�s difficile. Il faut :
- analyser le domaine et identifier les processus m�tiers
- les processus m�tiers sont d�composables en services m�tiers (ceci
introduit la SOA). Les processus m�tiers sont donc des orchestrateurs de
services et un processus m�tier est lui-m�me une classe (dans son
impl�mentation)
- Ces services m�tiers utilisent les m�thodes d'objets m�tiers en les
orchestrant
- Les objets m�tiers sont des cat�gories au sens de Grady Booch
- Les objets m�tiers sont donc des ensembles de classes faisant parti
d'un ou plusieurs "packages"
- Et pour finir, les classes sont impl�ment�es selon les 4 concepts
majeurs de l'approche objet : abstraction (en s'inspirant de travaux
ant�rieurs � l'objet que sont les ADT (Abstract Data Types) au sens de
John Guttag/Barbara Liskov, modularit� (au sens objet), encapsulation
bas�e sur les 2 principes de forte coh�sion interne et faible couplage
et enfin hi�rarchie (agr�gation, composition et h�ritage).
On peut essay� de raffiner ceci par tous les termes que l'on veut mais
si on respecte ce qui est d�crit ci-dessus, on n'aura pas de grandes
surprises, y compris pour les �volutions si on respecte, en plus, les
patterns MVC, DAO pour l'ind�pendance vis-�-vis des bases de donn�es
(qu'elles soient relationnelles, objet ou XML), factory (abstraite,
�tendue et "controller") et Fa�ade + un certain nombre d'autres en
fonction des sp�cificit�s de l'application.
>
> Je retrouve "value semantics" dans Extended STL (OK, l'auteur une
> approche autre pour beaucoup de choses).
>
> Prenons Stepanov. Dans son /Element of Programming/ (qu'il a
> malheureusement retir� de son site, il semblerait qu'il faille
> obligatoirement investir dans son livre maintenant), je lis p19:
> ----------
> * A value is an abstract idea (logical or mathematical) such as false
> or 2 or a geometrical point
> * An entity is an idea of a thing such as a car or an email message
> - An entity has attributes with values, such as job level or salary
> of
> an employee
> - An entity can be composed of other entities called parts, such
> as the engine of a car or the body of an email message
> - An entity can be in relationships with other entities, such as
> the supervisor of an employee
Une entit� est donc un objet m�tier au sens o� je l'ai indiqu�.
> * An activity is an idea of changes performed on entities that
> changes their attributes or creates new entities, such as
> promoting a given employee
Les modificateurs dans le vocabulaire objet.
> -----
>
> Dans /C++ Standard Library: A Tutorial and Reference/ de 1999 (bien
> avant l'article de Henney), � 5.10.2 "Value Semantics or Reference
> Semantics".
>
> Certes, une fois on va parler de reference, l'autre d'entit�. Mais les
> termes sont bien plus ancr�s au C++ que ce que tu l'as remarqu�. Est-
> ce que maintenant c'est rest� trop confin� � clc++m/fclc++ et chez
> Addisson-Wesley? C'est possible, je ne saurais le dire.
R�f�rence et valeur sont des termes ambigus car ils sont utilis�s � la
fois dans le cadre du passage de param�tres (et pas seulement en C++) et
en UML avec la distinction agr�gation/composition.
>
>>> La notion de copie n'a
>>> plus de sens. Deux jumeaux ont beau �tre �gaux sur bien des points,
>>> ils n'en restent pas moins deux individus (/entit�s) diff�rents. Toute
>>> classe tir�e d'une hi�rarchie de classes polymorphes a implicitement,
>>> de par la syntaxe du C++, une s�mantique d'entit�.
Le probl�me n'est pas l�, � mon sens, tout d�pend de la s�mantique des
objets m�tiers.
>> Ah, tiens, voil� que la syntaxe agit sur la s�mantique maintenant. Je
>> croyais, na�vement sans doute, qu'on attribuait plut�t une s�mantique �
>> une syntaxe. ce n'est JAMAIS la syntaxe qui guide la s�mantique (sauf
>> les nombres de G�del mais l�, c'est autre chose, on est dans le domaine
>> des m�tamath�matiques).
>
> C'est un "effet de bord" du C++. Je savais que je passais trop vite l�
> dessus.
> Rendre affectable une classe tir�e d'une hi�rarchie rel�ve de la haute
> voltige en C++ : cf les deux contournements que sont l'idiome
> enveloppe-lettre et le mini-framework pour rendre /Regular/ des objets
> (article de St�panov et/ou Sean Parent chez Adobe). En prenant la
> "d�finition" de "un type valeur est copiable, affectable, et
> comparable (!= ordonnable)" on arrive au point o� la syntaxe fait que
> la s�mantique de valeur est difficilement compatible avec ces classes
> tir�es de hi�rarchies.
Oui type priv� versus type priv� limit� en ADA.
>
> Maintenant, ce n'est pas un probl�me car dans les faits, en pr�sence
> de hi�rarchie, on manipule quasi syst�matiquement des entit�s en C++.
> Nous n'y sommes pas pouss�s � d�river syst�matiquement d'un type
> Object. D'o� le raccourci.
>
>> D�cid�ment ce vocable de "s�mantique d'entit�" s�me une grande confusion
>> (d'ailleurs l'article "entity class" sur le Wikipedia anglais est
>> pratiquement orphelin, presque personne ne pointe sur lui et c'est tant
>> mieux !).
>
> En effet il n'y a rien sur les divers termes associ�s. Tant mieux ? Je
> ne pense pas. Cela nous prot�gerait des r�gles qualit� b�cl�es qui
> stipulent que toute classe devrait suivre la Forme Canonique Orthodoxe
> de Coplien (FCOdC) sans se soucier des conditions d'applicabilit�.
Seules les classes dont les constructeurs font de l'allocation dynamique
devraient respecter la FCOdC.
>
>> le concept d'objet m�tier me para�t 10000 fois plus pertinent.
>
> La partie m�tier est tr�s importante, tout � fait. Cependant, au
> moment o� on s'occupe de la mise en �uvre, on finit par se retrouver
> dans l'espace du langage. Et dans cet espace, il y a des r�gles
> simples qui apportent de la robustesse au code [en gros le c�ur de la
> discussion au moment o� je suis intervenu]. Ranger nos types dans
> l'une des deux familles (quand applicable) est un gain majeur.
Sauf que ce n'est pas la bonne approche dans une optique d'architecture
de services (SOA) car trop dichotomique justement.
>
>
>> Le terme
>> "entity class" me semble vouloir rapprocher le mod�le objet du mod�le
>> entit�/relation, ce qui est un non-sens que font pratiquement tous les
>> informaticiens qui ont pratiqu� le mod�le relationnel avant l'objet.
>> L'approche objet est radicalement diff�rente et ne l'encombrons pas d'un
>> vocabulaire ambigu qui ne fait qu'obscurcir les choses.
>
> Le choix du terme n'est peut �tre pas heureux. C'est possible. Ta
> remarque va dans la direction de l'omnipr�sence de "reference
> semantics" chez nos amis anglo-saxons. Personnellement, je trouve que
> le terme est trop bas niveau, et qu'il ne met pas suffisamment
> l'accent sur l'aspect identitaire.
Je pr�f�re 100 fois le terme anglo-saxons mais il est vrai que j'ai
plut�t cette culture dans le domaine informatique �tant membre de l'IEEE
et de l'ACM.
>
> De plus, la dichotomie est bien l�, en particulier en C++ o� on peut
> avoir des valeurs d�nu�es de vie et qui sont d�finies par le biais de
> classes, et des entit�s qui vivent et qui ont des comportements et qui
> sont aussi d�finies gr�ce � des classes.
Toutes les classes ont des comportements (au sens objet du terme, i.e.
il y a des m�thodes). Une classe sans m�thode ne sert � rien.
>
>>> Le vrai probl�me que l'on a � r�soudre.
>>> Il y a quelques ann�es, j'avais d�fini une hi�rarchie de classes de
>>> r�seau de neurones artificiels o� j'allais jusqu'� mod�liser chaque
>>> neurone (plut�t que de travailler avec des couches mod�lis�es par des
>>> matrices (math�matiques)). Dans la mouvance de surchargeons tout (et
>>> sans tuteur C++ien pour me guider), j'avais d�fini constructeur de
>>> copie et op�rateur d'affectation (j'ai un doute pour lui maintenant
>>> que je sais que c'est impossible) qui dupliquaient tous les neurones
>>> et qui retissaient tous les liens. Et au final ? Je ne m'en suis
>>> jamais servi. Aujourd'hui j'interdirai ces op�rations et je passerai �
>>> la _suite_ : c'est � dire d�finir les algos de propagation et
>>> d'apprentissage, et l'utiliser dans du code "client".
>> D�finir les algos rel�ve de la conception d�taill�e. Nous parlions de
>> sp�cifications et de conception globale...
>> La discussion ne se situais pas au niveau du code...
>
> Hum ...
> Tout de m�me, quand on parle des pi�ges du C++ et de la pertinence de
> partir sur la FCOdC en pr�sence d'un membre pointeur, ou des passages
> d'arguments par r�f�rence constante, nous sommes � un niveau bien plus
> d�taill� que celui de la mise en �uvre des algorithmes.
Pas du tout, ce sont des probl�mes qui doivent forc�ment �tre r�gl�s �
la fin de la conception globale (elle devrait �tre compilable).
Wykaaa
PS : cette discussion est vraiment tr�s int�ressante.
cjps...@gmail.com
> > > La notion de copie n'a
> > > plus de sens. Deux jumeaux ont beau être égaux sur bien des points,
> > > ils n'en restent pas moins deux individus (/entités) différents. Toute
Pourquoi ne pas dire identité ?
> > > classe tirée d'une hiérarchie de classes polymorphes a implicitement,
> > > de par la syntaxe du C++, une sémantique d'entité.
On ne pourrait pas avoir une hiérarchie de classes à sémantique de
valeur ?
> Rendre affectable une classe tirée d'une hiérarchie relève de la haute
> voltige en C++ : cf les deux contournements que sont l'idiome
> enveloppe-lettre et le mini-framework pour rendre /Regular/ des objets
> (article de Stépanov et/ou Sean Parent chez Adobe). En prenant la
> "définition" de "un type valeur est copiable, affectable, et
> comparable (!= ordonnable)" on arrive au point où la syntaxe fait que
> la sémantique de valeur est difficilement compatible avec ces classes
> tirées de hiérarchies.
Imaginons une classe abstraite dont les descendants sont des objets
géométriques de base : point, segment, carré, cercle, etc...à
sémantique de valeur. Cela permet le polymorphisme.
Et la copie est autorisée. Qu'est-ce qui est choquant là dedans ?
> ne pense pas. Cela nous protègerait des règles qualité bâclées qui
> stipulent que toute classe devrait suivre la Forme Canonique Orthodoxe
> de Coplien (FCOdC) sans se soucier des conditions d'applicabilité.
>
> > le concept d'objet métier me paraît 10000 fois plus pertinent.
>
> La partie métier est très importante, tout à fait. Cependant, au
> moment où on s'occupe de la mise en œuvre, on finit par se retrouver
> dans l'espace du langage. Et dans cet espace, il y a des règles
> simples qui apportent de la robustesse au code [en gros le cœur de la
> discussion au moment où je suis intervenu]. Ranger nos types dans
> l'une des deux familles (quand applicable) est un gain majeur.
>
Je crois qu'il y a deux niveaux sémantiques très différents qui sont
abordés et que
la difficulté est de bien les séparer dans le discourt : Il y a les
objets métiers, valeur, entité ou autres et leur implémentation. On
peut implémenter un objet à sémantique de valeur avec des membres qui
sont des références. Il faut alors prévoir d'implémenter la sémantique
de valeur dans les opérateurs. Ce n'est pas le fait d'avoir une
référence en donnée membre qui fait la différence . C'est la
sémantique de l'objet qui conduit l'implémentation.
Comment dit-on en UML : l'agrégation forte ?
> > Le terme
> > "entity class" me semble vouloir rapprocher le modèle objet du modèle
> > entité/relation, ce qui est un non-sens que font pratiquement tous les
> > informaticiens qui ont pratiqué le modèle relationnel avant l'objet.
> > L'approche objet est radicalement différente et ne l'encombrons pas d'un
> > vocabulaire ambigu qui ne fait qu'obscurcir les choses.
>
> Le choix du terme n'est peut être pas heureux. C'est possible. Ta
> remarque va dans la direction de l'omniprésence de "reference
> semantics" chez nos amis anglo-saxons. Personnellement, je trouve que
> le terme est trop bas niveau, et qu'il ne met pas suffisamment
> l'accent sur l'aspect identitaire.
Entièrement d'accord. Parce qu'on ne parle pas de la même chose si on
se situe
au niveau métier ou au niveau implémentation.
Le terme référence est problématique. On peut parler de pointeur,
d'accès ou d'adresse. Mais un nom de fichier a aussi une sémantique de
référence.
> De plus, la dichotomie est bien là, en particulier en C++ où on peut
> avoir des valeurs dénuées de vie et qui sont définies par le biais de
> classes, et des entités qui vivent et qui ont des comportements et qui
> sont aussi définies grâce à des classes.
>
La différence entre la (ma) montre et l'heure du déjeuner :-)
>
> > Définir les algos relève de la conception détaillée. Nous parlions de
> > spécifications et de conception globale...
> > La discussion ne se situais pas au niveau du code...
>
> Hum ...
> Tout de même, quand on parle des pièges du C++ et de la pertinence de
> partir sur la FCOdC en présence d'un membre pointeur, ou des passages
> d'arguments par référence constante, nous sommes à un niveau bien plus
> détaillé que celui de la mise en œuvre des algorithmes.
>
C'est toute la difficulté du discourt sur le langage : à quel niveau
sémantique on se situe?
Et quand on fait la conception on doit prendre en compte les
possibilités du langage de programmation.
Luc Hermitte
> On 17 juin, 19:17, Luc Hermitte <luc.hermi...@gmail.com> wrote:
>
> > > > La notion de copie n'a
> > > > plus de sens. Deux jumeaux ont beau être égaux sur bien des points,
> > > > ils n'en restent pas moins deux individus (/entités) différents. Toute
>
> Pourquoi ne pas dire identité ?
Hum ... Bonne question. Pour ne pas me répéter? (avec des trucs que
j'ai dis ailleurs ou que j'avais en tête...)
Et effectivement, le but est de différencier égalité d'identité (qui
reste un terme flou que certains emploient pour désigner aussi
l'égalité). Tout cela me rappelle ces interminables articles relatifs
au Java sur comment définir isEqual()
> > > > classe tirée d'une hiérarchie de classes polymorphes a implicitement,
> > > > de par la syntaxe du C++, une sémantique d'entité.
> On ne pourrait pas avoir une hiérarchie de classes à sémantique de
> valeur ?
Difficilement. La syntaxe du C++ ne nous aide pas. Dans la sémantique
de valeur, on s'attend à un opérateur d'affectation fonctionnel. Cf
plus bas pour l'exemple.
Si on ignore l'aspect affectable et classes manipulées par valeur (+/-
sur la pile ou syntaxiquement équivalent), on peut se concentrer sur
l'aspect comparable qui est sémantiquement le plus intéressant, je
pense. Mais là on sort de la manipulation typique du C++ à mettre des
new là où on arrive à les éviter.
> > Rendre affectable une classe tirée d'une hiérarchie relève de la haute
> > voltige en C++ : cf les deux contournements que sont l'idiome
> > enveloppe-lettre et le mini-framework pour rendre /Regular/ des objets
> > (article de Stépanov et/ou Sean Parent chez Adobe). En prenant la
> > "définition" de "un type valeur est copiable, affectable, et
> > comparable (!= ordonnable)" on arrive au point où la syntaxe fait que
> > la sémantique de valeur est difficilement compatible avec ces classes
> > tirées de hiérarchies.
>
> Imaginons une classe abstraite dont les descendants sont des objets
> géométriques de base : point, segment, carré, cercle, etc...à
> sémantique de valeur. Cela permet le polymorphisme.
> Et la copie est autorisée. Qu'est-ce qui est choquant là dedans ?
Comment définir, en C++ :
Square mySquare;
Shape r = mySquare;
?
Déjà Shape ne peut plus être abstrait. Ensuite, il faut sortir soit
l'idoine enveloppe-lettre, soit le mini framework de Stepanov et/ou
Parent pour rendre /Regular/ des objets.
La sémantique de valeur a une connotation forte en C++ : copiable
(facile), affectable (l'enfer sur les hiérarchies), comparable (pas le
plus gros problème, cf la littérature Java qui n'a d'autres choix que
de se poser cette question)
Après il y a l'autre gros problème du LSP avec un tel exemple...
> > De plus, la dichotomie est bien là, en particulier en C++ où on peut
> > avoir des valeurs dénuées de vie et qui sont définies par le biais de
> > classes, et des entités qui vivent et qui ont des comportements et qui
> > sont aussi définies grâce à des classes.
>
> La différence entre la (ma) montre et l'heure du déjeuner :-)
Oui.
--
Luc Hermitte
Luc Hermitte
> > En effet il n'y a rien sur les divers termes associés. Tant mieux ? Je
> > stipulent que toute classe devrait suivre la Forme Canonique Orthodoxe
>
> Seules les classes dont les constructeurs font de l'allocation dynamique
> devraient respecter la FCOdC.
On paye alors un prix prohibitif pour une chose qui en pratique ne
devrait jamais servir dans des cas pourtant très simples à
reconnaitre. C'est une chose que j'avais apprise en payant le prix
fort (cf mon exemple de duplication de RdNA).
Le débutant que l'on pousse vers le support de la FCOdC (parce
qu'écrit en dur dans des règles qualités) va alors perdre du temps
pour :
- définir un truc qui en pratique ne sert pas
- réaliser un code facilement buggué (savoir réaliser des copies
exception-safe est une chose peu connue, et pourtant "relativement"
simple dans l'essentiel des cas, ou alors d'une énorme compléxité (re-
cf l'exemple de mon réseau de neurones artificiels))
- permettre au compilateur de compiler du code qui sera lent : i.e.
prendre des paramètres par copie alors qu'ils auraient dû être pris
par référence constante (il n'y a pas de [in] en C++ ...:( )
- permettre du slicing dans des hiérarchies, soit un bug bien sournois
qui arrive vite à la première évolution dans une hiérarchie -- sans
parler de l'enfer pour mettre en œuvre une affectation fonctionnelle.
La solution a tous ces problèmes est très simple : interdire la copie
(et l'affectation) -- je ne considère pas l'interdiction de copie
comme un cas particulier de mise en œuvre de la FCOdC. Serait-ce une
des sources de notre différence de point de vu ?
Et la règle la plus simple pour conclure avec un "on interdit la
copie" que je connaisse, c'est de regarder comment on compare deux
objets : égalité d'état => copiable ; identité des individus => non
copiable.
> Sauf que ce n'est pas la bonne approche dans une optique d'architecture
> de services (SOA) car trop dichotomique justement.
Beaucoup de choix sont dichotomiques. Sémantique de nombres/entités
mathématiques ? Copiable / pas copiable ? Pile / tas ?
> > De plus, la dichotomie est bien là, en particulier en C++ où on peut
> > avoir des valeurs dénuées de vie et qui sont définies par le biais de
> > classes, et des entités qui vivent et qui ont des comportements et qui
> > sont aussi définies grâce à des classes.
>
> Toutes les classes ont des comportements (au sens objet du terme, i.e.
> il y a des méthodes). Une classe sans méthode ne sert à rien.
Je ne qualifie pas de comportement les fonctions comme operator+
(Matrix, Matrix). Je sais que ce n'est pas le bon terme. Pour les
fonctions qui ne modifient pas l'état des objets sur lesquels elles
s'appliquent, on utilise un autre terme. Reste qu'il y a ici une
différence suffisamment remarquable pour être exploitée.
--
Luc Hermitte
Wykaaa
>>> stipulent que toute classe devrait suivre la Forme Canonique Orthodoxe
>> Seules les classes dont les constructeurs font de l'allocation dynamique
>> devraient respecter la FCOdC.
>
> On paye alors un prix prohibitif pour une chose qui en pratique ne
> reconnaitre. C'est une chose que j'avais apprise en payant le prix
> fort (cf mon exemple de duplication de RdNA).
>
> qu'�crit en dur dans des r�gles qualit�s) va alors perdre du temps
> pour :
> - d�finir un truc qui en pratique ne sert pas
> - r�aliser un code facilement buggu� (savoir r�aliser des copies
> exception-safe est une chose peu connue, et pourtant "relativement"
> cf l'exemple de mon r�seau de neurones artificiels))
> - permettre au compilateur de compiler du code qui sera lent : i.e.
> par r�f�rence constante (il n'y a pas de [in] en C++ ...:( )
Je suis d'accord, et je l'ai d�j� dit, que le mode de passage par d�faut
des param�tres en C++ devrait �tre par r�f�rence constante. Pour le
constructeur de copie c'est plus subtil � cause de l'initialisation
d'instances constantes.
> - permettre du slicing dans des hi�rarchies, soit un bug bien sournois
> qui arrive vite � la premi�re �volution dans une hi�rarchie -- sans
> parler de l'enfer pour mettre en �uvre une affectation fonctionnelle.
Ceci est vrai principalement quand on utilise l'h�ritage multiple qui
devrait �tre BANNIT de toute conception et impl�mentation. Ce n'est pas
pour rien que Java ne supporte pas l'h�ritage multiple (et surtout qu'on
ne me dise pas, comme la majorit� de la litt�rature le consid�re
pourtant, que l'h�ritage d'interfaces en Java permet de "simuler"
l'h�ritage multiple. Ceux qui disent ceci n'ont rien compris au r�le des
interfaces en Java).
>
> La solution a tous ces probl�mes est tr�s simple : interdire la copie
> (et l'affectation) -- je ne consid�re pas l'interdiction de copie
> comme un cas particulier de mise en �uvre de la FCOdC. Serait-ce une
> des sources de notre diff�rence de point de vu ?
Il faut la mettre en oeuvre, �ventuellement pour l'interdire (dans ce
cas, on d�finira l'op�rateur d'affectation et le constructeur de copie
dans la partie priv�e de la classe et ils seront vides ( { } ).
Si on ne d�finit pas ces op�rateurs, ils auront de toutes fa�on un
comportement par d�faut ("bitwise copy") qui peut conduire � des
catastrophes (en particulier lors du passage d'une instance par valeur).
>
> Et la r�gle la plus simple pour conclure avec un "on interdit la
> copie" que je connaisse, c'est de regarder comment on compare deux
> objets : �galit� d'�tat => copiable ; identit� des individus => non
> copiable.
??? (car copiable, clonable, morceau partiel de m�moire partag�e par des
objets, persistence ??).
>
>
>
>> Sauf que ce n'est pas la bonne approche dans une optique d'architecture
>> de services (SOA) car trop dichotomique justement.
>
> Beaucoup de choix sont dichotomiques. S�mantique de nombres/entit�s
> math�matiques ? Copiable / pas copiable ? Pile / tas ?
Je parlais de la dichotomie valeur/entit�. Ce n'est pas si simple.
Il n'y a pas de dichotomie pile/tas (c'est une fausse dichotomie) car ce
choix d�pend du contexte et de l'utilisation. Il y a �galement les
instances constantes qui peuvent, suivant les compilateurs, n'�tre ni
dans la pile, ni dans le tas mais allou�es dans un segment m�moire,
�ventuellement "non �crivible".
Il y a d'ailleurs des logiciels o� toute manipulation de la pile (pas de
variable locale) ET allocation sur le tas sont bannies (il n'y a pas de
variable cr��e � l'ex�cution, tout est statique, comme dans le bon vieux
Fortran IV), les logiciels embarqu�s pour le guidage de missile, par
exemple.
>
>
>>> De plus, la dichotomie est bien l�, en particulier en C++ o� on peut
>>> avoir des valeurs d�nu�es de vie et qui sont d�finies par le biais de
>>> classes, et des entit�s qui vivent et qui ont des comportements et qui
>>> sont aussi d�finies gr�ce � des classes.
C'est quoi des valeurs d�nu�es de vie ? fais-tu r�f�rence aux langages
fonctionnels (dont Miranda est un des plus pur repr�sentant) sans
affectation ou � assignation unique ?
>> Toutes les classes ont des comportements (au sens objet du terme, i.e.
>> il y a des m�thodes). Une classe sans m�thode ne sert � rien.
>
> Je ne qualifie pas de comportement les fonctions comme operator+
> (Matrix, Matrix). Je sais que ce n'est pas le bon terme. Pour les
> fonctions qui ne modifient pas l'�tat des objets sur lesquels elles
> s'appliquent, on utilise un autre terme. Reste qu'il y a ici une
> diff�rence suffisamment remarquable pour �tre exploit�e.
Les fonctions qui ne modifient pas l'�tat de l'objet sont appel�es
s�lecteur ou accesseur suivant les auteurs (elles font, malgr� tout,
partie de sont comportement car un attribut priv� qui n'a pas
d'accesseur ne peut pas �tre "lu").
Les op�rateurs surcharg�s font bien parti du comportement de l'objet (au
sens objet de conception donc classe) puisque chaque op�rateur peut �tre
fourni ou non (c'est donc un choix de comportement de l'objet).