[Résolu][Débutant C++]strchr

TITM4v3rick a dit:

un compilateur ne va pas pré-calculer s.size() en "voyant" qu'une chaîne est la même tout le temps... Mais dis donc, tu me sorts quoi là ?!

Cliquez pour agrandir...

Je ne vois pas pourquoi il s'en priverait. Si tu lui demandes d'optimiser, bien sûr.

Bon amusement.
Je back le source, si tu le veux tu vas aux cours. Et puis comme ça je pète pas le layout.

Cours de quoi? Où? J'ai dix-sept ans...
Si tu n'as pas l'implémentation de size() sous la main donne moi au moins le code source en entier, par pm, par ex.

Mais pour faire simple... Imagine ceci

Justement c'est le size() qui est important. Si c'est un string comme dans Pascal, il n'y à qu'à regarder le premier octet pour avoir la taille. Si c'est un string "null terminated", il faut tout parcourir.

theodorus a dit:

Cours de quoi? Où? J'ai dix-sept ans...
Si tu n'as pas l'implémentation de size() sous la main donne moi au moins le code source en entier, par pm, par ex.

Cliquez pour agrandir...

Ok... Ca ne servirait à rien de te filer le source vu qu'il s'agit de la librairie STL.
C'est un espace de nom, un regroupement logique de fichiers .h contenant les implémentations de classes template (modèle en français).

Merde tu m'as bien eu. Moi qui ait tout parcouru en essayant de trouver la définition complète. J'ai même essayé de ravoir le source avec le bouton back!

theodorus a dit:

Justement c'est le size() qui est important. Si c'est un string comme dans Pascal, il n'y à qu'à regarder le premier octet pour avoir la taille. Si c'est un string "null terminated", il faut tout parcourir.

Cliquez pour agrandir...

Cet exemple c'est pour te montrer que derrière une méthode il n'y a pas forcément de calcul mais juste un retour d'une propriété ou plutôt d'un membre donnée.

Si tu savais ce qu'est l'OO (le pouvoir du côté obscur de la force), tu ne poserais pas une telle question.

Pour rappel, le but d'une instance de classe est d'encapsuler (de mettre ensemble) des attributs (ou membres données) et des fonctions membres (ou méthodes).

les attributs, les données, l'implémentation de la classe sont ce que l'utilisateur de la classe ne doit pas comprendre, savoir pour en tirer parti... Ca s'appelle le masquage de l'information.

Comment ça marche ?

On déclare les données comme membres PRIVES de la classe => on ne les voit pas de l'extérieur et on ne peut donc pas y accéder
On déclare les méthodes (l'interface utilisateur) PUBLICS (attention, toutes les méthodes ne sont pas forcément publics, je simplifie)

Via des appels à des méthodes on accède, on modifie les données.

exemple (simplifié tjs)

TaClasse unObjet;

unObjet.attribut1; //=> Boum, inaccessible...
unObjet.methode_SetAttrib1(...); //=> on modifie l'attribut1
unObjet.methode_GetAttrib1(...); //=> on accède à l'attribut1

Je sais très bien tout çà (enfin je que je peux appliquer à partir de Ada95), mais si size() utilisait une autre méthode non publique, j'aurais été voir celle-là, c'est tout. Ce que je veux c'est l'algorithme, aussi bas niveau soit-il, qui calcule la longeur de la chaîne qui permeterai de savoir le temps qu'il prend (et du même coup quel type de chaîne la classe string utilise pour stocker le texte.)

edit: ou alors size() ne fait que retourner un attribut "taille", mais c'est pareil question rapidité, il aura falu calculer cet attribut à un moment donné.

theodorus a dit:

Je sais très bien tout çà (enfin je que je peux appliquer à partir de Ada95), mais si size() utilisait une autre méthode non publique, j'aurais été voir celle-là, c'est tout. Ce que je veux c'est l'algorithme, aussi bas niveau soit-il, qui calcule la longeur de la chaîne qui permeterai de savoir le temps qu'il prend (et du même coup quel type de chaîne la classe string utilise pour stocker le texte.)

edit: ou alors size() ne fait que retourner un attribut "taille", mais c'est pareil question rapidité, il aura falu calculer cet attribut à un moment donné.

Cliquez pour agrandir...

ya pas moyen de te donner un bas niveau compréhensible à la lecture. Il faut savoir que la STL c'est aussi un paquet de classes spécialisées (je parle d'héritage) => ce n'est pas un simple tableau dynamique d'éléments primitifs.

Faudrait t'expliquer la généricité du C++...
Le fait de pouvoir générer des classes avec des types primitifs et/ou de type utilisateur.

Trop lourd pour un forum => Bjarne Stroustrup

Mes meilleurs bouquins de C++ :
C++ de Bjarne Stroupstrup (quand tu as lu les 2 autres)
Comment programmer en C++ de Deitel & Deitel (quand tu as lu Delannoy)
Programmer en C++ de Claude Delannoy (c'est bien pour commencer)

Donc, selon toi, on doit programmer en C++ sans savoir comment il marche. Donc pas d'optimisations, du code peut-être redondant, etc... c'est ce qui m'attend si je veux programmer en C++? Très peu pour moi.

Simple, rapide, efficace. Je suis quasi sûr que c'est plus rapide que ton algo en C++, mais à ce rythme-là on ne le saura jamais...[/code]

edit: petite erreur de C

Te montrer un code, c'est pas forcément parlant.
Pour faire simple, tu veux créer une classe qui te donneras des instances de tableaux d'entiers (exemple une pile)...

Qu'as-tu besoin de savoir au niveau utilisateur ?
- le sommet de la pile
- le nombre d'éléments dans la pile
- la pile est-elle vide ?

Qu'aimerais-tu pouvoir faire en tant qu'utilisateur de la classe ?
+ créer une pile d'entier
+ ajouter un élément
+ retirer un élément
+ des méthodes pour savoir ce qu'il y a au sommet de la pile,
le nombre d'éléments dans la pile et savoir si elle est vide (par exemple)

Quand tu vas instancier (créer) un objet (une pile d'entiers) de ta classe, ton constructeur va s'occuper de créer ce qu'il faut...
Quand tu vas ajouter un entier à la pile, la méthode va en même tps incrémenter le nombre d'éléments (ici, on ne parcourt pas pour savoir cb il ya d'éléments, non, ici on le dit...)

Quand tu vas demander la taille de ta pile, la méthode ne vas pas s'amuser à parcourir ton vecteur, ton tableau, ton implémentation pour renvoyer le résultat. La méthode va se simplifier la vie (enfin, le programmeur va "optimiser") en renvoyant la valeur de l'attribut directement.

Alors pour faire simple, la STL n'a pas été conçue par un innocent.

Donc ton objet pile maintient un attribut "taille" privé qu'il entretient à chaque appel de méthodes relatives à la taille de la pile, et peut instantanément connaître sa taille. C'est donc le même principe que les strings Pascal. Est-ce que cela s'applique aux objets Strings? Ils ont un attribut qui représente leur taille en permanence? Alors le problème de performances ne se trouve plus quand on veut savoir la taille, mais lorsqu'il s'agit de la calculer... Imaginons que je veuille ajouter une chaîne de caractères (venants d'un fichier quelconque) à mon objet String, il va devoir la parcourir pour calculer la taille à ajouter quand même. Le système n'utilise pas des Strings C++, lui. D'un autre côté, c'est vrai que le calcul n'est fait qu'une fois et qu'on peut se servir des résultats rapidement. Mais imaginons deux threads travaillant sur le même string.. non ça devient de la branlette intelectuelle .

(La bibliothèque standard du C n'as pas non plus été conçue par des innocents et pourtant les fonctions de traitement des strings parcourent allègrement toutes les chaînes en long et en large )

Pour le calcul, oui on ne le fait qu'une seule fois.

Là, je fais très très lite : dès que tu en as la possibilité (en C++ donc) utilises la classe string de la STL et oublie le vieux char * pour des raisons de sécurité, de maintenance, de portabilité et de réutilisabilité (bref, à cause de l'OO)

la classe string intègre de nombreuses méthodes (interface publique) mais en hérite bcp aussi dont size() qui est une méthode que tu retrouves avec les conteners de la STL tels que vector, deque, list, map...

OK, mais ça m'arrangerait mieux d'avoir la preuve concrète que String a un attribut taille. :wink:
Pour la maintenace et la portabilité d'accord, mais pour la sécurité, qu'est ce qui empêcherait un prgramme en C++ d'avoir de buffers overflows à cause d'un String (ou autre), comme tu avais l'air de le dire? Je n'ai pas compris comment il peut lever une exception (et d'ailleurs à quel évenements précis réagit-il?)

theodorus a dit:

OK, mais ça m'arrangerait mieux d'avoir la preuve concrète que String a un attribut taille. :wink:
Pour la maintenace et la portabilité d'accord, mais pour la sécurité, qu'est ce qui empêcherait un prgramme en C++ d'avoir de buffers overflows à cause d'un String (ou autre), comme tu avais l'air de le dire? Je n'ai pas compris comment il peut lever une exception (et d'ailleurs à quel évenements précis réagit-il?)

Cliquez pour agrandir...

tu ne trouverais pas un tel attribut dans string mais plus haut vu que d'autres classes génériques s'en servent.
le mécanisme d'exception c'est encore une autre histoire, un exemple ce sont les effets de bords...

Bon j'ai trouvé mon compte dans vos propositions et NON je ne travail pas que à l'école si je faisait que ça je ne serait pas suivre, j'ai jsute une vie à côté aussi :?

Merci pour votre aide en tt cas !