OVH Cloud OVH Cloud

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

10 réponses

Avatar
Marc Boyer
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.

| N'accordes pas trop d'importance à mon poids dans
| l'avenir de C++...

comme ils disent dans la pub mckay...


Inconnue dans mon référenciel, désolé.

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

Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Si on parle des choses qui AMHA (1) manquent actuellement
| à C++:
| - des types entiers avec détection d'overflow (leur
| arrivée dans la norme permettrait au compilateur de
| se reposer sur les bits d'overflow présents dans de
| nombreux processeurs en faisant "comme si" on testait
| lhs > numeric_limits<..>::max()-rhs)

C++ permeyt actuellement à une implémentation de lever une exception
s'il y a débordement. Mais, en aucun cas ce n'est un préalable pour
introduire un GUI en C++

| - des compilateurs qui donnent des messages plus
| explicites lorsque des templates sont en jeu

Plus concrêtement ?

Encore une fois, je ne vois pas cela comme un préalable à
l'introduction d'un GUI en C++.

| - un moyen de déterminer la signature minimale nécessaire
| à un type pour être argument d'un template (les
| solutions comme la fonction membre "constraint"
| reposent sur le programmeur)

Peux-tu préciser ?

| - des extern "Ada", extern "Java", extern "tcl"
| (liste ni minimale ni exhaustive)

C'est déjà permis.

| - je serais séduit pas une gestion de la notion
| de module avec interface/implémentation autre
| que le #include actuellement utilisé.

Plus concrêtement, qu'appelles-tu module avec interface/implémentation ?

| (1) Je rappelle que mon avis est humble, et que je
| peux évidement mal évaluer la criticité d'un problème.

C'est un forum démocratique où chacun est libre de donner son avis.

En fait, donner son avis ne coute rien...

| >| qui supporte la montée en taille d'un projet (en offrant des outils
| >| d'abstraction) et qui permette une solution implémentable
| >| demain, et pas dans un futur lointain.
| >
| > Avoir un GUI dans la norme en est un bon exemple.
|
| Avoir une bonne GUI, surement oui.
|
| >| Je ne voyais pas les IHM comme un problème de C++,
| >| mais un problème d'IHM (de même qu'un OS performant
| >| mais pas gourmand par exemple).
| >
| > Personne ne demande à C++ de résoudre les IHM. Par contre, ce que
| > certaines personnes souhaitent, c'est C++ offre un certain binding à
| > certaines notions de GUI. C'est plus que du bon sens.
|
| Mais c'est un problème différent.
| "un certain binding à certaines notions de GUI" et
| "une GUI normalisée", sont deux phrases qui évoquent
| des choses très différentes pour moi.

Bah.

| >| >| Puisque Gaby dit que BS y pense, visiblement, ça commence à venir.
| >| >
| >| > Ça commence à venir ?
| >| >
| >| > http://www.research.att.com/~bs/bs_faq.html#gui
| >|
| >| J'avais gardé de la lecture du DnE la distinction
| >| entre langage et système, et je mettais plutôt l'IHM
| >| du côté système. Je n'ai pas le DnE sous la main là,
| >| mon souvenir est peut-être faussé.
| >
| > Et as-tu suivi le lien ci-dessus ?
|
| Oui.
|
| > Encore une fois, je n'ai vu personne proposer que C++ resolve les
| > problèmes d'IHM. J'ai par contre vu des demandes facilités de GUI
|
| Il me semble que la requette de l'OP, à laquelle je
| répondais, était d'offrir une GUI minimale normalisée.
| Je n'aurais je pense pas fait la même réponse pour
| "des demandes facilités de GUI".

quelques que soient ces facilités de GUI, elles seront toujours
minimales pour un groupe d'utilisateurs ; je ne vois pas la pertinence
de ta distinction.

| >| Qu'on commence à mettre des ressources sur l'étude de
| >| la résolution de ce problème, je ne le savais pas.
| >
| > Mais il y a beaucoup de choses que tu ne sais pas ;-p
|
| C'est le problème de la frontière de la connaissance.
| Plus la surface de la connaissance augmente, plus la
| frontière avec l'inconnu augmente.

Pfffiou.

-- Gaby
Avatar
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes:
|
| Non, C++ a été conçu comme un "langage" et évolue dans ce sens.

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. A un moment, si ma
mémoire est bonne, BS explique que C++ n'est pas un
"système" complet mais un "language", non ?
Après, oui, j'ai vu ta ref sur le soucis qu'il
a de la mutliplicité de GUI pour C++. Le message
auquel tu réponds date du 9/1 d'après Google,
et le 14/1, j'ai reconnu mon ignorance.
<bu3udk$5b7$

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:
| > Marc Boyer writes:
| >
| >| Gabriel Dos Reis wrote:
| >| > vector est portable parce qu'il fait partie de la norme et que
| >| > les implémentations le fournissent. À partir du moment où on met un
| >| > GUI dans la norme et que les implémentations le fournissent, il devient
| >| > portable.
| >|
| >| Lapalisse n'est pas loin.
| >
| > L'essentiel est que ce n'en soit pas une.
|
| 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.

[...]

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

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

| > (2) penses-tu éventuellement proposer un GUI pour C++ ?
|
| Non.
|
| >| >| Cf. ci dessus.
| >| >| 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 ?
| >| >
| >| > Tu n'as qu'à essayer, tu verras.
| >|
| >| Encore une fois, une gestion de projet saine me
| >| semble commencer par une évaluation des couts et
| >| bénéfices attendus. Partir bille en tête "pour voir",
| >| cela ne me tente pas.
| >
| > Ma précédente réponse correspond à toutes les phases de la
| > réalisation d'un tel projet, y compris l'évaluation. Mais peut-être
| > ton évaluateur est une fonction récursive qui n'a pas de test d'arrêt ?
|
| Peut-être n'avons-nous pas la même définition de "Essayer"
| et "Evaluer".

Le problème n'est pas là.

[...]

| >| > Been there, done that.
| >|
| >| Words, words...
| >
| > De la part de quelqu'un qui a proposé zilk amélioration pour C++,
| > c'est..., disons, rafraichissant.
|
| Disons que quand je suis en position d'expertise et que
| j'ai face à moi quelqu'un qui prend la peine de construire
| une argumentation, j'essaye de prendre le temps de dire
| en quoi il se trompe, ou je lui dit que je ne suis pas
| d'accord mais que je manque de temps pour argumenter,
| mais j'essaye d'éviter l'argument d'autorité.

Félicitations ; tu es sur la bonne voie.

| Je ne pense pas avoir un quelconque poids dans l'évolution
| de C++. J'aurais éventuellement pu te servir à fourbir
| tes arguments contre les gens qui pensent qu'une GUI
| normalisée dans C++ est un problème trop difficile.

j'aurais voulu que c'eût été le cas...

-- Gaby
Avatar
Gabriel Dos Reis
Loïc Joly writes:

| Gabriel Dos Reis wrote:
|
| Je vais aussi répondre au sondage, histoire que l'échantillon de la
| population questionné soit > 1.
|
| > On va faire simple : réponds par oui ou non aux questions suivantes
| Répondre par oui ou non est souvent loin d'être simple...
| > (1) souhaites-tu un GUI dans la prochaine version de C++ ?
| Réponse courte : Non
| Réponse longue : Il y a trop de différences dans les conceptions d'IHM

La question de construire des IHM.

| pour que l'uniformisation qu'apporterait une norme soit utile,

je présume que quand tu dis « tuile », tu veux qualifier par
« pour une certaine catégorie ». Si une partie de la norme n'est pas
utile pour toi, tu n'es pas obligé de l'utiliser.

[...]

| > (2) penses-tu éventuellement proposer un GUI pour C++ ?
| Réponse courte : Non
| Réponse longue : Mais si une proposition est faite qui a l'air d'être
| en accord avec les objectifs énoncés question 1, je serais très
| probablement avide de l'étudier, voire de donner mon avis.

OK, c'est clair.

-- Gaby
Avatar
Gabriel Dos Reis
Marc Boyer writes:

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

Mon avis est essentiellement résumé dans

EI003
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1512.html

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

| Si on parle des choses qui AMHA (1) manquent actuellement
| à C++:
| - des types entiers avec détection d'overflow (leur
| arrivée dans la norme permettrait au compilateur de
| se reposer sur les bits d'overflow présents dans de
| nombreux processeurs en faisant "comme si" on testait
| lhs > numeric_limits<..>::max()-rhs)

C++ permeyt actuellement à une implémentation de lever une exception
s'il y a débordement. Mais, en aucun cas ce n'est un préalable pour
introduire un GUI en C++


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

| - des compilateurs qui donnent des messages plus
| explicites lorsque des templates sont en jeu

Plus concrêtement ?


<bug422$2l1$

Encore une fois, je ne vois pas cela comme un préalable à
l'introduction d'un GUI en C++.


Moi non plus.

| - un moyen de déterminer la signature minimale nécessaire
| à un type pour être argument d'un template (les
| solutions comme la fonction membre "constraint"
| reposent sur le programmeur)

Peux-tu préciser ?


Un programmeur écrit un conteneur toto<T>.
Il a besoin pour que le conteneur fonctionne de
pouvoir appeller le constructeur de copie et
de rien d'autre. Comment signifie-t-il cela
à un utilisateur ? Comment peut-il s'assurer
qu'il n'en a pas oublié ou ajouté ?

| - je serais séduit pas une gestion de la notion
| de module avec interface/implémentation autre
| que le #include actuellement utilisé.

Plus concrêtement, qu'appelles-tu module avec interface/implémentation ?


Etre plus concret, c'est déjà avancer vers une
proposition.
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.

| Mais c'est un problème différent.
| "un certain binding à certaines notions de GUI" et
| "une GUI normalisée", sont deux phrases qui évoquent
| des choses très différentes pour moi.

Bah.


Et oui.

| Il me semble que la requette de l'OP, à laquelle je
| répondais, était d'offrir une GUI minimale normalisée.
| Je n'aurais je pense pas fait la même réponse pour
| "des demandes facilités de GUI".

quelques que soient ces facilités de GUI, elles seront toujours
minimales pour un groupe d'utilisateurs ; je ne vois pas la pertinence
de ta distinction.


Tu ne vois pas de différence entre "un certain binding à
certaines notions de GUI" (tes propos) et "une petite [GUI]
par defaut" (propos de l'OP) ?
Ben, normal que tu ais du mal à voir une logique dans
mes propos.

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:
| > Marc Boyer writes:
| >|
| >| Non, C++ a été conçu comme un "langage" et évolue dans ce sens.
| >
| > 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.

-- Gaby
Avatar
Gabriel Dos Reis
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.

-- Gaby
Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Gabriel Dos Reis wrote:
| > Marc Boyer writes:
| >
| >| Si on parle des choses qui AMHA (1) manquent actuellement
| >| à C++:
| >| - des types entiers avec détection d'overflow (leur
| >| arrivée dans la norme permettrait au compilateur de
| >| se reposer sur les bits d'overflow présents dans de
| >| nombreux processeurs en faisant "comme si" on testait
| >| lhs > numeric_limits<..>::max()-rhs)
| >
| > C++ permeyt actuellement à une implémentation de lever une exception
| > s'il y a débordement. Mais, en aucun cas ce n'est un préalable pour
| > introduire un GUI en C++
|
| 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é.

[...]

| >| - je serais séduit pas une gestion de la notion
| >| de module avec interface/implémentation autre
| >| que le #include actuellement utilisé.
| >
| > Plus concrêtement, qu'appelles-tu module avec interface/implémentation ?
|
| Etre plus concret, c'est déjà avancer vers une
| proposition.

Non, pas forcément. Cela signifie simplement expliquer ce que tu
veux dire. Module, interface/implémentation veulent dire tellement de
choses pour des gens différents.
L'étape de proposition c'est quand tu proposes une solution ; pour le
moment, je veux juste comprendre ce que tu exhibes comme problæme.

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

-- Gaby