Pre-Lillehammer mailing

In article <m3d5ttnlm8.fsf@merlin.cs.tamu.edu>, Gabriel Dos Reis wrote:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-03

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.

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.


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.

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.

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

In article <pxbfyynptya.fsf@news.bourguet.org>, 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.

J'avais lu trop vite (en fait, je suis pas allé voir la norme IEEE-754R).

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 ?

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

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.

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

In article <pxbfyynptya.fsf@news.bourguet.org>, 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.

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, ...)

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

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

| 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.

| 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

Gabriel Dos Reis wrote:

Marc Boyer <Marc.Boyer@enseeiht.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.

| 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@posting.google.com>

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.

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.

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

[...]

| >| 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@posting.google.com>

OK. Je suis très en retard en ce qui concerne fclc++.

[...]

| > 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

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. (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

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.)

--
James Kanze mailto: james.kanze@free.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