au sujet d un acces curieux a un string ...

hello

mais en mettre une petite par defaut serait une aide a bcp de personnes !

Mais serait un défaut pour de bien plus nombreuses personnes.

cela reste a prouver

partout ou je suis alle, les programmeurs cherchaient de petites
extensions de base pour divers travaux ...
a l'heure actuelle, je ne connais quasiment personne qui ne souhaiterait
pas au moins une gestion de base du graphisme, meme incomplete... et
combien sont obliges de cherche une solution de ci de la...

comme pour python, et tkinter ... on l'a quasiment d'office, et si on
n'aime pas , on peut prndre wxpython ou tout autre chose...
mais au moins, de java a python en passant par tcl et consort, on a un
minimum de base... qu'on peut critiquer, mais on l'a ...

il me parait normal, a l'epoque actuelle qu'un langage ai des bases dans
ce domaine...
dans le cpp, tout le monde n'aime pas le cin, pourtant il y est par defaut.

je suis d'accord avec vous pour les gros projets : des briques de base
normes ne servent pas... mais elles sont vitales pour bcp de petits
projets ...

de meme un simple gestion de fenetre avec 2 ou 3 widgets d'i/o
aideraient bcp de monde, ne vexant que les puristes qui oublient un peu
rapidement qu'un langage sert aussi beaucoup a de petites societes qui
ont autre chose a faire que de se taper wxwindos et le bazooka juste
pour avoir une fenetre ... il n'y a pas que les gros projets qui existent :(

je prend l'exemple de tk pour sa simplicite pour des aplli de base. il
ne devrait pas etre dur d'integrer cela comme point de depart ...
tout comme on considere qu'on n'est pas oblige d'utiliser toutes les
fontionnalites du cpp, celui qui n'aime pas utilisera autre chose !

@+
ricky

"ricky" <eric_nyme@yahoo.fr> a écrit dans le message de
news:btlait$hhu$1@news-reader3.wanadoo.fr...

hello

mais en mettre une petite par defaut serait une aide a bcp de personnes
!

Mais serait un défaut pour de bien plus nombreuses personnes.

cela reste a prouver

partout ou je suis alle, les programmeurs cherchaient de petites
extensions de base pour divers travaux ...
a l'heure actuelle, je ne connais quasiment personne qui ne souhaiterait
pas au moins une gestion de base du graphisme, meme incomplete... et
combien sont obliges de cherche une solution de ci de la...

Parfaitement d'accord avec Ricky, il me semble que pas mal de monde cherche
des fonctionnalités graphiques là ou il n'y en a pas : c'est-à-dire dans
C++.
Ne serait-il pas possible de faire une petite extension en profitant par
exemple d'OpenGl, qui n'est pas une norme propriétaire ?
Ca choquera peut-être ceux qui on l'habitude de manipuler C++ et les
librairies satellites, mais AMHA ce serait un progres.
A+
un noob :-)

Alain Naigeon wrote:

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
news: btgv2f$kod$1@news.cict.fr...

ricky wrote:

Plus exactement, un langage qui laisse le programmeur choisir sa
bibliothèque GUI ;-)

mouais
mais en mettre une petite par defaut serait une aide a bcp de personnes

Mais serait un défaut pour de bien plus nombreuses personnes.

"default" = pris en compte si et seulement si rien d'autre
n'est choisi ; comme je suis sûr que tu le sais mieux que moi,
j'ai l'impression que ta réponse ressemble à un coup de pied
en touche ;-)

Non, elle est minimalement polémique, mais j'ai des arguments
derrière.
1) elle obligerait les gens qui veulent faire un compilateur
conforme à implémenter cette GUI, ce qui leur ferait perdre du
temps, qui ne serait pas passé à autre chose. Si en plus on
désire écrire un compilateur multi-plateforme (genre g++),
on plombe tout le développement. Pour g++, soit il renconce
à la portabilité, soit il renonce à implémenter cette GUI.
Dans les deux cas, les utilisateurs sont perdants.
2) elle aurait un effet "attracteur": énormément de
projet, pour résoudre les problèmes de portabilité,
prendrait cette GUI, donc à terme exigerait qu'elle soit
de qualité, d'y ajouter des choses. Déjà que BS se bat
pour ne pas ajouter trop de choses dans C++, il
serait submergé dans ce cas. Par exemple, combien
d'applis Java ont une IHM autre que swing ?
3) on se retrouverait avec au minimum 3 niveaux
de plateforme: sans écran, avec mode console, avec
système de type fenêtres carrées (Windows, X...),
donc combien de définitions pour la GUI.
4) Un potentiel problème grave de perénité: qui
peut prétendre que l'on va continuer à communiquer
avec une machine principalement avec un clavier et
un écran ?
5) ça s'oppose a tout ce qu'on enseigne en conception
d'IHM sérieux, ou on découple le modèle et la vue
(le cas du controle étant compliqué)


Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

ricky wrote:

mais en mettre une petite par defaut serait une aide a bcp de personnes !

Mais serait un défaut pour de bien plus nombreuses personnes.

cela reste a prouver

Oui, c'est le genre d'affirmation ou la preuve serait
couteuse. Mais une argumentation, on peut tenter.

partout ou je suis alle, les programmeurs cherchaient de petites
extensions de base pour divers travaux ...

Et elles existent: tk par exemple.

a l'heure actuelle, je ne connais quasiment personne qui ne souhaiterait
pas au moins une gestion de base du graphisme, meme incomplete...

Demandes à James, à Gaby. Moi, je serais contre, j'ai dit
pourquoi dans la réponse à Alain. Mais je ne pense pas
avoir un quelconque poids sur l'avenir de C++.

comme pour python, et tkinter ... on l'a quasiment d'office, et si on
n'aime pas , on peut prndre wxpython ou tout autre chose...
mais au moins, de java a python en passant par tcl et consort, on a un
minimum de base... qu'on peut critiquer, mais on l'a ...

il me parait normal, a l'epoque actuelle qu'un langage ai des bases dans
ce domaine...

Ca dépend de ce qu'on attend d'un langage. J'ai plus le DnE sous la
main, mais BS y dit bien que C++ n'est qu'un langage, pas un système.
On a déjà assez de mal à avoir un bon langage C++, je ne pense
pas le temps venu d'avoir une bonne GUI C++.

dans le cpp, tout le monde n'aime pas le cin, pourtant il y est par defaut.

Quelle plateforme n'offre pas d'entrée orienté charactère
à ses programmes ?

je suis d'accord avec vous pour les gros projets : des briques de base
normes ne servent pas... mais elles sont vitales pour bcp de petits
projets ...

Tk ? Java ?

de meme un simple gestion de fenetre avec 2 ou 3 widgets d'i/o
aideraient bcp de monde, ne vexant que les puristes qui oublient un peu
rapidement qu'un langage sert aussi beaucoup a de petites societes qui
ont autre chose a faire que de se taper wxwindos et le bazooka juste
pour avoir une fenetre ... il n'y a pas que les gros projets qui existent :(

Le fait que tu considères wxwindows comme "trop lourd" aurait
tendance à me faire dire qu'on ne sait pas faire pour les GUI
se qu'on commence à savoir faire avec C++ (et d'autres langages):
un système portable, qui soit accessible aux petits projets
et qui monte en charge jusqu'aux très gros.

je prend l'exemple de tk pour sa simplicite pour des aplli de base. il
ne devrait pas etre dur d'integrer cela comme point de depart ...

Ben, prends Tk, non ?
Un coup de Google "Tk C++" me donne 354.000 réponses, dont 9 des
10 de la première page me semble adéquates pour ce que tu demandes.

tout comme on considere qu'on n'est pas oblige d'utiliser toutes les
fontionnalites du cpp, celui qui n'aime pas utilisera autre chose !

Cf ma réponse à Alain.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

bonjour

1) elle obligerait les gens qui veulent faire un compilateur
conforme à implémenter cette GUI, ce qui leur ferait perdre du
temps, qui ne serait pas passé à autre chose.

cela leur derait perdre leur temps parceque pour toi c'est peu important
cette parti
pour d'autres c'est tres important

et ce raisonnement tu peux le faire pour quasiment tout developpement,
donc on gele definitivement le c++ :(

Si en plus on
désire écrire un compilateur multi-plateforme (genre g++),
on plombe tout le développement.

pourquoi alors c'est possible dans la plupart des autres langages ?
java, tcl, python, etc marchent multi plateforme ! pourquoi le cpp
serait plus bloque qu'eux???

Pour g++, soit il renconce
à la portabilité, soit il renonce à implémenter cette GUI.
Dans les deux cas, les utilisateurs sont perdants.

non parcequ'avec ce raisonnement on ne fait surtout plus rien !
tout peut etre source de divergence et de probleme de portabilite
exemple ? le int dans le for ... bomm incompatible avec les premiers
compilateurs (pour la portee), pourtant cela a ete fait sauf pour visual
c, etc etc

et puis, desole mais wxwindows y arrive, donc pourquoi ne pas mettre un
sous ensemble simple ???

2) elle aurait un effet "attracteur": énormément de
projet, pour résoudre les problèmes de portabilité,
prendrait cette GUI, donc à terme exigerait qu'elle soit
de qualité, d'y ajouter des choses.

encore une fois, cela n'a jamais ete demande a tk par exemple
ceux qui voulaient mieux avaient les moyens de se donner de la peine

tous tes arguments sont des suppositions qui ne tiennent pas devant tous
ceux qui ont besoin d'une interface minimaliste...
la preuve en est le nombre de verrue avec tcl juste pour obtenir une
fenetre a la noix

pour ne pas ajouter trop de choses dans C++, il
serait submergé dans ce cas.

ce ne serait pas forcement a lui de le faire
ensuite un langage se doit de faire le minimum requis
il ne s'agit pas d'ajouter trop de chose mais d'ajouter du vital
meme les string etaient moins vitales que ca, car au moins avec des char
* on peut les emuler alors que le graphisme et les directory nada

le boost a regle mes problemes saufs pour le graphisme!
et encore, je ne demande pas du graphisme mais un minimuml d'interface

on vit dans un monde ou les os ne sont plus textuels. le minimum serait
que les langages en tiennet compte desole ...

Par exemple, combien
d'applis Java ont une IHM autre que swing ?

il y a toutes les combinaisons possibles, mais au moins, il y a la base ...

3) on se retrouverait avec au minimum 3 niveaux
de plateforme: sans écran, avec mode console, avec
système de type fenêtres carrées (Windows, X...),
donc combien de définitions pour la GUI.

encore une fois tous les autres langages quasiment se dirigent vers ca..
en quoi le cpp serait plus obtus ?
on vit dans un monde ou cela exite .. autant le prendre en compte

4) Un potentiel problème grave de perénité: qui
peut prétendre que l'on va continuer à communiquer
avec une machine principalement avec un clavier et
un écran ?

qui peut pretendre qu'on aura encore des zones memoires ou une
architecture xo neumann plus tard?
personne
faut arreter la parano...
avec ce raisonnement je ne fais plus rien .. qui me prouve que
l'ordinateur existera encore ?

5) ça s'oppose a tout ce qu'on enseigne en conception
d'IHM sérieux, ou on découple le modèle et la vue
(le cas du controle étant compliqué)

encore une fois, tu t'oppose a la realite
on n'est plus a la fac
tout comme les bases canoniques sont une heresie au point de vue
rentabilite (le but d'une entreprise), une base graphique apporterait
beaucoup de chose a la majorite des projets
et desole mais regarde la taille et la simplicite de tk .. ce serait
assez simple de l'integrer a une stl sans toucher a la sacro sainte
bible du cpp

@+
ricky

Mahello

Oui, c'est le genre d'affirmation ou la preuve serait
couteuse. Mais une argumentation, on peut tenter.

amha meme pas
moi je me suis ballade dans bcdp de pme pour mon travail
et quasiment TOUS les programmeurs ralaient et il y en a eu au mojns 10%
qui ont quitte le cpp rien que pour ca

perso j'ai fourni bcp de pgm en cpp + tcl qui les aidaient enormement a
develpper leur petit truc pour pas un sou

Et elles existent: tk par exemple.

oui en tant qu'extension avec comunication par variable pas evidente et
lancant forcement l'interpreteur
donc justement, pourquoi ne pas integrer un tk a la stl, qui virerait
tout le probleme variable

le pb des petites boites et de depnser le moins en formation (que ce
soit bien ou non, c'est un fait)

Demandes à James, à Gaby. Moi, je serais contre, j'ai dit
pourquoi dans la réponse à Alain. Mais je ne pense pas
avoir un quelconque poids sur l'avenir de C++.

moi non plus et je n'interfereais surement pas avec ces deux la ou meme
les autres vues leur competence
mais j'estime qu'en refusant, vous vous mettez dans une tour d'ivoire ou
tout projet doit etre parfait et ou toute boite a les moyens d'aller
regarder plusieurs langages.
je rappel que ce n'est pas le meme prix en exterieur qui fait du c et un
exterieur qui fait c+tcl+tk+wxwindows +...

Ca dépend de ce qu'on attend d'un langage.

d'etre utile

J'ai plus le DnE sous la
main, mais BS y dit bien que C++ n'est qu'un langage, pas un système.

bien sur
mais un langage qui est dans un enviroonement qui a change depuis 20 ans

et la preuve, y a bien les string, les auto ptre, les templates qui ont
evoluers
alors ?

On a déjà assez de mal à avoir un bon langage C++, je ne pense
pas le temps venu d'avoir une bonne GUI C++.

un minimum est faisable
desole,mais pour bcp un petit gui est plus important qu'un string qui
peut etre fait autrement

Quelle plateforme n'offre pas d'entrée orienté charactère
à ses programmes ?

quel langage actuel ne propose pas le moindre gui ou n'a pas l'intention
d'en proposer un ?

Tk ? Java ?

demandent une formation en plus du cpp

Le fait que tu considères wxwindows comme "trop lourd" aurait
tendance à me faire dire qu'on ne sait pas faire pour les GUI
se qu'on commence à savoir faire avec C++ (et d'autres langages):
un système portable, qui soit accessible aux petits projets
et qui monte en charge jusqu'aux très gros.

tu confond la :
le probleme (ou l'avantage de) wxwindow est qu'il est concu pour tout
faire. c'est pourquoi il est lourd pour les petits projets

de meme aucun langage d'apres moi n'est accessible des petits projets
jusqu'au gros et je continue a voir que le cpp ne repond pas a tous les
besoins de tous les projets (mais c'est un autre debat)

Ben, prends Tk, non ?
Un coup de Google "Tk C++" me donne 354.000 réponses, dont 9 des
10 de la première page me semble adéquates pour ce que tu demandes.

oui avec un cout supplementaire pour les boites
et un defaut d'integration qui entraine des pb

encore une fois, il faut se rappeler que pour une entreprise , tout cela
a un cout
un truc integre a tjrs coute moins cher au niveau de petits projets que
plusieurs trucs (ce n'est plus forcmeent vrai pour les gros projets)

Cf ma réponse à Alain.

c est fait :)

@+
ricky

In article <btmiuq$8pj$1@news-reader5.wanadoo.fr>, ricky wrote:

bonjour

1) elle obligerait les gens qui veulent faire un compilateur
conforme à implémenter cette GUI, ce qui leur ferait perdre du
temps, qui ne serait pas passé à autre chose.

cela leur derait perdre leur temps parceque pour toi c'est peu important
cette parti pour d'autres c'est tres important

et ce raisonnement tu peux le faire pour quasiment tout developpement,
donc on gele definitivement le c++ :(

Non, C++ a été conçu comme un "langage" et évolue dans ce sens.
Il y a des évolutions au "langage".

Si en plus on
désire écrire un compilateur multi-plateforme (genre g++),
on plombe tout le développement.

pourquoi alors c'est possible dans la plupart des autres langages ?
java, tcl, python, etc marchent multi plateforme ! pourquoi le cpp
serait plus bloque qu'eux???

Je crois qu'ils n'ont vraiment pas les mêmes objectifs
d'universalité.

Pour g++, soit il renconce
à la portabilité, soit il renonce à implémenter cette GUI.
Dans les deux cas, les utilisateurs sont perdants.

non parcequ'avec ce raisonnement on ne fait surtout plus rien !
tout peut etre source de divergence et de probleme de portabilite
exemple ? le int dans le for ... bomm incompatible avec les premiers
compilateurs (pour la portee), pourtant cela a ete fait sauf pour visual
c, etc etc

Ne confondons pas portabilié et compatibilié ascendante,
ça n'a rien à voir.

et puis, desole mais wxwindows y arrive, donc pourquoi ne pas mettre un
sous ensemble simple ???

Ben, c'est le travail des gens de wxwindows, pas du comité C++.

2) elle aurait un effet "attracteur": énormément de
projet, pour résoudre les problèmes de portabilité,
prendrait cette GUI, donc à terme exigerait qu'elle soit
de qualité, d'y ajouter des choses.

encore une fois, cela n'a jamais ete demande a tk par exemple
ceux qui voulaient mieux avaient les moyens de se donner de la peine

Parce que Tk n'a pas forcément les mêmes ambitions que C++.

tous tes arguments sont des suppositions qui ne tiennent pas devant tous
ceux qui ont besoin d'une interface minimaliste...

Je n'empèche personne de développer une interface minimaliste
pour C++. Je note juste que ce besoin n'a pas encore donnée lieu
à une réponse. Dans une économie de marché, c'est étonnant.

pour ne pas ajouter trop de choses dans C++, il
serait submergé dans ce cas.

ce ne serait pas forcement a lui de le faire

Disons qu'actuellement, c'est lui qui a ce rôle.
<META> Au fait, si laissais un peu plus de mon texte original,
ce serait plus facile de comprendre tes réponses.</META>

ensuite un langage se doit de faire le minimum requis
il ne s'agit pas d'ajouter trop de chose mais d'ajouter du vital
meme les string etaient moins vitales que ca, car au moins avec des char
* on peut les emuler alors que le graphisme et les directory nada

Si le sujet t'intéresse, je te conseille la lecture de
"Design and Evolution of C++". BS considère lui que les
string étaient vitales. Je suis tenté de me ranger à son avis.

le boost a regle mes problemes saufs pour le graphisme!
et encore, je ne demande pas du graphisme mais un minimuml d'interface

on vit dans un monde ou les os ne sont plus textuels. le minimum serait
que les langages en tiennet compte desole ...

De quels OS parles-tu ? Un OS sur une carte à puce n'a
même pas d'interface textuelle.

Par exemple, combien
d'applis Java ont une IHM autre que swing ?

il y a toutes les combinaisons possibles, mais au moins, il y a la base ...

Mais l'IHM Java a un effet attractif très fort.

3) on se retrouverait avec au minimum 3 niveaux
de plateforme: sans écran, avec mode console, avec
système de type fenêtres carrées (Windows, X...),
donc combien de définitions pour la GUI.

encore une fois tous les autres langages quasiment se dirigent vers ca..
en quoi le cpp serait plus obtus ?

Parce qu'il a d'autres ambitions ? Il est un peu comme
Ada, Eiffel.

on vit dans un monde ou cela exite .. autant le prendre en compte

Il me semble que toute la démarche informatique est de
séparer les problèmes, de construire des architectures
logicielles. Je ne suis pas convaincu que lier C++ et
une GUI soit une bonne idée. Il existe des langages,
il existes des GUI, je ne crois pas qu'il faille confondre.

4) Un potentiel problème grave de perénité: qui
peut prétendre que l'on va continuer à communiquer
avec une machine principalement avec un clavier et
un écran ?

qui peut pretendre qu'on aura encore des zones memoires ou une
architecture xo neumann plus tard?
personne
faut arreter la parano...
avec ce raisonnement je ne fais plus rien .. qui me prouve que
l'ordinateur existera encore ?

Disons que l'informatique peut tout de même regarder
40 ans en arrière, et dégager certaines tendances.

5) ça s'oppose a tout ce qu'on enseigne en conception
d'IHM sérieux, ou on découple le modèle et la vue
(le cas du controle étant compliqué)

encore une fois, tu t'oppose a la realite
on n'est plus a la fac

Moi si, mais c'est un autre débat.

tout comme les bases canoniques sont une heresie au point de vue
rentabilite (le but d'une entreprise),

C'est quoi une "base canonique" dans ce contexte ?

une base graphique apporterait
beaucoup de chose a la majorite des projets
et desole mais regarde la taille et la simplicite de tk .. ce serait
assez simple de l'integrer a une stl sans toucher a la sacro sainte
bible du cpp

Mais pourquoi l'intégrer plutôt que de l'utiliser ? Tk
existe, il existe des moyens de lier Tk avec du code C++.
Quoi de plus ?

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

il ne s'agit pas d'ajouter trop de chose mais d'ajouter du vital
meme les string etaient moins vitales que ca, car au moins avec des
char * on peut les emuler alors que le graphisme et les directory nada

Ah ben oui, vu comme ça, on comprend tout de suite mieux ce qui est
vital et ce qui ne l'est pas. Je crois qu'avec ça tu auras su
convaincre tous les intervenants de ce groupe !

ricky wrote:

Mahello

Oui, c'est le genre d'affirmation ou la preuve serait
couteuse. Mais une argumentation, on peut tenter.

amha meme pas
moi je me suis ballade dans bcdp de pme pour mon travail
et quasiment TOUS les programmeurs ralaient et il y en a eu au mojns 10%
qui ont quitte le cpp rien que pour ca

Et ils ont pris quoi comme langage ?

perso j'ai fourni bcp de pgm en cpp + tcl qui les aidaient enormement a
develpper leur petit truc pour pas un sou

Bien.

Et elles existent: tk par exemple.

oui en tant qu'extension avec comunication par variable pas evidente et
lancant forcement l'interpreteur
donc justement, pourquoi ne pas integrer un tk a la stl, qui virerait
tout le probleme variable

Pourquoi Tk et pas autre chose ?

le pb des petites boites et de depnser le moins en formation (que ce
soit bien ou non, c'est un fait)

Peut-être que C++ n'est pas fait pour les petites boites qui
veulent dépenser peu en formation.
BS dit un truc genre "C++ was designed for making programming
more fun for serious programmers".
Peut-être que Java ou VC++ sont la bonne solution
pour les PME.

Demandes à James, à Gaby. Moi, je serais contre, j'ai dit
pourquoi dans la réponse à Alain. Mais je ne pense pas
avoir un quelconque poids sur l'avenir de C++.

moi non plus et je n'interfereais surement pas avec ces deux la ou meme
les autres vues leur competence
mais j'estime qu'en refusant, vous vous mettez dans une tour d'ivoire ou
tout projet doit etre parfait et ou toute boite a les moyens d'aller
regarder plusieurs langages.

Je ne crois pas qu'il existe de langage universel. En fait,
je crois qu'il en existe deux: C et Java, mais que comme
toute solution générique, elles sont inadaptées dans plein de
cas particuliers.
Je vois un créneau pour des langages C++/Ada/Eiffel,
il n'implique pas de GUI.

je rappel que ce n'est pas le meme prix en exterieur qui fait du c et un
exterieur qui fait c+tcl+tk+wxwindows +...

VB ? VC++ ? Java ?

Ca dépend de ce qu'on attend d'un langage.

d'etre utile

On peut faire la même réponse pour un OS, une pile
protocolaire et un débogueur.

J'ai plus le DnE sous la
main, mais BS y dit bien que C++ n'est qu'un langage, pas un système.

bien sur
mais un langage qui est dans un enviroonement qui a change depuis 20 ans

et la preuve, y a bien les string, les auto ptre, les templates qui ont
evoluers
alors ?

Alors je pense que les évolutions que tu cites étaient déjà
de manière plus ou moins présentes dans le projet initial
de C++, et qu'en se centrant sur un créneau donnée, C++ donne
plutôt de bons résultats.

On a déjà assez de mal à avoir un bon langage C++, je ne pense
pas le temps venu d'avoir une bonne GUI C++.

un minimum est faisable
desole,mais pour bcp un petit gui est plus important qu'un string qui
peut etre fait autrement

Et ben, je sais pas. Qu'ils utilisent autre chose. Je ne
prétends pas que C++ soit la meilleure solution au
développement logiciel pour toutes les configurations.
Visiblement, il existe des gens qui pensent que le rôle
de C++ c'est d'offrir string et pas TextDialog.

Quelle plateforme n'offre pas d'entrée orienté charactère
à ses programmes ?

quel langage actuel ne propose pas le moindre gui ou n'a pas l'intention
d'en proposer un ?

Ada, C++, Eiffel, bash, awk...

Tk ? Java ?

demandent une formation en plus du cpp

Me semble qu'on fait plus vite un bon programmeur Tk qu'un
bon programmeur C++, mais je me trompe peut-être.

Le fait que tu considères wxwindows comme "trop lourd" aurait
tendance à me faire dire qu'on ne sait pas faire pour les GUI
se qu'on commence à savoir faire avec C++ (et d'autres langages):
un système portable, qui soit accessible aux petits projets
et qui monte en charge jusqu'aux très gros.

tu confond la :
le probleme (ou l'avantage de) wxwindow est qu'il est concu pour tout
faire. c'est pourquoi il est lourd pour les petits projets

Ben, C++ est conçu pour être un langage avec une forte
capacité d'abstraction, de bonnes performances, et ne pas
être un système complet, et c'est pour cela qu'il est
insuffisant pour les petits projets.

de meme aucun langage d'apres moi n'est accessible des petits projets
jusqu'au gros et je continue a voir que le cpp ne repond pas a tous les
besoins de tous les projets (mais c'est un autre debat)

On est d'accord.

Ben, prends Tk, non ?
Un coup de Google "Tk C++" me donne 354.000 réponses, dont 9 des
10 de la première page me semble adéquates pour ce que tu demandes.

oui avec un cout supplementaire pour les boites
et un defaut d'integration qui entraine des pb

VB ? VC++ ?

encore une fois, il faut se rappeler que pour une entreprise , tout cela
a un cout
un truc integre a tjrs coute moins cher au niveau de petits projets que
plusieurs trucs (ce n'est plus forcmeent vrai pour les gros projets)

Je sais pas si C++ s'intéresse à ces petits projets.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Marc Boyer wrote:

ricky wrote:

Demandes à James, à Gaby. Moi, je serais contre, j'ai dit
pourquoi dans la réponse à Alain. Mais je ne pense pas
avoir un quelconque poids sur l'avenir de C++.

Je suis plutôt contre moi aussi. Je développerai plus loin.

Tk ? Java ?

demandent une formation en plus du cpp

Mais la question n'est pas là, il faut se demander ce qui prendrait le
plus de temps :
Apprendre le C++ et TK pour les gens faisant de l'IHM
ou
Apprendre un C++ enrichi de fonctions de type TK mais pensées pour C++
et non génériques

Pour quelqu'un qui ne fait pas d'IHM, la proposition intégrée est plus
longue, pour ceux qui en font, on peu supposer qu'elle est légèreemnt
plus courte.

Ben, prends Tk, non ?
Un coup de Google "Tk C++" me donne 354.000 réponses, dont 9 des
10 de la première page me semble adéquates pour ce que tu demandes.

oui avec un cout supplementaire pour les boites
et un defaut d'integration qui entraine des pb

Quel coût supplémentaire ? Le coût pour les boîtes serait AMA le même
s'il y avait des bibliothèques graphiques suffisemment standardisées.

Je sais pas si C++ s'intéresse à ces petits projets.
Je pense personellement que si, dans le sens où une boîte faisant de

petits projets aura souvent besoin de faire des projets assez semblables
les uns aux autres, et la réutilisabilité qui est un point fort de C++
peut permettre de répartir l'investissement sur plusieurs projets.


Maintenant, mon avis :
D'abord quelques éléments en vrac :

- Une façon standardisée de faire de l'IHM serait intéressante
- L'IHM est un monde qui évolue beaucoup, et où chacun à ses propres
idées : Une IHM standardisée n'est pas facile, et devra de toute façon
être très configurable
- Les outils d'IHM en C++ que je connais n'exploitent pas vraiment le
standard C++, et au contraire le duplique un peu par moment (QString de
et QMap de QT)
- Une bibliothèque d'IHM n'est pas utile, ou même n'a pas de sens, sur
tous les environnements où le C++ peut tourner
- Un standard à géométrie variable est une vraie horreur à gérer
- Il pourrait être intéressant de permettre de choisir le fournisseur de
l'implémentation de la bibliothèque graphique indépendemment du choix du
fournisseur de compilateur

Puis ma conclusion :
Une bibliothèque standardisée d'IHM pour le C++, je serais pour, mais à
condition qu'elle constitue un standard en soi, et non une sous partie
du standard C++. Ce standard aurait un champ d'application plus
restreind que le standard C++.

Ainsi ceux qui souhaitent l'utiliser peuvent le faire, etceux qui ne
veulent (peuvent) pas l'implémenter n'ont pas à le faire.

Parmi les bibliothèques que je connais un peu, aucune ne serait un
candidat envisageable comme base pour un tel standard. :(

--
Loïc