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++ Midterm mailing

Midterm mailing

74 réponses
Avatar
Gabriel Dos Reis
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-06

-- 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 4 5
Avatar
Gabriel Dos Reis
Marc Boyer writes:

[...]

| > As tu déja crée tes propres classes d'encapsulation des sockets ?
|
| Pas vraiment eut besoin de faire une "super classe générale",
| mais plutôt des mini trucs ad-hoc.
| Sans parler de cette proposition, la question que je me
| pose est celle de la "bonne" interface.
| La proposition reste assez bas niveau: transfer de flux de char,
| la contribution étant dans la gestion des erreurs et de IPv4/IPv6.
| Est-ce la bonne solution ? Est-ce qu'une bibliothèque réseau C++
| ne doit elle pas aussi gérer l'encodage des types primitifs ?
| Veut-on des flux typés ?
|
| Je ne me sens pas capable de répondre à ces questions,
| mais il me semble qu'elles doivent être discutées avant une
| normalisation.


Ce n'est pas rare de voir des gens venir dire que les autres langages
ont des GUI, sockets, GC etc. et que C++ n'en a pas et que c'est
incompréhensible. De fait, souvent le problème n'est pas que C++ n'a
aucune de ces bibliothèques. C'est en fait qu'il y en a plus d'une, chacune
avec ses avantages et ses défauts. L'un des problèmes est d'en prendre
une qui satisfait une bonne partie des gens intéressés par C++. Un
autre aspect, ce sont les ressources nécessaires pour faire une
contribution au standard ISO. Nombre des langages « concurrents » sont
propriétaires ou sponsorisés par des consortiums. La norme C++ est
largement le fruit de volontaires. La vraie question, pour moi, n'est pas
pourquoi une telle inertie concernant l'évolution de C++ ?
Ceux qui dépensent des ressources pour poser ces questions devraient,
à mon sens, les reallouer pour répondre à la question
« comment je peux contribuer à l'évolution de C++ ? ». Du moins, si
la réponse à la première question les intéresse.

Il faudra probablement attendre 2010* si on passe le plus clair de
notre temps à se poser ces questions. Aussif, il est utile de se
garder de « what is good for other languages is good enough for C++. »
Autrement, on risque de rentrer dans des perversions.

-- Gaby
Avatar
Stan
"Marc Boyer" a écrit dans le message
de news:
"Marc Boyer" a écrit dans le
message
de news:


Non, je voulais une liste des nombreux langages qui possèdes
GC + MT + API réseau, en restant sur le même marché que C++,
ie les langages généralistes ayant fait leurs preuves.


Heu, pourquoi ajouter plus de conditions que je ne l'ai fait ?
C'est pour réduire encore plus la liste ;-)
T'a oublié "...ayant fait leurs preuves et que j'affectionne
particulièrement. "

Ca s'interface bien ?
A quel coût ?


Pas supérieur à l'écriture en C il me semble.


Ce n'est pas un pb d'écriture mais d'intégration dans ton application
développé en C++.
Je suppose que tu essaies d'écrire des progs qui soient le plus proche de ce
qu'offre
la POO ?
Si tu veux implémenter une interface réseau, combien même serait-elle POSIX,
tu vas te retrouver avec une liste de fonctions;
si tu veux que ta classe soit vraiment ré-utilisable et fonctionnelle, ca
demande du temps.

As tu déja crée tes propres classes d'encapsulation des sockets ?


Pas vraiment eut besoin de faire une "super classe générale",
mais plutôt des mini trucs ad-hoc.


Moi aussi il m'est arriver d'en créer histoire d'isoler
l'implémentation. Mais pour qu'une telle classe soit vraiment
utile et pérenne, il faut penser à toute la gestion d'erreur et des
mécanismes
inhérent aux communication ( synchrone / asynchrone ).
Vois comment sont complexes ios_base et compagnie ds la STL !

Sans parler de cette proposition, la question que je me
pose est celle de la "bonne" interface.


Les mêmes questions ont dû se poser pour la gestion de flux ( je suppose ).

La proposition reste assez bas niveau: transfer de flux de char,
la contribution étant dans la gestion des erreurs et de IPv4/IPv6.
Est-ce la bonne solution ? Est-ce qu'une bibliothèque réseau C++
ne doit elle pas aussi gérer l'encodage des types primitifs ?
Veut-on des flux typés ?

Je ne me sens pas capable de répondre à ces questions,
mais il me semble qu'elles doivent être discutées avant une
normalisation.


Cela n'a-t-il pas toujours été le cas ?

--
-Stan


Avatar
Gabriel Dos Reis
Marc Boyer writes:

| >> >> En ce qui concerne les sockets, je ne suis pas sur que le
| >> >>besoin soit pattent: POSIX existe, s'interface bien avec
| >> >>C++.
| >
| > Je me démande s'il vaut même la peine de réagir à une bêtise
| > aussi grosse. Je crois qu'il s'agit plutôt d'un troll.
|
| Heuh, non. D'une naïveté que tu peines à imaginer
| peut-être, mais je ne voulais pas faire le Troll.
|
| >> > Ca s'interface bien ?
| >> > A quel coût ?
| >> > As tu déja crée tes propres classes d'encapsulation des
| >> > sockets ?
| >
| >> Ce coût est-il si dissuadant que ca ?
| >
| > Le coût, c'est que je ne peux pas utiliser mes classes dans les
| > interfaces avec d'autres bibliothèques. C'est un coût énorme,
| > prohibitif même. (Régarde tous les problèmes qu'on a avec
| > std::string et les bibliothèques qui précède la norme.)
|
| Je ne comprends pas ta remarque. Je dois être très à
| côoté de la plaque sur cette question.

Si le problème fondamental, c'est que C++ n'offrait aucun moyen pour
supporter ces facilités, alors il suffirait de décréter qu'on prend
une bibliothèque X -- avec invention des core language supports
correspondants.

Mais, dans le cas de C++, il y a souvent beaucoup de telles
bibliothèques déjà en utilisation. Si tu en mets une standard
(inventée ou existante) il faut qu'elle soit adoptée dans la pratique
par tout le monde. Mais cela n'est pas simple si les gens ne peuvent
pas l'interfacer avec leur code -- un projet est souvent évolutif. Une
fois que tu as intégré la nouvelle fonctionnalité, il faut repasser
par la case validation ; et ce n'est pas souvent gratuit (en
ressources). Souvent cela implique aussi changement d'ABI ; il ne faut
pas sous-estimer le coût.

Si tu inventes un langage propriétaire avec le budget qui va avec, ou
un langage dont il n'y a qu'une seule implémentation officielle, le
problème est moins accru.

Bref, la vrai question, à mon sens, n'est pas pourquoi une telle
inertie. Mais comment contribuer. Et là, on manque de ressources et
les gens sont toujours les bienvenus.

-- Gaby
Avatar
Marc Boyer
Le 07-07-2005, Stan a écrit :
"Marc Boyer" a écrit dans le message
de news:
"Marc Boyer" a écrit dans le
message
de news:


Non, je voulais une liste des nombreux langages qui possèdes
GC + MT + API réseau, en restant sur le même marché que C++,
ie les langages généralistes ayant fait leurs preuves.


Heu, pourquoi ajouter plus de conditions que je ne l'ai fait ?
C'est pour réduire encore plus la liste ;-)


Non, ce sont les 3 évolutions que tu as cité il me semble
dans ton message initial.

T'a oublié "...ayant fait leurs preuves et que j'affectionne
particulièrement. "


Pas du tout: cite C# si tu veux ;-)

Ca s'interface bien ?
A quel coût ?


Pas supérieur à l'écriture en C il me semble.


Ce n'est pas un pb d'écriture mais d'intégration dans ton application
développé en C++.
Je suppose que tu essaies d'écrire des progs qui soient le plus proche de ce
qu'offre la POO ?


Non, pas spécialement.

Si tu veux implémenter une interface réseau, combien même serait-elle POSIX,
tu vas te retrouver avec une liste de fonctions;
si tu veux que ta classe soit vraiment ré-utilisable et fonctionnelle, ca
demande du temps.


Je n'ai en effet pas tenté de faire une classe ré-utilisable et
fonctionnelle.

As tu déja crée tes propres classes d'encapsulation des sockets ?


Pas vraiment eut besoin de faire une "super classe générale",
mais plutôt des mini trucs ad-hoc.


Moi aussi il m'est arriver d'en créer histoire d'isoler
l'implémentation. Mais pour qu'une telle classe soit vraiment
utile et pérenne, il faut penser à toute la gestion d'erreur et des
mécanismes inhérent aux communication ( synchrone / asynchrone ).
Vois comment sont complexes ios_base et compagnie ds la STL !


Parce que, intégrés au langage, ils ont en effet une vocation
universelle.

C'est peut-être là le coeur du problème: écrire une classe
qui encapsule les sockets, c'est un exercice d'étudiant.
Ecrire une classe ayant la qualité suffisante pour répondre
aux besoins de 90% de la communauté C++ qui utilise le réseau,
c'est un autre jeu (dont je commence à peine à comprendre
les règles).

Sans parler de cette proposition, la question que je me
pose est celle de la "bonne" interface.


Les mêmes questions ont dû se poser pour la gestion de flux ( je suppose ).


Je n'y étais pas.

La proposition reste assez bas niveau: transfer de flux de char,
la contribution étant dans la gestion des erreurs et de IPv4/IPv6.
Est-ce la bonne solution ? Est-ce qu'une bibliothèque réseau C++
ne doit elle pas aussi gérer l'encodage des types primitifs ?
Veut-on des flux typés ?

Je ne me sens pas capable de répondre à ces questions,
mais il me semble qu'elles doivent être discutées avant une
normalisation.


Cela n'a-t-il pas toujours été le cas ?


As-tu vu ces question évoquées dans le papier que tu citais ?
Moi pas.

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?



Avatar
Marc Boyer
Gabriel Dos Reis a écrit :
Marc Boyer writes:
La vraie question, pour moi, n'est pas
pourquoi une telle inertie concernant l'évolution de C++ ?
Ceux qui dépensent des ressources pour poser ces questions devraient,
à mon sens, les reallouer pour répondre à la question
« comment je peux contribuer à l'évolution de C++ ? ». Du moins, si
la réponse à la première question les intéresse.


J'avoue que, pour ma part, si les évolutions de C++ m'intéressent,
je me sens bien incapables (limité par mes compétences) pour
y contribuer.

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?

Avatar
Stan
"Marc Boyer" a écrit dans le message
de news:
Je ne me sens pas capable de répondre à ces questions,
mais il me semble qu'elles doivent être discutées avant une
normalisation.


Cela n'a-t-il pas toujours été le cas ?


As-tu vu ces question évoquées dans le papier que tu citais ?
Moi pas.



Pour discuter de quelque chose, il faut une proposition.
Ce papier est une proposition, il faut bien apréhender le pb
par un bout;
si tu soulèves toutes les questions dès le départ, tu fais fuir tout le
monde ;-)

Je pense que toutes les évolutions précédentes ont dû être apprement
discutées avant d'être adoptées.

--
-Stan



Avatar
Marc Boyer
Le 07-07-2005, Stan a écrit :
"Marc Boyer" a écrit dans le message
de news:
Je ne me sens pas capable de répondre à ces questions,
mais il me semble qu'elles doivent être discutées avant une
normalisation.


Cela n'a-t-il pas toujours été le cas ?


As-tu vu ces question évoquées dans le papier que tu citais ?
Moi pas.


Pour discuter de quelque chose, il faut une proposition.
Ce papier est une proposition, il faut bien apréhender le pb
par un bout;
si tu soulèves toutes les questions dès le départ, tu fais fuir tout le
monde ;-)


Peut-être une déformation professionnelle: dans toute nouvelle
proposition, faire la liste des pbs qu'elle prétend rédoudre,
faire aussi la liste des principales propositions alternatives,
montrer en quoi la nouvelle est meilleure sur de nombreux points.

Après, je ne sais pas comment aime travailler les gens qui
contribuent à l'anvancée de C++.

Je pense que toutes les évolutions précédentes ont dû être apprement
discutées avant d'être adoptées.


J'imagine.

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?




Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Le 07-07-2005, Stan a écrit :
| > "Marc Boyer" a écrit dans le message
| > de news:
| >>>> Je ne me sens pas capable de répondre à ces questions,
| >>>> mais il me semble qu'elles doivent être discutées avant une
| >>>> normalisation.
| >>>
| >>> Cela n'a-t-il pas toujours été le cas ?
| >>
| >> As-tu vu ces question évoquées dans le papier que tu citais ?
| >> Moi pas.
| >
| > Pour discuter de quelque chose, il faut une proposition.
| > Ce papier est une proposition, il faut bien apréhender le pb
| > par un bout;
| > si tu soulèves toutes les questions dès le départ, tu fais fuir tout le
| > monde ;-)
|
| Peut-être une déformation professionnelle: dans toute nouvelle
| proposition, faire la liste des pbs qu'elle prétend rédoudre,
| faire aussi la liste des principales propositions alternatives,
| montrer en quoi la nouvelle est meilleure sur de nombreux points.
|
| Après, je ne sais pas comment aime travailler les gens qui
| contribuent à l'anvancée de C++.

C'est sûr que je n'ai pas vu des propositions sérieuses discutées
par le comité sans considérer ces aspects que tu mentionnes.

-- Gaby
Avatar
Stan
"Gabriel Dos Reis" a écrit dans le message de
news:
Marc Boyer writes:

largement le fruit de volontaires. La vraie question, pour moi, n'est pas
pourquoi une telle inertie concernant l'évolution de C++ ?
Ceux qui dépensent des ressources pour poser ces questions devraient,
à mon sens, les reallouer pour répondre à la question
« comment je peux contribuer à l'évolution de C++ ? ». Du moins, si
la réponse à la première question les intéresse.


Tu me ferai presque culpabiliser de poser des questions.
Ce n'est pas très pédagogique ;-)

--
-Stan

Avatar
Marc Boyer
Le 07-07-2005, Stan a écrit :
"Gabriel Dos Reis" a écrit dans le message de
news:
Marc Boyer writes:

largement le fruit de volontaires. La vraie question, pour moi, n'est pas
pourquoi une telle inertie concernant l'évolution de C++ ?
Ceux qui dépensent des ressources pour poser ces questions devraient,
à mon sens, les reallouer pour répondre à la question
« comment je peux contribuer à l'évolution de C++ ? ». Du moins, si
la réponse à la première question les intéresse.


Tu me ferai presque culpabiliser de poser des questions.
Ce n'est pas très pédagogique ;-)


Gabriel est un pédagogue décapant ;-)

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?


1 2 3 4 5