Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ au sujet d un acces curieux a un string ...

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

156 réponses
Avatar
ricky
bonjour

j ai de nouveau un chtti truc etrange !

je fais quelquechose comme :
int main()
{
string pattern;
...
cout << "entrez le pattern";
cin >> pattern;
cin.get(); // pour virer le enter du buffer pour apres

balayage cache
recherche du pattern
affochage
}

ok tout marche super

je rajoute juste un truc :
...
cin.get();

cout << pattern[0];
...

donc juste un affichage du premier caractere, un truc bien neutre quoi

et la , la recherche echoue et donne 0 resultats !!!

quelque soit le code de recherche, en quoi le simple fait d afficher le
premier caractere d une string peut il changer quoique ce soit ?????

une idee ? :-)

@+
ricky... je sais pas si les reveillons me reussissent moi :)
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
6 7 8 9 10
Avatar
Marc Boyer
In article <btnhcm$vps$, ricky wrote:
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 !!!


Tu fais la une grave erreur de raisonnement. Un langage generaliste
doit *aussi bien* traiter les systemes embarques que les PC sous M$.
Oui, cela ammene a prendre le plus *petit* denominateur commun.
C'est dans les choix fondateurs de C++.

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

Avatar
Marc Boyer
In article <3fff4151$0$7150$, Alain Naigeon wrote:
"Marc Boyer" a écrit dans le message
news: btm8eg$1tk$

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


Non, pas si minimaliste que ca: l'histoire de l'informatique
est pleine de normes qui gereaient tout et n'ont jamais ete
implementees et sont tombees dans les oubliettes apres une
survie de niche: CORBA, ATM, la pile OSI...

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


Tu as un projet C++ a faire. Tu as des objectifs de
portabilite M$/MasOS/Linux (grand public). Tu choisis la
GUI C++ ou wxwindows ? Si ta fonction d'evaluation des
solutions est de la meme qualite que celle subie par ricky,
tu choisis la GUI C++. Et quand ton projet avances, tu demandes
a ton fournisseur de compilateur de te fournir une GUI C++
plus etoffee.
Je ne crois pas a cette idee de GUI simpliste et normalisee.

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


Hein ? Non, vivement la reconnaissance vocale, l'environnement
de travail 3D, le gant tactile...
Deja, l'ecran tactile me semble l'hypothese la plus
vraisemblable pour une percee de la domotique. Est-ce que
Tk est le bon "minimum vital" pour faire des IHM pour la
menagere de moins de 50 ans ? Je suis pas sur du tout.
J'ai mis un adverbe "principalement" pour qualifier
le mode de mon verbe "communiquer".

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


Avatar
Marc Boyer
In article <btnisc$boi$, ricky wrote:
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




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



Avatar
breholee

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


Cette critique est prise en compte, j'ai l'impression.

[GTK, wxWindows, Qt]
non mais compliqueoui (a differencier de complexe)
et cette complication a un cout


Si le besoin est aussi simple que tu le dis, ces GUI n'ont rien de
compliqué. Le code à produire sera relativement long, mais pas
compliqué.

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


Ce n'est pas parce qu'un outil existe et te convient, et que cet outil
est intégré à certains langages, qu'il a forcément sa place dans le
C++.

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


La "mort" de ceux qui s'obstinent à choisir des langages ou des outils
peu adaptés à leurs besoins me paraît plus probable que celle du C++ :)
Par ailleurs le C++ évolue.

et bien, oui, en gui on se contenterai deja de l'equivalent char* !
c est ce que je voulais dire...


Mais l'objectif de C++ n'est pas de se contenter d'équivalents de
char*. C'est au C qu'il faudrait demander ça.

le string est concu sur du char*


Le type string est le type chaîne de C++, peu importe comment il est
réalisé.

Avatar
Fabien LE LEZ
On Fri, 09 Jan 2004 05:27:08 +0100, ricky wrote:

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


De toutes façons, tout programmeur C++ doit savoir aller chercher une
bibliothèque adaptée, et l'intégrer à son environnement de
développement. Et une fois qu'on sait faire ça, aller chercher la
bibliothèque GUI adaptée à ses besoins n'est pas bien difficile
(d'autant que certains éditeurs, comme Borland et Microsoft, en
proposent une d'office dans leur système de développement).

--
;-)

http://www.gotw.ca/gotw/063.htm
http://www.gotw.ca/gotw/067.htm#2

Avatar
Jean-Marc Bourguet
Fabien LE LEZ writes:

On Fri, 09 Jan 2004 05:27:08 +0100, ricky wrote:

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


De toutes façons, tout programmeur C++ doit savoir aller chercher une
bibliothèque adaptée,


s/C++//

Sur la standardisation d'une bibliotheque graphique,

- vu qu'une telle specification est figee plus d'un an avant sa
promulgation promulgation et dure de 5 a 10 ans apres, est-ce que
standardise un domaine qui est toujours tres volatile est utile?

- vu que je ne connais pas une seule bibliotheque de GUI que
j'aimerais voir standardisee, je me demande si l'etat de l'art est
mur pour une telle operation.

- vu l'importance pour le GUI de l'homogeneite avec le reste de la
plateforme (une application MFC sous Unix ca ne s'integre pas
reellement bien avec le reste, une application Motif sous Windows
c'est pas mieux), est-ce qu'il y a une approche acceptable par autre
chose que des developpements jouets? (Il y a bien l'approche des
frameworks qui par nature imposent plus que des bibliotheques
graphiques et sont donc encore apparemment plus loin de la maturite
necessaire a la normalisation).

- on pourrait se rabattre sur une sorte de minimum, quite a devoir
utiliser autre chose pour les programmes ayant des exigences en la
matiere -- un peu comme ca a ete fait pour les IO qui sont deja
normalisees, est-ce un hasard que le probleme soit dans la meme
zone? -- mais il faut accepter les limitations de l'ambition.

- de toute maniere il faut une proposition et a ma connaissance il n'y
en a pas, et personne de volontaire -- particulier ou entreprise, vu
le travail plutot entreprise mais quel est le ROI? -- pour un faire
une.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org


Avatar
Erwann ABALEA
Bonjour,

On Mon, 12 Jan 2004, ricky wrote:

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


Oui. Mais le processeur de la bagnole ne s'occupe pas de formatter la
sortie sur l'écran, de choisir la couleur, l'alignement, et toutes ces
bêtises. C'est le rôle du terminal qui reçoit les données. Tu confonds.

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


un processeur n a pas d ecran


Raccourci que j'aurais pu éviter, c'est vrai.

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


Là encore, même erreur de raisonnement. A chacun son boulot.

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


En prenant en compte tes erreurs, tu revois tes chiffres? ;)

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


Cette SSII ne doit pas coder beaucoup alors... Quand on n'a que quelques
octets de RAM disponible, et quelques kilo octets d'EEPROM ou de ROM, on
préfère quand même l'assembleur, même si on commence par écrire du C. Et
quand une place non négligeable du silicium est occupée par un composant
particulier (par exemple un accélérateur crypto), et qu'on se retrouve
avec 2 fois moins de ROM/EEPROM, on doit trancher encore plus.

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


Là encore, tu confonds. Evidemment que les machines qui font de la
personnalisation de cartes à puce ont un écran, mais la carte à puce ne
sait absolument pas ce qu'est un écran. quand même, et elle sait encore
moins gérer une GUI qui peut tourner soit sur un OS/2, un Windows, ou un
X11...

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


J'en doute... Tu pourrais dire que Windows est l'OS le plus utilisé au
monde, et ce serait également faux.

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


N'importe quoi. Quand je présente un PIN code à une carte à puce, elle se
fout de savoir si le PIN code a été saisi sur une boîte de dialogue bleue
ou rouge, ou même si le clavier qui a servi à saisir le code existe ou
non. La carte ignore complètement ce genre de détails, et ne sait donc pas
ce qu'est un clavier, un bouton, un écran, un pixel, ...

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


Oui, pour afficher un logo. Mais c'est bien tout.

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


Evidemment, puisque le canal est le même.

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


Ces "programmeurs de base" sont théoriquement capables de s'adapter, et de
choisir la meilleure GUI, selon leurs critères (prix, portabilité,
possibilités, support, religion, ...).

[...]
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 !


Tu es libre de faire une proposition au comité, qui l'appréciera à sa
juste valeur. Ce newsgroup n'est pas en charge de définir l'avenir du
langage C++.

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


Quels sont ces langages actuels? Es-tu sûr que la "majorité" de ces
langages intègre une GUI minimaliste? A part Java, VB, et peut-être C#, je
ne vois pas d'autre langage intégrant *nativement* une GUI. Mais je me
trompe peut-être.

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


Et tu considères que les extensions graphiques à Cobol et Fortran font
partie du langage? Pourquoi ne pas adopter la même approche pour le C++,
et utiliser une extension?

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
``Average programmers should be rounded up and placed in internment
camps to keep them away from keyboards.''
Well known Linux personage


Avatar
kanze
Marc Boyer wrote in message
news:<bttrqg$iea$...

Non, pas si minimaliste que ca: l'histoire de l'informatique est
pleine de normes qui gereaient tout et n'ont jamais ete implementees
et sont tombees dans les oubliettes apres une survie de niche: CORBA,
ATM, la pile OSI...


Quelle survie de niche : CORBA est encore très vivante, et pratiquement
la seule solution possible si tu ne veux pas te lier à un seul
fournisseur. La pile OSI sert aussi pas mal dans les applications de la
téléphonie.

En ce qui concerne la normalisation d'une interface graphique : le fait
qu'il y a des systèmes sans écran n'est pas un argument. D'une part, il
y a d'autres fonctions qui ne sont pas implémentables par tout (time,
par exemple), et de l'autre, la plupart des systèmes sans écran sont des
systèmes embarqués, avec des implémentations « free standing ».

Jean-Marc a donné les vrais arguments contre la normalisation.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Avatar
Gabriel Dos Reis
Jean-Marc Bourguet writes:

| Sur la standardisation d'une bibliotheque graphique,
|
| - vu qu'une telle specification est figee plus d'un an avant sa
| promulgation promulgation et dure de 5 a 10 ans apres, est-ce que
| standardise un domaine qui est toujours tres volatile est utile?

L'existence d'une composante bibliothèque dans la norme ne veut pas
dire qu'elle convient à tout le monde où qu'elle est impérissable (au
sens où sa technologie est la plus au pointe). Si un conteneur
intrusif convient mieux à mon application et que les containers
standard ne conviennent pas pour ce que je veux faire, dois-je
m'entêter à vouloir l'utiliser, ou est-ce un argument contre sa
présence dans la norme ?
Je ne crois que non dans les deux cas.

| - vu que je ne connais pas une seule bibliotheque de GUI que
| j'aimerais voir standardisee, je me demande si l'etat de l'art est
| mur pour une telle operation.

Je crois qu'on peut faire l'argument pour pas mal de composantes de la
bibliothèque standard.

| - vu l'importance pour le GUI de l'homogeneite avec le reste de la
| plateforme (une application MFC sous Unix ca ne s'integre pas
| reellement bien avec le reste, une application Motif sous Windows
| c'est pas mieux),

le même argument peut être servi pour les fichiers/flux.

[...]

| - on pourrait se rabattre sur une sorte de minimum, quite a devoir
| utiliser autre chose pour les programmes ayant des exigences en la
| matiere -- un peu comme ca a ete fait pour les IO qui sont deja
| normalisees, est-ce un hasard que le probleme soit dans la meme
| zone? -- mais il faut accepter les limitations de l'ambition.

Cela il le faut de toute façon, pour n'importe qu'elle fonctionnalité
de la bibliothèque standard.

| - de toute maniere il faut une proposition et a ma connaissance il n'y
| en a pas, et personne de volontaire -- particulier ou entreprise, vu
| le travail plutot entreprise mais quel est le ROI? -- pour un faire
| une.

Ça c'est un fait, sérieux et embêtant.

J'ai une idée de comment provoquer des réactions.

-- Gaby
Avatar
Alain Naigeon
"Marc Boyer" a écrit dans le message
news: bttrqg$iea$

Deja, l'ecran tactile me semble l'hypothese la plus
vraisemblable pour une percee de la domotique.


Beurk, des traces de doigts partout, l'écran tactile c'est dégoûtant :-(

Est-ce que
Tk est le bon "minimum vital" pour faire des IHM pour la
menagere de moins de 50 ans ?


Il y en a bien qui lui conseillent de passer à Linux !

--

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

6 7 8 9 10