Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Post Mont Tremblant mailing

Post Mont Tremblant mailing

27 réponses
Avatar
Gabriel Dos Reis
C'est disponible en ligne depuis quelque temps

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

====

Comme cela se passait qu Québec, Michel Michaud nous a rendu visite et a
activement participé aux travaux. Et on a aussi discuté vin :-)

====

Le papier intitulé « Specifying C++ Concepts » a été accepté à la
conférence « Principles of Programming Languages 2006 »

http://www.cs.princeton.edu/~dpw/popl/06/acceptedpapers.htm

La version finale qui apparaîtra dans les « proceedings » est
différente de celle qui se trouve sur le site du comité. Nous comptons
la mettre en ligne dès que possible.
Les commentaires et suggestions sont toujours les bienvenus.

-- Gaby
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Jean-Marc Bourguet
Gabriel Dos Reis writes:

| Les concepts relevent du meme mecanisme: abandonner une certaine
| souplesse au profit d'une verification statique plus poussee.

Note cependant que pour nous, les concepts sont des prédicats de types
et de valeurs, et donc peuvent être manipulés direcrement avec les
opérateurs logiques.
De plus, on peut faire de la surcharge à base des concepts


Interessant. On abandonne une certaine souplesse, on en gagne une
autre en plus de la verification statique.

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

Avatar
Marc Boyer
Le 17-01-2006, Gabriel Dos Reis a écrit :
Note cependant que pour nous, les concepts sont des prédicats de types
et de valeurs, et donc peuvent être manipulés direcrement avec les
opérateurs logiques. De plus, on peut faire de la surcharge à base des
concepts

concept Small<typename T, int N>
where sizeof (T) < N
{ }

template<typename T> where Small<T, 256>
void f(const T&);

template<typename T> where !Small<T, 256>
void f(const T&);


J'avais vu ça. Encore un nouveau champ d'investigation
pour la programmation C++.

Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain

Avatar
Marc Boyer
Le 17-01-2006, Gabriel Dos Reis a écrit :
Marc Boyer writes:

| Le 19-11-2005, écrit :
| > Miam, il y a l'air d'y avoir du bon. Pour l'instant, j'ai juste lu (une
| > première fois, d'autres lectures seront nécessaires) le document "A
| > formalism for C++". Un point me gêne : Je ne vois pas à quoi peut
| > servir ce formalisme. As-tu un exemple ?
|
| Je me demande si sans ce formalisme ils auraient pu prétendre
| aussi facilement que leur notion de concept permettait de
| vérifier à la compilation qu'un ensemble de contraintes
| suffit à garantir la signature d'un template.

cela serait effectivement beaucoup plus dur à avancer :-)
Nous avons appris beaucoup de choses avec ce formalisme (même
incomplet) :-)


Ca ne m'étonne pas. Tiens, je bosse avec un thésard qui
avait fait un outil de traduction d'un formalisme A vers
une formalisme B. Ca semblait bien marcher. On a écrit
la preuve, et trouvé pas loins d'une douzaine d'erreurs.


Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain

Avatar
Gabriel Dos Reis
Jean-Marc Bourguet writes:

| Gabriel Dos Reis writes:
|
| > Gabriel Dos Reis writes:
| >
| > [...]
| >
| > | Le papier intitulé « Specifying C++ Concepts » a été accepté à la
| > | conférence « Principles of Programming Languages 2006 »
| > |
| > | http://www.cs.princeton.edu/~dpw/popl/06/acceptedpapers.htm
| > |
| > | La version finale qui apparaîtra dans les « proceedings » est
| > | différente de celle qui se trouve sur le site du comité. Nous comptons
| > | la mettre en ligne dès que possible.
| > | Les commentaires et suggestions sont toujours les bienvenus.
| >
| > Désolé d'avoir « disparu » du forum après avoir lancé cette
| > disucssion. Pour ceux que cela intéresse toujours, la version finale
| > du papier présentée à POPL la semaine dernière est disponible sur la
| > page de BS
| >
| > http://www.research.att.com/~bs/papers.html
|
| Les papiers sur SELL ont l'air interessant aussi.

:-)
J'espère qu'on aura une version officielle d'ici l'été -- pas
printemps parce qu'il faut travailler sur les concepts aussi et nous
ne sommes que deux pour le moment :-)

|
| Pas sans rapport avec ce dernier sujet, vous avez regarde SystemC?

oui -- nous devrions le mentionner plus complètement dans les «
Related Work » ; merci.

-- Gaby
Avatar
fabien.chene.invalid
Jean-Marc Bourguet writes:

Les papiers sur SELL ont l'air interessant aussi.


En lisant le papier sur SELL, il me vient quelques interrogations ...

3.3, il y a un squelette du concept Parallelizable :

concept Parallelizable<typename T>
{
// operations required by any Parallelizable type
// only required operations will be accepted
// for an objet of a Parallelizable type.
}

Je m'étonne du "only required", si on regarde l'exemple suivant :

concept PostIncrementable <class T>
{
Var<T> v;
v++;
}

template <class T>
where PostIncrementable<T>
T f( )
{
T t;
t++;
return t;
}

D'après ce que j'ai lu dans le dernier papier sur les concepts, T doit
obligatoirement fournir les operations spécifiés dans le concept
PostIncrementable, mais peut aussi fournir d'autres opérations, comme
par exemple la construction par défaut d'un T.

Les commentaires dans le squelette du concept Parallelizable sus-cité
me paraisse contradictoire avec ce que je comprends.

Peut-être est-il envisagé une solution de ce genre (?) :

template <class T>
expectexactly PostIncrementable<T>
T f( )
{
T t; // Erreur
t++;
return t;
}

qui demande au compilateur de regarder dans la scope de f (au moins
...), si chaque opération sur un T est spécifié dans sa clause
"expectexactly". Cela me parait difficilement faisable non ?


-- Fab --

Avatar
fabien.chene.invalid
Gabriel Dos Reis writes:

"" wri tes:

[...]

| Autre question, qui m'est venue en lisant ça, et par le fait que je
| découvre un peu le Java et le C# en ce moment. J'ai un peu
| l'impression que dans ces langages, les interfaces remplissent assez
| souvent le rôle que l'on voudrait faire remplire aux concepts en C++.
| Suis-je le seul à être de cet avis ?


Si les contraintes sur les générics s'étaient exprimées comme ceci :

class Foo <T implements Constraints> (*)
{ ... }

au lieu de

class Foo <T : extends Base >
{ ... }

, je crois que je serais de cet avis.

Je crois que la ressemblance est seulement superficielle.


Est-ce en pensant à quelque chose du genre (*) que vous y voyates une
ressemblance superficielle ? :)

En générale, les gens ont tendance à dire que les concepts
ressemblent aux « type classes » de Haskell. Mais là, également,
nous avons expliqué dans les deux papiers (ainsi qu'à POPL) la
semaine dernière que la ressemblaence est encore superficielle même
si elle est forte.


Je crois que je vais m'intéresser à Haskell, merci.

Avatar
Gabriel Dos Reis
( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:

| Jean-Marc Bourguet writes:
|
| > Les papiers sur SELL ont l'air interessant aussi.
|
| En lisant le papier sur SELL, il me vient quelques interrogations ...
|
| 3.3, il y a un squelette du concept Parallelizable :
|
| concept Parallelizable<typename T>
| {
| // operations required by any Parallelizable type
| // only required operations will be accepted
| // for an objet of a Parallelizable type.
| }
|
| Je m'étonne du "only required", si on regarde l'exemple suivant :
|
| concept PostIncrementable <class T>
| {
| Var<T> v;
| v++;
| }
|
| template <class T>
| where PostIncrementable<T>
| T f( )
| {
| T t;
| t++;
| return t;
| }
|
| D'après ce que j'ai lu dans le dernier papier sur les concepts, T doit
| obligatoirement fournir les operations spécifiés dans le concept
| PostIncrementable, mais peut aussi fournir d'autres opérations, comme
| par exemple la construction par défaut d'un T.

Oui.

| Les commentaires dans le squelette du concept Parallelizable sus-cité
| me paraisse contradictoire avec ce que je comprends.

Je ne comprends pas.

| Peut-être est-il envisagé une solution de ce genre (?) :
|
| template <class T>
| expectexactly PostIncrementable<T>
| T f( )
| {
| T t; // Erreur
| t++;
| return t;
| }
|
| qui demande au compilateur de regarder dans la scope de f (au moins
| ...), si chaque opération sur un T est spécifié dans sa clause
| "expectexactly". Cela me parait difficilement faisable non ?

Je ne suis pas aou courant d'une proposition « expectexactly » et ce
qu'est sa sémantique.

Le commentaire dans dans Parallelizable veut dire que seules les
opérations spécifiées seront acceptées dans le corps de la fonction
qui est controlée par Parallelizable. Voir plus de details dans le
papier « A Concept Design (Rev. 1) » ou le papier « Specifying C++
Concepts »

-- Gaby
Avatar
Gabriel Dos Reis
( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:

| Gabriel Dos Reis writes:
|
| > "" writes:
|
| > [...]
|
| > | Autre question, qui m'est venue en lisant ça, et par le fait que je
| > | découvre un peu le Java et le C# en ce moment. J'ai un peu
| > | l'impression que dans ces langages, les interfaces remplissent assez
| > | souvent le rôle que l'on voudrait faire remplire aux concepts en C++.
| > | Suis-je le seul à être de cet avis ?
|
| Si les contraintes sur les générics s'étaient exprimées comme ceci :
|
| class Foo <T implements Constraints> (*)
| { ... }
|
| au lieu de
|
| class Foo <T : extends Base >
| { ... }
|
| , je crois que je serais de cet avis.

Je ne comprends pas.

| > Je crois que la ressemblance est seulement superficielle.
|
| Est-ce en pensant à quelque chose du genre (*) que vous y voyates une
| ressemblance superficielle ? :)

Quelque chose comme (*) spécifie des contraintes sur des paramètres
individuellement, c'est rarement ce dont on a besoin dans le contexte
de C++ -- je passe sous silence l'argument traditionnel qu'une
solution à base de hiérarchie de classe ne convient pas à C++. Voir
D&E et les papiers d'octobre 2003 sur les concepts.

-- Gaby
Avatar
fabien.chene.invalid
Gabriel Dos Reis writes:

writes:

| Gabriel Dos Reis writes:
|
| > "" writes:
|
| > [...]
|
| > | Autre question, qui m'est venue en lisant ça, et par le fait que je
| > | découvre un peu le Java et le C# en ce moment. J'ai un peu
| > | l'impression que dans ces langages, les interfaces remplissent assez
| > | souvent le rôle que l'on voudrait faire remplire aux concepts en C++.
| > | Suis-je le seul à être de cet avis ?
|
| Si les contraintes sur les générics s'étaient exprimées comme c eci :
|
| class Foo <T implements Constraints> (*)
| { ... }
|
| au lieu de
|
| class Foo <T : extends Base >
| { ... }
|
| , je crois que je serais de cet avis.

Je ne comprends pas.


oups, je réalise que class Foo <T extends Base<T> > peut aussi obliger T à
implementer l'interface Base<T>, et non de seulement hériter de Base<T>
comme je m'y attendais.

Je trouvais la solution "obligeant à implémenter l'interface" moins
éloigné de l'esprit des concepts C++0x, que ne l'est la solution
"obligeant à hériter d'une classe de base". Mais c'est très
superficiel. Et vu que j'ai du mal à trouver cohérente la notion
d'interface Java, j'ai du mal à faire le pont avec C++.

| > Je crois que la ressemblance est seulement superficielle.
|
| Est-ce en pensant à quelque chose du genre (*) que vous y voyates une
| ressemblance superficielle ? :)

Quelque chose comme (*) spécifie des contraintes sur des paramètres
individuellement, c'est rarement ce dont on a besoin dans le contexte
de C++


Effectivement ! étant donné que je regarde des exemples simplissimes
sur les concepts, ce n'est pas la première chose qui m'a sauté aux
yeux ( c'était plus la possibilité de surcharge ). Mais le tout
combiné, ça va donner une sacré puissance à la bête !

-- je passe sous silence l'argument traditionnel qu'une
solution à base de hiérarchie de classe ne convient pas à C++. Voir
D&E et les papiers d'octobre 2003 sur les concepts.


Vu dans le D&E, bien expliqué d'ailleurs.


-- Fab --

Avatar
fabien.chene.invalid
Gabriel Dos Reis writes:

( =?iso-8859-15?q?Fabien_CH ÊNE?=) writes:

[ ...]
|
| Je m'étonne du "only required", si on regarde l'exemple suivant :
|
| concept PostIncrementable <class T>
| {
| Var<T> v;
| v++;
| }
|
| template <class T>
| where PostIncrementable<T>
| T f( )
| {
| T t;
| t++;
| return t;
| }
|
| D'après ce que j'ai lu dans le dernier papier sur les concepts, T doit
| obligatoirement fournir les operations spécifiés dans le concept
| PostIncrementable, mais peut aussi fournir d'autres opérations, comme
| par exemple la construction par défaut d'un T.

Oui.


concept Parallelizable <class T>
{
T v1, v2;
typename T::size_type i;
v[i];
v1 + v2;
v1 * v2; // par exemple ...
}

template <Parallelizable T>
void f( T const& t )
{
auto* x = &t[0];
}

Alors ceci ne peux pas être rejeter par le compilateur ?

Comment peut-on alors formuler, en C++0x standard, un concept
interdisant 3.1 #2 dans l'article sur SELL ? Si cela n'est pas
faisable, je comprendrai mieux l'intérêt de passer par un SELL pour
faire du calcul à hautes performances.

| Les commentaires dans le squelette du concept Parallelizable sus-cité
| me paraisse contradictoire avec ce que je comprends.

Je ne comprends pas.

| Peut-être est-il envisagé une solution de ce genre (?) :
|
| template <class T>
| expectexactly PostIncrementable<T>
| T f( )
| {
| T t; // Erreur
| t++;
| return t;
| }
|
| qui demande au compilateur de regarder dans la scope de f (au moins
| ...), si chaque opération sur un T est spécifié dans sa clause
| "expectexactly". Cela me parait difficilement faisable non ?

Je ne suis pas aou courant d'une proposition « expectexactly » et ce
qu'est sa sémantique.


Non, ce n'est pas une proposition officielle ;) La clause where telle
que je la comprend, est satisfaite/vraie lorsque T fourni *au moins*
les operations présentes dans le concept sous-jacent.

Ce qui a l'air d'être requis pour Parallelizable est : T fourni *au
moins* les operations présentes dans le concept sous-jacent, *et pas
une de plus*, c'est ce que je voulais dire par expectexactly.

Le commentaire dans dans Parallelizable veut dire que seules les
opérations spécifiées seront acceptées dans le corps de la foncti on
qui est controlée par Parallelizable.


Ce qui nécessite une analyse du corp de la fonction. Je crois que
l'origine de mon incompréhension réside dans le fait que je ne
distingue pas ce qui est C++0x de ce qui est "SELL" appliquée au
calcul à hautes performances.

En C++0x, l'analyse du corp de la fonction n'est (sauf erreur) pas
effectuée pour déconsidérer une fonction lors de la résolution de
surcharge.
Est-ce que ça peut être le cas dans une extension SELL ?

Voir plus de details dans le papier « A Concept Design (Rev. 1) » ou
le papier « Specifying C++ Concepts »


Je plonge dans le premier, en espérant regagner la surface ...


-- Fab --

1 2 3