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

Je répond sur le post de Marc, je n'ai pas vu passer celui de ricky sur
mon serveur.

On 9 Jan 2004, Marc Boyer wrote:

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

[...]

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.

Même chose pour une voiture, un PABX, une machine à laver, un onduleur,
un ascenceur, et plein d'autres processeurs embarqués. Nous sommes
complètement cernés par les processeurs, et la très grande majorité
d'entre eux n'a ni clavier, ni é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é)

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

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.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
je suis équipé d'un PC avec PENTIUM II 300 mhz, et d'une RAM de 64 Mo,
modem USR de 58 K Pour améliorer les perfo sur Internet, vaut-il mieux
accroître la RAM ou faire passer le P II à 450 Mhz ?
-+- PL in GNU : Bien configurer son Cray T3E avec Wanadoo -+-

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

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.

Oui enfin ça c'est un argument minimaliste, tout ce qui est dans
le langage doit être implémenté, d'où une perte de temps pour
traiter quoi... ce qui n'y est pas ? :-)

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.

Je ne suis pas sûr de pouvoir compiler ta phrase ;-)

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 ?

Non mais là, que l'avenir du langage soit influencé par
les concepts humains qu'il permet de manipuler, c'est sûr.
Ils ont normalisé les adresses postales, malgré la menace
de l'arrivée des e-mails ! En l'occurrence tu pousses d'ailleurs
le bouchon trop loin : cette histoire de clavier et d'écran
n'est due qu'à l'existence (malheureuse mais pérenne ?!) de
petits outils appelés doigts et yeux ;-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France

hello

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 !

justement
je cherche a demontrer que rien ou tout peut etre considere comme vital
selon les personnes... chacun a sa vision du vital donc l'argument qui
m'est oppose qui est "il y a d autres trucs plus vitales" dans l'absolu
ne marche pas !

et meme si mon exemple fait rire, tu ne peut pas prouver que string est
"plus" vital qu'un mini gui pour une appli actuelle car je peux
contourner l'abscence de string sans quitter ce que fait un compilo de
base, mais pas l'abscence de gui ...

or justement ce sont des intervenant qui me disent qu'il y a "plus" vital

je reconnais que mon ecriture a peut etre ete un peu aggressive et je
tiens a m'en excuser aupres de ces intervenat, mais je voudrais faire
comprendre que les besoins de bcp de personnes ou societes peu fortunes
pourraient etre resolus avec peu de chose.
personne ne demande de super gui d'enfer qui poserait probleme ... mais
des bases ... et ce n'est pas avec des glues (tcl/tk par exemple) qu'on
ameliore la portabilite !

de meme , l'echange cpp/java ne se revele pas super optimal selon les
systemes et les debuggers ...

donc oui fabien, james gabriel et les autres sont des grands dans ce
domaine, qui sont tres respectables (et merci a eux pour fournir les
informations utiles) ... mais parfois, ils oublient qu'il y a des petits
qui ne peuvent pas investire dans certaines choses, qui ne peuvent pas
forcement cnnaitre la norme par coeur, et qui ont de "petits" besoins
tout bete, qu'on trouve resolu dans la majorite des langages sauf le
cpp... et qui sont quand meme obliges de faure vivre des appli en cpp...

je suis fan de c (par le coeur) et j'aime le cpp (par la raison), et je
ne cherche pas a dire qu'il faut voir ailleur... mais qu'un truc minimal
de gestion de reprtoire par exemple (integrer une petite partie de la
boost par exempl) ou une mini gui (juste la partie fenetre, champs de
wxwindows) pourrait satisfare la majorite ...
et pour les trucs avances, bien sur il faut le reste

enfin, je ne demande pas a gcc d'evoluer comme ca, le travail est
admirable et c'est gratuit... mais combien de compilo ont pris en compte
les template en peu de temps ? seuls quelques payants l'ont fait, les
autres ont edulcores la notion en gardant les moteurs de bases et en
virant des verif .. c'est arrive avec le temps

je souhaite juste qu'on reflechisse a cela et qu'on regarde ce qu'on
peut faire ... pas qu'on le fasse par magie !!! juste le point de vue de
debutant avec des besoins

perso, je me suis mis avec plaisir a wxwindows, mais je ne le
conseillerais pas dans certaines boites qui veulent juste un ensemble de
boutons simplistes !

@+
ricky

hello

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

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)
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

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
on evolue, les machines evolues...
ensuite la majorite des systemes dont tu parles sont plus en c qu'en cpp

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)

de plus :
1)
soit ces machines n'ont pas du tout d'ecran, donc autant virer toute
sortie d'apres ton raisonnement
2)
les autres evoluent vers les ecrans pour la plupart, ou sont ecrit en c
3)
en ligne de code, desole mais la majorite est sur ecran, meme si en
nombre la majorite est en embarque...
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,
soit c'est un langage generaliste comme je le vois ici, et j'apprend
donc qu'un langage generaliste ne s'occupe que de systemes embarques (et
je doute que la notion de template soit tres utilisee dans un systele
embarque a faible puissance et memoire) ce qui n'est pas tres
generaliste !!!

@+
ricky

hello

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.

desole mais par experience, et la j'en ai vu, sans aucun probleme le c++
enrichi
l'une des raisons est simple : la ou les personnes ont perdus le plus de
temps est dans le mecanisme de transmission des variables entre les
couches , et le debuggage par le plus connu des gratuits (gdb) qui a bcp
de mal dans les cas (c++ - tcl - tk et c++ - java)

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.

non il y a le probleme de transfert
dans l'une des boites, la gestion differait selon solaris, hp, windows
dans la facon de transmettre les variables
alors que pour un systeme integre, tu utilise directement les variables cpp

exemple typique par exemple : le tcl n'a pas de type, dans certains cas
cela pose probleme a la transmission

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.

amha non
aucunes des boites que j'ai vu ne fonctionne come cela
je suis d'accord avec ce que tu dis, mais dans la realite, les grosses
boites preferent scinder les projets et les faire rentrer en conccurence

- Une façon standardisée de faire de l'IHM serait intéressante

oui

- 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

pas forcement
la demande est surtout d'un "minimum", l'evolution est moins forte dans
ce cadre
je continue a dire que je peux m'en sortir avec des char* a la place du
string , mais pas sur un affichage...

- 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)

oui

- 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

pas plus que la notion de template, ou que les string (dans le cas de
tres peu de memeoire) ou que la majorite de la stl

- Un standard à géométrie variable est une vraie horreur à gérer

c'est deja le cas pourtant !
aucun compilo n'est parfaitement standard donc dans la realite c'est le
cas (visual c++ est different de gcc, different de CC, etc)
on passe assez de temps a passer de l'in a l'autre
alors qu'est ce que cela changerait ?

- 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

oui et alors?
on a un minimum en stl
cela ne supprime rien au reste ?????

wxwindows fonctionne bien avec wxstring au lieu de string
actuellement... cela ne remet rien en cause !

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++.

dans ce cadre, je suis ENTIEREMENT d'accord !!!!
c'est ce que j'aimerais bien sur ...

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

c'est le cas pour la stl non ?
je ne suis pas oblige de l'utiliser ou de l'implementer :)

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

je ne peut pas te contredire sur ce point, meme si j'aimerais bien un
"tkcpp" qui communique directement avec le cpp standard

mais je ne voudrais pas qu'on condamne l'idee comme j'ai l'impression
que certains le font ...

@+
ricky

bonjour

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 ?

java en general, c'est ce que les decisionnaires preconisent...
quelques python + tkinter, que j'essaye de faire changer en python+wxpython
je precise que je ne donne aucun jugement sur le choix, on est tous
libres :)

Pourquoi Tk et pas autre chose ?

euh j'ai pris tk parceque c'est la plus petite generatrice de gui que je
connaisse , qu'il fonctionne sur solaris, windows, hp, etc ce qui est
pas mal deja :)

mais c'est un exemple, tout ce qui peut donner une fenetre me plait :)

Peut-être que C++ n'est pas fait pour les petites boites qui
veulent dépenser peu en formation.

mais ces boites doivent maintenir de l'existant , que ce soit des
erreurs ou non

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.

je ne dit pas forcement le contraire
bien que j'aime le cpp, et que je pense qu'on peut eviter les trucs
complexe et quand meme obtenir de bonnes choses pour pas tres cher ...

Je ne crois pas qu'il existe de langage universel.

je suis d'accord bien evidement

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 dirais plus c que java :)

Je vois un créneau pour des langages C++/Ada/Eiffel,
il n'implique pas de GUI.

amha, la puissance du c++ necessite qu'il fournisse un peu de gui...
c++ est un langage genial, et honnetement, c++ et tcl/tk me prouvent
qu'on peut obtenir de supers trucs pour pas trop cher... mais complque a
transmettre les infos ...

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 ?

1) il y a pas mal de maintenance
2) il ne s'agit pas que de probleme technique, mais bcp de decideurs
preferent c++ a vb, pour des raisons non techniques, donc le rechnicien
est au pied du mur

il faut quand meme preciser que tres souvent, le choix nest pas
technique helas ...

oui pour java si on laisse la possibilite ... c est amha le meilleur
choix pour celui qui veux faire une gui tout compris

visual c++ a sa propre norme et certains societes sont contre billou ...

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

bien sur !

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.

oui je dois l'admettre ...
mais est ce une raison pour ne pas etudier la possibilite de lui donner
deux bonnes armes supplementaires qui ne couteraient pas forcement grand
chose a l'heure actuel

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.

le technicien n'a pas touours le choix helas

Visiblement, il existe des gens qui pensent que le rôle
de C++ c'est d'offrir string et pas TextDialog.

bien sur, et il existe le contraire

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

ada a evolue,il en existe un qui s'integre et qui est en train d etre norme
bash n'est pas un langage mais un shell, et dans ce cadre il s'integre
facilement a tcl/tk donc il en a un
euh c++ ? :-P

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

oh oui
tu fais super rapidement un programmeur tcl mais un bon, ouich .. le tcl
a des subtilites bien mechantes
ensuite le pb est dans l'interaction cpp/tcl-tk

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.

d'accord, dit comme cela :)

VB ? VC++ ?

tjrs ma reponse : ce n'est pas le technicien qui decide souvent
ensuite vc++ ne marche pas sur autre chose que windows non ?

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

pourtant il est souvent choisi : grande aura aupres des decideurs, une
image de marque , etc
c'est la le probleme actuel...

@+
ricky

et meme si mon exemple fait rire, tu ne peut pas prouver que string
est "plus" vital qu'un mini gui pour une appli actuelle car je peux
contourner l'abscence de string sans quitter ce que fait un compilo de
base, mais pas l'abscence de gui ...

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 ?

mais parfois, ils oublient qu'il y a des petits qui ne peuvent pas
investire dans certaines choses, qui ne peuvent pas forcement
cnnaitre la norme par coeur, et qui ont de "petits" besoins tout
bete, qu'on trouve resolu dans la majorite des langages sauf le
cpp... et qui sont quand meme obliges de faure vivre des appli en
cpp...

On ne peut pas connaître la norme par coeur et tu voudrais en
rajouter... Tu veux un langage avec quelques briques dans chaque
direction. C++ n'a pas pris cette direction, et un tel langage me
paraît en pratique inutilisable (parce qu'il faudrait tout faire
soi-même). Ce qui est dans le langage est cohérent et assez
complet. Ce qui n'y est pas se trouve ailleurs, en particulier quand
c'est aussi spécifique qu'une GUI.

je suis fan de c (par le coeur) et j'aime le cpp (par la raison), et
je ne cherche pas a dire qu'il faut voir ailleur...

Mais pourquoi pas, si un autre langage convient mieux ? S'il n'existe
pas de GUI pour le C++ à te convenir, c'est peut-être ce qu'il y a de
mieux à faire. Le manque n'est pas dans C++, il manque juste la
bibliothèque graphique simple qui t'irait.

perso, je me suis mis avec plaisir a wxwindows, mais je ne le
conseillerais pas dans certaines boites qui veulent juste un
ensemble de boutons simplistes !

Mais ça c'est un besoin particulier. 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.

ricky wrote:

enfin, je ne demande pas a gcc d'evoluer comme ca, le travail est
admirable et c'est gratuit... mais combien de compilo ont pris en compte
les template en peu de temps ? seuls quelques payants l'ont fait, les
autres ont edulcores la notion en gardant les moteurs de bases et en
virant des verif .. c'est arrive avec le temps

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

--
Loïc

ricky wrote:

hello

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.

desole mais par experience, et la j'en ai vu, sans aucun probleme le c++
enrichi
l'une des raisons est simple : la ou les personnes ont perdus le plus de
temps est dans le mecanisme de transmission des variables entre les
couches , et le debuggage par le plus connu des gratuits (gdb) qui a bcp
de mal dans les cas (c++ - tcl - tk et c++ - java)

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.

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.

non il y a le probleme de transfert
dans l'une des boites, la gestion differait selon solaris, hp, windows
dans la facon de transmettre les variables
alors que pour un systeme integre, tu utilise directement les variables cpp

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

exemple typique par exemple : le tcl n'a pas de type, dans certains cas
cela pose probleme a la transmission

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.

amha non
aucunes des boites que j'ai vu ne fonctionne come cela
je suis d'accord avec ce que tu dis, mais dans la realite, les grosses
boites preferent scinder les projets et les faire rentrer en conccurence

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

- Une façon standardisée de faire de l'IHM serait intéressante

oui

- 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

pas forcement
la demande est surtout d'un "minimum", l'evolution est moins forte dans
ce cadre
je continue a dire que je peux m'en sortir avec des char* a la place du
string , mais pas sur un affichage...

Le minimum désiré sera à mon avis très différent sur un PC, un téléphone
portable et un Mac.

- 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

pas plus que la notion de template, ou que les string (dans le cas de
tres peu de memeoire) ou que la majorite de la stl

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.
Pour ce qui est de l'IHM, j'ai pluus de mal à voir ce qu'elle peut
signifier sur un calculateur d'ABS. 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.

- Un standard à géométrie variable est une vraie horreur à gérer

c'est deja le cas pourtant !
aucun compilo n'est parfaitement standard donc dans la realite c'est le
cas (visual c++ est different de gcc, different de CC, etc)
on passe assez de temps a passer de l'in a l'autre
alors qu'est ce que cela changerait ?

Qu'il y a un but unique à atteindre. Même s'il n'est pas encore atteind.
Si maintenant on met plein d'élémens optionnels dans le standard, même
ce voeux pieu d'objectif commun s'écroule(1). 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...).

(1) En fait, dans le standard, il y a déjà une divergence entre
implémentation hosted et non hosted.

- 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

oui et alors?
on a un minimum en stl
cela ne supprime rien au reste ?????

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...).

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

c'est le cas pour la stl non ?
je ne suis pas oblige de l'utiliser ou de l'implementer :)

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.

--
Loïc

bonjour

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

On ne peut pas connaître la norme par coeur et tu voudrais en
rajouter...

si j'ai bien lu, on m'a dit qu'on ne faisait pas cela car on a d'autres
choses a rajouter...
donc de toute facon on en rajoute alors ...

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

C++ n'a pas pris cette direction, et un tel langage me
paraît en pratique inutilisable (parce qu'il faudrait tout faire
soi-même).

java le fait bien dans sa philosophie...

et encore une fois, le "il faudrait tout faire" n'est qu'une hypothese
qui refuse la notion de minimum vital...
"il faudrait tout faire " si et seulement si on demandait un truc
absolument complet qui fasse tout et le cafe ... les bases sont
faisables assez simplement, cela a ete prouve par les autres langages

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 ...

Ce qui est dans le langage est cohérent et assez
complet. Ce qui n'y est pas se trouve ailleurs, en particulier quand
c'est aussi spécifique qu'une GUI.

une gui de base n'est pas plus specifique que les acces memoires ou les
acces sortis texte et c'est devenu important

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

il faut arreter de raisonner en monde parfait

vous avez raison, dans un monde ou tout le monde prend les bonnes
decisions sur le simple critere du bon choix

S'il n'existe
pas de GUI pour le C++ à te convenir, c'est peut-être ce qu'il y a de
mieux à faire. Le manque n'est pas dans C++, il manque juste la
bibliothèque graphique simple qui t'irait.

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

Mais ça c'est un besoin particulier.

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

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
le besoin d'une base est la demande la plus generale ... apres les
besoins particuliers sont ceux d'une plus grande completude

tout langage est issu de compromis, mais part de bases quand meme

@+
ricky