"Marc Boyer" a écrit dans le
message de news:
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,
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++.
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le
message de news: slrndcnsa5.jqi.Marc.Boyer@localhost.localdomain...
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,
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++.
"Marc Boyer" a écrit dans le
message de news:
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,
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++.
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.
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.
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.
Tu oublies un peu vite que le C++ a empreinté pas mal de
concepts issues d'autres langages nés avant lui.
Un GC possédent des inconvénients mais aussi des avantages, sinon pourquoi
aurait-il fait l'objet de dissusion ?
Pour argumenter, il faut connaitre un minimun son sujet.
Ca n'a pas l'air d'être le cas au vu de cette remarque.
Tu oublies un peu vite que le C++ a empreinté pas mal de
concepts issues d'autres langages nés avant lui.
Un GC possédent des inconvénients mais aussi des avantages, sinon pourquoi
aurait-il fait l'objet de dissusion ?
Pour argumenter, il faut connaitre un minimun son sujet.
Ca n'a pas l'air d'être le cas au vu de cette remarque.
Tu oublies un peu vite que le C++ a empreinté pas mal de
concepts issues d'autres langages nés avant lui.
Un GC possédent des inconvénients mais aussi des avantages, sinon pourquoi
aurait-il fait l'objet de dissusion ?
Pour argumenter, il faut connaitre un minimun son sujet.
Ca n'a pas l'air d'être le cas au vu de cette remarque.
"Stan" ( remove the dots )> writes:
Ce que les gens demandent, c'est une liste de ces « nombreux
langages. »
Moi aussi, j'ai mon langage avec son GC; mais il ne fait pas la mêe
chose que C++ et il n'a que 3 utilisateurs.
-- Gaby
"Stan" <z.y.l.o.g@wanadoo.fr ( remove the dots )> writes:
Ce que les gens demandent, c'est une liste de ces « nombreux
langages. »
Moi aussi, j'ai mon langage avec son GC; mais il ne fait pas la mêe
chose que C++ et il n'a que 3 utilisateurs.
-- Gaby
"Stan" ( remove the dots )> writes:
Ce que les gens demandent, c'est une liste de ces « nombreux
langages. »
Moi aussi, j'ai mon langage avec son GC; mais il ne fait pas la mêe
chose que C++ et il n'a que 3 utilisateurs.
-- Gaby
"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++.
"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++.
"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++.
"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 ?
"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 ?
"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 ?
Une question qui peut sembler naïve, mais
pourquoi une telle inertie concernant l'évolution du C++ ?
Une question qui peut sembler naïve, mais
pourquoi une telle inertie concernant l'évolution du C++ ?
Une question qui peut sembler naïve, mais
pourquoi une telle inertie concernant l'évolution du C++ ?
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.
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.)
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.
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.)
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.
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.)
