Je rapplique avec une question pas très sexy, désolé.
Si j'ai une lib en C que je veux utiliser en C++, et que la lib n'a pas été
conçue pour C++, la solution est de retoucher les headers de la lib et de
rajouter des :
#ifdef __cplusplus
extern "C" {
#endif
dans tous les .h.
Si dans cette lib, y'a une struct avec un membre qui s'appelle operator. ex:
struct st {
int operator;
};
Est-ce que c'est correct de faire:
#ifdef __cplusplus
extern "C" {
#endif
struct st {
#ifdef __cplusplus
int xoperator; // operator est un mot clé réservé en C++
#else
int operator;
#endif
};
#ifdef __cplusplus
}
#endif
Autrement dit, est-ce que une structure n'aurait pas une espèce de signature
(comme une fonction) qui ferait intervenir le nom des membres, et qui
empêcherait de l'utiliser si on la falsifie. (d'après la norme, et d'après
la réalité du terrain).
Autre question:
sur un :
typedef char * charptr;
ou :
typedef struct st *structptr;
est-il nécessaire d'encadrer ces typedefs d'un extern "C" ?
Je sais pas vous mais moi ca m'arrive encore d'appeler des variables 'new'.
Je n'irais pas jusque là, mais c'est vrai que des `register´ et autres `auto´ m'échappent de temps à autre (tiens, c'est vrai que ça fait longtemps, en fait).
--drkm
"Thierry Noc" <svill@free.fr> writes:
Je sais pas vous mais moi ca m'arrive encore d'appeler des variables
'new'.
Je n'irais pas jusque là, mais c'est vrai que des `register´ et
autres `auto´ m'échappent de temps à autre (tiens, c'est vrai que ça
fait longtemps, en fait).
Je sais pas vous mais moi ca m'arrive encore d'appeler des variables 'new'.
Je n'irais pas jusque là, mais c'est vrai que des `register´ et autres `auto´ m'échappent de temps à autre (tiens, c'est vrai que ça fait longtemps, en fait).
--drkm
drkm
Gabriel Dos Reis writes:
drkm writes:
| autres `auto´ m'échappent de temps à autre (tiens, c'est vrai que | ça fait longtemps, en fait).
cela ne va pas durer longtemps ;-)
-- Gaby, membre de l'Association Pour la Réhabilitation d'auto.
Vive `decltype´, c'est ça ?-)
--drkm
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
drkm <darkman_spam@yahoo.fr> writes:
| autres `auto´ m'échappent de temps à autre (tiens, c'est vrai que
| ça fait longtemps, en fait).
cela ne va pas durer longtemps ;-)
-- Gaby, membre de l'Association Pour la Réhabilitation d'auto.
| autres `auto´ m'échappent de temps à autre (tiens, c'est vrai que | ça fait longtemps, en fait).
cela ne va pas durer longtemps ;-)
-- Gaby, membre de l'Association Pour la Réhabilitation d'auto.
Vive `decltype´, c'est ça ?-)
--drkm
Gabriel Dos Reis
drkm writes:
| Gabriel Dos Reis writes: | | > drkm writes: | | > | autres `auto´ m'échappent de temps à autre (tiens, c'est vrai que | > | ça fait longtemps, en fait). | | > cela ne va pas durer longtemps ;-) | | > -- Gaby, membre de l'Association Pour la Réhabilitation d'auto. | | Vive `decltype´, c'est ça ?-)
et auto.
compare
for_each(v.begin(), v.end(), auto (auto x) -> cout << x)
si le compilateur connaît le type de v.begin(), donc celui de *v.begin(), pourquoi dois-je encore le dire dans le ostream_iterator<> ?
-- Gaby
drkm <darkman_spam@yahoo.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > drkm <darkman_spam@yahoo.fr> writes:
|
| > | autres `auto´ m'échappent de temps à autre (tiens, c'est vrai que
| > | ça fait longtemps, en fait).
|
| > cela ne va pas durer longtemps ;-)
|
| > -- Gaby, membre de l'Association Pour la Réhabilitation d'auto.
|
| Vive `decltype´, c'est ça ?-)
et auto.
compare
for_each(v.begin(), v.end(), auto (auto x) -> cout << x)
| Gabriel Dos Reis writes: | | > drkm writes: | | > | autres `auto´ m'échappent de temps à autre (tiens, c'est vrai que | > | ça fait longtemps, en fait). | | > cela ne va pas durer longtemps ;-) | | > -- Gaby, membre de l'Association Pour la Réhabilitation d'auto. | | Vive `decltype´, c'est ça ?-)
et auto.
compare
for_each(v.begin(), v.end(), auto (auto x) -> cout << x)
si le compilateur connaît le type de v.begin(), donc celui de *v.begin(), pourquoi dois-je encore le dire dans le ostream_iterator<> ?
-- Gaby
drkm
Gabriel Dos Reis writes:
si le compilateur connaît le type de v.begin(), donc celui de *v.begin(), pourquoi dois-je encore le dire dans le ostream_iterator<> ?
Yep.
Tout simplement, j'avais oublié cet usage de `auto´ en le citant dans mon précédent article. Je pense que c'est toi qui avais posté la référence de « Decltype and auto » (de mémoire) de Stroustrup and al. J'y avais jeté un oeil, mais si je me souviens bien, c'était à une époque délicate pour un étudiant, et je n'avais pas suivit les discussions ici à ce sujet.
--drkm
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
si le compilateur connaît le type de v.begin(), donc celui de
*v.begin(), pourquoi dois-je encore le dire dans le
ostream_iterator<> ?
Yep.
Tout simplement, j'avais oublié cet usage de `auto´ en le citant
dans mon précédent article. Je pense que c'est toi qui avais posté la
référence de « Decltype and auto » (de mémoire) de Stroustrup and al.
J'y avais jeté un oeil, mais si je me souviens bien, c'était à une
époque délicate pour un étudiant, et je n'avais pas suivit les
discussions ici à ce sujet.
si le compilateur connaît le type de v.begin(), donc celui de *v.begin(), pourquoi dois-je encore le dire dans le ostream_iterator<> ?
Yep.
Tout simplement, j'avais oublié cet usage de `auto´ en le citant dans mon précédent article. Je pense que c'est toi qui avais posté la référence de « Decltype and auto » (de mémoire) de Stroustrup and al. J'y avais jeté un oeil, mais si je me souviens bien, c'était à une époque délicate pour un étudiant, et je n'avais pas suivit les discussions ici à ce sujet.
--drkm
Gabriel Dos Reis
drkm <fr.comp.lang.c++@fgeorges.org> writes:
| Gabriel Dos Reis writes: | | > si le compilateur connaît le type de v.begin(), donc celui de | > *v.begin(), pourquoi dois-je encore le dire dans le | > ostream_iterator<> ? | | Yep. | | Tout simplement, j'avais oublié cet usage de `auto´ en le citant | dans mon précédent article. Je pense que c'est toi qui avais posté la | référence de « Decltype and auto » (de mémoire) de Stroustrup and al. | J'y avais jeté un oeil, mais si je me souviens bien, c'était à une | époque délicate pour un étudiant, et je n'avais pas suivit les | discussions ici à ce sujet.
tu n'as pas à te flageler : mon utilisation de auto dans le message précédent n'est pas vraiment contenu dans le papier, même si elle y apparaît entre les lignes.
-- Gaby
drkm <fr.comp.lang.c++@fgeorges.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > si le compilateur connaît le type de v.begin(), donc celui de
| > *v.begin(), pourquoi dois-je encore le dire dans le
| > ostream_iterator<> ?
|
| Yep.
|
| Tout simplement, j'avais oublié cet usage de `auto´ en le citant
| dans mon précédent article. Je pense que c'est toi qui avais posté la
| référence de « Decltype and auto » (de mémoire) de Stroustrup and al.
| J'y avais jeté un oeil, mais si je me souviens bien, c'était à une
| époque délicate pour un étudiant, et je n'avais pas suivit les
| discussions ici à ce sujet.
tu n'as pas à te flageler : mon utilisation de auto dans le message
précédent n'est pas vraiment contenu dans le papier, même si elle y
apparaît entre les lignes.
| Gabriel Dos Reis writes: | | > si le compilateur connaît le type de v.begin(), donc celui de | > *v.begin(), pourquoi dois-je encore le dire dans le | > ostream_iterator<> ? | | Yep. | | Tout simplement, j'avais oublié cet usage de `auto´ en le citant | dans mon précédent article. Je pense que c'est toi qui avais posté la | référence de « Decltype and auto » (de mémoire) de Stroustrup and al. | J'y avais jeté un oeil, mais si je me souviens bien, c'était à une | époque délicate pour un étudiant, et je n'avais pas suivit les | discussions ici à ce sujet.
tu n'as pas à te flageler : mon utilisation de auto dans le message précédent n'est pas vraiment contenu dans le papier, même si elle y apparaît entre les lignes.
-- Gaby
kanze
Richard Delorme wrote in message news:<3f67005f$0$20942$...
Gabriel Dos Reis wrote in message news:...
Loïc Joly writes:
| Pour le posteur initial, une version vraiment propre consisterait | à écrire une couche d'interface pour cette bibliothèque en C | compatible C++, mais ça rajoute un niveau de complexité.
éviter le nom « operator » est plus simple.
Utiliser le nom « operator » dans du code C écrit aujourd'hui, c'est effectivement irresponsible. En revanche, je m'en servais aussi tard que 1988, et je ne me sentais pas irresponsible. Et je me rappelle bien la première fois que j'ai dû compiler un en-tête C avec un compilateur C++, le compilateur a râlé à cause d'un membre « class ».
(Ceci dit, si j'étais pourvoyeur d'une bibliothèque C aujourd'hui, égal quand la bibliothèque a été écrit, je me débrouillerais pour qu'aucun symbol dans les en-têtes publics s'appelle operator, ni class, ni ... Que du code ancien contient de telles choses, c'est normal, mais l'effort de les enlever, au moins dans les interfaces, n'est vraiment pas grand.)
Utiliser les mots clés du C++ (class, this, operator, ...) dans du C est toujours un plaisir malin pour certains. Ce n'est pas de l'irresponsabilité, mais une volonté d'affirmer avec une certaine et stupide constance, que C et C++ sont deux langages différents et incompatibles.
Faire quelque chose exprès pour rendre la vie difficile aux autres, c'est un enfantilisme, et rien d'autre. Et C et C++ ont beau être deux langages différents, il arrive qu'on veut appeler du C à partir du C++, et il faudrait être ou bien vraiment naïf ou bien de mauvaise fois pour ne pas le prendre en compte.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Richard Delorme <abulmo@nospam.fr> wrote in message
news:<3f67005f$0$20942$7a628cd7@news.club-internet.fr>...
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m38yopre5i.fsf@uniton.integrable-solutions.net>...
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| Pour le posteur initial, une version vraiment propre consisterait
| à écrire une couche d'interface pour cette bibliothèque en C
| compatible C++, mais ça rajoute un niveau de complexité.
éviter le nom « operator » est plus simple.
Utiliser le nom « operator » dans du code C écrit aujourd'hui, c'est
effectivement irresponsible. En revanche, je m'en servais aussi tard que
1988, et je ne me sentais pas irresponsible. Et je me rappelle bien la
première fois que j'ai dû compiler un en-tête C avec un compilateur C++,
le compilateur a râlé à cause d'un membre « class ».
(Ceci dit, si j'étais pourvoyeur d'une bibliothèque C aujourd'hui,
égal quand la bibliothèque a été écrit, je me débrouillerais pour
qu'aucun symbol dans les en-têtes publics s'appelle operator, ni
class, ni ... Que du code ancien contient de telles choses, c'est
normal, mais l'effort de les enlever, au moins dans les interfaces,
n'est vraiment pas grand.)
Utiliser les mots clés du C++ (class, this, operator, ...) dans du C
est toujours un plaisir malin pour certains. Ce n'est pas de
l'irresponsabilité, mais une volonté d'affirmer avec une certaine et
stupide constance, que C et C++ sont deux langages différents et
incompatibles.
Faire quelque chose exprès pour rendre la vie difficile aux autres,
c'est un enfantilisme, et rien d'autre. Et C et C++ ont beau être deux
langages différents, il arrive qu'on veut appeler du C à partir du C++,
et il faudrait être ou bien vraiment naïf ou bien de mauvaise fois pour
ne pas le prendre en compte.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Richard Delorme wrote in message news:<3f67005f$0$20942$...
Gabriel Dos Reis wrote in message news:...
Loïc Joly writes:
| Pour le posteur initial, une version vraiment propre consisterait | à écrire une couche d'interface pour cette bibliothèque en C | compatible C++, mais ça rajoute un niveau de complexité.
éviter le nom « operator » est plus simple.
Utiliser le nom « operator » dans du code C écrit aujourd'hui, c'est effectivement irresponsible. En revanche, je m'en servais aussi tard que 1988, et je ne me sentais pas irresponsible. Et je me rappelle bien la première fois que j'ai dû compiler un en-tête C avec un compilateur C++, le compilateur a râlé à cause d'un membre « class ».
(Ceci dit, si j'étais pourvoyeur d'une bibliothèque C aujourd'hui, égal quand la bibliothèque a été écrit, je me débrouillerais pour qu'aucun symbol dans les en-têtes publics s'appelle operator, ni class, ni ... Que du code ancien contient de telles choses, c'est normal, mais l'effort de les enlever, au moins dans les interfaces, n'est vraiment pas grand.)
Utiliser les mots clés du C++ (class, this, operator, ...) dans du C est toujours un plaisir malin pour certains. Ce n'est pas de l'irresponsabilité, mais une volonté d'affirmer avec une certaine et stupide constance, que C et C++ sont deux langages différents et incompatibles.
Faire quelque chose exprès pour rendre la vie difficile aux autres, c'est un enfantilisme, et rien d'autre. Et C et C++ ont beau être deux langages différents, il arrive qu'on veut appeler du C à partir du C++, et il faudrait être ou bien vraiment naïf ou bien de mauvaise fois pour ne pas le prendre en compte.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Samuel Krempp
le Wednesday 17 September 2003 07:31, écrivit :
tu n'as pas à te flageler : mon utilisation de auto dans le message précédent n'est pas vraiment contenu dans le papier, même si elle y apparaît entre les lignes.
et tu pourrais donner une estimation (sans garantie) du délai avant que ce soit utilisable de manière à peu près portable ? en lisant dans le marc de café, les tripes de membre de comité, ce que tu veux, sans contrainte de fiabilité..
(au fait il est où ce papier ?)
-- Sam
le Wednesday 17 September 2003 07:31, gdr@integrable-solutions.net écrivit :
tu n'as pas à te flageler : mon utilisation de auto dans le message
précédent n'est pas vraiment contenu dans le papier, même si elle y
apparaît entre les lignes.
et tu pourrais donner une estimation (sans garantie) du délai avant que ce
soit utilisable de manière à peu près portable ?
en lisant dans le marc de café, les tripes de membre de comité, ce que tu
veux, sans contrainte de fiabilité..
tu n'as pas à te flageler : mon utilisation de auto dans le message précédent n'est pas vraiment contenu dans le papier, même si elle y apparaît entre les lignes.
et tu pourrais donner une estimation (sans garantie) du délai avant que ce soit utilisable de manière à peu près portable ? en lisant dans le marc de café, les tripes de membre de comité, ce que tu veux, sans contrainte de fiabilité..
(au fait il est où ce papier ?)
-- Sam
Gabriel Dos Reis
writes:
| Faire quelque chose exprès pour rendre la vie difficile aux autres, | c'est un enfantilisme, et rien d'autre. Et C et C++ ont beau être deux | langages différents, il arrive qu'on veut appeler du C à partir du C++, | et il faudrait être ou bien vraiment naïf ou bien de mauvaise fois pour | ne pas le prendre en compte.
Tu devrais aller prêcher un peu sur fclc ;-)
-- Gaby
kanze@gabi-soft.fr writes:
| Faire quelque chose exprès pour rendre la vie difficile aux autres,
| c'est un enfantilisme, et rien d'autre. Et C et C++ ont beau être deux
| langages différents, il arrive qu'on veut appeler du C à partir du C++,
| et il faudrait être ou bien vraiment naïf ou bien de mauvaise fois pour
| ne pas le prendre en compte.
| Faire quelque chose exprès pour rendre la vie difficile aux autres, | c'est un enfantilisme, et rien d'autre. Et C et C++ ont beau être deux | langages différents, il arrive qu'on veut appeler du C à partir du C++, | et il faudrait être ou bien vraiment naïf ou bien de mauvaise fois pour | ne pas le prendre en compte.
Tu devrais aller prêcher un peu sur fclc ;-)
-- Gaby
Gabriel Dos Reis
writes:
| Mais mon point principal était simplement que la règle ODR en C++ ne | s'applique qu'au C++, et que la règle en C ne s'applique qu'en C. Et que
l'ODR s'applique à tout programme C++.
| du moment tu melanges les deux langages, tu passes au règne du spécifié | par l'implémentation
ou au fonctionnement indéfini.
[...]
| > C'est du fonctionnement indéfini, parce que « extern "C" » ne veut pas | > dire, vous pouvez passer n'importe quoi. « extern "C" », ne veut pas | > dire, on lève la vérification des contraintes. | | Ce qu'« extern "C" » veut dire dépend de ce qui est « extern "C" ». Si | c'est une définition d'une struct, elle ne veut rien dire.
oh que si. cela veut dire quelque chose, et ce que cela veut dire est explicitement couvert par la norme C++.
| > | dès qu'on utilise « extern "C" », mais que le but de l'« extern "C" | > | » est clair, et que tous les compilateurs C implément l'équivalence | > | structurelle, et ne risquent pas de changer à cause du code | > | existant, | | > cela a probablement dû s'afficher dans la même couleur que le fond de | > ton lecteur de messages, mais j'ai précisé que c'était une pratique | > répandue mais incorrecte. | | J'ai bien vu que tu disais que c'est une pratique répandue. J'ai aussi | vu que tu disais que c'est une pratique incorrecte, ce qui est fausse. | C'est aussi correct que n'importe quel autre chose qui dépend de | l'implémentation.
Non.
-- Gaby
kanze@gabi-soft.fr writes:
| Mais mon point principal était simplement que la règle ODR en C++ ne
| s'applique qu'au C++, et que la règle en C ne s'applique qu'en C. Et que
l'ODR s'applique à tout programme C++.
| du moment tu melanges les deux langages, tu passes au règne du spécifié
| par l'implémentation
ou au fonctionnement indéfini.
[...]
| > C'est du fonctionnement indéfini, parce que « extern "C" » ne veut pas
| > dire, vous pouvez passer n'importe quoi. « extern "C" », ne veut pas
| > dire, on lève la vérification des contraintes.
|
| Ce qu'« extern "C" » veut dire dépend de ce qui est « extern "C" ». Si
| c'est une définition d'une struct, elle ne veut rien dire.
oh que si. cela veut dire quelque chose, et ce que cela veut dire est
explicitement couvert par la norme C++.
| > | dès qu'on utilise « extern "C" », mais que le but de l'« extern "C"
| > | » est clair, et que tous les compilateurs C implément l'équivalence
| > | structurelle, et ne risquent pas de changer à cause du code
| > | existant,
|
| > cela a probablement dû s'afficher dans la même couleur que le fond de
| > ton lecteur de messages, mais j'ai précisé que c'était une pratique
| > répandue mais incorrecte.
|
| J'ai bien vu que tu disais que c'est une pratique répandue. J'ai aussi
| vu que tu disais que c'est une pratique incorrecte, ce qui est fausse.
| C'est aussi correct que n'importe quel autre chose qui dépend de
| l'implémentation.
| Mais mon point principal était simplement que la règle ODR en C++ ne | s'applique qu'au C++, et que la règle en C ne s'applique qu'en C. Et que
l'ODR s'applique à tout programme C++.
| du moment tu melanges les deux langages, tu passes au règne du spécifié | par l'implémentation
ou au fonctionnement indéfini.
[...]
| > C'est du fonctionnement indéfini, parce que « extern "C" » ne veut pas | > dire, vous pouvez passer n'importe quoi. « extern "C" », ne veut pas | > dire, on lève la vérification des contraintes. | | Ce qu'« extern "C" » veut dire dépend de ce qui est « extern "C" ». Si | c'est une définition d'une struct, elle ne veut rien dire.
oh que si. cela veut dire quelque chose, et ce que cela veut dire est explicitement couvert par la norme C++.
| > | dès qu'on utilise « extern "C" », mais que le but de l'« extern "C" | > | » est clair, et que tous les compilateurs C implément l'équivalence | > | structurelle, et ne risquent pas de changer à cause du code | > | existant, | | > cela a probablement dû s'afficher dans la même couleur que le fond de | > ton lecteur de messages, mais j'ai précisé que c'était une pratique | > répandue mais incorrecte. | | J'ai bien vu que tu disais que c'est une pratique répandue. J'ai aussi | vu que tu disais que c'est une pratique incorrecte, ce qui est fausse. | C'est aussi correct que n'importe quel autre chose qui dépend de | l'implémentation.
Non.
-- Gaby
Gabriel Dos Reis
Samuel Krempp writes:
| le Wednesday 17 September 2003 07:31, ,bi(Bcrivit : | | > tu n'as pas à te flageler : mon utilisation de auto dans le message | > précédent n'est pas vraiment contenu dans le papier, même si elle y | > apparaît entre les lignes. | | et tu pourrais donner une estimation (sans garantie) du délai avant que ce | soit utilisable de manière à peu près portable ?
je n'ai aucune idée.
Il est probable que j'aie fini mes implémentations expérimentales avec GCC dans un an. Mais c'est sans garantie. Assez curieusement, je n'ai pas beaucoup de temps ces temps-ci pour jouer avec GCC (ne me demande pas comment cela se fait, je n'en sais rien).
| en lisant dans le marc de café, les tripes de membre de comité, ce que tu | veux, sans contrainte de fiabilité..
hmm, là j'ai peur de ne pas bien comprendre...
| (au fait il est où ce papier ?)
le truc dont je parle n'est pas encore décrit dans un papier. Le papier dont il était question est
une version un peu plus à jour sera disponible d'ici une semaine à peu près, dans la pre-Kona mailing. Mais ce n'est tout. Il te faut aussi lire d'autres propositions de BS ainsi que ses collaborateurs pour avoir une idée de l'ensemble.
En ce qui concerne l'utilisation de « auto » dont je parlais il est possible qu'il ait une proposition formelle pour la réunion de Sydney, i.e. pas avant Avril 2004 si nous ne sommes pas débordés.
-- Gaby
Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> writes:
| le Wednesday 17 September 2003 07:31, gdr@integrable-solutions.net ,bi(Bcrivit :
|
| > tu n'as pas à te flageler : mon utilisation de auto dans le message
| > précédent n'est pas vraiment contenu dans le papier, même si elle y
| > apparaît entre les lignes.
|
| et tu pourrais donner une estimation (sans garantie) du délai avant que ce
| soit utilisable de manière à peu près portable ?
je n'ai aucune idée.
Il est probable que j'aie fini mes implémentations expérimentales avec
GCC dans un an. Mais c'est sans garantie. Assez curieusement,
je n'ai pas beaucoup de temps ces temps-ci pour jouer avec GCC (ne me
demande pas comment cela se fait, je n'en sais rien).
| en lisant dans le marc de café, les tripes de membre de comité, ce que tu
| veux, sans contrainte de fiabilité..
hmm, là j'ai peur de ne pas bien comprendre...
| (au fait il est où ce papier ?)
le truc dont je parle n'est pas encore décrit dans un papier. Le
papier dont il était question est
une version un peu plus à jour sera disponible d'ici une semaine à peu
près, dans la pre-Kona mailing.
Mais ce n'est tout. Il te faut aussi lire d'autres propositions de BS
ainsi que ses collaborateurs pour avoir une idée de l'ensemble.
En ce qui concerne l'utilisation de « auto » dont je parlais il est
possible qu'il ait une proposition formelle pour la réunion de
Sydney, i.e. pas avant Avril 2004 si nous ne sommes pas débordés.
| le Wednesday 17 September 2003 07:31, ,bi(Bcrivit : | | > tu n'as pas à te flageler : mon utilisation de auto dans le message | > précédent n'est pas vraiment contenu dans le papier, même si elle y | > apparaît entre les lignes. | | et tu pourrais donner une estimation (sans garantie) du délai avant que ce | soit utilisable de manière à peu près portable ?
je n'ai aucune idée.
Il est probable que j'aie fini mes implémentations expérimentales avec GCC dans un an. Mais c'est sans garantie. Assez curieusement, je n'ai pas beaucoup de temps ces temps-ci pour jouer avec GCC (ne me demande pas comment cela se fait, je n'en sais rien).
| en lisant dans le marc de café, les tripes de membre de comité, ce que tu | veux, sans contrainte de fiabilité..
hmm, là j'ai peur de ne pas bien comprendre...
| (au fait il est où ce papier ?)
le truc dont je parle n'est pas encore décrit dans un papier. Le papier dont il était question est
une version un peu plus à jour sera disponible d'ici une semaine à peu près, dans la pre-Kona mailing. Mais ce n'est tout. Il te faut aussi lire d'autres propositions de BS ainsi que ses collaborateurs pour avoir une idée de l'ensemble.
En ce qui concerne l'utilisation de « auto » dont je parlais il est possible qu'il ait une proposition formelle pour la réunion de Sydney, i.e. pas avant Avril 2004 si nous ne sommes pas débordés.
