Une question qui peut sembler naïve, mais pourquoi une telle inertie concernant l'évolution du C++ ? Je pense notamment à : - A Proposal to Add Sockets to the Standard Library - Transparent Garbage Collection for C++ - ISO C++ Strategic Plan for Multithreading
Faudra-t-il attendre 2010* pour posséder un langage qui fasse ce que fait de nombreux autres langages ?
*date arbitraire -- - Stan
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
news: m3irzujbzc.fsf@uniton.integrable-solutions.net...
Une question qui peut sembler naïve, mais
pourquoi une telle inertie concernant l'évolution du C++ ?
Je pense notamment à :
- A Proposal to Add Sockets to the Standard Library
- Transparent Garbage Collection for C++
- ISO C++ Strategic Plan for Multithreading
Faudra-t-il attendre 2010* pour
posséder un langage qui fasse ce que fait
de nombreux autres langages ?
Une question qui peut sembler naïve, mais pourquoi une telle inertie concernant l'évolution du C++ ? Je pense notamment à : - A Proposal to Add Sockets to the Standard Library - Transparent Garbage Collection for C++ - ISO C++ Strategic Plan for Multithreading
Faudra-t-il attendre 2010* pour posséder un langage qui fasse ce que fait de nombreux autres langages ?
*date arbitraire -- - Stan
Marc Boyer
Le 06-07-2005, Stan a écrit :
"Gabriel Dos Reis" a écrit dans le message de news:
Une question qui peut sembler naïve, mais pourquoi une telle inertie concernant l'évolution du C++ ? Je pense notamment à : - A Proposal to Add Sockets to the Standard Library - Transparent Garbage Collection for C++ - ISO C++ Strategic Plan for Multithreading
Faudra-t-il attendre 2010* pour posséder un langage qui fasse ce que fait de nombreux autres langages ?
Quels nombreux autres ? Java ? Soulignons que Java résoud ne nombreux problèmes par l'adjonction d'une grosse couche intermédiaire, la JVM. Jusqu'à présent, il me semble que C++ essayait d'être plus prêt de la machine.
En ce qui concerne les sockets, je ne suis pas sur que le besoin soit pattent: POSIX existe, s'interface bien avec C++.
En ce qui concerne des choses comme le GC ou MT, je ne suis pas spécialiste (d'ailleurs, je suis pas spécialiste non plus en C++ ;-) ), mais ce qui me semble, c'est que s'il est facile de voir un problème, relativement facile de faire *une* solution, ce qui est difficile, c'est de faire une *bonne* solution. Car, avec la règle de compatibilité ascendante, si on a fait un mauvais choix, ben, on le garde longtemps...
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Le 06-07-2005, Stan <z.y.l.o.g@wanadoo.fr> a écrit :
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
news: m3irzujbzc.fsf@uniton.integrable-solutions.net...
Une question qui peut sembler naïve, mais
pourquoi une telle inertie concernant l'évolution du C++ ?
Je pense notamment à :
- A Proposal to Add Sockets to the Standard Library
- Transparent Garbage Collection for C++
- ISO C++ Strategic Plan for Multithreading
Faudra-t-il attendre 2010* pour
posséder un langage qui fasse ce que fait
de nombreux autres langages ?
Quels nombreux autres ? Java ? Soulignons que Java
résoud ne nombreux problèmes par l'adjonction d'une
grosse couche intermédiaire, la JVM. Jusqu'à présent,
il me semble que C++ essayait d'être plus prêt de la
machine.
En ce qui concerne les sockets, je ne suis pas sur que le
besoin soit pattent: POSIX existe, s'interface bien avec
C++.
En ce qui concerne des choses comme le GC ou MT, je ne
suis pas spécialiste (d'ailleurs, je suis pas spécialiste non
plus en C++ ;-) ), mais ce qui me semble, c'est que s'il est
facile de voir un problème, relativement facile de faire
*une* solution, ce qui est difficile, c'est de faire une
*bonne* solution.
Car, avec la règle de compatibilité ascendante,
si on a fait un mauvais choix, ben, on le garde longtemps...
Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?
Une question qui peut sembler naïve, mais pourquoi une telle inertie concernant l'évolution du C++ ? Je pense notamment à : - A Proposal to Add Sockets to the Standard Library - Transparent Garbage Collection for C++ - ISO C++ Strategic Plan for Multithreading
Faudra-t-il attendre 2010* pour posséder un langage qui fasse ce que fait de nombreux autres langages ?
Quels nombreux autres ? Java ? Soulignons que Java résoud ne nombreux problèmes par l'adjonction d'une grosse couche intermédiaire, la JVM. Jusqu'à présent, il me semble que C++ essayait d'être plus prêt de la machine.
En ce qui concerne les sockets, je ne suis pas sur que le besoin soit pattent: POSIX existe, s'interface bien avec C++.
En ce qui concerne des choses comme le GC ou MT, je ne suis pas spécialiste (d'ailleurs, je suis pas spécialiste non plus en C++ ;-) ), mais ce qui me semble, c'est que s'il est facile de voir un problème, relativement facile de faire *une* solution, ce qui est difficile, c'est de faire une *bonne* solution. Car, avec la règle de compatibilité ascendante, si on a fait un mauvais choix, ben, on le garde longtemps...
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Jean-Marc Bourguet
"Stan" ( remove the dots )> writes:
"Gabriel Dos Reis" a écrit dans le message de news:
Une question qui peut sembler naïve, mais pourquoi une telle inertie concernant l'évolution du C++ ?
Je pense notamment à : - A Proposal to Add Sockets to the Standard Library - Transparent Garbage Collection for C++ - ISO C++ Strategic Plan for Multithreading
Faudra-t-il attendre 2010* pour posséder un langage qui fasse ce que fait de nombreux autres langages ?
Tu peux donner ta liste? J'ai du mal a aller plus loin que trois noms en restant dans des langages avec plus ou moins la meme vocation. Et encore, pour l'un je suis genereux en ce qui concerne les sockets (il a une interface pour l'execution distribuee mais ce n'est pas reellement une interface pour les sockets).
(Des trois langages auxquels je pensais, un seul a une norme ISO; les societes derrieres les deux autres ont soit abandonne l'idee de normalisation, soit opte pour un systeme beaucoup plus souple).
L'histoire aussi, un langage dont la conception remonte au debut des annees 80, dont un des principes de conception etait la compatibilite forte avec un langage plus ancien a des contraintes (a nouveau de ma liste, seul celui avec la norme ISO est aussi vieux et les principes sur lesquels il est base sont differents).
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
"Stan" <z.y.l.o.g@wanadoo.fr ( remove the dots )> writes:
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
news: m3irzujbzc.fsf@uniton.integrable-solutions.net...
Une question qui peut sembler naïve, mais pourquoi une telle inertie
concernant l'évolution du C++ ?
Je pense notamment à :
- A Proposal to Add Sockets to the Standard Library
- Transparent Garbage Collection for C++
- ISO C++ Strategic Plan for Multithreading
Faudra-t-il attendre 2010* pour
posséder un langage qui fasse ce que fait
de nombreux autres langages ?
Tu peux donner ta liste? J'ai du mal a aller plus loin que trois noms
en restant dans des langages avec plus ou moins la meme vocation. Et
encore, pour l'un je suis genereux en ce qui concerne les sockets (il
a une interface pour l'execution distribuee mais ce n'est pas
reellement une interface pour les sockets).
(Des trois langages auxquels je pensais, un seul a une norme ISO; les
societes derrieres les deux autres ont soit abandonne l'idee de
normalisation, soit opte pour un systeme beaucoup plus souple).
L'histoire aussi, un langage dont la conception remonte au debut des
annees 80, dont un des principes de conception etait la compatibilite
forte avec un langage plus ancien a des contraintes (a nouveau de ma
liste, seul celui avec la norme ISO est aussi vieux et les principes
sur lesquels il est base sont differents).
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
Une question qui peut sembler naïve, mais pourquoi une telle inertie concernant l'évolution du C++ ?
Je pense notamment à : - A Proposal to Add Sockets to the Standard Library - Transparent Garbage Collection for C++ - ISO C++ Strategic Plan for Multithreading
Faudra-t-il attendre 2010* pour posséder un langage qui fasse ce que fait de nombreux autres langages ?
Tu peux donner ta liste? J'ai du mal a aller plus loin que trois noms en restant dans des langages avec plus ou moins la meme vocation. Et encore, pour l'un je suis genereux en ce qui concerne les sockets (il a une interface pour l'execution distribuee mais ce n'est pas reellement une interface pour les sockets).
(Des trois langages auxquels je pensais, un seul a une norme ISO; les societes derrieres les deux autres ont soit abandonne l'idee de normalisation, soit opte pour un systeme beaucoup plus souple).
L'histoire aussi, un langage dont la conception remonte au debut des annees 80, dont un des principes de conception etait la compatibilite forte avec un langage plus ancien a des contraintes (a nouveau de ma liste, seul celui avec la norme ISO est aussi vieux et les principes sur lesquels il est base sont differents).
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
Stan
"Marc Boyer" a écrit dans le message de news:
Quels nombreux autres ? Java ? Soulignons que Java résoud ne nombreux problèmes par l'adjonction d'une grosse couche intermédiaire, la JVM. Jusqu'à présent, il me semble que C++ essayait d'être plus prêt de la machine.
Quand je disais "de nombreux langages" j'inclus aussi ceux qui ne sont pas OO. Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
En ce qui concerne les sockets, je ne suis pas sur que le besoin soit pattent: POSIX existe, s'interface bien avec C++.
Ca s'interface bien ? A quel coût ? As tu déja crée tes propres classes d'encapsulation des sockets ?
-- -Stan
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrndcnsa5.jqi.Marc.Boyer@localhost.localdomain...
Quels nombreux autres ? Java ? Soulignons que Java
résoud ne nombreux problèmes par l'adjonction d'une
grosse couche intermédiaire, la JVM. Jusqu'à présent,
il me semble que C++ essayait d'être plus prêt de la
machine.
Quand je disais "de nombreux langages" j'inclus aussi ceux
qui ne sont pas OO.
Des concepts comme le GC ne datent pas d'hier et de nombreux
langage en disposent.
En ce qui concerne les sockets, je ne suis pas sur que le
besoin soit pattent: POSIX existe, s'interface bien avec
C++.
Ca s'interface bien ?
A quel coût ?
As tu déja crée tes propres classes d'encapsulation des sockets ?
Quels nombreux autres ? Java ? Soulignons que Java résoud ne nombreux problèmes par l'adjonction d'une grosse couche intermédiaire, la JVM. Jusqu'à présent, il me semble que C++ essayait d'être plus prêt de la machine.
Quand je disais "de nombreux langages" j'inclus aussi ceux qui ne sont pas OO. Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
En ce qui concerne les sockets, je ne suis pas sur que le besoin soit pattent: POSIX existe, s'interface bien avec C++.
Ca s'interface bien ? A quel coût ? As tu déja crée tes propres classes d'encapsulation des sockets ?
-- -Stan
Fabien LE LEZ
On Wed, 6 Jul 2005 19:12:49 +0200, "Stan" ( remove the dots )>:
Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement contraire à l'idée de GC : on crée un objet, il est automatiquement détruit en fin de bloc (ni avant, ni après), et tout va bien.
On Wed, 6 Jul 2005 19:12:49 +0200, "Stan" <z.y.l.o.g@wanadoo.fr (
remove the dots )>:
Des concepts comme le GC ne datent pas d'hier et de nombreux
langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement
contraire à l'idée de GC : on crée un objet, il est automatiquement
détruit en fin de bloc (ni avant, ni après), et tout va bien.
On Wed, 6 Jul 2005 19:12:49 +0200, "Stan" ( remove the dots )>:
Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement contraire à l'idée de GC : on crée un objet, il est automatiquement détruit en fin de bloc (ni avant, ni après), et tout va bien.
Stan
"Fabien LE LEZ" a écrit dans le message de news:
On Wed, 6 Jul 2005 19:12:49 +0200, "Stan" ( remove the dots )>:
Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement contraire à l'idée de GC : on crée un objet, il est automatiquement détruit en fin de bloc (ni avant, ni après), et tout va bien.
Moins bien avec l'usage de new.
-- -Stan
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
eq4oc19aopdql842hnn63st8ln7n7pj9tm@4ax.com...
On Wed, 6 Jul 2005 19:12:49 +0200, "Stan" <z.y.l.o.g@wanadoo.fr (
remove the dots )>:
Des concepts comme le GC ne datent pas d'hier et de nombreux
langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement
contraire à l'idée de GC : on crée un objet, il est automatiquement
détruit en fin de bloc (ni avant, ni après), et tout va bien.
On Wed, 6 Jul 2005 19:12:49 +0200, "Stan" ( remove the dots )>:
Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement contraire à l'idée de GC : on crée un objet, il est automatiquement détruit en fin de bloc (ni avant, ni après), et tout va bien.
Moins bien avec l'usage de new.
-- -Stan
Anthony Fleury
"Marc Boyer" a écrit dans le message de news:
Quand je disais "de nombreux langages" j'inclus aussi ceux qui ne sont pas OO. Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
Et alors ? parce que c'est disponible dans d'autres langages on devrait l'ajouter dans C++ ? Je ne sais pas si c'est l'avis des autres programmeurs C++ ou si la majorité est contre moi, mais pour ma part je ne veux pas d'un GC dans C++. Quand j'ai une variable en C++, je sais qu'elle sera détruite à la fin du bloc si c'est une variable automatique, à la fin du programme si c'est une static, et quand je vais faire un delete pour une variable allouée dynamiquement. Pourquoi avoir un GC ?? (enfin perso si il est inclut ca me plairait de récupérer le comportement normal de mon compilateur C++)
En ce qui concerne les sockets, je ne suis pas sur que le besoin soit pattent: POSIX existe, s'interface bien avec C++.
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 ? et requiert-il vraiment que des concepts comme les sockets soient inclus dans la bibliothèque standard d'un langage qui se veut plus général que ca ? En fait, le concept de socket me parait trop "proche de l'OS" (et loin de l'idée que je me fais des langages tels que C et C++) pour être mis dans C++, de même je ne vois pas, comme java, mettre le concept d'interface graphique dans C++.
-- Anthony Fleury
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrndcnsa5.jqi.Marc.Boyer@localhost.localdomain...
Quand je disais "de nombreux langages" j'inclus aussi ceux
qui ne sont pas OO.
Des concepts comme le GC ne datent pas d'hier et de nombreux
langage en disposent.
Et alors ? parce que c'est disponible dans d'autres langages on devrait
l'ajouter dans C++ ? Je ne sais pas si c'est l'avis des autres
programmeurs C++ ou si la majorité est contre moi, mais pour ma part je
ne veux pas d'un GC dans C++. Quand j'ai une variable en C++, je sais
qu'elle sera détruite à la fin du bloc si c'est une variable
automatique, à la fin du programme si c'est une static, et quand je vais
faire un delete pour une variable allouée dynamiquement. Pourquoi avoir
un GC ?? (enfin perso si il est inclut ca me plairait de récupérer le
comportement normal de mon compilateur C++)
En ce qui concerne les sockets, je ne suis pas sur que le
besoin soit pattent: POSIX existe, s'interface bien avec
C++.
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 ? et requiert-il vraiment que des
concepts comme les sockets soient inclus dans la bibliothèque standard
d'un langage qui se veut plus général que ca ? En fait, le concept de
socket me parait trop "proche de l'OS" (et loin de l'idée que je me fais
des langages tels que C et C++) pour être mis dans C++, de même je ne
vois pas, comme java, mettre le concept d'interface graphique dans C++.
Quand je disais "de nombreux langages" j'inclus aussi ceux qui ne sont pas OO. Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
Et alors ? parce que c'est disponible dans d'autres langages on devrait l'ajouter dans C++ ? Je ne sais pas si c'est l'avis des autres programmeurs C++ ou si la majorité est contre moi, mais pour ma part je ne veux pas d'un GC dans C++. Quand j'ai une variable en C++, je sais qu'elle sera détruite à la fin du bloc si c'est une variable automatique, à la fin du programme si c'est une static, et quand je vais faire un delete pour une variable allouée dynamiquement. Pourquoi avoir un GC ?? (enfin perso si il est inclut ca me plairait de récupérer le comportement normal de mon compilateur C++)
En ce qui concerne les sockets, je ne suis pas sur que le besoin soit pattent: POSIX existe, s'interface bien avec C++.
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 ? et requiert-il vraiment que des concepts comme les sockets soient inclus dans la bibliothèque standard d'un langage qui se veut plus général que ca ? En fait, le concept de socket me parait trop "proche de l'OS" (et loin de l'idée que je me fais des langages tels que C et C++) pour être mis dans C++, de même je ne vois pas, comme java, mettre le concept d'interface graphique dans C++.
-- Anthony Fleury
Cyrille
"Fabien LE LEZ" a écrit dans le message de news:
Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement contraire à l'idée de GC : on crée un objet, il est automatiquement détruit en fin de bloc (ni avant, ni après), et tout va bien.
Moins bien avec l'usage de new.
L'une des raisons principales d'utiliser new/delete, c'est d'avoir un contrôle fin sur la désallocation, justement. Avec un GC, il n'y aucune manière de savoir quand un destructeur va être appelé. D'ailleurs, comme un fait exprès, Java n'a pas de destructeur. Je ne sais pas comment se démerde C#, d'ailleurs, à ce sujet.
Certes, le C++ permet de garder un pointeur sur un objet qui a été détruit, ce qui peut créer des problèmes. On peut le résoudre dans la plupart des cas en disciplinant son code, ou encore avec des pointeurs intelligents comme boost::shared_ptr (est-ce que c'est dans le tuyau pour la standardisation, ça?).
-- "I have nothing to declare except war on Austria." ~ Oscar Wilde, 1936
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
eq4oc19aopdql842hnn63st8ln7n7pj9tm@4ax.com...
Des concepts comme le GC ne datent pas d'hier et de nombreux
langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement
contraire à l'idée de GC : on crée un objet, il est automatiquement
détruit en fin de bloc (ni avant, ni après), et tout va bien.
Moins bien avec l'usage de new.
L'une des raisons principales d'utiliser new/delete, c'est d'avoir un
contrôle fin sur la désallocation, justement. Avec un GC, il n'y aucune
manière de savoir quand un destructeur va être appelé. D'ailleurs, comme
un fait exprès, Java n'a pas de destructeur. Je ne sais pas comment se
démerde C#, d'ailleurs, à ce sujet.
Certes, le C++ permet de garder un pointeur sur un objet qui a été
détruit, ce qui peut créer des problèmes. On peut le résoudre dans la
plupart des cas en disciplinant son code, ou encore avec des pointeurs
intelligents comme boost::shared_ptr (est-ce que c'est dans le tuyau
pour la standardisation, ça?).
--
"I have nothing to declare except war on Austria." ~ Oscar Wilde, 1936
Des concepts comme le GC ne datent pas d'hier et de nombreux langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement contraire à l'idée de GC : on crée un objet, il est automatiquement détruit en fin de bloc (ni avant, ni après), et tout va bien.
Moins bien avec l'usage de new.
L'une des raisons principales d'utiliser new/delete, c'est d'avoir un contrôle fin sur la désallocation, justement. Avec un GC, il n'y aucune manière de savoir quand un destructeur va être appelé. D'ailleurs, comme un fait exprès, Java n'a pas de destructeur. Je ne sais pas comment se démerde C#, d'ailleurs, à ce sujet.
Certes, le C++ permet de garder un pointeur sur un objet qui a été détruit, ce qui peut créer des problèmes. On peut le résoudre dans la plupart des cas en disciplinant son code, ou encore avec des pointeurs intelligents comme boost::shared_ptr (est-ce que c'est dans le tuyau pour la standardisation, ça?).
-- "I have nothing to declare except war on Austria." ~ Oscar Wilde, 1936
Fabien LE LEZ
On Wed, 6 Jul 2005 19:50:57 +0200, "Stan" ( remove the dots )>:
Moins bien avec l'usage de new.
On utilise rarement new tout seul. Généralement, il s'accompagne d'un pointeur intelligent (dans le sens le plus large possible du terme, i.e. un objet qui a le delete correspondant dans son destructeur).
On Wed, 6 Jul 2005 19:50:57 +0200, "Stan" <z.y.l.o.g@wanadoo.fr (
remove the dots )>:
Moins bien avec l'usage de new.
On utilise rarement new tout seul. Généralement, il s'accompagne d'un
pointeur intelligent (dans le sens le plus large possible du terme,
i.e. un objet qui a le delete correspondant dans son destructeur).
On Wed, 6 Jul 2005 19:50:57 +0200, "Stan" ( remove the dots )>:
Moins bien avec l'usage de new.
On utilise rarement new tout seul. Généralement, il s'accompagne d'un pointeur intelligent (dans le sens le plus large possible du terme, i.e. un objet qui a le delete correspondant dans son destructeur).
Fabien LE LEZ
On Wed, 06 Jul 2005 19:51:04 +0200, Anthony Fleury :
En fait, le concept de socket me parait trop "proche de l'OS" (et loin de l'idée que je me fais des langages tels que C et C++) pour être mis dans C++,
D'autant qu'en fait, les sockets sont déjà standardisés. Je ne vois pas l'utilité pour le comité de standardisation du C++ de rajouter une standardisation par-dessus.
de même je ne vois pas, comme java, mettre le concept d'interface graphique dans C++.
Ce point de vue ne semble pas faire l'unanimité ici. Les capacités des diverses interfaces graphiques (Windows, différents X, etc.) varient ; aussi, on s'aperçoit que si on veut faire quelque chose de portable (avec wxWidgets par exemple), on est limité au dénominateur commun, et on perd certaines fonctionnalités.
Aussi, si je souhaite développer une application pour Windows uniquement, une bibliothèque graphique portable ne conviendra pas forcément, car trop limitée.
Si en plus on désire sortir du "petit" monde Windows/*nix, on risque de se retrouver avec une bibliothèque GUI certes portable, mais inutilisable car trop limitée.
On Wed, 06 Jul 2005 19:51:04 +0200, Anthony Fleury
<fleury_anthony@hotmail.com_>:
En fait, le concept de
socket me parait trop "proche de l'OS" (et loin de l'idée que je me fais
des langages tels que C et C++) pour être mis dans C++,
D'autant qu'en fait, les sockets sont déjà standardisés. Je ne vois
pas l'utilité pour le comité de standardisation du C++ de rajouter une
standardisation par-dessus.
de même je ne
vois pas, comme java, mettre le concept d'interface graphique dans C++.
Ce point de vue ne semble pas faire l'unanimité ici.
Les capacités des diverses interfaces graphiques (Windows, différents
X, etc.) varient ; aussi, on s'aperçoit que si on veut faire quelque
chose de portable (avec wxWidgets par exemple), on est limité au
dénominateur commun, et on perd certaines fonctionnalités.
Aussi, si je souhaite développer une application pour Windows
uniquement, une bibliothèque graphique portable ne conviendra pas
forcément, car trop limitée.
Si en plus on désire sortir du "petit" monde Windows/*nix, on risque
de se retrouver avec une bibliothèque GUI certes portable, mais
inutilisable car trop limitée.
On Wed, 06 Jul 2005 19:51:04 +0200, Anthony Fleury :
En fait, le concept de socket me parait trop "proche de l'OS" (et loin de l'idée que je me fais des langages tels que C et C++) pour être mis dans C++,
D'autant qu'en fait, les sockets sont déjà standardisés. Je ne vois pas l'utilité pour le comité de standardisation du C++ de rajouter une standardisation par-dessus.
de même je ne vois pas, comme java, mettre le concept d'interface graphique dans C++.
Ce point de vue ne semble pas faire l'unanimité ici. Les capacités des diverses interfaces graphiques (Windows, différents X, etc.) varient ; aussi, on s'aperçoit que si on veut faire quelque chose de portable (avec wxWidgets par exemple), on est limité au dénominateur commun, et on perd certaines fonctionnalités.
Aussi, si je souhaite développer une application pour Windows uniquement, une bibliothèque graphique portable ne conviendra pas forcément, car trop limitée.
Si en plus on désire sortir du "petit" monde Windows/*nix, on risque de se retrouver avec une bibliothèque GUI certes portable, mais inutilisable car trop limitée.
