Marc Boyer 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.
Marc Boyer <Marc.Boyer@enseeiht.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.
Marc Boyer 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.
Marc Boyer wrote:Gabriel Dos Reis wrote:Marc Boyer 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.
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.)
Marc Boyer wrote:
Gabriel Dos Reis wrote:
Marc Boyer <Marc.Boyer@enseeiht.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.
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.)
Marc Boyer wrote:Gabriel Dos Reis wrote:Marc Boyer 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.
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.)
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.)
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.)
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.)
Jean-Marc Bourguet wrote:Marc Boyer 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.
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.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.
Jean-Marc Bourguet wrote:Marc Boyer 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.
Marc Boyer 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<T> >
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.
Marc Boyer <Marc.Boyer@enseeiht.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<T> >
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.
Marc Boyer 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<T> >
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.
James Kanze writes:
Jean-Marc Bourguet wrote:Marc Boyer 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.
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.
É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?
James Kanze <kanze@none> writes:
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.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.
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.
É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?
James Kanze writes:
Jean-Marc Bourguet wrote:Marc Boyer 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.
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.
É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?
* 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).
Per se, je suis d'accord. Le problème, c'est que selon
l'application, voire des parties de l'application, le
nombre de décimales varient. Une implémentation virgule
flottante permettrait à la même classe de servir partout.
* 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)
Là, j'avoue que moi non plus, je ne sais pas trop. Mais
c'est ce que les spécialistes dans le domaine me dit. (En
effet, le problème de l'arrondie double semble réele.)
* 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.
Le format standard de Cobol est un peu bizarre -- il se base sur
le PIC, qui lui se base sur l'affichage. Tant qu'on reste en
dehors des USAGE IS COMP (où le format et ce qu'on supporte
dépendent de l'implémentation),
on peut dire grosso modo que chaque variable à un nombre
de ciffres fixe (maximum 13), avec le décimale à une
position fixe dans ces chiffres.
Il est moins clair ce qui se passe réelement quand on fait
l'arithmétique avec ses valeurs -- sur les mainframes de
la Siemens, la représentation interne était bien un espèce
de virgule flottant : 8 octets, 13 chiffres BCD, 4 bits de
signe, et un octet qui précisait la position de la
décimale -- un espèce de exposant, si tu veux.
* 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).
Per se, je suis d'accord. Le problème, c'est que selon
l'application, voire des parties de l'application, le
nombre de décimales varient. Une implémentation virgule
flottante permettrait à la même classe de servir partout.
* 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)
Là, j'avoue que moi non plus, je ne sais pas trop. Mais
c'est ce que les spécialistes dans le domaine me dit. (En
effet, le problème de l'arrondie double semble réele.)
* 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.
Le format standard de Cobol est un peu bizarre -- il se base sur
le PIC, qui lui se base sur l'affichage. Tant qu'on reste en
dehors des USAGE IS COMP (où le format et ce qu'on supporte
dépendent de l'implémentation),
on peut dire grosso modo que chaque variable à un nombre
de ciffres fixe (maximum 13), avec le décimale à une
position fixe dans ces chiffres.
Il est moins clair ce qui se passe réelement quand on fait
l'arithmétique avec ses valeurs -- sur les mainframes de
la Siemens, la représentation interne était bien un espèce
de virgule flottant : 8 octets, 13 chiffres BCD, 4 bits de
signe, et un octet qui précisait la position de la
décimale -- un espèce de exposant, si tu veux.
* 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).
Per se, je suis d'accord. Le problème, c'est que selon
l'application, voire des parties de l'application, le
nombre de décimales varient. Une implémentation virgule
flottante permettrait à la même classe de servir partout.
* 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)
Là, j'avoue que moi non plus, je ne sais pas trop. Mais
c'est ce que les spécialistes dans le domaine me dit. (En
effet, le problème de l'arrondie double semble réele.)
* 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.
Le format standard de Cobol est un peu bizarre -- il se base sur
le PIC, qui lui se base sur l'affichage. Tant qu'on reste en
dehors des USAGE IS COMP (où le format et ce qu'on supporte
dépendent de l'implémentation),
on peut dire grosso modo que chaque variable à un nombre
de ciffres fixe (maximum 13), avec le décimale à une
position fixe dans ces chiffres.
Il est moins clair ce qui se passe réelement quand on fait
l'arithmétique avec ses valeurs -- sur les mainframes de
la Siemens, la représentation interne était bien un espèce
de virgule flottant : 8 octets, 13 chiffres BCD, 4 bits de
signe, et un octet qui précisait la position de la
décimale -- un espèce de exposant, si tu veux.
Marc Boyer wrote:
[...]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 ?
La première chose qui me vient à l'esprit : est-ce qu'une classe
dérivée peut modifier le contrat, et comment ? En Eiffel, une
classe dérivée peut toujours donner des préconditions plus
libérale, et les post-conditions plus strictes
en général, je
préfère ne pas offrir cette liberté. Mais il y a de bons
arguments des deux côtés, et on pourrait bien imaginer l'offrir
dans certaines classes, et non dans l'autres.
La question de l'utilisation de la valeur précédante (le
« old ») dans les post-conditions est aussi à résoudre, surtout
dans le cas des classes qui ne supportent pas la copie. (En
Eiffel, autant que je sache, toutes les classes supportent la
copie, par définition, et on peut toujours se servir de
« old ». En C++, il faudrait bien quelques qualifications.)
Il y a aussi la question de l'applicabilité des contrats en cas
d'appel de la fonction lorsqu'on est dans une autre fonction
membre de la classe (ou d'une classe dérivée). En général, je
l'enforce, mais là aussi, il y a des exceptions (et Eiffel ne
l'enforce jamais dans ce cas).
Sans doute moins un problème, mais il y a aussi des classes
(surtout des interfaces de callback) où la programmation par
contrat ne s'applique pas.
La situation actuelle en C++ est simple : je fais ce que je
veux. L'idiome des fonctions publiques non-virtuelles qui
renvoient à des fonctions virtuelles privées ou protégées permet
à couvrir à peu près tous les cas. On discute donc du sucre
syntactique. Non sans intérêt, SI il ne nous limite pas par
ailleurs, mais non essentiel non plus.
Marc Boyer wrote:
[...]
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 ?
La première chose qui me vient à l'esprit : est-ce qu'une classe
dérivée peut modifier le contrat, et comment ? En Eiffel, une
classe dérivée peut toujours donner des préconditions plus
libérale, et les post-conditions plus strictes
en général, je
préfère ne pas offrir cette liberté. Mais il y a de bons
arguments des deux côtés, et on pourrait bien imaginer l'offrir
dans certaines classes, et non dans l'autres.
La question de l'utilisation de la valeur précédante (le
« old ») dans les post-conditions est aussi à résoudre, surtout
dans le cas des classes qui ne supportent pas la copie. (En
Eiffel, autant que je sache, toutes les classes supportent la
copie, par définition, et on peut toujours se servir de
« old ». En C++, il faudrait bien quelques qualifications.)
Il y a aussi la question de l'applicabilité des contrats en cas
d'appel de la fonction lorsqu'on est dans une autre fonction
membre de la classe (ou d'une classe dérivée). En général, je
l'enforce, mais là aussi, il y a des exceptions (et Eiffel ne
l'enforce jamais dans ce cas).
Sans doute moins un problème, mais il y a aussi des classes
(surtout des interfaces de callback) où la programmation par
contrat ne s'applique pas.
La situation actuelle en C++ est simple : je fais ce que je
veux. L'idiome des fonctions publiques non-virtuelles qui
renvoient à des fonctions virtuelles privées ou protégées permet
à couvrir à peu près tous les cas. On discute donc du sucre
syntactique. Non sans intérêt, SI il ne nous limite pas par
ailleurs, mais non essentiel non plus.
Marc Boyer wrote:
[...]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 ?
La première chose qui me vient à l'esprit : est-ce qu'une classe
dérivée peut modifier le contrat, et comment ? En Eiffel, une
classe dérivée peut toujours donner des préconditions plus
libérale, et les post-conditions plus strictes
en général, je
préfère ne pas offrir cette liberté. Mais il y a de bons
arguments des deux côtés, et on pourrait bien imaginer l'offrir
dans certaines classes, et non dans l'autres.
La question de l'utilisation de la valeur précédante (le
« old ») dans les post-conditions est aussi à résoudre, surtout
dans le cas des classes qui ne supportent pas la copie. (En
Eiffel, autant que je sache, toutes les classes supportent la
copie, par définition, et on peut toujours se servir de
« old ». En C++, il faudrait bien quelques qualifications.)
Il y a aussi la question de l'applicabilité des contrats en cas
d'appel de la fonction lorsqu'on est dans une autre fonction
membre de la classe (ou d'une classe dérivée). En général, je
l'enforce, mais là aussi, il y a des exceptions (et Eiffel ne
l'enforce jamais dans ce cas).
Sans doute moins un problème, mais il y a aussi des classes
(surtout des interfaces de callback) où la programmation par
contrat ne s'applique pas.
La situation actuelle en C++ est simple : je fais ce que je
veux. L'idiome des fonctions publiques non-virtuelles qui
renvoient à des fonctions virtuelles privées ou protégées permet
à couvrir à peu près tous les cas. On discute donc du sucre
syntactique. Non sans intérêt, SI il ne nous limite pas par
ailleurs, mais non essentiel non plus.
writes:
| À vrai
| dire, je crois que je supprimerais aussi les fonctions inline et
| les templates autre que exportés.
et tu offrirais un éditeur binaire et un clavier à deux touches à la
place ?
kanze@gabi-soft.fr writes:
| À vrai
| dire, je crois que je supprimerais aussi les fonctions inline et
| les templates autre que exportés.
et tu offrirais un éditeur binaire et un clavier à deux touches à la
place ?
writes:
| À vrai
| dire, je crois que je supprimerais aussi les fonctions inline et
| les templates autre que exportés.
et tu offrirais un éditeur binaire et un clavier à deux touches à la
place ?
