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

bonjour

Il me semble que pour les template, justement, gcc a été relativement
réactif, comparé par exemle à visual C++

il n'y avait aucune attaque conte gcc !!! compilo admirable et qui
permet a bcp de fonctionner a faible cout...
et vc++ est connu pour son .. manque de reactivite a la norme :)

ce que je voulais dire, c'est qu'il faut du temps avant d'integrer quoi
que ce soit... c'est vrai pour tout, et nuol ne veut une revolution en
une version !

@+
ricky

bonjour

Je voulais parler d'une bibliothèque externe mais pensée pour le C++.
Dans ce cas, il n'y a pas vraiment de problème de transition.

ah desole alors , je prend :)

Pourquoi si la bibliothèque et le langage sont tous deux standardisés y
aurait-il des problèmes différents suivant les OS ?

meme si les deux sont standardises, certaines choses ne le sont pas dans
les faits comme le mangling , ou la facon d'utilise la memoire

Je n'ai pas l'expérience de telles boîtes, mais si elle n'ont pas de
structure pour gérer ce qui est commun entre leurs projets, c'est :
- Soit qu'elle achètent tout ce qui pourrait être commun à l'extérieur
- Soit qu'elles perdent une bonne occasion de gagner de l'argent

on est relativement d'accord sur ce point comme la majorite des techniciens
mais on dit aussi que cela permet la "saine emulation" des travailleurs !
Le minimum désiré sera à mon avis très différent sur un PC, un téléphone

portable et un Mac.

pas forcement tant que cela
un ecran et une i/o restent la meme chose, la base est identique

J'arrive à imaginer des cas où std::string ou std::vector ne sont pas
utilisés, mais j'ai plus de mal à imaginer des cas où ils ne sont pas
utilisables.

ben dans tous les cas... tu te fais toi meme ta version avec des char*
comme cela se faisait autrefois

Pour ce qui est de l'IHM, j'ai pluus de mal à voir ce qu'elle peut
signifier sur un calculateur d'ABS.

par exemple pour pouvoir corriger le programme en cas de revision de la
voiture

Et pour information, je sais de

source sure (c'est un peu mon boulot) que même dans un monde très
prudent comme l'automobile, on commence à parler de langages de
programmation haut niveau pour les systèmes embarqués. Certains
fournisseurs ont même des protos écrits en Java.

protos en java + couche c pour les driver ou les accees non
rechargeables le plus souvent
c'est le cas le plus frequent (et amha le meilleur pour le moment a
cause d'autres criteres)

Qu'il y a un but unique à atteindre. Même s'il n'est pas encore atteind.

pas si unique que cela !

Si maintenant on met plein d'élémens optionnels dans le standard, même
ce voeux pieu d'objectif commun s'écroule(1).

on a deja plein d'optionnels


Et d'autres éléments

auraient AMA priorité sur l'IHM : Threads, réseau, et d'autres éléments
sont AMA du même niveau : regex, gestino du son, interface vers des
ports (USB, série, parallèle, cartes d'E/S...).

au meme niveau ok
et pour les autres, c'est un probleme de choix et de vision AMHA bien sur

Je ne peux pas utiliser la bibliothèque standard de GCC avec Visual C++
(je ne sais vraiment pas pourquoi j'en ai envie dans ce cas particulier,
mais bon...).

oui mais on utilise celle de visual qui devrait suivre la norme :)

Tu n'es pas obligé de l'utiliser, mais ceux qui veulent faire un
compilateur répondant à la norme (ce qui est quand même un argument de
vente important) doivent l'implémenter.

ah oui bien sur

mais bon, cela reste amha un probleme de choix de priorite :)

@+
ricky

Je ne peux pas le prouver uniquement dans ce contexte où l'on
s'interdit toute utilisation de bibliothèque. La question est de
savoir si ce contexte-là est vraiment pertinent ?

ni plus ni moins que le reste

Sans plus d'explication ? C'est une question que d'autres t'ont déjà
posée : que la GUI soit ou non dans le langage, il faut l'apprendre
pour l'utiliser. Quel est alors l'intérêt de s'interdire une GUI
extérieure, juste pour le principe ?

Tu veux un langage avec quelques briques dans chaque
direction.

dans chaque direction UTILE ou DEMANDEE a l'heure actuelle par un
grand nombre de personnes nuance

Il n'y a aucune nuance, on trouvera des demandeurs pour tous ces
domaines.

java le fait bien dans sa philosophie...

Ce n'est pas la même philosophie, c'est peut-être Java que tu devrais
utiliser. Et ce n'est pas forcément une réference pour le C++.

l ihm est devenu quelque chose de quasiment vital de nos jours, il n'y
a pas eu tant de cha,gement que cela ailleurs ...

Plein de choses vitales à un projet sont fournies par autre chose que
le langage. La GUI est un bon exemple de ce qui peut être fourni par
une bibliothèque.

Mais pourquoi pas, si un autre langage convient mieux ?

parcequ'il y a un passe
parceque certaines boites ne peuvent se permettre de payer des
personnes maitrisant plusieurs langages
parceque les decideurs ne sont pas toujours les techniciens

Mais ce sont de mauvaises raisons, on ne va quand même pas polluer un
langage avec des ajouts incohérents pour ce genre de prétextes. Le
jour où il y aura une solution satisfaisante à intégrer au langage, ce
sera sans doute fait.

S'il te faut rester avec le même langage, alors wxWindows convient
(par exemple).

on est d'accord MAIS une bibli qui s INTEGRE au cpp, et pas qui se
relie au cpp, bref quipermet l'usage direct des variables c par
exemple

Fabien t'as conseillé wxWindows qui est « plutôt simple d'utilisation
quand on se contente de quelques trucs basiques ». J'ai utilisé GTK
dont je dirais la même chose.

comme n'importe quoi mais un besoin particulier qui devient l'un des
besoins les plus demandes dans la realite

Dans les parties client.

Dans un autre projet, il faudra
aussi quelques trucs simplistes, mais ce ne seront pas les mêmes. Et
finalement seule une GUI complète conviendra, et il en existe.

non ca ne marche pas avec ce raisonnement, rien ne conviendrait

Si justement, ce qui est entré dans C++ (tu prenais l'exemple des
strings) est suffisamment complet pour convenir à la plupart des
utilisations. On ne peut pas définir la même chose aussi facilement
pour une GUI.

bonjour

Sans plus d'explication ? C'est une question que d'autres t'ont déjà
posée : que la GUI soit ou non dans le langage, il faut l'apprendre
pour l'utiliser. Quel est alors l'intérêt de s'interdire une GUI
extérieure, juste pour le principe ?

mais on ne s interdit pas un gui exterieur... en plus :)
il faut toujours apprendre le gui, mais dans le cas ou aucune base n
existe, il faut aussi apprendre ale faire communiquer correctement avec
le langage, et cela n existe que dans le cas exterieur...

Il n'y a aucune nuance, on trouvera des demandeurs pour tous ces
domaines.

c est bien ce que je dit : donc c est bien un choix arbitraire de ne pas
vouloir l un plus que l autre

Ce n'est pas la même philosophie, c'est peut-être Java que tu devrais
utiliser. Et ce n'est pas forcément une réference pour le C++.

encore une fois, tout le monde n a pas le choix

Plein de choses vitales à un projet sont fournies par autre chose que
le langage. La GUI est un bon exemple de ce qui peut être fourni par
une bibliothèque.

sauf qu aucune bibli ne s integre correctement au cpp actuellement dans
le domaine du gui simple

Mais ce sont de mauvaises raisons, on ne va quand même pas polluer un
langage avec des ajouts incohérents pour ce genre de prétextes. Le
jour où il y aura une solution satisfaisante à intégrer au langage, ce
sera sans doute fait.

on ne risque pas de la trouver en refusant de la chercher !

S'il te faut rester avec le même langage, alors wxWindows convient
(par exemple).

trop lourd pour de la base

Fabien t'as conseillé wxWindows qui est « plutôt simple d'utilisation
quand on se contente de quelques trucs basiques ». J'ai utilisé GTK
dont je dirais la même chose.

wxwindows est simple ... quand on maitrise pas mal...
dans ce que j'ai pu voir, pas mal de personnes rament avec ...
ce n est pas une critique contre wx, mais simplement qu il est
puissant... et pas franchement pour du truc basic

Dans les parties client.

et alors? cela compte aussi

Si justement, ce qui est entré dans C++ (tu prenais l'exemple des
strings) est suffisamment complet pour convenir à la plupart des
utilisations. On ne peut pas définir la même chose aussi facilement
pour une GUI.

pourtant tk convient a la plupart des projets de base que je connais
ona deja defini des sets minimaux qui interessent la majorite et c est
loin d etre aussi "dur a definir" que tu veux le faire croire...
et loin d etre "complet".. c est simplement adapte aux demandes
majoritaires... comme pourrait l etre un gui

et pas plus que de decider de tout ce que contient le string

@+
ricky

mais on ne s interdit pas un gui exterieur... en plus :)
il faut toujours apprendre le gui, mais dans le cas ou aucune base n
existe, il faut aussi apprendre ale faire communiquer correctement
avec le langage, et cela n existe que dans le cas exterieur...

Fabien a répondu à ça, je crois qu'on est plusieurs à ne pas voir cet
obstacle qui "diparaît" si la GUI devient standard :/

Il n'y a aucune nuance, on trouvera des demandeurs pour tous ces
domaines.

c est bien ce que je dit : donc c est bien un choix arbitraire de ne
pas vouloir l un plus que l autre

Non il y a d'autres critères j'imagine : notamment l'existence de
bibliothèques portables à intégrer au langage. Boost contient de bons
candidats. Où est la GUI idéale prête à être intégrée dans la norme
C++ ?

Ce n'est pas la même philosophie, c'est peut-être Java que tu devrais
utiliser. Et ce n'est pas forcément une réference pour le C++.

encore une fois, tout le monde n a pas le choix

Dans ce cas ce n'est peut-être pas au C++ d'être la cible de cette
critique ?

sauf qu aucune bibli ne s integre correctement au cpp actuellement
dans le domaine du gui simple

WxWindows, GTK, Qt s'intègrent correctement (pour ce qui en a été dit,
ou ce que j'en ai vu). Et sont suffisamment simples, si on n'a que des
choses simples à faire. Bien sûr « simple » ça ne se mesure pas en
nombre de lignes.

Mais ce sont de mauvaises raisons, on ne va quand même pas polluer un
langage avec des ajouts incohérents pour ce genre de prétextes. Le
jour où il y aura une solution satisfaisante à intégrer au langage, ce
sera sans doute fait.

on ne risque pas de la trouver en refusant de la chercher !

Mais qui te dit que personne ne cherche ?

S'il te faut rester avec le même langage, alors wxWindows convient
(par exemple).

trop lourd pour de la base

Alors ce que tu veux est vraiment spécifique : une GUI, mais pas une
GUI complète, juste ce qu'il faut pour tel projet particulier. Le
manque c'est une petite bibliothèque GUI C++. Si le besoin est si
fort, comment se fait-il qu'il n'y en ait pas alors qu'on en trouve de
complètes et libres ?

wxwindows est simple ... quand on maitrise pas mal...
dans ce que j'ai pu voir, pas mal de personnes rament avec ...
ce n est pas une critique contre wx, mais simplement qu il est
puissant... et pas franchement pour du truc basic

Ça donne vraiment l'impression que ton besoin c'est un langage comme
Python mais qu'une contrainte injustifiée t'oblige à utiliser C++. Ce
n'est pas le C++ qui est en cause...

Dans les parties client.

et alors? cela compte aussi

Ça compte mais c'est limité à ça. Tu disais « l'un des besoins les
plus demandés dans la réalité ».

pourtant tk convient a la plupart des projets de base que je connais
ona deja defini des sets minimaux qui interessent la majorite et c est
loin d etre aussi "dur a definir" que tu veux le faire croire...
et loin d etre "complet".. c est simplement adapte aux demandes
majoritaires... comme pourrait l etre un gui

Et c'est défini comment, « la majorité » ? Où est spécifiée cette GUI
si c'est fait, est-ce qu'elle a été proposée, confrontée à l'avis des
gens du C++ ?

Je ne doute pas que ça puisse être facile à définir dans des cas
particuliers.

et pas plus que de decider de tout ce que contient le string

Tu dis toi-même que c'est loin d'être complet, alors que string l'est
suffisamment (l'équivalent de ton "set minimal", ce serait de rester
avec les char*).

Bonsoir,

On Sat, 10 Jan 2004, ricky wrote:

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

le cpp ne sert pas qu'a eux
et souvent ces puces sont programmees en c

Pour du prototypage oui. Mais pour du code en production, on préfère
encore l'assembleur. C'est un peu comme utiliser du VB pour faire une
maquette, et faire le vrai boulot en C++.

Même chose pour une voiture, un PABX, une machine à laver, un onduleur,
un ascenceur, et plein d'autres processeurs embarqués.

ils ont de plus en plus des ecrans (machine a lavee , voiture, onduleur)

Tu ne vas quand même pas prétendre qu'une led sur le tableau de bord d'une
bagnole constitue un écran?

on va de plus ne plus vers les ecrans ... et c est exact dans tous tes
exemples ... y compris pour l'ascenseur pour les processus de verification

Et le processeur qui se trouve dans mon hub, il a un écran? Et celui qui
calcule l'injection dans ma bagnole, il a un écran? (dans une voiture,
aujourd'hui, on peut trouver une vingtaine de processeurs, et aucun n'a
d'écran, à part peut-être celui du GPS).

Nous sommes

complètement cernés par les processeurs, et la très grande majorité
d'entre eux n'a ni clavier, ni écran.

de plus en plus inexact a l'heure actuelle

Allez, si on passe de 5 à 10% de processeurs qui causent avec un écran,
c'est déjà bien. Mais ça n'en constitue toujours qu'une faible minorité.

on evolue, les machines evolues...
ensuite la majorite des systemes dont tu parles sont plus en c qu'en cpp

Peut-être (encore que pour les cartes à puce, on préfère l'assembleur, et
je pense que c'est toujours le cas pour beaucoup d'autres applications).
Mais le langage C++ n'étant pas destiné qu'aux 10% de machines équippées
d'un écran, il est normal que l'effort de définir et d'intégrer des
fonctions graphiques soit considéré d'un intérêt douteux.

Ben justement. A la fac, tu ne vois rien d'autre que des PC ou des
stations, bref des machins avec des claviers et des écrans. Mais ça n'est
qu'une petite minorité de ce qui peut se programmer, et de très loin, dans
le monde réel. Donc on n'est plus à la fac, et donc on apprend à séparer
les besoins.

non pas la notion d'ecran...
(pour le clavier je ne vois pas le rapport, tout rensemble de bouton est
assimilable a un clavier)

Tu me montreras les boutons et l'écran sur une carte à puce, un contrôleur
de freinage ABS, ou même une des cartes intégrées dans un PABX.

de plus :
1)
soit ces machines n'ont pas du tout d'ecran, donc autant virer toute
sortie d'apres ton raisonnement

Non. Mon switch, je peux le contrôler soit par un terminal qui va
m'afficher les octets qu'il envoit, et j'aurais donc une représentation
'visuelle' de ces infos, soit par un programme qui va 'parser' tout ça et
agir comme je l'aurais décidé. Ca n'est pas parce qu'une machine n'a pas
d'écran qu'il faut supprimer toute sortie. Pour reprendre les cartes à
puce, tu supprimes la sortie, et tu te retrouves avec une bête carte
plastique qui ne sert plus à rien.

2)
les autres evoluent vers les ecrans pour la plupart, ou sont ecrit en c

Encore faux. Mais tu ne travailles que sur des machines avec un écran,
donc ton raisonnement est faussé.

3)
en ligne de code, desole mais la majorite est sur ecran, meme si en
nombre la majorite est en embarque...

Je demande à voir. Le monde n'étant mu que par une faible proportion de
processeurs type Intel 32 bits ou autres (moins de 10%), même en écrivant
beaucoup de lignes de code pour ceux là, s'il y a avantage, il n'est pas
énorme.

4)
l'un n'empeche pas l'autre

soit tu affirmes que le cpp n'existe QUE pour les systemes embarques
sans ecran, dont acte, mais je ne le vois pas ecrit dans la norme,

Je n'applique pas ton raisonnement. C'est toi qui défend que le C++
*devrait* (comprendre: "si c'est pas ça qui est fait, alors le C++ est un
langage de tapette, et ne sert à rien") avoir une interface graphique. Je
n'ai jamais prétendu que le C++ n'existait *que* pour les systèmes ne
possédant pas d'écran.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Je voudrais savoir comment chercher n'importe quelle nationalités. S'il
y en a qui sont faciles à trouver, il y en a d'autres mêmes européennes
ou mondiales...
-+- ER in <http://neuneu.mine.nu> : C'est un monde ça -+-

bonjour

Pour du prototypage oui.

pas uniquement loin de la quand meme...


Mais pour du code en production, on préfère

encore l'assembleur.

ca depend des cas mais de moins en moins

C'est un peu comme utiliser du VB pour faire une
maquette, et faire le vrai boulot en C++.

absolument pas
la majorite des processus sur lequel j ai pu travaille pour lembarque
avaient en version definitive 3 couches : une de java pour l externe, le
c pour l'algorithme general et l assembleur pour les drivers

tout evolue :)

Tu ne vas quand même pas prétendre qu'une led sur le tableau de bord d'une
bagnole constitue un écran?

non, meme si le processus est bien le meme
mais les moteurs, comme tu le sais, sont concus pour s interfacer avec
les ordinateurs constructeurs en permettant reglage, verification, etc

Et le processeur qui se trouve dans mon hub, il a un écran?

un processeur n a pas d ecran
mais pas mal de hub hauts de gamme peuvent effectivement se brancher sur
des consoles de reglages

Et celui qui

calcule l'injection dans ma bagnole, il a un écran? (dans une voiture,
aujourd'hui, on peut trouver une vingtaine de processeurs, et aucun n'a
d'écran, à part peut-être celui du GPS).

un processeur n a pas d ecran !!!
mais le programme qui gere l injection electronique a souvent une
interface de liaison avec les consoles de reglages qui en ont un...

Allez, si on passe de 5 à 10% de processeurs qui causent avec un écran,
c'est déjà bien. Mais ça n'en constitue toujours qu'une faible minorité.

tu es loin du compte dans les fait
la majorite des cas actuels prevoient l interconnection a la base

et quel rapport entre "processeur" et "ecran" ?

Peut-être (encore que pour les cartes à puce, on préfère l'assembleur

euh???
la ssii qui gere certaines cartes a puces semble en profond desaccord
avec cela :)

Mais le langage C++ n'étant pas destiné qu'aux 10% de machines équippées
d'un écran,

sauf que plus de 40% de ces machines sont concues pour pouvoir etre
verifiees en usine par des outils avec ecran et prevoient a la base
cette connection !!!

il est normal que l'effort de définir et d'intégrer des
fonctions graphiques soit considéré d'un intérêt douteux.

non car il ne faut pas confondre nombre de machine et nombre de code
different utilise

a ce petit jeu, les deux programmes les plus utilises au monde loin
devant les autres sont le demineur et tetris et donc tout ce qui ne leur
sert pas est d un interet douteux

ce qui compte est l'importance en terme humain de l'usage

il y a beaucoup de progammes embarques, mais il y a aussi beaucoup de
petits programmes vitaux aux pme en tout aussi grand nombre...

tu sais, avec un seul processeur on peut en faire tourner des
programmes, donc le rapport nombre de processeur sur nombre de machine
ne veut rien dire

on pourrait aussi voir le nombre de ligne de cpp utilisee selon l'usage
et la le rapport s inverserait sans peine

Tu me montreras les boutons et l'écran sur une carte à puce, un contrôleur
de freinage ABS, ou même une des cartes intégrées dans un PABX.

la carte a puce est concue pour gerer les entrees venant des dac et
possede bien une gestion io de ce style sorry
cela ne veut pas dire qu'il y a un clavier physiquement sur la carte

Non. Mon switch, je peux le contrôler soit par un terminal qui va
m'afficher les octets qu'il envoit, et j'aurais donc une représentation
'visuelle' de ces infos, soit par un programme qui va 'parser' tout ça et
agir comme je l'aurais décidé.

donc entree ET sortie en general

Ca n'est pas parce qu'une machine n'a pas

d'écran qu'il faut supprimer toute sortie.

bravo
ben cela s applique aussi au gui
ce n est pas parcequ une machine n a pas de base un ecran graphique qu
il faut en virer toute sortie graphique

sun par exemple l a bien compris en integrant au niveau le plus bas un
peu de graphisme comme lesderniers pc avec le reglage des bios :a tout
niveau, une interface humaine est beaucoup plus rentable quand elle est
claire et accessible que quand elle n est gerable que par des inities


Pour reprendre les cartes à

puce, tu supprimes la sortie, et tu te retrouves avec une bête carte
plastique qui ne sert plus à rien.

et de meme pour l entree

Encore faux. Mais tu ne travailles que sur des machines avec un écran,
donc ton raisonnement est faussé.

loupe j'ai travaillé aussi a la fabrication des codespour cartes a puce
justement :) je ne suis pas limite a un monde, mon travail se situant
justement plus dans la mise en adequation de l informatique avecla
rentabilite de l entreprise et la prise en compte des besoins des
programmeurs, que dans le codage meme d une application

et cela a justement ete cette societe qui a ete le plus demandeur
d'interface graphique basique !!!

je pense que vous snobez pas mal les besoins de la majorite des
programmeurs "de base" qui pondent des applications que vous ne
connaissez pas et qui representent pourtant une tres grande proportion
des utilisateurs

Je demande à voir.

pas dur a voir partout
par exemple chez les ssii travaillant pour ft, edf, etc

Le monde n'étant mu que par une faible proportion de

processeurs type Intel 32 bits ou autres (moins de 10%), même en écrivant
beaucoup de lignes de code pour ceux là, s'il y a avantage, il n'est pas
énorme.

QUEL RAPPORT AVEC INTEL ?????????????????????????????????????
y a que les pca base d 'intel qui ont un ecran ???
les processeurs specifiques del 'armee n'y ont pas le droit?
les 68000 n'y ont pas le droit???

vous etes au courant que beaucoup de petites entreprises n ont pas de pc
moderne a l'heure actuelle ??? qu'elles vivent avec des processeurs
non 32 bits et qu'elles produisent pourtant beaucoup de ligne de code???

Je n'applique pas ton raisonnement. C'est toi qui défend que le C++
*devrait* (comprendre: "si c'est pas ça qui est fait, alors le C++ est un
langage de tapette, et ne sert à rien")

absolument pas, decidement, on dirait que vous restez bloquer sur des
hautes spheres...

je vois qu'il y a beaucoup de sujet de discussion sur des sujets dont
beaucoup de programmeurs industriels se contrefichent, que vous trouvez
cela important ... soit
mais que sur un sujet que la base trouve importante, vous rejetez sans
autre argument finalement que cela prendrait du temps a d'autres
innovations qui vous plaisent plus ...
ce n'est pas le cpp que je critique, mais l'attitude de certains dans un
forum qui defendent une idee en rejettant d'autres idees, pourtant tres
demandee, au simple nom que cela ne leur semble pas utile a eux !

et aussi je critique ceux qui comme toi dans cette partie de la reponse,
convertissent ce que l'interlocuteur dit afin de mieux casser le
raisonnement, ce qui n est pas honnete
le COMPRENDRE que tu as ecrit n'appartient qu'a toi, et montre plutot un
manque d'ouverture d esprit puisque seul ce que tu comprend semble etre
ce qu'il faut comprendre...
je ne vois pas vraiment la necessite d'essayer de traduire a ta sauce un
raisonnement que tu n'arrive pas vraiment a casser

avoir une interface graphique. Je
n'ai jamais prétendu que le C++ n'existait *que* pour les systèmes ne
possédant pas d'écran.

en reprennat tes termes ci dessus,
"

il est normal que l'effort de définir et d'intégrer des
fonctions graphiques soit considéré d'un intérêt douteux.
"

et en traduisant a ta sauce : gui interet douteux donc on ne fait pas
donc le cpp ne s adresse a ces systemes que si la societe peut se
permetre de depenser de l'energie a se debrouiller avecce qu'on veut
bien leur donner sans regarder l usage actuel

bon je vais arreter la car de plus en plus les raisonnement
contradictoires deviennent de mauvaise fois, interpretant a leur guise
les propose de l'interlocuteur, ou melangeant divers notions pour noyer
le poisson

il n en reste pas moins que personne n a repondu a la question :
pourquoi la majorite des langages actuels quels que soient leur but
arrivent a integrer une base minimaliste de GUI et pas le cpp ...
je dout que le cpp soit siiiiii specifique que ca dans son domaine, et
meme en fortran ou cobol, des bases apparaissent pour satisfaire les
banques... alors qui du cpp??? il faut normer que pour le plaisir ou
pour quand meme aider le programmeur ????

bon j arrete sur ce sujet, car cela devient hs et cela m'enerve de voir
que les seuls remarques sont sur la beaute d'un langage ou sur les
besoins des quelquesplus connus au depend de la majorite des besoins des
PME...

je constate qu aucun argument vraiment technique n a ete donne a par "ca
serait difficile donc on n essaye meme pas", ce qui est amusant car pour
jauger d une difficultee reelle, on essaye un tantinet

hello

Fabien a répondu à ça, je crois qu'on est plusieurs à ne pas voir cet
obstacle qui "diparaît" si la GUI devient standard :/

je suis tout a fait d accord avec toi, mais aucun GUI ne deviendra
standard si les pontes du cpp n'y mettent pas du leur en aidant...
tant qu il y aura blocage, il n'y aura pas d 'espoir dans ce domaine

Non il y a d'autres critères j'imagine : notamment l'existence de
bibliothèques portables à intégrer au langage. Boost contient de bons
candidats. Où est la GUI idéale prête à être intégrée dans la norme
C++ ?

peut etre bloquee parceque cela ninteresse pas ceux qui pondent des
specifications liees au cpp?

Dans ce cas ce n'est peut-être pas au C++ d'être la cible de cette
critique ?

mais je ne critique pas le cpp
mais plutot ceux qui le bloque en ne tenant pas compte de cette critique !
le monde evolue, les mots evoluent, et bien les langages aussi

WxWindows, GTK, Qt s'intègrent correctement (pour ce qui en a été dit,
ou ce que j'en ai vu).

oui tres correctement


Et sont suffisamment simples, si on n'a que des

choses simples à faire. Bien sûr « simple » ça ne se mesure pas en
nombre de lignes.

non mais compliqueoui (a differencier de complexe)
et cette complication a un cout

Mais qui te dit que personne ne cherche ?

certaines reponses provenant de ce newsgroup : on ne va pas passer du
temps a cela alors que d'autres choses sont plus importantes!

Alors ce que tu veux est vraiment spécifique : une GUI, mais pas une
GUI complète, juste ce qu'il faut pour tel projet particulier.

non
cett h=gui existe ailleurs : tk, tkinter, etc

manque c'est une petite bibliothèque GUI C++. Si le besoin est si
fort, comment se fait-il qu'il n'y en ait pas alors qu'on en trouve de
complètes et libres ?

tu as donne en partie la reponse
les gros projets ont plus de poids que la majorite des petits projets
ils poussent plus facilement a produire des monstres que des petits
trucs dont on ne pourra pas sevanter facilement

c est quand meme plus gratifiant d ecrire que "notre produit a ete
utilise sur un programme de 15 millions de lignes dans la plus grosse
boite " que "nous sommes tres utilisespour des petits besoins de pme"

Ça donne vraiment l'impression que ton besoin c'est un langage comme
Python mais qu'une contrainte injustifiée t'oblige à utiliser C++. Ce
n'est pas le C++ qui est en cause...

personnellement, mon besoin est resolu par cpp et tcl/tk
mais pas celui des entreprises que j'ai pu voire
le cpp (ou plutot ceux qui decident de l avenir) est en cause car il
n'evolue pas dans le sens de la demande, et ce qui n'evolue pas devient
mort rapidement

Ça compte mais c'est limité à ça. Tu disais « l'un des besoins les
plus demandés dans la réalité ».

il y a les programmes autonaumes, et j'aime bien votre "limite a ca"
dans les pme, on constate actuellement un besoin d'une dizaine de
programme de ce type en moyenne ...multiplie par le nombre de pme et le
fait qu'ils evoluent beaucoup plus rapidement que les programmes lourd
ou meme que les codes embarques, cela represent donc dans les faits la
majorite des codes manipules en permanence pour ceux ecrit en cpp

Et c'est défini comment, « la majorité » ? Où est spécifiée cette GUI
si c'est fait, est-ce qu'elle a été proposée, confrontée à l'avis des
gens du C++ ?

"la majorite" peut facilement se mesurer dans ce cadre oui, avec les
utilisateurs .. il y a des associations qui s'en occupent et des
groupements d'utilisateurs...
et les demandes sont bien qualifiables... je n'ai pas pris l'exemple de
tk par hasard : c est ce qui s'est revele etre le plus a meme de faire
plaisir a la majoritee :)

Je ne doute pas que ça puisse être facile à définir dans des cas
particuliers.

des particuliers, je ne sais pas
des pme, sans probleme

Tu dis toi-même que c'est loin d'être complet, alors que string l'est
suffisamment (l'équivalent de ton "set minimal", ce serait de rester
avec les char*).

et bien, oui, en gui on se contenterai deja de l'equivalent char* !

c est ce que je voulais dire... le string est concu sur du char* malgre
tout, mais en gui, il n'y a aucun moyen
et idem pour l'acces aux directories (et oui les autres langages y arrivent)

bon j arrete d ennuyer le forum avec cette discussion

à+
ricky

ricky wrote:

Il n'y a aucune nuance, on trouvera des demandeurs pour tous ces
domaines.

c est bien ce que je dit : donc c est bien un choix arbitraire de ne pas
vouloir l un plus que l autre

Non, c'est un choix fondateur de C++ d'etre un langage et pas un systeme
complet, et ce choix a de nombreuses justifications, qu'on retrouvera
dans DnE par exemple, et dont je me suis fait le rapporteur.
Un choix arbitraire, c'est un choix sans justification.

Ce n'est pas la même philosophie, c'est peut-être Java que tu devrais
utiliser. Et ce n'est pas forcément une réference pour le C++.

encore une fois, tout le monde n a pas le choix

Mais C++ n'est peut-etre pas fait pour tout le monde...
Tu es en train de dire auem puisque ton chef t'as donne un tournevis,
les clous devraient avoir une tete rainuree et un corps en spirale...
Si C++ n'est pas adpate a un projet, est-ce le probleme de C++
ou du chef de projet ?

Plein de choses vitales à un projet sont fournies par autre chose que
le langage. La GUI est un bon exemple de ce qui peut être fourni par
une bibliothèque.

sauf qu aucune bibli ne s integre correctement au cpp actuellement dans
le domaine du gui simple

Il y a peut-etre un manque d'outillage a ce niveau. Mais pourquoi
pas VC++ et les MFC au fait ?

S'il te faut rester avec le même langage, alors wxWindows convient
(par exemple).

trop lourd pour de la base

Mais C++ lui meme n'est il pas "trop lourd pour de la base" ?

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

ricky wrote:

Fabien a répondu à ça, je crois qu'on est plusieurs à ne pas voir cet
obstacle qui "diparaît" si la GUI devient standard :/

je suis tout a fait d accord avec toi, mais aucun GUI ne deviendra
standard si les pontes du cpp n'y mettent pas du leur en aidant...
tant qu il y aura blocage, il n'y aura pas d 'espoir dans ce domaine

Il est assez clair que, suivant les choix de base de C++,
on attendra longtemps avant d'avoir un systeme et non uniquement
un langage.
Mais il eixste aussi des standars de fait. Une solution technique
n'a pas forcement besoin d'une norme pour s'imposer.

Non il y a d'autres critères j'imagine : notamment l'existence de
bibliothèques portables à intégrer au langage. Boost contient de bons
candidats. Où est la GUI idéale prête à être intégrée dans la norme
C++ ?

peut etre bloquee parceque cela ninteresse pas ceux qui pondent des
specifications liees au cpp?

Ne confondons pas desinteret et obstruction. Ton reproche tiendrais
la route s'il existait quelque part un groupe travaillant a une GUI
et que le commite C++ faisait tout pour que la norme soit incompatible
avec les propositions de GUI.
Il y a des choses dans Boost qui n'interessaient pas le commite
et qui vont semble-t-il entrer dans la norme.

Dans ce cas ce n'est peut-être pas au C++ d'être la cible de cette
critique ?

mais je ne critique pas le cpp
mais plutot ceux qui le bloque en ne tenant pas compte de cette critique !
le monde evolue, les mots evoluent, et bien les langages aussi

Ils ne bloquent pas: ils disent que c'est un "autre" probleme.

Mais qui te dit que personne ne cherche ?

certaines reponses provenant de ce newsgroup : on ne va pas passer du
temps a cela alors que d'autres choses sont plus importantes!

Qui est "on" ? Si une communaute a un probleme, elle se prend
par la main pour le resoudre.

manque c'est une petite bibliothèque GUI C++. Si le besoin est si
fort, comment se fait-il qu'il n'y en ait pas alors qu'on en trouve de
complètes et libres ?

tu as donne en partie la reponse
les gros projets ont plus de poids que la majorite des petits projets

Non, pas forcement. L'histoire de la bureautique (Windows/Office)
a montre le contraire. Alors que les "gros" faisaient du mainframe/unix
avec framemaker, M$ a attaque le marche des PME/particuliers avec
Windows/Office. Qui a gagne la guerre ?

c est quand meme plus gratifiant d ecrire que "notre produit a ete
utilise sur un programme de 15 millions de lignes dans la plus grosse
boite " que "nous sommes tres utilisespour des petits besoins de pme"

Quel est le plus gros marche ?

le cpp (ou plutot ceux qui decident de l avenir) est en cause car il
n'evolue pas dans le sens de la demande, et ce qui n'evolue pas devient
mort rapidement

Que les gens qui ont choisis C++ alors qu'ils avaient besoin de
Java abandonnent C++ pour Java ne me semble pas un mal pour C++.

"la majorite" peut facilement se mesurer dans ce cadre oui, avec les
utilisateurs .. il y a des associations qui s'en occupent et des
groupements d'utilisateurs...
et les demandes sont bien qualifiables... je n'ai pas pris l'exemple de
tk par hasard : c est ce qui s'est revele etre le plus a meme de faire
plaisir a la majoritee :)

Et qu'est-ce qu'elle attend pour se prendre par la main cette
majorite si presente aux besoins si bien qualifies ?

bon j arrete d ennuyer le forum avec cette discussion

Si ca m'ennuyais, je repondrais pas ;-)

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