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
9 10 11 12 13
Avatar
breholee

Et des membres respectables du comité, comme Dietmar Khül, pensent
que std::string n'est pas un vrai type chaîne de caractère -- et je
suis plutôt sympatisant de cette pensée.


Ça je veux bien le croire, mais c'est une critique sur ce qui a
finalement été adopté. Je suppose qu'une démarche dans le sens de
l'ajout d'un type chaîne de caractère était bien là. Je voulais juste
opposer ça à ce que Ricky propose : un simple ajout de quelques
services rudimentaires. Je trouve que chaque concept introduit en C++
va au-delà d'un simple petit ajout, même si le résultat n'est pas
parfait. Et donc son souhait de n'avoir que quelques ajouts
rudimentaires pour la GUI ne me paraît pas cohérent avec ce qui a été
fait pour le reste (que je n'idéalise pas pour autant).

| C'est pourtant ce que tu veux, puisque les toolkits existants sont
| considérés trop compliqués.

Tu as un pointeur vers ces évaluations de toolkits existants, dit
« trop compliqués » ? « Trop compliqués » peut vouloir dire « trop
compliqués » d'utilisation, par forcément « trop compliqué » en
fonctionnalités.


Je me suis sûrement mal exprimé, j'aurais dû dire « puisque tu
considères les toolkits existants trop compliqués ». Je ne reprenais
dans cette phrase que son avis (mais je ne le partage pas).

Avatar
Gabriel Dos Reis
(=?iso-8859-15?q?Benoît_Bréholée?=) writes:

|
| > Et des membres respectables du comité, comme Dietmar Khül, pensent
| > que std::string n'est pas un vrai type chaîne de caractère -- et je
| > suis plutôt sympatisant de cette pensée.
|
| Ça je veux bien le croire, mais c'est une critique sur ce qui a
| finalement été adopté. Je suppose qu'une démarche dans le sens de
| l'ajout d'un type chaîne de caractère était bien là. Je voulais juste
| opposer ça à ce que Ricky propose : un simple ajout de quelques
| services rudimentaires. Je trouve que chaque concept introduit en C++
| va au-delà d'un simple petit ajout, même si le résultat n'est pas
| parfait. Et donc son souhait de n'avoir que quelques ajouts
| rudimentaires pour la GUI ne me paraît pas cohérent avec ce qui a été
| fait pour le reste (que je n'idéalise pas pour autant).

OK, dans ce cas, nous sommes sur la même longueur d'onde.

-- Gaby
Avatar
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes:
| > ensuite le but du cpp n'a jamais ete d'etre complet ! normal ... mais de
| > resoudre des problemes vitaux, si
|
| Mais je ne sais pas si la GUI fait partie des
| problèmes vitaux adressés par C++.

Et que penses-tu que les problèmes vitaux de C++ sont ?
Merci de ne pas éluder la question.


Permettre d'écrire la partie calcul d'un code
de manière portable, efficace, au typage qui protège
le programeur contre son étourderie, 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.
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).

| 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é.
Qu'on commence à mettre des ressources sur l'étude de
la résolution de ce problème, je ne le savais pas.

Un certain nombre d'entre nous pensent qu'une bibliothèque standard
peu extensive est un vrai fondamental pour le futur de C++. En
conséquence, nous sommes de l'opinion que la prochaine version de C++
devrait être ambitieuse côté bibliothèque.


s/vrai fondamental/vrai probleme fondamental ?

Bon, je prends note.

De la même manière que BS a bâti une « wishlist » pour l'EWG, Matt
Austern voudrait en avoir une pour le LWG. Il a envoyé une requête à
BS -- qui a une compilation de voeux divers et variés. Par nécessité
de fait, j'ai eu à discuter de cette liste avec BS. Et je sais que la
mention de GUI y figure. Je sais également *de fait* que le GUI est un
problème qu'il considère majeur et que lui-même rencontre
quotidiennement dans son travail -- et cela n'est pas récent.

Je crois pas qu'il aura le temps de proposer un GUI lui même, je ne
crois pas que j'aurais le temps d'en proposer un, et je ne crois pas
que Matt aura le temps d'en proposer un. Mais si quelqu'un arrive avec
une proposition sérieuse sur la table, nous serions plus
qu'enthousiastes pour l'examiner.


Oui, et je ne serais pas étonné que, hormis la qualité de
rédaction d'une telle proposition, des critères que j'ai présenté
(facilité d'implémentation portable, équilibre entre minimalité
et extensivité...) ne soient pas pris en compte pour évaluer
son "sérieux".

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

| > Tu cherches des arguments contre quoi exactement ?
| > Il y a au moins deux choses que tu sembles confondre : le souhait
| > d'avoir un GUI dans la norme et une spécification d'un tel GUI.
| > Tu argues pour/contre quoi exactement ?
|
| J'essaye de donner des pistes d'avaluation des couts
| liés à l'intégartyion d'une GUI à la norme C++.

Mais tu réponds à côté de la question.

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
(mais je ne pense pas que mon avis personnel influe beaucoup
sur l'avenir de C++).

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

| > Si le comité a une proposition concrète sur la table, je crois qu'il
| > l'examinera indépendamment de ce que ce soit plus facile ou plus
| > difficile qu'une class string internationalisable.
|
| Bien sur, mais *avant* d'avoir une proposition concrette,
| il faut la batir cette proposition, non ?

Ciel !

| Et ce n'est pas un effort nul, voire négligeable, non ?

Essayer de trouver la tête et la queue de ton raisonnement demande
un effort non néligeable, effectivement.


J'ai essayé de présenter ce qui rend une bonne GUI C++
difficile à concevoir, et les dangers d'en avoir une
mauvaise.
Après, on peut me reprocher de surestimer les
difficultés ou les dangers.

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

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:
| >| > ensuite le but du cpp n'a jamais ete d'etre complet ! normal ... mais de
| >| > resoudre des problemes vitaux, si
| >|
| >| Mais je ne sais pas si la GUI fait partie des
| >| problèmes vitaux adressés par C++.
| >
| > Et que penses-tu que les problèmes vitaux de C++ sont ?
| > Merci de ne pas éluder la question.
|
| Permettre d'écrire la partie calcul d'un code
| de manière portable,

Qu'entends-tu par portable exactement ?

| efficace,

C++ le permte déjà. Ou alors as-tu un exemple spécifique sous la main
et à quoi cela devrait ressembler ?

| au typage qui protège le programeur contre son étourderie,

C'est déjà le cas et cela a toujours été un critère de conception.
As-tu une vision de comment cela pourrait être améliorer concrêtement
?

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

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

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

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

| 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

| > Un certain nombre d'entre nous pensent qu'une bibliothèque standard
| > peu extensive est un vrai fondamental pour le futur de C++. En
| > conséquence, nous sommes de l'opinion que la prochaine version de C++
| > devrait être ambitieuse côté bibliothèque.
|
| s/vrai fondamental/vrai probleme fondamental ?

Whatever.

| > De la même manière que BS a bâti une « wishlist » pour l'EWG, Matt
| > Austern voudrait en avoir une pour le LWG. Il a envoyé une requête à
| > BS -- qui a une compilation de voeux divers et variés. Par nécessité
| > de fait, j'ai eu à discuter de cette liste avec BS. Et je sais que la
| > mention de GUI y figure. Je sais également *de fait* que le GUI est un
| > problème qu'il considère majeur et que lui-même rencontre
| > quotidiennement dans son travail -- et cela n'est pas récent.
| >
| > Je crois pas qu'il aura le temps de proposer un GUI lui même, je ne
| > crois pas que j'aurais le temps d'en proposer un, et je ne crois pas
| > que Matt aura le temps d'en proposer un. Mais si quelqu'un arrive avec
| > une proposition sérieuse sur la table, nous serions plus
| > qu'enthousiastes pour l'examiner.
|
| Oui, et je ne serais pas étonné que, hormis la qualité de
| rédaction d'une telle proposition, des critères que j'ai présenté
| (facilité d'implémentation portable, équilibre entre minimalité
| et extensivité...) ne soient pas pris en compte pour évaluer
| son "sérieux".

Disons les « critères » que tu dis avoir présentés me paraissent...
absents.

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

(=?iso-8859-15?q?Benoît_Bréholée?=) writes:

| Je ne sais pas s'il y a des objectifs officiels, ou si ça pourrait se
| résumer. Mais en regardant ce langage, il semble que quand un concept
| y est mis, il n'y est pas à moitié. Les chaînes de caractères sont
| utiles, donc on ne se contente pas de pointeurs sur des caractères, il
| faut un vrai type.

Et des membres respectables du comité, comme Dietmar Khül, pensent que
std::string n'est pas un vrai type chaîne de caractère -- et je suis
plutôt sympatisant de cette pensée.


Est-ce principalement à cause de la présence de fonctions non constantes
qu'il pense ce genre de choses ?

--
Loïc

Avatar
Loïc Joly
Gabriel Dos Reis wrote:

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


Je pense que c'est là une différence fondamentale et qui correspond plus
à mes attentes.
En particulier, j'y vois un parallèle avec un argument pour
l'introduction des threads dans la norme : Ce n'est pas tant les threads
eux-mêmes qu'il est important de normaliser, mais c'est plutôt l'impact
que les threads peuvent avoir sur le reste du langage ("core" comme
bibliothèque).

Quelles sont donc les notions les plus citées pour des GUI ?

J'y vois à première vue :
1- les notions de propriétés (sous les deux formes usuelles qui sont
souvent confondues dans les discussions à ce sujet : Les propriétés
entant qu'autre écriture pour des appels de fonction, et les propriétés
en tant que fonction pouvant être appéles pendant le codage.

2- Les notions de callback

3- Peut-être moins de nuances entre les phases de codage et celles
d'exécution

4- La gestion de code à la fois généré par des outils et retouché par
l'humain


| > Je crois pas qu'il [BS] aura le temps de proposer un GUI lui même, je ne
| > crois pas que j'aurais le temps d'en proposer un, et je ne crois pas
| > que Matt aura le temps d'en proposer un. Mais si quelqu'un arrive avec
| > une proposition sérieuse sur la table, nous serions plus
| > qu'enthousiastes pour l'examiner.


Ce que je trouve vraiment dommage actuellement, c'est que je n'ai pas
encore rencontré de bibliothèque qu'IHM qui tire vraiment profit des
facilités du C++ (et en particulier de sa bibliothèque), mais plutôt des
bibliothèques écrites en "C with classes". Je ne sais pas trop à quoi
c'est du. Probablement en grande partie au temps énorme qu'il a fallu
pour que les compilateurs commencent à compiler du C++ selon la norme.

--
Loïc

Avatar
Loïc Joly
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
pour que l'uniformisation qu'apporterait une norme soit utile, possible
ou même souhaitable. Une IHM de téléphone portable ne ressemble pas à
une IHM sur PC qui ne ressemble pas à une IHM de voiture. Par contre, il
est possible que toutes les IHM utilisent certains concepts communs
qu'il serait souhaitable de normaliser. Enfin, s'il existe par système
une norme d'IHM en C++ dissociée de la norme du C++, je n'ai rien contre.


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

--
Loïc

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

| Gabriel Dos Reis wrote:
| > Marc Boyer writes:
| >| > ensuite le but du cpp n'a jamais ete d'etre complet ! normal ... mais de
| >| > resoudre des problemes vitaux, si
| >|
| >| Mais je ne sais pas si la GUI fait partie des
| >| problèmes vitaux adressés par C++.
| >
| > Et que penses-tu que les problèmes vitaux de C++ sont ?
| > Merci de ne pas éluder la question.


Commençons par préciser qu'il s'est produit là un glissement
sémantique important: je ne parlais pas des problèmes que
C++ a, mais de ceux qu'il cherche à résoudre.

Et globalement, je pense que C++ actuellement
résoud les problèmes que j'évoquais.

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)
- des compilateurs qui donnent des messages plus
explicites lorsque des templates sont en jeu
- 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)
- des extern "Ada", extern "Java", extern "tcl"
(liste ni minimale ni exhaustive)
- je serais séduit pas une gestion de la notion
de module avec interface/implémentation autre
que le #include actuellement utilisé.

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

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

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

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

| Oui, et je ne serais pas étonné que, hormis la qualité de
| rédaction d'une telle proposition, des critères que j'ai présenté
| (facilité d'implémentation portable, équilibre entre minimalité
| et extensivité...) ne soient pas pris en compte pour évaluer
| son "sérieux".

Disons les « critères » que tu dis avoir présentés me paraissent...
absents.


Puisque nous ne parlons déjà pas de la même chose
initialement, il est clair que les critères sont inadéquats.

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

Avatar
kanze
Loïc Joly wrote in message
news:<bu4pim$q7q$...
Gabriel Dos Reis wrote:

(=?iso-8859-15?q?Benoît_Bréholée?=) writes:

| Je ne sais pas s'il y a des objectifs officiels, ou si ça pourrait
| se résumer. Mais en regardant ce langage, il semble que quand un
| concept y est mis, il n'y est pas à moitié. Les chaînes de
| caractères sont utiles, donc on ne se contente pas de pointeurs
| sur des caractères, il faut un vrai type.

Et des membres respectables du comité, comme Dietmar Khül, pensent
que std::string n'est pas un vrai type chaîne de caractère -- et je
suis plutôt sympatisant de cette pensée.


Est-ce principalement à cause de la présence de fonctions non
constantes qu'il pense ce genre de choses ?


Je ne peux pas parler pour Dietmar, mais en général, je ne vois pas en
quoi on pourrait considérer std::string une abstraction d'une chaîne de
texte. Ce n'est qu'une collection comme une autre.

Une chaîne de texte aurait des fonctionnalités qui concerne le texte, et
non seulement des fonctionnalités qui permet d'insérer ou de supprimer
des éléments d'un type de base. (N'oublions pas que char, ce n'est pas
un type de caractère non plus, mais simplement un autre type d'entier.)

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


9 10 11 12 13