 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Gabriel Dos Reis
Guest
|
|
| Back to top |
|
 |
Marc Boyer
Guest
|
 Posted: Tue Mar 22, 2005 3:07 pm Post subject: Re: Pre-Lillehammer mailing |
 |
|
In article <m3d5ttnlm8.fsf (AT) merlin (DOT) cs.tamu.edu>, Gabriel Dos Reis wrote:
Intéressant.
Je fais un petit résumé partial du N1778 "Modules in C++", Daveed Vandevoorde
En ce qui concerne les modules, la volonté de ne pas rajouter
de mot clef donne une syntaxe déroutante (mais peut-être que
je m'y ferais).
namespace >> MaLib {
// Code de ma lib
}
namespace << MaLib; // Utilisation de MaLib
// Remplacement de #include "MaLib"
Par defaut, tout ce qui est dans une librairie est privé,
sauf ce qui est précédé d'export.
Il n'y a pas a priori de différence entre la spécification et
l'implémentation, mais on peut couper un module en partie, et
l'usage devrait faire la distinction. Ca donnerait
namespace >> MaLib["hdr"] {
// Spec
}
namespace >> MaLib["imp"] {
// Code
}
La question des inline semble gérée, mais j'ai pas eut le temps
de lire les détails.
Tout cela irait plutot dans le bon sens (AMHA).
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
|
|
| Back to top |
|
|
Marc Boyer
Guest
|
| Posted: Tue Mar 22, 2005 3:27 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
Gabriel Dos Reis wrote:
Quelques remarques sur les différents papiers (moins précis que
mon autre post).
N1776 "Decimal Types for C++" Robert Klarer
Pas bien compris la proposition. J'ai du lire trop vite. Mais
si j'ai bien compris, on aurait des types décimaux conformes
à la norme "IEEE-754R". Ca devrait éviter des débats pour savoir
pourquoi à 17,58 euros de l'heure, une heure n'est pas facturée
17,58 mais 17,579...
Je me disais que C++ pouvait plutot offrir un type où le
nombre de décimales était un paramètre template (pour avoir
2 décimales dans ma compta, 3 pour l'essence, 5 pour EDF...).
Enfin bon, je suis pas spécialiste du domaine.
N1773 "Proposal to add Contract Programming to C++" D. Abrahams,
L. Crowl, T. Ottosen, J. Widman
Préconditions, postconditions, invariant de type. Rien que du bon.
J'aurais aimé voir une possibilité d'activer/désactiver finement
certaines vérifications, mais je suppose que ça relevera des options
du compilateur.
Sinon, j'ai été un rien déçu de pas voir de suite de N1758 "Concepts
for C++0x" J. Siek, D. Gregor et al. mais mieux vaut une bonne
solution qui se fai attendre qu'une mauvaise vite baclée.
Marc Boyer
--
Je ne respecte plus le codeoA de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
|
|
| Back to top |
|
|
Jean-Marc Bourguet
Guest
|
| Posted: Tue Mar 22, 2005 3:43 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
| Quote: | N1776 "Decimal Types for C++" Robert Klarer
Pas bien compris la proposition. J'ai du lire trop vite. Mais
si j'ai bien compris, on aurait des types décimaux conformes
à la norme "IEEE-754R". Ca devrait éviter des débats pour savoir
pourquoi à 17,58 euros de l'heure, une heure n'est pas facturée
17,58 mais 17,579...
|
A part que c'est des flottants donc avec les pertes non signalees qui
vont avec. Je n'ai toujours pas compris l'interet des flottants
decimaux.
| Quote: | Je me disais que C++ pouvait plutot offrir un type où le nombre de
décimales était un paramètre template (pour avoir 2 décimales dans
ma compta, 3 pour l'essence, 5 pour EDF...). Enfin bon, je suis pas
spécialiste du domaine.
|
Plutot que le nombre de decimales, je ferais une classe de rationnel a
denominateur constant. Le pb est de specifier la multiplication
(c'est possible en imposant que le type du resultat ait pour
denominateur le produit des denominateurs) et la division (c'est plus
complexe). Pour une approche, voir
http://www.adaic.org/standards/95lrm/html/RM-G-2-3.html
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
|
|
| Back to top |
|
|
Marc Boyer
Guest
|
| Posted: Tue Mar 22, 2005 3:53 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
In article <pxbfyynptya.fsf (AT) news (DOT) bourguet.org>, Jean-Marc Bourguet wrote:
| Quote: | Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
N1776 "Decimal Types for C++" Robert Klarer
Pas bien compris la proposition. J'ai du lire trop vite. Mais
si j'ai bien compris, on aurait des types décimaux conformes
à la norme "IEEE-754R". Ca devrait éviter des débats pour savoir
pourquoi à 17,58 euros de l'heure, une heure n'est pas facturée
17,58 mais 17,579...
A part que c'est des flottants donc avec les pertes non signalees qui
vont avec. Je n'ai toujours pas compris l'interet des flottants
decimaux.
|
J'avais lu trop vite (en fait, je suis pas allé voir la norme IEEE-754R).
| Quote: | Je me disais que C++ pouvait plutot offrir un type où le nombre de
décimales était un paramètre template (pour avoir 2 décimales dans
ma compta, 3 pour l'essence, 5 pour EDF...). Enfin bon, je suis pas
spécialiste du domaine.
Plutot que le nombre de decimales, je ferais une classe de rationnel a
denominateur constant.
|
Eternel débat de la généralisation... Est-ce qu'il existera beaucoup
d'instanciation avec un dénominateur qui ne soit une puissance de 10 ?
De toute façon, une telle classe doit etre conçue comme une
implémentation de base, de manière à ce que les comportements
puissent être particularisés pour les applications.
Faire ça sans payer le cout de fonctions virtuelle est
surement possible en C++.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
|
|
| Back to top |
|
|
Jean-Marc Bourguet
Guest
|
| Posted: Tue Mar 22, 2005 4:03 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
| Quote: | In article <pxbfyynptya.fsf (AT) news (DOT) bourguet.org>, Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
N1776 "Decimal Types for C++" Robert Klarer
Pas bien compris la proposition. J'ai du lire trop vite. Mais
si j'ai bien compris, on aurait des types décimaux conformes
à la norme "IEEE-754R". Ca devrait éviter des débats pour savoir
pourquoi à 17,58 euros de l'heure, une heure n'est pas facturée
17,58 mais 17,579...
A part que c'est des flottants donc avec les pertes non signalees qui
vont avec. Je n'ai toujours pas compris l'interet des flottants
decimaux.
J'avais lu trop vite (en fait, je suis pas allé voir la norme IEEE-754R).
|
J'en ai lu des avants projets. L'aspect interessant dont je me
souviens etait l'analyse de la representation avec les 3 facteurs
- la capacite a recuperer les ALU de calculs binaires
- la possibilite d'une conversion facile en decimale
- la compacite de l'encodage (4 bits par chiffre,
10 bits pour 3 chiffres, ...)
| Quote: | Je me disais que C++ pouvait plutot offrir un type où le nombre de
décimales était un paramètre template (pour avoir 2 décimales dans
ma compta, 3 pour l'essence, 5 pour EDF...). Enfin bon, je suis pas
spécialiste du domaine.
Plutot que le nombre de decimales, je ferais une classe de rationnel a
denominateur constant.
Eternel débat de la généralisation... Est-ce qu'il existera beaucoup
d'instanciation avec un dénominateur qui ne soit une puissance de 10 ?
|
J'ai un copain qui fait du traitement du signal. Il utiliserait les
puissances de 2 a tout casser. Les autres cas seront
vraissemblablement annectotiques effectivement.
Mais ici, ma proposition etait plutot basee sur le fait que j'ai fait
du calcul en virgule fixe dans une autre vie. J'ai souvenir avoir eu
besoin du denominateur, pas du nombre de decimales.
L'aspect transformation en representation decimale peut pousser vers
une representation telle que ci-dessus et alors mon idee du
denominateur n'est peut-etre pas bonne. Comme il n'y a que deux bases
a considerer, 2 classes vaudraient peut-etre mieux.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Tue Mar 22, 2005 5:00 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
| Quote: | Gabriel Dos Reis wrote:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-03
Quelques remarques sur les différents papiers (moins précis que
mon autre post).
N1776 "Decimal Types for C++" Robert Klarer
Pas bien compris la proposition. J'ai du lire trop vite. Mais
si j'ai bien compris, on aurait des types décimaux conformes
à la norme "IEEE-754R". Ca devrait éviter des débats pour savoir
pourquoi à 17,58 euros de l'heure, une heure n'est pas facturée
17,58 mais 17,579...
Je me disais que C++ pouvait plutot offrir un type où le
nombre de décimales était un paramètre template (pour avoir
2 décimales dans ma compta, 3 pour l'essence, 5 pour EDF...).
Enfin bon, je suis pas spécialiste du domaine.
N1773 "Proposal to add Contract Programming to C++" D. Abrahams,
L. Crowl, T. Ottosen, J. Widman
Préconditions, postconditions, invariant de type. Rien que du bon.
J'aurais aimé voir une possibilité d'activer/désactiver finement
certaines vérifications, mais je suppose que ça relevera des options
du compilateur.
|
Ce qui m'inquiète, c'est la tournure que ça prend. Je n'ai pas vu
d'explications claires sur les problèmes fondamentaux que la
proposition essaie de résoudre, quelle est leur fréquence, leur
contournement dans le langage actuel et ses coût.
| Quote: | Sinon, j'ai été un rien déçu de pas voir de suite de N1758 "Concepts
for C++0x" J. Siek, D. Gregor et al. mais mieux vaut une bonne
solution qui se fai attendre qu'une mauvaise vite baclée.
|
Hmmm. Il y a beaucoup de choses à dire sur ce papier et je ne crois
pas être bien placé pour faire ce job.
Il y a une suite (en train d'être écrite en ce moment même), plus
précisemment une suite aux papiers de 2002. Nous n'avions jamais eu le
temps de la finir avant la date butoire. Normalement, elle était censéea
être finie pour ce matin mais nous avons tous des « daytime jobs » qui
parfois placent des contraintes sur ce que nous pouvons faire « à côté
». Il ne reste plus qu'a fignoler quelques menus détails et c'est emballé.
Je regrette que la proposition d'Indiana soit trop compliquée -- et
que cela provoque des résistances aux concepts quelque soit ce qui est
proposé par la suite. Je regrette aussi que la proposition d'Indiana
n'est pas fait la part des choses dans les papiers de 2002.
-- Gaby
|
|
| Back to top |
|
|
Marc Boyer
Guest
|
| Posted: Tue Mar 22, 2005 5:10 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
Gabriel Dos Reis wrote:
| Quote: | Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
[SNIP Decimal]
| N1773 "Proposal to add Contract Programming to C++" D. Abrahams,
| L. Crowl, T. Ottosen, J. Widman
|
| Préconditions, postconditions, invariant de type. Rien que du bon.
| J'aurais aimé voir une possibilité d'activer/désactiver finement
| certaines vérifications, mais je suppose que ça relevera des options
| du compilateur.
Ce qui m'inquiète, c'est la tournure que ça prend. Je n'ai pas vu
d'explications claires sur les problèmes fondamentaux que la
proposition essaie de résoudre, quelle est leur fréquence, leur
contournement dans le langage actuel et ses coût.
|
Je sais que j'aimerais ce support dans mon usage personnel
de développeur, mais de là à généraliser à "problème fréquent",
je ne sais pas.
Je fais tout dans la doc (Doxygen) + assert. Ca unifierait la chose.
| Quote: | | Sinon, j'ai été un rien déçu de pas voir de suite de N1758 "Concepts
| for C++0x" J. Siek, D. Gregor et al. mais mieux vaut une bonne
| solution qui se fai attendre qu'une mauvaise vite baclée.
Hmmm. Il y a beaucoup de choses à dire sur ce papier et je ne crois
pas être bien placé pour faire ce job.
|
J'avais déjà donné mon avis dans
<792a8d3f.0502150646.7ae992c0 (AT) posting (DOT) google.com>
| Quote: | Il y a une suite (en train d'être écrite en ce moment même), plus
précisemment une suite aux papiers de 2002. Nous n'avions jamais eu le
temps de la finir avant la date butoire. Normalement, elle était censéea
être finie pour ce matin mais nous avons tous des « daytime jobs » qui
parfois placent des contraintes sur ce que nous pouvons faire « à côté
». Il ne reste plus qu'a fignoler quelques menus détails et c'est emballé.
|
Bon, je l'attends avec envie.
| Quote: | Je regrette que la proposition d'Indiana soit trop compliquée -- et
que cela provoque des résistances aux concepts quelque soit ce qui est
proposé par la suite. Je regrette aussi que la proposition d'Indiana
n'est pas fait la part des choses dans les papiers de 2002.
|
"Indiana" n'évoque rien pour moi. Il me manque un bout
du contexte.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Tue Mar 22, 2005 5:38 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
[...]
| Quote: | | Sinon, j'ai été un rien déçu de pas voir de suite de N1758 "Concepts
| for C++0x" J. Siek, D. Gregor et al. mais mieux vaut une bonne
| solution qui se fai attendre qu'une mauvaise vite baclée.
Hmmm. Il y a beaucoup de choses à dire sur ce papier et je ne crois
pas être bien placé pour faire ce job.
J'avais déjà donné mon avis dans
[email]792a8d3f.0502150646.7ae992c0 (AT) posting (DOT) google.com[/email]
|
OK. Je suis très en retard en ce qui concerne fclc++.
[...]
| Quote: | Je regrette que la proposition d'Indiana soit trop compliquée -- et
que cela provoque des résistances aux concepts quelque soit ce qui est
proposé par la suite. Je regrette aussi que la proposition d'Indiana
n'est pas fait la part des choses dans les papiers de 2002.
"Indiana" n'évoque rien pour moi. Il me manque un bout
du contexte.
|
Les auteurs du papier sont ou étaient des gens du « Open Systems
Laboratory » de l'Indiana University, Bloomington (ville de l'état
d'Indiana, USA).
-- Gaby
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Tue Mar 22, 2005 8:41 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
Jean-Marc Bourguet wrote:
| Quote: | Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
N1776 "Decimal Types for C++" Robert Klarer
Pas bien compris la proposition. J'ai du lire trop vite.
Mais si j'ai bien compris, on aurait des types décimaux
conformes à la norme "IEEE-754R". Ca devrait éviter des débats
pour savoir pourquoi à 17,58 euros de l'heure, une heure n'est
pas facturée 17,58 mais 17,579...
A part que c'est des flottants donc avec les pertes non
signalees qui vont avec. Je n'ai toujours pas compris
l'interet des flottants decimaux.
|
Toutes les raisons qui poussent à utiliser les flottants
ailleurs, avec le plus que les arrondies suivent les règles
juridiques de la comptabilité.
Évidemment, ce n'est intéressant que s'il y a suffisamment de
chiffres de précision. (Dans l'application sur laquelle je
travaille actuellement, on travaille aux dix millièmes d'Euro,
pour des montants qui peuvent facillement dépasser les cent
milles Euros, voire plus. Alors, la précision « classique » de
treize chiffres suffira.)
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Tue Mar 22, 2005 8:52 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
Marc Boyer wrote:
| Quote: | Gabriel Dos Reis wrote:
Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
| N1773 "Proposal to add Contract Programming to C++" D. Abrahams,
| L. Crowl, T. Ottosen, J. Widman
| Préconditions, postconditions, invariant de type. Rien que
| du bon. J'aurais aimé voir une possibilité
| d'activer/désactiver finement certaines vérifications, mais
| je suppose que ça relevera des options du compilateur.
Ce qui m'inquiète, c'est la tournure que ça prend. Je n'ai pas
vu d'explications claires sur les problèmes fondamentaux que
la proposition essaie de résoudre, quelle est leur fréquence,
leur contournement dans le langage actuel et ses coût.
Je sais que j'aimerais ce support dans mon usage personnel
de développeur, mais de là à généraliser à "problème
fréquent", je ne sais pas.
|
Ça dépend comment tu définis « problème ». J'utilise la
programmation par contrat plutôt souvent, mais je ne suis pas
convaincu qu'il faut plus de moyens que ce que le C++ nous donne
déjà -- le coup de la fonction publique qui renvoie à la
fonction privée est assez efficace, et donne un maximum de
souplesse. Le seul vrai avantage que je vois pour l'introduire
formellement dans le langage, c'est que ça en encourage
l'utilisation, et si c'est ça une motivation, je verrais plutôt
des choses qu'il faudrait supprimer.
| Quote: | Je fais tout dans la doc (Doxygen) + assert. Ca unifierait la
chose.
|
C'est prèsque ce que je crais. Que ça unifierait trop. Les
besoins en varient énormement d'une classe à l'autre, et déjà,
ce que je fais d'habitude n'est pas exactement ce que fait
Eiffel, et ne pourrait pas se faire en Eiffel. Figer un modèle,
à l'exclusion des autres, n'est bon que si on est 100% sûr du
modèle. (Ou si c'est le modèle que j'utilise, moi:-). Mais dans
ce cas précis, le modèle que j'utilise varie d'une classe à
l'autre, parce que ce qui convient à une ne convient pas à
l'autre.)
--
James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|
|
| Back to top |
|
|
Loïc Joly
Guest
|
| Posted: Tue Mar 22, 2005 9:35 pm Post subject: Re: Pre-Lillehammer mailing |
|
|
Gabriel Dos Reis a écrit :
| Quote: | Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
|
| N1773 "Proposal to add Contract Programming to C++" D. Abrahams,
| L. Crowl, T. Ottosen, J. Widman
|
| Préconditions, postconditions, invariant de type. Rien que du bon.
| J'aurais aimé voir une possibilité d'activer/désactiver finement
| certaines vérifications, mais je suppose que ça relevera des options
| du compilateur.
Ce qui m'inquiète, c'est la tournure que ça prend. Je n'ai pas vu
d'explications claires sur les problèmes fondamentaux que la
proposition essaie de résoudre, quelle est leur fréquence, leur
contournement dans le langage actuel et ses coût.
|
J'ai un peu l'impression aussi que la proposition est trop limitée. Je
pressent qu'il y a des zone de recouvrement entre le contract
programming, les concepts, le static_assert... Il suffit de voir le
début de l'exemple de vector :
template< class T, class Alloc = allocator
class vector
{
static invariant
{
static is_assignable<T>::value : "value_type must be
Assignable" ;
static is_copy_constructible<T>::value : "value_type must be
CopyConstructible" ;
}
Or dans le papier, je ne vois rien sur les intéractions entre cette
proposition et les autres propositions en cours. Aller dans cette
direction me semblerait donc être bloquant pour quelquechose de plus
général.
C'est un peu comme si on proposait une solution avant que d'avoir posé
le problème.
--
Loïc
|
|
| Back to top |
|
|
Marc Boyer
Guest
|
| Posted: Wed Mar 23, 2005 7:23 am Post subject: Re: Pre-Lillehammer mailing |
|
|
En introduction, avant de répondre point par point, je réalise
que je me suis entousiasmé un peu vite (et que je manque de
recul pour juger des bonnes évolutions d'un langage).
En fait, je me suis réjouis de voir arriver dans le langage un
support pour pre/post/invariant dans le sens ou cela
encouragera son usage et faciliterait sa mise en oeuvre.
Mais est-ce de cette solution là dont on a besoin, là,
j'ai du mal à juger.
In article <42408582$0$1356$636a15ce (AT) news (DOT) free.fr>, James Kanze wrote:
| Quote: | Marc Boyer wrote:
Gabriel Dos Reis wrote:
Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
| N1773 "Proposal to add Contract Programming to C++" D. Abrahams,
| L. Crowl, T. Ottosen, J. Widman
| Préconditions, postconditions, invariant de type. Rien que
| du bon. J'aurais aimé voir une possibilité
| d'activer/désactiver finement certaines vérifications, mais
| je suppose que ça relevera des options du compilateur.
Ce qui m'inquiète, c'est la tournure que ça prend. Je n'ai pas
vu d'explications claires sur les problèmes fondamentaux que
la proposition essaie de résoudre, quelle est leur fréquence,
leur contournement dans le langage actuel et ses coût.
Je sais que j'aimerais ce support dans mon usage personnel
de développeur, mais de là à généraliser à "problème
fréquent", je ne sais pas.
Ça dépend comment tu définis « problème ». J'utilise la
programmation par contrat plutôt souvent, mais je ne suis pas
convaincu qu'il faut plus de moyens que ce que le C++ nous donne
déjà -- le coup de la fonction publique qui renvoie à la
fonction privée est assez efficace, et donne un maximum de
souplesse. Le seul vrai avantage que je vois pour l'introduire
formellement dans le langage, c'est que ça en encourage
l'utilisation, et si c'est ça une motivation, je verrais plutôt
des choses qu'il faudrait supprimer.
|
Que proposerais tu à la suppression ?
| Quote: | Je fais tout dans la doc (Doxygen) + assert. Ca unifierait la
chose.
C'est prèsque ce que je crais. Que ça unifierait trop. Les
besoins en varient énormement d'une classe à l'autre, et déjà,
ce que je fais d'habitude n'est pas exactement ce que fait
Eiffel, et ne pourrait pas se faire en Eiffel. Figer un modèle,
à l'exclusion des autres, n'est bon que si on est 100% sûr du
modèle. (Ou si c'est le modèle que j'utilise, moi:-). Mais dans
ce cas précis, le modèle que j'utilise varie d'une classe à
l'autre, parce que ce qui convient à une ne convient pas à
l'autre.)
|
J'avoue que je suis un peu perdu moi. Je ne voyais globalement
qu'une manière de faire. Si tu as du temps, tu peux donner
des exemples ?
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
|
|
| Back to top |
|
|
Loïc Joly
Guest
|
| Posted: Wed Mar 23, 2005 7:38 am Post subject: Re: Pre-Lillehammer mailing |
|
|
James Kanze a écrit :
| Quote: | C'est prèsque ce que je crais. Que ça unifierait trop. Les
besoins en varient énormement d'une classe à l'autre, et déjà,
ce que je fais d'habitude n'est pas exactement ce que fait
Eiffel, et ne pourrait pas se faire en Eiffel. Figer un modèle,
à l'exclusion des autres, n'est bon que si on est 100% sûr du
modèle. (Ou si c'est le modèle que j'utilise, moi:-). Mais dans
ce cas précis, le modèle que j'utilise varie d'une classe à
l'autre, parce que ce qui convient à une ne convient pas à
l'autre.)
|
Pourrais tu donner un exemple qui indique en quoi ce modèle varie d'une
classe à l'autre, et en quoi il diffère d'Eiffel ?
--
Loïc
|
|
| Back to top |
|
|
Jean-Marc Bourguet
Guest
|
| Posted: Wed Mar 23, 2005 8:15 am Post subject: Re: Pre-Lillehammer mailing |
|
|
James Kanze <kanze@none> writes:
| Quote: | Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr.invalid> writes:
N1776 "Decimal Types for C++" Robert Klarer
Pas bien compris la proposition. J'ai du lire trop vite.
Mais si j'ai bien compris, on aurait des types décimaux
conformes à la norme "IEEE-754R". Ca devrait éviter des débats
pour savoir pourquoi à 17,58 euros de l'heure, une heure n'est
pas facturée 17,58 mais 17,579...
A part que c'est des flottants donc avec les pertes non
signalees qui vont avec. Je n'ai toujours pas compris
l'interet des flottants decimaux.
Toutes les raisons qui poussent à utiliser les flottants
ailleurs,
|
Le choix d'un type de representation, c'est un compromis entre:
- l'intervalle representable
- la precision
- la facilite d'implementation
Les flottants donnent une precision relative presque constante --
l'ideal de ce point de vue serait une representation logarithmique,
mais l'implementation est trop couteuse, et plus la base est grande,
plus la precision varie, donc une base 10 est plus mauvaise de ce
point de vue -- sur un grand intervalle.
Les representations en virgule fixe (dont les entiers) donne une
precision absolue constante sur un intervalle plus faible.
| Quote: | avec le plus que les arrondies suivent les règles
juridiques de la comptabilité.
|
* Je ne vois pas l'interet de la precision relative constante en
comptabilite. Je vois un interet a une precision absolue constante.
Ce qui veut dire virgule fixe (ou rationnel a base fixee, ce qui est
la meme chose).
* J'aimerais la preuve que les flottants donnent des arrondis
respectants les regles juridiques. Celles-ci me semblent etre
plutot du genre "arrondi donne a x decimal apres un calcul exact".
En essayant de faire ca avec des flottants decimaux ou non, on a le
probleme du double arrondi. A nouveau une representation de virgule
fixe peut offir ce genre de garantie beaucoup plus facilement (j'ai
cite la partie adequate de la norme Ada par exemple)
* Cobol n'offrait pas non plus de flottants -- decimaux ou binaire --
la derniere fois que j'ai regarde. Ce qui me semble etre une
indication que la finance et le commerce n'en ont pas besoin.
La seule chose qui me fait penser qu'il y a peut etre un interet c'est
l'implication d'IBM, qui a priori a une bonne experience en la
matiere. Mais j'ai pas encore vu de bonnes raisons de preferer des
flottants a une representation en virgule fixe pour ces problemes.
Alors l'implication d'IBM est peut-etre due au fait que c'est le dada
de quelqu'un de suffisemment influent.
| Quote: | Évidemment, ce n'est intéressant que s'il y a suffisamment de
chiffres de précision.
|
Ah, tu veux des flottants pour te limiter a les utiliser dans la zone
ou ils se comportent comme des virgules fixes? Alors pourquoi des
flottants et pas des virgules fixes ou tu peux prevoir une exception
en cas de depassement?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
