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
12 13 14 15 16
Avatar
Marc Boyer
Gabriel Dos Reis wrote:
|
| Tu m'avais demandé des "préalables" ?
| "Et que penses-tu que les problèmes vitaux de C++ sont ?"
|
| Je vois pas de notion de "préalable".

Effectivement, mais pour moi dans « vitaux », il y a une notion de
priorité.


Ah... Non, disons que dans mon point de vue, s'il est
vital pour moi de boire dans les 48h qui viennent, cela
ne m'empèche pas pour le moment de taper sur fclc++
(mais ça me donner soif d'en parler).

J'ajoute que j'ai aussi écrit "je pense que C++
actuellement résoud les problèmes que j'évoquais"
(qui étaient les problèmes "vitaux") et que la liste
que j'ai faite était celle "des choses qui manquent
actuellement à C++:" (dont aucun n'est vital, puisque
C++ vit visiblement assez bien).

| Actuellement, on travaille avec des #include,
| il faut se protéger contre les doubles inclusions,
| faire attention au nommage des gardes, tout ça.
| Dans mon souvenir, en Ada ou Pascal, c'est le
| langage qui gère.

Je connais relativement bien Pascal, et le langage n'est pas
télépathique ; donc, quand tu dis que c'est le langage qui gère, le
programmeur fait quelque chose. Aussi, ce que ces langages gèrent
a-t-il quelque chose à avoir avec C++ ? Ce n'est pas une question de
rhétorique.


Oui, le programmeur dit que telle portion de code
fait partie d'une unité, et fait partie de son interface
ou de son implémentation. Il peut aussi écrire un
programme (la distinction me semble pas forcément
pertinente).
Il utilise des directives d'utilisation (uses) et le
compilateur comprend tout seul qu'il lui faut l'interface
il gère les doubles inclusions, tout ça.

Il me semble que cette structuration en module
existe dans beaucoup de programmes C++, ou l'on
met ce que l'on considère "interface" dans un .h[pp]
et implémentation dans un .cpp.

Que cette notion entre dans le langage pourrait
éventuellement obliger (ou signaler) à n'avoir que
des déclarations de variable (et pas de définition)
dans l'interface, ce genre de chose.
On pourrait même envisager que la question des
codes templates ou inline, qu'actuellement on importe
avec #include, soit gérée par le compilateur qui,
en fonction de l'éditeur de lien cible, décide
de faire un .h et des inclusions dans les codes
utilisateurs, un .o, enfin, ce qu'il veut
qui respecte la sémantique.

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

Avatar
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes:

| Gabriel Dos Reis wrote:
| > Marc Boyer writes:
| >
| >| Je crois que pour envisager une GUI "normalisable"
| >| à C++, il faut déjà bien comprendre C++ tel qu'il
| >| existe, et comprendre ou ce situe le projet.
| >
| > Juste par curiosité, tu crois que quelqu'un comme BS comprend quelque
| > chose à C++ ?
|
| Devine.

Désolé, tu as déjà épuisé ton crédit chez moi. Donc, pas de devinette.
Si tu ne veux ou peux pas répondre, c'est une autre histoire.


Ne pas répondre aux mauvaises questions me semble
une base de la réthorique. Ta question était ironique, ou moqueuse.
Je ne vois vraiment pas pourquoi y répondre.

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

Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Gabriel Dos Reis wrote:
| >|
| >| Tu m'avais demandé des "préalables" ?
| >| "Et que penses-tu que les problèmes vitaux de C++ sont ?"
| >|
| >| Je vois pas de notion de "préalable".
| >
| > Effectivement, mais pour moi dans « vitaux », il y a une notion de
| > priorité.
|
| Ah... Non, disons que dans mon point de vue, s'il est
| vital pour moi de boire dans les 48h qui viennent, cela
| ne m'empèche pas pour le moment de taper sur fclc++
| (mais ça me donner soif d'en parler).

Moi non plus, mais je boirai *avant* de taper sur fclc++ -- surtout je
dois m'éterniser avec toi ;-/

| J'ajoute que j'ai aussi écrit "je pense que C++
| actuellement résoud les problèmes que j'évoquais"
| (qui étaient les problèmes "vitaux") et que la liste
| que j'ai faite était celle "des choses qui manquent
| actuellement à C++:" (dont aucun n'est vital, puisque
| C++ vit visiblement assez bien).

Donc, fianlement, tu ne sais plus où tu en es. Vitaux or not vitaux,
that is the question. C'est ça ?

| >| Actuellement, on travaille avec des #include,
| >| il faut se protéger contre les doubles inclusions,
| >| faire attention au nommage des gardes, tout ça.
| >| Dans mon souvenir, en Ada ou Pascal, c'est le
| >| langage qui gère.
| >
| > Je connais relativement bien Pascal, et le langage n'est pas
| > télépathique ; donc, quand tu dis que c'est le langage qui gère, le
| > programmeur fait quelque chose. Aussi, ce que ces langages gèrent
| > a-t-il quelque chose à avoir avec C++ ? Ce n'est pas une question de
| > rhétorique.
|
| Oui, le programmeur dit que telle portion de code
| fait partie d'une unité, et fait partie de son interface
| ou de son implémentation. Il peut aussi écrire un
| programme (la distinction me semble pas forcément
| pertinente).
| Il utilise des directives d'utilisation (uses) et le
| compilateur comprend tout seul qu'il lui faut l'interface
| il gère les doubles inclusions, tout ça.
|
| Il me semble que cette structuration en module
| existe dans beaucoup de programmes C++, ou l'on
| met ce que l'on considère "interface" dans un .h[pp]
| et implémentation dans un .cpp.

Il est exact que cette structuration existe en pratique en C++ -- et
des tonnes de littératures sont consacrées à ça. Mais ce n'est pas ce
que j'appellerai module ; et de fait, si c'en était une tu ne
demanderais pas que C++ résolve ce « problème ».

| Que cette notion entre dans le langage pourrait

Cette notion est déjà dans le langage. Donc, si je suppose que tu
parles de quelque chose d'autre. Il est difficile de savoir quoi tant
que tu n'as pas précisé (et non, ce n'est pas la phase de proposition).

| éventuellement obliger (ou signaler) à n'avoir que
| des déclarations de variable (et pas de définition)
| dans l'interface, ce genre de chose.
| On pourrait même envisager que la question des
| codes templates ou inline, qu'actuellement on importe
| avec #include, soit gérée par le compilateur qui,

Un code template n'est pas obligé d'être importé par #include.
Il existe un méchanisme dans le langage appelé « export ».

-- Gaby
Avatar
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes:
| Gabriel Dos Reis wrote:
| > Et qu'est-ce que cela veut dire concrêtement,
| > « être conçu comme un "langage" et évoluer dans ce sens » ?
|
| Tu dois avoir le DnE sous la main.

Non, il est au bureau. Mais dans tous les cas, tu as sorti cet
« argument » dans cette discussion donc tu dois avoir une idée de ce
que tu as voulu dire. C'est ça que je veux savoir.


Ce que je voulais dire, c'est que l'informatique a essayé
au cours de son histoire de séparer certains concepts. C'est
casse gueule d'en parler puisque c'est une sorte de culture,
mais aux frontières difficiles à tracer. Mais évoquons
rapidement l'OS, l'interface utilisateur, les réseaux,
les bases de donnée, les applications utilisateurs, etc.
Un objectif de cette séparation est d'avoir un couplage
faible, qui permet de changer un élément sans tout changer
(objectif plus ou moins atteind suivant les cas).

Il me semblait (impression, subjective) que C++
s'était centré sur la partie "calcul", en se donnant
des interfaces minimales d'entrée/sortie (flux)
et la possibilité de se lier avec d'autres codes (extern).

Voilà, je suis surpris (en fait, j'étais quand tu m'as
donné la ref à la FAQ de BS, maintenant, la surprise est
passée) de voir apparaître un intérêt plus spécifique
pour les GUI (1) que pour les répertoires, les bases de
donnée ou les connexions réseaux.

Marc Boyer

(1) j'ai bien noté "the standards committee
do not have the resources to build a new and better GUI",
alors que pour le garbage collector, c'est "there are good
commercial and public-domain garbage collectors for C++"
--
Lying for having sex or lying for making war? Trust US presidents :-(

Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Gabriel Dos Reis wrote:
| > Marc Boyer writes:
| >
| >| Gabriel Dos Reis wrote:
| >| > Marc Boyer writes:
| >| >
| >| >| Je crois que pour envisager une GUI "normalisable"
| >| >| à C++, il faut déjà bien comprendre C++ tel qu'il
| >| >| existe, et comprendre ou ce situe le projet.
| >| >
| >| > Juste par curiosité, tu crois que quelqu'un comme BS comprend quelque
| >| > chose à C++ ?
| >|
| >| Devine.
| >
| > Désolé, tu as déjà épuisé ton crédit chez moi. Donc, pas de devinette.
| > Si tu ne veux ou peux pas répondre, c'est une autre histoire.
|
| Ne pas répondre aux mauvaises questions me semble
| une base de la réthorique.

Donc, si je ne réponds pas aux tiennes tu ne prendras pas mouche, je
suppose ;-p

| Ta question était ironique, ou moqueuse.

Non. C'était une question pour aider à trouver une logique dans ton
argumentation.

| Je ne vois vraiment pas pourquoi y répondre.

Peut-être la peur de découvrir la réponse ?

-- Gaby
Avatar
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes:

| Non, mais dire qu'à partir du moment ou un problème
| est résolu, on a la preuve qu'il exisait une solution,
| je ne vois pas en quoi ça fait avancer le débat.

C'est parce que le vice est contenu dans ton assertion de départ :

Une classe String efficace, portable et internationalisable,
est-ce du même niveau de difficulté de spécification et
d'implémentation qu'une GUI efficace, portable et
internationalisable ? Si la réponse est "oui", alors,

Il n'y aucune obligation que le code d'implémentation de la
bibliothèque standard soit portable ; c'est là que tu commets l'erreur
de raisonnement.


Je n'arrive même pas à concevoir comment une telle
implémentation portable serait possible (à part de considérer
que l'IHM minimale du futur, c'est HTML).
Néanmoins, que le code d'implémentation ne soit
par portable me semble rendre plus difficile la réalisation
de compilateur multiplateforme. Non ?

| > On va faire simple : réponds par oui ou non aux questions suivantes
| >
| > (1) souhaites-tu un GUI dans la prochaine version de C++ ?
|
| Un bon GUI, bien sur.
| Entre un mauvais et rien du tout, je crois que je préfère rien

Un autre point de vue est que mauvais est mieux que rien.


Oui, tout a fait défendable aussi. C'est pour cela que
j'ai précisé cette nuance.

| (mais je ne pense pas que mon avis personnel influe beaucoup
| sur l'avenir de C++).

it is up to you. Si tu veux influencer l'avenir C++, il suffit de
joinde le comité et d'être actif.


Oui, il faudrait que mon avis se transforme en investissement,
et j'ai déjà inversti la quasi totalité de mes ressources
ailleurs.

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

Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Néanmoins, que le code d'implémentation ne soit
| par portable me semble rendre plus difficile la réalisation
| de compilateur multiplateforme. Non ?

La norme ne requiert pas un compilateur multiplateforme, ne dit pas
comment un tel compilateur doit être implémenté, ni que la
bibliothèque standard soit écrit en C++, et a fortiori que son code
d'implémentation soit portable. Donc, que le code d'implémentation
soit portable ou non importe peu.

Veux-tu banir le support des fichiers au prétexte que son code
d'implémentation n'est pas portable ?

On ne met pas quelque chose dans la bibliothèque standard juste parce
que son code d'implémentation est portable. En fait, un argument
sérieux pour mettre quelque chose dans la bibliothèque, c'est
justement parce que son code d'implémentation n'est pas portable.
Je crois que tu as mis les choses à l'envers.

-- Gaby
Avatar
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes:
| Ta question était ironique, ou moqueuse.

Non. C'était une question pour aider à trouver une logique dans ton
argumentation.


Quelle logique ? Que quand j'ai écris que je pensais
que c'était une mauvaise idée d'avoir une GUI en C++,
j'avais un avis différent de celui de BS, et que ça
devait me faire revoir mes arguments ? Oui,
sans aucun doute.

Sinon, t'a décidé d'aller bosser sans être passé
par la case sommeil .

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

Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Il me semblait (impression, subjective) que C++
| s'était centré sur la partie "calcul", en se donnant
| des interfaces minimales d'entrée/sortie (flux)
| et la possibilité de se lier avec d'autres codes (extern).

C++ a été conçu comme un outil (qui se trouve être un langage de
programmation), mais surtout un outil pragmatique. En particulier, il
n'y a pas une distinction académique religieuse entre bibliothèque et
« core language ».

| Voilà, je suis surpris (en fait, j'étais quand tu m'as
| donné la ref à la FAQ de BS, maintenant, la surprise est
| passée) de voir apparaître un intérêt plus spécifique
| pour les GUI (1) que pour les répertoires, les bases de
| donnée ou les connexions réseaux.

???

Si tu penses que les connexions réseaux posent un problème qui doit
être résolu, soumets une proposition (cela demande un investissement)
ou fait une suggestion (cela ne coûte rien).

| Marc Boyer
|
| (1) j'ai bien noté "the standards committee
| do not have the resources to build a new and better GUI",
| alors que pour le garbage collector, c'est "there are good
| commercial and public-domain garbage collectors for C++"

Et ?

-- Gaby
Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Gabriel Dos Reis wrote:
| > Marc Boyer writes:
| >| Ta question était ironique, ou moqueuse.
| >
| > Non. C'était une question pour aider à trouver une logique dans ton
| > argumentation.
|
| Quelle logique ?

J'avais supposé que ton argumentation avait une logique sous-jacente.
Mais s'il n'y a pas alors je comprends mieux.

| Que quand j'ai écris que je pensais
| que c'était une mauvaise idée d'avoir une GUI en C++,
| j'avais un avis différent de celui de BS, et que ça
| devait me faire revoir mes arguments ? Oui,
| sans aucun doute.

Là je ne te suis plus. D'abord, il n'y a aucune obligation à être
d'accord avec tout ce que dit BS. Ensuite comme tu dis que tu
« pensais », j'ai supposé que cette pensée était mue par une démarche
rationnelle, et donc qu'il y a avait une logique derrière.

| Sinon, t'a décidé d'aller bosser sans être passé
| par la case sommeil .

Une fois de plus, tu as faux.

-- Gaby
12 13 14 15 16